C++
COM
VST
vst3

VST3 SDKについて

この記事は、音楽ツール・ライブラリ・技術 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については非推奨扱いになります。

https://www.steinberg.net/en/newsandevents/news/newsdetail/article/vst-2-coming-to-an-end-4727.html


ライセンスについて

VST3 SDKは、 Proprietary Steinberg VST3 LicenseGPL 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社のサイトからダウンロードできます。

https://www.steinberg.net/en/company/developers.html

あるいは、githubのリポジトリでもコードが公開されています。ただし、こちらの方はSteinberg社のサイトからダウンロードできるパッケージと異なり、ホストアプリケーション検証ツールが含まれていないようです。

https://github.com/steinbergmedia/vst3sdk

VSTは、第二世代の最終バージョンであるVST2.4までは、比較的シンプルなC++ライブラリとして実装されていました。

ホストとプラグインの通信は、主にdispatcherという関数を通じて行われるようになっており、これはシンプルではありますが、機能的に制限が強く拡張性にも乏しい仕組みです。この仕組みのままでさまざまな新しい機能を追加するのは困難でした。

これを踏まえ、VST3ではより柔軟で拡張性のある仕組みを提供できるように、設計の根幹部分から仕組みが刷新されることになりました。最も大きな特徴は、COMを採用したことです。

COMはMicrosoftが開発した、バイナリインターフェースの規格です。COMの仕様に従ってモジュール(.dll)を作成すれば、そのモジュールに含まれるコンポーネントを、DLLのバイナリ境界やプロセスの境界、あるいはマシン境界を超えて利用できます。また、COMは言語によらない仕組みになっていて、異なる言語で開発されたモジュール同士も同じように扱えるようになっています。

VST3はCOMの仕組みのもとで、プラグインの中でGUIや編集操作に関わる部分を担当するコンポーネント (EditController) と、バス接続やオーディオ処理を担当するコンポーネント (Processor) とを別々に扱うための仕組みを整備しました。これによって例えば、あるプラグインに対して、GUI処理は現在のマシン上で実行し、オーディオ処理は専用の別のマシン上で実行させるというような柔軟な構成をサポートできるようになります。

また、拡張性はCOMのQueryInterfaceという仕組みによって実現されます。たとえば、プラグイン側があるインターフェースを実装していて、ホスト側もそのインターフェースを利用できるように実装してあれば、ホストがプラグインからインターフェースを取得して、その機能を利用できます。2

COMの採用と設計の刷新によって、VST3ではVST2には無かった以下のような機能をサポートできるようになりました。


  • 動的なI/O構成の変更機能

  • サンプル単位でのオートメーション情報を転送する機能

  • パラメータの階層管理機能

  • などなど


VST3の難点

さて、このように大きく仕組みが変わったVST3ですが、それが普及するまでにはしばらく時間がかかりました(現在でも、メジャーなDAWでVST3がサポートされてない例があり、VST2ほどには普及していません)。その原因について、筆者としては、主には以下の理由により開発コストが高くなってしまうためであると考えています。


  1. VST2からの変更点が大きいため、それまでの既存の実装を流用できない。

  2. COMの知識が必要になったり、開発の複雑さが増した

  3. ドキュメントが不足している

それぞれについて、もう少し細かく見ていきましょう。

最初の 1 についてですが、VST2とVST3は、ほぼ別物と考えられるほどに違いが大きいため、その点で混乱が生じて、プラグイン開発者/ホスト開発者両方にとって、最初の導入の敷居が高かったのだろうと考えられます。

次の 2 についてですが、COMについての知識がいくらか必要になったということが、開発のハードルを上げました。

COMは言語によらない規格として定義されているため、C++でCOMの仕組みを利用するプログラムは、純粋なC++としてプログラムを書くよりも冗長で扱いにくいところが出てきます。

