Should these generate the same pattern?
d1 $ s "bd/1.25 sn"
d1 $ stack [ s "bd/1.25", s "~ sn" ]
It's a bit easier to hear if you pan like
d1 $ s "bd/1.25 sn" # pan "0 1"
d1 $ stack [ s "bd/1.25" # pan 0, s "~ sn" # pan 1]
The bd of the patterns plays like this (well it would but I couldn't get tidal to play nice with the pattern to slow)
d1 $ slow "<1.125 1.125 1.125 1.625>" $ s "bd"
d1 $ slow "1.25" $ s "bd"
The version using stack plays a 4 against 5 pattern with the two playing in unison on their third triggers as expected.
The first version above ends up using timeCat which mentions fastcat in a comment so I tried these versions below and they behave identically to the first pattern above even though timeCat uses rotR and _fastGap rather than any kind of cat.
[I notice that at some point my tests changed to the snare hitting on the first half of the cycle, it doesn't really impact the issue but sorry.]
d1 $ fastcat [ slow 1.25 $ s "bd", s "sn" ]
d1 $ fast 2 $ cat [ slow 1.25 $ s "bd", s "sn" ]
I investigated a simplified version using cat since it's simpler than timeCat and they behave the same.
Here are the transforms that I noticed in cat and slow (transforming the query then the result - I hope they make sense)
setcps 1
d1 $ cat [ slow 1.25 $ s "bd", s "sn" ]
global cat slow Event slow cat
/ 1.25 * 1.25
0>1 0>1 0>0.8 0 - BD 0 0
1>2 0>1 0 - SN 1
2>3 1>2 0.8>1.6 1 - BD 1.25 2.25 (should be 2.5)
3>4 1>2 1 - SN 3
4>5 2>3 1.6>2.4 2 - BD 2.5 4.5 (should be 5)
5>6 2>3 2 - SN 5
6>7 3>4 2.4>3.2 3 - BD 3.75 6.75 (should be 7.5 **)
7>8 3>4 3 - SN 7
8>9 4>5 3.2>4.0 -
9>10 4>5 4 - SN 9
10>11 5>6 4.0>4.8 4 - BD 5.0 10
11>12 5>6 5 - SN 11
12>13 6>7 4.8>5.6 5 - BD 6.25 12.25 (should be 12.5)
In this particular case the result needs to be multiplied by n (number of buckets) and then offset by the bucket # (cycle mod n). I could get this far but the ** interesting problem is that for events triggered in the second half of the cycle this ends up generating results that are beyond the current cycle's end and are dropped and they won't be picked up again in the next cycle. Completely abandoning cat it's pretty straight forward (in this fairly simple case) to build a pretty simple solution using stack/rotR/slow similar to how TPat_Seq is expanded in the bp parser.
[Edit: I discovered that although the first version of the stack/rotR/slow worked for this case it didn't work for nested patterns at all so here's a pattern that seems to to work with arbitrary nesting although it doesn't work for nested patterns that include slow and, well, that's the whole point so I'll keep looking for one that does work.]
d1 $ stack [ slow 1.25 $ s "bd", s "~ sn" ] # pan 0
d2 $ stack [ slow 1.25 $ s "bd", stack [ rotR 0 $ _fastGap 2 $ silence, rotR (1%2) $ _fastGap 2 $ s "sn" ] ] # gain 1
Here's the post's first version for posterity.
d1 $ stack [ slow 1.25 $ s "bd", s "~ sn" ] # pan 0
d2 $ fast 2 $ stack [ rotR 0 $ slow 2 $ slow 1.25 $ s "bd", rotR 1 $ slow 2 $ "sn" ] # pan 1
As I said before, playing & learning.
) The "skipped" cycle is just the 4 ticks that are part of the previous hit. No different mathematically (but quite different rhythmically) than skipping from 3 3/4 to 5 in an uncompressed version.