Curious assert

#1

im using a graph to host vst instances, basically after i created the vst instance i add it to the graph like this:

vstID1 = graph->addNode(instance1.get())->nodeID;

instance1 is a std::unique_ptr, vstID1 is a AudioProcessorGraph::NodeID so that i can call that node through the id later, in processBlock i process every single node like this:

graph->getNodeForId(vstID1)->getProcessor()->processBlock(buffer, midiMessages);
graph->getNodeForId(vstID2)->getProcessor()->processBlock(buffer, midiMessages);
graph->getNodeForId(vstID3)->getProcessor()->processBlock(buffer, midiMessages);

everything work fine and every node get processed well in chain, but if i load a vst with 2 buses, 1 input stereo and 1 sidechain stereo i hit this assertin juce_VST3Common.h:

jassert (channelEnd >= 0 && channelEnd <= buffer.getNumChannels());

channelEnd equal 4, i guess is the sum of all the channels, 2 input and 2 sidechain, but even in that case aren’t they processed separately? i mean is there a situation where a buffer could be 4 channels? bit confused, if i ignore the assert anyway everything seems working well, should i ignore it or still it means that something is going wrong?

0 Likes

#2

If instance1 is a unique_ptr, then this code will cause the inner processor to be double-deleted. The AudioProcessorGraph takes ownership of the processors it contains, so you shouldn’t try to manage their lifetimes with unique_ptr, shared_ptr etc. When adding a node to the graph, you should do something like this:

id = graph->addNode (instance1.release())->nodeID

Calling release means that the unique_ptr will give up ownership of the object, and won’t try to delete it later. This is fine, because the AudioProcessorGraph will do it instead.

That’s unnecessary, you should just call graph->processBlock (buffer, midiMessages);

You’re likely hitting this assertion because the audio buffer is two channels wide, but the plugin is expecting to see four channels at its input (1 input stereo pair, and 1 sidechain stereo pair). I suspect that if you were to connect the graph properly by calling graph->addConnection, and then to use graph->processBlock, the graph would ensure that each node has the right number of ins/outs and you’d no longer see that assertion. I suggest reading the docs for AudioProcessorGraph::processBlock for more details.

0 Likes

#3

Hi, thx for your answer about the unique_ptr thx for the info, i will fix that, for what regards the processblock processing each node there is a reason, if i do graph->processBlock (buffer, midiMessages) it process also the raw input sound layered to the vsts processed sound, so it’s like having a clean input + the processed one played at once, the connection get 2 nodes In and Out:

AudioProcessorGraph::AudioGraphIOProcessor* in;
	in = new AudioProcessorGraph::AudioGraphIOProcessor(
		AudioProcessorGraph::AudioGraphIOProcessor::audioInputNode);

	AudioProcessorGraph::AudioGraphIOProcessor* out;
	out = new AudioProcessorGraph::AudioGraphIOProcessor(
		AudioProcessorGraph::AudioGraphIOProcessor::audioOutputNode);

graph->addNode(in);
graph->addNode(out);

the node In get connected to the vst, the vst get connected to the out node, any idea how to get only the vst processed removing the raw input sound?

0 Likes