yair reshef

to restart a qt.movie i expect [time 0] or [frame 0] will jump the playhead

but if i stop the metro and pass those messages to the qt.movie, when i re

enable the metro it plays from a different position.

i have a problem that bewilders me.
to restart a qt.movie i expect [time 0] or [frame 0] will jump the playhead
to frame/time 0 .
but if i stop the metro and pass those messages to the qt.movie, when i re
enable the metro it plays from a different position.

restarting-a-movie

This reflects a misunderstanding of how jit.qt.movie is working. 

_regardless_of_whether_the_metro_is_on_or_not_. if you want to stop 

the movie, send the "stop" message to the movie, and then the "start" 

message to get it going again. If you need to switch the metro off 

and on, for whatever reason, you can do it as I've repatched below:

Am 12.12.2006 um 21:51 schrieb yair reshef:

> to restart a qt.movie i expect [time 0] or [frame 0] will jump the 

> but if i stop the metro and pass those messages to the qt.movie, 

> enable the metro it plays from a different position.

This reflects a misunderstanding of how jit.qt.movie is working.  
jit.qt.movie is playing the movie,  
_regardless_of_whether_the_metro_is_on_or_not_. if you want to stop  
the movie, send the "stop" message to the movie, and then the "start"  
message to get it going again. If you need to switch the metro off  
and on, for whatever reason, you can do it as I've repatched below:

> i have a problem that bewilders me.
> to restart a qt.movie i expect [time 0] or [frame 0] will jump the  
> playhead
> to frame/time 0 .
> but if i stop the metro and pass those messages to the qt.movie,  
> when i re
> enable the metro it plays from a different position.


>This reflects a misunderstanding of how jit.qt.movie is working. 

Apparently. But happily, this can be remedied by looking at Jitter

on the floor there's a long wooden table/on the table there's an open book/

on the page there's a detailed drawing/and on the drawing is the name I took

>This reflects a misunderstanding of how jit.qt.movie is working. 
>jit.qt.movie is playing the movie,

Apparently. But happily, this can be remedied by looking at Jitter
Tutorials 1 and 4.
-- 
on the floor there's a long wooden table/on the table there's an open book/
on the page there's a detailed drawing/and on the drawing is the name I took
Gregory Taylor http://www.rtqe.net


stopping the metro does not stop the playhead from moving. if you 

want to stop the playhead from moving send the stop message.

if you want to stop outputting frames, and stop the playhead moving, 

just because you arent feeding metros doesnt mean the playhead isnt 

On Dec 12, 2006, at 3:51 PM, yair reshef wrote:

> when i re enable the metro it plays from a different position.

> #P user jit.pwindow 92 224 82 62 0 1 0 0 1 0;

> #P message 154 162 60 9109513 time 0 , bang;

> #P flonum 131 141 35 9 0.5 0 1 139 0 0 0 221 221 221 222 222 222 0 

> #P newex 97 198 103 9109513 jit.qt.movie 320 240;

stopping the metro does not stop the playhead from moving. if you  
want to stop the playhead from moving send the stop message.

if you want to stop outputting frames, and stop the playhead moving,  
send stop and no longer bang.

just because you arent feeding metros doesnt mean the playhead isnt  
moving. :)

> i have a problem that bewilders me.
> to restart a qt.movie i expect [time 0] or [frame 0] will jump the  
> playhead to frame/time 0 .
> but if i stop the metro and pass those messages to the qt.movie,  
> when i re enable the metro it plays from a different position.
>
> max v2;
> #N vpatcher 15 55 516 455;
> #P user jit.pwindow 92 224 82 62 0 1 0 0 1 0;
> #P window setfont "Sans Serif" 9.;
> #P window linecount 1;
> #P message 223 163 60 9109513 read;
> #P message 154 162 60 9109513 time 0 , bang;
> #P flonum 131 141 35 9 0.5 0 1 139 0 0 0 221 221 221 222 222 222 0  
> 0 0;
> #P toggle 97 141 15 0;
> #P newex 97 161 44 9109513 metro 2;
> #P newex 97 198 103 9109513 jit.qt.movie 320 240;
> #B color 5;
> #P connect 0 0 6 0;
> #P connect 2 0 1 0;
> #P connect 5 0 0 0;
> #P fasten 1 0 0 0 102 191 102 191;
> #P fasten 4 0 0 0 159 188 102 188;
> #P connect 3 0 1 1;
> #P pop;
>

