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?