themanymeaningsof livecoding

The Many Meanings ofLive Coding

Andrew Sorensen,∗ Ben Swift,† andAlistair Riddell∗∗Institute for Future EnvironmentsQueensland University of TechnologyP Block, Level 8, P803-12, Gardens Point Campus2 George Street, Brisbane, 4001, QLD, [email protected]†School of Computer ScienceComputer Science and Information TechnologyBuilding (108)Australian National UniversityCanberra, ACT 0200, [email protected]∗Photography and Media Arts, School of ArtAustralian National UniversityCanberra, ACT 0200, [email protected]

Abstract: The ten-year anniversary of TOPLAP presents a unique opportunity for reflection and introspection. In thisessay we ask the question, what is the meaning of live coding? Our goal is not to answer this question, in absoluteterms, but rather to attempt to unpack some of live coding’s many meanings. Our hope is that by exploring some of theformal, embodied, and cultural meanings surrounding live-coding practice, we may help to stimulate a conversationthat will resonate within the live-coding community for the next ten years.

Musical meaning is predicated on communication,but communication does not entail meaning.Ultimately, for any communication of musicalmeaning to take place between a composer and anaudience, some shared interpretation is required, asnoted by Benjamin Boretz:

Thus the salient characteristic of an art entitymay, most generally, be considered to be its“coherence”; and the extent of its coherence,and hence of its particularity as a work ofart, may be considered to reside in the degreeof determinate complexity exhibited in theordered structure of subentities of which it is aresultant (Boretz 1970, p. 543).

Live coding (Collins et al. 2003; Wang andCook 2004) is a performance practice in whichmeaning exists on a number of different lev-els. First, meaning is inherent in the formalsystem that defines the programming languageinterface used for live coding. This meaning isknown as the program-process semantics (Smith

Computer Music Journal, 38:1, pp. 65–76, Spring 2014doi:10.1162/COMJ a 00230c⃝ 2014 Massachusetts Institute of Technology.

1996). Second, meaning is conveyed through therun-time computational processes set in actionby the live coder’s manipulation of code. This isthe process-task semantics (Smith 1996). Finally,live coding’s cyber-physical relationship with thephysical environment results in perturbations inthe world (Sorensen and Gardner 2010). Theseperturbations result in embodied meaning.

Meaning in a live-coding context is thereforemultifaceted—a complex interplay of symbolic,computational, and embodied meaning. Furthercomplicating these relationships is the fact thatthey are shared between a live-coding practitionerand an audience, each of whose relationship withthe “meanings” of live coding will be unique.

In this article, we attempt to unpack some oflive coding’s many meanings, paying particularattention to the formal semantics which are soprominent in live-coding practice, with its com-mitment to the display of source code and theimportance of algorithms. We approach this ques-tion largely from a compositional perspective byinvestigating the structural function of form. Weacknowledge that ideas of meaning in music (andindeed in the arts more generally) have been widelydiscussed elsewhere (Meyer 1956; Boretz 1970;

Sorensen et al. 65

Goodman 1976; Cross and Tolbert 2009). We alsobelieve, however, that live coding offers a freshchallenge to the interrelationships of meaning informal systems and musical composition. To explorethese ideas we expand on the work of our colleagues(Rohrhuber et al. 2007; Rohrhuber and de Campo2009; McLean and Wiggins 2010; Magnusson 2011a)in the hope of encouraging further discussion of livecoding’s many meanings.

Musical Formalism

A core concern of the musical composer is managingcomplexity. Musical form, at all levels, requires adelicate balance of coherence and novelty. In orderto tame this musical complexity, some composershave turned to formal methods. The desire to imposeorder on the musical chaos of the times has foundvoice from antiquity to the present day (Loy 1989;Essl 2007; Edwards 2011). For instance, JohannJoseph Fux, writing in 1725, objected:

at this time when music has become almostarbitrary and composers refuse to be boundby any rules and principles, detesting the veryname of school and law like death itself (Fux1965, p. 17).

Order, or coherence, in music is multifaceted. Oneimportant distinction in this regard is the distinctionbetween structural and cultural coherence. Thatstructural coherence in music would be amenableto formal processes is largely self evident, formand structure being almost synonyms from acompositional perspective. Cultural coherence,on the other hand, appears to be considerablymore difficult to formalize, and is perhaps besttackled “with that particular kind of explorationthat systematically extends perception; a kind ofexploration called ‘play’ ” (David Keane, quoted inEmmerson 1986, p. 111).

