A GENETIC ALGORITHM FOR MUSIC COMPOSITION
GAVIN PENNYCOOK
MSC INFORMATION TECHNOLOGY (SYSTEMS)
September 2001
-2-
Gavin Pennycook MSc Information Technology (Systems)
TABLE OF CONTENTS
TABLE OF FIGURES .................................................................................................................................... 4
ABSTRACT ..................................................................................................................................................... 6
ACKNOWLEDGEMENTS............................................................................................................................ 7
CHAPTER 1 - INTRODUCTION .............................................................................................................. 8
1.1 SOME MUSIC THEORY.......................................................................................................................... 9 1.1.1 Pitch........................................................................................................................................... 9 1.1.2 Rhythm..................................................................................................................................... 10
1.2 ALGORITHMIC MUSIC COMPOSITION................................................................................................. 12 1.2.1 The Composition of Music ...................................................................................................... 13 1.2.2 Rule-Based Systems ................................................................................................................ 13 1.2.3 Learning Systems.................................................................................................................... 14
1.3 GENETIC ALGORITHMS...................................................................................................................... 15 1.3.1 Considerations........................................................................................................................ 18
1.4 GENETIC ALGORITHMS AND MUSIC COMPOSITION........................................................................... 21 1.4.1 Automated Fitness Function .................................................................................................... 21 1.4.2 Human Fitness Function ......................................................................................................... 22
CHAPTER 2 – DESIGN AND IMPLEMENTATION OF PROGRAM ... ............................................... 24
2.1 REQUIREMENTS................................................................................................................................. 24 2.2 DESIGN OF THE ALGORITHM .............................................................................................................. 25
2.2.1 Representation......................................................................................................................... 25 2.2.2 Population ............................................................................................................................... 26 2.2.3 Operators................................................................................................................................. 26 2.2.4 Evaluation................................................................................................................................ 28 2.2.5 Selection .................................................................................................................................. 29
2.3 THE OVERALL ALGORITHM ............................................................................................................... 31 2.4 IMPLEMENTATION.............................................................................................................................. 33
2.4.1 The class Bar ........................................................................................................................... 35 2.4.2 The class Tune ......................................................................................................................... 35 2.4.3 The class Pop........................................................................................................................... 36 2.4.4 The class GA............................................................................................................................ 36
2.5 VALIDATION ...................................................................................................................................... 37 2.6 VERIFICATION.................................................................................................................................... 37
2.6.1 Module Testing ........................................................................................................................ 37 2.6.2 Bar Store Array ....................................................................................................................... 37 2.6.3 Cross-checking for Errors ....................................................................................................... 38 2.6.4 Errors Checklist....................................................................................................................... 38 2.6.5 Structural Testing .................................................................................................................... 38
2.7 INTERFACING WITH SOUND................................................................................................................ 38 2.8 GRAPH PLOTTING SOFTWARE............................................................................................................ 39
CHAPTER 3 - EXPERIMENTAL DESIGN AND RESULTS........ .......................................................... 40
3.1 EXPERIMENTAL DESIGN..................................................................................................................... 41 3.1.1 Choosing Initial Fitness Function Weights ............................................................................ 41 3.1.2 Choosing Initial Population Size ............................................................................................. 41 3.1.3 Choosing Initial Mutation Rate ............................................................................................... 41 3.1.4 Choosing Total Number of Generations.................................................................................. 41
3.2 INVESTIGATING EFFECT OF VARYING FITNESS FUNCTION WEIGHTS................................................. 42 3.2.1 Plot of Mean Fitness................................................................................................................ 42 3.2.2 Plot of Maximum and Minimum Fitnesses and Standard Deviation ....................................... 49
3.3 INVESTIGATING EFFECT OF VARYING STANDARD GA PARAMETERS................................................. 63 3.3.1 Varying Mutation Rates........................................................................................................... 63 3.3.2 Varying Population Size .......................................................................................................... 63
-3-
Gavin Pennycook MSc Information Technology (Systems)
3.3.3 Results ..................................................................................................................................... 65 3.3.4 Discussion of these Results ...................................................................................................... 70
3.4 EXAMINATION OF TUNES OF MAXIMUM FITNESS............................................................................... 71 3.5 LISTENING TO THE MUSIC PRODUCED................................................................................................ 72
CHAPTER 4 - CONCLUSIONS AND POSSIBILITIES FOR FUTUR E WORK.................................. 73
4.1 CONCLUSIONS.................................................................................................................................... 73 4.2 POSSIBILITIES FOR FUTURE WORK .................................................................................................... 74 4.3 SUMMARY .......................................................................................................................................... 76
REFERENCES .............................................................................................................................................. 77
BIBLIOGRAPHY ......................................................................................................................................... 82
APPENDICES ...............................................................................................................................................83
APPENDIX 1 CONTENTS OF CD............................................................................................................... 84 APPENDIX 2 SOURCE CODE .................................................................................................................... 85
-4-
Gavin Pennycook MSc Information Technology (Systems)
TABLE OF FIGURES Fig. 1 2 octaves of a piano keyboard ...............................................................................10 Fig. 2 Relationships between different note durations ....................................................11 Fig. 3 A Typical GA ........................................................................................................17 Fig. 4 Two Point Crossover .............................................................................................19 Fig. 5 Mutation ................................................................................................................19 Fig. 6 Chunk Crossover ...................................................................................................27 Fig. 7 Genetic Algorithm for Music Composition...........................................................32 Fig. 8 UML class diagram for the program .....................................................................34 Fig. 9 Varying AVERAGE_LENGTH_WEIGHT ..........................................................43 Fig. 10 Varying CONSECUTIVE_LENGTH_WEIGHT................................................43 Fig. 11 Varying FINAL_PITCH_WEIGHT....................................................................44 Fig. 12 Varying FIRST_PITCH_WEIGHT.....................................................................44 Fig. 13 Varying FINAL_LENGTH_WEIGHT ...............................................................45 Fig. 14 Varying NOTES_BEGIN_WEIGHT_1 ..............................................................45 Fig. 15 Varying NOTES_BEGIN_WEIGHT_2 ..............................................................46 Fig. 16 Varying NOTES_BEGIN_WEIGHT_4 ..............................................................46 Fig. 17 Varying TRANSITION_WEIGHT .....................................................................47 Fig. 18 Comparing Mean Fitness using Different Weights .............................................47 Fig. 19 GA with normalised weight values .....................................................................50 Fig. 20 Increasing AVERAGE_LENGTH_WEIGHT.....................................................51 Fig. 21 Decreasing AVERAGE_LENGTH_WEIGHT ...................................................51 Fig. 22 Increasing CONSECUTIVE_LENGTHS_WEIGHT..........................................52 Fig. 23 Decreasing CONSECUTIVE_LENGTHS_WEIGHT .......................................52 Fig. 24 Increasing FINAL_PITCH_WEIGHT ................................................................53 Fig. 25 Decreasing FINAL_PITCH_WEIGHT ...............................................................53 Fig. 26 Increasing FINAL_LENGTH_WEIGHT............................................................54 Fig. 27 Decreasing FINAL_LENGTH_WEIGHT...........................................................54 Fig. 28 Increasing FIRST_PITCH_WEIGHT .................................................................55 Fig. 29 Decreasing FIRST_PITCH_WEIGHT................................................................55 Fig. 30 Increasing NOTES_BEGIN_WEIGHT_1..........................................................56 Fig. 31 Decreasing NOTES_BEGIN_WEIGHT_1 .........................................................56 Fig. 32 Increasing NOTES_BEGIN_WEIGHT_2...........................................................57 Fig. 33 Decreasing NOTES_BEGIN_WEIGHT_2 .........................................................57 Fig. 34 Increasing NOTES_BEGIN_WEIGHT_4..........................................................58 Fig. 35 Decreasing NOTES_BEGIN_WEIGHT_4 ........................................................58 Fig. 36 Increasing TRANSITION_WEIGHT.................................................................59 Fig. 37 Decreasing TRANSITION_WEIGHT ..............................................................59 Fig. 38 Comparing Minimum Fitness using Different Weights ......................................60 Fig. 39 Comparing Maximum Fitness using Different Weights......................................60 Fig. 40 Table Showing Different Settings of Mutation Rate and Population Size..........64 Fig. 41 MUT_RATE_1 high, MUT_RATE_2 high, POP_SIZE high ............................65 Fig. 42 MUT_RATE_1 high, MUT_RATE_2 high, POP_SIZE low .............................65 Fig. 43 MUT_RATE_1 high, MUT_RATE_2 low, POP_SIZE high .............................66 Fig. 44 MUT_RATE_1 high, MUT_RATE_2 low, POP_SIZE low...............................66 Fig. 45 MUT_RATE_1 low, MUT_RATE_2 high, POP_SIZE high .............................67 Fig. 46 MUT_RATE_1 low, MUT_RATE_2 high, POP_SIZE low...............................67
-5-
Gavin Pennycook MSc Information Technology (Systems)
Fig. 47 MUT_RATE_1 low, MUT_RATE_2 low, POP_SIZE high...............................68 Fig. 48 MUT_RATE_1 low, MUT_RATE_2 low, POP_SIZE low................................68 Fig. 49 Varying Mutation Rates and Population Size .....................................................69
-6-
Gavin Pennycook MSc Information Technology (Systems)
ABSTRACT
The aim of the project was to learn Java then write a program in this language to
implement a Genetic Algorithm with an automated objective fitness function for music
composition, then to investigate the effect of varying parameter values on the overall
fitness of the melodies produced. The basic GA was implemented successfully and found
able to improve the fitness of random melodies over many generations. However, after
these first generations, the fitness of the best individual in almost all trials remained at the
same value for the remaining generations. This was found to be due in each trial to the
increasing abundance over the generations of a small number of bars which made a large
contribution to tune fitness and rendered the standard GA operators ineffective.
-7-
Gavin Pennycook MSc Information Technology (Systems)
ACKNOWLEDGEMENTS
I’d like to thank my supervisor, Nick Taylor, for his guidance and patience; Steve Salvini,
problem manager, for technical advice; and my fellow students Craig Douglas, Panos
Chorianopoulos, Kirsteen McInnes and Jennifer Low for helpful comments.
-8-
Gavin Pennycook MSc Information Technology (Systems)
CHAPTER 1 - INTRODUCTION
Algorithmic music composition is an area of work with a long history and many different
techniques and approaches. Since 1991 there have been various attempts to compose music
using Genetic Algorithms (GA’s), a process modelled on the biological process of
evolution. This project aimed to add to the current body of knowledge of GA’s and music
by implementing a GA in Java to compose melodies, and experimenting with different
values of the GA parameters.
A common AI technique for problem-solving is to consider the problem as a search
problem. The goal is to explore the entire set of possible solutions to find one that satisfies
the original criteria; it is important to structure this set of possible solutions so that one
does not have to examine each solution, allowing the completion of the search in a finite
period of time. The GA is one technique used to solve a search problem.
Some basic music theory is described in section 1.1, followed by an introduction to
algorithmic composition in section 1.2. Genetic Algorithms are explained in Section 1.3,
and the application of Genetic Algorithms to music composition is outlined in section 1.4.
-9-
Gavin Pennycook MSc Information Technology (Systems)
1.1 Some Music Theory
A melody has been defined as a “sweet or agreeable succession or arrangement of sounds”,
or a “rhythmic succession of single tones organized as an aesthetic whole” [Merriam-
Webster, 2001]. For our purposes, we can consider a melody to be a sequence of notes.
The primary attributes of these notes are pitch and duration.
1.1.1 Pitch
Pitch can be defined as “the property of a sound and especially a musical tone that is
determined by the frequency of the waves producing it : highness or lowness of sound”
[Merriam-Webster, 2001]. A note’s frequency is the number of wave cycles per second
(Hz) which characterises the note. In western music, the interval between a note of
frequency (or pitch) f and a note of frequency 2f is known as the octave. We divide this
interval into twelve pitch steps or semitones, where the ratio between one semitone and the
next higher one is around 1:21/12. We assign the same letter to a pitch and the pitch an
octave higher. For example, the note that an orchestra usually tunes to (the A above middle
C) has a frequency of 440 cycles per second, and the note with double this frequency
(880Hz) is also called A. This can be seen in fig. 1, which displays two octaves of a piano
keyboard.
-10-
Gavin Pennycook MSc Information Technology (Systems)
Fig. 1 2 octaves of a piano keyboard
Db Db ##
Of the twelve semitones, seven (the degrees) play a central role in a particular mode or
key. These seven can be represented in a key-independent form as doh, re, mi, fah, soh, lah
and ti. For example, the scale of C major begins on C and includes the notes D, E, F, G,
A, B, and terminates on the next C (doh again). The first note of the scale, doh, is also
known as the tonic note and is the most important note in the scale or key. The less
important notes in a key are known as the chromatic notes – in this case C#, D#, F#, G#
and A#.
A chord is defined as three or more musical tones played simultaneously [Merriam-
Webster, 2001]. The most important chord in a piece of music is the tonic triad, consisting
of the tonic note, the mediant (mi or the third note of the scale) and the dominant (soh or
the fifth note). This is often the first and last chord of the piece.
1.1.2 Rhythm
Rhythm is a pattern of durations. Some common durations used in western music are the
semibreve, minim, crotchet, quaver and semi-quaver. In terms of length, 1 semibreve = 2
minims = 4 crotchets = 8 quavers = 16 semi-quavers (see fig. 2). A note can have length
equal to any combination of these durations, and it should be remembered that these are
relative durations only – that is, there is no universal standard for the length of, say, a
crotchet in seconds.
C D F E A G B
C#### D####
C D F E A G B
D# C# F# A# G# C# D# F# G# A#
Db
or
Db
or
Eb
or Gb
or Ab
or Bb
or Db
or Eb
or Gb
or Ab
or Bb
or
440 Hz 880 Hz
Increasing frequency
-11-
Gavin Pennycook MSc Information Technology (Systems)
Fig. 2 Relationships between different note durations
Music is often divided up into units called measures or bars. Each measure contains a
certain number of beats, and the number of beats is determined by the time signature or
meter. For example, some music is written as 34 . The top number ( 3 ) represents the
number of beats per bar and the bottom number tells us what value of note we assign as the
duration of each beat, in this case the crotchet ( 4 ). Phrases are sequences of bars, and
what we recognise as tunes or melodies are generally sequences of phrases.
1 semibreve
2 minims
8 quavers
4 crotchets
16 semi-quavers
-12-
Gavin Pennycook MSc Information Technology (Systems)
1.2 Algorithmic Music Composition
The first musical instruments which have been identified as such are 32 000 year-old bone
flutes found in caves in France dating from 34 000 BC [Lander], so we know man has
been making music for a very long time indeed. For thousands of years he has been
attempting to define the rules that govern music and to understand what is meant by
“good” music.
Pythagoras investigated the connections between mathematics and music 2500 years ago,
discovering the mathematical relationship represented by harmonic intervals such as the
fourth, the fifth and the octave by observing different lengths of string being plucked. In
1026, Guido d'Arrezzo suggested a scheme that assigned pitches to each vowel sound in a
religious text, pioneering formal techniques for melody composition. The Austrian
composer Mozart (18th century) threw dice to determine the order in which he placed
phrases in his compositions.
The use of computers to compose music began in the mid-1950s. With a computer, it is
possible to preview and test the musical capabilities of many different algorithmic types
and judge whether they have the potential to be developed into fully-fledged composition
systems. The earliest composition programs were often driven by stochastic (random)
processes. Hiller's 1956 work, The Illiac Suite for String Quartet, is recognized as being
the very first computer-composed composition – he used random generators and Markov
Chains, a technique for making decisions on the basis of probability [Papadopoulos &
Wiggins, 1999].
The advent of affordable and powerful computing resources has meant that algorithmic
composition is no longer the exclusive province of the professional composer or computer
scientist - more and more people have been able to realize their composition algorithms
from their PC's. Also, interactive algorithmic music composition software, for example
jMusic at Queensland University of Technology [Sorensen & Brown], has been developed,
enabling novices to create their own compositions.
-13-
Gavin Pennycook MSc Information Technology (Systems)
1.2.1 The Composition of Music
The composition of music can be considered from an AI viewpoint as a search problem:
consider the set of all possible compositions as the solution space, and try to solve the
problem of finding a composition that sounds good. Unfortunately, the solution space is
unstructured; good solutions may be adjacent to extremely poor ones : if just a few notes in
a piece of music are changed, it may become far less tuneful, though it may be almost
identical from a low-level perspective.
When simulating human music composition, all AI systems must resolve the trade-off
between novelty and structure. This can be seen as from an artistic point of view as the
tension between creativity and aesthetic and technical constraints; or from an AI point of
view as the trade-off between the ability to search a large space of potential solutions, and
the constraints and bias dictated by the need for an efficient search.
Although most computer-generated music composition involves elements of an AI
approach, three distinct categories based on AI techniques have been identified [Todd &
Werner, 1999] – rule-based systems, systems which learn by trial and example and
evolutionary algorithms.
1.2.2 Rule-Based Systems
Rule-based systems for music composition have a history stretching back to Mozart's dice.
The advantage of such systems is that their encoded knowledge is explicit, so they behave
in a predictable way. However, the problem with attempting to define human performance
with rules is that there are exceptions to these rules and exceptions to the exceptions, an
example being the lack of a complete and consistent set of rules for counterpoint and voice
leading [Towsey et al., 2001]. Rule-based systems approach the problem from the structure
side of the trade-off – they do not always incorporate novelty. A common contemporary
approach in this category is expert systems [Yu, 1996][Cope, 1997].
-14-
Gavin Pennycook MSc Information Technology (Systems)
1.2.3 Learning Systems
When trained on melodic sequences, learning systems acquire statistical knowledge about
local structure - that is, given a sequence of four or five notes the system is able to predict
the probability of each candidate for the next note. The advantage of these systems is that
they can produce tuneful sequences on a short time scale. However, since they do not learn
large scale structure, their melodies tend to show little sense of direction.
Learning systems often include Markov models [Loy, 1991] and neural networks ( eg the
CONCERT software [Mozer, 1994] ). The EMI and CUE software [Cope, 1997]
implements a hierarchy of Markov models in an attempt to rectify the lack of large-scale
structure. Learning systems lie at the centre of the trade-off – they can generalise to novel
situations on the basis of their acquired statistical knowledge.
-15-
Gavin Pennycook MSc Information Technology (Systems)
1.3 Genetic Algorithms
The search method we consider here is the Genetic Algorithm. An algorithm is a sequence
of steps designed to solve a specific problem – if the steps are clearly enough defined they
can be executed by a computer program. Genetic Algorithms are based on the concept of
evolution – adaptation through crossover and mutation over many generations.
Computational approaches based on evolution were first explored in the 1950s.
In nature, the evolutionary process takes place when the following conditions are satisfied
[Koza, 1992] :
1. An organism has the ability to reproduce itself.
2. There is a population of such self-reproducing organisms.
3. Variety exists among these organisms.
4. The variety is linked to a difference in ability to survive in the environment.
In nature, variety is shown in the differences between the chromosomes of the organisms
of a particular population. This variety is associated with differences in the organisms’
structure and behaviour and so also with a variation in their survival and reproduction
rates. Thus organisms with a structure and behaviour more conducive to success in their
environment will survive and reproduce more than others in the population the concept of
natural selection and survival of the fittest introduced by Charles Darwin in his book “The
Origin of Species”. Over many generations, the population will come to contain
progressively fitter individuals whose structure will be different from those in the initial
population – we may say that the population has evolved.
Chromosomes, the primary identifiers of a biological individual, are strings of characters
“written” in a four-letter alphabet, the “letters” being nucleotide bases denoted by A, C, G
and T, which appear along the length of each DNA molecule. DNA molecules are capable
of self-reproduction, and they govern the structure and behaviour of biological cells, which
in turn govern the fitness of an individual. The chromosomes of offspring contain strings
of these bases from their parent(s), so the strings which lead to greater success in the
environment are passed on to future generations at higher rates. Mutation may also take
-16-
Gavin Pennycook MSc Information Technology (Systems)
place in the chromosomes during the reproduction (we can think of this as representing
errors in copying) and this provides still more potential for variety in the DNA.
Genetic Algorithms were proposed by John Holland in the 1960s and explained in his
book “Adaptation in Natural and Artificial Systems” [Holland, 1975] – he realised that
any problem based on adaptation could be expressed in genetic terms and investigated
using such an algorithm.
We can define a Genetic Algorithm as a parallel mathematical process which transforms a
set of mathematical objects, each with an associated fitness value, into a new set (the next
generation’s population) using operations modelled on reproduction, mutation and survival
of the fittest. A GA searches the space of all possible strings to find high-fitness strings,
guided only by the numerical fitness values. It is a domain-independent way of rapidly
searching an unknown space for points of high fitness. The technique is particularly well-
suited to solving problems where the nature of the solution domain is difficult to
understand or there is no obvious way to judge the solutions effectively. Genetic
Programming (GP), first proposed by Koza [Koza, 1992], is a form of evolutionary
computation in which the individuals (chromosomes) in the population are computer
programs themselves, and the genes are blocks of this program code.
Genetic Algorithms have wide-ranging applications, ranging from exam timetabling
[Corne et al., 1993] to creating visual art [Sims, 1993].
A GA consists of the following components:
1. A representation for chromosomes or hypotheses, potential solutions to the
problem considered.
2. An initial population of these chromosomes.
3. A set of operators which serve to generate new candidate hypotheses from
chromosomes in the population, and information as to when these operators
should be applied.
4. An evaluation function to assess the fitness or quality of a hypothesis.
5. A selection method which gives good solutions a better chance of survival.
-17-
Gavin Pennycook MSc Information Technology (Systems)
Fig. 3 A Typical GA
Increase generation number by 1
Initialise population – generate p hypotheses at random
Evaluate – for each hypothesis calculate fitness.
Is termination condition true?
Yes
No
Is this first generation?
Yes
Create new population - select hypotheses from
previous generation’s pool
Finish
Select some fraction of the hypotheses from current population
Cross over pairs of these hypotheses with each other to generate children
Mutate some fraction of the child hypotheses by applying the mutation operator
Evaluate all child hypotheses
Add all child hypotheses to population , creating temporary pool
No
-18-
Gavin Pennycook MSc Information Technology (Systems)
An initial set of hypotheses, possible solutions consisting of a string of genes (a gene is our
basic building block, and particular values of genes are known as alleles) is created at
random. At this and each subsequent generation, the hypotheses are evaluated for their
fitness, and the fittest hypotheses are selected probabilistically and used to produce
offspring hypotheses using operations such as crossover and mutation. The offspring
hypotheses are added to the current population to create a temporary pool, then the next
generation’s population is produced by selecting the required number of hypotheses from
this temporary pool.
1.3.1 Considerations
1.3.1.1 Representation
There exist many ways of encoding the chromosomes in a form that the GA can
manipulate, for example a string of binary digits or a logical expression. The method
chosen will depend on the problem being considered.
1.3.1.2 Population We must consider:
1. Population size – large populations have a larger and possibly more diverse
number of candidate hypotheses, but they will take longer to evaluate. Within a
given run of a GA, the population size tends to be fixed.
2. Method of updating population from one generation to the next – there are two
common approaches here - steady-state, where a maximum of only a few
hypotheses (often only one) are replaced at each generation, and generational,
where any number of hypotheses up to all those in the population may be replaced
at each generation [Drakos et al., 1996]. The word may is used because one
possibility for both steady-state and generational GA’s is that the selection process
at a particular generation may lead to all the individuals in the old population
surviving to the next one.
-19-
Gavin Pennycook MSc Information Technology (Systems)
1.3.1.3 Operators
1.3.1.3.1 Crossover
The crossover operator implements an exchange of information between two, or possibly
more, chromosomes in a population. This can be illustrated by a common operator for
binary strings – two-point crossover – which picks two points at random along the strings
and exchanges the digits in the strings between these two points to produce children eg.
Fig. 4 Two Point Crossover
0 0¦0 0 0 0¦0 0 Crossover 0 0¦1 1 1 1¦0 0
1 1¦1 1 1 1¦1 1 -------------> 1 1¦0 0 0 0¦1 1
Crossover is useful because it can bring together portions of separate strings associated
with high fitness, creating even fitter children, and conversely bring together poorer
portions so that they can be purged from the population.
1.3.1.3.2 Mutation The mutation operator randomly changes part of a chromosome. For the example of a
binary string, one or more bits are simply flipped:
Fig. 5 Mutation Mutation
0 0 0 0 0 0 0 0 -------------> 0 0 0 0 0 1 0 0
Holland emphasised a low mutation rate, and early GA research tended to view mutation
as not being particularly important. However, the fact that mutation-only optimisation
techniques can obtain significant results has convinced many scientists today that mutation
is in fact an important operator [Wiggins et al., 1999]
-20-
Gavin Pennycook MSc Information Technology (Systems)
1.3.1.4 Evaluation
Use a function to measure the quality of a hypothesis. This function may be difficult to
define, especially where multiple fitness measures have to be assigned different weights in
order to be combined into an overall function. GA’s which use subjective human opinion
instead of an objective fitness function are known as Interactive Genetic Algorithms
(IGA’s).
1.3.1.5 Selection
How should we select hypotheses for breeding and for survival into the next generation?
Common methods for selection include fitness proportionate selection or roulette wheel
selection, where the probability that a hypothesis is selected is equal to the ratio of its
fitness to that of other competing hypotheses in the same generation; tournament selection,
where pairs of hypotheses are chosen at random from the current population, and the fittest
is selected - this may lead to more diversity in the population than the use of roulette wheel
selection; and rank selection, where each hypothesis in the population is allocated a rank
representing its position in the order of hypotheses' fitnesses, then selected with a
probability proportional to this rank.
-21-
Gavin Pennycook MSc Information Technology (Systems)
1.4 Genetic Algorithms and Music Composition
GA's are well-suited to the task of musical composition because they combine the ability
to explore a large search space (creativity - the mutation and crossover operators) with
constraints or structure (a fitness function) explicitly built into the algorithm. The designer
is able to manipulate the balance between these two.
The success of the GA approach depends on imposing appropriate constraints on the
search, and in particular on devising a fitness function which measures the aesthetic worth
of a melody.
Most attempts have used very simple representations to try to reduce the space to be
searched – this has compromised the quality of the solutions found. Compositional GA's
have been attempted with both types of fitness function - with an automated fitness
function and with a human critic supplying the evaluation (interactive GA). Both
approaches present problems – it is difficult to define musical fitness objectively and hence
difficult to design an automated fitness function; a human critic must listen to a huge
number of tunes, possibly thousands, over the course of many generations, the great
majority of which will not be tuneful – this can be exhausting and it is likely that the
subject’s critical faculty will be temporarily numbed by over-exposure.
1.4.1 Automated Fitness Function
The first published record of the use of GA's for music composition used an automated
fitness function and investigated thematic bridging between very simple melodies [Horner
and Goldberg, 1991]. McIntyre [1994] used GA’s to generate four-part harmony for an
input melody.
Spector and Alpern [1994] used Genetic Programming to evolve programs which return a
melody as an output when one is inputted. Papadopoulos & Wiggins [1998] used a GA to
evolve jazz melodies on a given chord progression, their genes being note pitches relative
to the current chord. They report that the success of a GA depends on the amount of
-22-
Gavin Pennycook MSc Information Technology (Systems)
knowledge supplied to the system, and that it can be difficult to impart this knowledge
successfully to the system because GA’s do not simulate human behaviour.
Shamblen [1999] used a GA for the rhythm of two lines of a pop melody and another for
the underlying chord progression. The results of these were used as input fitness
parameters for a third GA, which composed the notes of the melody. He described his
results as fair but with an “aimless meandering quality”.
Milkie and Chestnutt [2000] designed a GA to create fugues, pieces of music with a
recurring melody or subject, with an automated fitness function. The program was able to
generate subjects successfully, but unable to create complete fugues.
Towsey et al [2001] used their GA to explore melodic extension. They aimed to use their
system as a teaching tool to provide a critique of and suggest an extension to a melody
composed by a student, using a statistical analysis of a library of existing melodies to
define fitness function parameters
1.4.2 Human Fitness Function
Biles [1994] used GenJam, an interactive GA incorporating a learning system, to produce
jazz solos over a given chord progression, using the metaphor of a novice jazz student. He
described his results as “competent with some nice moments”.
Jacob [1995] devised a composing system, Variations, which dealt with the high-level
structures of phrases and motives. Motives were input by a human subject, then variations
on these were composed by his Composer module fed to his Ear module, which had been
“trained” by the human subject, for evaluation.
Burton & Vladimirova [1997] examined the performance of an interactive GA along with
a neural network fitness evaluation to compose rhythms. Horowitz [1994] describes a
genetic algorithm for creating interesting rhythms – he succeeded in generating “tasteful”
patterns.
-23-
Gavin Pennycook MSc Information Technology (Systems)
Johanson & Poli [1998] experimented with Genetic Programming to evolve pieces of
music. With a human critic, they reported the emergence of pleasant melodies over runs of
20 individuals over 10 generations, but with a neural-network based automated rater,
despite using bigger population sizes and greater numbers of generations, they recorded
poorer results.
Tokui & Iba [2000] combined a GA with Genetic Programming to generate rhythms. Their
GA individuals represented short pieces of rhythmic patterns, and their GP individuals
expressed how these patterns were arranged in terms of their functions.
-24-
Gavin Pennycook MSc Information Technology (Systems)
CHAPTER 2 – DESIGN AND IMPLEMENTATION OF PROGRAM
2.1 Requirements It was considered likely that the only users of this system would be the programmer
himself and possible future students who may want to take the work a step further, so the
requirements were easily stated: a program was required which would implement a
Genetic Algorithm with an automated objective fitness function for music composition and
enable the investigation of the effect of varying parameter values on the overall fitness of
the melodies produced.
-25-
Gavin Pennycook MSc Information Technology (Systems)
2.2 Design of the Algorithm The important design issues were the choice of mode of representation for the
chromosomes and genes, the initial population of chromosomes, the operators, the
evaluation function and the selection method.
2.2.1 Representation
I had to consider how to encode chromosomes (hypotheses or individuals) and their basic
building blocks, genes.
2.2.1.1 Chromosomes
GA’s have worked with melodies, rhythm patterns, chord progressions and harmonic lines
as their chromosomes. It was decided to use the melody as the chromosome here.
2.2.1.2 Genes
GP’s tend to use functions performed on notes or sequences of notes [Johanson & Poli,
1998] for their genes. Musical GA’s have used individual notes [Milkie & Chestnutt,
2001] as genes, but because notes have different durations, this means that each
chromosome can have a different length – this makes comparison of the chromosomes
more difficult.. Longer phrases (a phrase contains several bars) have also been used as
genes [Biles, 1994] Jacob [1995]. Shamblen [1999] used bars as his genes for each of his
GA's.
If we consider only tunes throughout which the time signature is constant, and this is true
for the vast majority of tunes, then all the bars contain the same number of beats – they
are of the same length. It seems convenient then to use the bar as the basic building block
- this means that all our genes will be of the same length. This has obvious advantages for
continuity and ease of comparison, not least since replacing one bar with another at
crossover will not alter the length of a tune.
-26-
Gavin Pennycook MSc Information Technology (Systems)
In the interests of simplicity, this project will deal only with pieces of music in 44 time –
this is often known as "common" time and is indeed the most common time signature for
all types of music. In such pieces there are 4 beats in each bar, each represented by a
crotchet. It was decided that the semibreve should be the maximum possible duration and
the semi-quaver the minimum duration unit, so the length of each bar is 1 semibreve or 16
semi-quavers.
The project will deal with one octave of a major scale including both tonic notes – the
eight note pitches which constitute the scale (the degrees of the scale) can thus be
represented simply by the numbers 0 to 7.
2.2.2 Population
It was considered simplest to use a population of fixed size. Since a generational GA
progresses more quickly and so saves on computer time, this approach was considered
most appropriate for the present project.
2.2.3 Operators
The two operators which must be considered are those for crossover and mutation.
2.2.3.1 Crossover
It was decided to use chunk crossover with constant chunk size, as it was felt that this
would encourage more variety in the chromosomes than would simple crossover using
fixed cross points. A bar P in the first parent tune is chosen at random (providing it is not
too close to the end of the tune) and bars from the beginning of the first parent tune until
the bar before P are copied to the child. A bar Q in the second parent tune is chosen at
random, and a chunk of bars of the aforementioned constant size from Q onwards is
copied from the second parent tune into bars P onwards of the child. From the child tune's
next bar until the end of the tune, bars are copied from the corresponding positions in the
first tune:
-27-
Gavin Pennycook MSc Information Technology (Systems)
Say P = 2 and Q = 4, with a chunk size of 3
Fig. 6 Chunk Crossover
2.2.3.2 Mutation
A two level mutation system will be used: 2 mutation rate constants, numbers between 0
and 1, will be used as probabilities for mutation.
First of all, it will be determined whether to allow mutation in this generation by
generating a random number between 0 and 1 and comparing this random number to the
first mutation rate constant m. If the random number is greater than m, mutation will be
permitted in this generation. m is thus the probability of any mutation being allowed in a
given generation.
If mutation is to be allowed in the generation, then for each tune we generate a second
random number and compare this to a second mutation rate constant n. If the random
number is greater than n, we will mutate the tune by removing one of its bars (chosen at
random) and replacing this with another bar, newly created and randomly filled with notes.
n is thus the probability of mutation for any tune within a generation where mutation is
allowed.
It can be shown simply that the probability of mutation for a tune in the GA can be
calculated by multiplying these two mutation rates together (m*n).
X0 X1 X2 X3 X4 X5 X6 X7 Y0 Y1 Y2 Y3 Y4 Y5 Y6 Y7
X0 X1 Y4 Y5 Y6 X5 X6 X7
-28-
Gavin Pennycook MSc Information Technology (Systems)
2.2.4 Evaluation
The use of human versus automated fitness functions was discussed earlier. It was decided
for this project to use an automated function – this would of course be more difficult to
code, but would mean that the program could proceed more independently. The fitness
function would be a weighted sum of many distinct characteristics of a tune. It was
decided to include the following parameters:
1. Number and size of unwanted pitch transitions. To discourage the melody from
leaping around too much in pitch, all transitions between notes of more than a
constant number of tones are penalised by a number proportional to the size of
the transition minus this constant number.
2. Number of consecutive length pairs – the number of consecutive pairs of notes
of identical length in the tune. Milkie and Chestnutt [2001] included this
parameter and suggested that the melody would flow better if there were more
such pairs.
3. Number of notes beginning at certain points in the bar. Papadopoulos &
Wiggins[1998] rewarded notes which begin on points which would normally be
emphasised, for instance the beginning of each half bar. With a 4 4 melody, the
half bars begin at beats 1 and 3. This project extends this idea to reward notes
which begin at each quarter bar and each eighth bar also. This encourages
consistency of rhythm.
4. Length of final note. Shamblen[1999] pointed out that melodies sound better
when they end on a long note. This seems to resolve the melody better.
5. Pitch status of final note. Shamblen [1999] also reasoned that melodies which
end on the tonic note resolve more satisfactorily than those which do not. Our
fitness function will reward the former.
-29-
Gavin Pennycook MSc Information Technology (Systems)
6. Pitch status of first note. The first chord of a tune is generally the tonic triad, so
it seems to make sense to reward first note pitches which are member pitches of
this chord ie the first, third and fifth notes of the scale.
7. Average note length – a number of the parameters introduced above are likely
to encourage a large density of notes (eg. Number of notes beginning at certain
points in the bar, number of consecutive length pairs). It was reasoned that this
fact might lead to the melodies being difficult to listen to – seeming too
cluttered with notes. If we reward long notes, then we should be able to redress
this balance. This parameter may also be useful for giving us an idea of the
speed of a piece of music. Speed can be considered proportional to note
density, and note density is proportional to the inverse of average note length,
given constant tune length in notes.
It is clear that the above parameters are not completely independent of each other. For
example, if the average note length is greater than 1, this obviously sets an upper limit on
the possible values for the number of consecutive length pairs. This number cannot in this
case be greater than the number of notes in the tune divided by (average note length minus
1).
There were many other candidates for inclusion in the list of fitness parameters – for
example, Yu [1996] rewarded notes of certain pitches whenever they occurred in the tune,
and Shamblen [1999] gave extra points to bars with similar rhythms, in an attempt to
encourage repetition. However, it was decided that coding functions to implement the
above nine parameters would represent a sufficient initial challenge.
2.2.5 Selection
It was considered that roulette wheel selection would drain too much computation time,
requiring as it does the calculation of the fitness of each individual proportional to the
mean fitness of the population, so it was decided to operate using other selection methods:
-30-
Gavin Pennycook MSc Information Technology (Systems)
• To select the parent tunes for crossover, tournament selection is used (see earlier). This
method has the advantages of encouraging more diversity than would roulette-wheel
selection and guaranteeing that the individual of lowest fitness in the population simply
will not be selected.
• To select the chromosomes from the temporary pool for inclusion in the next
generation's population, a method combining features of rank selection and roulette
wheel selection is used – the fitness of each chromosome is multiplied by a random
number to give a rank score, and the rank is simply the order of these rank scores. The
chromosomes with highest rank are selected, so a tune’s probability of survival is
proportional to its fitness, but no single tune is absolutely certain to survive to the next
generation. This again encourages more diversity and involves less computation than
simple roulette-wheel selection, and is easier to code than standard rank selection.
-31-
Gavin Pennycook MSc Information Technology (Systems)
2.3 The Overall Algorithm Fig. 7 describes the exact algorithm used
-32-
Gavin Pennycook MSc Information Technology (Systems)
Fig. 7 Genetic Algorithm for Music Composition
Initialise population – create array of tunes by filling them with bars generated at random
Evaluate – for each tune in population, calculate fitness.
Is generation number stillwithin range?
Yes
No
Finish
Is this first generation?
Yes
Create new population - select tunes from previous
generation’s combined array using rank selection
Select some fraction of the tunes from current population, using
tournament selection
Generate child tunes - cross over pairs of these tunes using chunk crossover
If there is to be mutation in this generation, mutate some fraction of the tunes by
replacing one of the bars in each one with a new bar generated at random
Evaluate all child tunes
Add all child tunes to population, creating temporary pool or combined
array
No
Increase generation number by 1
-33-
Gavin Pennycook MSc Information Technology (Systems)
2.4 Implementation
The programming language chosen was Java, because its object-oriented properties (in
particular encapsulation and aggregation) promised to provide elegant coding of the
various evolutionary entities which needed to be described, because of its platform
independence – useful if the project is to be further explored by another student, and
because expertise in this language is a skill much in demand in today’s IT job market. The
program was coded on Linux machines using Java version 2.0, Java Development Kit
version 1.2.2.
Java classes were used to represent bars, tunes, populations and the GA itself. The
relationships between these classes constitute a hierarchy of aggregations, as shown in fig.
8. An aggregation describes the relationship when an object of one class contains a
reference to an object of another class, and the objects’ lifetimes are not tied. For example,
an object representing population contains references to many objects representing tunes,
but although the population object is destroyed when the new generation’s population is
created, the tunes may survive.
-34-
Gavin Pennycook MSc Information Technology (Systems)
Fig. 8 UML class diagram for the program
GA
genNo meanFit[ ] stanDev[ ] popArray[ ] :
rankTunes( ) sortTunesRank( ) :
Pop
pCombinedArray[ ] pTuneArray[ ] pXedTunes[ ] :
combineArrays( ) pMut( ) xOver( ) :
Bar
notesInBar noteLength[ ] notePitch[ ] transition[ ] :
bFirstNoteStatus( ) bFinalNoteStatus( ) bFinalNoteLength( ) :
Tune
barArray[ ] rank :
tMut() xOver() evaluate() averageNoteLength( ) tFirstNoteStatus( ) tFinalNoteStatus( ) tFinalNoteLength( ) :
make up contains
make up
contains
contains
make up
TUNE_LENGTH
MAX_NO_GENERATIONS
POP_SIZE
-35-
Gavin Pennycook MSc Information Technology (Systems)
2.4.1 The class Bar
The most important fields in the class Bar are the integer arrays noteLength, notePitch and
transition. These arrays allow us to describe conveniently and completely a bar in terms of
its constituent notes, their pitch and duration, and the pitch differences between successive
notes. The important methods, aside from the constructor, are those which will help us to
calculate the values of the fitness parameters for a tune, for example
bFirstNoteStatus( ) and bNotesBegin ( ).
It was decided that the length of every note in a bar would be equal to 1 or some power
notePower (generated at random within a certain range) of 2 multiplied by a constant
called NOTE_UNIT, here fixed throughout all trials to 2. This meant that our possible note
lengths were 1, 2, 4, 8 and 16 semi-quavers. However, this approach had to be modified
when looking at the notes where the notePower generated corresponded to a noteLength
which would be too great and would extend the note beyond the end of the bar. To
legislate for this, extra code was written which looked at the number of semi-quavers left
in the bar and determined how to divide it into noteLengths which were powers of 2.
2.4.2 The class Tune
A Tune object contains an array of bars, and functions for mutation, crossover and
evaluation. The Tune methods for fitness parameter evaluation tend to be derived from the
equivalent methods in the constituent Bar objects, for example the tNotesBegin( ) method
in Tune simply sums the values returned by the bNotesBegin( ) methods from all the Bar
objects representing bars in the tune. However, for some of the fitness parameters, we have
to examine the boundaries between bars also, for example tLengthPairs( ), which returns
the number of pairs of consecutive notes of the same length, is not only a sum of all the
values returned by bLengthPairs( ), but must also include those pairs of notes of
consecutive length which contain the first note of one bar and the last note of the preceding
bar.
Also worth mentioning is the treatment of the parameter which penalised unwanted pitch
transitions between consecutive notes. If we subtracted fitness points from tunes which had
-36-
Gavin Pennycook MSc Information Technology (Systems)
unwanted transitions, we could end up with tunes with negative overall fitness functions.
This would lead to complications when it came to selection for survival into the next
generation, because the rank score assigned to each tune is equal to its fitness multiplied
by a random number between 0 and 1. If a tune’s fitness was negative, then it could not
possibly end up with a positive rank score, and so would have no chance of being selected
if competing against other tunes with positive fitness. This violates our intention that every
tune should have a chance, however slim, of being selected for the next generation.
With this in mind, it was decided to use two methods to deal with the transition score. The
first, tTransitionPen( ), recommends how much we should penalise a tune by if it includes
unwanted transitions, and the second, tTransitionScore( ), subtracts the value returned by
tTransitionPen( ) from some constant value. We use the value returned by
tTransitionScore( ) as our fitness parameter value, and set a lower limit of zero on it. This
solves the problem, because it means that tune fitness can never be negative.
2.4.3 The class Pop
A Pop object represents a population and has as its fields arrays of the tunes which are
fully-fledged members of the population, the crossed over tunes, and the combined pool of
all tunes. The most important methods are the constructors (one for creating the initial
population, another for updating by selecting certain tunes from the previous generation’s
population) those for crossover, mutation and combining the arrays of tunes.
2.4.4 The class GA
GA is our public class; there is only one GA object in the program. Its significant fields are
the generation number, and the arrays containing the population, standard deviation and
mean fitness for each generation, which allow us to trace the performance of the GA. The
most important methods are those for ranking the tunes and sorting them according to their
rank.
Also important in the GA class are the constants, which enable us to change values for the
important parameters from one trial to the next.
-37-
Gavin Pennycook MSc Information Technology (Systems)
2.5 Validation
Validation is the process of ensuring that the software is traceable to user requirements –
“are we building the right product?”. The results presented later in this report indicate that
the requirements have been fulfilled satisfactorily.
2.6 Verification The paragraphs below describe some attempts to confirm that we were “building the
product right”
2.6.1 Module Testing
Separate main programs were written to investigate the performance of the classes Bar,
Tune and Pop, as well as the public class GA, exploiting Java’s property of
encapsulation. Loops and if statements were tested individually using different categories
of input, then the various methods of each class were tested in a similar fashion. Display
functions for the classes Bar, Tune and Pop were used to print data to the screen and
“System.out.println” (print) statements were used at strategic points throughout the code to
check that it was functioning as required.
2.6.2 Bar Store Array
When the program was in an early stage of development, to facilitate easier tracking of the
bars within the population, some constant number of bars were initially created and used to
fill a bar store array, a field of the GA object. No bars were created after this point, which
meant that the bar store array held all the bars which would be used in the GA. The GA
proceeded exactly as the final version would proceed later, except that the mutation
method swapped a bar in a tune with one chosen at random from the bar store array,
instead of one newly created at random. Each bar was defined uniquely by an index in the
bar store array, and this meant that we could see more easily the distribution of bars in
tunes and populations in general. Checking that the methods of the various classes were
performing as required was thus made significantly easier. It was reasoned, however, that
-38-
Gavin Pennycook MSc Information Technology (Systems)
use of such a bar store array would lead to too little diversity in the population to merit its
inclusion in the final version of the program
2.6.3 Cross-checking for Errors
Where possible, if a calculation in the program could be performed equally well in another
way, the second way was attempted as well. This meant that the two results could be
compared – if they disagreed, there was obviously a problem and the code would have to
be looked at more thoroughly.
2.6.4 Errors Checklist
A checklist of likely errors was drawn up, two major candidates being the inclusion of '='
(assignment) instead of '= = ' (test) in an if condition, and the failure to terminate all loops.
2.6.5 Structural Testing
Structural testing was employed - trying to examine all the possible paths through the
program. While it would be impossible to test every possible combination of paths, it was
attempted to ensure that every path was traversed at least once.
2.7 Interfacing with Sound A considerable amount of time was spent on attempts to interface the music data produced
by the program with Java classes and packages, notably jMusic [Sorensen & Brown] and
JavaMidi [Marsanyi], which would have allowed the melodies produced by the program to
be played. However, this proved problematic because of these packages using previous
versions of Java with now deprecated methods, because of the lack of appropriate plug-ins
available, lack of expertise about Java CLASSPATHs for Windows, and shortage of
available hard disk storage quota. Unfortunately, no suitable Java classes were available in
the standard Application Programming Interface (API) from Sun.
-39-
Gavin Pennycook MSc Information Technology (Systems)
2.8 Graph Plotting Software An effort was made to download existing Java packages for graph drawing from the world
wide web, for example Playfair.Plot [Princeton University]. However, problems were
encountered similar to those faced when attempting to interface the program to classes for
playing music, most significantly the problem of previous versions of Java and deprecated
classes. Somewhat surprisingly and frustratingly, the standard Java API, despite containing
an extensive Graphical User Interface, contains no methods for plotting graphs. After a
comprehensive and fruitless search, it was decided to plot the graphs with Microsoft Excel.
This proved time-consuming, especially at first as the application was unfamiliar to me,
but produced clear plots.
-40-
Gavin Pennycook MSc Information Technology (Systems)
CHAPTER 3 - EXPERIMENTAL DESIGN AND RESULTS This chapter details the experimental investigation into the performance of the GA.
-41-
Gavin Pennycook MSc Information Technology (Systems)
3.1 Experimental Design Before conducting the experiment, thought was given to the choice of initial values for
some of the program constants.
3.1.1 Choosing Initial Fitness Function Weights
Our overall fitness function has to be a weighted sum of all the parameters listed above.
Because of our lack of knowledge about the relative importance of these parameters, it
seems reasonable first to normalise the product (parameter weight * parameter value) for
each parameter, ie to set this equal to a constant value. This was done by running the
program for only one generation with a large population size (1000) and calculating the
values for all the parameters. A normalisation constant was assigned arbitrarily to the
number 100 and each parameter weight was then set equal to (normalisation constant /
parameter value) for each parameter value.
3.1.2 Choosing Initial Population Size
An initial population size of 100 was chosen: this was a compromise between the large
population size desirable for effective operation of the algorithm on one hand [Holland,
1975] and the practical need to keep computational time for each trial short on the other.
3.1.3 Choosing Initial Mutation Rate
The literature suggests that a mutation rate of 0.01 might be a good starting point. It was
decided to code this as m = 1, n = 0.01 (m*n = 0.01) – mutation would be allowed in every
generation, and the probability of a tune in any generation being mutated would be 0.01.
3.1.4 Choosing Total Number of Generations
It was found on several preliminary trials that the mean fitness of the tunes in the
population did not improve after the first 100 generations, so it was decided to plot data
over the first 100 generations only.
-42-
Gavin Pennycook MSc Information Technology (Systems)
3.2 Investigating Effect of Varying Fitness Function Weights
It was decided to vary these weights, one by one, by a constant fraction (10%), both
upwards and downwards, while keeping all the other weights constant. It was hoped that
this might shed some light on the relative importance of each of the fitness function
parameters as the algorithm developed over the generations.
3.2.1 Plot of Mean Fitness
First of all, mean fitness was plotted against generation number for the first 100
generations.
-43-
Gavin Pennycook MSc Information Technology (Systems)
3.2.1.1 Results Fig. 9 Varying AVERAGE_LENGTH_WEIGHT
Varying AVERAGE_LENGTH_WEIGHT
0
500
1000
1500
2000
2500
0 20 40 60 80 100generation number
mea
n f
itn
ess
normalised*0.9 normalised normalised*1.1
Fig. 10 Varying CONSECUTIVE_LENGTH_WEIGHT
Varying CONSECUTIVE_LENGTH_WEIGHT
0
500
1000
1500
2000
2500
0 20 40 60 80 100
generation number
mea
n f
itn
ess
normalised*0.9 original normalised*1.1
-44-
Gavin Pennycook MSc Information Technology (Systems)
Varying FINAL_PITCH_WEIGHT
0
500
1000
1500
2000
2500
0 20 40 60 80 100
generation number
mea
n f
itn
ess
normalised * 0.9 normalised normalised*1.1
Fig. 11 Varying FINAL_PITCH_WEIGHT
Varying FIRST_PITCH_WEIGHT
0
500
1000
1500
2000
2500
0 20 40 60 80 100
generationNo
mea
n f
itn
ess
normalised*0.9 normalised normalised*1.1
Fig. 12 Varying FIRST_PITCH_WEIGHT
-45-
Gavin Pennycook MSc Information Technology (Systems)
Varying FINAL_LENGTH_WEIGHT
0
500
1000
1500
2000
2500
0 20 40 60 80 100
generation number
mea
nF
itn
ess
normalised*0.9 normalised normalised*1.1
Fig. 13 Varying FINAL_LENGTH_WEIGHT
Varying NOTES_BEGIN_WEIGHT_1
0
500
1000
1500
2000
2500
0 20 40 60 80 100
generation number
mea
n f
itn
ess
normalised*0.9 normalised normalised*1.1
Fig. 14 Varying NOTES_BEGIN_WEIGHT_1
-46-
Gavin Pennycook MSc Information Technology (Systems)
Varying NOTES_BEGIN_WEIGHT_2
0
500
1000
1500
2000
2500
0 20 40 60 80 100
generation number
mea
n f
itn
ess
normalised*0.9 normalised normalised*1.1
Fig. 15 Varying NOTES_BEGIN_WEIGHT_2
Varying NOTES_BEGIN_WEIGHT_4
0
500
1000
1500
2000
2500
0 20 40 60 80 100
generation number
mea
n f
itn
ess
normalised*0.9 normalised normalised*1.1
Fig. 16 Varying NOTES_BEGIN_WEIGHT_4
-47-
Gavin Pennycook MSc Information Technology (Systems)
Varying TRANSITION_WEIGHT
0
500
1000
1500
2000
2500
0 20 40 60 80 100generation number
mea
n f
itn
ess
normalised*0.9 normalised normalised*1.1
Fig. 17 Varying TRANSITION_WEIGHT Fig. 18 Comparing Mean Fitness using Different Weights
Comparing Performance of GA using Different Weights
0
500
1000
1500
2000
2500
normalised combinedl finalpitch finallength finallength notesbegin notesbegin notesbegin transition averagele
mea
n f
itn
ess
afte
r 10
0 g
ener
atio
ns
normalised decreased weights increased weights
-48-
Gavin Pennycook MSc Information Technology (Systems)
3.2.1.1 Discussion of these Results
A GA population can be easily described by the mean fitness of its hypotheses. All the
traces for mean fitness against generation number (figs. 9 to 17) show typical GA
behaviour ie a steep increase in mean fitness over the first few generations, gradually
reducing to a gentler and gentler gradient until becoming roughly flat. This is an indication
that our program is functioning as required. The algorithm quickly weeds out the poor
individuals from the initial population and creates improved ones through crossover and
mutation, but inevitably cannot continue at this rate as the population becomes
progressively fitter.
One might naively expect that the traces for the higher weight values would continue to
outperform the others at greater generation numbers, but this is not generally the case , as
we can see from fig. 18. In fact, the normalised weight combination performs better than
all combinations with increased weights except those for final length weight and transition
weight. Of course, as discussed earlier, the fitness parameters are not all independent of
each other; when this is taken into account, it is clear that they must interact in a complex
way to evolve the population, and that the trials using the higher weight values will not
necessarily outperform the others.
-49-
Gavin Pennycook MSc Information Technology (Systems)
3.2.2 Plot of Maximum and Minimum Fitnesses and Standard Deviation
It was reasoned that more could be gleaned about the tunes in a population by plotting the
maximum and minimum fitnesses and standard deviation of the fitnesses for each
generation against the generation number. This was again attempted for the same
combinations of weights as above, and the traces for each combination plotted on the same
graph along with mean fitness again.
-50-
Gavin Pennycook MSc Information Technology (Systems)
3.2.2.1 Results
GA with normalised weight values
0
500
1000
1500
2000
2500
0 20 40 60 80 100Generation Number
Fit
nes
s
meanFitness maxFitness minFitness Standard Deviation
Fig. 19 GA with normalised weight values
-51-
Gavin Pennycook MSc Information Technology (Systems)
AVERAGE_LENGTH_WEIGHT = normalised value * 1.1
0
500
1000
1500
2000
2500
0 20 40 60 80 100
Generation Number
Fit
nes
s
meanFitness maxFitness minFitness Standard Deviation
Fig. 20 Increasing AVERAGE_LENGTH_WEIGHT
AVERAGE_LENGTH_WEIGHT = normalised value * 0.9
0
500
1000
1500
2000
2500
0 20 40 60 80 100Generation Number
Fit
nes
s
meanFitness maxFitness minFitness Standard Deviation
Fig. 21 Decreasing AVERAGE_LENGTH_WEIGHT
-52-
Gavin Pennycook MSc Information Technology (Systems)
CONSECUTIVE_LENGTHS_WEIGHT = normalised value * 1.1
0
500
1000
1500
2000
2500
0 20 40 60 80 100Generation Number
Fit
nes
s
meanFitness maxFitness minFitness Standard Deviation
Fig. 22 Increasing CONSECUTIVE_LENGTHS_WEIGHT
CONSECUTIVE_LENGTHS_WEIGHT = normalised value * 0.9
0
500
1000
1500
2000
2500
0 20 40 60 80 100Generation Number
Fit
nes
s
meanFitness maxFitness minFitness Standard Deviation
Fig. 23 Decreasing CONSECUTIVE_LENGTHS_WEIGHT
-53-
Gavin Pennycook MSc Information Technology (Systems)
FINAL_PITCH_WEIGHT = normalised value * 1.1
0
500
1000
1500
2000
2500
0 20 40 60 80 100Generation Number
Fit
nes
s
meanFitness maxFitness minFitness Standard Deviation
Fig. 24 Increasing FINAL_PITCH_WEIGHT
FINAL_PITCH_WEIGHT = normalised value * 0.9
0
500
1000
1500
2000
2500
0 20 40 60 80 100
Generation Number
Fit
nes
s
meanFitness maxFitness minFitness Standard Deviation
Fig. 25 Decreasing FINAL_PITCH_WEIGHT
-54-
Gavin Pennycook MSc Information Technology (Systems)
FINAL_LENGTH_WEIGHT = normalised value * 1.1
0
500
1000
1500
2000
0 20 40 60 80 100
Generation Number
Fit
nes
s
meanFitness maxFitness minFitness Standard Deviation
Fig. 26 Increasing FINAL_LENGTH_WEIGHT
FINAL_LENGTH_WEIGHT = normalised value * 0.9
0
500
1000
1500
2000
2500
0 20 40 60 80 100
Generation Number
Fit
nes
s
meanFitness maxFitness minFitness Standard Deviation
Fig. 27 Decreasing FINAL_LENGTH_WEIGHT
-55-
Gavin Pennycook MSc Information Technology (Systems)
FIRST_PITCH_WEIGHT = normalised value * 1.1
0
500
1000
1500
2000
2500
0 20 40 60 80 100
Generation Number
Fit
nes
s
meanFitness maxFitness minFitness Standard Deviation
Fig. 28 Increasing FIRST_PITCH_WEIGHT
FIRST_PITCH_WEIGHT = normalised value * 0.9
0
500
1000
1500
2000
2500
0 20 40 60 80 100Generation Number
Fit
nes
s
meanFitness maxFitness minFitness Standard Deviation
Fig. 29 Decreasing FIRST_PITCH_WEIGHT
-56-
Gavin Pennycook MSc Information Technology (Systems)
NOTES_BEGIN_WEIGHT_1 = normalised value * 1.1
0
500
1000
1500
2000
2500
0 20 40 60 80 100
Generation Number
Fit
nes
s
meanFitness maxFitness minFitness Standard Deviation
Fig. 30 Increasing NOTES_BEGIN_WEIGHT_1
NOTES_BEGIN_WEIGHT_1 = normalised value * 0.9
0
500
1000
1500
2000
2500
0 20 40 60 80 100
Generation Number
Fit
nes
s
meanFitness maxFitness minFitness Standard Deviation
Fig. 31 Decreasing NOTES_BEGIN_WEIGHT_1
-57-
Gavin Pennycook MSc Information Technology (Systems)
NOTES_BEGIN_WEIGHT_2 = normalised value * 1.1
0
500
1000
1500
2000
2500
0 20 40 60 80 100Generation Number
Fit
nes
s
meanFitness maxFitness minFitness Standard Deviation
Fig. 32 Increasing NOTES_BEGIN_WEIGHT_2
NOTES_BEGIN_WEIGHT_2 = normalised value * 0.9
0
500
1000
1500
2000
0 20 40 60 80 100Generation Number
Fit
nes
s
meanFitness maxFitness minFitness Standard Deviation
Fig. 33 Decreasing NOTES_BEGIN_WEIGHT_2
-58-
Gavin Pennycook MSc Information Technology (Systems)
NOTES_BEGIN_WEIGHT_4 = normalised value * 1.1
0
500
1000
1500
2000
0 20 40 60 80 100
Generation Number
Fit
nes
s
meanFitness maxFitness minFitness Standard Deviation
Fig. 34 Increasing NOTES_BEGIN_WEIGHT_4
NOTES_BEGIN_WEIGHT_4 = normalised value * 0.9
0
500
1000
1500
2000
2500
0 20 40 60 80 100
Generation Number
Fit
nes
s
meanFitness maxFitness minFitness Standard Deviation
Fig. 35 Decreasing NOTES_BEGIN_WEIGHT_4
-59-
Gavin Pennycook MSc Information Technology (Systems)
TRANSITION_WEIGHT = normalised value * 1.1
0
500
1000
1500
2000
2500
0 20 40 60 80 100Generation Number
Fit
nes
s
meanFitness maxFitness minFitness Standard Deviation
Fig. 36 Increasing TRANSITION_WEIGHT
GA with TRANSITION_WEIGHT = normalised value * 0.9
0
500
1000
1500
2000
2500
0 20 40 60 80 100Generation Number
Fit
nes
s
meanFitness maxFitness minFitness Standard Deviation
Fig. 37 Decreasing TRANSITION_WEIGHT
-60-
Gavin Pennycook MSc Information Technology (Systems)
Com paring Perform ance of GA using D ifferent W eights
0
500
1000
1500
2000
2500
norm
alise
d
com
bined
lengt
h
finalp
itch
finall
engt
h
finall
engt
h
note
sbeg
in1
note
sbeg
in2
note
sbeg
in4
trans
ition
aver
agele
ngth
min
imu
m f
itn
ess
afte
r 10
0 g
ener
atio
ns
norm alised decreased weights increased weights
Fig. 38 Comparing Minimum Fitness using Different Weights
C om p aring Perform ance of G A us in g D ifferent W eig hts
0
500
1000
1500
2000
2500
norm
alise
d
com
bined
lengt
h
finalp
itch
finall
engt
h
finall
engt
h
note
sbeg
in1
note
sbeg
in2
note
sbeg
in4
trans
ition
aver
agele
ngth
max
fit
nes
s af
ter
100
gen
erat
ion
s
norm alised decreased weights increased we ights
Fig. 39 Comparing Maximum Fitness using Different Weights
-61-
Gavin Pennycook MSc Information Technology (Systems)
3.2.2.2 Discussion of these Results
Looking at the graphs (figs. 19 to 37), we can see that although both the maximum and
minimum fitnesses for a generation follow a broadly similar curve to that for the mean
fitness, the trace for the maximum is generally less smooth than that for the mean, and the
trace for the minimum is generally much less smooth again. The standard deviation trace
displays a general downward trend.
We would expect the trace for mean fitness to be smooth – after all, any particularly large
changes in individual tune fitnesses from one generation to the next will not be so evident
after being averaged with all the smaller changes occurring in the other tunes.
We would expect the maximum curve also to be fairly smooth because, although the
purpose of the GA is to find a tune with maximised fitness, this will clearly not be
achieved at every generation. The tune of greatest fitness will have the greatest probability
of survival from one generation to the next of any of the tunes in the population – we can
assume that it survives in the vast majority of cases. When it does survive, the maximum
fitness in the new generation will only be different from that of the previous generation if a
new, still more fit individual is created by crossover. Inevitably, this will not happen at
every generation.
The minimum fitness for a generation, however, is likely to change more often and by
greater amounts than the maximum fitness. This is because the tune of minimum fitness in
a generation has a very low probability of survival into the next one. The tune of minimum
fitness in the new generation will thus have a different value. This explains the jagged
nature of the trace for minimum fitness.
The downward trend of the standard deviation trace can be explained by the fact that as
generation number and mean fitness increase, the fitness of each tune in the population
tends to draw closer to the mean.
In the majority of these graphs (eg. figs. 19, 20, 22), when the trace for maximum fitness
reaches its maximum value, it will remain at this value for the remaining generations – the
GA cannot find any solutions better than this individual. Most of these values lie in the
-62-
Gavin Pennycook MSc Information Technology (Systems)
fitness range 2000 to 2100 (fig. 39). However, the theoretical maximum possible fitness,
given by summing the maximum possible contributions from each parameter assuming
parameters to be independent of each other, was calculated to be much higher (4403.02 for
normalised weights). Parameter interdependence means that this is certainly an
overestimate. However, it should certainly be possible to produce tunes with fitnesses
higher than these trials’ apparent ceiling. Maybe we could achieve higher fitnesses if we
varied the standard GA parameters of mutation rate and population size.
-63-
Gavin Pennycook MSc Information Technology (Systems)
3.3 Investigating Effect of Varying Standard GA Parameters
By keeping all fitness parameter weights constant (set to their normalised values), we can
investigate the effect on population evolution of varying the standard GA parameters of
mutation rate and population size.
3.3.1 Varying Mutation Rates
It was decided to vary the values of the mutation rates by 40% upwards and downwards.
This value was chosen because it represented the significant change deemed necessary to
produce a noticeable effect on the results (it should be remembered that with a population
size of in the region of 100 and an overall mutation rate around 0.01, the number of tune
mutations taking place in each generation is likely to be as low as 1), but still less than a
change of 50%, which was regarded as too large.
However, it was realised that increasing the mutation rate m (which represents the
probability of any mutation being allowed in a generation) would have no effect, because
m was initially set equal to 1. If m is set greater than 1, then the program automatically
resets its value to 1 – a probability of greater than 1 is not possible. So it was decided only
to vary m downwards by 40% - using m = 1 (high) and m = 0.6 (low).
n (probability of mutation for a tune in a generation where mutation is allowed) was varied
upwards and downwards by 40% - n = .014 (high) and n = 0.006 (low).
3.3.2 Varying Population Size
Population size was varied both upwards and downwards by 10%. The reason that this
value was chosen to be lower than the corresponding one for the mutation rates was that,
unlike mutation rate, the population size is a significant feature of the GA in every trial and
at every generation – it was felt necessary merely to perturb this parameter.
The program was run with all eight possible combinations of mutation rate and population
size. (fig. 40)
-64-
Gavin Pennycook MSc Information Technology (Systems)
Fig. 40 Table Showing Different Settings of Mutation Rate and Population Size MUT_RATE_1 MUT_RATE_2 POP_SIZE 1 0.014 110 1 0.014 90 1 0.006 110 1 0.006 90 0.6 0.014 110 0.6 0.014 90 0.6 0.006 110 0.6 0.006 90
-65-
Gavin Pennycook MSc Information Technology (Systems)
3.3.3 Results
Fig. 41 MUT_RATE_1 high, MUT_RATE_2 high, POP_SIZE high
MUT_RATE_1 = 1, MUT_RATE_2 =0.014, POP_SIZE = 110
0
500
1000
1500
2000
2500
0 20 40 60 80 100
Generation Number
Fit
nes
s
meanFitness maxFitness minFitness Standard Deviation
Fig. 42 MUT_RATE_1 high, MUT_RATE_2 high, POP_SIZE low
MUT_RATE_1 = 1, MUT_RATE_2 =0.014, POP_SIZE = 90
0
500
1000
1500
2000
2500
0 20 40 60 80 100
Generation Number
Fit
nes
s
meanFitness maxFitness minFitness Standard Deviation
-66-
Gavin Pennycook MSc Information Technology (Systems)
MUT_RATE_1 = 1, MUT_RATE_2 =0.006, POP_SIZE = 110
0
500
1000
1500
2000
2500
0 20 40 60 80 100
Generation Number
Fit
nes
s
meanFitness maxFitness minFitness Standard Deviation
Fig. 43 MUT_RATE_1 high, MUT_RATE_2 low, POP_SIZE high
MUT_RATE_1 = 1, MUT_RATE_2 =0.006, POP_SIZE = 90
0
500
1000
1500
2000
2500
0 20 40 60 80 100
Generation Number
Fit
nes
s
meanFitness maxFitness minFitness Standard Deviation
Fig. 44 MUT_RATE_1 high, MUT_RATE_2 low, POP_SIZE low
-67-
Gavin Pennycook MSc Information Technology (Systems)
Fig. 45 MUT_RATE_1 low, MUT_RATE_2 high, POP_SIZE high
MUT_RATE_1 = 0.6, MUT_RATE_2 =0.014, POP_SIZE = 90
0
500
1000
1500
2000
2500
0 20 40 60 80 100
Generation Number
Fit
nes
s
meanFitness maxFitness minFitness Standard Deviation
Fig. 46 MUT_RATE_1 low, MUT_RATE_2 high, POP_SIZE low
MUT_RATE_1 = 0.6, MUT_RATE_2 =0.014, POP_SIZE = 110
0
500
1000
1500
2000
2500
0 20 40 60 80 100
Generation Number
Fit
nes
s
meanFitness maxFitness minFitness Standard Deviation
-68-
Gavin Pennycook MSc Information Technology (Systems)
Fig. 47 MUT_RATE_1 low, MUT_RATE_2 low, POP_SIZE high
MUT_RATE_1 = 0.6, MUT_RATE_2 =0.006, POP_SIZE = 90
0
500
1000
1500
2000
2500
0 20 40 60 80 100
Generation Number
Fit
nes
s
meanFitness maxFitness minFitness Standard Deviation
Fig. 48 MUT_RATE_1 low, MUT_RATE_2 low, POP_SIZE low
MUT_RATE_1 = 0.6, MUT_RATE_2 =0.006, POP_SIZE = 110
0
500
1000
1500
2000
2500
0 20 40 60 80 100Generation Number
Fit
nes
s
meanFitness maxFitness minFitness Standard Deviation
-69-
Gavin Pennycook MSc Information Technology (Systems)
Comparing Performance of GA using Different Mutation Rates and Population Sizes, normalised weights
0
500
1000
1500
2000
2500
(0.6,0.006,90) (0.6,0.006,110) (0.6,0.014,90) (0.6,0.014,110) (1.0,0.006,90) (1.0,0.006,110) (1.0,0.014,90) (1.0,0.014,110)
(MUT_RATE_1, MUT_RATE_2, POP_SIZE)
fitn
ess
afte
r 10
0 g
ener
atio
ns
mean Fitness maximum Fitness minimum Fitness
Fig. 49 Varying Mutation Rates and Population Size
-70-
Gavin Pennycook MSc Information Technology (Systems)
3.3.4 Discussion of these Results
Traces broadly similar to those observed before for mean, maximum and minimum fitness
were observed (figs. 41 to 48). Again, the maximum fitness trace tended to reach a
maximum value after several generations and then remain there for the rest of the trial. We
might expect that by increasing mutation rates and population size, we would succeed in
breaking through the ceiling, but this does not seem to have happened here. In fact, the
highest value of fitness for any trial was achieved with MUT_RATE_1 high and
MUT_RATE_2 and POP_SIZE both low (see figs. 44 and 49).
So why do we have a ceiling? The fact that standard deviation of the fitnesses is low and
the mean fitness is very close to the maximum fitness for many of these trials after 100
generations suggests that perhaps many tunes share the maximum fitness. Perhaps we can
discover more by running other trials and examining the fitnesses of every tune in the
population after 100 generations, and the composition of the tunes of maximum fitness.
-71-
Gavin Pennycook MSc Information Technology (Systems)
3.4 Examination of Tunes of Maximum Fitness
In an attempt to understand better just why maximum fitness was limited, a version of the
program was run which outputted the fitnesses of all the tunes after 1000 generations.
It was found that anything from 20% to 78% of the tunes in a population had the same
single value of fitness, and that within each population a few fitness values were shared
among all the tunes. This suggested strongly that all the tunes shared a very small number
of different bars, which were arranged in different combinations.
Next, a version of the program was run which outputted information about the maximum-
scoring tune after 100 generations.
The tunes of maximum fitness were found to display the following common features:
1. In all cases, the final bar consisted of a note of pitch equal to one of the tonic pitches
and of length 16 semi-quavers. This meant that the tune scored optimally for final note
length and pitch.
2. In all cases, the first bar began with a note of pitch equal to one of the member pitches
of the tonic triad. This meant that the tune scored optimally for first note pitch. The
first bar tended to be identical to at least one of the middle six bars in the tune.
3. The six other bars in the tune were similar in that they contained no unwanted pitch
transitions, tended to have values which represented a trade-off between the other
fitness parameters, and tended both to begin on a note which was a member of the
tonic triad and end on the tonic note. In fact, in one case, the same bar was repeated six
times; in all others, the same two bars were arranged in different permutations.
This information goes some way towards explaining why maximum tune fitness tends to
stabilise after several generations. The population evolves to contain only a limited amount
of bars which give most tunes a high fitness. Because of this, crossover and mutation will
rarely alter tune fitness significantly. When they do, it is to decrease it.
-72-
Gavin Pennycook MSc Information Technology (Systems)
3.5 Listening to the Music Produced
Some examples of the maximum- and minimum-scoring tunes in a population were played
by the author on the violin. However, none of the melodies were particularly easy on the
ear, and the maximum-scoring tunes did not seem significantly better than the minimum-
scoring ones.
-73-
Gavin Pennycook MSc Information Technology (Systems)
CHAPTER 4 - CONCLUSIONS AND POSSIBILITIES FOR FUTURE WORK This chapter rounds off the dissertation with a paragraph about the conclusions of the
project, a discussion of possibilities for future work, and a summary assessing the value of
the project in general.
4.1 Conclusions A GA for music composition has been successfully implemented. However, in its present
form, and in particular with its present fitness function, it is only successful in improving
maximum tune fitness over a small number of generations. After these generations, the
maximum fitness tends to remain fixed at values of perhaps around half of the theoretical
maximum. This was found to be due to the proliferation of a small number of bars, and in
particular to the proliferation of a single bar in each particular trial, which rendered the GA
operators of crossover and mutation largely ineffective. Adjustment of the fitness function
parameters and standard GA parameters of mutation rate and population size were not
found to lead to any marked improvement in performance; it is likely that this could only
be achieved by modifying the fitness function in a way that would discourage too many
identical bars within a tune or too many identical tunes within a population.
-74-
Gavin Pennycook MSc Information Technology (Systems)
4.2 Possibilities For Future Work
If time had allowed, existing features of the GA could have been investigated more
thoroughly, and new features could have been added and experimented with.
A priority would certainly be to interface the program to software which would allow the
music generated to be heard. It is obviously difficult to determine whether an algorithm is
producing good music without a convenient playback facility. This would help us to
determine how best to weight our existing fitness parameters, and might give us some
clearer ideas as to which parameters to add.
Attempts could be made to modify the fitness function so that it would discourage the
emergence of too many identical bars within a tune or too many identical tunes within a
population.
Each fitness parameter could be graphed separately against generation number. This would
give us a better idea of the relative importance of each to the overall fitness function. More
sophisticated methods could be developed for tracking the algorithm, for instance a
method to return the number of tunes in a population with the same fitnesses and the
number of identical bars and tunes in the population.
We could investigate new ways of weighting the existing fitness parameters in an attempt
to discover the optimal combinations of weights giving the highest fitness scores. Some
parameters could be modified in more subtle ways, for instance the threshold transition for
the parameter penalising unwanted pitch transitions could be varied. Other fitness
parameters which could be introduced include amount of repetition in patterns both of
duration and pitch, and frequencies of occurrence of particular notes in the piece.
It could be worthwhile to explore further the effect on tune fitnesses of different
combinations of population size and mutation rate constants. It would also be possible to
experiment with varying population sizes from one generation to the next and exploring
different types of operators, eg. one to reverse the order of bars in a tune. Chunk size and
-75-
Gavin Pennycook MSc Information Technology (Systems)
the number of tunes to generate by crossover could also be changed, as could the selection
and crossover methods.
The many constants present in the program mean that it could be easily modified to
investigate melodies using different time signatures, different scales, and more than one
octave.
-76-
Gavin Pennycook MSc Information Technology (Systems)
4.3 Summary It is my opinion that this project has been moderately successful. The first few weeks were
spent familiarising myself with Java, this being the first time I had used the language.
Time was also spent attempting to interface the program to music software and graph-
drawing packages as discussed above, as well as to acquainting the author with Excel. This
left a rather shorter time than had been hoped for the core project work of coding and
investigation. However, the algorithm has been implemented with a fair degree of success,
and while the music produced by the program may not be of a particularly high standard,
the results have pointed towards some interesting possibilities for further work.
-77-
Gavin Pennycook MSc Information Technology (Systems)
REFERENCES
1. Biles, J. A.
“GenJam: A Genetic Algorithm for Generating Jazz Solos”, in Proceedings of the
International Computer Music Conference, International Computer Music
Association, Aarhus, Denmark, 1994.
2. Burton, A. R. & Vladimirova, T.
"Genetic Algorithm Utilising Neural Network Fitness Evaluation for Musical
Composition", in Proceedings of the 1997 International Conference on Artificial
Neural Networks & Genetic Algorithms, pp. 220-224
3. Corne, D., Fang H-L., Mellish, C.
"Solving the Module Exam Scheduling Problem with Genetic Algorithms", in
Proceedings of the Sixth International Conference on Industrial and Engineering
Applications of Artificial Intelligence and Expert Systems, Gordon and Breach
Science Publishers, Chung, Lovegrove, Ali (eds), 1993, pp. 370-373.
4. Cope, D.
“The Composer’s Underscoring Environment: CUE”, Computer Music Journal, 21
(3), 20-37, 1997.
5. Drakos, N., Prugel-Bennett, A. & Moore, R.
"Modelling Evolving Populations", online document, University of Southampton,
1996. http://www.isis.ecs.soton.ac.uk/isystems/evolutionary/notes/evol/evol.html
6. Holland, J. H.
“Adaptation in Natural and Artificial Systems”, University of Michigan Press,
1975.
7. Horner, A. & Goldberg, D. E.
“Genetic Algorithms and Computer-Assisted Composition”, in Proceedings of the
Fourth International Conference on Genetic Algorithms”, 1991.
-78-
Gavin Pennycook MSc Information Technology (Systems)
8. Horowitz, D.
“Generating Rhythms with Genetic Algorithms”, in Proceedings of the
International Computer Music Conference, Thessaloniki, Greece, 1994.
9. Jacob, B. L.
“Composing With Genetic Algorithms”, Proceedings of the International
Computer Music Conference 1995, International Computer Music Association,
Banff, Alberta, Canada, 1995.
10. Johanson, B. & Poli, R.
"GP-Music: An Interactive Genetic Programming System for Music Generation
with Automated Fitness Raters", in Proceedings of the 3rd Annual Conference in
Genetic Programming, 1998
11. Koza, J. R.
“Genetic Programming : On the Programming of Computers by Means of Natural
Selection”, MIT Press, Cambridge, Massachusetts, USA, 1992
12. Lander, N.
“A Memento – the Medieval Recorder”,
http://members.iinet.net.au/~nickl/medieval.html
13. Loy, D. G.
“Connectionism and Musiconomy” in Todd, P. M. & Loy, D. G., eds., Music and
Connectionism, pp. 20-36, Cambridge, MA, MIT Press, 1991.
14. McIntyre, R. A.
“Bach in a Box: The Evolution of Four-Part Baroque Harmony Using the Genetic
Algorithm”, in Proceedings of the IEEE Conference on Evolutionary Computation,
1994.
15. Marsanyi, R.
-79-
Gavin Pennycook MSc Information Technology (Systems)
JavaMidi, www.softsynth.com/Javamidi/doc/Package-jmidi.html
16. Merriam-Webster
“Merriam-Webster Online Collegiate Dictionary”, 2001,
http://www.m-w.com/home.htm
17. Milkie, E. & Chestnutt, J.
“Fugue Generation with Genetic Algorithms”, online paper, Department of
Computing Science, Cornell University, USA, 2001
http://www.cs.cornell.edu/boom/2001/Milkie/Fugue%20Generation%20through%20Genetic%20Al
gorithms_files/csReport.htm
18. Mitchell, T. M.
“Machine Learning”, McGraw Hill, 1997.
19. Mozer, M. C.
“Neural network music composition by prediction: Exploring the benefits of
psychophysical constraints and multiscale processing”, Connection Science, 6, 247-
280, 1994.
20. Papadopoulos, G. & Wiggins, G.
"A Genetic Algorithm for the Generation of Jazz Melodies", Proceedings of STeP
98, Jyvaskyla, Finland, 1998
21. Papadopoulos, G. & Wiggins, G.
"AI Methods for Algorithmic Composition: A Survey, a Critical View and Future
Prospects”, AISB Symposium on Musical Creativity, Edinburgh, 1999.
22. Princeton University
“Playfair.Plot”, http://www.princeton.edu/~scimath/playfair3/doc/Playfair.Plot.html
23. Shamblen, E.
"The Music or Noise Generator: A Genetic Algorithm Approach to Music
Composition", MSc thesis, University of Georgia, 1999.
-80-
Gavin Pennycook MSc Information Technology (Systems)
www.jps.net/shamblen/pro/thesis.html
24. Spector, L. & Alpern, A.
“Induction and Recapitulation of Deep Musical Structure”, in Proceedings of the
IJCAI-95 Workshop on Artificial Intelligence and Music, 1995.
25. Sims, K.
“Genetic Images”, Centre Georges Pompidou Revue Virtuelle Notebook 5, 1993.
http://www.genarts.com/karl/genetic-images.html,
26. Sorensen, A. & Brown, A.
“jMusic”, Queensland University of Technology, Australia
http://www.academy.qut.edu.au/music/newmedia/jmusic/
27. Todd, P. M. & Werner, G. M.
"Frankensteinian Methods for Evolutionary Music Composition", in Griffith, N. &
Todd, P. M. (Eds) Musical Networks: Parallel Distributed Perception and
Performance, MIT Press/Bradford Books, Cambridge, MA, 1999
28. Tokui, N. & Iba, H.
"Music Composition with Interactive Evolutionary Computation", Department of
Information and Communication Engineering, Graduate School of Engineering,
University of Tokyo, Japan
http://www.miv.t.u-tokyo.ac.jp/~tokui/research/iec-music/
29. Towsey, M., Brown, A.,Wright, S. & Diederich, J.
"Towards Melodic Extension Using Genetic Algorithms", in Educational
Technology & Society, vol. 4 no. 2, 2001.
-81-
Gavin Pennycook MSc Information Technology (Systems)
30. Wiggins, G., Papadopoulos, G., Phon-Amnuaisuk, S. & Tuson, A.
“Evolutionary Methods for Musical Composition”, International Journal of
Computing Anticipatory Systems, 1999.
31. Yu, C.
“Computer Generated Music Composition”, BSc/MSc thesis, MIT, Cambridge,
Massachusetts, 1996, http://www.oz.net/~cyu/Thesis.html
-82-
Gavin Pennycook MSc Information Technology (Systems)
BIBLIOGRAPHY
1. Bell, D., Morrey, I. & Pugh, J.
“Software Engineering – A Programming Approach”, second edn., Prentice Hall
International, Hemel Hempstead, England, 1992.
- useful description of Software Engineering basics.
3. Darwin, C.
“The Origin of Species by Means of Natural Selection”, 6th edn., Watts/John
Murray, 1976.
- the book in which Darwin first presented the revolutionary idea of
evolution through selection and mutation.
3. Eckel, B.
“Thinking in Java”, Prentice Hall, New Jersey, 2000.
- good introductory text on Java.
-83-
Gavin Pennycook MSc Information Technology (Systems)
APPENDICES
-84-
Gavin Pennycook MSc Information Technology (Systems)
Appendix 1 Contents of CD The CD has 4 subdirectories – excelfiles, which contains all tables and graphs of data,
programcode, which contains the final main program (Gasep6MostImp) and other versions
for outputting information about the Bar and Pop classes, programoutput, containing
sample output from various versions of the program and wordfiles, which contains a copy
of this dissertation.
-85-
Gavin Pennycook MSc Information Technology (Systems)
Appendix 2 Source Code