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: