衝撃の発表！ VST3オーディオプラグイン形式がMITライセンス化！

VST2の失敗から学んだかと思いきや、VST3はさらにWindows Component Object Modelをベースにしてて、さらにひどくなったね。車輪の再発明を避けたかったんだろうけど、リアルタイムオーディオプラグインやホストサポートには最悪のモデルだよ。APIはめちゃくちゃ複雑になったし、テストは悪夢だった。U-Heの開発者たちは現場の経験が全然違うのがわかるよ。

VST3が使われてる場所ではどこでもABIは安定してるよ。そうじゃないと何も動かないはずだからさ。

違うよ。VST2とVST3は名前が似てるだけで、共通点は何もないんだ。

僕の理解だと、VST3（とCLAP）はパラメーター値のルーティングが自由だから、すごく良いんだ。MIDIコントローラーだけじゃなくて、オートメーションカーブや他のプラグイン出力からもパラメーター値を送れる。例えば、2つのオートメーションカーブを掛け算プラグインで合成して、LPFの「カットオフ周波数」に入力して、MIDIノブでその変調量をコントロールできるとかね。プラグインがパラメーターを別入力として扱えるから、こういうのが自由にできるってことだよね。何か見落としてるかな？プラグイン開発はしたことないんだけどさ。

いくつか問題があるよ。まず、VST3はVST2やAUと共存しなきゃならないから、結局多くのプラグインでVST3イベントもMIDIに変換されちゃう。次に、パラメーター値は特別で、モジュレーションは直接パラメーター値をいじるんじゃなくて、その上にモジュレーションソースとして使うべきなんだ。MIDI CCなんかはモジュレーションソースとして扱われることが多い。それに、パラメーターは動的に扱えないから、MIDIコントローラーをモジュレーションに使いたいなら専用のパラメーターが必要だよ。VST3では、プラグイン間でパラメーターを出力して他のプラグインにルーティングするなんて、ほぼ不可能。だからVST3はMIDIの扱いが柔軟じゃなくて、MIDIサポートが貧弱なんだ。

VST3は最近moduleinfo.json機能が追加されたばかりだし、ホストはプラグインのスキャンを賢くやってるから、CLAPが宣言ファイルなしで速いって言っても、DLLが重い処理をしないのが一番だよ。CLAPのMIDIデータ表現は複数あるけど、プラグイン側での実装はそんなに難しくないんだ。それに比べてVST3は、パラメーターキューの扱いが特殊すぎて、効率的に書くのが大変。JUCEでさえ、VST3ビルドよりVST2ビルドの方がオートメーションがうまくいく場合があるんだ。MIDI CCのためにダミーパラメーターを2048個も作らなきゃいけないなんて指摘も的確だよ。VST3のAPIはめちゃくちゃで、バグも多いし、実装には何週間もかかった。CLAPは2、3日でサポートできたし、APIは簡潔でドキュメントもよく整備されてる。CLAPの開発に関わってたからちょっと偏見はあるけど、CLAPがダメなら正直に言うよ。

リアルタイムオーディオプラグインやオーディオホストサポートにとって、COMは非常に悪いモデルだ。COMは仮想テーブル内の3つの定義済み呼び出しに過ぎない。CLAPも似ていて、たくさんの関数ポインタを提供しているね。

なんで？Juceでは、複数のビルドターゲットを選ぶだけの問題じゃないの？

規格通りに書けば、VST3以外は全部動くはずだよ。

結構音楽やってるけど、CLAPプラグインなんてまだ一度も見たことないよ。

ABIはC++標準でカバーされてなくて、ターゲットやアーキテクチャに依存するんだ。この議論の目的では、VST3がサポートするターゲットとアーキテクチャではC++のvtableのABIは安定してるよ。
コンパイラとリンカがABIに従わないと、共有ライブラリのコンパイルやリンクには使い物にならないね。だから実際、ほとんどの有用なコンパイラは同じABIをターゲットにしてる。WindowsのMinGWのgccはちょっと変だけど、ほとんどのプロダクションソフトウェアはそれをサポートしてないしね。

COMは仮想テーブル内の3つの呼び出しだけって言うけど、実装側ではプラットフォームのvtable ABIがCOMと完全に一致すればそう単純でもあり得る。でも、問い合わせるたびに新しいオブジェクトを割り当てるような、もっと複雑な実装も可能だよ。
たとえオブジェクトがC++で実装されていて、プラットフォームのvtable ABIがCOMと完璧に一致して、実装しているインターフェースを正確に知っていても、dynamic_castは法的に使えないんだ。なぜなら、1つのクラスが両方のインターフェースから継承しているという要件がないからね。概念的な“COMオブジェクト”は、各インターフェースごとに1つのクラスとして実装されることもあり、それぞれが共有データクラスへのポインタを含むことが多いよ。これが、個々のインターフェースに対して参照カウントを行う必要がある理由でもある。実装側で全てに1つの参照カウントを共有するのは合法だけど、それは決して必須じゃないんだ。

