yeah, I believe something is 'spiking' which is holding up all processing hence why the midi message arrive in a single burst.
(I really would not expect to ever see more than 1 message in that queue, given the regularity its called)
but hard to know whats the spike is, could be heavy, could be the patch, could even be something related to IO over USB.
now I don't think its USB IO as I do quite heavy usb IO with the soundplane, and its ok. however, I dont use midi (and so alsa) , and I don't use heavy. (*)
as for the tests.
I think if you have ctlin contained in your patch, but not connected - then I think heavy is doing all its work (in terms of distribution) .. so if its not underruning then, id say there a spike in your patch perhaps as a result of midi messages coming in. at least that would be my initial working assumption....
you could try to 'replicate' this by removing the midi io entirely and creating an lfo or sequence (or similar) which 'emulates' what you'd expect from your controller then
- if it underruns you know its something in the patch (unrelated to midi)
- if it doesnt underrun (and its a fair emulation 😉 ) then it points back to midi.
note : I must admit I've also been really careful how I put together my apps though, in particular I do as much processing as possible OFF the audio thread.
if I take your example above, all the processing of your CC messages would be done in an aux thread. (eg. route /127, motf) - unfortunately thats not possible with PD (esp heavy)