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 stability.
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.
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.
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- vanilla.
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 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,
i do
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.
NO! 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...
cyrille
.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
Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev