Expose AudioParameterInt/Float member functions

Many times I’m passing the strongly typed parameter (AudioParameterInt/Float/etc) by reference to other classes/functions.

However, there are extremely useful member functions that are public in the AudioProcessorParameter base class, like getValue(), setValue(), getText(), etc, but are private in the concrete implementation. That means they require an ugly cast to the base class to be accessible.

Is there a reason why those aren’t public? I would like to avoid passing by the base class pointer, because then I’ll lose functions like get() that are very helpful.


For AudioParameterFloat and the others, you can cast to the underlying type to get the value, and just call = to set the value.


Yes, I’m aware I can achieve this with either downcasting or upcasting, I’m just not sure it’s needed in this case.

I guess these are private because of the ambiguity that setValue/getValue access the normalized/stored values (0…1) .

That’s the thing, in many situations I think you need either, or both, on the same parameter.

For example many times in a processing function, I might want to do something like:

void someProcessFunc(AudioBuffer<float>& buffer, AudioParameterInt& param)
    //The minimum normalized value means no processing at all
    if (param.getValue() > 0.f)
        //processing function needs the real world value:
        actualProcess(buffer, param.get());
1 Like

this post needs to reappear at the top of the forum again. in the process of implementing a better parameter system than i had before i needed to ditch AudioProcessorValueTreeState and work with the “raw” AudioParameterFloats. at some point i tried to use getDefaultValue() and was very confused to find out it’s private and one has to actively cast it back to the base class in order to use the method. This method and the ones around it should definitely not be private. Even if their names don’t make it 100% obvious if some of the values they return are normalized or denormalized it would only take a minute to print it to the console and see for yourself, while figuring out this casting-back-stuff takes much longer and doesn’t look nice in the code.

I tend to define things like the min, max, defaults, skews, etc. of parameters in constants rather than trying to get that info from the parameter directly, although it’d certainly be convenient to have that info available.

As a workaround, you could create your own Parameter class to wrap parameters and encapsulate the messy dynamic-casting needed to get the full functionality.

1 Like

that sounds like a good solution for me for now, yes. i also have it working fine with the casting atm, but it would certainly be best if it just worked the way mostly everyone would expect it to work

1 Like

I would advise against that approach. Having redundant information is rarely a good idea in the long run.

To access the min, max, or even to do all conversions prefer to retrieve the NormalisableRange that is available in any RangedAudioParameter heir.

Only for the default value I have no workaround yet, I think it is a fair request to get an accessor so custom components can use it.

1 Like

ok so… we are talking about these things here and my take is the following:

if it’s so bad, that the functions getValue() and setValue() are ambiguous because one doesn’t see if they are normalized or denormalized then

  1. the function get() doesn’t make it better in the slightest and it’s public.
  2. JUCE could just rename these functions like getNormalized(), setDenormalized() etc.

apart from that it’s easy peasy to DBG the output values while dragging their sliders and just check for yourself what they do. that’s why i say that this is not very ambiguous and problematic in the first place.

then the getDefaultValue(). we already agree on that. needs to be public!

getNumSteps() should also be public, so one can make custom parameter types with certain intervals. but idk, NormalizableRange probably already has something like that.

getText and getValueForText can be useful too and should be public, for example for being displayed on a popup display when hovering a parameter, or in the tooltips section.

even the std::functions might benefit from being public tbh. that might be useful for parameters that pretend to change range. like when you wanna make a rate-parameter that can be free in hz or synced in beats. at the moment i personally tend to make these 2 seperate parameters, because it’s just easier to do so in this framework, but a little change like this could change that.