Contemporary Music Review

ISSN: 0749-4467 (Print) 1477-2256 (Online) Journal homepage: www.tandfonline.com/journals/gcmr20

Two Computer-Assisted Composition Case Studies

Mikael Laurson & Mika Kuuskankare

To cite this article: Mikael Laurson & Mika Kuuskankare (2009) Two Computer-
Assisted Composition Case Studies, Contemporary Music Review, 28:2, 193-203, DOI:
10.1080/07494460903322471

To link to this article: https://doi.org/10.1080/07494460903322471

Published online: 10 Nov 2009.

Submit your article to this journal

Article views: 167

View related articles

Full Terms & Conditions of access and use can be found at

https://www.tandfonline.com/action/journalInformation?journalCode=gcmr20
Contemporary Music Review
Vol. 28, No. 2, April 2009, pp. 193–203

Two Computer-Assisted Composition

Case Studies
Mikael Laurson and Mika Kuuskankare

This paper presents two large-scale compositional projects that have been realized using a
Lisp-based visual computer-assisted composition environment. As such, the system does
not force the composer to use a predetermined aesthetic framework. In order to meet the
specific needs of individual composers, a user-library scheme is provided that allows one
to augment the kernel part of the system with modular software packages. In our first
case study, dealing with the realization of the pitch material for Lindberg’s orchestral
work Engine, we discuss the constraints system used by the composer. In the second case
study we present the underlying user-library ‘Viuhka’ that was used to realize a 15-part
electroacoustic work for tape by Heininen. We end with a discussion that lists some of the
experiences that the composers came across during the compositional process.

Keywords: Computer-assisted Composition; Constraints-based Programming; Composi-

tional Systems; Visual Programming

Introduction
Lisp-based computer-assisted compositions (CAC) systems such as CM (Taube,
1991), PatchWork (Laurson, 1996), OpenMusic (Assayag, Rueda, Laurson, Agon &
Delerue, 1999) and PWGL (Laurson, Kuuskankare & Kuitanen, 2008) have existed
for about 20 years. Thus it is appropriate to take a historical look in order to evaluate
how these systems have been used during the compositional process. Laurson,
Kuuskankare and Norilo (2009) give a detailed comparison of these systems.
In this paper, we take a retrospective look at some musical applications utilizing
PatchWork and its successor PWGL. PatchWork was conceived by the first author
during the late 1980s (later an intensive collaboration started with IRCAM), and
PWGL is currently being developed at Sibelius Academy. Our focus covers roughly
the years from 1996 onwards. We will deal with two Finnish composers from two
generations who have strongly influenced the PatchWork and the PWGL systems:
Heininen and Lindberg. A somewhat similar approach can be found in Agon,

ISSN 0749-4467 (print)/ISSN 1477-2256 (online) ª 2009 Taylor & Francis

