algorithmic composition for flute and accompaniment …mdv/courses/cm30082/projects... ·...
TRANSCRIPT
Algorithmic Composition for Flute and
Accompaniment
Lynda Annette Watson
Bachelor of Science in Computer Science with Honours
The University of Bath
May 2008
Page | II
This dissertation may be made available for consultation within the
University Library and may be photocopied or lent to other libraries
for the purposes of consultation.
Signed:
Page | III
Algorithmic Composition for Flute and Accompaniment
Submitted by: Lynda Annette Watson
COPYRIGHT
Attention is drawn to the fact that copyright of this dissertation rests with its author. The
Intellectual Property Rights of the products produced as part of the project belong to the
University of Bath (see http://www.bath.ac.uk/ordinances/#intelprop).
This copy of the dissertation has been supplied on condition that anyone who consults it
is understood to recognise that its copyright rests with its author and that no quotation
from the dissertation and no information derived from it may be published without the prior written consent of the author.
Declaration
This dissertation is submitted to the University of Bath in accordance with the
requirements of the degree of Bachelor of Science in the Department of Computer
Science. No portion of the work in this dissertation has been submitted in support of an application for any other degree or qualification of this or any other university or
institution of learning. Except where specifically acknowledged, it is the work of the
author.
Signed:
Page | IV
Abstract
The increasing accessibility and capabilities of computers have lead to many
more composers making use of them in their work. Many applications have
been developed for assisting the composer, as well as for playing and storing
music. Although there are now many programs for computer music composition, very few successfully imitate a given style
and there are no
widely available programs for generating music for certain instruments. This
project aims to develop a system capable of composing music for a modern transverse flute, focusing on the style of the classical era.
Flute Composer is a computer application for generating classical style music for flute, also providing a basic accompaniment part. Flute Composer
uses a composition algorithm based on a combination of stochastic processes
and pattern matching, also making use of the concepts of Lindenmayer
Systems and fractals. The application produces music in both manuscript pdf format as well as a MIDI audio version, and achieves a reasonable
approximation to the desired style.
Page | V
Acknowledgements
I would like to thank my supervisor Professor John Fitch for his help and
support throughout the project. I would also like to thank Ollie and Penny, without whom I would never have made it to the end of this project!
Page | 6
Table of Contents
1. Introduction (Page 7) 1.1 What is Algorithmic Composition? .............................................................................9
1.2 Algorithmic Composition and the Flute .................................................................... 10
1.3 Definitions ............................................................................................................... 10
2. Literature Review Part 1 - Flutes and Flute Music (Page 11) 2.1 Introduction ............................................................................................................ 11
2.2 Definitions ............................................................................................................... 11
2.3 Boehm Flutes .......................................................................................................... 12
2.4 Flutes in Classical Music........................................................................................... 12
2.5 The Notion of Playability ......................................................................................... 12
2.6 Features of Classical Flute Music ............................................................................. 14
2.7 Structure in Classical Flute Melodies ........................................................................ 15
2.8 Accompaniment ...................................................................................................... 15
3. Literature Review Part 2 - Algorithm Types and
Composition Methods (Page 16) 3.1 Introduction ............................................................................................................ 16
3.2 Stochastic Processes ................................................................................................ 16
3.3 Chaotic Systems ...................................................................................................... 18
3.4 Fractals and L-systems ............................................................................................. 19
3.5 Artificial Intelligence, Genetic Algorithms and Neural Networks .............................. 20
3.6 Other Methods ........................................................................................................ 21
3.7 Summary and Evaluation of Methods ...................................................................... 22
4. Requirements Analysis and Specification (Page 23) 4.1 Introduction ............................................................................................................ 23
4.2 Project Requirements (High Level) ........................................................................... 24
4.3 Input and Interface Requirements ........................................................................... 24
4.4 Generic Output Requirements ................................................................................. 24
Page | 7
4.5 Structure and Style Requirements ........................................................................... 25
4.6 Playability Requirements ......................................................................................... 25
4.7 Non-functional Requirements ................................................................................. 26
4.8 Scope of the Project ................................................................................................ 26
5. Design (Page 28) 5.1 Introduction ............................................................................................................ 28
5.2 Identification of Program Components .................................................................... 28
5.3 Inputs and Outputs .................................................................................................. 28
5.4 Development Environments and Additional Tools ................................................... 29
5.4.1 Development Languages ................................................................................... 29
The C Programming Language ............................................................................... 29
The C++ Programming Language............................................................................ 29
5.4.2 Musical Software Tools ..................................................................................... 29
Producing Manuscript Output ............................................................................... 29
Producing Audio Output ........................................................................................ 30
5.5 The Initial Algorithm Design..................................................................................... 31
5.6 Limitation of the initial algorithm ............................................................................ 32
5.7 Development of Structure ....................................................................................... 32
5.8 Improving Rhythmic Structure and Reducing Syncopation ....................................... 34
5.9 Increasing the Occurrence of Arpeggios and Scale Based Runs in the Musical Output
..................................................................................................................................... 35
5.10 Tying the Melody Back to the Chord ...................................................................... 36
5.11 Increasing Repetition ............................................................................................. 37
5.12 High Level Diagram of Complete Application ......................................................... 40
5.13 Accompaniment .................................................................................................... 41
6. Notes on Implementation (Page 42 ) 6.1 Introduction................................................................................................................42
6.2 Representation of musical structures.........................................................................42
6.3 Generation of Chords from the L-system....................................................................43
6.4 Note Splitting and Rhythm Generation.......................................................................43
6.5 Low Level Pattern Matching........................................................................................44
6.6 High Level Pattern Matching.......................................................................................44
6.7 Summary of Implementation......................................................................................46
Page | 8
7. Results and Evaluation of Musical Output (Page 47) 7.1 Validation of Requirements ..................................................................................... 47
7.1.1 High Level Requirements .............................................................................. 47
7.1.2 Input and Interface Requirements ................................................................ 48
7.1.3 Generic Output Requirements ...................................................................... 49
7.1.4 Structure and Style Requirements ................................................................. 49
7.1.5 Playability Requirements .............................................................................. 51
7.1.6 Non-functional Requirements ....................................................................... 52
7.2 Further Evaluation of Musical Output ...................................................................... 53
7.3 Summary of Evaluations .......................................................................................... 55
8. Conclusions and Further Work (Page 56) 8.1 Conclusions ............................................................................................................. 56
8.2 Further Work........................................................................................................... 57
Appendices A. Flute Composer Sample Outputs
B. Contents of Data Disc
C. Complete Code Listing
Page | 9
Chapter 1: Introduction
1. Introduction This section aims to introduce the concept of algorithmic composition and the
motivation for this project.
1.1 What is Algorithmic Composition? Algorithmic composition is the process of creating music using algorithms. There are
many different approaches to composing music with algorithms. Some are based on
models derived from the structure of a particular genre of music or the style of a given
composer, while others are use methods that often have no obvious connection to
music, for example, randomly generating data or reusing data collected for other
purposes and mapping it onto notes in the musical scale.
Although algorithmic composition is now synonymous with the use of computers in
generating music, algorithmic composition does not have to involve computers. Indeed,
the concept of creating music using a set of predetermined rules pre-dates the
development of computers as we know them. A particularly famous example of this is
the ‘musical dice game’ created by Mozart in 1787 for composing short waltzes (or
minuets), which consisted of 176 different note patterns of length three quavers and
two charts for determining how to put them together, based on the outcomes of
repeatedly rolling two dice (Jones 1991, Mozart 1787). There is evidence that people as
far back as ancient Greeks, such as Pythagoras and Plato, studied the relationship
between formal rules of mathematics and music (Ferreira 2002). However, in general,
the term algorithmic composition is now used to refer to the process of creating music
using a computer algorithm.
The increasing capabilities of computer hardware and software, in addition to the
development of a wide range of accessible development tools, over the later part of the
twentieth century brought greater interest to the field of algorithmic composition. For
perhaps the first time, many more composers were able to create their own programs
for generating music without needing the use of expensive specialist technology or
having intimate knowledge of low-level machine language. The increase in processing
power has allowed for increasingly complex and sophisticated algorithms to be
developed, and new discoveries in a wide range of fields have provided many new
techniques to base composition algorithms on.
Page | 10
1.2 Algorithmic Composition and the Flute This project will focus on algorithmic composition for flute, and consider algorithms for
both generating flute melodies and creating suitable accompaniment for them.
Currently, there are almost no widely known programs for algebraically generating flute
music.
1.3 Definitions Algorithm – An algorithm is “a sequence of unambiguous instructions for solving a
problem” (Levitin 2007). Levitin goes on to say that the unambiguous aspect of an
algorithm is particularly important and cannot be compromised.
Composition – With regards to music, composition can be defined as: “Composition
(noun): 1. a piece of music that someone has written 2. the process or skill of writing
music” (Cambridge 2005).
Music – The meaning attributed to the term ‘music’ is key to the way we view
algorithmic composition and often fundamental to how we judge the success of a
composition algorithm and its output. One famous definition is that music is “organised
sound” (Edgard Varese) allowing a very broad interpretation as to what may be
recognised as music. The Compact Oxford English Dictionary gives a specific definition:
“music - noun 1 the art of combining vocal or instrumental sounds in a pleasing way. 2
the sound so produced. 3 the written or printed signs representing such sound” (Oxford
2005). Although this narrows down the sounds that can be classed as music, the
definition is still very subjective, as different people may have very different views on
what constitutes a pleasing arrangement of sound.
Page | 11
Chapter 2: Literature Review Part 1 - Flutes and Flute Music
2.1 Introduction The term flute can be used to refer to a broad range of blown instruments, including
panflutes, oriental instruments such as the shakuhachi and other cultural instruments
around the world. However, today the term flute is most commonly used to refer
transverse instruments, which are “a high-pitched wind instrument consisting of a tube
with holes along it, usually held horizontally so that the breath can be directed against a
fixed edge” (Oxford 2005). Music played by flutes varies vastly between the types of
instrument.
2.2 Definitions It is necessary to define certain terms within the project that may have a wider meaning
in a more general context:
‘Flute’ – Within this project, the term flute is used to refer to modern Western concert
flutes, typically those using the Boehm system.
‘Classical style’ – The term classical music is often used by non-musicians to refer to
music composed before the start of the twentieth century. More precise definitions
usually refer to the classical era as lasting from the early eighteenth century to early
nineteenth century, preceded by the Baroque era (from the beginning of the
seventeenth century to this time) and followed by the Romantic era (lasting until early in
the twentieth century), although there are overlaps both in dates given and the style of
the three periods. In the context of this project, the term classical style is used to refer
to the style(s) of music typically seen during the period spanning late Baroque era
through to early Romantic era, encompassing the classical era.
Page | 12
2.3 Boehm Flutes Boehm flute is the name given to transverse flutes which are played by blowing across a
mouth piece and use the Boehm system.
The Boehm system of fingering and key position was developed between 1810 and 1947
by Theobald Boehm (1794-1881), and is now the accepted standard for Western concert
flutes. Figure 4.3 (below) shows an example of a modern flute using the Boehm system.
Figure 2.1 – A Trevor James “Privilege” Flute
Modern concert flutes are approximately 27 inches long and consist of three parts; the
head joint, consisting of a tube which is closed at one end with the mouth piece and lip-
plate, the main body where most of the tone holes and keys are positioned, and the foot
joint with three extra keys and holes. They have a range of three octaves, upwards from
middle C.
2.4 Flutes in Classical Music Typical flute music of this time included concertos, where a solo instrument is
accompanied by an orchestra, and sonatas, where the solo instrument is most
commonly accompanied by a keyboard instrument. The main composers of these
periods for flute include Antonio Vivaldi (1678-1741), Johann Sebastian Bach (1685-
1750), Georg Friedrich Handel (1685-1759) and Wolfgang Amadeus Mozart (1756-1791).
2.5 The Notion of Playability The term playability refers to whether an instrument or piece of music is playable,
defined “playable (adjective): describes a piece of music that is not too difficult for
someone to play” (Cambridge 2005). This is an important issue to address when creating
algorithms to generating music to be played by a physical instrument, as there is little
point producing music that cannot be played. Within this project, specific consideration
will be given to factors that determine whether music is playable by a flute. A number of
preliminary factors have been determined, relating to the limitations of both the
instrument and human flautists, and are detailed below:
Page | 13
Physical Limitations of the instrument:
The range of a standard concert flute is three octaves with the lowest note
being middle C. Although some instruments may have a special foot joint to
extent the range by one or two semitones below middle C, this is uncommon
and it should not be assumed that flautists will be able to play these notes, so
for this reason will not be considered within this project.
A flute plays in concert pitch, and the only notes playable on a flute are the 12
semitones of an octave. Although intermediate pitches can sometimes be
achieved by partially covering a hole or depressing a key, it is very difficult to
accurately attain any given frequency and the sound quality of the note
produced is generally poor.
For similar reasons to the above, musical techniques such as glissandos cannot
truly be achieved on a flute.
A flute is only capable of playing one note at a time, and notes cannot overlap.
This is in contrast to instruments such as pianos and panpipes, where it is
possible to sustain multiple notes concurrently.
Limitations of a human flautist:
Notes can only be sustained for a certain length of time. This time is limited to
the amount of time the flautist can sustain the correct air pressure for the note
across the mouth hole, and is therefore dependent not only on the lung capacity
and technique of the flautist, but also on the pitch and dynamics of the note
being played. Generally, lower and quieter notes require less air to sustain them
and so can be held for longer.
Big ‘jumps’ in pitch between consecutive notes may be difficult to play,
especially if there is very little time between the two notes and the notes are in
different registers, requiring the flautist to change the blowing pressure rapidly.
Experienced flautists overcome this problem with practice; however it is still
worth taking into account when composing for the flute.
The speed at which notes can be played is limited by how fast the flautist is able
to move their fingers between the fingering positions. Generally, the more
proficient a flautist is, the faster these transitions can be made. However, there
is a limit to how fast even a highly skilled flautist is able to change notes, and
whether a piece is playable is affected both by the tempo of the piece and by
how short the notes are.
Some key signatures are easier for the flute to play in than others, purely due to
the design of the instrument and the positions of the keys. The layout is based
predominantly based on the scale of C Major, with many of the fingering
positions for sharps and flats being more complicated, and so key signatures
containing several sharps or flats often involve more complex fingering changes.
Page | 14
2.6 Features of Classical Flute Music In order to develop a program capable of generating flute music in a classical style, it is
necessary to take a closer look at the defining characteristics of such music. To assist in
the process of composition, rules can be formulated based on these features. The
following rules are by no means comprehensive, nor do they apply to all flute music of
the classical period and style. However, it can be said that the following are generally or
often true of classical flute music:
Music is often very scale-based, with lots of ‘runs’ up and down the scale, hence
it is common for a note to be followed (and preceded) by a pitch that is
consecutive to it in the scale.
Arpeggios or ‘broken chords’ are also very common within classical flute music.
Most of the notes in a piece are from within the major/minor scale of the key
signature, although a small number of chromatic notes may also be used.
The most commonly used chords are the tonic and dominant of the key,
followed by the subdominant and the relative minor.
Pieces almost always end in the tonic chord, and generally also start in the tonic.
The most common chord changes (cadences) are dominant-to-tonic (known as a
perfect cadence) and tonic-to-dominant (imperfect cadence). Other common
changes include subdominant-to-tonic and subdominant-to-dominant. Pieces
often end with a perfect cadence.
Each section of a piece usually consists of several phrases (shorter sequences of
notes, analogous to phrases or sentences in speech).
Typical features of the style include sequencing, where fragments of note
patterns are repeated, often at a higher or lower pitch than the original.
Inversion of such patterns may also occur.
Repeating motifs frequently occur; often short segments or phrases are played
three or more times before moving on.
Section lengths are approximately in multiples of four bars.
Accompaniment is typically homophonic, often with a (mostly) isochronous
rhythm.
Whole sections of a piece may be repeated, with or without variations.
Page | 15
2.7 Structure in Classical Flute Melodies Classical flute music generally has a clearly defined structural hierarchy, with pieces
being divided into different sections, which in turn are divided into phrases and then
sub-phrases consisting of one of more notes or note patterns, each of which may be
repeated or varied throughout the piece (as shown below in figure 2.1).
Figure 2.1 - An example of a possible structure for a classical flute piece
2.8 Accompaniment The accompaniment of the Classical period is largely homophonic, in contrast to the
polyphonic accompaniment style of the earlier Baroque period. At around this point in
time, there was a transition from the contrapuntal harmonies between parts, with
independent rhythms, to a more distinct separation of the main melody and a simple,
often isorhythmic, harmony based accompaniment. Although polyphonic counter
melodies do not feature in this accompaniment, there is often a small amount of
decoration or ornamentation to compliment the melody lone, often in the form of
imitation or inversion of sequences originally heard in the melody.
Although there are obviously far more detailed rules to base classical accompaniment
on, these will not be studied in great detail as the accompaniment is not the primary
focus of the project.
Page | 16
Chapter 3: Literature Review Part 2 - Algorithm Types and Composition Methods
3.1 Introduction Over the years, computer music creators have developed a number of strategies for
creating composition algorithms. These generally fall into two classes, first identified by
Lejaren Hiller (Berg 1996), those that are based on the structure of a particular style of
music and the implementation of music theory, for example David Cope’s Experiments
in Musical Intelligence (Cope 1992), and those derived from data, structures or
equations in non-musical fields such as mathematics, biology of physical sciences, such
as L-systems (Prusinkiewicz 1986) and cellular automata (McAlpine et al. 1999). The
algorithms developed can be broadly classified into two types; deterministic and non-
deterministic algorithms. Deterministic algorithms will always provide an identical
output if given the same input, and so in this case it is the input data that must be
varied. Non-deterministic approaches include stochastic methods, where for any given
input, it is impossible to predict the output exactly (Roads 1996).
This section describes some of the more popular methods, as well as those of particular
interest in the development of Flute Composer.
3.2 Stochastic Processes Stochastic processes involve decisions made on the basis of random numbers while still
maintaining an overall structure or trend. The values of these numbers determine which
notes are selected at each stage of the composition process and it is impossible to
determine precisely any future outcomes. A trivial example is using a uniform
distribution to map each number to a note in the scale, and outputting a string of notes
corresponding to the numbers, however the output of such an algorithm is unlikely to
show any musical structure or meaning.
Compositions algorithms that make use of stochastic processes normally use a
probability table to determine the likelihood of each musical event relative to the others
(Roads 1996). The randomly generated numbers are mapped onto the probability
distribution and used to determine the sequence of musical events.
Possibly the most famous composer to develop programs to produce stochastic music
was Iannis Xenakis. In his book Formalised Music (Xenakis 1971), Xenakis discusses free
Page | 17
stochastic music and then goes on to talk about Markovian stochastic music. The latter
is based on Markov chains, a concept created by Andrey Markov at the start of the
twentieth century. Markov chains consider the context of events by taking into account
the events which immediately precede it, allowing greater control over note patterns, in
contrast to other stochastic processes where the probabilities of future events are
independent of the current event and relationships between different musical events
cannot be so well defined. As said by Charles Ames (Ames 1989), “the greatest strength
of Markov chains is their capability for predicting the immediate future based on what
has happened in the recent past” which is obviously important when attempting to
generate a coherent piece of music that appears to flow naturally from one note or
phrase to the next. Markov chains are not restricted to taking only the current event
into account; an N-th order Markov chain will consider the N events preceding the new
event being determined (Jones 1981). In more practical terms, a first-order Markov
chain can be represented by a two-dimensional probability table, with each row of
probabilities representing the probability distribution of possible next notes for the
current note, and there will be a row for each possible note and a column for each of all
the possible notes any current note can move to.
Probability distributions for stochastic processes may take the form of a specific
distribution such as linear, exponential, bell-shaped or U-shaped distributions (McAlpine
1999) where this is appropriate to the application, however in many instances more
irregular distributions may be necessary to reflect certain stylistic devices in the music or
the perceived likelihood of a particular component of a method occuring.
The potential applications of stochastic processes in algorithmic composition are widely
varied. Probabilities can be used as a method in their own right to entirely determine
the piece from start to finish, using processes such as Markov chains, or they can be
used to make decisions within other models such as chaotic systems or pattern
matching approaches. Probabilities can be used to determine chord cadences, note
lengths and pitches as well as many other components of the musical outputs.
Kevin Jones (Jones 1981) introduces the concept of space grammars within the context
of music. He uses a simple one-dimensional space grammar to generate a mono-pitched
rhythmic output by following one of two production rules (A →AA and A→a) with
probabilities (p) and (1-p) respectively. This generates a derivation tree that can then be
interpreted spatially and rhythmically by starting with a one-dimensional line
representing the length of the piece, and every time the first rule is applied, the space is
split equally into two halves, and these halves are then further split recursively when the
first rule is applied to the A denoting that half. When the second rule is applied, the
splitting process on that part of the line will cease. Musically, the divided line can then
be interpreted as the piece of music, with the note lengths being proportional to the
length of the segment of the line. Jones then proceeds to explain a possible mapping of
a two-dimensional space grammar onto musical notation for both pitch and rhythm, and
reflects upon possible applications of space grammars of even greater dimensions.
Page | 18
3.3 Chaotic Systems The behaviour of non-linear dynamic systems may be classified into three categories
(Leach 1995):
“Constant (where all points are identical)”
“Oscillatory (where the orbits consist of a repeating set of k distinct points)”
“Chaotic (where no point in the sequence is a repeat of a previous point)”
Due to its ability to potentially create ideas that almost repeat before going onto a new
idea, giving the listener some predictability on a small scale without being absolutely
predictable over time (Leach 1995), chaotic systems are probably the most interesting
category from a compositional point of view.
“Chaos is the generic term used to describe the output, under certain conditions, of
nonlinear dynamical systems” (Bidlack 1992). When applied recursively, the behaviour
and output of non-linear (or chaotic) functions is likely to appear to have little or no
structure at a low level, but when viewed across a wider scale similar patterns become
evident (Harley 1995). By returning the output of each iteration as the input of the next,
a simple dynamic algorithm can be used to generate complex musical outputs.
Bidlack (Bidlack 1992) uses systems of mathematical equations to model chaotic
systems, which he classifies into two categories: dissipative systems (the most common)
which lose energy as they progress, akin to physical phenomena involving friction where
energy is lost to the surrounding environment, and conservative systems where energy
is maintained. In particular he considers the suitability of the Henon Map, the Standard
Map, the Lorenz System and the Henon-Heiles System as models for algorithmic
composition, using the output of these systems to determine musical parameters such
as pitch and rhythm.
Possible interpretations of chaotic systems in algorithmic composition include directly
mapping the output of a chaotic equation onto musical values. This can lead to results
that are “aesthetically pleasing or at least acceptable” (Harley 1995). However this
process alone is unlikely to accurately model a given style of music without further
manipulation of parameters.
Leach and Fitch also consider the use of chaotic systems in both music and nature, and
their paper (Leach 1995) describes their use of dynamic equations in creating music
modelled on concepts in nature. They describe how an orbit of a non-linear dynamic
system can be sampled and directly translated onto an event tree to represent the
structure of a piece.
Page | 19
3.4 Fractals and L-systems The concept of fractal geometry is used to describe shapes that have a similar structure
no matter what level they are viewed from. Hence, if you take a fractal shape and zoom
in on a small section of it, it should appear the same. One of the most famous examples
of this is Koch’s Snowflake, generated by repeating the same process recursively on each
new side of the snowflake, namely dividing the each side into thirds and using the centre
third as the base of an equilateral triangle, and in effect creating four new sides for each
existing side. This is then repeated for a (theoretically) infinite number of times. Not all
fractal forms are so completely deterministic; many use probabilities to decide which of
a set of possible rules to follow. However, the overall effect of similarity remains the
same.
They are of interest in music as in many ways several styles of music are structured
similarly, with self-repetition occurring throughout the duration of the piece and
repetition at a low level, such as note patterns of a few notes long, are structured in
much the same way as the repetition of whole phrases or sections at a higher level.
One composer who has successfully incorporated the concept of fractals into an
algorithmic composition system is Charles Dodge. In ‘Profile’ (Dodge 1988) he attempts
to create ‘fractal music’ by recursively using the same process across multiple
instrument lines to generate a string of notes that will occur within the duration of a
given note in the line above. Hence, the later developed lines (which are written to be
played concurrently) are self similar to earlier lines, but on a ‘smaller’ scale meaning that
the note durations are shorter.
Lindermayer Systems (L-systems) have many similarities to fractal forms. Originally
introduced in 1968 by Lindenmayer, they were originally intended to formally describe
“the growth patterns of living organisms” and have since been extensively studied
within biological fields and computer biology (Prusinkiewicz 1986). L-systems recursively
substitute previous productions to generate strings of symbols. However, unlike
Chomsky grammars these productions are applied to all strings in the string
concurrently. They are well suited for use in composition styles where there is a large
amount of structural repetition at a variety of levels as such repetition is inherently
present within them.
In 1986, Prusinkiewicz (Prusinkiewicz 1986) first introduced the idea of using L-systems
as the basis for music, first representing the system graphically, and then interpreting
this representation musically by mapping y coordinates of the graphical representation
to musical pitches and making the note durations of these pitches proportional to the
length of the horizontal line. The piece is then generated continuously along the line of
the graphical representation from one end to the other, recording the length of
horizontal lines and the pitch corresponding to the position on the y axis. Mason and
Saffle (Mason 1995) develop this idea further and suggest that any space filling , self
Page | 20
avoiding, simple and self similar curves containing 90 ̊ angles can be used to generate
melodies of any length.
3.5 Artificial Intelligence, Genetic Algorithms and Neural
Networks Artificial intelligence (AI) is “the study of how to produce machines that have some of
the qualities that the human mind has, such as the ability to understand language,
recognize pictures, solve problems and learn” (Cambridge 2005). The potential for the
use of such techniques within music generation is obvious. The primary focus of many
people working within the field of algorithmic composition is to create a program that
realistically imitates the style of music composed by a human, and so a system that
could potentially be capable of replicating human thought processes during composition
and evolving as it learns (from human input or responses to previous outputs) is
naturally of great interest to many computer composers. Benefits of AI methods for
algorithmic composition could include more complex, but still ‘musically good’,
hierarchies and rule structures, intelligent musical data bases, the potential to
implement more aspects of human musical cognition and many more additions to the
set of available algorithmic composition tools (Roads 1980).
Genetic algorithms are able to “solve complex problems more quickly and efficiently
than other search and optimisation techniques” (Burton 1999). They start with an initial
population of a number of binary strings (the number and length depends upon the
specific situation) which are then evaluated for ‘fitness’, and those that are considered
the fittest will be selected for the ‘mating pool’. Reproduction (selection of individual
strings from the mating pool), crossover (selecting pairs of these at random and
swapping bits between the two) and mutation (a single bit of the string is changed with
low probability) operations follow until a termination condition is satisfied. Applications
of this to music composition could be based on mapping these strings (or the bits of the
strings) to musical notes or durations in a variety of different ways.
Neural networks can provide an alternative to normal artificial intelligence (Dolson
1989). They are also known as connectionist models or parallel distributed processors
and consist of “a large number of identical, interconnected processing elements” (Roads
1996). Possible applications of neural networks in algorithmic composition include
analysis of rhythm and pitch sequences and simulating analysis of polyphony and
tonality.
Page | 21
3.6 Other Methods Other widely used methods include:
Algebraic Systems - Algebraic systems are the other main concept considered by
Xenakis in his book Formalised Music (Xenakis 1971). He formulates a symbolic
way of thinking about music, based on existing algebraic concepts, to allow
music to be considered as an algebraic system.
Cellular Automata – these are discrete dynamical systems often used by
scientists as modelling and simulation tools (McAlpine 1999). An array of
elements or ‘cells’ take one of a number of defined states, and this state evolves
with time, dependant on the states of other surrounding cells. These can be
used in musical composition by either mapping co-ordinates of cells of a certain
state or mapping the states of a set of cells to a musical representation.
Grammars – The hierarchical structure that is frequently exhibited by music can
often be encapsulated in formal grammars. Applications of grammars in
algorithmic composition include generative grammars for creating new
permutations of musical structures within the set of production rules defined by
the grammar (often using a stochastic approach to decide which of the rules to
follow where there are multiple options) and in a more analytic role to evaluate
music it is given to ensure that it is recognised by the grammar. The latter could
be useful where an alternative composition algorithm produces a variety of
outputs of which only some are acceptable, and hence the grammar could be
used to determine whether a given output fits a specified criteria, or in systems
where the composition is required to respond, perhaps interactively, to the
input or performance of a human musician (Roads 1996).
Page | 22
3.7 Summary and Evaluation of Methods Any one of the tried-and-tested methods described above could be used to successfully
generate music algorithmically. However, for this project we need to consider the most
appropriate method(s) for composing music in the desired style.
Classical flute music generally has a clearly defined structure, with pieces being divided
into different sections, which in turn are divided into phrases and then sub-phrases,
each of which may be repeated or varied throughout the piece.
In this respect, the style of music exhibits the self-similar behavior associated with
chaotic systems, such as fractals. However, the lack of structure at a low level means
mapping a chaotic equation directly onto the music scale would not accommodate many
of the aspects of playability and key characteristics of the classical style, where certain
combinations of notes have a much greater probability of occurring. Hence, this project
will focus on stochastic approaches, with a table representing the probability
distributions of each note in the range of the instrument following any given note. This
method will allow far greater flexibility to manipulate the likelihood of certain musical
events occurring in order to improve the style and playability of the output.
Page | 23
Chapter 4: Requirements Analysis and Specification
4.1 Introduction The requirements for this project fall into two broad categories; those defining how the
system should work and those relating to the music produced by the system. The first
category includes the required functionality, inputs and outputs, and general system
performance. The second is split into stylistic requirements and playability
requirements. It is the latter group that are of primary interest in this project, however
the former are required to ensure that the system is actually usable for its intended
purpose.
Owing to the experimental nature of the project, requirements are not as precisely
defined as for many other software development projects, and to a large extent,
determining the constraints of the application is part of the design process. Also, note
that this section formalises the requirements of the project for evaluation purposes,
using generalisations based on the research documented in the Literature review
section, and so detailed explanations included elsewhere are not repeated here.
This section will also use the following terminology:
The term must means that this requirement is one of the core requirements of
the project and should be regarded as compulsory.
The term should suggests that the requirement is highly desirable, but the
project can still be regarded as a success if a small number of these
requirements are not met.
The term may denotes requirements that would add useful functionality to the
system but will not be used as the main criteria in determining the success of
the system.
Page | 24
4.2 Project Requirements (High Level) This section gives a high level overview of the requirements of the system and may be
considered to be the core success criteria of the overall system:
1. The system must create pieces of music for flute, without need for human input during the compositional process.
2. The system must provide some form of accompaniment for the flute pieces it creates.
3. The system must ensure that the flute parts produced are within the constraints of the instrument. For example, no notes outside the playable range and only concert pitch notes included.
4. The system should ensure that the flute parts produced are ‘playable’, that is, can be played on a flute by a suitably competent human flautist. For example, the flautist may be unable to hold notes for longer than a certain length or change fingerings faster than a certain rate.
5. The system should take into account the required user-entered parameters. 6. The system may allow the user to specify the style and instruments of the
accompaniment. 7. The system must output the music produced in either audio or manuscript form. 8. The system should output the music produced in both audio and manuscript form. 9. The system must allow the user to save the output in an appropriate format. 10. The system may provide the option of a computer-played accompaniment for each
flute part composed.
4.3 Input and Interface Requirements 1. The system must provide a simple visual interface allowing the user to enter any
required parameters and access the outputs of the program. 2. The system may provide a graphical user interface allowing the output to be viewed
and played back within the main program.
4.4 Generic Output Requirements 1. The system must produce an output that allows the user to directly generate the
music in either an audio format or in manuscript format without requiring additional
transcription or coding by the user, but possibly making use of external music tools
or software.
2. The system should produce an output that allows the user to directly generate the
music in both an audio format and in manuscript format.
3. The system should allow the user to save the musical output so that it can be
recalled and used at a later time.
4. The system may automatically generate the manuscript and audio output directly
from within the program.
Page | 25
4.5 Structure and Style Requirements The aim of the project is produce music in a classical style, and so it is required that the
output of the application adheres to certain stylistic and structural rules. The key
features of the style of music have been identified based on the widely accepted theory,
evaluation of existing music of the period and personal knowledge and intuition
summarised in chapter 2, and are detailed below.
1. The output must show clear signs of scale and arpeggio based note patterns, as this
is one of the primary features of the style.
2. There should be evidence of repetition in the musical output.
3. The melody must not contain a large amount of accidental notes, and should consist
almost entirely of notes from within the major/minor scale of the key.
4. The predominant chords of the piece should be the tonic, dominant, sub-dominant
and relative minor of the key.
5. The piece should contain some of the most common cadences, namely the ‘perfect’
and ‘imperfect’ cadences.
6. The piece should be divided up into distinguishable phrases.
7. The piece may also be split into larger sections.
4.6 Playability Requirements As the system aims to produce music to be played on a physical instrument, is it crucial
to ensure that the output is playable on this instrument. The following requirements aim
to confirm that the output meets the limitations imposed by the instrument and have
been derived from the knowledge of the constraints of the instrument and experience
of flute playing set out in chapter 2.
1. The flute melody must not contain any notes below middle-C, or any notes
above C’’’.
2. ‘Off-pitch’ notes outside of the 12 notes of the chromatic scale must not be
included.
3. Techniques, such as glissando, that are not playable on the flute must not
appear in the musical output of the program. (Note that a specific list of
techniques is not included here as numerous musical effects could be
interpreted as potential, but unachievable, techniques for the flute. However
the requirement is sufficient for evaluation purposes as the presence, or
absence, of such effects will be evident without the need for listing them here.)
4. Notes must be strictly sequential and not overlap in time.
5. Notes should not be sustained for any longer than 8 crotchet beats.
6. Jumps of more than one octave in pitch must not occur.
7. No notes shorter than a semi-quaver may be included.
8. The application should allow the composer to restrict the key of the piece to a
key of their choice.
Page | 26
4.7 Non-functional Requirements This section details the requirements that do not directly relate to what the application
does, but help to ensure that it is usable in the desired way.
1. The application should not require the user to have expert musical knowledge to
use it.
2. The application must operate within the Windows operating system, and should
also operate within Linux environments.
3. The application must not require access to any further musical software tools,
other than such as are freely available at no extra cost.
4. The application must not require any specialist hardware items, although it may
be assumed that the user has a standard sound card and audio output (e.g.
speakers or headphones) installed.
5. The application should not require more than 10MB to store and run.
4.8 Scope of the Project Due to time constraints, the following features are considered to be beyond the scope
of the project.
The system will not provide the user with the ability to directly modify or interact fully
with the output. Although this would be a useful feature, it would also be time
consuming to implement and is not within the main aims of this project, therefore it has
been decided to concentrate on the development of the composition algorithm. More
advanced users will have the option of modifying the Lilypond input file before
converting it to the required output formats.
Non-classical styles of flute music or music designed for other instruments are also
considered to be beyond the scope of this project. It is acknowledged that the music
generated may also be suitable for other instruments, and the range of the piece may be
altered or restricted to a certain extent by modifying the pitch probability tables;
however no further concessions will be made.
Dynamics and playing style are a key component in any musical performance. Many
months could be devoted to them as they would make an interesting study in their own
right, however in this instance they will be left to the interpretation of the performer.
The accompaniment provided by the system is intended to be a backing for the flute
melody rather than an integral part of the composition, and so will be relatively simple.
Again, much time could be spent studying the accompaniment of classical flute music
and attempting to accurately imitate its style, but within the timescale of this project
would only serve to detract from the development of the main melody generation
algorithm.
Page | 27
Music in more than one key, or alternative keys, shall not be directly implemented,
although the system will be implemented in such a way as to allow the composer to add
additional keys if required. The simplest way of providing alternative keys is to transpose
the output of the system directly into another key; however this could potentially lead
to outputs that contain notes outside of the playable range of the instrument. Although
there are ways around this problem, including ‘wrapping’ the notes back round to the
other end of the range (which could lead to large jumps in pitch) or reducing the number
of pitches permitted within the composition so that it can be transposed into any key
without encountering range problems, none really provide satisfactory solutions
musically. However the system could be easily adapted to compose in different key by
developing a different pitch probability matrix for each key required, but these will not
be provided as this could be extremely time consuming and does not really add to the
project.
Page | 28
Chapter 5: Design
5.1 Introduction This section contains a commentary on the design process and the decisions taken. The
three main phases of the design section are:
1. Design of the overall system
2. Formulation of an initial algorithm and evaluation of the limitations of this
prototype.
3. Further algorithm development of ideas to create a more sophisticated
algorithm.
These phases will be described in greater detail below.
5.2 Identification of Program Components The main components of the system are as follows:
1. User interface – allowing the user to specify the parameters of the piece being
composed.
2. Composition algorithm – the process that will generate the musical structures
and sequences of notes that will make up the new composition.
3. Output generator – to translate the musical output of the composition algorithm
into the required output formats.
5.3 Inputs and Outputs The system will accept the following input parameters from the user, via the user
interface:
The filenames the probability tables should be loaded from (thus allowing the
user to select different key signatures or vary the style of the music produced).
Whether to use a stochastic-based or L-system based method of generating the
chord structure.
The name of the file the output will be written to.
Page | 29
5.4 Development Environments and Additional Tools This project will make use of a number of existing programming languages and software
tools.
5.4.1 Development Languages
The C Programming Language
First developed in the early 1970’s by Dennis Richie (Richie 1993), C is a powerful
programming language with the advantages that it is reasonably platform independent
and is also compatible with many additional music and compilation tools. The way the
language handles arrays and pointers allows for flexibility in the way musical data is
stored and processed within a C program.
The C++ Programming Language
Originally known as ‘C with classes’, the C++ programming language was first introduced
in 1983 by Bjarne Stroustrup as an extension of the C programming language (Walsmley
1997), maintaining much of the same syntax and semantics but also incorporating the
object-oriented programming paradigm. C++ also provides better support for graphical
user interfaces, whilst still allowing the flexibility in linking data structures that pointers
provide.
Note: Although C was initially chosen as the development language and the initial basic
composition algorithm was coded in C, it was later decided that C++ would be a more
convenient language for the development of the final algorithm and user interface.
5.4.2 Musical Software Tools
Producing Manuscript Output
There are many tools available for creating manuscripts of a piece of music. Some of
these, for example Sibelius and Cubasis, are predominantly designed for the end user to
directly input the notes into the score, either using a graphical interface or played in
direct using a MIDI keyboard, and consequently are not well suited to automatic input
from a computer program. Other tools exist, generating manuscript music notation
based on ASCII text input making them music more suitable for producing manuscript
directly from the output of a computer program. Examples include Lilypond, developed
by Han-Wen Nienhuys and Jan Nieuwenhuizen, and abc, developed by Chris Walshaw in
the early 1990’s.
Page | 30
This project will use Lilypond to generate the manuscript form of the composition
output. Lilypond has been chosen as it combines simple syntax with the ability to quickly
and easily produce musical scores in the widely used PDF and PostScript formats, with
the additional capability of generating a MIDI file of the music requiring only one
additional line of code. Unlike more complex music tools requiring nested declarations
over multiple notes, the code structure of Lilypond is suited to being generated linearly
by another computer program.
Lilypond is also freely available across multiple platforms, helping to ensure that the
portability of the composition system is not compromised.
Producing Audio Output
The audio output of the system is in MIDI format, and this will be generated by Lilypond
directly from the Lilypond source code at the same time the visual scores are created.
The MIDI format was chosen over other computer music tools such as CSound both for
convenience, as the MIDI file can be generated automatically from the Lilypond source
file already created for the manuscript notation with only one extra line of code, and for
portability, as the MIDI format is platform independent and is supported across almost
all operating systems.
Page | 31
5.5 The Initial Algorithm Design The initial algorithm is relatively simple so more complex aspects can be introduced
separately to determine whether or not they have a positive effect on the output and
evaluate where the algorithm needs to be improved. Consequently it does not consider
all of the style and playability requirements. The composition process is based on a
series on randomly generated numbers, which are mapped onto the probability
distribution corresponding to the pitch of the previously generated note, to determine
the pitch of the next new note using a Markov chain approach. Note lengths are
selected randomly from a finite set of possible lengths. This process is repeated until the
total length of the piece reaches a pre-defined length.
Figure 5.1 Initial composition algorithm design
Page | 32
5.6 Limitation of the initial algorithm The initial algorithm produces music which is both playable and incorporates several
features of classical flute music, such as keeping within the tonic scale of the key.
However, this algorithm also has a number of limitations:
• Sequences of pitches are still very disjointed and there are almost no scale-
based runs or arpeggios (see fig 7.2 below). There are also several large jumps in
pitch between consecutive notes (for example, see the third bar of figure 7.2
below). Further amendments to the probability table are needed resolve these
issues, and possibly an additional consideration of intervals between multiple
previous notes.
• The algorithm introduces syncopated rhythms (see the first bar in fig 7.2 below)
which are not in keeping with the genre.
• There is little overall structure or repetition in the output. Consideration should
be given to this as both play a major role in music of the classical style.
Figure 5.2 An example of the output of the initial algorithm
5.7 Development of Structure In order to improve overall structure of the output, the concept of L-systems is
introduced to the system. By using an iterated L-system (such as those described by
Mason and Saffle, 1995), as the basis of a composition, we can achieve the effect of
repetition of smaller, simpler structures both at a high and low level. Whereas Mason
and Saffle, and before them Prusinkiewicz (Prusinkiewicz 1986), used L-systems as a
basis for melody generation, this project experiments as the basis for generating chord
sequences. Although L-systems have the potential to provide interesting melodies, it
was felt that they would not give the flexibility needed to closely imitate features such
as the arpeggios and scale-based runs of the classical style required, would restrict the
variety in the output too much, and to a large extent be repeating work previously done.
Basing the chord structure on a representation of an iterated L-system, the overall
movement of the piece is self-similar to the movement of the piece at a lower level, due
to the fractal properties of the L-system, giving the piece more overall coherence.
The chord sequences are generated by starting at the bottom left hand corner of the
geometric representation of the L-system chosen and interpreting the horizontal ‘axis’
as time, measured in crotchet beats (note that moves along this axis are always taken to
be positive, whether they move to the right or left), and each interval of the vertical
‘axis’ represents a chord pitch. The sequence is then generated by moving along the L-
Page | 33
system curve in one direction and recording the length and position on the vertical axis
of all the horizontal lines (in a similar way to that used by Mason and Saffle, 1995). A
trivial example to illustrate the method used is described below.
Figure 5.3 A graphical representation of a simple L-system
Example: Starting at the bottom left corner of figure 7.3, this would be interpreted as
follows:
(i) Two beats of the chord assigned to level 0, followed by
(ii) One beat of the chord assigned to level 1,
(iii) Two beats of the chord assigned to level 4,
(iv) One beat of the chord assigned to level 3, and finally
(v) Two beats of the chord assigned to level 2.
Assignment of chords to levels on the axis of the representation of the L-system can be
sequential or random, or another configuration of the users choice. Sequential
allocation most preserves the patterns in the graphical representation of the system,
never the less the inherent repetition due to the repeated patterns in the structure will
still remain as no matter how the chords are allocated; the chord pitch remains the
same across the whole of each level.
Figure 7.4 shows a slightly less trivial example of an L-system representation, including a
second iteration of the pattern, to illustrate how the concept of similarity and repetition
at a variety of levels throughout the piece can be introduced.
Page | 34
Figure 5.4 A graphical representation of the second iteration of an L-system
Each piece will also be divided into phrases for further definition of the structure of the
piece; these will also be derived from the L-system representation, with each phrase
being 1/nth of the L-system curve, where n is the horizontal length of the original
pattern.
5.8 Improving Rhythmic Structure and Reducing Syncopation The rhythm generation in the initial algorithm was very basic; note lengths were
generated at random in a linear manner, independently of the position of the note in
the piece and of the notes around it. Unfortunately this method, although simple to
implement, is unable to accurately reflect the desired style of music.
For the final algorithm, a different method has been adopted, using the chord lengths
generated from the L-system representation as a starting point. Each of these notes may
then be split further, with a probability dependant on the note length. These
probabilities will be read in from file at the start of the program. The process continues
recursively on each note generated until either the stochastic function used to split the
notes decides not to split the note or the minimum note length has been reached. This
method extends the concept of using one-dimensional space grammars to define
musical rhythms (explained in Jones, 1981) in that it uses a stochastic method to decide
whether to split the note using certain rules (represented by the production rule A →
AA) or whether the note is at its final length and the splitting process should cease
(represented by the production rule A → a, leading to the occurrence of the terminal
symbol a). However unlike Jones, Flute Composer does not assume the ‘space’ to be
split at the centre every time; although the required style of music suggests that this
should usually be the case, the program may also split note lengths into the ratio ¾ : ¼.
This method aims to reduce, and in most cases entirely remove, syncopation (off beat
rhythms) from the melody generated by ensuring that all notes are ‘paired’ with another
Page | 35
(i.e. the two parts of a longer note that they were split from), and so the rhythm has far
greater structure. Then, notes starting on the offbeat are unable to continue across the
next beat and hence the syncopation is removed. Exceptions to this may occur as
chords of an odd length (in terms of number of beats) are possible, although unlikely,
within the chord generation structure but even if such chords should occur, there is a
high probability that the length would be split into notes of a non-syncopated rhythm
purely due to the probabilities used in the note splitting function anyway.
5.9 Increasing the Occurrence of Arpeggios and Scale Based
Runs in the Musical Output Arpeggios and scale-based runs are a key feature in classical music and so the final
algorithm needs to correct their relative absence in the output of the initial algorithm.
The most obvious solution to this problem is to further bias the values in the probability
table towards these intervals. However, although this will increase the probability of
these intervals occurring within the musical output, this method alone will not be
sufficient to consistently produce the desired runs and arpeggios, as it takes no account
of ongoing patterns leading up to the previous note or of the current chord of the piece.
Because of this it is likely that arpeggios that do occur will be outside of the current
chord of the piece and so clash with the accompaniment. A possible solution to this
problem would be to introduce a multi-dimensional stochastic grammar and
corresponding probability table (or an nth order Markov chain), taking into account not
only the one previous note, but several of the preceding notes in addition to the current
chord. However, not only would this be computationally expensive, it would also be
highly complex and time consuming to formulate a table that accurately reflects the
style of the music, due to the vast number of possible combinations of note patterns.
This assertion is supported in Compositional Applications of Stochastic Processes (Jones
1981), which states that for nth-order Markov chains, if n is increased too far, the
structures “become unwieldy and almost impossible to use”.
Instead, a different method using low level pattern matching is introduced. As stated by
Leach and Fitch (Leach 1995), the behaviour of rhythm and melody “changes when a
major note is reached... In a sequence of notes the pitch increases or decreases by some
constant pitch interval as we move from one note to the next. Then, when we reach the
major note in the sequence we change the constant pitch interval to another value.”
Although the note sequences generated by Flute Composer are not based around the
concept of a key note, it is likely that such notes will inherently be present, even if they
are not identified as such. From the above, we can also infer that key notes can usually
be recognized by a change in rhythm, and that a change in pitch intervals is likely to
occur at the same place. This assumption forms the basis of the low level pattern
matching function used by Flute Composer to increase the occurrence of scales and
arpeggios in the musical output.
Page | 36
The function will act as an override for the Markov chain process, and is described using
the pseudo code below:
1. Start at current note (note n)
2. If length(n)≠ length(n-1), exit from low level pattern
matching and randomly generate note using the original
Markov process. Else...
3. Initialise i=2
4. While length(n)= length(n-i) {
If interval_between(n-1, n-2) = interval_between(n-i+1,
n-i){
i -> i+1
}
Else, exit while loop and go to 5.
}
5. Generate random number.
6. With a probability based on the number of previous note
length and pitch interval matches, repeat this interval to
find the pitch of the current note. If this probability is
greater than the random number generated, match this
interval and assign the new pitch to the note. Else, exit
from the low level pattern matching process and randomly
generate the note pitch using the original Markov process.
The basic principle of this method is that if a scale-based run or arpeggio has started, it is
likely to continue until the rhythm changes, when the pitch interval is also likely to
change. From many examples of classical music, we see that often the direction of pitch
change will also invert at this point, and so, for example, when the rhythm changes, a
pitch sequence may go from an upward scale to a downward arpeggio, and so with a
reasonably high probability the program will force the pitch change to invert.
5.10 Tying the Melody Back to the Chord Although up to this point the melody generated by the program incorporates many of
the key features of the style, as yet the melody bears no relation to the chords, and so
will sound disjointed when played with the accompaniment. It is evident that further
functionality is needed in order to bring the melody back into line with the underlying
chord structure. However, there is also the danger that if adherence to the chord is
enforced too rigidly, the arpeggios and scale patterns introduced above, which are a key
feature of the style, will be interrupted and the flow of the melody damaged.
For scale-based runs, tying the notes of the melody to the chord is not a big issue, as for
the predominant chords of any major scale, almost every other note of the scale occurs
within any given chord (with the exception of the 6th and 7th notes of the scale of that
Page | 37
chord, when there are two consecutive notes that do not occur in the scale, however as
this is likely to have a relatively low occurrence rate, it is deemed better to overlook this
issue rather than spoil potential scale patterns). It has been decided that because of
this, nothing will be done to alter notes in a scale based run depending on the chord.
The exception to this will be if the note is held over the whole length of the chord, as
then there is no opportunity for the melody to come back onto the chord and the note
would be likely to sound discordant. In this case, the note will be moved to the nearest
pitch that is part of the chord. This rule will be applied across the piece regardless of
whether it occurs in a scale-based run.
The case of arpeggios is more complex, for it is quite feasible that such a pattern could
continue for many notes without hitting any of the pitches that make up the chord at all.
To resolve this issue, instead of comparing the interval as an absolute number of
pitches, the program will record the type of interval between two notes, and the interval
type shall be used for interval comparison and generating new notes based on previous
pitches in the pattern matching functions.
The interval types are defined as follows:
1. Scale based pitch increase, denoting a move of one pitch up the scale of the
key the piece is based in from the previous note.
2. Scale based pitch decrease, denoting a move of one pitch down the scale of
the key the piece is based in from the previous note.
3. Arpeggio based pitch increase, where the pitch is taken to be two pitches
higher than the previous note, and then, if necessary, adjusted by raising it
one pitch at a time until the pitch occurs in the underlying chord of the
current note.
4. Arpeggio based pitch decrease, where the pitch is taken to be two pitches
lower than the previous note, and then, if necessary, adjusted by lowering it
one pitch at a time until the pitch occurs in the underlying chord of the
current note.
5. An interval that is none of the above, in which case the absolute pitch change
is stored.
This method should ensure that, while the overall audible effect is that the arpeggio
continues unbroken, even if the underlying chord changes during the pattern the
melody fits with its accompaniment.
5.11 Increasing Repetition Repetition of note sequences is another key feature of classical music. As stated by
Leach and Fitch (Leach 1995), “it is well known that it is not the actual notes in a piece of
music that distinguish it, but instead the intervals... If we repeat a sequence of notes,
then we repeat the relationships between their pitches, even if the sequence itself is
transposed to a higher pitch”, and we can see, both from this and intuitively that such
Page | 38
repetition, both at the same and different pitches, occurs frequently within the classical
style of music. The repetition may only consist of a sequence of a few notes repeated
within a phrase, or a larger sub-phrase repeated throughout the piece.
In order to encapsulate this within the Flute Composer application, a higher level
pattern matching mechanism is introduced. This function acts as an override for both
the low level pattern matching and the Markov based pitch generation. Starting from
the current note, it searches the melody generated so far, first for occurrences of
patterns of note lengths that match the sequence of note lengths of the current note
and the two that precede it. When a matching rhythm is found, the function then
compares the intervals of the notes. If no matches for both the rhythm and the pitch
intervals are found, the application will then continue onto the lower level pattern
matching. If matches are found, then the function continues increasing the length of the
sequence it searches for until a length is found where there are no matches. This
process is carried out separately within the current phrase and previous phrases, as it is
recognised that where there are multiple matching phrases of the longest length found
it is more likely that the piece will repeat a pattern that has only just occurred.
Where multiple matches are found in the previous phrases, or in the current phrase,
only the first occurrence in each case will be considered; this is based on the premise
that the patterns occurring earlier in the piece or phrase are more likely to be
remembered by a listener and also that the earlier they occur in the piece the more
likely they are to be repeated several times before the piece comes to the end, and so
can be considered to be the ‘dominant’ form of that repetition. The differences between
these candidate sequences to be used for repetition should be minimal, as in order for
them to both match the current sequence so far, their pitch intervals should be equal
apart from (in some cases) the last interval, i.e. the one that would be used to generate
the pitch of the current note, and their rhythms should be identical.
When the longest matches in both the current phrase and in the rest of the piece
preceding it have been found, the function looks up the probabilities of copying the
interval from each to generate the pitch of the new note. These probabilities will be
dependent on both the number of notes matched, and whether the match is within the
current phrase. Of the two matches, it will pick the one that has the highest probability
p of being used (or if matches only occurs outside of the current phrase then the longest
of these matches will be used), and then with probability p will repeat the final interval
of that match to generate the new note, otherwise it will carry on to the low level
pattern matching method described above.
Page | 39
The probabilities of using these notes are shown in the table below:
Table 5.1 - Showing the probabilities of matches of given lengths being used to generate the
current note
Number of Notes Matching Probability of the match being
used for a match of this length
within the same phrase, p
Probability of the match being
used for a match of this length
outside of the current phrase, p
3 0.6 0
4 0.7 0.3
5 0.75 0.4
6 0.80 0.7
7 0.85 0.8
8 0.95 0.85
9 0.95 0.9
10+ 0.95 0.95
Note: beyond 10 matching notes the probability of this match being used to generate
the new note will not change, but the notes will still be checked for matches to ensure
that the longest possible match is found.
Page | 40
5.12 High Level Diagram of Complete Application
Figure 5.5 – A high level flow diagram showing how the components of the composition
algorithm fit together.
Page | 41
5.13 Accompaniment The accompaniment provided by the Flute Composer application is intended only as a
basis for the melody, which is the main focus of the project. It is acknowledged that the
accompaniment itself could potentially become an integral part of the system and that
months could be spent on developing the accompaniment alone; however this is beyond
the scope and timescale of the project.
The accompaniment provided will take the form of a two line piano part, with an
isorhythmic structure, heavily based on the underlying chords, and will be generated as
follows:
The rhythm will consist of a constant crotchet beat for both the left and right
hands.
The notes of the bass line will be taken to be the base note of the current chord.
The notes of the treble line will be randomly selected from the set of notes that
make up the current chord.
Page | 42
Chapter 6: Notes on Implementation
6.1 Introduction This section provides a commentary on decisions made and problems encountered
during the implementation phase of the application. The development of the initial
algorithm will not be covered in this section as it was developed only as a prototype and
as it was so simple, no problems were encountered.
This section will not go into precise details of all the concepts implemented, as many of
them have already been described in the design section, but will explain additions to the
design that became necessary during the development of the system.
6.2 Representation of Musical Structures The first issue encountered during the implementation of the system was how to
represent the musical structures within the program in a way that would allow the
composition process to interact correctly with the previously generated components of
the music at each stage of the process.
The chosen solution for this was to represent the note structure as a tree (similar to the
event trees described in Leach 1995), with new classes being defined to represent the
nodes of the tree at each level. This method is well suited to the design of the
composition process as it reflects the recursive native of the chord dividing and note
splitting processes, as well as the overall hierarchy of the piece.
A class was created to represent the concept of a note in a way that allowed each note
to store its length, pitch and underlying chord (the last two variables were added further
into the implementation and are described at a later stage).
Class NOTESTORE {
public:
int Chord;
double Length;
int Pitch;
patternType PatternType;
int PitchChange;
}
Page | 43
6.3 Generation of Chords from the L-system The concept of generating music from an L-system is based on interpreting a geometric
representation. However this would be extremely complex to implement. Instead,
alternative representations of the generated L-system had to be considered. The
method chosen was to transcribe the graphical form of the L-system into a text file,
representing each side of the curve by a pair (direction of movement, length of side), as
this was by far the simplest.
Generally the development of the chord generation went smoothly and the concept was
implemented as described in section 5.7 above.
It was decided to use a second iteration of the L-system pattern as this would promote
greater repetition of chord patterns and inversions of chord patterns while still providing
variety, where as playing the output of several single-iteration systems would either
continually repeat the same pattern without allowing the piece to progress (in the case
that the same L-system was repeated) or there would be little or no repetition in the
chord sequences at all (in the case where different random patterns were used).
However, additional iterations were decided against as it was felt that this would
necessarily either greatly increase the length of the piece or produce a piece that is
overly fast or contains overly frequent chord changes, depending on how the extra
iteration is interpreted.
6.4 Note Splitting and Rhythm generation Mostly the process of splitting notes was straight forward and was implemented as
described in section 5.8. A grammar to represent possible productions was drafted and
this was then formalised as a two dimensional probability table with each of the allowed
source note lengths to be split being represented by a row and the columns
representing the length of possible first notes in the split. Each row was then equivalent
to the probability distribution for splitting a note of the length represented by that row.
Within the initial grammar, a note could be split into one of two ratios; ½: ½ or ¾: ¼. This
information was stored within a set of nodes (implemented as classes) linked in a tree
structure, with each node storing its current length, pointers to its child nodes (the two
notes that it will be split into, should they exist and the splitting function not terminate
at that node) and pointers to the note that follows it sequentially.
The problem then occurs when the L-system throws out an irregular chord length and
we end up splitting, for example, a note of length seven beats. Whether we split this in
the ratio ½: ½ or the ratio ¾: ¼ we will end up with a note that does not occur within the
set of acceptable lengths and even if we continue to split these lengths further, we will
not arrive back at a note length that is allowed to occur in the output. Once this problem
had been identified, it was easily resolved by modifying the probability table to ensure
that if a note of length 3, 5 or 7 crotchet beats occurred, it was split into two
appropriately sized components before being halved or split into the ratio ¾: ¼.
Page | 44
Once all branches of the tree have ceased splitting, the tree is then complete and is
ready to be read into the next phase of the algorithm.
6.5 Low level Pattern Matching The main issue within the pattern matching phases of the algorithm is maintaining the
flow of the pattern across underlying chord changes. With notes and intervals being
stored as absolute pitch values this can very difficult. To combat this problem, an extra
property of each note is stored along with the other data belonging to the note. This
value shows whether the transition between the two notes represents a jump in an
arpeggio, a single pitch interval or a random interval (these intervals are further
described in section 5.10).
The low level pattern matching, for detecting and repeating an ongoing scale or
arpeggio based pattern, will make use of this value to detect whether intervals occurring
between two notes within its run are essentially equivalent to each other, even if, for
example, one interval is three pitches and the other two due to an arpeggio either going
up into the next octave or crossing a chord boundary.
The high level pattern matching will also make use of this, to record intervals so that
comparisons can be made between patterns that repeat in form but start at a different
position on the scale.
6.6 High Level Pattern Matching The description of the high level pattern matching in the design section is not defined
very specifically. The pseudo-code below attempts to explain the process adopted more
clearly.
1. Find the longest string within the current phrase that
matches the string leading up to the current note.
2. Find the longest string prior to the current phrase that
matches the string leading up to the current note.
3. If no matches are found, exit from the high level pattern
matching function and proceed to the low level pattern
matching function.
4. If only one match is found within the whole of the piece so
far, match the next interval in the string to generate pitch
of the current note with probability p dependant on the
length of the match, otherwise exit from the high level
pattern matching function and proceed to the low level
pattern matching function.
Page | 45
5. If matches are found in both the phrase and previously in
the piece, let po be the probability of following the
longest pattern outside of the current phrase and pi be the
probability of following the longest pattern within the
current phrase (note that the values of po and pi will
depend on the respective lengths of the matching patterns):
If (po > pi AND random_number < po){
Follow the longest pattern outside the current phrase
to generate the new note based on the interval between
notes in the pattern corresponding to the current note
and the previous note.
}
Else if (pi > random_number){
Follow the pattern of the longest match inside the
current phrase
}
Else{
Drop down to the low-level rhythm based pattern matching
}
}
A further note is needed to explain the procedure used to identify matches in 1. and 2.
above. A further section of pseudocode below expands on this. Note that the process is
the same whether it is applied to the current phrase or the previous parts of the piece.
1. Initialise i = 1, match_found = true
2. While (match_found = true){
2.1.1 If (no match for the sequence consisting of i notes made
up of the current note and the (i-1) notes before it can
be found){
2.1.2 set match_found = false
2.1.3 }
2.1.4 Else {
2.1.5 Set i = i + 1
2.1.6 }
}
3. Return the length of the longest match i and the point in
the piece where this match occurs.
Page | 46
6.7 Summary of Implementation Unless otherwise stated above in this chapter, it may be assumed that the system was
implemented in the manner described in the design section (chapter 5). In general not
many problems were encountered during the main implementation phase. This may be
due to the development approach taken in implementing an initial prototype algorithm.
Learning from the limitations of this algorithm and being able to anticipate potential
areas of difficulty meant that only very few modifications to the new designs were
required when it came to coding the final algorithm.
Page | 47
Chapter 7: Results and Evaluation of Musical Outputs
7.1 Validation of Requirements This section evaluates the completed program against success criteria laid out at the
start of the project, and also further justifies some of the design decisions made by
explaining them in the context of the requirements that influenced them.
7.1.1 High Level Requirements
1. “The system must create pieces of music for flute, without need for human input during the compositional process.” Flute Composer generates pieces of music designed to be played on the flute, and apart from requesting the files for certain initial parameters requires no further user input in the compositional process.
2. “The system must provide some form of accompaniment for the flute pieces it creates.” Flute Composer provides a basic piano based accompaniment for the flute melody it generates.
3. “The system must ensure that the flute parts produced are within the constraints of the instrument. For example, no notes outside the playable range and only concert pitch notes included.” By defining all possible notes that can occur in the output within the probability table and further enforcing the bounds of the range in the composition algorithm, it is not possible for the melody to depart from the playable range of the instrument at any point in the process.
4. “The system should ensure that the flute parts produced are ‘playable’, that is, can be played on a flute by a suitably competent human flautist. For example, the flautist may be unable to hold notes for longer than a certain length or change fingerings faster than a certain rate.” The issue of playability is further evaluated below, where the more detailed Playability Requirements are validated.
5. “The system should take into account the required user-entered parameters.” Flute Composer allows the user to select parameters by specifying the files from which the input is read. Although default files are provided with the system, the user is able to modify these files or even create new ones to change the probability distributions used, the key of the piece and the L-system used to generate the chord structure. The user will also be able to specify the desired name and location of the output file.
Page | 48
6. “The system may allow the user to specify the style and instruments of the accompaniment.” Unfortunately this has proven to be beyond the scope and timescale of the project, although would provide an interesting extension to the system should time be spent on it in the future.
7. “The system must output the music produced in either audio or manuscript form.” Although it does not directly satisfy this requirement, Flute Composer produces output in a form that is easily converted to both audio MIDI format and PDF manuscript form without requiring the user to modify the output in anyway, only to run it in a specific musical tool (Lilypond), and so this requirement will still be considered to have been satisfied.
8. “The system should output the music produced in both audio and manuscript form.” See above (High Level Requirement 7).
9. “The system must allow the user to save the output in an appropriate format.” Flute Composer will generate and save a text based file suitable for input to Lilypond, using the filename specified by the user. On running this file, Lilypond will then automatically save the musical output into MIDI and PDF formats.
10. “The system may provide the option of a computer-played accompaniment for each flute part composed.” Flute Composer indirectly satisfies this requirement, as the output generated in MIDI audio format also includes the accompaniment. However, the system does not provide an audio file of the accompaniment without the melody. It would be possible for a more advanced user to modify the Lilypond input file very quickly; however this would require additional knowledge of Lilypond.
7.1.2 Input and Interface Requirements
1. “The system must provide a simple visual interface allowing the user to enter any required parameters and access the outputs of the program.” Flute Composer provides a basic text based interface, allowing the user to enter parameters and run the composition program.
2. “The system may provide a graphical user interface allowing the output to be viewed and played back within the main program.” Unfortunately the development of a graphical user interface proved to be beyond the timescale of the project, and as this was not a key feature it has been omitted.
Page | 49
7.1.3 Generic Output Requirements
1. “The system must produce an output that allows the user to directly generate
the music in either an audio format or in manuscript format without requiring
additional transcription or coding by the user, but possibly making use of
external music tools or software.”
Flute Composer allows the user to generate both MIDI audio and PDF
manuscript forms through the intermediate tool Lilypond.
2. “The system should produce an output that allows the user to directly generate
the music in both an audio format and in manuscript format.”
Although it does not directly satisfy this requirement, Flute Composer
produces output in a form that is easily converted to both audio MIDI format
and PDF manuscript form without requiring the user to modify the output in
anyway, only to run it in a specific musical tool (Lilypond).
3. “The system should allow the user to save the musical output so that it can be
recalled and used at a later time.”
Flute Composer will generate and save a text based file suitable for input to
Lilypond, using the filename specified by the user. On running this file,
Lilypond will then automatically save the musical output into MIDI and PDF
formats.
4. “The system may automatically generate the manuscript and audio output
directly from within the program.”
Unfortunately Flute Composer does not provide integration between the
composition algorithm and the music transcription tool Lilypond, as this would
have been too complex to complete within the timescale of the project, as
would developing an integrated tool to produce these output formats directly
within the project.
7.1.4 Structure and Style Requirements
1. “The output must show clear signs of scale and arpeggio based note patterns,
as this is one of the primary features of the style.”
Arpeggios and small scale-based runs frequently occur within the output of the
music. The likelihood of these occurring is increased by the large bias in the
probability distributions and the low level pattern matching process.
2. “There should be evidence of repetition in the musical output.”
Flute Composer introduces small amounts of repetition within the output,
although this is not always immediately obvious as the repetition occurs in the
rhythm and the note intervals, but not always the same pitches. It had been
hoped that the repetition would be more evident, as the high level pattern
matching functionality should have substantially increased the chances of
Page | 50
repetition occurring, and possibly if more time had been available, further
modifications to the probabilities could have improved this.
3. “The melody must not contain a large amount of accidental notes, and should
consist almost entirely of notes from within the major/minor scale of the key.”
In order to preserve the purity of the key, it was decided to omit all notes
outside of the major or minor scale of the key, and so this requirement is
automatically satisfied. More advanced users who wish to re-introduce
accidental pitches into the output of the algorithm are still able to do so by
modifying the scale information files and the pitch probability table.
4. “The predominant chords of the piece should be the tonic, dominant, sub-
dominant and relative minor of the key.”
Flute Composer defines the list of possible chords that can occur within a
piece; these are then assigned to ‘levels’ of the L-system. By ensuring that
these chords occur within the list (with only a small number of additional
chords) and are assigned to multiple levels of the L-system, Flute Composer
ensures that these chords make up the majority of the piece. This is also
evident when studying the chords of the output generated.
5. “The piece should contain some of the most common cadences, namely the
‘perfect’ and ‘imperfect’ cadences.”
Examination of the output shows that Flute Composer does indeed frequently
produce these cadences. Logically, they are likely to occur regularly as (with
the default chord parameters at least) only the most common chords are
defined and able to happen, and so there are a relatively small number of
possible cadences to chose from.
6. “The piece should be divided up into distinguishable phrases.”
Flute Composer automatically divides the output into a number of phrases (in
the case of the default L-system, there will be four phrases); however the
extent to which these are easily distinguishable depends on the particular
instance of the output, as some have more clearly identified phrasing than
others.
7. “The piece may also be split into larger sections.”
Unfortunately, Flute Composer has only reached the stage of developing short,
single section pieces. It is conceivable that the user could generate multiple
sections independently to be played consecutively, but at this stage this would
be a manual process.
Page | 51
7.1.5 Playability Requirements
1. “The flute melody must not contain any notes below middle-C, or any notes
above C’’’.
By defining the range of notes possible within the probability table, Flute
Composer ensures that no notes outside the range of the instrument can occur
in the melody. Although further functions may override the stochastic note
generation function, boundary checks are in place to ensure that the melody is
unable break these boundaries. Evaluation of a large range of sample outputs
show that no notes outside this range occur, and so it is safe to assume that the
measures to prevent the melody going out of range have been successful.
2. “‘Off-pitch’ notes outside of the 12 notes of the chromatic scale must not be
included. “
Because all the pitches in Flute Composer are defined relative to their position
in the scale, no other notes outside of the scale are able to occur.
3. “Techniques, such as glissando, that are not playable on the flute must not
appear in the musical output of the program. (Note that a specific list of
techniques is not included here as numerous musical effects could be interpreted
as potential, but unachievable, techniques for the flute. However the
requirement is sufficient for evaluation purposes as the presence, or absence, of
such effects will be evident without the need for listing them here.)”
Intuitively, it is evident from the program structure that Flute Composer will not
introduce such techniques into the melody as the system has no knowledge of
such devices and the program structure will prevent ‘accidental’ occurrences.
This assertion is supported by the absence of any undesirable techniques in the
wide range of sample output evaluated.
4. “Notes must be strictly sequential and not overlap in time.”
Flute Composer generates note lengths and then reads them back into the
system in a strictly sequential manner; therefore there is no possibility of notes
overlapping.
5. “Notes should not be sustained for any longer than 8 crotchet beats.”
With the default input parameters, it is not possible for any note length to
exceed 8 beats as the L-system structure, which is made up of 4x4 blocks will
not allow a continuous ‘straight line’ to pass through more than 2 blocks,
therefore the maximum chord duration, and hence the maximum length is 8
beats. It is possible for the user to override this constraint by modifying the L-
system dimensions, but in general this requirement is satisfied.
Page | 52
6. “Jumps of more than one octave in pitch must not occur.”
In the default probability table provided, the probability of any interval over one
octave occurring has been set to zero. Both the high-level and low-level pattern
matching functionality will not compromise this as they can only repeat intervals
originally generated by the probability table. The only place where jumps of
greater than one octave can occur is between the end of one phrase and the
start of the next, but this is acceptable. Again, the user is able to override this
constraint if they choose to, by modifying the distributions in the pitch
probability table, but in general this requirement is satisfied.
7. “No notes shorter than a semi-quaver may be included.”
All note lengths are computed within the recursive note splitting function, which
will automatically halt the splitting process on a given note if the minimum note
length (i.e. semiquaver) is reached, and hence it is impossible for shorter notes
to occur.
8. “The application should allow the composer to restrict the key of the piece to a
key of their choice.”
Flute Composer bases the key of the piece on the key and chord information
entered at the start of the piece, with the default key (and the key for which the
information files are provided) being C major. The probabilities that determine
the intervals that occur within the piece are key dependent but can also be
modified by the user. Therefore it is possible for the user to alter or rewrite
these files to provide information for an alternative key.
7.1.6 Non-functional Requirements
1. “The application should not require the user to have expert musical knowledge
to use it.”
Flute Composer requires no specialist musical knowledge to run it. More expert
users are able to further define or modify parameters by editing the input files;
however as default input files are provided with the system, such knowledge is
not essential.
2. “The application must operate within the Windows operating system, and should
also operate within Linux environments.”
The application has been thoroughly tested within the Windows operating
environment and is also thought to run correctly within Linux-based systems,
although limited access means that the latter has not been as extensively tested.
3. “The application must not require access to any further musical software tools,
other than such as are freely available at no extra cost.”
The only additional musical software tool required by Flute Composer is
Lilypond, which is available free on almost all platforms.
Page | 53
4. “The application must not require any specialist hardware items, although it may
be assumed that the user has a standard sound card and audio output (e.g.
speakers or headphones) installed.”
Flute Composer requires no additional specialist hardware devices.
5. “The application should not require more than 10MB to store and run.”
The Flute Composer system itself is only just over 50KB in size, and a sample
output (consisting of the Lilypond input file, the MIDI audio file and the PDF of
the manuscript) for the default input files is approximately 420KB. This figure is
naturally dependent on the length of the score generated, which in turn is
dependent on the parameters entered by the user, however as for the default
values the total storage required is easily less than 1MB, this requirement will be
considered to have been successfully met.
7.2 Further Evaluation of Musical Output This section provides further evaluation of the system and uses examples to highlight
some of the successful features in the output of the application. Sample lines have been
selected from a number of randomly chosen outputs from various instances of running
the program. The pieces are too long for the entirety to be produced here, although a
number are included in the appendices and on the data disc.
Example 1
Figure 7.1 – A sample of the output of the Flute Composer application.
This example clearly shows the occurrence of scale-based runs and arpeggios in the
melody. The first six notes of the melody form a downward scale, which is followed by
an upward arpeggio. Note that the pitch interval between notes changes here at the
same point the rhythm changes, in the manner described earlier in the design section.
This sample is the last line of the piece, and ends on the root note of the key as is typical
of the required style.
Page | 54
Example 2
Figure 7.2 – A second sample of the output of the Flute Composer application.
This is the first line of the second sample, and shows that the piece correctly starts on
the root note of the key. By comparing the first and third bars of the piece, we see that
the rhythm patterns are identical, and that the repetition in the pitch intervals is almost
identical with only a small one-note variation (the second to last note of the bar).
Remarks on Playability
In general, there are no playability issues within the output generated by the
application. Not only has the output been successfully assessed against the criteria for
‘playable’ flute music laid out in the Requirements section, a less formal (but possibly
more relevant) method of attempting to play the output on a physical flute has also
been employed. This method alone would not have been sufficient to gauge whether
the project is successful as it is not easily quantified and hence difficult to determine
precise criteria to evaluate or compare the output with. However, as a primary focus of
the project is to produce music suitable for playing on the instrument, this process
should not be omitted from the evaluation.
Performing the musical output of Flute Composer on an actual flute posed no real
playability problems. In general, the music was quite straightforward to play, as the
range of the composition stays within the range of the instrument and there are very
few faster passages in the music. Although potentially complex fingering changes occur
in places, as the speed of the piece (in terms of note lengths) is not too great, assuming
the piece is being played at moderate tempo, these should not prove to be too difficult
for a reasonably competent flautist to overcome with a small amount of practice and
more advanced flautists are unlikely to have any issues with playing the piece at all.
Further keys introduced by users may provide greater playability challenges, but it is
believed that these will not be so severe that they cannot be overcome.
Page | 55
Remarks on Style
The overall effect of the musical output is quite pleasing, even if it is still easily
distinguishable from genuine classical musical to the experienced listener. The melody
has good flow, and the disjointed feel of the initial algorithm output has been lost. The
scale-based runs and arpeggios are very much evident in all of the samples the
completed application has produced, and although the repetition is less obvious it can
be found to some extent in all the piece generated by the completed application so far.
7.3 Summary of Evaluations In general, evaluation of Flute Composer has shown the application is largely successful
in its objectives. The system meets all the ‘must’ criteria satisfactorily, in addition to
almost all of the ‘should’ criteria. A small number of requirements denoted by ‘may’
have proven to be outside of the scope and timescale of the project but this had largely
been anticipated, and these features were considered to be desirable ‘extras’ rather
than key criteria for success. Additional, less formal, evaluations have confirmed that the
successful criteria reflect the overall performance of the application.
Page | 56
Chapter 8: Conclusions and Further Work
8.1 Conclusions In general, this project has been reasonably successful in meeting its objectives. The
development of Flute Composer draws upon and extends the work of many previous
computer composers to create a new system for generating classical style flute music.
The application runs smoothly without problems and allows the user to produce the
desired output with minimal effort.
The initial algorithm produced acceptable results, but the final algorithm is much
improved. Although the program does not imitate the style produced by a human
composer quite as accurately as had been hoped, this is more due to early expectations
possibly being a little too high, and the output of the application still meets all of the
specified stylistic and playability requirements laid out at the start of the project. In
order to achieve a more exact replication of the classical style, a more in depth study of
the details of the style would be required in an attempt to further formalize the human
composition process, but as composition (at least, in this style) is generally perceived to
be to some extent an artistic process rather than an exact science, the rules of such
music are very hard to precisely define and may even be limitless. Therefore, it would be
unrealistic to expect to formalize them in under seven months, and so it is reasonable to
consider the project a success even though this has not been totally achieved. Also, as
the number of rules increase and the program tends towards a deterministic system,
much of the creative aspects of the composition will be lost and so this may not be
entirely desirable.
Many approaches and methods have been experimented with during the development
of the project, with varying degrees of success. Stochastic processes have been
successfully used in a variety of ways, as a complete method in their own right based on
Markov Chains to randomly generate pitches based on the previous note and in the note
splitting functions to determine the rhythm, as a tool within the pattern matching
methods to decide whether or not to follow the pattern and also in initializing the L-
system for the chord generation process. The ease of implementation and their large
range of potential use within the field of algorithmic composition make it evident why
they are so widely used. The concept of L-systems has been introduced into the chord
generation and although it has produced some reasonably satisfactory and certainly
interesting results, it is felt that the behavior of the system under the prescribed
parameters could still be further improved. The pattern matching methods used have
been effective in achieving their desired purposes. The combination of methods used in
the project may have been unusual; most widely available composition systems tend to
Page | 57
focus on one main method, however overall the application is quite successful in
meeting its aims.
Because of the specialist nature of the project, i.e. composing for a specific instrument
within a specific style, there are no widely available systems to compare Flute Composer
to directly. However, it is felt that Flute Composer has been successful in its own right,
and although many improvements are beyond the scope and timescale of this project,
many successful developments have been made in composing classical music for the
flute.
8.2 Further Work There are many areas of the project that, given more time, could be extended or
developed further. As mentioned above in the conclusions, a much more in depth study
of the classical music style and existing classical works would allow the composition
process to be formalized further and thus improve the accuracy with which the output
of the program imitates the styles of the human composers of that period. Although too
precise a definition could lead to a system that consistently produced almost identical
output every time it was run, it is likely that there is some room for improvement in this
area.
Additional manipulation and readjustment of the probabilities used at various stages of
the algorithm could potentially further improve the quality, musicality and style of the
output, but this is also an ongoing process that could go on for many months in itself. It
is felt that although the current probabilities may not be quite optimal for producing the
desired style of output, they are still more than satisfactory, particularly when
considered alongside the relatively short timescale of the project.
The accompaniment provided for the flute melody was never intended to be a primary
focus of the project, and hence the accompaniment developed is very simple. Although
to a certain extent the character of the accompaniment still reflects the classical style,
further work on the accompaniment would allow it to become a more integrated part of
the piece. Aside of both taking into account the underlying chord structure, the current
accompaniment is developed entirely separately to the melody, so a possible
enhancement would be to develop better links between the two, for example
incorporating other features of classical music such as sequencing and imitation
between the two parts, or sections of a ‘call and response’ type nature.
The underlying chord structure could also be developed further. The project
experiments with the use of L-systems in its chord generation, however it is felt that
there is further potential to reflect this concept more accurately within the process and
develop it more fully. Alternatively, there are many other approaches for generating
chord sequences that may also produce interesting results.
Page | 58
Although Flute Composer successfully produces short pieces, it currently provides no
mechanism for producing longer pieces with multiple sections. Obviously, the user could
simply generate a succession of short pieces and join these together to make a longer
one, but this is something that could also be automated within the application. The
system also does not provide repetition at a high level, for example the exact repetition
of complete phrases, as this was not seen to be compatible with the L-system chord
generation structure, however repetition of entire sections (each of which would be
generated independently from separate L-systems) would be possible if longer pieces
were desired.
Page | 59
Bibliography
AMES, C., 1989. “The Markov Process as a Compositional Model: A Survey and a Tutorial.” Leonardo Music Journal 22(2):175-187. BERG, P., 1996. “Abstracting the Future: The Search for Musical Constructs.” Computer Music Journal 20(3):24-27. BIDLACK , R., 1992. “Chaotic Systems as Simple (but Complex) Compositional Algorithms.” Computer Music Journal 16(3):33‐47. BURTON, A., & Vladimirova, T., 1999. “Generation of Musical Sequences with Genetic Techniques.” Computer Music Journal 23(4):59-73. CAMBRIDGE ADVANCED LEARNERS DICTIONARY, 2005. 2nd ed. Cambridge University Press. COPE, D., 1992. “Computer Modelling of Musical Intelligence in EMI.” Computer Music Journal 16(2):69-83. DODGE, C., 1988. “Profile: A Musical Fractal.” Computer Music Journal 12(3):10-14. DOLSON, M., 1989. “Machine Tongues XII: Neural Networks.” Computer Music Journal 13(3):28-40. FERREIRA, M., 2002. “Proportions in Ancient and Medieval Music”. In: G. ASSAYAG, H.G. FEICHTINGER, J.F. RODRIGUES, eds. Mathematics and Music, Springer Press. HARLEY, J., 1995. “Generative Processes in Algorithmic Composition: Chaos and Music.” Leonardo Music Journal 28(3):221‐224. JONES, K., 1981. “Compositional Applications of Stochastic Processes.” Computer Music Journal 5(2):45‐59 JONES, K., 1991. “Dicing with Mozart: Just as whimsical musicians in the 18th.” New Scientist 1799:26. LEACH, J. & Fitch, J.,1995. “Nature, Music, and Algorithmic Composition.” Computer Music Journal 19(2):23‐33. LEVITIN, A., 2007. “Introduction to the Design and Analysis of Algorithms” 2nd ed. Addison Wesley. MASON, S. & Saffle, M., 1995. “L-systems, Melodies and Musical Structure.” Leonardo Music Journal (4):31-38. McALPINE, K., Miranda, E. & Hoggar, S., 1999. “Making Music with Algorithms: A Case-Study System.” Computer Music Journal 23(2):19-30. MOZART, W. A., 1787. Musicalisches Wurfelspiel (Dice Music). OXFORD COMPACT ENGLISH DICTIONARY, 2005. 3nd ed. Oxford University Press. PRUNSINKIEWICZ, P., 1986. “Score Generation with L-systems.” IN: Proceedings of the 1986 International Computer Music Conference, pp. 455-457. RICHIE, D. M., 1993. The Development of the C Language. In: THOMAS J. BERGIN, JR. AND RICHARD G. GIBSON, JR, eds. Conference Proceedings of History of Programming Languages‐II, New York: ACM Press. ROADS, C., 1980. “Artificial Inteligence and Music.” Computer Music Journal 4(2):13-25. ROADS, C., 1996. The Computer Music Tutorial. United States of America: MIT Press. WALMSLEY, M., 1997. Programming in C++. Bernard Babani Publishing. XENAKIS, I., 1971. Formalised Music. Indiana University Press.
Page | 60
Appendix A: Flute Composer Sample Outputs
Page | 61
Appendix B: Contents of Data Disc
The data disc contains:
• the full code listing for Flute Composer
• the default input files for use with the program
• some samples of the audio and manuscript outputs produced by Flute
Composer.
Page | 62
Appendix C: Complete Code Listings for the Final Algorithm Implementation