Project Interim Report

Submitted for theBSc Honours in Computer Science

October 2207

Liquid Brain Music

by

Christopher Turner

Contents

Acknowledgements 1

Abstract 2

1 Introduction 3

1.1 Project Outline . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

1.2 Aims & Objectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

2 Background Context 4

2.1 Computer Music . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

2.1.1 Synthesis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

2.1.2 Sampling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

2.2 Artificial Intelligence & ALife . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

2.2.1 Cellular Automata . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

3 Project Overview 8

3.1 Cellular Automata . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

3.1.1 Visualisation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

3.2 Audio . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

3.2.1 Sample Based . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

3.2.2 Generative . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

3.3 Implementation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

3.3.1 Programming Languages . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

3.3.2 Graphics Programming . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

3.3.3 Audio Programming . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

3.4 Pattern Matching . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

3.5 Ethical Considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

3.6 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

4 Project Management 13

4.1 Planning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

4.2 Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

5 Software Development 15

5.1 Generative Audio System . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

5.1.1 Requirements& Specification . . . . . . . . . . . . . . . . . . . . . . . . . 15

5.1.2 Software Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

5.1.3 Implementation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

5.2 Cellular Automata System . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

5.2.1 Requirements& Specification . . . . . . . . . . . . . . . . . . . . . . . . . 20

5.2.2 Software Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

5.2.3 Implementation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

5.3 Liquid Brain Music . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

5.3.1 Requirements& Specification . . . . . . . . . . . . . . . . . . . . . . . . . 24

5.3.2 Software Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

5.3.3 Implementation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

6 Testing 28

6.1 Unit Testing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

6.2 Requirement testing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

6.3 User Testing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

6.3.1 Result Evaluation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

6.3.2 Post-Test Software Changes . . . . . . . . . . . . . . . . . . . . . . . . . . 29

6.4 Experimentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

7 Critical Evaluation 31

7.1 Software Development . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

7.2 Testing Evaluation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

7.3 Additional Features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

7.4 Objectives Evaluation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32

8 Conclusion 33

8.1 Future Work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33

Appendices 34

Appendix A: Task List . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34

Appendix B: Gantt Chart . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35

Appendix C: Supervisory Meeting Minutes . . . . . . . . . . . . . . . . . . . . . . . . 36

Appendix D: Version History . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38

Appendix E: UML Diagrams . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39

Appendix F: Full Parameter List . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44

Appendix G: Test Results . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45

Appendix H: User Documentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49

Appendix I: Risk Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52

References 53

Bibliography 53

Acknowledgements

1

Abstract

This document is a final stage report for a project titled ’Liquid Brain Music’, relating tohow aspects of artificial life and electronic music can be combined to create a fully autonomousmusic machine. The purpose of this report is to document the the various stages of developmentthroughout the life of the project.

The artificial life aspect of the system builds on the theory of cellular automata, in particularlythe work carried out by Stephen Wolfram in the field of elementary cellular automata. This isresearched, designed and ultimately implemented using a combination of C++ and OpenGL.

The electronic music is produced by a software emulation of a traditional subtractive synthesizer.This is again implemented in C++ with audio functionality provided by OpenAL and theSynthesis Toolkit. These two systems are then connected using a suitable pattern matchingsystem.

2

1 Introduction

Research will first be presented to give a background context on the technologies and theoriesbehind the project. This will be followed by the details of the design and development phases,drawing on the knowledge acquired in the initial research stage.

Finally the finished product will be critically evaluated and assessed along with the progress ofthe project as a whole.

1.1 Project Outline

It is as described in the initial brief as :

TITLE: Liquid Brain MusicSUITS: GD, CS, SE, BICSYS: Prolog or C++/C#KEYS: Music, Games, AI, A-LifeRATINGS: Research: 4 Analysis: 3 Design: 3 Implementation Volume: 3 Imple-mentation Intensity: 3OUTLINE:One reason why so many computer games are boring is the repetitive nature of theassociated music samples. This project looks at using liquid brains (Cellular au-tomata updated to the twenty-first century) to control the generation and synthesisof music, from a set of samples, according to the actions of the game and player.The game could be based on the cellular automata driven “Game of Life”.

Following discussions with the project supervisor, the outline was amended to :

One reason why so many computer games are boring is the repetitive nature of theassociated music samples. This project looks at using liquid brains (Cellular au-tomata updated to the twenty-first century) to control the generation and synthesisof music, according to the actions of the game and player.

1.2 Aims & Objectives

From the new specification the two major aspects of the project are to create a system capableof generating audio and a ‘Liquid Brain’ to control it. These can further be broken down intoa number of primary objectives :

• Create an artificial life simulation• Display a visual representation of the simulation• Generate suitable measures for the simulation data• Use the measures to control aspects of the audio generator• Output the resulting audio in a suitable format• Handle any user configuration

Later in this report these objectives will be expanded upon to produce a number of tasks.

3

2 Background Context

This section documents and organises background research on any relevant aspects of the aims& objectives to obtain a general context for the rest of the project.

2.1 Computer Music

‘Computer Music’ is a term used to describe the general involvement of computers in aspectsof the music making process. This involves anything from digital signal processing and audiosynthesis to sequencing and composition. It’s a field of study dating back as early as the 1940’s,born of the composers of the time tiring of the “tonal, textural, and timbral capabilities ofacoustic instruments” (Kuehnl, 2007).

The first major breakthrough in the field came with the development of early monophonicsynthesizers in 1950. Since then, computer music has grown to become a staple element ofalmost all modern day music productions. Two particularly large fields of interest are audiosynthesis, the process of generating new sounds, and sampling, the recording and playback ofexisting sounds.

2.1.1 Synthesis

Figure 1: The four most fundamental wave forms; Sine (top left), triangle (top right), square(bottom left) and sawtooth (bottom right).

While there are many methods of audio synthesis, the most commonly used are granular syn-thesis, additive synthesis, subtractive synthesis (Manning, 1993). The first, granular synthesis,works on similar principles to sampling in that it relies on a pre-existing waveform. It takes thiswaveform and splits it up into a number of minuscule samples, each only milliseconds long, andrearranges them to create an entirely new sound. This new waveform can then be manipulatedand processed in the same way as any other audio signal.

Additive synthesis is the process of :

“... building up composite sample patterns from sinusoidal components...”(Manning,1993).

This can also be described as creating a waveform from the ground up by building up thefrequencies and harmonics that comprise a sound. This is a method particularly favoured forcreating realistic emulations of traditional instruments.

Finally there’s subtractive synthesis, which involves generating a basic oscillating waveform(see Figure 1) and passing the signal through various filters and processes to ‘subtract’ certain

4

frequencies to create a new sound (Sound On Sound, 1999). It also happens to be one of theeasiest and most common methods of synthesis, making it an ideal candidate for this project.By using this method various patterns in the cellular automata can be mapped to suitableparameters in the synthesis engine (See section 3.4).

2.1.2 Sampling

Another popular aspect of computer music is sampling. This is process of using pre-recordedportions of audio as the basis for new compositions or musical instruments. One of the firstmajor milestones in the history of the sampler came about with the Mellotron in 1950, “man-ufactured units that contained recorded (tape) loops of various rhythms... that played a tapedsound when a key was depressed” (Pinder, 2007).

In popular culture, sampling became came about with early hip-hop music, which often incorpo-rated drum tracks sampled from old vinyl records. This process was later adopted by a numberof genres including rap and dance. These days sampling plays a huge rule in music production,owed in no small part to the advances in the personal computer. Instruments and sounds nowcan be recorded onto a hard disk and processed or manipulated to create entire new sounds.

The legality and ethics of sampling is still the subject of much controversy, see section 3.5

2.2 Artificial Intelligence & ALife

2.2.1 Cellular Automata

The ‘Liquid Brain’ mentioned in the project outline actually refers to a subset of artificial intel-ligence study known as ‘Cellular Automata’. Cellular Automata at its simplest is a geometricalarrangement consisting of a number of cells. In their most basic form each cell may be in oneof two finite states, on or off. The state of a cell at time t is a function of the states of itsneighbouring cells at t − 1. This neighbourhood may include orthogonal cells, diagonal cellsand even original cell itself (Sarkar, 2000).

It may seems logical to discuss the topic from the ground up, beginning with the most basic1-dimensional arrangements. However the reality is that the some of the most seemingly simplerelements in the field of cellular automata were also the most recently discovered, as such theywill be explained towards the end of the next section in order to paint a chronologically accuratetime line.

The concept of cellular automata first arose with John Von Neumann and Stanislaw Ulam inthe 1940’s. Von Neumann had an interest the possibility of self replicating machines; robotswhich could be programmed to build copies of themselves (Wolfram, 2002).

The complexity of creating such a machine and providing it with a constant stream of spareparts of which to replicate soon became apparent to Von Neumann. Ulam, who at the time wascarrying out research in the field of crystal growth, suggested he take an abstract mathematicalapproach to the problem; leading to von Neumanns 19-state cellular automata (Levy, 1992).

The next major development came with the publication of John Conway’s ‘Game of Life’ inScientific America in the 1980s. This zero-player-game involved a grid of square cells repre-senting lifeforms, each of which could be in one of two states, dead or alive. To determine thestate of a lifeform at any time, Conway devised four simple rules (Gardner, 1970).

5

Figure 2: The two most common types of 2D neighbourhoods, von Neumann (left) and Moore(right). In each case the neighbourhood of the black cell is displayed in grey.

• Alive cells with 0 or 1 neighbours die of loneliness• Alive cells with 2 or 3 neighbours survives to the next generation• Alive cells with 4 or more neighbours dies of overpopulation• Dead cells with 3 neighbours come alive

(Callahan, 1971)

Note that a neighbour in this instance refers to any cell that falls into a Moore neighbourhood(see Figure 2).

Figure 3: 6 generations of a simple evolving pattern in Conway’s Game of Life.

These rules are applied to every cell of the initial grid and the result becomes the next generationof life. After a time we see the appearance of unexpected and sometimes complex patterns ofcells behaving as though preprogrammed, a phenomenon known as emergence. This can rangefrom simple evolving patterns to entire self replicating collectives (see Figure 3).