Live coding meets both structural and cultural cri-teria by supporting structural development throughformal methods, at the same time supporting thesystematic extension of perception through play.For the live coder, the digital computer supports theconstruction of sonic micro-worlds—creative spaces

that support an unprecedented spectrum of sonicpossibilities. To fully realize the power of thesemost flexible of machines the live coder must workwithin the framework of formal systems.

Formal systems often play a functional role inmusical composition and performance as accompa-nists, antagonists, muses, and even conductors, butare usually heavily directed by a human performer(or performers) working through some form of non-formal interface—a keyboard, joystick, monome,microphone, or similar.

In live coding the performance is also heavilydirected by a human performer (the live coder), butin this case the interface is, itself, a formal system.What distinguishes live coding from other formalapproaches to music is that the formal systemunder consideration can be modified on-the-fly by ahuman operator. In most traditional formal systemscontexts (e.g., GenJam, cf. Biles 2007) the rules andaxioms are unalterable, once the system is definedit cannot be altered in playback. Live coding breaksfrom this rigidity by supporting a human composerwho operates “above-the-loop,” in that live codingallows for the run-time modification of the system’saxioms and rules. By incorporating a formal languageinterface into a real-time system composed of bothsensors and actuators, live coding enables composersto modify automatic formal systems designed formusic production, and to do so in real time, at runtime.

Token Meaning and Embodied Meaning

Although many computer music composers arecomfortable with formal languages (particularlycomputer programming languages) the relationshipbetween these formal systems and the musicalabstractions which are built upon them are complexand often unclear.

John Haugeland (1981) describes the computer’scentral processing unit as an automatic formalsystem (AFS) that inputs, stores, manipulates, andoutputs meaningless tokens. These tokens arenon-symbolic (in a Fregian sense; see Eco 1979)in that they lack referents. An algorithm—a setof instructions or “recipe” for manipulating these

66 Computer Music Journal

tokens—is a formal system that is defined in termsof manipulations of these tokens, a representationwithout any external reference.

This is not to suggest that these meaninglesstokens are meaningless internally. Within theformal system tokens must have a consistentsemantics to support interpretation by the AFS. Inother words, they must have a syntactical meaning.What makes an AFS such a powerful tool is thatthese internal semantic engines can be layered ontop of one another, operating at increasingly highlevels of abstraction. This allows programmers tocreate new conceptual worlds that obey laws thatare independent of the platforms on which they arebuilt.

This suggests that semantics can operate at manydifferent levels, but raises the important question ofhow meaning crosses semantic borders. According toCharles Morris (1938), semiotics be can broken intothree fields: pragmatics (the relationship betweensigns and interpreters), semantics (the relationof signs to objects), and syntactics (the relationsof signs to one another). The distinction betweenthese three fields can be expressed in terms of therelationship between the semantic levels they areconcerned with:

Syntactics becomes relations within one level,whatever the level is; semantics becomesrelationships between two adjacent levels; andpragmatics presumably becomes the relationsleading outside of the level scheme, whatever“outside” is (Zemanek 1966, p. 140).

Textual programming languages gain leveragefrom natural languages. It is therefore understand-able that tokens commonly used in programminglanguages would have culturally rich symbolic deno-tations. The existence of meaning at different levelscan get the programmer into trouble, however, andthe degree to which those denotations are syntactic,semantic, pragmatic, or a mixture of all three is of-ten vague. A frog variable is a syntactic element inthe C programming language and conveys meaningfor the interpreter (compiler) of the C language. Thefrog variable also conveys semantic meaning forthe human programmer, denoting a frog—as a sense,concept, or type. That these two meanings coexist

Figure 1. A simple ixi langcode example, playing thefour beat pattern: kick,snare, kick, snare.

is interesting within a computational context, be-cause the strong “cultural unit” (Eco 1979), whichhelps to form the frog concept, is only valid so longas a pragmatic relationship with the concept remainsvalid. In other words, if the programmer uses frogas the name of a variable representing an animatedcharacter, and a robot (rather than a frog) is drawnon the screen, the linguistic identity of the symbolfrog is challenged, and a new sign production takesplace.

