[PD-dev] why using vanilla better than extended; was :Re: pow~ in Cyclone [was: Re: stripping down Pd-extended's default libs]
Hans-Christoph Steiner
hans at eds.org
Tue Feb 24 01:14:53 CET 2009
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. 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. Saying that you tailor
your environment to your patches is not a solution. Then your
patches will only work in your custom setups.
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
.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 at 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
More information about the Pd-dev
mailing list