[PD-dev] why using vanilla better than extended; was :Re: pow~ in Cyclone [was: Re: stripping down Pd-extended's default libs]

[cyrille henry]

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