I thought perhaps the interval parameter of setRange() might have some relation to the sensitivity parameter of setVelocityModeParameters(), but if it does, it is lost on me. What think ye?
The above code works, and each slider is velocity sensitive. However, as soon as I change the range to anything below 16.21 the velocity sensitivity no longer works. If this is expected behaviour can someone point out why?
The slider has a lower limit on when it decides to use velocity-sensitive mode - if the range is small enough that every possible value can be set by just straightforward absolute dragging, then it won't go into velocity mode.
I think someone else requested recently that this behviour should change.. Maybe that's a fair point.
Thanks Jule and sorry for pestering. Ok, this makes aboluste sense now. Maybe this could be added to the manual for future clowns who fails to see why velocity mode isn't kicking in!
This just tripped me up too, while switching a plug-in over to use AudioProcessorValueTreeState for parameter management.
The issue came up because the slider.setRange calls in the Editor constructor didn’t have an effect anymore of setting the slider interval, since APVTS uses SliderAttachments to link sliders to parameters.
I eventually figured out I had to go back to the Processor’s constructor initializer list, and modify how the AudioParameterFloats were being initialized, because I needed to give them a small enough interval. This also required changing from the 2nd (simpler) form of the AudioParameterFloat constructor to the 1st form.
For example, this: std::make_unique<AudioParameterFloat> ("mix", "Mix", 0, 1.0f, 0.5f)
Had to change to: std::make_unique<AudioParameterFloat> ("mix", "Mix", NormalisableRange<float> (0, 1.0f, 0), 0.5f)
So that the interval could be explicitly defined as 0.
After making this change, the modifier key to engage “velocity sensitive mode” worked again.