What's the right way to remove an AudioProcessorParameter from an AudioProcessor?
I have a plug-in that should have either 2 parameters if loaded in mono, or 4 if loaded in stereo. I call getNumInputChannels() to check if I am in mono or stereo. However, the getNumInputChannels() call is valid only during prepareToPlay(). This means, I have 2 choices seemingly: 1) add all 4 parameters in my AudioProcessor constructor, and then "remove" the unnecessary ones in the prepareToPlay call, or 2) add all required parameters in prepareToPlay() itself.
I don't feel too good about adding my parameters in prepareToPlay() just because it surely doesn't seem the right place to do that, so how can I remove parameters if needed then?
No its not designed that way. Add the parameters in the constructor, and NEVER remove them, because the host depends that the number of parameters is fixed.
Instead, if you need different parameters for channels, use this kind layout
#1 Para1 Channel1
#2 Para2 Channel1
#3 Para1 Channel2
#4 Para2 Channel2
and then only use the parameters you need.
(But the other parameters should be also stored and processed, even if the don't used)
I see. The problem in that case though is that, in Logic, there is a view which shows all parameters to the user and allows them to modify them. So in the mono case, it displays even those parameters that I don't want the user to have access to (Knob 2 & Slider 2 below). How do I work around this?
Don’t do it, some hosts might be fine others won’t! Either have all the parameters available all the time and only expose the relevant ones on the GUI based on the channel configuration - or the best option IMO is to actually build two plugins one for mono support the other stereo, this also prevents the rather odd and unexpected case of a plugin changing it’s appearance at runtime (channel configurations can change at runtime).
Imagine a scenario where someone inserts the stereo instance, automates all the parameters, then changes the track from stereo to mono - what happens to all the automation they recorded? we could dream up ways in which this might be handled but ultimately it’s undefined behaviour of a plugin to be changing the number of parameters or the ranges and details of parameters - the only exception I can think of for this off the top of my head is varients - but seriously you might as well just build two plugins that’s essentially what a varient is anyway!
I actually don’t see insurmountable issues with removing parameters as long as each parameter can be uniquely identified by the host. Why would the host have to have problems with automation for parameters that might currently not be there?
But there is more to it than only a few channel dependent parameters. Whats with a plugin with a completely unknown amount of parameters that will vary throughout the lifetime? I.e. a modular synth, for which modules can be added, or its complete processing structure is on disposition?
Can’t believe I’m only noticing this issue now.
It’s a major problem for any JUCE plugin wanting to define parameters per-channel.
I can easily do this in a pure AAX plugin, where the channel config is known when creating and setting up the plugin.
I have a plugin which supports mono thru 9.1.6… so if the above is really true, our mono plugin will have to expose all parameters for all 16 (or more) possible channels. These will all be visible as automation lanes, despite being completely useless.
Is there really no callback where we can register parameters while requested channel counts are already known?
And do some DAWs really change channel config dynamically? My understanding was that the plugin was torn down and a new one created in the new format.
I think the point is, its outside the scope of JUCE and its unknown behavior.
There isn’t an industry-wide standard for DAWs like there is for, say, BlueTooth. This is apparent from numerous threads that mention niggling differences in how different DAWs handle many things e.g. beginChangeGesture is a big one.
Here are two threads to help verify compatibility with different DAWs:
At the end of the day, until there’s an industry standard, it’s a DAW problem not a JUCE problem and your best bet is “better safe than sorry”.
Sure, but it’s a shame we lose functionality by using JUCE instead of the plugin SDKs natively. I think I can hack the juce AAX wrapper to get around this issue, but for VST/AU it might be more complex, as your links point out.
I think this is just built into the concept of JUCE. You are using JUCE to create an audio plugin, not an audio unit, a VST plugin or an AAX plugin – and leave the thinking to JUCE.
That being said, I feel like the biggy here is, that using the native API (for example Apples frameworks for AUs) is a hole lot of poorly documented pou… So JUCE becomes a very appealing option even when you are actually building a AU unit or an AAX plugin. But I rather like to look at it as a major advantage of JUCE, rather than a disadvantage.
Yeah, except that JUCE breaks a thing that is already achievable in AAX. We have a specific wrapper for each format, in which these things ought to be handled. But as I say I think it can be achieved with some hackery.
One way of achieving this is to allocate a fixed number of parameters, say 256 of them or something. Treat them as empty slots.
In JUCE you can set the name of parameters and also the ranges etc dynamically. With a bit of footwork you can set up listeners etc to treat these slots as proxies to internal parameters.
The downside is that youll see empty slots in the automatable list but that doesn’t really matter. For general UI youll also need the ability to assign UI control parameters to be automatable, perhaps with a right-click popup menu. Youll also need code that saves/restores the state of the slots on plugin store/load.
In your case you’ll be able to assign slots programmatically.
For examples of this in the wild see PhasePlant and Omnisphere.
Thanks Justin.
It’s the long list of automation lanes I’m trying to avoid. Users definitely dig into the lanes, so it’s a little embarrassing to have tons of unused stuff mixed in with the used stuff.
It’s a known paradigm. At least the unused slots will be blank rather than seeing a bunch of named parameters that are unused and/or don’t do anything.
Pick your battles though I say. You may be able to hack AAX and get Protools to behave but for VST3 and AU across other DAWs it’ll be a PITA issue.
