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

[Roman Haefeli]

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