jit.matrix error: “jit.qt.movie: could not create temporary GWorld for open()”
This is an updated plea from a previous post that yielded no responses. I now get the same error message when substituting a jit.matrix for the jit.qt.movie object. Curiously, the error is still attributed to jit.qt.movie. Previous info plus a few updates:
I get the error “jit.qt.movie: could not create temporary GWorld for open()” when looping through loading hi-res still images (anywhere from 3000x2000 to 6000x4000) into jit.qt.movie via asyncimport or jit.matrix via importmovie. I get the error (and no more loads) after looping through several dozen image loads. The load loop interval is long enough that I know the previous image has been completely loaded before loading the next. There is no metro clocking jit.qt.movie, just a bang sending the loaded still on for processing. I’ve started sending a “dispose” message prior to each asyncimport in hopes of fixing this problem, but no love.
This loop works fine by itself, but my complex problem patch does have at least five other matrixes of 1920x1920, as well as a chain of GPU slabs and Jitter gens. (I was under the impression that jit.qt.movie and jit.matrix use CPU and system RAM rather than GPU, but that may not be the case?)
In addition to any specific intel about the GWorld error, I'd appreciate any thoughts on how to examine/diagnose what's happening with system resources related to jit.qt.movie and jit.matrix.
The only other post I’ve found about this error seemed to solve by compiling the source images in a movie and changing the frame index… not a viable option for my application.
Max 6.1.3, Mac Pro 2.66GHz Quad-Core Intel Xeon, 8GB 1066 DDR3, ATI Radeon HD 5870, Mac OS 10.6.8
Any help appreciated! Thanks!
Jeff
OK... so monitoring via Apple's Activity Monitor utility, I can confirm that this problem seems to align with Max/Jitter's RAM 2GB limit. While 64-bit may solve, my problem there is that I'm using a variety of slabs and Jitter gen for processing... and they are not all certified for 64-bit yet. :(
Examining other workarounds now...
in this case, you should try on 64 bit.
the slabs and gen files should all work fine.
please report any issues you encounter to the list.
another option is to split your patch up and run on two instances of max, and share textures using syphon.
Thanks, Rob! Reporting good progress so far (with a few caveats below)...
Actually, I've already split my patch up into separate UI/control and gfx engine instances... partially because it's the only way I can seem to get my Frankenstein monster to run without crashing and partially because it allows me to load still images from disk without interrupting the gfx animation. (I'm loading the images from disk via the UI/control patch, then piping them to gfx via jet.net.send.) Right now the UI/control is rolled into a standalone and the gfx engine is running native Max... but it's destined to be a separate standalone as well.
Re 64-bit, I was going on the C74 web caveats accompanying the 64-bit release re jitter. Good news so far... 64-bit seems to work for me so far with a handful of gfx processes loaded, although I haven't loaded up the Full Monty of slabs and jit gen.
I still have a slight concern in 64-bit in that, initially while looping through a series of matrix loads, Activity Monitor showed a continued increase in RAM and VM with each image load, just as I had in 32-bit. It seems to have leveled out at just under 4GB each for both RAM and VM on my gfx engine instance running native in Max and 1.39GB RAM and 1.53GB VM in the UI/control standalone. It's as if Max isn't disposing of old data as it rewrites matrix data... yet it mysteriously changes behavior after some critical mass (magically just under 4GB). Any clues?
So far the only real problem has been that jit.qt.movie doesn't seem to support "asynchread" in 64-bit. The "read" message seems to work for my need to load stills as well, though. I'll post if anything else breaks.
Thanks so much for your help! You rock!
Jeff