On Feb 25, 2009, at 4:03 AM, Frank Barknecht wrote:
Hallo, Luke Iannini hat gesagt: // Luke Iannini wrote:
is something like this possible: each developer drops his stuff in svn in the current structure, but when compiled all externals are divided into categories (e.g. like the above named)? each developer has his own corner to drop stuff, but he has to check to which category each object belongs to, and they get distributed at compiling time. and, unchecked objects don't get compiled.
is this feasible/logic? it sounds logic to me, as f.e. my abstractions cover a bit of everything: GUI, midi, audio, ...
(The following uses the term "library" also for abstraction collections.)
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.
I think it would be a bad idea to just rename libraries. Instead of these top-down views of categories of libraries, I suggest that people just start making topic-organized libraries in topics that they are interested in. That's how it was done with 'mapping' and 'apple'.
As for old dependencies, we can keep the 'purepd' library in there until nothing depends on it. Its just files in the file system if they are not used, so I don't see the harm.
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)
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.
I think you outlined the argument against this proposal with your zexy example. It doesn't sound like a real solution if you include one version of list-drip in the list-abs library because of technical restrictions, but then you use a different version because it works better. Why not have a system of libraries where you can use the code that works better?
That is why it is important to have a library format and search path behavior that treats all objectclasses as equals, whether they are written in Pd, C, Lua, etc.
.hc
Ciao
Frank Barknecht Do You RjDj.me? _ ______footils.org__
Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
----------------------------------------------------------------------------
You can't steal a gift. Bird gave the world his music, and if you can hear it, you can have it. - Dizzy Gillespie