It's also notable for being probably the only Haskell library used almost exclusively by people with no prior knowledge of Haskell, which is an insane feat in itself.
I think I must not be expressing myself well. These tools seem to be optimized for parametric pattern manipulation. You essentially declare patterns, apply transformations to them, and then play them back in loops. The whole paradigm is going to encourage a very specific style of composition where repeating structures and their variations are the primary organizational principle.
Again, I'm not trying to critique the styles of music that lend themselves well to these tools.
> And yet it also constrains and prevents the construction of bad programs in a very strict manner via its type system and compiler.
Looking at the examples in their documentation, all I see are examples like:
d1 $ sound "[[bd [bd bd bd bd]] bd sn:5] [bd sn:3]"
So it definitely isn't leveraging GHC's typechecker for your compositions. Is the TidalCycles runtime doing some kind of runtime typechecking on whatever it parses from these strings?> It's also notable for being probably the only Haskell library used almost exclusively by people with no prior knowledge of Haskell, which is an insane feat in itself.
I think Pandoc or Shellcheck would win on this metric.
the runtime is GHC (well GHCi actually). tidal's type system (and thus GHC's typechecker) ensures that only computationally valid pattern transformations can be composed together. if you're interested in the type system here's a good overview from a programmer's perspective https://www.imn.htwk-leipzig.de/~waldmann/etc/untutorial/tc/...
these strings are a special case, they're formatted in "mini-notation" which is parsed into composed functions at runtime. a very expressive kind of syntactic sugar you could say. while they're the most immediately obvious feature of Tidal (and have since been adapted in numerous other livecoding languages), mini-notation is really just the tip of the iceberg.
>The whole paradigm is going to encourage a very specific style of composition where repeating structures and their variations are the primary organizational principle.
but that applies to virtually all music, from bach to coltrane to the beatles! my point is that despite what the average livecoder might stream/perform online, live coding languages are certainly not restricted to or even particularly geared towards repetitive dance music - it just happens that that's a common denominator of the kind of demographic who's interested in livecoding music in the first place.
i'd argue that (assuming sufficient knowledge of the underlying theory) composing a fugue in the style of bach is much easier in tidal than in a DAW or other music software. on the more experimental end, a composition in which no measure ever repeats fully is trivial to realize in tidalcycles - it takes only a handful of lines of code to build up a stochastic composition based on markov chains, perlin noise and conditional pattern transformations. via the latter you can actually sculpt these generative processes into something that sounds intentional and follows some inner logic rather than just being random.
the text-based interface makes it much easier to use than anything GUI-based. it's all just pure functions that you can compose together, you could almost say that Tidal is like a musical equivalent of shell programs and pipes. equally useful and expressive both for a 10 year old and a CS professor.
>I think Pandoc or Shellcheck would win on this metric.
touché!
I agree that it's easier to build a composition in a coding environment that uses stochastic models, markov chains, noise, conditions, etc. But I don't think that actually makes for compelling music. It can render a rough facsimile of the structure, but the result is uncanny. The magic is still in the tiny choices and long arc of the composition. Leaving it to randomness is not sufficient.
Bach's style of composition _is_ broadly algorithmic. So much so that his style is taught in conservatories as the foundational rules of Western multi-voice writing, but it's still not a perfect machine. Taste and judgment have to be exercised at key moments in the composition on a micro level. You can intellectually understand florid counterpoint on a rules-based level, but you still have to listen to what's being written to decide if it's musically compelling or if it needs to be revised.
The proof is in the pudding. If coded music were that good, we would be able to list composers who work in this manner. We might even have charting music. But we don't, and the best work is still being done with instruments in hand, or written on a staff, or sequenced in a DAW.
I want this paradigm to work - and perhaps it can - but I've yet to hear work that lives up to the promise.
"Computer games don't affect kids. If Pac Man affected us as kids, we'd all be running around in darkened rooms, munching pills and listening to repetitive music." -- Marcus Brigstocke (probably?)
Also, related but not - YouTube's algorithm gave me this the other day - showing how to reconstruct the beat of Blue Monday by New Order:
My sister likes to work with [checks notes carefully to avoid the wrong words] old textiles. This of course constrains the kind of art she can make. That's the whole point.
I see live coding the same way as the harp, or a loop sampler, an instrument, one of an enormous variety of tools which you might find suits you or not. As performance I actually enjoy live coding far more than most ways to make music, although I thought Amon Tobin's ISAM Live was amazing that's because of the visuals.
And year, your music tools/instruments constrain you. There are only so many music genres you can reasonable play or compose on an acoustic guitar. Or an oboe. Or modular synths. I suspect it's _possible_ to compose and play altrock or country music using live coding instead of a guitar - but why would you?
For the end result .. which we've yet to hear.
Before it landed a country(?) banjo(?) cover of Eminem's rap classic Lose yourself was a but why would you.
And then Kasey Chambers owned it.
Johnny Cash's "Hurt" is an example where the performance was transformative. Reznor's "Hurt" is a song by a 20-something addict feeling sorry for himself. However Cash is a man who knows he actually doesn't have much time left†, and so almost identical lyrics ("Crown of shit" is changed) feel very different.
† Cash died about a year after his recording was published.
I'm only aware of it myself because of an unusual number of vocal coaches being overly enthusiastic about it. "Country" is a an odd label for it given the transition midway.
The thrust to the comment was to remind the GP to not limit their expectations about what others might do. You yourself highlighted Cash's cover as something you deem of value, it's another example of an unexpected product.
Live coding my or may not progress in any particular direction or genre, I'd prefer to not make any predictions myself and leave open the possibility of being pleasantly surprised.
To kinda get away from that or even just experiment, I was interested in the possibility of writing music with code and either inject randomness in places or at least vary the intervals between beats/etc using some other functions (which would again just be layering in patterns, but in a more subtle way).
I think this format of composition is going to encourage a highly repetitive structure to your music. Good programming languages constrain and prevent the construction of bad programs. Applying that to music is effectively going to give you quantization of every dimension of composition.
I'm sure its possible to break out of that but you are fighting an uphill battle.