Computation as Material in Live Coding

Author(s): Till Bovermann and Dave Griffiths

Source: Computer Music Journal , Spring 2014, Vol. 38, No. 1 (Spring 2014), pp. 40-53
Published by: The MIT Press

Stable URL: https://www.jstor.org/stable/24265531

REFERENCES
Linked references are available on JSTOR for this article:
https://www.jstor.org/stable/24265531?seq=1&cid=pdf-
reference#references_tab_contents
You may need to log in to JSTOR to access the linked references.

JSTOR is a not-for-profit service that helps scholars, researchers, and students discover, use, and build upon a wide
range of content in a trusted digital archive. We use information technology and tools to increase productivity and
facilitate new forms of scholarship. For more information about JSTOR, please contact support@jstor.org.

Your use of the JSTOR archive indicates your acceptance of the Terms & Conditions of Use, available at
https://about.jstor.org/terms

The MIT Press is collaborating with JSTOR to digitize, preserve and extend access to Computer
Music Journal

This content downloaded from

213.55.244.33 on Fri, 22 Apr 2022 15:47:00 UTC
All use subject to https://about.jstor.org/terms
Till Bovermann* and Dave Griffiths1
"Institute for Time-based Media
Computation as Material
Berlin University of the Arts
Grunewaldstrafte 2-5 in Live Coding
10823 Berlin, Germany
t.bovermann@udk-berlin.de
fFoAM vzw
Koolmijnenkaai 30-34
1080 Brussels, Belgium
dave@fo.am

Abstract: What does computation sound like, and how can computational processing be integrated into live-coding
practice along with code? This article gives insights into three years of artistic research and performance practice wit
Betablocker, an imaginary central processing unit architecture, specifically designed and implemented for live-coding
purposes. It covers the themes of algorithmic composition, sound generation, genetic programming, and autonomous
coding in the light of self-manipulating code and artistic research practice.

Computation is odd. Seventy-five years since the to grasp it and try to gain understanding into what
first programmable computer, the Zuse Zl, we it looks like (McLean et al. 2010) as well as what it
continue to fail to fully grasp computational besounds like.
havior. This lack of understanding results in a In light of these considerations, we introduce
struggle to keep unseen ramifications of our deBetablocker, our contribution to the field of artistic
cisions under control. Faced with such a strangeunderstanding of low-level computation (Howse and
Kemp 2006; Lehtomaen 2011), a field that research
and yet essential beast, the only sane strategy is to
try to tame it. The field of software engineering isinto digital sound synthesis discovered as early
littered with concepts such as regression testing, as in the 1970s (Berg 2009) and has been continually
type checking, white rooms, sandboxing, contracts,
investigated, for instance, by implementations of
and encapsulation—all attempts to cope with the
instruction synthesis in SuperCollider (Collins
fact that we fail to successfully understand how a 2008). Betablocker intersects live-coding practice
mundane machine of sufficient complexity will act and brings to light many different strategies for
when it is programmed by a human. presenting computation as tangible material—
Live coders look this beast straight in the eye.by making computational processing as much a
When live coding performers take to the stage andpart of live coding as the code that describes it,
project their screens, they invite us to join them a field investigated, e.g., in ixi lang (Magnusson
in attempting to understand this intricate dance2011) and Fredrik Olofsson's Arduino live coding
between human and machine (Collins 2011). Be (www.fredrikolofsson.com/fOblog/index.php?q=
yond performance practice, live coding is a broad node/590). Built around this element are a variety of
applications for testing, exploring, and performing
field that can be viewed from many different angles.
From rehearsed public performances, collaborativeboth scientific and artistic investigations.
improvisations, and individual sound explorations This article collects experiences, challenges,
to its utilization as a method in science, live coding
and insights gathered by the two authors over the
has been used in manifold applications. All these course of three years, while we designed imaginary
variations of the original theme share elements ofcentral processing unit (CPU) architectures and
live coding as they are featured in the TOPLAP man investigated the combination of both established
ifesto draft (www.toplap.org/wiki/ManifestoDraft, and emerging live coding techniques. Central to
see also Ward et al. 2004). Live coding attempts tothe work presented here is the use of live coding,
treat computation as a material on its own terms, performance contexts, and exploration strategies
in order to gain a better understanding of behavior
emerging from simple instruction sets when given
Computer Music Journal, 38:1, pp. 40-53, Spring 2014 self-modification abilities. This leads us towards a
doi: 10.1162/CC)MJ_a_00228
© 2014 Massachusetts Institute of Technology. kind of second-order live coding where, beginning

40 Computer Music Journal

This content downloaded from

