|IOhannes zmoelnig||Feb 19, 2003 12:07 pm|
|chris clepper||Feb 19, 2003 6:21 pm|
|bbogart||Feb 20, 2003 8:37 am|
|zmoe...@iem.at||Feb 21, 2003 12:38 am|
|guenter geiger||Feb 21, 2003 3:33 am|
|Me||Feb 21, 2003 7:36 am|
|Matthew Allen||Feb 21, 2003 10:10 am|
|chris clepper||Feb 21, 2003 10:47 am|
|chris clepper||Feb 21, 2003 11:58 am|
|IOhannes zmoelnig||Feb 24, 2003 2:48 am|
|guenter geiger||Feb 24, 2003 5:33 am|
|chris clepper||Feb 24, 2003 11:00 am|
|IOhannes zmoelnig||Feb 24, 2003 11:29 am|
|Subject:||Re: [PD-dev] [GEM] pix_blur ???? which Gem-objects do we need (have) ?|
|Date:||Feb 20, 2003 8:37:41 am|
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.
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 ?
_______________________________________________ PD-dev mailing list PD-...@iem.kug.ac.at http://iem.kug.ac.at/cgi-bin/mailman/listinfo/pd-dev