Broadcast messages between plugins

Hi Juce folks,

I’m looking into different ways of doing communication between plugin instances. Each plugin should be able to send broadcast messages to all the other instances in order to sync some controls across multiple plugins. Searching the forum I have come across different possibilities, but I’m unsure, which one would be the best way.

MessageManager::broadcastMessage ()
is this reliable? It seems not to be used very often?

InterprocessConnection with Named Pipes
Only point to point communication, no broadcast, right?

Static / Singleton
Some hosts could run plugins in different processes, right?

Shared Memory

Does anyone have some advice, what should be used in my case?


Some hosts could run plugins in different processes, right?

I’d be interested to know if there are hosts where multiple versions of the same plugin would be launched in different processes. I haven’t personally seen this so far, but have haven’t looked hard either.

Anyone know if any common platforms do this?

I believe bitwig does this, might be an option in Reaper too, I think anything running AUv3 plugins will be doing this? i think I’m right in saying that AUv3 is pretty much a stand alone app, I’m sure there are others too. TBH hosts will probably do this more as time goes on as it allows them to prevent crashes in a plugin causing the host to crash.

But is that one process per plugin, or one per instance? Time to load bitwig:)

Hmm that’s a good question, I’m under the impression it’s per instance but it would be nice to know for certain. If I get a chance I might try and run it up to confirm. In the case of AUv3 however if I’m right that the plugin is essentially a stand-alone app then that would presumably have to be per instance.

I’m sure Jules has gone on the record saying that there was an attempt to get Tracktion running plugins sand boxed for the same reasons I’ve outlined above, so maybe he will have some better input regarding this.

thanks for the answers, dose anyone have more input, which approach(es) should be considered?

It’s not plug-in specific but I’ve used zeromq before to communicate between different applications. If the firewall permits it you can communicate over TCP, which might get you out of any sandboxes.

thanks @t0m, is it easy to implement in a cross-plattform environment, such as JUCE?

this has worked for me before:

It’s cross platform, but I’ve only used it on Linux so I can’t really comment about that. The documentation on the website is really good.

I’ve thought before about using OSC which I believe is over TCP so it wouldn’t be dissimilar to using zeromq in that sense I guess? The advantage being that JUCE already has built-in support for OSC.


Used with juce:Time? check every 250 ms, if a changed detected set the timer to a small value, then back to 250ms?

You have a bunch of options, depending on load of message…

DatagramSocket <- this uses UDP broadcasting… msg size is limited to around less than 512 bytes

InterprocessConnection and friends: Very stable, works across iOS and Android too, creating a manager and sending to a bunch of connections is pretty trivial

what we came up after a bunch of experimentation is a combination of the 2. we created a ServerBeacon and ServerLocator classes that use UDP broadcasting and listening, we pick up a tiny message that contains the port and ip address of target server, with that data coming over the udp wire we connect to an intrerprocess connection and go from there.

SharedResourcePointer is better used for things that have to exist only once in all your instances… like a library of parameters or something like it…

hope i helped you a bit

1 Like