vade

Yes its me again! Can someone please take a look at this patch, and 

I have a jit.qt.movie @unique 1, with a LOW framerate, which is 

setting the contents of two textures which feed a and b side of a mixer.

This mixer has a gate on it, which demonstrates the bug.

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 

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 

I believe the proper behavior is that gate OPEN is the SAME as gate 

Anyone care to explain whats going on here behind my back? I need the 

above functionality for a project - specificially for frame blending 

two frames of a movie to make low framerates looks nicer. Regardless 

of the specific goal, I think this behavior makes little sense....

Yes its me again! Can someone please take a look at this patch, and  
verify that its behavior makes sense?

I have a jit.qt.movie @unique 1, with a LOW framerate, which is  
setting the contents of two textures which feed a and b side of a mixer.
This mixer has a gate on it, which demonstrates the bug.

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.

Anyone care to explain whats going on here behind my back? I need the  
above functionality for a project - specificially for frame blending  
two frames of a movie to make low framerates looks nicer. Regardless  
of the specific goal, I think this behavior makes little sense....

bug-with-jit-gl-slab-and-automatic-0

> 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 

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 

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 

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 

Let us know if there's still any confusing behavior.

> 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.

On Jan 9, 2008, at 1:28 PM, Joshua Kit Clayton wrote:

> 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).

Okay, I got all excited by taking some time to play with Jitter 

(rather than being nose deep in Max 5 development), that I kept 

fooling around and figured I should show you how to do this latter 

approach (since that's probably more what you want for your frame 

blending). This is actually pretty tricky to do if you don't know 

exactly how texture's dynamic mode works, and how jit.gl.slab uses 

the incoming texture name rather than copying. To have a true delay 

line which copies the data so that it can work with such a strategy, 

you'll need to do something like the following. If you don't want the 

extra CPU data copy that texture mode static employs you could just 

add another jit.gl.texture -> jit.gl.slab @thru 0 after the top right 

hand jit.gl.slab. Kinda tricky, I know, but these thigns are done to 

> 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).

Okay, I got all excited by taking some time to play with Jitter  
(rather than being nose deep in Max 5 development), that I kept  
fooling around and figured I should show you how to do this latter  
approach (since that's probably more what you want for your frame  
blending). This is actually pretty tricky to do if you don't know  
exactly how texture's dynamic mode works, and how jit.gl.slab uses  
the incoming texture name rather than copying. To have a true delay  
line which copies the data so that it can work with such a strategy,  
you'll need to do something like the following. If you don't want the  
extra CPU data copy that texture mode static employs you could just  
add another jit.gl.texture -> jit.gl.slab @thru 0 after the top right  
hand jit.gl.slab. Kinda tricky, I know, but these thigns are done to  
make the GPU code faster.

You are totally correct - a right to left bug - my god, staring at 

that forever it just was invisible to me. Ive added a different delay 

Thanks, ugh, n00b error! :) Im glad I added that (?) to my bug report :D

On Jan 9, 2008, at 4:28 PM, Joshua Kit Clayton wrote:

> 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?

You are totally correct - a right to left bug - my god, staring at  
that forever it just was invisible to me. Ive added a different delay  
method, now it seems to work.

> 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?


Thanks JKC! Im glad you could take a breather from Max 5! (NOW GET 

BACK TO WORK! ;), and thanks to taking the time to explain some of the 

subtle internals of the GL stuff. Its nice to know a bit of what is 

Here is a GPU powered frame blending movie player add on that lets you 

turn the rate of your movies down REALLY SLOW (0.01 etc) and does 

frame blending to make the result smooth and not 'pop' the next frame 

This makes going slow much easier on the eyes.

Some might like to add a little tp.slide.jxs 'sliding' action perhaps 

in there, but I am not so sure it is needed, but tweak away.

Thanks again JKC, (note - has a few loadbangs - ).

Thanks JKC! Im glad you could take a breather from Max 5! (NOW GET  
BACK TO WORK! ;), and thanks to taking the time to explain some of the  
subtle internals of the GL stuff. Its nice to know a bit of what is  
going on behind the scenes.

Here is a GPU powered frame blending movie player add on that lets you  
turn the rate of your movies down REALLY SLOW (0.01 etc) and does  
frame blending to make the result smooth and not 'pop' the next frame  
in.

Some might like to add a little tp.slide.jxs 'sliding' action perhaps  
in there, but I am not so sure it is needed, but tweak away.

doesnt work on jiiter 1.6.3, max 4.6.3, macbook pro 2.4

max window reports that jit.qt.movie and jit.matrix don't understand outname

argument. there is out_name for jit.qt.movie bun not for jit.matrix

i guess you are using experimental jitter framework. is it stable?

doesnt work on jiiter 1.6.3, max 4.6.3, macbook pro 2.4
max window reports that jit.qt.movie and jit.matrix don't understand outname
argument. there is out_name for jit.qt.movie bun not for jit.matrix

No that was my stupid bug - thats what I get hacking around at 5am. I 

have a working version im about to post. It has an odd issue where the 

render context needs to be rebuilt after being turned on. No idea why.

On Jan 10, 2008, at 5:04 PM, klif _ wrote:

> doesnt work on jiiter 1.6.3, max 4.6.3, macbook pro 2.4

> max window reports that jit.qt.movie and jit.matrix don't understand 

> outname argument. there is out_name for jit.qt.movie bun not for 

> i guess you are using experimental jitter framework. is it stable?

No that was my stupid bug - thats what I get hacking around at 5am. I  
have a working version im about to post. It has an odd issue where the  
render context needs to be rebuilt after being turned on. No idea why.

> doesnt work on jiiter 1.6.3, max 4.6.3, macbook pro 2.4
>
> max window reports that jit.qt.movie and jit.matrix don't understand  
> outname argument. there is out_name for jit.qt.movie bun not for  
> jit.matrix
>
>
> i guess you are using experimental jitter framework. is it stable?
>
> klif


Bug (?) with jit.gl.slab and @automatic 0