Hi,
I gave some serious thought to the scripting thing last night. I am thinking of building a "python" external that would allow simple scripts - you would make make an object:
py scriptname
which would take a python class that is similar in structure to the external "class" structure used by externals currently - obviously a bit more simple. No DSP of course (can't imagine it would be vaguely fast enough). Python is a good fit with PD I belive - it does good list type manipulation (in fact it will be easy to write a set of list manipulation externals which I have been wanting for a while now) and its got some quite nifty features. Oh and I want to learn it which strikes me as a good a reason as any ;-)
So - does anyone have any requests for features or things I should be considering?
cheers
mark
I gave some serious thought to the scripting thing last night. I am thinking of building a "python" external that would allow simple scripts - you would make make an object:
py scriptname
which would take a python class that is similar in structure to the external "class" structure used by externals currently - obviously a bit more simple. No DSP of course (can't imagine it would be vaguely fast enough). Python is a good fit with PD I belive - it does good list type manipulation (in fact it will be easy to write a set of list manipulation externals which I have been wanting for a while now) and its got some quite nifty features. Oh and I want to learn it which strikes me as a good a reason as any ;-)
So - does anyone have any requests for features or things I should be considering?
Hi Mark, please do it!
What concerns dsp and existing pd objects i thought that it would be desirable in the future to be able to use this (with a fairly complex glue layer and some restrictions for the usable objects, of course) inside the python code as well. Maybe, pd classes could thus be mangled into python classes and used within the script. Naturally, this would impose a lot of design and coding work (if it is possible after all...)
greetings, Thomas
What concerns dsp and existing pd objects i thought that it would be desirable in the future to be able to use this (with a fairly complex glue layer and some restrictions for the usable objects, of course) inside the python code as well. Maybe, pd classes could thus be mangled into python classes and used within the script. Naturally, this would impose a lot of design and coding work (if it is possible after all...)
greetings, Thomas
Just 2$ from my own limited experience so far,
What I with my experimental scheme extern, is that I do not yet miss these features (the lack of DSP objects and the lack of the ability to embed existing PD objects into the script).
Of course it all depends on your goals. In my case, I was simply looking for a method to ease the rats-nest of interconnections, and be able to quickly come up with "one-off" (i.e. composition specific) objects that help with this. In other words my purpose was more to give me a conventional/linear framework for building constructs to simplify my patches, rather than something more complete. In other words, for probably 10% of the effort that would be needed for the full solution, It doesn't bother me that I have to interconnect my scheme object to seperate DSP boxes to do what I need.
But I don't mean to say that what you are proposing wouldn't be great indeed!
Larry
Having done a fair amount of investigation today (whilst at work - oops!) I reckon that first off the scripting thing will simply allow you to write PD (non DSP) externals in python. After that I will look into how much more of the PD internals you can expose. This is still a fair amount of work to make user friendly and useable - however it will allow you to create fairly interesting control objects pretty much on the fly for a patch.
cheers
mark
-----Original Message----- From: root@bestweb.net [mailto:root@bestweb.net]On Behalf Of Larry Troxler Sent: 26 February 2002 00:18 To: Thomas Grill Cc: Pd-List; mark@junklight.com Subject: Re: AW: [PD] Scripting
What concerns dsp and existing pd objects i thought that it would be desirable in the future to be able to use this (with a fairly complex glue layer and some restrictions for the usable objects, of course) inside the python code as well. Maybe, pd classes could thus be mangled into python classes and used within the script. Naturally, this would impose a lot of design and coding work (if it is possible after all...)
greetings, Thomas
Just 2$ from my own limited experience so far,
What I with my experimental scheme extern, is that I do not yet miss these features (the lack of DSP objects and the lack of the ability to embed existing PD objects into the script).
Of course it all depends on your goals. In my case, I was simply looking for a method to ease the rats-nest of interconnections, and be able to quickly come up with "one-off" (i.e. composition specific) objects that help with this. In other words my purpose was more to give me a conventional/linear framework for building constructs to simplify my patches, rather than something more complete. In other words, for probably 10% of the effort that would be needed for the full solution, It doesn't bother me that I have to interconnect my scheme object to seperate DSP boxes to do what I need.
But I don't mean to say that what you are proposing wouldn't be great indeed!
Larry
mark hat gesagt: // mark wrote:
I gave some serious thought to the scripting thing last night. I am thinking of building a "python" external that would allow simple scripts - you would make make an object:
py scriptname
which would take a python class that is similar in structure to the external "class" structure used by externals currently - obviously a bit more simple. No DSP of course (can't imagine it would be vaguely fast enough). Python is a good fit with PD I belive - it does good list type manipulation (in fact it will be easy to write a set of list manipulation externals which I have been wanting for a while now) and its got some quite nifty features. Oh and I want to learn it which strikes me as a good a reason as any ;-)
I like the idea very much. Larry Troxler started something similar with his PD-Scheme external, maybe you can get some inspiration here (http://www.westnet.com/~lt/pd/). Python is not that far away from Scheme in some regards. I would probably prefer Python as a scripting language, as I know this a lot better than I know Scheme. I know Perl even better, but I am always happy *not* having to write in Perl anymore ;)
bye,
__ __
Frank Barknecht ____ ______ ____ __ trip\ \ / /wire ______
/ __// __ /__/ __// // __ \ / / __ \ ___\
/ / / ____/ / / / // ____// /\ \ ___\____ \
/_/ /_____/ /_/ /_//_____// / \ \_____\_____
/_/ _\
On Mon, 25 Feb 2002, Frank Barknecht wrote:
I like the idea very much. Larry Troxler started something similar with his PD-Scheme external, maybe you can get some inspiration here (http://www.westnet.com/~lt/pd/). Python is not that far away from Scheme in some regards. I would probably prefer Python as a scripting language, as I know this a lot better than I know Scheme. I know Perl even better, but I am always happy *not* having to write in Perl anymore ;)
Hi, actually the main reason that I picked scheme was simply because the SIOD library was very easy to integrate.
I've been thinking lately about learning Python...
Larry
tcl might not work for a lot of needs, but how difficult would it be to have a tcl scripting external? Allows some quite complex operations, fast array searches and of course easy GUI creation. I currently have a tcl script that writes an array of 100+ gem objects, it would be neat to have this script exist inside a "script" object.
whats the advantage of python of tcl? since the interpreter is already there...
Ben
On Mon, 25 Feb 2002, mark wrote:
Hi,
I gave some serious thought to the scripting thing last night. I am thinking of building a "python" external that would allow simple scripts - you would make make an object:
py scriptname
which would take a python class that is similar in structure to the external "class" structure used by externals currently - obviously a bit more simple. No DSP of course (can't imagine it would be vaguely fast enough). Python is a good fit with PD I belive - it does good list type manipulation (in fact it will be easy to write a set of list manipulation externals which I have been wanting for a while now) and its got some quite nifty features. Oh and I want to learn it which strikes me as a good a reason as any ;-)
So - does anyone have any requests for features or things I should be considering?
cheers
mark
B. Bogart
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
hi
i had a python external written for an installation i did two years ago. the reason i never published it was that the author does not maintain the package, and i had lost the source (...). but just last night i found it on my old notebook - back from 'service' after more than one year, now completely broken but for the harddrive, to hell with gericom! anyway, it works fine, the python thingy, that is... (had it running in an installation for 6 consecutive months), is not complete (not all pd types are supported), restricted to python1.5 and since the interpreter runs inside pd it can block. let me know if you're interested. i can send you the code or post a link here.
and just to wet your appetites: there's a corba external coming up.
lu
On Mon, 25 Feb 2002, mark wrote:
::Hi, :: ::I gave some serious thought to the scripting thing last night. I am thinking ::of building a "python" external that would allow simple scripts - you ::would make make an object: :: :: py scriptname :: ::which would take a python class that is similar in structure to the external ::"class" structure used by externals currently - obviously a bit more simple. ::No DSP of course (can't imagine it would be vaguely fast enough). Python ::is a good fit with PD I belive - it does good list type manipulation (in ::fact ::it will be easy to write a set of list manipulation externals which I have ::been ::wanting for a while now) and its got some quite nifty features. Oh and I ::want ::to learn it which strikes me as a good a reason as any ;-) :: ::So - does anyone have any requests for features or things I should be ::considering? :: ::cheers :: ::mark :: ::
On Mon, 25 Feb 2002, mark wrote:
it will be easy to write a set of list manipulation externals which I have been wanting for a while now) and its got some quite nifty features. Oh and I want to learn it which strikes me as a good a reason as any ;-)
So - does anyone have any requests for features or things I should be considering?
Are you considering something like Peter Elsea's 'L' objects? It would be ~great~ to have fuzzy logic operators in PD!
DC
david casal --0+
d.casal@uea.ac.uk --9+
www.ariada.uea.ac.uk/~dcasal --)+
-
Ben Bogart - FMPM/F1999 -
david casal -
Frank Barknecht -
Larry Troxler -
ludwig zeininger -
mark -
Thomas Grill