no question, that it makes sense to collect code in order to provide it to everyone. i like also the idea to make a standard collection of externals/abstractions. it was not my intention to argue against that. i think we have to consider two points of view:
- when you do a patch for a certain project, where pd is only a part of
many interacting programs, you probably need specialized externals for certain tasks. when realizing such a project, you don't mainly care much about portability, since the whole project maybe depends on a certain os/environment.
- oftenly one creates a patch that can be widely used (e.g. synths,
sequencers, usefull abstractions). i think, that it is worth to focus on portability in such a case. of course, there is no reason against using externals, if you assume that people have installed pd-extended. but there are still some problems. some of the externals are only available on a certain os. there are also externals, that can be easily substituted by abstractions/subpatches made of internals (e.g [eadsr]) and i see no advantage of using an external when the same could be reached with internals. last but not least, (suddenly) not everybody uses pd-extended. it also need to be considered, that in many cases you won't come around using externals for special tasks (which can be considered as non-standard ones). i think it is important then, that a list of used externals comes with the patch. i see the main advantage of externals in providing non-standard possibilities, so i think they should be used with care, and people should be aware, what are internals and what are externals, so they use externals only for these special cases (oops, now i'm sounding like a preacher).
i consider [symbol2list] (or whatever it will be called) to be a standard task, thats why i sent this feature request. i just noticed that my argumentation will lead to a big disussion about what are standard and what are non-standard tasks. i think this will change accordingly with the growing of pd. as for now and since [list], message handling looks quite like a standard task in my eyes and a [symbol2list]-object is the last missing piece. writing this sentences led me to thinking about two concepts of how an environment could be designed. one one hand an environment like pd (+ externals) could be designed to provide very specialized functions/objects (don't know how to call that), that are very ready- and easy-to-use (e.g. [eadsr]). the disadvantage of such a design is, that these functions/objects are not quite flexible in use and you will need a lot of them in order to cover a wide area of tasks. on the other hand an environment could provide a small set of functions/objects, with which one could build the higher level task. this approach maybe is more difficult in use, but if offers higher flexibility. since the possibility of building abstractions i'd prefer the second approach, because once you've built the high-level tasks, you can use them as easily and fast as an external. this is one of the reasons, why i use pd and not max/msp or reaktor. i believe also, that miller (rather) follows the second approach, when he introduces the objs [rpole~], [czero~] etc. instead of providing 'baked and ready-to-eat' filters. i prefer the second approach, but this is just my personal opinion.
"Hans-Christoph Steiner" wrote:
I think we should think of Pd as a platform and all of the objects that people have written as libraries. Sticking to only the objects in the core of Pd means that you are reinventing the wheel again and again. If someone has written it and documented it, then use it, and spend your time making something new.
This is the idea that drives me to work on Pd-extended. And in the process, I've found a lot of amazing code that I never would have written. But now I can easily use it, play with it, etc. And I can also easily install it on someone else's computer and show them too, or even send them my patch, and it'll work.
Then when we have a Pd platform, then a patch can be an application. Just like java, once its installed, all you need to do is run one file and it can draw on the whole package.
.hc
On Apr 11, 2006, at 10:21 AM, Roman Haefeli wrote:
hi all
more and more i realize that i can do most basic things in pd without externals. before all, the introduction of [list] made many objs of externals, that i used a lot, obsolete. one (in my eyes) basic task remains uncovered by list: splitting symbols into lists (e.g. separated by a separator-char). it would be very nice, if this could be done in future versions of pd. i really like the idea to be independent from externals as far as it is possible, mainly for reasons of portability. even if i could reach the same with less code, i'd prefer the solution built with only natives. are there good reasons against this idea?
roman