[PD-dev] Proposals for object categories
hans at eds.org
Wed Feb 25 16:42:27 CET 2009
On Feb 25, 2009, at 4:03 AM, Frank Barknecht wrote:
> 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
>>> categories (e.g. like the above named)? each developer has his own
>>> to drop stuff, but he has to check to which category each object
>>> to, and they get distributed at compiling time. and, unchecked
>>> don't get compiled.
>>> is this feasible/logic? it sounds logic to me, as f.e. my
>>> cover a bit of everything: GUI, midi, audio, ...
> (The following uses the term "library" also for abstraction
> 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
> 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.
> Frank Barknecht Do You RjDj.me? _
> Pd-dev mailing list
> Pd-dev at iem.at
You can't steal a gift. Bird gave the world his music, and if you can
hear it, you can have it. - Dizzy Gillespie
More information about the Pd-dev