Small issue with bus configuration and VST3



Hello to the JUCE team ! Hello @fabian !

I have encountered a minor but very strange issue with the last version of JUCE from develop and the last version of the VST3 SDK.

I have a plug-in which is configured in the Projucer with “{1, 1}, {2, 2}” in Plugin Channel Configurations to specify that it can be either mono input mono output or stereo inputs stereo outputs. It worked fined this way until I added the VST3 export option.

In Reaper 64 bits on Windows, the VST3 version of my plug-in at first export is labelled “name of the plug-in” (mono) whereas the VST2 version is labelled “name of the plug-in”. And when I load it on a stereo channel in Reaper, the signal is processed… properly in stereo. Strange isn’t it ?

So I did more tests with a plug-in created from scratch in the Projucer, with different options for the Projucer Configuration :

  • {1, 1} : the VST2 and VST3 are labelled with (mono) and they do mono processing only
  • {2, 2} : the VST2 and VST3 are not labelled with (mono) and they do stereo processing only
  • {1, 1}, {2, 2} : the issue is there again, the VST2 is not labelled with (mono), but the VST3 is, and both are doing either mono or stereo processed if wanted, it’s just the label which is weird

And the weirdest thing is there :

  • {2, 2}, {1, 1} : the VST2 and VST3 are not labelled anymore with (mono), and they process sound as well as expected.

Any reason for this ? Is it something I do the wrong way ? Or maybe an issue with Reaper itself ? I guess it might do the same thing on macOS, but I have not tried yet…

Thanks in advance !


This is expected behaviour. The first layout you specify in the Plugin Channel Configuration is the default layout advertised to the host. You should be using {2,2}, {1,1}. Or even better use the AudioProcessor (const BusesProperties&) constructor and override AudioProcessor::isBusesLayoutSupported. The Plugin Channel Configuration field is legacy code anyway.

For a simple mono/stereo plug-in your constructor and isBusesLayoutSupported would look like this:

struct MyPlugin   : AudioProcessor
        : AudioProcessor (BusesProperties().withInput  ("In", AudioChannelSet::stereo())
                                           .withOutput ("Out", AudioChannelSet::stereo()))
    bool isBusesLayoutSupported (const BusesLayout& layout) const override
        // ensure input and output has same number of channels
        if (layout.getMainInputChannelSet() != layout.getMainOutputChannelSet())
            return false;
        auto numChannels = layout.getMainInputChannels();
        // only allow mono and stereo
        return (numChannels > 0 && numChannels <= 2);


Hello !

OK so that’s normal, I have never encountered this issue before even if I use “{1, 1}, {2, 2}” almost of the time, and isBusesLayoutSupported when I need something more complicated, that’s why I asked.

Thanks for the answer !


Yes we changed this behaviour a while ago. The order of channel configurations didn’t matter before as it would always use the configuration with the highest channel number as default. But for many plug-ins this default was not suitable.