[PD-dev] working pd-ext 0.43 build on windows?

Hans-Christoph Steiner hans at at.or.at
Wed Apr 13 17:11:50 CEST 2011

On Apr 13, 2011, at 10:54 AM, zmoelnig at iem.at wrote:

> Quoting "Hans-Christoph Steiner" <hans at at.or.at>:
>> The vanilla libdir will include [f], [t], [b], etc. you don't need  
>> a -nostdlib option to do that.  I so no reason to add a different  
>> library loading mechanism when we have one that works.
> excuse my ignorance, but i'm only proposing that the "vanilla"  
> library should be loaded by default, unless the user decides that  
> they don't want that.
> if you indeed read my mail like this, then i would like you to  
> explain to me again, why you needed additional search paths like ~/ 
> pd-externals/ to be compiled into pd, when we have a perfectly  
> working method to add "~/pd-externals" (well, given that the tilde  
> expansion works) to the search paths: "-path ~/pd-externals".

That is not quite a good analogy.  The existing method was there: a  
folder that was searched by default called path/to/pd/extra.  You did  
not need to specify -path path/to/pd/extra.  ~/pd-externals is just  
another folder in that same list of folders to search.

> removing the core objects from Pd seems a more aggressive assault to  
> people's workflows than having them manually add some "standard"  
> search paths.
> either you do make exceptions or you don't.

I want nothing aggressive or assaulting.  The idea is to solve  
problems like:

- wanting use a SIMD-optimized version of the core objects for things  
that need it
- ability to use the new GUI/editor features while maintaining  
compatibility with older versions of Pd (i.e. steps towards the  
separation of the editor and the runtime).



Using ReBirth is like trying to play an 808 with a long stick.    - 
David Zicarelli

More information about the Pd-dev mailing list