midi thinning

I had this issue with something I was working on, and as far as i could tell, I had to 'fix it at source'.

one possible thought,
iirc (*) , the midi is initially read in a lower priority thread as its IO, before being passed to the audio thread.
perhaps it could be thinned there, as it comes in.
it would have to be selective thinning, i.e. you dont want to thin note messages, only continuous messages like cc/aftertouch.

(*) its been a long time since I looked at this code, so may have changed alot

the render() function in the heavy wrapper goes through all the available messages:

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

Now, I have two guesses as to where the performance sink is. One possibility is that hv_sendMessageToReceiverV() is just very expensive. The other is that it is not that expensive, but several messages have stacked up in the parser, and therefore numAvailableMessages() returns a large value, which in turn means that the loop is executed so many times that it eventually causes a dropout. I guess the actual cause is a combination of the two. When running at 8 samples per block, the audio callback runs every 180us. When using 50% of the CPU, that leaves chunks of about 90us for the OS to do all its things AND to read MIDI inputs. Consider that a
thread may take anywhere between 20us to 100us and beyond to wake up. If the thread that runs Midi::readInputLoop() (which runs at Linux priority, not Xenomai priority, because it performs USB I/O) does not get to run for a while, and in the meantime several MIDI messages have stacked up in the input buffer, these may become visible to the audio thread (via numAvailableMessages()) all at once.

One thing you could do is to verify for what values of the return value from the first call of numAvailableMessages() you start getting dropouts. Then, try and comment out the hv_sendMessageToReceiverV(...); call (at least for ControlChanges, which I assume are the ones that are causing the issue for you): are the dropouts still there?

I will have a look on the scope to see how expensive the call to hv_sendMessageToReceiverV(...) is, but it would be good if you could figure out how many numAvailableMessages() are leading you to dropouts.

thetechnobear perhaps it could be thinned there, as it comes in.

yes it's a possibility. I figure for large blocksizes and low CPU usage by the audio thread, the non-rt loop could actually run several times between calls to render(), at which point thinning would be not fully effective (i.e..: render()` may still receive some duplicates), but then in that case it shouldn't be a big problem.

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