Hallo, Roman Haefeli hat gesagt: // Roman Haefeli wrote:

"Frank Barknecht" fbar@footils.org wrote:

...

1. negative indices to [list split] (patch available @sourceforge)

negative index would count items from the end of the list?

Yes. The [list-splat] abstraction of [list]-abs implements this. It is immensely useful to get the last element of a list with [list-splat -1]

Oh, and while we're at it: [list length] would also be useful. ;)

Ciao

Frank Barknecht _ ______footils.org_ __goto10.org__

"IOhannes m zmoelnig" zmoelnig@iem.at wrote:

ah: and i really would like if the list objects would NOT use space but some other delimiter so people (like frank) could write objects that are undistinguishable at first glance from built-in objects. just adding an alias name would be enough...

why should they look as standard, when they aren't? as long as these abstractions are not included in standard (millers) pd, i'm glad they are distinguishable from the built-in objects.

On Apr 11, 2006, at 12:40 PM, IOhannes m zmoelnig wrote:

Frank Barknecht wrote:

...

1. negative indices to [list split] (patch available @sourceforge)
2. a fast [drip] made native to [list] (source code in Zexy)

by [drip] do you mean [repack 1] or the "real" (delay-based!) [drip]?

...

what comes to my mind is als [list length] (but you already
mentioned that)

ah: and i really would like if the list objects would NOT use space
but some other delimiter so people (like frank) could write objects
that are undistinguishable at first glance from built-in objects. just adding an alias name would be enough...

I agree. How about:

[list/split] [list/append] [list/prepend] [list/trim]

I.e. a list libdir which works with the namespaces.

.hc

As we enjoy great advantages from inventions of others, we should
be glad of an opportunity to serve others by any invention of ours;
and this we should do freely and generously. - Benjamin Franklin

On Apr 11, 2006, at 12:22 PM, Federico wrote:

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 would like to see a [sscanf] object.... and a [sprintf] one too.

these are standard functions of C language.

[sprintf] would act like [makefilename], except that accept more
than one variable (makefilename gives unpredictable results sending
lists with a format string like a%d_b%d).

so, an example of how [sprintf] should act:

[list foo bar 34( | [sprintf %s-%s-%d]

would return a symbol: foo-bar-34 and sscanf would do the inverse job:

[symbol foo-bar-34( | [sscanf %s-%s-%d]

would return a list: symbol foo, symbol bar, float 34

consider this just a request for comment :)

[sprintf] exists, its in cyclone. [scanf] would be nice too. In
fact, a whole POSIX lib would be handy.

.hc

Man has survived hitherto because he was too ignorant to know how to
realize his wishes. Now that he can realize them, he must either change them, or perish. -William Carlos
Williams

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