Further interest in cellular automata came about with a series publications in the early 1980sby British mathematician Stephen Wolfram, detailing what are known as the 226 elementarycellular automata, so called because they’re the simplest form of cellular automata operating on1 dimension with only 2 states. To run such an automata, only a set of initial cells and simple8-bit binary rule were needed (Wolfram, 2002).

Figure 4: A Rule 90 (01011010) cellular automata at steps 1, 5 & 10.

With elementary cellular automata the new state of a cell can be determined by its current

6

state along with the state of its two neighbours. This totals 2 × 2 × 2 = 8 possible outcomesfor any one cell, which can also be thought of as statescells = 23 where states represents thenumber of possible states and cells represents the number of cells in the neighbourhood. Assuch, every possible outcome for these 8 combinations can be mapped onto a single byte, leadingto a possible 226 rules. These mappings, or rules, are usually described in terms of their binaryor decimal representations (see Figure 4).

Cellular automata need not be restricted to only 2 states however. So long as there are rules inplace to define them, there are no limits to the number of possible states that can be used, beit 2 or 220. When dealing with multiple states, a special class of cellular automata known astotalistic can be used to reduce the number of rule definitions. It can be described as :

“A cellular automata in which the rules depend only on the total (or equivalently,the average) of the values of the cells in a neighbourhood.” (Wolfram, 2002)

For example, take a cellular automata with 3 states - 1, 2 & 3. The state of a cell with aneighbourhood of 2-2-2 may be the same as one with 3-1-2 since the sum of states is identical inboth cases, despite the arrangement. In these cases there are only states×cells−2 = 3×3−2 = 7possible cell combinations to consider as opposed to the 33 = 27 possibilities a regular elementarycellular automata would produce.

7

3 Project Overview

3.1 Cellular Automata

3.1.1 Visualisation

To give the user an insight into how the cellular automata is controlling the generation of sound,it will be useful to provide a visual representation of the cells and their states as they evolve.Cellular automata are most often displayed as a geometrical grid of square cells (See figures 2,3 & 4), where the colour of a cell depends on its current state. For a 1-dimensional cellularautomata, the visualisation should begin with only a single row of cells. For each evolution ofthe automata, the updated cells should be displayed below their parent cells, creating a growingwall of cells along a single dimension, representative of time (See figure 4).

For a 2-dimensional automata such as Game of Life, the common solution is to display thecells on a 2-dimensional grid (See figure 4). This only allows user to see the current state ofthe automata however, whereas the 1-dimensional visualisation offers a perspective of the entireevolutionary process.

One final thought is a command line interface, which while not being the most aesthetic form ofvisual feedback is worth mentioning if just as safety net should any unforeseeable problems arise(see Appendix A: Risk Analysis) with other visualization techniques. Despite this, a textualCLI is more than capable of representing cellular automata in ASCII characters.

3.2 Audio

There are two methods to be considered in generating audio for this project, the first is tomanipulate external sound files and the other is to synthesize an audio signal from scratch.Both have their advantages and disadvantages.

• With a sample based system the output is limited by the sample files used, whereas withan entirely generative system the only limit is the complexity of the synthesis engine.

• This can be a double-edged sword though, as the synthesis engine may turn out to bevery primitive and incapable of producing the kind of a elaborate sounds a sample basedsystem may otherwise achieve.

• Updates to the synthesizer engine would require recoding and recompiling each time,whereas samples can simply be replaced at will.

• Unless the audio input is processed beyond recognition, the user will already have at leastsome idea of what to expect when using their own samples. A good generative systemwould be able to produce completely new sounds every time.

• Coding a cellular automata driven synthesizer is likely to be more difficult than a samplebased counterpart as the program will need to create and manipulate sounds completelyfrom the ground up.

• Using a generative system the program will be completely self contained and will have noexternal dependencies (other than DLLs). Using samples would first require the user tocreate or record the sounds in another application.

• Both generative and sample based solutions have their own ethical and legal considera-tions, which are discussed further in section 3.5.

8

3.2.1 Sample Based

One method of using cellular automata to create music explored by Stephen Wolfram has beenimplemented in the form of Wolfram Tones. The idea behind it is to use a 1D automata tippedon its side so that time is represented across a horizontal plane in the fashion of a traditionalmusical score. At its most basic, Wolfram describes it’s operation as:

“To take every block of contiguous black cells at a certain height, and map it to asingle note played by the same instrument.”(Wolfram, 2005)

The implementation on his website shows a much more advanced system using multiple instru-ments but the underlying rules behind it are exactly the same.

In this particular case the automata only provides information on which note or instrument toplay and is more focused on producing melodically pleasing music than manipulating the soundsat a lower level. As such, all other aspects of the sound are predetermined by the instrumentsand samples provided, which brings us to the second method.

3.2.2 Generative

Wolfram also offered a possible generative solution in his book, involving the use of an entireautomata itself as raw binary PCM data. However due to the nature of most cellular automatathe diversity of the cell data means a similar diversity of audio frequencies, often resulting inan unpleasant white noise.

A compromise between the two previously mentioned methods would be to generate audiowith a traditional sound synthesizer, having its parameters controlled by the state of a cellularautomata. This will allow for a richer sound pool than a sample based system whilst overcomingthe problems of using the states as raw audio data.

3.3 Implementation

3.3.1 Programming Languages

It would be possible to implement this project in a huge number of programming languages, aselect few have been researched and their suitability analysed for the purpose of this report.

The first candidate is Prolog, a logic programming language which especially favoured for ar-tificial intelligence applications. This makes it ideal for the cellular automata portion of theproject, however with the language being purely logic driven it would be extremely difficult ifnot impossible to program a functioning audio generator.

C++ and C# are two alternatives, both capable of implementing the project in its entiretyincluding the audio generator. The two languages are extremely similar from a syntactical pointof view, but both hold their own individual strengths and weaknesses. C# has the advantage ofautomatic memory management and safer coding conventions, however an application relyingon the .NET framework would be inherently and perhaps noticeably slower than the nativebinary from a C++ compiler.

9

3.3.2 Graphics Programming

To display the state of the automata graphically there are a 3 options I will consider, they areDirectX, OpenGL and WinAPI.

Both DirectX and OpenGL are professional high level API designed for rendering graphics.While they both perform the same tasks, there are some key differences between the two.

• DirectX is a proprietary API created by Microsoft and designed solely for use on MicrosoftWindows based operating systems. This is in contrast with OpenGL which is both opensource and cross platform.

• Though DirectX can be used to create 2D graphics it’s primary focus is 3D rendering,whereas OpenGL is designed with both in mind.

• OpenGL is generally considered easier to program with compared to DirectX.• The OpenGL Utility Toolkit, or GLUT, can be used to abstract much of the finer details

of OpenGL.

WinAPI is used to develop standard windows-based GUIs. While it has the advantage of speedand access to native widgets and dialogues, its suitability for complex graphics is questionable.This is not to say the WinAPI couldn’t be integrated with one of the previously mentioneddedicated graphics APIs to handle user interaction. As with DirectX, the WinAPI is proprietaryand as such can only be used on Microsoft Windows based operating systems.

3.3.3 Audio Programming

Some of the technologies considered for generating, processing and streaming the audio signalsare OpenAL, STK and Csound.

OpenAL is an open source audio library that can be seen as an audio counterpart for OpenGL(see section 3.3.2). While the two APIs are developed completely independently of each other,the syntax of OpenAL is purposely designed to resemble the OpenGL model. It specialisesin real-time audio output (3D spatial sound in particular) but has no functionality specific togenerating waveforms or signal processing, as such it would require the signal to be generatedelsewhere and supplied to an OpenAL buffer (OpenAL, nd).

The Synthesis Toolkit (STK), is another open source library, specific to audio synthesis as wellas real-time playback. Developed jointly by researchers at Stanford & Princeton University itprovides C++ classes to generate and manipulate waveforms, offering much of the functionalityfound in traditional synthesizers such as envelopes, filters and effects. Base waveforms aregenerated using a wavetable for efficiency, meaning only one cycle of a wave is calculated andthen repeated to create a longer signal (Cook and Scavone, 1995).

CSound is a high level audio programming language designed for rendering sounds and process-ing signals. It takes input in the form of orchestras, containing a number of instruments and ascore, detailing how the orchestra should be played. These are usually supplied in the form ofexternal files, although an API exists to directly interface with C++. While CSound is opti-mised for audio programming, much of its synthesis content derives from STK (CSounds.com,2007).

10

Subtractive Synthesis Parameters

Parameter ValueWaveform Sine, Triangle, Square, Saw-

tooth, Noise.State On or OffFrequency 22Hz - 22kHzPanning Left to rightAttack Time durationDecay Time durationSustain Volume levelRelease Time durationFrequency Modulation Audio signalAmplitude Modulation Audio signal

Figure 5: A list of standard parameters found in most synthesizers along with their corre-sponding value types.

3.4 Pattern Matching

To drive the audio engine, data from cell states must be used to control the types of parameterslisted in Figure 5. Taking a 1-dimensional n state cellular automata, the following are somepossible patterns that can be taken from a row of cells.

• Total number of cells in any given state.• Ratio of cell states.• Percentage of cell states.• Chains of 2 adjacent cells of the same state. This could also be reused for chains 3, 4,

5, etc. Obviously the frequency of longer chains depends on the size of the automata, solarger chains may not be suitable for generating diverse values.

• Largest chain with no adjacent cells of equal states.• Number of cells where state is equal at t and t− 1.• Cells where state at t > t− 1 or t < t− 1.• Odd/Even number of cells in any given state.

A lot of these patterns will depend on having a large enough set of data to yield values preciseenough to get a varied result from the synthesizer. This is something that will be subject totesting and experimentation to find the optimal automata size. It’s also worth noting that manypatterns make use of the same data, meaning their results would be linked. For example in a 2state automata the ratio or percentage of state-0 cells would always be inverse to that of state-1cells.

3.5 Ethical Considerations

