A Genetic Algorithm for Music Composition

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-


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-


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-


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-


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-


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-


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-


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-


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-


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-


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-


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-


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-


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-


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-


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-


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-


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-


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-


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-


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-


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-


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-


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-


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-


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-


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-


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-


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


2.3 The Overall Algorithm Fig. 7 describes the exact algorithm used

-32-


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-


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-


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-


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-


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-


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-


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-


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-


CHAPTER 3 - EXPERIMENTAL DESIGN AND RESULTS This chapter details the experimental investigation into the performance of the GA.

-41-


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-


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-


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-


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


Fig. 12 Varying FIRST_PITCH_WEIGHT

-45-


Varying FINAL_LENGTH_WEIGHT

0

500

1000

1500

2000

2500

0 20 40 60 80 100

generation number

mea

nF

itn

ess


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


Fig. 14 Varying NOTES_BEGIN_WEIGHT_1

-46-



0

500

1000

1500

2000

2500

0 20 40 60 80 100

generation number

mea

n f

itn

ess




0

500

1000

1500

2000

2500

0 20 40 60 80 100

generation number

mea

n f

itn

ess



-47-


Varying TRANSITION_WEIGHT

0

500

1000

1500

2000

2500

0 20 40 60 80 100generation number

mea

n f

itn

ess


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-


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-


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-


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-


AVERAGE_LENGTH_WEIGHT = normalised value * 1.1

0

500

1000

1500

2000

2500

0 20 40 60 80 100

Generation Number

Fit

nes

s


Fig. 20 Increasing AVERAGE_LENGTH_WEIGHT

AVERAGE_LENGTH_WEIGHT = normalised value * 0.9

0

500

1000

1500

2000

2500


Fit

nes

s


Fig. 21 Decreasing AVERAGE_LENGTH_WEIGHT

-52-


CONSECUTIVE_LENGTHS_WEIGHT = normalised value * 1.1

0

500

1000

1500

2000

2500


Fit

nes

s


Fig. 22 Increasing CONSECUTIVE_LENGTHS_WEIGHT

CONSECUTIVE_LENGTHS_WEIGHT = normalised value * 0.9

0

500

1000

1500

2000

2500


Fit

nes

s


Fig. 23 Decreasing CONSECUTIVE_LENGTHS_WEIGHT

-53-


FINAL_PITCH_WEIGHT = normalised value * 1.1

0

500

1000

1500

2000

2500


Fit

nes

s


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


Fig. 25 Decreasing FINAL_PITCH_WEIGHT

-54-


FINAL_LENGTH_WEIGHT = normalised value * 1.1

0

500

1000

1500

2000

0 20 40 60 80 100

Generation Number

Fit

nes

s


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


Fig. 27 Decreasing FINAL_LENGTH_WEIGHT

-55-


FIRST_PITCH_WEIGHT = normalised value * 1.1

0

500

1000

1500

2000

2500

0 20 40 60 80 100

Generation Number

Fit

nes

s


Fig. 28 Increasing FIRST_PITCH_WEIGHT

FIRST_PITCH_WEIGHT = normalised value * 0.9

0

500

1000

1500

2000

2500


Fit

nes

s


Fig. 29 Decreasing FIRST_PITCH_WEIGHT

-56-


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


Fig. 30 Increasing NOTES_BEGIN_WEIGHT_1


0

500

1000

1500

2000

2500

0 20 40 60 80 100

Generation Number

Fit

nes

s


Fig. 31 Decreasing NOTES_BEGIN_WEIGHT_1

-57-



0

500

1000

1500

2000

2500


Fit

nes

s




0

500

1000

1500

2000


Fit

nes

s



-58-



0

500

1000

1500

2000

0 20 40 60 80 100

Generation Number

Fit

nes

s




0

500

1000

1500

2000

2500

0 20 40 60 80 100

Generation Number

Fit

nes

s



-59-


TRANSITION_WEIGHT = normalised value * 1.1

0

500

1000

1500

2000

2500


Fit

nes

s


Fig. 36 Increasing TRANSITION_WEIGHT

GA with TRANSITION_WEIGHT = normalised value * 0.9

0

500

1000

1500

2000

2500


Fit

nes

s


Fig. 37 Decreasing TRANSITION_WEIGHT

-60-


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-


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-


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-


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-


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-


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


Fig. 42 MUT_RATE_1 high, MUT_RATE_2 high, POP_SIZE low


0

500

1000

1500

2000

2500

0 20 40 60 80 100

Generation Number

Fit

nes

s


-66-



0

500

1000

1500

2000

2500

0 20 40 60 80 100

Generation Number

Fit

nes

s


Fig. 43 MUT_RATE_1 high, MUT_RATE_2 low, POP_SIZE high


0

500

1000

1500

2000

2500

0 20 40 60 80 100

Generation Number

Fit

nes

s


Fig. 44 MUT_RATE_1 high, MUT_RATE_2 low, POP_SIZE low

-67-


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


Fig. 46 MUT_RATE_1 low, MUT_RATE_2 high, POP_SIZE low


0

500

1000

1500

2000

2500

0 20 40 60 80 100

Generation Number

Fit

nes

s


-68-


Fig. 47 MUT_RATE_1 low, MUT_RATE_2 low, POP_SIZE high


0

500

1000

1500

2000

2500

0 20 40 60 80 100

Generation Number

Fit

nes

s


Fig. 48 MUT_RATE_1 low, MUT_RATE_2 low, POP_SIZE low


0

500

1000

1500

2000

2500


Fit

nes

s


-69-


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-


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-


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-


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-


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-


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-


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-


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-


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-


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-


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-


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-


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-


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-


APPENDICES

-84-


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-


Appendix 2 Source Code

Documents

A Genetic Algorithm for Music Composition