PERFORMING COMPOSITION

Developing a Computer Assisted Composition

system through live coding performance.

Thorin McDonald Thomas Kerr, B.Mus.

Submitted in partial fulfilment of the requirements for the degree

of Master of Arts (Research), Queensland University of
Technology, Creative Industries Faculty, Music and Sound
February 2009.

Keywords
music, composition, performance, live coding, live programming, computer music,
computer assisted composition, algorithmic music, generative art, Impromptu, Csound.

Abstract
This thesis maps the author's journey from a music composition practice to a composition
and performance practice. The work involves the development of a software library for
the purpose of encapsulating compositional ideas in software, and realising these ideas in
performance through a live coding computer music practice. The thesis examines what
artistic practice emerges through live coding and software development, and does this
permit a blurring between the activities of music composition and performance.
The role that software design plays in affecting musical outcomes is considered to
gain an insight into how software development contributes to artistic development. The
relationship between music composition and performance is also examined to identify the
means by which engaging in live coding and software development can bring these
activities together.
The thesis, situated within the discourse of practice led research, documents a
journey which uses the experience of software development and performance as a means
to guide the direction of the research. The journey serves as an experiment for the author
in engaging an hitherto unfamiliar musical practice, and as a roadmap for others seeking
to modify or broaden their artistic practice.

Contents
Introduction

Chapter One: Computers, composition and performance

14

Chapter Two: An ontology of a musical practice:

CAC design for live coding performance.

24

Chapter Three: Methodology

32

Chapter Four: Performance and Reflection

42

Findings and Conclusion

56

Appendix I: Computer Assisted Composition System Usage and Features.

62

Bibliography

70

DVD Supplement, Documentation of live coding performances:

Index1:

Mirroring

Index2:

The Forest

Index3:

Soiree

DVD-ROM section, directory tree:

PERFORMING_COMPOSITION/
PerformingComposition DVD-ROM Contents/
AudioOnly/
Forest.wav
Mirroring.wav
Soiree.wav
Movies/
QuickTime/
Mirroring.mov
Forest.mov
Soiree.mov
WindowsMedia/
Mirroring.WMV
Forest.WMV
Soiree.WMV
CACSource/
CACLib_Src.pdf

Illustrations and Diagrams

Illustration 1. Page 34: A model of my iterative methodological approach.
Illustration 2. Page 38: An early example of a score.
Illustration 3. Page 39: An early example of a score player.
Illustration 4. Page 52: An example of a score, including a mixture of operators, players
and embedded functions.

Statement of Original Authorship

The work contained in this thesis has not been previously submitted to meet
requirements for an award at this or any other higher education institution. To the
best of my knowledge and belief, the thesis contains no material previously
published or written by another person except where due reference is made.

______________________________
Signature

______________________________
Date

Acknowledgements
In presenting this thesis, I am indebted to the people I have met, both past and present,
and the knowledge they have generously shared with me.

I would like to thank my supervisor Associate Professor Andrew Brown at the

Queensland University of Technology for assisting me through the research process, and
providing me with professional opportunities. I would also like to thank my associate Dr.
Robert Davidson for his valuable insights.

For my friend and colleague, the talented Andrew Sorensen, for developing Impromptu,
sharing his computer programming expertise, and his time to debate important issues
surrounding music and computers.

For the people I met and my experiences during my undergraduate at the Sydney
Conservatorium of Music, in particular I would like to thank Dr. Greg Schiemer and Dr.
Anthony Hood who introduced me to the world of Computer Music.

I would like to thank my wife and soul mate Dr Kirsty Martin, who sacrificed too much
to help me through. I will always be grateful for her encouragement and support.

Finally, I would like to thank my daughter Ada, whose arrival during my studies was a
particularly significant event in our lives, and has been the happiest blessing words can
hope to express.

Introduction
The Composer in Context
This thesis provides an account of my transition from that of a composer of pre-recorded
musical works, to a composer as performer. The research sees me undertake the task of
developing computer software for the purpose of live computer music performance. The
engagement of a live computer music practice is a significant change to my accustomed
compositional practice of creating fixed-media electro-acoustic works.
This thesis describes the transformation of a compositional practice and my
conceptualisation of composition into a performance practice. The journey described here
refers to three performances, Mirroring, The Forest and Soiree, which serve both as
artistic outcomes of various stages of the research, and as a means to direct the course of
the research. This process is described in more detail in Chapter three.
The accompanying DVD presents documentary video of the live coding
performances. The video performances are presented as a mixture of a 'screen cast' and
live footage at the performance venue. The 'screen cast' is a captured video from my own
computer screen during performance. Thus the images of text appearing on the screen is
the result of me typing at the keyboard. In performance, a 'screen cast' was projected on a
screen in front of the audience. The 'screen cast' footage presented on the DVD is
identical to the video displayed to the audience at the performance.
As with many composers schooled in western-art music making, my understanding
of the role of a composer had come to be defined as those who write musical scores. The
final outcome of my work was only a portion of what was required to realise the music.
The delivery of music to an audience lay in the domain of performance, with its own
practitioners and aesthetic criteria.
The reliance on performers to realise composed work motivated my interest in
computer music-making. Computer music offered a way to create a complete realisation

of the musical work entirely in the recorded medium. Using a variety of computer music
packages, I would carefully create, process and place sounds so as to make a final audio
work. My work in this area had been squarely located in what is now sometimes referred
to as 'deferred-time' computer music composition.
However, the freedom to realise the final audible work raised some concerns. The
'performance', in the sense of an event in which people come together and appreciate the
work as it is presented, was now unnecessary. It seemed easier, and in some ways more
appropriate, to simply distribute audio copies of my works for people to listen to
privately.
Unlike distributed recordings, performance engenders a social connection between
a performer and the audience. The mere presence of participating in the performance of
the work engages the audience in a much different way to that of a recording. Where a
recording could be experienced privately any time in almost any location, the
performance offered a mutually shared experience, a sense of uniqueness of the
experience, and an engagement between the performer and the audience. By removing the
performance experience from my music, I had removed a significant aspect of the
experience of music generally.
It should be qualified however, that some of my computer music works have been
'performed', and I have on occasions been 'the performer' in these works. However, while
these events can be considered 'performances', there was often very little participation by
myself or others during the performance. For example, in some 'electro-acoustic'
concerts, the 'performance' consisted of little more than the playback of the recorded
artefact in a concert situation.
The experience for the audience has been heightened in these situations by using
audio reproduction equipment not typically available to individuals, such as a large array
of speakers. The experience for me as a 'performer' has also been somewhat improved by

allowing me to 'diffuse' the spatial location of sounds across a collection of speakers

during the performance. In this way I have been able to take an active part in controlling
certain characteristics of the music as it was performed. This provided some degree of
creative practice during performance. Significantly, performing in this way represented a
form of creativity which had not been pre-composed and 'fixed'.
Be this as it may, the performative freedom involved in spatially diffusing prerecorded material is (arguably) a heavily constrained form of performance participation.
What I felt was lacking in these performances was the integration of my compositional
practice into a performance practice. My actions - if any - during a performance of these
works had little to do with the compositional thought which went towards making the
work. What was conceived when the piece was written, and what I did when performing
the piece were rarely in congruence and of little consequence.
In another context: I had also been involved as an instrumental performer in a
(progressive) rock band. This process of creating music would typically consist of
rehearsals, 'jam sessions' and improvisation. Here I had the experience of playing an
integral part in the creation of music during performance.
This experience was very different to that of composing scores or creating 'tape
music', however it also presented its own limitations. In particular, as my interest in
computer music grew, I attempted to incorporate various computer music sounds into
performances. This was fine in certain contexts, such as using unusual sounds to
supplement existing songs. Rarely would the position of computer music sounds and
techniques become the basis on which music was actually made. Computer music
functioned as a disposable additive to the characteristics of the music.
To an extent, the 'ear candy' role for these sounds in a rock band can be explained
as an inherent limitation within the particular musical genre within which the music was
made. Alternatively it can be argued that in the genre of computer music, performance

itself is seen as adjunct to 'the work'. This position would also explain the ancillary role of
my performance of diffused computer music works.
As I came to realise throughout the course of this research, there is an implicit
understanding that the artistic outcome of composition is in direct opposition to
performance. Whilst computer music performance displays a dichotomy between
composition and performance, it is not the cause of it. As performing computer music is a
comparatively common activity today, I believe it is possible to use the computer as both
a performance and composition instrument.
I wanted my performance decisions to play an integral part in the creation of the
music, in the same way that I understood music creation through means of composition.
Importantly, I still wanted to consider my works as compositions, without any
deprecation of the role of composition in the presentation of the work. In effect, I wanted
to blur the distinction between composition and performance as the means of realising
music.
Facilitating the Composer to Perform
I have chosen to develop an interactive music composition system in an
environment which facilitates live performances. Specifically, I have developed a library
of composition tools in software, for use in an interactive live coding environment. The
live coding environment I chose to develop these tools in, is the Impromptu software
developed by Andew Sorensen (Sorensen, 2005). Using the Impromptu environment
allows the library to be used as a collection of musical performance tools. This allows me
to model compositional ideas in software, and interact with them during a live
performance. The design of the library must therefore be considered in relation to both
music creation and music performance.
As such, an integral part of the research has been to consider the development
process itself as an aspect of the artistic practice.

10

The Premise of the Research

The aim of this research is to create a hybrid artistic practice consisting of performance,
composition and software development. In developing a hybrid practice, the distinctions
between these paradigms becomes less defined. A new understanding of this hybrid
practice needs to be considered. Therefore, the research question is: What is the nature of
the artistic practice that emerges when combining software development, composition
and performance?
The course of the Research
At first glance, this may seem a somewhat ambitious task. Where does one begin in
considering three separate fields of enquiry, their relationship to each other, what impact
they can possibly have on each other and finally what this means as a hybrid creative
practice? Furthermore, the notion that one particular practice can provide the definitive
answer to this question is problematic to say the least.
Instead, this research seeks to provide an answer by conducting an experiment. In
effect, I engage in a practice led journey with an intention, goals and methods. However,
the specific outcome of the journey is unknown. What comes about at the conclusion of
the journey is what needs to be analysed and critiqued against the premise with which I
began.
This process of subjective experimentation underpins the practice led research
methodology. While such an approach is a relatively new mode of academic enquiry,
it is an approach which is congruent with well established artistic methods across a broad
range of disciplines, including theatre, dance and music.
By way of example: Benjamin Knapton, in his exploration of the working
principals used by theatre director Robert LePage, employs an approach where the
process of creating a work is used to determine the content of the work. Knapton chooses
to create a performance without the use of a written script. Instead he seeks to create a

11

play through iterative rehearsal and improvisation. For Knapton, the final outcome of the
play is presented as an example of the evolution of the creative process itself (Knapton,
2008).
My own work uses an iterative approach to develop a software system and musical
performance practice. A similar methodological approach applicable to computer music
has been undertaken by Ren Wooller for the development of his LEMorpheus software,
in which a series of evaluations is used to guide the design of the software as it is
developed (Wooller, 2007).
Thus In this introduction, I have outlined my reasons for pursuing, and belief in the
realisation of a hybrid composition/performance practice through a practice led approach.
The first chapter locates this research in the specific area of computer music
composition, software development, and live computer music performance. The aim of
this endeavour is to provide an account of how computer music practitioners have
engaged these aspects of music making.
The second chapter considers the philosophical implications of attempting to
hybridise the component practices of composition and performance. The chapter seeks to
determine in what way an artistic practice can be considered a hybrid of these activities.
The third chapter describes the practical component of this research, including the
creation of tools aimed to develop a compositional approach which is not only effective
in performance situations, but also embodies its own compositional method. The software
library and the associated practice are informed by engaging in performance situations
using the system as it develops. The chapter describes the process of developing the
software and some of the main issues I faced in becoming a live coding performer based
composer.
The fourth chapter discusses three performances utilising the software library. The
performances mark particular milestones of what is effectively the work-in-progress. This

12

chapter describes and analyses the journey in terms of developing the system, engaging in
performances and reflections on the outcomes. The theoretical and practical components
of the research are drawn together in order to provide a framework with which to measure
the outcomes of the research.
The conclusion represents the outcome of the course of the research journey. The
results of the research are analysed to determine what insights can be gained from
engaging in this endeavour.

