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