Originally published as: Roger B. Dannneberg, “Live Coding Using a Visual Pattern Composition Language,” in Proceedings of the 12th Biennial Symposium on Arts and Technology, March 4-6, Ammerman Center for Art & Technology, Connecticut College, 2010. Live Coding Using a Visual Pattern Composition Language Roger B. Dannenberg roger.dannenberg at cs.cmu.edu, www.cs.cmu.edu/~rbd, 412-268-3827 School of Computer Science Carnegie Mellon University Pittsburgh, PA 15213 Abstract. Live coding is a performance practice in which music is created by writing software during the performance. Performers face the difficult task of programming quickly and minimizing the amount of silence to achieve musical continuity. The Patterns visual programming language is an experimental system for live coding. Its graphical nature reduces the chance of programming errors that interfere with a performance. Patterns offers graphical editing to change parameters and modify programs on-the-fly so that compositions can be listened to while they are being developed. Patterns is based on the combination of pattern generators introduced in Common Music. Introduction Live coding is a music performance practice where music generation software is programmed in real time (Nilson, 2007). Often, the software development process itself is featured along with the resulting sound, usually by projecting the developer’s computer screen for the audience to see. One of the interesting and enjoyable aspects of live coding is that the audience can anticipate new sounds and changes in sounds by following the code development process. The composer also has the opportunity, by typing comments and simply by exposing the software structure, to communicate musical intensions directly to the audience as part of the performance. Many musicians like to read scores while listening to music. The score can reveal structures in music that are not immediately apparent upon listening, and the score gives the reader/listener some ability to look ahead and perhaps understand the music, not only in terms of what has been heard already, but in terms of where the music is going. Live coding brings yet another aspect to the perception of music, which is that deeper layers of structure in music can be understood from the program (if visible to the audience) and related to the sound. As a simple example, a loop statement that generates some randomized notes might cause the audience to think about seemingly unrelated random notes as repeated variations of just one underlying sound. This perception might not occur without knowledge of the program structure. Typically, live-coding performances are developed using a real-time system in which software can be modified incrementally, allowing for the continuous generation of sounds while the program is modified and extended. However, live coding has used a variety of languages including assembler, C, Perl (McLean, 2004), Lisp (Sorensen, 2005) and Python as well as more obvious choices of computer music languages such as Max MSP (Zicarelli, 1998), ChucK (Wang and Cook, 2004), and SuperCollider (Collins et al., 2003). One of the problems of live coding is that program development is usually a slow and tedious process. Like traditional composition with music notation, algorithmic composition or programmed music specification rarely takes place at real-time speeds. But this is exactly what is required in a live coding performance. It is often the case that live coding music suffers because the programmed specification must be accomplished quickly. Furthermore, the coder is more-or-less obligated to keep the audience’s interest from the beginning to the end of the performance. This means that taking even 10 minutes to carefully design some compelling sounds is not practical. The live coder can, in part, deal with thisLive Coding Using a Visual Pattern Composition Language Roger B. Dannenberg 2 problem by making the initial software development something of a prelude to the initial sound. Like a music prelude, the coder can create a visual, textual, and conceptual framework that is already evolving in time even before the “music” begins. When done well, the audience can marvel at the challenge and forgive the coder for a slow start. One the other hand, even the best live coding performances seem to proceed at a slow pace. Another problem is that unless the coder commits large amounts of code to memory or is a coding virtuoso, there are likely to be frustrating mistakes. In music, mistakes are often a matter of partial failure: a note is a bit out of tune or an entrance is a bit late. In software, mistakes are usually serious and must be corrected to move forward. Obvious mistakes that are easily corrected are merely annoying, but sometimes mistakes are subtle, leaving the coder to try repeatedly to understand and fix them while the audience wonders what is going on and the performance loses its momentum. After some experience with live coding, I became interested in better ways to express music as a form of program that could be developed quickly and with a relatively small chance of making significant programming errors. While part of the entertainment factor in live coding is watching music arise from very primitive foundations, it seems that another part of the enjoyment is relating the logic of the program to the sounds that emerge. In this sense, a higher-level language that can be understood by the audience might have some advantage over a low-level language where, in spite of the heroic efforts to coax out music, the audience is left staring at unintelligible text and having no clue how it relates to the sound. Toward this goal, I designed and developed a new graphical language system for live coding. The goals of the system are to provide an interesting visual interface that an audience can see and enjoy and the coder can manipulate easily, and to introduce a minimum of constraints and syntax rules to allow rapid manipulation of algorithmic music compositions without awkward debugging. The language is named Patterns. Model of Data and Computation The path I took combines pattern generators introduced in Rick Taube’s Common Music (Taube, 1997) with data-flow semantics and a graphical interface. Pattern generators take input parameters and generate a stream of values. For example, a cycle pattern generator takes a list of items, for example (a