The idea is to let the pd patches run without gui but only sometimes attaching to them, looking whether they are alright or not.
Fortunately puredata design is already split in server and GUI client so it isn't too much effort to achieve this. The main problem is to provide the old status to the new client. It is actually solved by replaying all server messages, after they are grepped out of unneccessary repetions and already deleted objects.
If you don't want to perform all the steps below, you also can download session5q and use it as input for Part E (steps 15.-19.).
Follow Part A, Part B, Part C, Part D, Part E. D+E is the reconnect cycle, so this can be repeated often (more or less).
WARNING 1 - The method is very error prone and I wasn't able to make a error free run. Don't rely on pd-reconnect!
WARNING 2 - The script sortout.sh uses the hard disk as database. For productive use, I recommend to mount a ramdisk!
WARNING 3 - I didn't test this on distributed systems and on the long run. There are lots of details to be solved.
WARNING 4 - Every tiny mouse move will be transmitted over the network - this
means lot's of traffic.
WARNING 5 - After the GUI signalls "Quit" to server, the server closes the
connection. This connection close makes the GUI vanish, so it has to be
emulated. (Btw. I can confirm that this TODO still makes sense, it could be extended to no sending mouse pointer moves over the network: [http://puredata.info/Members/zmoelnig/todo/pd-gui/?searchterm=gui])
GOOD NEWS 1 - No need for recompilation
GOOD NEWS 2 - pd seems to be pretty relaxed concerning timeouts. The only thing where a small bidirections connection delay is needed seems to be
mousedown-move-mouseup operations (moving around objects). Also changing the
number of Number2 objects has no timeout, but relies on some "ping"
mechanism.
1 Folgende Dateien herunterladen: sortout.sh
restore.sh allowed.tgz
2. allowed.tgz entpacken
3. Start pd (nogui server) with $ pd -guicmd true
4. Find out which port the server is using (tip: netstat -lp | head or you assume default port 5400 for first pd instance)
5. Start server pty with cd; socat TCP4:localhost:5400 PTY,link=TMP2,rawer
6. Remove history with rm -r X/mem
7. Start client pty with cd; socat TCP4-LISTEN:5555 PTY,link=TMP,rawer
8. Start GUI with pd-gui localhost:5555
9. Connect data direction client->server with cat ~/TMP | tee ~/TMP2
10. Connect data direction server->client with cat ~/TMP2 | tee ~/TMP | tee /dev/stderr | ./sortout.sh
11. The main/log window opens. Here you can choose the file you want to load or invent a new unsaved patch.
12. Go to pd-gui terminal and press Ctrl-C or kill it any other way. (Do NOT close any windows and do NOT close pd with Ctrl-Q)
13. Go to both cat terminals and press Ctrl-C there.
14. Save the output with ./restore.sh > sessionA
15. Restart cd; socat TCP4-LISTEN:5555 PTY,link=TMP,rawer
16. Restart pd-gui localhost:5555
17. (Maybe) watch pd-gui with cat ~/TMP
18. Infuse the saved state with cat sessionA > ~/TMP
19. Like a miracle the pd-gui opens with the right windows. (Remark: you will
not see the startup warn/error messages as usual)
20. Do NOT click in those windows, do NOT try to alter anything - the GUI isn't connected!
21. Connect client->server with cat ~/TMP | tee ~/TMP2 (before that kill cat ~/TMP from step 17.)
22. Connect server->client with cat ~/TMP2 | tee ~/TMP | tee /dev/stderr | ./sortout.sh
23. If patches don't look good, minimize+restore the patch windows now.
24. Now the patches can be altered like always. The actual operation never stopped.
You may want to choose another name for the session, maybe sessionA+ this time.
Use the new session file (probably sessionA+)
(Note that the log window and the patch window don't come from the same run, they come from different sessions.)
It should look like:
(You can correct that with minimize+restore after connecting to server in some cases.)
