[sdiy] Tools for testing MIDI

[chris]

On 21/05/2026 00:25, brianw wrote:
> What I recommend is to have two queues: One for System Real Time messages, and another queue for non-real time messages. You can't write the MIDI Clock immediately, unless the serial port is idle, so you need a dedicated queue to hold those timing-critical messages. With this design, your async serial output interrupt can first check the system real time output queue for anything, and prioritize any bytes there. If there's nothing in the real time queue, then the async serial interrupt handler can move on to the non-real time queue for lower priority data.
>
> I have not determined how big the System Real Time queue needs to be, but obviously you can get by with only a few bytes. I don't see how you could get hundreds of bytes behind for system real time unless there's something horribly wrong. Nothing will stay in the real time queue for long anyway, since it has top priority. Since many 8-bit MCU chips have limited RAM, saving on queue size is important.
>
If you're only sending clock, the second queue may be shrunk down to a 
simple flag, set by a timer. As soon as the send register becomes (or 
is) available and the flag is set, bam - send a clock byte, and clear 
the flag.

If there may be other real time messages, a real (but small) queue will 
be needed.

However, the flag scheme may be insufficient if the sending system can 
be busy with lots of things - then it would still be better to send 
multiple delayed clock messages late than never.


Chris