There are no major ethical considerations unique to to this project, owing partly to the factthat audio signals well be generated completely from scratch. If a sample based solution hadbeen decided upon the ethical issues surrounding the legality and artistic merit of samplingcould have been taken into consideration.

11

With generative or electronic music, it could argued by some that machine-made sounds cannotbe considered ’true’ music in an artistic sense due to the inherent mechanical nature in whichthey’re created and the lack of any human or emotional element. While that argument may holdsome ground with purely generative music, electronic synthesizers and digital signal processinghave been used for decades and are considered a staple of modern music.

There are also issues regarding the aesthetics of music and whether a piece of audio withoutfamiliar structures, scales and timbres can be considered music. A counter argument to thiscould be that this project derives output from patterns; much in the way traditional westernmusic uses patterns in its time signatures, melody and song structure. A lot of pop music takeson a simple repetitive verse-chorus pattern in 4/4 time, for example.

3.6 Summary

After researching the technologies available to design and implement this project, it has beendecided that :

• A 1-dimensional cellular automata will be used as it’s the most computationally efficient.• C++ will be used to code the program as it can provide all of the functionality required

to implement all aspects of the system and is better suited to real-time audio generationthan the alternatives.

• OpenGL will be used for graphics due to its ease of use and 2D specific functionality.• STK will be used for generating audio and OpenAL for streaming output.

12

4 Project Management

4.1 Planning

Requirements

Design

Implementation

Verification

Maintainence

Figure 6: Waterfall development model.

As with any large software development task, planning played a major role in the developmentof the project. The development model chosen for this project was the waterfall model (seeFigure 6).

The first aspect of the design stage was to break the initial aims and objectives down into anumber of tasks and subtasks. These tasks were assigned start and finish times, taking intoaccount their estimated time for completion, difficulty and any other concurrent commitmentssuch as exams and coursework. A number of milestones were then identified by analysing theproject deliverables. The resulting task list can be found as Appendix ?.

Also taken into account were any foreseeable problems that may arise at any point throughoutthe project. A risk analysis (See Appendix ?) was produced, listing a number possible problemsand detailing proposed solutions. The combination of the each risk’s frequency and severity weretaken into account and the result of the analysis considered when planning and scheduling thetime frames for each individual task.

The task list was then used to produce a Gantt chart, which can be found as Appendix ?. Thisgave a clearer breakdown of the tasks and allowed for them to be scheduled easier. The Ganttchart played a crucial role in time keeping of the project and was often referred back to in orderto ensure the tasks were completed on time and were deliverables meeting their deadlines.

The Gantt chart was updated throughout the duration of the project to reflect any deviationsfrom the original plans. This included any unforeseen problems not already compensated forby the risk analysis.

13

4.2 Management

Figure 7: Backup structure.

A folder structure was maintained to keep backups of all reports, code, diagrams and notes onan external hard disk. As well making a backup of the most recent changes of the application,individual backups of every major version were kept. This was done not only to minimise theimpact of lost work (drive failure, theft, etc) but also to refer back to previous working versionsshould any faulty code need reverting to a previous state.

Weekly supervisory meetings were also attended develop ideas and ensure the project waskeeping on track. Hand-written minutes were written out each week detailing any pre-meetingagenda along with any issues discussed throughout the course of the meeting. Scans of theminutes can be seen in Appendix ?.

Coding standards were adhered to during the development of the project, keeping uniformlayouts and styles throughout all source files to increase readability. All variables and functionswere designed to follow the CamelCase naming convention and underscores were used to denotethe their scope in classes. An prefixed underscore would be used to indicate private scopewhereas an suffixed underscore would indicate protected scope.

14

5 Software Development

Early on it was decided to split the project into two individual cores; the audio synthesizerand the cellular automata. Both were complex individual systems in their own right and soit seemed only right to develop them in isolation. This was done to ensure both aspects ofthe system operated correctly and efficiently on their own before combining them into a singleapplication.

Designs and plans were created for each system, analysing what was required of each part andwhat they were to contribute to the overall design. After these initial plans were completedthere followed a continuous cycle of rapid development and design re-evaluation. As I had littleto no experience with parts of the project, OpenAL in particular, the prototyping phase helpedto route out any features that appeared to be infeasible due to difficulty or limitations in thevarious technologies.

5.1 Generative Audio System

The first part of the system I chose to develop was the audio synthesizer. This was mainly dueto my lack of experience with the technologies and also due to the high risk rating. Designs andprototyping for this section begun during the summer holidays, alongside the research phase,so as to tackle any potential problems early on.

5.1.1 Requirements& Specification

When specifying the initial task list of the main application, two key requirements of the audiosystem were outlined. The first being that system was capable of generating audio data basedon a set of supplied parameters. The second requirement was for the system to then stream thisdata to the sound card. As outlined in the risk analysis, should streaming to the sound card inreal-time prove unreliable, streaming the data to an external sound file could be considered asa backup option.

5.1.2 Software Analysis

Before the software was implemented the problem was first broken down and analysed withthe aid of class diagrams, use case diagrams and activity diagrams. This helped to break thesystem down into a number of smaller problems and to build a clear picture of the applicationsinternal structure before any coding had begun.

The audio system was design with modularity in mind, as it had to operate not only as astand-alone piece of software but also as part of a bigger application. Because of this, codereuse played a key factor in designing the objects and classes of audio system. The main classesfor both the streamer and generator were designed to be completely self-contained with nodependency on each other. This would allow for one class to remain unusable should the otherfail, for example should the streaming class need replacing with a file writing class, no changeswould be required on the part of the generator class. Likewise, should the generator class failit could easily be replaced with a sample based class with no detriment to the streamer.

Initial prototyping begun when the analysis stage yielded enough designs to implement a basicworking version with minimal features. Upon completion of the basic system, more featureswere added to the design and so too in the implementation. Due to the nature of this section

15

of the project, it was deemed unnecessary to design any form of GUI at this stage but ratheropt for a simple command line application.

5.1.3 Implementation

As previously established, this audio system would be comprised of two main elements; a audiosynthesizer to generate raw data and a streamer to make use of it. Both relied on a an externalaudio technology, STK in the case of the former and OpenAL in the latter. It was decided toundertake the implementation of the synthesizer first, as without it there would be nothing tostream.

The most basic feature of any subtractive synthesizer is an oscillating signal. While writingan algorithm to calculate such a waveform would be a simple task in itself, it was decided touse the sine, saw and square waveform classes provided by STK for their high efficiency. Thesignals samples returned by STK are in the form of real numbers, however for the purposesof this project the samples were required to be in the PCM (Pulse Code Modulation) formataccepted by OpenAL.

Sample Rate

Bit

Rat

e

Figure 8: Representation of PCM format. Where the red sine wave represents the originalanalogue signal and the blue steps represent the corresponding PCM data.

The PCM standard defines how a traditional analogue signal can be represented with digitalinformation as a set of discrete numbers. To do this, two parameters are required; the samplerate and the bit rate (see Figure 8). The sample rate determines how frequently the originalsignal should be sampled, for example a rate of 48000Hz would mean 48000 numbers wouldbe needed to represent a single second of an audio signal. The second parameter, bit rate,determines the number of bits used to represent each sample. For example, a rate of 4bit/swould allow each sample to be conveyed by a number ranging from 0 to 15, whereas 16bit/swould allow 65535 possible representation.

Obviously the higher the bit and sample rates the higher the fidelity, however with that comeshigher computational requirements which could prove a heavily impact on real-time streaming.Because of this the two rates were subject to change throughout the course of the project in aneffort to find the optimal trade-off between speed and quality.

In order to convert the signal into PCM format ready for streaming, each sample was multipliedby the the bit rate and converted to an integer. By encapsulating a number of these signalgenerators in a single class and providing a set of methods to modify pitch and waveform,the bare bones CellSynth class was created. Before developing the streaming element of thesoftware, PCM data was first exported from the generator and plotted alongside data generated

16

in a professional audio suite to ensure its accuracy (See Appendix ?).

A basic streaming class was next developed, the heart of which revolved around a number ofbuffers, each of which are streamed to a sound device before being populated with new audiodata. As with the the sample and bit rates of the synthesizer, the size and quantity of OpenALbuffers would be the subject of much experimentation. Having too many or too large bufferscan result in high latency between the data being generated and audio being output to thesound device, conversely having too small or few buffers can produce audio which stutters andglitches. For the time being 2 buffers of 4096× 2 (8192) bytes would be used.

Upon initialising the buffers, sound device and other prerequisites of an OpenAL application,the software would enter a continuous loop in which buffers would be filled with a number ofPCM samples (see Figure 9). The streamer cycles through each available buffer and checks tosee whether its data has already been processed, that being the case the tick() method of thesynthesizer object would be called, which in turn would calculate a single PCM sample for aspecified waveform. The tick() method is called once for each byte in a given buffer (8192 timesper buffer in this case) until the it’s full, at which point the buffer is sent to a processing queue.

Initialisation Fill Buffer Process Buffer

Empty BufferCheck Buffers

Figure 9: Representation of PCM format. Where the red sine wave represents the originalanalogue signal and the grey steps represent the corresponding PCM data.

At this stage a basic, working audio system was complete, allowing for a single waveform to bestreamed as an audio signal to the sound card. At this the design and in turn the implementationwere updated to include more and more features from the proposed parameter list in Appendix?. By the end of this process the audio generator a host of subtractive synthesis features andwas capable of producing a wide range of sounds. The final tick function looked as follows:

1 short int Cel lSynth : : Tick ( )2 {3 f loat amplitude = ads r . t i c k ( ) ;4 double s i g n a l ;56 // Apply ADSR enve lope7 i f ( ads r . g e tS ta t e ( ) == ADSR: : SUSTAIN) {8 i f ( 1 | | sampleCount >= ( int ) sampleRate ){9 ads r . keyOff ( ) ;

10 sampleCount = 0 ;11 } else { sampleCount++; }12 }1314 // Apply LFO modulation15 SetFrequency ( i n i t i a l F r e q u e n c y + ( l f o . t i c k ( ) ∗ l f o R a t e ) ) ;1617 // S e l e c t waveform18 switch ( waveform ){19 case SINE : s i g n a l = s i n e . t i c k ( ) ; break ;20 case SQUARE : s i g n a l = square . t i c k ( ) ; break ;

