I was just in Zürich working with Jasch, a long time Max user. He's swaying more and more the Pd way, and write now is starting to port his libs to Pd. For example, he's porting an easy-to-use ambisonic lib, a complete implementation of string.h as a lib, a boids lib, an XML parser, and more tasty bits.
So I propose to add him as a developer, he'll post his intro to this thread, then I'll add him after a week, if there are not objections.
.hc
________________________________________________________________________ ____
"Information wants to be free." -Stewart Brand
Am 08.05.2006 um 15:02 schrieb Hans-Christoph Steiner:
I was just in Zürich working with Jasch, a long time Max user. He's swaying more and more the Pd way, and write now is starting to port his libs to Pd. For example, he's porting an easy-to-use ambisonic lib, a complete implementation of string.h as a lib, a boids lib, an XML parser, and more tasty bits.
So I propose to add him as a developer, he'll post his intro to this thread, then I'll add him after a week, if there are not objections.
Not at all... these are interesting - if not suprising - news.. hi Jasch, already lurking? best greetings, Thomas
Thomas Grill http://grrrr.org
boids please!
It was sitting on my todo for ages, and I've never gotten around to it.
:)
.b.
Thomas Grill wrote:
Am 08.05.2006 um 15:02 schrieb Hans-Christoph Steiner:
I was just in Zürich working with Jasch, a long time Max user. He's swaying more and more the Pd way, and write now is starting to port his libs to Pd. For example, he's porting an easy-to-use ambisonic lib, a complete implementation of string.h as a lib, a boids lib, an XML parser, and more tasty bits.
So I propose to add him as a developer, he'll post his intro to this thread, then I'll add him after a week, if there are not objections.
Not at all... these are interesting - if not suprising - news.. hi Jasch, already lurking? best greetings, Thomas
Thomas Grill http://grrrr.org
PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
lurking indeed,
having just spent a very inspiring week in the company of hans, i have started building up my external porting-muscles (they are somewhere in the lower back, no?) ;)
let me introduce myself:
i'm a trained jazz doublebass-player and composer, but have mutated into a media-artist in the last few years. i hold a masters in digital arts from pompeu fabra university in barcelona (hi günther) and am currently employed at the institute for computer music and sound technology of the zurich school for music, drama and dance (soon to be part of the zurich art academy zhdk).
i've been using Max/MSP since 1997 and have followed the evolution of PD from the sidelines for almost the same time. my artistic work nowadays consists mainly in playing a live audiovisual piece called "codespace" and collaborating/creating installations involving realtime abstract graphics and surround sound. this is also where my main interest in using PD lies: as a tool for running long-term installations on the linux platform. my experience with code has been mainly with max-externals and i offer a collection of over a hundred objects for free download. i'm now interested in porting most of these objects to PD, on the one hand for selfish reasons: to have my tools available for my own work, but also with the idea of sharing them the same way than i do in Max/ MSP. in addition some of the projects at my workplace might also include writing code for PD. i have already convinced them to let us publish code such as the ambisonic-tools under the GPL (see http:// www.icst.net). so if i get accepted into the dev-circles, i hope to be contributing a fair bit of code if not also other support to the PD community.
to learn more about me visit my website http://www.jasch.ch
thank you for your attention...
/*j
boids please!
It was sitting on my todo for ages, and I've never gotten around to it.
:)
.b.
I was just in Zürich working with Jasch, a long time Max user. He's swaying more and more the Pd way, and write now is starting to port his libs to Pd. For example, he's porting an easy-to-use ambisonic lib, a complete implementation of string.h as a lib, a boids lib, an XML parser, and more tasty bits.
So I propose to add him as a developer, he'll post his intro to this thread, then I'll add him after a week, if there are not objections.
Not at all... these are interesting - if not suprising - news.. hi Jasch, already lurking?
On Wed, 10 May 2006, /*j wrote:
my experience with code has been mainly with max-externals and i offer a collection of over a hundred objects for free download.
That's a quite impressive list. How many of them are abstractions and how many are written in C ?
BTW I'm curious about what you use [xorlist] for...
i'm now interested in porting most of these objects to PD, on the one hand for selfish reasons: to have my tools available for my own work, but also with the idea of sharing them the same way than i do in Max/MSP.
Most of those should be really easy to port if they are written in C: you mostly have to just search-and-replace some struct names.
Abstractions are a little bit harder because I don't know of a MAX->Pd file converter (does Krzysztof know?).
Some of the externals will be harder because they use functions that are outside the intersection between MAX and Pd APIs. (By intersection I mean things that don't have a direct equivalent so that you can't port it by a dumb search-and-replace)
You will have to be careful about nameclashes. You may also find that several of your externals already have an equivalent under another name in Pd.
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801 - http://artengine.ca/matju | Freelance Digital Arts Engineer, Montréal QC Canada
Hallo, Mathieu Bouchard hat gesagt: // Mathieu Bouchard wrote:
Abstractions are a little bit harder because I don't know of a MAX->Pd file converter (does Krzysztof know?).
You can use Cyclone to load Max patches quite well. I used this to port some patches of Essl's RTC-lib (http://www.essl.at/works/rtc.html) to Pd. I'd like to port all, but didn't find the time yet. Or maybe someone already did it?
Just create a [cyclone] object, click on it and load a Max patch. Non-existing objects will be replaced by dummy substitutes with correct inlet/outlet count. In RTC-lib most of these can be emulated using abstractions or replaced by objects that have a different name in Pd, but otherwise work similar. It works very well for patches that only use objects where you can guess or look up the functionality. Of course with Jitter stuff this is a bit harder, or maybe not with GridFlow objects?
Ciao
On Wed, 10 May 2006, Mathieu Bouchard wrote:
On Wed, 10 May 2006, /*j wrote:
my experience with code has been mainly with max-externals and i offer a collection of over a hundred objects for free download.
That's a quite impressive list. How many of them are abstractions and how many are written in C ?
BTW I'm curious about what you use [xorlist] for...
i'm now interested in porting most of these objects to PD, on the one hand for selfish reasons: to have my tools available for my own work, but also with the idea of sharing them the same way than i do in Max/MSP.
Most of those should be really easy to port if they are written in C: you mostly have to just search-and-replace some struct names.
Anyone have a colection of these search-and-replace patterns? It would be good to start a script in scripts/ that does all these. Ultimately it should be possible to script most if not all of the process.
Abstractions are a little bit harder because I don't know of a MAX->Pd file converter (does Krzysztof know?).
This could also be a script.
Some of the externals will be harder because they use functions that are outside the intersection between MAX and Pd APIs. (By intersection I mean things that don't have a direct equivalent so that you can't port it by a dumb search-and-replace)
You will have to be careful about nameclashes. You may also find that several of your externals already have an equivalent under another name in Pd.
Nameclashes aren't such an issue with namespaces/Pd-extended. But yes, its good to avoid needless nameclashes.
.hc
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801 - http://artengine.ca/matju | Freelance Digital Arts Engineer, Montréal QC Canada
PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
zen \ \ \[D[D[D[D
Hans-Christoph Steiner wrote:
On Wed, 10 May 2006, Mathieu Bouchard wrote:
You will have to be careful about nameclashes. You may also find that several of your externals already have an equivalent under another name in Pd.
Nameclashes aren't such an issue with namespaces/Pd-extended. But yes,
i think matju did not mean _these_ nameclashes (correct me if i'm wrong), but rather _those_ where a max object and a pd object share the name but not the functionality. which would give you a false sense of security of a successfull patch-conversion.
its good to avoid needless nameclashes.
it's also good to avoid necessary nameclashes.
mfg.vser. IOhannes
On May 11, 2006, at 8:19 AM, IOhannes m zmoelnig wrote:
Hans-Christoph Steiner wrote:
On Wed, 10 May 2006, Mathieu Bouchard wrote:
You will have to be careful about nameclashes. You may also find that several of your externals already have an equivalent under another name in Pd.
Nameclashes aren't such an issue with namespaces/Pd-extended. But yes,
i think matju did not mean _these_ nameclashes (correct me if i'm wrong), but rather _those_ where a max object and a pd object share the name but not the functionality. which would give you a false sense of security of a successfull patch-conversion.
That's what cyclone is for. Objects from any other library should not be assumed to be Max compatible, as a rule. There are already plenty of duplicated max object names with differing functionality, including in the core, so it doesn't seem so useful to start worrying about that now.
.hc
its good to avoid needless nameclashes.
it's also good to avoid necessary nameclashes.
mfg.vser. IOhannes
PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
________________________________________________________________________ ____
¡El pueblo unido jamás será vencido!
On 10 May 2006, at 19:12, Mathieu Bouchard wrote:
On Wed, 10 May 2006, /*j wrote:
my experience with code has been mainly with max-externals and i offer a collection of over a hundred objects for free download.
That's a quite impressive list. How many of them are abstractions and how many are written in C ?
all of them are full blown C-objects.
BTW I'm curious about what you use [xorlist] for...
i used it to code the BCC in DIN66019II protocol whcih was used to control electrical motors on a theater set... see www.incidentsmemorables.org -> la pensee
i'm now interested in porting most of these objects to PD, on the one hand for selfish reasons: to have my tools available for my own work, but also with the idea of sharing them the same way than i do in Max/MSP.
Most of those should be really easy to port if they are written in C: you mostly have to just search-and-replace some struct names.
not quite... as i found out there are some more differences, the missing int being the most prominent, and the vector alisasing being the most annoying.
Abstractions are a little bit harder because I don't know of a MAX->Pd file converter (does Krzysztof know?).
Some of the externals will be harder because they use functions that are outside the intersection between MAX and Pd APIs. (By intersection I mean DIN things that don't have a direct equivalent so that you can't port it by a dumb search-and-replace)
exactly, some externals won't be portable because they use Max specific APIs and/or patcherstructures.
You will have to be careful about nameclashes. You may also find that several of your externals already have an equivalent under another name in Pd.
well, if you look at the list of names on my website you'll see that i avoid any max-names and try to come up with unique stuff, but i can always add a prefix or something. the worst offender is probably the string-lib with names like strcat (present in GEM i think), but it would be stupid to change these names because they correspond exactly to the c-function they enclose.
when in doubt i'll consult you people.
/*j
hi jasch,
On Fri, 2006-05-12 at 10:34 +0200, /*j wrote:
Most of those should be really easy to port if they are written in C: you mostly have to just search-and-replace some struct names.
not quite... as i found out there are some more differences, the missing int being the most prominent, and the vector alisasing being the most annoying.
if you'd consider to port your objects to flext, they would run both on max and on pd ... possibly some more work than just porting max externals to pd, but i guess it's easier to maintain only one external instead of two ...
cheers ... tim
-- TimBlechmann@gmx.de ICQ: 96771783 http://www.mokabar.tk
The composer makes plans, music laughs. Morton Feldman
On Fri, 12 May 2006, /*j wrote:
not quite... as i found out there are some more differences, the missing int being the most prominent, and the vector alisasing being the most annoying.
what do you mean by vector aliasing? (note: i never coded with the MAX API)
well, if you look at the list of names on my website you'll see that i avoid any max-names and try to come up with unique stuff, but i can always add a prefix or something. the worst offender is probably the string-lib with names like strcat (present in GEM i think), but it would be stupid to change these names because they correspond exactly to the c-function they enclose.
the "exactly" depends on the mapping system you are thinking in. Slightly different ways of mapping C->Pd may have slightly different (and thus completely incompatible) conventions.
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801 - http://artengine.ca/matju | Freelance Digital Arts Engineer, Montréal QC Canada
what do you mean by vector aliasing? (note: i never coded with the MAX API)
well, in MSP there's a flag that prevents input-vectors in a perform- method to be overwritten by the output-vectors. the MSP-API has a function that will allocate a new vector if you set that flag. in PD, i've been told, i have to work around this myself causing a rewrite of quite few perform-routine. (and flext wouldn't help with that, as thomas pointed out earlier).
but it would be stupid to change these names because they correspond exactly to the c-function they enclose.
the "exactly" depends on the mapping system you are thinking in. Slightly different ways of mapping C->Pd may have slightly different (and thus completely incompatible) conventions.
i haven't seen one coherent convention of mapping C-stuff to PD or Max yet.
we don't have C-strings in PD (and Max). the char array in the s_name field of a symbol is the closest thing there is.
strcat for example will concatenate the char arrays of the s_name fields of 2 symbols and output a third new symbol (using gensym()). strcmp will compare the char arrays of the s_name fields of 2 symbols and give its result either as boolean true/false or like the C- function as a number representing the match-distance. strtok takes the s_name field of one symbol, and iterates through it looking for a delimiter and outputs a list containing the new elements. etc etc.
by "exactly" i mean that the function doing the work *IS* the C- string-lib function by that name. how much closer can you get?
i'm against nameclashes myself, but i think the lib-dir / import lib mechanism .hc is setting up could alleviate this issue a lot.
/*j
On Mon, 8 May 2006 15:02:11 +0200 Hans-Christoph Steiner hans@eds.org wrote:
lib, a complete implementation of string.h as a lib, a boids lib, an XML parser, and more tasty bits.
Boids! Yum, yum! I've been meaning to write some boids externals myself, but never got round to it.
I look forward to trying the library.
Jamie
-
/*j -
B. Bogart -
Frank Barknecht -
Hans-Christoph Steiner -
IOhannes m zmoelnig -
Jamie Bullock -
Mathieu Bouchard -
Thomas Grill -
Tim Blechmann