DOI: 10.1080/07494460903322471
194 M. Laurson and M. Kuuskankare
Assayag & Bresson (2006), that contains composer reports using the OpenMusic
environment that has been developed at IRCAM. OpenMusic, like PWGL, is a
successor of PatchWork.
We are motivated by this choice of composers as their applications show very
different approaches when utilizing CAC tools for their work. In Lindberg’s case, the
result is a score containing pitch and rhythm information (the finalization and
orchestration was done by hand). In Heininen’s case, in turn, the final result is an
electroacoustic work for tape where the whole compositional process was realized
within the CAC system.
PWGL and its predecessor PatchWork are the result of 20 years of research. This
activity has involved numerous expert users, such as composers, researchers and
musicians, and thus PWGL can be seen as an encyclopaedia of different ideas and
approaches. In order to support these ideas, PWGL integrates several programming
paradigms (functional, object-oriented, constraint-based) with high-level visual
representation of data. The most important key points of PWGL can be listed as
follows: high-quality visual appearance; ergonomic, uniform, and efficient graphical
user interface; the ability to operate visually directly with high-level musical data;
powerful intermixing of textual and visual programming; tight integration of its
major tools (i.e. music notation, sound synthesis, scripting, and constraint-based
programming); and cross-platform code-base. Currently the kernel part of PWGL is
finished and it is available as free software (http://www.siba.fi/PWGL, accessed 29
July 2009). The system has found a wide acceptance within the Computer Music
community and it is used and taught in several universities and institutions.
PatchWork and PWGL do not provide a pre-defined aesthetic framework for the
user. Instead, the kernel part focuses on general-purpose tools dealing with visual
programming, music notation, constraint programming, scripting, and sound
synthesis. For more personal work, the system provides the user-library scheme
that has been utilized extensively by numerous composers ranging from Murail to
Ferneyhough. This approach has also been used by Lindberg and Heininen; both have
worked with user-libraries that were developed for their specific needs.
The rest of this paper is organized as follows. We will discuss the two case studies
in chronological order. Thus we start with the work of Lindberg and then we go over
to Heininen. In the former case our focus will be on a constraints-based system and
we will show how it was utilized to calculate the pitch information of a large-scale
orchestral piece. The latter case describes a compositional system that is specialized in
producing complex musical textures. Finally, a concluding section follows that
summarizes and evaluates some of the experiences that the composers encountered
during the projects.

Constraints and Lindberg’s Engine

Engine is a composition by Lindberg for chamber orchestra written for and
commissioned by London Sinfonietta. It was premiered in 1996 and the duration is
 Contemporary Music Review 195
16 minutes. Both the rhythmic and pitch structure of the piece were realized with the
help of PatchWork. The piece was divided into 38 sections. After computing a section
it was translated into Enigma file format. The result was then read into Finale, where
the final orchestration was done by hand. The rhythmic structure was accomplished
with a user-library called GRhythm (designed and implemented by Lindberg
himself). After having a metric score the next step was to fill it with pitch
information. This part of the task was in turn realized with a constraints-based
system called PWConstraints, originally developed by the first author (Laurson,
1996). The system has been afterwards adapted to PWGL and the syntax has
undergone several additions and revisions allowing, among other things, the use of
the rule system also for analytical purposes (Laurson et al., 2008).
During the last 10 years, the use of constraint-based languages in computer-assisted
composition environments has found increased interest. Besides our constraint-based
system, there are currently several other approaches oriented towards musical search
problems, such as Situation (Rueda, Lindberg, Laurson, Bloch & Assayag, 1998),
OMClouds (Truchet, Assayag & Codognet, 2001) and the more recent Strasheela
system (Anders, 2007) based on the OZ programming language.
In the following we will concentrate on the constraints part of the realization and
will first describe briefly the PWConstraints environment. After that we will show
how PWConstraints was used in this particular project.

PWConstraints
PWConstraints is a rule-based programming language where the user writes rules to
describe the end result from many different points of view instead of writing step-by-
step algorithms in a procedural manner. During the compositional process, the user
can add or remove rules in a modular fashion. This allows one to interactively refine
the search problem until satisfactory results are achieved.
A search space is defined as a set of search variables. Each search variable has a domain
containing a list of values. In a rule, a pattern-matching language is used to extract
relevant information from a potential solution. This information is given to a Lisp test
function that either accepts or rejects the current choice made by the search engine.
The pattern-matching part of a rule uses a fairly typical pattern-matching syntax. It
can contain variables (symbols beginning with the character ‘?’: e.g. ?1, ?2, ?foo),
anonymous-variables (plain ‘?’), one or two wild cards (‘*’) and index variables
(symbols that begin with the character ‘i’ and end with an index: e.g. i1, i2, i12). A
variable extracts single values from a partial solution and is typically used in
conjunction with wild cards. By contrast, an anonymous-variable is never bound to a
value, i.e. it only acts as a place-holder in the pattern. The wild cards match any
continuous part of a partial solution. Finally, an index variable extracts values from
an absolute position.
The pattern-matching part is followed by a Lisp-code part that begins with the
expression ‘(?if. . .)’. Besides the variables and index variables the Lisp-code part can
196 M. Laurson and M. Kuuskankare
refer to two special reserved variables ‘l’ and ‘rl’. ‘l’ is the partial solution (including
the current candidate) found so far by the search engine. ‘rl’ is the same list but in
reversed order.
As an example, a rule disallowing all two adjacent equal values in a result is written
as follows (this rule uses a wild card and two variables):

