Mattijs

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.

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

grabbing-jit-qt-movie-in-scheduler-thread-doesnt-work-bug

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 

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 

> 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.

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 

> 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 

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.

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.

>
> 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 
>
----------------------------------------------------


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?

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

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,

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.

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.

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 

> Interactive audiovisual sampling soft- and hardware

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.

>
> 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
>

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.

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

> 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.

>> 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.

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 

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.

> 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.

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 

> 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.

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.

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
>

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!

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.

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,

> 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) ;)

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.
>

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.

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!
>

> Mattijs
----------------------------------------------------


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