The “indexicality” of this sign relation, betweenthe frog and the computationally driven robotanimation, points to a powerful attribute of livecoding—its “cyber-physicality.” By this we meanthat symbols in the formal system have both a“computer world” (syntactic) meaning and a “realworld” (pragmatic) meaning through their outputon the screen. In live coding, these two meaningsare open to consideration and modification by theprogrammer, but not necessarily in a way whichkeeps these meanings “in sync” in all senses.

Consider the token random(). Within the context(interpretation) of sound, meaning can be ascribed tothis symbol, forming a mental conception of whitenoise. The context of the interpretation is critical:in other contexts (chaos theory, for instance) whererandom() may produce an altogether differentmental image. What makes live coding particularlyinteresting is that this mapping can be physicalas well as conceptual. The symbol random(), inthe context of live coding, can reify the conceptof white noise into a physical manifestation ofwhite noise sounding in the environment. In otherwords, live coding can make sign production anembodied experience, giving random() a real-timeindexical relationship to white noise in the physicalenvironment.

In the following, we start to unpack some of theseideas in a more practical context, starting with thevery simple ixi lang (Magnusson 2011b) example inFigure 1.

The tokens in this example (drums, ->, |, k,and s) are all valid symbols in the AFS specified byixi lang’s creator, Thor Magnusson. These tokens

Sorensen et al. 67

Figure 2. An obfuscatedversion of the pattern inFigure 1, written in thegnal ixi language.

have grammatical but not lexical meaning to ixilang; there is no need for the kick and snare drumsamples to be represented by the symbols k ands, they could just as easily be j and z. Grammati-cally, the meaning would remain the same. Semanti-cally, however, given the context of this article, thesymbol drums, and the use of ixi lang, it seems rea-sonable to ascribe the concepts of kick to k and snareto s. The kick k and snare s symbols convey mean-ing in the “conceptual musical world” of rhythm,timbre, and musical structure (repetition), which canbe understood by looking at the token string alone.

Ultimately, the composer has a very humanability to attribute musical meaning to the symbolsk and s as a kick drum and a snare drum, space assilence, | as a loop boundary, and position as anindication of temporal structure. This assignment ofmeaning exists outside of the formal semantics of theixi lang system. There is a distinction between the(human) musical meaning of a set of tokens and themeaning of those tokens within the formal system inwhich they are a well-formed string. These differenttypes of meaning are independent, as an examplefrom gnal ixi (ixi lang’s bizarro-world cousin)demonstrates. We doubt that anyone would grasp themusical meaning of the tokens in Figure 2 withoutreference to the previous (see Figure 1) example.

And yet, upon executing the expression in Figure 2in gnal ixi, the live coder will immediately hear themusical result as a repeating kick-snare-kick-snare four-beat pattern. What this demonstrates isthe difference between a static statement of formalsymbolic meaning and the idea of a statement “beingmeaningful.” This is significant as it suggests thatlive coding’s “liveness” provides an active, dynamic,and potentially physical “meaning” that is otherwisemissing from a static symbolic interpretation of thesystem. Embodied meaning.

These two examples (Figures 1 and 2) demonstratethat “meaning” can happen through a semanticinterpretation of tokens by a human interpreteror through the mechanical transduction of formaltokens into the physical environment. In the firstexample, musical information is conveyed via

Figure 3. Another ixi langexample, with themeaning of the symbolschanged from Figure 1.

tokens that are interpreted directly by both the livecoder and the audience. In the second example,musical information is conveyed only through ahierarchical nesting of abstraction layers—tokensare interpreted by ixi lang, turned into differenttokens which are interpreted by SuperCollider(which ixi lang uses for audio signal processing),turned into different (signal-level) tokens to beinterpreted by a digital-to-analog converter (DAC),transduced from electrical energy into magneticenergy, and pushed out into the world as pressurewaves. The difference here is analogous to thedifference between reading a score and listening toan orchestra.

Both of these approaches convey meaning, butnot the same meaning. A semantic meaning can beformally correct and yet represent an ambiguous, orfalse, relationship to the world.

The variation in Figure 3 also results in a kick-snare-kick-snare sonic result, although in thisexample s signifies kick and k signifies snare. Thisobvious but important problem is described byEco (1979) as the “referential fallacy.” A formalsystem can have a valid semiotic function and yetbe false in the real world. This is of course true inlive coding systems, as with other formal systems.Live coding, however, with its real-time relationshipwith the physical environment, can support the livecoder in more readily resolving ambiguities betweena multiplicity of sign systems. This is a usefulconsequence of the “liveness” of live coding.

