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.
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());
}
}
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.
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
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
the function get() doesn’t make it better in the slightest and it’s public.
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.
