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?)