I have been investigating different options for communicating between two JUCE apps - one will be a JUCE Plugin acting as a CLIENT, the other will be a JUCE Application
acting as a SERVER. This is on OSX for the time being. Eventually windows too.
I have a strong feeling that VST and AudioUnit sequencer makers who provide a 64 bit mode and provide a 32 bit “bridge” for older 32 bit plugins have to be doing something similar to this. And i assume they ( Apple with Logic for example ) must be doing it in a manner that doesnt penalise the CPU or add much latency.
Basically i use shared memory to pass audio blocks from server to client, and have been experimenting with different ways to send a COMMAND to the server from the plugin to go and
generate the next audio block. The client plugin will first stuff MIDI into a shared memory area before sending the command.
Given that for sample blok sizes of 64 we’re talking only a window of around 1.5 ms between each audio “fetch”, this means i need a fast and reliable interprocess mechanism.
IPC seems to give very high latencies and is dependent on whats going onGUI wise,
Using a UNIX USER SIGNAL gives low latencies but needs very good thread-safe coding.
I tried using a SIGNAL to wake a regular thread, and let the thread do the processing work - but this was very slow and dependent on the App event loop.
I tried using a timer to do a POLL , which was set to 1ms, which gives lowish latencies that are quite consistent but not as low as SIGNAL.
Is it possible to have timers in JUCE with intervals less than a millisecond ?
Using A pure loop gave good latencies but only if one doesnt yield much CPU time to the OS inside the loop, which wastes CPU.
Does anyone have suggestions as to the best REAL-TIME scheme for this in OSX + JUCE ?
Incidentally this has to be a PULL architecture. A push scheme wont work.
Any thoughts ?