Hi John,

You are correct.  Gem does not follow the normal top to bottom rules of PD.  I believe its render chain has more to do with the rules of OpenGL than with PD.

Sorry I can't give you an easy way of figuring which objects will be processed first.  If there is one then I've never heard/read it.  Keep experimenting.

For more information on this, I recommend looking up the "a flawed Gem" thread in the PD-List archives (and whatever thread that came out of). 
It'll give you some more information about Gem's relation to OpenGL and some users frustration with similar situations as yours.

I love using Gem, it's the environment I primarily work in when using PD.  However, it's a bit of a wild beast (at least to a non-programmer like myself).

Best of luck,
-Ben



>[Gemhead]
>|
>[object 1]
>|
>[object 2]
>|
>[object 3]
>
>we cannot conclude that the output of [object 1] feeds the input of [object
>2] and the output of [object 2] feeds the input of [object 3]. We only know
>that the data will be processed by objects 1, 2 and 3 but not in what order
>they will be processed.
>
>Further perhaps we cannot conclude that the output of an object is actually
>the result of the object having processed the data. Demonstrating this: in
>my patch example, [pix_buffer_write] outputs different data than it stores,
>or examples 1 and 3 would be the same.
>
>And this leads me to a more general statement of my original question: how
>can I determine the order in which objects are processed in Gem?
>
>And my specific example which started this thread: how would one apply a
>rotation to an image, then apply [pix_rtx] to the rotated image?
>
>-John