setPreferredBusArrangement removed in JUCE 4.3.0?

i just updated to JUCE 4.3.0 and my project won’t compile anymore, complaining about setBusArrangement not being a base member of AudioProcessor, so i can’t override it (VS 2015, tested x64 & x86) :

Error C3668 ‘ContainerInNode::setPreferredBusArrangement’: method with override specifier ‘override’ did not override any base class methods (compiling source file …\Source\VSTNode.cpp)

All my nodes get the same error, and are all child classes of AudioProcessor.

I checked in the Audio Processor class and i can’t find anything containing “busArrangement” … has this been changed for another thing in 4.3.0, or is it an error in my setup ?
I couldn’t find any topic here discussing this, or any clue of that on Juce git…

If it changed, the online documentation is out of date, because it still mentions the “setPreferredBusArrangement” method

Thank you

You’re not alone.

I had the same problem with setPreferredBusArrangement. I removed it and set my plugin’s audio configuration to {0, 2}. Now it compiles but doesn’t work and auval won’t validate it. I went back to 4.2.4 and everything is fine.

This is because in 4.3.0 they have introduced a new, revised multibus API.

The first attempt, based on setPreferredBusArrangement() was too complicated and didn’t cover all edge cases.

Until they update the official doc (which I hope is done soon), you can refer to the following topic for a description of how it works now:

Thank you for the quick reply !
It’s strange that they decided to roll out an official release with no official note on that, it will likely break every JUCE project using audio (so, almost every juce project).

Anyway, we will change that and put some feedback here and on the other topic.

Thanks !

Its a pretty simple fix for a project based on 4.2.x:

In processor.h, remove -

#ifndef JucePlugin_PreferredChannelConfigurations
 bool setPreferredBusArrangement (bool isInput, int bus, const AudioChannelSet& preferredSet) override;

and replace with -

#ifndef JucePlugin_PreferredChannelConfigurations
 bool isBusesLayoutSupported (const BusesLayout& layouts) const override;

in processor.cpp, do something like the following in your constructor -

#ifndef JucePlugin_PreferredChannelConfigurations
:  AudioProcessor (BusesProperties()
                 #if ! JucePlugin_IsMidiEffect
                  #if ! JucePlugin_IsSynth
                   .withInput  ("Input",  AudioChannelSet::stereo(), true)
                   .withOutput ("Output", AudioChannelSet::stereo(), true)
lastUIWidth(800), lastUIHeight(600)
1 Like

Thank you,
seems like a good starting point.
However, my audioProcessors needs to redefine their input and output count on runtime (we have nodes that can change their number of audio inputs and outputs), so defining that in the constructor is not enough.

Yes, that solved my problems. Thank you.

The “old” multibus API had a very short life and hopefully nobody used it for a lot of products, also in consideration of the fact that for the typical case of only having a single main bus, the approach with the JucePlugin_PreferredChannelConfigurations macro has never ceased to be fully functional (and it is still the suggested approach if one doesn’t need additional buses, I think)

For this, I think you should override AudioProcessor::canRemoveBus() and make it return true, then use addBus() and removeBus()

Check AudioProcessor.cpp at line 540 for the relevant docs (again, I hope they update the online doc soon!)

Oh ok, i didn’t know that, we have been developping our software since march, so i guess we only knew this way do do it, and to be honest and i’m not the main referee for the audio processing part in the software.
Thanks for the infos again, will try that.

Does that new Multibus API properly work with Pro Tools 10 / 32 bit AAX that have side chain input?

Yes it does. Just add a second bus to your plugin. Look at the JUCE/examples/PluginSamples/NoiseGate example. This has a sidechain and will work great with AAX.

Also, sorry about the incorrect documentation on the website. This will be fixed first thing on Monday.

1 Like

Thank you all for the answers,
our team managed to get everything working with the new API !

1 Like

Sorry guys, but changing your API without changing the documentation simultaneously is not at all ok. Please reconsider before you do that again.

Well, they wrote already that they will take care of it tomorrow.

If they do, that’ll be only a few days’ delay, part of which is on a weekend… I think we can live with it :wink:

I bet that slipped because they had to give full attention to organizing ADC, and to release 4.3.0 before it in order to properly present the BLOCKS sdk.

This was not intentional. We’ll fix this first thing Monday. The Juce and web teams were swamped with ADC and the blocks launch. Once again sorry for the inconvenience.