client server version

[Guenter Geiger]

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 at Stormfront.com]
> Sent: Thursday, December 03, 1998 8:57 AM
> To: tpt; Guenter Geiger
> Cc: pd-list at 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...
>