The AudioProcessorGraph works well… but its sort algorithm needs some serious attention… and it still doesn’t support (or handle) feedback connections. I’ve posted on this in the past and I’ve got some workarounds to deal with the feedback issue… but if I have a lot of Aux Tracks the logic to build the UI to avoid any feedbacks requires a lot of recursion so really slows down preset reloading… and even in a Mixer with a lot of nodes, switching an Aux send from Pre to Post requires changing the nodes… which causes the graph to be recalculated and sorted. There also seems to be no way to chain graphs to minimize the aforementioned issues.
I’ve previously posted a thread on adding some PDC functionality to the graph as well:
… and of course… making it thread safe would be great!
Now that you’ve released JUCE 5 and you’re going to have all that free time… I thought this would be the perfect time to broach this subject again
Yeah, that’s a bad idea. If you wanted to have feedback, what is the granularity? Whatever you decide, you will end up with lots of overhead and more or less destroy any performance you may want to have.
In Audio ToolKit, I forbid feedback for exactly this reason, you can’t have everything, or you use a JIT to recompile your process module itself on the fly, and that’s called Reaktor (and it has its own caveats).
Try to work out a different architecture that doesn’t have feedback loops.
If, at a minimum, we could chain AudioProcessorGraphs, I could have a separate graph for each track and that would reduce the number of nodes and connections that need to be sorted when only changing something on one track… which would help alleviate a lot of my issues.
