この記事は、音楽ツール・ライブラリ・技術 Advent Calendar 2018 六日目の記事です。
今回は、VST3 SDKについて紹介します。
VSTとは
まずはじめに、VSTとはなんでしょうか。
これは、ドイツのSteinberg社 (現YAMAHA子会社) が開発した、オーディオプラグインソフトウェアの規格です。
Steinberg's Virtual Studio Technology（一般的にはVST）とは、ソフトウェア・シンセサイザーやエフェクター・プラグインと波形編集ソフトウェアやデジタル・オーディオ・ワークステーション (DAW) 間のリアルタイムなデータ受け渡しを担い各種の加工などを施すプログラムを、プラグインとして提供するための標準的な規格の一つである。この規格に沿って制作されたプラグインは、多くが操作を容易にするためにGUIを採用している。 - https://ja.wikipedia.org/wiki/Virtual_Studio_Technology
エフェクタやインストゥルメントとして動作するプラグインソフトウェアがこのVST規格に従って作成されていれば、同じようにVST規格に対応するように開発されたホストアプリケーション上にそれらのプラグインを読み込んで利用できるようになります。
VSTは1996年に最初のバージョンがリリースされ、その後1999年にメジャアップデートであるVST2が、そして、2008年に今回紹介するVST3がリリースされました。（以降では、単にVSTあるいはVST SDKといった場合、最初のリリースバージョンを指すのではなく、VST2もVST3もすべてを包括した意味で使用します）
これまでしばらくは、VST SDKのパッケージの中にVST3用のSDKのファイルとVST2用のSDKのファイルが両方含まれており、（VST2の方はもう開発が終了しているけれども、）一応VST2 SDKのファイルは利用できる形になっていました。
しかしSteinberg社としては、VST2はもう古い仕組みで、VST3への移行を促したいために、VST 3.6.11からはVST SDKのパッケージの中にVST2のSDKのファイルが含まれないようになりました。なので、今後は基本的にVST3 SDKのファイルのみを使用してプラグインやホストを開発し、VST2については非推奨扱いになります。
ライセンスについて
VST3 SDKは、 Proprietary Steinberg VST3 License と GPL v3のデュアルライセンスになっています。
Proprietary Steinberg VST3 Licenseは、アプリケーションをバイナリで配布する場合に適用されるライセンスです。
アプリケーションのソースコードをオープンソースとして公開し、その中にVST3 SDKのファイルを含めたい場合にはこのライセンスは適用できず、その場合はGPL v3を適用する必要があります。1
Proprietary Steinberg VST3 Licenseにはさらに、ドキュメント中でSteinberg Media Technologies GmbHについて言及する必要があるなど、いくつかの条件があるようです。
詳しくは http://www.steinberg.net/sdklicenses や、SDK内のドキュメントを参照してください。
VST3について
VST3は2008年にリリースされた、第3世代のVSTです。
VST3のSDKはSteinberg社のサイトからダウンロードできます。
あるいは、githubのリポジトリでもコードが公開されています。ただし、こちらの方はSteinberg社のサイトからダウンロードできるパッケージと異なり、ホストアプリケーション検証ツールが含まれていないようです。
VSTは、第二世代の最終バージョンであるVST2.4までは、比較的シンプルなC++ライブラリとして実装されていました。
ホストとプラグインの通信は、主にdispatcherという関数を通じて行われるようになっており、これはシンプルではありますが、機能的に制限が強く拡張性にも乏しい仕組みです。この仕組みのままで新しい機能を追加するのは困難でした。
これを踏まえ、VST3ではより柔軟で拡張性のある仕組みを提供できるように、設計のベース部分から仕組みが刷新されることになりました。最も大きな特徴は、設計のベースに VST Module Architecture (VST-MA) という技術を採用したことです。
VST-MAはSteinbergが開発した技術で、Microsoftの Component Object Model (COM) に非常に似た仕組みになっています。COMと同様に、VST-MAの仕様に従ってモジュール(.dll)を作成すれば、そのモジュールに含まれるコンポーネントを、DLLのバイナリ境界を超えて利用できます。 2
VST3はVST−MAの仕組みの上で、プラグインのGUIや編集操作に関わる部分を担当するコンポーネント (EditController) と、バス接続やオーディオ処理を担当するコンポーネント (Processor) とを別々に扱うための仕組みを整備しました。これによって例えば、あるプラグインに対して、GUI処理は現在のマシン上で実行し、オーディオ処理は専用の別のマシン上で実行させるというような柔軟な構成をサポートできるようになります。
また、プラグインやホストの拡張性はVST-MAが提供するqueryInterfaceというAPIによって実現されます。たとえば、プラグイン側があるVST-MAのインターフェースを実装していて、ホスト側もそのインターフェースを利用できるように実装してあれば、ホストがプラグインからインターフェースを取得して、その機能を利用できます。3
VST-MAの採用と設計の刷新によって、VST3ではVST2には無かった以下のような機能をサポートできるようになりました。
- 動的なI/O構成の変更機能
- サンプル単位でのオートメーション情報を転送する機能
- パラメータの階層管理機能
- などなど
VST3の難点
さて、このように大きく仕組みが変わったVST3ですが、それが普及するまでにはしばらく時間がかかりました（2018年12月現在でも、メジャーなDAWでVST3がサポートされてない例があり、VST2ほどには普及していません。4）。その原因について、筆者としては、主には以下の理由により開発コストが高くなってしまうためであると考えています。
- VST2からの変更点が大きいため、それまでの既存の実装を流用できない。
- COMの知識が必要になったり、開発の複雑さが増した
- ドキュメントが不足している
それぞれについて、もう少し細かく見ていきましょう。
最初の 1 についてですが、VST2とVST3は、ほぼ別物と考えられるほどに違いが大きいため、その点で混乱が生じて、それまでVST2でプラグイン／ホストを開発していた開発者にとって、最初の導入の敷居が高かったのだろうと考えられます。
次の 2 についてですが、VST-MAやCOMについての知識がいくらか必要になったということが、開発のハードルを上げました。
先に述べたとおり、VST3の設計のベースがVST-MAになり、VST-MAはCOMによく似た仕組みとして作られています。
そのため、COMを知らないとVST-MAがよくわからない、VST-MAがよくわからないとVST3自体がよくわからない、という状態になります。5
さらに、COMは言語によらない仕組みとして設計されているため、C++でCOMを利用するプログラムは、純粋なC++としてプログラムを書くよりも冗長で扱いにくいところが出てきます。VST-MAもこれと同様の問題が発生します。
この問題は一応、VST3 SDK内に用意されているスマートポインタなどのユーティリティクラスによって、いくらか吸収できます。それであってもやはり、COMでのプログラミングスタイルに慣れなければ、VST2の頃より複雑な仕組みになったと感じることでしょう。
またVST3では、プラグインのコンセプト自体が複雑になりました。
例えばVST2までは、プラグインの動作モードはインストゥルメントかシンセか、どちらかだけを指定する仕組みだったのに対し、VST3ではそのどちらの性質も持ったプラグインを開発できます。ほかには、Unitという仕組みによってプラグインの持つ多数のパラメータを階層構造で管理する仕組みが導入され、さらにそれぞれのUnitごとにプログラムチェンジを設定できるようになっています。
このようにVST3ではVST2よりもできることは増えましたが、そのために理解しなくてはいけないことや、実装しないといけないことが増えたため、結果として開発の複雑さが増すことになりました。
そして、最後の 3 が一番大きな問題です。
用意されているドキュメントに記述の足りない箇所が多く、古い記述が残っている箇所もあったり、同梱のサンプルプロジェクトのコードと齟齬が発生している箇所も存在します。6
加えてドキュメントの構成がわかりにくいという問題もあります。7
また、1, 2に関連する問題として、最初にVST3開発に取り掛かるためのドキュメントが圧倒的に不足しています。
例えば自分で新たにプロジェクトを構築してプラグインを作成しようと思っても、そのための十分なチュートリアルは用意されていません。既存のサンプルコードのプロジェクトをコピーして再利用する手順について、How to add/create your own VST 3 Plug-insという1ページ程度のドキュメントが用意されているのみで、あとはドキュメント中のさまざまな記述を拾ったり、サンプルプロジェクトのコードを読み解く必要があります。
（さらに、ホスト側の開発については、プラグイン側以上にドキュメントが用意されていません。筆者がVST3プラグインをホストするデモアプリケーションを実装したときには、プラグイン版のドキュメントの記述を参考にしたり、ホスト実装のサンプルプロジェクトのコードを参考にしつつ、試行錯誤することになりました。）
ここまで上記の3つの原因を上げましたが、筆者としては結局は3番目の、ドキュメントの問題が一番の原因であると考えます。ある程度複雑な仕組みであっても、ドキュメントさえしっかりしていれば、自分で適切なラッパーを被せて扱うこともできます。一方でドキュメントが中途半端なせいで仕様が理解できなければ、もうお手上げです。
一応、現在のVST3 SDKにはプラグインやホストの検証ツールが含まれていて、作成したプラグインやホストの挙動を検証できるようになっています。なので、実際の開発では、
- ドキュメント上の分散した記述
- サンプルコードの実装
- 検証ツールが出力する検証レポート
の3つを見比べつつ、ある程度試行錯誤を繰り返しながら実装をしていくことになるでしょう。
フレームワークを使用する
上記の通り、VST3は、VST2とは比べ物にならないほどの開発コストがかかるものになりました。8
そのため、しばらくVST3プラグインは体力も技術力もある大手プラグインベンダーが対応するだけで、多くのプラグインベンダー（特にフリーのプラグイン開発者）は引き続きVST2でプラグインを開発することが多かったように思います。
しかしやがてJUCEというフレームワークが台頭し、プラグイン開発者がプラグインフォーマット（VST／Audio Unitなど）の違いを意識せずにプラグインを開発できる体制が整ってきてたため、現在は基本的なプラグインフォーマットすべて（VST2／VST3／Audio Unit／AAX）でプラグインが提供されることも一般的になりました。
このようなフレームワークを使用すると、プラグイン開発者は一つのクラスに対して処理を記述するだけで、あとはフレームワーク側が用意している独自のラッパーがさまざまなプラグインフォーマットの形でプラグインを生成してくれます。
この仕組みによって、プラグイン開発者は、プラグインフォーマットごとのビルド処理をセットアップしたり、プラグインフォーマットごとの違いを意識してコードを書く必要がなくなり、メインの処理を実装することに注力できるようになります。
反面、プラグインフォーマットごとに提供している機能の違いは、平均的なもの、あるいは最も基本的なものに揃えられてしまって、プラグインフォーマットごとの特色はほとんどなくなります。その点は少しさみしい感じもあります。
とはいえやはり、VST3プラグインの開発コストを考えると、このようなフレームワークを使って開発するというのは非常に合理的ではありますね。
VST3の情報を得るには
VST3の情報を得るにはどうすればよいでしょうか。
日本語の情報のうち、プラグイン開発側については、うつぼかずら(@vstcpp)さんが公開しているこのサイトが素晴らしいです。現状これだけVST3の情報が丁寧にまとめられたサイトは、日本では唯一です。（英語でもなかなか見つからないのではないでしょうか。）
ホスト開発側の情報は、現状ほとんどありません。筆者が2014年ごろVST3をホストするデモアプリケーションを作成し、それに合わせてホスト側の実装を紹介した記事9もありますが、当時の理解が足りていなかったために正確でない記述があったり、内容が古かったりする問題がありました。
筆者は現在、そのデモアプリケーションの新バージョンを開発中です。新しい知見もいろいろ得られているので、ホスト開発側の情報については後日改めて記事にしたいと考えています。
[追記 2019/04/15]
先日、music.dev #1という勉強会で、ホスト開発側から見たVST3の仕組みについて解説する発表を行いました。
これまでよりもしっかりとVST3の仕組みについて調査して作った資料なので、2014年に公開した記事よりも充実した内容になっています。VST3ホスティングについて、日本語での情報を探している人に役立つと思います。
[追記終わり]
JUCEやwdl-olなどのフレームワークで、さまざまなプラグインフォーマットのラッパークラスが実装されていることがあるので、そのVST3実装を見るのも参考になります。10
また、単純に調べてもわからない問題はForumを利用するのがいいでしょう。
SteinbergのサイトにはVST3開発者用のForumが設置されているので、そこを見たり、投稿して質問するのが良いでしょう。このForumにはVST3の開発者であるYvan Gravitや、上で紹介したwdl-olの開発者であるoli larkinなどが発言しています。
また、JUCEもForumを設置しているので、JUCEのVST3ラッパー実装についてわからない点があったら、ここで聞いてみるのがいいと思います。こちらにはJUCEの開発チームのメンバーや、時にはVST3の開発者であるYvan Gravitも発言しています。
また、JUCEの開発元であるROLI社が主催しているAudio Developer Conferenceというイベントでも、VSTに関連するセッションがありました。
動画が公開されていて、どちらもすごく参考になります。
- Fabian Renn Giles - Under the hood of VST2, VST3, AU, AUv3 and AAX
- Yvan Grabit - VST3 history, advantages and best practice (ADC'17)
まとめ
今回はVST3 SDKについて紹介しました。簡単にまとめると以下のようになります。
- VST3はSteinberg社のオーディオプラグインソフトウェアの規格の第3世代のバージョン
- VST3は拡張性が重視されており、VST2ではできなかったことができるようになった
- しかし複雑性が増し、ドキュメントも不十分なため、開発のコストが高い
- そこにフレームワークが台頭し、VST3プラグイン開発が容易になった
-
wdl-olというライブラリの場合は、WDLライセンスが適用されて、VST3 SDKのデュアルライセンスとは別の形態になっていますが、これはVST3 SDKをリポジトリに含めない形になってるので可能になっている？ ↩
-
COMは言語によらない仕組みになっていて、異なる言語で開発されたモジュール同士でもCOMの仕組み上で同じように扱えるようになっていますが、VST-MAではいまのところ、VST-MAのモジュールをC++から扱う仕組みだけが用意されています。ただしVST-MAはCOMとバイナリ互換があるので、別の言語に用意されたCOMの仕組みを流用して別の言語からVST3プラグインを扱うこともできるかもしれません。 ↩
-
VST2のときにも、dispatcherでeffCanDo／audioMasterCanDoというメッセージを送ることで、プラグインやホストが追加の機能を実装しているかを問い合わせる仕組みは存在しました。しかしこれは、プラグインやホストが、指定した名前の機能をサポートしているかどうかをYes/No/Don't knowの三値で返すだけのAPIであり、あまり拡張性がある仕組みではありませんでした。 ↩
-
記事公開当初はAbleton LiveやDigital PerformerがVST3に対応していなかったためにこのような書き方をしていましたが、その後どちらもVST3をサポートするようになりました。これによって、VST2に変わってVST3が主流になる流れが加速したような気がします。） ↩
-
実は、VST3プラグイン／ホスト開発時にVST-MAに触れる際には、COMのプログラミングスタイルに基づくいくつかの作法だけ知っていればVST-MAを使うのに十分で、それ以上のCOM自体の知識は実際にはあまり必要になりません。しかしVST-MAのドキュメントが不十分で非常にわかりにくいため、COMでのプログラミングスタイルの知識がないプログラマがVST-MAのドキュメントだけからその作法を把握するのはとても困難です。 ↩
-
サンプルプロジェクトのコード側と齟齬が発生する問題は、サンプルプロジェクトのコードのほうが実際に動く例になるので、ドキュメントよりもサンプルコード側を正解として扱うことになるでしょう。 ↩
-
ドキュメントのナビゲーションメニューに4種類のセクション (VST 3 API／Basic Module／VST-MA／SDK Helper Classes)があるのですが、どのセクションが何についてのドキュメントなのかと、それぞれのドキュメントの関係性がどうなっているのかがわかりにくく苦労します） ↩
-
一例として、高品質なプラグインをリリースしているu-heというチームが、Podolskiというプラグインを公開しており、そのパッケージにVST3_Readme.txtというファイルが同梱されています（日付は2014年5月22日)。そのファイルに曰く、「VST2版を使うのを強くおすすめします。VST3版を用意しようとして数ヶ月頑張ってみたけど、まだランダムなエラーとグリッチが発生する。VST3の複雑さを甘く見てた」。 ↩
-
つい最近、筆者もデモアプリケーション開発にあたり、VST3のドキュメントが不十分で理解できない箇所について、JUCEのコードを見てそこからVST3の仕様を推定したりしました。 ↩