[PD-dev] why using vanilla better than extended; was :Re: pow~ in Cyclone [was: Re: stripping down Pd-extended's default libs]

[Hans-Christoph Steiner]

On Feb 22, 2009, at 7:50 PM, cyrille henry wrote:

>
>
> João Pais a écrit :
> ...
>
>> is there anyone out there that really sticks to pd-van, and doesn't  
>> use  any externals, for other purposes than low-level educational  
>> ones?].
> i do use only vanilla + Gem + my externals.
> well, most of the time.
> (by example chdh performance patch does also use canvas, moog~ and  
> repeat (i'll remove the later when i'll have time))
>
> i don't have anything against externals but there are different  
> things that prevent me using lot's of them :
> (i use all the external i need. i just don't really need lot's of  
> them)
>
> -for stability : i don't wish to use code that i don't fully trust,  
> and i don't have time to personally test everything deeply.

Yes, there is definitely some crappy code included in Pd-extended.   
That's why I think we should stop including anything but the most  
stable libraries, and instead make it very easy for people to make and  
install libraries.  But one nice thing about using libdirs is that, if  
you don't use the crappy code, it is just a blob taking up disk  
space.  It is not loaded at all, therefore it won't affect your  
stability.

> -for simplicity : i think it's more simple to use a limited set of  
> object, than choosing from about 2000 of them.

I agree simplicity is good, and there is a lot of redundancy in Pd- 
extended.  The redundancy is mostly for backwards compatibility.  Then  
the other problem is that one person's simple set of objects don't  
work for someone else.  For example, I don't think you ever use creb  
but for others, that's indispensible.

> -for compatibility : i need to have my patch running on lot's of  
> different computer, using different version of pd, different OS.  
> since pd-extended is not yet the standard pd distribution for  
> anyone, i have to use the minimal set of external. i.e : almost  
> none. (see RJDJ by example)

If you don't use externals at all, then this is true.  If you do, then  
Pd-extended is the most compatible way to use externals.

> -for conservation : in 50 years, it will certainly be easier to use  
> a pd patch than a pd-extended patch. at least, it will not be  
> harder. This was true for the last few years since pd extended was  
> not mature until recently.

If you use no externals at all, or you always include every external/ 
abstraction you use within the project, then this could be true.   
AFAIK, this is how Miller bundles his code in PDRP.

If you use externals at all, then I disagree here quite strongly.   
There is no standard way to install or setup externals with Pd- 
vanilla.  That means in 50 years, people will have no idea how you set  
up your Pd-vanilla + externals.  Pd-extended will still be just a  
package with everything in the right place.

> -for new feature : pd-extended is 1 or 2 version late, and new pd  
> feature are usually really nice. by example i deeply use the new pd~  
> object for a project i'm working on. i don't really know when pd- 
> extended will be in version 0.42.

With new features come new bugs, unfortunately, like the editing  
helper and the pow~/override issue.  The latter could cause big  
problems.  But mostly the reason why there is a delay is because there  
is only so much I can do.

> -to prevent incompatibility : pd extended does not use transparent  
> object and this does break some of my old patch (when using a canvas  
> and symbol to create some visual feedback). moreover, it's visually  
> ugly.
> -for fun: most externals are useless and can be replaced by  
> abstraction. although it's fun not to use external, it also more  
> elegant.

Unless you always include the abstraction with the project, all of the  
same problems occur with abstractions.  If you have an abstraction  
that you reuse a lot, then you find a bug, you'd have to then fix it  
in all of your projects.  So you'd want to put that abstraction into a  
single reusable library.  Then it becomes an external. There really is  
no difference then in terms of distribution issues between a .pd and  
a .pd_linux.

> this is what i was thinking for the last 5 year. i don't say that  
> this will never change. anyway, i really appreciate the work made on  
> pd-extended, but it is not ready for me yet. i know that my position  
> is a bit extreme, but i don't really have problem with it.

Perhaps one day,  you'll join us ;-P

.hc

>
>
> Cyrille



----------------------------------------------------------------------------

Looking at things from a more basic level, you can come up with a more  
direct solution... It may sound small in theory, but it in practice,  
it can change entire economies.     - Amy Smith