Hans-Christoph Steiner wrote:
I don't think we should try to come up with an hierarchy in which everything can fit. pix_sig2pix~ can stay in Gem for now. This should be the standard libs of common things, which is currently split across libs like vanilla, zexy, list-abs, creb, etc.
sorry for being unclear, this is clearly a misunderstanding.
i used [pix_sig2pix~] as an example about how categories often fail. it was the first object that came to my mind that clearly belongs into several categories at the same time. there are other objects (within zexy, vanilla, list-abs, creb, you-name-it) that are not simply "glue" or "math", but both and more.
and this is not necessarily a design problem of these objects (though sometimes it might well be).
fortunately loads of object do belong to a simple category, so don't let Gödel stop us from trying to define such categories.
however what i think is relevant is that all categories should be on the same level. e.g. "complex-math" and "signal" are categories on different levels: nothing keeps you from doing complex-math in signal-domain.
otoh, the object interface for doing complex-math in signal-domain might look significantly different than the one in message-domain, or image-domain, or matrix-domain. so, not all objects doing complex-maths (in various domains) should go into the same category "complex-math"
if we have fixed (library-like) categories, then objects should not wander through categories either. otoh, categories should have more than one entry. e.g. if we only have a single bandlimited oscillator, why would we create a category "bandlimitedosc~" rather than just put it into the "osc~" group (btw, should [osc~] itself go into the bandlimitedosc~ group or not?). but when enough blosc~s show up to form a separate category, should we move our original osc into the new group? so people cannot find it anymore.
or should we just have a handful of really big groups? who would be willing to maintain them (e.g. the "fx~" group)
mf.ar IOhannes