Interprocess communication (JUCE vs ZeroMQ)

I would like to synchronise some control data across multiple plugin instances. After some research i found there are multiple solutions:

Shared Memory (Static / Singleton)
This is the simplest solution and works well for plugin instances within the same process. However, it fails in sandboxed environments or when plugins run in separate processes.

Sockets / Named Pipe
More complex, but this approach allows for communication across processes, making it suitable even in sandboxed or isolated plugin environments.

To support as many hosts as possible and to keep it future proof i think sockets or named pipes are the better option. Now i’m curious to what would be the best solution for implementing this.

There is the JUCE InterprocessConnection class, which looks like it’s an easy solution.

I’ve also watched Peter Sciri’s talk on ADC24, where he explains how they use ZeroMQ.

I’m wondering, what would be the (dis)advantages of using ZeroMQ over JUCE? Also i’m quite new to interprocess communication, would it be better to use sockets or named pipes?

Shared memory using memory mapped files stored in sandbox-friendly locations is the preferred technique. We’ve been discussing this here, btw:

1 Like

Thanks, this looks like exactly what I need!

Do you happen to know how well this performs in terms of latency? My goal is to synchronize plugin parameters with minimal delay, ideally, the receiving plugin should update its parameter within the same processBlock as the one sending the change.

I did some rough measurements for NamedPipe on Windows and saw between 5ms and 100ms latency. So I’d say pipes are a non starter if you need it sync within one block.

Also synchronising plugin parameters is somewhat hard since behaviour varies across plugin formats. Do run some tests in each format before getting too deep into it.