On Wednesday, February 19, 2003, at 03:07 PM, IOhannes zmoelnig wrote:
Hi list, hi chris.
hi IOHannes,
I think, Gem should follow pd's (vs. other libraries) object-policy: make a minimum orthogonal object-set, that let's you do "everything" you want. This implies, that there shouldn't be 2 objects, that do basically the same thing. basically [pix_blur] is a one-stage feedback-filter. [tv_biquad] is a two-stage feedback-filter.
...I sympathize with this, but the branching started early on: for example, why have a [square] AND a [rectangle]? Isn't a square just an equal side rectangle?
btw. [tv_*] was meant to "work (only) on series of images", while [pix_*] should work on single images as well. thus [pix_blur] should rather be [tv_blur] (but never mind)i do think, that pd is a programming language (with a lot of flaws (in terms of a prog-lang), sure)
...hey, I understood the difference (guess not everyone reads src/Gnu/WHATSNEW)...which brings up a point about documentation: wouldn't it be better to have one focused document rather than adding documents hither and thither? your recent readme in the OpenGL folder being an example...now there's the docs in /Gem, the docs in /Gem/docs, docs in /Gem/manual, the readme in /src/openGL, and stuff in src/Gnu...then there's the notes scattered throughout the source, and finally, the cvs commit info...not very good from the "usability" standpoint, but you seem to be quite ambivalent to that.
i do think, that Gem should be a language-extension, rather than a set of cool effects. That's why i thought it a good idea, to make this openGL-wrapping stuff (which is surely harder to use than all those ready-made Geos)
any comments ?
...well, true, pd/GEM is a programming language, and it's much higher level than the language it's written in...therefore it's likely that a pure abstraction of a function will be slower than a coded version (tho I realize that won't always be the case)...
...my view is in both camps: we need streamlined building blocks that can do many things they aren't specifically designed for, but we also need objects or abstractions that allow casual users access; otherwise, users and developers will go elsewhere...
...after recently working on the different vertex manipulation oriented geos, it really struck me that "there's got to be a better way": in other words, it was obvious that we don't need or desire a specific geo object for every possible surface/manipulation...so I'm trying to come up with other strategies that are more generalized, but I'm not there yet!
...to end, I think this is a good thing to keep in mind along with the "usability" issue; personally, I develop for this because it allows me to do other productions, not because I want to make a really "clean" tool...I really don't think that our two approaches are mutually exclusive...
...btw, I'm really enjoying the openGL stuff!
l8r, jamie