Showing posts with label monome. Show all posts
Showing posts with label monome. Show all posts

Monday, March 17, 2008

The OcTinct is up and running!

OcTinct


The OcTinct, the 8x8 member of the Tinct family (a full-colour monome clone), is up and running! The colours don't show up nearly as well in my videos (if anyone knows how to fix that, please let me know):




Technical details after the jump.


The Tinct is based off of custom-made PCBs and is being driven by an Arduino. The colour of each LED can be independently set, and the colour range is pretty much as close to "true" colour as you're going to get with an LED. The software is fully monome-compatible; the OSC command set is a superset of the monome protocol, adding in commands to control colour. Right now the colour control is pretty rudimentary, but will be expanded. There are two auxiliary analog inputs, which can be attached to anything that gives output as voltage: for example, potentiometers (as seen in the Life video above), or a two-axis accelerometer.

The controlling circuitry is currently all on breadboards, and is a horrible mess. You can see it in the videos. Eventually I'm going to make boards to hold this all nicely, and maybe tuck it into a nice case. Before I do that, I'm probably going to try a redesigned control scheme which uses two microcontrollers instead of one, in order to have a dedicated "video card." If it improves performance enough, I'll keep it that way. This is all about teaching myself electronics, though, so mostly I want to see if I can get the dual-processor scheme working.

Right now it's being powered off of the USB connection, but this is a temporary solution. I'm limiting the current to each 4x4 board via the transistors (I did this accidentally, but it worked out nicely for testing). What this means is that if any colour channel is trying to draw too much current (which occurs when more than 5 LEDs on a single panel are on at full blast in any of the three colour channels), then the colours might go a bit funny or dim. This will be fixed when I get around to building a proper power supply.

I have two extra sets of the custom boards for building this. If you're interested in trying to build one, get in touch (jmg *shift-2* upwardnotnorthward *dot* com).

Read More...

Wednesday, March 5, 2008

RGB monome clone update and rename: Tinct!


The gist: the video above is of the second version of my RGB monome clone. The reason is looks so much worse that the first version on video is because it is so bright that it saturates my camera's CCD; in reality, it looks much better than the original. It is fully compatible with monome programs and the colour can be changed on the fly via software. The project has been renamed "Tinct," the 4x4 version shown above is called TiniTinct, and that's how I'll refer to them from now on. Right now, production kits are looking unlikely, but I do have a couple of extra sets of the prototype boards if anyone is interested in them. For more details continue after the jump.

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.

Read More...

Wednesday, February 13, 2008

In the works: RGB monome-esque kit

Update: This kit probably isn't going to happen for various reasons. Read about it in this post.

After talking with Brian, and obtaining his blessing (and advice), I've decided to invest the money to produce a custom PCB for an RGB button pad prototype. This design is completely different than my original, offering improved colour-depth and brightness: the pre-prototyping I've done blows the old one out of the water. I hope to have the design completed and the custom PCBs in-hand by the end of the month. What I'd like to do is order a medium-sized run of these boards so that I can split the development cost with like-minded hardware hackers. These would not be "plug and play" kits by any stretch of the imagination: these would require significant extra work to get them to do anything, and comfort working with electronics. The numbers will be kept small, so we can all easily communicate, and hence people who want to participate will need to be in touch with me first. This will be nothing like the monome kits, which are much more user friendly! You have been warned! If you fit this description, I need your feedback, so please read on and respond!

There are a few ways I could do this that I'm considering, each with their own advantages and disadvantages (both for me and for you). This would only be a board with the buttons and LEDs on it, as well as the circuitry to drive the LEDs. No logic would be on-board, that would have to be handled by an external microcontroller, most likely an Arduino (although your favourite board could work, too).

