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