Keep in mind that GEM builds a graph based on the pointers when you turn on rendering.  Pix_invert and pix_record are both using that same pointer, and the [t] object is simply controlling the order of the graph that is constructed.  In fact, when rendering, the [t] object doesn’t get any messages at all…all messages/events are happening in that constructed graph.  This basically the same as how the ~ objects work.

  Reversing the order pix_invert and pix_record will still apply the invert…it will just happen after the pix_record happens.

Mark

---

From: pd-list-bounces@iem.at [mailto:pd-list-bounces@iem.at] On Behalf Of chris clepper
Sent: Thursday, December 07, 2006 10:07 AM
To: Mathieu Bouchard
Cc: pd-liste; vincent Rioux; IOhannes m zmoelnig
Subject: Re: [PD] pix_record mixed pixes

On 12/7/06, Mathieu Bouchard <matju@artengine.ca> wrote:

what's a lot more surprising is that

[pix_video]
  |
[pix_gain]
  |
[t a a]
  |   |
  |  [pix_invert]
  |
[pix_record]

actually applies [pix_invert], because gem messages handle pix (and all
the other state) by pointer, so that the pix seemingly sent from
[pix_gain] to [pix_record] is actually modified although the message sent
isn't modified.

This doesn't necessarily happen in other video plugins.

Reversing the order of pix_invert and pix_record won't apply the inversion though.  That would be consistent with the rest of Pd messaging right?