On Tue, 24 Jun 2008, Matt Barber wrote:
[tabread_tweak~] [tabread_transpose~]
I really hate to be a fart on this one
You should love it, if you intend it for the good of pd.
- I tend to greatly prefer object names which say what the object
"does," not what it is "for,"
This is one of the major points of the DIY movement.
I'm sure that there are men who buy themselves «bikini line trimmers» in pink boxes labelled «designed exclusively for women» just so that they can have more precision tailoring themselves a chin pinch, and this doesn't have anything to do with being gay or effeminate, though the peer pressure wouldn't miss making that kind of allusion or another of the same level. Some other people would use the same bikini line trimmer to perform intricate pruning on bonsaï trees.
(doesn't anyone feel embarrassed that someone talks about a bikini line trimmer on pd-list? does it make me pervert, gay, or just oblivious to social customs? doesn't that exactly prove our point? consider the object for what it can do.)
especially with rather low-level objects. IMO, the latter labeling tends to constrain one's thinking about the use of an object in a way that the former does not.
I'd say that beyond "what it does" and "what it's for", there is also "what it's marketed as" or "what you will be told that it's for", which might be the same as "what it's for", but modified and specialised to make it more obviously relevant to people's life.
A major schism in the pd world is how GEM/PDP feel somewhat more "what it's for" than pd itself, whereas GF and pd are more "what it does". This is about both the naming and how an object's multipurposeness is only multiple ways of thinking about what is the single thing that the object does, rather than have multipurposeness correspond to multiple behaviours defined separately, each matching a single "what it's for".
This is a gross generalisation. There are definitely GEM/PDP classes that were designed in a "what it does" way, and GF classes that are definitely "what it's for" in style, but when asking yourself the question of why something is different in GF than in [pix_...], that kind of difference is often the most important difference.
All of that said, I think something like the [sampler~] object proposed in another post would be much in keeping with the "user-friendly" filter objects like [bp~] (as opposed to [rpole~] and [rzero~] which are the real "building block" kinds of filter classes).
I consider [lop~] to be on essentially the same level as [rpole~], really. [rpole~] is simply a different kind of building block that appeals more to people who work in terms of so-called «transfer functions».
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801, Montréal, Québec