Hacker News Reader

Comment by prox | Hacker News Reader

Of all technologies, I believe MIDI has been the most plug and play experience for me. Plug a midi cable in, boot up a sequencer and you are good to go. Really interesting to see what can be done with MIDI 2.0

View on HN

I was trying to write a program using midi last year and was surprised by the lack of any libraries to work with it. Then I looked up the spec and was able to get all the functionality I needed with 10 lines of code interacting with /dev/midi. Incredible how powerful such a simple interface is.

Midi can plug-and-play so easily because there is no handshaking. Every midi capable device has already agreed upon the 31,250 serial baudrate and 8-bit data + 1 stopbit format and the commands.

The only occasional problem I'll experience with midi is if I unplug before sending a note-off for a note, then that note might forever be stuck on.

And even that is not really a protocol problem. It's trivial for a device to implement "reset-on-disconnect".

The problem is that there is no such thing as a disconnect signal, so a device can't know a cable has been pulled or something in between has been powered off; if it happens then the device is left hanging with a note on, and one must find a way to send the relevant note off or the all notes off message when communication is restored. Adding such controls (aside the simple reading of the current loop value that doesn't solve all problems) would require one more layer which would translate in more complexity and more latency.

If I had to implement such things on top of an improved protocol, I would likely also ditch the serial link, ignore completely USB, and jump straight to Ethernet, which is damn fast, near realtime, supported pretty much everywhere (Ethernet switches would essentially work as MIDI Thru boxes) and free of royalties. Devices in the same local network wouldn't even need the transport and above layers to work, so latencies would be extremely low, but adding more IP stack layers would allow to remote things easily.

>There is no such thing as a disconnect signal

Incorrect :) MIDI OUT provides power. No power = disconnect.

That's not to mention that you don't need a signal for *physical disconnect Your stereo knows when you unplug headphones.

The midi out port provides a small current (a few mA) that is used only to drive the photocoupler at the receiver side (per MIDI specifications, transmitter and receiver have to be electrically insulated). It doesn't and can't supply anything else, although in the past some manufacturers produced little out-of-standard devices that took their supply from the MIDI signal, but they were mostly marketing gimmicks.

Moreover, MIDI is a digital signal which doesn't carry any status about the media it travels through; I mean, 10 seconds of nobody playing would appear identical to 10 seconds after a pulled cable.

> jump straight to Ethernet, which is damn fast, near realtime

And could optionally use ptp (precision time protocol) Ethernet interface so that the local network clocks are synced to sub-microsecond precision, and so can put timestamps on the midi messages so they can be properly sequenced.

And for increases reliability, incorporate with AVB which uses stream reservation to ensure priority packets can get sent.

Seems you guys should start up :)

Btw I think the hard part is probably not he implementation of Ethernet, but getting hardware vendors on board. Midi 2.0 needed a lot of companies to be on board for the change.

Perhaps if you make adapters and translate devices to help folks transition.

There already are adapters around and software/libraries to build applications to tunnel MIDI over IP, but the hard part IMO is to define a standard so that different products can talk together. Small Ethernet capable microcontrollers are cheap, so once a standard is defined it would be easier to implement it on devices.

https://www.thomann.de/gb/bome_bomebox.htm

https://openmuse.org/transport/mip_oview.html

http://www.linuxsampler.org/ethernetmidi/

https://qmidinet.sourceforge.io/

etc.

That's all good up until you try to synchronize different MIDI devices with their own sequencers. Even "voltage triggering" is more accurate...

have you tried using https://en.wikipedia.org/wiki/MIDI_beat_clock

The clock is not very accurate and devices have to interpolate it. Which is something they all do slightly differently, especially if the tempo changes - which doesn't happen much in pop, but happens regularly in media composition.

If you're lucky the result will be in-time-ish, but it's never going to be sample accurate.

This actually matters for some applications, including sound design. If you trigger two samples with a variable offset you can get phase cancellation and other easily audible effects.

DAWs are sample accurate now, but 5-pin DIN MIDI 1.0 really isn't.

Reply on news.ycombinator.com