On Thu, 2008-03-13 at 17:26 +0100, Matteo Sisti Sette wrote:
I do totally agree that [pdlua] is a great thing and that it would be desirable to have it become part of PD-Vanilla. Nevertheless,
Frank Barknecht wrote:
Some people may miss [s2l] in vanilla Pd, others miss a [pipe] for variable length lists or a multi-period [metro], a flexible markov chain object and whatnot. With pdlua most of this is almost trivial to write and can be installed without the need to compile anything once pdlua is installed.
We first have to distinguish between A) things that can already be achieved IN vanilla pd by creating abstractions on top of built-in objects B) things that can not.
Within category (A), there are things that would either result in a horribly inefficient implementation or require some hugly hack, so they deserve to be treated like case (B). Think for example about the "old" [list-length] abstraction that returned the length of a list by scanning it and counting its elements: it implemented the same funcionality of the later built-in [list length], yet it was quite desirable to have a built in object to do that. Probably better examples can be found.
Except these cases, I think that externals that solve class-A problems are not candidate to becoming part of PD Vanilla.
Now about class B that is the one I'm concerned with.
It's great to include a high-level interpreted language in PD that lets one create all the extensions s/he wants, but that doesn't mean that, if this extension language (lua) became part of PD Vanilla, ANY built-in object whose functionality could be obtained with a lua script would become unnecessary!
True: if [pdlua] was part of PD Vanilla, you wouldn't strictly "need" a [symbol2list] (or splitsymbol or whatever) object. But then you wouldn't need [*], [-], [sqrt], [cos], [list ...], [moses], [until]...... probably not even [trigger]. Would you imagine how pd patches would look like??
It is, I think, a matter of "elegance" (which means that it is subjective, I recognize).
Let me make a parallelism. I always missed [>=~], [==~], [abs~], etc.; I was quite astonished to find out they didn't exist when I first needed them, and I never understood why they didn't, until [expr~] became part of PD Vanilla, or probably until I _realised_ that [expr~] _was_ part of PD Vanilla. Now I still think they should exist, as I find ugly to write [expr~ $f1>=$f2] (or whatever it is) instead of [>=~]. I think it is a matter of elegance and consistence that every control math operator should have its signal counterpart.
Now i'm SURE there are good reasons why basic signal math operators don't exist, I haven't even searched the archives but i'm sure I'll find out something about it, however take this as an _example_.
Now I think breaking symbols is just another example; and like a couple of people have said in this thread, since you can join them it's reasonable to expect you can break them just as easily.
wow......
i wouldn't have been able to make my point _this_ clear. those would be my words, if i'd be able to speak so eloquently.
roman
___________________________________________________________ Der frühe Vogel fängt den Wurm. Hier gelangen Sie zum neuen Yahoo! Mail: http://mail.yahoo.de