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: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] 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 <[EMAIL PROTECTED]> 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?
_______________________________________________ [email protected] mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
