39. MIDIファクトシート

39.1 理想的なMIDI動作

デジタル・オーディオ・ワークステーション（DAW）内でMIDIがどのように動作するかを理解するために、参考となる用語や概念についていくつか紹介します。 DAWでは、MIDIに関連した3つの異なるシナリオに対処する必要があります。

1. レコーディング とは、ハードウェア機器（MIDI鍵盤など）からMIDIノートやコントロール情報をDAWに送信して保存することです。 理想的なレコーディング環境であれば、ソングのタイムラインに合わせて、この入力情報をオーディオレコーディングのような完璧なタイミング精度で取り込むことができます。
2. プレイバック とは、DAWを扱う際に関連する2つのシナリオを指します。 1つ目のシナリオは、MIDIノートやコントロール情報を、DAWからシンセサイザーなどのハードウェア機器へ送信することです。 2つ目のシナリオは、Operatorシンセサイザーなどのデバイスを再生する際、保存したMIDI情報をコンピューター内でオーディオデータに変換できるようにすることです。 どちらのケースでも、理想的な再生環境であれば保存した情報を完璧に再現できます。
3. プレイスルー とは、ハードウェア機器（MIDI鍵盤など）からMIDIノートやコントロール情報をDAWへ送信して、リアルタイムでハードウェア・シンセサイザーに戻したり、DAW内のプラグイン・デバイスへ送ることを指します。 理想的なプレイスルー環境であれば、ピアノなどの物理的な楽器と同じくらい正確で反応が速く「感じられ」ます。

39.2 MIDIタイミングの問題

コンピューターベースのMIDIは複雑であり、非常に多くの不確定要素が含まれているため、前述のような理想的なシステムを構築するのは不可能です。 2つの基本的な問題があります。

1. レイテンシー とは、システム固有の一定した遅延を指します。 これは、DAW特有の問題です。 デジタルオーディオは、オーディオインターフェースとリアルタイムで送受信できないため、その代わりにバッファーが必要になります。 アコースティックピアノでさえ、ある程度のレイテンシーが生じます。ピアノの場合では、鍵盤を押さえてからハンマー機構が弦に触れて音を出すまでの間、いくらかの遅延が生じます。 演奏面から言えば、少ないレーテンシーはほとんどの場合問題とはなりません。遅延が一定であれば、演奏家は他の演奏家とタイミングを合わせ、遅延を補正できるためです。
2. ジッター とは、システム内の一定しないランダムな遅延を指します。 これは特にDAW内部で問題となります。システム（MIDI、オーディオ、ユーザーインターフェースなど）内部のさまざまな機能が個別に処理されるためです。 MIDIデータをプラグインのプレイバックに変換する場合など、情報をある処理から別の処理へと移動させる必要がほとんどです。 ジッターのないMIDIタイミングには、システムを構成するコンポーネント（MIDIインターフェース、オーディオインターフェース、DAW自体）内の異なるクロック間で、正確な変換を行う必要があります。 この変換の精度は、使用するオペレーティングシステムやドライバーのアーキテクチャーなどさまざまな要素によって異なります。 ジッターが生じると、レイテンシーが生じた場合よりもMIDIタイミングの「もたり」や「ずれた」印象を与えます。

39.3 LiveのMIDI解決策

MIDIのタイミングに対するAbletonのアプローチは、2つの重要な前提に基づいています。

1. どのような場合でも、ジッターよりもレイテンシーが生じる方が望ましい。 レイテンシーは一定で予見可能であるため、コンピューターや人間によって比較的簡単に対処できます。
2. 録音中にプレイスルーを使用する場合、レイテンシーにより 演奏 からわずかに遅れて聞こえたとしても、聞こえている 音を録音したいと思うでしょう。

Liveは、MIDIのタイミングが反応良く、正確で一貫して信頼性のあるものになるよう、レコーディング、プレイバック、プレイスルー固有の問題を処理します。 受信したイベントをLiveセットのタイムラインの正しい位置へ録音するには、これらのイベントがMIDI鍵盤から入力された正確な時間を、Liveが検知している必要があります。 しかし、Liveはイベントを直接受信することはできません。 イベントは、まずMIDIインターフェースのドライバーとオペレーティングシステムにより処理される必要があります。 この問題を解決するため、インターフェースのドライバーは、MIDIイベントを受信すると、各イベントに タイムスタンプ を付けます。 タイムスタンプはイベントと共にLiveへと送られ、Liveがいつイベントをクリップに加えたらよいか正確に検知できるようになります。

