This summer, I was fortunate enough to get the chance to work on a project as part of the Summer of Haskell. This allowed me to work on the TidalCycles (Tidal) live coding software: free/open source software for pattern generation with code. Often this is used to create musical pattern, although increasingly it has been used for other things too, e.g. pattern visualisation, weaving. It is a language that is regularly used in live coding, a subset of artistic programming which looks at live improvisation and performance of algorithms to produce artistic outputs such as music, visuals or dance (to name a few).

> /code <id> <source>

< /code/ok

> /expand <code> 

< /expand/ok <expanded code>

or get the cycles per second value

> /cps

< /cps <number>

As the auto-completer’s ML backend was running in Python and we were sending OSC messages between a test python server and currently only an atom editor, the earlier discussed Tidal API would attempt to make this interaction more transparent and universal.

One issue flagged with the autocomplete agent was the nature of the corpus used for generation of new pattern, based on the code of a small set of live-coders. This would be able to create ‘statistically probable’ code, which might not have been seen before but would be unlikely to introduce radically new ideas. We wanted a way to expand the ‘search space’ of the machine learning agent, by adding combinations of functions to the corpus that had not been seen before.

The aim was to create a walker agent that could navigate through the conceptual space of all possible Tidal code, modelling Haskell’s type system to ensure anything generated would be syntactically valid. To ‘steer’ this walk, we weighted its decisions based on n-gram data, created realistic code that could then be used to train the autocomplete agent. There were various steps taken to implement this. Below shows the architecture of such a program.

Other than achieving outcomes from the project, some of the main things I have learnt have been to do with collaborating on an open source project. Not coming from a traditional computer science background, this has been one of the first larger scale projects I’ve been able to work on (although what I do has meant I’ve learnt a lot of computer science over a short period of time, I still feel “new” to the area). Some things that have been particularly useful to learn are using github to collaborate on coding projects (and how to fix merge conflicts!) and on attempting to meet milestones throughout the project, including trying to organise these coherently. 

One particular problem I encountered throughout was that most of my coding experience comes from imperative coding. This meant that when trying to write code in a functional way seemed a little unintuitive for me. It took some time to work on using concepts like folds and recursions rather than concepts like iterating over a for-loop. Learning Haskell through completing a project has definitely helped me think in a more functional way.

Finally of course, there were some errors that were encountered with the project. Debugging in Haskell was a little tricky without being able to backtrace/ find breakpoints in the code. Using a lot of print statements helped conceptualise how the program was running and where things might have been going wrong.

I’ve started a “Learning TidalCycles” course with support of Lucy Cheesman (aka Heavy Lifting) and other friends (newcomers – see below for video explaining what live coding and TidalCycles is). We called it “Tidal Club” after some peer learning events Lucy started in Sheffield. The course is now in the fourth week of the first group of lessons. In an effort to keep the course accessible as possible, there’s absolutely no time limit on getting through the material, which is oriented around pre-recorded video and worksheets. (more thoughts about making online courses accessible here..)

So registrations are still open, and you can join the course it at any time, (although I might have to pause signups from time to time so we don’t get overrun with new learners). Interaction is based around the Tidal Club forum, for which we’ve got a code of conduct, and Lucy has been developing guidelines for giving each other constructive feedback on our work too.

The course is “pay as you feel” via this shop, with the following guide for the first four-week block:

• £0 – for those who wouldn’t be able to participate otherwise
• £12 (£3 per week) – standard
• £24 (£6 per week) – those with extra cash to spare
• £40+ (£10 per week) – those with institutional backing

Here’s the video lessons covered so far, at the time of writing (6th May 2020):

• Intro
  • Installation
  • Technical tour of a Tidal system
• Week 1 – mini-notation week!
  • Tidal Interaction
  • Loading sample packs
  • Sequencing with mini-notation (parts one, two and three)
• Week 2
  • Starting out with effects
  • Manipulating time with setcps, cps patterns and fast/slow functions
  • Combining patterns with arithmetic (plus the ‘hurry’ function)
• Week 3
  • Exploring the ‘every’ function, including tackling that ‘$’
  • ‘cut’ vs ‘legato’
  • ‘slice’ and ‘splice’
  • ‘chop’ and ‘striate’
