“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)