midi thinning

hv_sendMessageToReceiverV does not look particularly 'heavy' to me.
basically it just creates a timestamped message and places it on a queue …
I assume it will then process the pipeline during hv_process() , so once per block as this would be inline with what pd does for control rate msgs.

I think giuliomoro previous point about 'stacking' up is the issue, a controller does not produced messages at anywhere near 180uS... so Id think the parse is backing up due to not enough cpu time.
… but if that's the case, then its just there is not enough spare time to process, but why?

have you monitored the cpu? are you seeing a cpu spike when you send the messages?
(when your app code is not processing them - as that needs to be removed from the equation)

would thinning help? and where?
I guess ideally it would be done in the midi parser... so render() doesn't even get it.
but it might still work in the heavy render(), since although the sendMessage may not be expensive, the audio thread is still going to have to process the control pipeline later... and that may be heavier.

I think what I would do, is try to implement a rudimentary thinning in render() , since I assume you know what the troublesome messages are.
if its mpe , they are pitchbend, cc74 and ch. pressure,
so you'd just need to store these 'per channel' along with a timestamp, and then only send if the new time vs last time is greater than your set threshold.
it be an interesting test, as it would point to if the cpu issue is below the heavy layer or not.

( I think its a bit more difficult to do without overhead, in the generic case, since you'd need to store a timestamp for every note/cc/ and midi msg type.... which is a fair amount of data, albeit not that big... also grabbing a timestamp is expensive … unless we can use the one that accompanies the midi message, is that of sufficient resolution?)

lokki i still went along and commented the hv_sendMessage part for cc messages out. this made underruns far less frequent, but they still occur

hmm that's interesting. I am looking at all parts of the code in that while() loop and I cannot really find the bottleneck. I will really have to plug this into a scope and try and troubleshoot it that way.

thetechnobear I assume because its a control rate message, so will only every be processed 1 per block (if its going to behave like PD does), so it will process the pipeline during hv_process() (?)

Good point. This means debugging will be harder, as I will have to poke at the heavy internals at runtime.

thetechnobear have you monitor the cpu? are you seeing a cpu spike when you send the messages

CPU usage is an average (not sure over which time period), so you are unlikely to see the spikes that lead to dropouts (as they'd be concentrated in a few us).

thetechnobear so you'd just need to store these 'per channel' along with a timestamp, and then only send if the new time vs last time is greater than your set threshold.

I think the first thing you want to do is making sure that you send at most ONE message per CC number per each call to render(), which may be slightly simpler than that. So, if you receive 6 messages that are all for CC 1 , discard them all except the most recent one, and only send that one to heavy. This is easier said than done, however.

In the meantime, if you are in a hurry and all you care about is just to get it done with it, the easiest implementation is just non-discriminating throttling as suggested by

thetechnobear what might be worth a test is to only process a maximum number of messages for each render.

That would be done as:

 int msgs = 0;
 int maxMsgs = 5;
 while(msgs++ < maxMsgs &&  (num = midi[port]->getParser()->numAvailableMessages()) > 0)
{
...
}

Make a note about the earlier points about increased latency of this approach.

@lokki how do you have the qunexus setup up?
is it only sending continuous CC per note, or are you doing other messages like channel or poly pressure, and pitchbend? as you could try commenting them out in the render() as well.

also how many keys are you holding down?

another interesting possibility, is to run one of the C++ examples that process midi
do they exhibit the issue? this could help eliminate heavy from the 'enquiry'

lokki is there a way to see if my patch has some spikes in cpu usage even without midi? (and that one midi message causes the underrun)

do you have a good scope?

EDIT: digital scope that can do some basic stats (average, min, max of the duration of a pulse).

You could toggle a GPIO before and after the heavy callback. Use this example as a starting point. Basically, besides the code in setup(), you'll need:

gpio.write(1);
// code you want to test goes in here
// ...
// ...
gpio.write(0);

So you could start from:

gpio.write(1);
hv_processInline(gHeavyContext, gHvInputBuffers, gHvOutputBuffers, context->audioFrames);
gpio.write(0);

and then see if you can spot some inconsistencies there. If that is not the case, move gpio.write(1) earlier, possible to the top of render(), but I think it is most likely that the bottleneck will be hv_processInline().

Then connect the scope to the GPIO in use and see if you see irregularities in the length of the callback.