Two live coding systems have been introduced in this thesis, the Tidal paern DSL (§4.5) and the related visual language Texture (§5.6). We have discussed technical aspects of live coding in the process, but until now have not discussed the creative practice of live coding. e termlive codingemerged around 2003, to describe the activity of group of practitioners and researchers who had begun developing new approaches to making computer music and video animation (Collins et al., 2003; Ward et al., 2004; Blackwell and Collins, 2005; Rohrhuber et al., 2005). It is defined by Ward et al. (2004) as “the activity of writing a computer program while it runs”, where changes to the source code are enacted by the running process without breaks in musical or visual output. e archetypal live coding performance involves programmers writing code on stage, with their screens projected for an audience, their code dynamically interpreted to generate music or video.
Closely related terms are interactive, on-the-fly (Wang and Cook, 2004), conversational (Kupka and Wilsing, 1980), just-in-time (Rohrhuber et al., 2005) andwith-time(Sorensen and Gardner, 2010) programming. Many of these terms are interchangeable, although there are dif- ferences of technique and emphasis, for example live coding is most oen used in the context of improvised performance of music or video animation. is context of improvised computer
C 6: C
music is adopted here, and although much of the following could be related to work in live video animation, focus on computer music is kept for brevity.
In live coding the performance is theprocessof soware development, rather than its out- come. e work is not generated by a finished program, but through its journey of development from nothing to a complex algorithm, generating continuously changing musical or visual form along the way. is is by contrast togenerative art, popularised by the generative music of Brian Eno (1996). Generative art may be understood by a gardening analogy, where processes are composed as ‘seeds’, planted in a computer and le to ‘grow’. e random number generators oen used to provide variation in generative processes have led to their being likened to the construction of wind chimes, in that they are structures that are ‘played’ by sources of noise. Like wind chimes, while generative art may constantly vary, generative systems which pro- duce qualitative changes are rare. Output more or less follows the same style, with only a few permutations giving an idea of the qualities of the piece. is is well illustrated by our case study of an artist-programmer (§6.3), who ran their program a few times not to produce new works, but to get different perspectives on the same work.
With live coding, hands-on human involvement is essential to the development of a piece. Metaphorically speaking, rather than sowing seeds, live coders metaphorically construct plants from scratch by splicing different plants together, modifying their DNA while they grow, and experimenting with different ways of destroying them for artistic effect. With generative art, onlookers are oen le to question whether the programmer or computer is the creative agent in the artistic process. However with live coding there is no question, the programmer very visibly provides all the rules, the human act of programming providing all creative impetus, and the computer process extending the human range of exploration.
Live coding allows a programmer to examine an algorithm while it is interpreted, taking on live changes without restarts. is unites the time flow of a program with that of its de- velopment, using dynamic interpretation or compilation. Using techniques outlined in (§5.2), live coding makes a dynamic creative process of test-while-implement possible, rather than the conventional implement-compile-test cycle. e creative processes shown in Figures 6.2 and 6.3 still apply, but are freed from the constraints of time, with the arrows now representing concurrent influences between components rather than time-ordered steps.
Live coding not only provides an efficient creative feedback loop, but also allows a pro- grammer to connect soware development with time based art. is is bricolage programming (§6.3.1) taken to a logical and artistic conclusion, particularly with archetypal ‘blank slate’ live coding. Here risk is embraced and pre-planning eschewed, the aim being to design a program ‘in the moment’ where it is implemented and executed in the expectant atmosphere created by
C 6: C an audience.
e primary research focus around live coding practice has been upon the integration of performance time with development time, for example in the live coding papers already cited. is is important work, as human perception of the progression of time during the evaluation of an algorithm has oen been deliberately ignored in computer science (§6.6). is line of research is certainly not complete, but there are now several working approaches to improvis- ing music through live code development. Some research emphasis has therefore moved from time to space, that is, to the consideration of visuospatial perception within the activity and spectacle of live coding performance.
6.8.1 “Obscurantism is dangerous. Show us your screens.”
e present section title is taken from the manifesto draed by the Temporary Organisation for the Promotion of Live Algorithm Programming (TOPLAP; Ward et al., 2004), a group set up by live coders to discuss and promote live coding. It neatly encapsulates a problem at the heart of live coding; live coders wish to show their interfaces so that the audience can see the movement and structure behind their music, however in positioning themselves against the computer music tradition of hiding behind laptop screens (Collins, 2003), they are at risk of a charge of greater obscurantism. Most people do not know how to program computers, and many who do will not know the particular language in use by a live coder. So, by projecting screens, do audience members feelincluded by a gesture of openness, orexcluded by a gibberish of code in an obscure language? Do live coding performances foster melding of thoughts between performer and audience, or do they cause audience members to feel stupid? Audiences have not yet been formally surveyed on this issue, but anecdotal experience suggests both reactions are possible. A non-programmer interviewee in a BBC news item (“Programming, meet music”, 28th August 2009) reported ignoring projected screens and just listening to the music, and less ambiguous negative reactions have been rumoured. On the other hand, a popular live coding tale has it that aer enjoying a live coding performance by Dave Griffiths in Brussels (FoAM studios, 17th December 2005), a non-programmer turned to their lover and was overheard to exclaim “Now I understand! Now I understand why you spend so much time programming.”
Partly in reaction to the issue of inclusion, a new direction of research intovisual program- minghas emerged from live coding practice, evident in the systems reviewed and introduced in the previous chapter. e challenge is to find new ways of notating programs suitable not only for containing the expressions of a well-practiced live coder, but for doing so in a way meaningful to an audience.
C 6: C
6.8.2 Cognitive Dimensions of Live Coding
Blackwell and Collins (2005) have examined live coding with respect to the Cognitive Dimen- sions of Notation (CDN), using it to compare the ChucK language for programming on-the-fly computer music (Wang and Cook, 2004) with the commercial Ableton Live production so- ware. ChucK, and by implication live coding in general, does not come off particularly well. It has low on the dimensions of visibility,closeness of mappingandrole-expressiveness, is
error-proneand requires hard mental operations in part to deal with its high level of ab- straction. It would seem that the progressive evaluationand representational abstraction
offered by ChucK come at a cost. Nonetheless, these are costs that many are willing to over- come through rigorous practice regimes reminiscent of instrumental virtuosos (Collins, 2007). ey are willing to do so because abstraction, while taking the improviser away from the direct manipulation that instrumentalists enjoy, allows them to focus on the compositional structure behind the piece. Being able to improvise music by manipulating compositional structure in theoretically unbound ways is too aractive a prospect for some to ignore.
Established norms place the live coder in a stage area separate from their audience mem- bers2, who depending on the situation, may listen and watch passively or interact enthusiasti- cally, perhaps by dancing, shouting or screaming. We therefore have two groups to consider, the performers needing to work ‘in the moment’ without technical interruptions that may break creative flow (Csikszentmihalyi, 2008), and the audience members needing to feel included in the event, while engaged in their own creative process of musical interpretation (§4.4). ere is a challenge then in reconsidering live coding interfaces, creating new languages positioned at a place within the CDN well suited for a broader base of musicians and audiences who may wish to engage with them. e question is not just how musicians can adapt to programming environments, but also the inverse; how may programming environments, oen designed to meet the needs of business and military institutions, be rethought to meet the particular needs of artists? First, we should consider what those needs might be.
An interesting cognitive dimension with respect to live coding iserror-proneness. ere are different flavours of error, some of which are much celebrated in electronic music, for example theglitgenre grew from an interest in mistakes and broken equipment (Cascone, 2000). In improvisation, an unanticipated outcome can provide a creative spark that leads a performance in a new direction. We would classify such desirable events as semantic errors, in contrast with syntactic errors which lead to crashes and hasty bug-fixing.
In terms of the CDN, bricolage programming requires high visibilityof components, in 2Performance norms are of course extensively challenged both inside (Rohrhuber et al., 2007) and outside (Small, 1998) live coding practice.
C 6: C
particular favouring shorter programs that fit on a single screen, and avoiding unnecessary
abstraction. Here is a conflict – as noted above abstraction sets live coding apart from other approaches to improvisation in computer music, but also acts as an obstacle to bricolage pro- gramming. We are pulled in different directions, and so look for the happiest medium, a com- mon result from taking a CDN perspective. Some programmers, known in some quarters as architecture astronauts, enjoy introducing many layers of abstraction that only serve to ob- fuscate (Spolsky, 2004). Bricolage programmers are the opposite in wanting to be as close to their work as possible. is is not however a case of removing all abstraction, but finding the right abstraction for the work. Programming aer all is an activity that takes place somewhere between electric transistors and lambda calculus – the trick is finding the right level of abstrac- tion for the problem domain (§4.3). Accordingly a computer musician may find having to deal with individual notes a distraction, and that a layer of abstraction above them provides the creative surface where they can feel closest to their composition.