ð ?1 ?2 ð?if ð= ¼ ?1 ?2ÞÞ ‘no equal adjacent values’Þ

The user can also define preferences by heuristic rules. These are similar to the
ordinary PWConstraints rules except that the Lisp-code part of a heuristic rule
returns a numerical value instead of a truth value (heuristic rules never reject
candidates). This scheme allows the search to sort candidates that are accepted by the
ordinary rules. The search tends to favour candidates with high numerical values. For
instance, a heuristic rule that prefers large intervals can be written as follows:

ð ?1 ?2 ð?if ð?abs ð?2 ?1ÞÞÞ ‘prefer large intervals’Þ

Two classical CSP tools (forward checking and back jumping) allow the user to optimize
a difficult problem. Forward checking is useful when some relation in the result is given
in advance. For instance, we may write a rule that states that the interval between the first
and the fifth notes in a sequence is either 5 or 6 (i.e. the relation between the first and fifth
note is fixed). By contrast, back jumping is useful when the search reacts dynamically to
the state of the partial solution. A typical case is, for instance, a melodic rule that allows
only a given amount of repetition within a subsequence of notes. In this case, we do not
know in advance the exact positions where the repetitions will occur.
Besides these basic tools, PWConstraints contains several extensions. The most
important and complex one is used to solve polyphonic search problems. This is
accomplished with a function called Score-PMC. As in a traditional polyphonic score,
the user operates with several layers (parts) of events (notes). The rhythmic structure of
a search problem is normally prepared in advance in a score editor. This input score
(which can be arbitrarily complex) is given as an argument to the search engine. The
search, in turn, aims at filling the input score with pitch information according to the
given rules.

The piece Engine

When realizing the pitch structure of Engine, the main tool was naturally Score-PMC,
as the rhythmic structure for each section was calculated in advance. Next we give an
overview of the rules that were used during the search. This discussion is necessarily
greatly simplified and does not cover all the rules used during this project.
In order to produce musically meaningful results, a section typically needs 30–40
rules. These rules can be divided roughly into four main categories: melodic,
harmonic, voice-leading and crossing-ambitus.
 Contemporary Music Review 197
Melodic rules can be divided into two main groups: interval control, and control of
repetitions of melodic cells. During the realization process, the composer developed a
personal library of allowed interval successions. This was done in order to personalize
the musical material and to treat problematic cases. Another type of interval rule
checks that in every adjacent-note group (the length varies from three to six) the
minimum and maximum pitches should not form octaves. Some interval rules are
sensitive to the rhythmic context. Fast successions of notes have a different interval
character than slow ones. The control of melodic cells consists of avoiding direct
repetitions within a given window size.
Harmonic rules forbid octaves (unisons are allowed) and require that vertical
interval formations have a given set-class identity. Often chord formations having a
long duration are controlled more strictly than shorter ones.
Voice-leading rules are always applied for two parts at a time. A cross-identity rule
forms a 2ÿ-by-2 matrix where the first row consists of a two-note melodic succession
of a given part and the second row consists of a simultaneous two-note succession of
another part. The rule states that the diagonal pitch-class relations in this matrix
should not be equal. A similar but stricter version of this rule exists where the matrix
size is 2-by-3. Another voice-leading rule states that two parts should result in an
almost parallel movement. Voice-leading rules can easily be chained to control more
than two parts. For instance, when the last mentioned rule is applied, say, to parts 1
and 2, and then to parts 2 and 3, the result is that the parts 1 and 3 follow the same
rule.
Like voice-leading rules, crossing-ambitus rules are applied for two parts. They
deal with cases where one wants to prevent two parts from crossing each other (parts
can form unisons). This category contains also an ambitus rule that controls the
minimum and maximum distance between two parts.
One of the most important targets in this project was that the user must be able to
localize rules easily for certain musical situations. For instance, a melodic rule may
react differently to rhythmical two-note patterns (such as short–short, short–long,
long–short, long–long); chord formations that have a long duration are controlled
more strictly than short ones; parts may form different melodic and voice-leading
textures (for instance parts 1–2 may use repetitions and large skips, parts 3–4 can be
more static but avoid repetitions, parts 5–8 can be controlled by rules that force them
to move in an almost parallel fashion), etc. An example of this kind of multi-layered
texture is given in Figure 1. It shows the beginning of section two.

