After more hours than I’d like to admit, even if I actually knew how many, I’m done. I started this, believe it or not, before the APC40 was even announced, and at the time there weren’t many products out there like it. Now, obviously it would make more sense to just buy one of those products, nevertheless, where are you gonna get an RGB monome with a nixie tube display that takes OSC commands? Exactly.
- RGB monome (64 buttons, 64 colors)
- 6 slide faders
- 1 infrared sensor
- 1 touch strip sensor
- 4 arcade buttons (internally lit)
- 1 toggle switch
- 4 digit nixie tube display
- 12 button keypad
- xlr microphone pass through
- 6 port usb hub (powered)
- 4 external power jacks
- 1 12VDC power output source
I’ll start with the functionality of the device first and get into the guts later, for anyone not interested in how it was made. For anyone not interested in what it does…I guess just jump down a bit.
Here’s a demo of what it looks like. The camera doesn’t really do the colors justice, but you get the idea. Also, I know I’m not very good at using the monome, be kind. This is really just to show how the controller works.
The monome section of the controller takes OSC commands the same way a typical monome works. I wrote my own version of monomeSerial which gives me access to the additional faders and sensors on the board, but the serial commands for interacting with the monome are actually the same. Ultimately, monomeSerial would also work with the controller, but there would be no access to the extra components. I realized early on that writing my own patches for the monome, that utilized the RGB capability of the monome would be tedious and likely pointless. And while the ability to change the color of the buttons to anything you like is cool, it’s not really adding anything new. On the other hand, after playing with a few monome patches, I found that it’s very common to find information organized into columns and rows on the monome. For example, in the critically acclaimed OBO patch, the top row shows the position of your sequencer, and the corresponding column shows which note to be triggered. By simply changing the underlying color of those rows, you can still use the patch the same way you always have, but now, each column is color coded. That may not seem like a big deal at first, but after using it a bit in mono-color mode compared to mult-color, allows your eye to not get lost as easy in a matrix of buttons that start to all look the same. The same technique can of course be applied to rows and columns, depending on the patch you are using. Similarly, the board could be divided into quadrants of different colors (this would be useful on a bigger board of course).
All the analog controllers (faders, ir sensor and touchstrip) are midi-mapped from within the computer router application. A “polynome5000″ device is created when the serial application is running, which sends midi data as controller commands to anything that’s listening. In my case, ableton, which lets you midi map just about anything to a knob/fader/etc in your set.
There are two sensors on the board, one touch sensitive strip, and a second infrared sensor for theremin like purposes. The touch sensitive strip acts just like the faders, holding it’s value after releasing your finger. The infrared sensor however drops to zero when your hand is away. I felt that the IR sensor would be more useful if the value could be held without keeping your hand in a certain place. Enter the toggle switch. The firmware is setup so that when the toggle switch is up, values from the IR sensor pass through, otherwise, they do not. This creates a sort of latching on the sensor, I like it.
The toggle switch and 4 arcade buttons simply send up/down commands similar to the monome. The arcade buttons have leds inside that respond to led on/off messages, just like monome buttons and can be used anyway that a monome button would be used. The toggle switch is connected in series with a 3W blue led, so when the toggle is up, the blue led comes on, there is no other contol over that led. Why it’s there is really anyone’s guess…. I thought it looked cool? I had one laying around? I don’t really know, but it does look cool when you’re using the IR sensor and your hand is lit up.
I get a lot of comments about the keypad, why is it there? What’s the point? I don’t know why this is such a mystery, it’s honestly one of the most useful thing on the controller. When used with the router application alone, the keypad simply sends keypress values based on the following. Enter numbers like you would on a calculator, they get pushed to the left, the star acts as a backspace, and the pound key acts as enter. So you can enter any number from 0 -9999. You can send that value to max/msp, or anywhere you want via osc messaging. Currently, I have to admit, I haven’t taken the time to give it any real functionality, but I have some ideas…And yes, it was just laying around when I was building this and there was extra space on the controller, so I stuck it there, but I still think it’s rad.
The 4 nixie tube digits at the top are simply a 4 digit display. You can set them via osc commands. They also are the display for any input on the keypad, otherwise they display the current time in beats from the running ableton set.
In addition to the surface controls, there are also hardware connections on the side and back of the controller for other devices. Something I wish there was more of on today’s controllers, a way for daisy chaining equipment together, or at least limiting the amount of cabling necessary going back to the computer. The controller has a powered 7 port usb hub inside, one is used for the polynome itself, the others are open for connections. The mains power is also rerouted to the external jacks on the back, for plugging in any other hardware that needs a plug. That eliminates a need for any kind of power strip etc. Last and pretty much least, there is a 12V DC output on the back for connecting any peripherals that need 12 V power. Ultimately, I kinda left this out, but it could be connected if I ever want it.
There are two parts to this, and really I could talk a lot about the software, but maybe in another post. Basically I took the communication code from monomeSerial, and adjusted it a bit to match my own hardware and add some of the extra commands for rgb, analog, keypad etc. There’s a lot of other details to this, as the software is really what keeps the controller ticking. Originally I was doing this using openframeworks, but the end package was just too cpu intensive, and wasn’t fast enough to handle quick changes, for example spectrum display monome programs. The code is below if you’re interested.
Secondly, there’s the max4live plugin:
You can download that below too if you’re interested in how it was made. The way it works is you choose either row, col, led, or monome color to adjust the color. Clicking on a button selects either the individual led, the row, or the col, then choosing a color from the color box sets that particular row/col/led/monocolor. You can save and load previous color configurations after that. The arcade button leds are actually controlled from inside the max4live patch so that you can differentiate between momentary switches, or toggle. The bottom right arcade switch is used to indicate the current beat of the song by flashing the led inside. Also, if the tempo controlled box is checked, you can use that button to set the tempo by tapping, the same way you would set it in ableton by tapping the “TAP” button.
or…why this took so long to finish…
This is the controller I’m using to run just about everything. I designed it to work for multiple projects, not just this, but as a result, I kept adding more and more switches and lights until I’d used up just about all the possible ins and outs. The monome, like everything else, is controlled and read from by a chain of shift registers. The switches are on a chain of 3x – 74HC165 registers which can read in a total of 24 digital inputs. The LEDs are multiplexed, but only in groups of 4 columns. So instead of going across all 8 rows, I split the LED chains into two sections of 4. That means you need two driving sources for the LED power, and 48 sinking sources for the particular LED. I did this using the 6 TPIC6B595 chips to sink the LED current, and one SN7441A hex driver to source the LED current. The driver IC is connected to the outputs of one of 3 74HC595 shift registers, the other two provide 16 additional digital I/O ports, used for driving the nixie tubes.
I chose to multiplex half the LEDs in groups of two in order to increase the overall brightness, and also increase the resolution of color depth. I ultimately decided on only allowing for 64 colors, (4 bit resolution on red, green, and blue) because it’s honestly not worth going much further. Through the buttons, it’s really hard to see any difference between 4 bit and 8 bit resolution, although I’m happy to say, even driven by the shift registers, you can still get 8 bit color resolution no problem.
The shift register chain is constantly updating the display in order to pulse-width-modulate the LEDs, it is also scanning the buttons for any button presses, while keeping track of possible debouncing errors. This is executed outside of the main program in an interrupt driven by one of the atmega168 timers. All the files related to the project can be found at the end of the post.
I made the case in individual pieces using ponoko. Pretty straight forward, you can download the illustrator files below if you want a reference for the monome button layout. I had a little trouble with the angled lid, or at least lining it up properly and had to do some cutting when I received the pieces. But…it could have been worse.
When all the LEDs are on, at full brightness, you essentially have 3*8*2 (rgb*8percolumn*2groups multiplexed) 48 LEDs lit. Each one is sourcing ~ 20mA, so that leads to ~ 1A of power for the LEDs alone. Switching of that kind of current turned out to be a pretty serious problem which I’ll mention later. Adding in the rest of the components, you need around another 200-300 mA of power. So total, at 5V you need maybe minimum of 1500mA. In addition, the nixie tubes are getting their power from a 180V converter that takes in ~200mA at 12V. I happened to have an old external hard drive enclosure laying around I wasn’t using anymore, and the power brick to go with it, so I cut open the brick and used the corresponding 12V and 5V as my power. The power supply is rated for 2A at 5V and 12V each, plenty more than I need. Since I had a lot of power to spare, I ended up connecting the 5V line to the power of the USB hub to give any externals needed power.
The nixie tubes get their power from a separate board (larger pcb on the right pictured below), 12V input goes through a DC-DC converter up to 180V, detailed here. The 12V then goes through a regulator to give 5V to the 4 74141 chips that drive the nixie tubes based on BCD input. This board is being used on another not yet finished project of mine, but I figured since I had multiples I could just use one to handle the dc conversion and BCD decoding. What I didn’t have was a good way to connect to this board at this point, so it’s a little sloppy, but it seems sturdy enough.
The nixie tubes themselves are IN-12B tubes, mounted on their appropriate sockets, held up using standoffs ~5/8″ long. When I was mounting these, I had recently seen a nixie tube project on the internet where someone back-lit the tube with an LED. I thought it looked kinda cool, but wasn’t planning on spending anytime figuring out how to do it. Then, I noticed that the sockets for the IN-12 tubes have these perfect little holes cut in the back middle. Almost the exact same size as a 5mm LED head. I had some laying around and tried it out, I was sold immediately, and it took almost no effort to add these in.
The monome buttons of course come from sparkfun.com, as many of the other parts that I’ll get to shortly. The pcb they are connected to came from a project I had started a while ago and sorta scrapped. It was a 128 monome (rgb of course) and it fit into a 5 unit rack. Why I stopped working on it when it was nearly completed is kind of a complicated answer, nevertheless, I had a bunch of extra pcb boards laying around so I cut one in half and used it for this project.
As I mentioned earlier, the LEDs that are being multiplexed are split into two groups. What I mean by this is that instead of turning on each row individually, and scanning across all 8, I hooked up the anode pins of rows 0 and 4, 1 and 5, 2 and 6, and 3 and 7 together. Then I cut the traces on the board between the RGB lines and switch lines ( you can see the white slash marks on the pcb in the picture below). Although this definitely added a lot more work, and a lot more wiring, it’s also a lot more bright. One of the disappointing features of my rack-mount monome was it wasn’t very bright. And although that was multiplexing across 16 columns instead of 8, I figured I wouldn’t take any chances, so now I only multiplex across 4 columns, in two groups. The code to do this is in the microcontroller files below.
If you look at the Eagle files, you can see that the current flows from the LEDs into the 6 TPIC6b595 shift registers. The current comes from a SN7441 hex driver which is capable of outputting 2A of current form its outputs, it is triggered by one of three 74HC595 shift registers, the other two drive the nixie tubes. Normally, I would move on here, but this is where I ended up running into a problem that delayed me about 3 months before I found a solution. At this point, everything on the circuit board works, and works well, accept for the analog inputs. When the LEDs are not connected, the analog inputs read very cleanly, there is almost no noise on their respective lines. However, when the LEDs get plugged back in, there is so much noise, that I couldn’t even get a 4 bit analog value to be stable. For reference, 4 bits means my sliders would have a range of 0-15. That would be pretty useless, and embarassing, and I couldn’t even get that! So obviously this problem had to be solved.
For a while I thought the problem was coming from the sinking of so much current. Since the LEDs can be draining ~1000mA, switching at frequencies of ~1MHz, there should of course be some induced noise from that. So I eventually isolated the ground from the shift registers and used a star ground type technique. That helped the problem, but only slightly. The real fix can be seen below in the form of a 3.3mF (that’s mili not micro) capacitor and a 10uH inductor. A friend of mine pointed out that the problem with the noise might not be from induction, but that the power supply is incapable of sourcing so much current on and off quickly. In order to compensate I would need a capacitor on the anodes of the LEDs, or essentially the output of the SN7441 hex driver. I tried some 100uF caps at first and got no change, and almost stopped until I found that big cap in one of my drawers. I put that on and all of a sudden the noise was gone entirely. Naturally I celebrated with some delicious Angel City Ale. If I had a bigger cap I would try that out, but I don’t so I stuck with this one.
Sensors (Faders, IR, Touch)
As with the monome buttons, the IR sensor, the touch strip, and the slide potentiometers(faders) all come from sparkfun.com. The uC is an Atmega168 TQFP package and has 8 analog inputs instead of the 6 on the common PDIP packages. The slide pots are just that, pretty dead easy to use as is the touch strip. In fact, so is the IR sensor, all of these devices just need to be wired up, and as long as there’s no noise on your AVCC line, you should be able to use them pretty much straight away. This added to my frustration when everything was working great, except the part that was supposed to be easiest.
The touchstrip is mounted on a piece of acrylic I had cut out specially from a different project, it is backlit with some surface mount leds glued to the sides.
The keypad, is from all places…sparkfun.com. Now I know I’m not the only one that at some point has been ordering things and seen this little number pad, for only $3.95!! and bought it with no actual intention of every using it. I can’t even remember when I bought mine, and it sat in a bin for over a year before I ever considered using it. But I had some extra space on the front and thought it would be useful, and IT IS. Anyways, the keypad works very similar to the monome switches. You have to scan a column of buttons and check the rows for button presses, or vice-versa. Essentially, you’ll need 7 pins, either 4 outputs and 3 inputs, or the other way around, either works. I was delighted when I realized I already had 4 outpus that were already scanning on my monome. So all I had to do was connect the 4 pins of the keypad for the columns, to a group of anodes on the monome LEDs and then I only had to read the 3 input pins. After more careful work, I also realized, if I chose the correct pins on my shift register for the inputs (0,1 and 2) and the correct keypad columns for (0,1,2, and 3). Then a keypad press could be read without any significant mapping. It’s not really important to understand, if you can figure out what I did in the code maybe you’ll appreciate it.
Arcade Buttons + Toggle
Guess where the arcade buttons are from….WRONG, theyr’e not from sparkfun, although they sorta could be. I actually decided to use the slightly translucent electric ice arcade buttons instead. My conclusion….they’re not that much better. If you have to only buy a few then I guess the extra price is worth it, but not if you’re buying a bunch. Each one is lit internally by a white LED, no not rgb, I was out of outputs for that. All I realy have left at this point is 4 outputs on the second SN7441 chip, these control the LEDs. The switches are connected to the last 74HC165 shift register which has the 4 arcade buttons, 3 keypad buttons, and 1 toggle switch (8 total). That pretty much wraps up all the I/O. 48 current sinking outputs (LEDS), 16 digital outputs (nixie tubes), 8 driving outputs (4 anodes, 4 leds), 16 inputs( 2×8 monome switch sections), and the 8 arcade, keypad, toggle switch inputs.
The toggle is fairly simple, it is connected directly to the 12V power supply and has an internal red led inside the switch that comes on when it’s in the active position. When it’s active, current flows through the switch, to a 3W blue led, then two a voltage divider circuit where the shift register reads to see if the switch is up.
The toggle switch I got from ebay, although yes, sparkfun does also sell one, but not with a slick internally lit switch.
One problem with my power supply is that there is no diode at it’s output. So if you use it as a 5V supply for a USB hub, when you connect a USB peripheral, power flows through the power supply even if it’s not plugged in, from the computer. I don’t like that, at all, so I put my own diode there. It does lower the voltage of the USB hub down to about 4.6V, but that doesn’t seem to be an issue at the moment. On my first board simply adding the diode worked, so I did the same on my second board. Obviously I wouldn’t be writing this if that worked also, here’s what happened.
Much to my surprise, there was an error on the PCB board, but it wasn’t mine! This is the first time I have witnessed this and it makes me uneasy. I really didn’t think this was very common, and I’ll spare slandering the board house responsible. But take a look at the pictures below of what the problem board looks like, compared with another board from the same batch:
This turned out to be not a big deal as how it affected the board working, but imagine if that wasn’t simply the USB 5V connected to the VCC plane. If for some reason the top plane was the GND plane, I would be short circuiting all the USB devices connected to the board! Not cool. I’ll have to start checking for those kinds of things from now on, and that sucks.
Wiring and other pictures
Really just to emphasize what a pain in the ass all this wiring turned into, and to encourage people to use crimp connectors wherever possible, take a look at all the wiring that was necessary and try and realize how much time and effort was saved when I was able to use crimp connectors, and when I wasn’t.
If you’ve made it this far…YOU’RE DONE! Thanks for reading!
polynomeSerial (very lite version of monomeSerial with the necessary adjustments for this controller. I’ve added some other controllers to the same project since finishing, which are also in the code.)
polynome5000 max4live object