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.

1

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.

2

Contents

Introduction 7

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.wavMirroring.wavSoiree.wav

Movies/QuickTime/

Mirroring.movForest.movSoiree.mov

WindowsMedia/Mirroring.WMVForest.WMVSoiree.WMV

CACSource/CACLib_Src.pdf

3

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.

4

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

5

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.

6

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

7

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

8

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 pre-

recorded 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

9

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 One-

gesture-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. Deliège 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” (Deliège 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 Gould’s 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 composer’s 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” (Deliège, 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 performer’s 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-one-

acoustic-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 pre-

determined 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 loop-

player, 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 real-

world 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 over-

time. 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 in-

depth 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 “composer’s 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:set-

timemults! 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 DescriptionMiscellaneous 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.

define-instrument

Use this to specify either Csound or AudioUnit instruments.

au:audio-unit? predicate for instrument type

cs:Csound-instrument?

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-at-indices

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.

interval-distances

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.

vectorget-index

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:read-scale

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.

set-evparameter!

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:print-events

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, in-place.

:* 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.

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

Score In-place versions of :pmod

:append 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.

:append! Events Appends events in place.

Scores Appends Scores in place.

Players

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

cs:play-params

A procedure to send a numerical parameter list to Csound.

cs:event-send2

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:ornament-event

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:event-sendt

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

au:ornament-event

Play ornamented score events on an AU.

au:play-events

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.

rescue-Csound

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:current-event

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:set-evactions!

Change the procedures executed at each score event.

pl:set-timemults!

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

pl:set-termaction!

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

pl:set-player! Change the procedure which reads the score.

pl:call-method

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: 291–317

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): 11–24.

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. 1987Reprinted & 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): 361-381.

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):8–18.

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

Deliège, I. and M. Richelle. 2006. The Spectrum of Musical Creativity. In Musical Creativity: Multidisciplinary Research in Theory and Practice, eds. Deliège, 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 Lepage’s 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): 69–82.

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): 54–61.

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. 242-261.

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