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 _______________________________________________ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev