[PD-dev] Proposals for object categories

Frank Barknecht fbar at footils.org
Wed Feb 25 10:03:26 CET 2009


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.

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.

Ciao
-- 
 Frank Barknecht            Do You RjDj.me?          _ ______footils.org__




More information about the Pd-dev mailing list