• Week 4 (this week)
  • Continuous ‘waveform’ patterns – sine, square, tri, saw and random functions (with a bit on binary patterns)
  • More still to come – all the random functions, including shuffle, sometimes and someCycles
• Plus!
  • Challenges! (so far, exploring big tempo changes, and making music from speech)
  • Live streams (at different times to reach different timezones, and archived for later viewing)
  • A performance talk-through with Antonio Roberts
  • + more to come, including reference material.

After this four-week block we’ll take a rest, so I can prepare for the next four-week batch of lessons, taking things to the next level.. For which there’ll be another opportunity to pay-as-you-feel!

If you’re unsure what live coding and/or Tidal actually is, then here’s a quick video intro about that (and the also awesome Gibber and Hydra live coding environments), which I did for the creative guild in Sheffield:

If this sounds good to you, sign up over here!

(If you don’t want to join the course, but want to join the Tidal Club forum, you can register here.)

Structure comes from where you want

In current Tidal, “the structure comes from the left” has become a bit of a mantra. In the next version, it’ll come from where you want.

For example `”1 2 3″ + “4 5″` used to give you "4 6 7", because the structure comes from the first part, and  that2 in the middle starts in the first half of the cycle, so matches with 4.

In the rewrite, by default, structure comes from both sides, so in the above example, you end up with the equivalent of `”1 [6 7] 8″` — the `2` gets split in two, to match with both `4` and `5`.

To get the old behaviour, of structure coming from the left, you’d use |+, i.e. "1 2 3" |+ "4 5". To get structure from the right, you’d do "1 2 3" +| "4 5", which would give you "5 7".. Then `|+|` does exactly the same as +, i.e. it gets structure from both sides.

Unified pattern operators

|+|, `|+` and +| all work on patterns of parameters (now known as control patterns) as well as patterns of numbers. So these two are the same: `n (“1 2” + “3 4 5”) + s “bass”` and n "1 2" + n "3 4 5" + s "bass".

Of course there are also *, /, `%` and `-` versions of the above.

There is also `|>|` and `|<|` and friends; the arrow there points at where the values come from. So you could do `”[1 2] [3 5 6]” |> “5 2″` to take the structure from the left, and the values from the right, giving you `”[5 5] [2 2 2″`. Aha!

|> basically does what `#` does now, we’ll likely keep that as an alias..

On the way.. Stateful patterns

Patterns can now respond to state, the idea being that you can do things like `note “c a f e” # sound “bass” # speed (scale 1 1.6 $ control “knob1”)` where knob1 somehow maps to an external controller. Latency might be an issue.. It’s all in bits at the moment though, the new version doesn’t actually make sound yet.. Will update this post as things develop.

Internals

The most exciting thing for me is that the code is a bit cleaner on the inside, with fewer bugs and edge cases, and things generally make more sense. There’s even some tests, a start at creating a more complete definition of what patterns are and how they should behave. Patterns are flagged as being either continuous or discrete, which clears up a lot of ambiguity that was around before.

Keep an eye on the project for updates!

Config Setting Errors

The new update now removes errors telling you that the TidalCycles config settings were “unknown”. Now it’s just a clean config:

Neat!

Boot File Path Errors

A few minor versions ago, we introduced the ability to configure a path to a custom Tidal boot file. With that, you can now configure Tidal to load up all of your custom stuff in a seamless bootup sequence. However, if VS Code could not locate your custom bootup file it wouldn’t tell you.

Now, the Tidal console output and a VS Code message will notify you that you boot file was not found:

What’s more is that you can fix your boot file config settings and try to reboot Tidal without restarting VS Code. Fancy!

Oh Hey One More Thing!

VS Code recently released a new feature where you can dock the terminal to the right-hand side of the IDE:

So now you can put the Tidal output to the side instead of below your Tidal code, if you so desire:

How to update

If you use cabal (rather than stack) to install, it’s just a matter of running cabal update then `cabal install tidal` from the commandline. I’m not clear on the best way to update using stack (as tidal hasn’t yet updated on stackage LTS), if you know please leave a comment!

New Bjorklund (aka Euclidean) functions