この問題は一応、VST3 SDK内に用意されているスマートポインタなどのユーティリティクラスによって、いくらか吸収されます。それであってもやはり、COMでのプログラミングスタイルに慣れなければ、VST2の頃より複雑な仕組みになったと感じることでしょう。

またVST3では、プラグインのコンセプト自体が複雑になりました。

例えばVST2までは、プラグインの動作モードはインストゥルメントかシンセか、どちらかだけを指定する仕組みだったのに対し、VST3ではそのどちらの性質も持ったプラグインを開発できます。ほかには、Unitという仕組みによってプラグインの持つ多数のパラメータを階層構造で管理する仕組みが導入され、さらにそれぞれのUnitごとにプログラムチェンジを設定できるようになっています。

このようにVST3ではVST2よりもできることは増えましたが、そのために理解しなくてはいけないことや、実装しないといけないことが増えたため、結果として開発の複雑さが増すことになりました。

そして、最後の 3 が一番大きな問題です。

用意されているドキュメントに記述の足りない箇所が多く、古い記述が残っている箇所もあったり、同梱のサンプルプロジェクトのコードと齟齬が発生している箇所も存在します。3

加えてドキュメントの構成がわかりにくいという問題もあります。4

また、1, 2に関連する問題として、最初にVST3開発に取り掛かるためのドキュメントが圧倒的に不足しています。

例えば自分で新たにプロジェクトを構築してプラグインを作成しようと思っても、そのための十分なチュートリアルは用意されていません。既存のサンプルコードのプロジェクトをコピーして再利用する手順について、How to add/create your own VST 3 Plug-insという1ページ程度のドキュメントが用意されているのみで、あとはドキュメント中のさまざまな記述を拾ったり、サンプルプロジェクトのコードを読み解く必要があります。

(さらに、ホスト側の開発については、プラグイン側以上にドキュメントが用意されていません。筆者がVST3プラグインをホストするデモアプリケーションを実装したときには、プラグイン版のドキュメントの記述を参考にしたり、ホスト実装のサンプルプロジェクトのコードを参考にしつつ、試行錯誤することになりました。)

ここまで上記の3つの原因を上げましたが、筆者としては結局は3番目の、ドキュメントの問題が一番の原因であると考えます。ある程度複雑な仕組みであっても、ドキュメントさえしっかりしていれば、自分で適切なラッパーを被せて扱うこともできます。一方でドキュメントが中途半端なせいで仕様が理解できなければ、もうお手上げです。

一応、現在のVST3 SDKにはプラグインやホストの検証ツールが含まれていて、作成したプラグインやホストの挙動を検証できるようになっています。なので、実際の開発では、


  • ドキュメント上の分散した記述

  • サンプルコードの実装

  • 検証ツールが出力する検証レポート

の3つを見比べつつ、ある程度試行錯誤を繰り返しながら実装をしていくことになるでしょう。


フレームワークを使用する

上記の通り、VST3は、VST2とは比べ物にならないほどの開発コストがかかるものになりました。5

そのため、しばらくVST3プラグインは体力も技術力もある大手プラグインベンダーが対応するだけで、多くのプラグインベンダー(特にフリーのプラグイン開発者)は引き続きVST2でプラグインを開発することが多かったように思います。

しかしやがてJUCEというフレームワークが台頭し、プラグイン開発者がプラグインフォーマット(VST/Audio Unitなど)の違いを意識せずにプラグインを開発できる体制が整ってきてたため、現在は基本的なプラグインフォーマットすべて(VST2/VST3/Audio Unit/AAX)でプラグインが提供されることも一般的になりました。

このようなフレームワークを使用すると、プラグイン開発者は一つのクラスに対して処理を記述するだけで、あとはフレームワーク側が用意している独自のラッパーの仕組みによって、さまざまなプラグインフォーマットの形でプラグインを生成してくれます。

この仕組みによって、プラグイン開発者は、プラグインフォーマットごとのビルド処理をセットアップしたり、プラグインフォーマットごとの違いを意識する必要がなくなり、メインの処理を実装することに注力できるようになります。

