Optimus Mini Three Fun

I can't explain the thrill of writing software to drive hardware- there's just some strange sense of power that comes from making things happen in meatspace by manipulating software. With that in mind, I've been following Scott Hanselman's trials trying to get .NET plugins working on the Optimus Mini Three keyboard with great interest. Back in February, he posted a request for someone to bridge the Optimus' C++ configurator plugin interface to a more friendly managed version. I'm not much of a dancer, but I whipped off a quick COM interop hack and sent it into the ether.

Fast-forward a few weeks- it's turned into a bit of an obsession. Scott liked my hack, kindly wrote it up, and asked for some enhancements. It got my mind spinning on how one could build a really nice managed bridge API (which it looks like others have also started). One three-hour-of-sleep night later, requested enhancements are working and out the door.

A quick aside- jeers to the dev at Art Lebedev Studios that thought changing a bunch of the plugin API constants and calls between release 1.29 and 1.30 of the configurator was a good idea. It's already hard for average folks to write plugins for your cool toy, but even worse that they break hard between minor releases of the product... I understand why they made the changes they did (clears up some muddiness in the model- one "plugin" per key, period), but it still caused me an extra chunk of work I hadn't planned on when I upgraded at 3am.

I'd originally been told that this hardware was capable of 30fps on each key. Maybe the hardware INSIDE the box, but the USB interface on this thing is actually a Prolific USB->Serial bridge (eg, the device inside the box speaks RS232, not native USB). Thus, the "keyboard" is not a standard HID device (it shows up as a virtual COM port), and has slow-as-molasses communication (relative to USB's capabilities). You're lucky to get 3fps, and that's on one key. If you're trying to animate all three keys, well, let's just say that "animated" is probably a strong word for what you'll end up with. Some back-of-the-napkin math shows that we're not coming close to maxing out the Prolific device's throughput, either, so it looks like the device itself is the bottleneck.

Anyway, griping aside, this thing is still a blast to play with, more so since Scott loaned me his hardware for a few days... We're currently exploring the possibilities of a Vista SideShow driver for this beast. My old college roommate was involved in a lot of the initial design for UMDF (the basis for SideShow drivers), and I've been looking for an excuse to write a driver for awhile now. This won't be the hardcore experience of writing a kernel-mode driver, but it's a fun and easy start, comparatively (and much less likely to BSOD my box).

More to come...