Viuhka and Heininen’s The Blue Exposure

The Blue Exposure, composed in 2002, is a 15-part piece for computer-generated tape
by Paavo Heininen. It was composed using two user-libraries: Viuhka and
PWCollider. In the following we will concentrate on the first part of the
compositional process, which was realized with Viuhka. This section focuses on
the visual aspects of our system (Figures 2–4). The composer can refine and redo the
 198
M. Laurson and M. Kuuskankare

Figure 1 A six-measure realization. The constraint solver applies 40 rules to generate the pitch material for this excerpt. The rhythm
structure was prepared before the search using Lindberg’s rhythm library.
 Contemporary Music Review 199
compositional process, working directly at patch level modifying various aspects of
the input data with an almost immediate visual and audio feedback.

Viuhka
Viuhka (Finnish, in English ‘Fan’) is a user-library designed for and based on ideas by
Heininen. The system was originally realized by the first author in the mid 1990s. Viuhka
allows the user to create complex, multi-layered musical textures. These can be used to
produce scores for instrumental music and/or to provide material for sound synthesis.
The end result of a Viuhka patch can either be displayed in a music notation editor or in
a piano-roll display. Finally, the resulting texture is translated to a synthesis file. More
recently the Viuhka system has been adapted to PWGL and it is used, for example, for
our macro-note scheme that allows the simulation of complex playing techniques for
physics-based instrument models (Laurson & Kuuskankare, 2008).
The starting point in Viuhka is a group of break-point functions (‘Viuhka bpfs’)
that constitute the pitch field (harmonic skeleton) of the result. Viuhka bpfs provide
the main pitch material which can then be reacted to (or elaborated on) by different
sorts of Viuhka ornaments. Besides ‘typical’ ornaments (like grace notes, trills, etc.),
the Viuhka ornaments can also be runs, repetitions, chords, clusters, clouds or even
complete Viuhka patches (i.e. a Viuhka patch can contain other Viuhka patches).
The user typically divides a Viuhka patch into musical time slices or segments. The
durations of the segments are given as a list of delta-times (or time intervals). The
structure of each segment (i.e. number of layers, rhythmic structure, time
modification, ornaments and synthesis information) is normally given inside an
abstraction window. There the user defines the Viuhka parameter values by using ‘v-
params’ and optional ‘i-params’ boxes (the former boxes are used to define note
events, while the latter ones define instrument parameters that are used by the
synthesis engine). The output of the ‘v-params’ boxes is then given to the main
Viuhka box (called ‘mk-viuhka’), which in turn calculates the final score.
Several inputs for the ‘v-params’ and ‘i-params’ boxes accept as arguments circ-
lists. Circ-lists are like ordinary Lisp lists except that the items are read in a circular
fashion (i.e. after reading the last item, the next item is accessed from the beginning
of the list). A circ-list can either contain constants (numbers, symbols, etc.) that
simply return themselves, special variables that are evaluated when they are being
read, break-point functions, or Lisp expressions.
Figure 2 gives an example where a ‘mk-viuhka’ box (1) generates a result score (4)
in piano-roll format (see the ‘2D-Editor’ box). The first input of the ‘mk-viuhka’ box
is connected to a 2D-Editor box that contains two break-point functions that define
the global pitch field for our result (2). The sequence lasts for 15 seconds (second
input). Finally, the third input is connected to a list of ‘v-params’ boxes that define
the segments of the overall structure of the piece. Here we use only one ‘v-params’
box (3) thus resulting in a one-segment, one-layer 15-second texture. The user can
append additional segments by adding more ‘v-params’ boxes to the patch.
200 M. Laurson and M. Kuuskankare

