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

João Pais jmmmpais at googlemail.com
Thu Feb 26 17:22:16 CET 2009


> 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 : ) )

I can start organising the info in a wiki page later in the day. I guess  
this is point where we all agreed, we should try to move in the direction  
of a structured pd-ext?


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

is the consistent interface really necessary? there was already some  
discussion about the layout for the pddp project (am I right?), maybe  
elements from there could be taken?
or maybe it's enough to provide a general template with guidelines to be  
followed, in case the developer wants the objects to become part of  
pd-ext? f.e., I have a consistent approach to the documentation of my  
abstractions - of course I can use another graphical template, but that  
might open lots of unecessary discussions: "why these colors", "why this  
layout", "why so many graphics and not only text", .....

But I think that in general it should be stressed that objects should be  
stable and properly documented.


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

shouldn't they really? depends on what you're talking about - rtc, vasp,  
etc. are very cohese libs, that anyway don't go much outside their domains  
- their developers even made that separation clear, by putting other  
externals available elsewhere. they could easily go to /control/rtc or  
/control/array/vasp or etc. But for not so tight lib-packages, is it that  
bad to separate objects, as long as they're all available on path?


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

I have no problem in structuring my abstractions (I can't code), but my  
"lib" is probably one of the most simple ones.




More information about the Pd-dev mailing list