12-02-2020, 04:20 PM
The best results for timing is to use a MIDI Thru device that has no processing. When the MIDI device supports filtering, merging, channel mapping, etc, then the processor in the device has to process and dispatch every MIDI message. MIDI note data is very slow relative to modern processor speeds, but when you add 24 PPQ clock there's a lot more data to sort. A hardware MIDI thru has no processing or routing features, so its just electrically repeating the MIDI data and there will be no latency. Of course, this isn't always the best or most convenient solution for a complicated studio. For instance, my Sequential Circuits Prophet 600 was a version that was always OMNI, so it would listen to every MIDI channel on the port. A good case for channel filtering.
The good news is, modern microcontrollers are so fast, and have microsecond timers so MIDI data is no challenge to process quickly and accurately. Most things are happening in nanoseconds and the processor is just waiting for slow slow MIDI data. It makes us wonder why USB MIDI has so much latency on a Windows PC! We know why, because there is no priority feature in the OS that is available to the USB audio class driver. We think the USB MIDI performance on MRCC will be much better than a PC! One of the well respected legacy MIDI routers was the Edirol UM-880 and 550. They had a processor for every 2 inputs routed to the main processor, which they could bypass if there was no MIDI processing to be done. Fortunately we don't need to do this anymore, but in its day it was the best way to make it a great performer.
You can also introduce latency and jitter, and even corrupt data by daisy chaining MIDI connections from device to device. Some MIDI Thru ports are actually being processed at the input. The worst MIDI timing I've ever seen was with the Korg Kaoss Pad. It tries to "beat match" the MIDI clock, and immediately starts drifting. When we designed The NDLR, we used this lesson to handle external MIDI clock differently. We use each clock message as if it were our own internal clock tick. So what you send it is exactly what you hear. It works as a pretty good BPM meter too. The downside is, when the external clock stops, so does The NDLR.
The good news is, modern microcontrollers are so fast, and have microsecond timers so MIDI data is no challenge to process quickly and accurately. Most things are happening in nanoseconds and the processor is just waiting for slow slow MIDI data. It makes us wonder why USB MIDI has so much latency on a Windows PC! We know why, because there is no priority feature in the OS that is available to the USB audio class driver. We think the USB MIDI performance on MRCC will be much better than a PC! One of the well respected legacy MIDI routers was the Edirol UM-880 and 550. They had a processor for every 2 inputs routed to the main processor, which they could bypass if there was no MIDI processing to be done. Fortunately we don't need to do this anymore, but in its day it was the best way to make it a great performer.
You can also introduce latency and jitter, and even corrupt data by daisy chaining MIDI connections from device to device. Some MIDI Thru ports are actually being processed at the input. The worst MIDI timing I've ever seen was with the Korg Kaoss Pad. It tries to "beat match" the MIDI clock, and immediately starts drifting. When we designed The NDLR, we used this lesson to handle external MIDI clock differently. We use each clock message as if it were our own internal clock tick. So what you send it is exactly what you hear. It works as a pretty good BPM meter too. The downside is, when the external clock stops, so does The NDLR.