Thanks for providing some example code, that makes it much easier for us to investigate the problem. I can reproduce the issue with the provided sample.
The docs for sendBlockOfMessages say that the time is specified using the same time base as Time::getMillisecondCounter. If I switch your demo to use that function in getNextAudioBlock instead of the HiRes version, then the timing issue seems to disappear and notes are immediately forwarded to the output.
I tried artificially creating very rapid outgoing midi events and didn’t see this ‘burst’ behaviour. My output device is the computer’s built-in MIDI synth.
How large is your audio block size? In your example, you’re sending all of the outgoing messages at time ‘0’. If your blocksize is large (e.g. 4000 samples) then the messages will only be sent once every 100ms or so. Maybe this is the cause of the ‘bursts’ of notes. You might get better results by keeping track of the relative times of the incoming messages, rather than setting them all to 0. It’s probably also a good idea to check that the outgoing note-ons and note-offs are properly matched (i.e. avoid sending two consecutive note-ons on the same key) just in case this is confusing the output device somehow. You could also try sending the outgoing midi events to a MIDI Monitor app so that you can check the message order and timestamps yourself. If the messages look good in a MIDI monitor, then the ‘burst’ issue is probably caused by the MIDI output device, rather than the app itself.
This is the intended behaviour. The demo isn’t intended to pass messages from inputs through to outputs. It just logs incoming messages, and allows messages to be sent from the onscreen keyboard.