Hi there, I've already asked this question over at the pdpatchrepo forums but I get the feeling you guys really know your stuff so I wanted to ask here too.
Here's the situation -
Computer 1: a raspberry pi with no screen, keyboard or mouse that automatically runs a headless instance of pure data when it boots up: pd -nogui mypatch.pd
Computer 2: my laptop. I want to start the GUI separetly and connect it to the existing pd instance on the raspberry pi so that I can program the patch, alter it, save it, and watch it in action. I believe the command should be something like: pd-gui HOST:PORT
But I can't seem to make it work and there is no documentation to speak of anywhere. Can anyone help?
I'd be happy to document this on the pd wiki and forums once I figure it out, as there currently seems to be no reference.
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
cheers Miller
On Sat, Sep 10, 2016 at 05:17:45PM +1000, Jeremiah Rose wrote:
Hi there, I've already asked this question over at the pdpatchrepo forums but I get the feeling you guys really know your stuff so I wanted to ask here too.
Here's the situation -
Computer 1: a raspberry pi with no screen, keyboard or mouse that automatically runs a headless instance of pure data when it boots up: pd -nogui mypatch.pd
Computer 2: my laptop. I want to start the GUI separetly and connect it to the existing pd instance on the raspberry pi so that I can program the patch, alter it, save it, and watch it in action. I believe the command should be something like: pd-gui HOST:PORT
But I can't seem to make it work and there is no documentation to speak of anywhere. Can anyone help?
I'd be happy to document this on the pd wiki and forums once I figure it out, as there currently seems to be no reference.
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
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
Hi Miller and IOhannes,
Thanks for the extremely informative replies!
The -guicmd option seems to work but will not meet my needs unfortunately. I'm specifically interested in a way to connect the GUI to an existing running instance of the DSP without interrupting the patch.
IOhannes, I came across your suggestion of using a proxy server in an old Google Groups post from 2010: https://groups.google.com/forum/#!topic/linux.debian.bugs.dist/lKMEPX417h4
By doing the following,
*Terminal 1* $ cd /tmp $ mknod backpipe p $ netcat -l -p 8000 0<backpipe | netcat -l -p 7000 1>backpipe *Terminal 2* $ /usr/bin/pd -guiport 8000 *Terminal 3* $ /usr/lib/pd/bin/pd-gui 7000
I was able to get it working successfully. However, the problem is that until the GUI is started, the DSP does not start running. So the DSP cannot run independently of the GUI (if I start the DSP with -nogui then the -guiport command no longer works).
Do you think it would be difficult to write a patch for PD to create the following behaviour?
*Terminal 1* $ /usr/bin/pd -nogui -guiport 8000 (sound starts playing) *Terminal 2* $ /usr/lib/pd/bin/pd-gui 8000
Regards, Jerry
From: IOhannes m zmölnig zmoelnig@iem.at To: pd-list@lists.iem.at, 20160904152103.GD5414@localhost.localdomain Subject: Re: [PD] connecting pd-gui to pd Message-ID: 4ff4b5f6-084c-912c-1b82-b20729308e9e@iem.at Content-Type: text/plain; charset="utf-8"
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
On 11 September 2016 at 00:23, Miller Puckette msp@ucsd.edu 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
cheers Miller
On Sat, Sep 10, 2016 at 05:17:45PM +1000, Jeremiah Rose wrote:
Hi there, I've already asked this question over at the pdpatchrepo forums but I get the feeling you guys really know your stuff so I wanted to ask here too.
Here's the situation -
Computer 1: a raspberry pi with no screen, keyboard or mouse that automatically runs a headless instance of pure data when it boots up: pd -nogui mypatch.pd
Computer 2: my laptop. I want to start the GUI separetly and connect it
to
the existing pd instance on the raspberry pi so that I can program the patch, alter it, save it, and watch it in action. I believe the command should be something like: pd-gui HOST:PORT
But I can't seem to make it work and there is no documentation to speak
of
anywhere. Can anyone help?
I'd be happy to document this on the pd wiki and forums once I figure it out, as there currently seems to be no reference.
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/
listinfo/pd-list
Do you think it's likely that such a patch would be accepted by the maintainer? On 13/09/2016 5:14 PM, "IOhannes m zmoelnig" zmoelnig@iem.at wrote:
On 2016-09-13 07:40, Jeremiah Rose wrote:
Do you think it would be difficult to write a patch for PD to create the following behaviour?
it's not very difficult. in my last email i listed a number of issues you have to take care of.
gamsdr IOhannes
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/ listinfo/pd-list
On 09/13/2016 09:24 AM, Jeremiah Rose wrote:
Do you think it's liakely that such a patch would be accepted by the maintainer?
which maintainer?
what i'm talking about is a middleware software (a standalone proxy), that handles the connections from both Pd-core and Pd-gui. this is possible. it has already been done (in a different context -"peer data"). back then i implemented the middleware as a Pd-patch. there is no maintainer who could accept anything.
if you are talking about modifying ("patching") the Pd-core so it would allow dis/connections from an independently started Pd-GUI, then I am the wrong person to ask: miller reads this list, so you could ask him directly.
btw, i seem to remember that at miller's last visit to Graz we talked about this very feature and he seemed to be in favour. so i guess, if a patch against Pd-core follows the coding style and is "not very" intrusive, chances are high that it might get included.
gmards IOhannes
Hi Jeremiah,I'm not sure what kind of feature you're describing. Is it that you want a long running Pd instance on the rpi with the ability to connect/disconnect a _single_ GUI at will?
On Tuesday, September 13, 2016 6:46 AM, IOhannes m zmölnig zmoelnig@iem.at wrote:
On 09/13/2016 09:24 AM, Jeremiah Rose wrote:
Do you think it's liakely that such a patch would be accepted by the maintainer?
which maintainer?
what i'm talking about is a middleware software (a standalone proxy), that handles the connections from both Pd-core and Pd-gui. this is possible. it has already been done (in a different context -"peer data"). back then i implemented the middleware as a Pd-patch. there is no maintainer who could accept anything.
if you are talking about modifying ("patching") the Pd-core so it would allow dis/connections from an independently started Pd-GUI, then I am the wrong person to ask: miller reads this list, so you could ask him directly.
btw, i seem to remember that at miller's last visit to Graz we talked about this very feature and he seemed to be in favour. so i guess, if a patch against Pd-core follows the coding style and is "not very" intrusive, chances are high that it might get included.
gmards IOhannes
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
IOhannes, sorry yes I meant "patch" as in a software engineering patch rather than a PD patch. Thanks for the info, I will get in touch with Miller and see if he still thinks it's a good idea.
Jonathan, yes that's exactly it. On 15/09/2016 4:21 AM, "Jonathan Wilkes via Pd-list" pd-list@lists.iem.at wrote:
Hi Jeremiah, I'm not sure what kind of feature you're describing. Is it that you want a long running Pd instance on the rpi with the ability to connect/disconnect a _single_ GUI at will?
On Tuesday, September 13, 2016 6:46 AM, IOhannes m zmölnig < zmoelnig@iem.at> wrote:
On 09/13/2016 09:24 AM, Jeremiah Rose wrote:
Do you think it's liakely that such a patch would be accepted by the maintainer?
which maintainer?
what i'm talking about is a middleware software (a standalone proxy), that handles the connections from both Pd-core and Pd-gui. this is possible. it has already been done (in a different context -"peer data"). back then i implemented the middleware as a Pd-patch. there is no maintainer who could accept anything.
if you are talking about modifying ("patching") the Pd-core so it would allow dis/connections from an independently started Pd-GUI, then I am the wrong person to ask: miller reads this list, so you could ask him directly.
btw, i seem to remember that at miller's last visit to Graz we talked about this very feature and he seemed to be in favour. so i guess, if a patch against Pd-core follows the coding style and is "not very" intrusive, chances are high that it might get included.
gmards
IOhannes
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/ listinfo/pd-list
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/ listinfo/pd-list
I believe libpd already has this capability (I've been using it but am not sure my changes made it upstream). I'm planning to put this in Pd vanilla for the next major release but since I'm on the road till end of December this won't be ready for a while (I have to have access to my doddering old machines at home to test things on various platdoforms to make a release).
In the meantime, try writing an extern that does what libpd does:
int libpd_start_gui(const char *libdir) { t_canvas *x; for (x = pd_getcanvaslist(); x; x = x->gl_next) canvas_vis(x, 0); sys_nogui = 0; if (sys_startgui(libdir)) return -1; for (x = pd_getcanvaslist(); x; x = x->gl_next) if (strcmp(x->gl_name->s_name, "_float_template") && strcmp(x->gl_name->s_name, "_float_array_template") && strcmp(x->gl_name->s_name, "_text_template")) { glist_maybevis(x); canvas_vis(x, 1); } return 0; }
void sys_stopgui( void);
void libpd_stop_gui( void) { t_canvas *x; for (x = pd_getcanvaslist(); x; x = x->gl_next) canvas_vis(x, 0); sys_vgui("%s", "exit\n"); sys_stopgui(); }
cheers Miller
On Thu, Sep 15, 2016 at 08:48:06AM +1000, Jeremiah Rose wrote:
IOhannes, sorry yes I meant "patch" as in a software engineering patch rather than a PD patch. Thanks for the info, I will get in touch with Miller and see if he still thinks it's a good idea.
Jonathan, yes that's exactly it. On 15/09/2016 4:21 AM, "Jonathan Wilkes via Pd-list" pd-list@lists.iem.at wrote:
Hi Jeremiah, I'm not sure what kind of feature you're describing. Is it that you want a long running Pd instance on the rpi with the ability to connect/disconnect a _single_ GUI at will?
On Tuesday, September 13, 2016 6:46 AM, IOhannes m zmölnig < zmoelnig@iem.at> wrote:
On 09/13/2016 09:24 AM, Jeremiah Rose wrote:
Do you think it's liakely that such a patch would be accepted by the maintainer?
which maintainer?
what i'm talking about is a middleware software (a standalone proxy), that handles the connections from both Pd-core and Pd-gui. this is possible. it has already been done (in a different context -"peer data"). back then i implemented the middleware as a Pd-patch. there is no maintainer who could accept anything.
if you are talking about modifying ("patching") the Pd-core so it would allow dis/connections from an independently started Pd-GUI, then I am the wrong person to ask: miller reads this list, so you could ask him directly.
btw, i seem to remember that at miller's last visit to Graz we talked about this very feature and he seemed to be in favour. so i guess, if a patch against Pd-core follows the coding style and is "not very" intrusive, chances are high that it might get included.
gmards
IOhannes
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/ listinfo/pd-list
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/ listinfo/pd-list
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
-
IOhannes m zmoelnig -
IOhannes m zmölnig
-
Jeremiah Rose -
Jonathan Wilkes -
Miller Puckette