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

[João Pais]

>> -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, ...)


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


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


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