Cellular Automaton Music

This video presents an instance of two discreet apps programmed by Marshall Heiser (using the Processing & Max/MSP platforms respectively) and interfaced with the Open Sound Control (OSC) protocol. LEVEL: Intermediate. LENGTH: 3min. 38 sec. (No voice over, music starts at 0.49 sec.).

Getting Processing to talk and Max/MSP to listen.

This video demonstrates a computer music project I created in order to see if I could get two different programming environments to “talk to each other” successfully – or rather, have one talk and the other repeat parrot-fashion. The two platforms involved were Processing 2 and Max/MSP 6, featuring a cellular automaton app and frequency modulation (FM) synthesiser made from the ground up respectively.

Rationale

I chose to make a cellular automaton app for the data generator partly to see if I could make up a set of rules that would produce aesthetically pleasing pitch and rhythm events with minimal input from the user. Unlike some music produced by similar apps I’d previously tried (which looked good but sounded less so), I aimed to fashion one that would generate events that struck a pleasing balance between variation and repetition. I also wanted to make an app better suited to my own personal needs (for e.g., one able to send data to a variety of destinations, potentially over a network). It was also a fun challenge to see if I could program something of this complexity (well…complex for me anyhow) using Processing.

The Interface

The linking of the two apps was achieved using the OSC protocol, which can be thought of as a internet-friendly alternative to the comparatively archaic Musical Instrument Digital Interface (MIDI). The automaton app outputs a number between 0 and 8 each time a moving coloured square hits the edge of the grid. These numbers are then converted to form a steps within a pentatonic scale inside Max, but can easily be set to any desired configuration.

The code

The code for the automaton component was developed by looking at a variety of open source “Game of Life” Processing sketches as a starting point. This mathematical problem, originally developed by John Conway, allows for any single cell on a grid to be in one of two possible states (i.e., “dead” or “alive”), based on the previous state of its neighbours. When viewed over successive iterations, this “zero-player” game produces quite complex behaviour using very simple rules.

Rules

By comparison, my automaton (inspired by the “Otomata” app, Bozkurt, 2011) produces behaviour of a vastly less complex nature than Conway’s (thus is the want of the minimalist aesthete). This rule-set produces patterns with a certain degree of repetitiveness (pleasing to the ear), depending upon the initial “seed” (starting pattern) chosen by the player. For each cell, one of six possible states are adopted as a result of its “neighbours'” previous states.

Depending upon their colour, green, brown, peach or purple cells each “pass” their current state to an adjacent cell (see below). If passed on to a cell at the edge of the grid however, each is sent back in the opposite direction, with its colour modified accordingly. When more than one neighbour is non-blue, subsequent collisions (indicated by the colour black) are either reversed or cancelled out. This latter condition is where my app varies from “Otomata,” and is responsible for the important variation element.

User Interface

1 mouse click on any cell = green (move west)
2 clicks = brown (move east)
3 clicks = peach (move north)
4 clicks = purple (move south)
5 clicks = blue

Space Bar = START
X = PAUSE
Z = STOP (repeat for CLEAR)
S = SEP THRU

Playframing

Both negotiating the rules of the game and implementing them, are good examples of playframing and, in this case, a lengthy process (depending upon one’s programming skills). The task of designing/programming the whole system represents one over-riding level of frame negotiation. The creative choices made by the player with regard to planting the seed and controlling any other timbre-related parameters (in subsequent “receiver” programs, perhaps in real-time) represents a sub-level of negotiation with the “givens” of the system.

(c) 2017 Marshall Heiser

References:

Bozkurt, B. (2011). Otomata. [Computer software]. Istanbul: Earslap.

Gardner, M. (1970). Mathematical games: The fantastic combinations of John Conway’s new solitaire game “life.” In Scientific American, 223, 120-123. London, England: NPG.

banner_P_M_P_P_3

Simple SATB Sequencer

This is a demonstration of a sequencer app built by Marshall Heiser using Max/MSP and the “playframing” approach to creative practice. The video features an impromptu, unedited jam session by the author with the program.

Background

In the 21st Century, popular music creative practice, dissemination, and performance/reception have all been transformed by the rise of the internet, youtube and a general “democratisation of technology” (a term coined by Leyshon, 2009). Popular music making today is seen as a recreational activity for all to engage in (even for “non-musicians”) as much as it ever was a passive one. As a musician and songwriter, I once bemoaned the fact that the performer/audience, producer/consumer dichotomies (amongst other paradigms) had broken down to a point where it became increasingly difficult for individual’s identifying as a practitioners of music to justify their place in society. Now I embrace it.

The game has changed

Around about 2010 I finally accepted that the old music industry ways had passed (at least as the main focus for practitioners). And with that acceptance of the death of the old came the birth of something much, much more satisfying. I had realised for some time that by focusing more on the process of music-making I could reclaim the joy and innocence of music making time and time again. Each piece of music could be approached as a game with its own rules that were totally binding, but only within the scope of that particular piece. Instead of identifying as a practitioner of music, I now saw myself as a practitioner and advocate of play.

At that time, I had discovered Max/MSP, the perfect system for a game-like approach to music making. Instead of trying to using Digital Audio Workstations and instruments that offered too many creative possibilities, I could now build my own virtual systems that were limited in scope according to the needs of the piece of music in question. Each with their own rules of engagement, and with interfaces of my own design that attempted to control the user much as the user would attempt to control them.

The rules of the game

The rules/limitations of this featured program (Simple SATB Sequencer) are what makes effortless action possible and results in the musical statement’s balance of coherency/variation when engaged by the user in a sensitive (rather than “expert”) fashion. Best results are obtained by inputting less notes in each sequencer and focusing attention upon the relationships of the four voices in a “sum-is-greater-than-the-parts” manner. Negotiating the rules (both as designer and user) is a form of “playframing” (a term coined by Sutton-Smith, 1979).

So what are the rules of this particular game (Simple SATB Sequencer)?
1) Four individual (monophonic) voices, each capable
of inputting eight notes in sequence
2) Four pitch steps per voice
3) Each sequence voice’s cycle can be put out of sync with the others by a “quarter measure”
4) Overall pitch scale can be chosen (from a set of presets)
5) Cycle of each sequence voice can run through its series of notes in one of three ways: up(1-8), down (8-1) or up/down (1-8,8-1)
6) The pitch range of each sequence voice is limited to something similar to traditional soprano, alto, tenor & bass.
7) Each voice has it’s own discreet synthesiser sound generator
8) The timbre of each voice can be manipulated easily via choice of waveform type.
9) The timbre of each voice can be further manipulated easily via filter settings (and choice of filter type)
10) The articulation of each voice can be manipulated (less) easily via a set of presets/ graphical user interface embedded in a sub-window (not being able to access this feature from the main GUI window actively discourages the user from using it too much).

Text: (c) 2016 Marshall Heiser, Max/MSP Program: (CC BY 3.0 AU) 2013 Marshall Heiser, Music:  (c) 2013 Marshall Heiser.

banner_P_M_P_P_3

References:

Leyshon, A. (2009). The software slump?: Digital music, the democratisation of technology, and the decline of the recording studio sector within the musical economy. InEnvironment & Planning. A, 41 (6), 1309 – 1331.

Sutton-Smith, B. (1979). Play and learning. New York, NY: Gardner Press.