AudioProcessor "removeParameter"?


#1

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?


FR: access to AudioProcessor managedParameters
#2

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)

 

 


#3

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?

 


#4

There are practical use cases for being able to remove parameters. Is it possible at all and if so are they any plans to support this in JUCE?


#5

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!


#6

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?