Yeah, I couldn’t see anything wrong either, which is why I just replaced the whole thing. Must have been something very subtle!
Jules, do you think the PDC stuff will make it into JUCE in some way?
Sorry, I hadn’t even noticed your earlier post! Thanks! I’ll take a look and see what I can do…
I added it a couple of weeks ago, didn’t I?
Plugin Delay Compensation, or the optimizations? He was asking about the delay / latency compensation.
The delay stuff was already added yeah. Haven’t used it myself though. Impressive stuff!
Oh, excellent! Sorry for the false alarm…
Pinging this old thread as I just stumbled upon it. I checked that the JUCE core modules (AudioProcessorGraph.cpp) still have all these solutions included, but how should one actually use those latency compensation mechanisms? I’m asking because it seems that I might have just encountered this problem when using a latency heavy chain in Plugin Host example. And might have because I really can’t tell just yet - and especially not after reading all this and it’d seem to me that all this latency compensation should be happening on the background in AudioProcessorGraph instances already…?
If you hear me, let me know which is it - should the latency compensation already be happening in the Plugin Host example automatically, or do I have to somehow make manually use of those structures described in this thread / nowadays included in the AudioProcessorGraph.cpp.
The PDC changes mentioned in this thread were implemented… but there are still some PDC issues remaining which I addressed in my thread here
Good! Let’s move all the further discussion to this new thread then.
I just ran into the original issue motivating this thread - with about 20 effect nodes, connected in series, each receiving and producing 2 audio channels, I see ~10 seconds time to add a new node to the graph on a newish 13 inch MBP. Looking at the profiler, almost all of this time is spent in
AudioProcessorGraph::isAnInputTo, which is still being recursively called in
AudioProcessorGraph::createOrderedNodeList (JUCE v5.4.7). I don’t see any of the optimizations mentioned in this thread on the master branch, as far as I can see. Other folks, like zax, are saying that these solutions are included. I’m confused, did this never actually make it in?
The changes were indeed added but I believe the graph has been refactored fairly significantly since then. Unfortunately I haven’t used the graph in a long time so I can’t speak to it’s current implementation.
The Graph is awesome in a lot of manners, you can build very large projects fairly easily with it, and everything works as expected, however, there are some bottlenecks which unfortunately do cause problems with large production ready apps.
The best bet is to copy the graph code into your own project space and make the changes necessary for your use case. Things such as offline rendering, the order of prepareToPlay, and the speed of changing the graph when new connections are created, are all fairly substantial issues the library hasn’t addressed
10 seconds for adding a new node to 20 nodes with two connections in&out each… sounds like something is wrong. While there are certainly bottlenecks with graph rebuild performance, this amount of connectivity should never take 10 seconds. Are you sure you are rebuilding the graph just once?
Yeah… that is not normal, however, the isAnInputTo function, is recursive, and actually, can be slower or faster, depending on the order your nodes were added to the graph surprisingly. Try to add the nodes to the graph, in the same order as their general signal flow, and it will make it faster too.
Or, simply remove the recursion checks all together if your graph is purely serial, it will still generate the correct order