はじめに
今回は VST3 プラグインのモジュールとプラグインの構造について解説します。
モジュールの構造について
下の図は、VST3 プラグインのモジュールの大まかな構造を表したものです。
VST3 規格では、モジュールの中に複数のプラグイン（例えば Synth, EQ, Reverb, Comp, など）を定義できます。1 言い換えるとモジュールはプラグインのコンテナであるといえます。
モジュールに含まれる各プラグインは、通常は、次のふたつのコンポーネントで構成されます。2 逆に言うと、 VST3 規格ではこのコンポーネントのペアをひとつのプラグインとみなします。
- Processor コンポーネント
- バスの管理、プラグイン状態のSave／Load、信号処理などプラグインとしての基本的な役割を担う。
- また、自身がどの Edit Controller コンポーネントとペアになるかの情報を持つ。（図中の点線矢印で示したもの）
- Edit Controller コンポーネント
- パラメータ情報の管理、プログラムリスト管理、エディターウィンドウの表示など、編集操作に関する役割を担う。
複数の Processor コンポーネントが同じ Edit Controller コンポーネントを参照することもあります。上記の図では、プラグイン B と プラグイン C が同じ Edit Controller B を参照しています。この場合、プラグイン B と プラグイン C は、パラメータリストやプラグインの UI が同一でありながら、サポートしているバスの種類や信号処理が異なるプラグインになります。
また、非推奨ではありますが Processor コンポーネントの機能と Edit Controller コンポーネントの機能をひとつのコンポーネントにまとめて実装することも可能です。上記の図では プラグイン D がそのように実装されています。
モジュールにはさらにプラグインファクトリというクラスがひとつだけ含まれます。ホストアプリケーションはプラグインファクトリを利用して、モジュールに含まれるプラグインを列挙したり、指定したプラグインをロードしたりできます。
コンポーネントを分離する設計について
先に書いた通り、 VST3 ではひとつのプラグインを Processor コンポーネントと Edit Controller コンポーネントで構成し、逆にこれらのペアをひとつのプラグインとみなします。このようにプラグインをふたつのコンポーネントに分離している設計は、VST3 プラグインの大きな特徴です。
ひとつのプラグインを実装するのにわざわざふたつのコンポーネントを別々に実装するのは、面倒が増えたり、余計な手間がかかったりする不便さがあります。しかし一方で、リアルタイムに処理しなければいけない信号処理部分とそうする必要がない編集操作を処理する部分が設計レベルで分離されるため、それらの処理を安全に実装しやすくなる利点があります。
また VST3 規格では、コンポーネントを分離する仕組みによって、プラグインの信号処理と編集操作の処理を異なるマシンで実行することも想定しています。モジュールに含まれるコンポーネントはひとつひとつを個別に構築できるため、手元の PC ではプラグインの Edit Controller コンポーネントのみを構築し、それとは別の高速な PC で Processor コンポーネントを構築することで、手元の PC に信号処理の負荷をかけずにプラグインを利用できます。3 4
おわりに
今回は、VST3 プラグインのモジュールとプラグインの構造ついて解説しました。次回は、 VST3 SDK のベースに利用されている VST-MA について解説します。
-
モジュールの中に複数のプラグインを含める仕組みは、有名な所では Waves 社の WaveShell プラグインファイルで利用されています。 ↩
-
コンポーネントとは VST-MA の仕組みにしたがって定義された具象クラスです。 ↩
-
ただし、これを実現するには RPC (Remote Procedure Call) が必要になります。 VST3 SDK には RPC の仕組みは含まれていないため、そこはホストアプリケーション側が自分で実装する必要があります。 ↩
-
VST3 プラグインのふたつのコンポーネントを別々の PC 上に構築して利用できるホストアプリケーションが実際にあるかどうかは不明です。 Waves 社の SoundGrid という技術はまさにこのような仕組みを提供していますが、その実装に VST3 のこの仕組みが利用されているかどうかは分かりません。 ↩