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.
Bye m.
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
On Mar 13, 2008, at 1:36 PM, Roman Haefeli wrote:
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
This is fundamentally the reason for Pd-extended. We can include A
and B solutions in a common layout so everyone's patches work on
other people's computers.
.hc
"Free software means you control what your computer does. Non-free
software means someone else controls that, and to some extent
controls you." - Richard M. Stallman
-
Hans-Christoph Steiner -
Matteo Sisti Sette -
Roman Haefeli