Logic Pro for iPadの登場でオーディオプラグイン/DAW開発は変わるのか?
AppleがLogic ProのiPad版を公開したというので話題になっている
自分はLogic Pro使いではないので（iOS使いですらない）、Logic Pro固有の事情については興味がないのだけど、Logic Pro for iPadは、オーディオプラグイン開発に新しい前提をいくつか持ち込んでいるはずなので、その観点で興味深い。
iPadで使えるオーディオプラグインフォーマットはほぼAU (AudioUnit) v3一択ということになるだろうけど、少し情報収集してみた感じでは、AUv3というのはオーディオプラグイン開発者の間でもあんまし理解されていなそうだったので、このLogic Pro for iPadがもたらすであろう変化を自分が書ける範囲でまとめておこうと思う。AUv3に詳しい人がいたらコメントなりSNS（Mastodon, Misskey, Nostrなど）なりで教えてほしい（blueskyはまだアカウントを持ってないので読めない）。
モバイルDAWとしては以前からCubasisやFL Studio Mobileが存在したし、最近はAbleton Noteなんてのもリリースされたけど、今回出てきたLogic Pro for iPadにはちょっとgame changerになる側面があると思っている。
前提: iOS上のオーディオプラグインについて
デスクトップで動作するDAWでは、VST3、AUv2、LV2、AAXみたいな、いわゆる「オーディオプラグイン」が楽器とエフェクターを担っている。これにはDAWベンダー自身などが開発する固有のやつ（他のDAWでは使えないやつ）とどのDAWでも使えるやつがあって、当然ながら後者のほうがマーケットが広いのでより多くのユーザーを獲得できることになる。どのDAWでも使えるようにするには、オーディオプラグインは何らかの汎用プラグインフォーマットと呼ばれるAPI等の仕組みに則って作られている必要がある。
デスクトップの場合、プラグインをDAWがロードするには、一般的にはdlopen()とかLoadLibrary()みたいな仕組みでプログラムを動的ライブラリとしてロードする必要がある（オーディオプラグインはリアルタイム処理がきちんと出来ていないと、GCやJITが走るたびに音が途切れたりノイズになったりするので、JavaScriptみたいな動的言語のモジュールとしてロードできることはほぼ無い）。
このライブラリをロードするという仕組みが、iOSでは使えない。一般のアプリケーションにすぎないDAWが、「他のアプリケーション」であるところのAUv2プラグインのプログラムを「ロードする」ことはできないからだ。そこで、「ライブラリをロード」しなくても独立したプログラム同士で連携できるように、AppleはiOSのApp Extensionという機構を利用するAUv3というフォーマットを新しく作り出した。
AUv3にはAUv2とは全く異なる課題がある。オーディオ処理はさっきも書いたようにリアルタイム性能が求められるシビアな世界なのだけど、AUv3はこれをIPC（プロセス間通信）によって超克しなければならないし（リアルタイムで動かさなければならず、WebサーバやgRPCサーバみたいなやつを適当に立てても解決しない）、iOSでデスクトップのようにプラグインGUIをダイアログ表示するには、特別なAPIの流儀に沿って作らなければならない。AUv3はmacOSでも使えて、デスクトップのほうが少し制約が緩いのだけど、AUv2とは別物と考えたほうがいい。
AUv3はAUv2の移植として突然iOSのオーディオプラグインソリューションとして出現したわけではなくて、AUv3以前にはInter App Audioというオーディオルーティングの仕組みがあって、さらにはiOSコミュニティでAudioBusというアプリケーション間オーディオ連携の仕組みがあって、これらがオーディオプラグイン的なものを部分的に実現していたのだけど、オーディオプラグインらしい機能は2023年現在では、ほぼAUv3が巻き取っていると考えていいと思う。
Logic Pro for iPadがフィーチャーするAUv3の機能
タッチUI
Logic Pro for iPadは、モバイル用に最適化されたApple製のAUv3プラグインをフィーチャーしている。"An all‑new creative interface. Made for touch." と書いてある。オーディオプラグイン開発者の間でも、iPad用にはデスクトップとは全く異なるGUIを構築する必要があるという認識は広まりつつあるようだ。
筆者は2019年くらいから書いているのだけど、今後モバイルプラットフォームも踏まえてクロスプラットフォーム・マルチフォーマットのプラグインSDKを使ってオーディオプラグインを開発するのであれば、タッチUI対応は必須になるだろうし、そこではFlutterやReactみたいなモバイルが前提のGUIフレームワークがいろいろな面で適性がありそうだと思っている（まあreact-juceはデスクトップだけで使っていると無駄に複雑だったかもしれないけど…）。オーディオプラグインのGUIは基本的に単一ウィンドウのダイアログ表示だし、キーボードはDAWのショートカットキーと干渉するのであまり使わない傾向がある。
従来のプラグインSDKはデスクトップ上でのクロスプラットフォームを前提として作られているので、タッチUI対応などは基本的に「クリックの代わり」程度でしかなく、モバイルに向いているとはとても言えない。MPEやらノートエクスプレッションやらをサポートするのにマウスカーソルひとつ分しかコントロールできないんじゃ、全然ありがたみが無い。タッチやスタイラスのプレッシャー（強弱）とか、いろいろ出来るべきことがある。
compact view
Logic Pro for iPadは新しい要求事項をプラグイン開発者に突きつけてきた。Logic Pro for iPadのプラグインのリストはタイルになっていて、そこから選択するとフルコントロールのUIが出てくるようになっているようだ。
このタイルUIの上では「コンパクトビュー」が表示されて、ここでは重要なコントロールだけが表示されるようだ。今後、AUv3プラグインでは、このコンパクトビューと完全ビューの2つが求められるようになったというわけだ（この仕組みがAUv3のAPIとしてどのように構成されているのかは自分は把握していない）。
もちろん、何もコントロールを表示しないデフォルトビューを作るのも難しくはないだろう。パラメーターのリストを取ってきて、何ならパラメーターの重要度みたいなプロパティを設定できるようにして、順番に表示できるだけ表示すればいい。GUIの無いプラグインでデフォルトUIを表示するようなものだ。
iOS SDKに含まれるAUAudioUnit.hには、parametersForOverview()というメソッドが定義されている。
This method allows a host to query an audio unit for a small number of its most important parameters, to be displayed in a compact generic view.
compact generic viewというのが、このコンパクトビューがプラグインで用意されていないときに代替UIを構築するときに使える、ということなんだろう（未確認）。多分われわれはこれと同じようなコンセプトのGUIをBitwig StudioのDevice Panelで見てきている。もちろん他のDAWにもあるかもしれない（筆者はDAWには詳しくない）。
Bitwigの固有プラグインではパネルのUI要素がカスタマイズされている様子が見えるが、右端に繋いだVSTのNeutron 3では単なるKnob付きパラメーターリストしか出てこない。こういうのは先述のプロパティなどを使えば作れそうだ。もしAudioUnit SDKが提供していないとしても、JUCEやiPlug2みたいなプラグインSDKがやる気になればやっつけられるだろう。
モバイルとデスクトップでのデータ共有
Logic Pro for iPadは "Roundtrip compatibility" もちゃんとサポートしている。iPadで打ち込んだ楽曲がiPadでしか編集・再生できないというのは魅力に乏しい。
Easily move your Logic Pro projects between Mac and iPad to create in the studio or out on the road.
iOSでもAndroidでも、モバイル版を出していてデスクトップ版も存在するという音楽アプリでは、モバイルで打ち込んだものを（クラウドストレージなどを経由して）デスクトップ版でロードできるというのはよくある。逆にデスクトップでモバイル以上の機能を提供していると、そのデータをモバイルでどこまで読めるようにするか、という難しい問題が発生したりもする。
楽曲データのデータポータビリティという観点では、2023年になった今でもSMFレベルでしか出来ないことも多い。Appleプラットフォームの場合、CoreMIDIは内部的に全てMIDI 2.0化しており、AUでもMIDI 2.0 UMPをサポートしているので、MIDI 2.0に準拠して楽曲データを保存するのは理にかなっていると思う（楽曲のポータビリティは個人的には別途 追いかけている テーマなのだけど、今回は深入りしない）。
デスクトップとモバイルでデータを共有できるようにするためには、デスクトップとモバイルの両方で同じプラグインが動作していなければならない。Logic Pro for iPadが実際にどれだけのデータポータビリティを実現しているかは現時点で未知数だけど、伝統的なデスクトッププラグインの世界では難しかった問題だ。
そもそも同じデスクトップOS同士でもパスが変わっただけで正常に楽曲データを復元できないプラグインがあってもおかしくない（「そのサンプラー、wavファイルをパスで保存してる?」）のだけど、さすがにそれはプラグインの実装の仕方の問題なので（サンプラーの場合は環境別の所定フォルダからの相対パスなどで記録しておくべき）、それは別論としても、プラグインのいわゆるstateのバイナリ形式はフォーマット固有なので、AUv2とAUv3では互換性が無いだろうし、VSTとAUでは互換性が無い。各フォーマットでバイナリデータにどのようなヘッダ情報が含まれるか、みたいな違いが生じるので、たとえば各プラグインで「stateはプラットフォームやプラグインフォーマットを問わずXMLやJSONで保存するので、パラメーターの内部状態が同じなら同一のstateバイナリが生成される」のように実装していたとしても、この違いはカバーできない。
そういうわけで、iPadOSとmacOSで打ち込んだ楽曲をラウンドトリップできるとしたら、同じプラグインが同じフォーマットで入っている必要があると思うのだけど、iOSではAUv2が使えないので、これは実際には「macOS上にAUv3プラグインがあればラウンドトリップできる」と言っているのに等しいのではないかと思う（もしAUv2とAUv3でstateデータに互換性があるのならその限りではない）。現実にはmacOS用のAUv3プラグインというのは滅多にないだろう。
「マルチフォーマットで同一のstateバイナリを使うようにしよう」という試みが出てきてもおかしくはないのだけど、プラグインフォーマットがそこを握っているうちは無理で、多分これに一番近いコンセプトで実現可能なものを挙げるとしたらMIDI 1.0/2.0のSysExやMixed Data Setによるセーブとロードだ。DX7のパラメーターをstateで保存せずにSysExで保存するような感じ。
macOSのプラグインはAUv3にシフトするか?
これまで、macOSのプラグインの多くはAUv2で開発されてきた。ひとつには、AUv3がサポートする分離プロセスモデルは、デスクトップではマイナス要素でしかないからだ。AUv3はデスクトップで動作する場合は分離プロセスモデルが必須ではない。だからAUv3で実装してもパフォーマンス上のネガティブインパクトがあるわけではないのだけど、AUv2で特に困っていないのだから、プラグイン開発者としては移行する理由がない。VSTプラグイン開発者の多くは、VST2 SDKがダウンロードできなくなるまでVST3に移行しなかった。
iOS上のAUv3プラグインもDAWも、商業的にはあまり売上が期待できるとは言い難い状況のようだけど（audiodevconのパネルディスカッションなどでたびたびそういった発言が見られるし、冒頭のHacker Newsにもそのようなコメントがある）。Logic Pro for iPadの登場で、このような状況が変わってくる可能性がある可能性はある。とはいえ月額サブスクリプションモデルだし、Logic Pro for iPad自体そこまで人気が出るかは未知数で、影響力があると考えるのは過大評価かもしれない。
DAW側はAUv3をサポートしていないことも多いだろうから、プラグイン開発者はAUv2でもAUv3でもプラグインをリリースしなければならなくなる…となると、プラグイン開発のコストがまた上がることになる。そう考えるとAUv3に対応しているJUCEみたいなプラグインSDKがますます求められるようになりそうだけど、一方でAUv3の場合は特に先述したコンパクトビュー対応などが新しく、JUCEのようなマルチフォーマットのプラグインSDKでは対応できない可能性もある。
モバイルアプリケーションの開発現場ではよく起こっていることだけど、クロスプラットフォームSDKが優位だと考えられるサイクルと、プラットフォームネイティブのSDKが優位だと考えられるサイクルが入れ替わりでやってくる傾向があって、AUv3によって、少なくともGUIに関しては、しばらくはネイティブ寄りの開発アプローチが優位になるかもしれないなと思っている。
それと、今後はmacOSのプラグインをiOSにも、という流れとは逆に、iOSにあったプラグインをmacOSにも、なんていう流れが出てくる可能性すらある。これはLogic Proとは無関係だろうけど実例はある。
Androidは?
iOSでAUv3のエコシステムが進化する中で、Androidではオーディオプラグインフォーマットをどうしているのかというと「無い」。でもオーディオプラグインフォーマットが無いといつまでも楽器／エフェクターアプリケーションがリリースされないし（DAWのin-house pluginsだけになってしまう）、Androidが音楽制作環境として全くリスペクトされなくなってしまうので、自分で作ってみている。だから類似しているAUv3の動向をこうやってまとめているわけだ。
最近「Audio Plugins For Androidの設計と実装」という同人誌を出していて（筆者はざっくり言えばAndroid用のAUv3みたいなやつを作っている）、技術書典14でも販売する予定なので、この分野に興味がある人がいたら見てみてほしい。
あと、先月Shibuya.apkでも同じトピックについて15分話したときのスライドがあって、これはAndroidについてのものだけど、モバイルにおける制約について言及しているので、AUv3がv2と何が違うのか知りたい人にも参考になると思う。
Discussion