Please tell me everything you know about MIDI over Ethernet or MIDI over IP.

February 11, 2007 9:55 PM

Please tell me everything you know about MIDI over Ethernet or MIDI over IP.

Or, more specifically, how do I set up MIDI over IP? How do I optimize it for performance and reliability? Pitfalls? Limitations?

What kind of overhead or load can I expect from the software MIDI over IP clients? (Windows machines, but in general.)

posted by loquacious to technology (14 comments total)

MIDI as a standard implies RS-232. Strictly speaking, "MIDI over ethernet" is a contradiction in terms.

Music Instrument Digital Interface == MIDI but "MIDI" has become used for a lot of different things. For instance, it refers to a data format. It refers to a physical layer and a software handshake protocol (with the physical layer being RS-232).

I suppose you could replace the physical layer with TCP/IP, but it would be a bit strange. The main problem would be timeliness; MIDI requires information to be sent and received in a timely manner, and TCP/IP is not known for that. This being music, milliseconds matter.

Why do you want to do such a strange thing?
posted by Steven C. Den Beste at 10:02 PM on February 11, 2007

These guys used to have a project dedicated to a Flash interface for MIDI over TCP but it doesn't look like it's there anymore. I know they've performed virtual "shows" with it before and they had a working concept. I wonder what they're up to now.
posted by afx114 at 10:15 PM on February 11, 2007

Lots of work on MIDI over IP for both Linux and Windows here. I've done it, but only for attribute change signals (ie. "moving sliders") not time-sensitive things like actually playing notes.

I did it a while ago, on a whim. Can't remember exactly how, I've got a Python script sitting around somewhere. I vaguely remember it involved basically sending the MIDI data though a TELNET session to the client, which then took the data it received and acted on it appropriately. MIDI is, after all, just bits and bytes. You can send it through a TELNET stream, or put together your own bit of code. Like I said, though, this wasn't time sensitive, so it worked quite well.

That said, I don't think time would be that much of a problem. I might be barking up the wrong tree here, but MIDI sends, I think, 24 messages per quarter note. At 120bpm, that equals 2880 signals per minute, or 48 per second, or 2/100ths of a second per signal. With local network ping times on the order of <1 ms, i don't think lag will be a serious problem for most music. br>
I'd say make sure your MTU on your network is pretty low, so each byte gets there as quickly as possible. In terms of overhead from software load, I would hope it would be pretty low; after all, we're not processing audio data here, we are (in the case of the script I wrote, anyway), taking a byte from a MIDI interface as input, and sending it straight back out as a byte over the network. No serious processing involved until it gets to whatever function is turing that MIDI to sound.
posted by Jimbob at 10:30 PM on February 11, 2007

Why do you want to do such a strange thing?

Lots of reasons, not least that it is more ubiquitous to have a bunch of PCs connected by ethernet than by MIDI cables these days.
posted by Jimbob at 10:31 PM on February 11, 2007

Found some links:
eJamming
"Jamming Online"
Everything on Create Digital Music tagged with online.

You might also want to ask the forum at KVR Audio. The Europeans on there should be waking up in a little while.
posted by redteam at 10:36 PM on February 11, 2007

Mac OS X has MIDI over the network built in. Here's the underlying technology.

(SCDB's assertion that traditional MIDI's physical layer is RS-232 is just plain wrong, by the way. Completely irrelevant to the question being asked, too.)
posted by xil at 10:44 PM on February 11, 2007 [1 favorite]

Oh I should add, also, that dealing with a very simple system (master and slave) should be simple with MIDI over IP. Dealing with master to multiple slaves, or a MIDI "network" is more complex, because of the sync issues.

MIDI in it's native form, as I suggested above, sends a constant sync signal that makes sure all the instruments are in time. It's a bit like the old coax-cable Ethernet network - the same data gets sent along the wire, each machine listens to the part of the signal it needs.

The setup I described did not transmit that sync signal (tick tick tick); just the MIDI signals (Set Controller 13 to 123). Working from one master to one slave, this shouldn't be a problem; working from one master to multiple instruments might be, because it will be sending data over the internet to slave 1, then slave 2, then slave 3...leading to sync issues, unless a more complex system is put in place where the MIDI-network listening program on each slave is set to sync and all start in time with one another.

