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 Pd-dev@iem.at 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 Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev