Midi via ethernet UDP/IP

A working proposal for a protocol that can replace standard MIDI with possible extentions, a manifold speed benefit and wherefore the receivers can be implemented on small microcontrollers.

dr.Godfried-Willem Raes.

Introduction:

The many problems related to MIDI are a burden to many designers, composers and musicians. So we will not deeply enter into the vast area of justified complaints in this regard. Our personal prime reasons to look into alternatives for standard 5p-DIN-wired midi were:

These problems came out as very severe and really asked for an urgent fix in the context of our ever growing electro-mechanical robot orchestra housed at the Logos Foundation in Ghent, Belgium.

First experiments:

The very first suggestion coming up was going for DMX, a technology very similar to Midi but running at the double speed. The main property that makes DMX attractive seemed however, more so than the speed advantage, the allowable cable lengths of over 100m. At the other hand, the existing standards whereby channels are continuously scanned, seemed as such not very suitable for fast real time applications. The net gain of this technology was too marginal to make a practical implementation worth the effort.
Then, after checking possibilities via USB 2.0, we rejected this completely because of the shaky so called' intelligent' mode of the operating systems at the one hand (leading to having to reinstall drivers every time again the OS refused to 'recognize' the non-Microsoft approved device...) and the strong restrictions on cable length at the other. (USB is even far worse than Midi in this respect. Dont even dream of a USB cable 20meters in length...).

Then entered ethernet into scope. First we attempted to use TCP/IP but found the jitter musically completely unacceptable. Delivery of data packets was just not deterministic enough to be usefull in real time and interactive applications. For this experiment we set up two laptop PC's: one generating notes via its internal soundcard and outputting the same, shifted a fifth, via TCP/IP. The other receiving the data packets and outputting them in turn via its internal soundcard. We could simply never get them to play really together...

Next we checked out UDP/IP. Under specific conditions, this came out as a workable alternative. The conditions being that one should use a dedicated network without external connections eating network bandwidth. Based on mere bandwidth capacity one would assume ethernet at 10MB being a factor 300 faster than Midi, but this factor gets reduced by the fact that minimum data packet size in UDP seems to be 28 bytes, versus 2 or 3 bytes in midi. Thus the actual speed gain is rather in the order of 30 times. If we further take into account our wish to support at least 128 channels, than the net performance would only be 3.75 times faster than plain old midi... Of course we could go for 100MB or even 1GB ethernet, but the non availability of small microcontrollers to support these speeds made us (at least as far as technology stands now) stick to 10MB. This speed can be handled with the newest generation of Microchip PIC controllers, our favorites for building our musical robots and automatons.

The first experiments were carried out using a PC-type master laptop server with a 16 port hub. Each of our midi-controlled robots was given a workstation laptop running a UDP/IP data communication program written in our own GMT language (a superset of PowerBasic) translating the UDP packets back into midi. (On some of the older robots we could translate directly into the parallel bus they had, using the laptops printer port).

When we look into a standard midi command such as note on, this is coded as a data stream in following format:

 

velocity byte note status + channel
0xxx xxxx 0xxx xxxx 1010 xxxx

(This is the big endian byte order as used by the Windows midiOutShortMsg function.)

In our GMT language we already extended the number of possible channels, by using multiport devices. To implement this, we placed the status + channel byte into a word (16 bit) variable, wherein the high byte of that word contained the port number. So the structure of the channel-word became:

not used (always reset) port nibble status nibble channel nibble
0000 pppp ssss cccc

It shall be clear that this way it was easy to implement 256 midi channels using midi-multiport devices such as MidiMan 8x8. The reconstructed byte ppppcccc returns the channel.

The new wrapper for the note playing command in our software thus became:

FUNCTION Play (BYVAL channel as WORD, BYVAL note as byte, BYVAL velo as BYTE)

For the UDP experiments and evaluations, we used the high nibble of that word as a pointer into a list of IP adresses. Thus the meaning of the binary component of the status word became:

