midi thinning

it's not actually that straightforward, because the underrun is detected in the backend. One solution is to use a global variable to record the latest count of available messages and then print it out if there was an underrun.
Edit the file in core/PRU.cpp (on the board) as follows (add the lines with a leading +, remove the line with a leading -):

diff --git a/core/PRU.cpp b/core/PRU.cpp
index 65f74f95..10d484d7 100644
--- a/core/PRU.cpp
+++ b/core/PRU.cpp
@@ -854,6 +854,7 @@ int PRU::testPruError()
        }
 }

+unsigned int gGlobal;
 // Main loop to read and write data from/to PRU
 void PRU::loop(void *userData, void(*render)(BelaContext*, void*), bool highPerformanceMode)
 {
@@ -1450,7 +1451,7 @@ void PRU::loop(void *userData, void(*render)(BelaContext*, void*), bool highPerf
                                // don't print a warning if we are stopping
                                if(!gShouldStop)
                                {
-                                       rt_fprintf(stderr, "Underrun detected: %u blocks dropped\n", (pruFrameCount - expectedFrameCount) / pruFramesPerBlock);
+                                       rt_fprintf(stderr, "Underrun detected: %u blocks dropped. Value: %u\n", (pruFrameCount - expectedFrameCount) / pruFramesPerBlock, gGlobal);
                                        if(underrunLed.enabled())
                                                underrunLed.set();

Then in render(), your approach above would work, but it's probably easier to just call getNumMessages() one more time, before the while():

 gGlobal =  midi[port]->getParser()->numAvailableMessages();
 while((num = midi[port]->getParser()->numAvailableMessages()) > 0) 
{
  ...
}

Does it make sense?

what might be worth a test is to only process a maximum number of messages for each render.
this would help, if there are 'peaks' in the flow as it would even them out a bit.

it won't help much if the flow is continuously very high, and it would introduce latency.
(in that case, Id think thinning really is the only option)

what I'd also check is that its not the patches processing of the midi messages thats not too computationally expensive e.g. if you remove the processing, do you still get underruns.
if not, then you'd likely be able to do the thinning in the patch.

one thing Ive seen with some expressive controllers is continuous expressions can 'bounce' around quite a bit.
i.e. when you think your finger is holding a steady pressure, it might be bouncing between cc74 = 65,66,65 at the full data rate (which could be 250-500 msg/sec). this really needs to be smoothed, I usually use a cheap low pass filter (or similar...)

imo, it also often ends up sounding better - e.g. without this my Soundplane can sound quite 'jittery'.

note: this depends upon controller and its software, often the software/firmware will have this filtering as an options, as its a really effective way to reduce data.

lokki error: use of undeclared identifier 'gGlobal'

sorry you need an

extern unsigned int gGlobal;

at the top of the render.cpp file

lokki i "preprocess" all cc messages like this to route them per channel and cc number easily, maybe heavy/pd does not like the message $ or something...

When you say this:

lokki just sending the messages to heavy without even connecting anything in heavy/PD leads to dropouts

what does the patch look like? Just [ctlin] without anything connected to it? Can you try with deleting [ctlin] altogether?

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)