Forums > Jitter

Grabbing jit.qt.movie in scheduler thread doesn't work (bug?)

March 7, 2007 | 9:42 am

Hi everyone,

It looks like grabbing a movie in scheduler thread doesn’t work. Could that be true or did I miss something?

The patch below illustrates the problem and contains steps to reproduce. Please save and load the patch in order for the loadmess to fire.

Mattijs

Max 4.6.2, jitter 1.6.3b2, Mac OS 10.4.8, Mac Pro

#P comment 411 108 133 196617 after this it works properly;
#P comment 64 36 85 196617 2) enable metro’s;
#P comment 104 201 72 196617 1) load movie;
#P newex 127 129 78 196617 loadmess 5000;
#P newex 260 65 49 196617 pipe 250;
#P toggle 47 36 15 0;
#P newex 279 166 68 196617 prepend time;
#P newex 260 146 29 196617 t b f;
#P newex 260 220 89 196617 grab 1 grabmovie;
#P user jit.pwindow 259 242 178 141 0 1 0 0 1 0;
#P flonum 260 129 78 9 0 0 0 3 0 0 0 221 221 221 222 222 222 0 0 0;
#P newex 260 84 58 196617 metro 500;
#P flonum 47 129 78 9 0 0 0 3 0 0 0 221 221 221 222 222 222 0 0 0;
#P newex 66 166 68 196617 prepend time;
#P newex 47 146 29 196617 t b f;
#P user jit.pwindow 46 242 178 141 0 1 0 0 1 0;
#P newex 47 84 58 196617 metro 500;
#P newex 150 220 65 196617 r grabmovie;
#P message 73 201 30 196617 read;
#P newex 47 220 102 196617 jit.qt.movie @rate 0;
#P comment 269 108 134 196617 < -- 3) insert deferlow here;
#P connect 13 1 14 0;
#P connect 12 0 11 0;
#P connect 13 0 12 0;
#P connect 14 0 12 0;
#P connect 10 0 13 0;
#P connect 9 0 10 0;
#P connect 16 0 9 0;
#P connect 15 0 4 0;
#P connect 15 0 16 0;
#P connect 6 1 7 0;
#P connect 1 0 5 0;
#P connect 2 0 1 0;
#P connect 3 0 1 0;
#P connect 7 0 1 0;
#P connect 6 0 1 0;
#P connect 8 0 6 0;
#P connect 4 0 8 0;
#P connect 17 0 8 0;


March 7, 2007 | 6:19 pm

On Mar 7, 2007, at 1:42 AM, Mattijs Kneppers wrote:

> It looks like grabbing a movie in scheduler thread doesn’t work.
> Could that be true or did I miss something?

Not a bug. Feature. This is only supported in low priority thread.
All output is deferred to the low priority thread regardless of
whether banged from a metro. See tutorials for more information on
how the low priority thread is used to gracefully downsample to what
can be accomplished in "real-time" when being overdriven from the
scheduler thread.

You can however, use qfaker in advance of sending the bang message to
jit.qt.movie, but you need to really know what you’re doing. And you
can use jit.qt.movie in JS or C from whatever thread you want. You
just can’t draw to the screen or outlet into a max patch in anything
but the low priority (main application) thread.

Besides, I would stay away from the grab object unless you absolutely
need it. It’s sort of a hack. Would recommend you use Java or JS or C
instead.

-Joshua


March 7, 2007 | 7:06 pm


March 7, 2007 | 7:07 pm


March 8, 2007 | 4:44 pm

Quote: jkc wrote on Wed, 07 March 2007 19:19
—————————————————-
>
> On Mar 7, 2007, at 1:42 AM, Mattijs Kneppers wrote:
>
> > It looks like grabbing a movie in scheduler thread doesn’t work.
> > Could that be true or did I miss something?
>
> Not a bug. Feature. This is only supported in low priority thread.
> All output is deferred to the low priority thread regardless of
> whether banged from a metro. See tutorials for more information on
> how the low priority thread is used to gracefully downsample to what
> can be accomplished in "real-time" when being overdriven from the
> scheduler thread.
>
> You can however, use qfaker in advance of sending the bang message to
> jit.qt.movie, but you need to really know what you’re doing. And you
> can use jit.qt.movie in JS or C from whatever thread you want. You
> just can’t draw to the screen or outlet into a max patch in anything
> but the low priority (main application) thread.

Ah! This is good to know.

>
> Besides, I would stay away from the grab object unless you absolutely
> need it. It’s sort of a hack. Would recommend you use Java or JS or C
> instead.

Ok, that’s valuable information, and a real pity too. For me the grab object opens the possibility to have info stored in one place and independently retrieve it whenever necessary, comparable to a function that returns data to its caller. We use grab in combination with coll a lot for this purpose.

Thanks for the info,
Mattijs

>
> -Joshua
>
—————————————————-


March 8, 2007 | 4:46 pm

Quote: wesley.hoke@gmail.com wrote on Wed, 07 March 2007 20:07
—————————————————-
> whoops, should be jit.qt.movie @out_name myfreakinawesomevideo
>

Thanks wes, could it be true that this feature is not documented? I can’t find it. What does it do?

Mattijs


March 8, 2007 | 5:02 pm

It is documented here JitterReference/group-mop.html . All MOP
objects have the features mentioned in this doc. If you click on the
Matrix Operator link at the top of the jit.qt.movie object’s ref page,
you’ll find this html doc as well.