For all I know, the MIDI-IP software listed above takes this into account. My simple "send the bytes over TELNET" didn't. Just sayin'.
posted by Jimbob at 11:01 PM on February 11, 2007

How do I optimize it for performance and reliability? Pitfalls? Limitations? ... Don't worry about it. xil and Jimbob have it right. MIDI over RS-232 is something like 33K bits/second and daisy-chained between equipment with whatever delays the equipment brings to the picture. Ethernet at even the lowly 10 M bits/second can handle MIDI while browsing porn... Timewise, people may be fooled by the Microsoft programs like 'ping' where they report the round-trip time in round millisecond intervals, the best that the normal Microsoft programs will give you for a round-trip time is 1 milli-second. This is just a limitation of the programs timing output, my Linux version of 'ping' gives me a round-trip time over my home network as 0.231 milliseconds.

As long as you're not trying to sync MIDI over kilometer distances while downloading porn and streaming video at the same time, you can forget about any penalty for using Ethernet instead of the RS-232 serial versions. If your software supports some sort of MIDI over IP (TCP or UDP) that will be much better.

I'm not a musician, but from what I remember of MIDI it should be trivial to send the 'MIDI bytes' in a UDP packet to another machine and there read the 'MIDI bytes' and send them upstream to the music program.

None of the steps to go from 'sending bytes over a serial link' to 'sending bytes over Ethernet/IP/UDP/TCP' are complex enough to worry about. If your hardware and software supports MIDI over Ethernet then I don't think you have any reason to be worried about performance or reliability. For pitfalls and limitations, maybe you'll need a machine to go from Ethernet to serial for the hardware that doesn't support Ethernet. Maybe you'll have to buy a cheap Ethernet switch for your machines to plug into.

(on preview)... sync shouldn't be a problem. The sync can be sent to a broadcast or multicast address and all other machines can receive the same sync packets. Even sending 5 or 10 or 15 sync packets in sequential order, the receiving machines will all receive the packets in less time than it takes RS-232 MIDI to finish sending a single packet. Ethernet is that much faster than 33K bit/second serial.
posted by zengargoyle at 11:30 PM on February 11, 2007

I don't know of any current implementations over TCP/IP, but I would suggest that, for a multiple-instrument setup, UDP is going to be a lot faster than straight TCP.
posted by Civil_Disobedient at 12:42 AM on February 12, 2007

Civil,

The problem with UDP is that dropping MIDI packets causes _really_ bad things to happen (for example, the loss of a "reduce reverb" command).

The problem with TCP is that it takes so long for the stream to realize there's been a drop, that everything goes to hell.

Really, what you want is a customized protocol; some sort of reliable variant of RTP in which you'd specifically synchronize to some reasonable period of lag (you've got about a 10-20ms budget for performance-quality latency, so maybe 5ms?), and nodes must acknowledge receipt within that period.

Dunno if anyone's built this, though. Nobody in tech ever pays enough attention to latency.
posted by effugas at 2:57 AM on February 12, 2007

Good point, effugas. Perhaps you could use UDP for the sync because of its low latency, but TCP for the actual data, in a similar fashion to how multicast voice/video-oIP is done. That way, dropped packets can be resent automatically, but the timing issues are handled better.
posted by Civil_Disobedient at 3:13 AM on February 12, 2007

I have used MIDIoverLAN to sync two machines running Ableton Live for a live performance. It worked well enough, and I chose to use it because USB MIDI interfaces make me nervous. It's very stable, works really well, but it is commercial. I was using the 14-day demo.

Also if you are doing anything MIDI you should have a copy of MIDI-OX.
posted by cmicali at 4:58 AM on February 12, 2007

Robert Henke of Monolake trusts MIDI over IP enough for a transatlantic performance.
posted by mkb at 7:02 AM on February 12, 2007

I used MIDIoverLAN to control Arkaos VJ on three slave systems simultaneously in an interactive art project. Master was a dual 1ghz G4, the slaves were 1.33ghz (I think?) Mac Minis. I realize that sync isn't nearly so important in video as audio, but I never had any problems making everything work.

The professor with whom I created the project has used MOL for music, and I didn't hear any complaints from him. I have no knowledge of the complexity of his system, however.
posted by Alterscape at 7:34 PM on February 12, 2007