Hey,
thanks for the link. I didn't read the Strudel doc yet.
Looking forward to trying this out once it's in Tidal.
1 Like
In summary, after a lot of work splitting out signals from sequences under a pattern class, I went back again to the single model of patterns being functions from timespans to events, adding another field for tactus which I'm now renaming to steps. Looking back at the history of Tidal's types, I've oscillated between these two approaches a lot..
This extra field is enough to support a lot of stepwise functionality. This is all that is needed, as the cycles can then become closer to standing for a period.. E.g. if you stepcat ["a b c", "d e"], you can a cycle of five steps. Once implemented, zip ["a b c", "d e"] would be a cycle of twelve steps ("a d b e c d a e b d c e"), and so on. You end up composing dense cycles stepwise that you then adjust to a particular steps per cycle with pace at the end.
So interestingly, introducing stepwise functionality also makes the concept of a cycle more coherent.
The problem is what to do with things like stepcat [fast "2 4" "a b c", "d e"]. In this case the first pattern doesn't have a fixed number of steps per cycle.. It's mixing cycle-based and step-based time transformation. Strudel gives up, but in Tidal steps per cycle is itself a pattern so it can try its best:
tidal> drawLine $ stepcat [fast "2 4" "a b c", "d e"]
[3 cycles]
|a-b-c-abcabcd---e---|a-b-c-abcabcd---e---|a-b-c-abcabcd---e---
Ah that's a lie, it works fine in strudel
stepcat("a b c".fast("2 4"), "d e").drawLine()
|a-b-c-abcabcd---e---|a-b-c-abcabcd---e---|a-b-c-abcabcd---e---
... because fast doesn't actually change the step count, it increases the density of events per step.
It works with expand too:
stepcat("a b c".expand("2 4"), "d e").drawLine()
|a-b-c-a---b---c---de|a-b-c-a---b---c---de|a-b-c-a---b---c---de
Hmm!
1 Like