[PD-dev] Proposals for object categories

cyrille henry cyrille.henry at la-kitchen.fr
Wed Feb 25 11:21:49 CET 2009



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




More information about the Pd-dev mailing list