From Brian Willoughby Sent Wed, Dec 5th 2018, 03:54
From Brian Willoughby Sent Wed, Dec 5th 2018, 03:54
Apple has USB-MIDI Class compliant drivers fully sorted. Apple implement = every aspect of the specification, where Microsoft Windows versions fall = short. I know this because I have designed USB-MIDI hardware and found = out the hard way where the OS support for the USB-MIDI specification = stops. For my clients, I deliver firmware that supports Windows, because it=E2=80= =99s a market necessity. Unfortunately, that requires dumbing down the = feature set to the short list supported by Microsoft. For my personal = control surfaces and MIDI interfaces, I use firmware that takes full = advantage of USB-MIDI capabilities, even though these devices only work = with Mac OS X. That said, even the USB-MIDI specification is severely lacking. It = provides no timing information, so precise timing of MIDI events is very = sloppy. This is a shortcoming of the specification itself. What you=E2=80=99re witnessing is that manufacturers like Roland and = MOTU are trying to improve on USB-MIDI by providing a = non-class-compliant implementation that adds the missing precision. The = problem here is that there is no standard for decent MIDI time stamping, = so there=E2=80=99s no way for an OS to ship a class compliant driver. = The result is that users must download drivers from the manufacturer and = install them before things will work well. That=E2=80=99s a difficult = task when operating systems are constantly changing, so I=E2=80=99m not = really surprised that hardware vendors sometimes fall behind. Note that there is a standard for better-than-USB-MIDI performance on = macOS. It falls under the umbrella of Apple=E2=80=99s CoreMIDI. Thanks = to CoreMIDI, applications like Logic can access the precise timing of = MOTU MTS (MIDI Time Stamping), and presumably whatever it is that Roland = has to get beyond the limitations of USB-MIDI. Applications do not need = to be aware of hardware specifics, or variations in the USB protocol = additions. As long as they support CoreMIDI, and as long as the hardware = manufacturers provide CoreMIDI drivers in addition to their USB drivers, = everything works. What this means is the Logic can read ahead in your MIDI sequence file, = deliver the data to the MIDI interface ahead of time in a way that = circumvents any bandwidth bottlenecks, and then the shared time = reference allows the MIDI interface to transmit the MIDI data at the = precise time it was authored for. In the other direction, incoming MIDI = is marked with a time stamp that is then delivered to the application = via CoreMIDI in a way that preserves sub-millisecond accuracy. The = caveat is that you cannot improve real-time passthrough of MIDI data = because there=E2=80=99s no looking ahead, and thus any bottlenecks in = bandwidth necessarily introduce latency. In this latter case, you=E2=80=99= re better off doing MIDI overdubs, with separate record and playback = passes, rather than attempting to do real-time MIDI manipulation. For the technical reasons described above, I recommend MOTU (Mark of the = Unicorn) MIDI interfaces that feature MTS (MIDI Time Stamping). You need = to make sure that you install the custom drivers, but it=E2=80=99s the = only system that doesn=E2=80=99t have serious flaws. (I=E2=80=99ve yet = to evaluate Roland=E2=80=99s improvements, so perhaps they=E2=80=99re on = par) Brian Willoughby On Dec 4, 2018, at 11:02 AM, Jason Proctor <xxxxx@xxxxxxx.xxx> wrote: > still a little disappointed that operating systems didn't get MIDI = sorted ages ago and we still have driver compatibility nonsense = happening this far down the line (and i say this as a developer). >=20