Normalizable Range


#1

Can anyone give me an overview of what NormalizableRange is all about? I am trying to set up an AudioParameterFloat parameter for my plugin so that I can at least display a value outside the range [0,1]. For example, a percent reverb parameter in the range [0,100] or a room area parameter in the range [1000,10000] (sq. ft.). I have constructed my plugin by starting with the NoiseGate example, which has two parameters in the range [0,1] and uses the GenericEditor, and modifying it to support my five parameters and use my own brand of signal processing. Works fine if all parameters range from 0 to 1. I only modified the processor code, using the editor code as is. But when I tried to change my percent reverb parameter from [0,1] with initial value 0.5 to [0,100] with initial value 50, it behaved in a way I could not understand. Here is a sample of my code:

NormalisableRange pctRevRange(0.0, 100.0);
addParameter(percentReverb = new AudioParameterFloat(“percentReverb”, “Percent Reverb”, pctRevRange, 50.0));


#2

OK. I think I understand the NormalisableRange class now and can use it to go back and forth between a [0,1] range and an [A,B] range. My remaining problem is that I cannot see what is happening between my slider values and the corresponding parameter values. I assume that the slider value is unnormalised and needs to be normalized in the editor, but I am not sure how or where to do this.


#3

Unfortunately dealing with the parameter ranges (and skews) and sliders tends to be a bit tricky, but I am sure you will eventually find out some solution that works for you.


#4

I now have further insight into what is going on. The (AudioParameterFloat) parameter methods getValue and setValue (and one or two other methods) apply conversions to and from the [0,1] domain. This is only apparent if you look at the code for these methods. I tried, without success, to undo the conversions in my code so that “percent reverb” came back to my processor in the range [0,100]. What finally worked was to change the JUCE code for getValue and setValue to eliminate the conversions. I guess the idea behind the audio parameters and normalization is to make sure that sliders are always in the range [0,1] even if the parameters they control are not. This is more or less the opposite of what I want to do.


#5

Aha!! I tried an approach based on the AudioProcessorValueTreeState tutorial and it works just fine without the need to hack any JUCE code. My five sliders all display the ranges I like and the parameters appear to arrive in the processor intact. No need for slider listeners or worrying about what to do when the slider value changes (or is in the process of changing). I’ve learned a lot from this exercise. Next project: make the GUI look sexier!