Lets Get Loaded! A midi-sysex ecosystem for loading and debugging code.

Of all the protocols used in the realm of physical computing only MIDI is designed to read gestures, take notes, play sequences, identify what equipment is available, set parameters, load code and make things happen in real time. MIDI was designed from the beginning for performance. In usb-midi no drivers are required across the 3 major operating systems. Through sysex, the 20 year old MIDI standard allows for arbitrary data to be sent between devices allowing for seamless debugging and out of band communication between (arbitrary) devices. As a framework for physical computing MIDI Rocks!

But tell me, just what is that you want to do?

“We want to be free.
We want to be free to do what we want to do.
We want to be free to ride.
We want to be free to ride our machines without being hassled by The Man…
And we want to get loaded!
And we want to have a good time.
That’s what we’re gonna do: we’re going to have a good time.
We’re gonna have a party.” — Heavenly Blues (from the Wild Angels)

We want to get loaded, and we want to have a good time!

So why are we not looking at devices that connect to the midi bus and can then be identified, programmed, and debugged by novices?

I have a theory…

I believe it is because no one has thought “inside the box” long enough to theorize about how it could be, and then to specify how it should be. (#1)

That’s hip! Lets check it out!

The midi protocol provides for System Exclusive (sysex) messages to be sent between devices which can be either educational/non commercial or members who have paid for commercial identifiers through the MMA. Once the end to end identification (think of it as a route) of the message is established, the content of the message is entirely arbitrary. Because of this devices must have some agreement as to how they want to handle this data.

But tell me, just what is that you want to do?
  • We want to be free. We want to be free to do what we want to do
    We want to be able to take what is called “exclusive” and use it to identify devices who are like us so we can do what we want. And we want what we do to be unrestricted by platform or architecture and shared.
  • We want to be free to ride our machines without being hassled by the man.
    We want our projects and products to work within the midi specifications and compatible with both open source communities and commercial associations.
  • We want to get loaded.
    We want to load and verify code and configurations to our devices over midi/usb-midi
  • We want to have a good time.
    We want to be able to figure out what is going on and debug our code so we can have a good time.

And that’s what we are going to do.

 

Initial target hardware.

For the purpose of testing and developing this ecosystem I intend to use the following hardware in order of priority. For the avr I will be working with Dean Camera’s lufa library for the usb-midi implimentation.

4360721704_36037fb9df_z
  • MidiMonster a community (dorkbotPDX) designed midi device without fully functional firmware.
  • The Leonardo/esplora/micro series chips.
  • Wiring For Midi replace the ftdi chip with a usb-midi gateway and use it to communicate/program the xx4 family of chips (midi gateway will be based on the pic18f14k50).
  • Leaflabs Maple (Arm Cortex-M3).
  • a nuc120 based design (Arm Cortex M0)

Software Requirements.

  • Devices that wanna get loaded should tell us that using an extension of midi Universal System Exclusive Messages.
  • Programs that want to load code should be able to identify the target and build code specifically for it without being told what it is, its underlying architecture, and where to look for it.
  • Only in the case where multiple devices are avaliable should the user have to identify which device to work with.
  • It should be possible to identify, update and reboot the target device through an easy to use, cross platform, generalized interface.
  • This interface should be embeddable into multiple contexts.
  • The device once running the new code should be able to send debugging information to a generic debugging interface available to numerous contexts.

But tell me (again), just what is that you want to do?

The “Lets Get Loaded!” ecosystem is broken into 4 major components.

  1. Establishing the identity of devices that are compatible.
  2. Loading and verifying new code to the device.
  3. Providing an API which can be wrapped and used into environments like the arduino, eclipse, or xcode or embedded into standalone code updaters.
  4. Providing a console for sending debugging information from compatible devices.

Establishing identity.

One of the simplest examples of sysex use is the Universal System Exclusive Message for “Identity Request”. The instigator (better word) simply asks the individuals or everyone accessible for their identity. Each device that understands the request returns a “Identity Reply” which identifies who the manufacturer. is where it is listening, what it is and a 4 (7 bit) digit software version number. Devices that were open source would use the educational/non commercial device id along with 2 digits to uniquely identify the device. Commercial devices would use the 1 or 3 digit id provided by the MMA. The 4 digit version number would be used to identify the device as LGL! compatible. The reply could be extended by 4 characters (following a 4 digit software version) if it could be demonstrated that this would not break other software or systems processing the “Identity Request” either way the last 4 digits of the “Identity Reply” should be sufficient to determine which devices can party!

Once a device that is capable of getting loaded is found arbitrary sysex commands can be used to find out more about the device such as its architecture, device capabilities and other information needed to compile or load the appropriate code.

Loading Code.

LGL!’s primary purpose is to provide a generalize sysex method of (protocol for) loading and verifying code onto compatible devices. This protocol should work regardless if the device speaking midi is programming the target via ISP (midi monster), or using a native boot loader. Once the code is loaded the device should be able to provide verification that the code was loaded accurately and run it.

Wrapping it.

At its base LGL! is a set of system exclusive messages which will be implemented on the targets midi stack and also on the clients operating system in a way that provides an API or a set of script-able commands that can be embedded in IDEs such as the Arduino or standalone software updaters for your custom devices.

Debugging.

While not necessary for LGL! sysex provides an end to end transport for messages that can be used for debugging. To complete the loop and to make sure that the party roles smoothly along LGL! will include a standard way of handling sysex debugging in addition a console will be provided as a reference.

Freedom and Independence.

It is my goal in creating the “Lets Get Loaded!” protocol/standard/ecosystem to create something that is independent of the operating system it is running on (it should run on OSX, Linux and Window) . It should beindependent of the hardware configuration used (hw midi / usb midi / on board midi gw/ or programmer)  and the architecture of the target device (arm/avr/microchip). It should also be independent of commercial (proprietary) and anti-commercial (gpl3) interests.

To those ends I plan to use gcc for the micro controllers,  rtmidi and python for the clients,  and a modified bsd or MIT style licence all around.

References.

 

Grumblings.

 

#1 I have other theories but they are largely negative and not what I want to work on It could also be:

  1. Some implementations are incomplete (Arduino Midi / Mbed midi)
  2. Some implementations are tied to closed hardware (teensy midi)
  3. Some code is licensed in a way that prevents the adaption by people who want to pay their programmers by making products (Current Arduino midi /xnormidi)

Leave a Reply

  • (will not be published)