Hi Giulio -

This is an interesting idea and I'd like to try to incorporate it. I guess it's adequate fro teh GUI to have an additional menu item that would kill whatever instance it's connected to and connect to a new one (or perhaps start one - I guess this should be a dialog window).

Meanwhile, yes, the open/save-as dialogs are a problem when Pd and the GUI are on different machines!

I'm curious whether it would be possible (or even useful) to make thefile polling step pluggable in Pd so that other solutions (including no-OS ones) could easily be fit into Pd.

cheers Miller

--------------------------- quote ------

In my understanding the remote GUI features has not been given much attention recently, but we are interested in using it for our application on the embedded platform Bela http://bela.io, based on the BeagleBone Black. Currently, our users run their patches using libpd but we want to give them a way to do live patching.

For this reason, we want to run the Pd backend on the BeagleBone Black and the GUI front-end on their computer, taking advantage of the ethernet-over-USB connection between the two.

In our working prototype the user has to manually start the Pd GUI on the computer, giving the port and address used by the BeagleBone.

In order to make this easier out-of-the-box, it should be possible to add a menu entry in the Pd GUI like "attach to running Pd" which would detach (and possibly kill?) the current Pd instance and attach to one on the specified port / interface. Is this a feature that you would be happy to merge back into Pd? Any recommendations?

Another issue with running a remote GUI, is that the GUI shows the filesystem of the computer it is running on, while the backend will try to save on that path in the filesystem it is running on, which is pretty inconvenient. I worked around it with a solution that is good for us but is pretty much platform-specific (see below). A more widely useful way of doing this would involve the Pd backend send the directory listing over to the GUI.

Additional notes on the current status of the project:

The project in its current state is https://github.com/giuliomoro/pure-data/tree/Bela-master Additional changes I already made involve:

- writing a Pd audio backend for Bela

- taking the polling of file descriptors out of the audio thread, as that is a big burden for low-power embedded platforms, and especially bad for us since we are using Xenomai and we aim at low latency. If the fd is ready to be read, I write to a ringbuffer (got it from libpd/utils) which is then read from the audio thread. This is still patchy but works mostly ok. I should add pre-parsing of the GUI messages in the polling thread so that they do not take too much CPU when they are parsed in the audio thread (messages generated by moving the mouse can be pretty CPU intensive ... ).

- load/save when GUI and Pd are on different machines: the BeagleBone automatically exposes and mounts its filesystems to the computer. Exploiting the shared filesystem I allow users to save/load patches from a location on the shared volume by "remapping" in the backend the path passed by the GUI .

- when running a remote GUI, the GUI shows the filesystem of the computer it is running on, while the backend will try to save on that path in the filesystem it is running on, which is pretty inconvenient. The BeagleBone automatically exposes and mounts its filesystems to the computer. Exploiting the shared filesystem I allow users to save/load patches from a location on the shared volume by "remapping" in the backend the path passed by the GUI .

- so now on Bela I can make live patching with an actual (measured) roundtrip latency of 3.7ms (blocksize 64, delay 0).