i wanted to take a moment and say that i am highly amazed by the work that can be done with the py extern by Thomas Grill. i just went through the example files in pd and the related python files and i cant believe that the extern works so smoothly with pd.
first off you can dynamically create objects on the pd canvas ! i have not seen this before in pd , maybe i just wasnt looking hard enough ?
secondly , you can create tcl/tk windows to do what ever you can do in tcl/tk , but have it controlled through a pd patch you have made.
thirdly , it seems the py external can be used to create simple externals , and there for circumventing the whole C external paradigm. which to me seems easier for non-programmers to learn python then to learn C [in the context of pd externals].
and last but not least ,, you can create threads !! i havent thought of something i would like to use them for . but i think thats because i never really played with threads in the past . but i am sure some more seasoned programmers can think up thing .
that was a nice advertisement :] but seriously .. thanks for all your work on this external Thomas!!
joge .
Hi Joge, many thanks for your mail! I'm also a bit proud of the py/pyext objects but we have yet to see if they are stable enough for daily work. I have already made some changes that will soon be published concerning crashes with wrong parameters and non-optimal thread behaviour.
A few things to add:
- Objects made from Python scripts are great for experiments, sketching
functionality or really quick-and-dirty stuff for instant use. If you want to do serious work in a real-time domain it won't save you from coding your externals in C, though. I didn't do any tests how the garbage collection influences the response time of the pyext objects.
- Another advertisement: Coding C++ externals with flext is not really more
complicated than the Python scripts and you have comparable possibilites (like transparent threading).
- What concerns tcl/tk: Using the Python Tkinter interface is comfortable
but it isn't the same approach PD uses, therefore there's no synergy with PD. I'm not sure if it's possible but i'd like to use Tkinter with the PD tcl/tk socket approach. In that case you could steer PD GUI objects on the normal canvas with Python scripting. The next major release of flext comes with a GUI part.... let's see what's in it.
- Concerning dynamic object creation: there are quite a few people on the
list who did great stuff with it (take a look at the nqpoly patch!) but the scripting interface still sucks. You need a lot of bad tricks - i hope this is enhanced soon. On the other hand, one could think of a respective Python library that can cope with all those caveats and still expose a neat usable interface.....
- I'm still not too sure whether Python or Ruby is the better choice..... it
seems ruby is more dense and powerful but Python has the clearer syntax and much much more libraries to use. Once, if a have too much time, i'll probably do rb/rbext externals as well....
all the best, Thomas
----- Original Message ----- From: "joge ." joge@goodship.net To: pd-list@iem.kug.ac.at Sent: Saturday, September 07, 2002 9:04 PM Subject: [PD] Py extern : WOW !!
i wanted to take a moment and say that i am highly amazed by the work that can be done with the py extern by Thomas Grill. i just went through the example files in pd and the related python files and i cant believe that the extern works so smoothly with pd.
first off you can dynamically create objects on the pd canvas ! i have
not
seen this before in pd , maybe i just wasnt looking hard enough ?
secondly , you can create tcl/tk windows to do what ever you can do in tcl/tk , but have it controlled through a pd patch you have made.
thirdly , it seems the py external can be used to create simple externals , and there for circumventing the whole C external paradigm. which to me seems easier for non-programmers to learn python then to learn
C
[in the context of pd externals].
and last but not least ,, you can create threads !! i havent thought of something i would like to use them for . but i think thats because i never really played with threads in the past . but i am sure some more seasoned programmers can think up thing .
that was a nice advertisement :] but seriously .. thanks for all your work on this external Thomas!!
joge .
PD-list mailing list PD-list@iem.kug.ac.at http://iem.kug.ac.at/cgi-bin/mailman/listinfo/pd-list
On Sun, 8 Sep 2002, Thomas Grill wrote:
- Objects made from Python scripts are great for experiments, sketching
functionality or really quick-and-dirty stuff for instant use. If you want to do serious work in a real-time domain it won't save you from coding your externals in C, though. I didn't do any tests how the garbage collection influences the response time of the pyext objects.
I don't know, does python 2.2 have full-blown garbage-collection now, or just the patched up ref-counting it had last time i checked? Ruby has mark-and-sweep which is often quite nice, except for the lack of realtimeness. Ruby authors often talk about a multipart mark-and-sweep, which would be much more realtime, but i expect to wait another year.
- I'm still not too sure whether Python or Ruby is the better choice..... it
seems ruby is more dense and powerful but Python has the clearer syntax and
That Python has clearer syntax is an opinion many people don't share.
much much more libraries to use. Once, if a have too much time, i'll probably do rb/rbext externals as well....
Talk to me when you do wish to work on that, because I've already written it. It's not as sophisticated as yours (and is currently right in the middle of a migration from C to C++) but I have one extra feature:
the same Ruby code works in both PureData and jMax.
Mathieu Bouchard http://artengine.ca/matju
Hi Mathieu,
I don't know, does python 2.2 have full-blown garbage-collection now, or just the patched up ref-counting it had last time i checked? Ruby has mark-and-sweep which is often quite nice, except for the lack of realtimeness. Ruby authors often talk about a multipart mark-and-sweep, which would be much more realtime, but i expect to wait another year.
I don't know much about the internals but it's obvious that Python's GC is based on mere reference counting... and to keep track of borrowed and new references is one of the hardest things with Python/C programming.
- I'm still not too sure whether Python or Ruby is the better choice..... it
seems ruby is more dense and powerful but Python has the clearer syntax and much much more libraries to use. Once, if a have too much time, i'll probably do rb/rbext externals as well....
Talk to me when you do wish to work on that, because I've already written it. It's not as sophisticated as yours (and is currently right in the middle of a migration from C to C++) but I have one extra feature: the same Ruby code works in both PureData and jMax.
Yes, i'd like to have o look at your code! Is it all included in GridFlow? I think that most of the py/pyext code should be reusable for a Ruby interface. You know that py/pyext is based on flext. As i won't port flext to jMax in the next future, the rb/rbext wouldn't run there either.... it would run (as py/pyext would) under MaxMSP for Windows and OSX (but not under OS9), though.
greetings, Thomas
On Tue, 10 Sep 2002, Thomas Grill wrote:
Yes, i'd like to have o look at your code! Is it all included in GridFlow?
Yes, 0.6.2, but that is confined to CVS until i fix the bugs. The more I look at some of them, the more I think that there are bugs directly in Ruby and/or PD. However I cannot pinpoint what they are at all, so I'm stuck in pre-0.6.2.
I think that most of the py/pyext code should be reusable for a Ruby interface. You know that py/pyext is based on flext. As i won't port flext to jMax in the next future, the rb/rbext wouldn't run there either.... it would run (as py/pyext would) under MaxMSP for Windows and OSX (but not under OS9), though.
I don't think your Ruby<->PD interface would be compatible with mine, though, because mine is designed after the Ruby<->jMax interface and so has a lot of jMaxisms in it.
matju
-
joge . -
Mathieu Bouchard -
Thomas Grill