max is too busy to deal with me
hi
my max jitter rig is in a processing coma
I asked it to render something thats so scheduler intensive that no amount
of click on toggle or shifting out of perform mode affects it, its got
another 1950 frames to process before the auto shut initiates, but just in
general this often happens where max is so busy with an uzi or qmetro big
old process that is locks up for ever without being able to poll for new
user commands, is their any option in max like "underdrive" or something so
that user interface can push into the clouds of activity and maybe touch a
toggle so I can tune the program out of the over abundant redundant
incesance that its looping through for another couple hours? maybe a hot key
that does the opposite of resume. STALL?
have you tried command-period to stop the scheduler? works most of the time for me when my metros are banging my jitter effects or whatever too fast and things get stuck.
-CJ
At 3:48 PM -0700 9/6/07, Derek Franz wrote:
>my max jitter rig is in a processing coma
Perhaps you could sprinkle some deferlow’s around in the non-critical part of your patch? I’ve had some success squeezing out a little more responsiveness using this method.
-C
–
Chris Muir | "There are many futures and only one status quo.
cbm@well.com | This is why conservatives mostly agree,
http://www.xfade.com | and radicals always argue." – Brian Eno
non critical?! well I put it in the critical part and it didn’t help….haha
Ill try to find some non critical parts next time
I’ll try the command . next time it locks up, sometimes just making sure I
put a 0 message on the metros is enough cause toggle you never know if you
hit them once and were ignored or hit them again and got through turns out
to be a double hit and your back in the fryer
http://www.vcnet.com/~franz/max/
fun stuff