[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.


>> 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