[PD] inflating PD-Vanilla (was Re: [almost OT] need suggestions for an implementation)

[Matteo Sisti Sette]

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.