AudioProcessorGraph with VST plugins - issue getting started



I’ve been trying to get started with writing a plugin using an AudioProcessorGraph connecting a number of my own AudioProcessor. But without success… :confused:

It all started from the Introjucer (4.1) to create a plugin, I replaced the default plugin AudioProcessor (in PluginProcessor.cpp/h) by an AudioProcessorGraph. I removed the original override of processBlock. And I added the graph constructions commands into the prepareToPlay function to simply connect the inputs to the outputs:
In PluginProcessor.h:
class MyAudioProcessorGraph: public AudioProcessorGraph

In PluginProcessor.cpp:
void MyAudioProcessorGraph::prepareToPlay (double sampleRate, int samplesPerBlock)

inProc = new AudioProcessorGraph::AudioGraphIOProcessor(AudioProcessorGraph::AudioGraphIOProcessor::audioInputNode);
inNode = addNode(inProc);

outProc = new AudioProcessorGraph::AudioGraphIOProcessor(AudioProcessorGraph::AudioGraphIOProcessor::audioOutputNode);
outNode = addNode(outProc);

addConnection(inNode->nodeId, 0, outNode->nodeId, 0);

I don’t have any compilation error (debug mode), but when the plugin gets instantiated by the JUCE audio plugin host, it stops at this jassert. Which I don’t understand why.
// the processor may not support this arrangement at all jassert (newNumIns == getTotalNumInputChannels() && newNumOuts == getTotalNumOutputChannels());

I must be doing something silly, any ideas?

value for newNumIns is 0 and getTotalNumInputChannels() returns 1


Maybe start by NOT inheriting from AudioProcessorGraph. It’s not designed to be a base class, and as soon as you override the methods that it needs to do its job, you’re going to break things!


Ah okay, so the default main subclassed AudioProcessor will instantiate the AudioProcessorGraph which will call some AudioProcessors. Why not :slight_smile:


Hmm, same problem :frowning:
Now I have:
class MyAudioProcessor : public AudioProcessor

In its constructor I call:
graph = new AudioProcessorGraph();

Then in prepareToPlay
void MyAudioProcessor::prepareToPlay (double sampleRate, int samplesPerBlock)
// Use this method as the place to do any pre-playback
// initialisation that you need..

inProc = new AudioProcessorGraph::AudioGraphIOProcessor(AudioProcessorGraph::AudioGraphIOProcessor::audioInputNode);

inNode = graph->addNode(inProc);
and it triggers the same error (jassert) calling this addNode(inProc).

I created a new project from scratch, with the same end result…


Read the MultiBus sticky thread. It’s a bug introduced with JUCE 4.1 and has meant I can’t update past JUCE 4.0 until it’s fixed. Hopefully it’s on the radar…

See: (DEPRECATED) The ultimate JUCE 4.1 MultiBus Guide



Thank you for pointing this out. I thought it could be related, but wasn’t sure. I guess I’ll downgrade for now, then.



@jules is it on the radar? Kind of a shame to be stuck with JUCE 4.0…


Sorry, really struggling to understand what exactly your problem is. Might be something that Fabian recognises from the multibus work, but he’ll be away and busy for the next week.


Hi Jules,

The new MultiBus configuration isn’t propagated down to the AudioProcessorGraph – I posted a modified version of the synth demo from JUCE 4.1 to demonstrate the issue in the other thread.



In version 4.2 of JUCE, I am not sure but I may have found an issue in juce_AudioProcessorGraph.cpp at line 1643 ?

The inputs should be specified first, then the outputs ?

This would seem to solve Fred’s problem.

void AudioProcessorGraph::AudioGraphIOProcessor::setParentGraph (AudioProcessorGraph* const newGraph)
    graph = newGraph;

    if (graph != nullptr)
        // Modified by Jacques on May 23 2016;
        // Inputs go first 
        setPlayConfigDetails (
                              type == audioInputNode  ? graph->getMainBusNumInputChannels()  : 0,
                              type == audioOutputNode ? graph->getMainBusNumOutputChannels() : 0,


It solved the very same issue I had with creating a output node in the graph.


AudioProcessorGraph in a VSTi Plugin

Fixed on develop tip.


Great, thanks Fabian and Jacques!