So frustrated with the mutibus stuff


Sorry but I have to let it out, the multi-bus stuff is driving me crazy ! Hosts are all buggy when it comes to aux channels and the Juce multibus code is insanely complicated, I just can’t understand it or debug it. Right now, I’m just blacklisting each host one by one because there is alway a combination of (plugin_type/host) that leads to the plugin crashing, producing horrible buzz, or just being instanciated with a channel layout that is not a sensible one.

I would have liked it so much if we could just list an exhaustive list of the layouts that we accept, instead of the super-powerful and generic but complicated thing we have now. In my case, the layout that I would accept would be, in order of preference:

stereo, mono, stereo+3 mono aux, mono + 4 mono aux bus, and that’s all.


Sorry for your pain. I’ll try as best as I can to help you get this sorted.

That is super simple with the multi-bus API:

bool JuceDemoPluginAudioProcessor::isBusesLayoutSupported (const BusesLayout& layouts) const
     static const Array<BusesLayout> mySupportedLayoutsList = ....;
     return mySupportedLayouts.contains (mySupportedLayoutsList);

I’m sorry to say, that particularly several aux buses are just not well supported by hosts. There is nothing that JUCE can do here. Even the best API won’t help you. For example, Logic only supports one additional mono/stereo aux bus, 15 additional mono/stereo aux busses or 1 main stereo out + 15 mono aux buses.

Cubase and VST3 has similar limitations.


Thanks Fabian, I agree your code is simple, what drives me mad are the exceptions to the rule and the host bugs. For example I was refusing layouts where some aux channels had 0 channel, it worked fine everywhere except in Dorico which seemed confused and produced a loud buzzing sound. Ableton live also works 50% of the time, I don’t know why, so I’m just going to disable the multibus for it. I also have a special case for Logic, it can list the ‘Stereo+3xmono’ and ‘mono+4x mono’ entries if one adds the AUChannelInfo mentionned here:

But apparently it is the single AU host that works that way.

The three VST3 aux buses work nicely in Cubase, it seems. But with REPEAR I’m not sure. It selects the ‘1x mono + 3x mono’ first (while I would prefer to have ‘stereo + 3x mono’ being selected).

Anyway… that was not really a rant against JUCE (although I think the code is too complicated for me) – so thank you for replying, and I know your task is not funny.


Hi everybody, thought I might jump in here before I waste time tracking a nasty buzz in my plugin running in Cubase 9.5. My instrument is configured as 0 audio ins with main out + 4 aux buses. If I turn on, from cubase, aux 1, 2 and 3, then disable aux 2… I get a nasty buzz (exactly like if you don’t clear an audio buffer when you should).

Having recently add support multi-out, I think this is a problem in my own code… so I disabled my processBlock by simply clearing the audio and midi buffer, then returning (none of my DSP code is running now and the buffers are cleared every cycle).

I rebuild and reload in cubase, and the buzz is still there… does this mean the problem is in Cubase? What should I tell people? Am I better off to not support Aux buses at all?

I just have a hard time believing that the inventors of VST3 wouldn’t properly support aux buses in their own DAW.


I also have just now modified the JuceDemoPlugin (using latest master branch). I added 3 aux inputs and 3 aux outputs, turned on VST3, and also categorized it as a synth. I get the exact same situation as described above… horrible noise when busses are skipped e.g.

Aux 1 = On
Aux 2 = Off
Aux 3 = On

So I guess this could be a bug in the VST3 wrapper, or Cubase… but considering other plugins with multi out don’t buzz, It seems like this is a juce problem (but I’m known to be wrong).


notification squad… see my last two posts in this thread.


This is a pretty serious issue guys, assuming that it really is a VST3 wrapper bug:
This video is unlisted, and I’ll take it down once somebody reviews it:

You can hear it pop when the bus is disabled, from there it sounds like that pop gets trapped in an audio buffer somewhere thus creating that horrible buzzz. It’s the exact same behaviour in my plugin, yours, and probably others whom have VST3 multi output buses… just a hunch.


Unfortunately, Fabian is the only one of us who really understands multi-bus enough to debug things like this, and he’ll be away for a few weeks… @t0m is this something you might be able to decipher?


Re-bumping this thread as it doesn’t look resolved? And I’m seeing a very similar situation with my multiout synth plugin.

I’ve got up to 16x stereo outputs configured which works nicely as long as the buses in Cubase (9.5) are enabled in a contiguous fashion i.e., buses 0, 1, 2, 3. But if I disable a bus in the middle of that set then I also get this noise mentioned by mfisher and my audio seems to get routed to the wrong buses in Cubase itself. For example, if I have buses 0, 2, & 3 enabled and in my internal engine I write to bus index 3 the audio appears in Cubase on bus index 2. The random noise I get is from bus 3 in this case. I’m pretty sure I’m using all the getBusBuffer() and getBusCount() stuff correctly in my code.

I’m going to take the JUCE multisynth code and see if I can reproduce there.


OK — I can reproduce this with the MultiOutSynthPlugin example.


  • Load the plugin into Cubase 9.5 as a VST3
  • Activate outputs #1-#4:
  • Playing on MIDI Channels 1-4 works as expected from Outputs #1-#4 respectively
  • Now disable Output #2
  • Playing on MIDI Channel 3 no longer works
  • Playing on MIDI Channel 4 now outputs from Output #3
  • Also, randomly enable some other outputs and when you get unlucky you’ll get noise from some of the outputs e.g.,


(Protect your ears and headphones!)


Pretty sure it’s this stuff in the VST wrapper that’s ignoring whether buses are disabled:

    auto n = jmax (vstOutputs, getNumAudioBuses (false));

    for (int bus = 0; bus < n && totalOutputChans < plugInOutputChannels; ++bus)
        if (bus < vstOutputs)
            if (auto** const busChannels = getPointerForAudioBus<FloatType> (data.outputs[bus]))
                auto numChans = jmin ((int) data.outputs[bus].numChannels, plugInOutputChannels - totalOutputChans);

                for (int i = 0; i < numChans; ++i)
                    if (auto dst = busChannels[i])
                        if (totalOutputChans >= plugInInputChannels)
                            FloatVectorOperations::clear (dst, (int) data.numSamples);

                        channelList.set (totalOutputChans++, busChannels[i]);
            const int numChans = jmin (pluginInstance->getChannelCountOfBus (false, bus), plugInOutputChannels - totalOutputChans);

            for (int i = 0; i < numChans; ++i)
                if (auto* tmpBuffer = getTmpBufferForChannel<FloatType> (totalOutputChans, data.numSamples))\
                    tmpBufferNeedsClearing = true;
                    channelList.set (totalOutputChans++, tmpBuffer);


This seems to fix it for me for outputs on VST3. I have applied the same fix for inputs but I don’t have any code to test multiple inputs. I can’t help thinking there must be a more efficient way of determining whether a bus is enabled from the wrapper since calling getBus() for every bus does relatively unnecessary branching.
vst3multiout-noncontiguousbuses-fix.diff.txt (1.2 KB)


I’m still pretty sure this is a fix for VST3 multibus stuff, we’ve been using it for synth output plugins