thierry@thierryfourni

A question about time. Could it be possible to record live video with 

a jit.qt.grab, and store it in real time in a variable access buffer, 

which would be read at variable speed rates ?

For example we would read this buffer at the same speed than the 

incoming live video (= no delay), then we would read it slower, at 

different speeds (=> creating an increasing delay compared with the 

realtime), and then for example accelerate again the lecture speed of 

the buffer, in order to re-synchronise it with the incoming realtime 

I tried to make it with the "video delay" example published by 

Jonathan Lee Marcus on the list (thanks again), using matrix 

dimensions to store frames read with the srcdimstart and srcdimend 

cmds, but I didn't get it : I can't read these stored matrix at 

different speed rates. Sorry if it's obvious, I'm not very 

comfortable with this method. I post the patch again for reference.

A question about time. Could it be possible to record live video with  
a jit.qt.grab, and store it in real time in a variable access buffer,  
which would be read at variable speed rates ?

For example we would read this buffer at the same speed than the  
incoming live video (= no delay), then we would read it slower, at  
different speeds (=> creating an increasing delay compared with the  
realtime), and then for example accelerate again the lecture speed of  
the buffer, in order to re-synchronise it with the incoming realtime  
video.

I tried to make it with the "video delay" example published by  
Jonathan Lee Marcus on the list (thanks again), using matrix  
dimensions to store frames read with the srcdimstart and srcdimend  
cmds, but I didn't get it : I can't read these stored matrix at  
different speed rates. Sorry if it's obvious, I'm not very  
comfortable with this method. I post the patch again for reference.

realtime-video-buffer-with-variable-speed-access

For variable speed access, all you have to do is move an index up or

down at different rates. You can play around with a floating point

index and take the 2 closest frames which you would then blend in some

fashion according to the fractional amount of the index.

For variable speed access, all you have to do is move an index up or
down at different rates.  You can play around with a floating point
index and take the 2 closest frames which you would then blend in some
fashion according to the fractional amount of the index.

Inspired by this discussion I was playing with time buffers a bit, I thought you might like this one.

Thank you again, a lot, for these explanations and the example.

>> But theorically I could (in "thru 0") recall the last frame with 

>> "matrixoutput 0", or 1 or 2, etc and increase progressively my 

>> delay- but apparently these frames can be read only when the 

>> entire cycle is filled again. Did I miss someting ?

> perhaps i misunderstand, but i think you are confusing the way 

> thru should be off, so that we only see what we call for using 

> jit.matrixset stores the incoming matrix at the position you 

> "matrixoutput 0" outputs zeroth position of the buffer, not 

> we need to keep track at which frame we just wrote into, so that we 

> delay depending on that position. that's why i used the + and % 

> wraps around the max num frames, while keeping the same distance 

But I didn't get this point - I believed that the last frame was 

always at index 0. Though it's obvious that it can't be...

I'm going to have a serious look at your patch, at timecube too (I 

downloaded it yesterday), and I come again when all these questions 

>> But theorically I could (in "thru 0") recall the last frame with  
>> "matrixoutput 0", or 1 or 2, etc and increase progressively my  
>> delay- but apparently these frames can be read only when the  
>> entire cycle is filled again. Did I miss someting ?
>>
>
> perhaps i misunderstand, but i think you are confusing the way  
> matrixoutput and index works.
> thru should be off, so that we only see what we call for using  
>
>
> jit.matrixset stores the incoming matrix at the position you  
> specify in the buffer through
> the "index " message.

>
>  "matrixoutput 0" outputs zeroth position of the buffer, not  
> exactly previous frame as you mention.
> we need to keep track at which frame we just wrote into, so that we  
> can think on more or less
> delay depending on that position. that's why i used the + and %  
> operator. it ensures the result
> wraps around the max num frames, while keeping the same distance  
> from the frame just written.

But I didn't get this point - I believed that the last frame was  
always at index 0. Though it's obvious that it can't be...

I'm going to have a serious look at your patch, at timecube too (I  
downloaded it yesterday), and I come again when all these questions  
will be absolutely clear for me :-)

>> "matrixoutput 0" outputs zeroth position of the buffer, not 

>> exactly previous frame as you mention.

>> we need to keep track at which frame we just wrote into, so that 

>> delay depending on that position. that's why i used the + and % 

>> wraps around the max num frames, while keeping the same distance 

> But I didn't get this point - I believed that the last frame was 

> always at index 0. Though it's obvious that it can't be...

this would be true for a fifo like behaviour, but the way the object 

it builds an internal array of matrices, that you can write to 

and read from position x-1, which gives you one frame delay (with 

because x-1 might fall off the 0-maxframes interval (think on the 

reading would be pos -1) the + and % are the objs are used to make 

you'll read from pos max, in a 1 frame delay scenario..

it took me a long time to figure out this stuff, but its quite simple 

look at this in slow motion, it helped me a lot too. remember to use 

frames delay, and decrease the number to increase the delay

> I'm going to have a serious look at your patch, at timecube too (I 

> downloaded it yesterday), and I come again when all these questions 

welcome, and thank you Mattijs for a very cool patch!

>
>>
>>  "matrixoutput 0" outputs zeroth position of the buffer, not  
>> exactly previous frame as you mention.
>> we need to keep track at which frame we just wrote into, so that  
>> we can think on more or less
>> delay depending on that position. that's why i used the + and %  
>> operator. it ensures the result
>> wraps around the max num frames, while keeping the same distance  
>> from the frame just written.
>
> But I didn't get this point - I believed that the last frame was  
> always at index 0. Though it's obvious that it can't be...
>

this would be true for a fifo like behaviour, but the way the object  
works,
it builds an internal array of matrices, that you can write to  
position x (index x)
and read from position x-1, which gives you one frame delay (with  
message 'outputmatrix (x-1)')

because x-1 might fall off the 0-maxframes interval (think on the  
case writing to array pos 0,
reading would be pos -1) the + and % are the objs are used to make  
sure if you write to pos 0,
you'll read from pos max, in a 1 frame delay scenario..

it took me a long time to figure out this stuff, but its quite simple  
in the end..

look at this in slow motion, it helped me a lot too. remember to use  
max num for 0
frames delay, and decrease the number to increase the delay

> I'm going to have a serious look at your patch, at timecube too (I  
> downloaded it yesterday), and I come again when all these questions  
> will be absolutely clear for me :-)
>

Thanks a lot ! The effect is nice... I have to enter the spider now ;-)

Thierry Fournier
http://www.thierryfournier.net

Just a (late) message for thanking Andre Sier, Mattijs Kneppers and 

Wesley Smith for your wise advices about realtime video buffer, one 

month ago. I worked again on this project after some weeks of 

interruption. Everything's was conceptually clear enough to define 

the functions of the patches. Mathieu Chamagne will work with us, on 

This small installation, which is called "Point d'orgue" ("Fermata"), 

will be premiered in Montpellier (France), in November, and I'll keep 

Just a (late) message for thanking Andre Sier, Mattijs Kneppers and  
Wesley Smith for your wise advices about realtime video buffer, one  
month ago. I worked again on this project after some weeks of  
interruption. Everything's was conceptually clear enough to define  
the functions of the patches. Mathieu Chamagne will work with us, on  
the project software.

This small installation, which is called "Point d'orgue" ("Fermata"),  
will be premiered in Montpellier (France), in November, and I'll keep  
you informed.

----------------------------------------
Thierry Fournier
http://www.thierryfournier.net


Realtime video buffer with variable speed access