Introduction

A Monome is an undedicated controller consisting of an Cartesian array of illuminated switches. As it is undedicated, its function is wholly defined by the program driving it. Normally a Monome is configured as an 8 by 8, 16 by 8 or 16 by 16 array. Using standard software it presents a uniform program interface that has allowed many people to write programs that use it. Its main use is in music applications and has been programmed in a wide range of languages including Max, Chuck, PD and Ableton Live.

It is well known that a tool, especially a music tool, often dictates what you can do with it, some things are easy yet others remain virtually impossible. By changing that tool you often open up new and interesting possibilities, it is with this in mind that I developed the Hexome.

Hexome switches and LEDs

Internal Wiring

Finished unit

As the order increases the number of hexagons in a concentric ring increases by six.

You will see that a fourth order Hexome corresponds quite closely to an 8 by 8 Monome and a sixth order to a 16 by 8 instrument. While a sixth order Hexome might be nice I thought I would start with the smaller fourth order one, it proved to be quite a challenge in itself.

A Hexagonal based Monome

By Mike Cook

Design

The basic idea is simple enough, a hexagonal key top has a tube attached to its base, this tube is inserted though a plate to align it and rests on two tack switches. An RGB LED sits between the two switches and shines light up the tube. One problem with this arrangement is that there is nothing to hold the key and tube in place when it is turned upside down. To get round this a second plate is placed over the first with oval holes and tabs. These tabs slot into a notch cut in the tube and hold the key in place.

I spent a lot of time seeing if I could construct the circuit on perforated board with a 0.1" pitch, there was a bit of play as to the switch position and I tried various arrangements of scale and positioning before I reluctantly gave up. The main problem is that the spacing for hexagons involves the non rational number root three. I would get the X spacing right only for the Y spacing to be not quite right, and vice versa. In order to do these investigations I wrote a program in Processing that drew the layout with various different size parameters. It is this program that I used to produce the final set of drawings. This program can be downloaded with the main CAD Files CAD Files.zip. It starts with a number of different size parameters and flags that define exactly what will be drawn. The program can output its results to the screen or a PDF file. It turned out that a PDF file is exactly what I needed to drive the laser cutter.

The processing program also generates the component drilling data and track isolation drawing.

Construction

The technique I used here was to print the hole (and tracks) onto paper. With the size of Hexome I was making this required an A4 printer. Then this sheet was glued onto a piece of single sided printed circuit material and the holes drilled, most at 0.8mm diameter. I used SRBP in place of fibre glass board so it was gentle on the drills. The drawing also indicated the mounting holes used to join the PCB and the tube guide plate together.

I soon abandoned any hope of a complete PCB layout in favour of just isolating the components for the switches and LEDs. I could make the parts in a switch position join up but not the switch positions themselves. Therefore the PCB was a sort of customised prototype board, each switch / LED cell would be milled out but connecting them together would have to be done by soldering wires between the cells. Now one snag was that my miller did not have a very big milling area and also had a limited size to the work piece it could accommodate. It turns out that I calculated that if I split the PCB in half I could mill the isolation tracks by moving the work piece along. However, some of the switch positions would have to be tackled upside down if I were to achieve this. Therefore I wrote two Gcode files, one for the normal position and the other for the inverted position for when I tackled the milling from the other side.

So after I drilled the holes, I cut the PCB in half and align up the miller's zero position on the red cathode’s hole and then I milled round the holes to isolate a switch position. I repeated this for all the switch positions, moving the PCB every couple of switch positions and slight misalignments in the isolation tracks did not matter. I made some wooden clamps to hold the PCB as I moved it so that it was always firmly held down. As the holes were produced by the same program that defined the tube positioning plate, alignment was assured. After the milling was completed, the two halves the PCB were attached to the tube alignment plate and were joined together again, using epoxy and some small pieces of PCB material, this restored the alignment.

The key tops were laser cut from 3mm acrylic after they were laser engraved with a concentric hexagon pattern. This ensured not only a good light diffusing surface but also gave them a good textured feel. The PDF document I produced also included a few spare keys to experiment with and also in case things went wrong with the finishing of them. On the back of each key top I put in a circular grove so that the tube would be a good push fit in. I did this with a parting tool on the lathe. I clamped a block of wood to the lathe bed to ensure that the lathe cut the same depth on each key top. Each hexagonal key top was placed flush with the lathe chuck by holding s small flat sheet of wood over the end of the chuck and ensuring the key top was flush with this before tightening the chuck. It is vital that this is done to ensure the same depth grove is cut on each key top. Also the same overall length of tube must be used on each key top, in order for all the keys to be level. Before gluing the tubes in place I glued aluminium foil to the back of the key tops to act as an internal reflector to try and ensure even illumination. I applied glue to the area of the key top outside the grove and removed the foil on the inner part of the key top with a scalpel before pushing on the tube and gluing it in place.

Here is a quick rundown of what I have written so far:-

