In this artist statement, I will discuss the tension between source code as an interactive system for performers and source code as information and entertainment for audiences in live-coding performances. I then describe augmentations I developed for the presentation of source code in the live-coding environment Gibber, including animations and annotations that visually reveal aspects of system state during performances. I briefly describe audience responses to these techniques and, more importantly, how they are critical to my own artistic practice.
date-parts
2022
3
24
family
given
Roberts
Charles
International Journal of Performance Arts and Digital Media
The TidalCycles (or Tidal for short) live coding environment has been developed since around 2009, via several rewrites of its core representation. Rather than having fixed goals, this development has been guided by use, motivated by the open aim to make music. This development process can be seen as a long-form improvisation, with insights into the nature of Tidal gained through the process of writing it, feeding back to guide the next steps of development. This brings the worrying thought that key insights will have been missed along this development journey, that would otherwise have lead to very different software. Indeed participants at beginners' workshops that I have lead or co-lead have often asked questions without good answers, because they made deficiencies or missing features in the software clear. It is well known that a beginner's mind is able to see much that an expert has become blind to. Running workshops are an excellent way to find new development ideas, but the present paper explores a different technique -- the rewrite.
A JavaScript dialect of its mini-notation for pattern is created, enabling easy integration with creative coding tools and an accompanying technique for visually annotating the playback of TidalCycles patterns over time. TidalCycles has rapidly become the most popular system for many styles of live coding performance, in particular Algoraves. We created a JavaScript dialect of its mini-notation for pattern, enabling easy integration with creative coding tools. Our research pairs a formalism describing the mini-notation with a small JavaScript library for generating events over time; this library is suitable for generating events inside of an AudioWorkletProcessor thread and for assisting with scheduling in JavaScript environments more generally. We describe integrating the library into the two live coding systems, Gibber and Hydra, and discuss an accompanying technique for visually annotating the playback of TidalCycles patterns over time.
In this paper we introduce "version zero" of TidalVortex, an alternative implementation of the TidalCycles live coding system, using the Python programming language. This is open-ended work, exploring what happens when we try to extract the 'essence' of a system like TidalCycles and translate it into another programming language, while taking advantage of the affordance of its new host. First, we review the substantial prior art in porting TidalCycles, and in representing musical patterns in Python. We then compare equivalent patterns written in Haskell (TidalCycles) and Python (TidalVortex), and relate implementation details of how functional reactive paradigms have translated from the pure functional, strongly typed Haskell to the more multi-paradigm, dynamically typed Python. Finally, we conclude with reflections and generalisable outcomes.
This paper brings together two main perspectives on algorithmic pattern. First, the writing of musical patterns in live coding performance, and second, the weaving of patterns in textiles. In both cases, algorithmic pattern is an interface between the human and the outcome, where small changes have far-reaching impact on the results. By bringing contemporary live coding and ancient textile approaches together, we reach a common view of pattern as algorithmic movement (e.g. looping, shifting, reflecting, interfering) in the making of things. This works beyond the usual definition of pattern used in musical interfaces, of mere repeating sequences. We conclude by considering the place of algorithmic pattern in a wider activity of making.
Estuary is a browser-based collaborative projectional editing environment built on top of the popular TidalCycles language for the live coding of musical pattern that includes a strict form of structure editing, a click-only border-free approach to interface design, and explicit notations to modulate the liveness of different parts of the code. This paper describes the initial design and development of Estuary, a browser-based collaborative projectional editing environment built on top of the popular TidalCycles language for the live coding of musical pattern. Key features of Estuary include a strict form of structure editing (making syntactical errors impossible), a click-only border-free approach to interface design, explicit notations to modulate the liveness of different parts of the code, and a server-based network collaboration system that can be used for many simultaneous collaborative live coding performances, as well as to present different views of the same live coding activity. Estuary has been developed using Reflex-DOM, a Haskell-based framework for web development whose strictness promises robustness and security advantages.
This is an improvised, from-scratch live coding performance. The NIME interface which this performance showcases is the new Feedfoward editor for the TidalCycles live coding environment. Feedforward is written in Haskell using the ncurses library for terminal-based user interfaces. It runs on low-powered hardware including the Raspberry Pi Zero, with formative testing of prototypes conducted with several groups of children between the ages of 8 and 14. Feedforward has a number of features designed to support improvised, multi-pattern live coding. Individual Tidal patterns are addressable with hotkeys for fast mute and unmuting. Each pattern has a stereo VU meter, to aid the quick matching of sound to pattern within a mix. In addition, TidalCycles has been extended to store context with each event, so that source code positions in its polyrhythmic sequence mini-notation are tracked. This allows steps to be highlighted in the source code when- ever they are active. This works even when Tidal combinators have been applied to manipulate the timeline. Formal evaluation has yet to take place, but this feature appears to support learning of how pattern manipulations work in Tidal. Feedforward and TidalCycles is free/open source software under a GPL licence version 3.0.
The Euclidean algorithm (which comes down to us from Euclid's Elements) computes the greatest common divisor of two given integers. It is shown here that the structure of the Euclidean algorithm may be used to automatically generate, very efficiently, a large family of rhythms used as timelines (rhythmic ostinatos), in traditional world music. These rhythms, here dubbed Euclidean rhythms, have the property that their onset patterns are distributed as evenly as possible in a mathematically precise sense, and optimal manner. Euclidean rhythms are closely related to the family of Aksak rhythms studied by ethnomusicologists, and occur in a wide variety of other disciplines as well. For example they characterize algorithms for drawing digital straight lines in computer graphics, as well as algorithms for calculating leap years in calendar design. Euclidean rhythms also find application in nuclear physics accelerators and in computer science, and are closely related to several families of words and sequences of interest in the study of the combinatorics of words, such as mechanical words, Sturmian words, two-distance sequences, and Euclidean strings, to which the Euclidean rhythms are compared. 1.
date-parts
2022
4
24
family
given
Toussaint
Godfried
In Proceedings of BRIDGES: Mathematical Connections in Art, Music and Science
The original Tidal is implemented as a domain specific language (DSL),
embedded in the Haskell pure functional programming language, taking
advantage of Haskell's terse syntax and advanced, 'strong' type system.
Javascript on the other hand, is a multi-paradigm programming language,
with a dynamic type system. Because Tidal leans heavily on many of
Haskell's more unique features, it was not always clear that it could
meaningfully be ported to a multi-paradigm scripting language. However,
this already proved to be the case with an earlier port to Python
[TidalVortex; @https://zenodo.org/record/6456380], and we have now
successfully implemented Tidal's pure functional representation of
patterns in Strudel, including partial application, and functor,
applicative and monad structures. Over the past few months since the
project started in January 2022, a large part of Tidal's functionality
has already been ported, including it's mini-notation for polymetric
sequences, and a large part of its library of pattern manipulations. The
result is a terse and highly composable system, where just about
everything is a pattern, that may be transformed and combined with other
patterns in a myriad of ways.
Representing Patterns
Patterns are the essence of Tidal. Its patterns are abstract entities
that represent flows of time as functions, adapting a technique called
pure functional reactive programming. Taking a time span as its input, a
Pattern can output a set of events that happen within that time span. It
depends on the structure of the Pattern how the events are located in
time. From now on, this process of generating events from a time span
will be called querying. Example:
In this example, we create a pattern using the sequence function and
query it for the time span from 0 to 1. Those numbers represent
units of time called cycles. The length of one cycle depends on the
tempo, which defaults to one cycle per second. The resulting events are:
Each event has a value, a begin time and an end time, where time is
represented as a fraction. In the above case, the events are placed in
sequential order, where c3 takes the first half, and e3 and g3 together
take the second half. This temporal placement is the result of the
sequence function, which divides its arguments equally over one cycle.
If an argument is an array, the same rule applies to that part of the
cycle. In the example, e3 and g3 are divided equally over the second
half of the whole cycle.
In the REPL, the user only has to type in the pattern itself, the
querying will be handled by the scheduler. The scheduler will repeatedly
query the pattern for events, which then will be used for playback.
Making Patterns
In practice, the end-user live coder will not deal with constructing
patterns directly, but will rather build patterns using Strudel's
extensive combinator library to create, combine and transform patterns.
The live coder may use the sequence function as already seen above, or
more often the mini-notation for even terser notation of rhythmic
sequences. Such sequences are often treated only a starting point for
manipulation, where they then are undergo pattern transformations such
as repetition, symmetry, interference or randomisation, potentially at
multiple timescales. Because Strudel patterns are represented as pure
functions of time rather than as data structures, very long and complex
generative results can be represented and manipulated without having to
store the resulting sequences in memory.
Pattern Example
The following example showcases how patterns can be utilized to create
musical complexity from simple parts, using repetition and interference:
The pattern starts with a rhythm of numbers in mini notation, which are
interpreted inside the scale of D minor. Without the scale function, the
first line can be expressed as:
fast(n): speed up by n. g3.fast(2) will play g3 two times.
off(n, f): copy each event, offset it by n cycles and apply function
f
legato(n): multiply duration of event with n
echo(t, n, v): copy each event t times, with n cycles in between
each copy, decreasing velocity by v
tone(instrument): play back each event with the given Tone.js
instrument
pianoroll(): visualize events as midi notes in a pianoroll
Future Outlook
The project is still young, with many features on the horizon. As
general guiding principles, Strudel aims to be
accessible
as compatible as possible with Tidal
modular and extensible
The main accessibility advantage over Tidal is the zero install browser
environment. While OSC output to SuperCollider is possible with Strudel,
it requires the user to install SuperCollider with a custom setup
script, which is not trivial. Without OSC output, Strudel is able to
output sound inside the browser via Tone.js, which is a major limiting
factor, both in terms of available features and runtime performance. For
the future, it is planned to integrate alternative sound engines, with
possible candidates being like glicol
[@{https://webaudioconf.com/posts/2021_8/}] or faust
[@{https://webaudioconf.com/posts/2019_38/}]. To improve compatibility
with Tidal, more Tidal functions are planned to be ported, as well as
full compatibility with Tidal's SuperDirt synth. Besides sound output,
other ways to render events will be explored, such as graphical, serial
or kinetic output.
Space for one laptop + small audio interface (20 cm x 20cm), with
mains power.
Stereo sound system, either placed behind presenter (for direct
monitoring) or with additional stereo monitors.
Audio from audio interface: stereo pair 6,3mm jack outputs
(balanced)
Projector / screen (HDMI.)
Acknowledgments
Thanks to the Strudel and wider Tidal, live coding, webaudio and
free/open source software communities for inspiration and support. Alex
McLean's work on this project is supported by a UKRI Future Leaders
Fellowship [grant number MR/V025260/1].
