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

[Hans-Christoph Steiner]

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

.hc

----------------------------------------------------------------------------

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