What I'm most likely to make first is a 4x4 button pad design to work with Sparkfun's buttons. It would include a small overhang to hold the circuitry to drive the LEDs, which would interface serially with whichever microcontroller platform you'd like. The serial interface would only control the LEDs; the buttons' wiring would be broken out to control however you like. All of the inputs and outputs will be neatly bundled together in a ribbon cable. Code and schematics for running it off of an Arduino (and possibly other platforms) would be made freely available. It would be possible to daisy-chain multiple 4x4 boards, but this would require more complicated off-board wiring. This kit would be the least expensive option, and also offers the most flexibility. The disadvantage would be that it would require the most outside wiring to get working, especially if you're planning on chaining multiple boards.

What I'd really like to make, personally, is an 8x8 button pad on a single baord, which would include a full serial interface for both the buttons and the LEDs, as well as power circuitry on-board (an 8x8 RGB pad uses a lot of current!). It is highly doubtful that I would do this initially for several reasons: for starters, it would be a much more complicated board for me to design and test. Perhaps more importantly, it would require me to invest in the professional edition of Eagle, which is an additional $600. That's money I need to put up initially, and it's money that would have to be factored into the cost of the boards for any other developers. So, unless feedback is overwhelmingly in favour of the 8x8 pad, this would most likely come later, if the interest existed.

Finally, there's the logic board. For now (and probably forever), this would be an Arduino. If you want to hook it up to something else, then by all means you could do so; if I hook it up to something else, I'll probably post code for it. For now, though, I'm developing on an Arduino and maybe AVR, so that's what I'll offer.

In terms of functionality, it will probably be possible to make this "monome-compatible," like my monomuino project. Of course, the colour functionality would not be accesible in this mode, you would have to pick the colour you wanted to display. I can't stress enough: if you want to build a monome, buy the kits from monome! This is for people interested in hardware tinkering. This device could also be controlled with a to-be-developed custom protocol which supports full colour, but in terms of software to utilize this, it would have to be custom written. Hopefully, if we get together a group of about a dozen people to do this, we'll be able to put together some neat stuff.

Here's what I'd like to hear from you:
  • Which kit(s) would you be interested in? How many?
  • The LEDs I like are from superbrightLEDs.com, and are much more expensive than ones you can find on Ebay, but much higher quality. If I bought a bulk order of those, and sold them at around cost (that's the discounted bulk cost, not the individual LED cost at superbrightLEDs), would you buy them bundled with the kit? (This would add ~$20 to a 4x4 kit, and ~$80 to an 8x8).
  • Similarly, would you want the Sparkfun buttons bundled with the kit? This would save you shipping from Sparkfun.
  • Can I contact you in the future with questions about the kit, and/or with announcements about the kits' availability?
  • Any other questions or comments you might have
If you email me (at jmg -atsign- upwardnotnorthward -dot- com), I will not give your information out to anybody under any circumstances. I will contact you precisely once, to let you know that the boards are available, unless you explicitly give me permission to contact you more, or ask that I not contact you at all.

If you don't trust me with your email address, and never want to hear from me, then simply leave your thoughts in the comments below. That's cool, too.

Read More...

Tuesday, January 29, 2008

monomuino: an Arduino-based monome compatible


I believe this is the first monome-compatible based on an Arduino (and possibly the first monome-compatible device, period). I call it the monomuino. I considered calling it a minimonome, since it is only 4x4, but I wanted to get some Arduino reference in there; as much fun as minimonomuino is to say, it's a bit of a mouthful. If I make a larger version, maybe I'll rename it. I'm pleased that, like the name of the original, there is a minimalist mathematical inspiration behind the term.


In an earlier post I presented a project that used the monome form-factor with the RGB colour blending in each button. That project, however, didn't communicate with a host computer, and had all of its software on the Arduino. This device uses the monome256 protocol to interact with MonomeSerial. The video above shows it pretending to be (one quadrant of) a monome sixty-four, interacting with several of the MaxMSP patches from the monome base collection. (Apologies as always for the lousy video quality!)

For information on how it works, read on.

This project does not use the full RGB capabilities of my earlier button pad, because the monome protocol doesn't support it. Instead, I've connected the blue channels directly to the Arduino in a standard 4x4 multiplex arrangement, and the buttons as before. This uses essentially all of the pins on the Arduino to power just a 4x4 grid, so it obviously can't scale directly; I do believe, however, that with a couple of inexpensive chips added to it, I could scale up to an 8x8 or possibly higher.

The trickiest part of this project was getting MonomeSerial on OS X to recognize the Arduino as a monome (note that all of this information applies only on OS X; your mileage may vary on other systems). From what I can tell, MonomeSerial looks for a device named tty.usbserial-m40h-xxx, tty.usbserial-m64-xxxx, tty.usbserial-m128-xxx, or tty.usbserial-m256-xxx, where the first part indicates the device, and the x's are a (presumably unique) serial number. I tried making links to the Arduino device with the correct name format, but that didn't work; looking over the source for MonomeSerial, it appears to look for an event from the Kernel. I tried figuring out how to change the source to recognize other device names, but my C++ skills aren't up to snuff. So, I realize I had to change the serial number of my Arduino (or, more specifically, the serial number of the FT232 chip in my Arduino). If there's an easier way to do this, I'd love to hear about it in the comments!

To do this requires programming the chip's EEPROM. (Obligatory WARNING: if you kill your Arduino trying this, it's not my fault!) I found some Linux programs to do this (Google for FTDI EEPROM for others), but couldn't get any to compile on OS X, so, despite my distate for it, I grudgingly went to a Windows box. FTDI offers a utility called MProg for programming EEPROMs. Note that it requires the D2XX drivers, which I gather aren't the "normal" drivers that you already have installed if you're using an Arduino. MProg has one of those terribly unintuitive user-interfaces that only an extremely niche product can get away with (or maybe that's par for the course on Windows), but it got the job done. Soon enough, my Arduino was renamed tty.usbserial-m64-0001, and was recognized by MonomeSerial.

