game of life - Programme notes

Harry Brokensha

game of life an algorithmic composition in Max/MSP Conway’s Game of Life, also known simply as Life, is a cellular automaton devised by the British mathematician John Horton Conway in 1970.1 The universe of the Game of Life is a two-dimensional orthogonal grid of square cells, each of which is in one of two possible states, alive or dead. Every cell interacts with its eight neighbours, which are the cells that are horizontally, vertically, or diagonally adjacent.

At each step in time, the following transitions occur: 1 2 3 4

Any live cell with fewer than two live neighbours dies, as if caused by under-population.

Any live cell with two or three live neighbours lives on to the next generation.

Any live cell with more than three live neighbours dies, as if by over-population.

Any dead cell with exactly three live neighbours becomes a live cell, as if by reproduction.

Concept The main draw of this automaton as a model for a composition is the organic results that it produces.

Watching the process evolve is akin to observing a petri dish full of living organisms, as bundles of Life’s ‘cells’ multiply, split and interact with one another in the course of the pattern. Organicism, then, became the centre focus of the project; my intention became to design a piece that organically creates itself while following and representing the resultant patterns and structures that emerge in a grid of the Game of Life.

The visual programming language Max allows the composer to access powerful routines (known as objects) designed to work with interactive music and multimedia. One of these objects is jit.conway, which ‘performs Conway’s Game of Life on incoming 1- or 4- plane character matrices.’2 In Game of Life, jit.conway outputs a 1-plane matrix of 16x16 tiles (coordinates (0, 0) to (15, 15)), which is visually represented in a jit.pwindow object below. The rate at which the Game of Life progresses is dictated as a division (selectable by the user) of the tempo given to it by a host DAW application. Logic Pro X to supplies the tempo as well as to handle the output of sounds which will be detailed later.

Rather than beginning the Game of Life with one set pattern and letting it evolve without further input, which would have ended fairly quickly with just a 16x16 grid, the best option was to create a function to input common patterns at specific bar intervals (the number of bars in between inputs is selectable by the user.) The patterns chosen are a variety of commonly used Life patterns, which have different characteristics under the rules of Life: still lifes, such as the block, (see fig. 1), which remain stationary, oscillators, such as the pulsar, (see fig. 2) which are patterns that oscillate, and gliders, such as the lightweight spaceship, (see fig. 3) which translate across the grid with constant velocity.

Choosing the Sound The ‘sound’ of the program needed to be as organic as possible, to fit with the concept of the composition, while still reflecting the distinctly artificial algorithmically-controlled process of evolution that Life presents.

The idea of creating a post-humanist orchestra of computer-controlled sampled acoustic instruments to ‘play’ the composition greatly appealed as a means of achieving this. The orchestral sounds used are sampled libraries of human performers playing each note with perfect tuning, timing and articulation; the end result being an organic sound of acoustic instruments being ‘played’ perfectly and artificially by the computer.

Thus the Game of Life is reflected in the music; a fusion of natural and unnatural, and a glimpse of a future more and more intertwined with artificial intelligence.

Gardner, Martin (October 1970). Mathematical Games – The fantastic combinations of John Conway's new solitaire game "life". Scientific American 223. pp. 120–123.

1

Max/MSP online documentation for the jit.conway object can be found at the webpage: https:// docs.cycling74.com/max5/refpages/jit-ref/jit.conway.html 2

Modules The main bulk of the program deals with interpreting the data from this matrix in several different ways.

Four main instrument modules create the notes of the piece, which are sent to the host DAW as MIDI messages. Dynamics (sent as MIDI velocity and expression messages) are extracted from the matrix by way of another module, and individual instrumental phrasing and rhythms are selected by random and probabilistic functions which can be set by the user before or during the piece. Finally, the harmonic aspect to the piece (and thus part of the note choice aspect, as it affects the pitches obtained by the interpretations of the matrix) is determined by a module that switches between modes at certain bar intervals. The inner workings of each of these will be discussed in this section.

Mode Switcher: utilising the modal_change object from The Modal Object Library (2006), from the EAMIR SDK

This object from The Modal Object Library 3 takes in messages for key and mode, and outputs a list of 7 numbers from 0 to 12 corresponding to the pitch values of the scale. It then stores these numbers in a coll object so that they can be used throughout the program to sync up all the note content into the right mode. My addition of a module on top selects a new key after a specific number of bars have elapsed.

Chord Generator The Chord Generator takes the matrix output from jit.conway and processes individual values within it to create 6-note chords. First in the chain is the subpatcher 6ChordGenerator. This first inputs the raw matrix data as a list of numbers (beginning with (0, 0), then (0, 1) and so on), de-interleaves the list into two lists. I then used zl.compare to compare the two lists and output a the indexes of the changed values in each list to a new list. The resulting numbers are scaled to playable MIDI pitches, scrambled and then a slice of the first (scrambled) 6 numbers is taken from this new list.

These are the notes to be played by the chord generator, but they firstly each pass through an instance of the Modal Object Library object modal_filter, which moves chromatic MIDI pitches into the nearest pitch of the selected mode. These 6 pitches are then packed and interlaced into a final list alongside their respective velocities, which are determined by the scaled output of the number of live cells in the grid.

The “6ChordGenerator� subpatcher 3

Found at http://www.eamir.org/developers/modal-object-library

This list is then routed into another subpatcher 6ChordOut, which processes and formats the individual MIDI note messages so that they can be sent out to the host DAW.

The “6ChordOut” subpatcher To add rhythmic characteristics to the Chord instrument module, a rhythmic ‘doubler’ delays each chord message by a multiple of the selected division of the beat, up to three times, in order to create up to 3 measured repetitions of the chord.

