Synchronize multiple plugin instances


Hi All,

I’m trying to build a plugin which needs to be synchronized with all of its instances (i.e., it affects a track’s output depending both on its audio content and on the other tracks audio content).

My current approach is to use a SharedResourcePointer object with waitable events that signal when all instances have finished processing the current window. The heavy load of the audio processing is done on a separate thread (one per instance, per channel), because I understand that it is not a good idea to put a lock or wait inside the audio thread. In fact, when I tried having all the processing inside the audio thread and telling the instance to wait for the other instances to finish inside the processBlock function, I got into a deadlock where the other instances didn’t event start. Could anybody explain this to me? Shouldn’t different instances of a plugin run in different processes or at least, different threads? I’m building an AU and testing in Logic Pro 10.2.1.

Anyways, I decided to spun a thread to do the processing and the waiting, which frees the lock once all the instances are done. However, I’m not very confident on this approach because I’m not sure wether the process is actually finished before the audio thread reads the output. Is there a way to tell the audio thread to wait without locking? I’d highly appreciate recommendations for the architecture of this plugin, I’m a quite new to plugin development with JUCE, and this seems to be a little over my experience.


Wow, that’s a ninja-level threading problem to tackle if you’re new to plugin development… It’s not something where I could offer a one-line piece of magic advice, except that any kind of blocking/waiting is out of the question, you’d need to have some kind of shared FIFO that all the plugins use, and when their process functions are called, they’d have to just take whatever data is ready without waiting.

Not sure how you’d handle situations where the user has multiple different projects open, each containing instances of your plugin, I guess that’s just something that wouldn’t work correctly.

Good luck!


I’m not sure how something like this would work in Final Cut Pro, it launches several threads which it runs the plugin from in order to calculate what the waveform will look like after you adjust any parameters. Then there are hosts which send variable block sizes to improve automation accuracy, I suspect some channels could get different block sizes called at different rates to others, this might also have some strange consequences with what you are trying to do.


Maybe this would help, but not available in many hosts


Thank you for your answers and insights guys!

Another option I had considered was analyzing the tracks beforehand, sort of what melodyne does, so I’ll check that ARA framework to see if that helps.


It won’t help much because not all hosts support ARA based processing. (For example Cubase, Reaper, Ableton Live and Pro Tools are missing it.)