jit.qt.movie playback not smooth

While we're talking about this (on multiple threads), I thought I'd share another quick and dirty example that touches on many of the things that Vade's examples demonstrate (for reference, his excellent patches are here http://abstrakt.vade.info/?p=147 ). The main additions relate to using a single, fast qmetro (of 1ms rather than 16ms). They also include some monitors to see where the timing is off, and provide some scheduler recommendations (see schedulerlab subpatch).

Anyway, in the meantime, these patches show how you can get pretty decent playback, before you start adding a bunch of UI objects and other issues that will cause timing issues. In such a case, it is recommended that you run your engine in a separate instance of the application and communicate to your performance patch over the network.

I was using James' example movie file for testing:
http://www.vjfader.com/transfer/clock_spin.mov

Here are some recommendations from the patch:

1. use a *single* 1 ms qmetro to drive all of your jit.qt.movie objects.

2. make sure you use "@unique 1" for all jit.qt.movie objects (@adapt 1 and @colormode uyvy recommended)

3. disable overdrive if you are only doing jitter work. high priority scheduler work typically interfere's with jitter. You may also want to set a small scheduler slop value in this case.

4. generate as *few* low/high priority events as possible--i.e. don't use a lot of metronomes or line objects if you can avoid it.

5. use as few dynamically updating UI elements as possible

6. if possible, separate your video playback mechanism from your performance patch. communicate over the network with your playback engine running in two separate instances of the applciation (run your playback engine in the runtime version)

7. if you are using other jit.gl.* objects for mixing or otherwise, drive your render drawing and swapping from a single master movie's output or following slab chain, rather than a separate metronome