I decided to open up my Alesis Vortex Wireless 2 - partly because it needed cleaning, but mostly because I've been curious about what kind of hardware is actually inside it and whether there's any possibility of writing my own firmware. I've got a few reasons for wanting to do this, most of them having to do with the pads.
Reasons
The Vortex has CC toggle pads, but their state isn't really part of the preset. If I switch from one preset to another, the pads retain whatever state they had in the previous preset. Worse, the LEDs don't reflect that state—they always come back showing their OFF color. It seems much more useful for each preset to have its own pad states, particularly if you're using the pads to trigger different loops, effects, or other functions. This doesn't seem like it would require much additional memory or complicated code, so I've always found the behavior a little frustrating.
I'd also like to be able to send MIDI messages to the Vortex to change the pad states. That would let the controller reflect what's happening in a DAW or external sound module—my SquishBox, for example. Whether that would be accomplished with CC messages, SysEx, or something else isn't clear.
Finally, there's the perennial MIDI-controller problem: the software used to program the Vortex doesn't have a Linux version. I could potentially reverse-engineer its SysEx protocol by watching the traffic while configuring the controller from Windows, but writing my own firmware would give me considerably more control over the whole thing.
What's Inside
The Vortex turns out to be built around a fairly ordinary ARM STM32F103R8 microcontroller. That's encouraging: it's a well-supported chip with inexpensive development boards and plenty of documentation and examples. Even more interestingly, there's an 8-pin header on the main PCB labeled PROGRAM, so there appears to be a fairly direct way of programming the MCU.
The rest of the hardware is considerably more interesting than the basic MCU would suggest. The keybed's aftertouch is implemented with a single long force-sensitive resistor, while the neck controls live on their own board. There's a separate I/O board, an accelerometer, and various connectors and test points on the main board, including a collection of labels that provide some clues about how the different pieces communicate.
Of course, finding the programming header doesn't mean I've suddenly got a replacement firmware ready to go. The MCU has to handle all of those peripherals, as well as the wireless USB functionality, so I'd need to figure out how the hardware is connected and how the existing firmware uses it. Reverse-engineering the original firmware might help, but that's a substantially larger project than I initially had in mind. Still, knowing what's actually in the thing makes the possibility seem a little less hypothetical.
MIDI Hardware Thoughts
The teardown also got me thinking about something broader. We have a huge selection of inexpensive USB MIDI controllers, but the software for configuring them is often the least open and least satisfying part of the experience. The hardware is capable of doing interesting things, but you're frequently expected to configure it through a proprietary application that communicates with the controller using an undocumented stream of SysEx messages.
I'd love to see manufacturers take a more open approach. A MIDI controller could present itself as both a MIDI device and a USB mass-storage device, with a small partition containing a simple, documented configuration file. The manufacturer could still provide a polished graphical editor for people who want one, but power users could write their own tools or edit the configuration directly. It would also make supporting Linux much less of a special case.
There's nothing particularly exotic about the idea. I could build a MIDI controller around a Raspberry Pi Pico that worked this way myself. But it would be nice if the commercial hardware we already have took this approach. Even just publishing the SysEx protocol would go a long way toward making these devices more useful to people who want to understand and modify how they work.
That's really what I find interesting about tearing things like this apart. The manufacturer doesn't have to make every aspect of the device easy to modify, but once there's a capable microcontroller, a handful of interesting peripherals, and a programming header sitting on the board, it seems a shame for the software side of the device to remain completely opaque.