Parallel processorChains

Hi Everyone

I’m trying to wrap my head around the new-ish DSP module. Is there a tidy way to combine processorChain objects into a parallel (audio) structure? I didn’t see any classes that look like they’re intended for this but this has to be common for anyone creating any kind of mixer-like structure with sends and returns or any more complex effect such as a reverb. What’s the JUCE-y solution? Any examples you can point me to?

Also, what about managing those chains? If want to create a mixer that has many aux channels, my first idea was to add a bunch of processor chains to a std::vector to make them easy to manage. But that doesn’t seem to work on account of the fancy templating stuff that’s being done. How would you manage a group of similar processing chains?

Actually, figured out adding chains to a vector and it seems to work. This just feels kind of … wrong? I don’t know. Maybe I’m just not used to working with templates and seeing all those angle brackets everywhere.

std::vector <std::unique_ptr <juce::dsp::ProcessorChain<juce::dsp::LadderFilter<float>, juce::dsp::Gain<float>>>> processorChains;

A ProcessorChain needs to be fully defined at compile time. So it is perfectly suitable for a specific DSP job of a few operations defined in dsp::Processors.
For your use case, to define the different plugins dynamically on each track, you will need a dynamic approach, which is wrapping the individual dsp::ProcessorChains into AudioProcessors and load them either in an AudioProcessorGraph or call them sequentially yourself (if you don’t need individual channel mappings, I found it simpler not to use AudioProcessorGraph).

For identical dsp::ProcessorChains you probably already found the dsp::ProcessorDuplicator to create multi-mono processing.

I’m curious, as I am still new to all of this.

What does this accomplish? I do realize that you’ve mentioned what you’re trying to do, but a lot of these terms are still on the vague side to me.

What can the end product do, that a layperson would understand?

My understanding was to have maybe some A/B mixer for alternative signal paths, for instance but not only dry/wet. Remember that in this scenario you might need to have a delay in the bypassed signal to have the same latency in both paths.

Good to know. Thanks.

More for me to learn and experiment with.