flags, etc. I probably would do it differently today, but
back when an SGI Indy was top of the line it was a different story :-)
Mark
> -Original Message-
> From: Mathieu Bouchard [mailto:[EMAIL PROTECTED]
> Sent: Friday, December 08, 2006 6:40 PM
> To: Danks, Mark
> Cc:
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:[EMAIL PROTECTED]
> Sent: Thursday, December 07, 2006 7:49 PM
> To: chris clepper
>
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 message
t; To: Danks, Mark
> Cc: pd-list@iem.at
> Subject: Re: [PD] pd on ps3
>
> On Tue, Nov 21, 2006 at 07:22:17PM -0800, Danks, Mark wrote:
> > On a random note, I actually got PD and GEM running on a PS2 a few
> years ago...it is possible.
>
> That's awesome. Was that on
I'll chime in, although I can't say too much about this due to NDA issues...
There is no reason you couldn't have the DSP networks running on the SPUs.
You wouldn't want to bother with having a full fledged PD instance on the SPU
(it wouldn't fit anyways). However, if you rewrote the ~ obj
