The AudioProcessorGraph, when adding/removing a connection or a node, calls the internal function
topologyChanged() which recreates the rendering sequence. This is great, except typically I want to make more than a single change to the graph at a time, so the
topologyChanged() function gets called extraneously multiple times, which slows things down considerably.
I am wondering if there is a reason for this to be called on every single pass? Or could there be a batch add/connect function for the graph? For example, pass a flag or juce::Notification into the connect/disconnect/add/remove functions and make the
topologyChanged() function public, so that a user can bypass the call until everything is set up, then manually call the function. From my tests it was taking a few seconds to make all the connections, and after making the change the time was vastly reduced.
Hope that makes sense.
unfortunately you’ll likely have to copy the graph to your own namespace and then add this functionality – it’s been requested before
Thank you. That was what I did to test the change. I guess I will just keep it for now.
Do you know the reasoning from JUCE for not implementing this feature? I couldn’t find any other forum posts about it.
Actually it’s an ancient request and there are many posts about it. I suggest voting for this FR: [FR] AudioProcessorGraph addConnections/removeConnections
Oh thank you! Clearly my google skills need work.
I think using Google might be the issue. It’s better to use the provided search functionality from within the forums.
Yeah that said – @t0m added some insane speed improvements to the graph construction in a recent update.
The other main things that can slow it down is:
Lots of bulk changes & very wide nodes with tons of input pins (mine have a lot of parameter modulation)
The quickest patches are adding a “don’t rebuild on change” mechanism and ability to manually trigger graph construction.
The other is a bit more in depth, but is improving some of the ways that source nodes & connections are traversed when doing render sequence construction. Once the graph is constructed, playback is pretty much no problem.