17

21 case SAW : s i g n a l = saw . t i c k ( ) ; break ;22 }2324 // Generate a s i n g l e sample by a m p l i f y i n g the o s c i l l a t o r s i g n a l25 return ( int ) ( s i g n a l ∗ maxAmplitude ) ∗ ( amplitude ∗ ga in ) ;26 }

The tick function performs 4 basic tasks:

• Line 3: The current state of the ADSR (Attack-Decay-Sustain-Release) envelope is polled.This returns a real value in the range of 0 to 1 and acts as a sample coefficient to createtones that rise and fall in volume. ADSR is explained in further detail in Appendix ?.

• Line 7: The state of the ADSR envelope is updated.• Line 15: A low frequency oscillator is ticked and the returned signal is used to modulate

the synthesizer pitch.• Line 18: The appropriate oscillator is ticked and single sample returned.• Line 22: Apply the various offsets to the basic waveform and return processed sample.

The values used in the tick function such as the LFO frequency, ADSR times and wave nameare all private to the CellSynth class and so a number of public accessors and mutators wereimplemented to allow these values to be modified. It’s also worth noting that not all of thesignal processing is performed in the tick method, panning for example is calculated later on.

Figure 10: Final version of the audio system.

With a working generator and streamer in place the next step was to implement some basicinterface functionality and attempt to simulate how the audio system would be used in the finalapplication. This was achieved by streaming 8 instances of the synthesizer class and occasionallyupdating each one with a new set of random parameters, a screenshot of which can be seen inFigure 10. After some minor buffer and rate tweaking to compensate for any speed issues theresulting sound was a smooth flow variable frequency tones; pulsating, fluctuating and buzzing.

This was a positive start for the project, as up until this point there was no indication as towhat kind of noises the software might produce. While the output might not be considered

18

traditional music, it certainly had rhythmic and ambient qualities about it.

19

5.2 Cellular Automata System

The second part of the application I designed was the cellular automata. This process wasallocated less time than the previous system due to my previous experience with OpenGL.That being said, the cellular automata system was not without it’s own risks, especially giventhat it had to be as optimised and efficient as possible to lend the bulk of processing time tothe audio system.

5.2.1 Requirements& Specification

The two main requirements of the cellular automata system were the simulation itself and theaccompanying visualisation, the latter requiring OpenGL functionality. The simulation wouldbe required to update itself in discrete time while the visualisation should constantly redrawthe current state of the simulation to the screen.

5.2.2 Software Analysis

As was the case with the audio system, the problem was again broken down into a number ofsmaller tasks. Again, diagrammatic analysis was performed in the form of class (Appendix ?),activity (Appendix ?) and use case (Appendix ?) diagrams; all of which were subject variousupdates throughout the life of the development process.

At this time, the exact nature of the relationship between the audio system and the cellularautomata was still the matter of some deliberation. As such, the classes were designed withmulti-state cellular automata in mind, despite only 2-state binary being used in the final product.This route was also taken to curb the risk of ending up with insufficient unique parameters todrive the pattern matcher, since using multiple states increases number of potential parametersexponentially.

Similarly to the the audio system, code reuse was of utmost priority, as both systems wouldeventually have to be incorporated into a single application. It was also important to keep adegree of separation between the simulation algorithms and the visualisation. As outlined inthe risk analysis, there’s a possibility that the combination of audio generation and graphicsrendering may prove too exhaustive for a standard processor to handle. If that should be thecase, one of the proposed solutions would be drop the visualisations altogether leaving thecellular automata to operate behind the scenes.

5.2.3 Implementation

The first piece of functionality implemented was the simulation, as without it the visualisationswould be redundant. To initialise the simulation, a number of parameters were needed; size,number of states and speed being rather straight forward to implement it. One of the moredifficult methods to implement was setting the rule number.

As explained previously in the report, cellular automata rules are defined as decimal numbersand then used in terms of their binary value in the case of 2-state automata, tertiary for 3-state, etc. That is to say in a 2-state automata, given a decimal rule of 43, its binary formatof 00101011 would be referenced when the automata updates. Because of this it was deemedappropriate for the automata class to take a decimal rule as input, yet convert and store eachbit as an array element. With the previous example of 43, this would be stored internally in

20

the format rule = [0, 0, 1, 0, 1, 0, 1, 1], allowing cell updates to be calculated with the formulastate = rule[n] where n is the calculated total of the current cell and its neighbourhood.

Due to the decision to add multi-state capability to the simulation, the system was required toconvert rules to any given base, dependant upon maximum specified state. Therefore returningto the previous example, should the maximum state be specified as 3 the value 48 would be storedas ? and with 4 states ?. This proved to be quite problematic, as while there exists standardC++ functions to convert a number from one base to another, none return them in the form ofa byte array. This required a new custom base conversion function to be implemented.

1 unsigned byte r u l e s [ 5 1 2 ] ;23 // ! Assign a r u l e and conver t i t to the c o r r e c t base4 void CellAutomata : : SetRule (unsigned int r u l e ) {5 this−> r u l e = r u l e ;6 for ( int i =0; i <512; i++) { r u l e s [ i ]=0; }7 baseConvers ion ( ru le , this−> s t a t e s , this−> r u l e s ) ;8 }9

10 // ! Convert a number by a g iven base and p o p u l a t e a number o f c e l l s11 // ! Could do wi th c l e a n i n g up to make t h i n g s a b i t more p o r t a b l e12 void baseConvers ion ( int number , int base , Ce l l (& r e s u l t ) [ 5 1 2 ] , int b i t =0)13 {14 i f (number<=0) return ;15 baseConvers ion ( number/base , base , r e s u l t , ++b i t ) ;16 r e s u l t [ b i t −1] = ( Ce l l ) ( number%base ) ;17 }

With the rules function in place, the next stage of development was the update routine itself.This would contain two algorithms, elementary and totalistic. With elementary, for any givencell a 3-digit value is formed from the value of the cell itself and it’s two adjacent neighbours.As with the rule array, the base of this 3-digit value should reflect the maximum number ofstates for the current simulation. For example a cell valued at 1 with a left neighbouring cellof 1 and a right of 0 would produce the binary value 110 for a 2-state automata. The decimalrepresentation of this value, 6 in this case, acts as an index for rule array. The correspondingelement then becomes the new cell value. The totalistic routine works in a similar way, the onlydifference being that 3 neighbourhood values are summed together rather than converted to asingle value. A graphical depiction of this process can be seen in figure 11.

It was also decided to wrap neighbourhoods for the sake of convenience and to keep a fluidsimulation. Without this wrapping, updating the first and last cells of the automata wouldyield a neighbourhood of only 2 cells and would require extra provisions in the code to calculatecorrectly.

Finally came the visualisation element of the system. This was originally intended to takeadvantage of the OpenGL Utility Toolkit (GLUT) to remove the burden of hand coding someof the more trivial portions of the application, namely window initialisation. However, earlyon in the prototyping stage it became apparent that some crucial features of the WinAPI wereobscured by GLUT, the most vital of which being a callback for window termination, whichwould prevent garbage collection routines from running should the software be terminated theregular way. As a result the designs were amended to use pure OpenGL very early on in thedevelopment process. In hindsight this wasn’t too large a drawback, as the use of extra toolkitsand libraries may have adversely affected the efficiency of the software.

21

1 0 0 1 1 0 1 0 1

6 2

Neighbourhood

Rule 90 1 1 0 2 1+1+0

1 0 0 1 1 0 1 0 1

Elementary Totalistic

0 1 0 1 1 0 1 08 7 6 5 4 3 2 1

Figure 11: Cellular automata update function for a 2-state rule 90 simulation. Details bothelementary and totalistic routines.

The main function of the visualisation was to draw a grid of coloured squares, one for each cellin the simulation. This was done by calculating the x and y coordinates from the cell positionand the colour from the cell state. Below is a snippet of the rendering routine.

1 Ce l l ∗∗tempCA = automata . GetAutomata ( ) ;2 unsigned int maxRow = automata . GetHistory ( ) ;3 unsigned int maxCol = automata . GetSize ( ) ;45 for ( int row = 0 ; row < maxRow; row++) {6 for ( int c o l = 0 ; c o l < maxCol ; c o l++) {7 char c l r = tempCA [ row ] [ c o l ]+1;8 i f ( c l r > 0) c l r = ( int )225/ c l r ;9

10 i f ( automata . G e t T o t a l i s t i c ( ) ) g lColor3b (0 , c l r , c l r ) ;11 else g lColor3b ( c l r , 0 , c l r ) ;12 g lBeg in (GL QUADS) ;13 glVertex2d ( row∗ c e l l S i z e+row , c o l ∗ c e l l S i z e+c o l ) ;14 glVertex2d ( ( row+1)∗ c e l l S i z e+row , c o l ∗ c e l l S i z e+c o l ) ;15 glVertex2d ( ( row+1)∗ c e l l S i z e+row , ( c o l +1)∗ c e l l S i z e+c o l ) ;16 glVertex2d ( row∗ c e l l S i z e+row , ( c o l +1)∗ c e l l S i z e+c o l ) ;17 glEnd ( ) ;18 }19 }

The above algorithm performs 2 main features:

• Line 7: Firstly the the state of the current cell is converted to a valid byte colour range.• Line 12: A quad is drawn to the screen based on the position of the cell.

22

Figure 12: Final version of the cellular automata system.

The completely cellular automata system included some rudimentary interface functionality;direction keys to adjust the states and rule and a key to toggle between update algorithms. Ascreenshot of the final version can be seen in figure 12.

23

5.3 Liquid Brain Music

The final aspect of the development was to bridge to audio and cellular automata systems to-gether with a pattern matcher to produce the complete application. With a lot of the frameworkalready in place and both systems coded as independent modules, the bulk of the remainingwork lay in designing the relationships between the various structures and classes.