うん、https://ossia.io で存在するほぼ全てのプラグインAPIの実装を経験したけど、VST3はやめてCLAPに移行すべきなのは間違いないね。

VST3ではパラメータ変更に線形補間を使うから、DAWはプラグインがどう値を解釈するか予測できて、オートメーションカーブの最適な近似を作れるんだ。でもCLAPには補間方法が定義されてないから、プラグインごとにやり方が違って予測不能で、正確なサンプル精度じゃないかもね。
スペックで補間について見当たらなかったけど、ノートエクスプレッションの補間については言及してるよ。あと、CLAPはパラメータとノートエクスプレッションに同じイベントを使うべきだったんじゃないかな？似てるし。
MIDI CCsにマップされる”ダミー”パラメータを作る必要があるってコメントは的を得てるね。JUCEはこれをやってる。2048個の追加パラメータが必要って、これはひどい解決策だよ。MIDI2は128個以上のコントローラがあるんだからね。URL: https://github.com/free-audio/clap/blob/main/include/clap/ev…

VST3はCOM vtableのレイアウトを実装してないってことに注意して。彼らのCOMライクなFUnknownは、実質3つの仮想メソッドとたくさんのGUIDsだけだよ。プラットフォームのC++ ABIが壊れないことに頼ってるんだ。
QueryInterfaceが異なるオブジェクトを返すってのは正しいけど、参照カウントを手動で管理しないなら、それが著しく複雑になるわけじゃないよ。

コンパイラとリンカがABIに従わないと共有ライブラリのコンパイルやリンクにはほとんど役に立たないって言うけど、C++では違うコンパイラで作られたライブラリをリンクしちゃいけないってこと？この場合はC互換のインターフェースを使うべきなのかな？

u-heは昔より規模が大きくなったよ。DivaやHans ZimmerがZebraを使ってるおかげで人気が出てきてるみたい。インタビューでもHans Zimmerはu-heをすごく褒めてるんだ。

u-heは最近、素晴らしいバーチャル楽器をたくさん作ってるよね。Divaは特に大ヒットだよ。

DAWのルーティングシステムを設計しようとしてたんだけど、オーディオ、MIDI、オートメーションの3種類のデータをプラグインで自由にルーティングできたら面白いなって思ったんだ。VST3のパラメータ補間モデルは便利だけど、パーノートパラメータは未対応なのが弱点かな。プラグインが出力パラメータを持てば、パラメータデータも処理できると思うよ。

CLAPフォーマットがめちゃくちゃ良いから、VST3もMITライセンス化したんだと思う。SteinbergはVST3を無理やり押し付けて、VST2.4 SDKを消したり、開発者を脅したりして、CLAPの普及を邪魔してきたよね。

独自フォーマットからの移行はもう遅すぎるくらいだよ。DAWをたくさん使うから、プラグインのスキャンにすごく時間がかかるんだ。AppleとかAvidが、この件を受けて開発者たちの負担を減らす話し合いをしてくれるといいな。AAXはコンパイルが大変だし、AUはVSTのラッパーだったりするから、もっと標準化が進んでほしいね。

Linuxに完全移行してから、DAWも音楽制作も完全にやめちゃったんだ。デジタルオーディオ業界って商業主義的すぎる気がするから、Blenderみたいなのが出てきて、業界を変えてほしいな。

このニュースは技術者にとって最高の発表だよ！コミュニティが何年も待ち望んでいたことだよね。フォーラムでこんなにひっそり発表するなんて、めちゃくちゃすごい！SteinbergとYAMAHAに感謝だね。きっとこれからもっと良いことがたくさん起こるはずだよ。

最近、オープンソースのオーディオ分野には良いニュースがたくさんあるね。Audacityの今後のバージョン4の計画に関するこの動画も見てみてよ: https://www.youtube.com/watch?v=QYM3TWf_G38

面白いことに、その動画の25分あたりでVST3ホストの実装がいかに大変か話してるんだ。「やるなら、相当な時間を覚悟しろ」だって。

俺は自分でVST3ホストを持ってるけど、正直そんなに難しくないよ。本当に問題なのは、多くのプラグインが標準じゃない「変なこと」をするせいで動かないことなんだ。

確か、それって動画でも言ってたよね。

VST3技術なしで同じことを実装してみなよ。もしやるつもりなら、相当な時間を覚悟しといた方がいいよ…。

Google Analyticsをまたこっそり入れようとしないことを願うだけだよ。

Audacity 4はかなり注意して見てるよ。また何かやらかさないか確認するためね（笑）。

これはすごいニュースだね。みんなが言ってる通り、CLAPがきっかけなのは間違いないけど、どう進化していくか楽しみだ。VSTはサポートが複雑だけど、CLAPはもっとシンプル。でも、VSTの方がずっと普及してるよね。

CLAPをサポートしてるプラグインは200個に1個くらいで、VSTは100%サポートされてる。だから、VST3がもっと簡単に、少ないライセンス負担で、コミュニティ貢献もあれば、これは大きいことだよ。ほとんどのプラグインがCLAPに対応するまでには、もし対応したとしても、まだしばらくかかるだろうね（CLAPとかけてるけどね）。

