Number of parameters varies with number of input channels

My plug-in accepts an arbitrary number of input channels. Each channel is supposed to have its own set of parameters, e.g. a gain coefficient.

From what I’ve been reading on the forum, changing the number of parameters on the fly is a no-go; parameters pretty much need to be added in the constructor of the processor. However, at that point I don’t know the number of input channels yet since the host doesn’t set them until after the creation of my plug-in (and theoretically the number of channels can change at any time).

So does that mean what I’m trying to do is impossible with Juce? Seems to be a pretty common use case and I know of quite a few plug-ins that manage to do this.

I think that those plugins you’re referencing that are able to adjust the number of parameters per channel on the fly in actuality have a hard limit of parameters that you haven’t managed to reach, and just enable / disable them as the channel count changes. Might be wrong though…

As @momentumm says I think you’ll find most plugins that have a variable number of parameters actually do have a fixed number of parameters behind the scenes they just only show them available in the UI. This unfortunately can make for a messy experience for a user in some DAWs, especially if you record automation.

You could probably manage to add / remove parameters on the fly however you’ll run into all sorts of issues on different DAWs / platforms for specific edge cases. This has very little to do with JUCE.

For example imagine a user recorded automation on your parameters and then the number of input channels changed - what would/should happen to the automation data?

1 Like

Not that messy, imo. If you record automation on two channels, then change to only one channel, your code needs to simply ignore the second channel values. Allow them to change as you normally would, but let the actual processing ignore their values.

I was suggesting that having a lot of parameters (especially poorly named ones) is messy for the end user in some DAWs. For example I’m not keen on EQ’s that allow unlimited nodes as it’s not always easy to tell which node relates to which parameter as it depends when you added the node in the graph. I much prefer having an explicit limited list of named EQ nodes. Obviously everyone is different and TBH it normally depends on the workflows and how the DAW helps or hinders the process for the end user.

Ah, gotcha. I was thinking just about having stereo parameters defined but then being switched to mono (without launching a different instance for that).

I agree, for general parameters having a hard-coded limit and showing/hiding them as needed through the GUI seems to be standard (fabfilter’s Pro-Q comes to mind), although it’s not very elegant. But conceptually, there’s a difference between showing parameters that are currently unused but might be used later (I might want to use all 16 EQ bands for automation) and showing parameters that don’t make any sense for the current configuration (e.g. Left Surround Gain for a plug-in on a mono track).

I do know of a few AAX panning plug-ins whose numbers of parameters vary with number of input/output channels. I wonder if this is particular to AAX since users in PT have to pick what channel configuration they want for a plug-in from the get-go and hence the number of inputs would presumably already be known during instantiation. The channel configuration of a plug-in in PT also seems to be fixed during its lifetime.

Sadly, I can’t check since I don’t know have the AAX SDK (yet – hopefully).

1 Like