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.