cps patterns do not sound correct

[kindohm]

Using these patterns:

d1 $ s "bd bd bd cp*8" # cps "1 1 1 0.125"
d1 $ s "bd bd bd cp*4" # cps "1 1 1 0.125"
d1 $ s "bd bd bd cp*4" # cps "1 1 1 0.25"

When the pattern gets to the cp sample, the timing sounds off. It sounds like there are two cp samples played very quickly together at the beginning of the 0.75-1.0 arc, followed by the remaining cp samples.

So for example, this:

d1 $ s "bd bd bd cp*4" # cps "1 1 1 0.25"

Sounds more like this (approximately):

d1 $ "bd bd bd [[cp*2 ~ ~ ~ ~] cp cp]"

Version: Tidal 1.0.10
OS: MacOS

[yaxu]

Interesting, same under linux.. I'll have a look

[yaxu]

Do you think this is a new bug?

[kindohm]

I bet this has existed since at least 1.0.7, which I've been stuck on for a while. May have existed earlier.

[bgold-cosmos]

If I slow it down a bit with a |* cps 0.25 at the end, then sometimes it sounds OK. It seems a bit random about when, though. I suspect there's some kind of subtle timing issue with scheduling the cps changes vs latency or something similar.

[kindohm]

Was wondering if the latest from the master branch might have fixed this, but not yet. Still hearing some unevenness/stuttering when shifting between cps values:

d1 
  $ cat [ 
    s "[bd*4, cp]" # cps 1
    , s "[bd*36, cp*4]" # cps 0.3 
  ]

It sounds like when the 2nd pattern starts, there are some extra notes thrown in. Like a remainder from the first pattern, even though the first pattern has audibly completed.

[yaxu]

I haven't had a chance to look at this yet, keen to though!

[yaxu]

Could you make a recording of that please @kindohm? That's kind of sounding OK to me, it might be slightly off but I don't think I hear extra notes. It'd also be good to know what cFrameTimespan you're running at.

[yaxu]

Actually forget that - if I change the samples the stuttering / extra notes are clear.

[yaxu]

With a slightly simpler version:

d1 
  $ cat [ 
    s "bd" # gain 0 # cps 2 -- s "[clap:4*8, cp]" # cps 1
    , s "[clap:3*16]" # cps 0.25
  ]

I can see that the second clap gets generated twice, with the same cycle value but slightly different timestamps. Also the cps doesn't have an effect on the timestamp until the second clap. So that fully confirms what you're hearing.

I'm not surprised the timing is wrong but am surprised by the extra clap.

When the scheduler sees a cps control it schedules a cps change for the future. That's wrong however, events are scheduled ahead of time, so the cps should be changed ahead of time too.

The extra event is another bug, somehow it's calculating some slice of time twice, but can't immediately see why it's doing that.. It should always start from where the last calculation left off.

[yaxu]

Ah, it's because the scheduler now works on system clock time, not cycles.

[yaxu]

I'm not 100% sure it's fixed but seems a lot better, see what you think!

[yaxu]

Still getting what seems like the same behaviour with this one

d1 
  $ cat [ 
    s "bd" # cps "4"
    , s "[sd:1*16]" # cps 0.5
  ]

[kindohm]

Pulled latest just now. Still hearing the issue. It kind of seems like I have to make large cps differences (e.g. from 3 to 0.2) in order to hear it. Example:

d1 
  $ cat [ 
    s "[drum*4, odx:1]" # cps 3
    , s "[bd*36, cp*4]" # cps 0.2 
  ]

[kindohm]

Hmmm it seems like the smaller the cps difference between patterns the less often it happens, but it still happens. The larger the difference, it seems to happen on every cps change.

[kindohm]

fwiw here is how I am booting tidal:

tidal <- startTidal (superdirtTarget {oLatency = 0.1, oAddress = "127.0.0.1", oPort = 57120}) (defaultConfig {cFrameTimespan = 1/20})'

[yaxu]

My current hypothesis is that the timing issue is fixed, but some events are getting processed twice.
The bug seems to be that if the cps slows partway through the processing of a frame, then the remaining events are processed even though they are now outside of that frame.

[yaxu]

Ok seems better now