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?
) one might put forth that the initial post was about a slightly different problem of updateMatchedPairs() and from rereading the topic now, I see it took a direction towards efficiency instead of fixing the main issue (improper changing of the the midi score by inserting unneccessary note-offs).