Conditionals for Pure Data: Interactive tutorial 2: Using the ‘expr’ object.

This is the second interactive tutorial regarding making your own conditionals in the Pure Data open-source programming platform. This time the ‘expr’ object is used.  Click here to download. Please note that this particular object chews up more CPU than those featured in the previous tute. You will also first need to have Pure Data (Pd) installed on your computer to use this app (it’s free). The reason for emphasizing the use of conditionals in Pd here is twofold: (i) functions that exploit variables and probability form the bedrock of simple generative music programs, and (ii) unlike Max/MSP, Pure Data doesn’t come with conditionals included: you have to make them yourself or use someone else’s.

Conditionals are decision-making blocks of code: something like rules in a game. You can tell parts of your program to do something WHEN or IF specific criteria have been met, or ELSE to do something different.

When making a generative music program for the first time, there’s no need to worry too much about decisions regarding each conditional’s behaviour or where these little blocks of code fit into the overall program. What’s most important is that they’re there at all. You can have a lot a fun just taking any music programs you might already have and letting the (numerical) output of one part of the program influence the behaviour of another. In this way, you can automate small sections of a program and, bit by bit, get a feel for what conditionals can do. The more parameters and triggers that you connect, the closer you get to creating a fully-fledged generative music app.

Each of the conditionals illustrated above (and combinations thereof) can be embedded within ‘pd objects’ (or as ‘abstractions’) which are something like Pd’s equivalent functions. This will not only make your Pd patches cleaner, but you’ll see similarities with the architecture of modular synthesisers, where you can have fun plugging ‘this’ into ‘that’ to see what happens.

If you’re a John Cage type, then as long as the program flows well you’ll probably be happy with the results, regardless of the aesthetic feel. If you’re more of a Brian Eno, then you’re likely to be more selective. In the latter  case, you might like to try out different combinations of conditionals, as well as, their relationship to the various parameters being influenced, such as those belonging to: tone generators; filters; pitches; the triggering of sequences (and sequencers); (opening/closing) gates (‘spigots’ as they’re called in Pd); tempo; choosing pathways (form, challenge ‘levels,’ duration etc), or anything you can imagine! Tinker away until you find results that please you.

To get more information regarding what each discreet Pd object can do, control+click on the relevant object (Apple users). Enjoy.

The expr object is created by Shahrokh Yadegari. The downloadable interactive tutorial is (cc) 2019 Marshall Heiser (Attribution 4.0 International). This license lets you distribute, remix, tweak, and build upon my work, even commercially, as long as you credit me for the original creation. Any derivatives will also allow commercial use. Click here for more licence details.



Conditionals for Pure Data: Interactive tutorial

Computer programs need to determine how to proceed at certain points in their program flow, depending on whether certain predetermined (or variable) conditions have been met or not. Such operations are a mainstay of computing and are known as a “conditional” test. For example, when a condition has been met, a result of TRUE (“1”) is produced, otherwise a FALSE (“0”) message results: these are known as Boolean values. Conditional tests (or conditionals for short) are particularly useful in programs such as “generative” music compositions, where the “rules of the game” are predetermined, and require no further input from the programmer after the piece has started.

The conditionals provided in Pure Data (Pd) are very basic, consisting of simple relational operators (such as == [“equals”], != [“not equals”], <, <=, >,  >=) and logical operators ( && [“and”],  || [“or”]). In order to make your own conditional objects that match the complexity of what Max/MSP offers as standard, you’ll need to have a look at the 9 (interactive) examples illustrated above. By changing the values in the yellow boxes, each test will produce one of two possible outcomes.

Whereas Pd’s relational and logical operators produce Boolean values, a “Select” object is necessary in order to produce a “bang” result (which is often necessary when programming in Pd). In the examples provided, the select object has been used to produce either a bang (only if a TRUE value results) or two different bangs (one for TRUE and another for FALSE).

Click here to download the interactive tutorial. Please note, you’ll first need to have Pure Data (Pd) installed on your computer to use this app (it’s free). Once you understand how each of the provided complex conditionals work, you can then embed them in their own subpatches, making your patcher window much less cluttered (as illustrated in the orange square next to example 1. Click on the pd X==Y object to see “inside”). In order to get more information on what each discreet Pd object can do control+click (Apple users*) on the relevant object. Enjoy.

The downloadable interactive tutorial is (cc) 2016 Marshall Heiser (Attribution 4.0 International). This license lets you distribute, remix, tweak, and build upon my work, even commercially, as long as you credit me for the original creation. Any derivatives will also allow commercial use. Click here for more licence details.


Pure Data: Reference Card

If you use the Pure Data (Pd) visual data-flow programming platform, or plan to, then this downloadable pdf will be essential. It outlines the correct names and functions of the Pd “objects.” Without this chart you’ll find yourself forever stalling, as you try to find that object you need and can remember by function, but not quite by name. To create an object using this chart, simply enter “edit” mode (command-click + E)* and command-click + 1 on the “patcher” window (not the Pd window), or select “object” from the “Put” menu. Type in the object’s name and you’re done. To find out more about what each object does simply control-click the object and select “help.” This very useful reference tool was kindly created/shared by Karim Barkati and may be freely distributed (see license details below).

CLICK HERE to download the Pure Data Reference Card.

*My apologies to all the PC users out there. Since Apple computers have become the standard for the audio industry I’ve adhered to this standard for the sake of simplicity (please use your PC equivalents).

Copyright (c)  2010 Karim Barkati <>. Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.3 or any later version published by the Free Software Foundation; with no Invariant Sections, no Front-Cover Texts, and no Back-Cover Texts.


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.


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.


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
Z = STOP (repeat for CLEAR)


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


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.


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.


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.



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.