music_note オンラインメトロノーム(タップテンポ) star

ほとんどのブラウザ製メトロノームがずれる理由

JavaScriptでメトロノームを作る最も分かりやすい方法はsetInterval(playClick, 60000 / bpm)です。これは数秒間はうまく動きますが、そのうち動かなくなります。setIntervalが保証しているのは、コールバックが要求された遅延時間より早く発火しないということだけで、実際にどれだけ遅く発火する可能性があるかについては何も保証しません。JavaScriptのメインスレッドは、ページが行うあらゆること — DOMの更新、レイアウト計算、ガベージコレクション — と共有されており、そのどれもが保留中のタイマーを数十ミリ秒遅らせる可能性があります。ほとんどのUIコードにとってこれは気づかれることのない問題ですが、メトロノームにとっては致命的です。あるビートで40ミリ秒遅れ、次のビートで10ミリ秒遅れるクリック音は、単に「ずれている」だけでなく耳で分かるほど揺らぎ、それを頼りに練習しているミュージシャンを積極的に誤らせてしまいます。

ミュージシャンがメトロノームに頼るのは、まさに人間の一定時間に対する感覚が、外部の基準なしでは信頼できないからです — これは1815年にJohann Maelzelがぜんまい式のバージョンを特許取得して以来、この装置の存在意義そのものです。それ自体がずれるソフトウェア製メトロノームは、その目的を台無しにしてしまいます。そして解決策は、より賢いタイマーを使うことではありません。requestAnimationFrameを含め、すべてのJSタイマーは同じメインスレッドのボトルネックを共有しているからです。本当の解決策は、JavaScriptに正しい瞬間に音を出すよう求めること自体をやめることです。

先読みスケジューリング: このメトロノームが正確さを保つ仕組み

このツールは、かつてGoogle ChromeのWeb Audioチームに所属していたChris Wilson氏が、広く引用されている記事「A Tale of Two Clocks」で広めたパターンを使用しています。スケジューリングのロジックを音のタイミングから完全に切り離すという考え方です。Web Audio APIのAudioContextは、サンプル精度のクロックを持つ専用のオーディオスレッド上で動作し、それはAudioContext.currentTimeとしてJavaScriptに公開されています。そのクロックから得た未来のタイムスタンプを使ってosc.start(t)を呼び出すと、オーディオエンジンはその瞬間にメインスレッドが何をしていようと関係なく、正確にtの時点で音を再生します — ビートちょうどのタイミングで「目を覚ます」必要は一切なかったのです。

メインスレッドの仕事は帳簿付けだけです。およそ25ミリ秒ごとに、スケジューラーが今後100ミリ秒以内に来るビートがないかを確認し、それぞれについて正確な未来のcurrentTimeを指定してosc.start()を呼び出します。このループはおおよそ時間通りであればよいため、通常のジッターが耳で分かる問題を引き起こすことはありません — 音自体は依然としてサンプル精度でスケジュールされているからです。各クリック音は約30ミリ秒のオシレーターのバーストで、各小節の1拍目は耳で分かるアクセントとして高い音程になり、対応する視覚的なパルスと同期しています。

タップテンポは別の問題を解決します。それは、読み取るための譜面がない音楽のBPMを見つけることです。ビートに合わせてタップすると、このツールはタップ間の間隔を測定し、60000 / averageIntervalMsで変換します。少なくとも2回のタップが必要で、直近のタップの平均を取ることで小さなタイミングの誤差が平滑化されます。2秒を超える間隔があると、それは通常ビートを見失ったことを意味するため、シーケンスがリセットされます。