Changing parameter range (REVISITED)

I resolved a problem I was having that I thought was caused by the inability to change parameter ranges on the fly. However, there is still a problem I am having with that.

I have some ComboBoxes that are filled with a different number of items, depending upon another parameter. That is working fine, except when loading saved session data. In that case, when I load the value for those ComboBox parameters, and try to set the parameter value for which item was selected when the session was saved, the code behind the scenes scales the parameter based on its originally defined range. But I need to scale it based on the number of items that I just added to its associated ComboBox, not the static range initially defined for the parameter.

For example, if the session data causes there to be 5 items in the ComboBox, then a value of 0.5 in the session data should be the index 2 (out of 0,1,2,3,4), but if there are only 3 items in the ComboBox now, then a value of 0.5 should result in selecting item 1 (out of 0,1,2). But I don’t see how I can do that.

If I could somehow re-define the parameter range on the fly, then I could easily set the parameter value. But with it set (to [0.0,1.0]), I can’t see how to set the parameter value such that the ComboBox selects the correct item.

Any ideas?

Oh, wait… I can use lambdas, can’t I? Using [this], so I can call a member function of my Processor class to do the conversions and snapping? That would allow me to use the current number of items that the ComboBoxes should have, regardless of whether the Editor is showing or not. Ooh, I think I like lambdas! :slight_smile:

@HowardAntares

can you show an example of how you solved this?

If you go changing a parameter range, isn’t this going to play havoc with any automation the user may have written into the host at assumed ranges? Seems like a risky thing to do to me. Am I missing something?

Sure. I defined a NormalisableRange like this:

	NormalisableRange<float> myParamRange = NormalisableRange<float>
(
	0.0, 1.0, // ignored in functions below
	[this]( float start, float end, float value0To1 ) // convertFrom0To1Func
	{
	 return this->convertMyParamFrom0To1( value0To1 );
	},
	[this]( float start, float end, float worldValue ) // convertTo0To1Func
	{
	 return this->convertMyParamTo0To1( worldValue );
	},
	[this]( float start, float end, float valueToSnap ) // snapToLegalValueFunc
	{
	 return this->snapMyParamToLegalValue( valueToSnap );
	}
);
// Need these to be 0, so that the attachment causes the control to use this NormalisableRange.
myParamRange = 0.0;
myParamRange = 0.0;
//
pMyParam = parameters.createAndAddParameter( myParaMID,
	"My parameter",
	{},
	myParamRange,
	0.0f,   // default
	nullptr,
	nullptr,
	false,  // not meta
	false,    // automatable
	true, // discrete
	AudioProcessorParameter::genericParameter,
	false ); // boolean
parameters.addParameterListener( myParamID, this );

And in those functions, I simply convert the values by multiplying or dividing by the number of items currently in the associated drop-down (minus 1).

1 Like

thanks I will have a look!

1 Like

It would, indeed, cause problems with automation. However, in my case, neither the parameters whose ranges change nor the parameter that leads to that range change (by causing their associated ComboBoxes to be repopulated) are themselves automatable, so it’s not a problem.