Since building my first prototype I've spent countless hours investigating a suitable technical path for some of the things I anticipate delivering next year. I don't believe that technology should come before user experience, the interaction solutions should come first with a technical solution to follow. That said, I'm set on using this project – unique opportunity that it is – to take my development skills to the next level. I'm also a little intimidated by the amibitious bar I've set myself to deliver something fully functioning as part of my thesis. I don't want to 'fake it'. For this reason I've been keen to set myself on a path so I have ample time to get to grips with whatever technology I choose.
Processing My first prototype used Processing and Arduino. We learned a little of both last year. I feel confident that Arduino is an appropriate tool for the sensor inputs I forsee developing, but Processing didn't feel like the right tool for the software component. It's perhaps not powerful enough, and things like selecting objects via mouse are unnecessarily laborious.
Raspberry Pi I got set up with a Raspberry Pi and learned the basics of Python, before deciding the hardware was probably too underpowered for what I hoped to achieve.
openFrameworks In some ways openFrameworks is the spiritual successor to Processing. It's more powerful, and I spent quite some time getting to grips with its potential. It seems fantastic, but suffers from similar limitations to Processing for my purposes – keeping track of object properties and being able to manipulate them with user interaction appears to be somewhat problematic. For example, if I draw an irregular shape and then want to select it with a mouse, a lot of math is involved in detecting if the mouse if over the shape (at least, as I understand it).
My second prototype used Paper.js and Breakout to build a simple potentiometer-controlled RGB selector:
It's been a really useful process. It doesn't quite work from an interaction perspective, for two key reasons: the sliders don't quite make sense being controlled by a circular dial, and the potentiometer can't reset itself to a position undermining a full feedback loop between the input and object.
To clarify this last point – the potentiometer holds a certain value between 0-1, which is mapped to the slider and consequently color output. But if switching to another color, or if in future another object was selected to manipulate its color value, the potentiometer can't reset to a received value. Instead we apply its value to the color object, which is probably not what the user would want. This can be seen as I switch between the sliders in the video (currently just by pressing the R, G or B keys on the keyboard).
One option for overcoming this problem is to use a rotary encoder, which can keep turning infinitely and doesn't store a specific value (it just tracks change up or down). But a better option, with way more potential for a closed feedback loop, is a motorized fader. It's not going to be simple, but this is the focus of my next effort.