[jitter] Bug (?) with jit.gl.slab and @automatic 0
Joshua Kit Clayton
jkc at musork.com
Wed Jan 9 14:28:02 MST 2008
- Previous message: [jitter] Bug (?) with jit.gl.slab and @automatic 0
- Next message: [jitter] Bug (?) with jit.gl.slab and @automatic 0
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
On Jan 9, 2008, at 11:52 AM, vade wrote: > if the gate is closed, the mixer is only banged to render when the > textures are updated, IE, at a slow rate. > > If the gate is open, the mixer renders at the main clock speed. The > output of the mixer is this mode is NOT the same as when the gate > is closed, even though the contents of the textures and their > assignment REMAINS THE SAME (this is the bug) > > The patch below demonstrates. I do not think this behavior is > correct. If the contents of the textures are not changing during > the bangs that the slab mixer is being updated. > > I believe the proper behavior is that gate OPEN is the SAME as gate > CLOSED. Wrong. Perhaps you are misunderstanding what the bang message does. It renders the slab with the current input textures, which in your patch are *both* the same frame. Please look at your trigger logic and think carefully about what the right input is and when--i.e. it sets the left texture, then immediately sets the right texture, so they are only different frames for the duration *between* the two list outputs of your trigger object. This works with the gate closed, since it is the first list output from your trigger which causes the slab to render. However, when you are banging from your gate, they are now the same frame. Make sense? The solution to such a situation is to just add an instance of jit.gl.texture, which is banged by your gate instead, as the attached modified patch demonstrates, or to have a single frame delay stage which works differently than your logic (i.e. doesn't update the right input immediately following, but instead keeps in an external jit.gl.texture and updates immediately *before* sending the current frame into the jit.gl.slab). Btw, I don't think you need any @automatic 0, or @adapt 1 entires in this patch since that's the default for jit.gl.slab and jit.gl.texture, but perhaps you just added them out of voodoo trying to track this down. Let us know if there's still any confusing behavior. -Joshua #P window setfont "Sans Serif" 9.; #P window linecount 1; #P newex 332 695 204 196617 jit.gl.texture v001 @automatic 0 @adapt 1; #P window linecount 3; #P comment 622 613 99 196617 High mix amount to visually see differences.; #P window linecount 2; #P comment 646 508 99 196617 New Frame and Old Frame.; #P user gswitch 317 400 41 32 0 0; #P window linecount 1; #P newex 425 506 204 196617 jit.gl.texture v001 @automatic 0 @adapt 1; #P newex 754 506 204 196617 jit.gl.texture v001 @automatic 0 @adapt 1; #P newex 772 451 27 196617 b; #P user jit.fpsgui 773 471 60 196617 0; #P newex 449 451 27 196617 b; #P user jit.fpsgui 449 471 60 196617 0; #P user jit.fpsgui 467 317 60 196617 0; #P message 302 121 107 196617 jitter glreadback fbo \;; #P message 303 104 106 196617 jitter glreadback rtt \;; #P newex 395 317 40 196617 t b l l; #P newex 754 423 327 196617 jit.gl.slab v001 @automatic 0 @file cc.uyvy2rgba.jxs @dimscale 2. 1.; #P flonum 594 592 35 9 0 0 0 3 0 0 0 221 221 221 222 222 222 0 0 0; #P newex 500 630 103 196617 pak param amount 0.; #P flonum 442 247 35 9 0 0 0 3 0 0 0 221 221 221 222 222 222 0 0 0; #P message 441 267 44 196617 rate \$1; #P newex 425 423 327 196617 jit.gl.slab v001 @automatic 0 @file cc.uyvy2rgba.jxs @dimscale 2. 1.; #P newex 425 667 327 196617 jit.gl.slab v001 @automatic 0 @file co.normal.jxs @param amount 20.; #P message 395 171 30 196617 read; #P newex 276 765 269 196617 jit.gl.videoplane v001 @transform_reset 2 @automatic 0; #P newex 395 286 286 196617 jit.qt.movie @adapt 1 @unique 1 @colormode uyvy @rate 0.1; #P newex 275 198 40 196617 t b b b; #P toggle 120 89 15 0; #P newex 120 115 51 196617 qmetro 2; #P newex 120 153 58 196617 t b b erase; #P newex 180 788 157 196617 jit.window v001 @depthbuffer 1; #P newex 120 306 92 196617 jit.gl.render v001; #P comment 438 171 341 196617 load a movie please.; #P window linecount 24; #P comment 156 371 94 196617 someone explain to me why turning this gate on seems to replace the values of my mixers second input (the texture)? Regardless of how fast I bang my mixer I should get the same results of the contents of the textures it is currently using. No? My textures are only updated when the jit.qt.movie updates. Thus its value and contents SHOULD NOT CHANGE during bangs to the mixing slab? Am I crazy?; #P user panel 306 393 65 47; #X brgb 255 0 0; #X frgb 0 0 0; #X border 1; #X rounded 0; #X shadow 0; #X done; #P connect 29 0 32 0; #P connect 32 0 10 0; #P connect 12 0 32 0; #P connect 13 0 28 0; #P connect 13 0 24 0; #P connect 26 0 25 0; #P connect 18 0 26 0; #P connect 18 0 27 0; #P fasten 19 1 18 0 415 384 759 384; #P connect 27 0 12 1; #P connect 17 0 16 2; #P connect 9 0 19 0; #P connect 9 0 22 0; #P connect 24 0 23 0; #P connect 15 0 14 0; #P connect 16 0 12 0; #P connect 28 0 12 0; #P connect 19 2 13 0; #P connect 14 0 9 0; #P connect 11 0 9 0; #P connect 8 2 9 0; #P connect 8 1 29 2; #P connect 8 0 10 0; #P fasten 5 1 8 0 149 184 280 184; #P connect 5 2 3 0; #P connect 5 0 3 0; #P connect 6 0 5 0; #P connect 7 0 6 0; #P window clipboard copycount 33;
- Previous message: [jitter] Bug (?) with jit.gl.slab and @automatic 0
- Next message: [jitter] Bug (?) with jit.gl.slab and @automatic 0
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
