[PD-dev] Proposals for object categories

[cyrille henry]

Hans-Christoph Steiner a écrit :
> 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.
yep.
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

?


> 
>> 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?
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.

cyrille


> 
> .hc
> 
> 
>>
>> Ciao
>> -- 
>> Frank Barknecht            Do You RjDj.me?          _  
>> ______footils.org__
>>
>> _______________________________________________
>> Pd-dev mailing list
>> Pd-dev at 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
> 
> 
> 
> 
> _______________________________________________
> Pd-dev mailing list
> Pd-dev at iem.at
> http://lists.puredata.info/listinfo/pd-dev
>