HXCSTR

2019-12-01  (Updated 2024-07-10)    12 minute read

The problem

This project came out of an interest in learning how to play isomorphic keyboard layouts and a personal wish to perform live electronic music. The primary product this is based on, the Novation Launchpad Mk II, is a square grid of 64 red/green LED backlit silicone dome keys. While this was a suitable setup for some cases, I often found myself needing more buttons, and didn't like using it as a pitched instrument. In addition, this time in my life was a pivotal point in my love for hexagons. In my research, I had discovered the sonome, a large (and expensive) isomorphic keyboard, and the C-thru Axis 49, a smaller (but still pretty expensive) isomorphic keyboard. I liked both of these, but my favorite thing about the Launchpad was the colored lights, as they not only provided visual feedback to the player, but also easily turned an audio-based performance into an audiovisual experience. Also, there's an entire industry built around putting lights with music, and I feel like that has to exist for some reason.

The solution

After seeing the viability of a hexagonally arranged set of keys, I sought to make a keyboard that was minimally expensive (below $500 per unit, optimally below $150 at large scales), RBG LED backlit, and user-reprogrammable. Other than these necessary elements, other design priorities included satisfying physical and visual response, ergonomics, and ease of manufacturing.

picture of 5 black HXCSTRs and one white one, tesselated together, with a single potato placed on the white one
Potato for scale

Teensy

PJRC's Teensy seems ubiquitous in the hobbyist music technology scene nowadays, and I would attribute that to 2 factors. The first is that it's a very wholesome company that seems to only be able to do good things. The second is that the Teensy has supported MIDI over USB since the Teensy 2.0. My original prototype of the HXCSTR used the Arduino, which is a great teaching tool, but a pretty lackluster microcontroller. I think Arduino boards nowadays support MIDI, but it took them a loooong time to do it.

Keys

an extremely blurry and glare-ridden image of a PCB with
	hexagonally arranged Cherry MX Black keyswitches.
	There is a Teensy, a barrel jack, and a USB Type-B connector at the
	edge
Inside the HXCSTR

Switches

I don't remember how exactly I came across the Cherry MX line of switches, but I had a friend around that time of my life who was really into mechanical keyboards, and I think I learned about them from him. I liked the keys because they had a pretty long travel distance, which most MIDI controllers didn't (other than piano-style keyboards). I also felt like building the HXCSTR using them made them feel more premium, though I'm not sure how accurate that is. For anyone who knows about mechanical keyboard switches, my choice of the black variety of Cherry MXs may seem like a terrible idea, but there was a very very good reason for it: they're much cheaper than other Cherry switches. For anyone not familiar, the Cherry MX line of keyswitches come in many colors, and each color indicates a different style of switch. Some have a tactile bump, others have an audible click, and there are many different actuation forces for each. Black Cherry MX switches have the highest actuation force and no tactile or audible enhancements. While a loud MIDI keyboard would probably be distracting, I think the tactile bump would have been helpful. It didn't really matter which style I chose anyway, since they all have the same PCB footprint and I could replace them if I ever felt the need to.

Shift registers

Most mechanical keyboards and MIDI controllers read their switches by using a diode matrix. The basic idea behind this is that you can index by rows and columns rather than attach a pin to each individual switch. This means for a 12x12 grid of switches, you only need 24 pins from a microcontroller to read all the switches rather than 144. A better solution (as far as I know), however, is to use shift registers. Though the way it works is very very different, a shift register is practically a digital multiplexer. You can send a signal to it to tell it to read all of its inputs (8 inputs per shift register in my case), then use a simplified verison of SPI to send that data to the microcontroller.

Velocity?

Unfortunately not. I saw a similar project at one point that also used Cherry MX switches, but they cut off the bottom of each switch to allow the stem to hit a second switch. I (foolishly) thought that velocity sensitivity wasn't worth cutting up 91 Cherry MX switches, designing and populating a whole extra PCB, and doubling the read time of each switch, so I went without velocity sensitivity. This project was less about being able to play expressively and more about learning the layout (and, to be honest, showing off).

Keycaps

The keycaps in my first prototype were laser cut, and I also experimented with resin casting a 3D printed part (a very smelly and sticky mistake), but once I got to the point where I could make these at larger volumes, I switched to injection molding. It was a huge hassle, but in the end, I think it was the right decision. The keycaps are made from polypropylene, and the diffusion is achieved by introducing a little bit of white pigment. I'm very satisfied with the appearance of the keycaps, but they add a lot of unnecessary weight, and the stems should have been round instead of rectangular.

Spacing

The key offset spacing was selected to be similar to that of a piano key. Additional spacing between keys is not something that existed in the Sonome or Axis-49, but I thought that it would be necessary in order to reduce friction between keys. It was not, and I definitely should not have included spacing between the keys. Hindsight is 20/20.