After that, implementation of the monome256 protocol was pretty straightforward. The only annoying part was figuring out what speed the serial connection was set to: I couldn't find it documented anywhere, so it was simply a matter of guessing and checking until something worked. I assumed it would be pretty fast, so I started at 115200 baud and worked my way down; since it turns out to be 9600 baud, it was a bit of an exercise in frustration. After seeing how frustrated it can be working with an extremely well-documented protocol, I have renewed respect for any hardware hackers who do real reverse-engineering! There were also some timing issues with my serial implementation, which were easily resolved by making sure I wasn't calling Serial.available() too often (not entirely sure why it was a problem, but it did the trick), and timing problems in the other direction, making sure I wasn't dropping any received commands.

So what's next? I see two obvious directions: one is to see if I can get an 8x8 pad running off the Arduino. As I said above, I'm fairly certain I can, but it would cost me another ~$100 or so in parts if I got them off the shelf, and I don't think I'm willing to invest that much in it. I'd much rather pursue my improved design for the RGB button pad. That requires designing my own PCB, which I've never done before, so it holds a lot more interest for me. The problem is that a 4x4 button pad PCB is larger than the free version of Eagle allows, and I haven't been able to get KiCad running satisfactorily on OS X (if anyone can help with that, it would be greatly appreciated!). The beta for version 5 of Eagle is a pretty huge improvement on OS X, though, so I might be willing to shell out once that's released.

Thanks to the great folks over at monome for making their hardware and software so open! Congratulations, too, on the amazing success of their most recent offering; these products are hard to get than Hannah Montana tickets!

As always, questions and comments are welcome and encouraged.

Read More...

Saturday, January 19, 2008

My first project: Full-colour RGB monome clone (Trinome?)


Here it is, the first project that I designed and executed on my own. I'm thinking of calling it the Trinome, but that's still up in the air. Here it is running a simple demo program:



The monome is a gorgeous, minimalist, open-source light-and-button pad used primarily by musicians as a controller. The folks over at SparkFun Electronics, inspired by the monome, released their own button pads and circuit boards, only they designed theirs to be able to hold RGB LEDs. They made this nifty Tetris game with their parts. Looking at it, though, I noticed something: they only seemed to use a limited palette, in particular, they only appeared to have red, green, blue, cyan, magenta, yellow, and white, corresponding to channels being fully on or fully off. I wanted to see if I could get colour mixing, wherein channels were on partially in order to blend colours smoothly.

