[PD-dev] [GEM] pix_blur ???? which Gem-objects do we need (have) ?

IOhannes zmoelnig zmoelnig at iem.kug.ac.at
Wed Feb 19 21:07:49 CET 2003


Hi list, hi chris.

Maybe a stupid question:
What is this [pix_blur] for ?
Hey, i don't want to be rude (mr. bad guy again....), but there already 
is a thing like [tv_biquad] that does very similar things (and more)

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.

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 see the point, that a 1-stage filter needs less CPU-power than a 
2-stage filter.
But imo, this should rather lead to a general object (like [tv_filter]; 
i can't think clearly right now, but [tv] indicating that it works in 
time-domain and "filter", should make clear what is meant; maybe 
[tv_iir] would be better), that can do all lengths of recursive 
filterings (and is loop-unrolled for low orders) and can have clipping 
turned on/off (or not)

And I would like to have more control over the filter-paramters: i 
prefer "y(t)=a*x(t)+b*y(t-1)" to "y(t)=a*x(t)+(1-a)*y(t-1)", especially, 
when clipping is involved.

Ah, that leads to what i wanted to ask/state anyhow:
Is it possible to make objects that perform "scientific tasks" (like 
convolution) rather than "folkloristic FX" (like smoothing)
[pix_convolution] is far more powerful than [pix_smooth] could be.
And of course, you can build a [pix_smooth]-abstraction with 
[pix_convolution]
Maybe a bit of a thought before doing a "quick hack" could save 
programming-time in the long term. (ooh, this sounds really like mr. 
bad-guy. i don't want to insult anybody)

i do think, that pd is a programming language (with a lot of flaws (in 
terms of a prog-lang), sure)
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 ?


mfg.as.dr
IOhannes





More information about the Pd-dev mailing list