[PD-dev] Proposals for object categories

[IOhannes m zmoelnig]

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