[PD-dev] pbank in build/src (aka "flatspace")

Luke Iannini lukexipd at gmail.com
Thu Feb 26 11:09:20 CET 2009


On Wed, Feb 25, 2009 at 7:33 AM, Hans-Christoph Steiner <hans at eds.org> wrote:
>
> On Feb 25, 2009, at 5:07 AM, cyrille henry wrote:
>
>>
>>
>> João Pais a écrit :
>>>>>> when pd-extended or the cvs will be ordered to have directory
>>>>>> like : /math
>>>>>> /audio/math
>>>>>> /audio/effect
>>>>>> /save
>>>>>> /matrix
>>>>>>
>>>> but i would prefer to organise this properly (i.e. not by
>>>> developer but by functionality)
>>>>
>>>> for now, using flatspace is the only way i know to include code in
>>>> pd-extended, i'll digg more when i'll get time.
>>> 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, ...
>>> Also, the amount of categories should be discussed, and probably on
>>> the main list. I think that MP's original list isn't enough, and
>>> new categories should be included (especially considering the
>>> amount and diversity of objects in pd-ext). audio filters,
>>> generators, effects, ... I can look at the pd-ext-list I've made
>>> and give a concrete suggestion in the next days, if you want.
>>> this discussion will be a bit chaotic, but it should go to the main
>>> list/pdpedia.
>>
>> yes,i think such proposition can be constructive.
>>
>
>
> Honestly, I think the libraries should not be automatically formed.
> They should be owned by someone and designed as a whole, not pieced
> together from random bits.  This is how libraries are usually written
> in Perl, Python, etc. etc.  This would ensure that the objectclasses
> in a library have matching interfaces, and work well together.
My suggestion is certainly aimed towards that goal, but tackled with
an iterative approach.

Basically, organization of the libs could not really be any /worse/
than it is now (e.g. I'm constantly checking ggee, hcs, moonlib and
zexy to find various OS and filesystem externals I need), so I'm
basically proposing the same thing you are, but approached as follows:
* Lazy consensus on a directory structure (I think we were already
making very nice progress on that in the "Proposals for object
categories" thread before it went off track : ) )
* Creation of a branch of SVN with the directory structure in place
* Everyone works together to shuffle the many libs into the new structure
* We each claim a domain we'd like to maintain
* And then, finally, the maintainer (with help from consenting
developers where necessary) begin to rewrite the objects in that
category to have a consistent interface.

One of the benefits of this is it will become much clearer what that
common interface should be once many objects of the same type are
collected together.  And I think it will be much more likely for
maintainers to step forward once the libraries are loosely assembled,
since the potential will be so much clearer.

And of course this does not need to be a mandate - if a developer
would rather keep all his/her stuff together, that's fine.  And, there
will always be exceptions like rtc-lib or sigpack that shouldn't
really be split up.

But, on the other side, I'm assuming there are many developers that
would be more than happy to move their code into common categories -
at the very least including myself, João and Cyrille, and only haven't
done so because the structure did not exist.  And personally I'd be
just as willing to adapt the interfaces of my abstractions to a
category-defined standard, but once again, none exists now to adapt
to.

Does that make sense?
Best
Luke

>
> .hc
>
>
> ----------------------------------------------------------------------------
>
> Mistrust authority - promote decentralization.  - the hacker ethic
>
>
>
> _______________________________________________
> Pd-dev mailing list
> Pd-dev at iem.at
> http://lists.puredata.info/listinfo/pd-dev
>




More information about the Pd-dev mailing list