MBroach

I’m having an interesting problem creating working video feedback on a patch I’ve created. Part of the patch, which I’m calling “video keys,” triggers different parts of a video as different notes on a midi keyboard are played. Essentially, each note triggers a different videoplane that fills a small vertical stripe of the screen, revealing part of the same video texture. The more keys down, the more of the video you see.

I’m working to get feedback/video delay functioning on these “video keys”, but I’ve been having some trouble getting it to function properly. I’m using a gl.sketch object to put all of the videoplanes into one layer, and then using capture to write that to a texture. The problem is that if I load that texture into a new videoplane, it will be entirely opaque, except for the small vertical stripes of the active, smaller videoplanes. What I’d like is for the “video key” layers to sit on top of the other videos behind them.

I’ve tried playing with the blend_mode options, but these make the “video key” parts themselves translucent. Is there a way to allow for a feedback/delay loop on the “video key” parts, which keeping them fully opaque while not blocking out the spaces in between?

I’ve attached a simplified version of my patch (with just the “video keys” part and a single background video) – normal you’d need a midi keyboard to active that “video key” layers, but you can just use the trigger boxes to turn them on and off manually.

Any help you could give would be much appreciated! Thanks!

Hey everyone-
I’m having an interesting problem creating working video feedback on a patch I’ve created.  Part of the patch, which I’m calling “video keys,” triggers different parts of a video as different notes on a midi keyboard are played.  Essentially, each note triggers a different videoplane that fills a small vertical stripe of the screen, revealing part of the same video texture.  The more keys down, the more of the video you see.

I’m working to get feedback/video delay functioning on these “video keys”, but I’ve been having some trouble getting it to function properly.  I’m using a gl.sketch object to put all of the videoplanes into one layer, and then using capture to write that to a texture.  The problem is that if I load that texture into a new videoplane, it will be entirely opaque, except for the small vertical stripes of the active, smaller videoplanes.   What I’d like is for the “video key” layers to sit on top of the other videos behind them.

I’ve tried playing with the blend_mode options, but these make the “video key” parts themselves translucent.  Is there a way to allow for a feedback/delay loop on the “video key” parts, which keeping them fully opaque while not blocking out the spaces in between?

Any help you could give would be much appreciated!  Thanks!
-matt


jitter-feedback-loop-with-partial-texture

hmm. I think you broke the patch while trying to simply it. [s keystexture] doesn't have a corresponding receive and I don't see where you're capturing to texture. I'd like to comment more, but since I can't see where the feedback is happening, I really can't help at this point.

hmm.  I think you broke the patch while trying to simply it.  [s keystexture] doesn't have a corresponding receive and I don't see where you're capturing to texture.  I'd like to comment more, but since I can't see where the feedback is happening, I really can't help at this point.


Yeah, I realized going back through it, that my simplification left a few bugs. Apologies.

However, I hadn't put the feedback in that particular version, because none of the methods of getting video feedback functioning actually worked. Nonetheless, I've got a new version below, with the bugs fixed and a demonstration of the capture problem I was talking about.

Yeah, I realized going back through it, that my simplification left a few bugs.  Apologies.

However, I hadn't put the feedback in that particular version, because none of the methods of getting video feedback functioning actually worked.  Nonetheless, I've got a new version below, with the bugs fixed and a demonstration of the capture problem I was talking about.

These errors are important and may be the cause of your problems:

name combined already in use. ob3d does not allow multiple bindings

name loopkeys already in use. ob3d does not allow multiple bindings

You have several objects with the same name. You need to give unique names to every object.

name combined already in use. ob3d does not allow multiple bindings
name loopkeys already in use. ob3d does not allow multiple bindings

You have several objects with the same name.  You need to give unique names to every object.


Whoops, thanks for catching that. I've had the problem with the unsimplified patch, though -- and when I got my names straight, it's still having the same problem.

Whoops, thanks for catching that.  I've had the problem with the unsimplified patch, though -- and when I got my names straight, it's still having the same problem.


- use layers to order object drawing instead of @automatic 0 and drawing with a bang. It will be much easier to manage. The object you want on the bottom, set @layer 0, the object on the top, @layer 1000 or something bigger than 0 so it draws last

- since you're drawing a bunch object objects with sketch that all have the same @layer value, @layer doesn't do anything since the drawing itself is triggered by sketch. Give sketch the appropriate @layer value to draw them at the appropriate time

- instead of using jit.gl.sketch, if you have max6, you might want to use jit.gl.node with @capture 1.

