Yes, it is easy to get rid of the GUI by sending the messages from pd into Nirvana. The problem is, what we really want is a client server model and a communication model that isnŽt dependent from Tcl/Tk. If I have more than one instance of Pd, IŽd still like to control those instances. So, we need a GUI that makes it possible to control more than one pd, with less communication overhead than we have now ......... a major rewrite of this part, and it would make it possible to add GUIŽs the way we like it (e.d Java)
Guenter
-----Original Message-----
>>>>>>>> From: Mark Danks [mailto:mdanks@Stormfront.com]
Sent: Thursday, December 03, 1998 8:57 AM To: tpt; Guenter Geiger Cc: pd-list@iem.mhsg.ac.at Subject: client server version
All of the talk about a true client/server model, especially without a GUI is something that I'm very interested in. As any one who has tried to do an audio and graphics patch knows, you basically can't run audio Pd and GEM at the same time. In the past, I've gotten around it by using two machines, but it is a real drag.
In theory, I'm getting a dual-processor box in the near future and one thing that I want to do is make it so that it is easy to run two instances of Pd at the same time...and have them talk to each other (probably netsend to start with).
Also, it should be fairly easy to remove the GUI part. You would need to write a new "front end", since pd.exe immediatedly calls pd.dll. Instead of calling sys_main and sys_startgui, you would need to provide the "hooks" for the pd.dll to send the data, but then don't ever do anything with that data. On NT, for instance, sys_startgui connects to wish80 with a pipe and sends the data that way. By rewriting some of the functions in s_inter.c, it would be simple to get rid of the gui...if my ramblings made any sense...