Hi!
This is my first post, but I have already gotten an enormous amount from this forum just by reading others’ posts - Thank you!
I am building an audio plugin and I would like the user to be able to select the units for some of the controls - like Hz vs radians/sec or similar.
I’m thinking I could do this with a single slider/parameter for each control by overriding Slider::getValueFromText and Slider::getTextFromValue so that there is a conversion factor that depends on a user preference. The only drawback that I can think of is that the automation will be stuck in the units of the underlying parameter - not sure if it’s possible to configure that.
Another approach would be to make a slider and a parameter for each unit and just change which is visible based on the user preferences and then sync them all. This feels like a lot of extra stuff to keep in my APVTS and a lot of housekeeping to make sure they are all in sync. In this case, I could allow each ‘unit’ to be automated, but this would allow a scenario where a user is simultaneously automating two parameters that control the same underlying dsp value, which feels like something to avoid.
Any suggestions for how to approach this?
Thanks!
Ben
You’re right that the underlying parameter must be fixed to the “default” units. I would conceptualize this feature as basically different ways of viewing the parameter value in the GUI.
What I would typically do is have the slider convert to/from the default units to display whatever mode the user has selected. You can either support all modes in one slider class, or (my preferred method) create one slider for each display mode, position them all in the same spot, and only make the active one visible.
All I would store in the APVTS is the parameter value (in the default units) and which display mode is active. I wouldn’t store the parameter value in every different units, I would just store only the default units and then do conversion on the GUI side.
1 Like
JUCE already has a great system in regard to parameters and their views. the processor owns the parameters. every float parameter has a normalized and a denormalized value, defined by its range and conversion functions. but most importantly there are lambdas for valueFromString and stringFromValue. the latter is ideal for drawing a value to the screen to the user, not only on the sliders via parameter attachments, but also when the value is shown in automation lanes of most DAWs.
so now trying to manually make the slider look different from the stringFromValue function would be a downgrade from this perfect structure.
in order to maintain it, you have to make sure your stringFromValue function doesn’t just paint a single unit, but actually knows how to draw all variations. this could be done with a conditional inside of the function, which looks at a reference of a value that represents the current state of the unit that should be shown to the user. such a reference can easily be set up if in your processor’s initializer list an object of that value is created before the parameter and its stringFromValue function. make sure to also consider to serialize that state
1 Like
Thanks so much for the advice - this was super helpful.
I managed to get the behavior I was looking for using the parameters’ stringFromValue and valueToString lambdas as well as the sliders’ textFromValue and valueFromText lambdas.
I couldn’t figure out a simple way to configure the parameter’s labels to change along with the selected units - they seem to be fixed once the parameter is constructed. If anyone knows a way around this, I’d be curious, thanks.
