Room To Play Week 6 – Nick Harbourne
“Have you ever wondered what it was like to see the world through a bat’s eyes? Mostly darkness and misty shapes, rather akin to me sans glasses. A rather better question is: What does it mean to hear the world like a bat?
Working with the mildly baffling and eternally frightening software that is Pure Data* (PD), this week’s Room to Play focused on programming an ultrasonic sensor to do our musical bidding. The sensor is plugged into a breadboard into which a Teensy board is slotted, providing the link between computer and hardware. In order to hear what it’s outputting, you must then turn to software to interpret the data. Max MSP does the job absolutely fine, and I’m pretty sure if you worked hard enough any software would work, even Audacity, though I shudder at the thought. The wonderful thing about PD is that is it a free, flexible piece of software which apes much of Max MSP’s workflow with rather less hand-holding, being perfect for myriad purposes including the one we’ll be using it for today.
Transforming the data from the sensor into something usable in PD takes a small while to figure out. Scaling issues, Arduino code confusion, and incorrectly constructed breadboards are among the problems (note how there’s always one common factor: myself). However it’s very easy to use to quickly alter parameters such as sample start and end times. This is the first step towards a controllable granular synthesiser, which is precisely what I failed to create in the session. Rapidly retriggering a recorded sample allows you to work within miniscule time scales, something that’s great for granulation – though hard on the ears. The challenge is working out effective enveloping in order to reduce zero-point crossing, why you get unpleasant glitches, and then how to make sure those envelopes don’t get totally mangled in the process.
All of these challenges aside, it’s mildly amusing and vaguely effective to simply programme the data in order to trigger random parameters for an aleatoric outcome and then ‘perform’ it, similarly to how one would perform a theremin. Cue several minutes of hand waving and general wizardy-looking performance.
One of the issues in using an ultrasonic sensor is that the data isn’t very pure. Because of the way the sensor works – emitting a sound from a speaker, recording the reverberation from a surface with a microphone, and then calculating the distant based on travel time – you end up with a lot of interference from different surfaces. Therefore, its use should be very carefully thought out, or used for something that doesn’t care about inaccurate data. However, when building an unpredictable and quite frankly crazy sounding PD patch, I don’t think the accuracy of data really matters all that much in the grand scheme of things. Somehow, being wrong only makes it feel more right.
Except when it stops working entirely, at which point you throw the entire system out of the window.
As a continuation of our exploration in working with different types of sensors, the ultrasonic sensor ended up being interesting but a little hard to make work predictably. As a tool to create controlled chaos it was certainly effective. The important question though is, did we end up hearing what a bat hears? I certainly hope not, lest I mourn for the unfortunate fate of our local bat population, periodically flying into nearby chimneys at the behest of their faulty sensors. “
*Colloquially known as What-Is-That-Why-Is-It-Beeping-Oh-God-I-Think-It’s-On-Fire Data, or the catchy WITWIIBOGITIOFD.
– Nick Harbourne (Room To Play Artist)