Exploring photography and programming as systems of communication
Mar 24, 2015

I had two lines of practice that I thought were distinct. My visual work (mostly photography) was art, but I didn't consider my experiments with programming languages in that context.

The latter work began with my Velato language, which asks programmers to write their code as music.The Velato compiler reads each composition: the intervals between successive notes are translated into commands to do simple things such as print to the screen, or, given a long enough composition, perform complex algorithms. It wasn't research, since it had no potential for practical use, and it was too technical to feel like art—I thought of it simply as a project, an experiment in what music might be composed for such a system.

Halfway through my first year in the MFA program at ICP, I made the connection to theorists and artists such as John Cage, the Oulipo movement, Fluxus and Gutai, the early Conceptualists, and Bit Magazine-era algorists. Considering my work in the context of these experiments, I learned to clarify the essence of the piece and to explore how such a system would actually be used.

Cells from Daniel Temkin's Light Pattern machine.
Cells from Daniel Temkin's Light Pattern machine

This research led to a visual language, based on photographs. The key to the project was the connection between the camera and computer as apparatuses indifferent to the meaning of their content to us—for both photographs and text. Conceptual works such as John Hilliard's Camera Recording Its Own Condition (1971) had made this point about the camera itself. In Hilliard's piece, the camera photographs itself across the entire range of exposures, some of which obliterate itself as subject through over- and under-exposures. To the camera, each of these images is equally valid, regardless of whether anything is visible. I saw this as similar to the compiler (the tool which converts the code we write into machine instructions), which is only aware of denotation, of instructions. Nuance, affect, connotation, and color, the core of human communication, inevitably find their way into the code we write, yet have no meaning to the machine. In Light Pattern, these two ideas are tied together by using photographs as code. To write a Light Pattern program, one takes photos, following a formula of changes in color and exposure from one image to the next, which are then read by the machine.

My first experiment with the language involved photographing people. I designed a machine to take the photos for me, in order to take away any subjective choice or influence by the photographer. The machine was Arduino-based, controlling an early Canon EOS camera. A motor controlled colored gels connected to wood strips, passing them in front of the camera. It was a very fragile prototype, but it worked. I kept the machine set up in my studio space in Long Island City and let it run when classmates were in the space. This noisy machine would draw people to it out of curiosity. When a camera is pointed at us, we are not indifferent; we will perform for it or sit uncomfortably. Either way, these human reactions become the most visible elements of the code.

Daniel Temkin's Light Pattern machine prototype.
Daniel Temkin's Light Pattern machine prototype

This first experiment used visible human expressiveness while being photographed as a sort of analogy for human expression in code. My next experiment involved shooting the same program every day. In each resulting photo series, the patterns of exposures would become apparent through repetition. I decided to make Hello, World! programs (generally the first program one writes in a new language—it prints "Hello, World!" to the screen). In Light Pattern, this takes 51 photos to do. Instead of using the machine (which requires a power source), I would carry a camera and tripod with me and, each day between 11 am and 1 pm, shoot the 51 photos, wherever I happened to be. I shot close to noon because people usually avoid shooting then due to the heavy contrast. Usually, it results in details in the light or dark areas being less apparent, but it also meant I could shoot in a wide range of exposures and get at least some content in each—this is necessary for the program to work. The content of the images was immaterial, random, with as little meaning as possible (much like the "Hello, World!" string itself).

Each image, changing in color and exposure, would filter different parts of the scene, isolating different elements of color and detail. I called this approach Algorithmic Photography. The photo settings were determined by the algorithm I was constructing, but it was not executed here by an automated system: I was building the set of photos manually, in order to communicate with the machine. The results were shown in video form, with each photograph crawling across the screen to replace the previous one, with the number that transition translates to and its corresponding commands piling up to the right of the screen. Any narrative element to the sequence was incidental, whether they were of garbage swirling in a puddle at a suburban dump, or simply images of seaweed that become easier to identify as the exposures pass. I would sometimes fail at getting the correct exposure: it is difficult to shoot 51 photos with determined exposures and color correctly each time (the color came from holding gels or filters in front of the lens). The failures could be identified by their code, but were exhibited alongside successful programs: even if they did not write "Hello World!", they still were structured by the attempt to create that program.

While the Hello, World programs made the code element of Light Pattern more apparent, I next wanted to create work where the output of the code and the photographs that constructed it were more closely linked. I thought of Light Pattern as a rhizomatic exploration of code and photography. The result was the beginning of my "Unmaking" series. In their event scores, Fluxus artists blurred the performative with everyday life. George Maciunas, founder of Fluxus, singled out Brecht's score Exit as the most impersonal. The score, which has a single instruction, "Exit," could be and is performed by everyone without notice. To become aware of the score is only to re-situate that everyday occurrence into a performative context, thus reducing the aura of any particular art context (what would that mean when every exit is a performance?). This felt like a key idea to explore in Light Pattern, which reconsiders any JPEGfamily photos, vacation images, stock imageryas code, if it is simply presented in the correct order.

In my piece Three Lamp Events, I used three lamps—one with a red bulb, one with a green, and one with a blue—and took a series of photos with exposures that, when combined, created the right amount of red, green, and blue to write George Brecht's instructions for his "Three Lamp Events" score. The score tells us to turn on and off lamps; in Light Pattern, we turn on and off lamps in order to write the score, thus turning the performance back into its instructions. I followed this with a performance of Yoko Ono's "Fly" event (with the single instruction "fly"), which I interpreted as a camera, thrown in front of a light source, in order to capture its own shadow, repeatedly, until all three letters are drawn to the screen. I am currently working on an "Unmaking" piece of Sol LeWitt, where one of his wall drawings, through repeated exposures that highlight one color of his work at a time, recreate the instructions for his piece itself.

The updated version of the Light Pattern machine, using a filter wheel designed for a laser system.
The updated version of the Light Pattern machine, using a filter wheel designed for a laser system

Because Light Pattern is an open-ended system, it is never complete. Each program or set of programs I build for the language opens new questions, which I can choose to pursue in another project using this same set of rules. It also means I'm not the only one who can do make works within the language. My previous languages, Velato and Entropy, have been experimented with by other programmers—not only to build programs, but sometimes as other implementations of the language itself. In the case of Entropy—a language I designed around the idea of unstable data—a programmer I had no contact with coded a very well-written JavaScript version. This is the version I now often send to new developers, as it's easier to begin working with than my implementation.

This is what is great about building a system rather than a discrete artwork: it is an inherently collaborative form. In the art world, the intent of the original creator is sometimes confused with details of the original creator's implementation of that idea. In the open-source software world, it is the norm for others to contribute to a project —this perhaps comes closer to respecting the actual concept itself, as opposed to its specific manifestation. Bringing together approaches from these two worlds has led my experiments in systemic practice: the MFA-trained skills of clarifying ideas and learning to see how a work resonates, with the open-source approach to decentralized, less authorial practice.