AudioGraphIOProcessor with the new bus system


#1

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 };
   #else
    const short channelConfigs[][2] = { {2, 2} };
   #endif

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

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

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?


#2

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

Rail


#3

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


#4

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


#5
https://forum.juce.com/t/the-ultimate-juce-4-1-multibus-guide

See post #19

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

Rail


Old links broken
#6

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.


#7

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).
 


#8

* double post *


#9

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();
    busArrangement.inputBuses.clear();
    busArrangement.outputBuses.clear();
    if (type == audioOutputNode)
        busArrangement.inputBuses.add  (AudioProcessorBus ("Input",  AudioChannelSet::canonicalChannelSet(numOuts) ));
    if (type == audioInputNode)
        busArrangement.outputBuses.add (AudioProcessorBus ("Output", AudioChannelSet::canonicalChannelSet(numIns) ));
}