プレイスルー中、DAWはすぐに聞こえるべきイベントをなるべく早く処理する必要がありますが、これらのイベントはレイテンシーやシステム遅延といった避けられない要因により、実際にはすでに過去に発生したものになります。 そこで選択を迫られます。イベントを受信した時点で再生するべきか（システムの状態によってジッターを生じる場合がある）、遅延するべきか（レイテンシーが増える）、どちらかを選択しなければなりません。 Abletonが選んだのはレイテンシーを増やす方です。ユーザーにとって、ランダムなジッターよりも一定のレイテンシーの方が適応しやすいと判断したためです。

レコーディング中にモニタリングをオンにすると、Liveはお使いのハードウェアのバッファーサイズに基づき、イベントのタイムスタンプをさらに遅延させます。 この追加レイテンシーにより、イベントを 再生 した時点ではなく、イベントが 聞こえた 時点で、イベントをクリップに記録できるようになります。

ハードウェア機器をプレイバックする場合、出力するMIDIイベントをスケジューリングするため、Liveはタイムスタンプを生成して、MIDIインターフェースのドライバーと通信しようと試みます。 しかし、Windows MMEドライバーはタイムスタンプを処理できないため、このドライバーを使用するデバイスに対しては、Liveの内部でイベントをスケジューリングします。

オーディオがドロップアウトするようなシステム負荷の高い状態であっても、Liveは入力されるMIDIイベントの受信を続けます。 オーディオのドロップアウトが生じる場合、プレイスルー中にタイミングが狂ったり、オーディオが歪むことがありますが、それでもLiveは正確にMIDIイベントをクリップへ記録します。 その後、システムがドロップアウトから復帰すると、記録したイベントのプレイバックは正確になるはずです。

39.4 Liveがコントロールしきれない要素

一般的に、タイムスタンプは、MIDIイベントのタイミングを扱うのに非常に信頼度の高い構造です。 しかし、タイムスタンプは、コンピューター内部のデータにのみ適用されます。 コンピューターの外部にあるMIDIデータはこの情報を利用できないため、外部機器と送受信するタイミング情報は、外部機器がスケジュールに沿って処理するのではなく、受信するとすぐに処理されます。 さらに、MIDIケーブルは 直列 です。 つまり、一度にひとつの情報しか送信できません。 同時に演奏した複数のノートは、MIDIケーブルを介して同時に送信できないため、順番に送信する必要があります。 イベントの密度によっては、MIDIのタイミングに問題が発生する場合があります。

もう一つの問題は、特にMIDI黎明期のハードウェア・シンセサイザーを扱う際に起こり得るもので、機器の スキャンタイム の速度が比較的遅い可能性があることです。 スキャンタイムとは、シンセサイザーが鍵盤の入力があるかどうか確認する頻度を指します。 この速度が遅すぎると、ジッターを生じることがあります。

ハードウェアレベルで存在するこのようなタイミングの問題は、機材が増えるごとに増加します。

コンピューター内であっても、タイムスタンプの精度は、MIDIインターフェースの品質やドライバー・プログラミングのエラーなどによって、大きく変化する場合があります。 Liveは、入力したMIDIイベントに添付されたタイムスタンプが正確であり、送信するイベントは外部機器で正確に処理されるという前提で動作します。 しかし、どちらの状況もLiveが確認することは不可能です。

テストと結果

入力MIDIイベントのタイミングを検証する手順は、以下の図のとおりです。

MIDIソース （ランダムなMIDIイベントの長いシーケンスを再生する鍵盤や他のDAW）の出力を、レイテンシーのない MIDI分配器 に送ります。 分配器の出力の一部をLiveの新規MIDIクリップに録音します。 他の出力は MIDI-Audioコンバーター に送ります。 この機器は、MIDIソースからの電気信号を単純なオーディオノイズに変換します。 この機器はMIDIデータを読み取らないため、この変換をレイテンシーなしで処理します。 その後、このコンバーターの出力をLiveの新規オーディオクリップに録音します。 理想的なシステムでは、MIDIクリップ内の各イベントはオーディオクリップ内の対応するイベントと同時に発生します。 したがって、2つのクリップでMIDIとオーディオのイベント間でタイミングの差異を計測すると、Liveの精度を判断できます。