Formal Structures and Musical Hierarchies

The appeal of a strong musical semantics in thetoken system is obvious. Musicians who are unfa-miliar with programming languages can intuitivelygrasp what the tokens in the source code mean,as well as what changes to the source would benecessary to achieve desired changes to the mu-sical output. There is, however, an inherent costto building these higher-level “conceptual mu-sical worlds”—that a generality inherent in the


Figure 4. Literal numericvalues representing a (very“lo-fi”) sine wave.

Figure 4

Figure 5. A function thatuses the cos function togenerate a pure sine toneas audio output.

Figure 5

manipulation of “meaningless” symbols gives wayto a structured hierarchy imbued with meaning.Consider a contrived ixi lang sine wave designed asa signal-rate operation, as shown in Figure 4.

It is clear that specifying waveforms in this directpattern-language formalism is unwieldy, perhapsimpossibly so. From a perspective of formal systems,the tokens in this ixi example must be literal values,although what these tokens mean musically candiffer between different modes of the language—thisexample would be a signal mode, in addition to themelodic, percussive, and concrete modes currentlysupported by ixi lang. The approach taken by ixi langprivileges token semantics that are information-richfrom a musical perspective (such as pitch numbers orsample names) rather than tokens that are musicallyinformation-poor (such as the raw audio samplesoffered for interpolation in this example).

It is worth noting that with an appropriate hiddeninterpolation layer, this example may actually getquite close to the desired (sine wave) result—an ixipattern language for signals. There are, nevertheless,certainly representations that are more economicaland that describe the real-world phenomenon ofsound more generally.

It is worth considering that, where computerscience gains leverage through formal abstraction,engineering gains intellectual leverage throughmathematical modeling. This allows engineers totame an unruly reality, but it does not providethe explicit interface or conceptual world thatabstractions from computer science provide. Inother words, the purity of mathematics, with itsunintentional stance (Dennett 1989), divorces itfrom the type of semantic entailment that higher-level computational abstractions may invoke. Thevalue, then, of an unintentional stance is to lessen

(although never to remove) the chance of beingcaught up in a referential fallacy.

Let us briefly consider the implications of thisfor formal systems in the domain of sound andmusic. At the signal level, computer hardwareperipherals operate with numbers—for our presentdiscussion, we will assume floating-point numbers.In the Extempore code example in Figure 5, thedsp function is called directly from the DAC to“compute” a real-time waveform on a sample-by-sample basis. (More information about Extemporeand its programming language, XTLang, can be foundonline at extempore.moso.com.au.) We anticipatethat most readers will have an intuition about themusical structure of this code example—a 440-Hz(concert A pitch) sine tone. Now consider the codeexample in Figure 6.

Musically, the example in Figure 6 represents thesame kick-snare-kick-snare pattern as the ixi langexample in Figure 1, with the sinusoid oscillatingbetween the general MIDI “drum” numbers 36 (kick)and 38 (snare). What is interesting about this simpleexample is the degree to which an intentionalrepresentation (that of a signal-level sinusoid)almost forces itself upon those who already possessan appropriate system of interpretation. These twoexamples help to demonstrate that it is not domainknowledge of the mathematical cosine function,nor of Extempore’s XTLang programming language;instead it is a common domain understandingof the cosine’s usage in signal processing that givesthe first example a clearer musical meaning thanthe comparatively unusual usage of a cosine forflip-flopping between two MIDI values. From theformal position of syntactically valid XTLang tokenstrings, there is virtually no difference between thetwo.

Sorensen et al. 69

Figure 6. Another use ofthe cos function, but thistime in a sequencing role.

These simple examples have shown the relation-ship (at times complicated) between the differenttypes of meaning the composer is dealing with inusing formal systems for musical expression. Onesurprising point is the fact that, although a musicallegibility (a lexical semantics) in token strings offerssome benefits, in live coding this relationship is lessnecessary, because musical meaning can be derivedthrough the algorithm’s execution and realizationin the world. Having the live coder present inthe loop connects the token system to its embod-ied musical result and allows for fuller reflectionon the current state of the musical system. Thisallows the token system itself to be less stronglycoupled to the musical domain it seeks to represent,which provides other benefits to the live coder, aswe shall attempt to articulate in the next section.

Meaningless Tokens Are Powerful Tokens