- when drawing with jit.gl.render, it's best to connect [t b erase] to it where erase clears the frame and the bang invokes drawing. If you need to do something before the drawing happens, use [t b b erase] and hook the middle bang to whatever needs to happen.

Here's a roughly re-organized patch. I messed with some colors to see what was going on.

- use layers to order object drawing instead of @automatic 0 and drawing with a bang.  It will be much easier to manage.  The object you want on the bottom, set @layer 0, the object on the top, @layer 1000 or something bigger than 0 so it draws last

- since you're drawing a bunch object objects with sketch that all have the same @layer value, @layer doesn't do anything since the drawing itself is triggered by sketch.  Give sketch the appropriate @layer value to draw them at the appropriate time

- when drawing with jit.gl.render, it's best to connect [t b erase] to it where erase clears the frame and the bang invokes drawing.  If you need to do something before the drawing happens, use [t b b erase] and hook the middle bang to whatever needs to happen.

Here's a roughly re-organized patch.  I messed with some colors to see what was going on.


Thanks for you comments on simplifying the patch. The automatic 0 was a holdover from when I was doing the "video keys" part as a single videoplane being drawn multiple times, as opposed to separate videoplanes.

This still doesn't solve the feedback problem, though. Any thoughts on how I can get this functioning?

Wesley -
Thanks for you comments on simplifying the patch.  The automatic 0 was a holdover from when I was doing the "video keys" part as a single videoplane being drawn multiple times, as opposed to separate videoplanes.

This still doesn't solve the feedback problem, though.  Any thoughts on how I can get this functioning?


honestly, I wasn't able to tell what the capture part of the patch was. Here's a really simple capture+sketch patch. You should be able to make it work with your stuff:

honestly, I wasn't able to tell what the capture part of the patch was.  Here's a really simple capture+sketch patch.  You should be able to make it work with your stuff:


The capture part is working fine. In the patch, the gl.sketch taking all the individual videoplanes in the "keyplanes" patcher and capturing them into a single texture named "loop." That part is functional.

The problem is that those individual videoplanes don't fill up the entire window -- they are just a number of small vertical slices. When I load those into a new videoplane, the parts that AREN'T filled with the texture show up as opaque, while I'd like them to be empty (so the video below shows through). If you activate some of the trigger boxes that feed into the "keyplanes" patcher, you'll see what I'm talking about.

Like I said, I tried fiddling with the blend_mode on the videoplane layer that is taking in the captured texture, but those make the whole thing translucent. I'd like the part in between the activated vertical slices to be empty, so that the video below shows through, while the vertical slices remain opaque.

The capture part is working fine.  In the patch, the gl.sketch taking all the individual videoplanes in the "keyplanes" patcher and capturing them into a single texture named "loop."  That part is functional.  

The problem is that those individual videoplanes don't fill up the entire window -- they are just a number of small vertical slices.  When I load those into a new videoplane, the parts that AREN'T filled with the texture show up as opaque, while I'd like them to be empty (so the video below shows through). If you activate some of the trigger boxes that feed into the "keyplanes" patcher, you'll see what I'm talking about.

Like I said, I tried fiddling with the blend_mode on the videoplane layer that is taking in the captured texture, but those make the whole thing translucent. I'd like the part in between the activated vertical slices to be empty, so that the video below shows through, while the vertical slices remain opaque.


Hmm, I've done a little testing, and it seems like the problem is that the "capture" function doesn't seem to transfer the alpha channel of the texture. When I load a movie with an alpha channel into a texture and drop it into a videoplane, it works fine. When I run that same texture through a slab, though (which, if I'm understanding correctly, is essentially using the "capture function under the hood), the alpha channel just disappears.

Am I correct in understanding that this problem is fixed in Max 6, using the erase_color attribute on the texture? Or is the fix a little more complicated than that?

Hmm, I've done a little testing, and it seems like the problem is that the "capture" function doesn't seem to transfer the alpha channel of the texture.  When I load a movie with an alpha channel into a texture and drop it into a videoplane, it works fine.  When I run that same texture through a slab, though (which, if I'm understanding correctly, is essentially using the "capture function under the hood), the alpha channel just disappears.

Am I correct in understanding that this problem is fixed in Max 6, using the erase_color attribute on the texture?  Or is the fix a little more complicated than that?


You can use the erase_color attribute of jit.gl.texture to achieve this:

Also, you can just draw the geometry needed to display whatever sliver of texture you need instead of covering parts of the texture that have no texture information.

Jitter feedback loop with partial texture