2024年のオーディオアプリケーション開発技術の動向に関する私的見解 (1)
来月COSCUP 2024で "Catching up trends in audio app development" というタイトルでセッション発表することになっているので、ここ1, 2年くらいでトレンドとなったオーディオアプリ開発技術について、いろいろおさらいしておかないといけなくなった。というわけでこれはメモ書き程度にいろいろまとめていこうというものだ。
いろいろ考えをまとめていたら、だいぶ長くなってしまったので、3部作くらいにして公開すると思う。2部になるかも。
WebView
オーディオプラグインのUIにWebViewを採用しようという動きが活発になっている。C++のアプリケーションビルドモデルは、hot reloadingが不可能であるという点だけでも現代のGUI開発ツールの要求事項とは相性が悪い。RADが可能でデスクトップもサポートしているものとしては、JavaScript以外にもたとえばFlutterのような選択肢があるが、開発リソースが圧倒的に多いのはWeb UIだろう。
オーディオプラグインでWeb技術を取り込む可能性に関しては1年半前にも書いたのだけど、最近は具体的に利用可能な技術として「WebViewをUIとして使う」という方面に特定した話題が多い。Web AudioやWeb MIDIの方面では特に新しい技術が出現していない。Web UIに関しては、ADC (Audio Developer Conference) '23ではWeb UIを使ったプラグインをリリースしているOutput社のセッションがあった。
現地でセッションを見ていた勢としては、2023年に「MVCアーキテクチャで問題を解決しよう!」みたいな話かあ…これからWPFのMVVMみたいなのが来てCode as UIとか宣言的UIが5〜10年後くらいに来るのかなあ…みたいな感想だったのだけど（ちなみにADC24のtalk submissionにMVVMのやつが実際にあった）、オーディオプラグイン開発の世界はこんな感じのジェネレーションギャップがあるのが一般的だ。
まだWebViewを採用した製品は他では多くは出ていないが、WebViewを使用して開発サイクルを短縮しようという仕組みの開発の成果がいくつか出ている。
JUCE8の目玉機能はWeb UI対応だ。JUCEにはこれまでもWebViewコンポーネントが存在していたが、カスタムWebリソースのローダーやJavaScriptのインターフェースすら持たず、Web UIとやり取りしようと思ったらローカルに別途HTTPサーバなどを立てる必要があった。カスタムWebリソースローダーもHTTPサーバも無いとどうなるかというと、UIのHTMLを（SVGなどもあり得るが）file://... やdata:...のようなopaque originのURLでロードすることになり、fetch()やXMLHttpRequestが使えなくなる。JavaScriptインターフェースはGtk WebKitにもAppleのWebKitにもWindowsの古典的なWebViewにすらあり、JUCEのやつはネイティブプラットフォーム開発者視点では本気度の低い代物だった。
JUCE8はこれら2つの課題は乗り越えている。UIコンポーネントとC++ interopのサポートは正直まだ評価しがたい。Juce.getSliderState("gain"); みたいなコード例を見ると「スライダーに特化した関数がある…? マジで?」となってしまうのだけど（Juceというのが公式JSライブラリのクラスなのだけど、このアプローチってreact-juceでreconcilerをコンポーネントごとに実装する必要があったのと同じ轍を踏んでない?）、この辺は今後どうとでもなる可能性があると思っている。まずはプリミティブな基盤を整えた（整える）ことが重要だ。
JUCE以外のクロスプラットフォームC/C++ WebView実装としては、最初に思いつくのはwebview/webviewだけど（昔はzserge/webviewだった）、これもカスタムWebリソースローダーはサポートしていない（やろうと思えばできるようだが）。
Web UIをサポートするというJUCEのアプローチには、コミュニティでは反発もそれなりにあって、JUCEがそんな方向性で開発を進めていくのならJUCEは使わない、というユーザー（開発者）もそこそこいる（公式フォーラムやTAP Discordで見られる）。これはWeb UIでは期待通りのパフォーマンスが出ないからだ（in their holding opinion）と考えられるが、実際にたとえばWebGLを使用してUIを構築しても無理か、などは多少は検証の余地がある。とはいえアーキテクチャ的に理論上ネイティブよりパフォーマンスが良くなるとは考えられないので、基本的には彼らに相応の理がある。単にまともな開発者リソースを確保できていないjuce_gui_basicsの設計と実装がイケてなくて、Web技術の集大成たるWebKit上のUIよりパフォーマンスが悪い…という事態は生じ得るけど。
JUCEとは関係のないオーディオ関連プロダクトとしては、CmajorもUIにWebViewを使う想定で開発されていて、今年公開されたPro-54は、Native InstrumentsのPro-53のクローン（Pro-53自体はProphet 5のクローン）がWebでも動作する!という感じで話題になった。
「関係のない」と書いたけど、もちろんJUCEもCmajorもjules (Julian Storer)が創始者だ。CmajorのWebViewサポートは、同じくjulesの開発しているTracktion/chocに基づいていて、これはMicrosoft WebView2のDLLをそのままCヘッダーファイルに埋め込むという暴挙(?)に出ている（必須ではない）。WebViewのDLLってそれなりにセキュリティアップデートが頻繁に来るんじゃないの? あまり製品のアップデートが頻発しないオーディオプラグインにstatic linkして大丈夫? と個人的には気になってしまうのだけど、オーディオプラグインのプログラムは単独で完結しているべき／DLL HELLに陥ってはならない、といった要件を突き詰めるとこうなるのだろう。chocについてはADC '22のセッションで語られている。
どのWebView実装でもまともに解決できていない課題としては、LinuxでGtkを前提にしていることが挙げられる。Linux上で動作するオーディオプラグインはX11のAPIで実装すべきとされているので、GtkWebKitを使ってはいけないはずである。Linuxも含めたクロスプラットフォームWeb UIを実現したオーディオプラグインは、自分が知る限り存在しない（UIがプロセス境界を越えるatsushieno/aquaは、ちゃんとリリースまで作り込めば世界初の事例になる可能性がある）。
オーディオプラグインのロジック部分とWeb UIでは、データを共有しなければならない。たかだか数バイトのパラメーター入力を受け取ってアニメーションUIとして反映するくらいのことなら十分に可能だろうけど、SerumやVitalのような3D波形を、あるいは入力波形と加工後の波形をパラレルに表示するEQなどを、Web UI上で実現しようと思ったら、そのWeb UIのJavaScriptからオーディオデータを取得できなければならない（DSPで処理したオーディオバッファをMMAPした領域をWebView上のJSランタイムが読み取れるUint8Arrayとして渡せるだろうか?）。これが現実的に実現可能なのかは、まだ明らかではない。Output社の製品でWebViewを使っているのはArcadeだが、これがパフォーマンス的に強い（厳しい）性能要件のUIを実現しているとは思えない。
オーディオ処理とは異なりUIでは厳密なリアルタイム性は求められない、というのが現時点でのオーディオプラグイン界隈での理解だと思うけど（自分の感覚でも妥当だとも思う）、visionOSのようなAR/VR環境でGUIを操作するような時代になると、プラグインUIも60fpsでスムーズに動作するようなものが求められる時代になるかもしれない。
CLAP as a Plugin SDK
WebViewまわりでもcontrovertialな反応が出ていたJUCEだけど、JUCE8ではライセンス面で大きな変更が出て問題…すくなくとも話題になった。まずGPLv3で提供されていた部分が全てAGPLになり、そしてISCライセンスで公開されてた部分も全てAGPLに変更された。もともとライブラリをGPLで公開するという時点でほぼ商用製品としてリリースしていたようなものだが、AGPL化することで「何とかして商用ライセンスを買わせる」方向に向かっているのは間違いない。ISCコンポーネントの廃止の原因は多分juce_midi_ciをISCでは出せない…とか考えるのめんどくさかったからだろうと想像するのだけど、まああくまで想像だ。ただこれを見たjulesは「マジかよ…」と呆れていて、ネガティブなインパクトがあったことも間違いない。
Cmajorではこの変更を受けて（と断定して良いと思う）JUCEをgit submoduleから外してしまった。Cmajorをチェックアウトしても、もはやデフォルトでJUCEによるプラグインをビルドする仕組みはない。もちろんCmajorはプラグインビルドをデフォルトで放棄したわけではない。ではどうしているかというと、CLAPプラグインをビルドする機能が追加されている。CLAPのプロジェクトの成果は、ほぼMITライセンスで公開されているので、JUCEのようなライセンス問題が発生しない。
CLAPプラグインをビルドしたってVSTやAUにはならないじゃん、と思われるだろうけど、CLAPプロジェクトのほうでは、去年あたりからclap-wrapperというプロジェクトの開発が活発になっていて、これを使えば問題ない、というのがCLAPコミュニティのスタンスであるようだ。実際Cmajorがサポートするような機能はVST3の個別のAPIを使わなくても実現できるだろう。
DAWにおけるCLAPフォーマットの採用は今でも地味に拡大していて、最近はFL Studioにもサポートが追加されているのだけど、Bitwig社が主導しBitwig社の意思で方向性が決まるプロジェクトという側面もあり、VST3を開発している Steinbergが自社製品であるCubaseでCLAPフォーマットをサポートする日はたぶん来ないだろう。AppleがLogic ProでVST3をサポートするのを期待するのと同じくらい無理がある。BitwigもBitwig StudioのLV2サポートを求める声を完全に黙殺しているので、同じ穴のムジナではある。
そういうわけで、VST3プラグインをAUとしてロードするのと同じように、CLAPをVST3としてロードできるようなプラグインラッパーが開発されている。これがあれば、プラグイン開発者はCLAPプラグインだけを開発すればよく、他のフォーマット向けにはclap-wrapperを使えば間接的に利用できる、という発想だ。
これが実現して一般化すると、JUCEはいらない子になるだろうか? 数年後にはそうなる可能性はあるけど、まだまだclap-wrapperのエコシステムだけではJUCEが提供している価値には追いついていない。まずCLAP APIはそもそもプラグインとホストのインタラクションに特化したAPIであって、clap-helpersも（C APIで提供されるCLAP APIに対して）C++でコーディングできるという以上のものではない。UI部品は含まれていないし（これはもちろん良し悪しはあるが、少なくともJUCEを使いつつjuce_gui_basicsを使わないという選択肢はある）、プラグインUIとプラグインの間でパラメーターをやり取りする実装みたいなものは特に含まれていない。
あと割と無視できないのがiOS (AudioUnit V3) とAndroidサポートの不在だ。JUCEは（いろいろ足りていない部分もあるけど）基本的にはこれらのプラットフォームをサポートしている。CLAPは現状そこまでplatform agnosticなプロジェクトではない。AUv3は根本的にパラダイムが異なるので（何ならAUv3にはUIとロジックのコードベースを分離しているLV2のほうが近い）、CLAPのエコシステムがそこまで包摂した設計になっているJUCEに追いつくにはしばらくかかるだろう。そもそもBitwigがモバイル製品を何もリリースしていないので、関心領域外としてコミュニティに丸投げする状態が続くと思われる。
今日はここまで。
Discussion