Trying to understand this proposal, but I’m not sure I follow what each of these flags would mean. DontInterpolate == discrete?
Can you give an example of a host that does this? My experience has been that most hosts do not attempt to interpolate to a new automation point from a midi control but instead jump to the exact value.
Yes, I tried to mimic the existing names (e.g. DontSendNotification) and having the current behaviour as flag unset, so it wouldn’t break existing code.
john_henry provided very good images in this post above. I see the last image for ProTools AAX, if I have less than 1000 steps as well (which is why I need this patch to go through).
That is exaclty my point, if the settings were always “Interpolate” (or CanRamp, I don’t care too much about the name), the visual representation of the automation lane would not reflect the MIDI controller data.
VS. drawing automation data using a pen tool you will probably want the ramps.
AFAIK you will always get exactly one value for the parameters for each process block. Even though some plugin APIs allow parameter changes inside a processBlock, there seems to be no cross plattform solution (at least not straight forward), hence JUCE doesn’t provide that granular data.
EDIT: @fabian / @jules: please correct me here, as I cannot speak for the juce team…
Thanks for the clarification. That looks a bit more sensible than the flood of time stamped parameter changed messages that I was expecting.
Any response from JUCE folks? Even after adding as many workarounds as we can for VST3 and AAX, we’re still getting complaints from beta testers who are accustomed to our continuous/discrete params working correctly in AU hosts.
I’m investigating this now, but I can’t find the original patch. @fbecker, @hguthertz could you please share your changes/workarounds again?
As previously noted, please use “discrete/continuous” as the terminology, not “canRamp/cantRamp” or “jump/interpolate”. The former succinctly and exactly captures the characteristic being described, and matches existing terminology in the RTAS and AAX SDKs. The latter options imply other characteristics or ambiguities (What is the rate of the ramp? Is the interpolation linear? cubic?..)
A flag or boolean “isDiscrete” would be the preferred implementation.
Also, this:
We would also vote for the “discrete/continuous” terminology. It’s what we already use internally in our code.
Regarding testing and backwards compatibility: afaik, it will be impossible for any JUCE Audio Unit plugin that is updated to use discrete parameters to be backwards compatible. Any session saved with the original plugin would no longer map parameter values correctly. This is because discrete parameter support in AU will require changing maxValue to be the true maximum value (or the number of steps) instead of just hardcoded 1.0f as it was previously. Perhaps it would be cleaner to use the true parameter values instead of zero-to-one values everywhere in AU (and other wrappers that support it?) since there may be other AU features that require non-zero-to-one values, and it would be difficult to make this transition twice.
Well, I’m so sorry we have to come back to this terminology issue. “discrete/continuous”. The issue with this is that it is confusing people about the fact that a limited number of possible parameter values is NOT tied with the fact that the parameters are ramped by the DAW and that a continuously variable parameter value is NOT tied with the values being ramped in the DAW. Which confusion was initially implemented in the JUCE wrappers (e.g. RTAS…). This terminology in DAW SDKs is confusing and we are not tied to use it. But whatever.
About the backward compatibility: my patch implements it by providing a legacy parameter configuration.
Cool. That’s oldRampCompatibility in your patch?
yep it’s oldRampCompatibility
Is there a situation where you would want to have getNumSteps() return something other than the default (i.e. you are indicating that your parameter is stepped) but still retain continuous/ramped behaviour?
I’ve been testing in a range of hosts and they all seem to ignore the result of getNumSteps() unless you also flag the parameter as discrete… If possible it would be nice to have the discrete flag set automatically if getNumSteps() is changed from the default.
FWIW, all of our parameters return a non-default number of steps because we use it to indicate a reasonable granularity for the control.
Here’s an example:
Please please do not tie the continuous/discrete flag to the number of steps. In my opinion, it is the most problematic assumption that the AAX wrapper makes at the moment. I understand that most hosts may not use getNumSteps until a parameter is marked as discrete, but that doesn’t mean that none do or that none will in the future.
But where is the granularity indicated?
Logic, Reaper, Ableton, Bitwig, FL Studio and Pro Tools (on all supported platform and plug-in types) all appear to ignore the number of steps completely. I’m only omitting other hosts as I’ve not yet tested in them.
(Isn’t it (12 / 96) / 0.01 + 1 = 10801 in you case?)
Pro Tools does not ignore the number of steps, plus it uses it on control surfaces. I can’t test it again but I’ve found multiple hosts that support it anyway. IMHO it’s not because few hosts support it that plug-ins should not provide the info.
I’ve created an AAX parameter with 4 steps and marked it as continuous. Pro Tools then lets me set arbitrary values in the automation lane, and these arbitrary values get transmitted to the plug-in. Where does the number of steps come into play?
I don’t have a control surface to hand at the moment.
Could you please provide an example?
IIRC there is a VENUE emulator… You can run a software surface…
See http://www.avid.com/products/venue-software/features → “work offline”
