Dear list,
I am trying to remove the Tk gui from pd and use it just as an engine and do the patch editing programatically, i.e. replace the GUI by a (python) program.
Reading through the pd sourcecode it seemed to me that the Tk gui is seperated from the pd core and communication takes place through a socket. Is this right, or am I completely off?
If so, is this the best way to control pd programmatically? And is this protocol documented somewhere? Or where should I look in the sourcecode?
If not, what would be the best way to remove the Tk gui from pd? Again maybe someone can point me at the right place to start digging in the pd sourcecode.
Finally, is there some general document on the pd software architecture / implementation?
Thanks for your time,
regards Jelle
I am trying to remove the Tk gui from pd and use it just as an engine and do the patch editing programatically, i.e. replace the GUI by a (python) program.
Reading through the pd sourcecode it seemed to me that the Tk gui is seperated from the pd core and communication takes place through a socket. Is this right, or am I completely off?
well, if you're just building a user interface for a patch, then just use the -gui command line flag and build your python gui in py/pyext ...
the socket-communication between pd's kernel and the gui is one of the weakest parts of pd ... using a threaded py/pyext, you won't need to use this bottleneck ...
if you think of writing a patch editor, it's more complicated ... but it would also be possible using a pyext object (that's providing the gui) and a dyn~ object (providing the patching environment)...
Finally, is there some general document on the pd software architecture / implementation?
i never counted, but i guess there are about 200 lines of comments in the pd source code :-/
cheers ... tim
Quoting Tim Blechmann (TimBlechmann@gmx.net):
I am trying to remove the Tk gui from pd and use it just as an engine and do the patch editing programatically, i.e. replace the GUI by a (python) program.
Reading through the pd sourcecode it seemed to me that the Tk gui is seperated from the pd core and communication takes place through a socket. Is this right, or am I completely off?
well, if you're just building a user interface for a patch, then just use the -gui command line flag and build your python gui in py/pyext ...
the socket-communication between pd's kernel and the gui is one of the weakest parts of pd ... using a threaded py/pyext, you won't need to use this bottleneck ...
alright.
if you think of writing a patch editor, it's more complicated ... but it would also be possible using a pyext object (that's providing the gui) and a dyn~ object (providing the patching environment)...
yes, that's what I'm looking for. thanks, will look into this.
ps. there's an interesting file on the dyn website, "dyn_py - Python module for py/pyext". no documentation however...
Finally, is there some general document on the pd software architecture / implementation?
i never counted, but i guess there are about 200 lines of comments in the pd source code :-/
that's why I asked :-)
thanks again, Jelle
Hi Jelle,
if you think of writing a patch editor, it's more complicated ... but it would also be possible using a pyext object (that's providing the gui) and a dyn~ object (providing the patching environment)...
yes, that's what I'm looking for. thanks, will look into this.
ps. there's an interesting file on the dyn website, "dyn_py - Python module for py/pyext". no documentation however...
true, but it's just an experimental project in an early stage of development and there are presentation slides and Python scripts serving as some kind of documentation. The problem is the whole thing is built on top of PD and doesn't integrate - therefore it's not efficient at all.
i have stopped this project for now - most of the functionality is integrated into dyn~ anyway.
all the best, Thomas
Hey Thomas and list,
Quoting Thomas Grill (gr@grrrr.org):
if you think of writing a patch editor, it's more complicated ... but it would also be possible using a pyext object (that's providing the gui) and a dyn~ object (providing the patching environment)...
yes, that's what I'm looking for. thanks, will look into this.
ps. there's an interesting file on the dyn website, "dyn_py - Python module for py/pyext". no documentation however...
true, but it's just an experimental project in an early stage of development and there are presentation slides and Python scripts serving as some kind of documentation.
The problem is the whole thing is built on top of PD and doesn't integrate - therefore it's not efficient at all.
i have stopped this project for now - most of the functionality is integrated into dyn~ anyway.
Out of curiousity I just had a look at this document: http://puredata.info/community/projects/convention04/lectures/tk-grill/
This seems to be exactly what I need (with or without Python wrapper). Why is dyn~ better?
Jelle
Out of curiousity I just had a look at this document: http://puredata.info/community/projects/convention04/lectures/tk-grill/
This seems to be exactly what I need (with or without Python wrapper). Why is dyn~ better?
It's not that dyn~ is better, it's just different - it provides an easy way for in-patcher scripting, but for that it internally uses the current m_pd.h API. The dyn API is far more general, it is a proposal for a C interface to replace this current PD API, but at the moment it's not integrated into the PD kernel, therefore needing much more resources than necessary. This is ok for smaller applications but not for larger ones, as a replacement for a patcher system would be. However, you are welcome to use it and i'm happy about any feedback.
best greetings, Thomas
if your goal is simply to control pd from an external GUI while running pd -nogui, it's pretty easy to do using OSC and your favorite language and/or gui toolkit.
i just did this the other day with glade-2, perl, Net::OpenSoundCountrol.
to use sends in pd for this purpose, you can just do something like dumpOCS - symbol2list - route to drop the "/", pack, [; $1 $2{
On Fri, 2005-09-09 at 19:05 +0200, Thomas Grill wrote:
Out of curiousity I just had a look at this document: http://puredata.info/community/projects/convention04/lectures/tk-grill/
This seems to be exactly what I need (with or without Python wrapper). Why is dyn~ better?
It's not that dyn~ is better, it's just different - it provides an easy way for in-patcher scripting, but for that it internally uses the current m_pd.h API. The dyn API is far more general, it is a proposal for a C interface to replace this current PD API, but at the moment it's not integrated into the PD kernel, therefore needing much more resources than necessary. This is ok for smaller applications but not for larger ones, as a replacement for a patcher system would be. However, you are welcome to use it and i'm happy about any feedback.
best greetings, Thomas
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
On Fri, 9 Sep 2005, Jelle Herold wrote:
Out of curiousity I just had a look at this document: http://puredata.info/community/projects/convention04/lectures/tk-grill/
Btw there is also:
http://puredata.info/community/projects/convention04/lectures/tk-bouchard/Im...
Mathieu Bouchard - tél:+1.514.383.3801 - http://artengine.ca/matju Freelance Digital Arts Engineer, Montréal QC Canada
On Fri, 9 Sep 2005, Jelle Herold wrote:
I am trying to remove the Tk gui from pd and use it just as an engine and do the patch editing programatically, i.e. replace the GUI by a (python) program.
Join the DesireData project! (formerly known as ImpureData)
We are trying to do that client-server separation and model-view separation, with the view being in the client and the model being in the server, using a system that automatically copies attributes from model to view through an observer-observable relationship.
Even though our new GUI is still based around Tcl/Tk, we are decoupling the client and the server, which will cause the protocol to become slimmer and much more data-oriented than appearance-oriented.
Reading through the pd sourcecode it seemed to me that the Tk gui is seperated from the pd core and communication takes place through a socket. Is this right, or am I completely off?
in regular pd, almost all of the view code lies in the server, which ends up micromanaging the client, doing essentially all the job of the client. It's not that much better than having Tcl/Tk being hosted inside of Pd itself.
If so, is this the best way to control pd programmatically? And is this protocol documented somewhere?
The client-to-server protocol is like [netsend]/[netreceive].
The server-to-client protocol is Tcl code.
This is not changing in DesireData, but the actual content of the transmissions does change: e.g. in the latter, the server does not send any Tk-specific commands, and barely even uses Tcl commands.
I also have a plan of modifying the syntax of Pd slightly so that it looks more like Tcl. It will make it much more powerful yet about as easy to parse. This isn't really creating a dependency on Tcl because Tcl is among the easiest languages to parse. Examples of easy-to-parse languages are:
Lisp and Scheme and Tcl (nested list syntax).
Forth and PostScript (stack-oriented syntax, alias "RPN"),
Smalltalk and Self (object-oriented subject-verb-complements).
MAX and PureData (but it's missing nested lists! what???).
What I want is PureData syntax minus the current behaviour of backslash plus those constructs from Tcl: doublequotes, braces, backslash. There will still be some major differences between Tcl and the new Pd format, the biggest being that Pd distinguishes between float and symbol at the lexical analysis level (and in the spirit of that, the new syntax will also make string and nested-list distinct atom types at the lexical analysis level too).
It should be easy to write (in most any language) a recursive-descent parser for Tcl and/or the new Pd syntax, in less than 100 lines of code (unless you like to put a lot of whitespace in your code).
Or where should I look in the sourcecode?
Download it using CVS : http://sourceforge.net/cvs/?group_id=55736
You should insert "-r devel_0_39" without the quotes, just after the "checkout" keyword.
That will be a few hours behind the actual up-to-date devel_0_39. If you want that one, you will have to register for a developer's account at sourceforge.net.
If you want upload permissions you need both the account and to ask for a developer account on pd-dev. It's highly recommended that you subscribe to pd-dev : http://lists.puredata.info/listinfo/pd-dev
In devel_0_39, you have the code of both the regular Pd GUI and the DesireData GUI. You can select the one you want using "scons desire=yes install" (to get back to the regular GUI, use "scons desire=no install"). You should have the SCons compilation management software installed, as well as the GCC compiler (just the C part, no need for the C++ part). You will _not_ need "Make" nor AutoConf nor AutoMake for that.
To start DesireData, do not run "pd". Instead run "wish desire.tk" from the "pd/src" directory. You should have realtime disabled by using -nrt in ~/.pdrc because desire.tk doesn't have a watchdog yet. If you don't have the GDB debugger you will have to write "wish desire.tk -nogdb" instead. I recommend compiling with "debug=yes wall=yes".
Currently, DesireData is not usable at all, but most of the required code is already there, so progress will be quick, as it's mostly a matter of putting things together.
If not, what would be the best way to remove the Tk gui from pd? Again maybe someone can point me at the right place to start digging in the pd sourcecode.
Join our team: Mathieu Bouchard (matju) Chun Lee (chun) Carmen Rocco (changes nickname every week or so)
We mostly meet on IRC on the #dataflow channel of the irc.freenode.net network.
The project originally ran February-May 2004 as a separate branch "-r impd_0_37". Chun Lee and I restarted it last month with a new name. In the meanwhile Carmen has made experiments using Toxy and TkZinc and such.
Finally, is there some general document on the pd software architecture / implementation?
no.
PS: Those who find the name desiredata cheesy should reverse the "red"
part in order to get a nice word in latin. (it is also in English
dictionaries such as m-w.com)
Mathieu Bouchard - tél:+1.514.383.3801 - http://artengine.ca/matju Freelance Digital Arts Engineer, Montréal QC Canada
What I want is PureData syntax minus the current behaviour of backslash plus those constructs from Tcl: doublequotes, braces, backslash. There will still be some major differences between Tcl and the new Pd format, the biggest being that Pd distinguishes between float and symbol at the lexical analysis level (and in the spirit of that, the new syntax will also make string and nested-list distinct atom types at the lexical analysis level too).
well, i'm not a big fan of extending the pd syntax!
this would result an incompatibility from one pd interpreter to another one... although i like the idea of having an extended dataflow syntax (nested lists, exact numeric data types) compatibility should be a major concern.
this would be another project and it would be much cleaner to reimplement a whole dataflow language from scratch, rather than using the pd codebase for that... it's just not suited for that ... ... maybe a topic for my bachelor thesis, once i started to study again ...
cheers ... tim
On Tue, 13 Sep 2005, Tim Blechmann wrote:
well, i'm not a big fan of extending the pd syntax!
Plain extending of syntax is just the same as extending the behaviour of anything else in Pd.
this would result an incompatibility from one pd interpreter to another one...
I'm talking about 99% backwards compatibility, the difference being mostly that all doublequotes will have to be backslashed in order to keep their old meaning.
reimplement a whole dataflow language from scratch, rather than using the pd codebase for that... it's just not suited for that ... ... maybe a topic for my bachelor thesis, once i started to study again ...
I'll convince you otherwise.
Mathieu Bouchard - tél:+1.514.383.3801 - http://artengine.ca/matju Freelance Digital Arts Engineer, Montréal QC Canada
-
Jelle Herold -
Mathieu Bouchard -
shift8 -
Thomas Grill -
Tim Blechmann