FR: AudioParameterBool/Choice/Int/Float -> public getText/getValueForText

Audio Plugins
1

Can you move:

String getText (float, int) const override;
float getValueForText (const String&) const override;

from private to public?

1 Like
2

it would be very nice if that happened.

3

I can see the motivation for overriding those functions in AudioParameterBool/Float. What do you envision for choice and int?

4

Well yes, just for flexibility. For example getValueForText() could be used to evaluate the right value from a text, even when its uses a different unit

“2k” -> 2000 -> 0…1
"2ms" -> 0.002 -> 0…1
"violet" -> purple -> 3 -> 0…1

getText()
0…1 -> 1000 (kg) -> tonne
0…1 -> 60 (s) -> 1 minute

(i’m aware that getText/getValueForText() expect the normalised value as parameter/return value, may be this should be added to the documentation)

5

I’m hesitating over making this change.

The whole point of these classes is that you never need to worry about normalised values. If you have an integer parameter then you simply supply integers to the constructor, there’s very little that can go wrong.

As soon as you introduce a float [0.0f, 1.0f] range into the mix mistakes are suddenly pretty easy, and will mean that your parameter will behave in unexpected ways during things like automation. For a very simple example consider the following override of AudioParameterBool:

String getText (float value, int) const override
{
    return v > 0.5f ? "YourOnValue" : "YourOffValue";
}

For a value of 0.5f you would accidentally display “YourOffValue” when the parameter is “On”. It’s even easier to make mistakes with AudioParameterChoice - there are multiple ways to chop up [0, 1] into subregions and you need match what’s going on in the rest of the implementation exactly.

I think a better approach would be to add lambda functions for non-normalised conversions to the constructor, that way you can remain completely in the bool/int domain.

6

okay!

7
8

Thank you so much, I appreciate it.