I have a plugin with a lot of parameters (72,000 approximately). This works fine in VST format but I’ve come up against some huge overheads when creating the plugin when hosting it as an AU.
I’ve been going through looking at ways to optimise the parameter systems both on our hosting side, the plugin side and (most importantly) the AU wrapper hosting side as this is by far the biggest bottleneck.
The main issue is that during load, setCurrentProgramStateInformation is called which results in a call to sendAllParametersChangedEvents (actually this is called several times during initialisation and also when we change presets from within the plugin).
What sendAllParametersChangedEvents does is:
• Create and dispatch 70,000 parameter change messages
• For each message the eventCallback is called which then
• Iterates all the parameters to find a paramID
• Calls sendParamChangeMessageToListeners
• Which then iterates all the listeners
This is taking several minutes for our plugin but I’ve seen similar problems with plugins with far fewer parameters.
So I have two main questions:
Is it really necessary to send a parameter change message like this during initialisation? From what I can tell, other formats don’t do this when the state is loaded?
If this is necessary, is dissipating events like this the way to go? Would it not be better to simply iterate all the parameters, get their current value and call sendParamChangeMessageToListeners synchronously?
That is fascinating, I have a plug-in with just above 10k automation entries (many of which are also declared not automatable, but lots of hosts simply ignore that), and that alone is enough to make it almost unusable in a variety of hosts.
Pro Tools is the most notable one, it takes almost a minute for each instance of the plug-in to be created and therefore the only way we found around this is to add a level of indirection:
the plug-in exposes only few hundreds of automated parameters (let’s say, 512), and then it allows to map each of these automation “slots” to one of the “internal” 10k parameters. And the association is stored together with the plug-in state
Yes, we’ve found the same problem with AAX. Their parameter handling is certainly not, shall we say, optimised…
We did think of a similar approach creating a parameter map but then that complicates things for the user as they have to manually choose a slot, choose the parameter to map it to and then actually perform your automation. We wanted the user to just be able to grab any know in the UI, turn it and record some automation.
You wouldn’t have thought that 70K is that many these days but it’s certainly exposed some room for improvements.
I don’t even think that the GUI of many DAWs out there is designed to handle that many parameters, meaning that the user may already find it difficult to assign the correct automation.
I’m thinking of those that present automation with single column popups: 70k params would make it for a very loooong list, which certainly exceeds the size of what can be vertically fit on the screen. Scrolling through a popup menu much higher than the screen should already be problematic (if you click somewhere else by mistake, and the menu is dismissed, good luck scrolling through it again for the parameter you’re searching)
Yes, that certainly is problematic and is actually how we currently do it in Waveform. Add to that the tiny character limit of VST parameter names (unless you use VSTXML) and the lack of grouping support it’s very hard to deal with a large number of parameters in a host.
However, most hosts should be able to simply start recording automation if a parameter is changed right? Then, you can view only ‘active’ automation.
I know we are an extreme case but the problems I mentioned with AU plugin hosting present themselves with as little as 1000 parameters.