IP-adress pointer in list port nibble status nibble channel nibble
nnnn pppp ssss cccc

The nnnn nibble is a pointer into a list of binary encoded IP adresses, wherein the usual notation 255.xxx.xxx.xxx (or similar) becomes &Haabbccdd, packed into a single unsigned word variable.

The UDP send command, replacing former midi now becomes:

UDP SEND porthandle AS DWORD, AT segment_ip(nnnn), udp_port(nnnn), BYVAL msg AS STRING

The msg message string thus sent, is -apart from the string format in the declaration, identical to the normal midi bit sequence as sent out by the midi functions.

The wrapper for midi via UDP becomes simply:

FUNCTION g_net_send (BYVAL msg AS STRING, BYVAL nr AS DWORD) EXPORT AS LONG

Up to 2004 most of our musical robots used a dedicated laptop computer for communication and control So there was always a hassle in setting up the IP adresses en keeping the ini-files up to date. Now, in 2007 all robots have there own (ofter very many...) small microcontrollers translating the midi commands into whatever is required for the automates. To implement midi over UDP/IP we now are developing small boards with an ethernet connector and two midi DIN connectors, to allow bidirectional communication. The IP adresses for each board, and therewith for each robot, are hard encoded in the firmware and can be different for each robot. The advantage to use bidirectional data links is in the first place to overcome the intrinsic deficiency of UDP (as compared to TCP) in dealing with lost packets. Now each robot can (optionally) send its status back to the server, or -if usefull- to any other robot on the network segment. For musicians dealing mainly with pure electronic instruments or samplers this may sound a bit silly if not over the edge, but remind you these are electromechanical robots sounding purely acoustical. For instance, our bass accordion (<Bako>) has a motor to move the bellows up and down. De direction of the movement is under midi control but a sensefull musicians will let the requested direction of the movement depend on both the actual bellows position and the durational rerquirements for the note he wants to play. Hence this robot outputs the position of its bellows via midi, and soon, via UDP...

----------to be completed and followed up ------------.

On the receiver side, in our case mostly the dedicated microcontroller built into any particular robot, the UDP-receive function returns data with regard to the sender (the IP adress) as well as a data packet than can be directly relayed to the midi-out port, if the channel matches the channel for the robot and if the message is acceptable to the robot. This way the risk of overflowing the midioutput with more data than the midi serial format is capable of handling, is seriously reduced. However it remains possible. So, the microcontroller should provide as much as possible of its (very limited) memory as a buffer. On buffer overflow, the microcontroller can output a warning message via UDP send using its unique IP adres to the server.

Quartertone music

An increasing number of our automats is tuned in quartertones:<Qt>, a 6-octave quartertone organ, <Tubi> a tubular quartertone metallophone, <Puff> a quartertone percussive puff-organ, <Xy>, a quartertone 3.5 octave xylophone... To use these instruments using standard midi, we provided each of these with two subsequent midi-channels. The lowest channel for playing the 'normally' tuned pitches, the higher channel for playing the quartertone pitches. This seemed to be the most elegant solution within the limited musical world (12-tone, monometric - remind you the Midi File Format 2 was never properly implemented...) covered by the midi standard. This, of course at the cost of already way too scarce midi channels.

Non-real time midi transfers

Most of our robots have an implementation for system exclusives, allowing users to program lookup tables for velocity scaling, pitch remappings en such more. To implement this with ethernet, we would rather use TCP/IP, since sysex dumps should never be done in real time or during interactive composition performances.

2001/ 2007

Collaborators on this project:

  • Johannes Taelman (Microchip PIC programming)
  • Yvan Vander Sanden (Linux o.s. implementation)
  • Kristof Lauwers (Midi file player development under PowerBasic/GMT)
  • dr.Godfried-Willem Raes (hardware design, project management)

last updated:January 11, 2007

dr.Godfried-Willem Raes