Containerized Particulate

Generally when I’m involved in creative projects, I tend to try to keep things relatively simple, technically. This is partially a conscious decision, as I don’t want technical minutia getting in the way of creative expression, but it’s also a constraint of my so-so technical background. At any rate, I’ve been working on a few projects lately that involve pretty simple requirements, for which I’ve found relatively simple solutions. The first, I’ll write up today. I’ll save the other for soonish, once I’ve got it figured out 100%.

For the first project, the idea was to make a tactile interface out of conductive material, to provide data about who’s touching what, when, and to what degree. I settled on using an n in n out audio interface as a sensor array. The idea is to feed back each channel output back into its own input, turning the combined channel into  I/O in the sensor array. Each channel has a unique frequency assigned to it’s output, and a notch filter on its input making it ‘deaf’ to its own tone. When a user touches two or more of these I/O channels, their skin conducts the audio signals from channel to channel, and each channel registers the amplitude of the other tones it’s receiving. My setup right now involves insert snakes, with the mono ends plugged into the input / outputs of the audio interface, and the TRS end plugged into a 1/4″ stereo jack with the signal lines tied together.

Currently, the Max patch tells you the sum total of one channels tone being picked up on all others. Later, I may spend some time turning it into an n by n matrix, providing more specific information on channel to channel relationships. I don’t really feel a need for all that extra data right now, though.

Also, I don’t know why it would, but this patch (and misuse of your audio interface in this way) may totally destroy your interface / computer / life. So don’t say I didn’t warn you. Here’s the patch – sensor.maxpat (right click ->save as…)

Just a brief update before I lose sight of this stuff;

I’ve lately decided to spend a lot more time with Supercollider, which doesn’t serve as well for prototyping as something like Max/MSP or PD, but has already proven to have a lot of the same functionality, given a willingness to actually deal with code. sc140 contains a lot of excellent examples of the kinds of complexity you can get with relatively little code, and  is easily my favorite thing involving twitter *ever*. Also, whenever I have the time, I plan to sit down with ixi, and see what that’s all about. The goal I have in mind is a Supercollider… synth? program?… that will take OSC input from one or more running instances of Isadora during a live performance. Ideally, I’d act as a kind of ‘operator’, routing, scaling and biasing various OSC signals to appropriate parameters within the synthesizer, creating a live indeterminate composition with clear correlations with the video being projected. I’ll post interesting and useful code / resources as I work my way through this process.

True! Beyond (hopefully) looking and behaving much better, a lot of old stuff is now more organized / available. So uh, yeah.

So we’ve finally reached some kind of finished-like-state with the midiglock. I’ll be putting media up over in the new section I’ve made for it over the next few days (hint: it’s on the left, under ‘projects’). Expect it to take a little while; my computer doesn’t render video like it used to.

Yes indeed. Some of the subtleties of velocity differentiation are lost on this video, but if nothing else, it’s made these bells much less irritating to listen to. Low PWM and high frequency also yields some very cool modem / printer like tones. What’s even less obvious is a total rewrite of the code, which should make it a breeze to upgrade this thing to a 3 octave glock + Arduino Mega.