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.
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)
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).
Until pix_video supports multiple devices (please please), or even after, it would be useful if all pix_video objects send out the same video no matter which particular instance is attached to the device. This feature would be nice because one may have more than one pix_video in a patch (in multiple chains) but may want to switch on the fly between pix_movie and pix_video (by spigoting the gemchain) Just because there is more than one pix_video in a patch does not mean that they are indeed sending video to the screen... Maybe the last pix_video to be switch on (in a chain) could grab the video..? rather than the first one instanciated...
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...
Thanks Ben
#N canvas 455 239 454 304 10; #X obj 23 119 gemwin 30; #X msg 71 85 0 , destroy; #X msg 43 63 FSAA 8 , create , 1; #X obj 65 223 gemhead; #X obj 65 246 square; #X obj 54 171 loadbang; #X msg 62 195 0; #X msg 98 197 1; #X text 133 198 <- turn it on , and it works.; #X connect 1 0 0 0; #X connect 2 0 0 0; #X connect 3 0 4 0; #X connect 5 0 6 0; #X connect 6 0 3 0; #X connect 7 0 3 0;
#N canvas 506 132 647 313 10; #X obj 183 80 gemhead; #X obj 186 106 pix_film; #X obj 212 200 pix_texture; #X obj 215 249 square 4; #X obj 249 106 t f; #X obj 198 172 pix_rgba; #X obj 214 223 alpha; #X obj 24 144 gemwin 30; #X msg 72 110 0 , destroy; #X msg 241 13 bang; #X obj 249 35 openpanel; #X msg 273 61 open $1; #X msg 44 88 create , 1; #X msg 116 46 auto 1; #X obj 103 13 loadbang; #X obj 209 138 tgl 15 0 empty empty empty 0 -6 0 8 -262144 -1 -1 0 1; #X text 231 139 <- moving image w/out pix_rgba on , same for pix_grey. Only pix_yuv passes moving image.; #X connect 0 0 1 0; #X connect 1 0 5 0; #X connect 1 2 4 0; #X connect 2 0 6 0; #X connect 4 0 1 1; #X connect 5 0 2 0; #X connect 6 0 3 0; #X connect 8 0 7 0; #X connect 9 0 10 0; #X connect 10 0 11 0; #X connect 11 0 1 0; #X connect 12 0 7 0; #X connect 13 0 1 0; #X connect 14 0 13 0; #X connect 15 0 5 0;
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
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
Hi.
don't know much about the FSAA stuff, but for the [pix_rgba] read on:
Zitiere "B. Bogart" ben@ekran.org:
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
hmmm i certainly use the [pix_rgba]/[pix_grey] a lot (and eventually [pix_yuv]) - mostly for testing other pix-objects. they work just fine with everything that i have come across. what do you mean exactly by "only pass a still image" ? does it mean, that only the first image is "passed through" and the rest is kind of blocked ? this might be due to performance tuning on the mac-side (client-storage textures), but i don't know exactly. does it work, when you send a [client_storage 0(-message to the [pix_texture] pbject ?
mfg.asd.r IOhannes