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 > [email protected] > http://lists.puredata.info/listinfo/pd-dev > _______________________________________________ Pd-dev mailing list [email protected] http://lists.puredata.info/listinfo/pd-dev
