Cross Platform Audio Plugin communication (data not audio)


#1

So I have a new idea for a set of plugins I would like to develop which would rely on some sort of communication between then. This doesn’t have to be real time as the data is only analytical.

I did a search and only came up with references to InterProcess classes from 2009 and was wondering is there a good elegant solution that’s platform agnostic (at least win and mac).
Would OSC be a good choice as there would be a host plugin within the Host DAW?


#2

I’ve implemented an analytics plugin that communicates its results to another plugin using juce::InterprocessConnectionServer and juce::InterProcessConnection only yesterday - it works just fine on macOS with Logic Pro X. As far as I can tell from the source, it will work on Windows as well, as it uses sockets internally, which JUCE supports for both OSes.

For my data, OSC would have been an overkill, as I implemented my own, very simple protocol.


#3

Cool that’s good to know. I was thinking of building a socket server and client but was hoping juce had done the work for me. Cheers


#4

If you have any specific questions regarding the usage of juce::InterprocessConnection, feel free to ask :slight_smile:


#5

I used that approach as well (InterProcessConnection), it works great for interactive demands.

However, be aware, that since the connection is done on the message thread, you will likely get problems, if bouncing out relies on being in sync with the communicated data…


#6

That’s fine. I can build in fault tolerance and I can afford to loose packets. I’ve been planning my new product which has a standalone app as host and VST’s in DAW that communicate - data is frequent but small approx. 1 meg a second in an extreme use case. I am going to test IPC over the next couple of days to test viability of the idea and will let know if I have any problems


#7

Trying to do a similar thing. How did you make sure there’s ever only one Server object? Wouldn’t using a SharedResourcePointer be just fine and use that object as the hub for communication between plugin instances? Are you aware of any hosts that run the same plugin in different processes?

Johannes


#8

I’ve solved this by writing my analytics plug-in so it’s able to run as a Server, or send messages to an existing Server, which in turn distributes all its messages to other Clients.

Therefore, whenever a message is to be sent, I execute this code:

		// ensure a sender exists.
		while (!sender && !threadShouldExit()) {
			// first, try to connect to an existing server
			auto client = std::make_unique<Client>(*this);
			if (client->connectToScaleMessageServer(connectionTimeout)) {
				// the client successfully connected to a server.
				sender = std::move(client);
			} else {
				// the client couldn't connect to a server.
				// try to host a server.
				auto server = std::make_unique<ScaleMessageServer>();
				if (server->startListening()) {
					// the server was successfully started.
					sender = std::move(server);
				}
			}
		}

		if (sender) {
			sender->sendScaleMessage(message);
		}

The Client::connectToScaleMessageServer function simply wraps a connectToSocket call to the port that my server always runs on. Similarly, ScaleMessageServer::startListening simply wraps beginWaitingForSocket on the port.

If this is applicable to your architecture, I’d say it’s the simplest and most reliable way to go, and you don’t have to worry that the SharedResourcePointer approach works on any platform/host combination.


#9

All AUv3s

Bitwig

There are others…


#10

With the right settings Reaper can too.