Hans-Christoph Steiner a écrit : > I don't think that Pd-extended is for everyone, that's fine by me. I > think its good to have many distros of Pd+libs. we all agree here. > But what I think is > essential is that we have a common library format so that patches made > in one distro can be compatible in others. yes, it is important. but having patch compatible between 2 pd distro require more than just a common lib format.
> Saying that you tailor > your environment to your patches is not a solution. Then your > patches will only work in your custom setups. yes. my aim is the opposite. starting pd with -noprefs is not really "tailor your environment to your patches" but trying to make your patch to work on all environment. > > That is why I think we need to discuss the library format and come up > with a format that works for everyone. I posted the idea for a common > library format somewhere in this thread. This is an idea that has > been formed from the contributions of a number of people, and I think > it covers all the concerns that I know of. Please take a look and > comment on it, so we can start coding it and lay this argument to > rest :D i miss this discussion. so, having every file (.pd, .pd_linux .dll .pdlua and *-help.pd) in the same directory is ok for me. The way you distribute a lib should also be related to the way you develop this lib on the svn. so, should the svn be ordered on the same way : every files on the same dir? except for sources and everything that need for compiling externals that could go on a src sub-folder? and also a sub-folder for the examples (that are not help files)? about the loading order : is this mandatory to introduce incompatibility between vanilla and extended? changing the loading order in pd-extended may break some patch. this is not a major problem for me since we all can adapt old patch to work with a new software version. But to have different order between vanilla and extended is not really nice. cyrille > > .hc > > > On Feb 23, 2009, at 6:16 PM, cyrille henry wrote: > >> >> João Pais a écrit : >>>>> -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. >>> here here. even if the code gets loaded into memory, as long as >>> there are no nameclashing you shouldn't even notice it (except >>> you're running an installation on a low-end computer and each byte >>> counts, ...) >> loading a patch when you have lot's of lib loaded should be slower. >> but why using pd-extended if you don't need all the lib? >> >>>>> -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. >>> and I also think that the redundancy comes also from the fact that >>> there is no object list for pd-ext. no one has the time to search >>> 2xxx objects, so they just program their own. >> it's not very hard to look on the svn for a specific object name >> before writing the same object wih the same name. >> >> >>>>> -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. >>> is pd-ext not the standard version for many reasons more than it >>> isn't maintained by MP, and because it isn't as actual as pd-van? >> i just mean pd-extended is not used by anyone. >>> I don't know about the compatibility issue - you say this because >>> some systems have low resources (like rjdj), or because pd-ext >>> isn't stable in some systems? the 1st makes sense, naturally (also >>> if you get a 10year old computer for an installation, etc.) >> everybody use a different set of external. so when you share a >> patch, you can have problem if someone does not load the lib you're >> using. >> look at how many problem send on the pd list is solve via changing >> pd lib loading preferences. >> >>>>> -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. >>> I think so as well, the builds are a solid package (if the code >>> inside works, like it does in many of the libs). anyway, this >>> discussion (and subsequent actions, if they happen) would be a >>> good step to make pd-ext even more mature. I would think that a >>> small "tester group" to test objects, or to alert developers for >>> good testing + documentation + use of proper formats (for >>> documentation + pdpedia or whatever) would be a good thing. I >>> would be up to give some time for it (can't give much more than >>> that, anyway). >>>>> -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. >>> are there any users that could help HC with the task of putting pd- >>> van and pd-ext at the same level? I guess that the most mature >>> result would be that MP's code would go directly to pd-ext after >>> being tested/released. >>>>> -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. >>> what do you mean visually ugly? the fonts, or something that can't >>> be adjusted? >> i just don't like the not transparent object. >> >> cyrille >> >>> _______________________________________________ >>> Pd-dev mailing list >>> [email protected] >>> http://lists.puredata.info/listinfo/pd-dev > > > > ---------------------------------------------------------------------------- > > "[W]e have invented the technology to eliminate scarcity, but we are > deliberately throwing it away to benefit those who profit from > scarcity." -John Gilmore > > > > _______________________________________________ > 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