反面、プラグインフォーマットごとに提供している機能の違いは、平均的なもの、あるいは最も基本的なものに揃えられてしまって、プラグインフォーマットごとの特色はほとんどなくなります。その点は少しさみしい感じもあります。

とはいえやはり、VST3プラグインの開発コストを考えると、このようなフレームワークを使って開発するというのは非常に合理的ではありますね。


VST3の情報を得るには

VST3の情報を得るにはどうすればよいでしょうか。

日本語の情報のうち、プラグイン開発側については、うつぼかずら(@vstcpp)さんが公開しているこのサイトが素晴らしいです。現状これだけVST3の情報が丁寧にまとめられたサイトは、日本では唯一です。(英語でもなかなか見つからないのではないでしょうか。)


ホスト開発側の情報は、現状ほとんどありません。筆者が過去にVST3をホストするデモアプリケーションを作成し、それに合わせてホスト側の実装を紹介した記事もありますが、当時の理解が足りていなかったために正確でない記述があったり、内容が古かったりする問題があります。

筆者は現在、そのデモアプリケーションの新バージョンを開発中です。新しい知見もいろいろ得られているので、ホスト開発側の情報については後日改めて記事にしたいと考えています。


JUCEやwdl-olなどのフレームワークで、さまざまなプラグインフォーマットのラッパークラスが実装されていることがあるので、そのVST3実装を見るのも参考になります。6


また、単純に調べてもわからない問題は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に関連するセッションがありました。

動画が公開されていて、どちらもすごく参考になります。



まとめ

今回はVST3 SDKについて紹介しました。簡単にまとめると以下のようになります。


  • VST3はSteinberg社のオーディオプラグインソフトウェアの規格の第3世代のバージョン

  • VST3は拡張性が重視されており、VST2ではできなかったことができるようになった

  • しかし複雑性が増し、ドキュメントも不十分なため、開発のコストが高い

  • そこにフレームワークが台頭し、VST3プラグイン開発が容易になった





  1. wdl-olというライブラリの場合は、WDLライセンスが適用されて、VST3 SDKのデュアルライセンスとは別の形態になっていますが、これはVST3 SDKをリポジトリに含めない形になってるので可能になっている? 



  2. VST2のときにも、dispatcherでeffCanDo/audioMasterCanDoというメッセージを送ることで、プラグインやホストが追加の機能を実装しているかを問い合わせる仕組みは存在しました。しかしこれは、プラグインやホストが、指定した名前の機能をサポートしているかどうかをYes/No/Don't knowの三値で返すだけのAPIであり、あまり拡張性がある仕組みではありませんでした。 



  3. サンプルプロジェクトのコード側と齟齬が発生する問題は、サンプルプロジェクトのコードのほうが実際に動く例になるので、ドキュメントよりもサンプルコード側を正解として扱うことになるでしょう。 



  4. ドキュメントのナビゲーションメニューに4種類のセクション (VST 3 API/Basic Module/VST-MA/SDK Helper Classes)があるのですが、どのセクションが何についてのドキュメントなのかと、それぞれのドキュメントの関係性がどうなっているのかがわかりにくく苦労します) 



  5. 一例として、高品質なプラグインをリリースしているu-heというチームが、Podolskiというプラグインを公開しており、そのパッケージにVST3_Readme.txtというファイルが同梱されています(日付は2014年5月22日)。そのファイルに曰く、「VST2版を使うのを強くおすすめします。VST3版を用意しようとして数ヶ月頑張ってみたけど、まだランダムなエラーとグリッチが発生する。VST3の複雑さを甘く見てた」。 



  6. つい最近、筆者もデモアプリケーション開発にあたり、VST3のドキュメントが不十分で理解できない箇所について、JUCEのコードを見てそこからVST3の仕様を推定したりしました。