wrong method to get movie dim ?
why is this not working properly ?
i want to retrieve the dimenesions of a movie immediatly after being loaded. when using the [route read] method to retrieve the dim i need to select the movie twice in order to get the correct dimensions, which should not be the case (?).
from the tutorial 4 about [route read] : "...This message has two purposes: first, to let you know that the movie file has been successfully located and opened; second, so that you can use this message to trigger subsequent actions in the Max patch..."
so if i undersand well if the movie has been properly located and opened i should be able to get its dimensions without any problem when usin this method ?
anybody ? pleazzzzz ?
could anybody point out what i am doing wrong here ?
Quote: (karrrlo) wrote on Sun, 20 January 2008 01:16
----------------------------------------------------
> why is this not working properly ?
> i want to retrieve the dimensions of a movie immediatly after being loaded. when using the [route read] method to retrieve the dim i need to select the movie twice in order to get the correct dimensions, which should not be the case (?).
> from the tutorial 4 about [route read] : "...This message has two purposes: first, to let you know that the movie file has been successfully located and opened; second, so that you can use this message to trigger subsequent actions in the Max patch..."
> so if i undersand well if the movie has been properly located and opened i should be able to get its dimensions without any problem when usin this method ?
>
>
>
> #P window setfont "Sans Serif" 9.;
> #P window linecount 1;
> #P comment 294 127 100 196617 720 480;
> #P newex 332 248 51 196617 print dim;
> #P message 201 128 83 196617 read dvkite.mov;
> #P message 187 110 83 196617 read dishes.mov;
> #P user jit.pwindow 63 256 82 62 0 1 0 0 1 0;
> #P toggle 65 104 15 0;
> #P newex 64 132 52 196617 metro 33;
> #P newex 223 248 47 196617 t getdim;
> #P newex 173 223 60 196617 unpack s 1;
> #P newex 173 201 328 196617 route read dim;
> #P newex 64 170 155 196617 jit.qt.movie @adapt 1 @unique 1;
> #P comment 280 109 100 196617 320 x 240;
> #P connect 8 0 1 0;
> #P connect 9 0 1 0;
> #P connect 2 1 10 0;
> #P connect 4 0 1 0;
> #P connect 1 0 7 0;
> #P connect 6 0 5 0;
> #P connect 5 0 1 0;
> #P connect 2 0 3 0;
> #P connect 1 1 2 0;
> #P connect 3 1 4 0;
> #P window clipboard copycount 12;
>
----------------------------------------------------
Works fine for me. The unpack is unnecessary unless you actually want to filter out failed read attempts (in which case you want to pass it to a and then to the trigger obj). But it works nevertheless. Maybe you're computer is slow and you need a deferlow after the trigger?
Zachary
No wait, you're absolutely right. Wasn't paying close enough attention to it. Even with a deferlow it doesn't work. Appears to be a period after the movie is loaded when the info hasn't yet updated. A del 500 solves it for me:
The 'problem' here is @unique 1
if you remove @unique 1, and do 'read movie.mov, bang, getdim' it
works as expected, at least, it does here. The getdim 'issue' happens
between the unique frames, thus the del 500 is long enough to wait so
that jit.qt.movie reads the next FRAME (since bang, with @unique, 1
does not update the frame immediately). ONCE the new frame is loaded
it appears to report the dim properly.
I would think this is a bug.
The workaround would be something like: This works everytime, as has
as small a delay as possible.
On Jan 20, 2008, at 10:47 PM, Zachary Seldess wrote:
>
> No wait, you're absolutely right. Wasn't paying close enough
> attention to it. Even with a deferlow it doesn't work. Appears to be
> a period after the movie is loaded when the info hasn't yet updated.
> A del 500 solves it for me:
>
> max v2;
> #N vpatcher 10 59 440 425;
> #P window setfont "Sans Serif" 9.;
> #P window linecount 1;
> #P newex 236 276 43 131137545 t getdim;
> #P newex 236 252 40 131137545 del 500;
> #P newex 236 229 30 131137545 sel 1;
> #P newex 190 205 56 131137545 unpack s 1;
> #P comment 274 85 100 131137545 720 480;
> #P newex 219 183 51 131137545 print dim;
> #P message 180 84 83 131137545 read dvkite.mov;
> #P message 166 66 83 131137545 read dishes.mov;
> #P user jit.pwindow 44 214 82 62 0 1 0 0 1 0;
> #P toggle 45 62 15 0;
> #P newex 45 90 52 131137545 metro 33;
> #P newex 190 152 69 131137545 route read dim;
> #P newex 45 128 155 131137545 jit.qt.movie @adapt 1 @unique 1;
> #P comment 260 67 100 131137545 320 x 240;
> #P connect 4 0 3 0;
> #P connect 6 0 1 0;
> #P connect 7 0 1 0;
> #P connect 13 0 1 0;
> #P connect 3 0 1 0;
> #P connect 1 0 5 0;
> #P connect 1 1 2 0;
> #P connect 2 0 10 0;
> #P connect 2 1 8 0;
> #P connect 10 1 11 0;
> #P connect 11 0 12 0;
> #P connect 12 0 13 0;
> #P pop;
>
> --
> http://www.zacharyseldess.com
>
On 21 janv. 08, at 05:15, vade wrote:
> I would think this is a bug.
I don't think it's the case. My understanding of the behavior is that:
sending getdim to [jit.qt.movie] returns the size of the output
matrix, as adapt attribute is on, this means that it will change as
soon as it needs to output the first frame. The problem is that you
ask for the dimension of the matrix just after reading the file, not
after outputting the first frame. That's why I suggested using
getmovie_dim instead of getdim.
Cheers,
ej
thanks for your help Emmanuel, Vade, Zach for your help , some questions/comments :
----------------------------------------------------
> On 21 janv. 08, at 05:15, vade wrote:
>
> > I would think this is a bug.
i wasn't sure about it but i would expect that when a file is opened most of the quicktime info is ready to be retrieved without needing to play a first frame (?).
what if one needs the dim of a movie before starting actually playing it and/or being set on "autosart 0"
> Quote: Emmanuel Jourdan wrote on Mon, 21 January 2008 08:42 :
----------------------------------------------------
> On 21 janv. 08, at 05:15, vade wrote:
>
> > I would think this is a bug.
>
> I don't think it's the case. My understanding of the behavior is that:
> sending getdim to [jit.qt.movie] returns the size of the output
> matrix, as adapt attribute is on, this means that it will change as
> soon as it needs to output the first frame.
The problem is that you
> ask for the dimension of the matrix just after reading the file, not
> after outputting the first frame.
yes Emmanuel but isn't one of the function of the adapt mode to get out of the [jit.qt.movie]'s default 320x240 dim ? why would a first frame be needed to actually "adapt" the [jit.qt.movie] to the actual movie dim ?
anyway the "getmovie_dim" message works like a charm, thanks Emmanuel, i oversaw this message in the help and reference file
( although it is spelled "getmoviedim" (both work fine) ).
it makes more sense to use this message then the getdim anyway ( at least for my needs )
thanks a lot Vade for your work around, it works fine but i need to be in unique 0 mode ( which of course could be set after receiving the dim info, in my case...)
thanks Zach for doublechecking i was not crazy :)
anyway problem solved all is good now:
On 21 janv. 08, at 12:59, karl-otto von oertzen wrote:
> yes Emmanuel but isn't one of the function of the adapt mode to get
> out of the [jit.qt.movie]'s default 320x240 dim ? why would a first
> frame be needed to actually "adapt" the [jit.qt.movie] to the actual
> movie dim ?
>
> anyway the "getmovie_dim" message works like a charm, thanks
> Emmanuel, i oversaw this message in the help and reference file
> ( although it is spelled "getmoviedim" (both work fine) ).
> it makes more sense to use this message then the getdim anyway ( at
> least for my needs )
yeah, my understanding is that when you query the [jit.qt.movie]
object to get the output matrix dimension, the adapt hasn't been made
yet, because this is done, the first time you ask for a frame (when
you send a bang). Whereas getmoviedim just ask the dimensions of the
file that you just successfully opened.
ej