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


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

    • Mar 07 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
    • Mar 07 2007 | 7:06 pm
    • Mar 08 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 > ----------------------------------------------------
    • Mar 08 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
    • Mar 08 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
    • Mar 08 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 //
      www.vade.info abstrakt.vade.info
    • Mar 08 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
    • Mar 08 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
    • Mar 09 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
    • Mar 09 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
    • Mar 09 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
    • Mar 09 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 ----------------------------------------------------