I’ve been using a simple parameterManager class in my VSTs. It’s basically an array of floats and get/set methods. I make one in the main filter constructor and pass the pointer out to all the classes it uses.
I’m thinking of making it into a more generic/reusable thing and theres a couple of things that could go into it.
Mapping of bools and ints to 0-1 floats for use with automation for one. It could be thread safe and simplify the connection of gui to parmeters, presuming it wraps the notifying-host bit.
And, and here’s where I’m out of my depth so to speak, it could have an option to generate the gui based on parameter meta data. Kind of like the VST standard gui but much nicer looking.
The point being that a new parameter only results in one or two new lines of code rather than 15 or so, and it could probably work well togther with VST2.4 where you can define the parameters more freely.
And then I thought, hey, if Jules did it, it might even work!
…I could probably do it myself, but I’m thinking it might make a nice addition to the framework.
i made a parameter management scheme for my extension to the juce audio plugin (a bunch of ‘enhanced’ base classes to use instead of the filter and editor bases).
i hadn’t considered making an auto-generating GUI, but it should be reasonably simple, as long as you’re happy with the parameters defaulting to sliders for all parameters. it could be reasonably easy to specify the type of control desired for a parameter too (the parameter base object could have an enumeration that could indicate this). An array of the Parameters could then be used to populate an ‘AutomaticFilterGui’ Component object. This would simply read through all the Parameters and create a new control widget on the panel. [this would also be a nice way to automatically link a parameter to its GUI widget, creating a direct link for updating/setting purposes.]
If you’re happy with an automatic layout that’s fine too. But i guess it could be straightforward to extend the Parameter base with a Rectangle indicating the desired size and position on the GUI.
All in all i think it should be fairly simple to add this feature to a nice working Parameter management system.
I have also made a set of parameter classes. My design is not as full-featured as haydxn’s, and is more work to use, but it’s very flexible and lightweight.
The tree of base classes is in AudioPluginParameter.h. Subclasses for this project (BitControl) are in BitControlParameter.h. (I know there’s not much documentation – sorry about that)
This design is working out well for me; it allows me to connect parameters to controls arbitrarily, which I need for this project, and it allows the parameter data to be stored in any form, while transparently handling 0-1 mapping. The rest of the program will change a good deal, but I think this will stay.
Another feature to consider for the framework might be additional support for program management, since so many plugins need that. But that would be another thread, I think …
I’ve not had time to check out the classes that you guys came up with, but did any of you think about using the PropertyComponent classes for this? That way you could just throw a bunch of them into a PropertyPanel like the Jucer’s…
The property panel stuff is cool and all, but i personally don’t really like the way they look. i know i could override the look and feel stuff for changing the way they’re painted, but i kinda prefer a bit more control over the appearance of everything. It sure is a timesaver, granted. But so far, any time i’ve encountered a situation where that’s almost the solution, i’ve ended up going for a custom approach instead (i just prefer a tailored look! and they’re really big!).
of course, please don’t take this as offence or criticism! it’s a marvellous system you have there, i just choose not to use it myself.
I did know about the JUCE property system, but I didn’t use it, because it didn’t seem quite right for my purposes. But I’ll confess that I hadn’t looked at it as closely as I should have – now I have studied it harder, I think the design is a very good one for application preferences and object inspectors, but perhaps not best for plugins. Here is why:
Parameters are indexed by name. The plugin wrapper wants them indexed by number. To support automation, you need a fast mapping from number to component and back. The Property classes don’t provide this (although it could be added easily enough).
The plugin wrapper wants a mapping for each (scalar) parameter to 0-1 and back. Again, the Property classes do not provide this.
The PropertyPanel is very handy for preferences dialogs and inspectors, but I think it isn’t particularly useful for plugins, which typically have elaborate custom panels. An automatically generated editor is nice, but I do not think most people would want this for their plugin editor; and many hosts already provide automatically made editors for plugins.
There’s not a clear provision for attaching custom controls to properties. It can be done, but not very conveniently. (In fact, the mechanism by which properties are associated to PropertyComponents is not immediately clear.)
The Property classes store values internally. This isn’t always a good thing for plugins. My plugin must transmit an 80-byte sys-ex block containing all 50 parameters whenever a parameter is changed. (My plugin is an editor for an old synthesiser with a poor MIDI implementation.) To save time, I keep the parameters in a preformatted sys-ex block, and my parameter objects operate directly on this, so that I don’t have to synthesise a new block every time I update a parameter. I could perhaps do this with the Property classes, but not so conveniently.
I think it may be possible to do a set of classes that everybody would be happy to use for plugin parameters, but I don’t think it’s been done yet. If it is, it should be integrated into the wrapper. (And I still think it will also provide for patch management.)
Mr Storer, you’re evidently a talented library designer – I’d bet you could do it.
