[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
hans at eds.org
Mon Feb 23 06:03:22 CET 2009
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
More information about the Pd-dev
mailing list