Could AudioProcessor::addParameter be optimized


#1

I have a plugin with several thousand parameters, in a debug build it takes 1 minute to start up. In a release build it’s under 1 second.

Every time a parameter is added it does a linear search to see if the ID is already in use. It’s crazy slow. Could this be done once all the parameters are added or use some sort of hash?

for (auto q : managedParameters)
{
    jassert (q == nullptr || q == p || paramId != getParameterID (q->parameterIndex));
}

#2

Yep, I’ll optimise that


#3

Beware of that route, it proved to be problematic in several DAWs. The undesirable effects I could remember just now are:

  • ProTools took minutes to load the plug-in, even in Release build
  • Mainstage hung and then crashed when attempting to display the list of automated parameters
  • Cakewalk SONAR (ceased development now) presented the automated parameters in a single-column popup menu, in which it is very inconvenient to find the parameter that you are looking for among several thousands.

#4

Yeah, I am rethinking it. Now I’m thinking that only the parameters from the first 32 sounds layers will be automatable, and parameters from additional sound layers (if used), will only be available in the plugin. Is that weird? Do any other plugins do something similar?

Dynamically changing the number of parameters isn’t supported, is it?


#5

changing the number of parameters may be supported by some DAWs, but I believe not all of the major ones (or plug-in formats) support it.

As for your proposed solution, that sounds reasonable. In our case (different kind of plug-in though), we exposed a fixed set of automation “slots”, each of which could be connected to one of the “internal” parameters at the user discretion.

That ensured max flexibility but the additional level of indirection certainly adds complexity for the user.

If you think some flexibility may be useful in your case, you may follow a similar route but improve its user-friendliness.
For example, the user may choose an automation “colour” for each of the layers, and those colours will be also mentioned in the automated parameters.
So, for example,“Red Volume” will act on the Volume parameter of the layer (if any) marked with the “Red” colour

EDIT: or do a mix of the two: the first 32 (or whatever) layers always have automation parameters, and then 4 or so more sets can be assigned to the layers exceeding 32 via these “colour” markers