Plugin Channel Configurations question Juce 4.2.2


#1

I am new to a large legacy commercial project that was originally built in 2013 using Juce 2.1.2 and is now being updated to use Juce 4.2.2. I am an experienced SW developer, but new to Juce.

The project builds a virtual instrument plugin that has audio in and out, MIDI in, and is a host for third-party virtual instrument VST plugins. It uses a fairly complex AudioProcessorGraph which includes mixing of the plugins. I want to configure my plugin as 2 in/ 2 out, the nodes in the processor graph each have specific numbers of in/out buses, and the hosted VST plugins have specific numbers of in/out busses.

The problem I am seeing is that AudioProcessor::setPreferredBusArrangement() does not distinguish between external buses (my plugin’s buses), internal buses (nodes in the graph), and buses for hosted plugins.

FYI I have read many related discussions on this forum, specifically guidelines for overriding setPreferredBusArrangement, but the rules say I can only reject a configuration; accepting a configuration requires going through the base-class method.

In our currently shipping version, which uses Juce 2.1.2, we used the default Projucer “Plugin Channel Configuration” settings {2,2},{1,1}, and we have many calls to AudioProcessor::setPlayConfigDetails() for the internal processor nodes that adjusted the number of input and output buses for each node.

In Juce 4.2.2 this technique does not seem to work, most visibly due to code that limits the inputs and outputs of the internal processors to JucePlugin_MaxNumInputChannels and JucePlugin_MaxNumOutputChannels and checks against the list of channel configurations. With the default Plugin Channel Configuration settings, Projucer generates a value for JucePlugin_MaxNumOutputChannels (and Input) of 2, yet my processor nodes in the graph as well as the hosted plugins frequently need more ins or outs.

I found that by adding many many pairs of values to the Plugin Channel Configuration settings I was able to get it to mostly work, but that approach causes at least two problems, one is that my plugin appears to have 16 inputs and 64 outputs, even though it is stereo in/out, and much worse: I think I would need to add a channel configuration for every possible plugin that we might host, which cannot be predicted.

I tried removing all values from Plugin Channel Configurations, which did not work. I am still working on this approach, but an example problem is that the base-class version of setPreferredBusArrangement() (with no Plugin Channel Configurations specified) does not limit the number of output buses, causing an assert in JuceVSTWrapper::setMaxChannelsOnAllBuses() ( // VST-2 requires a maximum number of channels. If you are hitting this assertion then make sure that your setPreferredBusArrangement only accepts layouts up to a maximum number of channels) but this class uses AudioProcessor::setPreferredBusArrangement() which AFAIK I should not be modifying. I could not figure out how to override it in this context. Even if you can help me to override this method, I am still stuck with the problem where my plugin looks like it has a very large number of inputs and outputs, even though it is stereo in and out.

In summary, I want my plugin to be limited to 2 ins/ 2 outs, and I want each node in the processor graph to have specific number of ins and outs, and each hosted VST to be able to have the correct (plugin-specific) number of ins and outs.

I am aware that the Juce team is in the middle of re-writing the multi bus code, but I don’t think we can wait, so I am trying to make 4.2.2 work. Any tips or advice?

-John


#2

This is Fabian’s area, but he’s away this week… Hopefully when he’s back in a few days he’ll be able to give you a good answer!


#3

Any word from Fabian?


#4

Hi Jules and Fabien,

It has been two weeks now since I asked my question above. I am still stuck and still looking for some help. FYI before I asked my question, I spend many many hours working on it myself before deciding that I needed some assistance. I would like to avoid “hacking” the Juce library if I can avoid it!

-John


#5

The bug you are describing is why we needed to rework the multibus system. Basically the current version on develop/master does not support hosting plugins in a graph while being a plugin at the same time.

The bug fixes for this are on the experimental/multibus branch. Unfortunately, to fix the bugs, some breaking API changes were necessary.

To get a good understanding of the new API, please have a look at the examples/PluginSamples folder on the experimental/multibus branch. In particular the NoiseGate, Surround and multisynth plugins.

We are planning on doing a bug fix release soon (a week or two) where the current develop will become master, and the experimental/multibus branch will be merged into develop - ready for the bug fix release thereafter.

It would be so helpful for us if you could test your project with the experimental/multibus branch and report any issues or feedback.

I’m sorry I don’t have a better answer.


#6

Thanks for your answer. For various reasons we may be forced to modify the version of Juce that we already have, but (if schedule permits) we may be able to wait for the new code and integrate it. I will try to make some time to look at the experimental branch, but I can’t promise that I will be able to. If I can find the time to look at it I will also try to find the time to give you some feedback and/or questions!
-John