while working on a new plugin, I noticed that the list of parameters is getting quite big and the PluginProcessor/Editor are quite long. I want to “modularize” the code and I read the chaining effects tutorial. The AudioProcessorGraph technique looks interesting but I have some doubts.
Let’s say we have PluginProcessor that will load the various effects, named Effect1, Effect2 and so on. Each Effect class derives from ProcessorBase.
Can I declare the parameters in each Effect class?
Can I link a different Editor for each Effect class?
If both answers are yes, then I have to figure out how to expose each Effect Processor/Editor in the main PluginProcessor/Editor classes.
If you want to use the audio processor graph in a plugin / audio processor, you need to manage the parameters in the top layer (actual audio processor) and then pass pointers of the parameters down into the nodes for them to have access.
I don’t believe currently that you can add the parameters internal to each no in the graph and have them display in the parent processor.
You can add to each of your processor classes a static function, that will create the Parameters suitable to be put into a ParameterGroup. In your main AudioProcessor you will then just add all parameters together (and possibly put each sub block into a ParameterGroup)
Note 1) The parameter creation cannot be dynamically, so you cannot add parameters later.
It will happen during the creation of the main AudioProcessor (injected from a static createParameterLayout() method that you define)
Note 2) AudioProcessorGraph is best for dynamic setups, vs. dsp::ProcessorChain is best for static setups, because the compiler can optimise the code
The reason is, that if you change your modular setup, how would a recorded automation continue to work?
There is a workaround, most hosts will hide parameters with an empty name.
You can define the maximum number of parameters you will need and rewire them internally in your code to the aspect they shall control.
I agree, it is not ideal, but there is no solution with recorded automation, afaik. Especially one that would work across most if not all hosts.