The AudioProcessorGraph is a bit slow nowadays

After I updated to Juce 6 a typical task that previously took virtually no time at all (<0,5s) now takes over a minute to complete.

The cause seems to be an update to the AudioProcessorGraph made some time ago, during Juce 5, don’t know exactly when because I don’t update that often.

Now, in Juce 6, this piece of code in the graph is executed for every change being made (adding a node, making a connection etc)

static void updateOnMessageThread (AsyncUpdater& updater)
{
    if (MessageManager::getInstance()->isThisTheMessageThread())
        updater.handleAsyncUpdate();
    else
        updater.triggerAsyncUpdate();
}

The call to handleAsyncUpdate() is a call to buildRenderingSequence(), which rebuilds the whole graph every time, effectively blocking the message thread.

A typical task in my app is to open a midi file whereupon a few basic plugins are attached to each track, say a score display, a sample player, volume/balance, a VU meter etc.

For a 16 track file this means some 64 plugins are added to the graph and a few hundred connections are being made, connecting inputs to outputs, times two if it’s stereo. All in all, typically a couple of
hundred consecutive calls are being made to graph.addNode() and graph.addConnection().

Each one of these calls triggers a call to buildRenderingSequence() which rebuilds the graph from scratch over and over again.

Previously the code, effectively, was

static void updateOnMessageThread (AsyncUpdater& updater)
{
  updater.triggerAsyncUpdate();
}

which concatenated all subsequent calls to buildRenderingSequence() to just one, giving an effective graph set up time of virtually zero instead of as of now, halfanother minute!

Ok, I admit it’s the debug build I’m talking about, but even in release mode it takes over 10 secs to open a file like anotheronebitesthedust.mid, and virtually all this time is spent in the AudioProcessorGraph doing repeated calls to buildRenderingSequence…

Could we please have an update to the graph that allows a non blocking operation of the graph, even if called from the message thread, like before?

1 Like