Research Outputs
The outputs of this practice led research with intended weighting for evaluation:
Written Component:
Evaluation weighting: 50%
Materials: Thesis.
Creative Practice:
Evaluation weighting: 50%
Materials: DVD/DVDROM
Performed works include Mirroring, The Forest and Soiree.
The DVD is playable as a DVD Video disc in a standard DVD player.
A DVD-ROM section on the disc is able to be read by Windows and Mac
computers. Content on the DVD-ROM includes Quicktime Movie, Windows
Media Video and WAV(Audio only) versions of the performances.
Source code for the Computer Assisted Composition software library is also
provided in PDF format.

13

Chapter One: Computers, composition and performance

In this chapter I look at some of the motivations and concomitant methods which have
compelled computer music practitioners to engage in both composition and live
performance. I concentrate on two aspects of computer music practice: Specifically, these
concern Computer Assisted Composition (CAC) systems1, and the emerging performance
practice of live coding. These activities are not overtly related, although both activities
can be quite compatible. Both the usage of CAC systems and live coding practice
typically involve text-based code as the interface, and algorithmic techniques for creating
music. Both of these activities are significant elements of this project.
The development of real-time computer processing power has allowed musicians to
generate and manipulate digital audio as it is performed. This effectively transforms the
computer into a musical instrument, able to turn performers gestures into an audible
outcome. This ability to have an immediate musical response to a performer's instruction
could be seen as a logical result of technological development and concordant with a
'traditional' means of 'playing' music via means of physical instruments. However, the
transition of computer music practice into a performable practice has not been a clear
path.
The performance of computer music provokes a need for interactive interfaces able
to respond to performance gestures. Interface/instrument design is no trivial appendage to
computer music practice. Ross Bencina has observed that 46 percent of the 94,000 lines
of code which make up his AudioMulch software is dedicated to the graphical user
interface, while only 12 percent constitutes processes directly related to music (Bencina,
2006, p. 20).

1Ariza proposes a definition of a Computer Aided Algorithmic System (CAAC) being software
that facilitates the generation of new music by means other than the manipulation of a direct music
representation" (Ariza, 2005, p. 1). Whilst I have adopted the more common term of Computer
Assisted Composition (CAC) system, Ariza's definition adequately describes the class of systems
to which I refer.

14

Despite the variety of approaches, the presentation of computer music in

performance situations has often proved to be a disappointing experience for both
performers and audiences. My own experience of the limited performance possibilities
offered by spatially diffusing recorded works, mentioned in the introduction, can be
considered one end of the spectrum of computer music performance modes.
There is, for example, the long-standing genre of 'performer and tape' works,
involving players of traditional instruments accompanying a 'tape' recording of sounds
produced using a computer. Note that the composer typically has no involvement in the
performance of these works: this is completely handed over to performers.
The difficulty comes with the tape accompaniment being treated with equivalence
to that of a score: Both tape and score are the final fixed outcome from the composer.
Performers often find the experience un-enjoyable as they struggle to realise a score in
accompaniment to the unrelenting, un-interactive tape accompaniment (Vinao & Cross,
2006. p. 461).
The use of custom or re-appropriated hardware controllers to control audio
processes can provide performative correlations with sound. However, controllers can
also prove limiting in their expressive possibilities. Bob Ostertag suggests that new
instruments are not sophisticated enough to allow performers to develop virtuosity
(Ostertag, 2002, p. 13). Although the success of instruments such as the theremin or the
record turntable suggest there are other factors to consider.
Guy Garnett suggests there is something about the nature of computer music itself
which often leads to lacklustre performances, even if the works themselves are highly
regarded (Garnett, 2001). Performed computer music still largely draws from methods
employed in producing 'deferred time' rendered computer music. Many computer music
processes do not translate neatly into the performance domain as traditional instrumental
music does. Instead computer music has tended toward abstraction and objectivity, often

15

with dis-appointing results (Garnett, 2001, p. 26).

It is interesting to note that the difficulties surrounding interface design and
performed representation largely disappear when playing synthetic sounds on something
resembling a traditional instrument, such as a keyboard. David Wessel and Matthew
Wright (2002) offer an explanation for this phenomena when they refer to the Onegesture-to-one-acoustic-event-paradigm. Every physical gesture on a physical instrument
is directly correlated with an audible result.
Digital signal processing or algorithmic note generation doesn't have a traditional
performance framework on which to draw. Correlating this kind of activity to an audience
is difficult. An audience can easily lose a sense of association between the performed
gestures and sound.
Many computer musicians don't attempt any visual performative action to
accompany the music. Indeed the term 'laptop performance' has become synonymous
with a motionless performer providing no perceivable cues between their actions and the
music. This style of presentation has even been referred to as a kind of 'non-performance',
with audiences not even considering the music to be a performance (Turner, 2003).
Incorporating the rise of DJ and VJ culture, another approach to enhancing
performed computer music is to incorporate other media, such as animated video. The
goal in performance is to integrate the visual activity and musical activity into a new
hybrid media art (Collins and Olofsson, 2006). A discussion of the artistic objectives of
multi-media art forms is beyond the scope of this thesis, suffice to say that, as with any
art form, the varying approaches are as multifarious as practitioners.
One approach to integrating media is to represent an abstract process both visually
and sonically. The aim is to develop processes which can be represented in both media
such that correlations are drawn between the activities. Roger Dean (Dean et. al, 2006)
uses the term 'algorithmic synaesthesia' to describe the 'semiotic exchange' of underlying

16

meanings common to the representation presented in each media. Techniques can include
cutting and splicing material in both media in ways which have a similar experiential
result, sonification of visual data or visualisation of sonic material, or multiple
representations of singular concepts such as 'space'. In this way a 'work' comes about
through the composition of the relationships and placement of material according to an
abstract design.
Live coding of music takes a similar approach by side-stepping direct
representations of musical gesture and instead attempting to communicate the way the
music is constructed. This is often achieved by literally displaying the computer
programming code which generates the music to the audience. A 'performance' involves
the code being written and modified as it is physically typed, resulting in corresponding
changes to the music. The objective is to allow the audience to intellectually grasp the
structures and abstractions of a work (Sorensen, 2005, p. 149).
While there are early precedents to live coding techniques, in the last several years
the practice has coalesced into an artistic movement. Many live coders gravitate around a
loose collective of artists under the banner of 'Toplap': The exact meaning of which
appears in several forms, although it is commonly used as an acronym for the 'Temporary
Organisation for the Promotion of Live Algorithmic Performance. (Ward, Rohrhuber,
Olofsson, McLean, Griffiths, Collins and Alexander, 2004). Software developers can
apply for 'Toplap approval' of their software systems, denoting that their tools are suitable
for use by live coders, and adhere to a live coding aesthetic. Performances can also be
reviewed by the Toplap panel.
Live coding satisfies a requirement mentioned by Garnett: that the music be
'cognisable' by the performer. Indeed, coding has a tendency to force cognisability on the
part of the performer. However presenting code prompts a new question: 'what if the
audience doesn't understand what they are looking at?' Not all audience-goers can be

17

expected to be computer programmers. Even those who are familiar with programming
may find it difficult to comprehend the audible implications generated from the code.
This is perhaps the point most at odds with the 'obscurantism is dangerous' mantra,
obliquely criticising computer musicians use of 'black box' applications (Draft manifesto,
Toplap).
A response to this is presented in the 'Lu beck 04 Manifesto': It is not necessary
for a lay audience to understand the code to appreciate it, much as it is not necessary to
know how to play guitar in order to appreciate watching a guitar performance (Ward,
Schubert, Wolfson, McLean, Griffith, Collins, Alexander, 2004, p. 248). This point is not
expanded upon in the manifesto, however one might say that the point of both live coding
and guitar performance is to provide enough cues for the audience to draw their own
correlations between the performers actions and the audible experience.
Other comparisons of live coding to 'traditional performance' have been be made:
Programming requires practice and specific skills. Many programmers have years of
experience honing their skills. The possibility exists then for a live coder to display a
level of virtuosity that will hopefully provide a stage presence that has often been
missing in live laptop performance (Sorensen, 2005, p. 149). Indeed many live coding
performances can involve hours of 'rehearsal'. Similarly, improvising in a live coding
scenario carries 'risk' and danger of failing or producing unexpected results. However it is
this risk that makes the performance compelling (Collins, McClean, Rohrhuber and Ward,
2003).
Despite the comparisons, it should be recognised that the appreciation one has of a
live coding performance is not entirely the same as that of a traditional instrumental
performance. The manipulation of algorithms is itself an integral part of the artistic
process. The display of the algorithms to the audience is effectively a parallel
representation of the composer/performers thought process of making music. As such,

18

some live coders have advocated that the code itself is also the art. Live coding provides
aesthetic appreciation of the algorithm itself (Ward, Rohrhuber, Olofsson, McLean,
Griffiths, Collins, Alexander, 2004).
Presentation of, and access to, underlying algorithms is of course counter to the
design of many pre-built software packages. The interfaces of many software packages
are designed to hide the underlying complexities from the user, prescribing the available
processes usable by the performer. From a live coding perspective, this hinders the ability
to design processes which are unique and original. Philosophically, live coding advocates
that only programming in a language can provide enough creative freedom for an artist.
A language provides one with a finite set of words and a grammar for combining
these words into phrases, sentences, and paragraphs to express an infinite variety of
ideas (Scaletti 2002, p. 69).
Of course, the practicalities of performance have an influence on how 'from
scratch' live coders are willing to be when using their chosen programming language.
Because of the danger of running very complicated new code live, in practice most
composers would content themselves with modifying pre-tested snippets. They'd go to a
gig with a library of prefabricated and tested code (Collins, McLean, Rohrhuber, Ward.
2003. p. 322). So, we can see that employing pre-written libraries of code is not
inherently problematic in a live coding scenario. What matters is that the freedom of
expression provided by using a programming language is not curtailed.
Of course many computer music 'packages' are often much more complicated than
just a row of buttons. Ariza notes that the distinction between 'packages and languages' is
not a useful one because it doesn't reflect the abilities of either the language or the
package (Ariza, 2005). In discussing her use of her own pre-built 'shortcuts' for her
video/text software 'the Thingee', Amy Alexander goes further and suggests there is no
distinction at all:

19

In making the shortcuts, of course I'm essentially writing a language

one level higher/more abstract than the one I was writing in (Lingo).
Which is itself written on top of something else, eventually going down
1's and 0's of machine language and then to the processor. If I kept going
to successively higher level languages I could eventually get down to
pre-scripted one-keypress actions, which is more traditional user
interaction for performative software. So this illustrates for me anyway
that the line between programmer and user is really a continuum, not a
line in the sand (Alexander in Ward, Rohrhuber, Olofsson, McLean,
Griffiths, Collins 2004, p. 254).
Another important consideration in the development of 'higher level' tools, is that
the design of a system carries with it the conceptual understandings of the developer. This
is reflected in the development of all software. By designing abstractions to describe a
design, particular aspects of the design are emphasised and others de-emphasised
(Abelson, Sussman, 1996, p.xviii).
For the large majority of tasks that computers and software design systems are
called upon to perform, this inherent tendency is a desirable characteristic. An engineer
will use the tools appropriate for the task. Many of those tools will no doubt be useful for
following engineering conventions and solving common engineering problems.
In his work, Ross Bencina defines 'Creative Software Development' as direct
engagement with programming as a creative medium (Bencina 2006, p. 12). This
follows the observation that in creative arts the creative 'task' is not necessarily described
by convention. Program design in this arena should be for the purpose of enhancing
creativity. The objective should be to provide freedom for creative artists to create works
they would otherwise have found difficult or even impossible to create. A good quality
system may even suggest new directions which the composer had not anticipated.
The influence of the designer's understanding of the task in my case to create
music will have an influence on the design of the system. By incorporating ideas about
music making in the design, this in turn influences the kind of music the software is
suitable for. Ariza (2005) calls this an 'idiom affinity', and suggests as with all software

20

