[PD-dev] Proposals for object categories
hans at eds.org
Wed Feb 25 20:49:28 CET 2009
On Feb 25, 2009, at 1:51 PM, cyrille henry wrote:
> Hans-Christoph Steiner a écrit :
>> 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 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
>>>>> 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
>>> 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
>>> 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
>> 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.
> so how should i remove purepd dependency of the mapping lib :
> -should i copy purepd/once to mapping/once and change in the purepd/
> once object to once
> -should i copy purepd/once to mapping/mapping_once and change in the
> purepd/once object to mapping_once
'purepd' is pure Pd, so just copy the folder where you need it. That
will work on any Pd distro. Maintaining many different copies of the
same object is not a solution.
For example, if you put the purepd folder in your project, then
[purepd/once] will work.
>>> A route that I would suggest (and suggested several times in the
>>> 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.
>>> 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
>>> 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
>>> 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
>>> 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?
> because zexy is not available for iphone.
> so both list_drip are important.
>> 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.
> i think we can have a list-abstraction library and a list-abstration-
> optimised and a list-abstraction-optimised-mmx
> the 1st contain all list-abs in pd vanilla, the 2nd could contain
> objects using zexy
> the 3d contain binary compiled with mmx optimisation.
> the object in the 3d could override the object in the 2nd (and 2d
> override the 1st).
> so everybody is happy : you can always use a vanilla abstraction, or
> a more optimized on, if your computer allow it.
>>> 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
>> Pd-dev mailing list
>> Pd-dev at iem.at
The arc of history bends towards justice. - Dr. Martin Luther
More information about the Pd-dev