New function einv, which fills the “blanks” left by e. For example, e 3 8 "x" gives "x ~ ~ x ~ ~ x ~", whereas einv 3 8 "x" gives `”~ x x ~ x x ~ x”`.

Another new function `efull` which takes two patterns rather than one, combining `e n k` on the first with `einv n k` on the second. For example, `efull 3 8 “2” “1”` gives `”2 1 1 2 1 1 2 1″`

Yet another function distrib, which is similar to e, but takes a list of numbers. `distrib [5,8] “x”` is the same as e 5 8 "x", but `distrib [2,5,8]` will  do something rather freaky.. It will take the `(5,8)` pattern as a starting point (which is "x ~ x x ~ x x ~") and then attempt to distribute two events evenly over those five xs as though they were contiguous,  creating `”x ~ ~ x ~ ~ ~ ~”`). Basically, give it a list of numbers which increase in value and you’ll find some interesting off-kilter rhythms.

`d1 $ distrib [5,7,16] $ sound “bd:7″`

Sequence parser

Now you can give * and / subpatterns in the parser. For example `”[a b]*[2 3]”` would be the same as "[a b] [b a b]" (i.e. the first half of "a b a b", which is the pattern at twice the speed, and the second half of "a b a b b a b", which is the pattern at three times the speed).

Floating point notes

Now notes are floating point. This means that you can do things like d1 $ s "drum*8" # n (sine * 8). It also means that for some synthesised sounds you can play between the notes (microtones?), e.g. `d1 $ sound “supermandolin*8” # n sine`. There have been other adjustments in this area, so previously where you had to do fiddly conversions between integers and floats, you no longer have to.

ghc support

Tidal now supports the latest version of ghc (8.4.1). You should probably be running at least 7.10.3 by now but older versions may still work.

SuperDirt

Exciting SuperDirt update to follow soonish, including new MIDI support.

Enjoy!