5.3.1 Requirements& Specification

The requirements for the final application were the pattern matching system and the imple-mentation of the user interface. The pattern matcher would require data from the simulationto be converted to suitable parameter information for the audio synthesizer. With some minorinterface features already implemented in the cellular automata system, the foundations for thefinal application were already in place. The remaining requirements were to allow give

5.3.2 Software Analysis

With the analysis already completed for two previous elements, the focus of the the analysisfell on the pattern matcher. This involved determining how data should be measured fromthe cellular automata, how it should be translated and finally how it should be applied to thesynthesizer. With much of the foundations already present, many of the design diagrams fromprevious stages were reused and updated to suit the needs of the final application.

Another key consideration at this stage was ensuring the two systems interfaced as efficiently aspossible. While they both performed fine as independent pieces of software, running a numberof instances in unison might prove to be too computationally intensive, forcing a redesign of oneor both systems. Some testing had been carried out before this point in an effort to estimatethe performance of the final application (see section 6), however the risk still remained.

5.3.3 Implementation

The first task of this implementation was simply to have both the audio and cellular automatasystems running parallel in the same process. At this stage no relationship was present betweenthe two systems and the focus was simply to gauge their performance alongside each others.With both systems implemented the next stage was to connect them through the patternmatching system.

As previously established, the pattern matcher would work on a search and count basis. Thatis to say the current generation of cells would be searched for a set of predefined patterns, eachmatch would then be tallied and the resulting counts would form the basis of the synthesisparameters. From the list of parameters considered at the design stage (see Appendix ?) atotal of 8 base patterns were short-listed for the final application:

• 1 white cell• 1 black cell• 2 white cell• 2 black cell• 3 white cell• 3 black cell

24

• 4 white cell• 4 black cell

Of these 8 parameters, 2 counting schemes were implemented for both, boosting the totalpatterns to 16. The two schemes employed were ’Run length’ and ’Block Size’. The ideabehind the run length count was to blindly search for a matching pattern, paying no regard tosurrounding cells. In this respect, when searching for 2 white cells in the field of 8 adjacentwhite cells, the value returned would be 4 as the 8 cells contain 4 sets of 2 white cells.

Block size encoding differs in the fact that it pays regard to the cells either side of the currentsearch field. In the case of the previous example the 8 white cells yield a result of 0 whensearching for 2 white cells. This is because the block (size) is 8 white cells as opposed to the 2specified. The fact that a number of 2 white exist inside it is disregarded, as only exact matchesare considered under this scheme.

With the measurement aspect of the pattern matcher in place, the next stage was to translatethese values into information relevant to the pattern matcher. The first stage of this involvedconverting the pattern counts to real number in the range of 0 to 1, with 1 being the maximumachievable count for that particular search pattern. This gives us a weighted percentage thatwe can use for any parameter, regardless of the originating pattern.

Matching 2 white

CellSynthFind WeightedPercentage

x(Max-Min)+ Min

x(Max-Min)+ Min

Find WeightedPercentage

Runlength Blocksize

4 1

ParameterFrequency

Min: 100hzMax: 16000hz

New Value: ?

Figure 13: Simplified depiction of the pattern matching process, for both block size and runlength encoding.

For the next stage, each synthesizer parameter was assigned a minimum and a maximum value.The weighted search values would then be multiplied by the maximum of their correspondingpattern and offset by the minimum. This would translate any of the search pattern into asuitable and correctly ranged value for any given parameter. The minimum and maximumvalues would later be subject to experimentation to target the values producing the best audioresults (see section 6.4). The diagram of matching and parametrisation process can be seen infigure 13 and a section of the code follows:

25

12 // Sca le by maximum , o f f s e t by minimum3 parameters [ i ] . va lue = ( ( f loat ) parameters [ i ] . pattern−>value /100)4 ∗ ( parameters [ i ] . maximum − parameters [ i ] . minimum)5 + parameters [ i ] . minimum ;67 // Assign new parameter v a l u e to t h e i r corrosponding Ce l lSynth methods8 iSpeed = 22−parameters [ 1 0 ] . va lue ;9 ce l l Synths−>SetADSRMode ( ( bool ) parameters [ 1 2 ] . va lue ) ;

10 ce l lSynths−>SetGain ( parameters [ 1 1 ] . va lue ) ;11 ce l lSynths−>SetWaveform ( Cel lSynth : : OscType ( ( int ) parameters [ 0 ] . va lue ) ) ;12 ce l lSynths−>SetHarmonics ( parameters [ 2 ] . va lue ) ;13 ce l lSynths−>SetPanning ( parameters [ 7 ] . va lue ) ;1415 // Only update ADSR i f p r e v i o u s enve lope has f i n i s h e d16 i f ( c e l l Synths−>GetADSRState ( ) == ADSR: :DONE)17 {18 ce l lSynths−>SetLFOFrequency ( parameters [ 8 ] . va lue ) ;19 ce l lSynths−>SetLFORate ( parameters [ 9 ] . va lue ) ;20 ce l lSynths−>SetADSR( parameters [ 3 ] . va lue ∗ ( ( iSpeed )/4+1) ,21 parameters [ 4 ] . va lue ∗ ( ( iSpeed )/4+1) ,22 parameters [ 5 ] . value ,23 parameters [ 6 ] . va lue ∗ ( ( iSpeed )/4+1)) ;24 ce l lSynths−>Star t ( parameters [ 1 ] . va lue ) ;25 }26 else i f ( ! c e l l Synths−>GetADSRMode ( ) )27 {28 // I f ADSR enve lope i s in progress , on ly update f requency29 ce l lSynths−>SetFrequency ( parameters [ 1 ] . va lue ) ;30 }

Figure 14: The evolution of the graphical user interface.

With the pattern matcher in place the final stage was to implement the GUI. The existingcellular automata visualisation was used as the basis of the interface, it was then extended toaccommodate a list of local synthesis parameters and global modifiers. The entire interfacewas then skinned with a background image. This was done for two reasons, firstly to improvethe aesthetics of the application and secondly to reduce the burden placed on the renderingfunctions. Screenshots of the GUI throughout the various stages of development can be seen infigure 14.

User interaction was designed to be as simple and straight forward as possible, revolving almostentirely around the keyboards arrow keys. The keys could be used to navigate the list of syn-thesizer parameters and select which pattern matching scheme should be used to determine theparameter value. Some parameters such as polyphony and speed were not suited to automated

26

control and so in the user is given direct control of these values.

27

6 Testing

Various methods of testing were performed through the entire development cycle to ensure thesoftware functioned without error and that it met the required specifications.

6.1 Unit Testing

The first form of testing was unit testing. This was a key consideration in the design of thesystem and indeed one of the main reasons for developing the software as a number of sub-systems.

Unit testing is the process of ensuring the individual components of an application all work asintended, this was a very straightforward procedure as both the cellular automata and audiosystems were developed as standalone components with a view to eventual integration. Thismeant each aspect of system could be scrutinised and tested in isolation without any externalinterference. That being the case, each of the systems could be implemented in such a way asto simulate their final environment, allowing for all possible behaviours to be accounted for.

When the various units were brought together in the final system they were then integrationtested. This was to ensure they retained their original behaviour whilst also functioning togetheras part of a single system. The bulk of this process revolved around stepping through code induring runtime to analyse the the internal state of each object. This was particularly useful inretrieving and analysing data in the synthesizer before beginning work on the streamer.

6.2 Requirement testing

Another continuous process throughout the life of the software development process was re-quirement testing. This concerned whether or not the software was satisfying the requirementsoutlined at the start of the project, which can be found in Appendix ?). As well as acting asa safeguard to keep development on the right track, it also allowed me to determine when thefinal system was at an acceptable stage of completion.

6.3 User Testing

With all of the requirements satisfied and a usable piece of software complete, a small numberof volunteers were asked to thoroughly test application and rate their experiences with it.

A selection of 9 volunteers were used at this stage, all with varying degrees experience inthe fields of computer science and computer music. This was done in an attempt to gain anunbiased account of the applications usability regardless of the end users existing knowledge.They were asked to experiment with the application both before and after they had read theuser documentation. This was done in an effort to determine the applications ’out of the box’usability and also to rate the effectiveness of the user documentation itself.

After testing the software, users were asked to fill out a small multi-choice questionnaire (seeappendix ?) with the option of providing any general remarks on the application and itsdocumentation. The results were compiled and plotted onto a number of graphs (see appendix?) in an effort to quantify the suitability and usability of all aspects of the software.

28

6.3.1 Result Evaluation

While no major problems were discovered in the software itself, some of the feedback did reflectnegatively on the software’s ease of use. A common remark, especially among the users withlittle to no background in computer music, was that it was not entirely clear how to interactwith the software upon initially opening it.

Other feedback concluded that:

• The range and variety of sounds produced were very well received.• The interface itself aesthetically pleasing.• The user documentation was relatively useful.

6.3.2 Post-Test Software Changes

Figure 15: Updated on-screen help.

In response to user feedback in the testing phase, the GUI was extended to incorporate a newon-screen help panel, shown in figure 15. This includes a full listing of keyboard controls alongwith details of the currently selected parameter, giving a short description for every aspect ofthe program in a small space.

6.4 Experimentation

With provisions for testing in place along with a fully functioning piece of software, the experi-mentation phase could begin. As previously outlined there were a number of parameters in thesystem that could be subject to change to increase efficiency. The changes included:

• Sample Rate: The originally proposed sample rate of 48000Hz was reduced to 22200Hz,this resulted in a noticeable boost in performance. Due to the relatively simple nature ofthe tones being generated there were little to negative changes in their perceived quality.

• Bit Rate: Likewise the bit rate, the originally 16bit, was dropped to 8bit without no-ticeable detriment to the audio quality.

• Buffer Quantity: This was one of the trickier parameters to optimise due to its depen-dency on buffer size. In the end it was determined that any number of buffers between 2and 4 resulted in acceptable efficiency.

• Buffer Size: Due to the inherent limitations of OpenAL, the smallest buffer size todeliver a constant and reliable stream of sound fell around 8000 sample mark. While thismeant a somewhat noticeable delay between audio being generated and being output, thelatency issues did not impact on the software too heavily.

