[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