jit.qt.movie playback pausing when loading in Windows 7, it works under OSX

I have no definitive news for you, but it sounds like a platform issue. Perhaps related to other things like a large search path, virus protection, etc.

If you send an absolute path, rather than just the file name, is the behavior different? That would suggest search path size/overhead.

However, you might want to use the asyncread message to do the loading in a background thread.

Unfortunately, this sounds like QT is at fault. You can try loading all your movies in advance like the "poly~ for movies" example patch.

Otherwise, I’d recommend searching online for general QT performance issues under windows.

Sorry for the nuisance. That sounds like an impressively fast machine, and frustrating to have QT as your bottleneck. Under Jitter 64bit, we do have preliminary support for using DirectShow for playing back movies, but it is a long way towards being useful, and I’m not sure if it exhibits any better loading performance.

If you discover anything, please share your experience here.

From my experience on PCs, it probably doesn’t have anything to do with that DSfilter stuff Vital VJ is talking about. The Codec itself can make a huge difference in playback rate/processor use, but I’m not sure what he is talking about is even happening within Jitter and the quicktime object on a 32bit system.
Max/Jitter on PC has always been problematic in ways that aren’t addressed, but subtly disappoint. This is especially true of anything to do with file handling/loading/parsing. If you have a finite set of videos, I’ve found that creating a bunch of qt objects and starting and stopping the videos gets you proper triggering without delays. This is sort of like the poly object idea, but perhaps less limiting if you want to do something like crossfade the videos without having two sets of them. This approach should work fine if you’ve got something like a finite set of 20 videos, or even "sets" that you can load (realizing there will be a long, cludgy pause when loading the entire set).
It is good to go through all the parts of your process and see if something unexpected is causing the pause. I’ve eliminated some issues that were related to using umenu for file choosing as an example. The "@frames unique" attribute can cause things to be less crisp. There’s also the question of whether the loading is freezing the entire output, or just the qt.movie source itself. So, if you have a second movie playing, does it freeze when you load another in a separate object? If it is freezing everything, it may have as much to do with UI, threading, or screen updating as it does to do with that one file loading. I’m not sure if the example patch you’re referencing involves dragging and dropping files, but that is pretty much a complete joke on a pc.
All that said, if it works cleanly on a Mac and dirty on a PC, then you may just be screwed. That level of system specific tweaking doesn’t seem to be a high priority. It probably does come down to Quicktime on PC implementation, and of course Apple has a vested interest in making sure that never works quite as well on a different platform than their own.
If you have an example/direction of what you’re aiming at, maybe I can provide a more constructive response.