• Parameter Ranges: Every parameter of the subtractive synthesizer underwent somedegree of experimentation to pinpoint the best sound ranges, however the most noteworth is probably the frequency. Originally a range of 22Hz to 22kHz was implemented,

29

the standard range of audible frequencies for the average human. Upon testing however,it proved difficult to differentiate between tones falling in the latter half of the spectrum.After much experimentation the frequency range implemented in the final application is40Hz to 8kHz.

30

7 Critical Evaluation

This section of the report is intended to critically review and evaluate a number aspects of thisproject.

7.1 Software Development

The waterfall software development model was chosen for this particular project. However withthe open-ended requirements of the project, the non-iterative nature of the model proved tobe somewhat restricting. As such, while the model was adhered to as closely as possible, someaspects of rapid prototyping were utilised alongside it. This was the case with the earlier stagesof the audio system in particular.

That aside, the waterfall model provided a good basis for the development process and laidout clear and logical path, making it very suitable for sequencing tasks in a relatively shortperiod of time. Had a more agile model been selected, the risk of ever-changing requirementsand designs may have adversely impacted on time management for a project of this size.

Given a larger scale project the spiral model may have been more suitable for the task in hand,as it combines aspects of both the prototyping and waterfall models (Boehm, 1988). Thisprocess is more suited to large and complex projects however and would likely be overkill in thecase of Liquid Brain Music.

7.2 Testing Evaluation

A number of testing methods were employed for this project including user testing and unittesting. While perhaps not most extensive tests, I believe they were adequate suited for thisparticular project, as evident by the final working product. Given more time or a larger project,some form of automated unit testing may have been in order to systematically measure everypossible system state.

The results of the user questionnaire helped to identify potential usability problems in thesoftware and resulted in a new and updated interface features. Had more than the relativelylow amount of 9 volunteers been used, further issues may have been pinpointed. Ideally a greaternumber testers would have been preferred, however, finding more volunteers and distributingthe system to them was deemed to be more effort than it was worth and in the end moreimportant tasks took priority.

Requirements testing began from the very first stages of development and a while relativelysimple process I believe it helped to keep progress on track. With a project specification asvague as that for Liquid Brain Music, the absolute requirements were relatively simple. Hadthis project have been on a larger scale however, the requirements testing may have played amuch larger role in the development process.

7.3 Additional Features

Following the implementation of the required features, a number of additional features weredesigned and included into the software. First of which being polyphony, which while not aspecified requirement was always considered for the final version. A maximum of 8 simultaneous

31

voices were made available to users, which was deemed more than enough to cover a large rangeof frequencies.

Another additional feature added was the ability to toggle between a direct stream and an ADSRenvelope. The problem with ADSR is slow swelling and shrinking of tones, usually resulting inquite a mellow sound scape. To open the software up to more possibilities, an option was madeto switch the ADSR envelope off and instead allow for a continuous stream of sound. Withthis being the case, frequencies are updated in real-time as a direct response to changes to thecellular automata state, as opposed to at the beginning of each new envelope as is normally thecase.

Some minor options were then added to polish the application off, these included a ’mute voice’button, a number of randomisation features and individual gain levels for every voice. As wasthe case with polyphony, many of these features were kept in mind throughout the design phase,ready to implement towards the end of the development process should time permit.

Finally saving and loading operations were added to the software in another step toward incor-porating the features of a useful composition tool. These file operations imported and exportedaccordingly, all global parameters along with the parameters for each active cellular automatavoice. Unfortunately, due to time constraints the saving and loading operations provide littlein the way of user feedback and are somewhat lacking in the way of flexibility.

7.4 Objectives Evaluation

A number of aims & objectives were detailed at the start of this project (see section 1.2), bornof the original project outline. The first, concerning the ‘creation of an artificial life simulation’has been satisfied in the form of the underlying cellular automata algorithms driving the entireapplication. This objective ties in very closely with the second, to ‘display a visual representationof the simulation’ achieved with a grid displaying a graphical depiction of every cells state, alongwith history of the 100 previous generations.

Objective goes on to state that this simulation should be used to generate a set of suitablemeasures. This objective forms the first part of the pattern matching process, searching forspecified blocks of cells and tallying totals. This leads onto the second half of the patternmatcher, which goes on to convert these measures into usable parameter values, thus satisfyingobjective 4 - to ‘use the measures to control aspects of the audio generator’.

The next objective requires the data create by the audio generator to be output in a suitableformat. While it was first doubted whether real-time audio output was feasible, I managed toimplemented it without any major problems. Had this have proved too difficult, an alternativemode of output such as a file streamer could have been used to fulfil this objective.

The final objective states that the software should handle user configuration, which has beensurpassed in the sense that not only can the simulation be configured, but almost every aspectcan be controlled and customised in real-time.

32

8 Conclusion

With all requirements, aims and objectives satisfied I consider this project to be a success.As previously mentioned, there are a few minor aspects of the assignment I would approachdifferently in hindsight. However, I don’t believe any issues raised have been a major detrimentto the overall success of the project.

Working on Liquid Brain Music has proved to be a challenging yet extremely rewarding experi-ence. Having never undertaken a software development project on this scale before, I have notonly had the chance to apply the knowledge gained over the course of the past few years, buthave also learnt new practices along the way.

8.1 Future Work

The work carried out on this project opens itself to a number of future uses. Of course, many ofthe classes and structures in the software were designed with code reuse in mind. The patternmatcher and audio generator are of particular interest, as they could lends themselves to a hostother uses.

Other future work recommendations include incorporating genetic algorithms into the system.This could allow for the more aesthetically pleasing configurations to be pinpointed and subse-quently evolved into new configurations. This would have the effect of creating a system capableof composing its own music, being able to decide which results sound best to the human ear.

I myself fully intend to continue work on the software when the assignment comes to end. Iwould like to remove the hard coded synthesis engine and instead implement MIDI functionality,an industry standard protocol allowing electronic instruments and computers to communicate.This would allow the pattern matcher to drive external hardware such as synthesizers, drummachine and samplers, allowing the focus of development to shift to the artificial life aspect ofthe system.

33

Appendix A: Task List

This section details the tasks that comprise the project and their current status. The Ganttchart in Figure 16 compares the original estimated task durations, the current progress and anupdated time plan. All of the estimations try to take any foreseeable problems into consideration(See Appendix A: Risk Analysis).

1. Background Research (22 wks) Will involve researching cellular automata, signalprocessing, pattern matching and the tools to implement them. Research will carry onthroughout the majority of the project.

2. Initial Report (4 wks) Prepare initial report for week 5 of the academic year.3. Design & Build Audio Engine (10 wks) Can be further broken down to a synthesis

engine and a streamer.4. Interim Report (7 wks) Prepare interim report for week 13 of the academic year.5. Design & Build Automata (4 wks) Design and create a cellular automata and visu-

alization.6. Examination Revision (6 wks) Revision over the Christmas Holidays for examinations

at the start of the year.7. Design Pattern Matcher (4 wks) Design pattern matching system to interface between

the audio engine and the cellular automata8. Design & Code Implementation (6 wks) Design & code the complete system includ-

ing user interface combining the previously designed classes.9. Testing (24 wks) Testing all aspects of the system. Will begin as soon as a testable

build of the audio engine is developed.10. Documentation (6 wks) User documentation and technical documentation.11. Final Report (9 wks) Combining both previous reports, documentation, designs, testing

and any other deliverables.12. Presentation Preparation (4 wks) Preparing and delivering the final presentation on

the project.

34

Appendix B: Gantt Chart

24-Sep-07

01-Oct-07

08-Oct-07

15-Oct-07

22-Oct-07

29-Oct-07

05-Nov-07

12-Nov-07

19-Nov-07

26-Nov-07

03-Dec-07

10-Dec-07

17-Dec-07

24-Dec-07

31-Dec-07

07-Jan-08

14-Jan-08

21-Jan-08

28-Jan-08

04-Feb-08

11-Feb-08

18-Feb-08

25-Feb-08

03-Mar-08

10-Mar-08

17-Mar-08

24-Mar-08

31-Mar-08

07-Apr-08

14-Apr-08

21-Apr-08

28-Apr-08

05-May-08

12-May-08

19-May-08

26-May-08

02-Jun-08

Wee

k Date

24-Sep-07

01-Oct-07

08-Oct-07

15-Oct-07

22-Oct-07

29-Oct-07

05-Nov-07

12-Nov-07

19-Nov-07

26-Nov-07

03-Dec-07

10-Dec-07

17-Dec-07

24-Dec-07

31-Dec-07

07-Jan-08

14-Jan-08

21-Jan-08

28-Jan-08

04-Feb-08

11-Feb-08

18-Feb-08

25-Feb-08

03-Mar-08

10-Mar-08

17-Mar-08

24-Mar-08

31-Mar-08

07-Apr-08

14-Apr-08

21-Apr-08

28-Apr-08

05-May-08

12-May-08

19-May-08

26-May-08

02-Jun-08

1

2

3

4

5

6

7

8

9

10

11

12

1

3 1

4

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

Seme

ster 1

Seme

ster 2

Easte

rCh

ristm

as

M1

M2

54321

4 wks

10 w

ks

7 wks

4 wks

21 w

ks

M38

Task

765

24 w

ks9

4 wks

6 wks

6 wks

4 wks

M4

M5

24 w

ks

6 wks

9 wks

4 wks

1211109 M1 M2 M3 M4

Origi

nal ta

sk pl

anInt

erim

Rep

ort c

omple

ted an

d han

ded i

nIm

pleme

ntatio

n full

y cod

ed an

d tes

tedFin

al Re

port

comp

leted

and h

ande

d in

Curre

nt tas

k pro

gres

sion

Revis

ed ta

sk pl

anCu

rrent

week

Initia

l Rep

ort c

omple

ted an

d han

ded i

n

Miles

tones

Key

M4 M5Fin

al Re

port

comp

leted

and h

ande

d in

Plan

ned a

nd de

liver

