[PD-dev] [GEM] pix_blur ???? which Gem-objects do we need (have) ?

[IOhannes zmoelnig]

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