VST 3.8.0はオーディオプラグイン開発の何を変えるか
MITライセンスになったVST3
10/20にリリースされたVST 3.8.0が、何の前触れもなくGPLv3からMITライセンスに変更になった。
Steinbergは "VST3 is now open source." と書いているが、VST3は以前からGPLv3でリリースされており、GPLv3はOSI approved licenseという意味でオープンソースなので、以前からオープンソースだったものが、よりリベラルなライセンスになったと書いたほうが適切だ（Hacker Newsの投稿なんかは"VST3 audio plugin format is now MIT"と公式の表現をわざわざ書き換えている）。
これまでのVST3SDKはGPLv3と非OSSのデュアルライセンスで公開されており、もしVST2SDKのようにSteinbergが新規ライセンス発行を停止すると、VST3SDKを使用していた製品はGPLv3でOSSにするか、古い利用許諾の承認を受けた（要するに以前からダウンロードしていた）ユーザーのみが引き続き利用するしかない、という状態だった。商用製品の開発者としては、GPLv3で公開するわけにもいかず、これはリスクでしかなかった。
SteinbergのVST3SDKのGPLv3でないほうのライセンスは厳しいものとはいえないが、このライセンス体系によって 「マスタースイッチ」を握りしめていたといえる。かつてSteinbergは、いつまでもVST3に移行しようとしないプラグイン開発者コミュニティに反発して、VST2SDKのライセンスを剥奪して、GitHubリポジトリなどに取り込んでいるものも全て削除させて回った。今後VST4となるかはわからないが、新しいフォーマットを公開したとき、VST2SDKのように商用製品の利用を許さず強制的に新しいAPIに移行させることが、GPLv3であれば実質的に可能だった。
これらの事情とは別に、VST3SDKは2017年のv3.6.7までLinuxをサポートできておらず（ちなみに筆者が調べてみたところ、LinuxサポートがStableになったになったという記録は無い）、これがOSS界隈でのVST3移行に歯止めをかけていた（これは実質的にはJUCE6によるサポートのほうが大きかったかもしれないが）。
CLAPがもたらしたプラグインフォーマットの競争
そんな中、2022年にBitwigが掌握するCLAPフォーマットが、VST3の旧弊をいろいろ改善したものとして公開された。これはMITライセンスなので、VST3SDKの抱えていたライセンス爆弾がなく、この観点で将来性を期待していた開発者が多かった。
CLAPがもたらしたものはライセンス条件の改善だけではない。CLAPはVST3と比べて相対的にシンプルなC APIとして設計されており、いくつかの点でVST3とは設計思想が異なる。CLAPにはVST3-MAのような煩雑な仕組みが無い。拡張機能のクエリはget_extension(URI)でポインターを取得して拡張機能の型にキャストするだけである。vtableを用いてABIを維持することは無い。ホストAPIとプラグインAPIの切り分けも美しく設計されている。開発のしやすさでいえば、VST3よりCLAPを選びたい開発者は多いだろう。
もちろん、CLAPが何でも優れているわけではない。CLAPが公開された当時、CLAPコミュニティは「ロードしたライブラリの関数を実際に実行せずにプラグインのメタデータを取得できるのでスキャンが高速だ」と主張していた。するとVST3のほうは、その次のv3.7.5リリースで、manifest.jsonという「そもそもライブラリをロードせずにメタデータを取得できる」やり方を実装してしまった。ライブラリファイルは巨大でシンボルもどれだけあるか分からず、これを実装済みのVST3プラグインのほうが高速なスキャンが実現できることは疑いない。VST3はこんな感じでバージョンアップのたびに改善が加えられている。
CLAPコミュニティによれば「挙動が明確にドキュメントされている」そうである。筆者の印象としては、これは断片的な側面でしかなく、VST3がCLAPに劣ることはない。新しい規則には穴が少なからず存在し、書かれざる要件が多々存在するものである。前出のHacker Newsのスレッドでは、CLAPプラグインはVST3の1/200くらいしか存在しないと言われていて、それが正しいとしたら、10本の実装の間で仕様の解釈に食い違いが無くても、2000本になればどうなるかはだいぶ怪しい。仕様の解釈に相違があったとき、Bitwig社が自社の都合に合わせて仕様解釈を押し付けてくるという懸念もある。これはSteinbergのVST3でも原理的には変わらないが、VST3には有力なDAWプレイヤーが複数あるので、Bitwigが独断専行できるほどの自由度はSteinbergには無いだろう。
ちなみにリベラルなライセンスのプラグインフォーマットとしてはCLAPよりもずっと前からLinuxを中心に使われていたLV2が存在していて、MacもWindowsもサポートしており、JUCEで作られたプラグインをエクスポートすることもJUCE 7.0での公式対応以前から非公式forkで出来ていたのだが、RDF Turtleなどを用いる仕様がやや難解であり（筆者に言わせればRDFセマンティックモデルは曖昧さをもたらす点が良くない）、非公式JUCE forkなかなか商用製品で対応しづらかったと考えられる（Pianoteqなどは採用していた）。筆者が理解する限りではライセンスの扱いが難しい。今はJUCEが公式対応していて、それに基づくLV2プロダクトもリリースされている。
LV2はGUIの分離などはよく練られた設計だが、ノート別エクスプレッションのサポートなどにあまり前向きではなく、UMP（MIDI 2.0）にも対応しておらず、現代的なアップデートに意欲的であるとは言い難い。設計がエレガントであるという議論は（自分も含めて）多くされるが、将来性を期待しているというユーザーは多くなさそうだ。
CLAPはオワコン?
VST3がMITで使えるようになったので「CLAPはもうｲﾗﾈ」というような言説が散見されるようになった。「VST3を使いたいがGPLv3というわけにはいかないのでVST3と同じことができるならCLAPにしてもいい」というプラグインAPIユーザー（ホストなりプラグインなりの開発者）にとっては、VST3SDKを使うという選択肢が優先されるだろう。
しかしそれ以外の開発者にとって、CLAPは引き続き有力な選択肢だ。VST3でもCLAPでもどちらでコードを書いても良い、と言われて、あえてVST3SDKの流儀でコードを書きたいという開発者は多くないだろう。CLAP APIの簡潔さとホスト・プラグインの役割の明確な識別は、プラグイン開発者にとって大きな魅力のひとつだ。またCLAP firstアプローチで、CLAPプラグインを書いてから、clap-wrapperを用いてVST3とAUにエクスポートする手法もある。筆者はLV2にエクスポートできないclap-wrapperを利用するつもりはないが。
また、JUCE v9.0が予告通りにCLAPをサポートするようになれば、JUCEを利用しているプラグインベンダーの多くはビルド対象としてCLAPを追加するだけで済むようになるので、CLAPを「サポートするコスト」というのは概ね無視できるレベルの問題になるだろう。実際のところ、githubでオーディオプラグインのコードを検索して見つかるのは大半がJUCEのアプリケーションであり、vst3sdkのAPIを使って書かれたプラグインはほとんど無い。プラグイン開発者の視点でいえば、キープレイヤーはJUCEである。
現在でもCLAPコミュニティの公式プロジェクトであるclap-juce-extensionsを使えばCLAP版をビルドするのはごく簡単だが（たいがいCMakeLists.txtにちょっと手を加えるだけで足りる）、JUCE側の公式対応待ちというベンダーも少なくないだろう。
MIDI 2.0マッピングの対応
VST3ではIMidiLearnとIMidiMappingというインターフェースがMIDIデバイスからの入力をVST3イベントにマッピングための拡張機能として規定されているが、これらはMIDI 1.0を前提としたものだったため、MIDI 2.0に対応するものとして、新たにIMidiLearn2とIMidiMapping2というインターフェースが追加された。これらはMIDI 1.0と2.0の両方のマッピングをカバーすることになる。
VST3におけるMIDIイベントのサポート
VST3はその他のプラグインフォーマットとは異なり「MIDIメッセージをサポートしない」唯一のフォーマットである、といえる。しかしこれは、VST3プラグインを使うとMIDIデバイスによる入力が一切利用できない、という話ではない。MIDIデバイスからの入力イベントは、VST3プラグインのホスト = DAWがVST3イベントに「マッピング」して送る、というかたちで利用できる。
VST2にはMIDI入出力のためのチャンネルが用意されていて、VST2プラグインはMIDIデバイスからの入力をそのまま受け取って処理することが可能だったし、MIDI出力を生成することも可能だった。これとは他にVST2イベントも入力として渡すことが可能で、こちらはMIDI 1.0よりも高精細な（32ビット等の）データを送信できた。これらが混在するとややこしいというので、SteinbergはVST3からMIDIイベントのサポートを「マッピングで対応しろ」ということにして切り捨てたのである。
これはsingle source of truthのような観点では歓迎できたことではあるが、実際にはこの仕様によって実現できなくなった類のプラグインがいくつも発生した。たとえば…
- GM互換音源を実現するためにはプログラムチェンジを「チャンネルごとに」指定できなければならないが、当初のVST3.0は「プログラムチェンジ用のパラメーターを作れ」で終わっていて、これを素朴に実現するためには16個のプログラムチェンジ用パラメーターが必要になった。現在の仕様では（VST3の仕様はバージョンを追うごとに進化している）、パラメーター変更の属性にunitというフィールドが追加されていて、ここにMIDIチャンネルを指定するかたちで実現することになっている。
- MIDI出力が生成できなくなった。パラメーター変更を出力するVST3イベントストリームのポートは作成できるが、そこに出力されるイベントがMIDIイベントに相当するものなのかはわからない。現在の仕様では、LegacyMIDICCOutEventというVST3イベント種別が規定されていて、これを使って対応することになる。
このような体たらくだったため、多くのプラグイン開発者やユーザーにとって、VST3はシンプルに「MIDIをサポートしない」フォーマットである、という扱いで喧々囂々だった。このようなフォーマットで「MIDIをサポートしている」と表現できるのであれば、MIDIよりも高度なイベントストリームをサポートするフォーマットは、MIDIのことを微塵も考慮していなくても「MIDIをサポートしている（なぜならマッピングできるから）」と言えてしまう。
MIDI 2.0構想が201x年代末に登場してから、2020年にVST3.7.0がリリースされたが、これはMMA (当時MIDI Manufacturers Association, 現在のMIDI Association) によって "VST 3.7 SDK Includes MIDI 2.0 Support"と宣伝されることになった。なぜならMIDI 2.0イベントのほとんど（全てではない）はVST3イベントとして表現できるから、である。VST3はこの時MIDI 2.0をサポートするための作業をほとんど何もしていない。
MIDI出力に対応するIMidiMapping2がもたらすもの
MIDI出力ストリームを「レガシー」扱いするSteinbergの基本的なスタンスは「それはDAWでやるべきもの」という「MIDIストリーム出力」の徹底的な敵視だった。しかしコミュニティからはNOを突きつけられ続け、前述のようにMIDI出力イベントに相当するVST3イベントを定義する羽目になった（それでもLegacyという蔑称を使うことに拘泥したが）。
IMidiMapping2のAPIは、IMidiMappingとは全く異なっている。新たにMIDI 2.0出力をサポートするためにBusDirectionsを指定してマッピングを取得することになっている。つまり、MIDI出力イベントをマッピングするためのインターフェースにもなっているのである。これはSteinbergが改心したとも読めなくもないが、おそらくSteinbergに問い質したら「MIDI 2.0は双方向メッセージングの仕組みだから」というのが正式な回答となって返ってくると思われる。もっとも、MIDI 1.0のマッピングでもMIDI出力を指定できるので、「それならMIDI 1.0用のAPIを変更する必要は無いのでは?」という反駁も考え得る。まあ我々(?)の溜飲は下がるかもしれないが、Steinbergの開発者を困らせても益がないだろう。MIDI 1.0と2.0でAPIが一貫しているほうが開発者にとっても有益だ。
API設計の変更の動機がいずれにあるにしても、MIDI出力イベントがマッピングできるようになったことは良いことである、と評価できそうだが、実際には新しい問題が作り出されたのではないかという意見も見られた。MIDI CCイベントはDAWでユーザーからMIDIマッピング指定されたものを送信して、それからフィルターチェインで直前に配置されたプラグインが出力したものも合わせて送信すべきなのか、同じタイミングでコントロールチェンジが重複した場合はどういう扱いになるのか。VST3はCLAPと異なり、複数のイベントストリームが同一のパラメーターを操作できる仕様になってしまっているので、これは以前から存在していた問題であるともいえるが、問題が生じる場面が増えるのは確かだ。
もっとも、DAWでMIDI 2.0を前提としたプラグインの操作においては、MIDI 1.0とは異なり、1つのUMPイベントストリームの中でも、Function Block単位で（UMPとしてはgroupフィールドによって）特定のプラグイン宛にメッセージを送信することが可能だ。筆者はたまたまプラグインのフィルターチェインを仮想MIDI 2.0デバイスとして演奏するホストを作っているが、そのパラメーターの操作の出入り口を設計していて、「MIDI 1.0の頃のようなMIDIマッピングは不要なのでは…?」と思っているところだ。この辺りはMIDI協会のDAW Working Groupで議論されるべき事柄といえる。
IMidiLearn2はIMidiLearnと同様、IMidiMappingのMIDI入力をプラグインから上書きする（それをホストにIComponentHandler::restartComponent()で通知する）ためのインターフェースであり、その基本的な役割は変わらない（入力専用である）。
ノート別コントローラー対応の不在
IMidiMapping2はRegistered ControllerとAssignable Controller、MIDI 1.0時代にはRPN/NRPNと呼ばれていた機能に対応する。一方で、MIDI 2.0で新たに導入されたノート別コントローラー (Per-Note Registered/Assignable Controller) には対応していない。MIDI 2.0のPNRC/PNACやVST3のNoteExpresionは、CLAPのパラメーター拡張とは異なりメタデータをグローバルパラメーターと共有しない（AudioUnitGetProperty()でコンテキストを使い分けるAUも同様といえる）。
原理的にはMIDI 1.0のMIDI Mappingと同様の機能が必要になりそうなものだが、現状DAWでほぼ実装できていないはずなので、具体的なワークフローが想定できず、現時点ではAPIを策定できないということだろう。将来的にはIMidiMapping3のようなものが出来て対応することになるかもしれない。
Waylandサポートの追加
VST3.8.0では、Linuxデスクトップ向けに新たにWaylandサポートがPreview APIとして追加されている。これもやや面倒な解説が必要な要素だ。
オーディオプラグインのGUIはX11の世界
VST、LV2、CLAPといったオーディオプラグインのLinux GUIの世界では、GtkでもQtでもなくX11を使うことが推奨されている。より正確には、ホストとプラグインの両方が特定のGUIフレームワークを前提として動作してメッセージループを立ち上げてはならない、ということになる。GtkもQtも独自にメッセージループを立ち上げるし、それらは通常は相容れずに競合する。競合を避けるためには、X11のレベルでX11のイベントが渡されることを前提にGUIを設計することになる。WindowsのWndprocや、CocoaのCFRunLoopのようにグローバルループがある前提のGUIでは、この種の問題は生じない。
VST3の場合、インターフェースとしてIRunLoopというものが定義され、GUIフレームワークの種類を問わず、ホスト側はこのインターフェースを提供し、プラグイン側は自身のIPlugViewにIPlugFrameをsetFrame()で登録するときに（ホストから呼び出されたときに）、registerEventHandler()とregisterTimer()という関数を使ってGUIループ上でUI処理を行えるようになって「いた」…これが過去形なのは、そう、Waylandが登場したためである。
既存のIPlugViewインターフェースの実装はLinux上ではX11が前提になっていると考えられるので、VST3ホストがプラグインからWaylandで動作するwl_subsurfaceを使えるようにするためには、Waylandサポートのインターフェースをクエリする必要がある。WaylandプラグインUIをホストにアタッチするにはwl_compositorも必要になり、いろいろAPIの平仄も合わないようだ。筆者はWayland開発を試したことが無いので知見が薄い（が、後述するようにLV2プラグインSDK開発者が「いま実験している」という段階でプラグインUIを開発できる知見がある人はそうそういないと思われる）。
PreSonusのWaylandサポート独自拡張
実は今回のWaylandサポートはSteinbergで開発されたものではない。元々はPreSonusが開発していた独自拡張だ。
PreSonusは2023年にStudio One 6.5で新たにLinux版をリリースした。Studio OneはLV2をサポートしておらず、公開プラグインフォーマットとしてはVST2とVST3が使えただけだったが（その後7.0でCLAPサポートも追加している）、さらに大きな問題として、Studio One for LinuxはWaylandアプリケーションだった。そのため、X11のプラグインUIが使えず、これらのフォーマットのプラグインはGUIなしで使うことが前提だった。Studio One for LinuxはさらにFlatpakアプリケーションとして配布されており、DAWとしてあらゆる地雷を踏んでいるともいえる(?)。
このような状況の中で、PreSonusとしてはVST3に独自拡張としてのWaylandサポートを追加する必要があった。PreSonusは以前からさまざまな独自VST3拡張を公開していて、Wayland拡張もそのひとつだった。そういうわけで、少なくともこのVST3拡張はDAW側では実装済みの技術といえる。大概のプラグインAPIはDAW側で実装されるほうが重要で、サポート製品が出ているというのは割と大きいアドバンテージだ。
ちなみにこの拡張の開発者は今年のLinux Audio Conferenceにも来ていて、このWaylandサポートのセッションのようなものもやっていた（筆者は現地で初めてこの独自拡張の存在を知ったので、詳しくは掘り下げていない）。ただし上記リポジトリで公開されている以上の発表資料などは特に無かった。
今回VST3SDKで公開されているWaylandサポートのAPIは、このPreSonusの実装をそのまま取り込んでいるようだ（細かい差分はあるかもしれない）。
「妥当な」WaylandサポートのAPIはどうなっているべきなのか
WaylandサポートはVST3だけの問題ではない。Appleプラットフォームでしか使えないAudioUnitを除く全てのプラグインフォーマットで問題になる。Waylandに問題がないというわけでは全くないが、X11からWaylandへの移行はLinuxデスクトップの世界における一般的な課題であり、2025年になって未だにX11での実装を求められるオーディオプラグインの世界は、技術的負債そのものともいえる。
そんな中でWaylandサポートに向けて一歩踏み出したVST3の動きは歓迎されていることだろう、と思われるかもしれないが、意外にも(?) Linuxオーディオ界隈の反応は実のところそんなに温かくない。
LV2では仕様策定の議論が2024年に上がりだしたが、今年になってDPF（プラグインSDK）とCarla（プラグインホスト）の開発者がWayland UIのPoC設計・実装を公開している。その設計にあたっては、PreSonusのWayland拡張に目を通していたらしいが、「proxy compositorを渡すのは不必要に煩雑で美しくない」といった感想が並んでいて、この試験リポジトリではwl_subsurfaceを使って実現しよう・できるはず、といったアプローチで臨んでいるようだ。wl_surface*がLV2_UI__parentのfeatureとして渡されていて、wl_displayはLV2 optionsとして渡されている。
CLAPではGUI拡張にCLAP_WINDOW_API_WAYLANDという定数が定義されていて、これだけ見るとWaylandサポートはすでに実現しているかのように見えるが、実際には定数が存在するのみで、これを使用したサンプルも何も公開されていない。ただ「embedはサポートされていない。floating windowを使え」というコメントはあって、盲目的に定数を定義だけしたわけではないようだ。とはいえ、これは要するにWaylandはまだサポートされていないということである。
これはどういうことなのか、というissueが登録されていて、仕様設計者も回答しているのだけど、「wl_displayを渡すAPIにはするべきではない。これをやるとWaylandのABIを引きずることになってしまう」「Waylandはプロトコルなのだから（strongly-typedなwl_displayではなく）Wayland socketを受け渡すようにすべき」みたいな議論をしていて、現状「誰かがPoCを作るべき」とだけ書かれていて先に進んでいない状況だ。
CLAP開発者の視点ではwl_displayを渡すLV2実験のアプローチもNGということになるが、そのCLAPでは現実として何もソリューションを提示できていないわけで、これが最適な状態であるとは言い難い。
結語
VST3はCLAPのような新しいフォーマットの前に存在感が埋もれがちだったが、3.8.0は、ライセンスの変更も含め、各方面で野心的な変更が盛り込まれていて、まだまだ枯渇した技術とは言い難い。現代でもJavaやC++が進化し続けているように、VST3もまだ進化し続けるのだろう。とはいえ、1つ前のマイナーリリースであるところのVST 3.7.0がリリースされたのはもう5年前（2020年）なので、ここまで大胆な変更はしばらくはでないと思ってもよさそうだ。CLAPが登場したのがほんの3年前だし、5年後にVST3がどのような位置付けになっているかは予測できないが、もう18年も前に最初のAPIがリリースされたVST3が、使われ続けている可能性はまだまだありそうだ。
Discussion