Read on for more details, videos, and instructions on how to build one.


The Design
A common way to control many LEDs is multiplexing, wherein only some of the LEDs are on at any given time. They are cycled through at a rate fast enough that the human eye can't detect it, and hence all appear to be on at the same time. In this case, having one row on at a time is the natural way to go. A similar method can be used to determine which keys are pressed; diodes are necessary to prevent "ghosting" and "masking" of buttons, as explained in this article.

Analog output, used to control LED brightness, is usually achieved via pulse-width modulation (PWM). While it may be possible to combine PWM with a multiplexed display, it would require very fast refresh rates in order to not appear to flicker. Furthermore, that would require 12 pins on the microcontroller be dedicated to controlling the brightness of the LEDs (3 colour channels x 4 LEDs on at a time). That eats up an unacceptable number of microcontroller outputs. Another solution had to be found.

Another way to adjust the brightness of an LED is using a resistor; in particular, if you want the brightness to be adjustable, a variable resistor. Fortunately, there exist digital potentiometers whose resistance can be set. I was introduced to one such digital pot in this tutorial on the Arduino website, written by Heather Dewey-Hagborg. The chip in the tutorial, the AD5206, has six independent potentiometers on board. As I mentioned above, this project needs to control 12 channels at once, so two AD5206s should do the trick nicely.


The Parts
4x4 Button pad ($10, Sparkfun)
Button pad breakout board ($15, Sparkfun)
Arduino ($33, Adafruit)
16 common cathode RGB LEDs (I used RL5-RGB-D) (~$1.50ea, Superbrightleds.com)
2 AD5206 digital potentiometers ($3.66, Digikey)
16 1N4148 diodes (Pennies, any electronics parts store)
4 2N2222 transistors (Pennies, any electronics parts store)
Various resistors (LED current limiting and pull-down) (Pennies, any electronics parts store)

The Build
I'm too inexperienced with Eagle (and, let's face it, too lazy) to draw up a proper schematic. If enough people want it, I suppose I'll put one together. Still, the build itself is pretty easy. The button pad assembly is straightforward: solder in the LEDs and the diodes according to the silkscreen on the board. Actually, the LEDs held in tightly even without soldering, and since I'm a bit paranoid, I did all of my testing with the LEDs held in place by tension alone. I soldered in wires for each of the input and ground lines, 24 wires in all, making it all quite a mess to work with. If I continue with this, I'll replace them with proper connections of some sort, but I didn't have anything handy, so wires it was.

The AD5206 gets wired up just like in the datasheet, or in this tutorial from the Arduino site. To add the second digital pot, you wire it up exactly the same, and share the same Serial In and Clock lines with the first chip, with a separate Chip Select line. Each of the twelve outputs gets wired to one channel of one column of LEDs, with a series resistor in between to protect the LED from too much current and to set the colour balance. (You might be able to get away without this resistor, but it will probably shorten the lifespan of your LEDs.) The zero setting of the AD5206 has a resistance of about 40 Ohms. In all the RGB LEDs that I've seen the red channel has a much lower forward voltage than the blue and green, something to consider when picking your resistor values.

The input and output lines from the buttons go into Arduino pins, with the output having pull-down resistors. The ground lines from the common cathodes of the LEDs go to the collectors of the transistors, with the emitters going to ground, and the base pins attached to the Arduino (through appropriate resistors). Using the transistors ensures the Arduino pins don't sink too much current.

One final word about the build: make sure that, when soldered, your LEDs don't stick up too high, otherwise you might not be able to get the buttons to make a good contact. I found this out the hard way.


The Code
The basic outline of the code is:

Looping through the rows, bring each row of buttons high in turn, in order to scan that row for button presses.
Looping through the columns, check if each button-press state has changed. If it has, run the appropriate on_press or on_release routines. If it hasn't, run the appropriate while_pressed or while_released routine.
Still inside both loops, write the potentiometer value for that button entry.
End the column loop.
Bring the row of buttons low.
Bring the LEDs for the row high, wait a little bit so it's visible, and then bring it low.
End the row loop.


