Tone.js: Transport + Players. Events go out of sync after 25-50 repetitions.

I’m layering 4 bar loops at 126.25bps (ogg with 6 decimal places of timing accuracy) at 320kbps so fairly light. After 25-50 iterations timing goes out of sync and eventually eliminates as much as a quarter note out of the loop. Inlcuding performance summary from Chrome representing structure of a single Task. I’m using React and not sure how you tested this (with loops) so might be a good opportunity to take a look as setup is in CodeSandbox. I’m attaching player in Track.jsx and using player object loop like this for every track.

https://codesandbox.io/s/github/MusicAsCode/set-player/tree/master/

    player.autostart = false;
    player.loop = true;
    player.loopStart = "0:0:0";
    player.loopEnd = "4:0:0";
    player.toMaster().sync();
    player.start();

This is quite a big Task structure that takes over 20ms to execute (this is from a still correctly audible iteration) Are they normally as complex or am I doing something wrong. Any recommendations?

About this issue

Original URL
State: closed
Created 4 years ago
Reactions: 2
Comments: 16 (4 by maintainers)

Most upvoted comments

@styk-tv If this issue is still persisting it might be because you are setting state from within the Loop callback. I had a similar issue that I resolved by removing any state updates from within the callback. In React state updates are not instant so in this case they are causing issues.

var loop = new Tone.Loop(function(time) {
    // do something

    // removing the set state below might remove any timing lag
    setTracksPos(Tone.Transport.position.toString().split(".")[0]);
  }, "4n").start(0);

Also if you use Tone.Sequence instead you can keep track of the current step by using the second argument.

useEffect(() => {
    new Tone.Sequence((time, step) => {
        // do something

        console.log(step)
      },
      [0, 1, 2, 3], "4n"
    ).start(0);
  }, []);

eoghanmccarthy on Mar 29, 2020

I am working to port this to 14+ …

styk-tv on Mar 19, 2020

@tambien Yotam,

tested with 3.8.34 and issue still remains. interesting fact is that this incremental start offset (issue) being added on every loop restart persists Tone.Stop() and Tone.Start()

All digging points to conclusion that player settings are honoured:

    player.autostart = false;
    player.loop = true;

transport setup

  Tone.Transport.timeSignature = [4, 4];
  Tone.Transport.bpm.value = 126.25;
  console.log("default bmp: " + Tone.Transport.bpm.value);
  Tone.Transport.loop = true;
  Tone.Transport.loopStart = "0:0:0";
  Tone.Transport.loopEnd = "4:0:0";

but transport settings especially start position is slowly shifting forwards, so it manifests with empty space then proper loop start, then loop cut off at the end repeat. in case of my example it takes 32 iterations to be audible. with tempo at 60/126.25bpm and loop at 4 bars = 7.603960396039604 per loop and audible at 243+ seconds

attaching paste of the transport beat positions. standard 4/4 signature 4 bars so 16 beats per iteration. you can see that scheduler seems to be doing a good job for a while, but after average above the error is so big that it jumps into the next quarter note and completely looses a beat.

this ubuntu pastebin is valid for a year until 2021-03-08, it represents 4 tracks (for same size loops) being played over and over, each one independently reporting its playback beat position.

https://paste.ubuntu.com/p/SywzwNmzwn/

Progressively Shifting Transport Start 0:0:0 Position:

Iteration 01 --> line 0004 --> Transport Beat Position: 0:0:0 
Iteration 02 --> line 0068 --> Transport Beat Position: 0:0:0.101
Iteration 03 --> line 0132 --> Transport Beat Position: 0:0:0.203
Iteration 04 --> line 0196 --> Transport Beat Position: 0:0:0.214
Iteration 05 --> line 0260 --> Transport Beat Position: 0:0:0.271
Iteration 06 --> line 0324 --> Transport Beat Position: 0:0:0.327
Iteration 07 --> line 0388 --> Transport Beat Position: 0:0:0.069 (seems schedule corrected)
Iteration 08 --> line 0452 --> Transport Beat Position: 0:0:0.171 (but then cycle repeats..)
..
..
Iteration 14 --> line 0836 --> Transport Beat Position: 0:0:0.33
..
..
Iteration 19 --> line 1156 --> Transport Beat Position: 0:0:0.388
Iteration 20 --> line 1220 --> Transport Beat Position: 0:0:0.489
..
..
Iteration 24 --> line 1476 --> Transport Beat Position: 0:0:0.58
..
..
Iteration 31 --> line 1924 --> Transport Beat Position: 0:0:0.616
..
..
Iteration 34 --> line 2116 --> Transport Beat Position: 0:0:0.83 (seems good recovery)
Iteration 35 --> line 2184 --> Transport Beat Position: 0:0:0.707 (but then slowly loosing the battle)
..
..
Iteration 39 --> line 2448 --> Transport Beat Position: 0:0:0.888
..
..
Iteration 41 --> line 2584 --> Transport Beat Position: 0:0:1.001 (and then unthinkable happens, we lost a full beat and loop is no longer 16 beats)
..
..
Iteration 45 --> line 2852 --> Transport Beat Position: 0:0:1.227 (keeps loosing time)
Iteration 54 --> line 3440 --> Transport Beat Position: 0:0:1.69 (keeps loosing time and eventually will loose another beat)

transport compensation lost the battle it seems

styk-tv on Mar 7, 2020