ed pr

oject

pres

entat

ionCu

rrent

week

Miles

tone

Figure 16: Gantt chart of tasks described in section 8.1.

35

Appendix C: Supervisory Meeting Minutes

36

Figure 17: Examples of supervisory minutes?.

37

Appendix D: Version History

38

Appendix E: UML Diagrams

CellAutomata

-_states: Cell-_rules: Cell-_totalistic: bool-_rule: unsigned int-_size: unsigned int-_history: unsigned int-_currentIndex: unsigned int-_grid: Cell

<<create>>-CellAutomata(states: Cell, rule: unsigned int, size: unsigned int, history: unsigned int)<<destroy>>-CellAutomata()+GetAutomata(): Cell+GetCurrent(): Cell+GetCurrentString(currentChar: char): void+SetCurrentString(currentChar: char): void+GetSize(): unsigned int+GetHistory(): unsigned int+SetTotalistic(totalistic: bool): void+GetTotalistic(): bool+GetStates(): unsigned int+SetStates(states: Cell): void+GetRule(): unsigned int+SetRule(rule: unsigned int): void+Reset(): void+Randomize(rule: unsigned int): void+Update(steps: unsigned int): void

Pattern<<CppStruct>>

+value: int+id: int+patternName: char

Parameter<<CppStruct>>

+minimum: �oat+maximum: �oat+value: �oat+step: �oat+pattern: Pattern+paramName: char+paramDesc: char

Source<<CppStruct>>

+alBu�ers: ALuint+alSource: ALuint+pSignal: SignalGenerator

PCMStreamer

-_pDevice: ALCdevice-_pContext: ALCcontext-_format: ALenum-_voices: int-_sampleRate: unsigned int-_sources: vector<Source>

+Initialise(sampleRate: unsigned int): void+Pause(): void+Release(): void+AddSource(pSignal: SignalGenerator): void+SetVoices(voices: int): void+Playback(): bool+Playing(): bool+Update(): bool-Stream(bu�er: ALuint, sIndex: int): bool

Voice

+automata: CellAutomata+cellSynths: CellSynth+patterns: Pattern+parameters: Parameter+iSpeed: int+updateTime: �oat

<<create>>-Voice()<<destroy>>-Voice()+MatchPatterns(): void

Figure 18: Gantt chart of tasks described in section 8.1.

39

CellSynth

-_waveform: OscType-_maxAmplitude: int-_frequency: �oat-_lfoFrequency: �oat-_lfoRate: �oat-_initialFrequency: �oat-_panning: �oat-_gain: �oat-_sampleCount: int-_timeCount: int-_harmonics: unsigned short-_mute: bool-_adsrmode: bool-_attackTime: �oat-_decayTime: �oat-_sustainLevel: �oat-_releaseTime: �oat-_sampleRate: int-_adsr: ADSR-_sine: SineWave-_square: BlitSquare-_saw: BlitSaw-_lfo: SineWave

+Initialise(waveform: OscType, sampleRate: unsigned int): void+Start(frequency: �oat): void+Tick(): short int+SetWaveform(waveform: OscType): void+GetWaveform(): OscType+SetGain(gain: �oat): void+GetGain(): �oat+SetADSRMode(status: bool): void+GetADSRMode(): �oat+SetHarmonics(harmonics: unsigned short): void+GetHarmonics(): unsigned short+SetFrequency(frequency: �oat): void+GetFrequency(): �oat+SetLFOFrequency(frequency: �oat): void+GetLFOFrequency(): �oat+SetLFORate(rate: �oat): void+GetLFORate(): �oat+SetPanning(panning: �oat): void+GetPanning(): �oat+SetAttack(attackTime: �oat): void+GetAttack(): �oat+SetDecay(decayTime: �oat): void+GetDecay(): �oat+SetSustain(sustainLevel: �oat): void+GetSustain(): �oat+SetRelease(releaseTime: �oat): void+GetRelease(): �oat+Mute(mute: bool): void+Mute(): bool+SetADSR(attackTime: �oat, decayTime: �oat, susta inLevel: �oat, releaseTime: �oat): void+GetADSRState(): int

SignalGenerator

+Tick(): short int+GetPanning(): �oat+Release(): void+Mute(): bool

Figure 19: Synthesiser class and parent generator class.

40

CellAutomata

CellSynth

Pattern<<CppStruct>>

Parameter <<Struct>>

Source <<Struct>>

PCMStreamer

SignalGenerator

Voice116

1

1

1

10 1

1

11

1

1

0..*

1

Figure 20: Relationship between classes.

41

i = 0

i < CA Size

Totalistic?

Total = Cell[i] +Cell[i]-1 + Cell[i]+1

TRUE

TRUE

Total = Cell[i]*4 +Cell[i]*2-1 + Cell[i]+1

FALSE

Cell[i] = Rule[Total]

i++

Figure 21: Gantt chart of tasks described in section 8.1.

42

Update keyboardevents

i = 0

i < Polyphony

TRUE

Voice[i] Waiting?

UpdateCellAutomata[i]

Match Patterns

i++

Update Streamer

TRUE

FALSE

FALSE

i = 0

i < Polyphony

TRUE

Unprocessed?

Generate aPCM sample

i++

TRUE

FALSE

FALSE

Buffer Full?

TRUE

FALSE

Streaming?Restart

Streamer

TRUE

FALSE

Figure 22: Gantt chart of tasks described in section 8.1.

43

Appendix F: Full Parameter List

Subtractive Synthesis Parameters

Parameter Description** Waveform Base waveforms (Sine, triangle, square, sawtooth, noise,

etc).*** Harmonics Redefine the number of harmonics base waveforms comprise

of (Sine N/A).* State Is the generator turned on or off?** Frequency Pitch of the tone, human hearing range is usually between

22Hz and 22kHz.** Panning Distribution of signal between between two stereo channels

(Left & Right).** Attack Duration for signal to reach its peak amplitude (volume).** Decay Duration for signal amplitude to decay to a sustained level.** Sustain Point of signal decay at which to hold.* Hold Duration to sustain signal level.** Release Duration for signal completely decay upon releasing sustain

hold.Filter Type Method of attenuating signal frequencies (High pass, low

pass, band pass, comb, notch, etc).Filter Level Intensity of filter.* Filter Cut-off Frequency point at which to attenuate from.Filter Resonance Create a small frequency peak at the cut-off point.Filter ADSR See previous envelope parameters (Attack, decay, sustain,

release).Frequency Modulation Secondary audio signal to modulate the frequency of the

carrier waveform.Amplitude Modulation Secondary audio signal to modulate the amplitude of the

carrier waveform.LFO Waveform Waveform for a low frequency oscillator (See Waveform pa-

rameter).*** LFO Frequency Frequency rate of a low frequency oscillator.LFO Parameter Synthesis parameter to modulate.*** LFO Level Intensity of LFO modulation.

*

= Initially proposed parameters, ** = Implemented parameters, *** = Additionally imple-mented parameters.

44

Appendix G: Test Results

The follow questionnaire was issued to users testing the application.

Please rate the following statements on a scale of 1-5 based on your experiences with Liquid Brain Music.

1=Strongly Disagree, 2=Disagree, 3=Impartial, 4=Agree, 5=Strongly Disagree

Liquid Brain Music - Tester Questionnaire

Statement Rating

First Impressions

1.1 Upon first opening the application, it appears easy to use.

1.2 The user interface was effective and intuitive.

1.3 The user interface was aesthetically pleasing.

Documentation

2.1 Upon reading the user documentation, the application became easier to use.

2.2 The user documentation itself was easy to understand.

2.3 The user documentation satisfied any questions you had.

Sound

3.1 You were able to change the sound of the generated audio easily.

3.2 The synthesizer provided sufficient features and flexibility.

3.3 The polyphony limit of 8 voices provided enough sound possibilities

Visualisation

4.1 The visualisation provided a good insight into the workings of the cellular automata.

4.2 The parameter values provided a good insight into the inner workings of the system.

4.3 The chosen colour scheme was suitable and easy to use.

Interaction

5.1 The keyboard controls were responsive.

5.2 The keyboard controls were intuitively laid out.

5.3 The addition of mouse control would little no noticeable improvement.

Previous Experience

6.1 You have a good background if computer science.

6.2 You have a good background in computer music.

Any additional comments?

45

The following table display a compilation of the results gathered from user questionnaires.

Liquid Brain Music - Questionnaire Results

Statement 1 2 3 4 5

1.1 1 1 4 2 1

1.2 0 1 2 4 2

1.3 0 0 2 3 4

2.1 0 0 2 4 3

2.2 0 0 2 5 2

2.3 0 2 2 4 1

3.1 0 0 1 6 2

3.2 0 1 0 5 3

3.3 0 0 2 3 4

4.1 0 0 1 3 5

4.2 0 0 3 3 3

4.3 1 0 2 0 6

5.1 0 1 0 2 6

5.2 0 0 0 3 5

5.3 1 1 1 3 3

A number of additional comments were also left:

• “I kept having to refer back to the documentation to figure out what each key did.”

• “Needed to update my OpenAL drivers but software ran without problems after that.”

• “Could do with some on-screen pointers to make things easier.”

• “Very interesting program. I can see myself using it in the future.”

These results were then compiled into a number of graphs for easier analysis. Generally the

0

0.5

1

1.5

2

2.5

3

3.5

4

4.5

Strongly Disagree Disagree Indifferent Agree Strongly Agree

1.1

1.2

1.3

1 Results for questions relating to the users initial experiences.

46

0

1

2

3

4

5

6

Strongly Disagree Disagree Indifferent Agree Strongly Agree

2.1

2.2

2.3

2 Results for questions relating to documentation.

0

1

2

3

4

5

6

7

Strongly Disagree Disagree Indifferent Agree Strongly Agree

3.1

3.2

3.3

3 Results for questions relating to audio and sound quality.

0

1

2

3

4

5

6

7

Strongly Disagree Disagree Indifferent Agree Strongly Agree

4.1

4.2

4.3

4 Results for questions relating to visualisations and finer aspects of the user interface.

