Hi everyone, So I trying to develop what amounts to a new implementation of the Pd GUI. The first step was of course to remove the old GUI, which is actually a lot simpler than I thought. Pd can actually be launched with a -nogui flag, which keeps the gui from opening. Even more excellently, Pd can be launched with the guiport flag, which tells Pd to listen for input from a GUI outputting to the specified socket.
The problem is that I have no idea where to get started on learning how Pd communicates with the GUI. All I know is that messages are sent back and forth over a socket, typically 5400. The source code is fairly impenetrable; what would really be nice is if someone could point me towards what I need to look at to figure out how the Pd-GUI message system works. If there is a guide, or if someone could tell me where to focus my attack on the source code, that would be great.
Thanks very much, Sam
Tarakajian, Samuel wrote:
Hi everyone, So I trying to develop what amounts to a new implementation of the Pd GUI. The first step was of course to remove the old GUI, which is actually a lot simpler than I thought. Pd can actually be launched with a -nogui flag, which keeps the gui from opening. Even more excellently, Pd can be launched with the guiport flag, which tells Pd to listen for input from a GUI outputting to the specified socket.
The problem is that I have no idea where to get started on learning how Pd communicates with the GUI. All I know is that messages are sent back and forth over a socket, typically 5400. The source code is fairly impenetrable; what would really be nice is if someone could point me towards what I need to look at to figure out how the Pd-GUI message system works. If there is a guide, or if someone could tell me where to focus my attack on the source code, that would be great.
it is very stupid, as it basically sends tcl/tk draw commands from pd-core to pd-gui.
personally, i would _not_ go this route if i were you. fortunately there are other options available: - communicate directly with the pd-core via a socket: e.g. using FUDI (vanilla [netsend], [netreceive]) or OSC (mrpeach's [packOSC], [unpackOSC]) wrapped into TCP/IP or UDP.
you can design your own application layer protocol on top of that, which will probably fit your needs better.
OSC would have the added bonus that (in theory) you could use another backend than Pd if you feel like it.
fmgasd.r IOhannes
That's exactly what I was hoping to do: communicate with the Pd core though a socket connection. The real question is how to do that. Setting up the connection is easy, but I have no idea what kind of messages Pd core is expecting. Is there a list somewhere?
-Sam
-----Original Message----- From: IOhannes m zmoelnig [mailto:zmoelnig@iem.at] Sent: Wed 6/4/2008 2:44 AM To: Tarakajian, Samuel Cc: pd-dev@iem.at Subject: Re: [PD-dev] Messaging between Pd and GUI
Tarakajian, Samuel wrote:
Hi everyone, So I trying to develop what amounts to a new implementation of the Pd GUI. The first step was of course to remove the old GUI, which is actually a lot simpler than I thought. Pd can actually be launched with a -nogui flag, which keeps the gui from opening. Even more excellently, Pd can be launched with the guiport flag, which tells Pd to listen for input from a GUI outputting to the specified socket.
The problem is that I have no idea where to get started on learning how Pd communicates with the GUI. All I know is that messages are sent back and forth over a socket, typically 5400. The source code is fairly impenetrable; what would really be nice is if someone could point me towards what I need to look at to figure out how the Pd-GUI message system works. If there is a guide, or if someone could tell me where to focus my attack on the source code, that would be great.
it is very stupid, as it basically sends tcl/tk draw commands from pd-core to pd-gui.
personally, i would _not_ go this route if i were you. fortunately there are other options available: - communicate directly with the pd-core via a socket: e.g. using FUDI (vanilla [netsend], [netreceive]) or OSC (mrpeach's [packOSC], [unpackOSC]) wrapped into TCP/IP or UDP.
you can design your own application layer protocol on top of that, which will probably fit your needs better.
OSC would have the added bonus that (in theory) you could use another backend than Pd if you feel like it.
fmgasd.r IOhannes
Samuel Tarakajian wrote:
That's exactly what I was hoping to do: communicate with the Pd core though a socket connection. The real question is how to do that. Setting up the connection is easy, but I have no idea what kind of messages Pd core is expecting. Is there a list somewhere?
You can look in the source code for calls to sys_vgui().
Also starting pd with -d1 -d2 or -d3 prints the gui messages as they occur (-d1 prints messages from pd to pd-gui, -d2 prints messages from pd-gui to pd, -d3 prints both types).
And pd.tk is where the tcl/tk procs that communicate with pd are found.
Martin
I think what I'm going to do is launch Pd with the -nogui flag and then send messages to the core through the socket connection. From launching pd with the debug flags it seems to me as if pd-gui communicates with the core not by sending actual, meaningful messages (like "obj 0 0 someobject 0") but rather by actually sending all the mouse movement and keystrokes, which I"m assuming the pd-core then uses to figure out what objects to create and so on. I do not want to emulate this; instead I'd like to communicate with the pd-core with the more meaningful messages that can be used to control pd sans gui (like those at the end of g_canvas.c). Does anyone know where I can find a list of all these messages and their input/output? That would be swellcakes.
-Sam
-----Original Message----- From: Martin Peach [mailto:martin.peach@sympatico.ca] Sent: Wed 6/4/2008 12:02 PM To: Tarakajian, Samuel; pd-dev@iem.at Subject: Re: [PD-dev] Messaging between Pd and GUI
Samuel Tarakajian wrote:
That's exactly what I was hoping to do: communicate with the Pd core though a socket connection. The real question is how to do that. Setting up the connection is easy, but I have no idea what kind of messages Pd core is expecting. Is there a list somewhere?
You can look in the source code for calls to sys_vgui().
Also starting pd with -d1 -d2 or -d3 prints the gui messages as they occur (-d1 prints messages from pd to pd-gui, -d2 prints messages from pd-gui to pd, -d3 prints both types).
And pd.tk is where the tcl/tk procs that communicate with pd are found.
Martin
Tarakajian, Samuel wrote:
I think what I'm going to do is launch Pd with the -nogui flag and then send messages to the core through the socket connection. From launching pd with the debug flags it seems to me as if pd-gui communicates with the core not by sending actual, meaningful messages (like "obj 0 0 someobject 0") but rather by actually sending all the mouse movement and keystrokes, which I"m assuming the pd-core then uses to figure out what objects to create and so on. I do not want to emulate this; instead I'd like to communicate with the pd-core with the more meaningful messages that can be used to control pd sans gui (like those at the end of g_canvas.c). Does anyone know where I can find a list of all these messages and their input/output? That would be swellcakes.
i still do not understand why you would want to do such a thing. the communication between pd and pd-gui is really low-level tcl/tk (this is what i meant by "stupid"). why would you want to intercept that? what is wrong with using "meaningful" messages (like "obj 0 0 f 100;") or even higher-level "cue 3, maingain 0.9;" ?
as i have understood it, you are trying to create a specific application with a special gui & you are not trying to hook a different patcher front-end to the pd-core. but as soon as you go into sys_vgui() you are really dealing with the latter.
furthermore, all the sys_vgui will be suppressed when running Pd with "-nogui", so your entire interception idea might be void... (all right, i remember you talking about using the "-guiport" flag, which will help you here).
people have done great things by just using [netsend]/[netreceive] or OSC (e.g. the reacTable* is built that way; it really allows you to dynamically _patch_ using a haptic interface (so it kind of replaces the pd-gui) and still does not go the interception-way you want to use (i guess, because this is so awkward).
finally, from my experience with intercepting the pd/pd-gui connection (done in the "peer data / multipd" project, the connection API keeps changing! so your app might work with Pd-0.40 and not with Pd-0.41; it might work with Pd-extended-0.40, but not with Pd-vanilla-0.40.
fgamsdr IOhannes
Sam, I don't know if you have seen this, but have you heard about Paradiddle? It has been around for sometime, now, and sounds like what you are describing.
http://lindsay.at/work/pd/paradiddle.html
While it is Mac Specific, it could tell you what you need to know about connecting your gui up to Pd.
Mike
On Tue, Jun 3, 2008 at 10:10 PM, Tarakajian, Samuel < Samuel_Tarakajian@brown.edu> wrote:
Hi everyone, So I trying to develop what amounts to a new implementation of the Pd GUI. The first step was of course to remove the old GUI, which is actually a lot simpler than I thought. Pd can actually be launched with a -nogui flag, which keeps the gui from opening. Even more excellently, Pd can be launched with the guiport flag, which tells Pd to listen for input from a GUI outputting to the specified socket.
The problem is that I have no idea where to get started on learning how Pd communicates with the GUI. All I know is that messages are sent back and forth over a socket, typically 5400. The source code is fairly impenetrable; what would really be nice is if someone could point me towards what I need to look at to figure out how the Pd-GUI message system works. If there is a guide, or if someone could tell me where to focus my attack on the source code, that would be great.
Thanks very much, Sam
Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
-
IOhannes m zmoelnig -
Martin Peach -
Mike McGonagle -
Tarakajian, Samuel