防止 BPM 计时码表与真正的节拍器慢慢不同步

Posted 2023-02-16

【中文标题】防止 BPM 计时码表与真正的节拍器慢慢不同步

【英文标题】：Preventing a BPM ticker from slowly drifting out of sync with a real metronome

【发布时间】：2018-03-28 16:48:23

【问题描述】：

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

为了让一切以正确的每分钟节拍数运行，我使用了一个挂钟计时器，当您点击播放时，时钟从 0 开始，然后在有规律的间隔。每次函数结束时，我通过简单地计算适合自开始时间的刻度数来检查我们未来有多少刻度：

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);
  

  ...

音轨根据Steps 生成音乐，它以节拍表示其预期的播放长度（使用.duration 作为持久长度指示器，并使用.end 设置为未来的节拍值，只要播放一个步骤)，播放代码添加对播放步骤的刻度数的更正，以确保如果通过的刻度多于预期（例如由于复合舍入错误），则播放下一步，但是 - 许多刻度 -必要的更少，以保持同步。

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 年左右的时间

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

【问题讨论】：

为什么不直接使用真正的 MIDI，它通常以每四分音符 96 个脉冲运行？另外，你在同步什么？无论 BPM 是什么，您都应该遵循其时钟信号以保持完美同步。此外，使用性能计时器，而不是 Date.now()，以获得更准确的计时。

因为不能保证有一个主 DAW 正在运行，所以这将有效地运行“独立”在三个虚拟设备上生成 MIDI-OUT 信号，这些信号可能会被 DAW 播放其他东西读入，但也可能不会。性能计时器是个好主意，尽管考虑到充分同步所需的时间分辨率，Date.now() 确实可以完成所做的更改。

【参考方案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);