Seq - This is a sequencer, the steps move in concentric circles round the centre cell shown as a moving green light. When a key is pressed it will light up blue. When a green step light hits a blue cell it turns orange and a sound is triggered. It is a different sound for each concentric circle. Pressing the centre key wipes out all the blue lights. As each circle is a different length around its perimeter the whole sequence only repeats after the lowest common multiple of all the ring lengths. In the case of a fourth order Hexome this is 72 steps, not bad from an instrument with only 61 keys.

Orbit - When a key is pressed it turns blue and a green radius line rotates around it. The length of this radius line depend on the version of the program, there are 2, 3 and 4, key radius variants. Multiple key presses produce multiple orbit objects. When a green radius line crosses a blue centre source key (lit blue) it turns orange and generates a sound. As an alternative game, take it in turns with two players pressing keys and the first one to produce a sound looses.

Harmonic mapping - This maps the hexagonal keypad to a natural pattern such that chords of any key are produced from the same pattern of keys held down no matter where they are held down on the board.

Light Show - Running through some patterns of changing coloured lights. This will automatically change the pattern mode after a minute or when ever you press the P key.

Dice - This shows the perspective view of a dice with the spots of the top number in red. Pressing the centre key rolls the dice and you get a different number.

If you want to use OSC messages from your host software to control the Hexome then first you have to set up the USB bridge name to match the format that ArduinomeSerial requires, this was covered in the Mini Monome project. Then you can send and receive OSC commands just like a regular Monome.

While you can write host software in any language that handles serial data or OSC commands. I wrote some test applications for the Hexome in Processing. Some of them were written during development and have large look up tables in them for co-ordinate conversion, it fact that is where I discovered the usefulness of some addressing modes. They cover a number of different applications. They were developed out of each other so I can't always guarantee that there is not redundant code or look up tables in them, however, they will give an insight into how to talk to the Hexome. They all work on a step time which in processing is tied to the video frame rate. This can be speeded up or slowed down by pressing the + or - keys while the sketch is running and the processing run time window has the cursor focus. Other keys can also be used to change things and there is a small message output at the start of each program outlining what keys work.  Examples.zip

Firmware

Now I needed to turn my attention to the firmware. I had already tested most of the software I would need in the Mini Monome project so it was a matter of building on that. The multiplex library was extended to accommodate three TLC5940 chips and the switch matrix input changed to use the port expender chip. As this chip uses SPI and the TLC5940 needs some of the SPI lines in order for it to work, I had to write a routine to bit bang the port expander in an SPI manner rather than use the processor's internal hardware resource. Firmware.zip

The most important thing was the commands sent to the Hexome. I wanted these to be as like the Monome as possible so I kept the same basic structure, that is a one or two byte command for turning the LEDs on and a two byte message for when a key is pressed or released. However, this differs from a Monome in two important ways. First of all the LEDs are not just a single colour on or off but are defined by three 12 bit values for red, green and blue. And next the positions of the keys can't be reported as a simple X Y co-ordinate value because of the shape.

To get round the colour problem I adopted the model of reserving three commands that set the R, G and B values to use when ever an LED was commanded to be on. So you need to set the colour first and then send the command to turn on a specific LED. Of course if the colour doesn't need to change you can carry on setting LEDs without resending the set colour commands.

The problem of co-ordinates is a bit more problematical. At the basic level each LED has it's own unique number and that is what is reported by the key press / release messages and is also used for the basic set / clear LED command. That was all I had to begin with, and I had look up tables in the controlling software to convert these numbers into something more useful, like the LED numbers in concentric rings around the centre. This is a bit burdensome for the host software to have to do this conversion so I added some extra modes which allowed addressing of the LEDs / switches in a number of different ways. It is best to leave a discussion of these ways to a separate document which details all the messages and commands in the firmware download. There are however two new concepts to those familiar with a Monome and the way it communicates. First off when a key up / down message is sent from the hexome the state of up or down is given in the least significant bit of the first byte of the message just like a Monome. However, the next three significant bits act as an indication as to if that key's LED was lit. If all three bits are zero then the LED was not lit, however if there were some element of the LED colour lit when the button was pressed / released then that would show up in one or more of the three flag bits. So for example if you pressed a key that had the blue LED lit to any extent, bit 3 in the message would be set as that is the blue flag. As the host software doesn't have to keep track of what LEDs are lit, this greatly simplifies the host software's task, if you design your colour scheme to suite this feature.

The other new message mode is the collision detection feature. This, when enabled, sends a message back to the host software as if a key had been pressed, when ever an LED is commanded to change that has been already lit. So for example the software could just be setting the LED to say green and if that LED was already lit in the blue channel a message would be sent back to the host software indicating a collision of a lit LEDs. These collisions can be masked with the three colour component bits so that, for example, you only get a collision reported when trying to change the colour of an LED who's blue component was lit. There are commands that enable or disable this function, as well as defining the masking bits to use on the original colour. This greatly simplifies the host software when writing things like sequencers. I have found it best to enable the collision mode just before you write to an LED setting it to be lit and disable it before turning it off. It sounds complex at first but if you look at the examples you should soon get the hang of it.

