Why are all audio parameters *float?

#1

I followed the tutorial for connecting controls to you AudioProcesssValueTreeState, but they always end up being a pointer to float?

Let’s say I wanna read a combobox and made the parameter an int:

std::make_unique<AudioParameterInt>

then

AudioProcessorValueTreeState::getRawParameterValue()

gives me the float pointer. Is this the intended way? I don’t feel well comparing float values, why I chose int in the first place (although they seem to turn out “exact” after all)

0 Likes

#2

Yeah as far as i know that’s just a quirk. I feel like they should have made some more functions to get as different types but you can just cast from float to whatever type you want. It’s a bit silly because eg. It starts as a int, you get as a float, then you cast back to int. But it works. As far as I know there’s no other way currently.

1 Like

#3

Ok cool thanks! Just wanted to know if I’m far off the beaten path :slight_smile:

0 Likes

#4

Most hosts will store internally a normalised float, that’s why this is exposed here.
But with the latest additions, you can use the RangedAudioParameter classes directly:

auto* selection = dynamic_cast<AudioParameterInt*> (apvts.getParameter ("foo"));
auto intValue = selection.get();

btw. best practice is to have the pointer looked up only once in the constructor and keep it as a member variable. That saves iterating through the parameters, and JUCE doesn’t allow adding and removing parameters after the constructor anyway. I am not sure, how slow the lookup is in practice, I seem to remember, that there is a map in place for fast lookup…

1 Like

#5

Following up on @daniel’s comment, but don’t quote me on this, using a float for all parameters means the API only has to deal with one data type, instead of having a more complex API that has different functions for each of the data types. And the beauty of using a value of 0.0-1.0 is that it’s super easy to convert to and from… myValue = (floatValue * myValueRange) + myValueBase and floatValue = (myValue - myValueBase) / myValueRange. I think I wrote those correctly… lol…

0 Likes

#6

you did, but here’s the commercial block: jmap for the lazy:

myValue = jmap (value, minValue, maxValue);
// or
myValue = jmap (value, sourceMinValue, sourceMaxValue, targetMinValue, targetMaxValue);

:slight_smile:

0 Likes

#7

@daniel… doh! how do I keep forgetting that… …heads off to edit a bunch of code…

0 Likes