[PD] pix_record mixed pixes

[Danks, Mark]

Actually, this one is more complicated, because it involves the
underlying pix buffer.  That has nothing to do with OpenGL...

Mark

> -----Original Message-----
> From: Chris McCormick [mailto:chris at mccormick.cx]
> Sent: Thursday, December 07, 2006 7:49 PM
> To: chris clepper
> Cc: Danks, Mark; Mathieu Bouchard; pd-liste; vincent Rioux; IOhannes m
> zmoelnig
> Subject: Re: [PD] pix_record mixed pixes
> 
> On Thu, Dec 07, 2006 at 01:00:04PM -0600, chris clepper wrote:
> > On 12/7/06, Danks, Mark <MDanks at ea.com> wrote:
> > >   Reversing the order pix_invert and pix_record will still apply
the
> > >invert?it will just happen after the pix_record happens.
> >
> > That is a much clearer way to say what I was try to say.  The
inversion
> will
> > not be applied to the image input to pix_record, but the processing
> would
> > still happen.
> 
> Well, I don't want to speak for Matju, but I think what he's saying is
> that he realises this, but it is counter intuitive and suprising. If I
> have a dsp or message graph and I send the output of something through
> some modifiers, I don't expect those modifiers to be automatically
applied
> to another cable going somewhere else. I expect modifiers further down
> the tree to only effect things on the same branch. Essentially, when
> patching Gem, you have to be even more aware of the order of
operations
> than when just regularly patching dsp, because operations on one
branch
> of the graph can affect operations on another branch of the graph. I
> guess one way to 'fix' that (and break backwards compatability) would
> be perform a GLPushMatrix every time there is a fork in the graph,
> and a GLPopMatrix every time you get to a leaf node.
> 
> Best,
> 
> Chris.
> 
> -------------------
> chris at mccormick.cx
> http://mccormick.cx