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

[Hans-Christoph Steiner]

On Wed, 2011-04-13 at 19:09 +0200, IOhannes m zmölnig wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> On 04/13/2011 05:11 PM, Hans-Christoph Steiner wrote:
> > 
> > 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.
> 
> i think it is a good analogy.
> objects are loaded by default ("vanilla" set of objects).
> afair, you never needed to import "vanilla" to create [f].
> 
> however, what my analogy is really about is, that there is a startup
> flag "-nostdpath" which will _prevent_ path/to/pd/extra to be searched
> for objects.
> hence my suggestion to load "vanilla" by default, and add a flag
> "-nostdlib" to prevent loading of this if you need to.
> 
> > 
> >> 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.  
> 
> i appreciate that and i admit that using both "aggressive" and "assault"
> was a bit of an overshoot.
> 
> > The idea is to solve problems
> > like:
> > 
> > - wanting use a SIMD-optimized version of the core objects for things
> > that need it
> 
> a) i fully understand and support this.
> b) i don't understand how my suggestion breaks with your idea.
> you can always do a "-nostdlib -lib chocolate" to replace vanilla with
> stracciatella.
> 
> c) i don't understand how this is not possible with current Pd.
> as has been shown numerous times that you can simply override existing
> objects. cf. zexy's [pack] and gf's [print].
> 
> basically it seems that you are proposing something complicated to
> achieve something that is just there.
> 
> > - 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).
> 
> i'm all in favour of separating editor and runtime, and providing cool
> features. i fail to see how this is accomplished by forcing people to
> load core objects (and in fact leaving them with a bare, non "working"
> (for about all of the people) version of Pd)

First, its not done yet, so yes there are problems.  It'll be invisible
to all Pd-extended users except those that want to know about it.
That's my pledge.

Second, you don't even use Pd-extended, so you are hardly the target
audience.

.hc