[sdiy] MIDI Clock sync advice

brianw brianw at audiobanshee.com
Sun Mar 10 01:59:06 CET 2024


What I find interesting is that Emagic had a proprietary USB protocol for their AMT interface, and MOTU has their MTP. These both require custom USB drivers because they're not USB-MIDI Class compliant, but they do handle time stamping so that USB packet delays do not ruin recording (although there's not much you can do in real time other than purposely introduce a fixed delay to eliminate the jitter).

Even more interesting is that CoreMIDI allows applications to specify the timing of MIDI messages, and the MOTU drivers honor these time stamps so that the application can deliver MIDI data slightly in advance and the remote MIDI interface can schedule the events precisely.

What would be nice is if there were an open standard for AMT or MTP that new products could implement.

Brian


On Mar 9, 2024, at 3:16 PM, Tom Wiltshire wrote:
> The framing delay is why I won't touch USB-MIDI with a 6ft bargepole. The idea that some super-fast modern protocol has a jitter that is the same as the latency of an entire MIDI message is just hopeless. That cannot remotely be seen as progress! USB wasn't designed for this job and it shows massively.
> 
> A decent UART 5-pin MIDI implementation can still provide better timing, even at 31.25KHz. That's *shocking*, given that 40 years have passed.
> 
> On 9 Mar 2024, at 22:31, brian wrote:
>> On Mar 9, 2024, at 8:47 AM, Benjamin Tremblay wrote:
>>> Let’s pass usb midi through TOSLINK and call it a day.
>> 
>> Don't say that! ;-)
>> 
>> USB-MIDI is not MIDI. *
>> 
>> Better to say, "Let's pass Classic MIDI through TOSLINK and call it a day."
>> 
>> Ideally, "Let's pass MIDI over ethernet and call it RTP-MIDI." ... and wha'd'ya know, we already have that! Ethernet is generally ground isolated, although it's best to design for even better isolation than is typical.
>> 
>> FireWire is another existing standard for MIDI transport, although FireWire is now dead.
>> 
>> If you think about all of the other standards that have come and gone, it's incredibly impressive that MIDI has lasted 40 years, and modern gear can still connect to original gear. There aren't many standards where electronic devices from 40 years ago will work with modern equipment without some adapter.
>> 
>> Brian
>> 
>> (*) USB-MIDI converts MIDI messages that are 1 to 3 bytes long into 4-byte packets, where the added 4th non-MIDI byte includes redundant type information that can unfortunately be inconsistent with the same type information in the Classic MIDI message. Yes, I've seen actual USB-MIDI implementations where the two types conflict with each other, and there's no way to know which type is correct and which is in error. USB-MIDI also delays MIDI information by up to 1 ms in the best cases (0.5 ms average), even more when the USB Host has scheduling issues, and transmits the information without any time stamp that might indicate the timing of the original MIDI message before the USB framing delay. Because of all of the changes that USB-MIDI introduces, it would be best not to duplicate those for non-USB transports like a hypothetical TOSLINK transport. Instead, it would be better to follow the precedents set by other alternative MIDI transports that the MMA has specified.
>> 
>>> On Mar 9, 2024, at 11:05 AM, Mike Bryant wrote:
>>>> Nothing is stopping equipment having USB ground isolation - it's just never specified.
>>>> 
>>>> From: John Speth
>>>> Sent: 09 March 2024 15:14
>>>> 
>>>> On 3/9/2024 7:00 AM, Benjamin Tremblay via Synth-diy wrote:
>>>>> USB is just not ideal for music devices because of the star networking pattern. If we could evolve to a point where every usb cable is usb C and all connections are peer-to-peer, we could finally sunset five pin midi.
>>>> 
>>>> Except that 5 pin MIDI has the most excellent ground isolation. We don't 
>>>> get that with USB MIDI.




More information about the Synth-diy mailing list