[PD] pix_record mixed pixes

[Danks, Mark]

  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 at iem.at [mailto:pd-list-bounces at 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 at 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?

 

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puredata.info/pipermail/pd-list/attachments/20061207/bbb23f59/attachment.htm>