Simple VST Host based on Juce

General JUCE discussion
1

Hi everyone!

I would like to ask for a little help. I’m trying to develop a VST host with some advanced functionality.
I’m working with chains of VST plugins that are wrapped into AudioProcessorGraph which is working well.
My next step is to connect these chains to each other. And here I’m getting into trouble.
Is there any advice on getting an output of one AudioProcessorGraph and sending it as input of another AudioProcessorGraph?
My result is that all AudioProcessorGraphs are sending their output directly to the output device.

My current setup:
master AudioProcessorGraph contains one AudioProcessorGraph with VST instrument and a second AudioProcessorGraph with VST effects
master graph configured to output sound to device A.

I want to get the instrument graph output to the effect graph input, process it, and output it to the master graph output.

At the moment my vst instrument sends output directly to device A.

I would really appreciate any help.

2

The AudioProcessorGraph itself is an AudioProcessor, so you can wrap it in a node of the outer AudioProcessorGraph.
However, I am not sure if I understand your model right, usually an instrument would be at the start of a branch and is piped through the effects. So I am not sure what’s the point to have them in separate AudioProcessorGraphs.
But technically you can nest them as much as you want (and as much as processing power allows).

3

Hi Daniel,

Thank you for the reply. My description is very simplified. The idea is to have an instrument chain with its own effects and then to have FX chains that can be switchable and re-routable.

Anyway, what you have described is what I did:

mainProcessor = new AudioProcessorGraph();
trackNode  = mainProcessor->addNode (std::make_unique<AudioProcessorGraph>());
fxNode = mainProcessor->addNode(std::make_unique<AudioProcessorGraph>());
// Now I'm routing everything:
for (int channel = 0; channel < 2; ++channel) {
        mainProcessor->addConnection ({ { trackNode->nodeID,  channel },
            { fxNode->nodeID, channel } });
        mainProcessor->addConnection ({ { fxNode->nodeID,  channel },
            { audioOutputNode->nodeID, channel } });
}

Everything is connected here, but I don’t have the output of the trackNode in the fxNode…

Regards,
Oleksiy.

4

Honestly if I were in your position (I have been here) I would immediately start evaluating the Tracktion framework and the suitability of adding it to your project.

Everything you’re trying to do, Tracktion already handles in its Edit classes. You create an Edit, which contains the signal flow and plugin graph as you need it, and then you load it with Tracktion - ta dah! All done! And you can dynamically alter the Edit/audio graph in sensible ways too - at a slightly higher level of abstraction.

Of course this depends on if you have the resources needed to add Tracktion on top of JUCE, but having bit the bullet myself, from a similar position, I can say that it is very worthwhile to do so …

5

Hi,

Thank you for your response. As I’m starting from scratch, I think I could take a look at the Tracktion. My hope was to use a single framework only, but if Juce isn’t able to handle such a workflow, I’ll try all available ways to solve my puzzle.

I have one little question: “this depends on if you have the resources needed to add Tracktion on top of JUCE”
How much Tracktion needs additional resources? Is it quite heavy for CPU/RAM consumption?

Regards,
Oleksiy.

6

I don’t think it is a problem of JUCE, but I haven’t used AudioProcessorGraph much. Only once or twice a long time ago, so I cannot help much. What you did is what I expected to work.

Tracktion will become interesting in the future, when your demands will grow.
Stuff that Tracktion deals with in addition to JUCE (probably much mre, that’s just what I am aware of):

  • multi threading
  • latency for each node
  • state saving and restoring

So at the moment I don’t think you will need it necessarily, but if you encompass one of those points, it will make sense to evaluate it.

7

Resources = Time, Space, Energy, Patience, etc.

Frankly, I think you’re going to have a lot of fun discovering what Tracktion has to offer and how much work it will save you … but of course, ymmv …

8

So, it looks like I’ve found the issue.

You have to use the device manager from the parent node. In this case, AudioGraphIOProcessor nodes of the child AudioProcessorGraph will act as expected.
My mistake was using own instance of the AudioDeviceManager for each AudioProcessorGraph which caused such unexpected behaviour.