[PD-dev] why using vanilla better than extended; was :Re: pow~ in Cyclone [was: Re: stripping down Pd-extended's default libs]
cyrille.henry at la-kitchen.fr
Mon Feb 23 11:54:03 CET 2009
Hans-Christoph Steiner a écrit :
> On Feb 22, 2009, at 7:50 PM, cyrille henry wrote:
>> -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
yes, but i don't see the point of using pd-extended and removing the extended :-)
>> -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.
i always think at one point that backward compatibility is something that prevent a software to move forward.
look at max and the int / float problem. without backward compatibility Max would be much much better.
> 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.
yes, i don't think lot's of people use line3, but for me it's mandatory.
so anyone should use there set of externals.
but loading all like in current extended distribution is insane.
>> -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.
well, pd-extended is very compatible with other pd-extended.
but pd-extended is not the only pd distribution...
>> -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.
of course i do include all abstractions in my project directory.
a good project is a project that start :
pd -noprefs myproject.pd
with all declaration inside the patch.
(and an even better project is when you can remove the -noprefs, so that there is no name conflict)
> AFAIK, this is how Miller bundles his code in PDRP.
i'm not alone!
> If you use externals at all, then I disagree here quite strongly.
> There is no standard way to install or setup externals with Pd-
you can put them anywhere, when you [declare] that path in your patch
> 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.
without your work, pd-extended will collapse. i can't be as sure than you are about the future of pd-extended.
>> -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.
i know that you have good reason. my mail is not a personal attack.
but the fact is that i prefer using the 0.42 feature than the extended feature.
>> -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
>> -for fun: most externals are useless and can be replaced by
>> abstraction. although it's fun not to use external, it also more
> Unless you always include the abstraction with the project,
> all of the
> same problems occur with abstractions.
yes, that's why it's mandatory to do so.
> 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.
it can be bad to fix something that change the behaviour of your old patch.
unless of course you find a bug that could crash pd.
by example, i just saw that env+ change the amplitude of the signal depending on it's argument.
it's a bug and MUST be fixed.
doing this will not change the behaviours of my old patch, but anyone trusting pd-extended will have to modify there patch. (well, i hope nobody noticed the difference anyway).
so, if your patch use a buggy abstraction, you better not to correct it in order to use your patch as it should work.
i some specific case, you may have to modify lot's of your abstraction on the same way, but search/replace/script is your friend...
> 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.
yes, i do include both in my projects.(with sources for the externals)
>> 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
i did not say pd-extended is bad (you know i support your work). i just say that for my main laptop i prefer not using it.
but i do use it on the 100 of computers that run the patch i program...
> 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
> Pd-dev mailing list
> Pd-dev at iem.at
More information about the Pd-dev