Frank Barknecht a écrit : ...
There is one big problem to solve with reorganizing (which I'm generally in favour of): interdependencies between libraries.
That's why [list]-abs deliberately avoids these completely and relies only on Pd-vanilla, but libs like RTClib or mapping etc. depend on other collections (RTClib depends on [list]-abs and some externals, mapping has purepd and externals,...)
Now if you rename all libraries you will also have to change some of their objects to refer to the objects in new ways. mapping for example could not use [purepd/float_argument] anymore and would have to be changed to something like [utils/float_argument] or [import utils]+[float_argument]. But then, mapping would not work in other distributions anymore.
that's why my proposition was to start a new svn, using the 1st while organising the 2nd. then deprecated the 1st....
A route that I would suggest (and suggested several times in the past) would be to work on a kind of standard library that
a) consists only of abstractions b) uses no externals at all c) is selfcontained (i.e. no interdependencies)
this is very nice, but sometime not possible. i really like the physical model mapping, so i need msd for some mapping externals...
but yes, somthing like float_argument should be forked to go in the mapping directory.
cyrille
If you feel reminded of [list]-abs now, that's intentional. Basically such a standard library would define an *interface* for standard objects. Where performance is an issue, the interface could alternatively implemented with externals. This also is exemplified in [list]-abs, where personally I use a version of [list-drip] that has zexy's [drip] inside for speed reasons. It behaves exactly like the abstraction version so it doesn't matter if people don't have zexy installed.
Actually I'm working on such a project for a while now: the rj-lib for RjDj http://trac.rjdj.me/wiki/RjLibnew It's pure vanilla, has a well documented and (generally) consistend interface, has categories, a preset system and is generally patched in a clean, KISS and self-contained way. It's not so much intended to be "loaded" with -path, instead you should just drop the "rj" directory into your project directory as a whole and use the objects either as [rj/s_drumelectro] or you use [declare -patch rj] in your main patch and write the object names as [s_drumelectro]. This works surprisingly well: Most of the Scenes written for RjDj use this library sucessfully, although it's still far from 1.0.
Ciao