> just because you arent feeding metros doesnt mean the playhead isnt

back to basics for me, this is completly unintuative . way would a playhead

> to restart a qt.movie i expect [time 0] or [frame 0] will jump the

> but if i stop the metro and pass those messages to the qt.movie, when i re

> #P flonum 131 141 35 9 0.5 0 1 139 0 0 0 221 221 221 222 222 222 0 0 0;

>
> just because you arent feeding metros doesnt mean the playhead isnt
> moving. :)
>

back to basics for me, this is completly unintuative . way would a playhead
move if theres no bang.
thank you all for the corrections.

On Dec 12, 2006, at 3:51 PM, yair reshef wrote:
>
> i have a problem that bewilders me.
> to restart a qt.movie i expect [time 0] or [frame 0] will jump the
> playhead to frame/time 0 .
> but if i stop the metro and pass those messages to the qt.movie, when i re
> enable the metro it plays from a different position.
>
> max v2;
> #N vpatcher 15 55 516 455;
> #P user jit.pwindow 92 224 82 62 0 1 0 0 1 0;
> #P window setfont "Sans Serif" 9.;
> #P window linecount 1;
> #P message 223 163 60 9109513 read;
> #P message 154 162 60 9109513 time 0 , bang;
> #P flonum 131 141 35 9 0.5 0 1 139 0 0 0 221 221 221 222 222 222 0 0 0;
> #P toggle 97 141 15 0;
> #P newex 97 161 44 9109513 metro 2;
> #P newex 97 198 103 9109513 jit.qt.movie 320 240;
> #B color 5;
> #P connect 0 0 6 0;
> #P connect 2 0 1 0;
> #P connect 5 0 0 0;
> #P fasten 1 0 0 0 102 191 102 191;
> #P fasten 4 0 0 0 159 188 102 188;
> #P connect 3 0 1 1;
> #P pop;
>
>
>
> *v a d e //*
>
> *www.vade.info*
> *abstrakt.vade.info*
>
>
>
>
>
>
>

I still forget about this all the time - . its a bit unintuitive, 

but makes sense. The bang only tells jit.qt.movie to output a matrix, 

Realize too that the frames are still being decompressed when no 

matrix is being output, so unless you hit stop, you still may have a 

significant performance loss due to having a movie being playedin the 

background, esp if it is something like h.264 or a large DV movie, 

On Dec 12, 2006, at 5:05 PM, yair reshef wrote:

> just because you arent feeding metros doesnt mean the playhead isnt 

> back to basics for me, this is completly unintuative . way would a 

> On Dec 12, 2006, at 3:51 PM, yair reshef wrote:

>> to restart a qt.movie i expect [time 0] or [frame 0] will jump the 

>> but if i stop the metro and pass those messages to the qt.movie, 

>> when i re enable the metro it plays from a different position.

>> #P user jit.pwindow 92 224 82 62 0 1 0 0 1 0;

>> #P message 154 162 60 9109513 time 0 , bang;

>> #P flonum 131 141 35 9 0.5 0 1 139 0 0 0 221 221 221 222 222 222 0 

>> #P newex 97 198 103 9109513 jit.qt.movie 320 240;

I still forget about this all the time - . its a bit  unintuitive,  
but makes sense. The bang only tells jit.qt.movie to output a matrix,  
Realize too that the frames are still being decompressed when no  
matrix is being output, so unless you hit stop, you still may have a  
significant performance loss due to having a movie being playedin the  
background, esp if it is something like h.264 or a large DV movie,  
etc etc.