For example, if the chord doubler is set to 1/16, it will delay each message by 1, 2 and 3 semiquavers.

The on-the-beat message that is delivered every time Life progresses, as well as repetitions 1 to 3 can all be individually activated or deactivated by the user by four switches underneath the division setting in order to create interesting rhythms.

The “6ChordDoubler” subpatcher

The full Chord module in the main patcher window

Melody Generator The Melody Generator uses a different method of interpreting the matrix data. Instead of interpreting the raw matrix values, it instead produces MIDI messages by calculating the difference between frames of the visual output from the jit.pwindow object.

The full Melody module in the main patcher window The subpatcher framediffCalculator takes the visual information from the pwindow object, and calculates the absolute values of difference between the current and last frames. A jit.3m object reports the mean value of this, and then a series of functions are applied to translate this number into a usable MIDI note message. It is once again passed through the modal_filter object before being passed out of the subpatcher.

Subpatchers framediffOut and voiceDelayer allow for rhythmic and harmonic interest in the part. They work in much the same way as 6ChordOut and 6ChordDoubler; formatting the MIDI messages for output to the host DAW and allow a delayed second melodic voice to be applied. Additional in the Melody Generator is a transposition changer, which transposes the second voice by the number of semitones chosen in the number box.

The “framediffCalculator� subpatcher

Bass line Generator The Bass line Generator works in a different way to the first two modules; it takes data from the modal_change object directly when it changes key, and creates a rhythmically dynamic moving bass line out of pitches provided by the current scale.

The full Bass line module in the main patcher window

The “bassnoteGenerator” subpatcher This subpatcher takes pitch value information from the modal_change object, takes a random three pitches from the scale, scrambles them, and plays them out in order. The rhythm that they are played out in is determined by the number of bars between mode changes as dictated by the dropdown box in the Mode Switcher module. If ‘2 bars’ is selected, for example, the bassnoteGenerator subpatcher splits 2 bars into three chunks; for example, 1 bar, 1/2 bar and 1/2 bar. The resulting rhythm of the bassline for the next two bars will be semibreve, minim, minim. These messages are sent to the subpatcher bass1Out to be formatted as MIDI messages for the host DAW.

Percussion Generator

The full Percussion Generator in the main patcher The last generator creates percussive rhythms to complement the rhythms generated by the other parts. It runs on the tempo of the progression of Life, and creates notes based on its own probabilistic decisionmaking.

Probability tables for each drum A counter object counts through from 1 to 4 each time a beat passes. On beat 1, the sel object bangs the first table. The first table has 4 values stored in it: 0, 1, 2 and 3. As is clear from the diagram, the top left table has a slightly higher chance of outputting values 0 and 2 than it does 1 and 3. The resulting value is passed to a second sel object, which depending The “drumGenerator� subpatcher on if it receives a 1, 2 or 3 bangs MIDI pitch messages 65, 40 and 48 respectively which correspond to specific drums in the Logic drum sampler. A 0 gets passed out of the last output, which does not connect to a drum, so it is a silent note. The right-hand side of the subpatcher does the same process, but with no probabilistic decision-making, instead using random selections to choose drums. These two different processes can be switched between in the main patcher window.

Instrumentation Switcher The Instrumentation Switcher decides which instruments should be playing at any one time. Four sliders control the maximum number of beats that random functions in the InstrumentDecider subpatcher can choose from and thus affect how long the instrument is likely to be playing for (or not playing for). If 16 is selected for the percussion function, then the minimum number of beats the instrument might play for on its next activation is 5 and the maximum 19 (5 is added to the output of the random function as an output of 0 would confuse the decider and also so that the minimum number is 4.)

The full Instrumentation Switcher in the main patcher window

The “InstrumentDecider” subpatcher

The “onoffdecider” subpatcher The subpatcher constantVoice ensures that there is at least one voice activated at any one time. While in a standalone piece, silence (no instruments activated) might be a desirable outcome of the random functions, this decision to better complements the constant motion of Life.

The “constantVoice” subpatcher

Dynamics for Melody, Bass, and Percussion This module creates dynamic changes in the melody and bass parts, which are sustained unlike the chords. It smoothes the output of the velocity function (subpatcher velocityCalculator) which normally changes on each beat, creating dynamic changes that are jerky and inorganic. Using the values of the number of white (live) cells in the grid, a line object creates a timed ramp of exactly 1 beat (the length of one frame of Life) between each consecutive value received. The more live cells in the grid, the louder the dynamic.

The full Melody and Bass dynamics module in the main patcher window

Host DAW synchronisation/metronome

The full host synchronisation/metronome module in the main patcher window This section of the program collects tempo information from Logic Pro X via ReWire and uses it to send a metronome to the other modules. A subpatcher divisions timescales the output of a hostphasor~ object to a variety of different divisions so that the user can set the speed of Life’s progression. This method, rather than dividing the beat output of the hostsync~ object, provided a more accurate synchronisation and so a bang output from this subpatcher is used as the main metronome for the other modules.

The “divisions� subpatcher

The Game of Life and Pattern Drawing This section of the patcher runs Life and draws patterns at specific coordinates. The dropdown box at the top selects the number of bars before a new pattern is drawn into the matrix.

The full Game of Life module in the main patcher window

Accompanying CD The Game of Life CD provided with the portfolio contains two folders. The first contains the Game of Life Max 7 patcher, text file and EAMIR SDK. The second contains a demo of a run of Game of Life, both with and without the grid visuals, as well as another run using different instruments and a short sample of what the probability drummer can produce when used with electronic drums instead of acoustic drum samples.