Some DAWs ignoring isAutomatableParameter


#1

Hey folks,
if I understand this correctly, Parameters with isAutomatableParameter set to false should not be controllable by the DAW, they should be invisible. This appears to work with some DAWs (e.g. Cubase), with others it doesn’t (e.g. Bitwig 1.3.15, Akai MPC). Is this a known issue, or do I misunderstand the concept?
Thanks!
Jan


#2

Also with Ableton Live last time I checked that was the case.
You can’t do much. you can contact those hosts and request them to respect that but there are many API calls for every plug-in format that are being handled differently between each host (or not being handled at all).


#3

Ok, good to know that others ran into this. I thought so, it’s something the DAW vendors have to respect. Iirc there are no problems with AAX and AU. I do have my own data model classes for attaching ui elements to value trees etc, but esp. for “small” plugins it would have been nice to skip this effort (and some replicated code). My plugins are created in a way that nothing breaks if DAWs control parameters they shouldn’t, it’s just not pretty if you want to store some UI state or lookahead settings and the like.


#4

Maybe a hint in the JUCE docs that this feature is “unrealiable” would be nice.


#5

I don’t think you should be handling and storing things like that as plugin parameters to begin with.


#6

Technically they are part of the plugins state, so why not. If DAWs would realiably hide those params from their interfaces, all would be good. I’m not “abusing” the parameter interface to store stuff that doesn’t belong there conceptually, as I wrote I have other means to do that.


#7

I have to add quite some code and data handling now just for a stupid “enable/disable MS decoding” checkbox. Meh :wink:


#8

Would you store things like file names of sampler samples or convolution reverb impulse responses by using the parameters…?


#9

The AudioProcessorParameter classes serve the sole purpose to make the host aware of the parameter and to allow the user to create an automation.

You have full control over what is stored in your AudioProcessor::getStateInformation() / AudioProcessor::setStateInformation(). And by adding your variable to the public ValueTree AudioProcessorValueTreeState.state it is very easy to save that together with the other parameters.

There are methods to attach buttons etc. to ValueTree properties using Value::referTo()


#10

@Xenakios: Of course not. I’d also not store custom binary data for spline curve definitions etc. I’m not “abusing” parameters, I just want to hide some which due to principle would cause clicks or extensive recalculations, or some which don’t matter for signal processing.

@daniel: Yes, and I got a whole suite of classes for my more custom stuff, which also provide thread safe UI attachments etc.

Again, it would just have been convenient for really small projects which have such a simple data model that I would have liked to skip some work.


#11

The AudioProcessorParameter classes serve the sole purpose to make the host aware of the parameter and to allow the user to create an automation.

Then why have a flag for isAutomatableParameter at all?


#12

If DAWs provide undo/redo for plugin state changes, maybe that’s a reason to have a DAW aware of a parameter while not having it available for automation.


#13

To allow parameters that really belong to the audio processing, like FFT size, but are difficult to implement so that they can be automated from the host.


#14

True, and those are the ones I’d like to hide. Good crossover filters are another example that comes to mind, needing extensive calculations if you want to properly smooth out changes. Well, since it apparently doesn’t work reliably due to DAW vendors, my question is answered, thanks guys!


#15

If I would have been at that meeting when the SDKs like VST and AU defined that, I would have asked that question…

That is covered by using getStateInformation() / setStateInformation().

Another perspective, it is even more confusing, if you take into account, that the value of the parameters changes depending on the playhead’s position in the project (thanks to automation). So actually the information about the parameters value in setStateInformation() is redundant, and can in some cases even lead to problems. But for hosts, that don’t implement automation at all (like the JUCE Plugin Host), it makes sense to store them regardless…

Glad that you found a solution.


#16

Maybe a clue in the Reaper DAW changelog :

  • VST: skip non-automatable and plugin-internal VST3 parameters in the FX envelope dialog and FX parameter dropdown

#17

Found another somewhat annoying case where you need some data to be represented by Parameters even though it should not be automatable (in a “curve in DAW” sense): Certain hardware vendors offer certain control surfaces which are able to show some parameters on their displays, and you have to make some modifications to your plugin for this to work. The interface this requires is “plugin parameters” though. sigh


#18

if you mean Pro Tools (as we encountered the Gain Reduction showing up in Ableton Live for example) then you know you can declare the parameters just for that format right?

JUCE currently offers gain reduction and eq curve only on AAX.
Our branch also supports Gain Reduction on VST3 using PreSonus extensions.
so technically you can just ignore them on formats not using them.


#19

Nope, but nice to know about that ProTools specific feature.