Example: Pro Tools with Control Surfaces that have rotary encoders, but my bad for other host examples.
Doesn’t mean it has no sense. Otherwise forbidding the num steps + continuous would prevent ramping between the discrete values, or would force using “continuous” with no meaning to the C++ parameter config side, and prevent adequate handling on the control surfaces.
Yes! My bad, should be +1. I’ll update my post.
Very much this:
As one of the original implementors of the automation and control surface support in Pro Tools 20+ years ago (and author of 40+ plugins since) , I can tell you there are numerous very valid reasons that discrete/continuous is decoupled from the number of steps in the Avid SDK (and at least the VST3 SDK, I didn’t hunt it down in the others) – and should likewise be decoupled in JUCE. One specific example is to determine the “increment” size for, say, the up/down arrows during text entry, or if there is “nudge” functionality in the UI or a control surface.
Don’t discount it just because you can’t think of a reason for it, or because a limited survey of limited functions in limited hosts didn’t seem to make a difference for your limited test case.
ROLI, please stop trying to be “clever” with the plug-in wrappers. There have been many times a “clever” shortcut in the JUCE wrappers lead to headaches for developers, e.g.: using param index instead of IDs, tying chunk version to plug-in version, using num steps to determine discrete/continuous. The AAX, AU, and VST3 plug-in SDKs are the product of decades of (often painful) experience. Don’t assume that just because you don’t see why something is done a certain way that there isn’t a good reason.
I wasn’t discounting it, I was simply asking where I could see the effect.
Where is it decoupled in the VST3 SDK?
I called out the wrong SDK. I was incorrectly thinking of Vst::ParameterInfo::kIsList, which differentiates between parameters with string lists or dynamically generated strings. Similar to kAudioUnitParameterFlag_ValuesHaveStrings on the AU side.
The one it does matter for is AU, where there’s kParameterUnit_Indexed which discriminates between parameters that need to be passed normalized or non-normalized in order to appear correctly in the AU “Generic” UIs.
And - shoot me now - in AU there’s kParameterFlag_CanRamp which doesn’t appear to be documented anywhere.
I can’t speak to what aspects the JUCE parameter classes do or don’t support, but in the parameter classes I rolled before they existed there is quite a bit of differentiated behavior necessary for correct operation across GUI, Generic UI, automation, and control surfaces based on whether a parameter is discrete or not.
It’s hard to understand the pushback on this. The use of number of steps to set continuous/discrete in the AAX wrapper is an unquestionably wrong hack. It is a useful thing to keep the number of steps and discrete/continuous separated, because at least Pro Tools uses the number of steps distinctly from whether the control is continuous or discrete when it comes to control surfaces and automation. Once you make that distinction you can also use the number of steps to drive useful UI behaviors on all hosts and formats, even for continuous controls. The downside is…?
At the end of the day, I already have my own solution that works. It’s just frustrating that there is such resistance to fixing it once, in the main repo, leaving it instead for every developer to reinvent the wheel. Issues like this are why I and others continue to write and maintain our own custom wrappers and parameter classes.
Again, I’m not discounting those points I’m simply asking questions to ensure I haven’t missed anything, like what would have been a relevant part of the VST3 SDK.
We’ve added a new method: AudioProcessorParameter::isDiscrete.
Backwards compatibility can be maintained with the macro JUCE_FORCE_LEGACY_PARAMETER_AUTOMATION_TYPE.