design that every compositional aid carries the influence of the designer. Importantly
this includes systems intended as 'musically neutral' by providing tools which behave in
manners believed to be fundamental for all music making, or open-source systems
developed by a large developer/user communities.
Computer Music Composition systems (CAC's)
There are a great many computer music systems which have been developed by
composers to facilitate the production of music, as evidenced by catalogues such as the
Programming Languages Used for Music list (PLUM). An examination of selected
systems was undertaken to assist in understanding the relationship between computer
music systems and the music they produce, and thus give insight into the relationship
between my own compositional system and it's musical intentions and outcomes.
Some systems attempt to accommodate what seem to be fundamentals of music
composition. For example, Common Music is a popular system written in the Common
Lisp and Scheme languages. Common Music offers primitive functions, and
enhancements to the Lisp language with a view to assist compositional goals. Some of the
tools simply offer ways of converting data into a musical format such as MIDI or a
Csound score. Other tools revolve around loops and iteration. By working within the Lisp
language, the tools are able to be recombined as if they too were part of the language. The
composer is able to leverage their own programming knowledge to use these tools to
build their own processes (Taube, 2004).
There is a great deal of freedom provided by the tools in the Common Music
package, however it attempts to hide its 'idiom affinity'. The tools understandably have a
tendency to lend themselves well toward common computer music processes. These
include such well covered areas as stochastic composition, or Markov processes or the
sonification of chaos algorithms.
Alternatively, an example of a system with a distinct compositional viewpoint is

21

the Texture Pack developed by Trevor Wishart (Composers Desktop Project). This system
is implemented as several standalone batch programs which form part of the Composers
Desktop Project suite of applications.
The basic principal behind all the Texture programs is to generate 'ornaments' from
individual sound files. The program treats the sound file as if it were a musical note, for
example a pitch can be arbitrarily assigned to the sound. The 'note' may then be
ornamented with additional notes in a prescribed sequence of pitches. This is a simple
premise, however the texture programs can become quite complex. The manual
description of the 'Tmotifs/motifsin' command states: A texture with the onsets of fully
user-specified motifs constrained to a rhythmic grid and attached to pitches drawn from a
pitch range or from a Harmonic Field/Set; One or more input sounds (Composers
Desktop Software).
This is a powerful and original approach to algorithmically creating music. Within
the design of the underlying algorithms, the tools provided offer a large variety of
creative possibilities. Significantly, there is no attempt by the system to mimic generic
music-making methods: the design of the system reflects the rather unique working
method of its designer.
Rather than attempt to develop my own 'musically neutral' compositional system,
my aim is to develop a system which embodies a particular compositional approach. The
'idiom affinity' embodied in my system is used deliberately to represent my particular
way of approaching music-making. In this way, the musical choices I make in
performance are the corollary of the musical systems I implement in software. The
system effectively embodies and becomes a representation of my own artistic approach.
As will be discussed further in the third chapter, my artistic approach is itself a work in
progress, informed by the experience of performance and development.
Both live coding and CAC approaches provide a useful framework for me to create

22

my own individual compositional style, as they address issues surrounding performance

practice and compositional practice respectively. However, the aim of this research
project is to engage in a combined practice involving both live coding and CAC building
in order to blur the distinction between composition and performance. The implication of
this perspective is discussed in the next chapter.

23

Chapter Two: An ontology of a musical practice:

CAC design for live coding performance.
In order to understand how my compositional practice attempts to blur the boundary
between composition and performance it is useful to gain an understanding as to why a
boundary should be assumed at all, and what kind of musical activities, if any, are able to
integrate these practices into a hybrid form.
The relationship that CAC systems and live coding practice have to the genre of
Computer Music was discussed in the previous chapter. Computer Music as a genre sits
in a rather unique position in the landscape of contemporary music making activity.
Whilst the technology has largely turned computer music composition and performance
into a real-time activity, the genre largely stems from a western art music tradition in
which these activities are largely separate.
In other genre's including jazz, various folk musics, and contemporary popular
musics the boundaries between composition and performance are often more fluid. A
musical practice that many of these genre's have in common is the use of improvisation.
In this chapter I will discuss improvisation and show how it can help blur the distinction
between composition and performance. I will discuss improvisation mostly in relation to
jazz improvisation, and composition in relation to western art composition. This is not to
discount the use of improvisation and composition in other genre's, but rather because
improvisation and composition are well defined, and well documented, practices within
these genre's.
The separation between compositional activity and performance in western art
music may seem self-evident. Composers and performers roles in making music are
delineated such that there is no requirement for either to participate in the other's
activities. There is nothing inherent in the model of western art music which requires the
performer to contribute anything other than submission to the composers instructions as

24

documented in a score. Delige and Richelle succinctly encapsulate this version of a

performer's role in the opening pages of a text discussing performance creativity: music
needs a performer to convey the music from the composer to the audience (Delige and
Richelle, 2006, p.4).
Of course, performances and performers abilities do vary, and many discussions
concerning performer creativity concentrate on performers 'interpretation' of the score.
There are those aspects in the score which haven't been exactly specified, or specified at
all; How to figure appogiaturas or trills, tempo fluctuations, leeway in dynamic
indications and timbral quality.
Interpretation can be seen to require a performer to make many decisions which
determine the qualities of the music as it is heard. From this position it is not difficult to
consider performer interpretation of works as a kind of collaboration with the composer.
This is the position advocated by Fred Everett Maus, where he concludes The performer
will collaborate in producing an event that results from both the composer's and the
performer's musical creativity (Maus, 1999, p. 150). Maus's conclusion is interesting
because it suggests that the dichotomy between composition from performance is a
fallacy.
A similar position is taken by Kevin Bazzana in his book discussing the Canadian
pianist Glen Gould. Bazanna considers some of Gould's controversial performances in
which Gould would sometimes perform works with little regard, or even in a
contradictory manner, to what was written in the score. Bazzana suggests that Gould's
justification for deviating from the score was based on a view of the role of performance
in the music making process. In Gould's aesthetic there is no distinction between the
creation and re-creation of a work. To perform is as creative an act as composition.
(Bazanna, 1997).
While Gould's aesthetic does not seem to pay much concern for 'composers

25

intentions' by following performance instructions, Bazanna does point out Goulds intent
to be true to 'the work'. For Gould, to be true to the work is to be true to the underlying
structure of the work (Bazanna, 1997).
Such an idea conforms with a broader philosophical position to see the work of art
as having an 'ideal' or 'authentic' nature which stands outside the instantiation of itself.
Kemal & Gaskell suggest the need for art to have an 'authentic' reference point is to
mimic what was originally provided by divine authority (Kemal, Gaskell 1999, p. vii).
Bruce Ellis Benson relates this phenomena in the arts as an example of Husserls notion of
'treuwerk' (Benson, 2003).
In music, this means that a 'work' can exist whose merits are evaluated irrespective
of the quality of any performance of that work. The problem is that the conception of a
performers role in western art music means their exploration is always in reference to an
'ideal' or 'correct' way to perform the work. Jerrold Levinson states this quite clearly when
he sets out the premise: I begin with the suggested criterion for performance worth of
being true to the work performed (Levinson, 1990, p. 388). Irrespective of whether or
not the performer sees this as synonymous with being true to the composers intentions, it
is the art of interpretation which does not provide room for creative music making to
originate from the performance.
Given this, my own attempts to 'perform composition', in the western art music
sense of composition and performance, becomes a contradiction in terms. I can either
compose, or perform, but each activity is mutually exclusive. That I happen to be the
composer performing my own composition is not enough, it is merely a special case of
this plurality of functions (Delige, Richelle, 2006, p.4). The separation of activities for
composers and performers is ingrained such that the roles have become a definition of
terms.
It should be acknowledged that many composers have sought to subvert

26

orthodoxies inherent in the western art music model. In his book documenting
'experimental music', Michael Nyman uses John Cage's 4'33 as the basis for a definition
of a musical movement which sought to depart from post-war European modernism
which had established itself as the orthodox modern musical practice. As Robert Ashley
is quoted, It seems to me that the most radical redefinition of music that I could think of
would be one that defines 'music' without reference to sound (Ashley in Nyman, 1974, p.
10).
Techniques employed in these works often force performers to make decisions
normally reserved for the composer. Earl Brown's 'Folio and Four Systems' for example
requests the performer to interpret a graphic score into music (Brown, 1953). This
effectively requires the performer to make decisions on which notes to play. However
Brown did not necessarily anticipate performers taking liberties such that they would
make their own significant creative decisions affecting the course of the work. In an
interview with improvising musician Derek Bailey, Earl Brown reveals his own
reconstruction of the composers role in aleatoric music.
You see, it is somewhat my responsibility to create conditions which, in a
certain sense, won't be violated stylistically. For instance, if there's
somebody who is very good at improvising in the style of Bach, or the
baroque period, very often I suggest something verbally. Like, I ask for
erratic, jagged rhythms, so that he would not make sequences of 8th notes
(Brown in Bailey, 1992, p. 67).
I do not mean to suggest that the composers of these works are disingenuous about
their efforts to redefine musical practice. On the contrary, as Nyman points out, a defining
factor of many of these works is to relinquish compositional exactitude to some sort of
automated or emergent process (Nyman, 1974). The contribution these pieces offer is to
remove or at least redefine - the composers function in the creation of music. What
these pieces don't attempt is a redefinition of the performers role in making music. By
presenting a score, the performer may reposition their function as an interpreter, but not

27

so far as to be the creator of the work.

The ability of computer music composers to render sound directly to the recorded
artefact presents a unique situation in the standard composer/performer relationship, by
removing the performer as a creative contributor to music making. Real-time
performance-based computer music tools are now almost de rigueur, which of course has
re-introduced the performance element into computer music. It is tempting then to
consider computer music making as being guided more-so by the limitations of
technology than any express desire to redefine composer performer relations. This may
be true in part, but it is also worth considering that deferred time computer music
composition supports a notion of an 'ideal' compositional environment, without constraint
from performers abilities or instrumental capacity. Jean Claude Risset for example calls
this 'genuine' composition, and offers us this warning on the development of real-time
computer music performance tools. Real-time operation is in fact better suited to
performance and improvisation than to genuine composition. Composition is not - or
should not be - a real-time process (Risset, 1999, p. 37).
Improvisation, as an integral component of music making, has been largely and
conspicuously removed from western art music. Yet it is improvisation which starts to
break down the composer/performer schism. Improvising musicians are able to create the
structures and forms of the music they play. Furthermore improvisation seems to be
primarily a performers art, with little to do with, and at times even opposed to,
composition. As Evan Parker has provocatively remarked: I'm suggesting that if anyone
in the production of a music event is dispensable, it is the score-maker, or the 'composer'
as he is often called (Parker, cited in Bailey, 1997, p.97).
Yet the nature of improvisation is often misunderstood. The notion of a musician
'making it up on the spot', belies the summation of musical knowledge and experience
employed for its realisation. It is quite rare for a musician to completely improvise a piece

28

with no preparation at all. Even in some special cases such as 'free improvisation', most
performers would have had a specific musical background from which they arrive, and
some training on the instrument on which they perform. Improvisation can then be
described as a generative art, in which musical material is generated by the performer as
they draw from memorised knowledge, pre-dispositions, and physical and conceptual
practice.
Arnold Berleant considers improvisation in relation to a phenomenology of music.
For Berleant, improvisation must be generative by virtue of the generative characteristics
of music itself. Improvisation then reflects the generative characteristics of a given
material and offers a first approximation of where it might go (Berleant, 1987, p. 251).
Bailey describes something similar when he discusses 'idiomatic improvisation'.
For Bailey, it is the 'idiom' of the musician which largely determines the kind of music an
improviser plays. This explains why improvising musicians play in particular styles. A
jazz musician for example improvises in the jazz idiom, a flamenco musician in the
flamenco idiom, and so on (Bailey, 1997).
If we consider improvisation as a generative art, drawing from existing musical
knowledge it may start to seem as though improvisation is not entirely dissimilar from
composition. A jazz pianist once described to me that improvisation was nothing less than
instant composition. After-all, how different was it for an improviser to 'come up with
something' in performance than it was for me to 'come up with something' and write it
down? Alternatively, how many compositions have been written without the composer
improvising various passages to see how they worked? It is this presence of
improvisation that leads Benson to conclude that all music making can be classified as a
specialised form of improvisation (Benson, 2003).
I would suggest there is a difference in music produced through composition than
through improvisation, and the reason lies in the approach to abstract musical form. As

29

has been mentioned, an instrumental performer typically plays in what Wessel and Wright
call the One-gesture-to-one-acoustic-event-paradigm (Wessel, Wright, 2002). From an
audience perspective, this paradigm refers to the correlation of the visual perception of
physical actions to musical output. We can consider this paradigm in an alternative way if
we consider its implications for performers. In this context, the one-gesture-to-oneacoustic-event-paradigm means the performer is forced to assemble musical material by
cognitively generating music close to the surface level granularity of individual musical
events.
This is not to say that more abstract musical constructions can't come about
through improvisation. Indeed, much of the skill of a good improviser is appreciated by
their ability to fit the material into larger, more abstract musical structures. Johnson-Laird
describes this quality of jazz musicians:
As a result of years of improvisatory practice, they can navigate their way
through chorus after chorus of the chord sequence and create a seemingly endless
series of melodies appropriate to its harmonic implications (Johnson-Laird,
2002, p. 416).
What is of note is that these abstract musical structures are assembled by
cognitively generating smaller, less abstracted events. A jazz improviser for example
might conceive and generate 'licks' as the atomic unit. A hierarchical order is imposed on
increasing levels of musical abstraction. For example, a 'lick' becomes the starting point
from which to slot into more abstract structures such as harmonic sequences, sequences
into sections and possibly larger forms.
To some extent this method of musical creation is shaped by the requirements
inherent in performance. This is a different method of generating music than through that
of deferred time composition: The composer can rework material after an attempted
realisation. A work can be conceived and created irrespective of how the music actually
unfolded in time. Abstract structures at any level of granularity, from individual notes to
the entire form of a work, can be considered without the same hierarchical order

30

generated by performance constraints.

Improvisation in performance offers a way to create music in a way that breaks
down the divisions between composition and performance. However, there are some
complications in simply adopting an improvisational practice as a means to perform
composition. On a practical level, to live code sequences of 'licks' as quickly as an
instrumental performer would be unfeasible. More challenging was that I did not want to
relinquish compositional working methods and approaches to abstraction. To do so was to
take the composition out of the performance practice.
In these first two chapters I have discussed some various ways in which musicians
and musical practice have sought to redefine the relationship between composition and
performance. In the next chapter I reflect on my own methodological journey which
attempts to address these key issues in a practice based project.

31

Chapter Three: Methodology

Using my methodological approach, I sought to find a common practice with which I
could develop both compositional and performance practices. The use of computer
software offered the possibility of both modelling compositional ideas, and facilitating
live performance. By developing my own tools in software, I had the creative freedom to
invent my own compositional techniques, and tailor them to work as performance tools.
In part, I wanted to avoid adopting compositional ideas embodied in pre-built
software systems (Ariza, 2005). Horacio Vaggione (2001, pp. 55-56) has noted that the
exactitude required by working with computers forces a composer to formalise musical
relationships more so than would normally be required when working without a
computer. As each tool I developed in software embodied decisions concerning the range
of possible musical outcomes of the tool, I was effectively making assumptions about the
musical setting in which the tool exists, how useful the tool would be, and why I would
choose to use it as I developed it. Thus by developing music-making tools in software, I
was formalising a compositional approach.
Iterative development as a model for artistic exploration:
Developing a compositional approach in software would not necessarily prove to be a
useful performance tool. However, the performance paradigm was relatively unknown to
me. I had little notion of how effective a particular compositional strategy would be when
translated into a performance situation.
My approach has been to use the software development process itself as an
exploratory means for developing a musical practice. Rather than work to a final
specification of the CAC system, its use in performance and the pieces I create with it, the
system developed through a series of small 'create', 'test' and 'evaluate' experiments. Each
experiment provided input into the next 're-create, test and evaluate' experiment.
This resembles a form of iterative development process, which is a common design

32

strategy for software development teams. Various styles of this kind of methodology exist
under the headings of 'Agile Development', 'Extreme programming', 'Feature Driven
Development' and 'Evolutionary programming' amongst others (Miller, et al., 1991). The
techniques came about largely to address the inflexibility inherent in developing to a predetermined formal specification. In a typical scenario, a prototype 'bare bones', yet
functional software system is given some sort of user testing. Further development is
guided by user feedback, rather than predetermined specification.
My motivations for adopting an iterative development methodology in an artistic
project are of course quite different to that which encourages its adoption in a commercial
environment. What appeals to me is the form of the process. The triadic strategy of
develop, test and redesign strongly resembles an artistic process involving creation,
presentation and introspection. By way of illustration, consider this example describing
the development of an artistic work, such as painting.
As the painter begins to work on the canvas, a new interaction takes place. He or
she is constantly faced with both physical limitations and new potentials, in the
very muscular activity of painting and in fresh perceptions of the growing
painting beneath the brush (Bohm, David & Peat, F. David, 2000, p. 157)
Here, Bohm and Peat are describing the generative process in which a painter
develops a painting though a kind of reflective feedback loop: the artists intentions are
reflected back to the artist as the painting grows beneath the brush.
Similarly, the Australian composer Richard Meale describes his compositional
method as exploratory: That's why I like to start at the beginning of the piece and work it
through, because then I can feel the momentum that is building up behind the piece
which, of course, is form (Meale in Ford, 1993, p.33). Here, Meale uses the
development of the piece to guide the direction of the piece.
Finally, Andrew Brown has proposed the Software Development as Research
(SoDaR) approach as a means of conducting research. The SoDaR approach identifies

33

software development as forcing it's practitioner to externalise ideas, stimulate action

and reflection (Brown, 2007, p.1). The SoDaR approach is an iterative cycle in which
analysis and reflection of the performance of the software system in a real-world situation
is used as a guide to the further direction of the both the research and the software itself.
My iterative approach developed the system through a methodology of design,
performance and reflection. An initial prototype of the system was developed until
functional enough for a performance. The system, as it existed at that point in time, was
then tested by rehearsing and performing in front of an audience. Following the
performance, reflections on the effectiveness and limitations of the system were noted,
along with ideas for improvements. These results were used to inform the next phase,
which followed the same procedure. A diagrammatic representation is provided in
Illustration 1 below.

Illustration 1. A model of my iterative methodological approach.

The iterative approach meant that the end-project is not defined from the outset. I

34

did not necessarily have to know what the final CAC library would do, or even what my
music would eventually sound like. Instead I anticipated that my artistic approach would
coalesce as the library developed and my engagement with it continued.
Ron Herrema (Herrema, 2006) has described how engaging new tools, specifically
Paul Bergs Lisp-based 'AC Toolbox' , in turn influenced the way he engaged his
compositional approach.
Furthermore, since I was working with a new tool, I was engaging my discipline
in a new way and exploring compositional thoughts that I otherwise might not have
explored (Herrema, 2006 p.7).
Through both the development and use of my own tools I found I was developing my
own approach to interactive performance through composition. New compositional ideas
would come about both in the use of the tools, but also while designing and implementing
these tools.
Implementing the methodology.
During the development phase, I would make notes on the musical techniques I wished to
employ. Initially, many of these decisions constituted fundamental infrastructure I
considered necessary for making music. For example, decisions were made on how to
represent pitch, whether to collect groups of notes and how to play them. Many of these
decisions were also based on my current familiarity with the technology I was using. My
knowledge of programming largely guided my decisions on what I thought was at least
'possible' to implement in software.
In the lead up to a performance I would conduct rehearsals. This largely involved
me writing some particular piece of code, and experimenting with ways the code could be
modified as if I were in a performance situation. To an extent, the effectiveness of the
CAC system was being tested at this point, however, this sort of testing really served as a
means of refining components that had been developed, more-so than the holistic
evaluation possible through live performance.

35

The performance represents the culmination of a period of design and

development. Therefore the performance can be seen as a kind of result. Of course, the
preparation toward a performance is a creative endeavour: It is unlikely that, given the
same conditions, the same performance would occur. However, the characteristics of a
performance can be measured in a variety of ways.
Following each performance I would compare aspects of the performance to the
objectives of the performance. I would separate the notes I made into three categories;
Technical notes, for example, concerned how the musical outcome in performance met
the desired outcome implemented during development and rehearsal. My own aesthetic
judgement was considered as a kind of sanity check on whether the musical outcome was
ultimately satisfying for myself as a performer. Thirdly, audience feedback was usually
gathered via informal discussions with individuals following the performances,
depending upon the circumstances of the performance. These three sets of notes became a
vital part of the new set of criteria on which to conduct the next phase of development
and performance.
Live coding and Impromptu
I elected to use the Impromptu live coding environment for the development of the
system (Sorensen 2005). By facilitating both the use of pre-built libraries and live
performance, Impromptu presented an almost ideal environment for this purpose. The
Impromptu interface is essentially a Scheme (Lisp dialect) programming language editor.
The Impromptu user is free to design algorithms and functions with all the flexibility of a
high-level general purpose programming language. The underlying software engineering
required to interface with audio systems, and organise the scheduling of events has
already been implemented 'under the hood' in Impromptu. Controlling audio-unit
synthesisers, sending MIDI messages or OSC messages amongst others is as simple as
using some additional primitives provided in the Scheme language used by Impromptu.

36

As a live coding environment, Impromptu also provided a unique opportunity to

engage in a performance practice. By live coding, I had the opportunity to perform
directly with the library of tools I developed, rather than concern myself with relatively
non-musical concerns such as interface design.
CAC Library Development
As has been mentioned in Chapter One, Computer Assisted Composition systems can
take many forms, from programming languages to packaged software tools. My concern
was to create a musical system in which a collection of music making tasks could be
defined and put together to form musical relationships. An overall musical practice
would emerge through the relationships forged in the collection.
To me, this implied the development of defined musical tools, each tool carrying
out a specific musical technique. As such, the form of my Computer Assisted
Composition system would essentially amount to a collection of tools to carry out
musical functions. I have used the term 'library' which in programming terms largely
amounts to a collection of functions. The aim my CAC system was to create a collection
of functions which provides a coherent system able to adequately represent compositional
concepts, whilst also prove effective in realising these concepts in a performance
situation.
I began by considering a model of how music is made. As a composer I had been
familiar with the role of making scores. As I became involved in computer music, I
became familiar with the popular audio signal processing and synthesis language,
Csound. Csound is a system which also emulates a traditional music making model.
Sounds are made by 'instruments' in an 'orchestra' playing notes in a 'score'.
I decided that I would also have a model consisting of scores. A score would
simply be a collection of data which could be read as notes. The question I had to answer
was, what sort of data would a score contain? In a traditional music score a 'note' would

37

usually contain information containing a pitch, dynamics, duration and possibly some
form of articulation. A score could consist of a collection of notes, instrumental parts,
phrase indications, tempo instructions and meters. There is also information in a
traditional score which is implied, relying on established musical convention and
performance practice.
There are aspects of the traditional music system which I had no desire to specify.
For example, I did not want to assume all, or any, of my work would observe a specific
formalised approach to music making; such as functional harmony or serialism or even a
scheme of my own determined in advance. As such, my score representation was very
simple. The aim of this being to leave the interpretation of score data as open as possible.
This would allow me to decide what a score could actually represent 'on the day'.
Initially, I defined scores as a collection of numeric lists. The meaning of the
numbers in a note was determined by position of the value. An early example of these
scores looked like this:

Illustration 2. An early example of a score.

The values in each note in this case were represented by pitch, velocity and duration
parameters respectively. This in turn influenced the design of a score player. The loopplayer, pictured below, plays through a score repeatedly.

38

Illustration 3. An early example of a score player.

At this early stage of development, there were many obvious limitations to the
system. In particular; the number of parameters for each note, used in both the score and
the player, was limited to those able to be accommodated by the Impromptu primitive
'play-note'; Note onsets were not specified and determined completely by the duration of
the previous note in the score; as a consequence, the player assumes the score format to
be a monophonic melody.
Nevertheless, this was the foundation for a working system. As the system evolved
to allow more musical possibilities, the players I developed became more sophisticated,
and the score format became more general to allow for greater expressive possibilities.
The basic template involving communication between scores and players was retained.
Composition Directed Development vs. Performance Directed Development.
Prior to testing the system in a performance situation, the decision of which tools to
include in the library was largely based on what I believed would work compositionally. I
believed that if the purpose of the tool was general enough to be a common technique for
many pieces, then it should be included. Whereas if the technique employed by the tool
was specific to a piece, or not conducive to be generalised, or if I wanted access to its
internal mechanisms, then it was more suitable to either commit the code to my own
memory or copy and paste the code during performance.
Nevertheless, the decisions about what to include in a library, and what to reserve

39

for performance were often less than clear-cut. For example, a function which would
ornament notes with sequences of additional notes seemed a useful enough technique to
include in the library. However, also useful would be the ability to have access to some of
the parameters within the function as it performs, such as changing the rhythmic
characteristics of the sequences. In this case it would be more convenient for me to have
access to the code which makes up the function.
When I did begin to engage in performances, numerous other considerations began
to influence the kinds of tools I would implement. During rehearsals I would try and
develop a piece by building up a series of musical processes to run concurrently. To
maintain continuity in the music I had to ensure that a process was at least long enough
for me to set another process in motion. This was not so easy, as I found that to kick off a
new process could take anywhere up to thirty seconds of typing. This is not a great length
of time for coding, however it is much too long to tolerate inactivity or silence in musical
time.
Thus the tools I developed were modified to be able to generate processes of a
greater duration, or even processes which never stopped, such as the repetitive loops
described earlier. This solved issues of continuity, however it raised new challenges: The
expiration of a 'finite time' process becomes difficult to predict during performance. This
meant synchronising new processes or starting a new section at the time a particular
process finished was difficult. The unpredictability needed to be taken into account as the
piece develops, which in turn influenced the way in which a piece of music is put
together, usually by not having the piece rely on synchronised events.
An 'unlimited time' procedure such as a repetitive loop runs the risk of becoming
tiresome to listen to. When the code for a loop is presented in the Impromptu editor, then
it is possible to redefine the loop to make it more interesting, or alternatively to stop it.
The internal code of a library procedure is hidden from view, which limits this option.

40

There was no single solution to these issues. I present them here as a way of
illustrating how paradigms of library development, compositional objectives and
performance considerations began to relate to each other, and influence each other as
development continued.
As mentioned above the methodological approach was based on a learning by
doing process. The methodology discussion continues in the following chapter with a
discussion of how this process played out during three performed pieces.

41

Chapter Four: Performance and Reflection

The previous chapter explained the methodological framework I put in place. It described
an iterative process which would be used, not only as a means of developing a software
system, but also how this methodology would inform the development of an artistic
practice. This chapter details how this methodological framework was applied in realworld situations.
I will discuss each development cycle under the heading of the particular
performance associated with it. The qualities of the performance can be seen as a kind of
result of that development cycle. Reflection on each performance, its successes and
failures, serves to inform the criteria which the next cycle of development aims to
address.
Performance 1: Mirroring
Mirroring is so named as it was presented at the 'Mirroring' forum, a weekly series of
seminars in the Music and Sound department of the Creative Industries Faculty at the
Queensland University of Technology. The forum typically involves music researchers
and practitioners presenting research they have been involved in to their peers. The
performance at Mirroring on the 21st of September 2007 was my first experience of live
coding, and demonstrates an early version of my CAC system.
The audience was presented with the image of the code used to generate the music
projected on a screen as it was typed, for viewing by the audience. The performance was
followed by discussion and questions, the purpose of which was to gather feedback and
observations to direct the further progress of the research. I was interested to see what
sort of reception the live coded mode of presentation would receive, and whether the
capabilities of the CAC library, and my live coding abilities could be considered of any
value amongst the audience of music researchers and practitioners.

42

Preparation and Development

At the time I scheduled the performance at the forum, I did not have a pre-written
piece of 'work' ready to perform. I had the assumption that the capabilities of my CAC
library would make creating a piece a relatively trivial matter. Nevertheless, I wanted to
be prepared, and was not confident enough to completely improvise with code. After
some attempted rehearsals my understanding changed dramatically.
I found that rehearsals were as taxing and laborious an any instrumental
performance. Attempts at 'free' improvisation, without prior planning, rarely resulted in
satisfying musical experiences. The primary cause of musical dissatisfaction revolved
around timing and continuity. The time taken to code a musically interesting process was
often a great deal longer than the time required to sustain musical interest for a listener.
I noted some of the factors which contributed to an unsatisfactory temporal
experience of the performance. For example; my own unfamiliarity with the technology,
including the Scheme language, the Impromptu system and my own CAC library, would
require me to stop physically 'performing' (i.e. typing code) and consider the next course
of action. What seemed like only a few moments to remember the name of a particular
function; recall the number of arguments required by a function; or the use and expected
output of a function resulted in an unacceptably lengthy period in musical time.
Pondering on how to generate a phrase algorithmically, or indeed any moderately
complicated problem solving could take anywhere from several minutes to something
much longer than was anticipated for the entire performance.
Running several musical processes concurrently seemed like a useful way of
sustaining musical interest while giving me a chance to code up something new.
However, concurrent processes also served to distract me in performance. It was tempting
for example to make numerous 'micro' changes to a process. While small scale changes to
the characteristics of a musical process can extend the musical usefulness of the process,

43

tinkering with musical processes on a small scale can also reach a 'limit of interest'. More
dramatic changes in the music often require more work, and the time taken to implement
this this also needs to be considered.
I decided to plan the course of a piece much as I would sketch a 'deferred time'
composition. What I was able to specify musically did not necessarily have a ready made
counterpart in my CAC library. I found that a written or diagrammed musical sketch
omitted much of what needed to be specified in code. Eventually, I concluded that the
code itself served as the 'real' specification for what was to occur musically. My 'rough'
sketches, uninformed by the capabilities of the CAC library and performance
considerations proved to be only of limited value.
Rehearsals became a significant contributor to the refinement and additional
development of the system. With a performance date looming, the challenge was to limit
the time spent implementing features and bug fixes in favour of actually producing a
piece. Where half an hour could prove invaluable as rehearsal time, in could also prove to
be the tiniest of code tidy-ups to prevent a potential problem.
Performance
The performance of Mirroring highlighted the need to accommodate mistakes in
performance. By way of comparison, even a successful instrumental performance could
be riddled with mistakes known only to the performer, such as the incorrect fingering
used in a passage, or ignoring dynamic markings. Similarly, coding errors can range from
the benign to the disastrous. On some occasions, a mistake in coding can lead to
unexpected results, which may or may not be musically useful. More often however
this will cause a particular process to fail. In some cases the entire performance will come
to an abrupt end. This is exactly what occurred during the Mirroring performance.
Luckily on this occasion I had previously recorded a movie screen-capture of a rehearsal.
The remainder of the recorded piece was presented to a polite audience. Nevertheless, the

44

interruption and subsequent pre-recorded playback was not a desirable outcome.

Reflection
Interestingly, the feedback I received suggested that the piece was more
appreciated as a performance after I incurred the technical setback. The realisation by the
audience that there was a danger of failure in live coding practice served to enhance its
appreciation as a performance practice. In this respect, a live coding performance bears
similarity to other kinds of performances which involve a display of some kind of
technical skill. The possibility of the performer making a mistake plays an important part
in providing a context for appreciating technical ability.
Unlike a performance using traditional instruments however, a single incorrect
finger movement caused my instrument to completely cease operating. Therefore, in
resolving technical issues, I wanted to reduce the possibility of an outright performance
failure, while balancing some of the legitimate risks inherent in performance. In reality, a
fail-safe system was unlikely. However some simple methods were introduced to reduce
careless errors and at least continue performing even if mistakes were made.
Following the performance, I was asked questions by the audience. In addition to
technical questions, a number of interesting questions were raised concerning the
compositional process for the piece I had just presented. For example, there was a lot of
repetition used in the piece; was I some sort of minimalist composer? In reality my
approach for this piece had largely been guided by technical practicalities, and this in turn
had provided the stylistic quality of the piece. Repetitive loops for example are relatively
easy to implement, as are small changes to those loops over time. Similarly, as it takes
time to set up processes, it is perhaps not so surprising that the piece evolved from slow
simple patterns to larger structures.
Following the Mirroring forum, I considered the implications of allowing technical
practicalities to guide the development of the piece. I could not help but feel I had

45

deferred actual compositional decisions altogether. Instead I had applied the best musical
setting which I could manage given the characteristics of the system I was using. Yet was
this not the outcome to which I was aiming? My premise from the outset had been to
develop a compositional approach in conjunction, and embodied by, the tools I had
developed.
A number of other issues raised at the Mirroring forum had begun to concern me.
In particular: If I was not improvising in the performance, how can this be considered a
form of performed composition? This particular question also provoked another: How is
performed composition different to improvisation? These questions lead me to consider
the kind of relationship which exists between composition and performance as discussed
in the second chapter. They guided my decisions over how I should prepare pieces, what
contribution the CAC library makes to an artistic practice, and what role improvisation
should play in the presentation of a piece.
Performance 2: The Forest
The performance of The Forest occurred on the evening of the 17th of November
2007 in a caf (of the same name) close to the city centre of Brisbane. In contrast to the
university context of the Mirroring performance, this performance was open to the
public. I had little clue as to what the reception might be to a live coded performance in
this environment. With the added concern of repeating Mirroring's technical mishaps, I
was decidedly cautious in my approach to performing this work.
Preparation and development
On this occasion, I had decided to pursue a particular approach to creating music. I
wanted 'The Forest' to be a piece concerned with parameterised manipulation of sound,
rather than note-based music. The work is book-ended by a pre-recording of a
thunderstorm which undergoes a number of sound-shaping transformations.
Many of the tools developed for the performance provided means for shaping

46

parameter envelopes over time. For example, I developed tools to exponentially control
the position of loop points in a sample player. In an effort to generalise these tools as
library functions, the same tools could be used to control other parameters, such as gain
levels.
Performance
The performance followed two Audio-Visual works which ran somewhat overtime. As the last performer of the evening, I sensed the audience was reaching a limit of
their attention span. In rehearsals I had estimated a performance to last for approximately
half an hour. Surprisingly, I found I was sufficiently versed in the possibilities of the piece
and the system so-as to shorten the performance, whilst still conveying much of what I
wanted to. Whilst this was a relatively simple alteration based on the mood of the
audience, I was pleased that I had been able to conduct some moderate improvisation
during the performance, as this was a skill I had aimed for since the last performance.
Reflection
The ability to improvise and modify during the course of the piece exemplified the
differences between my work and the fixed-media audio-visual work which had been
presented earlier. Another interesting aspect of performing at The Forest, was the
noticeably different engagement from the audience to a performed work, than that of the
pre-recorded Audio-Visual work. As an observer pointed out to me, the audiences
attention concentrated, and alternated, between the activity on the screen, and myself (the
performer) typing away on the laptop. This performative aspect of the presentation of a
work suggested there was something significant about the presence of a performer, and
the act of performing, to engagement with the work. This too was noticeably in contrast
to the passive reception of earlier pre-recorded works.
I had also managed to complete the performance without technical problems. I had
effectively achieved what I had aimed for with this stage of development. However, the

47

experience of this performance was not without some troubles: I had such a large
collection of tools in the CAC library that I struggled to remember their names, the
meanings of their arguments and their output. During the performance, there were a
number of times when I would hesitate to embark on a particular musical activity,
because I could not recall all the tools necessary to complete the task.
This also demonstrated a performance constraint I had not been familiar with in a
compositional context. I had assumed that a large collection and variety of tools would
offer more choices in the available musical outcomes I was able to achieve. This is
certainly what appealed to me in a compositional context, where more tools presented
more musical possibilities. In performance, such a large collection of tools requires more
reliance on memory, and serves to increase the possibility of human error.
To reduce the possibility of a performance catastrophe, I had packaged up many of
my tools into single-line commands. While a single command can be powerful in some
circumstances, there are a few problems that arise when a performance relies on too many
tools. One problem is the lack of association to a musical process. Other than the name of
a particular command, there is almost no indication as to what the actual musical effect
might be. From the audience perspective, the performance seems to consist of numerous
abstruse tools, the presentation of which disconnects the audience from the musical
process. Obscuring the correlations between musical activity and coded activity largely
defeats the purpose of performing in front of the audience in the first place
My own experience as the performer also felt unadventurous. While I had gained
enough skills for some moderate improvisation, I felt more constrained than I had during
the Mirroring performance. The reason for this was the inaccessibility of the processes
after I had executed them. As I had packaged up the tools, the internal algorithms which
constitute the process were now inaccessible. Thus in performance, once a process had
been executed, the process was committed. For short events this is acceptable, however,

48

for lengthy processes which have a significant influence on the course of the music, this
leads to inflexibility during the performance.
Thus while I had addressed many of the issues raised since the performance of
Mirroring - the system was less prone to technical failure, and I was comfortable enough
for some moderate improvisation to take place during performance - new issues had
presented themselves: The unwieldy collection of tools now conspired to contrive my
performances. The inaccessibility of musical processes rendered improvisation as a
relatively harmless activity. The obscured packaging of code defeated the purpose of a
live coded performance presentation.
The result of this required a re-think in terms of what constituted a useful system to
perform and compose with. A change of direction in the course of CAC development was
needed. Instead of building a vast collection of tools, my attention now turned to the
design of the overall system as a means of providing musical expression.
CAC Development after The Forest.
After the performance of The Forest, the CAC library underwent the longest and most indepth development phase of the project. Much of what had been previously designed was
re-written in order to address the concerns which had emerged from the previous
performance. Many of these concerns revolved around the relationship of the usage of the
CAC library with the performance experience.
One simple solution was to simply remove a number of the functions in the library.
This would reduce the problems of committing the names and uses of tools to memory.
However, this would also reduce some of the expressive possibilities of the system, which
did not seem acceptable. Furthermore, as development continued and more functions
were added, it seemed likely that this problem would reappear.
Another possibility was to reduce the scope of what the tools in the library try to
achieve. Rather than attempt to create a singular tool for controlling a volume envelope,

49

the various tasks of creating a volume envelope could be broken down into smaller
components. Of course, the smaller components could be the primitives of the
programming language, however, I still wanted the library to encapsulate musical ideas
rather than generic programming ideas.
The collection of tools needed to behave like elements in a language. I needed a
means of linking the tools in such a way that the combinations provided new means of
expression. To an extent the syntax of the Scheme language was already available and
could be used. However, the self-contained tools I had created didn't really take
advantage of this. There was no system in place for re-combining these tools as elements
of a larger structure. I had effectively been removing the 'linguistic' power of a
programming language. This translated musically into limiting the expressive possibilities
which arise by combining and connecting musical elements.
My solution involved two important structural changes. The underlying principal
of 'scores' and 'players' remained. I now wanted to encapsulate many of the tools into
'generic operators'. The operators would operate on scores, or players, as if those items
were data. As an example, an addition operator :+ could be used to add notes together to
form a score. Alternatively, it could add entire scores together to produce larger scores.
Finally, I also wanted the :+ to add players together, just as if players were also data.
There are a number of ways to implement generic operators in Scheme. I chose the
'data directed' style described in The Structure and Interpretation of Computer Programs
text by Abelson and Sussman (1996). This method is generally recommended when the
types of data are few, and the operators are many. In this case, my only data types were
events (notes), scores (collections of notes) and players (functions to play scores). My
operators would provide various means of building, slicing and re-organising scores and
players. Much of the re-work of the system revolved around 'typing' data, for which I
employed a simple 'object' based approach, and rewriting existing functions to

50

accommodate new data type formats.

As a simple example of how previous functions were now employed as operators:
An individual tool such as sc:pop-tail was a function to remove the last note from a score.
This idea was now incorporated into the operator symbol :< , which would chop off a
given number of events from the tail of the score. A certain logic was employed in that
symbols such as :> or :>< would have the same effect on a score, from the head, or a
section in the middle respectively.
Another powerful concept in Scheme which I employed in the operator system,
was to consider procedures as data. In this case, a player procedure could equally undergo
manipulations by the same operators. As an example, where (:append score1 score2)
would create a new score combining score 1 and 2 in a particular way, (:append player1
player2 player3) would 'append' players 1, 2 and 3 by creating a new player, which would
execute the players in sequence.
The second structural change was to enrich the scores by allowing them to contain
procedures, rather than just numerical values. When a player reads a parameter in an
event which is a procedure, the player will execute the procedure. The score now behaved
more as a 'meta-level' sequence of events, which mixed both low-level note and
parameter data with higher-order abstract functions.
The notation in scores began to look quite different as new concepts were
introduced. An example of what this new notation now looked like is given in illustration
4, as seen below. This score contains a mixture of note events, random functions, and
even an event player. The use of the '~' character or the '~begin' name is special
instruction to tell a player to execute the expression only when scheduled by the score.
Parts of the score are composited by using some of the generic operators (:append and :+)
mentioned above.

51

Illustration 4. An example of a score, including a mixture of operators,

players and embedded functions.
This score may look obfuscated; this is deliberately so. What I hope to illustrate is
not so much that scores are now complicated, but that scores are now able to represent
musical expressions of a much higher order of abstraction than previously offered by the
use of numbers.
Also worthwhile pointing out is that in performance, a score would typically begin
as a much simpler entity, such as a single note. Throughout the course of the
performance, code can be 'injected' into the score creating more complex musical results
each time it is played. The correlation between growth in musical activity over time and
the proliferation of code embedded the score is actually quite easy to apprehend.
Performance 3: Soiree
Soiree was performed on August 12th, 2008 at the 'Backyard Soiree I', the first of a
series of computer music based performances hosted by Andrew Sorensen. The Soiree
performance occurred quite literally in the backyard of a private home. The evening
consisted of four live coding performances. The music was delivered to each audience
member through their own set of headphones, whilst a projector displayed screen-casts of
code as it was typed2.
2 Recorded movies of these performances exist online at the following locations:
http://runtime.ci.qut.edu.au/pivot/entry.php?id=29 , and
http://impromptu.moso.com.au/gallery.html (last accessed on 11/01/08).

52

Preparation
Soiree had comparatively minimal rehearsal time compared to the other
performances. The actual form of the Soiree piece came about only within the last couple
of days before the performance. Instead of 'composing' the piece by planning actions and
committing them to memory, much of the rehearsal time was spent gaining familiarity
with the new way of working with scores and players. Soiree came about largely through
improvisation and experimentation. Several alternative pieces were also explored and
abandoned, before settling upon the format of the piece for presentation.
Performance
In performance, Soiree progressed in an improvised fashion, following a rough
template which had been formulated in the last couple of days before the performance.
No adverse coding issues hindered the performance this time. The piece was performed
for a duration of approximately twenty minutes, before it became physically difficult to
type due to the extraordinarily cold weather!
I wanted to show off some ways the system worked. Scores were constructed with
various operators. Much of the piece revolved around manipulating score structures while
players repeatedly iterated through them. Whilst not necessarily the only way to perform
with the CAC library, The design of the CAC library is conducive to this method of
interaction.
As a little game with the audience, I defined scores and players with names of
various people sitting in the audience. There was obviously some humour in doing this,
and the mood of the audience was lightened. The effect was also useful for engaging the
audience in a way that reminded them that there was a real person performing.
The other consideration for the work was the handling of form. There is a tendency
for live coding pieces to have slow or minimal beginnings. This is especially the case
with performances which start 'from scratch' with little or no code to begin with. This is

53

understandable, considering the way code is typically used in performance; to initiate a

musical process, to increase complexity in a process or add additional process layers to
the piece as a whole. This is how I approached the Mirroring work at the beginning of
this project.
This progressive increase in complexity in live coding pieces works formally in a
musical sense as it emulates established compositional techniques for musical growth.
For example, a common formal development in late-romantic western-art music onwards
onwards is to follow a path of gradual increase in tension toward a climactic point, before
finding resolution. This would typically be achieved by an increase in harmonic
complexity and rhythmic density, whilst retaining cohesion by transforming pre-declared
musical material, as opposed to the introduction of new themes.
Similarly, using algorithms to generate content can be the ideal vehicle for
providing a logical centre to a particular process. Algorithmic-based music can emulate
the same sort of Platonic cohesion and continuity found in traditional music and the other
arts. Added to this, in a live coding situation it is algorithmic complexity which can then
be modified to follow the path of tension and resolution.
However, there is no technical reason a live coding performance needs to follow
this model. In considering possible forms for Soiree, my aims were relatively pragmatic.
The path of evolutionary growth in musical processes would still be prevalent. However I
also wanted the narrative of the piece to change direction in unexpected ways throughout
the course of the performance. One strategy to do this was to introduce musical material
which was unrelated even deliberately in contrast to - the context in which it arises. In
Soiree this comes about as much through the choice of sounds as the transformations they
undergo. In particular, at one point there is the introduction of a dramatic collection of
thumping sounds which evolve into a pitched rhythmic pattern.

54

Reflection
The presentation of scores, and the manipulation of these throughout the
performance was a curious experience for some in the audience who were already
familiar with live coded performances, as the meaning of particular functions and their
use was unfamiliar to them. Nevertheless most in the audience were still able to perceive
correlations between my coding activity and results in the music. This was a significant
improvement upon the audience experience of The Forest.
In Soiree I was able to conceive an outline of the course of the music prior to the
performance. This is a noticeably different situation to what I experienced with
Mirroring. In part this is testament to the improved expressive capabilities of the CAC
system. Also by this time I was quite familiar with how the CAC system worked, what its
strengths were and how to capitalise on these. The decisions I made in performance were
in sympathy with design of the CAC system, and with the musical model which I had
effectively developed.

55

Findings and Conclusion

The process of locating my work in a practice led research discourse has allowed me to
combine my interest in computer music composition with my desire to perform. I
effectively conducted an experiment in which I developed a practice by doing the
practice. I will now briefly mention the most significant outcomes that I have learned
from this process.
A significant aspect of this project has been the development of the CAC software
library. The performance of Mirroring used some simple 'scores', which largely amounted
to a table of numbers. There was a single convenience function to make a score quickly
and several methods of retrieving score and setting score values. There were also a dozen
'players' available to play scores in different ways. The Mirroring performance largely
revolved around using the Scheme language primitives to manipulate list structures which
made the scores.
The library at the time of The Forest performance consisted of hundreds of
functions. Many of these were used as infrastructure for other 'higher level' tools. For
example, a tool to create accelerandos used nine other functions in the library. As
mentioned earlier, in performance this led to the tendency of using these higher level
functions as standalone commands, rather than elements within a larger system.
The reorganisation of the CAC library following The Forest concerned itself with
the design of an entire system. Many of the 'higher level' functions were removed, or
incorporated into other tools. For example, the dozen score players could now be
emulated with a single player. By the time Soiree was performed, almost none of what
was coded used scheme primitives. The performance largely relied on the syntax of the
library. Thus the capabilities of the library as a system bore a substantial influence on the
nature of the music that I performed.
The 'idiom affinity' attached to computer music software systems, mentioned

56

earlier (Ariza, 2005) describes a relationship between software design and musical
outcomes. However, it is worthwhile considering the relationship between the composer
and software tool which cause this to be so. Andrew Brown has described this process as
a reflective process, whereby the capabilities of the system are absorbed and manipulated
by the composer. This is not to say the medium doesn't bear an influence on the outcome
or the process. However rather than see this as technology constraining what the
composer would otherwise do, the composer in reality uses this environment as a means
for artistic expression. The composer's compositional approach and method adapts with
the facilities offered by the computer. Thus the composers perspective is intimately
associated with the nature of the medium they are using (Brown, 2003, p. 225).
Composer and cognitive psychologist Otto Laske suggests something similar when
he describes the role the computer plays in the musical understanding of the composer.
For Laske, all composition is a self-referential activity such that realising a composition
(musical output) influences the musical framework (the knowledge and grammar
systems) of the composer. Developing software on a computer effectively places the
computer as a component of the compositional method. However, it is a component
which externalises and forces the explicit definition of elements of the compositional
process which would otherwise be guided by historicity or methodology (Hamman on
Laske, 1999, p.47).
In the case of my own work, this implies a reflective process, in which my
approach to creating music adapted to the capabilities of the CAC system, whilst at the
same time the capabilities of the CAC system were developed based upon my own
compositional approach. Through software development the technology evolved
symbiotically with the practice. The expressive capabilities of the CAC system were
manipulated such that both the CAC system and my approach to making music found, or
at least approached, a common meeting place to realise a musical expression. This is

57

slightly different than describing a relationship between my musical thought and the
computer. More apt would be to say that my engagement with the technological medium
is such that software development becomes an aspect of my musical creativity.
Computer collaboration as an indicator of a hybrid musical practice.
That my approach to music making also underwent a transformation is evidenced by my
different experiences during preparations for each performance. Recall for example that
my approach for Mirroring had been to pre-compose the entire piece. This lead to other
problems such as being unable to find ready-made tools in the CAC library for a
particular musical idea. For Mirroring, there was a disconnect between my musical
understanding and my understanding of how to realise these ideas using the CAC library
in a performance situation.
By contrast, my approach for Soiree involved improvisation; a musical practice I
had been hitherto unfamiliar with, and which had seemed implicitly contrary to what I
understood as composition. The engagement with the CAC library, and the experience of
performance had lead me to approach making music in an entirely different manner to
how I did so previously.
Understanding the nature of Performed Composition.
By altering my own conception of making music from a deferred time compositional
practice to a performed practice I felt I had arrived at something resembling the hybrid
practice which I had hoped to achieve. My activities when rehearsing, improvising, or
developing software became apposite to the practice. It was the change in how I
approached creating music which I took as an indication that I had completed the research
objectives.
How then can the nature of the artistic practice I have engaged in be discussed?
Media choreographer Johannes Birringer points out that the particular capabilities and
limitations of media technology in the arts are capable of redefining the way those arts

58

are conceived at all. Thus dance made exclusively for film has produced an aesthetic for
'video-dance'. Marionette theatre has a marionette aesthetic, distinct from regular theatre
(Birringer, 1999, p.366). Similarly, photography has developed its own aesthetic which is
particular to photography and distinct from other visual arts. Likewise, computer music
practices also harbour their own aesthetic criteria.
My own practice can also be considered within an aesthetic based on its own
technological parameters. This is not to suggest that the practice I engage in is an
exemplar of a new hybrid practice. Instead it suggests that the process used in producing
the work contributes to the aesthetic of the work. I will now consider the process which
produced my work.
By intuitively developing and reflecting on performances, I initially attempted to
recreate my understanding of how music is created. I began this journey from a position
rooted in western art-music compositional practice, and some aspects of my
compositional predilections are evidenced by aspects of the CAC system which uses
concepts such as 'events', which largely equate to 'notes' in a traditional music sense, and
scores. Similarly, 'players' interpret these scores, and represent in sound largely verbatim
whatever instructions they contain. I had recreated a small model of my own
understanding of the musical paradigm.
The danger with such an approach is that my practice would mimic aspects from
traditional music making idioms. By attempting to mimic the outcomes of those practices,
I invite my own work to be held up in regard to work produced in this way, rather than as
a practice in its own right.
However, my practice did depart from the traditional music making model.
Developing a live music system and using it in performance influenced the kind of music
I made, and at the same time influenced how I thought about making music. I no longer
thought of music making in terms of a binary opposition of composition and

59

performance. The journey concluded with my altered conception of making music from a
deferred time compositional practice to a performed practice.
Concretising an understood musical model in software, allowed me to consider the
paradigm objectively. From an objective position it was possible to consider and
manipulate elements of the modelled paradigm. For example, in software I was able to
enhance the role a 'score' had in performance, by embedding functions that would only be
decided at the time of performance. By gaining familiarity with the modelled paradigm,
manipulation of the paradigm in software could be echoed in the transformation of my
own artistic practice. Thus I also began to incorporate improvisation in my performances,
as this committed a move away from pre-composed work.
As my familiarity with the technology I was using, and the performance medium
itself grew, the combination of compositional ideas, and improvising musical processes in
performance combined to produce something new, which neither fits the western-art
model of music making, nor entirely fits the model of instrumental improvisation.
What I ended up creating was a practice which incorporates the ideas from which it
originated, however the ideas are employed in new ways to create its own practice. The
journey not only helped determine the nature of this practice, it also changed the way I
think about creating music, and allowed me to create a different kind of music, through
different means as a result.
The objectives of this research, as outlined in the introduction, were to determine
the nature of the artistic practice that emerges when combining software development,
composition and performance. The most significant conclusion from this experiment is
that software development can facilitate the emergence of an artistic practice which
combines some aspects of composition and performance. However, it would be more apt
to consider this practice in its own right, rather than in relation to each of these activities.
In part, this is because there are practical limitations in what can be transferred between

60

each discipline: Realising compositional techniques in performance is a compromise with

what is technically and cognitively achievable. Furthermore, in approaching the task by
combining such well established practices, the practitioner is likely to begin by emulating
these practices as they initially understand them. To combine composition and
performance in software involves the practitioner adjusting to their own understanding of
what composition and performance actually is, both in relation to each other and in
relation to what they can realise in software.
Transferrable outcomes
Much of this journey into an hitherto unfamiliar mode of music making, for myself, has
been introspective, and the knowledge experiential. Nevertheless some observations of
this journey can be useful for practitioners developing their own practice. This is
particularly the case when attempting to consider the development of my practice from a
relatively objective standpoint. This journey can serve as a guide for practitioners
wanting to step outside their current practice into territory they may be unfamiliar with.
In particular this thesis demonstrates a means of allowing the feedback from the
experience of 'doing' performance to inform the next stage of development and planning
of future work. This approach blurs the relationship between planning a creative work
and the realisation of the work in performance. Ultimately, it is an approach which
relinquishes control over what can be achieved conceptually and allows the practice of
making creative work guide artistic development.

61

Appendix I: Computer Assisted Composition System Usage and Features.

This appendix outlines some of the concepts and typical uses of the CAC library in
performance. Whilst a method of use is presented below, it is by no means the only
possible use of the tools available. As such, a list of the available functions and their
abilities is also provided. The CAC library presented here is the library as it was at the
conclusion of this research.
Events
An 'event' is the equivalent of a single musical note. Each event consists of parameters,
which describe aspects of the note. The format of the parameters is similar in style to
Csound score events: The first two parameters are used as relative onset-time (or delay)
and duration respectively. Most of the event players expect a further two parameters
which are usually used to represent velocity and pitch. Additional parameters can also be
specified in an event, the meaning of each parameter being determined by the instrument.
Significantly, events need not only contain numbers. The 'Player' object for example can
read procedures within events. It then executes the procedure at the time specified for the
onset of the event.
Examples of events:
An event can be defined using the 'make-event', 'event' or 'ev' procedure. The
different names all perform the same operation:
(make-event 0 1.5 88 60)
An event such as:
(ev 2 1.5 88 (lambda () (random '(67 60))))
specifies that at a time of 2 beats, a note with a randomly selected pitch of either 67
or 60 will be played.

62

Scores
Scores are collections of events. Events in scores can be in any order, however each event
should consist of the same number of parameters. Scores can be created by combining
events in various ways. The simplest example of this is by using the :+ operator, which
collects events into a score:
(define myscore (:+

(make-event 0 2 80 60)
(make-event 0 2 80 64)
(make-event 0 2 80 67)))

Players
Once a score has been defined, a 'Player' can be used to read the score and send audio
messages to a synthesiser such as Csound or an AudioUnit. There are a variety of Players,
however the most powerful is the 'make-player' or 'player' object. An instance of a player
is created by providing make-player with a name, instrument and a score as arguments.
The named player can then be started at a specified time.
;Instantiate 'myplayer' to play the *violin* instrument reading myscore.
(player myplayer *violin* myscore)
;start myplayer in three seconds.
(myplayer (+ (now) (* 3 *second*)))
The player has numerous features which can be accessed with a pseudo object oriented
interface. For example, to modify the pace by which a score can be read, the pl:settimemults! method can be applied:
;read the score in half the time.
(myplayer pl:set-timemults! '(0.5))
Operators
Events, Players and Scores can be manipulated using operators. For example, the
:append operator can be used on events to create a score in which each event begins
after the previous event has finished. Alternatively, :append can be used on scores to
create a larger score, each of which follows the last event of the previous score. The
:append operator can be used on players as well. In this case when each player has

63

finished reading its score, the next player begins.

Live Coding CAC Library for Impromptu:
Outlined below are descriptions of each library function. This list is not intended as a
manual for use. Rather, it is provided here to given an overview of the capabilities of the
CAC library. Not described in the list are supporting functions whose sole purpose is to
assist the implementation of another tool, or other infrastructure objects used to support
the library. Commented source code of the CAC library is provided on the accompanying
DVD-ROM.
Name

Description
Miscellaneous Helpers

rescale

Taken from Taube, H. Notes from the Meta Level, p 161.

Re-scales values from one range to another

limit

constrains a number within a minimum and optionally a maximum range.

wrap

wrap behaves like the modulo function, but operates within a range. Result is
inclusive of lower and upper bounds. e.g. (wrap 5 2 4) => 2

make-line

returns a function which calculates linear values

expt-curve

Returns an exponential curve function which accepts a steepness argument.

Calculates values between the points specified. A steepness of 1 reproduces a
straight line, 0.5 produces an inverse (logarithmic) result.

+-

;+- sums randomly positive or negative versions of each value in the argument
list

sched-exec

A wrapper for callback. evaluate the body at time. The body can be any
expression.

wraps any expression into a no-argument procedure. Useful for inserting

expressions into scores, and letting players evaluate the expressions at the time
specified in the score.

gen-recycle

Returns a state saving generator which resets itself after iterlimit number of
iterations. Useful with number counters.

counter

an integer counting generator. Begins again when stop is reached.

countdown

as above, counting down.

brownian

generates numbers in a random walk between bounds. Optsteps is a list providing

a selection of allowable stepsizes.

list-gen

Creates a generator which generates values in a list.

defineinstrument

Use this to specify either Csound or AudioUnit instruments.

au:audio-unit? predicate for instrument type

cs:Csoundinstrument?

predicate for instrument type

urge

Returns the evaluated result of an object if the object is a procedure. Otherwise,

64

just returns the object.

macro-apply

apply a macro to a list of arguments

repeat-until

Executes an expression repeatedly at a specified interval.

make-global

define a global variable, irrespective of the scope in which it is defined.

List Processors

last

return the last item in a list.

list-head

returns head of a list up to the index specified. Opposite of built-in 'list-tail'.

slice

return a section of a list between specified indices.

list-fill

returns a list of length n, filled with objects.

truncate

truncates a list to be the specified length. Lists which are lengthened repeat their
contents.

append!

append a list to a list in-place.

append-item

append an individual item to a list.

append-item!

append an individual item to a list in place.

safe-car

returns null rather than an error if no car is available on the list.

safe-cdr

returns null rather than an error if no cdr is available on the list.

insert-atindices

insert an object into a list at multiple specified indices.

flatten

flatten a list of items one level of depth.

scale-list

Scales numerical list values by a factor with the first value retained as the base
value.

scale-list!

In-place version of scale-list

list-refs

returns a list of values referenced by a list of indices.

intervaldistances

returns the absolute intervals in a list to a given reference value

get-index

Returns the index in the list with the closest match to the given numerical value.

get-position

Finds the index of the object in a list. Same as built-in cl:get-position in

Impromptu with a weaker equality test so-as to allow any object comparison.

vget-position

Finds the index of the object in a vector.

get-positions

Returns a list of all index positions in a list for the value. Useful to find
duplicates.

get-indices

Given a list of values, returns a list of indices indicating positions of the values.

vectorgetindex

Returns the index in the vector with the closest match to the given numerical
value.

match-val

Returns the closest value in the list or vector to the value provided.

match-vals

Returns a list of values in the list or vector to a list of values provided.

expify-lst

Modifies a list of values by applying an exponential curve with a specified

steepness to each value. Start and end points in the list remain fixed.

member?

predicate for determining if an object is in a list

merglsts

Merges any number of lists

mod-listndx

Returns a new list with the entry at the index replaced with a specified object.

65

permute

Returns a permutated copy of a list.

permuteseq

Appends a number of permutated copies of a list

durations

Returns a list of differences between values, with multipliers and constants able
to be applied to the values.

durs

Simplified version of durations. Multipliers and Constants are predefined.

rh-builder

Given a list of values, returns a list summing the values repeatedly until a
specified duration is reached. Useful for generating rhythmic sequences.

filter

From Scheme Cookbook: Removes elements in a list according to predicate test.

xrange

returns a list of integers ascending from start to stop.

xrange2

returns a list of integers from start to stop in a sequence according to a

comparator.

scaled-range

creates a list of values, increasing between limits, of a given number of

equidistant steps.

accum

Sums each value in a list to the previous value. Returns a list.

longest-list

Return the length of the longest list in a list of lists

ziplst

merges any number of lists of any length. Returns a sorted list.

lproc-eval

Evaluates any procedures in a list, and returns a new list with evaluated results.
Useful in scores when combined with the ~ macro.
Functions for working with Scala Scale Files.

scala:readscale

Read a scala scale file, and return a list of cent equivalent values

scala:cscale>mscale

Return a list of 128 'real' midi note number equivalents from a list of cent values.

scala:midi>hz

Convert between midi note number and frequency in cycles per second.

scala:cscale>hzscale

Returns a list of 128 hertz values from a cent scale.

Functions for working with Event Objects

Contents

Return the data of an event or score object.

event?

predicate for checking if the object is an event.

event-ref

Returns the value of the event at a given index.

get-evdur

Returns the duration of the event.

get-evvel

Returns the velocity (amplitude) value of the event.

get-evpit

Returns the pitch of the event.

get-evtv

Return the onset time of the event.

set-evdur!

Set the duration of the event.

set-evvel!

Set the velocity (amplitude) of the event.

set-evpit!

Set the pitch of the event.

set-evtv!

Set the Onset time of the event.

setevparameter!

Set the parameter value in the event at a given index

make-event

Make an event object.

66

ev

Alternative name for make-event.

ev:copy-base

Copies the contents of an event up to pitch. Extra parameters can be specified in

the argument list.
Functions for working with Score Objects

score-ref

Returns the event from the score at a given index.

sc:last

Returns a value from the last event in a score at a given parameter index.

score?

predicate for checking if the object is a score.

make-score

Make a score object. Effectively the same as the :+ operator.

params>score

Make a score from lists of parameters.

sc:length

Return the number of events in a score.

sc:events

Return a list of evaluated event data in a score.

sc:printevents

Print score contents to the log with event data displayed.

sc:get-param

Returns a list of the parameter values at pndx in a score.

sc:copy-base

Returns a score which copies parameters up to *pitch-ndx* from a score.

sc:copy

Copies an entire score.

sc:ornament

Generate a score from an event, based on a list of intervals and rhythmic values.

key->score

Creates a score by typing on the keyboard.

sc->pb

sc->pb puts a ':+' representation of score-events on the pasteboard.

Generic Operators

Operator

Argument type

Result

:+

Events

Collects events into a Score

Scores

Combines scores into a single score.

Players

Returns a new player which adds the scores and merges

event actions and termination actions from any number of
players.

:+!

Scores

Combines scores into the first score in the argument list, inplace.

:*

Events

Generates a score of harmonised to pitches from an event

Scores

Harmonises every event in a score. Returns a

score.

:replace!

Scores

Replaces a score with another score in place,

:><

Scores

Returns the remaining score after a section of the score

between indices has been removed.

:><!

Scores

Removes a section of a score in place.

:<

Scores

Given an index, removes the events from the tail of the score.

:<!

Scores

Given an index, removes the events from the tail of the score
in place.

:>

Scores

Removes the head of a score and returns the tail from an ndx

67

:>!

Scores

Removes the head of a score in place.

:pmod

Event

Modify a parameter value in an event, either by numerical

addition or applying a procedure with reference to other
parameters in the event.

Score

Return a score modifying all parameter values in events at a

given index.

Event

In-place versions of :pmod. Affects the first argument.

Score

In-place versions of :pmod

Events

Return a score by collecting events and modifying onset

times in events such that they will play consecutively.

Scores

Return a single score, combining scores such that they play

consecutively.

Players

Creates players which play in a consecutive sequence.

Events

Appends events in place.

Scores

Appends Scores in place.

:pmod!
:append

:append!

Players
toggle-player

Switches a player on or off depending on their current state.

cs:playparams

A procedure to send a numerical parameter list to Csound.

cs:eventsend2

A procedure to send events to Csound

cs:event-send Send events to Csound without a time argument.

cs:play-events Dump all events from a score to Csound
cs:ornamentevent

This sends ornamented events directly to Csound.

cs:loop-events A Csound score player which loops through scores.

au:mixer-fade A procedure specifically designed to modify levels on Apples Stereo Mixer
AudioUnit.
au:event-send Send an AudioUnit an event.
cs:event-sendt Send Csound an event, with a symbol reference to check the play status of the
player.
au:eventsendt

Send Can AudioUnit an event, with a symbol reference to check the play status
of the player.

au:ornamentevent

Play ornamented score events on an AU.

au:playevents

Play a score with an AudioUnit

cs:send->buss Change the routing of audio signal paths in Csound.

cs:set-param

Send parameter control data to Csound.

cs:multi-fade

Linearly adjust multiple parameters in Csound over time.

cs:multi-expt

Adjust multiple parameters in Csound over time with an adjustable exponential

curve.

rescueCsound

re-initialise the OSC receiving event generating instrument in Csound.

68

make-player and methods

pl:evactions

Returns the procedure/s executed for each event triggered by the score

pl:timemults

Returns the list of rhythm value multipliers applied to score events. '(1) by
default.

pl:currentevent

Returns the current event in the score which the player is up to playing

pl:inst

Returns the instrument number used by the player

pl:termaction

Returns the item executed when a player finishes reading a score. The default
symbol 'loop will execute the same player.

pl:incr

Returns the iteration incrementer used for score-reading. Can be a value or a

generator. This is set to 1 by default.

pl:score

Returns the score being read by a player.

pl:player

Returns the procedure used for reading scores.

pl:name

Returns a symbol of the name of the player.

pl:exec

An alternative method to start a player.

pl:setevactions!

Change the procedures executed at each score event.

pl:settimemults!

Change the time multiplier applied to each time value in the score.

pl:settermaction!

Change the termination item executed when the Score has finished being read.

pl:set-player!

Change the procedure which reads the score.

pl:callmethod

A procedure to call a method on a player.

(Time)

Any integer given as a method to the player will be considered a time value at
which time the player will begin playing.

69

Bibliography
Abelson, H. and G. Lindsay. 1996. Structure and Interpretation of Computer Programs,
Second Edition. Massachusetts: MIT Press.
Anderson, V. 2006, Well it's a Vertebrate ...: Performer Choice in Cardew's Treatise,
Journal of Musicological Research. 25: 291317
Ariza, C. 2005. Navigating the Landscape of Computer-Aided Algorithmic Composition
Systems: A Definition, Seven Descriptors, and a Lexicon of Systems and Research.
Proceedings of the International Computer Music Conference. 765-772.
Assayag G. 1998. Computer Assisted Composition Today. 1st Symposium on music and
computers. October 23-25, Corfu.
Bailey, D. 1992. Improvisation. Its Nature and Practice in Music. Second edition. United
Kingdom: Da Capo Press.
Bazzana, K, 1997. Glenn Gould. The Performer in the Work. Oxford: Oxford University
Press.
Bencina, R. 2006, Creative software development: Reflections on AudioMulch practice.
Digital Creativity, 17(1): 1124.
Benson, B. E. 2003, The Improvisation of Musical Dialogue. A phenomenology of Music.
Cambridge: Cambridge University Press.
Berleant, A. 1987, Musical Decomposition. In What is Music? An introduction to the
philosophy of music. (eds)Philip Alperson. pp 239-254, Haven Publications Inc. 1987
Reprinted & published by The Pennsylvania State University press, 1994. Pennsylvania
(PA 16802), U.S.A.
Bohm, D. and D. F. Peat. 2000. Science, order and creativity, Second Edition. London:
Routledge.
Birringer, J. 1999. Contemporary Performance/Technology, Theatre Journal, 51(4): 361381.
Brown, A. R. 2007. Software Development as Music Education Research. International
Journal of Education & the Arts 8(6): 1-14.
Brown, A. R. 2003. Music Composition and the Computer: An examination of the work
practices of five experienced composers. PhD Thesis: The University of Queensland.
Brown, E. 1953. Folio and Four Systems, New York: Associated Music Publishers Inc,
Collins, N., McLean, A., Rohrhuber, J. and A. Ward. 2003. Live coding in laptop
performance. Organised Sound, 8(3): 321-330.
Collins, N and F. Olofsson. 2006. klipp av: Live Algorithmic Splicing and Audiovisual
Event Capture. Computer Music Journal, 30(2):818.

70

Composers Desktop Project. 1986 - 2007. Wiltshire, United Kingdom: [Computer

software: CD-Rom].
Dean, R. T., Whitelaw, M., Smith, H. and D. Worrall. 2007. The mirage of real-time
algorithmic synaesthesia: Some compositional mechanisms and research agendas in
computer music and sonification, Contemporary Music Review, 25(4):311-326
Delige, I. and M. Richelle. 2006. The Spectrum of Musical Creativity. In Musical
Creativity: Multidisciplinary Research in Theory and Practice, eds. Delige, I. and G. A.
Wiggins. 1-6. Hove: Psychology Press.
Draft manifesto. 2007. http://www.toplap.org/index.php/ManifestoDraft (accessed April
17, 2007).
Garnett, G. E. 2001. The Aesthetics of interactive computer music. Computer Music
Journal, 25(1):21-33
Hamman, M. 1999. Structure As Performance: Cognitive Musicology and the
objectivication of Compositional Procedure. In Otto Laske: Navigating new musical
horizons, ed. Tabor, J. Connecticut: Greenwood Press.
Herrema, R. 2006. Composing along continuums of technology and purpose. Digital
Creativity, 17(1): 3-10.
Kemal, S. and I. Gaskell. 1999, Performance & Autheticity in the Arts. In Performance
and Authenticity in the Arts, eds. Kemal S. and I. Gaskell. Cambridge: Cambridge
University Press.
Knapton, B. 2008. Activating Simultaneity in Performance: Exploring Rovert Lepages
Working Principals in the Making of GAIJIN. Masters Thesis: Queensland University of
Technology.
Levinson, J. 1990. Music, Art,& Metaphysics. Essays in Philosophical Aesthetics. Ithaca:
Cornell University Press.
Lindley, M. 1980. The New Grove Dictionary of Music and Musicians (ed. Stanley
Sadie), London, Macmillan Publishers Ltd., 4(Castrucci Courante):599 602.
Maus, F. E. 1999. Musical Performance as analytical communication. In Performance
and Authenticity in the Arts, eds. Kemal S. and I. Gaskell. 129-153. Cambridge:
Cambridge University Press.
Miller, F. Paradis, R. and K. Whalen. Iterative Development Life Cycle (IDLC): A
management process for Large Scale Intelligent System Development. Proceeds of the
1991 IEEE International Conference on Tools for AI, San Jose, CA, Nov. 1991:520 -521.
Miranda, E. R. 2001. Composing Music with Computers. Oxford: Focal Press.
Nyman, M. 1974. Experimental Music. Cage and Beyond. London: Studio Vista.
Ostertag, B. 2002. Human Bodies, Computer Music. Leonardo Music Journal, 12:11-14

71

PLUM. 1991. Programming Languages Used for Music.

http://www.nosuch.com/tjt/plum.html (accessed January 8, 2008).
Risset. J. 1999. Composing in real-time? Contemporary Music Review, 18:3, 31-39
Scaletti, C. 2002. Computer Music Languages, Kyma, and the Future. Computer Music
Journal, 26(4): 6982.
Sorensen, A. 2005. Impromptu: An interactive programming environment for
composition and performance. Proceedings of the ACMA 2005, 149-153. Brisbane:
ACMA.
Taube, H. K. 2004. Notes from the Metalevel. Illinois: Taylor & Francis.
Toplap. 2007. http://www.toplap.org/index.php/Main_Page/ (accessed April 17, 2007).
Toplap Realaudio Documentary. http://thebot.org/video/toplap.ram (accessed April 17
2007).
Turner, T. 2003. The resonance of the cubicle: Laptop Performance in Post-digital Musics
Contemporary Music Review, 22(4):81-92.
Vaggione, H. 2001. Some Ontological Remarks about Music Composition Processes.
Computer Music Journal, 25(1): 5461.
Vinao, A. and I. Cross. 2006. Software Interface Between Human and Computer Virtual
Players for Music Performance in Concert. Leonardo, 39(5): 461-463.
Wang, G and P. Cook 2003. ChucK: A Concurrent, On-the-fly, Audio Programming
Language. Proceedings of the 2003 International Computer Music Conference, 219-226.
Ward, A., Rohrhuber, J., Olofsson, F., McLean, A., Griffiths, D., Collins, N. and A.
Alexander. 2004. Live Algorithmic Programming and a Temporary Organisation for its
Promotion. Papers from the Read_Me Software Art and Cultures Conference 2004. 242261.
Wessel D. and M Wright. 2002. Problems and Prospects for Intimate Musical control of
Computers. Computer Music Journal, 26(3):11-12
Whitall, A. 2002. The Oxford Companion to Music, Alison Lathan (ed.)
Oxford U.K., Oxford University Press: 279 283
Wooller, R. 2007. Techniques for automated and interactive note sequence morphing of
mainstream electronic music. PhD Thesis: Queensland University of Technology.

72