[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 :
> On Feb 22, 2009, at 7:50 PM, cyrille henry wrote:


>>
>> -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.
yes, but i don't see the point of using pd-extended and removing the extended :-)

>> -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. 
i always think at one point that backward compatibility is something that prevent a software to move forward.
look at max and the int / float problem. without backward compatibility Max would be much much better.
> 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.
yes, i don't think lot's of people use line3, but for me it's mandatory.
so anyone should use there set of externals. 
but loading all like in current extended distribution is insane.

> 
>> -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.
well, pd-extended is very compatible with other pd-extended.
but pd-extended is not the only pd distribution...

> 
>> -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.   
of course i do include all abstractions in my project directory.
a good project is a project that start :
pd -noprefs myproject.pd
with all declaration inside the patch.
(and an even better project is when you can remove the -noprefs, so that there is no name conflict)
> AFAIK, this is how Miller bundles his code in PDRP.

i'm not alone!

> 
> 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. 
you can put them anywhere, when you [declare] that path in your patch

> 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.
without your work, pd-extended will collapse. i can't be as sure than you are about the future of pd-extended.

> 
>> -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.
i know that you have good reason. my mail is not a personal attack.
but the fact is that i prefer using the 0.42 feature than the extended feature.

> 
>> -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.
>> -for fun: most externals are useless and can be replaced by  
>> abstraction. although it's fun not to use external, it also more  
>> elegant.
> 
> Unless you always include the abstraction with the project,
i do
> all of the  
> same problems occur with abstractions. 
yes, that's why it's mandatory to do so.
> If you have an abstraction  
> that you reuse a lot, then you find a bug, you'd have to then fix it  
> in all of your projects.
NO!
it can be bad to fix something that change the behaviour of your old patch.
unless of course you find a bug that could crash pd.
by example, i just saw that env+ change the amplitude of the signal depending on it's argument.
it's a bug and MUST be fixed.
doing this will not change the behaviours of my old patch, but anyone trusting pd-extended will have to modify there patch. (well, i hope nobody noticed the difference anyway).

so, if your patch use a buggy abstraction, you better not to correct it in order to use your patch as it should work.
i some specific case, you may have to modify lot's of your abstraction on the same way, but search/replace/script is your friend...


>  So you'd want to put that abstraction into a  
> single reusable library.  Then it becomes an external. There really is  
> no difference then in terms of distribution issues between a .pd and  
> a .pd_linux.

yes, i do include both in my projects.(with sources for the externals)

> 
>> this is what i was thinking for the last 5 year. i don't say that  
>> this will never change. anyway, i really appreciate the work made on  
>> pd-extended, but it is not ready for me yet. i know that my position  
>> is a bit extreme, but i don't really have problem with it.
> 
> Perhaps one day,  you'll join us ;-P

i did not say pd-extended is bad (you know i support your work). i just say that for my main laptop i prefer not using it.
but i do use it on the 100 of computers that run the patch i program...

cyrille

> 
> .hc
> 
>>
>> Cyrille
> 
> 
> 
> ----------------------------------------------------------------------------
> 
> Looking at things from a more basic level, you can come up with a more  
> direct solution... It may sound small in theory, but it in practice,  
> it can change entire economies.     - Amy Smith
> 
> 
> 
> _______________________________________________
> Pd-dev mailing list
> Pd-dev at iem.at
> http://lists.puredata.info/listinfo/pd-dev
>