Forums > MaxMSP

"could not create temporary GWorld for open() error" with WindowsXP64

June 14, 2010 | 7:00 pm

The title says it all…. well sort of. I’m running a copy of Max 5.1.4 on WindowsXP and am finding that when I allow my patch to run for multiple days I start to see these error messages popping up, "could not create temporary GWorld for open() error" with regards to my jit.qt.movie objects. I also notice that once these begin to appear, my video performance in Jitter starts to suffer, with videos freezing and "catching" when other videos are loading. I will admit fully that I haven’t worked on a windows computer in years, so my personal confidence in finding the appropriate solution isn’t fully there.

My patch runs without issue on mac osx in both tiger and leopard for extended periods of time on machines with far less memory, cpu, harddrive space etc… I really ran into no issues switching to PC, except this one error message.

I’ve never had this type of error before and I’m wondering what causes it and what I can do to make it no longer appear. Anyone have insight? My other computer specs are listed below. I could always run a script that closes max/jitter at night when no one is around, but I’d really rather just be able to have it run without issue.

nico

WindowsXP 64
4 GB of memory
CPU – Intel Xeon CPU W3530
Video Card – Quadro FX 3800



Ad.
June 14, 2010 | 7:26 pm

is your jit.window in the sreen resolution ?


June 14, 2010 | 7:36 pm

I’m not sure what you mean, sorry, my jit.window has a resolution of 853 x 480, my monitor currently has a resolution of 1280 x 1024, but this is just a testing monitor. The final display monitor will have a 1360 x 768 res.



Ad.
June 14, 2010 | 8:14 pm

try @pos 0 0 argument…if it’s not the case. Your window has to be in the sreen size.
That can be one cause of the problem


June 14, 2010 | 8:25 pm

Thanks, I normally dont throw in the @pos argument until I’m finishing up testing, but I’ve put it in there now and we’ll see what happens.

Still not clear about what you mean when you speak of the "screen size" do you mean the @size argument for the jit.window object? Otherwise, I’m obviously not too bright today, could you explain what you mean a bit further when you was, "your window has to be in the screen size".



Ad.
June 14, 2010 | 8:54 pm

If your main screen is 1650 x 1080 and you put your window at @pos 2000 1200,
it can’t work.


June 15, 2010 | 4:01 pm

Yup, not an issue since my window is @pos 0 -50 for the moment. I’ll see if the @pos argument helps with this error, though it will be a few days before it’ll start to occur (if history is any indication). Thanks for the help and I really hope this solves everything for me!


June 30, 2010 | 7:46 am

And James – did this resolve the issue??

I have the same error on os x 10.6.4 and max 5.1.4

I have been doing similar stuff literally for years, and now run into this error – could it have something to do with sending different jit.windows to different dvi outputs in the new version?

Although I have the same problem just running on a macbookpro as on a desktop machine using multiple video cards: after a few hours it not only gives this error, but crashes soon after I try to intervene.


June 30, 2010 | 8:09 am

I just made a quick patch which illustrates the problem.
causes crash after about 5 mins.

what to do – what not to do……???

– Pasted Max Patch, click to expand. –

June 30, 2010 | 10:32 am

like Joost Rekveld (haha, I know his name from somewhere) also overcame the problem by first rendering to video – and then moving through my sequence by setting time (position) in the movie instead of reading (vast quantities of) images into the jit.qt.movie object one by one…


Viewing 10 posts - 1 through 10 (of 10 total)