- dicussion on the list
ok not much can be done there so we'll make the best of it. maybe there are some people who are willing to test compiles and features on each platform that aren't developers? that would help out a lot.
- [pix_*] and [yuv_*] and [tv_*]
there has been much discussion that turned out (i think. did it?) that [yuv_*] should be incorporated into [pix_*]. Of course the same should be applied to the [tv_*] stuff (there are already [pix_*]-aliases, since [tv_*] was split from it.
ok, so everything is a pix_*.
- "dummy-users" vs "power-users"
i totally agree with chris et al. that "dummy-users" and "power-users" are both idiotic terms. I do think that there are no "dummy-users", but i do think that a lot of programs (and probably OSs) create "dummy-users" because of ignorance, what the users are capable of. btw. has not the term "power-users" been invented by micro$oft ?
i agree that we should not second guess GEM users. most of my work now is based on requests from people using it. most of them want as many tools as possible and have them be simple to use. and they have to be fast too!
- "high level abstractions" vs. "high level built-ins"
i think i have mad clear, that i would prefer abstractions to built-ins. guenter has made a good list of pros and cons of both of them. basically, i do think (but might, of course, be very wrong), that it all reduces to 3 points: a) speed! b) flexibility c) is it possible at all, to built a specifique function as an abstraction ? ad a) of course c-coded functions will always be faster than abstractions because of their very nature. but then, it might well be possible, that the speed-loss isn't that dramatic.
right. how about starting with the abstractions and if someone goes and optimizes them into C code then that could be available as well. one of the reasons i would like to have the specific coded convolution objects is they make more sense for yuv rather than a generic kernel. for example, edge detection usually focuses on luma only, so that right there is a pretty big increase in efficiency for yuv (slower for rgb because the luma has to be calculated). i will write an altivec version of pix_convolve at some point to hopefully get it somewhat usable performance wise. as a comparison, i used pix_convolve on a p4/2.5Ghz/winXP the other day and it took 40% cpu to process the homer.avi!! convolution is obviously something that requires a great deal of optimization for use in a real-time environment, so i'm all for doing as much as possible.
ad b) while c(++) offers the most flexibility in general, i think, that abstractions will provide more flexibility to the pd-programmer. (i chose pd, because i don't want to build my framework from scratch all the time (and when i started to use pd, i wasn't able to built my own framework at all)) abtractions can be made that have all the functionality of built-in's, but they can be seen by users. In my (a lot of my ancestors were/are teachers) opinion, users willing to learn can learn a lot from abstractions, users not willing to learn (now), will feel no difference in the usage.
both the abstracted version and the higher level built in objects can exist at the same time. so there could be a patch that illustrates how [pix_convolve] can be used to do all sorts of processes. some people would want to check this patch out and figure out how convolution works, while others might not care at all. it's best to leave this as an option to the user right?
ad c) obviously i cannot make a [pix_smooth] if there is no possibility to apply a convolution kernel.
you do have a point about not being able to make _every possible convolution possibility into it's own object, but that's why [pix_convolve] exists. i think that edge-detection and enhancement, blur, sharpen, embossing, and directional blur might cover the 'basics' of convolution. having the most common convolution processes available will let users know that they can apply these processes. of course some sort of documentation/tutorial needs to facilitate the learning process so people can make the jump from using specialized objects to the more general tools. that's really the subject of another thread though...
cgc