Evaluating whether to add a queue for outgoing midi messages...

[Guod3]

I have been able to develop my app very rapidly thanks to your library.
The app generates CC messages from an encoder array. I'm simply calling sendControlChange() on my instance of USBMIDI_Interface.
Is there much serial data buffering downstream of this? For example I imagine the USB midi itself would a have a FIFO. If there is, I will not bother with implementing a send queue, unless there is a definite need. At this point the risk of producing too much data at once is probably low (an array of 50 or so push switch/rotary encoders).

[tttapa]

Usually, you don't need a FIFO: MIDI over USB has flow control, which means that the Host will wait for you if you can't read quickly enough, and the code will simply block if you try to send more data than the Host can process (which is rather unlikely in normal use).

In many implementations, there will be one or two buffers of 64 bytes (16 messages). They're used as a simple buffer, not a circular FIFO: when you send a message, it is placed at the first free position in the buffer. Then either the buffer becomes full and this triggers a transmission of the entire buffer, or a timeout occurs before the buffer is full, also causing it to be transmitted.
A property of USB is that 64 bytes are always transmitted, regardless of whether the buffer was full or not.

Some lower-end microcontrollers (e.g. Arduino Leonardo) don't support a timeout, so a transmission is only triggered if the buffer is full, or when calling the sendNow function. For these boards, Control Surface automatically flushes the buffer after each message by default (which is wasteful in terms of bandwidth, but results in lower latency and is the only way to reliably transmit the data). You can tweak this behavior using the alwaysSendsImmediately(), neverSendImmediately() and alwaysSendImmediately() methods of the USBMIDI_Interface class (apologies for the naming).

If you need to send multiple messages at once, it's recommended to use the following trick:

bool restore = midi.alwaysSendsImmediately();
midi.neverSendImmediately();
midi.send(...); // Fill up the buffer with the data you need to send
midi.send(...);
midi.sendNow(); // Trigger transmission of the buffer
if (restore)
    midi.alwaysSendImmediately();

There is currently no way to query how many bytes can be sent without blocking, simply because the low-level backends don't expose this information (see e.g. MIDIUSB).

[Guod3]

Thanks for the detailed answer!
I'm using an ATmega32u4 board (teensy 2, or pro micro) so the lack of timeout is relevant to my situation.
I can have an internal FIFO, length of which would represent up to 64 bytes of midi messages, that would be emptied in a manner you showed me, at an interval I can specify ( 10 or 20 ms, I think).
Would this be emulating the unsupported timeout feature?