This is extremely helpful. I'm starting to "get" it. Comments/questions inline.
chris clepper wrote:
There are two types of objects in GEM: pix and OpenGL.
Pix objects do work in the top to bottom manner like Pd DSP objects.
would [pix_coordinate] be an exception to this? I've been playing with it and it seems to behave the way you have described OpenGL objects and not GEM objects. I read the help patch about [pix_texture] reassigning the coordinate values, but that still didn't explain all the behavior I was seeing.
The convention in GEM is to put the GL objects after the pix_ ones showing that once the pix_ processes are done on the CPU it is time for the GL processes on the GPU to start.
I understand you to be saying that the GL processes will always be applied after the pix_ processes. If that is the case, then it sounds like there is no way to have [rotateXYZ] applied before [pix_rtx]. Makes sense.
For the more general case, is it correct that there is no way in GEM to give an arbitrary rotation of an image as input to a pix_ object since there is no Gem pix_ object with arbitrary rotation function?
Figuring that might be the case, I tried to build [pix_rotate] using [pix_coordinate]...and this led me to the question about about [pix_coordinate]
Using pdp_rotate, pix_2gem and gem2pdp, I did successfully build a pix_ rotator. On the chance it might be helpful to see, I attached a demo patch which feeds a rotated video stream to [pix_rtx] then rotates the stream back to the way it was. While it more-or-less works it seems a bit scabby. Is there a better way?
There are lots of exceptions to Pd rules in GEM and there is really no way around them. It is kind of like learning English - I before E except after C, excepting all of those words that ignore the rule.
As long as I can make sense of what the rules are, which objects break them, and some rough idea as to why, I'm cool with that.
Thank you again for your help. As Hans suggests, I'd like to find a way to help organize, then share this information, whether it be on the wiki or in some other meaningful way.
-John
#N canvas 65 149 758 508 10; #X obj 95 44 gemhead; #X obj 95 67 pix_video; #X obj 235 386 pix_texture; #X obj 234 405 rectangle 4 3; #X obj 48 12 gemwin; #X msg 25 -31 create , 1; #X msg 103 -30 destroy; #X obj 24 -54 loadbang; #X obj 229 245 pix_rtx; #X obj 166 150 pdp_rotate; #X obj 184 120 pix_2pdp; #X floatatom 244 96 5 0 0 0 - - -; #X obj 167 172 pdp2gem; #X obj 116 153 gemhead; #X obj 176 96 t a b; #X msg 151 24 colorspace YUV; #X obj 149 3 loadbang; #X obj 235 331 pdp_rotate; #X obj 253 301 pix_2pdp; #X obj 236 353 pdp2gem; #X obj 185 334 gemhead; #X obj 245 277 t a b; #X obj 304 202 * -1; #X msg 231 217 set; #X obj 246 122 t f b; #X text 284 96 <- change angle of "wave" of rtx; #X connect 0 0 1 0; #X connect 1 0 14 0; #X connect 2 0 3 0; #X connect 5 0 4 0; #X connect 6 0 4 0; #X connect 7 0 5 0; #X connect 8 0 21 0; #X connect 9 0 12 0; #X connect 10 1 9 0; #X connect 11 0 24 0; #X connect 12 0 8 0; #X connect 13 0 12 0; #X connect 14 0 10 0; #X connect 14 1 10 0; #X connect 15 0 1 0; #X connect 16 0 15 0; #X connect 17 0 19 0; #X connect 18 1 17 0; #X connect 19 0 2 0; #X connect 20 0 19 0; #X connect 21 0 18 0; #X connect 21 1 18 0; #X connect 22 0 17 1; #X connect 23 0 8 0; #X connect 24 0 9 1; #X connect 24 0 22 0; #X connect 24 1 23 0;