Re: [AH] Alternatives to the UM-880 USB-MIDI interface?

From Jason Proctor
Sent Fri, Dec 7th 2018, 17:42

fwiw, the Emagic AMT-8 and Unitor interfaces implemented send-ahead
timestamping way back when (hence the name Advanced MIDI Transmitter).

not sure whether any drivers or apps still support it (maybe Logic as
previously described)

On Fri, Dec 7, 2018 at 9:18 AM Royce Lee <xxxxxxxxxx@xxxxx.xxx> wrote:
>
> I feel like midi timing on mac went through a U shaped curve, where its w=
as okay for a while (for me opcode on a beige power pc),then around the tim=
e of the big blue and white, plastic enclosures (G3,G4) it was horrible, an=
d now, it is really quite good.
>
> During that middle period I always wondered how anybody in the world made=
 records.
>
>
>
> On Fri, Dec 7, 2018 at 9:41 AM xxxxx@xxxxxxxxx.xxx <xxxxx@xxxxxxxxx.xxx> =
wrote:
>>
>> I=E2=80=99m thirding the Mac/MOTU MIDI - just recently I did test sendin=
g tight 16ths from logic to MIDI synth (in this case Doepfer MIDI > CV) rec=
ording in the result.
>>
>> MIDI timing on the mac has been a bug bear of mine since forever (well a=
ctually post RS-232 serial bus days!) and I was impressed - the final key w=
as entering low latency mode in Logic.
>>
>> No noticable jitter (I had to offset it a little).  This was with a real=
ly old MOTU FW 828 MKII on a new MBP and a nightmare USB3 -> lightning -> F=
W stack of dongles (=C2=A360!) but worked.  Even MIDI clock wasn=E2=80=99t =
too bad - there is a calculate plug-in latency mode in Logic which seems cl=
ose to usable.
>>
>> If the USB is as good then I wouldn=E2=80=99t have a problem with MOTU s=
tuff.
>>
>> Alex
>>
>>
>> From: Bruno Afonso <xxxxxxx@xxxxx.xxx>
>> Reply: Bruno Afonso <xxxxxxx@xxxxx.xxx>
>> Date: 7 December 2018 at 13:56:56
>> To: Brian Willoughby <xxxxxx@xxxxxxxxxxxx.xxx>
>> Cc: Analog Heaven <xxxxxxxx@xxxxxxxxx.xxx>, Jason Proctor <xxxxx@xxxxxxx=
.net>
>> Subject:  Re: [AH] Alternatives to the UM-880 USB-MIDI interface?
>>
>> Brian is right, what is nice about the motu stuff is their timestamping.=
 Drivers can be finicky at times. I'm curious to know about the timing of t=
he newer mio offerings... with a uC or smart oscilloscope one could properl=
y test these. I don't have a mio...
>>
>> On Tue, Dec 4, 2018, 22:56 Brian Willoughby, <xxxxxx@xxxxxxxxxxxx.xxx> w=
rote:
>>>
>>> Apple has USB-MIDI Class compliant drivers fully sorted. Apple implemen=
t 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 f=
eature set to the short list supported by Microsoft. For my personal contro=
l 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 prov=
ides 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 MO=
TU are trying to improve on USB-MIDI by providing a non-class-compliant imp=
lementation 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 fo=
r an OS to ship a class compliant driver. The result is that users must dow=
nload drivers from the manufacturer and install them before things will wor=
k well. That=E2=80=99s a difficult task when operating systems are constant=
ly changing, so I=E2=80=99m not really surprised that hardware vendors some=
times fall behind.
>>>
>>>
>>> Note that there is a standard for better-than-USB-MIDI performance on m=
acOS. It falls under the umbrella of Apple=E2=80=99s CoreMIDI. Thanks to Co=
reMIDI, applications like Logic can access the precise timing of MOTU MTS (=
MIDI Time Stamping), and presumably whatever it is that Roland has to get b=
eyond 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 C=
oreMIDI 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 circumv=
ents any bandwidth bottlenecks, and then the shared time reference allows t=
he MIDI interface to transmit the MIDI data at the precise time it was auth=
ored 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 prese=
rves sub-millisecond accuracy. The caveat is that you cannot improve real-t=
ime passthrough of MIDI data because there=E2=80=99s no looking ahead, and =
thus any bottlenecks in bandwidth necessarily introduce latency. In this la=
tter case, you=E2=80=99re better off doing MIDI overdubs, with separate rec=
ord and playback passes, rather than attempting to do real-time MIDI manipu=
lation.
>>>
>>> For the technical reasons described above, I recommend MOTU (Mark of th=
e 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 evalu=
ate 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.net> wrote:
>>> > still a little disappointed that operating systems didn't get MIDI so=
rted ages ago and we still have driver compatibility nonsense happening thi=
s far down the line (and i say this as a developer).
>>> >