>
>
> just because you arent feeding metros doesnt mean the playhead isnt  
> moving. :)
>
> back to basics for me, this is completly unintuative . way would a  
> playhead move if theres no bang.
> thank you all for the corrections.
>
> On Dec 12, 2006, at 3:51 PM, yair reshef wrote:
>
>> i have a problem that bewilders me.
>> to restart a qt.movie i expect [time 0] or [frame 0] will jump the  
>> playhead to frame/time 0 .
>> but if i stop the metro and pass those messages to the qt.movie,  
>> when i re enable the metro it plays from a different position.
>>
>> max v2;
>> #N vpatcher 15 55 516 455;
>> #P user jit.pwindow 92 224 82 62 0 1 0 0 1 0;
>> #P window setfont "Sans Serif" 9.;
>> #P window linecount 1;
>> #P message 223 163 60 9109513 read;
>> #P message 154 162 60 9109513 time 0 , bang;
>> #P flonum 131 141 35 9 0.5 0 1 139 0 0 0 221 221 221 222 222 222 0  
>> 0 0;
>> #P toggle 97 141 15 0;
>> #P newex 97 161 44 9109513 metro 2;
>> #P newex 97 198 103 9109513 jit.qt.movie 320 240;
>> #B color 5;
>> #P connect 0 0 6 0;
>> #P connect 2 0 1 0;
>> #P connect 5 0 0 0;
>> #P fasten 1 0 0 0 102 191 102 191;
>> #P fasten 4 0 0 0 159 188 102 188;
>> #P connect 3 0 1 1;
>> #P pop;
>>
>
> v a d e //
>
> www.vade.info
> abstrakt.vade.info
>
>
>
>
>
>
>

>I still forget about this all the time - . its a bit unintuitive, 

>but makes sense. The bang only tells jit.qt.movie to output a matrix,

So, if you send the bang message at a faster rate than the "film" is playing

inside the jit.qt.movie object, it repeats frames. If you send the bang message

more slowly than the movie's rate, it drops frames. This seems intuitively

optimal... to me, anyway. Or at least that Tutorial explained it pretty well.

>I still forget about this all the time - . its a bit  unintuitive, 
>but makes sense. The bang only tells jit.qt.movie to output a matrix,

So, if you send the bang message at a faster rate than the "film" is playing
inside the jit.qt.movie object, it repeats frames. If you send the bang message
more slowly than the movie's rate, it drops frames. This seems intuitively
optimal... to me, anyway. Or at least that Tutorial explained it pretty well.
-- 
on the floor there's a long wooden table/on the table there's an open book/
on the page there's a detailed drawing/and on the drawing is the name I took
Gregory Taylor http://www.rtqe.net


That part I got, the part that took me a while to digest was that not 

banging did not stop the movies frames from being decompressed 

On Dec 12, 2006, at 5:22 PM, Gregory Taylor wrote:

>> I still forget about this all the time - . its a bit unintuitive, 

>> but makes sense. The bang only tells jit.qt.movie to output a matrix,

> So, if you send the bang message at a faster rate than the "film" 

> inside the jit.qt.movie object, it repeats frames. If you send the 

> more slowly than the movie's rate, it drops frames. This seems 

> optimal... to me, anyway. Or at least that Tutorial explained it 

> on the floor there's a long wooden table/on the table there's an 

> on the page there's a detailed drawing/and on the drawing is the 

That part I got, the part that took me a while to digest was that not  
banging did not stop the movies frames from being decompressed  
'behind' the scenes.

>> I still forget about this all the time - . its a bit  unintuitive,  
>> but makes sense. The bang only tells jit.qt.movie to output a matrix,
>
> So, if you send the bang message at a faster rate than the "film"  
> is playing
> inside the jit.qt.movie object, it repeats frames. If you send the  
> bang message
> more slowly than the movie's rate, it drops frames. This seems  
> intuitively
> optimal... to me, anyway. Or at least that Tutorial explained it  
> pretty well.
> -- 
> on the floor there's a long wooden table/on the table there's an  
> open book/
> on the page there's a detailed drawing/and on the drawing is the  
> name I took
> Gregory Taylor http://www.rtqe.net

They aren't being decompressed per se, but QuickTime is preparing 

them for decompression and continuing to read data from disk.

> That part I got, the part that took me a while to digest was that 

> not banging did not stop the movies frames from being decompressed 

They aren't being decompressed per se, but QuickTime is preparing  
them for decompression and continuing to read data from disk.

> That part I got, the part that took me a while to digest was that  
> not banging did not stop the movies frames from being decompressed  
> 'behind' the scenes.


restarting a movie