ADC Japanでの発表が終わって、締切ドリブンなタスクが無くなったので、6月はひさびさにゆったりバカンスなどして過ごしました。（オマエ5月にもKotlinConfのついでに小旅行していたじゃんと言われればそれはそうですが、ADCの準備等を気にして早目に帰国したほうなので…）
ADC Japan 2026
今月は6/1〜6/3のADC Japanから始まりました。ADC Japanについては自分視点で書いたレポートを上げてあります。
https://zenn.dev/atsushieno/articles/fbf5b7e782fbe2
uapmd-ara
4月の時点でUAPMDにオーディオワープ機能を実装していましたが、これはごくシンプルなもので、まだ改善の余地があるものでした。4月の時点でこう書いています。
ただ、オーディオワープ機能は、どちらかというとARA2に対応するプラグインがオーディオ入力を受け取ってタイムストレッチを動的に（リアルタイムに、ではないにしても）適用できるように事前処理する仕組み、を表現できる必要があって、いま実装されている静的なリストはARAの仕組みとは相容れません。時間ドメイン（と書くとFFTの話っぽくてややこしいですが）における加工処理にも、一定の抽象化が求められそうです。この辺はvNext issueです。
ただ、この書き方もあまり正しくない側面があって（単にまとめた時点での理解不足）、オーディオワープポイントを編集する仕組み自体はこの時点で既に実現していました。今月はADCでARA2について勉強できたこともあって、だいぶ解像度が上がってきました。あまり直接関係しない話ですが、今の理解はこんな感じです:
https://bsky.app/profile/atsushieno.bsky.social/post/3moxkahfwts2p
UAPMDは普遍的なプロジェクト データモデルを理想として設計しているので、ARA2を前提としてデータモデルを設計することはありません。一方でARA2（そしてARA3）が提供する機能を実現できる程度には広範な機能を備えている必要があります。LSPにはドキュメント編集モデルとなるプロトコルが含まれているのですが、単なるテキストファイルとは異なり、ARA2はトラックやクリップの編成といったドキュメントモデルと、それらに対する変更のホスト側からの通知のようなイベント機構を前提としています。
これを踏まえて、まずuapmdのプロジェクトモデルを含むuapmd-dataモジュールで、これらを前提としたAPIを整備して、そのイベントモデルを利用してARA2に必要な処理を登録するモジュールとして、uapmdリポジトリから独立したuapmd-araというモジュールを作り出しました（ライセンスはApache V2）。uapmdでロードしたプラグインがARA2に対応していれば、uapmdはARA_SDKが対応しているVST3、AU、CLAPのARA2には対応できていると思われます。「思われます」というのは、現状ARA2に対応しているOSSのプラグインが見当たらなかったので、優先度を下げた…という感じです。
https://github.com/atsushieno/uapmd-ara
AAPの内部機構整備とaap-ara
ARA2サポートはAAPにも影響を及ぼしていますが、これはuapmdよりだいぶ難易度の高いタスクになりました。というのは、既存のデスクトップのプラグインフォーマットとは異なり、AAPはプラグインとホストのインタラクションも基盤レベルから不十分で追加対応が必要だったためです。
AAPは、ホストからプラグインの拡張機能を呼び出す部分は基本的に大部分が出来上がっていましたが、プラグインからホストの拡張機能を呼び出す仕組みはやっつけ仕事の状態でした（当初から双方向性のあるIPCにする前提がありませんでした）。また、どちらの方向も、拡張機構としての「一般化」が十分に機能していませんでした。Binder IPCとMIDI2チャンネルを利用したSysExメッセージングの両輪で拡張機能を呼び出せるようにしていたはずが、多くがBinderでしか動作しないものになっていました。
先月は余裕が無かったので具体的な話は全然書かなかったのですが、AAP v0.11はAAP v0.10以前とは異なるAudioPluginService V3からV4のプロトコルに舵を切り、それまでのAAPとは互換性のないものになりました。一方で、5月までのAAPは、ADC Japanでの発表のために、ある程度安定した実装、特にState APIやPresets APIのIPCを同期的なBinder呼び出しに限定した実装を維持する方向で進めました。そのおかげで(?)、当日はあまり破綻せずに実機デモを遂行できました。
ADC Japanセッションの時点でリリースを出しておくことも出来たのですが、一方でV4に切り替えた上で構築されたAPIは、安定性維持のために移行が未完成で、このままでv0.11をリリースすると、v0.12を出す頃には「間違いなく」またABIを破壊することになってしまいます。そのため、ADC Japanで発表したものは、ある程度安定はしていたものの、そのままリリースすることは避けて、v0.11を出す前にできる変更を施しておこう、という方針にしました。
6月は余裕ができたので、この辺りの問題に取り掛かり直しましたが、修正にかなりの時間を要しました。V3とV4のプロトコルの最大の違いは、同期的なAIDL定義からonewayを付けて非同期処理とコールバックを前提としたAIDLに切り替えたことですが、非同期的に複数のリクエストを呼び出せるデータプロトコルにはなっていないという問題も噴出して（実のところ同期的なBinder IPCが複数発生していたら過去にも死んでいたと思います）、現状ではそれぞれの拡張機能が最大でも1つのリクエストを処理できるのみ、みたいな状態に落ち着いています。
AAPのARA2対応作業は、内部構造を整理して、aap-coreリポジトリの外部から拡張機能を定義・実装するdogfoodingには最適なものだったといえます。これもaap-core本体にARA_SDK依存を追加するのはちょっと違うだろうと思って、別のリポジトリを立てることにしました。
https://github.com/atsushieno/aap-ara
ただ現状このリポジトリではARA_SDKを参照してもおらず、これが実際にARA2開発の役に立つことは全く証明できていないというか、必要なものが足りていないでしょう（ARA_VST3やARACLAPに相当する部分が無いはず）。この辺はAAPに対応してARA2にも対応するホスト…具体的にはuapmd…がデスクトップで実績を出せたら開発を再開する、くらいの優先度です。
aap-clap-hosting-helper
AAPでは、プラグインは数多く提供しているものの、ホストのアプリケーションはそもそもOSSであまりAndroidで動くものがありません。一方でホストになるアプリを作っている人たちからは「AAPホストを開発する時はどうすればいい? JUCEに依存したくないんだけど」「CLAPでホストを作ったら使えるようになってくれたりしないの」みたいなフィードバックがちょいちょいありました。aap-lv2にはホスティングAPIが無いから確かにMITライセンスで済ませたい勢には逃げ道が無かったのは確かです。ただ実際に動かせるものが無いし…と、あまり正面から取り合ってこなかった課題でしたが、まあAIエージェントで開発コストも下がったしやっておくか…ということで、とりあえず「CLAP APIでAAPプラグインを使えるようにする」ヘルパーライブラリを作りました。
https://github.com/atsushieno/aap-clap-hosting-helper
CLAPをVST3やAUにするclap-wrapperとは逆方向です。CLAPにはAndroidで実行するには向いていないさまざまな機能が含まれていますが（↓のように現在進行形で追加されていたり）、AAPが公開する機能をCLAPのAPIにラップする分にはそんなに困らないはずです。CLAPのAPIだと実現が難しいものがあったら、素直にAAPのAPIを使ってもらえば良いと思っています。そもそもuapmdを使えばデスクトップとも共通のAPIで開発ができますし。
https://bsky.app/profile/atsushieno.bsky.social/post/3mokp45hygc2j
どちらかとえばCLAP APIだけで動くサンプルホストを作るほうがコストかかったかもしれません。誰もAndroidで動くものを提供していないので。まあそれがないとdogfoodingにならず、特にGUI統合とかはだいぶ現実感が無くなってしまうので、やりましたが。
aap-integration-tests
AAPは一般的なAndroidアプリとは異なり、複数のリポジトリ上に分散しているさまざまなホストとプラグインが統合して動作する必要があります。プラグインアプリ単体では検査できず、aaphostsampleというaap-coreに含まれるホストだけでは覚束ないところもあります。uapmdというホストも実用的に動作するようになってきたので、GitHub ActionsでビルドされたartifactsをGradle Managed Device（aosp-atd）上にインストールしてプラグインのインスタンス生成・パラメーターとプリセットの取得、ステートの読み書き、uapmd楽曲プロジェクトのロードといった、テストを動かす仕組みを構築しました。
https://github.com/atsushieno/aap-integration-tests
結合テストが必要だ、というissueは2020年にはもう登録してあって、ずっと閉じられることのなかったissueだったのですが、7年の時を経て(!)ついに閉じることができました。今まで出来なかった理由はいろいろありますが、大まかにはこれで説明しているはずです:
https://bsky.app/profile/atsushieno.bsky.social/post/3mov5qjwpe227
有効にテストできていないプラグインもあります。aap-juce-surgeはダウンロードが700MB近くあり、巨大すぎて、ローカルでテストできずにカタログ追加を見合わせています。サードパーティプリセットが巨大すぎて700MB近いapkになっているのが原因で、Play Storeからダウンロードするのもしんどいはずなので、どうにかしたいとは思いますが、基本的に自分は仕組みを作る側を優先したい気持ちがあります。
ADLplug-AE AAP
AAPにはだいぶ初期の頃からOPN（4op FM音源）エミュレーター音源OPNplugの移植が含まれていたのですが、OPNplugはGitHubリポジトリとしてはOPL（3op FM音源）エミュレーターであるADLplugと合わせて開発されたプラグインの双璧のひとつです。aap-juceの1つのリポジトリに2つのプラグインが含まれている状況をハンドリングするのは長らく困難で、Projucerがメインだった時代にはシンプルに不可能、CMakeに移行した後もProjucerの構成を前提としていた頃は不可能、現在でも1つのアプリケーションに2つのaap-juceプラグインを含めるのはJUCE.initialiseJUCE()を複数呼べないので不可能…といった感じで、今月になって何とか実現するまでは棚上げにしていた課題でした。今月ようやくこの辺に手を出す余裕ができたので、やり方を模索して何とか「複数のAndroidアプリケーションモジュールをビルドする」方式で実現しました。
https://github.com/atsushieno/aap-juce-adlplug-ae
なおオリジナルのADLplugはJUCE準拠ではない独自のCMakeプロジェクトなので、当初のAAP移植はProjucerベースであり、現在の移植はいったんCMake化した自分のforkのAAP版です。現在はADLplugで使われているLIBADLMIDI / LIBOPNMIDIの開発者が独自にforkしたものが作られていて、それもCMake化されています（自分のforkより後から出てきたので、今のところ差し替えたりはしていません）。
ちなみに、aap-juce-adlplug-aeと同じ複数アプリ対応のアプローチを、aap-juce-ysfxにも適用して、これも複数インストール出来るようになっていますが、こちらはいずれもちゃんと音が出ないので実用性がありません（要調査）。SurgeもSurge XTとSurge FXがあるのですが、前記の通りSurge-XT単体でもでかいので及び腰です。あと何故か音が出ない系のプラグイン移植としてはZLEqualizerのportもそうで、いずれまとめて要調査という感じです。
aap v0.11.0, aap-lv2 0.6.0, aap-juce 0.8.0 released
以上のような諸々を解決して、月末頃にようやくAAP v0.11.0をリリースできました。7月にはこれを “AAP v1.0 Preview” として各所に公開していくことになると思います。まだドキュメント整備やWebサイトの設営等がいろいろ必要なので、地味な告知に収めている感じです。
ADC Japanの頃から各所で色んな人に動いているところを見せて回っているのですが、やはりDexedとかSurgeみたいな既存のデスクトップシンセがそのままAndroidでDAWみたいなやつ（uapmd）から呼び出して使えるようになっているのはだいぶインパクトが強いようで、好感触を得ていると思っています。
monogatari
このブログのシステムそのものをAstro-Paperベースではてなブログから移転するために、はてなブログのエクスポートデータから過去エントリーを変換して取り込むための仕組みをいろいろClaudeに作らせました。先日ここに書いたとおりです。
https://monogatari.audiopluginlab.com/posts/monogatari-ng/2026/06/20260627/
今や別にmono開発者というわけでもないので（というかもはやそういう歴史を知らない人のほうが多いかもしれない…一応自分の主なキャリアはコレです）、この名前にしておく意味が全く無いのですが、特に新しい名前も思いつかなかったのでそのまま続行です。
7月の予定
8月初頭にまた台湾のCOSCUP 2026でしゃべってくることになっているので、そのための開発とプレゼンテーションの下準備をする予定です。とはいえ、基本的にはuapmdでやっていることのエッセンスを取り出して話すだけなので、そんなに焦るようなことはないと思います。
あとADC Japanの時に、またMusic Tech Meetupを企画してやりたいみたいな話をしていたので、7月中にできると良いかなと思っています。8月になると日本からいなくなってしまうので日本にいるうちに…
あとはここまでいろいろやってきて貯まってきた知見を原稿に吐き出す時間をがっつり取りたいですね。AAP 1.0プレビューの公開作業を進めながら、その辺をやっていこうと思っています。