47

0

1

2

3

4

5

6

7

Strongly Disagree Disagree Indifferent Agree Strongly Agree

5.1

5.2

5.3

5 Results for questions relating to control and interaction.

0

1

2

3

4

5

6

Negative Positive

1

2

3

4

5

Mean averages for each section of statements, giving a general impression of overall user experi-ences..

48

Appendix H: User Documentation

Introduction

The Liquid Brain Music application is a polyphonic audio synthesizer controlled by a set of artificial lifeformsknown as Cellular Automata. These Cellular Automata will evolve over time, their current state at any givenmoment affecting how the synthesizer generates sounds.

You, as the user, can determine the precise nature of the Cellular Automata’s affect on the synthesizer. This isdone by associating patterns of data in the Cellular Automata with the synthesizer’s control parameters.

Application Features

• 225 elementary 1D rules

• 225 totalistic 1D rules

• 16 assignable patterns

• 8 voice subtractive synthesizer

• 3 base waveform

• ADSR envelope

• Pitch LFO Modulation

Application Interface

Above is the application GUI, containing all of the information functionality to control the system from a singleinterface. It consists of 4 sub-windows :-

• Top-left window displays a graphical depiction of cellular automata along with any related information.

• Top-right window displays user-changeable parameters affecting only the currently selected voice.

• Right window displays user-changeable parameters affecting all voices.

49

• Bottom window displays keyboard controls and parameter tips.

Application Usage

To control the interaction between the synthesizer and the cellular automata, the user navigates the parameter listusing the up and down arrow keys. The currently selected parameter is indicated by an arrow in the parameterlist. Upon selecting a parameter, the left and right arrow keys can be used to adjust its value or assigned pattern.

Pattern Types

There are 16 selectable patterns, falling into two categories types, Run Length (abbreviated to RL) and BlockSize (abbreviated to BS). Both RL and BS patterns have an option of 4 sizes, each with 2 choices of colour.

A BS pattern counts the exact size of a chain of adjacent same-state cells. Take for example the binary string001111. A BS pattern would match this as 2 blocks of 0’s and 4 blocks of 1’s.

In contrast, a RL pattern counts adjacent cells with no regard to the size of the chain and allows for cells to becounted multiple times. With the previous example string of 001111 this would relate to the following matches:-

• 2 blocks of single 0s

• 1 block of double 0s

• 4 blocks of single 1s.

• 2 blocks of double 1s.

• 1 block of triple 1s.

• 1 block of quad 1s.

If these rules seem difficult to comprehend, an easier way to imagine them is as BS being strict and matchingonly exact results. RL on the other hand pays no regard to blocks or chains and simply tallies cells as it findsthem. As such, RL pattern matching tends to yield a higher value.

Cellular Automata Rules

The Page Up and Page Down keys be used to adjust the rule for the currently selected cellular automata, with theT key allowing the user to toggle between elementary rules and totalistic rules. Elementary mode will producemore unique patterns, yet results in a lot of unusable or blank rules. Totalistic mode in conrast, tends to producefewer blank rules, however the patterns it does produce are rarely unique and are often shared by multiple rules.

ADSR Mode

The ADSR Mode can be toggled on to apply the ADSR volume envelope, producing tones that build and decaywith varying volumes. When this mode is switched off, tones change as a direct influence of the cellular automataat a fixed volume, resulting in arpeggiator-like functionality.

Polyphony

The polyphony, or number of simultaneous voices, can be adjusted in the global parameters section of the interfaceto a maximum of 8. The user can switch between these voices by pressing the corresponding number from 1 to8 on the keyboard. The M key can be used mute/unmute the selected voice for precision editing.

Troubleshooting

• The application won’t open.If the application fails to load at all and your system meets the minimum requirements, attempt to updateyour OpenGL drivers.

50

• The application loads but crashes shortly after.Attempt to reinstall OpenAL drivers.

• The cellular automata doesn’t appear to be updating.It may be stuck in a blank rule. It’s a naturally occurring feature of cellular automata that some rules dieout extremely quickly, or in some cases fail to evolve at all. When this is the case the cellular automatadisplay may appear blank. To remedy this, simply change the cellular automata rule and/or press R toreseed a new set of cells.

• No sound is being generated.Providing the system has adequate audio hardware and related drivers, it may be the case that a blankrule is being accessed (see above) or that the selected parameters dictate low or minimal sound.

System Requirements

• 1.5GHz Intel/AMD processor

• 226MB RAM

• 4MB disk space

• OpenGL drivers and compatible graphics card

• OpenAL drivers and compatible sound card

51

Appendix I: Risk Analysis

As with any large project there’s always the likelihood of problems cropping up throughout the development,as such it’s important analyse any foreseeable risks and devise suitable contingency schemes. The followingassessments are calculated using the formula Likelihood× Severity = Significance and plotted in Figure 23 asa fuzzy set, which is used instead of a regular set:

“... to use other degrees of membership in addition to 0 (does certainly not belong to it) and 1(does certainly belong to it) ... in taking the degrees of membership from the compact interval[0,1]” (R. Kruse and Klawonn, 1994)

That is to say with a regular set, a risk can only fall under 3 very specific categories (low, medium or high) givingno distinction between a risk barely considered medium and one nearing high severity. By using fuzzy set theorythe severity levels are gradual and give a more precise indication of severity over the risk spectrum.

Risk Severity

Risk Task Description Contingency

1 3 Too many simultaneous instruments forsmooth playback.

Reduce the polyphony or remove heaviereffects processing.

2 3 Real-time audio too demanding. Fall back to none real-time and output toPCM file.

3 3 OpenAL buffers too large for efficientstreaming

Increase number of buffers to compensate.

4 5 Visuals are too demanding for real-timeaudio.

Fall back to lower quality visuals.

5 7 Range of pattern data too small for audioengine parameters.

Reduce polyphony or increase automatasize.

6 7 Pattern matching too demanding for real-time audio

Research and implement more efficientpatterns.

7 8 Real-time user input interferes with signalprocessing

Only accept user input before processingbegins.

12 34 567

Likelihood

12 34567

Severity

12 34567

Significance

Key

LowMediumHigh

Figure 23: Risks as fuzzy sets (see section 8.1).

52

Bibliography & References

AAAI-Music, 2007, American Association for Artificial Intelligence. Available:http://www.aaai.org/AITopics/html/music.html, [Accessed 9 December 2007].

Adamatzky A, 2001, Computing in Nonlinear Media and Automata Collectives. London: Institute of PhysicsPublishing.

Askoy S, 2005, Introduction to Pattern Recognitionn. Bilkent University.

Bentley P. J, 2002, Digital Biology. New York: Simon & Schuster.

Boehm B, 1988, Spiral Model of Software Development and Enhancement, Computer, 21 (5), pp 61–72.

Brian Eno, 1996, Generative Music. Available: http://www.inmotionmagazine.com/eno1.html, [Accessed 20October 2008].

Callahan P, 1971, The Game Of Life. Available: http://www.math.com/students/wonders/life/life.html,[Accessed 3 January 2008].

Codd E. F, 1968, Cellular Automata. London: Academic Press, Inc.

Cook P. R and Scavone G. P, 1995, Synthesis Toolkit. Available: http://ccrma.stanford.edu/software/stk/,[Accessed 16 October 2007].

CSounds.com, 2007, What is CSound? Available: http://www.csounds.com/whatis/index.html, [Accessed 16October 2007].

Dubois D, 1980, Fuzzy Sets and Systems: Theory and Applications. London: Academic Press, Inc.

Elliot J, ND, Cyclic CA Transmusical Renderings. Available: http://jmge.net/cyclic.htm, [Accessed 2 March2008].

Essl K, 2006, Generative Music. Available: http://www.essl.at/bibliogr/generative-music.html, [Accessed19 January 2008].

Francis E. M, 2007, Artificial Life Links. Available: http://www.alcyone.com/max/links/alife.html, [Accessed20 March 2008].

Gardner M, 1970, Life, Scientific American, 223 (October), pp 120–123.

Kuehnl E, 2007, A Brief History of Computer Music. Available: http://music.calarts.edu/ eric/cm.html,[Accessed 6 December 2007].

Lab M. M, 2007, Music, Mind and Machine Group. Available: http://sound.media.mit.edu/, [Accessed 10

53

January 2008].

Levy S, 1992, Artificial Life. London: Penguin Books.

Manning P, 1993, Electronic Computer Music. Oxford: Clarendon Press.

Miranda E. R, 2002, Sounds of Artificial Life. ACM.

OpenAL, nd. Available: http://www.openal.org/, [Accessed 15 October 2007].

Pinder M, 2007, History of the Mellotron. Available: http://www.mikepinder.com/mellotron.shtml, [Accessed9 January 2008].

Pressing J, 1992, Synthesizer performance and real-time techniques. Oxford: Oxford University Press.

R. Kruse J and Klawonn F, 1994, Foundations Of Fuzzy Systems. West Sussex: John Wiley & Sons.

Research M, 2000, KVR Audio. Available: http://kvraudio.com, [Accessed 5 January 2008].

Sangild T, 2002, The Aesthetics of Noise. DATANOM.

Sarkar P, 2000, A Brief History of Cellular Automata, ACM Computing Surveys, 32 (March), pp 80–107.

Sound On Sound, 1999, Synth Secrets. Available: http://www.soundonsound.com/sos/allsynthsecrets.htm,[Accessed 21 October 2007].

Stanford University, 2007, Microsoft WAVE Soundfile Format. Available:http://ccrma.stanford.edu/courses/422/projects/WaveFormat/, [Accessed 22 January 2008].

Tyler T, 2007, Cellular Automata. Available: http://cell-auto.com/, [Accessed 1 November 2007].

Wainright R. T, 1971, LIFELINE Issue 1. Available: http://members.aol.com/life1ine/life/page1.htm,[Accessed 3 January 2008].

Wolfram S, 2002, A New Kind of Science. Illinois: Wolfram Media.

Wolfram S, 2005, Wolfram Tones. Available: http://tones.wolfram.com, [Accessed 12 October 2007].

54