An easy way to experiment with this is via Strudel[1], a JS port that plays in-browser (annoyingly, works better with Chrome than Safari.)

[1] https://strudel.tidalcycles.org

try https://glicol-tidal.netlify.app/

an alternative audio engine for Strudel with Glicol

Oh, neat, ta.

Met Alex and played with Tidal Cycles a few years back. It was an mind bending experience and I need to find more time to go back to tidal again.

Similar https://glicol.org/

Also https://foxdot.org/

Also (kinda) similar: https://100r.co/site/orca.html

Got a few others also listed on https://wiki.thingsandstuff.org/Creative_coding

I’ve been making pop music with Tidal for almost 10 years:

https://youtube.com/@LilData

https://instagram.com/lildata.music

Do you have any opinions on Tidal vs supercollider on its own, or other systems like PD, max/msp?

jarmitage is a legend (in my eyes), so I'm sure he has his own opinions, but TidalCycles (as it is now known) depends on supercollider for both Midi and Sample playback. It communicates to supercollider through the OSC protocol, so it's conceivable supercollider could/can be swapped out for another engine. As is I think the install a bunch of Haskell stuff + install an editor plugin + install supercollider is the largest blocker to getting folks started with tidal. In the pre-tidalcycles era, Tidal played samples (only afaicr) through its own Dirt sample player which was still a separate process, but included with tidal itself. Now it uses SuperDirt which depends on supercollider.

Compared to PD and max/msp, Tidal is far more focused on the pattern language and the magic that can come out of that. Any 'programming as programming' has to be done with Haskell and loaded in as its own functions. Puredata and max/msp both are full (graphical) programming environments with their own quirks and special tricks, but in a way a bit more like Supercollider in that they can speak midi and do playback inside their own engines (afaik).

Personally I've never been attracted to writing SuperCollider code, especially not in a live context, largely due to its syntax, but also its complexity.

So-called 'visual programming languages' I don't find interesting for performance, since they rely on the mouse for program manipulation.

For me Tidal's mini-notation is the greatest music sequencing tool of all time, bar none. Every time someone shows me a sequencer I can usually write the Tidal code in my head on the spot, and save $1000s on redundant hardware. It could only be beaten by being turned into a physical instrument, something I've tried to do in the past: https://github.com/jarmitage/Stenophone.

That being said, even though I'm evidently a big Tidal fan I would still call attention to ICLC and HLCI, where amazingly creative and interesting new systems and approaches are being proposed every year:

https://iclc.toplap.org/

https://hybrid-livecode.pubpub.org/

I've followed your music (and PC Music) forever, and I love what you do with Tidal. AG Cook's work through PC Music and your own work has been a huge influence around where I've evolved my approach as a composer, so I want to say thank you for opening my eyes. I'll end this with a question -- what made you settle on Tidal vs other similar packages in different languages IE Sonic Pi (Ruby) and FoxDot (Python)? Is there something about Tidal/Haskell that fits your workflow or style better?

Thanks, I never expected to hear anything like this when I started out, so it means a lot!

I started around 2014 or so, when there were fewer systems available. I saw Alex McLean perform with Tidal and that was enough for me, although I like to think I would have ended up using it anyway.

The main thing that initially grabbed me was the arbitrary subdivision of time in the mini-notation, something I’d spent countless hours doing painfully by hand in a DAW. I love the terse syntax and simple yet powerful philosophies underlying Tidal.

Tidal Cycles communicating with Ableton through MIDI makes for an extremely fun composition experience. The power of simple, declarative sequencing combined with predictive randomness has transformed how I write basslines and riffs

Some readings:

[1] Dean, Roger T. The Oxford handbook of algorithmic music. Oxford University Press, 2018.

[2] Blackwell, Alan F., et al. Live coding: a user's manual. MIT Press, 2022.

[3] Kirkbride, Ryan Philip. Collaborative interfaces for ensemble live coding performance. Diss. University of Leeds, 2020.

[4] Roberts, Charlie, et al. "Rethinking networked collaboration in the live coding environment Gibber." (2022).

After experimenting with PD, Csound, SC, Tidal, and Glicol for several years, I am now working on a time-stretching/pitch-shift algorithm, together with some FM synthesis with LLM: https://github.com/chaosprint/glicol/discussions/139

What I want to say is that there are also many underlying algorithmic patterns in sound itself. In digital music, it's the sample-level pattern. It's fascinating to think about it, especially in the context of collaboration.

Interestingly you can do audio rate patterning with Tidal, I’ve tried it up to around 10kHz!

I've been to some algoraves where people livecode this, it's amazing to experience live.

quickscanning through docs i didn't see anything about using more conventional music notation (e.g abc) for the notes strings (as alternative to mini notation)

Was thinking more melody lines, eg

note(`[ [ [e5 [b4 c5] d5 [c5 b4]] [a4 [a4 c5] e5 [d5 c5]] [b4 [~ c5] d5 e5] [c5 a4 a4 ~] [[~ d5] [~ f5] a5 [g5 f5]] [e5 [~ c5] e5 [d5 c5]] [b4 [b4 c5] d5 e5] [c5 a4 a4 ~] ],[ [[e2 e3]4] [[a2 a3]4] [[g#2 g#3]2 [e2 e3]2] [a2 a3 a2 a3 a2 a3 b1 c2] [[d2 d3]4] [[c2 c3]4] [[b1 b2]2 [e2 e3]2] [[a1 a2]*4] ] ]/16`)

Versus

<score lang="ABC"> X:1 T:The Legacy Jig M:6/8 L:1/8 R:jig K:G GFG BAB | gfg gab | GFG BAB | d2A AFD | GFG BAB | gfg gab | age edB |1 dBA AFD :|2 dBA ABd |: efe edB | dBA ABd | efe edB | gdB ABd | efe edB | d2d def | gfe edB |1 dBA ABd :|2 dBA AFD |] </score>

One could probably write a parser that would convert between these