Getting the 'full range' value of an AudioProcessorParameterWithID

I created an audioProcessorParameterWithID with a specific ‘valueRange’ using AudioProcessorValueTreeState::createAndAddParameter()
How do I get the full range (i.e. not normalized) value of the parameter then?

I can do the following :

AudioProcessorParameterWithID* param = processorValueTreeState.createAndAddParameter (...);
float fullRangeValue = processorValueTreeState.getParameterRange (param->paramID).convertFrom0to1 (param->getValue());

but there must be a less cumbersome way that I missed?

by the way it’s easy to get confused with parameters ranges/values. Often when I write param->getDefaultValue() I need to go inside the code to check if the value will be normalized or not…
It would be cool if the documentation was explicitly stating when the values are normalized or not (would be even better if it was in the methods/parameters names directly actually). But actually it’s perhaps always normalized and I’m the only to get confused with that? :slight_smile:

1 Like

AudioProcessorParameterWithID has no normalisation logic, but the derived internal Parameter class may have, but this class is hidden in the implementation.

One of the big problems i have with AudioProcessorValueTreeState is that reimplements logic, which ich also available in classes like AudioParameterFloat.

@Roli:
wouldn’t it make access to extend the AudioProcessorParameterWithID interface with virtual methods to get the unnormalised values?

This method could be also use AudioParameterFloat and co…

2 Likes

Just to insist about documenting (or better naming parameters) when values are normalised or not :

the “newValue” given by this is “full range” :
AudioProcessorValueTreeState::Listener::parameterChanged (const String& parameterID, float newValue)

while the “newValue” given by this is normalised :
AudioProcessorParameter::Listener::parameterValueChanged (int parameterIndex, float newValue)

that’s quite confusing…

1 Like

If it can be of any help for future terminology decisions, in my company we use “user value” to indicate the “full range” value, because those values are those that are meaningful for the human user (expressed in Hz, dB, etc.) while, of course, “normal value” is the one in the 0…1 range.

Great idea, maybe even define those three:

  • normalised value: 0…1
  • user value: min…max
  • display value: SI value: min…max like Hz / kHz or km / m / cm including suffix.

just to update the thread, there is :
float* AudioProcessorValueTreeState::getRawParameterValue (StringRef paramID)

2 Likes

Similarly, I’m confused as to why the range is not available as a member of AudioProcessorParameter/AudioProcessorParameterWithID?

It’s a bit awkward when you already have a pointer to your parameter to then have to grab the range from the APVTS with processorValueTreeState.getParameterRange(param->paramID)