[PD-dev] [GEM] pix_blur ???? which Gem-objects do we need (have) ?
Me
tigital at mac.com
Fri Feb 21 16:36:47 CET 2003
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
More information about the Pd-dev
mailing list