There’s also my favorite tool command+option+click (on mac) gets you a
list of all the messages and attributes of a jitter object.

wes


March 8, 2007 | 5:03 pm

It gives you a named matrix output so you can do things like feedback
without saying [jit.matrix mygreakinawesomevideo] or @in2_name
myfreakinawesomevideo etc or just use it for named matrix solutions
rather than using an intermediary matrix.

I believe it is documented in the html docs

On Mar 8, 2007, at 11:46 AM, Mattijs Kneppers wrote:

>
> Quote: wesley.hoke@gmail.com wrote on Wed, 07 March 2007 20:07
> —————————————————-
>> whoops, should be jit.qt.movie @out_name myfreakinawesomevideo
>>
>
> Thanks wes, could it be true that this feature is not documented? I
> can’t find it. What does it do?
>
> Mattijs
> –
> SmadSteck – http://www.smadsteck.nl
> Interactive audiovisual sampling soft- and hardware
>

v a d e //

http://www.vade.info
abstrakt.vade.info


March 8, 2007 | 5:09 pm

On Mar 8, 2007, at 8:44 AM, Mattijs Kneppers wrote:

>> You can however, use qfaker in advance of sending the bang message to
>> jit.qt.movie, but you need to really know what you’re doing. And you
>> can use jit.qt.movie in JS or C from whatever thread you want. You
>> just can’t draw to the screen or outlet into a max patch in anything
>> but the low priority (main application) thread.
>
> Ah! This is good to know.

Btw, in the above I meant to say Java. I haven’t played around too
much with JS in immediate mode using Jitter objects.

>> Besides, I would stay away from the grab object unless you absolutely
>> need it. It’s sort of a hack. Would recommend you use Java or JS or C
>> instead.
>
> Ok, that’s valuable information, and a real pity too. For me the
> grab object opens the possibility to have info stored in one place
> and independently retrieve it whenever necessary, comparable to a
> function that returns data to its caller. We use grab in
> combination with coll a lot for this purpose.

It will work, but you have to have a synchronous function (e.g.
something which is inherently deferred to the low priority thread
like banging jit.qt.movie or a file read operation etc will not work)
and things can get complicated quickly this way. In general, it’s
probably better to use routing in place of grab, but if it works for
your application, you shouldn’t feel bad about using it.

-Joshua


March 8, 2007 | 5:19 pm

On Mar 8, 2007, at 9:09 AM, Joshua Kit Clayton wrote:

> In general, it’s probably better to use routing in place of grab,
> but if it works for your application, you shouldn’t feel bad about
> using it.

And I forgot to mention… For transaction based requests from
individual max objects, there’s a good example of this in jitter-
examples/video/quicktime/jit.qt.movie-multi-head.pat.

-Joshua


March 9, 2007 | 9:54 am

Quote: jkc wrote on Thu, 08 March 2007 18:19
—————————————————-
>
> On Mar 8, 2007, at 9:09 AM, Joshua Kit Clayton wrote:
>
> > In general, it’s probably better to use routing in place of grab,
> > but if it works for your application, you shouldn’t feel bad about
> > using it.
>
> And I forgot to mention… For transaction based requests from
> individual max objects, there’s a good example of this in jitter-
> examples/video/quicktime/jit.qt.movie-multi-head.pat.
>
> -Joshua
>

Very good, this explains perfectly. Actually the only point I missed was that jit.qt.movie automatically defers to the low priority queue. That explains the whole issue.

Furthermore I am happy to hear that grab is still supported :) Routing has one big drawback, namely that you have to account for every separate destination inside the source patcher.

Thanks,
Mattijs


March 9, 2007 | 10:02 am

Quote: Mattijs wrote on Fri, 09 March 2007 10:54
—————————————————-
> Routing has one big drawback, namely that you have to account for every separate destination inside the source patcher.

Hey wait, I didn’t look at the example carefully enough. Now I see, nice one!

Mattijs


March 9, 2007 | 10:11 am

Thanks wesley and vade,

I found it :)

Quote: wesley.hoke@gmail.com wrote on Thu, 08 March 2007 18:02
—————————————————-
> It is documented here JitterReference/group-mop.html . All MOP
> objects have the features mentioned in this doc. If you click on the
> Matrix Operator link at the top of the jit.qt.movie object’s ref page,
> you’ll find this html doc as well.
>
> There’s also my favorite tool command+option+click (on mac) gets you a
> list of all the messages and attributes of a jitter object.
>

yea, I saw it there (my favorite too! Was there a rumor that max 5 adds this to every object?) but couldn’t find the explanation. Btw, did you know that option + right click works too (for the lucky multibutton mouse owners) ;)

Mattijs


March 9, 2007 | 10:15 am

Quote: Mattijs wrote on Fri, 09 March 2007 11:02
—————————————————-
> Quote: Mattijs wrote on Fri, 09 March 2007 10:54
> —————————————————-
> > Routing has one big drawback, namely that you have to account for every separate destination inside the source patcher.
>
> Hey wait, I didn’t look at the example carefully enough. Now I see, nice one!
>

Although of course there is still the drawback that you have to introduce an extra global name for every destination, which I try to avoid if possible.

> Mattijs
—————————————————-


Viewing 14 posts - 1 through 14 (of 14 total)