When I assembled the unit I found that I had to use an adjustable reamer to make the laser cut holes completely round, also the tubes were not quite as dimensionally stable as I would have hoped, being not always round in cross section. This meant that you had to rotate some to get a smooth non binding fit in the holes. A little silicon lubricant was also applied to the tubes. The final process was to cut the retaining notches out of the tubes. This was done with a small reamer bit in a bench press mounted drill, with the tubes being offered up by hand. This notch had to at least match the tab in the top retaining plate and be sufficiently deep that it did not prevent the full travel of the switch when depressed.

Construction of the box proved a bit more problematic. At first I was going to surround it with aluminium U channel extrusion to form the box, the snag with this, as I discovered, was that while it did fit, there was no way to get the board into the U channel in the first place. I settled for just having a few of the U channel sections and slotting the board in from the side. These were first mounted on the hexagonal base plate and surrounded with six sides that were glued together and onto the lid. One of the sides had a small hole cut out for the USB connector. The black edges from the laser cutter and the plane wood sides and top were finished off with a light oak staining varnish, two coats with a light sanding between each coat. This allowed the lid to side carefully over electronics.

I tested out the electronics just on the PCB without mounting any of the switches and went over the signals with an oscilloscope. I found that a few of the LED driving lines showed some unstable oscillation and this lead to intermittent malfunctions akin to insufficient supply decoupling. I cured this by putting a very small capacitor, around 100pF at the far end of the run of wiring for the LED cathodes. This before and after situation is shown on the photo of the scope traces.

Electronics

The next job was to build the electronics on the milled PCB. I milled out several prototype strip areas on the side of the PCB to accommodate the chips. In the end I had some over and I could have cut down on them. There are five main DIL chips, the ATmega (arduino) processor, a 16 bit port expander and three TLC5940 LED control chips. I had already built a mini Monome 4 by 4 to test out some of the ideas I used here including the multiplexing of the LED control chips. I have found that a 4:1 (four to one) multiplex scheme offered an acceptable compromise between reduction of the hardware and LED brightness reduction. The idea was to have a separate TLC5940 for each LED colour, in that way I could use the current set resistor on each chip to roughly balance the brightness of each colour component to achieve an acceptable white when they were all on full brightness.

So each colour is split into four rows of 16 LEDs per row and the rows were driven by P-channel FET current sources. The current sources were used to power all three colours in one multiplex bank, so that at any one time 16 X 3 = 48 LEDs could be on at the same time. Of course multiplexing meant that they looked like they were all on but for the purposes of current calculations only 16 of each colour need to be considered. I wanted to be able to run the whole thing from just USB power and so the maximum current has to be limited to 500mA at any instant. At the same time as a group of 48 LEDs were on, the state of the push switches were monitored by the 16 bit port expander, with the current sources providing input power to the diode switch matrix. This allowed any combination of keys to be depressed at the same time and read out correctly. As there are only 61 LEDs in a fourth order hexome then the last three LEDs / switches are omitted from bank 3.

The Schematics.zip are drawn in the hierarchical form, that is with blocks at the top level and further diagrams detailing the blocks. In this case each bank of LEDs is an identical circuit and so is shown in detail only once. The wiring up of this I have to admit is a bit on the advanced level side. When you see a picture of the final circuit the wiring just looks like a tangled mess but from the point of view of doing it it is quite systematic. I used three different colours of wire for the runs of different colour LEDs, red, blue and yellow. I used yellow because I didn't have any green wire but it keeps a handle on the wiring and stops it getting totally out of hand. Before I put the LEDs in I tested them with an external supply and resistor. It is a good job I did this, I had three of the red LED that did not work or crackled and blew when power was applied, and on another one the red LED was much brighter than the others. This is what comes from getting a cheap batch from Hong Kong via Ebay, in general the red was very much less bright than the green and blue, I suspect someone is selling off reject LEDs. The most important thing however is that they match. Before mounting them on the PCB I gave then a light rub down with some very fine sandpaper to improve the light diffusion characteristics.

Theory

The Hexome is an array of illuminated switches, just like a Monome. However, unlike a Monome the Cartesian layout has been swapped for a hexagonal layout and the switch illumination is from RGB LEDs. This brings a whole new set of possibilities and also problems to the Monome concept. This has been a project that has taken three years in the making, with about two and a half years taken up by deciding exactly how I should make it. It turned into a bit of a marathon, for example I knew I needed a CNC miller for this project, so I had to make one. In order to make the CNC I had to purchase a lathe, the lathe also came in handy for this project as well but the big breakthrough was getting the use of a Laser cutter thanks to the Manchester fab lab.

While you can easily see how big an 8 by 8 matrix might be it is more difficult with hexagons. I decided to classify the Hexome size by the number of concentric circles it has. Starting counting the centre hexagon at zero, this design is a fourth order Hexome. The following table shows how the total number of hexagons increases with the order.

Order

0

1

2

3

4

5

6

Number in ring

1

6

12

18

24

30

36

Total number

1

7

19

37

61

91

127