We take the idea of a sound object (by which wemean the commonsense definition as the “lowest-level component” or “fundamental building block”of a musical composition) as a good starting pointfor a musical exploration of the semantic issuesdiscussed in the previous section. The idea ofan atomic sound object, having a fixed numberof discrete and highly quantized parameters, islargely redundant to the modern computationalcomposer. Instead, the sound object is unstableand composable, and this shifting identity is nowa central part of computer music practice. Thelive coder is free to choose which attributes definethe sound object, what their capacities are, andwhether these attributes are stable or unstable overtime.

In Figure 7, we deliberately conflate elementsof what would usually be considered to belong to“discrete event” versus “signal level” abstractions.As in the proceeding dsp example (Figure 5), wetake the DAC’s floating-point representation asour symbol “floor.” We include comments in thisexample for the reader’s benefit, although thesewould not usually be present in a real live codingcontext.

This brief Extempore example (Figure 7) shows acomplete, run-time compiled, on-the-fly modifiable“waveform generator.” A small, self-contained,musical piece, it includes pitch, dynamic, timing,and spectral dimensions. As with the earlier dspfunction, caprice is called on a sample-by-samplebasis in order to directly calculate a waveform.

The caprice plays “notes” of stable pitch andconstant volume at a rate of 4 Hz. It does thisnot through any built-in concept of a note, butby performing a modulo check on the raw timeindex, a counter that increments once per audiosample (at 44.1 kHz). If this check returns zero, thecode (non-deterministically) changes the values ofthe local state variables pitch and volume. In thelatter part of the function, these values are used(along with a trivial implementation of the Karplus-Strong plucked string algorithm) to generate theaudio signal.

Our purpose here is to highlight the generalityof specification afforded by working directly withthe symbol system’s floating-point “floor.” Thereare no explicit notes, unit-generators, schedulers, orany other sound- or music-related abstractions—thefunction simply returns the raw digital values thatmake up the audio waveform. What makes theexample interesting is the high degree of musicalinformation conveyed with little to no higher-order


Figure 7. A small,self-contained capricewritten in Extempore’sXTLang. The operatorsaset! and aref are arrayoperators for setting and

referring to values inarrays. By convention, alloperators that changevalues in place end withan exclamationpoint (!).

Figure 7

Figure 8. Capriceabstracted to multiplepolymorphic parts.

Figure 8

musical abstractions (although our intention is stillhinted at in our choice of symbol names such aspitch and time).

It is also worth noting the imperative nature ofthis code. This addresses two very real issues forlive coders. We suggest that imperative code allowsaudiences, as well as live coders, to gain a greaterinsight into the operation of the algorithms beingdeveloped. Also, by working at “ground level,” thelive coder is presented with considerably greaterflexibility when exploring new algorithms.

We are not arguing against abstraction, of course.Consider the simple change outlined in Figure 8. Byabstracting caprice into a higher order functionwe can trivially combine any number of polyphoniccaprice parts. We also took the opportunity tointroduce inter-onset times for each part.

It is in this easy switching between levels of ab-straction, hoisting the tokens of the formal languageup and down the ladder of musical meaning as re-quired, that we see the true power of live coding in aformal systems context. As an example, Extempore

Sorensen et al. 71

is fully committed to the idea of token generalityby making the whole application stack availablefor run-time modification. For some perspective onthe scope of this run-time modifiability, Extem-pore’s compiler, including the very semantics of thelanguage, is available for run-time modification.

What this level of run-time reconfiguration meansin practice is that composers are free to peek andpoke their way around the whole audio stack, at runtime—replacing, extending, or deleting the audioinfrastructure as they see fit.

Breaking Open the Black Box

From a composer’s perspective, the desire to createabstractions is understandable, since music ex-hibits structure at so many different compositionallayers.

Since musical structures are architectonic, aparticular sound stimulus which was consideredto be a sound term or musical gesture on onearchitectonic level will, when considered aspart of a larger more extended sound term, nolonger function or be understood as a soundterm in its own right. In other words, the soundstimulus which was formerly a sound term canalso be viewed as a part of a larger structure inwhich it does not form independent probabilityrelations with other sound terms. In short, thesame sound stimulus may be a sound termon one architectonic level and not on another(Meyer 1956, p. 47).

