Vienna Ensemble Proで得すること/損すること
本記事は、特にMac Cubaseにおいて重量級のオーケストラライブラリを用いた大規模なセッションを作成する際に負荷を下げ快適に作業を行うための方法をまとめていきます。
まず、なぜ重いのか
制作用のセッションが重くなる理由は様々ですが主なものは次の4つです。
インストゥルメントのストリーミング負荷
エフェクトの処理負荷
外部との通信による負荷
メモリ使用量過多
そして、これらへの対策はある程度わかりやすくて、
速いSSDにサンプルを格納する
SSDを速いファイルシステム（APFSなど）で使う
速いCPUを使う
他のマシン、プロセッサ、アプリに負荷分散しない
無駄な音源、エフェクトをセッションから削除する
サンプルのプリロード量を減らす
といった工夫が挙げられます。サンプルライブラリは通常波形の先頭部分のみをメモリにロードし再生が始まってからその後ろを随時リアルタイムにストレージから読み込むため、最初にメモリに読み込んでおく量を減らせばメモリ使用量は下がります。（ただしその分ストリーミング負荷は上がります。）
ストリーミング負荷を掘り下げる
半導体の物理的性能限界が来ると言われて久しいですが、今なおCPUもRAMもストレージも速度面で目覚ましい進化を遂げ続けています。しかし、それでもなお我々は常に音飛び、再生のドロップアウトのストレスと戦い続けています。
これは私個人の感覚ですが、セッションの中に無駄な要素を常駐させていなければCPUの処理能力がボトルネックになることは稀だと感じていますし、RAMも容量が足りていれば速度に不満を抱えるシーンはあまり想像できません。問題はストレージです。
ストレージも飛躍的な進化を遂げています。HDDからSSDへの移行は恐らく多くの方が済まされたと思いますが、SSDの中でも規格の違いによってここ10年でSSDは（シーケンシャル読み込みで）10倍以上もスループットが速くなっています。
それだけ速くなったストレージが音飛びを生じさせているのは、読み込み（バッファリング）が始まった瞬間の待ち時間、レイテンシーが原因だとも考えられます。CPUがストレージに対して「データを下さい」と言ってから実際にデータがCPUに届くまでの時間です。
これを解決する最もシンプルな手段は
バッファサイズを上げること
サンプルを読み込みやすい場所に格納すること
です。誰もが当たり前のように行っていることですが、十分な量のデータをストレージから受け取って、エフェクト処理を行ってミックスしてさあ再生するぞ！という準備が整うまでユーザーが待つことが出来れば処理負荷は下がります。
ASIO-Guardが鍵
とはいえ、我々はバッファサイズを上げたいわけではありません。むしろ、リアルタイム入力のしやすさや録音のモニタリングの快適さを考慮するならバッファサイズは限界まで下げたいと考えるでしょう。
Cubase/Nuendoにはバッファサイズを下げるためのASIO-Guardという機能があります。これは「低レイテンシーでモニタリングしたいトラック以外の要素までしゃかりきに処理して負荷を上げるくらいなら、その他大勢のトラックはたっぷり待ち時間を設けて余裕を持って処理しよう」という機能です。恐らく他のDAWにも同様の機能がついています。
これで得られるメリットが、録音待機状態のMIDIトラック/Instrumentトラックに紐づいている音源だけを低レイテンシーで読み込んで、それ以外の音源はゆっくり時間をかけて読み込めるという点です。
バッファサイズを下げて今打ち込みたい音源だけがレイテンシー数msで鳴るよう設定したとしても、それ以外は数十msの余裕を持って読み込むことが出来ます。ゆえに、バッファサイズを下げつつ大規模プロジェクトをドロップアウト無しで安定動作させられるのです。
録音可能状態を意識する
ASIO-Guardが発動するのは録音可能状態になっているトラックに対してです。多くのトラックを一度に録音待機状態にすればその分高負荷になります。Cubaseはデフォルト設定では選択したトラックが自動的に録音待機状態になります。
Preferences > Editing > Project & Mix Console > Enable Record on Selected MIDI Track
のチェックを外すと、プロジェクトウィンドウ上でMIDIトラックを選択しても自動的に録音待機状態にならなくなります。
MIDIトラックを切り替えた時に録音待機状態まで一緒に切り替わると一瞬の無音が生じ、それが体感上の処理負荷の高さに大きく関わります。ASIO-Guardの処理とリアルタイムの処理のパスが選択し直されるためです。キビキビした動作を考えるのであればこれはOFFにした方が快適かもしれません。
VEProの使い方を考える
それでもなおドロップアウトが酷い、つらいと感じている僕のような人間はVEProの使い方に問題があるかもしれません。
VEProは1つのインスタンスの中にいくつもの音源を紐付けることが出来ます。この性質を利用して、例えば
弦楽器用のVEPro
Violin I用のKONTAKT
Violin II用のKONTAKT
Viola用のKONTAKT
Cello用のKONTAKT
Contrabass用のKONTAKT
その他に使う可能性のある弦楽器の音源類
と言ったマルチティンバーな構成が出来ます。これをするとCubase側の管理がとっても楽で、サンプルもVEPro側にロードさせたままCubaseプロジェクトを切り替えることが出来るため楽曲をまたいで同じテンプレートを使う時の待ち時間も短縮されます。また、同じMIDIトラックから複数の音源に対して同時にメッセージを送ることも簡単に出来ます。
これは一見万能に見えますが、レイテンシーのことを考えると非常に大きなムダが生じています。
例えば、Violin Iだけを編集しようと思ってViolin IのMIDIトラックを録音待機状態にした場合、Violin II、Viola、Cello、Contrabassも同様にASIO-Guardの管理下に入って低レイテンシーで読み込みを行おうとするのです。
ここでセッションのRack Instruments欄の視認性と全体のパフォーマンスの迫られることになりますが、一度試しに
弦をすべてロードしたVEPro
Vln I、II、Vla、Vc、Cbを別々のVEProにロード
したものを鳴らし比べてみたところパフォーマンスの差は歴然でした。前者では
バッファサイズ: 192
VEProのBuffer: 3
VEProのレイテンシー表記: 12ms
あたりまでしか詰められませんでしたが、後者は
バッファサイズ: 128
VEProのBuffer: 1
VEProのレイテンシー表記: 2.7ms
あたりまでドロップアウト無しで全パート一斉レガートランが可能でした。
ストリーミング負荷の高い音源ほどVEProを使う場合も粒度を細かく、逆に軽い音源ほど1つのVEProに色々纏めてしまう使い方が適していると言って良いでしょう。
VEProの負荷分散は万能なのか
VEProが4になった頃はまだ32bit環境でメモリも多くはなく、他のマシンに処理を任せられることが最大の売りでしたが果たして今もそうでしょうか。これに関してはスループットよりレイテンシーが重要になる場面ではVEProは逆効果になり得ると言えます。
変な喩えを使いますが、ペットボトルのお茶を物凄く速く飲める人がいたとして、冷蔵庫の中にあるお茶を飲むのと近所のコンビニや自販機までお茶を買いに走ってきてから飲むのではどちらが「速い」でしょうか？
お茶を飲むスピードは同じだとしても、お茶を飲み始めるまでの時間に大きな差があるのは明白です。そして、我々は「お茶を飲んで下さい」と言ってからその人がお茶を飲み終わるまでの時間だけで「お茶を飲む速さ」を判断します。実際に飲んでいる時のスピードはあまり考慮しません。
だからこそ、我々が他人に速くお茶を飲んでほしい（マシンに軽快に動作してほしい）場合近所に買いに走る（外部マシンに負荷分散する）のではなく家の冷蔵庫にお茶を入れておく（一台完結する）方が速く感じられるのです。
つまり、VEProは母艦に十分なCPUの処理能力とRAMが搭載されている場合外部マシンに処理を任せるのはむしろパフォーマンスを低下させる原因になるのです。
更にいうと、一台完結の環境でVEProを使っていたとしても
DAWからVEProに逃がすことで浮くCPU負荷
DAWとVEProの間で同期通信を行うためにかかるCPU負荷
のどちらが高いのかは冷静に見極める必要があります。ちょっとしたインストゥルメントであればDAWの中で処理してしまった方がお得かもしれません。
まとめ
レイテンシーを下げると処理負荷が高まる
レイテンシーを下げないとリアルタイム入力が出来ない
リアルタイム処理したいトラックだけレイテンシーを下げよう
ASIO-Guardで関係ないトラックまでレイテンシーを下げない
VEProは関係ないトラックまでレイテンシーを下げがち
VEProもASIO-Guardも快適な制作環境の構築のために大きく貢献してくれる存在です。それらが具体的にどう働いていてどう組み合わせるとリスクが生じるのかを理解することで、同じマシン環境でもストレスを大幅に減らすことが出来るようになるでしょう。