hi, I doubt that these categories will be as hierarchical and structured as proposed here. for example the pdp objects, gridflow and gem(pix and particle+related objects) are good examples for libraries. but zexy and cyclone are libraries where even after so many years I still don't know what some of the objects do or to which library they belong, so here the categorizations could make sense.
still, I think this is much more important for documentation and pedagogical reasans than with relation to avoiding nameclashes or similar, because then we would still end up with two gate objects in the same categorization...
btw I also care more about the functionality of an object than whether it is implemented as a C-external, an abstraction or a lua script. so again a good reference, documentation and communication of available object classes is what I think is missing most.
marius.
with some libraries this
João Pais wrote:
just a couple fast general comments (must leave in 15m):
- how about 3 (?) general categories, where everything else is organised?
It might be easier to keep everything in mind.
- glue/control
- singal/audio
- GUI
(probably there are more main categories?)
- maybe it's time easier to make a puredata.org page for this? and open it
to the main list?
will try to give concrete comments later.
Luke Iannini a écrit :
And, here's an example from my own sfruit/ collection:
i try to make some correction to add somes stuff...
gui/ (for extending, interacting with, or working around limitations of the IEMGUIs) ds-gui/ ds-abs/
input 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/
network 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/
filter effects table
os/
physical_model matrix preset ...
cyrille