Constructing high-level musical systems, in theform of algorithms that work on representationsat music-theoretic levels (scale modes, beat-basedmeter, diatonic harmony, etc.), does seem like anappealing use of an AFS from a compositionalstandpoint. As Gareth Loy points out, however:

Given a method or a rule, what is usuallydeemed compositionally interesting is to followit as far as to establish a sense of inertia, orexpectancy, and then to veer off in some waythat is unexpected, but still somehow related towhat has gone before (Loy 1989, p. 298).

Figure 9. An Extemporefunction that plays anAlberti bass as it movesthrough a circle of fifths.

High-level formal systems for composition mayeasily fall victim to the “iceberg effect,” with topsvisible above the water and large, unwieldy internalslying unseen below the surface. The common prob-lem is that high-level musical algorithms tend to beeither overly coherent or overly inventive—whereasit is not the aggregate of perceived coherence, butrather a distribution of coherence and inventionthrough time, that is important for musical mean-ing (Meyer 1956). Coherence, within the contextof music, is not simply a mathematical property,but a function of shared cultural and social val-ues. Consider the code snippet in Figure 9 (againin Extempore) of an Alberti bass line as it movesharmonically through a circle of fifths, starting withthe tonic.

The alberti-arpeggiate and circle-of-fifths-next-root functions (which are part ofa fictional high-level composition library) providethe arpeggiation and root movement informationrespectively, freeing the composer from the need toexplicitly define these processes in their code.

Now consider another code snippet that producesthe exact same musical result, but that prefersbasic mathematical functions and programminglanguage built-ins instead of higher-level musicalabstractions. As discussed in the previous section,the flexibility in the musical meaning of the tokensin the source code allows easy switching betweenthese different levels of abstraction.

In Figure 10, root represents the scale degree(using a 0-based indexing scheme, so 0 for the tonic,4 for the dominant, etc.). The alberti-bass-2function is called every half a beat (every eighth


Figure 10. Another versionof the Alberti bassfunction, this time usinglower-level mathematicaloperations rather thanhigh-level “musiccomposition” abstractions.

note), and the exact pitch to play is determined bythe current root plus an offset (calculated using acase statement) to perform the arpeggiation. Thething to note about this example is that althoughthere is some musical domain knowledge encodedinto (for instance) the scale list, the manipulationof the tokens is largely performed through basicmathematics. There is no domain knowledgehidden behind the tokens, no perform-complex-musical-transformation function hiding itsinternals.

In some senses, the first version (Figure 9) is moretransparent. The musically savvy observer standsa good chance at guessing what the alberti-arpeggiate and circle-of-fifths-next-rootfunctions do, and can therefore figure out what theoverall sound is going to be. Again, this is similarto our ixi lang example from before, in which thepattern language version was more meaningfulwhen considered purely as a string of tokens.

The live coders, however, are not simply appre-ciating the code as a string of tokens. They are lis-

tening, evaluating, and considering their next move.This is where the generality of the alberti-bass-2 in Figure 10 provides a benefit: The live coder cantweak the case statement to change the arpeggiationpattern, or edit the scale variable to use a differentmode, or alter the harmonic movement from astraight circle of fifths to something more complex.In the first alberti-bass example, in contrast, thevery tokens that allow the composer to easily guesswhat the code accomplishes also conspire to makeit difficult to get it to do anything else. Withoutthe ability to change the alberti-arpeggiatefunction (as would be the case if it were part of amonolithic formal composition system), live codersare limited in the changes that they can make.

In our own live-coding practice we have foundthis second approach to be more fruitful. It is a strat-egy that live coding is relatively unique in affording:the ability to peer inside and manipulate the formalsystem while it is running, and the ability to hearand judge the results of these manipulations instan-taneously. Whereas offline algorithmic composers

Sorensen et al. 73

must wait to hear how changes to their system arebehaving, live coders are able to hear whether theirsystem is working well (or not) much earlier, andare, therefore, able to apply corrective actions in away which we have found to be extremely fertilefrom a creative standpoint.

Given the obvious temporal constraints imposedon the live coder, it may seem counterintuitiveto promote this lower-level structural approach. Itpromotes a generality, however, that allows the livecoder to operate with a smaller subset of operatorswithout sacrificing utility.

