Académique Documents
Professionnel Documents
Culture Documents
Keywords
music, composition, performance, live coding, live programming, computer music,
computer assisted composition, algorithmic music, generative art, Impromptu, Csound.
Abstract
This thesis maps the author's journey from a music composition practice to a composition
and performance practice. The work involves the development of a software library for
the purpose of encapsulating compositional ideas in software, and realising these ideas in
performance through a live coding computer music practice. The thesis examines what
artistic practice emerges through live coding and software development, and does this
permit a blurring between the activities of music composition and performance.
The role that software design plays in affecting musical outcomes is considered to
gain an insight into how software development contributes to artistic development. The
relationship between music composition and performance is also examined to identify the
means by which engaging in live coding and software development can bring these
activities together.
The thesis, situated within the discourse of practice led research, documents a
journey which uses the experience of software development and performance as a means
to guide the direction of the research. The journey serves as an experiment for the author
in engaging an hitherto unfamiliar musical practice, and as a roadmap for others seeking
to modify or broaden their artistic practice.
Contents
Introduction
14
24
32
42
56
62
Bibliography
70
Mirroring
Index2:
The Forest
Index3:
Soiree
______________________________
Signature
______________________________
Date
Acknowledgements
In presenting this thesis, I am indebted to the people I have met, both past and present,
and the knowledge they have generously shared with me.
For my friend and colleague, the talented Andrew Sorensen, for developing Impromptu,
sharing his computer programming expertise, and his time to debate important issues
surrounding music and computers.
For the people I met and my experiences during my undergraduate at the Sydney
Conservatorium of Music, in particular I would like to thank Dr. Greg Schiemer and Dr.
Anthony Hood who introduced me to the world of Computer Music.
I would like to thank my wife and soul mate Dr Kirsty Martin, who sacrificed too much
to help me through. I will always be grateful for her encouragement and support.
Finally, I would like to thank my daughter Ada, whose arrival during my studies was a
particularly significant event in our lives, and has been the happiest blessing words can
hope to express.
Introduction
The Composer in Context
This thesis provides an account of my transition from that of a composer of pre-recorded
musical works, to a composer as performer. The research sees me undertake the task of
developing computer software for the purpose of live computer music performance. The
engagement of a live computer music practice is a significant change to my accustomed
compositional practice of creating fixed-media electro-acoustic works.
This thesis describes the transformation of a compositional practice and my
conceptualisation of composition into a performance practice. The journey described here
refers to three performances, Mirroring, The Forest and Soiree, which serve both as
artistic outcomes of various stages of the research, and as a means to direct the course of
the research. This process is described in more detail in Chapter three.
The accompanying DVD presents documentary video of the live coding
performances. The video performances are presented as a mixture of a 'screen cast' and
live footage at the performance venue. The 'screen cast' is a captured video from my own
computer screen during performance. Thus the images of text appearing on the screen is
the result of me typing at the keyboard. In performance, a 'screen cast' was projected on a
screen in front of the audience. The 'screen cast' footage presented on the DVD is
identical to the video displayed to the audience at the performance.
As with many composers schooled in western-art music making, my understanding
of the role of a composer had come to be defined as those who write musical scores. The
final outcome of my work was only a portion of what was required to realise the music.
The delivery of music to an audience lay in the domain of performance, with its own
practitioners and aesthetic criteria.
The reliance on performers to realise composed work motivated my interest in
computer music-making. Computer music offered a way to create a complete realisation
of the musical work entirely in the recorded medium. Using a variety of computer music
packages, I would carefully create, process and place sounds so as to make a final audio
work. My work in this area had been squarely located in what is now sometimes referred
to as 'deferred-time' computer music composition.
However, the freedom to realise the final audible work raised some concerns. The
'performance', in the sense of an event in which people come together and appreciate the
work as it is presented, was now unnecessary. It seemed easier, and in some ways more
appropriate, to simply distribute audio copies of my works for people to listen to
privately.
Unlike distributed recordings, performance engenders a social connection between
a performer and the audience. The mere presence of participating in the performance of
the work engages the audience in a much different way to that of a recording. Where a
recording could be experienced privately any time in almost any location, the
performance offered a mutually shared experience, a sense of uniqueness of the
experience, and an engagement between the performer and the audience. By removing the
performance experience from my music, I had removed a significant aspect of the
experience of music generally.
It should be qualified however, that some of my computer music works have been
'performed', and I have on occasions been 'the performer' in these works. However, while
these events can be considered 'performances', there was often very little participation by
myself or others during the performance. For example, in some 'electro-acoustic'
concerts, the 'performance' consisted of little more than the playback of the recorded
artefact in a concert situation.
The experience for the audience has been heightened in these situations by using
audio reproduction equipment not typically available to individuals, such as a large array
of speakers. The experience for me as a 'performer' has also been somewhat improved by
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
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
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
15
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
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
23
24
25
intentions' by following performance instructions, Bazanna does point out Goulds intent
to be true to 'the work'. For Gould, to be true to the work is to be true to the underlying
structure of the work (Bazanna, 1997).
Such an idea conforms with a broader philosophical position to see the work of art
as having an 'ideal' or 'authentic' nature which stands outside the instantiation of itself.
Kemal & Gaskell suggest the need for art to have an 'authentic' reference point is to
mimic what was originally provided by divine authority (Kemal, Gaskell 1999, p. vii).
Bruce Ellis Benson relates this phenomena in the arts as an example of Husserls notion of
'treuwerk' (Benson, 2003).
In music, this means that a 'work' can exist whose merits are evaluated irrespective
of the quality of any performance of that work. The problem is that the conception of a
performers role in western art music means their exploration is always in reference to an
'ideal' or 'correct' way to perform the work. Jerrold Levinson states this quite clearly when
he sets out the premise: I begin with the suggested criterion for performance worth of
being true to the work performed (Levinson, 1990, p. 388). Irrespective of whether or
not the performer sees this as synonymous with being true to the composers intentions, it
is the art of interpretation which does not provide room for creative music making to
originate from the performance.
Given this, my own attempts to 'perform composition', in the western art music
sense of composition and performance, becomes a contradiction in terms. I can either
compose, or perform, but each activity is mutually exclusive. That I happen to be the
composer performing my own composition is not enough, it is merely a special case of
this plurality of functions (Delige, Richelle, 2006, p.4). The separation of activities for
composers and performers is ingrained such that the roles have become a definition of
terms.
It should be acknowledged that many composers have sought to subvert
26
orthodoxies inherent in the western art music model. In his book documenting
'experimental music', Michael Nyman uses John Cage's 4'33 as the basis for a definition
of a musical movement which sought to depart from post-war European modernism
which had established itself as the orthodox modern musical practice. As Robert Ashley
is quoted, It seems to me that the most radical redefinition of music that I could think of
would be one that defines 'music' without reference to sound (Ashley in Nyman, 1974, p.
10).
Techniques employed in these works often force performers to make decisions
normally reserved for the composer. Earl Brown's 'Folio and Four Systems' for example
requests the performer to interpret a graphic score into music (Brown, 1953). This
effectively requires the performer to make decisions on which notes to play. However
Brown did not necessarily anticipate performers taking liberties such that they would
make their own significant creative decisions affecting the course of the work. In an
interview with improvising musician Derek Bailey, Earl Brown reveals his own
reconstruction of the composers role in aleatoric music.
You see, it is somewhat my responsibility to create conditions which, in a
certain sense, won't be violated stylistically. For instance, if there's
somebody who is very good at improvising in the style of Bach, or the
baroque period, very often I suggest something verbally. Like, I ask for
erratic, jagged rhythms, so that he would not make sequences of 8th notes
(Brown in Bailey, 1992, p. 67).
I do not mean to suggest that the composers of these works are disingenuous about
their efforts to redefine musical practice. On the contrary, as Nyman points out, a defining
factor of many of these works is to relinquish compositional exactitude to some sort of
automated or emergent process (Nyman, 1974). The contribution these pieces offer is to
remove or at least redefine - the composers function in the creation of music. What
these pieces don't attempt is a redefinition of the performers role in making music. By
presenting a score, the performer may reposition their function as an interpreter, but not
27
28
with no preparation at all. Even in some special cases such as 'free improvisation', most
performers would have had a specific musical background from which they arrive, and
some training on the instrument on which they perform. Improvisation can then be
described as a generative art, in which musical material is generated by the performer as
they draw from memorised knowledge, pre-dispositions, and physical and conceptual
practice.
Arnold Berleant considers improvisation in relation to a phenomenology of music.
For Berleant, improvisation must be generative by virtue of the generative characteristics
of music itself. Improvisation then reflects the generative characteristics of a given
material and offers a first approximation of where it might go (Berleant, 1987, p. 251).
Bailey describes something similar when he discusses 'idiomatic improvisation'.
For Bailey, it is the 'idiom' of the musician which largely determines the kind of music an
improviser plays. This explains why improvising musicians play in particular styles. A
jazz musician for example improvises in the jazz idiom, a flamenco musician in the
flamenco idiom, and so on (Bailey, 1997).
If we consider improvisation as a generative art, drawing from existing musical
knowledge it may start to seem as though improvisation is not entirely dissimilar from
composition. A jazz pianist once described to me that improvisation was nothing less than
instant composition. After-all, how different was it for an improviser to 'come up with
something' in performance than it was for me to 'come up with something' and write it
down? Alternatively, how many compositions have been written without the composer
improvising various passages to see how they worked? It is this presence of
improvisation that leads Benson to conclude that all music making can be classified as a
specialised form of improvisation (Benson, 2003).
I would suggest there is a difference in music produced through composition than
through improvisation, and the reason lies in the approach to abstract musical form. As
29
has been mentioned, an instrumental performer typically plays in what Wessel and Wright
call the One-gesture-to-one-acoustic-event-paradigm (Wessel, Wright, 2002). From an
audience perspective, this paradigm refers to the correlation of the visual perception of
physical actions to musical output. We can consider this paradigm in an alternative way if
we consider its implications for performers. In this context, the one-gesture-to-oneacoustic-event-paradigm means the performer is forced to assemble musical material by
cognitively generating music close to the surface level granularity of individual musical
events.
This is not to say that more abstract musical constructions can't come about
through improvisation. Indeed, much of the skill of a good improviser is appreciated by
their ability to fit the material into larger, more abstract musical structures. Johnson-Laird
describes this quality of jazz musicians:
As a result of years of improvisatory practice, they can navigate their way
through chorus after chorus of the chord sequence and create a seemingly endless
series of melodies appropriate to its harmonic implications (Johnson-Laird,
2002, p. 416).
What is of note is that these abstract musical structures are assembled by
cognitively generating smaller, less abstracted events. A jazz improviser for example
might conceive and generate 'licks' as the atomic unit. A hierarchical order is imposed on
increasing levels of musical abstraction. For example, a 'lick' becomes the starting point
from which to slot into more abstract structures such as harmonic sequences, sequences
into sections and possibly larger forms.
To some extent this method of musical creation is shaped by the requirements
inherent in performance. This is a different method of generating music than through that
of deferred time composition: The composer can rework material after an attempted
realisation. A work can be conceived and created irrespective of how the music actually
unfolded in time. Abstract structures at any level of granularity, from individual notes to
the entire form of a work, can be considered without the same hierarchical order
30
31
32
strategy for software development teams. Various styles of this kind of methodology exist
under the headings of 'Agile Development', 'Extreme programming', 'Feature Driven
Development' and 'Evolutionary programming' amongst others (Miller, et al., 1991). The
techniques came about largely to address the inflexibility inherent in developing to a predetermined formal specification. In a typical scenario, a prototype 'bare bones', yet
functional software system is given some sort of user testing. Further development is
guided by user feedback, rather than predetermined specification.
My motivations for adopting an iterative development methodology in an artistic
project are of course quite different to that which encourages its adoption in a commercial
environment. What appeals to me is the form of the process. The triadic strategy of
develop, test and redesign strongly resembles an artistic process involving creation,
presentation and introspection. By way of illustration, consider this example describing
the development of an artistic work, such as painting.
As the painter begins to work on the canvas, a new interaction takes place. He or
she is constantly faced with both physical limitations and new potentials, in the
very muscular activity of painting and in fresh perceptions of the growing
painting beneath the brush (Bohm, David & Peat, F. David, 2000, p. 157)
Here, Bohm and Peat are describing the generative process in which a painter
develops a painting though a kind of reflective feedback loop: the artists intentions are
reflected back to the artist as the painting grows beneath the brush.
Similarly, the Australian composer Richard Meale describes his compositional
method as exploratory: That's why I like to start at the beginning of the piece and work it
through, because then I can feel the momentum that is building up behind the piece
which, of course, is form (Meale in Ford, 1993, p.33). Here, Meale uses the
development of the piece to guide the direction of the piece.
Finally, Andrew Brown has proposed the Software Development as Research
(SoDaR) approach as a means of conducting research. The SoDaR approach identifies
33
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
36
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:
The values in each note in this case were represented by pitch, velocity and duration
parameters respectively. This in turn influenced the design of a score player. The loopplayer, pictured below, plays through a score repeatedly.
38
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
42
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
45
deferred actual compositional decisions altogether. Instead I had applied the best musical
setting which I could manage given the characteristics of the system I was using. Yet was
this not the outcome to which I was aiming? My premise from the outset had been to
develop a compositional approach in conjunction, and embodied by, the tools I had
developed.
A number of other issues raised at the Mirroring forum had begun to concern me.
In particular: If I was not improvising in the performance, how can this be considered a
form of performed composition? This particular question also provoked another: How is
performed composition different to improvisation? These questions lead me to consider
the kind of relationship which exists between composition and performance as discussed
in the second chapter. They guided my decisions over how I should prepare pieces, what
contribution the CAC library makes to an artistic practice, and what role improvisation
should play in the presentation of a piece.
Performance 2: The Forest
The performance of The Forest occurred on the evening of the 17th of November
2007 in a caf (of the same name) close to the city centre of Brisbane. In contrast to the
university context of the Mirroring performance, this performance was open to the
public. I had little clue as to what the reception might be to a live coded performance in
this environment. With the added concern of repeating Mirroring's technical mishaps, I
was decidedly cautious in my approach to performing this work.
Preparation and development
On this occasion, I had decided to pursue a particular approach to creating music. I
wanted 'The Forest' to be a piece concerned with parameterised manipulation of sound,
rather than note-based music. The work is book-ended by a pre-recording of a
thunderstorm which undergoes a number of sound-shaping transformations.
Many of the tools developed for the performance provided means for shaping
46
parameter envelopes over time. For example, I developed tools to exponentially control
the position of loop points in a sample player. In an effort to generalise these tools as
library functions, the same tools could be used to control other parameters, such as gain
levels.
Performance
The performance followed two Audio-Visual works which ran somewhat overtime. As the last performer of the evening, I sensed the audience was reaching a limit of
their attention span. In rehearsals I had estimated a performance to last for approximately
half an hour. Surprisingly, I found I was sufficiently versed in the possibilities of the piece
and the system so-as to shorten the performance, whilst still conveying much of what I
wanted to. Whilst this was a relatively simple alteration based on the mood of the
audience, I was pleased that I had been able to conduct some moderate improvisation
during the performance, as this was a skill I had aimed for since the last performance.
Reflection
The ability to improvise and modify during the course of the piece exemplified the
differences between my work and the fixed-media audio-visual work which had been
presented earlier. Another interesting aspect of performing at The Forest, was the
noticeably different engagement from the audience to a performed work, than that of the
pre-recorded Audio-Visual work. As an observer pointed out to me, the audiences
attention concentrated, and alternated, between the activity on the screen, and myself (the
performer) typing away on the laptop. This performative aspect of the presentation of a
work suggested there was something significant about the presence of a performer, and
the act of performing, to engagement with the work. This too was noticeably in contrast
to the passive reception of earlier pre-recorded works.
I had also managed to complete the performance without technical problems. I had
effectively achieved what I had aimed for with this stage of development. However, the
47
experience of this performance was not without some troubles: I had such a large
collection of tools in the CAC library that I struggled to remember their names, the
meanings of their arguments and their output. During the performance, there were a
number of times when I would hesitate to embark on a particular musical activity,
because I could not recall all the tools necessary to complete the task.
This also demonstrated a performance constraint I had not been familiar with in a
compositional context. I had assumed that a large collection and variety of tools would
offer more choices in the available musical outcomes I was able to achieve. This is
certainly what appealed to me in a compositional context, where more tools presented
more musical possibilities. In performance, such a large collection of tools requires more
reliance on memory, and serves to increase the possibility of human error.
To reduce the possibility of a performance catastrophe, I had packaged up many of
my tools into single-line commands. While a single command can be powerful in some
circumstances, there are a few problems that arise when a performance relies on too many
tools. One problem is the lack of association to a musical process. Other than the name of
a particular command, there is almost no indication as to what the actual musical effect
might be. From the audience perspective, the performance seems to consist of numerous
abstruse tools, the presentation of which disconnects the audience from the musical
process. Obscuring the correlations between musical activity and coded activity largely
defeats the purpose of performing in front of the audience in the first place
My own experience as the performer also felt unadventurous. While I had gained
enough skills for some moderate improvisation, I felt more constrained than I had during
the Mirroring performance. The reason for this was the inaccessibility of the processes
after I had executed them. As I had packaged up the tools, the internal algorithms which
constitute the process were now inaccessible. Thus in performance, once a process had
been executed, the process was committed. For short events this is acceptable, however,
48
for lengthy processes which have a significant influence on the course of the music, this
leads to inflexibility during the performance.
Thus while I had addressed many of the issues raised since the performance of
Mirroring - the system was less prone to technical failure, and I was comfortable enough
for some moderate improvisation to take place during performance - new issues had
presented themselves: The unwieldy collection of tools now conspired to contrive my
performances. The inaccessibility of musical processes rendered improvisation as a
relatively harmless activity. The obscured packaging of code defeated the purpose of a
live coded performance presentation.
The result of this required a re-think in terms of what constituted a useful system to
perform and compose with. A change of direction in the course of CAC development was
needed. Instead of building a vast collection of tools, my attention now turned to the
design of the overall system as a means of providing musical expression.
CAC Development after The Forest.
After the performance of The Forest, the CAC library underwent the longest and most indepth development phase of the project. Much of what had been previously designed was
re-written in order to address the concerns which had emerged from the previous
performance. Many of these concerns revolved around the relationship of the usage of the
CAC library with the performance experience.
One simple solution was to simply remove a number of the functions in the library.
This would reduce the problems of committing the names and uses of tools to memory.
However, this would also reduce some of the expressive possibilities of the system, which
did not seem acceptable. Furthermore, as development continued and more functions
were added, it seemed likely that this problem would reappear.
Another possibility was to reduce the scope of what the tools in the library try to
achieve. Rather than attempt to create a singular tool for controlling a volume envelope,
49
the various tasks of creating a volume envelope could be broken down into smaller
components. Of course, the smaller components could be the primitives of the
programming language, however, I still wanted the library to encapsulate musical ideas
rather than generic programming ideas.
The collection of tools needed to behave like elements in a language. I needed a
means of linking the tools in such a way that the combinations provided new means of
expression. To an extent the syntax of the Scheme language was already available and
could be used. However, the self-contained tools I had created didn't really take
advantage of this. There was no system in place for re-combining these tools as elements
of a larger structure. I had effectively been removing the 'linguistic' power of a
programming language. This translated musically into limiting the expressive possibilities
which arise by combining and connecting musical elements.
My solution involved two important structural changes. The underlying principal
of 'scores' and 'players' remained. I now wanted to encapsulate many of the tools into
'generic operators'. The operators would operate on scores, or players, as if those items
were data. As an example, an addition operator :+ could be used to add notes together to
form a score. Alternatively, it could add entire scores together to produce larger scores.
Finally, I also wanted the :+ to add players together, just as if players were also data.
There are a number of ways to implement generic operators in Scheme. I chose the
'data directed' style described in The Structure and Interpretation of Computer Programs
text by Abelson and Sussman (1996). This method is generally recommended when the
types of data are few, and the operators are many. In this case, my only data types were
events (notes), scores (collections of notes) and players (functions to play scores). My
operators would provide various means of building, slicing and re-organising scores and
players. Much of the re-work of the system revolved around 'typing' data, for which I
employed a simple 'object' based approach, and rewriting existing functions to
50
51
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
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
56
earlier (Ariza, 2005) describes a relationship between software design and musical
outcomes. However, it is worthwhile considering the relationship between the composer
and software tool which cause this to be so. Andrew Brown has described this process as
a reflective process, whereby the capabilities of the system are absorbed and manipulated
by the composer. This is not to say the medium doesn't bear an influence on the outcome
or the process. However rather than see this as technology constraining what the
composer would otherwise do, the composer in reality uses this environment as a means
for artistic expression. The composer's compositional approach and method adapts with
the facilities offered by the computer. Thus the composers perspective is intimately
associated with the nature of the medium they are using (Brown, 2003, p. 225).
Composer and cognitive psychologist Otto Laske suggests something similar when
he describes the role the computer plays in the musical understanding of the composer.
For Laske, all composition is a self-referential activity such that realising a composition
(musical output) influences the musical framework (the knowledge and grammar
systems) of the composer. Developing software on a computer effectively places the
computer as a component of the compositional method. However, it is a component
which externalises and forces the explicit definition of elements of the compositional
process which would otherwise be guided by historicity or methodology (Hamman on
Laske, 1999, p.47).
In the case of my own work, this implies a reflective process, in which my
approach to creating music adapted to the capabilities of the CAC system, whilst at the
same time the capabilities of the CAC system were developed based upon my own
compositional approach. Through software development the technology evolved
symbiotically with the practice. The expressive capabilities of the CAC system were
manipulated such that both the CAC system and my approach to making music found, or
at least approached, a common meeting place to realise a musical expression. This is
57
slightly different than describing a relationship between my musical thought and the
computer. More apt would be to say that my engagement with the technological medium
is such that software development becomes an aspect of my musical creativity.
Computer collaboration as an indicator of a hybrid musical practice.
That my approach to music making also underwent a transformation is evidenced by my
different experiences during preparations for each performance. Recall for example that
my approach for Mirroring had been to pre-compose the entire piece. This lead to other
problems such as being unable to find ready-made tools in the CAC library for a
particular musical idea. For Mirroring, there was a disconnect between my musical
understanding and my understanding of how to realise these ideas using the CAC library
in a performance situation.
By contrast, my approach for Soiree involved improvisation; a musical practice I
had been hitherto unfamiliar with, and which had seemed implicitly contrary to what I
understood as composition. The engagement with the CAC library, and the experience of
performance had lead me to approach making music in an entirely different manner to
how I did so previously.
Understanding the nature of Performed Composition.
By altering my own conception of making music from a deferred time compositional
practice to a performed practice I felt I had arrived at something resembling the hybrid
practice which I had hoped to achieve. My activities when rehearsing, improvising, or
developing software became apposite to the practice. It was the change in how I
approached creating music which I took as an indication that I had completed the research
objectives.
How then can the nature of the artistic practice I have engaged in be discussed?
Media choreographer Johannes Birringer points out that the particular capabilities and
limitations of media technology in the arts are capable of redefining the way those arts
58
are conceived at all. Thus dance made exclusively for film has produced an aesthetic for
'video-dance'. Marionette theatre has a marionette aesthetic, distinct from regular theatre
(Birringer, 1999, p.366). Similarly, photography has developed its own aesthetic which is
particular to photography and distinct from other visual arts. Likewise, computer music
practices also harbour their own aesthetic criteria.
My own practice can also be considered within an aesthetic based on its own
technological parameters. This is not to suggest that the practice I engage in is an
exemplar of a new hybrid practice. Instead it suggests that the process used in producing
the work contributes to the aesthetic of the work. I will now consider the process which
produced my work.
By intuitively developing and reflecting on performances, I initially attempted to
recreate my understanding of how music is created. I began this journey from a position
rooted in western art-music compositional practice, and some aspects of my
compositional predilections are evidenced by aspects of the CAC system which uses
concepts such as 'events', which largely equate to 'notes' in a traditional music sense, and
scores. Similarly, 'players' interpret these scores, and represent in sound largely verbatim
whatever instructions they contain. I had recreated a small model of my own
understanding of the musical paradigm.
The danger with such an approach is that my practice would mimic aspects from
traditional music making idioms. By attempting to mimic the outcomes of those practices,
I invite my own work to be held up in regard to work produced in this way, rather than as
a practice in its own right.
However, my practice did depart from the traditional music making model.
Developing a live music system and using it in performance influenced the kind of music
I made, and at the same time influenced how I thought about making music. I no longer
thought of music making in terms of a binary opposition of composition and
59
performance. The journey concluded with my altered conception of making music from a
deferred time compositional practice to a performed practice.
Concretising an understood musical model in software, allowed me to consider the
paradigm objectively. From an objective position it was possible to consider and
manipulate elements of the modelled paradigm. For example, in software I was able to
enhance the role a 'score' had in performance, by embedding functions that would only be
decided at the time of performance. By gaining familiarity with the modelled paradigm,
manipulation of the paradigm in software could be echoed in the transformation of my
own artistic practice. Thus I also began to incorporate improvisation in my performances,
as this committed a move away from pre-composed work.
As my familiarity with the technology I was using, and the performance medium
itself grew, the combination of compositional ideas, and improvising musical processes in
performance combined to produce something new, which neither fits the western-art
model of music making, nor entirely fits the model of instrumental improvisation.
What I ended up creating was a practice which incorporates the ideas from which it
originated, however the ideas are employed in new ways to create its own practice. The
journey not only helped determine the nature of this practice, it also changed the way I
think about creating music, and allowed me to create a different kind of music, through
different means as a result.
The objectives of this research, as outlined in the introduction, were to determine
the nature of the artistic practice that emerges when combining software development,
composition and performance. The most significant conclusion from this experiment is
that software development can facilitate the emergence of an artistic practice which
combines some aspects of composition and performance. However, it would be more apt
to consider this practice in its own right, rather than in relation to each of these activities.
In part, this is because there are practical limitations in what can be transferred between
60
61
62
Scores
Scores are collections of events. Events in scores can be in any order, however each event
should consist of the same number of parameters. Scores can be created by combining
events in various ways. The simplest example of this is by using the :+ operator, which
collects events into a score:
(define myscore (:+
(make-event 0 2 80 60)
(make-event 0 2 80 64)
(make-event 0 2 80 67)))
Players
Once a score has been defined, a 'Player' can be used to read the score and send audio
messages to a synthesiser such as Csound or an AudioUnit. There are a variety of Players,
however the most powerful is the 'make-player' or 'player' object. An instance of a player
is created by providing make-player with a name, instrument and a score as arguments.
The named player can then be started at a specified time.
;Instantiate 'myplayer' to play the *violin* instrument reading myscore.
(player myplayer *violin* myscore)
;start myplayer in three seconds.
(myplayer (+ (now) (* 3 *second*)))
The player has numerous features which can be accessed with a pseudo object oriented
interface. For example, to modify the pace by which a score can be read, the pl:settimemults! method can be applied:
;read the score in half the time.
(myplayer pl:set-timemults! '(0.5))
Operators
Events, Players and Scores can be manipulated using operators. For example, the
:append operator can be used on events to create a score in which each event begins
after the previous event has finished. Alternatively, :append can be used on scores to
create a larger score, each of which follows the last event of the previous score. The
:append operator can be used on players as well. In this case when each player has
63
Description
Miscellaneous Helpers
rescale
limit
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
expt-curve
+-
;+- 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.
gen-recycle
Returns a state saving generator which resets itself after iterlimit number of
iterations. Useful with number counters.
counter
countdown
brownian
list-gen
defineinstrument
urge
64
repeat-until
make-global
last
list-head
slice
list-fill
truncate
truncates a list to be the specified length. Lists which are lengthened repeat their
contents.
append!
append-item
append-item!
safe-car
safe-cdr
insert-atindices
flatten
scale-list
Scales numerical list values by a factor with the first value retained as the base
value.
scale-list!
list-refs
intervaldistances
get-index
Returns the index in the list with the closest match to the given numerical value.
get-position
vget-position
get-positions
Returns a list of all index positions in a list for the value. Useful to find
duplicates.
get-indices
Given a list of values, returns a list of indices indicating positions of the values.
vectorgetindex
Returns the index in the vector with the closest match to the given numerical
value.
match-val
Returns the closest value in the list or vector to the value provided.
match-vals
expify-lst
member?
merglsts
mod-listndx
Returns a new list with the entry at the index replaced with a specified object.
65
permute
permuteseq
durations
Returns a list of differences between values, with multipliers and constants able
to be applied to the values.
durs
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
xrange
xrange2
scaled-range
accum
longest-list
ziplst
lproc-eval
Evaluates any procedures in a list, and returns a new list with evaluated results.
Useful in scores when combined with the ~ macro.
Functions for working with Scala Scale Files.
scala:readscale
Read a scala scale file, and return a list of cent equivalent values
scala:cscale>mscale
Return a list of 128 'real' midi note number equivalents from a list of cent values.
scala:midi>hz
Convert between midi note number and frequency in cycles per second.
scala:cscale>hzscale
Contents
event?
event-ref
get-evdur
get-evvel
get-evpit
get-evtv
set-evdur!
set-evvel!
set-evpit!
set-evtv!
setevparameter!
make-event
66
ev
ev:copy-base
score-ref
sc:last
Returns a value from the last event in a score at a given parameter index.
score?
make-score
params>score
sc:length
sc:events
sc:printevents
sc:get-param
sc:copy-base
sc:copy
sc:ornament
Generate a score from an event, based on a list of intervals and rhythmic values.
key->score
sc->pb
Operator
Argument type
Result
:+
Events
Scores
Players
:+!
Scores
Combines scores into the first score in the argument list, inplace.
:*
Events
Scores
:replace!
Scores
:><
Scores
:><!
Scores
:<
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
:pmod
Event
Score
Event
Score
Events
Scores
Players
Events
Scores
:pmod!
:append
:append!
Players
toggle-player
cs:playparams
cs:eventsend2
Send Can AudioUnit an event, with a symbol reference to check the play status
of the player.
au:ornamentevent
au:playevents
cs:multi-fade
cs:multi-expt
rescueCsound
68
Returns the procedure/s executed for each event triggered by the score
pl:timemults
Returns the list of rhythm value multipliers applied to score events. '(1) by
default.
pl:currentevent
Returns the current event in the score which the player is up to playing
pl:inst
pl:termaction
Returns the item executed when a player finishes reading a score. The default
symbol 'loop will execute the same player.
pl:incr
pl:score
pl:player
pl:name
pl:exec
pl:setevactions!
pl:settimemults!
Change the time multiplier applied to each time value in the score.
pl:settermaction!
Change the termination item executed when the Score has finished being read.
pl:set-player!
pl:callmethod
(Time)
Any integer given as a method to the player will be considered a time value at
which time the player will begin playing.
69
Bibliography
Abelson, H. and G. Lindsay. 1996. Structure and Interpretation of Computer Programs,
Second Edition. Massachusetts: MIT Press.
Anderson, V. 2006, Well it's a Vertebrate ...: Performer Choice in Cardew's Treatise,
Journal of Musicological Research. 25: 291317
Ariza, C. 2005. Navigating the Landscape of Computer-Aided Algorithmic Composition
Systems: A Definition, Seven Descriptors, and a Lexicon of Systems and Research.
Proceedings of the International Computer Music Conference. 765-772.
Assayag G. 1998. Computer Assisted Composition Today. 1st Symposium on music and
computers. October 23-25, Corfu.
Bailey, D. 1992. Improvisation. Its Nature and Practice in Music. Second edition. United
Kingdom: Da Capo Press.
Bazzana, K, 1997. Glenn Gould. The Performer in the Work. Oxford: Oxford University
Press.
Bencina, R. 2006, Creative software development: Reflections on AudioMulch practice.
Digital Creativity, 17(1): 1124.
Benson, B. E. 2003, The Improvisation of Musical Dialogue. A phenomenology of Music.
Cambridge: Cambridge University Press.
Berleant, A. 1987, Musical Decomposition. In What is Music? An introduction to the
philosophy of music. (eds)Philip Alperson. pp 239-254, Haven Publications Inc. 1987
Reprinted & published by The Pennsylvania State University press, 1994. Pennsylvania
(PA 16802), U.S.A.
Bohm, D. and D. F. Peat. 2000. Science, order and creativity, Second Edition. London:
Routledge.
Birringer, J. 1999. Contemporary Performance/Technology, Theatre Journal, 51(4): 361381.
Brown, A. R. 2007. Software Development as Music Education Research. International
Journal of Education & the Arts 8(6): 1-14.
Brown, A. R. 2003. Music Composition and the Computer: An examination of the work
practices of five experienced composers. PhD Thesis: The University of Queensland.
Brown, E. 1953. Folio and Four Systems, New York: Associated Music Publishers Inc,
Collins, N., McLean, A., Rohrhuber, J. and A. Ward. 2003. Live coding in laptop
performance. Organised Sound, 8(3): 321-330.
Collins, N and F. Olofsson. 2006. klipp av: Live Algorithmic Splicing and Audiovisual
Event Capture. Computer Music Journal, 30(2):818.
70
71
72