[PD] feature request for [list]

[Roman Haefeli]

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:

1) 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.

2) 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