Figure 2 A Viuhka example that generates a 15-second texture consisting of a sequence of

alternating ordinary low notes, rapid up–down gestures in the high register, grace notes
and clusters of varying densities. The up–down gesture material is generated by calling
recursively another Viuhka patch that is found inside the ‘Super-note’ abstraction.

Of special interest here is the ‘ornaments’ input (see the fourth input of the
‘v-params’ box that is connected to a list box that defines a circular list of
ornaments). The predefined ornaments can be referred to by using short symbols
(e.g. ‘n’, ‘c’, ‘g-1’, etc.). The user can augment the ornament repertoire by defining
Viuhka sub-patches visually. The circular list consists here of an ordinary note (‘n’), a
connection to another Viuhka patch (the ‘Super-note’ abstraction), a grace note (‘g-
1’), and a cluster (‘C’).

Ripples
Two figures give an overview of the realization of Ripples, the fifth movement of The
Blue Exposure. The movement lasts for 92 seconds. It utilizes a complex pitch field
definition (Figure 3) that is clearly reflected in the final result (Figure 4). The overall
form consists of 15 segments, where each ‘v-params’ box layer utilizes individual
parameters to realize the local textures. This formal plan can be split into three main
sections each lasting for approximately 30 seconds. Each main section can, in turn, be
split into five segments. Towards the very end of the piece we find a short coda lasting
for two seconds.
Individual segments typically occur several times. For instance, the opening
segment (from 0 s to 13 s) can be found later twice (from 30 s to 43 s, and from 78 s
 Contemporary Music Review 201

Figure 3 Viuhka bpfs defining the global pitch field of the whole 92-second movement of
Heininen’s piece. The vertical lines denote the segment starts. See Figure 4 for the final
realization.

to 83 s). The durations of the reoccurring segments can vary (our example segment
has three occurrences that have the following durations: 13 s, 13 s, and 5 s). In this
case, the composer needs to define the segment only once (using the ‘v-params’ box
scheme, see Figure 2), and later it can be reused in the piece where it is interpreted
differently depending on its duration and on its time position in the global pitch
field.

Concluding Discussion
This paper has presented two approaches aimed at solving some practical and
principal compositional problems using various tools in a CAC environment. Despite
the different approaches, both composers seem to be motivated by the need to
formalize their work process in a way that can be articulated in a programmable
system such as PatchWork and PWGL.
For instance, in the case of Lindberg’s use of the constraint system, the program
notes of Engine give the following background information (Nieminen, 1996):
‘Engine brings counterpoint back up to date in Lindberg’s musical vocabulary, a
counterpoint which allows the music to live in symbiosis with the rules and
constraints imposed by the composer. The reason he uses constraint machines is that
he wants to find solutions enabling him to avoid the mannerisms of his own style. For
the composer, establishing constraints also means analyzing and decomposing his
style into rules, in order to master it better.’
According to Heininen (in a personal conversation with the composer on 5 June
2009), the main motivation behind Viuhka was to develop a system that is specialized
in dense, minimalist and pointillist textures consisting of very short note events.
These textures are typically not suitable for instrumental music, and thus as a rule the
resulting scores are realized using sound synthesis. The synthesis part, in turn, is
realized normally using simple enveloped sine wave synthesis where the spatialization
of the individual note events is an integral part of the composition process. There is a
tension between the local definition of note events (see the ‘v-params’ scheme in
Figure 2) and the global long-term specifications of the overall form (see the pitch
field definition in Figure 3): the short events have a stochastic nature (this is the result
202 M. Laurson and M. Kuuskankare
of using very short events having non-periodic rhythms combined with the tendency
of using non-stationary situations in the pitch field), whereas the pitch field
definition is deterministic by nature (this part is carefully planned by the composer
before the actual generation of the note events). A further reason for using short note
events and fast pointillist textures is that this allows one to realize the underlying
pitch field definition with great precision (compare Figures 3 and 4).
Although the current state of CAC tools presented in this article makes them useful
and allows the user to solve a wide range of compositional problems, it is clear that
this evolution needs still further research and effort to meet the highly diverse and
specialized needs of composers and musicians. Thus, for instance, one critique that
Lindberg mentions in dealing with the constraints approach is that the system
becomes, in more complex cases, difficult to use and maintain, as one has to

