[PD] still struggling with basic understanding of Gem dataflow

Ben Baker-Smith bbakersmith at gmail.com
Wed Mar 25 18:17:26 CET 2009


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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puredata.info/pipermail/pd-list/attachments/20090325/5978c866/attachment.htm>


More information about the Pd-list mailing list