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