Overdrive doesn’t seem to do much of anything for me, particularly for patches that involve sending out MIDI data. Even with overdrive on AND scheduler in audio interrupt, the timing accuracy of my MIDI data is seriously degraded by doing simple ordinary tasks such as resizing a window, opening up the File menu, etc. I thought overdrive was meant to put things like window resizing and screen redraws into a lower priority than max messages.
By the way, the patches I’m using are not very complicated at all, and are not sending out very much MIDI data (a couple of notes every 250ms), Max’s CPU usage while the patch is running is about 12%. When I start resizing a window, it jumps up to 60% and the tempo of the MIDI output gets completely erratic.
I can’t reproduce here. I can tell you that if you are opening other large patches or loading files, you may experience some time slippages while this activity takes place. But resizing a window (and most patching/ui activities) for example should not cause this.
If you would like, send along a simple patch with some steps to reproduce to support at cycling74 dot com and i’ll take a look.
I just tried creating an example patch but couldn’t reproduce the behavior. I went back to my original patch and realized that I had a js object in the middle of my signal chain. I set all of the js functions’ "immediate" properties to 1, and the problem went away.