Figure 4 The final score for Ripples, the fifth movement of Heininen’s piece The Blue
Exposure, shown in piano-roll notation. The time-line information above the musical
events is given in seconds.
 Contemporary Music Review 203
formalize a large number of rules: in a way the user has to formalize ‘everything’
(Stenius, 2006). One specific problem in using the Viuhka system, in turn, is that the
user has to work with fairly low-level parameters dealing with delta-times, tempo-
functions, articulations, etc. This makes it occasionally difficult to achieve natural-
sounding and well-articulated textures and thus the compositional process may
require a lot of trial and error until satisfactory results are achieved.
In order to cope with these problems, further research should be done that would
allow the user to deal with more high-level aspects of the composition process. In
order to make the PWGL environment more accessible to the computer music
community, we need an on-going discussion and feedback from users who are
experts in their fields.

Acknowledgements
The work of Mikael Laurson and Mika Kuuskankare has been supported by the
Academy of Finland (SA 114116 and SA 105557).

References
Agon, C., Assayag, G. & Bresson J. (Eds.). (2006). The OM composer’s book. 1. Editions Delatour
France/Ircam-Centre Pompidou, Paris.
Anders, T. (2007). Composing music by composing rules: design and usage of a generic music
constraint system. PhD Dissertation, Queen’s University, Belfast.
Assayag, G., Rueda, C., Laurson, M., Agon, C. & Delerue, O. (1999). Computer Aasisted composi-
tion at IRCAM: from PatchWork to OpenMusic. Computer Music Journal, 23(3), 59–72.
Laurson, M. (1996). PATCHWORK: a visual programming language and some musical
applications. PhD Thesis, Sibelius Academy, Helsinki.
Laurson, M. & Kuuskankare, M. (2008). Towards idiomatic and flexible score-based gestural
control with a scripting language. Proceedings of NIME’08 Conference, 34–37. Genova, Italy:
Università degli Studi di Genova.
Laurson, M., Kuuskankare, M. & Kuitunen, K. (2008). The visualisation of computer-assisted music
analysis information in PWGL. Journal of New Music Research, 37(1), 61–76.
Laurson, M., Kuuskankare, M. & Norilo, V. (2009). An overview of PWGL, a visual programming
environment for music. Computer Music Journal, 33(1), 19–31.
Nieminen, R. (1996). Magnus Lindberg: Engine. Programme note. Retrieved June 7, 2009, from
http://www.chesternovello.com/Default.aspx?TabId¼2432&State_3041¼2&workId_3041¼
7693.
Rueda, C., Lindberg, M., Laurson, M., Bloch, G. & Assayag, G. (1998). Integrating constraint
programming in visual musical composition languages. Paper presented at the ECAI 98
Workshop on Constraints for Artistic Applications, Brighton, UK.
Stenius, C. (2006). Chaconne: En bok om Magnus Lindberg och den nya musiken. Helsinki:
Söderströms.
Taube, H. (1991). Common music: a music composition language in Common Lisp and CLOS.
Computer Music Journal, 15(2), 21–32.
Truchet, C., Assayag, G. & Codognet, P. (2001). Visual and adaptive constraint programming in
music. In Proceedings of the International Computer Music Conference, 346–352. Havana,
Cuba: International Computer Music Association.