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
_______________________________________________ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list