On 09/10/2016 04:23 PM, Miller Puckette wrote:
This might help (the subject line is confusing but I think this answers your question too :)
https://lists.puredata.info/pipermail/pd-list/2016-09/116052.html
actually, i think the answer is not entirely correct.
at least i'm pretty confident that it still works the same as it used to back in - hm, hm - 2006 (and later), when we did the "peer data" thing.
what i did back then was: use a proxy that listens to two different tcp/ip ports (say 8001 and 8002; with all messages that are received on one port being forwarded to the other port - in both directions)
start Pd like "pd -guiport 8001" (so it uses the proxy as it's "GUI"). start Pd-gui like "pd-gui pdhost:8002" (so it uses the proxy as it's "DSP" engine).
unfortunately the proxy needs a bit of magic built in, for all that to work properly. what i remember from back then:
- if you want to do some audio-configuration via the menu, the proxy
MUST record a few messages at the beginning of the session (after connection to the DSP), when all the necessary data is sent to the GUI
- the proxy must store all the active window IDs, so when the pd-gui
connects anew, it can tell the DSP to redraw all the windows.
- i *think* the proxy needs to do a bit of handshake when connecting to
the DSP.
- for sanities reasons, it might make sense to disallow Ctrl-Q to
shut-down the DSP
- you might need to handle the watchdog events in the proxy (if running
with "-rt")
i also remember a bit of problems when using Pd-GUI on OSX (and we never tried on W32), but i cannot remember the nature of these problems (and bear in mind that the main objective of that project was to have *multiple* GUIs talk to a single DSP)
mdgfdsa IOhannes