AudioProcessor with multple AudioProcessorEditors or multiple processBlock

Audio Plugins
1

Hi,

I’m trying to create a plugin with multiple reorderable DSPs.

For that projucer created the classes inheriting from AudioProcessorEditor and AudioProcessor.

My AudioProcessorEditor has a list of different DSPPanels
juce::OwnedArray mDSPList;

Each DSPPanel will have it’s own Component(s) and AudioProcessorParameter(s)

These DSPanels can be reorder so I can have a view with:

DSP1 DSP3

DSP2 or DSP1

DSP3 DSP2

So the order will affect to how processBlock is done.

Each DSPPanel knows it’s own parameters and how to do processBlock

In AudioProcessorEditor there is a reference to the AudioProcessor but not the other way round.
So when I’m in AudioProcessor ::processBlock I don’t know how to access the AudioProcessorEditor to get the list of DSPs (juce::OwnedArray mDSPList;)

Any ideas of how to achieve this? Each path I take I get stuck.

Thanks!

2

General rule of thumb is the processor shouldn’t know about the editor. For example, the editor might not exist if the GUI is closed.

The data needs to exist within the processor, and the editor only needs to read/write to that data via the processor reference.

3

Thanks Fandusss, That makes sense.

So I could make my Editor register the parameters of each DSP with the Processor. I just need to find a way of telling the processor how to process the data depending the order of the DSPs.

Maybe if the processor has a list of functions and when the editor gets reordered I also reorder this list in the processor? I’ll have a think…

4

If you’re reordering GUI modules around, you’ll definitely want to store the GUI state in memory so you won’t have to reorder each time you open or maximize the plugin. So create a public AudioProcessorValueTreeState (or APVTS in short) object in your processor if you havn’t already. Look it up in the tutorials page if needed.

Once you have that APVTS, you can pass it as a reference to the editor, and also in the editor make a custom function to serialize mDSPList order to a string. So whenever you change the order from the GUI, the editor will pass this data as text to APVTS and the processor will have a way of knowing what to do.

This way you achieve what you want, and in addition you have the ability to change your DSP order without a visible GUI. So when a GUI opens up you get the opposite effect: the editor will reflect the correct internal DSP order by moving the pieces to the needed location. (thanks to the ability to store and load APVTS data. see getStateInformation and setStateInformation).

I didn’t explain how to fully setup APVTS. There are extra steps involving listeners and callbacks. You’ll have to get it from the docs yourself or else it won’t sink in, and you will have a hard time maintaining the code later on.

Search the forum for posts on how to save text data in APVTS properties.