tigital wrote:
On Sunday, September 14, 2003, at 10:28 PM, chris clepper wrote:
i added help for the following
PIX's pix_background pix_blur pix_chroma_key pix_compare pix_duotone pix_mix pix_motionblur pix_roll pix_scanline
...cool!
i have been ill the last days and thus have done a lot of documentation. somebody has noted a while ago: great minds tend to think alike ;-) i have integrated yours into mine and committed them but will commit mine for quite all the rest (still missing and NOT on my TODO-list are: pix_convert pix_dv pix_emboss pix_depot pix_get pix_put pix_movieYUV pix_test
some of them might be in my local copy only ;-) )
i'm not sure what the following objects even do (or why they exist):
pix_pix2sig~.pd or pix_pix2sig.pd?
well, the object should be named [pix_pix2sig~] (which is in fact an alias for [pix_pix2sig]). it is the inverse of [pix_sig2pix~] (which is documented neately now) and btw is a very cool object (in my opinion)
pix_test - nothing?
really nothing, it is just somthing to test. have i committed it to the cvs ?
pix_emboss - looks like my old yuv_ object to try and make a fast
it is. i consider it not functional and have not documented it.
pix_rds pix_dot - does this work?
i have also made changes to the srces:
one of my major issues is to get rid of values between 0 and 255. this range exists for purely technical reasons. In Gem all these ranges (eg: colors) have been handled as floats (0..1) for a long time. This (the history of Gem) is the only reason why i think we should try to make all limited ranges go from 0.0 to 1.0. and i think it is nice to have only one range to remember.... and now the big: SO::
[pix_duotone], [pix_posterize], [pix_backlight], [pix_mix] now all work with values between 0..1. this will surely break some patches :-( most of the controls for these objects had to be commited via a message to the first inlet. i have made additional inlets for the controls. this would have made it easy to give different names to (the old) uchar- and to (new) normalized values, but unfortunately i have thought of this very lately. i think one of the objects features this, but the others will break things.
[pix_chroma_key]: changed the default to m_processOnOff=1. it is very disturbing if some of the pix_fx have to be turned on, while others work as soon as they are connected. we cannot change the default behaviour for all pix_fx to not do anything before they are explicitly turned on (because it would break all(!) patches with pix'es) and i don't think that it is good to have some turned on and some turned off.
[pix_compare]: m_processOnOff=1 (see above). additionally i have changed the behaviour to compare luminances rather than the rgb-channels separately. this should make it more compatible to the YUVprocessing.
some YUV/Gray support for [pix_]-objects Geos: [rubber]/[ripple]: both have now arguments that allows to specify the number of segments of the grid. i haven't yet changed it, but i would prefer the ctrX and ctrY value be rather normalized. What should the sizeMess do exactly ? Right now it does nothing. Should we remove it or just put a glScale inside the object (but this could be done outside too) i have made at least the "height" message do something intelligent.
i have no idea what the inletFov is for at [ripple]
[newWave]: added some sense to the heightMess