Samples not playing for several bars after triggering

Questions and Answers
1

I'm running a do block that's using some samples that are 3-4 bars long. Whenever I trigger the do block the samples on channel 4 takes anywhere from 1-4 bars before it starts playing.
I was noticing some late messages in SC so I adjusted the values in the oLatency in the bootTidal.hs file but they still play very late.
The longest late message was 0.003 so I adjusted the oLatency to 0.05 to overcompensate with no noticeable change afterwards and then to 0.03 and still no change.
I'm not getting late messages now but the sample still takes forever to trigger.
Is this something to do with the slow command? The code is:

setcps (120/60/4)

do
  d1 $ sound "wolfkick [BehemothSnare, BehemothKick] wolfkick [BehemothSnare, BehemothKick, BehemothClap]"
  d2 $ sound "[BehemothOpen BehemothClosed BehemothOpen BehemothClosed]*4"
  d3 $ sound "[~] [BehemothMini BehemothMini ~ ~] [~] [BehemothMini BehemothMini ~ ~]"
  d4 $ slow 3 $ s "Sapph2Bass1:1" # gain 1.1
  d7 $ slow 4 $ striateBy 14 (1/4) $ rev $ s "symoneact2:1" # gain 1.1 # shape 0.2 # room 0.4 # size 0.4 # orbit 2

My sample on channel 4 is actually 4 bars long but for some reason in tidal it plays for 3 bars with a bar of silence when I set the command to slow 4.
If I remove the line of code with channel 7 from the do block it still has a weird 1-4 bar delay so it's not a weird mismatch between different sample lengths in the same do block.
When I trigger the line for d4 on its own it also has a weirdly long delay before playing.
I also tried changing the 's' to 'sound' to see if it made a difference and nothing changed.
The length of the delay doesn't seem consistent either. Sometimes it's 1 bar, other times it's 1 and a half or 3 bars before the sample starts playing.
Any ideas why it might be acting like that?

2

I can’t speak to the “3 bars with a bar of silence” part, though IIRC it might involve the use of a different function than slow, depending on the sample. I don’t recall the details off-hand but do recall reading it here or in the docs.

The “weird 1-4 bar delay” thing makes sense, though. You need to bear in mind that the event only arrives once every four bars, and that (as written) executing this kind of code block doesn’t mean “start now”, it means “update these patterns which are running in relation to tidal’s main clock.” Depending on when you execute the block of code, that could be anywhere between milliseconds later and four bars later.

There are some ways to run things sooner. Look into asap/once for one-shot behaviour, and for more loopy needs I believe there are ways to do it by referencing tidal’s current clock information but I’m not experienced with using those yet so hopefully another forum member can chime in on that part.

1 Like