Video Delay in Jitter
Hi -
I am trying to create an adjustable real-time delay from a video input. Maybe up to 10 seconds long at the maximum.
I am wondering if there is a simple way to do this? Perhaps something similar to the tapin~/ tapout~ objects in Max/MSP?
What I have researched so far leads me to think this isn't really a simple process... does anyone know otherwise?
Thanks,
Andrew
A 3d matrix way of doing it, which I find to be more reliable than the matrixset object.
I have this configured for 0-127 frames of delay. Just substitute values or variables for "127" maximum or "128" frames as necessary to have a different defined buffer of sorts.
Paste this:
Where do I paste this?
In your patch. It's magic!
wes
On 2/23/07, Andrew Douglas wrote:
>
> Where do I paste this?
>
>
Magic! Brilliance.
Thankyou very much!
Andrew D
The abstraction for video delay works great, but I don't understand the theory behind it
Could someone help explain the patch to me ? Why does the change of the third number in "srcdimstart 0 0 $1" or in "srcdimend 319 239 $1" affect the delayed video ?
(I thought the 3rd number only deal with dimension but not with time.)
What does the formula in the expr object do ?
Could someone help ? Thanks.
Quote: KillingFrenzy wrote on Thu, 22 February 2007 14:35
----------------------------------------------------
> A 3d matrix way of doing it, which I find to be more reliable than the matrixset object.
> I have this configured for 0-127 frames of delay. Just substitute values or variables for "127" maximum or "128" frames as necessary to have a different defined buffer of sorts.
>
> Paste this:
>
>
> #P outlet 37 209 15 0;
> #P inlet 157 2 15 0;
> #P inlet 37 1 15 0;
> #P window setfont "Sans Serif" 9.;
> #P window linecount 1;
> #P newex 56 125 111 9109513 expr (($i1+128)-$i2)%128;
> #P newex 37 171 215 9109513 jit.matrix 4 char 320 240 @usesrcdim 1 @adapt 0;
> #P message 56 149 182 9109513 srcdimstart 0 0 $1 , srcdimend 319 239 $1;
> #N counter 0 0 127;
> #X flags 0 0;
> #P newobj 56 57 73 9109513 counter 0 0 127;
> #P message 56 79 182 9109513 dstdimstart 0 0 $1 , dstdimend 319 239 $1;
> #P newex 37 101 233 9109513 jit.matrix 4 char 320 240 128 @usedstdim 1 @interp 0;
> #P newex 37 29 29 9109513 t l b;
> #P comment 2 3 30 9109513 Delay;
> #B color 10;
> #P comment 55 209 69 9109513 Delayed Video;
> #P comment 54 1 52 9109513 Input Video;
> #P comment 175 1 64 9109513 Delay Amount;
> #P user panel 1 0 34 20;
> #X brgb 0 0 0;
> #X frgb 0 0 0;
> #X border 1;
> #X rounded 0;
> #X shadow 0;
> #X done;
> #P connect 13 0 11 1;
> #P connect 11 0 9 0;
> #P connect 8 0 11 0;
> #P connect 8 0 7 0;
> #P connect 5 1 8 0;
> #P connect 10 0 14 0;
> #P connect 9 0 10 0;
> #P connect 6 0 10 0;
> #P lcolor 13;
> #P connect 5 0 6 0;
> #P lcolor 13;
> #P connect 7 0 6 0;
> #P connect 12 0 5 0;
> #P window clipboard copycount 15;
>
----------------------------------------------------
time is a dimension.
Think of the video frames as pictures.
with two dimensions you have X and Y, the familiar picture/photo/2D
image you are used to seeing.
With a Z axis, you can have LAYERS of frames ( think of stacking
photos on top of one another - each additional STACKED FRAME is
another increment in the Z axis)
The last srcdimstart 0 0 $1 refers to the LAYER, in this case, the
STACK number, or, WHAT particular frame in our stack that we want.
-- for more :
Imagine what you could do if you varied that number per EACH output of
a frame? You could make a single output frame that has MULTIPLE frames
within it, one frame as a conglomerate of many different moments in
time (hint: wesley smiths xray.timecube object :) )
On Dec 17, 2007, at 10:16 PM, Cheng Chien-Wen wrote:
>
> The abstraction for video delay works great, but I don't understand
> the theory behind it
>
> Could someone help explain the patch to me ? Why does the change of
> the third number in "srcdimstart 0 0 $1" or in "srcdimend 319 239
> $1" affect the delayed video ?
>
> (I thought the 3rd number only deal with dimension but not with time.)
>
> What does the formula in the expr object do ?
>
> Could someone help ? Thanks.
>
> Quote: KillingFrenzy wrote on Thu, 22 February 2007 14:35
> ----------------------------------------------------
>> A 3d matrix way of doing it, which I find to be more reliable than
>> the matrixset object.
>> I have this configured for 0-127 frames of delay. Just substitute
>> values or variables for "127" maximum or "128" frames as necessary
>> to have a different defined buffer of sorts.
>>
>> Paste this:
>>
>>
>> #P outlet 37 209 15 0;
>> #P inlet 157 2 15 0;
>> #P inlet 37 1 15 0;
>> #P window setfont "Sans Serif" 9.;
>> #P window linecount 1;
>> #P newex 56 125 111 9109513 expr (($i1+128)-$i2)%128;
>> #P newex 37 171 215 9109513 jit.matrix 4 char 320 240 @usesrcdim 1
>> @adapt 0;
>> #P message 56 149 182 9109513 srcdimstart 0 0 $1 , srcdimend 319
>> 239 $1;
>> #N counter 0 0 127;
>> #X flags 0 0;
>> #P newobj 56 57 73 9109513 counter 0 0 127;
>> #P message 56 79 182 9109513 dstdimstart 0 0 $1 , dstdimend 319
>> 239 $1;
>> #P newex 37 101 233 9109513 jit.matrix 4 char 320 240 128
>> @usedstdim 1 @interp 0;
>> #P newex 37 29 29 9109513 t l b;
>> #P comment 2 3 30 9109513 Delay;
>> #B color 10;
>> #P comment 55 209 69 9109513 Delayed Video;
>> #P comment 54 1 52 9109513 Input Video;
>> #P comment 175 1 64 9109513 Delay Amount;
>> #P user panel 1 0 34 20;
>> #X brgb 0 0 0;
>> #X frgb 0 0 0;
>> #X border 1;
>> #X rounded 0;
>> #X shadow 0;
>> #X done;
>> #P connect 13 0 11 1;
>> #P connect 11 0 9 0;
>> #P connect 8 0 11 0;
>> #P connect 8 0 7 0;
>> #P connect 5 1 8 0;
>> #P connect 10 0 14 0;
>> #P connect 9 0 10 0;
>> #P connect 6 0 10 0;
>> #P lcolor 13;
>> #P connect 5 0 6 0;
>> #P lcolor 13;
>> #P connect 7 0 6 0;
>> #P connect 12 0 5 0;
>> #P window clipboard copycount 15;
>>
> ----------------------------------------------------
>
>
Hi, Vade,
Now I understand a little bit better.
Thank you very much for the explanation.
Hello
I wanted to adapt the patch from above with the ability to change the resolution.
Maybe it is obvious and simple but i am not getting what i am doing wrong right now...
Help is very appreciated!
Here is my adapted version:
Well. I don't really see how this works. I plugged my webcam feed into the suggested solution here and the output was just black. It did not work for me.
much more efficient modern version using gl-textures:
This is even more confusing. What i'm looking for in terms of output is a video or frame that is delayed by a controllable amount. I don't know what this patch does, and I don't see where the video out would be. Perhaps we're not on the same page.
well you gotta take some time to examine and understand the patch in order to make what you want. here's more what you're looking for. check out the jit.matrixset help file, in the video-delay tab for further explanation of this functionality. jit.gl.textureset.js is a replacement for jit.matrixset that processes textures rather than matrices, and is therefore more efficient.
Hey Rob,
thanks for the great delay tool.
I'm a beginner with jitter / openGL and I' wondering what kind
of "data" the output of your js is.
If i send it into the jit.world everything works fine, but I can't seem to get it to work
with any other jitter/gl objects like videoplane etc.
Any tips or help for that?
Thanks in advance!
Hoowdie
it's simply jit_gl_texture messages. any jit.gl object that accepts texture input (e.g. videoplane) should be able to handle and display the output.
post your patch if you can't get it to work.
Thanks for the patch! It works nicely!
I do have an error though: "error destroying texture data, possible memory leak."
It seems to happen mostly or only when I close the patch.
Is it something to worry about? It's for an installation so it would be nice if my patch is not sensitive for crashing :). ( As far as I know a memory leak can cause a potential crash)
Hello,
This patch crash max under gl3...
Is this a logic behavior?
Cheers
H
@YURKI If that message is only happening when you close the patch then I wouldn't worry about it.
@GENERALH thanks for the report, I can reproduce and will investigate.
@ROB RAMIREZ
Your patch is lovely! Am upgrading a very old installation that works with time delay using the patch posted at the beginning of this thread (2007!). Your patch is a clear improvement, but I see that I can't plug it into my xfade object which allowed me to mix the live/delayed grab with recorded video from the same fixed camera. Am looking into how I can play the recorded footage as a texture, and build a GL fader to replace the xfade (maybe jit.op?)… unfamiliar territory unfortunately, so if you can give me any advice it would be very much appreciated. Maybe there's a tutorial or a forum thread… Thanks
Here is my patch as it is. I have no problem grabbing and playing back video as texture, but I don't know how to mix them (yet) and I'd like to soften the movements with something like jit.slide… would be grateful if anyone can help!
Am upgrading an old installation (new camera, new screen, so everything goes from 576 to 1080).
it's now textures, no more matrices, so you need a texture shader to mix.
Wow, thank you so much Herr Markant! I was hoping for a nudge in the right direction, but you just built the mixer for me, and it works beautifully. Very glad you did because I never would have guessed that 'git.gl.pix' might be the object I was looking for to build a video mixer. I have to say that the language of the GL universe is less intuitive than the old matrixes: 'textures' and 'shaders'… not easy to get your head around - though it does have a certain hard poetry to it. In any case I can't argue with the results. Many thanks!
Thank you Rob. Am going to look through that article now. Am hoping that 'common jitter objects' includes jit.slide, which is the last thing I need to add to this patch now that Herr Markant has given me a helping hand. I have not been working with Max since a few years and I had forgotten how brilliant and generous this community is. It's a lovely way of working and I wish I could spend more of my time with my head in patches… alas! Thanks to both of you @Rob Ramirez @HerrMarkant
That worked out fine, Rob!
jit.gl.slab @file tp.slide.jxs is a perfect replacement for jit.slide - some trouble getting it to operate though, since it needs to loop back on itself (thankfully covered in the forum discussion 'trouble with tp.slide.jsx'). All working fine now. Very crisp output. Thanks again.
@ROB RAMIREZ
Pleased to report that this patch works fine on apple silicon (a new M1 chip Mac mini). The installation runs autonomously morning to night. Only small issue is the error message already flagged by Yurki:
'error destroying texture data, possible memory leak', which only appears when closing, but am getting a lot them (more than I care to count). The one consequence I see is that over the course of a day, the disk fills up (about 20 Go less space at the end of the day), but it empties once the programme closes, so not a problem for me since have the Mac mini auto shut down every evening - still, if you can propose a fix, it certainly wouldn't take away from the elegance of your time delay patch!
glad to hear that is working out for you (and great to hear working on the M1!)
I will investigate the memory leak message, but that will have nothing to do with your disk filling up. I wouldn't be able to diagnose the culprit there without seeing your patch.
Well, here it is (anything well crafted in it came from you!). As I said, the disk filling up is not a problem really. Thanks for the help
(the patch will eventually read 6 films; for now there are just 2 which act as placeholders)
what a wonderful community!!! thanks to all!!