さまざまな条件下でMIDIのパフォーマンスを評価するため、MIDIを備えた価格帯の異なる3つのオーディオインターフェース（すべて有名メーカーの製品）を用いてテストを実施しました。 これらのインターフェースをそれぞれA、B、Cと呼びます。 すべてのテストは、macOSとWindowsマシンの両方に約 50％ のCPU負荷をかけて実施しました。 どちらもサンプルレートは 44.1 kHzと 96 kHzで、3つの異なるオーディオバッファーサイズを使用し、合計で 36 項目を個別にテストしました。

Windowsの場合

• インターフェース A: 最大ジッターは+/- 4 msで、ジッターの大部分は+/- 1 msで生じました。
• インターフェース B: ほとんどのテストで、最大ジッターは+/- 3 または 4 msでした。 96 kHz/バッファーサイズ 1024 サンプルでは、いくつかのイベントで+/- 5 msのジッターが生じました。 44.1 kHz/バッファーサイズ 512 サンプルでは、いくつかのイベントで+/- 6 msのジッターが生じました。 すべてのケースにおいて、ジッターの大部分は+/- 1 msで生じました。
• インターフェース C: ほとんどのテストで、最大ジッターは+/- 5 msでした。 96 kHz/バッファーサイズ 512 サンプルでは、いくつかのイベントで+/- 6 から 8 msのジッターが生じました。 44.1 kHz/バッファーサイズ 1024 サンプルでは、いくつかのイベントで+/- 10 msのジッターが生じました。 すべてのケースにおいて、ジッターの大部分は+/- 1 msで生じました。

Macの場合

• インターフェース A: 44.1 kHz／バッファーサイズ 1152 サンプルでは、+/- 4 から 11 msのジッターがほぼ均等に分散していました。 他のテストでは、最大ジッターは+/- 5 msでした。 すべてのケースにおいて、ジッターの大部分は+/- 1 msで生じました。
• インターフェース B: ほとんどのテストで、最大ジッターは+/- 4 または 5 msでした。 44.1 kHz/バッファーサイズ 1152 サンプルでは、+/- 2 から 11 msのジッターがほぼ均等に分散していました。 すべてのケースにおいて、ジッターの大部分は+/- 1 msで生じました。
• インターフェース C: すべてのテストで最大ジッターは+/- 1 msで、ほとんどのイベントではジッターは生じませんでした。

以下の図の通り、出力されるMIDIイベントのタイミングの検証についても同様の手順で行いました。

出力テストでは、すべてのケースで入力テストと同等の結果が生じました。

39.5 最適なMIDIパフォーマンスを得るには

Liveで最適なMIDIパフォーマンスを得たいユーザーのために、推奨される実行内容とプログラム設定をリストアップしました。

• お使いのオーディオインターフェースで選択可能な最小のバッファーサイズを使用する。 オーディオバッファーのコントロールは、Liveの環境設定［Audio］タブにありますが、お使いの機器より異なります。 詳しくは、レッスン｢オーディオ入力/出力の設定｣をご参照ください。
• MIDIタイムスタンプをできるだけ正確に生成や処理できるよう、最新のドライバーと高品質のMIDIインターフェースを使用する。
• 外部シンセサイザーなどのハードウェア機器を直接聞きながらMIDIを録音する場合（External Instrumentを使用してLive経由で機器のオーディオを聴いていない場合）、トラックのモニタリングはオンに しない。 同様に、別のMIDI機器（ドラムマシンなど）が生成したMIDIデータを録音する時は、トラックのモニタリングをオンにしないでください。 モニタリングがオンだと、Liveはプレイスルーのジッターを補正するために、レイテンシーを増加させます。 そのため、実際にプレイスルーしている場合にのみモニタリングをオンにしてください。

39.6 まとめ

ユーザーの皆さまがさまざまな関連トピックを理解する上で、ユーザーに役立つことを願っています。

• コンピューター・ベースのMIDIシステムに固有の問題
• Liveで生じた問題を解決するための私たちのアプローチ
• 説明できないその他の変動要素

先に説明したとおり、ご使用のスタジオにおけるMIDIタイミングの問題を解決する一番の方法は、できるだけ高品質のハードウェア・コンポーネントを使用することです。 このようなコンポーネントをご使用の場合、ソフトウェアMIDIシステムで大きな問題が生じることはありません。 最適とはいえない機器をご使用の場合でも、Liveはジッターを最小限に抑えることで精度を向上できますが、多少のレイテンシーが生じます。