Ok here we go, it seems the question of how to connect to Pd remotely is infrequently asked, and frequently unanswered, at least according my searches on Google. But I have had some interesting results tonight getting Pd’s GUI to connect over a local network connection to a Pd process on the 5moons.
Here is my setup for this experiment:
- 5moons is connected to my Mac with a USB cable.
- The USB Ethernet gadget (see previous thread mentioned above) is enabled, and my 5moons is addressable to my Mac at IP address 192.168.0.100. I can ssh to the 5moons to run commands at this address.
- I have Pd installed on my Mac. (The current version I have is Pd 0.54-1.)
Steps:
- ssh to the 5moons (
ssh root@192.168.0.100 with pw=organelle) and do the following:
i. Edit /etc/hosts on 5moons (I used vim), so that:
The first line:
127.0.0.1 localhost.localdomain localhost
is
0.0.0.0 localhost.localdomain localhost
(See notes below.)
ii. Stop the default Pd process from running (so that the audio device is available):
killall pd
iii. Now start Pd on 5moons with the following command:
pd -verbose -guicmd dummy /sdcard/pd/main.pd
(Note that the ‘-guicmd dummy’ option is really there literally as ‘dummy’; it’s there to prevent Pd from starting its standard gui process and to wait for a connection instead. The ‘-verbose’ option is used so that Pd will log the port it is listening to on the on the console.)
Here is what it might look like:
root@organelle2:~# pd -verbose -guicmd dummy /sdcard/pd/main.pd
Pd-0.51.4 ("") compiled 11:48:56 Sep 16 2021
float precision = 32 bits
port 54321
whateverWaiting for connection request...
sh: dummy: command not found
Note the ‘port’ number. Here for example it is 54321.
- Ok now on the Mac, I start the gui process as follows:
i. In a terminal window, assuming Pd is installed as /Applications/Pd-0.54-1.app, run:
/Applications/Pd-0.54-1.app/Contents/MacOS/Pd 192.168.0.100:54321
… and at this point what you should get is the Pd gui running on your mac, talking over the network to the Pd process running remotely on 5moons. Note the host IP of the 5moons is used here, and also the port number noted above.
Results:
What I saw working:
- The Pd log window prints messages from the 5moons patch, which would be useful for remote debugging.
- Interacting with objects and controls. The basic Pd patch stuff.
- Saving the current patch (cmd+s).
What didn’t work (not limited to):
- one of the ‘properties’ dialogs (I think for the integer control?). This may come down to the difference in Pd versions between my Mac (0.54) and 5moons (0.51).
- Right-click → Help on objects in the 5moons.
- File dialog boxes (save as, open), obviously, since the gui is running on my mac, those will only see the mac’s filesystem, not the 5moons’ directory tree.
Theory of operation:
When Pd runs, it usually splits itself into two processes. The ‘core’ process which runs a patch, and the GUI that you can interact with (by default a tcl/tk script running in the ‘wish’ runtime executable) . These processes communicate exclusively over a network socket. Normally this network socket is bound to both processes via a random port on ‘localhost’, so all communication is local.
To get this to work, I had to ‘trick’ Pd to open itself up to remote connections. This was done by editing the /etc/hosts file, which translates a host name (i.e. ‘localhost’) to an IP address (i.e. 127.0.0.1). By changing 127.0.0.1 to 0.0.0.0, it means that when Pd opens a socket connection to ‘localhost’ it makes itself available on all network interfaces, rather than just the loopback controller (internal connections).
So while it is waiting for a connection, on the remote computer I started Pd’s special GUI process . It takes a command-line argument pointing to the parent process, i.e. host:port.
Once the connection is made, Pd can talk to its gui, even though it is over a remote network connection.
Finally Note:
Probably, in general, very bad practice to set ‘localhost’ to refer to ‘0.0.0.0’ instead of ‘127.0.0.1’ in /etc/hosts, since in general any process that sets up a socket on localhost would now be open on any network interface on the device, rather than just to internal processes, breaking the assumption behind ‘localhost’. But for me this is just an experiment, so I’m not too concerned 
Ultimately I don’t know how solid this setup is. I’ve only played with it for a few minutes. But I thought I’d report my results.
