オーディオプラグインとHost as Pluginについて
ModalicsのPlugin Buddyという「プラグインホスト」がリリースされてオーディオアプリ界隈で話題になっている。日本語記事だと、このページがちゃんと内容を見て（単なる翻訳だけではない）評釈を書いているので参考にすると良いと思う:
プラグインホスト、ではあるのだけど、この製品の特徴はHost as Pluginである点だ。つまり、Plugin Buddy自身がプラグインとして他のDAWからロードできる。
これが何を意味するかというと、プラグインフォーマットにまつわる問題がいくつか解消できるということだ。Plugin Buddy自身はAUv2またはVST3のプラグインとして動作するが、これ自身はAUとして動作していようとVST3として動作していようと、どちらのプラグインもロードできる。そして自身がプラグインとしてDAWから渡されたオーディオ入力やMIDI入力…に相当するイベント入力…を自身がロードしたプラグインを含むオーディオグラフに渡すことができる。オーディオグラフと書いた通り、Plugin Buddy自身は複数のプラグインをロードしてオーディオグラフを構築できる。
Plugin Buddy自身はJUCEアプリケーションで（Modalicsは著名なJUCEアプリ開発者がやっている会社でもある）、そのオーディオプラグインホスティング機能は要するにjuce_audio_plugin_clientだ。DAWごとにプラグインホスト実装の互換性が怪しいときは、Plugin Buddyを使えば、少なくともDAWそのものと各プラグインの相性ではなくJUCEのプラグインホスト機能とプラグインの互換性だけを気にすれば済むことになるし、Plugin Buddy上でオーディオグラフを構築すればそのフィルターチェインはJUCEとの相性だけを気にすれば良いことになる。
プラグインとして機能するホストってどういうこと?
JUCEなどでプラグインとホストを開発したことがある人は十分わかっていることだと思うけど、オーディオプラグインホストのAPIとしてプラグインのオーディオ処理を呼び出す部分は、オーディオプラグインのAPIとしてオーディオ処理を行う部分と、ほぼ変わらない。JUCEの場合、プラグインホスティング機能を担うjuce::AudioPluginInstanceクラスはプラグイン実装の基盤となるjuce::AudioProcessorクラスから派生している。もちろんJUCEに限った話ではない。オーディオプラグインホスティングのライブラリは、MIDI楽器などとは違って、自前でオーディオI/Oを実装しているわけではない。オーディオ入力はDAWのオーディオエンジンから渡されてくる。なので、プラグインもホストも入力を受け取って出力を生成する部分は同じAPIになる。これはどのプラグインフォーマットでもだいたい同じだ（だからこそJUCEみたいなマルチフォーマット対応のプラグインSDKの需要があるわけだ）。MIDIイベントとVST3イベントのマッピングもJUCEの統一的な変換規則で、つまり「前のプラグインも次のプラグインもJUCEホストを介している」という前提で行えるだろう。
そんなことをして何の意味があるのか?というと、DAWがたとえばVST3だけをサポートするのであればほぼ意味がないのは確かだけど、DAWは実際にはAUv2、AUv3、今は亡きVST2, VST3, LV2, CLAPといったさまざまなプラグインフォーマットをサポートする、あるいはサポートしてほしいという圧力をユーザーから受けるし、ユーザーにとってはもちろん手持ちのプラグインがフォーマットの違いだけで使えないという問題がどうにかなってほしい。Plugin Buddyみたいにプラグインとしても機能するホストはHost as Pluginと呼ばれるのだけど、このHost as Pluginが解決する課題は大きい。
Plugin Buddyはプラグインラッパーの進化形
Plugin Buddyはフォーマット間の違いや実装の相性の問題を解決するユニークで画期的なプラグインなのかというと、実はそんなことはない。Host as Pluginの機能をもつソフトウェアは、「任意のフォーマットのプラグインを自身のフォーマットのプラグインとしてロードする」というソフトウェアであると変えれば、いくつもある。先日CLAPフォーマットの生存戦略の文脈でclap-wrapperというプロジェクトに言及したけど、プラグインラッパーというのは典型的なHost as Pluginの類型だ。
他のプラグインラッパーの例としては、wineを使ってWindows用のプラグインをロードしてLinux上のVST(2, 3)として使えるようにするyabridgeというプロジェクトもある。これ自身も画期的だったわけではなく、airwaveやLinVSTなどいくつもの先行技術がある。他にも、Ardourの開発者の1人がLV2プラグインを任意のVST2ホストで使えるようにしたlv2vstというプロジェクトもある。
Host as Pluginの系譜はもうひとつある。DAW自身がプラグインとして動作するというものだ。たとえばRenoise ReduxはもともとRenoiseというトラッカーのソフトウェアだけど、それをVST/AU化したソフトウェアだ（しかもめちゃくちゃ古い）。Tracktion Waveformのエンジン部分はTracktion_EngineというOSSとして公開されているけど、この中にはEngineInPluginDemoというサンプルプラグインがある。これもDAW（のエンジン）がプラグインとして動作する例といえるだろう。FL Studioも、インストールされているとプラグインとしてリストアップされる。
プラグインホストという側面を前面に押し出したPlugin Buddyは画期的だ、と思われるかもしれないが、この方面でも実は先行プロジェクトがある。DPFやCarlaの開発者がIldaeilというhost as pluginを公開している。こちらはVST/AUだけでなく、LV2やCLAP、さらにはReaperのJSFXまでロードできる（Carlaがサポートするものは何でもサポートしている）。
IldaeilはプラグインラッパーとしてUIを兼ね備えたプログラムという側面が強いので、Plugin Buddyのような多彩な機能は備えていない。Plugin Buddyはこの種のソフトウェアの利便性と完成度を上げて製品化したもの（無料だけど）、と捉えるのが妥当なところだ。
ただ、Ildaeilと比べてサポートフォーマットはまだ貧弱だし、Mac版とWindows版しかないので、どちらかといえばホストとプラグインの相性問題などを回避するための道具であるとか、実装の差異を吸収するための道具であるとか、そういった周辺的な部分での用途しかアドバンテージがないのが現状だ。この辺りはPlugin Buddyの今後の課題ともいえる。
プラグインラッパーやHost as Pluginの可能性
筆者が最近お試しで開発しているプロジェクトもそうなのだけど、他のオーディオプラグインをホストとしてロードして利用するという仕組みには、いろいろな可能性がある。たとえば入力イベントのコンバーターを追加したい（あるいは全く別のイベント入力システムを組み込みたい）とか、追加の入力コントローラーを差し込みたいけどDAWから作るのは現実的ではないとか、そういった状況において、プラグインラッパーの仕組みは一般化して活用できる。
一般的にDAWベンダーは強い独占性を持ってプラグインフォーマットの独占性を強化していく傾向があるので（Steinberg + Cubase + VST3, Apple + Logic Pro + Audio Unit, Bitwig + Bitwig Studio + CLAP）、中間層によってオープン化…に類する技術の拡大…が浸透することは、自由な音楽の創造に繋がる、と自分は考えている。
Discussion