Where Everybody's Crazy

If Google took you to this page because you have one of these keyboards and a Mac, and you don't know what to do with it, skip to where it says "The short version." Meanwhile, here's the long version.

On Thursday I took delivery of a new (well, second hand) MIDI keyboard. It's a very nice piano, with a great weighted-key feel and a nice bank of sounds. I'd not normally trust Casio for this kind of thing, but my boss had a look around and said it was one of the best on the market.

It also has a couple of MIDI ports on the back, and a USB socket. Excited at the idea of being able to compose songs straight onto my computer again, I hooked it all up, and then read the instructions. (You know how it goes.) And I found those magic words: "Macintosh not supported." I tried it anyway, and really, it wasn't supported.

At this point, I had two options - buy another USB to MIDI convertor (I think I have one in the UK somewhere, but very few people sell them these days) or reverse-engineer the protocol and write my own driver. I should note at this point I have no idea whatsoever how to write device drivers, for any OS, least of all OS X, but I still fancy myself as a bit of a reverse engineer, so I set to work.

Imagine my disappointment when, after a few hours of fiddling, I found that the protocol was just plain old MIDI over USB. Absolutely nothing special about it at all. Apart from the fact that the keyboard's USB interface, for some inane reason, didn't announce itself as an ordinary MIDI-class device, and so the operating system had no idea what to do with it.

But after breaking the protocol (such as it was), I still had no device driver. Thankfully, the standard OS X Developer package includes an example of a USB MIDI device driver. All I needed to do was plug in the manufacturer and device ID, and recompile, and I had a working driver. Depressingly easy, really.

The short version

You can download the device driver here. Put it into the directory it specifies, which if my packaging skills don't work properly, should be /Library/Audio/MIDI Drivers.

There is one slight annoyance. OS X loads its MIDI drivers once it wants to use them. The Casio keyboard, on the other hand, wants to talk with the computer on the USB interface as soon as it's turned on, so that it can determine whether or not to use USB or the MIDI ports. To convince the keyboard to talk on the right interface, you need to (a) turn it off, (b) open a Terminal, (c) type /System/Library/Frameworks/CoreMIDIServer.framework/MIDIServer and hit return, (d) turn on the keyboard. It should now happily report that the active port is USB. Then you're good to go.

There's a concept in leadership theory called the Einstellung effect; it's sometimes also known as the mechanisation of thought. It's a very helpful explanation for a lot of (bad) programming practices.

A guy called Lurchins gave people three jugs of varying sizes, and asked them to draw a certain amount of water into a bucket. So if you have a 21cc jug, (A) a 127cc jug, (B) and a 3cc jug, (C) and you want 100cc, then you fill jug B and put that in the bucket; then you fill jug A from the bucket and take it away; then you fill jug C from the bucket and take it away, and repeat this final step. Essentially, you've just done the sum B-A-2C.

He gave them a few exercises like that: A=14, B=163, C=25, make 99; A=18, B=43, C=10, make 5. That sort of thing. All of them can be solved with B-A-2C. Then he gave them A=23, B=49, C=3, make 20. 83% of them went for B-A-2C, even though A-C is somewhat simpler. When it got to A=28, B=76, C=3, make 25, 64% of them gave up, as B-A-2C no longer worked.

From this Lurchins deduced that when we find a solution that works in a general class of problems, we form a mental mould that is incredibly difficult to break so long as we're just solving problems. This is the Einstellung effect, and from this follows cut-and-paste code, "but we've always done it this way", and any number of other programming disasters.

But here's the interesting bit. As soon as we stop solving problems, and pay attention to something else, the Einstellung effect can be shattered:

After problem 5, Lurchins told some subjects "Don't be blind", which caused more than 50% to find the simpler solution on the remaining problems.

Interruption - any kind of interruption - can cause us to re-evaluate the problem from scratch. From this follows the common sense advise that if you can't see how to code what you want, get up and take a break. Chances are you just need to shift your brain away from a pattern it used to solve a similar problem before.

And if you catch someone cutting-and-pasting an inappropriate solution, don't be too harsh on them; they probably honestly can't see the simpler way due to the Einstellung effect. Just tell them to get up and make a cup of coffee, and see what they come up with when they look at it again...