It is through a series of structural choices (thechoice of symbolic floor, a flatter or a more hierar-chical structure) that an ontological commitment ismade for a given performance. That these choicesare essential to defining the character of a particularperformance seems uncontroversial in the case ofan improvisational practice like live coding. We arealso suggesting, however, that this ontological com-mitment forms the basis of all musical composition.One ramification of this is that each individualcomputational work is inherently dependent on itsown unique ontological commitments.

On Intention and Understanding

We have spent some time in this article describinga triumvirate of musical meaning including thesymbol (code), the referent (sound), and the inter-preter (both listener and machine). That musicalmeaning can be expressed as a variable combinationof these constituent parts is of some interest to thelive coding community whose mantra is that “codeshould be seen as well as heard” (The Lubeck 04Manifesto, Ward et al. 2004).

Audiences believe in the logic and purposefulnessof the composer and his or her intentions. As LeonardMeyer points out, “Though seeming accident is adelight, we believe that real accident is foreign togood art” (Meyer 1956, p. 74).

The variability of relationships between a par-ticular live-coding performance’s meanings are areflection of real, objective cultural values, onesthat express themselves in the form of a musical

style, community, or movement. To again quotefrom Meyer:

Musical meaning and significance, like otherkinds of significant gestures and symbols, ariseout of and presuppose the social processesof experience which constitute the musicaluniverses of discourse (Meyer 1956, p. 60).

It is clear, however, that musical intention andmusical understanding do not form a fixed and con-stant relationship. Where art is at its most powerfulis in the margins—the space between total under-standing and complete intention. Nevertheless,there must always be enough shared understandingfor communication to remain possible. It is in find-ing the correct balance between norms and deviantsthat artists struggle. For Meyer, musical meaning isa product of these expectations.

The ability to balance the norms and deviantsrequired to communicate a meaningful musicalmessage has proved to be problematic for purelyformal computational systems. We believe that bygiving the responsibility of higher-level structuralcoherence (through the orchestration of run-timeprocesses) to the live coder, human perceptionand intuition can be brought to bear on what isultimately a cultural and inherently non-linearproblem. The live coder is able then to choosea meaningful pathway between social norms anddeviants, and—most importantly—to chart this pathanew for each and every performance.

While the meaning of a musical work as awhole, as a single sound term, is not simply thesum of the meanings of its parts, neither is theentire meaning of the work solely that of itshighest architectonic level. The lower levels areboth means to an end and ends in themselves.The entire meaning of a work, as distinguishedfrom the meaning of the work as a single soundterm, includes both the meanings of the severalparts and the meaning of the work as a singlesound term or gesture. Both must be consideredin any analysis of meaning (Meyer 1956, p. 47).

Ultimately, though, it is arguably the support thatlive coding provides for easily shifting between AFSsof different levels—different semantic layers—that


may prove its enduring legacy. As Meyer articulatesin the previous quote, musical form is a complexinterrelationship of hierarchical meanings that arenot easy to untangle. The great advantage for livecoding is the presence of a human agent who providesan exit/re-entry point for switches between formalsystems as well as for the on-the-fly redefinition ofa formal system’s rules and axioms. This human-in-the-loop approach to the development of formalsystems is a unique contribution to the artisticlandscape.

Conclusion

The live coder’s ability to orchestrate abstractformal processes in perceptual response to theacoustic environment provides scope for intuitionand play. By supporting a dynamic interplaybetween the composer’s formal intentions and themachine’s formally derived actions, the composeris able to guide the musical outcome, as embodiedin the physical environment. By placing a human inthe loop, live coding provides not only the means tocritique an algorithm (as any offline method also al-lows) but also to modify an algorithm over time—tosteer the result in culturally meaningful directions.

In this article we have attempted to open a di-alog on the multiple levels of meaning present inlive-coding practice. We have discussed the com-poser’s role in the formation of various ontologicalcommitments, with some regard to the inevitablecompromises associated with different levels ofrepresentation. Ultimately, we have only begun toexplore the complex interwoven semantics inherentin live-coding practice. Our hope, then, for thismodest contribution is to engage the community ina robust discussion surrounding the many meaningsof live coding.

We conclude with an observation from WilliamSchottstaedt in 1987. In regards to his Pla computermusic language, he wrote:

To my surprise, neither the real-time inputof data nor the real-time interaction withcomposing algorithms has generated muchinterest among other composers (Schottstaedt1989, p. 224).

We believe that, after over ten years of live-codingpractice, the value of interacting with composingalgorithms in real time is beginning to reveal itself,and in ways that the computer music community ofthree decades ago could not have imagined.

