> i'm still reluctant to include "random" simple objects into streamline Gem. > in the given case i will most likely include it, but be prepared that > once i find a decent [pix_expr] implementation that object will be > replaced by an abstractions.
I agree. I am still not in peace with the fact that any little pixel operation in Pd has to be written in C++, or else expressed in a combination of objects as if they were weird symbols in a high level messy language. You have to really know each pix_ object and express your idea in that irregular language. Only to realize that it can't be expressed in this language, and only then you write your simple C++ loop. This must be a sign that something is not right with the approach, or that this is just an expected drawback of the Pd paradigm. I'm not sure as I am not that experienced with Pd, but I've been willing to live with that drawback anyways. Not sure how the high number of users that are not familiar with C++ deal with this drawback/frustration. Regarding the normalization of color to the 0-1 range, I was aware of it, but was not comfortable adhering to it in practice, since in the [pix_equal] case any round-offs may cause you pick out the wrong pixels. [pix_equal] needs to be precise, I want pixels with R=156 and *not* R=155. Worse, even: if you want R=0 and, after normalizations and denormalizations you get back to, say R=0.00001, you won't pick out any R=0 pixels. I actually faced that issue when I was writing [pix_equal]. Integers are very good for this situation. Moreover, I have seen other pix_* objects use the 0-255 range. Could we keep it not normalized? > > also, i'd like to point to the existance of frei0r and FreeFrame-1.0 > plugins, that would allow you to write code once for a large number of > hosts, and which integrate seemlessly into Gem as well - at least for > algorithms that don't do any fancy analysis which has to be output in > non-pix form (like [pix_multiblob]) This is very interesting! I was aware of frei0r but didn't think the approach went beyond just algorithms useful for visual effects (filters for VJ and video editing software). I will keep this in mind. _______________________________________________ GEM-dev mailing list [email protected] http://lists.puredata.info/listinfo/gem-dev
