Drawing out the archive
This essay was originally published in the catalogue for Vault: The Non-Stop Performing History of Circus Oz, which was exhibited at the Melbourne Festival, October 9-26, 2014.
Last Friday, I spent the whole day trying to get a button to work.
And yesterday, I spent 6 hours trying to get the small computer that made said button work start a simple program when it powered up.
Last Friday, the situation was: I had a button (in fact, a small electronic switch known as a ‘microswitch’), wired to a small computer known as a ‘Raspberry Pi’. The switch, when pressed, completed a circuit which, via a General Purpose In Out (GPIO), told a small program, running in a programming language known as ‘Python’, that the switch had been pressed. The program executed, and when I pressed the button, the program let me know so by printing out a button pressed message to a ‘console’, in an aesthetic approximation of what ticker-tape must have been like back when ticker-tape was a thing.
Also running on the computer was a program written in a language known as ‘Javascript’. This program connected to the internet, loaded a random entry from the Circus Oz Living Archive database, selected three words in sequence from a closed set of database fields, switched all the pixels on a screen connected to the Raspberry Pi to a bright pink, and then switched some of the pixels to black so that the three words were displayed — with sometimes surprising, amusing results. “Introduces with monologue”, “and steals his”, “skull hat dance”.
The problem I was having was in getting the two programs communicating with each other. What was supposed to happen was the switch in the Python code was meant to trigger the loading action on the Javascript program. You press the switch, you get three words. Simple enough.
I can’t explain here exactly what took me so long to get this working. Partly because of space issues in this catalogue, but partly because I’m not quite sure myself. It involved deciphering long, complicated online forum posts (written with a lot of assumed knowledge), downloading software and ‘code snippets’, cutting and pasting and moving code between text files in directories named /etc/ and /home/pi/. I googled combinations of words that looked oddly like my program’s output: “raspberry pi GPIO xinit chromium”, “python stdin simulate keypress popen”, “startx uinput bug”. I seriously considered buying a USB keybord, cutting it with a grinder so that it was only one button, and using that instead.
I did get the Dreaded Electronic Button working late Friday afternoon, and took a much needed rest on the weekend, tidying the garden, sanding and painting window frames in our new house.
Back in the studio on Monday, I faced another issue: I could make my programs start by invoking them manually, (typing code into the ‘command line’), but I couldn’t get them to start automatically when the computer booted up (an important requirement for this exhibition: what would happen if the power went out, or if we wanted to power down the exhibition overnight?) More specifically, I could get the programs to start, but I couldn’t get them to show on the screen. One program at a time? No problem. Both? For some reason, impossible. I began again… reading forum posts, copying and pasting code, downloading software, googling sentences that, had I said them out loud, you would have assumed I’d had a mild stroke.
Bret Victor calls programming ‘blindly manipulating symbols’: unlike a painter who manipulates paint directly on a canvas, when programming one writes in symbolic code, which is computationally interpreted to produce an output which is made of considerably different stuff: electrical signals, light, pixels, actions. Victor argues that the inherent blindness in the programming systems that we use today acts as a hindrance to art in that it separates the creator from their ideas by putting up technical barriers. In my PhD thesis (which I completed while working closely with archive of digital videos that made this exhibition possible), I argued that this ‘blind manipulation’ is occasionally beneficial if using coding to design new things, in that it can produce unexpected outputs and serendipitous discoveries. But in the Case of the Electric Button, this blind manipulation was only frustrating. I knew exactly what I wanted, and my poor understanding of the tools at my disposal was only a barrier to my practice. And I couldn’t even really tell you what I learned from the process, other than for my particular odd set of interacting elements, some things have to be in this order and not in that order in order to function. The resulting piece of art produced through this described effort is the Poetic Randomiser, a ‘act’ in our exhibition which, in the end, could be though of as little more than a simple joke about data integrity.
Examples like the one above demonstrate how ‘the idea of software’s “immateriality” is ultimately trivializing and debilitating’. Sure, code is really just 1s and 0s, code doesn’t ‘exist’ in a physical space. But when you are ‘coding’ your code is always supposed to perform actions in the real world. And those actions are determined by computational systems — both hardware and software — that are largely out of your control.
My experience with programming, as an interaction designer, software developer, and in producing computational art and artefacts, has been largely hardware agnostic: focussed on making things using common technologies with online distribution. Vault is my first attempt at working in a physical space where factors such as power outages, auto-startup, and hardware switches matter to any great degree. This exhibition is touted as the ‘non-stop performing history of Circus Oz’, so it’s non-stoppiness matters, and the code that makes it non-stop has to not-stop. And someone has to write this code, even if it takes hours of frustration.
One of the things about circus is that they never tell you what is difficult and what is easy, what is real and what is fake, or what is risky and what is safe. What might look simple in our case often relies on a fragile collection of unstable hardware and software, internet connections and databases: messages from one part are sent over the internet, around the world, and back to a screen in the next room or (in one extreme case) mere metres away along a wall. It could all come crashing down at any moment. This makes the exhibition a code space, a physical space inseparable from the code that makes it operate.
The material that makes up what I have described is what I would call an interpretive code layer, imposed by us on the archive to draw out, highlight, or, as Ross Gibson might say, activate the archive in new ways. The archive is made of material too — performances, or videos of performances, or descriptions and metadata, or 1s and 0s, or hard drives (depending on your perspective, and what you plan to do with the stuff). The digital archive stores data, and makes it available for use, but code and computational hardware is required to activate it.
Our approach to this activation has been to eschew the allure of so-called ‘big data’ approaches to the archive. Instead of taking our data set and examining, analysing and visualising it in terms of its aggregate — as is the temptation — we decided to use the gallery space to represent the archive by showing its individual items, fragmented, and juxtaposed. The circus is made up of fragments, (whether circus acts, or tricks, or gestures, or sounds). And the archive is comprised of these fragments too, each one unique and important. Our performance in this space is an act of representation, revealing what was already ‘there’ in the data. What the digital material of the archive offers is an opportunity to play with juxtaposition and scale — to perform a new history of Circus Oz by re-composing elements of their history as recorded. Various works, such as the History Teller, the Wall of Wonders, or the Marathon of Marvels take the ‘same’ data, but computationally represent it in vastly different ways, some more fragmented than others.
I think it is telling that, despite the freedom to manipulate the digital, we haven’t compromised the integrity of the digital videos to any great degree. Low resolution GIF encoding brings a certain broken, glitchy, lo-fi quality to some elements (I see this as little more than an update to the badly-tracked VHS quality of the original recordings), but where the videos are shown they are still shown ‘intact’, if sometimes dramatically edited. Montage and juxtaposition of words and images create new work, but the performers are still there, on stage, recorded in the past and represented in the now. I think we still want to be deferential to the physical work that has come before us — afraid to re-encode, to de- code, to potentially destroy what makes these images those of Circus and not Some Other Thing.
So though we may present the ‘performing history’ with computationally complex systems, activating the archive by making new work out of old, we still care about the ‘truth’ in the fragments. Our code-space is an interpretive one, and I hope that by drawing attention to particular events, or particular phrases, or particular facts, or particular gestures, we are drawing attention to that which was — and is — made by real people, real bodies, in real space.