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

bbogart bbogart at ryerson.ca
Thu Feb 20 17:38:03 CET 2003


hello all,

I think its good to have less objects that have more functionality, but 
by the same token that intimidates new users and if we were to go in 
that direction I think a large number of abstractions, or at least more 
in depth help files to cover "known" uses of these complex objects. 
These complex objects would end up with much larger more complex help 
files, which I think is a good thing.

I do also think redundancy is bad, and that a particular operation 
should be as abstracted from its data-type as possible. (this whole tv. 
vs pix. is already confusing me. why not one set of objects for 
image-manipulation, with the ability to apply as texture... )

my 2 cents

Looking forward to trying to openGL wrapper stuff.

Ben

On Wednesday, February 19, 2003, at 03:07 PM, IOhannes zmoelnig wrote:

> 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
>
>
> _______________________________________________
> PD-dev mailing list
> PD-dev at iem.kug.ac.at
> http://iem.kug.ac.at/cgi-bin/mailman/listinfo/pd-dev





More information about the Pd-dev mailing list