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

cyrille henry cyrille.henry at la-kitchen.fr
Mon Feb 23 18:27:30 CET 2009

yep, when you need to compile some stuff, pd-extended is not really made for you.
since i quite often have to use a very recent Gem version for my project, (specially when i correct some Gem bugs when working on this project), i must recompile Gem on the target machine, so using extended is not really easy.
using extended is ok when installing a project i made about 1 year ago...


IOhannes m zmoelnig a écrit :
> Frank Barknecht wrote:
>> Hallo,
>> cyrille henry hat gesagt: // cyrille henry wrote:
>>> 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.
>> I have a similar position. :)
>> To me the problem of Pd-extended or the reason why I don't use it is
>> because it is not only a collection of externals and abstractions, but
>> it also bundles it with a modified, often out-of-date version of Pd
>> into a big monolithic package.
> i guess one of the main reasons for us (the iem) to not use pd-extended 
> is, that it is targeted at people without compilers, whereas we often 
> develop libraries for our projects.
> (Pd-extended is severely limited in this respect, e.g. the 103MB disk 
> image on OSX comes without g_canvas.h)
> fmasd.r
> IOhannes
> ------------------------------------------------------------------------
> _______________________________________________
> Pd-dev mailing list
> Pd-dev at iem.at
> http://lists.puredata.info/listinfo/pd-dev

More information about the Pd-dev mailing list