It would be great to have some of this documented better. I mentioned
in the book sprint email that there are lots of Gem examples, but
there isn't really any text that I could find that introduces these
concepts of Gem.
So if you do figure this stuff out, please join us for the book
sprint, or point us to your findings so someone can write it up!
.hc
On Mar 25, 2009, at 1:17 PM, Ben Baker-Smith wrote:
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
----------------------------------------------------------------------------
Programs should be written for people to read, and only incidentally
for machines to execute.
- from Structure and Interpretation of Computer Programs
_______________________________________________
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management ->
http://lists.puredata.info/listinfo/pd-list
