(DEPRECATED) The ultimate JUCE 4.1 MultiBus Guide

Audio Plugins
61

Instead of channels.size() == 2 you can also just use ! channels.isDisabled()

62

Isn’t this much better ?

busArrangement.isBusEnabled (bool isInput, int busIndex)

Also, the function AudioBusArrangement::getBusBuffer returns a copied object on the stack, getting it difficult to use in situations where you have if logic for enabled / disabled channels.

AudioSampleBuffer busBuffer;
if (! busArrangement.outputBuses.getReference(1).channels.isDisabled()) // look the verbosity... juce has never been like this !
{
    busBuffer = busArrangement.getBusBuffer(output, false, 1); // copying ?!
}

if (busBuffer.getNumChannels() > 0) // enabled ? use it
{
    // ...
}

this seems a bit overkill when i just need to get the location of those buffers, nullptr otherwise.

63

Don’t worry fix is coming. All though I currently prefer the fix where JUCE requires multibus plugins (i.e. only plugins with additional sidechains and aux buses AND only on vst 2) to have a static layout which is their default layout. This would get rid of much of the complexity of vst 2 plugins and DAWs don’t support this properly anyway.

64

The second time round I’m doing this it’s all still super-confusing :slight_smile:

Mainly this:

setPreferredBusArrangement

There aren’t any good reasons for it to reject your change anyway (other than specifying buses that don’t exist).

Here’s the relevant code from AudioProcessor.cpp:

if (! isPositiveAndBelow (busIndex, numBuses))
    return false;


bus.channels = preferredSet;

if (oldNumInputs != getTotalNumInputChannels() || oldNumOutputs != getTotalNumOutputChannels())
{
    updateSpeakerFormatStrings();
    numChannelsChanged();
}

So basically you are just proposing an alternative arrangement which will be accepted by the method.

And I have to write a method that looks like this:
{
if (busIndex > 0)
return false; // only support a single bus in or out

    if (preferredSet == AudioChannelSet::mono())
    {
        AudioProcessor::setPreferredBusArrangement(isInput, busIndex, preferredSet);
        return true;
    }

    if (preferredSet == AudioChannelSet::stereo())
    {
        AudioProcessor::setPreferredBusArrangement(isInput, busIndex, preferredSet);
        return true;
    }

    return false;
}

But with a slight tweak to the parent class all the calls to AudioProcessor::setPreferredBusArrangement class wouldn’t need to be there, and it could look like this:

{
    if (busIndex > 0)
        return false; // only support a single bus in or out

    if (preferredSet == AudioChannelSet::mono())
        return true;

    if (preferredSet == AudioChannelSet::stereo())
        return true;

    return false;
}

Or even:

{
        if (busIndex > 0)
            return false; // only support a single bus in or out

        return preferredSet == AudioChannelSet::mono() || preferredSet == AudioChannelSet::stereo();
}

Which is starting to look super-obvious…??

And then we just need a nice name for a call that sets the other buses if they also need to change as a result of a request to this function. Maybe this could look like:

bool requestBusArrangement(...)
{
        if (busIndex > 0)
            return false; // only support a single bus in or out

        setBusArrangement(! isInput, 0, preferredSet); // make the ins and outs the same size.
        return preferredSet == AudioChannelSet::mono() || preferredSet == AudioChannelSet::stereo();
}

And it’s still looking easy to understand?

66

Can you please remove empty lines from the code sections of the first post ? They’ve been added since guide is deprecated.

Thank you!

67

Thanks!   

68

Thank you !!!

69

Fabian - is this depreciated because the alternative is now available, or is this depreciated in advance of the replacement being in the main branch?

70

The API described in this post is the multibus API which is on develop/master. However, this will be replaced by the improved and fixed API found in the new experimental/multibus branch. An introduction to this API can be found here:

https://forum.juce.com/t/revised-multibus-api-experimental-please-test?source_topic_id=16755
1 Like