Sharing warping between sliders and parameters - how, I ask?

Audio Plugins
1

Hi all,

In my current plugins, I am using the built-in warping in the Slider class to create a usable range (I’ve added bipolar warping, which is useful for pitch and frequency shifting). However, having the warping in the Slider means that people that use the DAW automation on the low level parameters will have no warping, or some sort of messed up warping. I could warp the parameter itself, but this would break the relationship between the slider and the slider text display/editor.

Any ideas on how to resolve this issue?

Thanks,

Sean Costello

2

I think the cleanest solution is to warp the parameter itself (as quadratic/logarithmic scale), and then calculate the right text in the slider and vice versa.

3

The question is, how to sync the text up with the slider? Should I use the text editor that comes with the slider, warp the slider, and then do some “unwarping” of the parameter that is sent out in order to have it work properly with the warped low level parameter? Or should I just use an independent text editor from the slider? Or…?

Thanks,

Sean Costello

4

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)

Long answer:
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.

5

Sounds great :smiley: