Short answer: I ended up using a separate TextEditor because it allows more control over layout and look and feel, and simplified the workarounds to get keyboard input working in all platforms. The “warping” of the parameters, and converting their values to Strings seemed to be worth extracting into dedicated classes to keep TextEditor, Slider and host automation in synch. Especially since it has do be done over and over again at many different places in the code (if you have more than a few parameters)
A plugin we developed last year required a lot parameters to be manipulated, saved or automated. Doing all the serialization and normalization in our AudioProcessor subclass would have become messy, and the same kind of conversions between internal, “warped” values and their string representations are also needed when changing or displaying parameters in the GUI (some with standard, some with custom JUCE components).
Heavily summarized, I ended up with
- a set of classes to define parameters, their value ranges, validation and conversion rules
- a set of listeners to connect standard JUCE components to these parameters
- an AutomatedAudioProcessor class that implements the persistence and automation of plugin-parameters in a generic way
This might sound a bit over-engineered to some, but looking back it was well worth the effort. It turned out to be quite useful, not only for plugin automation and GUI, but also for (de)serializing the state of your audio-chain (undo/redo, copy/paste, command line parsing, unit-tests)
I am wondering if anyone would be interested in these classes, since the topic of interaction between your plugin’s parameters, JUCE components and the host automation comes up quite often in the forum. Also it’s required for pretty much every plugin and not exactly fun to implement again and again.
Since its way too much code to post in the forum, this might be a good candidate for contributing a 3rd-party module. But it’s not exactly light-weight, and needs some major cleanup in some parts before publishing it (and even then it won’t reach JUCE’s level of documentation soon). So before committing to quite a bit of work, I’d like to know if there’s anyone out there who’d actually use it and/or is interested to do some nitpicky code/design review to help me improve the code quality.
If you’re interested I can post some examples tomorrow, so you can get a better idea of the functionality and level of complexity to expect.