Trackpad activity temporarily locking out keyboard/mouse input in jitter patch

Hi. I'm having a problem where when I am running any demanding jitter patch (ie one that is running at a slower framerate than the qmetro I'm driving it with, so it is in a sense "saturating" the low priority queue) and I put a lot of fingers on my multitouch trackpad (built-in macbook pro trackpad or magic trackpad, OS X 10.8) and move them around, I get locked out of mouse and keyboard control of the UI of Max for anywhere from 5 to 40 seconds. Video continues to process, and scheduler events continue to run (i can still control the patch with the MIDI faders I have mapped) but keyboard and mouse control is completely unresponsive until the system deems it acceptable for me to use them again. The more fingers and motion on the multitouch trackpad, the longer it tends to lock me out for.

If i use a MIDI controller to stop the video processing qmetro, and therefore empty the low priority queue, keyboard and mouse control of the patch comes back immediately.

I don't think its anything specific to multitouch, it just generates a lot more events. I can even get the lockout to happen for a short time if I continually spin the scrollwheel of my normal mouse like a crazy person.

I thought it was something to do with patcher scrolling in Max's UI. The patcher I'm testing with does not have any objects that extend beyond the visible window, so there are no scrollbars and it never moves, but that doesn't seem to help. I've tried changing the scroll animate time to 0, turning on UI refresh with various speeds, changing queue throttle and redraw queue throttle by several orders of magnitude in each direction, turning on and off refresh - none of which helped.

But its probably not scrolling because the lockout still happens if you do lots of trackpad scrolling when the mouse is positioned over an area of blank screen space where there is no max window, if Max is not the frontmost application, and even if max is hidden so no windows are visible! When this happens, switching to max with Cmd-tab does not actually bring any max windows back to the front until the lockout has ended.

So it's some sort of weird thing where events from a multitouch trackpad register in max even when max is not in front, and flood or gum up the UI and keyboard/mouse input and/or the low priority queue (although probably not because video continues to process at normal framerate) of Max so that normal keyboard and mouse events don't get through for a long, long time.

This problem comes about because I use fingerpinger with the magic trackpad extensively as a control surface. I was convinced at first that the problem was fingerpinger - so convinced that I actually downloaded the source code and started playing around with the threading. But then I realized that the problem happened even after I deleted fingerpinger from the patch and restarted max. The upshot of this is that I compiled a version of fingerpinger that outputs messages in the scheduler thread like a well behaved Max object should, rather than in some unknown thread determined by the multitouch framework callback. The downside is it didn't solve my problem :/

I never noticed this problem before with multitouch, because before now i had only used it seriously for audio where there is not typically an intense usage of the low priority queue like there is for video.

This problem manifests itself in the big 2 person/2 computer collaborative live editing/VJ patch I just finished where, among other effects, I can rotate, zoom and move video with two fingers for each of two separate videos on the magic trackpad. During the performance this lockout would happen (at the time i didn't know why) and I was stuck with my current pair of video clips until the UI came back. Luckily I had mapped a decent amount of MIDI control so i could at least do something while waiting for my keyboard and mouse control to come back.

So - any thoughts of other things to try? I was actually hoping that this would turn out to be a problem with 3rd party externals - which is something I could actually do something about. But if its a problem with the Max app in general, that is obviously something I can't fix.

If anyone from C74 can chime in - if i does turn out to be a Max app problem, do you think there is a possibility of fixing this? And sorry for writing a freakin' book here.