ほとんどのプラグインは直接APIを使わず、JUCEみたいなラッパーに依存してるんだ。JUCEがCLAPをサポートすれば、プラグインも追随するだろうね。来年にはそうなるはず。もっと大きな問題はホスト側だよ。AppleやAvidは多分CLAPをサポートしないだろうけど、Ableton以外のほとんどはサポートしてる。彼らは業界の他よりも動きが遅いんだ（VST3の実装に10年くらいかかってる）。CLAPはホスト側もプラグイン側も格段に使いやすいから、これって変だよね。とはいえ、CLAPプラグインをVST3やAUとしてラップすることは今でも可能だよ。正直、それが一番手っ取り早い方法だろうね。

CLAPをサポートしてるクールなやつもいくつかあるよ。例えば、Surge XTってオープンソースシンセサイザーは、1万個のプリセットが内蔵されてるんだ: https://surge-synthesizer.github.io/
あと、TX16Wxって非プロ用なら無料で使えるサウンドフォントサンプラーもあるよ: https://www.tx16wx.com/
全部はできないかもしれないけど、初心者にとっては、この二つで無料なのにかなり広範囲をカバーしてくれるよ。

CLAPはプラグインサポートの面でAUと似てくるかもしれないね。AUもかなり一般的だから。

CLAPはAUの普及率には全然及ばないよ。ほとんどのVSTプラグインにはAUバージョンがあるし（80〜90%くらい、主要なものは99%）、CLAPバージョンがあるVSTプラグインなんてほとんどないよ（1〜5%くらい、これでも多めに見積もってる）。

今すぐ普及するわけじゃないのは分かってるよ。でも、別のフォーマットの余地があるってことさ。AUが、どうやって新しいフォーマットが浸透するか良い例だね。

AUはLogic ProがAUしか読み込めず、そのユーザー層が魅力的だから普及した。
しかしCLAPは、CLAPのみを読み込むDAWがない。これはSteinbergがVST3で直面した問題と同じだね。VST2ライセンスを廃止して強制したけど、開発者は抵抗した。最近になってCubase/NuendoがVST2サポートを終了すると発表されたけど、CLAPはSteinbergのように強制できないし、CLAP専用DAWもないから、普及は難しいだろうね。

オーディオの専門家じゃないけど、僕の観察はこうだね：1. VSTがもっとオープンになるのは良いこと！
2. SDKは想像よりずっと大きそうだ。特に’このAPIは、他のどのスレッドからでもメインスレッドでのタスクのスケジューリングを可能にする’って部分が、オーディオ生成中心のAPIなのに、何に使うのか分かりにくかった。
3. 記事の表示がちょっとおかしい。ちゃんとしたリンクとMarkdownリンクが混在してるし、アスタリスクで囲まれた太字もあって、分かりにくいね。

＞SDKは想像よりずっと大きそうだ。特に’このAPIは、他のどのスレッドからでもメインスレッドでのタスクのスケジューリングを可能にする’って部分が、オーディオ生成中心のAPIなのに、何に使うのか分かりにくかった。
VSTプラグインはほとんどがGUIを持ってるから、VST SDKはクロスプラットフォームのUIフレームワーク全体をサポートする必要があるんだ。このスレッディング機能は、主にメイン（UI）スレッドへ入力イベントやレンダリング更新をやり取りするためのものだよ。

VSTには単一のUIフレームワークなんてないよ。プラグインAPIはGUIウィンドウの作成、破棄、サイズ変更のためのインターフェースがあるだけ。VSTGUIを使う必要はないんだ。

背景として、VSTのUIはバリエーションがかなり豊富で、まるでゲームのUIみたいにクリエイティブなものが多いよ。

良くも悪くも、ひどいことが多いけどね。UXって言葉が生まれる前の時代にタイムスリップしたみたいだよ。

その通り、ネイティブハンドルが渡されるだけ。それをどう使うかは自由だね。JUCEは人気のUIフレームワークだよ（少なくとも10年前は）。ElectronアプリをVSTに入れている人たちも見たことがあるね。

ああ、これは本当に厄介な問題になりそうだね。なのに僕たちは、リアルタイムオーディオ処理にC++を使うのと他の言語を使うのと、どっちが良いかって議論してるんだから。

スレッドAPIの背景はね、プラグインは’メイン’と’オーディオ’スレッドを基本とするんだ。APIは各メソッドがどのスレッドから呼べるか決めているよ。
’メイン’スレッドは主にUIを担当し、プラグインは重い処理をバックグラウンドスレッドでやりたいけど、このモデルがスレッドの管理を難しくしているんだ。
CLAPはホストのスレッドプールにフックする拡張を導入して、プラグインがスレッドを自分で生成しなくて済むようにした。VST3もこれをコピーしているよ。
APIの注釈は、どこでメソッドを安全に呼べるかのメモさ。
複雑に聞こえるなら、その通り。大半はVST3が生み出した複雑性だね。