Site navigation

Loading AudioProcessorGraph state from a background thread

General JUCE discussion
#1

Hi,

I’m facing issues when trying to load nodes and connections into an AudioProcessorGraph from a background thread.

Basically what I want to do is this:

- Instantiate an AudioProcessorGraph on the main thread

- Start a Thread in the background

- Add a bunch of nodes within the Thread::run() callback, and update a progress bar on the main thread

- After all the nodes are added, connect them by adding a bunch of connections to the graph in the background thread, while updating the progress bar on the main thread

 

What happens is that every time I add a node or a connection to the graph, the graph triggers an async update to rebuild its ops, which makes impossible to determine when all nodes or connections are done being added.

As a result, I get a crash (bad access) in ConnectionSorter::compareElements when I add the connections from the background thread.

 

What I’d like to have is a way to make the graph stop calling triggerAsyncUpdate() temporarily, add my nodes and connections, and after that call triggerAsyncUpdate() just once.

Unfortunately I don’t see anything I could do without modifications to the AudioProcessorGraph class.

Any thoughts?

#2

JUCE currently does not support the multi-threaded use of the AudioProcessorGraph. However, some other forum users have implented their own processor graphs which seem to work quite well. See this thread for more info.

#3

I think this thread is more about problems using the current (single-core) AudioProcessorGraph in an a threading-context. My (proof-of-concept) AudioProcessorGraph is more about balancing the CPU-load of the nodes over multiple cpu-cores.

 

#4

+1 it would be great to be able to disable AsyncUpdates on the graph

#5

This sounds like a good idea and I can definitely add that. However, doesn’t all the initialisation happen inside the buildRenderingSequence callback anyway. This is where all the prepareToPlay callbacks will happen and this is where most plug-ins load their resources, right?

#6

Yes, you are right, plug-ins get definitely initialised there.
But in this way they would be initialised just once, after all nodes and connections are added to the graph.
It would be really great if you could add a way to disable the async updates temporarily.

#7

OK I’ve added a change on develop so that the graph will not be rebuilt if the AudioProcessingGraph is not prepared, i.e. if prepareToPlay hasn’t been called yet or releaseResources was called. You can then add all your plug-ins after a releaseResources call (or right after constructing the graph). Once the plug-ins have been added, you just need to call prepareToPlay. Does this work for you?

#8

Won’t this break my suggested AudioProcessorGraph PDC changes?

Rail

#9

Yes, thanks, this works for me.
I don’t know if this can affect Rail’s changes though.