On Tue, Feb 24, 2009 at 4:34 PM, João Pais jmmmpais@googlemail.com wrote:
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.
Yo, Perhaps an interesting way to approach this would be for each developer to hierarchize their own collection, and then we can find the common ground between them all. It also might be nice for everyone to claim a library and stand as its maintainer, as Frank has done for list-abs/ and Cyrille and HC have done for mapping/, etc. I've begun ds-gui/ to this effect...
Best Luke
And, here's an example from my own sfruit/ collection: gui/ (for extending, interacting with, or working around limitations of the IEMGUIs) ds-gui/ ds-abs/ keyboard/ hid/ color/ control/ (i'm guessing everyone has enough of these that we'll have to make this finer-grained) dialog/ (these are different manifestations of "dialog boxes" in Pd) gem/ OSC/ list-abs-extended/ (these are list-abs that require objects not in Pd-vanilla (a restriction laid down by Frank long ago for list-abs)) midi/ sequencing/ signal/ envelope/ mix/ oscillators/ os/
Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev