Hey Chris,
As for FSAA the same thing happens with FSAA 2|4|6 The window is currupted even after the render message is sent if there are not gemheads. Did you try my example patch?
I don't understand how I've been using FSAA 8 the whole time and I've always gotten an AA render window?! I guess it was using FSAA 6 internally?
Since pix_rgba is unneeded, how can I use pix_mask? I simply get errors that pix_mask cannot process two YUV streams... Has this object not been updated yet?
I thought it maybe QT grabbing the device. I'll have to think around a solution. I have multiple pix_video objects because they are different instances of the same abstraction. I would like each instance to be able to grab the video... I'll have to do some more dynamic routing stuff.
Off for dinner.
Thanks, Ben
chris clepper wrote:
On Mar 20, 2004, at 7:12 PM, B. Bogart wrote:
Hey all,
Attached is an example patch of a bug I found with chris's current gem compile (march 16th).
If you create a window with FSAA 8, with no gemheads in it, or with only gemheads that are not processing the window does not seem to start rendering, and apears currupted. Without FSAA 8 the window behaves as normal.
I don't think FSAA 8X exists yet, so the bug is that numbers above 6 aren't trapped. Try 2, 4 or 6X.
Also with this same compile pix_yuv seems to be the only object that passes texture properly. pix_grey and pix_rgba seem to only pass a still image in a moving video source. See "pix_rgba_bug.pd" This is anoying because I'm trying to use live video with a pix_mask but cannot since it only seems to accept two RGBA streams, but I can't get video passing through as RGBA! (or grey)
I have no idea about this one as I haven't used pix_yuv or pix_rgba since we removed the need for them long ago.
Last and certainly least...
Looks like the first pix_video object one creates grabs the 1394 device. Any subsequent pix_video's get created, but can't grab the device so they just sit there sending (green).
Yes, this is perfectly acceptable behavior. Why are you using multiple pix_video objects anyway? The best solution is to use pix_separator and route the video that way.
I could use dynamic patching to re-instanciate the "right" pix_video, but that is really ugly... I'm thinking of pix_video as a catch~ for one particular video stream sent through throw~ I think this only effects pix_video since all other pix_ objects can have a local copy of a pix...
Sorry, this isn't going to happen. QT grabs the component instance for each device and that's it. Why not make your own catch and throw using separator and send and receive? That seems to be what Pd is all about right?
cgc
Thanks Ben
GEM-dev mailing list GEM-dev@iem.at http://iem.at/cgi-bin/mailman/listinfo/gem-dev