Patterns vs cycles

Hi, I am new to Tidal Cycles and I am impressed with its possibilities.
I am trying to create a quick reference to all possibilities of TC for myself. After reading lots the documentation from different sources, I am still confused about the usage of the terms ‘pattern’ and ‘cycle’.
A pattern is defined as e.g. ‘d1 $ s “cp bd”’ and at some point it is only “cp bd” and after that it is sometimes called a cycle.
Really confusing is e.g. concatenation of patterns or is it concatenation of cycles? Is a cycle just one loop of a pattern?
It would help to make (more) clear what the definitions of pattern and cycle are. Is that possible?

I think of a cycle as a unit of time

A pattern is a series of events

The spacing of the pattern events is defined by how many cycles you choose to apply the pattern over.

The speed at which the pattern executes is defined by your tempo (in cycles per second/cps)

  1. sound "bd cp" defines a pattern with two events, spaced over 1 cycle

  2. slow 2 $ sound "bd cp" defines the same pattern, with two events spaced over 2 cycles (because slow 2)

  3. sound "<bd cp>" defines the same pattern as in 2. because "<>" makes bd and cp alternate each cycle

  4. sound "bd cp" # cps 0.5 sets the pattern execution time to 1/2 cycle per second, so bd would play, a second will pass then cp will play

  5. sound "<bd cp>" # cps 1 will sound exactly the same as 4, but the events are playing in alternating cycles which are 1s in length

I'm not sure if any of this helps, but hopefully it explains something


Thank you @cleary for your clear answer!
I thought of what's between " " as a cycle, but in the notation "<bd cp>" the two elements replacing each other every other cycle.
In "bd <sn [hh cp*2]>" it is not "bd sn bd [hh cp*2]", like fastcat, but cat ["bd sn", "bd [hh cp*2"]]

The notation s "arpy [bd bd |cp |hh*3]" can only produce e.g. cat [s "arpy bd*2", s "arpy cp", s "arpy hh*3"] for one cycle. But not cat [s "arpy bd bd", s "arpy cp", s "arpy hh*3"] as notated.

If you know that it does work out this way, it is not a problem. And I can understand that in live coding the notation should be as short as possible. But for learning it is not straightforward.

In this case, 's' is shorthand for the 'sound' function -
You pattern the samples as an argument to the 'sound' function, but a function call is not a pattern itself

Tidal is a language, and you learn it like one. It has some imperfections and some inconsistencies - sometimes they can be problems and sometimes they can be exploited. It's constantly being developed so they're often fixed, and that can change the course of a previously written pattern. These are just the challenges of the tool we're choosing to use

Thank you again, @cleary. The examples I use are just for illustration.
As a programmer I am used to work with inconsistent languages, like PHP, but as Tidal Cycle is still under development it would be better to remove inconsistencies as soon as possible and be clear about the definitions of all the terms and functions and their naming. Haskell is a great language and well defined, why not use its possibilities to create a better implementation of TC.

Welcome @Componix!

Stuff between double quotes like "bd sn" is called 'mini-notation'.

A cycle is a unit of time. Most music software counts time in 'beats'. Tidal counts it in 'cycles', and the number of 'beats' per cycle is flexible and might change from one cycle to the next.

"bd sn" will repeat every cycle. "bd <sn cp>" will repeat every two cycles. So it doesn't really work to say this is a cycle.

A 'pattern' is a function from time to events. In particular, it's a function from a timespan to events that are active during that timespan. It's polymorphic, in that you can have a pattern of strings, or a pattern of numbers, or a pattern of synthesiser control messages.

The result of mininotation like "bd sn" is a pattern of strings. sound "bd sn" is a pattern of synthesiser control messages. So is sound "bd sn" # squiz "1 2", as the # operator joins together two patterns into a new pattern.

These things are very well defined and consistent, but perhaps not always described consistently in the documentation yet. You are welcome to help standardise the docs, there's an edit button on every page on . It's also helpful to ask a lot of questions as that helps everyone understand and work out how to better explain this stuff.

Thank you, Alex @yaxu for your answer. It makes things a bit more clear. As I understand now is that the "mini-notation" is an instruction to produce a pattern. My confusion is, I guess, more about the "mini-notation" and not about the domain specific language of TC itself. The functional way of constructing a pattern is clear, but is not always reflected inside the "mini-notation".
I will try to contribute to the documentation, but first I have to study more about the language itself and look more into the source code.

Here is an example why the documentation makes me doubt also about the structure of the language:
As I read through it, it gives an impression that function naming is not quite uniform.

I see in the documentation that timeCat is written with a capital C and fastcat is not.
But in the source code I see that fastCat is also allowed. So it is okay.

Kind regards

Yes true. This looks more uniform in the source code, but we are missing an alias for timecat. I've just added it for the next tidal release so timecat should work in the future.

(although I've found that in real life cats aren't so predictable)