hc gilje

 with some really useful keystone, masking and warping tools made by David Fortmann.

Basically I am doing a very simple thing with the masking patch: moving the movie source to a separate patcher and then just using send and receive. 

This works as expected with jit.movie and jit.playlist, but when I do this with a vizzie.playr object nothing is displayed in the render window. If I have a vizzie.playr object in the masking window it works.

So it seems this particular jit.gl.pix code struggles for some reason, because if I send a vizzie.playr stream remotely to the jit.gl.pix example file it works.

Attached is the modified masking file, the MGraphics.js and the remote source sender.

This is with latest 8.2 version of Max on a mac.

Masking2mod.maxpat

remotesource.maxpat

MGraphics.js

Hi,
I am trying to modify a patch from this thread with some really useful keystone, masking and warping tools made by David Fortmann.
btw, these tools are available on his github page
Basically I am doing a very simple thing with the masking patch: moving the movie source to a separate patcher and then just using send and receive. 
This works as expected with jit.movie and jit.playlist, but when I do this with a vizzie.playr object nothing is displayed in the render window. If I have a vizzie.playr object in the masking window it works.

This is with latest 8.2 version of Max on a mac.

HC


Hi,
I am trying to modify a patch from this thread with some really useful keystone, masking and warping tools made by David Fortmann.
btw, 

vizzie-jit-gl-pix-woes

I think I got this working by switching to gl3 engine in the prefs. 

Does that mean there is something incompatible with gl2 in the vizzie objects in 8.2?

I think I got this working by switching to gl3 engine in the prefs. 
Does that mean there is something incompatible with gl2 in the vizzie objects in 8.2?


hi hc, this is an unfortunate side effect of how vizzie deals with external contexts. The official answer is to always use a PROJECTR context as your main context when using vizzie modules, especially across top-level patch boundaries. that is the only way to ensure correct output timing to play nicely with non-vizzie gl.slab and gl.pix objects.

unofficially, you can force correct timing by sending the external feed to a jit.gl.texture @thru 0, and then bang the texture with the context render bang to output through your slab-chain.

in a not too distant update I hope to have resolved some of the current limitations with vizzie and non-PROJECTR contexts so that it works more seamlessly and avoids some of these wrinkles.

hi hc, this is an unfortunate side effect of how vizzie deals with external contexts. The official answer is to always use a PROJECTR context as your main context when using vizzie modules, especially across top-level patch boundaries. that is the only way to ensure correct output timing to play nicely with non-vizzie gl.slab and gl.pix objects. 

ok, this is slightly confusing, but thanks for the workaround which seems to work great.

So the fact that I got it to work with the gl3 engine and not with the gl2 engine is not related?

I normally don´t use the vizzie modules, but thought they would be useful for a workshop I am teaching.

Hi Rob,
ok, this is slightly confusing, but thanks for the workaround which seems to work great.

So the fact that I got it to work with the gl3 engine and not with the gl2 engine is not related?

I normally don´t use the vizzie modules, but thought they would be useful for a workshop I am teaching.


vizzie + jit.gl.pix woes