LEDs

In the first prototype, I hot-glued the LEDs to the keys. While that was all fine and dandy, it was definitely not the optimal way to add lights. In the final version, I ended up with two PCBs-- one for the keys and one for the lights. The lights PCB was essentially a glorified LED strip that snaked through the board. I ended up giving myself a few headaches by not indexing the lights in the same direction in every row (instead, the rows snaked back and forth, alternating direction), but nothing too terrible. I actually had to reorder the LED boards because I didn't leave enough clearance for the stems to pass through the holes in the board.

WS2812B

If you've ever worked with large sets of RGB LEDs, you've probably heard the part number 'WS2812B' before. This LED is individually addressable, meaning each LED can be a different color, and it only requires one data pin, as opposed to the usual 2. The way it achieves this is by using a synchronous communication protocol. This protocol uses a varying pulse-width signal to send digital data serially through the chain of LEDs. What this essentially amounts to is an LED strip that's super cheap and very easy to send data to, but also limited in its data transmission rate. A synchronous protocol is (almost?) always limited to a single clock rate, and to ensure compatibility with a wide range of microcontrollers, that clock rate is generally not the highest it can be. As a comparison, the WS2812B's data rate is one LED per 30 microseconds, while the APA102, which has a clock signal, only takes a little over 2 microseconds per LED at its fastest. While a 28 microsecond difference is small by itself, these LEDs are generally used in large numbers, usually hundreds in a chain (in this project, there were 91 in a single serial chain). The more important difference in timing, however, is the internal PWM oscillator rate. To allow a range of colors, each component color of the LED is controlled by a PWM signal, which can be modified to make the color seem brighter or dimmer. This brightness is more or less controlled by turning the LED on and off very very quickly, and if the speed that it's turning on and off is too slow, it can lead to weird artifacts in videos and pictures, or worse, eye strain (not a confirmed medical effect, just me guessing). According to Tim, the WS2812B is about 430 Hz while the APA102 runs at 19200 Hz. I've never had any issue with image artefacts with APA102s. If you leave this blog post with one takeway, it should be that APA102s are much better than WS2812Bs.

Power

One of the most annoying hardware problems with the initial prototype was dealing with the 3.3v and 5v conversion. I also ended up switching my power jack component when I didn't need to, which was a bummer. The fact that it was a different height than the USB jack was a little annoying. Plus, for the most part, the current is low enough that it can be powered by just USB, so if I designed it better, I could've avoided the barrel jack altogether, or at least made it optional.

Layouts

TODO

  • Tonnetz/Harmonic Table
  • Wicki-Hayden
  • Janko
  • Drum Flowers

Other hexagonal isomorphic keyboards

Roughly in chronological order

Starr Labs MicroZone U648

I know next to nothing abouth this one, and only came across it as I was writing this article. Seems fine.

C-Thru Axis-49

Mentioned earlier in the article, and probably the first commercial electronic isomorphic keyboard. They are now out of business, but their controllers are still floating around on resellers these days. In my opinion, the keys were way too close together, and felt terrible. At least they were velocity sensitive though. These were the primary inspiration for the HXCSTR, in the sense that I thought I could do a lot better.

Rainboard

https://youtu.be/blNM4tX_0gE

Very pretty, and I appreciate the transparent enclosure. It seems like the velocity is global though, and at that point, I would've opted to omit velocity sensitivity altogether. I also personally don't like how arcade buttons feel, but there are definitely people out there who really like them. The accompanying app also seems like a pretty convenient way to mess with the configuration. The pitchbend is also a nice feature that I wish I had on the HXCSTR.

I think shiverware fizzled out a long time ago, but someone else made their own rainboard in 2020, and they do not seem to be affiliated.

Unnamed keyboard

Another one with mechanical switches. Reminds me of this rat maze: https://youtu.be/skcJc2KV4_Q?t=1722

BeeBoard

Also don't know much about this one.

Lumatone

One of the more recent iterations, and probably the biggest so far. And most expensive. They seem to be aiming pretty firmly at the microtonal crowd, which I think is clever because I think they tend to be more open to buying more esoteric and gimmicky gear than most other types of musicians.

dualo/equis

The polyphonic expression is nice.

s-ol 0x pads

Designed to work as both a computer keyboard as well as a musical keyboard. Also the only one on this list that is OSHW certified. I'm personally really interested in this one because I saw a picture of an alternate case that lets 4 of them fit together to make a mega keyboard, and I think that's fun.

There's also a guide written by someone who works at Adafruit on making your own board with the same keycaps (which are available seperately).

Hexboard

3D-printed keys. Not sure how I feel about them. The firmware seems to have a lot of features though, and they are fellow sr.ht enjoyers.