Binary Modulation

As our world’s dependence on computers continues to grow, so to does our need to study and expose the inner workings of this ubiquitous technology. Inspired by The Critical Engineering Manifesto (The Critical Engineering Working Group, 2011), Binary Modulation is a series of live improvisations dealing with alternative ways of performing with the ever-present laptop computer. Tunnelling beneath the usual layers of software abstraction, each performance uses sonic means of production to illustrate how “all of computation is possible thanks to the binary modulation of the physical, in this case electricity. On or off” (Howse, 2007).

Eschewing the laptop performers usual arsenal of Max/MSP and Ableton Live, and influenced by the Data Sedimentation works of Martin Howse and Valentina Vuksic’s performance piece Tripping through runtime, Binary Modulation exploits various quirks of the Debian GNU/Linux command-line interface alongside the forensic detection of the laptop’s many and varied electromagnetic emissions.

Each performance can be broken down into two main sections.

cat /lib/modules/2.6.32-5-686/* > /dev/dsp

uses redirection to throw the contents of the Linux kernel source code as raw ASCII data straight at the laptop’s sound card.

./howse/self “/bin/ps” “-ef” > /dev/dsp

uses code, written by the artist Martin Howse, to translate “CPU/machine code registers starting and running a specific process into audio” (Howse, 2012). Both commands can be seen as a form of audification where the measurements of a process are made audible in the most direct way possible: converted to air pressure values and transferred to a loudspeaker.

Throughout the whole performance a telephone pick-up coil – metres of thin copper wire wrapped around an iron slug, which when plugged into a suitable amplifier, acts like a radio antenna for frequencies low enough to be within the range of human hearing (Collins, 2009, p.12) – listens in to the electromagnetic energy given off by “the binary modulation of the physical, in this case electricity. On or off” (Howse, 2007).


Collins, N., 2006. Handmade electronic music: the art of hardware hacking. 2nd ed. Abingdon: Routledge.

The Critical Engineering Working Group, 2011. The Critical Engineering Manifesto. [online] October 2011. Available at: <> [Accessed 8 May 2013].

Howse, M., 2012. Data sedimentation, _____ -micro research [London/Berlin]. [online] Available at: <> [Accessed 8 May 2013].

Howse, M., 2007. The executable’s song, Tux Deluxe. [online] 20 May 2007. Available at: <> [Accessed 4 May 2013].

Vuksic, V., 2011. Tripping through runtime, Zeromoon. [online] Available at: <> [Accessed 8 May 2013].


One comment

  1. yukigusu

    Stephen, thanks for the intriguing post. In all honesty I’m quite new to the areas including critical engineering, data sedimentation, Linx. As green as grass, it made me stop and think when you write: “Each performance can be broken down into two main sections.” Perhaps my question is something to do with the function of code. What does a code contain? Or, what is it that distinguishes one code from another one? My guess is that the first code presented here is something about module and some number. While I suppose that both codes are written by Martin, I thought it’s interesting that only the second code includes his name. I’m not sure if this is of significance. I have never written or deciphered code and am not quite sure if code is something that is deciphered or decipherable in some way in critical engineering. If you can share thoughts on this, I would very much benefit from hearing and learning from you. Thanks.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s