I wanted to include real code here, but I have yet to figure out how to properly format it in the Blogger tags. If people really want to see it, I'll figure out how to add it in here. (Update: I've posted some code in the Arduino forum for now.)


The Catch
Or, rather, the catches. Basically, this is a lousy a pretty lousy method to accomplish the colour blending. First of all, the digital potentiometers are voltage dividers; they limit current (and therefore brightness) by limiting voltage. That means that, once the supply voltage drops below the LED's forward voltage, the LED turns off. For the blue and green channels, this happens less than halfway through the pot's 8-bit range, severely limiting the range of colours you can get. I could use the digital potentiometers as rheostats, limiting only current, but then the 10kOhms maximum isn't enough to get them anywhere close to off, so I'd either need a high-resistance pot (with correspondingly low resolution), or additional circuitry to turn the LEDs off. Both bad choices. Furthermore, because of the LEDs' nonlinear current-brightness curve, the number of visible changes within that limited range is further cut. So, the resolution in colour space is much less than I'd like.

The other catch is brightness. Though the videos look really bright, it doesn't look anywhere near that good in person. Don't get me wrong, it looks alright, but not as good as it could look. Because of the multiplexing, the LEDs are on at a maximum a quarter of the time. In reality, it's probably more like a fifth or less because of overhead. Comparing a full-on LED to one at the duty cycle on the board really makes me want to come up with a non-multiplexed solution.

The Future
The good news is, I think I have come up with a solution that will work for non-multiplexing the LEDs. The bad news is, it will eat a lot of current (so I'm looking in to power supply options), and it will require me to make my own circuit board (which I've never done before, but I'm going to have to learn sometime, so why not now?). The really bad news is that the free version of Eagle CAD has a size limit per board that is smaller than the 4x4 buttons. I'm not sure I'm ready yet to invest $125 in the non-profit license, so we'll have to see what happens. I'll get a breadboard prototype working first.

As for this version, I think it should easily expand to a 4x8 pad by adding two more AD5206s. It might require some fancy work, or even a demultiplexer IC, to read all 8 buttons in a row, but I think it should work. An 8x8 layout might also be attainable, but in order to keep the brightness up I would set it up as two 4x8's being driven off the same master controller. I think anything higher than 8x8, at least with this design, will require multiple microcontrollers for different segments with a master controller coordinating it.

One other possibility using this design, which is more in tune with the minimalist philosophy of the original, would be to use single colour LEDs and fade them, ideas of which are shown in the following couple of videos:


Finally, if I were to continue pursuing this design, I would want to eventually put it on a board that could function as a "backpack" to the Sparkfun breakout board, similar to their serial interface for their RGB pixel boards, or the idea behind the Arduino shields. The idea would be a board with headers that lined up with those of the breakout board, which can be attached directly to it to extend it's functionality.


The Challenge
Wow! If you've read this far you must be really interested. I'm flattered!

Here's the deal: so far, all the demos I've written are running directly on the Arduino, so the whole setup is standalone. One of the coolest things about the monome, though, is that it's interfacing with something (namely, the computer). Implementing a serial protocol on the button pad is pretty trivial. However, you need something to interface with. I haven't had time to write any software that would talk to the button pad via the serial port and do something cool; I'm too caught up in the microcontroller side of things. However, if someone were to write software to talk to the button pad, I would definitely set it up to work and post a video of it in action.

Here are the requirements: it needs to run on OS X, and I need to be able to see the source. A Processing sketch would be ideal. You can set the communications protocol up any way you like, as long as you explain it; it should be easy, all you need to send are coordinates and RGB data, and received a 16-bit binary string indicating whether buttons are pressed or not. Post something in the comments, maybe a link to the code, and we'll see if we can get it working.

I'll be honest, I don't really expect anyone to respond to this, but man, it'd be cool if someone did!

Read More...