Welcome to a new series of “Function of the month” (FotM) blog posts. We hope to build up a comprehensive picture of TidalCycles by periodically making a post with a short video. We plan to be true to the name, and do this every month, with a focus on a particular function. However allow us to deviate from this plan immediately by first taking some time to describe how the different parts of a standard Tidal system works. Take this as a hopefully illuminating preamble for this series.. We’ll get onto specific Tidal functions in FotM #1!
0. Introduction
A video accompanying the below will go here, once we’ve made it. In the meantime please feed back with comments and questions on the below, which we’ll then be able to respond to in the video itself.
A complete TidalCycles system has a few components which we’ll tour around, the TidalCycles language for generating pattern from code, the SuperCollider synthesis system which hosts SuperDirt for turning those patterns into sound, and an editor such as Atom which acts as a text editor for writing those Tidal patterns. but lets start our tour with the TidalCycles language itself.
1) TidalCycles
TidalCycles is a computer language for generating pattern from code. It consists of an expressive mini-language for describing polyrhythmic sequences, and a wide range of pattern operators and functions for patterning such sequences in a variety of ways. For example, by rotating them, mirroring them, shifting them in time, combining them into weird interference patterns, and ‘glitching’ the sequence with random numbers.
You’ll have noticed that we often call TidalCycles by its shorter name Tidal. That’s actually what it was originally called, until someone started up a music streaming service with the same name, and we felt the need to differentiate..
Tidal is written in a programming language called Haskell. Strictly speaking, when you’re making patterns in Tidal you’re mostly writing Haskell code, but in practice you don’t need to learn Haskell in order to be a top Tidal coder. This is because Tidal is what is called a “Domain Specific Language”, embedded in Haskell, which supplies its own model of computation, operators, function and mini-language for sequences, all centred around pattern generation. That said, are some things about the underlying Haskell language that take a bit of getting used to though, like what that mysterious $ is doing, we’ll confront this in a later episode.
It’s important to note that the Tidal language does not make sound by itself, it only makes patterns. It talks to other software or hardware to make sound (using e.g. the OSC or MIDI protocol), usually SuperDirt running in SuperCollider. However, quite a few people have plugged Tidal into custom software in order to generate patterned visuals, lights or even choreography. For now lets focus on the common case – SuperCollider and SuperDirt.
2. SuperCollider
SuperCollider is the synth behind most desktop live coding systems, and by default, Tidal is no exception. As we said above, Tidal is made for generating patterns, but doesn’t itself make any sound, that’s why you need SuperCollider installed. SuperCollider is a very well developed programming language that is designed for sound synthesis (and digital signal processing in general) that can itself be live coded. By default though, you’ll just use it in order to host SuperDirt.
2a) SuperDirt
SuperDirt is a sound synthesis framework designed especially for TidalCycles, and written in SuperCollider. You don’t need to know anything about SuperCollider in order to run SuperDirt, you just have to start it up, and Tidal will by default send messages to it in order to trigger sounds. SuperDirt comes with a fairly large library of sound samples, as well as a range of synthesisers.
With the latest version it is also possible to register MIDI devices with SuperDirt, so that you can trigger external sounds on soft/hardware synthesisers. This will be the topic of a FotM post later on.
If you run some Tidal code like this:
d1 $ s "cp supermandolin"
You’re sending two trigger messages to SuperDirt per cycle, first for the cp sound, and then the supermandolin sound. In the case of cp, SuperDirt will play a short sound sample, which it will find inside a folder called cp on your computer. You can find it from SuperCollider – from the menus select ‘open user support directory’, and then open ‘downloaded-quarks’ and then ‘Dirt-Samples’. You’ll see a bunch of ‘.wav’ files inside the cp folder, because cp isn’t a single sound but a set of them known as a ‘soundbank’. By default SuperDirt will play the first one – to play the second, you can specify cp:1 in your pattern instead (it starts counting at 0).
You won’t find a folder in Dirt-Samples called supermandolin, because that is a synthesiser rather than sample-based soundbank. You can play notes as numbers like this:
d1 $ note "0 7 12" # s "supermandolin"
or as note names like this:
d1 $ note "c gs7 c6 gf4" # s "supermandolin"
(If supermandolin isn’t working for you, it’s almost definitely because sc3-plugins isn’t installed properly, which is required by most synths.)
3. Atom
Your main interface to all this is probably Atom, or otherwise one of the other supported text editors. Atom is where you type in and run your Tidal patterns, although strictly speaking, Tidal itself doesn’t run inside Atom but in its own process. You’ll have installed a ‘tidalcycles’ extension inside Atom, but this isn’t tidal itself, but an interface to it. Clear? Hopefully!
Summary
Ok, that was a brief tour of the different components of a standard Tidal system. There’s a text editor Atom, sending code to a Tidal process to run, which in turn sends messages to SuperDirt to make sound, which in turn runs inside SuperCollider. Hopefully that’s straightened out some confusions, but feel free to ask some questions below!