Site navigation

AudioProcessorGraph slow manipulations

General JUCE discussion
#77

How about this (I’ve just copied the binary search algorithm from SortedSet, but haven’t tested it):

[code] Entry* findEntry (const uint32 destNodeId, int& insertIndex) const noexcept
{
Entry* result = nullptr;

    int start = 0;
    int end = entries.size();

    for (;;)
    {
        if (start >= end)
        {
            break;
        }
        else if (destNodeId == entries.getUnchecked (start)->destNodeId)
        {
            result = entries.getUnchecked (start);
            break;
        }
        else
        {
            const int halfway = (start + end) / 2;

            if (halfway == start)
            {
                if (destNodeId >= entries.getUnchecked (halfway)->destNodeId)
                    ++start;

                break;
            }
            else if (destNodeId >= entries.getUnchecked (halfway)->destNodeId)
                start = halfway;
            else
                end = halfway;
        }
    }

    insertIndex = start;
    return result;
}

[/code]

#78

Yep, this one works! :smiley:

#79

I stared at your original findEntry () and I couldn’t see the problem…any idea what it was? It looked right…

#80

Nice work by the way, that was exactly what was needed.

#81

Yeah, I couldn’t see anything wrong either, which is why I just replaced the whole thing. Must have been something very subtle!

#82

Jules, do you think the PDC stuff will make it into JUCE in some way?

#83

Sorry, I hadn’t even noticed your earlier post! Thanks! I’ll take a look and see what I can do…

#84

Bumpety-bump… :smiley:

#85

I added it a couple of weeks ago, didn’t I?

#86

Plugin Delay Compensation, or the optimizations? He was asking about the delay / latency compensation.

#87

The delay stuff was already added yeah. Haven’t used it myself though. Impressive stuff!

#88

Oh, excellent! Sorry for the false alarm…

#89

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.

AudioProcessorGraph PDC and changing latency
#90

The PDC changes mentioned in this thread were implemented… but there are still some PDC issues remaining which I addressed in my thread here

Rail

#91

Good! Let’s move all the further discussion to this new thread then.

#92

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?

1 Like
#93

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.

#94

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

1 Like
#95

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?

#96

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