AudioProcessorValueTreeState::Parameter::getText() normalised or non-normalised argument?

General JUCE discussion
1

Is AudioProcessorValueTreeState::Parameter::getText() expected to be passed a normalised or non-normalised value? Unless I misreading the code, it looks like this expectation depends on whether valueToTextFunction is nullptr:

String getText (float v, int length) const override
{
    return valueToTextFunction != nullptr ? valueToTextFunction (range.convertFrom0to1 (v))
                                              : AudioProcessorParameter::getText (v, length);
}

Shouldn’t this be AudioProcessorParameter::getText (range.convertFrom0to1 (v), length); ?

Otherwise, what have I missed here?

2

It expects a normalised value. The code is correct as AudioProcessorParameter::getText expects the value to be normalised as well so a convertFrom0to1 would lead to the wrong result.

3

Ah right, so valueToTextFunction expects a non-normalised value, but should effectively return a string representation of the value on a “normalised” scale (in order to be consistent with AudioProcessorParameter::getText) …?

Otherwise if you have a set of parameters, some of which set valueToTextFunction and others don’t, Parameter::getText() is going to return string representations on a mix of normalised and non-normalised scales.

Also: why doesn’t valueToTextFunction take a normalised value?

4

Yes that’s exactly it.

I guess we wanted it to be an easy replacement for AudioProcessorParameter::getText so that the switch-over to the new parameter system would be more straight-forward.

5

I agree, this is inconvenient!
When we create a simple parameter this way :

pluginTreeState.createAndAddParameter ("paramID",
                                       "paramName",
                                       "%",
                                       NormalisableRange<float> (0.f, 100.f),
                                       0.f);

we expect the host to show the values between 0% and 100%, not between 0% and 1%…
can’t we have that as the default with a simple String (range.convertFrom0to1 (v), 2) ? I can’t see why anyone would want a different behaviour…

then why not renaming the parameter “value” to “normalisedValue” and add a jassert (normalisedValue >= 0.f && normalisedValue <= 1.f) in it?
Those normalised/user values parameters are confusing, better naming would help.

3 Likes