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
signature.asc
Description: OpenPGP digital signature
_______________________________________________ [email protected] mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
