javascript - 防止BPM代码缓慢地与实际的节拍器不同步漂移

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

为了使所有内容以每分钟正确的节拍数运行，我使用了挂钟计时器，当您敲击演奏时，该钟从0开始计时，然后每隔一定间隔就开始将1/128个音符计数为“滴答声” 。每次函数滴答结束时，我都可以通过简单地计算time-since-start内适合的滴答声数量来检查将来有多少滴答声：

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生成音乐，这些音乐以滴答声表示其预期的播放长度（使用.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左右的千年

是什么仍然可能导致失步？

最佳答案

事实证明，this.v128的计算仍可能导致引入漂移的值。例如，120 BPM的每刻度产生15.625ms，这是相当可靠的，但是118 BPM的每刻度产生15.889830508474576271186440677966ms。 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);
}

关于javascript - 防止BPM代码缓慢地与实际的节拍器不同步漂移，我们在Stack Overflow上找到一个类似的问题：https://stackoverflow.com/questions/49540098/