[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
Wed Feb 25 16:29:52 CET 2009
On Feb 25, 2009, at 5:01 AM, cyrille henry wrote:
>
>
> Hans-Christoph Steiner a écrit :
>> On Feb 24, 2009, at 11:49 AM, cyrille henry wrote:
>>>
>>>
>>> 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.
>> Yes, but we have to start somewhere.
>>>> 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)?
>> here is the proposal in question:
>> http://lists.puredata.info/pipermail/pd-dev/2009-02/013009.html
> this mail is only about pd-extended file organization.
> i'll be happy to have a svn organization proposition.
> or did i misunderstand things?
That thread is about the design of a common library format and search
path order.
.hc
>
>
>> If you are happy including any externals in the same folder, then
>> do that, you don't need libraries. For me, I would like to be able
>> to easily use externals that have been updated. Yes, fixing bugs
>> can break patches, but that's hardly an argument to stop fixing
>> bugs. Any change in code can break things, shall we just stop
>> changing Pd at all? I think a better solution is to allow a patch
>> to query Pd for the version, then include info about which version
>> that patch was made with. Pd-extended has [version] for that
>> purpose.
>>> 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.
>> The idea would be to change vanilla, then extended would inherit it.
> i certainly miss some discussion here : does miller agree?
>
> I
>> also want to avoid a difference here.
> cool
>> I think changing the loading order won't change anything in how Pd-
>> vanilla objects are loaded, it might change which objectclass gets
>> loaded in Pd-extended, but that can be checked with a script.
>> It could change how a patch behaves, but in a way that could happen
>> switching between distros and installations too. Things are so
>> messy now, I don't think it would be wise to keep it that way.
>
> i don't see problem to change pd behaviors from 1 version to an
> other. but i whish pd and pd-extended to be easily compatible.
> so, let's go!
>
> Cyrille
>
>> .hc
>>>
>>>
>>> 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 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
>>>> _______________________________________________
>>>> Pd-dev mailing list
>>>> Pd-dev at iem.at
>>>> http://lists.puredata.info/listinfo/pd-dev
>> ---------------------------------------------------------------------------- "[T
>> ]he greatest purveyor of violence in the world today [is] my own
>> government." - Martin Luther King, Jr.
----------------------------------------------------------------------------
You can't steal a gift. Bird gave the world his music, and if you can
hear it, you can have it. - Dizzy Gillespie
More information about the Pd-dev
mailing list