Could someone please add this to AudioProcessorValueTreeState? I’ve been using this to allow the user to change the resolution of a slider from 9 steps to 17 steps to continuous. I’ve used this for the past year and it’s worked fine. It also seemed odd that there was already a getRange() but no setRange().
void AudioProcessorValueTreeState::setParameterRange(juce::StringRef paramID, NormalisableRange<float>newRange)
if (Parameter* p = Parameter::getParameterForID (processor, paramID))
p->range = newRange;
Is there any way to upvote this? It would be great to have more control over the resolution of AudioProcessorValueTreeState slider attachments.
Since the Range is used to normalise the value, changing it would invalidate all automation data in the host. So it would be a bad idea to change that at anytime (even on an update of your plugin, you would invalidate saved sessions)
I can see the use of changing the interval, although you can keep the interval at maximum granularity and restrict it in the slider directly after you attached the SliderAttachment.
After adding my comment here, I worked out that you can get default range and interval behaviour by using a NormalisableRange constructor, with a skew factor of 1.0.
I fully see the value of keeping a set range too, however granularity was an issue for me as my values are really small - this is where the NormalisableRange helped me.
See AudioProcessorValueTreeState range values
I’ve tried to add your code to my APVTS class but get a compile error - no member named getParameterForID in JUCE::AudioProcessorValueTreeState::Parameter
The code in the OP is not supposed to work anyway for the reasons I wrote in my answer on May 28.
Ok, I understand. I did read your comments. Just wanted to see what happens if I implement it.
Does this mean that there is absolutely no way you can change the range of a parameter ones you have initialized it in AudioProcessorValueTreeState?
Yes, the parameter is not intended to be changed after creation, because that F**s up all stored projects (the automation is a normalised value from 0…1, how would your plugin later know, using which range the number was recorded?)
But the Slider granularity you can change afterwards, since that is simply affecting the representation of your parameter. Obviously it might be weird, if the automation sets a value and the slider doesn’t accept it and snaps to a different value…
I have a solution where I keep the parameter range and then simply switch between different sliders range (mySlider.setRange() ) in My GUI editor. I also display a text, showing the type of value (ex. ms, %, 1/4 notes… ) appended after the value, reflecting users settings. That works, by not very good…a thing is that in Ableton live’s own listed parameter view(small sliders you can automate), the range is not updated. It seems it only reads directly from the parameter in APVTS. I’ve seen it work in plugins like Native Instruments Replika XT. The range and text, displaying the type of value (ex. ms, %, 1/4 notes… ), is updated, reflecting users settings.
Do you have an idea about how I do this - updating the parameter view in Ableton.