As much as I like the name
Trinome, I felt it implied a little too close an association with the real
monome project. As a result, I was reluctant to actually
use that name, and ended up just calling it "RGB monome clone" or "RGB button pad," which are boring. So, I've decided to rename the project
Tinct. The 4x4 version shown above is the TiniTinct (pronounced Tiny Tinct), and the 8x8 version will be called the OcTinct. To be clear, the monome folks didn't ask me to make this change - they have been nothing but supportive - but I just decided to make it out of respect for them and their work.
As for the kit: thank you to everyone who has expressed interest. Right now, I just don't think it will happen. Making a kit would require another version of the 4x4 boards to fix small mistakes in the prototype (or designing an 8x8 version of the board), plus making a second board to hold controlling circuitry; this development would be expensive, and it's money I'm not willing to invest. There's also the issue of reliability and capabilities; this is very much a hacked-together project, and if I made it a kit, people would (reasonably) expect certain standards to be met. I'm just not sure I could be satisfied that I was meeting those standards without a lot more investment of time and money in this project. Finally, I just don't think I'm up to the task of providing technical support for a kit of this complexity. I'm finishing off a PhD, and I don't want to commit time to helping others build a kit. So, for the foreseeable future, a kit won't be produced.
But, if you really are interested and up for it, there are a couple ways you can get your hands on this.
I have two extra sets (four boards each) of the prototype boards. When I put out the call earlier, I had two people respond, which made the production of these boards financially possible for me. They have their boards now and are working on duplicating my project. They were brave enough to buy the boards knowing that they might not work at all, or not as advertised. Well, now we know that you can at least use them to make a 4x4 monome-compatible device which can change colours on the fly. Soon I expect to have the 8x8 version up and running. A set of four bare boards will cost about $100. Parts will probably be another $100 or so (or much more, depending on the LEDs you get). If you understand and accept the difficulties involved and still want to duplicate my project (Don't say I didn't warn you!), please get in touch. If I hear from 8 people who want single boards before I hear from 2 people who want sets of four, then I'll be happy to sell the boards as single 4x4's. If I hear from enough people who are crazy enough to do this (let's say, six people looking for sets of four), then I'll order more of the prototype boards - on the understand that this is duplicating a prototype, not building a kit, and that minimal support will be provided. If you can't get it to work, don't come complaining to me!
The second way is if an "angel investor" were to appear (rather unlikely, I know). If someone were to pay me a lot of money, I would be willing to continue development on this. Cost would depend on the level of polish in the final product, but I think the least expensive I would do it for would be $1000, with prices rising from there depending on what exactly the demands of the project are. I don't expect this to happen, but I'm throwing it out there in case someone reading has both more money and more passion for this project than I do.
On to the technical details: I wrote my own version of monomeSerial in Processing to make it easier to hack during development. This software takes the OSC commands that the monome MSP patches and Chuck shreds send out, and translate them into serial commands that the Arduino can understand. It also receives the Serial data that the Arduino sends about button presses, and translates them into OSC commands that get sent back to the controlling program. I modified it slightly to create TinctSerial, which does the exact same thing, with the addition of an on-screen colour selector. You click on a colour in the window, and the Tinct changes its colour accordingly. The matching of colours isn't perfect yet, but you get a reasonable approximation of what you choose (and if anyone knows of a good way to accurately translate RGB values to the PWM frequencies needed to match that colour, please let me know!).
The LEDs are being driven by a single TLC5940 16-channel PWM driver. All 16 LEDs are connected to the chip simultaneously, and multiplexing is done over the colour channels. That means that only one colour channel is on at any given time, but it cycles through quickly enough that the eye can't see it. The camera, however, occasionally can, and so you might notice occasional "colour hiccups" in the video; these can't be seen in real life.
Switching from the digital pots to the TLC5940 has huge benefits: much brighter max brightness, and a colour resolution improved at least 20-fold. It does come with downsides, though. The main one is, the TLC5940 requires constant attention from the microprocessor. If too much time is spent doing something else, for example registering button presses, sending serial data, or interpreting received serial data, then the LEDs flicker visibly. Making sure that this doesn't happen has really been pushing my programming skills (which is great, because I always love a challenge). I've been able to get it running in monochrome mode without flickering, but I fear that frequently changing the colour of individual buttons might be impossible to do flicker-free in this setup. Of course, it all depends on your refresh speed. 30fps video might not be feasible, but 10fps might work; many full-colour applications that only require occasional colour changes should be fine. I think this problem could be overcome by using multiple microcontrollers, one to handle the buttons and serial I/O, and the other to take care of the TLC5940. Right now I'm not planning on taking the project in that direction (unless somebody offers me a lot of money to do it, which I doubt). If someone wants to buy my extra boards and give it a shot, you have my blessing.
The serial protocol I'm using is identical to the
monome256 protocol, with the addition of the colour command. Since the monome protocol has message id's 0 and 1 reserved for messages coming from the device to the computer, I simply hijacked id 0 and use it to send colour data from the computer to the monome. I initially had some issues with commands getting misinterpreted. In particular, if you changed colours very rapidly you would sometimes get an LED turn on erroneously. This was a very annoying bug. I would think I had fixed it, test it and everything appeared fine, and then as soon as I started filming it it would pop up again. I kept trying to fix the problem in the firmware, but I finally tracked it down to a problem with the TinctSerial program and I believe I've fixed it; at the very least, the error rate is now low enough that I haven't been able to make it happen again. There were also timing issues on the receiving end: initially, the Life program was sending commands to the Tinct much too quickly, and so packets would get dropped. Another timing-related issue which was much more rare caused dropped packets, creating
frameshift mutations (did I mention I'm working on my PhD in molecular biology?). These created completely unpredictable effects. I believe I've managed to quash all of these timing issues in firmware.
I caved and bought cheap Ebay RGB LEDs instead of the expensive superbrightleds.com ones. I couldn't help it, they're 1/5th the price! The quality isn't terrible: they are very bright and the colour is quite rich. The only problem is, the colours don't match from LED to LED like the superbrightleds.com ones do. Frankly, for the ~$80 I saved, I can live with it, but in a perfect world I'd use the superbrightleds.com ones.
