javascript - 防止 BPM 自动收报机缓慢漂移与真实节拍器不同步

Question

我正在开发一个音乐发生器，它将 BPM 值作为输入，之后它将开始生成一些和弦、低音音符，并使用 MIDI 信号触发鼓 VSTi。

为了让一切都以正确的每分钟节拍数运行，我使用了一个挂钟计时器，它在您点击播放时从 0 开始计时，然后开始将 1/128 音符计数为“节拍”一个固定的时间间隔。每次函数滴答结束时，我都会通过简单地计算适合自开始时间的滴答数来检查 future 有多少滴答声:

class TrackManager {
  constructor(BPM) {
    this.tracks = ... 
    this.v128 = 60000/(BPM*32);
  }

  ...

  play() {
    this.tickCount = 0;
    this.playing = true;
    this.start = Date.now();
    this.tick();
  }

  tick() {
    if (!this.playing) return;

    // Compute the number of ticks that fit in the
    // amount of time passed since we started
    let diff = Date.now() - this.start;
    let tickCount = this.tickCount = (diff/this.v128)|0;

    // Inform each track that there is a tick update,
    // and then schedule the next tick.
    this.tracks.forEach(t => t.tick(this.tickCount));
    setTimeout(() => this.tick(), 2);
  }

  ...
}

轨道根据 Step 生成音乐，这些 Step 以节拍表示它们的预期播放长度(使用 .duration 作为持久长度指示器，以及 .end 设置为任何时候播放一个步骤的 future 滴答声值)，播放代码添加一个校正来播放一个步骤的滴答声数，以确保如果通过的滴答声多于预期(由于例如复合舍入误差)下一步将播放，但需要更少的滴答数，以保持同步。

class Track {
  ...

  tick(tickCount) {
    if (this.step.end <= tickCount) {
      this.playProgramStep(tickCount);
    }
  }

  playProgramStep(tickCount) {
    // Ticks are guaranteed monotonically increasing,
    // but not guaranteed to be sequential, so if we
    // find a gap of N ticks, we need to correct the
    // play length of the next step by that many ticks:
    let correction = this.stopPreviousStep(tickCount);
    let step = this.setNextStep();
    if (step) {
      step.end = tickCount + step.duration - correction;
      this.playStep(step);
    }
  }

  stopPreviousStep(tickCount) {
    this.step.stop();
    return (tickCount - this.step.end);
  }

  ...
}

这工作得相当好，但最终的音轨速度仍然存在一些漂移，在运行单独的节拍器时尤其明显(在我的例子中，鼓模式 VSTi，它被告知以哪个 BPM 播放哪个模式，以及然后留下来做自己的事情)。虽然最初听起来还不错，但大约一分钟后，节拍器播放的 BPM 与发生器运行的 BPM 之间出现了轻微但明显的不同步，我不确定这种不同步可能仍然来自哪里。

我本以为在节拍级别出现最微妙的不同步(对于 120 BPM 小于 16 毫秒)，这远低于明显的水平，但代码中似乎留下了复合不同步，我不确定它会在哪里。滴答声是根据系统时钟生成的，所以我不希望在 JS 遇到 Date.now() 的不稳定整数值之前出现不同步，我们不会这样做又跑了 285 年左右

什么可能仍然导致不同步？

Answer 1

事实证明，this.v128 的计算仍然会导致引入漂移的值。例如，120 BPM 产生每滴答 15.625 毫秒，这是相当可靠的，但 118 BPM 产生每滴答 15.889830508474576271186440677966[...] 毫秒，任何四舍五入(到任何数量的有效数字)最终都会产生越来越不正确的结果tickCount 计算。

这里的解决方案是通过将 this.v128 值替换为 this.tickFactor = BPM * 32; 来保持所有参与滴答计算整数的值，然后更改 tick() 函数以计算 tickCount 为:

tick() {
  if (!this.playing) return;

  // Compute the number of ticks that fit in the
  // amount of time passed since we started
  let diff = Date.now() - this.start;

  // first form a large integer, which JS can cope with just fine,
  // and only use division as the final operation.
  let tickCount = this.tickCount = ((diff*this.tickFactor)/60000)|0;

  // Inform each track that there is a tick update,
  // and then schedule the next tick.
  this.tracks.forEach(t => t.tick(this.tickCount));
  setTimeout(() => this.tick(), 2);
}