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

[Hans-Christoph Steiner]

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