{"id":96,"date":"2011-07-18T22:36:50","date_gmt":"2011-07-18T22:36:50","guid":{"rendered":"http:\/\/timeline85.com\/?p=96"},"modified":"2011-07-18T22:42:50","modified_gmt":"2011-07-18T22:42:50","slug":"a-tale-of-two-midis","status":"publish","type":"post","link":"https:\/\/www.timeline85.com\/?p=96","title":{"rendered":"A Tale of Two MIDIs"},"content":{"rendered":"

One of the considerations for the class I’m teaching<\/a> at RobotSpeak<\/a> is that most people using an\u00a0Arduino<\/a> as an USB MIDI controller will want to communicate over USB without having to also connect the controller via MIDI ports. \u00a0However I’m a purist, and I want my students to be able to use their controllers for any application, including as a hardware controller in a non-computer based setup. \u00a0To do this our serial communication will have to be at 31250 baud. \u00a0For the hardware side, a single 220 ohm resistor and a 5-pin din MIDI port are all that is needed to connect the Arduino to a MIDI device. \u00a0However on the software side, we will need to run a utility that listens to the Arduino USB serial port, and then sends that data to a virtual MIDI port (OSX supports this natively with the IAC bus in Audio\/MIDI setup, PC users can use Maple<\/a> or MIDI\/OX<\/a>) which can then be read from our DAW software.<\/p>\n

This is easier said than done. \u00a0A quick check of the Arduino Playground<\/a> shows several different solutions, however many are either no longer available, or only support MIDI note on\/off and CC data. \u00a0This may work for my RobotSpeak class as it is just an introduction and basic controller class, but plans for my own controller will include emulation of commercially available controllers that use SysEx<\/a> for channel names and Pitchwheel<\/a> data\u00a0for high resolution 14-bit values\u00a0(like channel volume). \u00a0This is a problem that must be addressed in the future.<\/p>\n

For my class I have chosen the application made by Spikenzie Labs<\/a>. \u00a0For windows users, S2MIDI<\/a> is an option, but the Spikenzie app is written in Java (technically made in Processing<\/a> with the MIDIBus<\/a> library) and they do offer versions for both operating systems.<\/p>\n

With this choice I ran into two problems, the first being that the OSX version of the application would hang when selecting 31250 baud. \u00a0I can only assume this means that the Spikenzie hardware that this utility was written for runs at a faster baud rate, and that MIDI communication in the software world can actually go faster than what I thought was a hard limit in the spec. \u00a0(Otherwise they would have caught this, no?) \u00a0After some furious Google searching I found that someone had solved this<\/a>. \u00a0Apparently this is a limitation in the RXTX Java Serial library, and by adding the fix from the IRQ5 blog I was able to get the Spikenzie converter to work. \u00a0Sort of. \u00a0This brings me to my second problem, turning the knobs on my controller I was getting erratic results and useless data. \u00a0The MIDI equivalent of a garbled message.<\/span><\/span><\/p>\n

When I developed ColorSynths<\/a> and coded the entire MIDI spec in Assembly (something I try to mention casually in conversations as often as possible), one of my first oversights was the implementation of running status<\/a>. \u00a0Most MIDI data packets are three bytes: one status byte followed by two data bytes. \u00a0The MIDI specification<\/a> requires us to store the most recent status byte, and if a two byte data packet is received without a status byte, we re-use the last one. \u00a0This frees up data to allow us to transmit more information, and while it may seem like a more advanced function of the MIDI spec, it can trip up even the most basic of applications if you aren’t aware of it.<\/span><\/p>\n

As far as I can tell, the MIDIBUS library that Spikenzie’s application uses (and from the contact page I think it’s possible Spikenzie wrote the library) doesn’t support running status. \u00a0This of course wouldn’t be a problem if our Arduino code was directly addressing the serial port and only sending 3 byte data packets. \u00a0But I had originally written my code for the class using the Arduino MIDI library<\/a>, which of course uses running status. \u00a0The Spikenzie application had no way of recognizing these two byte data packets that lacked a status byte.<\/p>\n

I opened up the included source code to get a better understanding of what was going on. \u00a0I had assumed that an application like this would be a simple pass through of data from the serial port to the corresponding MIDI port, byte per byte. \u00a0Instead what I found was that the Spikenzie labs app is actually handling and interpereting the data, it’s analyzing each byte and waiting for a Note ON\/Off or CC status byte followed by two data bytes, and only transmitting when it receives them in that format. \u00a0This wasn’t too tough of a fix, I wrote a routine that recognized the entire MIDI spec, including running status and SysEx, in a few hours (nbd). \u00a0But because the MIDIbus library doesn’t support the transmission of MIDI using the runningstatus format, the incoming serial data would overflow the outgoing MIDI data (since it was 33% slower).<\/p>\n

My eventual solution was to remove the Arduino MIDI library from my source code and to instead manually create 3 byte only MIDI data packets by addressing the serial port directly in the Arduino code. \u00a0 This solved all problems (that and replacing the RXTX serial library with the one that supports 31250 baud) and gave us working code, but it’s not optimal and our controller could be 33% faster.<\/p>\n

Clearly two features need to be added to the MIDIBus library. \u00a0The first is support for transmission and reception of running status. \u00a0But the second is a way to handle raw data to and from the MIDI port. \u00a0I can see the benefits to having a library that creates the MIDI packets for you (that’s why I preferred the Arduino MIDI library to creating the bytes manually) but this application doesn’t need it. \u00a0A simple byte-to-byte pass through of the data would eliminate any errors in implementation of the MIDI standard, and avoid complications like Realtime System events (which are single byte and can occur in the midst of a 3 byte event) or SysEx timing. \u00a0SysEx is of particular concern to me, because some commercial controllers will send SysEx data and expect a timely response. \u00a0The last thing you’d want is to wait for your SysEx handler in the library to get back to you when your code is supposed to be responding.<\/p>\n

I’ve written to Spikenzie Labs and hope they’ll update their app, there are no suitable OSX alternatives listed on the Arduino Playground and eventually the correct solution might be to write my own utility that is a simple pass through. \u00a0It’s a shame to have to reinvent the wheel though.<\/p>\n","protected":false},"excerpt":{"rendered":"

One of the considerations for the class I’m teaching at RobotSpeak is that most people using an\u00a0Arduino as an USB MIDI controller will want to communicate over USB without having to also connect the controller via MIDI ports. \u00a0However I’m a purist, and I want my students to be able to use their controllers for […]<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[1],"tags":[],"class_list":["post-96","post","type-post","status-publish","format-standard","hentry","category-uncategorized"],"_links":{"self":[{"href":"https:\/\/www.timeline85.com\/index.php?rest_route=\/wp\/v2\/posts\/96","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.timeline85.com\/index.php?rest_route=\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.timeline85.com\/index.php?rest_route=\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.timeline85.com\/index.php?rest_route=\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/www.timeline85.com\/index.php?rest_route=%2Fwp%2Fv2%2Fcomments&post=96"}],"version-history":[{"count":4,"href":"https:\/\/www.timeline85.com\/index.php?rest_route=\/wp\/v2\/posts\/96\/revisions"}],"predecessor-version":[{"id":99,"href":"https:\/\/www.timeline85.com\/index.php?rest_route=\/wp\/v2\/posts\/96\/revisions\/99"}],"wp:attachment":[{"href":"https:\/\/www.timeline85.com\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=96"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.timeline85.com\/index.php?rest_route=%2Fwp%2Fv2%2Fcategories&post=96"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.timeline85.com\/index.php?rest_route=%2Fwp%2Fv2%2Ftags&post=96"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}