When to flush MIDIUSB

From the MIDIUSB reference:

[b][color=#E67E22]MidiUSB.flush()[/color][/b]

This function forces the USB layer to send the data immediately. Since the USB bus is not realtime, a sendMIDI() doesn't guarantee the data to be sent with the correct timing unless immediately followed by a flush()

When sending multiple messages immediately after each other, should I flush after each message, or after all messages have been "sent"?

midiEventPacket_t msg = {0x09, 0x90, 0x3C, 0x7F};
MidiUSB.sendMIDI(msg);
MidiUSB.flush();
MidiUSB.sendMIDI(msg);
MidiUSB.flush();
MidiUSB.sendMIDI(msg);
MidiUSB.flush();
// ...

or

midiEventPacket_t msg = {0x09, 0x90, 0x3C, 0x7F};
MidiUSB.sendMIDI(msg);
MidiUSB.sendMIDI(msg);
MidiUSB.sendMIDI(msg);
// ...
MidiUSB.flush();

What happens when the TX buffer is full? Will it block, flush automatically and send the message when the buffer is empty again? Do I risk dropped messages? Will there be a large delay?
Is there a performance penalty when flushing after each message?

The relevant lines of the MIDIUSB library are here.
The implementation of USB_Send is here.
It seems to block for a maximum of 250ms if there's no more space in the TX buffer, but I'm unsure if and when it will start flushing the buffer if flush() is never called.
My knowledge of USB is not good enough to understand the entire PluggableUSB/USBCore.

Thanks,
Pieter

What happens when the TX buffer is full? Will it block, flush automatically and send the message when the buffer is empty again? Do I risk dropped messages? Will there be a large delay?

The sendMIDI() call writes the data to a buffer. If the buffer is full it will be sent but not the same way as in a flush because if there is data written which is not yet in the buffer when it's been sent, that data may stay in the buffer. You don't risk dropped messages. The delay may be quite large.

Is there a performance penalty when flushing after each message?

Yes, but not a big one.

In your example code I would use the second option as you do a flush when you sent everything. The flush after each message is not necessary. But I would definitely do a flush before you do any task that may keep the processor busy for some time (even if that time is measured in ms).

pylon:
if there is data written which is not yet in the buffer when it's been sent

Not sure what you mean here, could you clarify?

pylon:
The delay may be quite large.

What determines the duration of the delay?

pylon:
But I would definitely do a flush before you do any task that may keep the processor busy for some time (even if that time is measured in ms).

Isn't the sending handled in an ISR?

Not sure what you mean here, could you clarify?

If the buffer gets full it might be that the message you just wrote didn't fit into the buffer. So although the buffer was "flushed" it isn't empty after the write.

What determines the duration of the delay?

I haven't studied the complete code. The message are written to the processor-internal FIFO so the delay until they are actually written is probably not that high. If you call flush, the rest in the FIFO is sent immediately.

Isn't the sending handled in an ISR?

Probably but I don't know the hardware well enough to answer that. But the way to do it is clear: send all messages that you have ready at the moment and then call flush.

Okay, thank you for your replies.