AudioGraphIOProcessor with the new bus system

When writing a synth plugin that consists of a series of submodules chained together in an AudioProcessorGraph, with an AudioGraphIOProcessor::audioInputNode at the beginning and an AudioGraphIOProcessor::audioOutputNode, I'm running into the issue that those in- and output nodes fall back to the AudioProcessor constructor for setting up their bus arrangements. If I look at the AudioProcessor constructor:

#ifdef JucePlugin_PreferredChannelConfigurations
    const short channelConfigs[][2] = { JucePlugin_PreferredChannelConfigurations };
    const short channelConfigs[][2] = { {2, 2} };

 #if ! JucePlugin_IsMidiEffect
   #if ! JucePlugin_IsSynth
    busArrangement.inputBuses.add  (AudioProcessorBus ("Input",  AudioChannelSet::canonicalChannelSet (channelConfigs[0][0])));
    busArrangement.outputBuses.add (AudioProcessorBus ("Output", AudioChannelSet::canonicalChannelSet (channelConfigs[0][1])));

  #ifdef JucePlugin_PreferredChannelConfigurations
   #if ! JucePlugin_IsSynth
    AudioProcessor::setPreferredBusArrangement (true,  0, AudioChannelSet::stereo());
    AudioProcessor::setPreferredBusArrangement (false, 0, AudioChannelSet::stereo());

all the defines will come from the "parent" audio processor plugin, so if that is a synth, for instance, there will be no input bus for the AudioGraphIOProcessor::audioOutput module (although it would need one, obviously). It seems to me that those modules should now take care for their own bus setup in their constructors?

I’ve reported issues with the AudioProcessorGraph in the ultimate MultiBus thread. You may want to check that out.


Not sure which thread you mean exactly... I haven't seen this specific issue discussed yet, although I could have overlooked something of course.

this is bullshit... why in 2016 do we go back to the stone age with this nonsensical macro fluff inside a basic audio foundation class ? this smells badly sorry

See post #19

(Edit: (DEPRECATED) The ultimate JUCE 4.1 MultiBus Guide)


The "macro fluff" is just our internal hacks for backwards-compatibility with people's existing code. If you're writing a new plugin there's no reason to use any macros.

True for the channel configurations, but I'm not using them anymore. The JucePlugin_IsMidiEffect and JucePlugin_IsSynth macros are what can potentially cause trouble for audio processors consisting of several sub-audio processors (if one doesn't take care of the buses for those sub-processors in their constructors, which is what I'm suggesting for the IO processors).

* double post *

So this is still an issue in 4.2.1. For now, I’ve added these lines to the constructor of the AudioGraphIOProcessor:

AudioProcessorGraph::AudioGraphIOProcessor::AudioGraphIOProcessor (const IODeviceType deviceType)
    : type (deviceType), graph (nullptr)
    int numIns = busArrangement.getTotalNumInputChannels();
    int numOuts = busArrangement.getTotalNumOutputChannels();
    if (type == audioOutputNode)
        busArrangement.inputBuses.add  (AudioProcessorBus ("Input",  AudioChannelSet::canonicalChannelSet(numOuts) ));
    if (type == audioInputNode)
        busArrangement.outputBuses.add (AudioProcessorBus ("Output", AudioChannelSet::canonicalChannelSet(numIns) ));