213.55.244.33 on Fri, 22 Apr 2022 15:47:00 UTC
All use subject to https://about.jstor.org/terms
with a blank slate, programs written a few minutes the .NET Common Language Runtime) is that every
ago interact and interfere with the live coding of possible combination of values is a valid, executable
subsequent programs, or even write programs all on program and that each of these values is interpreted
their own. either as an instruction, an address, or a data item.
This article starts with an introduction to the Regarding the instruction table, we differentiate
Betablocker core technology, followed by a back between the core set, which consists of 22 dis
ground section featuring a historical overview. After tinct instructions, and various extensions to this
that, we describe our findings and explorations with set, which, depending on the actual application,
regard to Betablocker, and we give insights on how introduce features such as playing a note (NOTE)
its behavior influenced our live coding sessions. or copying information to the output pins of an
This is followed by a report on more than three AVR microprocessor (OUT). An overview of the
years of performance practice in Betablocker live instructions is given in Figure 1. As there are no
coding. The article concludes with a discussioninstructions,
and interrupts, or error states telling the
outlook on future work. engine to halt, programs will continue to run until
externally terminated. They will tend to converge,
however, into a (possibly complex) stable repetitive
Betablocker Core Technology behavior, including infinite loops.
A thread executes code stored on the heap. The
The core of all investigations described in this program counter pC stores the current position (i.e.,
article is the Betablocker engine, a highly simplified,the instruction it is currently evaluating). The stack
multi-threaded virtual machine. finally serves as a temporary private storage for
The Betablocker engine consists of (1) a heap a thread, not addressable by other threads. Stored
with 28 = 256 addressable slots to store 8-bit valuesvalues are accessed by either popping an item from
(bytes); (2) an instruction table linking a byte to anthe stack to a given address or to the indirect location
atomic instruction; and (3) a number of independent specified by a given address (e.g., POP POPl), or by
threads, each with an 8-bit program counter (pC) pushing a value to the stack in immediate, literal,
pointing to an address in the heap, and a stack of or indirect mode (PSHL, PSH, PSHI, respectively).
eight bytes. The resulting state vector consisting All mathematical processes operate using the stack
of a heap, along with a set of stacks and program rather than heap memory directly, so the resulting
counters (one per thread), sufficiently represents thelanguage is close to the operation of the Forth
whole Betablocker engine. programming language (Rather, Colburn, and Moore
The heap is where all data is stored. Following 1993).
the von Neumann architecture (von Neumann
1993), Betablocker computation does not make
any distinction between a program (i.e., values Background and Historical Context
representing instructions) and data (i.e., values
on which the program operates). The notions ofBetablocker first came to life in 2006 as an attempt at
code, data, and program are, therefore, synonymous a live-coding system controlled by a gamepad, using
in systematic and structural terms. They differ, the gaming engine Fluxus (www.pawfal.org/fluxus/).
however, in their semantics. Particular attention It was inspired by a discussion on the TOPLAP mail
has to be given to the fact that, although a specific ing list about virtual machines, and by games such
part of the data stored on Betablocker's heap is meantas Mr. Driller. What was interesting about the Mr.
to be a program, by definition the possibility exists Driller game was the mechanism of colorful blocks
that it will be altered (e.g., by a separate process interacting with each other and setting up chain re
running independently on the same heap, or evenactions by (www.ign.com/games/mr-driller/dc-14308).
itself). On the other hand, a critical difference fromCore Wars (www.corewars.org)—a game where
other virtual machines (e.g., Java virtual machinecontestants
or write simple programs that battle

Bovermann and Griffiths 41

This content downloaded from

213.55.244.33 on Fri, 22 Apr 2022 15:47:00 UTC
All use subject to https://about.jstor.org/terms
Figure 1. Betablocker
instructions.
Instruction Set
ORG Set address start
o 0x01 'beginning of program).
m n nQ at location specified by
EQU Push 1 if top two stack
❖
CZZ)
cud n items are equal, 0
uxuz otherwise. Pops 2.
JMP Jump program counter
r>Yn-3 to location specified by
uxud the argument.
(—>
JMPZ Jumps if top of stack is
0x04 zero' Pops 1 item' <x>
P5HL Push argument on to
oo
0x05 stack 'Push literal).
PSH Push byte at address
0x06 9iven by the argument. o n n items, ANDs them
□
PSHI Push byte pointed to by
n n7 byte at address given by
uxu/ argument (indirect).
POP Pop stack byte to address
0x08 given by argument.
to gain memory footprint over each other—was
also an important inspiration, both in terms of
domain-specific low-level languages, and in terms
of imaginary hardware.
From a musical point of view, Betablocker can
be viewed as a tool for algorithmic composition
(Maurer 1999) and simultaneous sonification and
visualization of process. It is also inspired by
nonlinear and stochastic synthesis techniques as
described by Xenakis (Xenakis 1971; Luque 2009).
Betablocker's development was driven by a need
to escape certain programming conventions in live
coding performances—for example, by removing
the reliance on the combination of keyboard and
mouse. An unintended side effect was the ability
to remove the laptop entirely from focus—with
a long, universal serial bus (USB) cable, at times
we could join the audience with the gamepad
and use the projection screen for live coding. The
language and concept of byte-code level visualization
and icon-based assembler programming was initially
motivated primarily by these considerations. Later,
after moving to dedicated game hardware, it became
more obvious that the musical and artistic scope
42 Computer Music
This content downloaded from
213.55.244.33 on Fri, 22 Apr 2022 15:47:00 UTC
All use subject to https://about.jstor.org/terms
POPI Pop stack byte to address NOT Bitwise NOTs the top
uxua argument (indirect). 0x11 stackbvte
ADD Pops the top 2 stack ROR Bitwise rotates the top
n n items, adds them
uxud and pushes the result. o r. 1 -j stack byte by bits specified
uxi*: by the argument (right).
SUB Pops the top 2 stack ROL Bitwise rotates the top
n nh items, subtracts them
uxud ancj pUShes the result. 0 C I o stack byte by bits specified
uxu by the argument (left).
1i
INC Increments the top stack PIP Increments byte specified
0x0c bytebyone' 0x14 by argument.
DEC Decrements the top stack PDP Decrements byte specified
0x15 by argument.
OxOd bytebyone'
AN D Pops the top 2 stack o DUP Pushes a duplicate of the top
uxue and pushes the result. o 0x16 stackbvte
OR Pops the top 2 stack NOTE Pops the stack and plays the
§
Oynf 'tems, 0Rs them 01 7 current sample at a frequency
uxur and pushes the result. UXA ' specified by the byte.
XOR Pops the top 2 stack VOX Pops the stack and uses the
nvin items, XORs them
ux±u and pushes the result 0 DvlH byte to choose the sample to
uxl° play at the current frequency.
of the technique were also worth pursuing in their
own right, leading to its later use as a sound
generation engine, as embedded hardware, and as
robotics.
Live-Coding Philosophy and Aesthetic Findings
Betablocker is distinct from other approaches to
computational machines in several aspects. In the
design of Betablocker, the ability to observe com
putational behavior was an essential goal, whereas
the result of the computation (and therefore process
optimization) played a minor role. Furthermore,
Betablocker is implemented as a software emulation
and can be modified easily. This allows alteration
regarding introspection (by adding probes) and cus
tomization (by altering the instruction set). Last
but not least, compared with common micropro
cessor architectures such as the x86 (Alpert and
Avnon 1993) or even reduced instruction set com
puting (RISC) microcontrollers (Kane 1988) such as
the Atmel AVR, Betablocker's architecture is kept
minimal. Operational complexity arises from the
Journal
 Figure 2. Soundcheck.

induced data and its processing rather than from theSoundcheck

system's architectural features.
The character of Betablocker influences not
only the sonic results of a live coding session but
f^fRbWgMM^Ree
also its overall structure. Due to potential process
complexity it is possible to start with a blank page,
as proposed in the TOPLAP Manifesto draft, and
and manually entering programs, byte by byte. The
quickly build interacting software agents that gain
sufficient complexity to result in an interestingprograms trigger synthesis patches, while modifying
output while remaining controllable. themselves and each other. Bytes used as address
We describe our findings and explorations withlocations are visualized literally as pointers—
regard to Betablocker in the following paragraphsarrows indicating the addresses in memory they
and give insights on how its behavior influenced are referencing. Eventually, between the quantity of
our live coding sessions. As we used Betablocker self-replicating fork bombs, sequencers interpreting
mainly in two perceptually contrasting modes—a memory as percussion triggers, and programs busily
rhythmic mode, which slowed down processing in reversing the contents of memory, the activity
order to perceive it, and an audio mode, speedingreaches a level where the performer is confronted
with
up processing in order to hear its sonic properties a kind of "Turing soup" that is writing and
altering
directly—we differentiate in the following between its own code. At this point, the performer
Betablocker/Rhythm and Betablocker/Audio. must decide whether to take advantage of the
situation or attempt to regain control over it.
Taking advantage of the situation involves looking
Very Slow Computing: Betablocker/Rhythm for interesting sections of code that emerge and
manually modifying them. To regain control of
Betablocker/Rhythm (the Fluxus and Gameboy theDSsituation, the best strategy turned out to be
version) makes computation tangible by slowing finding an unoccupied memory area to write a
down processes by many orders of magnitude program that gradually clears memory, thereby
compared with typical computing applications. Theeventually allowing the performer to start over. In
smallest musical loop in Betablocker/Rhythm is most successful performances both options were
repeatedly
three instructions long—push a value onto the stack taken over the course of the concert.
[PSH, 123], play it as a note [NOTE], jump back It is this gradual cessation of control, with im
to start [ JMP, 0]. mediacy and totality of the understanding (or, at the
In order to play this at 120 BPM it will needvery least, display) of the machine that sets this apart
to run at 6 cycles per second. (The machine thisfrom traditional live coding performance, where the
article was written on peaks at 2.8 x 109 cycleshigh level description of a process is the only con
per second, which is 466 million times faster nection between all, the audience, the performers,
than Betablocker/Rhythm.) This strategy makes and the process creating the sounds they hear.
computation audible as polyrhythmic techno music.
Simultaneously, computation is made visible as the
Code Patterns for Live Coding
thread's positions are displayed on the live-coding
interface, synchronized with the audio, along withIn order to further illustrate the kinds of programs
the entire heap's memory contents. The memory is and live-coding strategies we use, we list some
displayed on a 16 x 16 grid, in order to maximize concrete
the "code patterns" used in common live
visibility of the state and align with hexadecimalcoding situations. The first is a program called
notation. Soundcheck, which will play all the sounds in a
Our performance practice with Betablocker/sound bank at all frequencies available (see Figure 2).
Rhythm consists of starting with empty memory Multiple threads can be issued to play this program

Bovermann and Griffiths 43

This content downloaded from

213.55.244.33 on Fri, 22 Apr 2022 15:47:00 UTC:56 UTC
All use subject to https://about.jstor.org/terms
Figure 3. XOR rave.
Figure 4. A simple
aipeggiatoi for
Betablockei /Rhythm.
J 16byte drum sequencer
XOR rave
°EW[2?Hg??ra0i@00
t_t
Figure 3
16byte arpeggiator
Note thread Reset thread
t I
Figure 4
at the same time to provide more complexity. Values
interpreted as pointers are visualized as arrows.
In Betablocker/Rhythm the beat is always locked
to the instruction cycle, therefore faster melodies
or beats are a matter of optimization. A fast inner
loop program can be used for playing sounds
while another slower program modifies the first by
overwriting parts of it while it is running, as in the
"XOR rave" (see Figure 3).
The next two programs (see Figures 4 and 5) are
both 16 bytes long, and require three concurrent
threads to be running over different parts of the
program. In both figures, working from left to right,
the first thread loads an immediate byte and plays
it as a sound repeatedly, the second one increments
the byte that the first is loading, and the third
periodically resets the byte to a constant value.
The example in Figure 4 simply plays the byte
as a note—resulting in an arpeggiator-style melody.
After writing the code, the performer can change the
speed of each of the three threads to get more variety.
For example, the slower the resetting thread runs,
the longer the pattern will evolve before it repeats.
The example in Figure 5 is very similar, but it
is slightly modified to play a sequence of different
sounds rather than notes, in order to become a
percussion sequencer. The second instruction is
changed from a "push literal" to a "push contents of
44 Computer
213.55.244.33 on Fri, 22 Apr 2022 15:47:00 UTC
All use subject to https://about.jstor.org/terms
Figure 5. A sequencer for
Betablocker /Rhythm.
Note thread Reset thread
-| "o^Jpd
1
(TiTeeTeeleeTTsleeTTaleelogl^
address" which results in the program playing a part
of memory as a sequence. We can control the start
address location with the reset byte, write directly
to this part of memory, or modify the other thread's
speed to further increase the complexity.
Other types of programs alter the memory rather
than focusing on sound production. For example,
given two addresses, a program may increment one
and decrement the other, copying bytes from the
source to the destination,- this results in a reversal of
the entire CPU memory. Another type of program is
a self-replicating fork bomb, which copies its code to
other locations so gradually more and more threads
run the replication code.
Use of Genetic Algorithms as Creative
Augmentation in Live Coding
The same features that makes the Betablocker ap
proach suitable for exploratory artistic and musical
applications (lack of error states and isomorphism
between code and data) also make it a highly conve
nient environment for using evolutionary strategies.
The use of genetic algorithms (Barricelli 1963) in
this case is different from their traditional use. In
the case of Betablocker/Rhythm the desire to use
genetic algorithms arose from the need to discover
and learn new, optimal coding patterns for use in
live coding performances, as a way of escaping the
feeling of being "stuck in a creative rut." The use
of genetic algorithms in this case is to provide new
ideas for musical use—in contrast to final programs
for their own sake.
According to the cognitive dimensions of nota
tions (Green 1989), viscosity is an important metric
of success—how malleable a notation is without re
quiring repetition of actions and without knock-on
Music Journal
This content downloaded from
Figure 6. A function Figure 8. A program
written in Clojure for evolved by genetic
detecting repeated values programming for
in a list. Beta blocker/Rhythm.

Figure 7. A fitness function

for evolving melody.

(defn freq [1 n]
(defn _ [c]
(cond
(>= (+ c n) (count 1)) 0
(= (nth 1 c) (nth 1 (+ c n) ) ) (+ 1 (_ (+ c 1) ) )
:else (_ (+ c 1))))
(_ 0) )
Figure 6

(+ {* 50 (count (num-unique res))) ; unique notes are very good

(freq res 4) ; equal notes every four beats are good
(freq res 6)) ; equal notes every six beats are good

Figure 7

effects with relation to internal constraints. One

G3 GS 23 0C CO
of the features of evolutionary strategies is that
programs are automatically converged upon, in MI
which extremely unorthodox approaches may be
Figure 8
taken—especially when optimization is linked to
fitness criteria and when architectures are used
where self-modification is possible. We can grow the stack to store the current position, (2) a rising
small programs capable of large output complexity,
scale by self-modifying address 12 (the first 0 0),
in turn providing inspiration for increasing viscosity
(3) playing its own code as a pattern of notes by
of live coding during a performance. To do this using
we address 12 as a pointer, and (4) playing the
bitwise NOT of its own code at the same time.
take apart successful individual programs in order
to use them musically in hand-written code. The resulting note numbers: 0 0 232 255 23
In a genetic algorithm, we need a way to judge 1 232 254 13 2 242 253 22 3 233 252 7 4

fitness in order to select promising programs from

248a 251 12 5 243 250 17 6 238 249 20 7

population. In this application we are creating lists 235 248 12 8 score poorly for r
of note numbers, and, in order to create a fitness but extremely highly for uniquen
metric, we favor patterns that have unique notesthis (to surprising local maximum w
avoid repetition) but also look for a rhythmic nature the rhythmic fitness criteria, wh
by measuring them with the function defined in must have had an early influen
Figure 6. It detects repeating values spaced apart populations.
by
npositions, so that (freq ' (100 1 2 3 100 4 5 The evolved programs provided
6 100 7 8 9 100) 4) returns 3, as it finds three used in subsequent live coding
pairs of equal values (100) at the distance specified including self-playing programs l
(four positions apart). greater use of the stack (evolved
With the fitness function defined in Figure 7 less reliance on storing values o
we favor rhythmic components of four or six beats to robuster programs), and—more
and boost the uniqueness score by multiplying it general reappraisal of the potentia
by 50. Figure 8 is a resulting program that has possible with this restricted instr
evolved after several thousand generations. The Following this work, Betablock
program efficiently creates a complex pattern in Spork Factory to the ATtiny85 pr
four different ways: (1) a descending scale using an ongoing investigation of phy

Boveimann and Griffiths 45

This content downloaded from

213.55.244.33 on Fri, 22 Apr 2022 15:47:00 UTC
All use subject to https://about.jstor.org/terms
Figure 9. Basic examples or all (in BBlockerBuf)
on how the two interfaces stack elements. In the
to Betablocker/Audio BBlockerBuf example,
can be utilized. Evaluationthe program counter de
of each code block results termines where the signals
in an audification of the are spatially positioned
first (in DetaBlockerBuf) in the stereo panorama.

x = { // DetaBlockerBuf example
var signal = Demand.ar (
Impulse.ar('bbRate'.kr(22100)),
' reset' .tr(0) ,
DetaBlockerBuf('heapBuf' .kr ( 0))
);
LeakDC.ar(signal) ;
}-play;

x = { // BBlockerBuf example
var pC, stack;
#pC ... stack = BBlockerBuf.ar('bbRate'.kr(22100),
'heapBuf' .kr(0) , 'startpoint' .kr(0));
stack = LeakDC.ar(stack) ;
// use information on program counter to place sound output
Splay.ar(stack, spread: 0.1, center: pC) ;
}-play;

objects and robots. Here, the instructiontypical

set was
audio sampling rates, the reported signals are
extended with IN and OUT instructions forinaccessing
the audible range,- just as it is possible to probe
the pins of the microcontroller. This enabled
hardware
audio circuitry with, e.g., the Audio Sniffer
programs to be evolved for the processor, (www.openmusiclabs.com/proiects/audio-sniffer),
analysing
we were able to probe Betablocker engines while
the resulting sounds with a fast Fourier transform
to provide fitness metrics. they were executing.
Betablocker/Audio was implemented in
the SuperCollider programming environment.
Sound Computing: Betablocker/Audio The source code is available as a plug-in to
SuperCollider. (The plug-in is available online at
github.com/supercollider/sc3-plugins.)
One goal of the investigation into Betablocker was to To facilitate
typicaldata
gain new insights into the aesthetics of typical usage, we decided to provide two different
processing. How dynamic is the behavior of a chip a demand-rate UGen (DetaBlockerBuf)
interfaces:
exposing the topmost value of the stack by means of
when it runs an algorithm? What does computation
sound like, and is the variety of programs Supercollider's
reflected demand chain implementation, and
a multi-out
in a diversity of sounds? Because of our intention version (BBlockerBuf) that exposes
the position
to probe an otherwise independent system, no sepa of the program counter as well as the
complete
rate instructions or other structural manipulations stack. A basic example on how they can
be accessed
that would influence its computational behaviour is given in the listings in Figure 9. It is
assumed
should be introduced to the Betablocker engine. To that the heap to be operated on is preloaded
into a
get answers to these questions, however, we had to Buffer object. By applying a LeakDC operation
to the
add virtual sensors, called pointsOfTouch, to mean stack values, DC offsets that could harm the
speaker system
ingful parts of the virtual machine like the stack and are removed.
the program counter (cf. Bovermann, Rohrhuber,
and de Campo 2011). These additional program parts
do not have an effect on code execution but contin
Noise Aesthetics: On Texture and Rhythm
uously report the signal running through them. As Although the system is deterministic (i.e., its
outcome can be calculated, given that its state
the Betablocker/Audio variation runs at rates around

46 Computer Music Journal

This content downloaded from

213.55.244.33 on Fri, 22 Apr 2022 15:47:00 UTC
All use subject to https://about.jstor.org/terms
Figure 10. A cluster
generator for synthesizing
Betablocker operations on
randomly generated heaps.
The output of the 20
Betablocker/Audio engines
are spread out in the stereo
panorama.

{var srcs = ({BBlockerBuf.ar(

s.sampleRate * 0.5,
BBlockerProgram({rrand(0, 24) } !256) .makeLocalBuf
)[1]}!20);
Splay.ar(srcs.collect{ | src | LeakDC.ar(src)}, 1, 0.4);
}.play

JMP,
is known), because of its complexity 1], and and—as
a valid a pulse wave can be implemented
it turns out—fruitful approach is with
to[ORG,
work [NOP, . . . , NOP] , NOT, JMP, 1]
with
randomness and empirical observations
(here the
rather
ellipsis indicates
than an arbitrary string of
additional
with other analytical approaches. To NOPs). The
investigate number of NOP operations
this,
we implemented a cluster generatordetermines the pulse width. Similar to the sawtooth
for synthesizing
Betablocker operations of randomlyexample,
generated
the valuesheaps
of the remaining bytes in the
(see Figure 10). heap do not affect the program execution.
We developedthat
After extensive listening, we discovered all the example codes for classic
the heaps often sound like airily high-pitched
waveforms by exploratory live coding using the
helper class
and infinitely sustained sound clouds, BBlockerProgram,
broken up which implements
(among
occasionally by a rhythmical pattern. other functionality)
Typically, the play and plot methods
clouds settle either to a constant pitch
to, respectively,
or to silence
play and display a given Betablocker
after about 0.1 sec. In the long runheap. (after
An overviewaboutof the rendered signals is shown
in Figure
4 minutes), such clusters settle into 11.
a local stability
with fewer high frequencies than at While
the investigating
beginning. possibilities of implement
The first 1,000 computation steps ing a sawtooth
could wave with adjustable
therefore be slope, we
camevariation
called transients, and the long-term across a more complex
can be structure that resem
considered a timbral decay. bles such a sawtooth combined with a pulse: [ORG,
PSHL, 6, ADD, JMP, 1, <slope>]. Here, the
decision to add a probe to the stack rather than
Lessons Learned from Manually Programming
to implement additional side-effect instructions
Sonic Structures
came into play: The pulse wave in the program's
output (i.e., the stack's top value) is caused by an
When interacting with a low-level computational
operation that seems necessary to implement the
system, it is crucial to understand its inner structure
and get an idea of how it operates. It is possibleadjustable
to slope with a given data item. The shape
gain such knowledge by manually programming of the waveform is therefore limited due to the way
the sound signal is derived from the Betablocker
(simple) algorithms in the system's native language
and observing the resulting behavior. In order engine,
to namely, probing the items on one of its
functional parts. Note that the slot in which the
understand the specifics regarding the sonic charac
slope parameter is stored will never be reached by
teristics of the Betablocker engine, we hand-crafted
algorithms using the SuperCollider implementation the program counter and can therefore be used as
to render given waveforms as closely as possible. "safe" data storage for the slope parameter.
We found that a sawtooth wave can be modeled Another finding of the exploration of support for
live coding with Betablocker, one which links the
by setting the initial four bytes of the heap to [ORG,
INC, JMP, 1], When computation starts withresults of the oscillator exploration described in the
pC = 0, the remaining 252 bytes can be set arbi previous paragraph with explicitly written code, was
the sonic outcome of a combination of random data
trarily, as they will never be reached by the engine.
An impulse at nearly the Nyquist frequency can and a specifically designed algorithm that interprets
be rendered by executing the program [ORG, NOT, it. Given the program [NOP, ORG, NOP, NOP,

Bovermann and Griffiths 47

This content downloaded from

213.55.244.33 on Fri, 22 Apr 2022 15:47:00 UTC
All use subject to https://about.jstor.org/terms
Figure 11. Manually Figure 12. When a
generated waveforms, from Betablocker program is
left to right: sawtooth, written to a heap, it is
impulse, short pulse, long possible to set all
pulse, and saw impulse. non-specified slots to
contain random values.

Figure 11

a = BBlockerProgram([\NOP, \ORG, \NOP, \NOP, \PSH, 245,

\PSH, -1, \SUB, \DUP, \POP, -1, \POP, 1, \JMP, 1]);
a.fillUpRandom = true;
x = a.play(1000, leak: true);

Figure 12

PSH, 24 5, PSH, -1, SUB, DUP, POP, -1, the parameter range in which the oscillators control
POP, l, JMP, l] followed by random numbers,
each other.
the topmost element in the stack varies As well as being
according to able to modulate its output
values addressed in previously pushed values. the
amplitude, Every
Betablocker/Audio implementation
in SuperCollider
set of input values then sounds different, though the can alter its calculation rate
sounds share a common "root note" on that depends
a per-cycle basis. This makes it possible to
add dynamics
on the execution rate. Note that the program not only in amplitude but also
itself
in pitch.
is part of the data and can be addressed, too. In several research-oriented sessions of
Because
live coding values
the point to which the stack pops its topmost we explored the sonic character of
assembling
depends on the machine's state, it might Betablocker engines according to the
also destroy
aforementioned
the original program, leading to unstable (yet maybe synthesis techniques.
refreshingly new) behavior. Figure 13 displays block diagrams for additive
To explore such variations in Supercollider, we
synthesis, frequency modulation, and amplitude
introduced the flag fillUpRandom to the helper
modulation, using two Betablocker/Audio modules.
class BBlockerProgram. When set, the heap's
Although the implementation of these synthesis
techniques
remaining slots are filled with uniformly was straightforward, the live coding
distributed
random values whenever a Betablocker engine is revealed several aspects worth
experimentation
mentioning.
initialized with the program given in Figure 12. In FM or AM synthesis, adjusting
the rate of the modulator to be below the audio
range results in sequencer-like monophonic synthe
sizer patterns that are mostly "pseudo-repetitive."
Classic Synthesis Techniques Adapted That is, they begin with a chaotic movement that
to Betablocker/Audio
is followed by repetitions of a (possibly) slowly
Classic signal synthesis techniques such as ad changing pattern. This behavior significantly ex
ditive synthesis, frequency modulation (FM), tends the sonic qualities of a Betablocker/Audio
and amplitude modulation (AM) combine sev engine, a feature the first author used extensively
eral sound-generating modules in order to create in his live coding performance at the SuperCol
new sounds. The result depends highly on factors lider symposium in London (see the following
like the ratios between the frequency components, section on Betablocker live-coding practice for
the signal characteristics of the base oscillators, and details).

48 Computer Music Journal

This content downloaded from

213.55.244.33 on Fri, 22 Apr 2022 15:47:00 UTC
All use subject to https://about.jstor.org/terms
Figure 13. Block diagrams
of classic synthesis tech
niques adapted to
Betablocker/'Audio: addi
tive synthesis (a), frequ
ency modulation (b), and
amplitude modulation (c).

Carrier

As is known from classic FM synthesis, modu Piksel open-source media-arts festival in Norway.
lation rates in the audio range result in a broader This was a 20-minute solo live coding performance
frequency spectrum. Linking the rates of all used using a gamepad as the only input mechanism.
Betablocker engines results in harmonic additions Ring-shaped menus activated by analog joysticks
to the (noisy) spectra. The sonic relation between were used to pick instructions and set data values,
different Betablocker programs seems to follow a and the directional gamepad buttons were used to
specific rule, but it does not seem to be a straight navigate memory and choose addresses. A 16 x
forward one. Another way to generate aesthetically 16 zoomable grid of the program and data was
interesting patterns with complex rhythmic interre projected and both sample and synthesis patches
lations can be achieved by letting both engines run were triggered. Despite the esoteric nature of the
on the same heap. assembly code, the audience feedback implied
To summarize, the application of classic syn that this was a particularly effective live-coding
thesis techniques allows for additional control and performance, due in large part to the inclusion of
variation of the sonic output and, depending on the the audio-synchronized movement of the process,
actual code on which the engines are running, may program counter, audio trigger animation, and
even give rise to musical structures. pointer visualizations—an early indication that
understanding these mechanisms is important to
an audience. Subsequently Betablocker was used
Betablocker and Live-Coding Performance in a series of performances in London, both solo
Practice (Griffiths) and in collaborative musical live sessions
as part of the group Slub (www.slub.org).
Over the course of the last three years, we used
Betablocker in a wide variety of live-coding sit
uations, including both public performances and 4for8, Aalto Media Lab, Helsinki (April 2011)
research-oriented investigations. The result of the
research process was reported in the previous sec After some time experimenting with Betablocker us
tion. We now describe relevant Betablocker-based
ing Fluxus, during 2010 the engine was ported to the
public performances in their order of occurrence.
Gameboy DS system via an unofficial, open source
"home brew" development tool. This gaming plat
form was chosen for its stylus input mechanism,
Piksel Festival Bergen (October 2006) sound coprocessor, and extremely fast dedicated
graphics hardware. The touch screen provided
improved input over the previous gamepad mech
The very first performance of Betablocker in the
Fluxus environment took place in 2006 at theanism, with new features such as drag-and-drop

Bovermann and Griffiths 49

This content downloaded from

213.55.244.33 on Fri, 22 Apr 2022 15:47:00 UTC
All use subject to https://about.jstor.org/terms
 Figure, 14. The live coding
environment used by Till
Bovermann at the
Supercollider Symposium
2012, London. The heaps
are visualized in the
bottom part of the screen.

ffc Supercollider File Edit Lang Ul Format Window Library Help LFSaw <2 O ^ « <D P » ^ Do. 21:05 - X Q
mainPerformer.scd NdefMixer_Ndef.allpocalhost']
Color.block.
Color.green(l, 0.5), reduce doc docSel opertKr Recon3

AOO NDefModular.rtf

)
}.sum.tonh;