@tidalbot weave’ 16 (sound “bd sn feel*2 [~ arpy]”) [jux (slow 2), (# speed “0.75”), striate 16]

— Lizzie Wilson (@dgtlslvs) April 3, 2018

@tidalbot density 0.75
$ stack [
jux (rev)
$ every 4 (iter 3)
$ every 3 (iter 2)
$ every 5 (jux (0.25 <~))
$ sound “[less:0*3, hh*5, hh*4]”,
sound “~ sn:2” # gain “0.8”,
sound “bd:1*16” # gain “[0.9 0.8]*8”
]

— bogdan.plan @ REZZED (@BogdanVera) April 3, 2018

@tidalbot s “supersaw(5, 8, {0, 3})” #n “[0, 4, 7, 9, 11]” |+| n “{0, 7, 12}” |+|n “<-7 7 0 5 -5>/2” #cutoff (scale 800 20000 $slow 4 $sine1) #resonance “0.3” #sustain “{0.01 0.15 0.1}%4”

— 田所 淳 (@tadokoro) April 3, 2018

@tidalbot s “gab*19?”
# pan (slow 15 $ sine)
# end (discretise (1/8) $ slow 19 $ scalex 0.0001 0.01 $ rand)
# loop 99
# delay 0.9
# delayfb 0.95
# delayt (discretise (1/9) $ slow 23 $ scalex (1/999) (1/9) $ rand)
# lpf (slow 2 $ scale 200 20000 $ rand)
# gain 4

— Daniel M Karlsson (@danielmkarlsson) April 3, 2018

As a bonus, the latest pattern is currently being projected into the shop window of Access Space Labs on Fitzalan Square in Sheffield.

This means that you no longer need to modify the provided BootTidal.hs file in the package with your own custom logic (e.g. custom functions, additional modules, etc).

If you want to create your own boot file:

1. Create a copy of the original (available here)
2. Save it anywhere on your computer
3. Modify the TidalCycles package settings to point to where you saved the new file

First – what’s a Markov chain? Basically it’s some kind of random sequence where each step depends only on the step immediately before it. A common way to express this is to imagine several possible “states” for each step, and then write a “transition matrix” which gives the odds of going from one state to another.

How should we represent all this in Tidal/Haskell?  We ultimately want to have the chain as a Pattern, but it’ll probably be easier to start out with an ordinary list, and then use the listToPat function to turn it into a Pattern.  Let’s number the states with integers, starting at zero.  Then the chain itself will be a list of integers.  The transition matrix is a list of lists of floating point numbers – we’ll use doubles. Then one way of writing things is to have a function that takes the transition matrix and a chain as arguments, and returns a new chain which is just the old one with one new element added. Here’s just the signature:

markovStep :: [[Double]] -> [Int] -> [Int]

Next let’s start the basic structure of what the function will have to do. Let’s call the transition matrix tp and the input chain xs. We need to look at the top element of the list to see what the “from” state is, and find that row of the transition matrix: tp!!(head xs). Next we need to generate a random number r (we’ll worry about how to actually do this later) and somehow use it to choose what the “to” state for the next step of the chain should be.

For example, if the row of the matrix were [0.20, 0.30, 0.50], this would mean 20% chance of transition to state zero, 30% chance to state one, and 50% chance to state two. So if our random number (between zero and one) were between 0 and 0.2, we’d pick state zero, between 0.2 and 0.5 state one, etc. This is easier to write if we take the cumulative sum of the row, and there’s a handy Haskell function we can use for that: scanl1 (+). That’ll turn the row into [0.20, 0.50, 1.00], and now when we have a random number we just need to find the index of the first element in the row larger than our random number. That’ll be the state the chain jumps to next.

There’s a handy Haskell function for finding things in lists too: findIndex. While it doesn’t quite work yet, we have most of our function:

markovStep tp xs = (findIndex (r <=) $ scanl1 (+) (tp!!(head xs))) : xs

(the : xs at the end adds the existing chain after the new element we just made)

One problem is that findIndex doesn’t actually return an Int. It returns a Maybe Int, because it might not find anything.  If our transition probabilities for each row add to one we’ll always be safe, but if we mess up or make a typo things might go wrong.  We have two options, (1) choose a safe default or (2) throw an exception and halt.  For the first option we could use fromMaybe 0 (to default to state zero), and for the second we’d use fromJust. Both require us to import the Data.Maybe module. Since I like to immediately know when I’ve made a math mistake and don’t mind if my performance grinds to a halt, I’m choosing the second option:

import Data.Maybe

markovStep tp xs = (fromJust $ findIndex (r <=) $ scanl1 (+) (tp!!(head xs))) : xs

The final thing to take care of is the random number. While it’s not quite the intended use, we can use the timeToRand function, which takes a rational number as an argument and hashes it to a pseudorandom result. We just have to make sure we get a different number for each step of the chain by using the length of the chain, and do type conversion as necessary:

import Data.Maybe

markovStep tp xs = (fromJust $ findIndex (r <=) $ scanl1 (+) (tp!!(head xs))) : xs 
  where r = timeToRand $ fromIntegral $ length xs

The last touch to make this a bit more usable is to wrap markovStep in a function that will repeat the step process to build a chain n numbers long from an initial state xi, flip it around so the most recent element is at the end, and turn the whole thing into a pattern with one number per cycle.

import Data.Maybe

markovStep :: [[Double]] -> [Int] -> [Int]
markovStep tp xs = (fromJust $ findIndex (r <=) $ scanl1 (+) (tp!!(head xs))) : xs 
  where r = timeToRand $ fromIntegral $ length xs
markovPat n xi tp = slow (fromIntegral n) $ listToPat 
  $ reverse $ (iterate (markovStep tp) [xi]) !! (n-1)

Now it’s ready to use in Tidal:

d1 
 $ fast 4 
 $ n (markovPat 64 0 [[0.3, 0.4, 0.3], [0.3, 0, 0.7], [0.7, 0.3, 0]])
 # s "arpy"

The chain states are always integers starting at zero, and that seems rather limiting.  But we can treat the chain as an index to some other array of our choice, which needn’t even be numerical:

d1
 $ fast 4
 $ n (fmap ([0,3,5]!!) $ markovPat 64 0 [[0.3, 0.4, 0.3], [0.3, 0, 0.7], [0.7, 0.3, 0]])
 # s "arpy"

d2
 $ fast 8
 $ s (fmap (["hc:2", "cr"]!!) $ markovPat 128 1 [[0.88, 0.12], [0.7, 0.3]])
 # cut 1

I’m sure there are still improvements we could make, but this is a pretty fun start!