[PD-dev] Revamping the remote GUI feature

[Miller Puckette]

Hi Giulio et al -

I've been thinking about this sort of thing for a long time but haven't acted
on it partly because I don't have a good use case in hand -now that Bela is
doing this I'm willing to try to make Pd more friendly for this kind of work.

Certainly the GUI would benefit from having a "connect" menu entry (and then
it should be able to stay alive when there's no Pd instance and offer a 
"restart" (which would open a dialog window offering to restart on the local
machine or connect to a running Pd instance via socket to a choosable host and
port number).  If you want to write such a patch I'd be happy to grab it...

Meanwhile, yep, I've hit the problem with load/save and don't have a general
solution so that might as well stay hacked for now.  I saw youre (related)
arrow patch on sourceforge which I'm gearing up to merge in.

cheers
Miller


On Fri, Jun 02, 2017 at 04:45:01PM +0000, Giulio Moro via Pd-dev wrote:
> 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).
> 
> _______________________________________________
> Pd-dev mailing list
> Pd-dev at lists.iem.at
> https://lists.puredata.info/listinfo/pd-dev