Hi all.

I've just had a long discussion with my girl-friend, and she said, that it's hard to discuss with me, since i won't give in. Maybe she is right, and i should re-think.

0. dicussion on the list ~~~~~~~~~~~~~~~~~~~~~~~~ unfortunately i have to do my "alternative service" for 7 more months (in october i'll be free (like in "software") again) that's why i'm not so much online (my internet-connection at home is rather sad), and that's why i'm not able to do following as much as i like: update changes i make to the CVS, get changes others made from the CVS, comment these changes, answer all mails that should be answered. Sorry

1. [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.

2. "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 ?

3. "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.

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.

ad c) obviously i cannot make a [pix_smooth] if there is no possibility to apply a convolution kernel.

Conclusions/Solutions: ======================

0. my online presence ~~~~~~~~~~~~~~~~~~~~~ cannot do much about this. sorry

1. [tv_*] ~~~~~~~~~ i will put all tv-objects back into pix

2. dummy-users vs. power-users ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ do not exist. don't let Gem generate some

3. abstractions vs built-ins ~~~~~~~~~~~~~~~~~~~~~~~~~~~~ note: this is not intended to be authoritative but a suggestion: abstractions: use abstractions when it is possible without to much speed-loss, whatever is "too much"... built-ins: keep them as flexible as possible (without too much speed-loss). make them as optimized as possible.

=========================== so i have written down a lot of obvious chunk.

mfg.asd.r IOhannes