I don't know about clearing the MIDI "cache", if there is one in Max or the OS, but you could try [change] and especially [speedlim] to thin out how many CC messages you're getting. Try [speedlim 50] first, which is fast enough to seem like there's nothing throttling it, then adjust to fit. This has helped me a lot in the past with similar issues.

If you find that something like [speedlim 250] will keep things from crashing better, and the update rate isn't good enough, use [line $1 250] to smooth out the values (you could set the [line] time grain to 50 perhaps). While this will send more values to your eventual usage of the numbers (so it would seem like it's a step backward), your crash might be related to the transfer of MIDI beforehand, not the values going into the jitter patch. To experiment, see if a patch will crash if you just show the raw CC messages as numbers, which I imagine it won't. Then you can trace where the overrun happens, step by step... could be a backlog of jitter drawing/op commands down the line.

Are you formatting the MIDI data by means of a message box (that is not getting cleared)?

change and speedlim are excellent ideas.

"Then you can trace where the overrun happens, step by step... could be a backlog of jitter drawing/op commands down the line. "

"step by step" debugging is really hard when the crash is inconsistent. something could appear to be running fine, but actually be the culprit of the crash if it's causing a memory leak, or something insidious like that.

to spectro, the MIDI messages are being sent to number boxes then scale objects.

seems to be running smoothly after putting a change/speedlim message in front of every ctlin. also halved the size of the two qt.movie objects to 320-240.

Could I see your patch? Trying to experiement a bit with midi messages from my monomachine and in the future possibly a machinedrum, but it is a little harder to grasp than I thought.