References

Biles, J. A. 2007. “Improvizing with Genetic Algorithms:GenJam.” In Evolutionary Computer Music. Berlin:Springer, pp. 137–169.

Boretz, B. 1970. “Nelson Goodman’s Languages ofArt from a Musical Point of View.” The Journal ofPhilosophy 67(16):540–552.

Collins, N., et al. 2003. “Live Coding in Laptop Perfor-mance.” Organised Sound 8(3):321–330.

Cross, I., and E. Tolbert. 2009. “Music and Meaning.” InThe Oxford Handbook of Music Psychology. Oxford:Oxford University Press, pp. 24–34.

Dennett, D. C. 1989. The Intentional Stance. Cambridge,Massachusetts: MIT Press.

Eco, U. 1979. Theory of Semiotics. Bloomington: IndianaUniversity Press.

Edwards, M. 2011. “Algorithmic Composition: Compu-tational Thinking in Music.” Communications of theACM 54(7):58–67.

Emmerson, S. 1986. The Language of ElectroacousticMusic. London: Macmillan.

Essl, K. 2007. “Algorithmic Composition.” In N. Collinsand J. d’Escrivan, eds. The Cambridge Companionto Electronic Music. Cambridge, UK: CambridgeUniversity Press, pp. 107–125.

Fux, J. 1965. The Study of Counterpoint: From JohannJoseph Fux’s Gradus ad Parnassum, trans. A. Mann.New York: Norton.

Goodman, N. 1976. Languages of Art: An Approachto a Theory of Symbols. Cambridge, Massachusetts:Hackett.

Haugeland, J. 1981. “Semantic Engines: An Introductionto Mind Design.” In J. Haugeland, ed. Mind Design.Cambridge, Massachusetts: MIT Press, pp. 1–34.

Loy, G. 1989. “Composing with Computers: A Survey ofSome Compositional Formalisms and Music Program-ming Languages.” In M. V. Mathews and J. R. Pierce,eds. Current Directions in Computer Music Research.Cambridge, Massachusetts: MIT Press, pp. 291–396.

Magnusson, T. 2011a. “Algorithms as Scores: Coding LiveMusic.” Leonardo Music Journal 21(21):19–23.

Magnusson, T. 2011b. “The ixi lang: A SuperColliderParasite for Live Coding.” In Proceedings of the Inter-national Computer Music Conference, pp. 503–506.

Sorensen et al. 75

McLean, A., and G. Wiggins. 2010. “Bricolage Program-ming in the Creative Arts.” In Annual Workshop of thePsychology of Programming Interest Group.

Meyer, L. 1956. Emotion and Meaning in Music. Chicago,Illinois: University of Chicago Press.

Morris, C. W. 1938. Foundations of the Theory of Signs.Chicago, Illinois: University of Chicago Press.

Rohrhuber, J., and A. de Campo. 2009. “ImprovisingFormalisation: Conversational Programming andLive Coding.” In G. Assayag and A. Gerzso, eds.New Computational Paradigms for Computer Music.Sampzon, France: Delatour.

Rohrhuber, J., et al. 2007. “Purloined Letters andDistributed Persons.” In Music in the Global VillageConference (pages unnumbered).

Schottstaedt, W. 1989. “A Computer Music Language.”In M. V. Mathews and J. R. Pierce, eds. CurrentDirections in Computer Music Research. Cambridge,Massachusetts: MIT Press, pp. 215–224.

Smith, B. C. 1996. On the Origin of Objects. Cambridge,Massachusetts: MIT Press.

Sorensen, A., and H. Gardner. 2010. “Programmingwith Time: Cyber-Physical Programming withImpromptu.” ACM SIGPLAN Notices 45(10):822–834.

Wang, G., and P. R. Cook. 2004. “On-the-Fly Pro-gramming: Using Code as an Expressive MusicalInstrument.” In Proceedings of the Conference onNew Interfaces for Musical Expression, pp. 138–143.

Ward, A., et al. 2004. “Live Algorithm Programmingand a Temporary Organisation for Its Promotion.” InO. Goriunova and A. Shulgin, eds. Proceedings of theREADME Software Art and Cultures Conference, pp.243–261.

Zemanek, H. 1966. “Semiotics and ProgrammingLanguages.” Communications of the ACM 9(3):139–143.


themanymeaningsof livecoding

Documents