Ndef(\stereoPorallei).ploy

Ndef(\stereoPorollei) stop
/els (C Ndef(\stereoPorollei)setn(\bufnum, q buffers osArroy scromble[0 3].collect(_.bufnum))
| Ndef{\stereoParollei).fadeTime = 2;
Ndef(\stereoParallel).xsetn(\bufnum, q buffers asArray scramble[8..3] collect(-.bufnum),
\bbRote, 18000)
Hdef(\stereoParollei) xset(\bbRate, 5000);

Tdef (\randanizeTi11, {loop{

1 wait;
q.buffers asArray scramblefO 3].collect{IbufI at ( rnnA(0^\ .

jrand(38))} NdefCui_stereoRatemodPlayer
emodPiayer ar2 CLR reset scope doc end fade 0.02

|
JpdateFreq 20 | NdefCui_stereoRatefeedbackPlayer
•ateBufnum i 6
IbackPlayer ar 2 CLR reset scope doc end fade 0 02 poll
S localhost server low Rate i i 1
I slop
•ua -occ/j > E hghRate in i 1000 —

Q.< k running .
low Rate | —11
teStartpomt i 0
A*gCPU 12J * * cpu Ma *
1 - hghRate [ | I 1000
UGont 469
bufnum i 14

Groups 10 starlpont 0
| . : bufnum | [ E3) o
startpotm | I0
| ¥) -13.1 Q
spread i |o.i j : spread m I 0.1

address lookup. This system, based around the performed on top of it. At the same time, we both
touch-screen interface, was first performed in prepared our performance setups.
Helsinki in 2011, using a Web camera to project the Bovermann's aesthetic goal for the performance
screen, stylus, and fingers of the live coder. This was to play polyrhythmic layers of colored, noisy
sounds, with a setup purely based around his Su
system and software is now used as a way of explain
percollider Betablocker implementation. At the
ing and demonstrating live coding, particularly to
same time, he aimed for a certain amount of trans
children, who tend to be familiar with the Gameboy
DS. parency, i.e., it should be possible to see not only
the changes he made to the code but also how
Betablocker engines alter the heaps' content. This
SuperCollider Symposium London: Live Coding meant (1) developing a visual representation of the
and Visuals (April 2012) heaps he was playing; (2) designing a textual helper
environment for his live coding, mainly provid
For the live coding performance at the ing text blocks; and (3) preselecting heaps that he
SuperCollider Symposium 2012, London, the two used as "raw materials" for his part of the perfor
authors performed together for the first time. Asmance.
we Figure 14 shows a screenshot of the setup
are not located at the same place, we developedused.
a
remote rehearsal routine in which each performer The improvisation with Bovermann allowed
Griffiths some freedom from the synchronized
prepared his part as a sound recording and the other

50 Computer Music Journal

This content downloaded from

213.55.244.33 on Fri, 22 Apr 2022 15:47:00 UTC
All use subject to https://about.jstor.org/terms
Figure 15. The Oulipop turns (live.code.festival
performance setup is a 2013, Karlsruhe University
laptop with two typing of Music (HfM), photo by
areas that are manipulated Daniel Bollinger,
by two performers taking www. danielbollinger. de).

lockstep of his solo performances, and this concert
was the first to experiment with independent
speed settings for the different threads. Having
control over this meant greater breadth of possible
higher-level patterns, and being able to speed up
or slow down different parts while listening to
Bovermann's music provided greater control needed
in collaborative performance.
This performance using Betablocker DS was also
the first to use a new synthesis engine written
specifically for the ARM7 sound streaming copro
cessor on the DS, parts of which were written in
hand-optimized assembly code, allowing for greater
sonic possibilities, such as subtractive and FM syn
thesis, as well as more experimental sonifications of
the DS's tile graphics memory area.
Oulipop: Translation of Codes (May 2012,
April 2013)
This piece for two performers and one laptop was
conceptualized and realized by Till Bovermann and
Sara Hildebrand Marques Lopes (see Figure 15).
By manipulating texts according to rules from
the Ouvroir de literature potentielle (abbreviated
Oulipo, cf. Mathews, Brotchie, and Queneau 2005),
and, at the same time, sonifying the results with
the help of a Betablocker system, it deals with the
relation between writing and manipulating text,
code, and sound.
While the laptop performers are editing text in
one of two text panes, each keystroke also triggers a
process that translates the current text's characters

Bovermann and Griffiths 51

This content downloaded from

213.55.244.33 on Fri, 22 Apr 2022 15:47:00 UTC
All use subject to https://about.jstor.org/terms
into a set of Betablocker/Audio instructions. The inherent complexity, Betablocker can be viewed
correspondence of characters to instructions is as a companion for live coding that one has the
defined by connecting the letter frequency in opportunity to get to know, collaborate with,
the performance language (in this case, German) to and—sometimes—work against. In our endeavor
values representing the influence of each instruction to find out specifics of digital processing using
on the rendered signal. For example, NOT has a high Betablocker, both in performances and as the object
value, as it inverts the current output, whereas of investigation itself, we saw it unfold as a digital
NOP has a small value, as it does not change object with an intrinsic character. In the future, we
the output. Each line in the editor is treated as imagine Betablocker being implemented as part of a
input to one Betablocker module. The output wide range of mostly artistic or educational systems.
of these Betablocker engines is organized in an
FM-like structure. The resulting sound, an ever
changing blend of noisy texture and rhythmical References
patterns, influences the performers' decisions on
how to further alter the text. Over the course Alpert, D., and D. Avnon. 1993. "Architecture of the
of the performance, an initially meaningful text Pentium Microprocessor." IEEE Micro 13(3): 11—2,1.
Barricelli, N. 1963. "Numerical Testing of Evolution
turns into nonsense before it eventually settles
into a new—and often surprising—meaning. ForTheories." Acta Biotheoietica 16(3):99-126.
Berg, P. 2009. "Composing Sound Structures with Rules."
more information and a documentation video, see
Contemporary Music Review 28(l):75-87.
www. tai- studio. org/oulipop.
Bovermann, T., J. Rohrhuber, and A. de Campo. 2011.
"Laboratory Methods for Experimental Sonification." In
T. Hermann, A. Hunt, and J. G. Neuhoff, eds. The Soni
Meta-Discussion
fication Handbook. Berlin: Logos Publishing House,
pp. 237-272. Available online at sonification.de/
In this article, we presented our work on and handbook. Accessed October 2013.
Collins, N. 2008. "Errant Sound Synthesis." In Proceed
with Betablocker, an imaginary CPU architecture,
specifically designed and implemented for live ings of the International Computer Music Conference,
coding purposes. Live coding with Betablocker canpp. 575-578.
be undertaken in various forms and on different Collins, N. 2011. "Live Coding of Consequence."
Leonardo 44(3):207-211.
levels, ranging from assembler-level programming,
Green, T. R. G. 1989. "Cognitive Dimensions of Nota
through recursive live coding based on the engine's
tions." In A. Sutcliffe and L. Macaulay, eds. People and
capability of self-modification, to genetic algo Computers V. Cambridge, UK: Cambridge University
rithms and structural programming. We shared our Press, pp. 443-460.
insights on the system-inherent aesthetic possibili
Howse, M., and }. Kemp, eds. 2006. [the] xxxxx [reader],
ties and presented our performance practice around London: Mute.
live coding with Betablocker in its various flavors.
Kane, G. 1988. MIPS RISC Architecture. Upper Saddle
Over the course of the project, our preconception River, New Jersey: Prentice-Hall.
was that the beast of computation, with all its Lehtomaen, S. 2011. "Algorithmic Symphonies from One
complexity, was not to be tamed. So is it with Line of Code: How and Why?" Available online at
Betablocker: Although the output of a Betablocker countercomplex.blogspot.co.uk/2011/10/algorithmic
-symphonies-from-one-line-of.html. Accessed
engine is determinate, it still remains a mysteryOctober 2013.
for the human mind; it is "pseudo-indeterminate."
Luque, S. 2009. "The Stochastic Synthesis of Iannis
However, human desire for understanding leads Xenakis." Leonardo Music fournal 19:77-84.
us to suspend our disbelief and attach higher level
Magnusson, T. 2011. "The ixi lang: A Supercollider
meaning to a system's reaction as a way to gain Parasite for Live Coding." In Proceedings of the
tangible understanding. In this light, we recognize International Computer Music Conference, pp. 503
that, with its ability for self-modification and its 506.

52 Computer Music Journal

This content downloaded from

213.55.244.33 on Fri, 22 Apr 2022 15:47:00 UTC
All use subject to https://about.jstor.org/terms
Mathews, H., A. Brotchie, and R. Queneau. 2005. Oulipo
Compendium. London: Atlas.
Maurer, J. 1999. "A Brief History of Algorithmic Composi
tion." Available online at ccrma.stanford.edu/
~blackrse/algorithm.html. Accessed January 2013.
McLean, A., et al. 2010. "Visualisation of Live Code."
In Proceedings of the Electronic Visualisation and the
Arts Conference, pp. 26-30.
Rather, E., D. Colburn, and C. Moore. 1993. "The
Evolution of Forth." ACM Sigplan Notices 28(3): 177—
199.
von Neumann, J. 1993. "First Draft of a Report on the
EDVAC." IEEE Annals of the History of Computing
15(4):27-75. (Originally published 1945 in Technical
Report 4. Philadelphia: University of Pennsylvania,
Moore School of Electrical Engineering.)
Ward, A., et al. 2004. "Live Algorithm Programming
and a Temporary Organisation for Its Promotion."
Proceedings of the README Software Art Conference,
pp. 243-261.
Xenakis, I. 1971. Formalized Music. Bloomington: Indiana
University Press.

Bovermann and Griffiths 53

This content downloaded from

213.55.244.33 on Fri, 22 Apr 2022 15:47:00 UTC
All use subject to https://about.jstor.org/terms