There is a grid, and it is blank, just 81 squares arranged in nine rows and as many columns. Click on any single square, and it lights up: a cell has been activated, and it begins moving upward, toward the top of the grid. When the cell hits the wall, it rebounds, emitting a pinging sound at the moment of collision. The cell then travels down until it hits the opposing wall, again rebounding and pinging at once. Click on two squares side by side horizontally, and watch the resulting cells travel in unison visually, though they are pitched apart. Click on enough of these squares, and the resulting cells will collide with each other, triggering sideways motion and ushering in a new level of sonic and geometric complexity.
Yet for all the potential chaos, for all the unpredictable interactions, the resulting sound is what could widely be described as musical: tuneful, percussive, internally coherent.
This is Otomata, the grid-based generative music system, or audio-game, or sound-toy, developed by Batuhan Bozkurt, who is based in Istanbul, Turkey. A little more than a month ago Bozkurt announced the free tool’s existence on his earslap.com website. The rules, as he describes them, are simple:
Each alive cell has 4 states: Up, right, down, left. at each cycle, the cells move themselves in the direction of their internal states. If any cell encounters a wall, it triggers a pitched sound whose frequency is determined by the xy position of collision, and the cell reverses its direction. If a cell encounters another cell on its way, it turns itself clockwise.
The resulting wave of Internet-fed curiosity proved just as unpredictable as the sonic outcomes inherent in his creation. The Otomota site received more than a million page views in a matter of days. As of this writing, the above YouTube clip of Otomata in action has had more than 175,000 views. Coverage popped up not only on digital-music sites like createdigitalmusic.com (where Peter Kirn highlights Otomata’s social component, in which users share the result of their experiments), but also consumer-tech site like engadget.com. As a measure of the extent to which Otomata has helped popularize generative sound, note that the comments at Engadget are relatively free of the sort of snarky nay-saying that has been the reader response there to posts about sound art (witness, for an unfortunate contrast, a recent Engadget post about Switzerland-based Zimoun).
Contacted via email, Bozkurt agreed to be interviewed, and what follows is that conversation, lightly edited. He talks about the software-development fine-tuning that yielded Otomata, the promise and precursors of generative art, and some of the unlikely sources of his inspiration, notably the “hang” (“hang drum”), the steel instrument from which he derived Otomata’s tuning and sounds.
Inevitably, the discussion touches on John Conway’s Game of Life, the popular ur-application of cellular automata, in which simple rules yield complex patterning. Bozkurt is careful to distinguish between the shape-changing algorithms of Conway’s 1970 concoction, and the more straightforward collisions of his own creation.
The email format of the discussion proved fruitful, allowing us to pursue various tangents, and easily track back to the moment at which conversation diverged. We talked about how he utilizes generative tools in live performance, and about a possible aesthetic parallel between his programmed and composed musical output.
Bozkurt, who was born in Istanbul in 1983 and continues to live there, is especially eloquent about the way that the ever-changing nature of computer technology shapes his decision-making as an artist and as a software developer. In a manner of speaking, the chaotic realm of digital sound — as exemplified by diverging platforms such as Flash and HTML5, and browsers that have their own idiosyncratic standards — is itself a generative construct yielding unexpected delights.
Marc Weidenbaum: The rules that apply in this game, the way collisions alter the way sounds are triggered — were they the first set of rules that you experimented with, or did you develop them through trial and error?
Batuhan Bozkurt: I have experimented with cellular-automata systems a lot in the past. I always found them fascinating for a multitude of reasons, the most important one being that they included the most essential elements I tend to employ for creating generative art. They have clearly defined states, they use feedbacks (the system is fed back its previous state and generates a new state), they have well-defined rules, and as a result they have emergent behavior. I’ve been programming my own tools to make art for many years and I don’t always work with very simple systems. Working with cellular automata (CA) is like a recreational hobby for me. They are very simple to implement, use, and understand, yet they include almost all of the ingredients I care about.
So if we take my past interest in these types of systems into account, it is an evolutionary step for me. That said, the rules Otomata uses were derived without any type of experimentation whatsoever. The idea just popped into my mind just as I was drifting into sleep one day. Later I thought it wouldn’t work well, or it wouldn’t be interesting at all, but I implemented it anyways to see how it behaves. A few tweaks (not to the rules but to the way they generate sounds) and I liked the result. Actually this was the first time I experimented with such a system. I mean, all the CA systems I’ve worked with in the past relied on neighborhood rules (like in Conway’s Game of Life). Otomata is distinct in this sense (it only cares about collisions) and I’m not even sure if it can be classified as a CA system technically. Weidenbaum: How about the grid in Otomata? I imagine it wasn’t 9×9 to begin with. What tweaking led to its final dimensions?
Bozkurt: Dimensions of the grid needed tweaking. Instinctively, I built the first prototype with an even-sized grid. I think it was 8×8. Then I tried 10×10, 20×20 and similar grids. At that stage I didn’t have any ideas about how I would go for sonifying the emergent behavior. It was fun to watch but it also was slightly annoying in a way, and I tried to figure out where the problem was. Then it appeared to me that I tended to use edge cells for setting up initial states (an inherent bias we all have, I believe), and not having a middle row and column meant that active cells initialized from edges facing each other were not going to meet and interact with each other. To have symmetry and interaction, there had to be a middle row and a middle column, so I needed an odd-sized grid, so then I also experimented with them. They worked a lot better and it was a lot more fun to play with that way. The final decision of 9×9 was more or less arbitrary — I wanted to use a hang-drum scale and it had nine pitches, so that had an influence. It could have been 11×11 or 13×13, and I’m willing to make it dynamically settable in the future.
Weidenbaum: I am guessing the answer will be the latter, but tell me: was this software intended mostly as an experiment, or do you have strong feelings about the potential for generative composition?
Bozkurt: I do have very strong feelings about the potential of generative art in general. As computer is a multi-domain artistic instrument to me, I regard making software as a means of artistic expression. I’ve been programming computers using domain-specific languages (SuperCollider, Pure Data, Processing, etc.) for many years to make my own tools to create art. But I had no means to share what I was creating and using, with people outside a limited circle who were already familiar with the platforms I used. My long-held dream was to be able to share my creations similar to Otomata on the web without making people to download and install something to their computers. Until recently, the technology simply wasn’t there but now things are getting a lot better. I can elaborate on the technical issues that similar-minded people are facing if you want. I am willing to use this new potential and create and share similar creations with the world. In that regard, Otomata was the first in a chain of ideas that I was willing to share. The way it was received, though, was far far above my expectations and that makes me extremely happy about the future.
Weidenbaum: Explain to a general reader what you mean by “domain specific.”
Bozkurt: Computer programming is time-consuming and usually a confusing thing to do. When using general purpose tools (as opposed to domain specific tools), getting a single beep out of the computer is hard. And things get exponentially harder if you try to do more complicated things. Domain specific programming languages assume a specific programmer audience with goals limited in a particular domain (creating music, visuals, multimedia works etc.). They are built in a way to make life a lot easier for those very people. Some require no coding at all (e.g. Pure Data, Max/MSP), as artists without a programming background usually have an aversion to anything related to coding, so instead they employ the visual patching paradigm to create custom software. With domain specific tools, the idea is to make the learning curve gentler for the newcomer, and to hide technical details unrelated to the domain to aid flowing creative process for more advanced people.
Weidenbaum: Are there specific examples of generative art from the past that have inspired you?
Bozkurt: To this day, I still find enormous joy in [Steve Reich’s] early “Process Music” (see: columbia.edu) experiments. They don’t fit into the “generative art” definition of today, but they provide a strong foundation for a lot of things related to it. When faced with this question, I immediately think of the earlier works of 20th century that demonstrate the emergent nature of particular processes. I could point to phase music experiments of Steve Reich, “Poème Symphonique”of Ligeti, “In C”of Terry Riley, experiments exploiting the acoustics of spaces by Alvin Lucier. I particularly find the approach of Iannis Xenakis inspiring. I am always moved by the emotional qualities of his music despite his methodical approach of creating them.
I also regard the foundations of most baroque music as generative, especially the fugue form. It does not rely on computation of course but coming up with pieces with all that organic flow derived strictly from a single thematic statement leaves the exact same impression on me.
In the more current definition of generative art, most of the things that inspire me are visual works, actually. I think that is because they tend to be well polished and easily accessible. Jared Tarbell has a solid body of works on his complexification.net site, which I enjoy enormously. I can also point to the works of Mario Klingemann residing in his incubator.quasimondo.com.
I have also enjoyed many audio tools that have generativity in focus but they are less accessible and personal tools that are created in domain specific environments so it is hard to point at them. I’m pretty sure this will change in the very near future, I honestly expect an explosion on accessible generative audio tools.
Last but not least, I am deeply inspired by the demoscene (see: scene.org). I particularly enjoy the works by Farbrausch (see farb-rausch.de).
Weidenbaum: Could you explain a little more why you elected to do Otomata initially as a browser-based tool, rather than implementing it as an “app” in, say, iOS or Android?
Bozkurt: My primary aim was to to make my work fairly accessible. Otomata was not a result of a little experiment, but part of a bigger plan I had. From the time realtime cross-platform audio synthesis became possible inside web browsers, I knew I had to make use of it. I had been waiting for it for so long. It is easy to convince people to try something new; all it takes is a description catchy enough to make that person click on a link. So I spent some months programming a DSP library for this purpose. My plan was to make my work accessible through a web browser and work more on (make mobile versions, VST/AU plug-ins etc.) the ones that gained significant attention. I made Otomata public just to test the waters, actually, but the attention it brought caught me off guard. I got more than a million hits on my website in just a few days. Now I’m working on mobile/VST versions of it and trying to optimize my workflow for future projects.
Weidenbaum: Could you select a brief bit of Otomata code of which you’re particularly proud, and explain it to the reader?
Bozkurt: The mechanics behind Otomata is pretty simple, the logic is just a few lines of code and it basically recites “turn backwards if you encounter a wall and make a sound, turn clockwise if you bump into another cell” in a computer language, so I wouldn’t say I’m very proud of that code as much as I’m proud of the idea behind Otomata overall. But I’m very proud of the backing audio synthesis engine which I spent some months creating and it is quite big. I’m planning to open-source it in the near future.
Weidenbaum: Do you foresee yourself improving upon Otomata, or are you primarily interested in moving on to your next programming project?
Bozkurt: I will improve Otomata to some degree as a side project, but I’m eager to move onto future projects.
Weidenbaum: Are there other web-based generative-sound implementations, or apps for that matter, that you recommend?
Bozkurt: It might be surprising but I honestly can’t point to anything that inspiring. Web-based generative-sound is still at its infancy. Writing raw samples (as opposed to playing pre-recorded sounds) to sound card buffer has been around only since Adobe Flash 10. Before that I know that André Michelle (see: andre-michelle.com) was hacking his way through doing this with earlier versions of flash, and his lab page (lab.andre-michelle.com) has some stuff demonstrating the techniques though he seems more interested in bringing the desktop music production experience to the web. He was also behind the “Adobe, make some noise!” movement (see: make-some-noise.info). He has a generative web-tool/app called Pulsate (andre-michelle.com/pulsate), which I enjoyed.
Weidenbaum: Is there a programming or tech community in Istanbul of which you feel you are part?
Bozkurt: Nope. Also I’m not a very social person, unfortunately. It’s usually up to my fiancée to make sure I get to socialize just barely enough to function as a healthy human being. As a result, my interaction with relevant communities tends to be online and my home country is not very ripe when it comes to programming for art. So my interactions tends to be with people outside of Turkey. I am a (not very active) developer for the SuperCollider project (see: supercollider.sourceforge.net) and I try to fix/improve on things when I encounter them to the best of my ability. I am also an avid SuperCollider user of course, and am quite an evangelist at that.
Weidenbaum: Do you perform your music live at all, and if so what is your setup, if you have a standard setup?
Bozkurt: I perform live but very rarely. I am planning to do a lot of live performing in the future but I have other priorities for now. When I play live, I use my electric guitar plugged into computer, and custom software (almost always written in SuperCollider). I also use some MIDI controllers (foot controller, knob/slider stuff), nothing too complicated. I don’t like dealing with a lot of gear.
Weidenbaum: In your live setup, do you employ any generative processing, perhaps in SuperCollider?
Bozkurt: Of course, all the time. Actually I have very hard time putting events on a time grid into place by hand. Being forced to do that alienates me from what I’m trying to do. When I try to compose in more conventional methods, I always find myself asking myself questions such as: “Why am I putting this here? Why can’t this event be over there? Why am I using this particular pitch? Is it because it sounds better? How do I define ”˜good,’ anyways?” It is hard for me to get over all these; that was one of my most important frustrations regarding more conventional methods that led me to algorithmic composition. For me, it eliminates the anxiety of deciding the final temporal places for musical events, so I can function. Creating processes that produce events and sounds themselves in countless variations, instead of creating a single arrangement of events by some sort of intuition, feels natural and enjoyable to me. Also, I figured my artistic tendencies are driven by the urge of discovering new things and hunting for those serendipitous moments. So algorithmic/generative/procedural approaches are a good playground for surprising myself to no end. In live performances, I decide what tools I am going to use, plan a vague structure (that almost always gets abandoned on stage), but leave all the details for improvisation. I can handle failure and I love the thrill of performing with the unknown.
Weidenbaum: I sense a kind of collision aesthetic in some of the fixed recordings on your site, in particular in “Reminiscent.” Is there something about the aural effect of a collision that has particular appeal to you?
Bozkurt: That is an interesting observation, a pattern I hadn’t noticed before. Looking back at my recent works (not all of them are listed on my site) I can clearly see a similar influence now. For example last year I composed a 30-minute electronic piece for The Morning Line project (by TB-A21 Thyssen-Bornemisza Art Contemporary; see: tba21.org) and the main structural theme of that piece was gravity. Things dropping from a distance and making sounds and all that. And there are others I can think of. I might need to look into that, can’t see what is causing that tendency right now.
In a more general sense though, I enjoy reading and thinking about physics and astronomy a lot. I actually studied physics half a semester before dropping out and going full time with music. So I can see many influences of ideas derived from those sciences in majority of my works. My interest in making things collide and whatnot might come from my “interested in physics” part of my brain.
Weidenbaum: Have you ever used the Automaton effect from the company Audio Damage (see: audiodamage.com)? I’ve enjoyed using it, mostly to lend a bit of organized chaos to the processing of pre-existing tracks.
Bozkurt: Nope, never used it. I saw a CA sequencer implemented in Native Instruments Reaktor, though — called “newscool,”it was one of the factory instruments — and it was enjoyable because it had a novel logic behind it. It was a nicely designed instrument overall (see: youtube.com).
Weidenbaum: I don’t think we have actually discussed how you came up with the sounds you use in the software.
Bozkurt: My main instrument influence for Otomata was the Hang Drum. I tried to synthesize sounds close to a Hang Drum in terms of timbre. DSP and sound synthesis is still an expensive operation for web browsers (in terms of computer load), and it is cheap to synthesize such a sound realtime. It takes two to three sine wave generators, a noise source for the attack, and a little bit of filtering.
Weidenbaum: Did you consider ever putting in a random element as an option?
Bozkurt: I use randomization a lot, but only when it is called for. Otomata is deterministic instrument as far as its logic is concerned and I wanted to keep it that way. That said, there is some randomization in the sound synthesis stage. Probably most ears won’t notice, but each time you launch Otomata, the tuning is slightly different (“off”), and unique, just like it is with a physical/acoustic instrument.
Weidenbaum: Please tell me about yourself, your musical, educational, and professional background.
Bozkurt: I am a Turkish guy located, born, and raised in Istanbul. I am working toward my MA degree in Sound Engineering and Design, and I studied music in college. Computers and electric guitar are my main instruments. Programming computers started as a hobby when I was a little kid and I still write code daily, as that is the language of my main instrument, but I have no formal training in computer science or anything related to it. I am currently making a living by doing commission work and tutoring but I’m shifting my focus to creating accessible software for computer music and generative art that is meant to be used by people other than me basically.
Weidenbaum: Were your parents musical or technical? What did they do?
Bozkurt: I have only one musician relative in my whole extended family. My father used to work in a bank and my mother was a factory worker; but they are both technical people. My mother used to repair the machines in the factory even though it wasn’t her job; she is good at fixing things. My father was an electronics hobbyist and I have many memories from my childhood working with him. He is also an avid music listener so I was looking for and appreciating good music with him all the time.
Weidenbaum: Where in Istanbul do you live, and what is the neighborhood is like?
Bozkurt: I live in the intersection point where working class and lower middle class people meet. A bit noisy, but fairly safe environment. I don’t have friends living in my neighborhood. I’m a bit sticking out actually, people usually know each other here. I’m sure they are wondering what I’m all about.
Weidenbaum: You mentioned how the demoscene is inspiring to you. Could explain how?
Bozkurt: I especially enjoy the size limited demos where a group tries to fit many minutes of audio and visuals into a, say, 64KB executable. When programmers are limited in code size, they can’t use pre-built 3D models, baked visual textures, or pre-recorded audio samples/music to create a piece of work; they need to find procedural/algorithmic ways of creating that content. To make this happen, programmer/artist groups in the demoscene literally compete against each other to find beautiful algorithms that generate novel patterns (for logic and visuals) to build audiovisual experiences. This competition drives innovation so the demoscene becomes a natural habitat where beautiful algorithms emerge and evolve for procedural content creation. They also tend to employ extreme ends of the technology (either cutting edge, or completely obsolete). It’s amazing how arbitrary limitations (like binary size, processing power) nurture the creative process. It’s the art of compression. That said, I’ve seen many procedural approaches to visuals but yet to see any procedural audio in demos, and I keep wondering why it is not so commonplace. I would love to collaborate with some people to do that type of work. Hopefully in the future …
Weidenbaum: Early on in this conversation, you had said, “I can elaborate on the technical issues that similar-minded people are facing if you want.” If you’re still up for it, that would be great.
Bozkurt: Of course. This will be a bit long.
There are two different paradigms for programming computers to emit sounds (as far as programming APIs [“application programming interface”] are concerned). The first one only deals with using pre-recorded sounds (samples). If the platform or the programming library limits the programmer to this approach, that means the programmer is only able to load pre-recorded samples to memory and trigger their playback when desired. In this paradigm, basic support for panning and adjusting the gain for the output is usually expected.
A platform or programming API that claims to have multimedia support is expected to at least support this kind of operation. The good thing about this approach is that it is easy for the vendors to implement across all platforms. It is very high level. You have these sounds, and you want to play them back at specific times. Load sound. Trigger playback whenever you want. All the details are hidden.
The bad thing about this is that you can’t synthesize new sounds. You can’t create new sounds from scratch, you can’t influence the output or run it through effects you programmed. You can’t get sound input from microphone for example, transform it to something new, and play it back that way. You need to have access to what we call “input/output buffer” of the operating system sound backend; you need to be able to read from and write values directly into this buffer.
The second paradigm deals exactly with this. The aim is to expose this input/output buffer to the programmer so that the programmer can compute values by using DSP (digital signal processing) methods and write these values to sound card’s output buffer to make them audible. With this method, if you want to hear a sine wave, you just compute a sine wave realtime, write these values to output buffer and it goes through the layers of the operating system that eventually makes it audible through connected speakers.
Now if we return to the issue with web browsers, up until the HTML5 standard, there was no direct and/or standardized support for either of these paradigms. You could of course, make native software for certain operating systems, and demand users to download it to use it, but it is hard to convince people to do so. Another option is to use a browser plug-in which is capable of doing this type of thing, but it still requires the users to download and install a software to their computers which is not going to happen most of the time. Without the support of plug-ins, the web browsers were essentially silent.
Fortunately, there is this browser plug-in called Adobe Flash, which is already installed in almost all desktop computers. Up until version 10, it supported the first paradigm of sound generation across all major platforms. That meant you were able to use pre-recorded samples and trigger their playback, but there was no access to sound output buffer, so no sound synthesis was possible. The feature was not heavily demanded anyways, as Flash was mainly used for creating simple, addictive online games and game programmers rarely needed that kind of thing. With Flash Player version 10, Adobe decided to include support for the second paradigm, which took some additional time to get it right afterwards. That meant cross-platform sound synthesis inside web browsers was now possible without the need of any additional software besides Flash. This is a very recent development, and it is a solution to a problem we were facing. Otomata uses this method generate its sounds.
Then HTML5 standard came along. HTML5 supports the “audio” tag, which meant the first paradigm of sound generation inside HTML5-capable web browsers (without relying on any third-party plug-in, such as Adobe Flash) became possible. You can load pre-recorded sounds and play them back at specific times. But no sound synthesis, no fun.
The most recent development came with Mozilla Firefox 4, which is just a few months old as of now. Firefox 4 has a new but non-standard sound API which enables the programmer to synthesize sounds inside the browser without relying to a third-party plug-in. The feature is not inside the HTML5 standard, and it is up to the decision of other browser vendors to implement it. If a programmer uses this method now, it will only work with Firefox 4. We are hoping that this will be adopted across other browsers in the future.
Weidenbaum: Do you feel there is an earlier tradition that generative work is rooted in? You mention Xenakis and others of his era, but how about from the pre-recording era?
Bozkurt: I wouldn’t call it a tradition but there certainly are roots from the pre-recording era. I can point to Musikalisches Würfelspiel, the musical dice game of W. A. Mozart, a “method” where he supposedly used randomization with dices to stitch together short fragments of music, each composed exclusively for this purpose.
Going further back, there is this instrument called Aeolian Harp which is designed to be played by the wind. Initially used by ancient Greeks, it is named after the ancient Greek god of the wind, Aeolus. It is a stringed generative instrument where the blowing wind makes the tuned strings resonate creating rising and falling harmonies.
Going even further back, there are these “wind chimes,” probably coming from prehistoric times. Wind chimes are also generative instruments played by the wind. As far as I know, there is a big culture and tradition behind different types of this beautiful instrument.
More on Batuhan Bozkurt and Otomata at earslap.com, twitter.com/earslap, facebook.com/batuhanbozkurt, vimeo.com/batuhan, youtube.com/noissez, and github.com/batuhan.
great interview marc.
here’s an early demo of a monome version of otomata:
http://vimeo.com/23782810
Great article, Marc. Some familiar names and ideas, others new ones to follow up.