明後日のDroidKnightsの登壇準備というかソフトウェアセットアップの保全をいろいろやっていて、これを書く時間はそんなに取れませんでした。
AAP 0.12.0 and co.
dynamic manifest
今月はAAPに大幅な改善が加えられました。プラグインからパラメーターリストの再構成を通知できるようになり、ホストがその通知を受け取って動的なパラメーターリストの再構成ができるようになりました。プラグインラッパーの類が、ロードしたプラグインによってパラメーターリストを刷新できるようになり、ギターアンプモデルの類でロードしたモデルに応じてパラメーターリストを構成できるようになりました。BYOD AAPでプリセットを選択すると、パラメーターリストの内容がが変わります。
これを実現するにあたっては、AAPXS（拡張機能呼び出し）の同期・非同期メッセージングが整備され、プラグインからのコールバックがきちんと機能するようになったという技術的背景があります。
buses extension
動的なパラメーターリストが実装できたので、動的なポート構成も実現可能になったはず…と考えて、関連APIを設計することにしました。AAPには以前から存在だけしていてまともに実装されていなかったport-configというAPIがあったのですが、仕切り直して buses extension として作り直すことになりました。動的なバス構成もサポートしました。
多少気に入らないAPIになった側面もあって、少なくともあと1度はAPIが変更されるのですが（ABIの変更はまだ無い予定）、とりあえず機能的にはこれでAAPは概ねfeature completeに近いレベルに至ったと思っています。feature completeがこの時点で見えてくるとは思っていなかったのですが、AAPも十分に成熟してきたといえるでしょう。
soundpack-provider-for-android
先月aap-lv2-sfizzとaap-juce-usf2pluginでそれぞれカスタムSFZ/SF2ファイルを利用できるように改良を加えましたが、この辺の仕組みはざっくり共通化できるものです（実際、aap-juce-usf2pluginの実装時には、aap-lv2-sfizzの実装を参照して実装するようClaude Codeに指示して作らせたので、「共通化モジュールを作るか?」と訊き返されるレベルでした）。
もうひとつの応用例として、aaphostsampleには、1つしか無いoggファイルへのエフェクトの適用だけでなく、任意のオーディオファイルを選択可能にしたいというissueが昔から登録されています。任意のファイルを選択するUIを用意するのはさすがに無駄ですし、プラグインの数だけ同じファイルの登録が必要になるのは煩雑なので、これも特定のProviderから提供されるものをselector1つで選択するだけにしたいところです。
この機能は、突き詰めて考えると、単に所定の用途（この場合は「AAP用のサンプル音声」）に対応するwav / ogg / mp3等の音声ファイルをリクエストしているだけなので、これはもはやサンプルパックのプロバイダーとやっていることが変わらない、ということになります。それであれば、SFZやSF2も合わせて、用途に合わせてローカルストレージあるいはユーザーが登録したフォルダからサンプルファイルのカタログを構築してクライアントに返す、汎用的なサウンドパックのプロバイダー アプリケーションが有用、ということになりそうです。
そういうわけで、これらを1つにまとめたAndroidアプリケーションを1つ作りました:
https://github.com/atsushieno/soundpack-provider-for-android/
https://bsky.app/profile/atsushieno.bsky.social/post/3myzh6l4vdc2a
まだREADMEがAI slopなので広く共有できるレベルではないのですが、これを使えばSFZやSF2などのサウンドリソースを一元管理できます。aap-sfz-vpo3やaap-sfz-salamander-drumkitのように、一元管理せずに個別のAPKから取り込む方法も引き続き有効なアプローチです。このアプリである必要はありませんが、リソースの提供方法が統一的なProviderなので、複数のやり方を調べなくても済むという利点があります。
aap-coreのCompose Activityに統合した実装もsoundpack-providerというブランチで作ってあるのですが、依存ライブラリをMaven Centralに発行しないままに参照を追加するのはちとアレなのでmainブランチにはマージできていません。
aap-cmajor
CmajorはAAPでプラグインとして動かしてみたかったけど実現していなかった候補だったのですが、今月改めてチャレンジしたら今回は動くようになりました。動かなかった理由は主に2つあって、1つはJITエンジンがAndroid上でコード生成に失敗していたことでしたが、これはどうやらarm64環境でx64実装が間違って組み込まれていたせいでした。もう1つはchoc WebViewがAndroid実装を持っていなかったことで、これは仕組みとしては難しくはないはずなのでClaude Code（確か。Codexだったかも）に実装させました。半年前にこれらに調べさせた時はどちらも失敗だったので、コーディングAIエージェントの進化によって（人間が調査に時間をかけなくても）対処可能になったといえます。
このサンプルスクショだとPro-54サンプル限定みたいになっていますが、実際にはCmajorリポジトリに含まれているサンプルをひと通り拾って選べるようにしていて、InstrumentとEffectも追加しています。
aap-juce: big simplification
今月はついにaap-juceの完全なsimplificationに着手しました。一番シンプルになったaap-juce-altarのパッチを見ると、たったこれだけでオリジナルソースツリーのAAP対応が完了しています:
diff --git a/CMakeLists.txt b/CMakeLists.txt
index d2c8913..cf5cea6 100644
--- a/CMakeLists.txt
+++ b/CMakeLists.txt
@@ -1,5 +1,10 @@
cmake_minimum_required(VERSION 3.22)
+get_filename_component(app_source "${CMAKE_CURRENT_LIST_DIR}" REALPATH)
+add_subdirectory("${app_source}/../aap-juce" "${CMAKE_CURRENT_BINARY_DIR}/aap-juce" EXCLUDE_FROM_ALL)
+aap_juce_configure(JUCE_SOURCE_DIR ../JUCE ICON Source/UI/Images/icon.png ADOPT_EXISTING_PATCHES)
+
+
if(APPLE)
set(CMAKE_OSX_DEPLOYMENT_TARGET "11.0" CACHE STRING "Minimum macOS deployment version" FORCE)
endif()
@@ -118,3 +123,5 @@ if(MSVC)
target_link_options(Altar_VST3 PRIVATE /INCREMENTAL:NO)
target_link_options(Altar_Standalone PRIVATE /INCREMENTAL:NO)
endif()
+
+aap_juce_plugin(TARGET Altar)必要なのはaap_juce_configure()とaap_juce_plugin()だけです。正直ここまで単純化出来るとは思いませんでした。パッチセットは利用するJUCEのバージョンから自動的に推測します。それで足りない場合は今まで通りに指定できます。ホスト側もaap_juce_host()だけでいけるようになっています。
aap-juce-womb
soundpack-provider-for-androidを作ってから、そもそも世にあるサウンドパックの管理アプリってどうなっているんだろうと思ってGitHubで探してみて、それっぽいJUCEプラグインを発掘したので、ちょっとデスクトップで使ってみて、機能的には悪くないという印象を受けました。GUIが巨大なのがモバイル向けではないですが、とりあえずAAP化してみています。
https://github.com/atsushieno/aap-juce-owmb
https://bsky.app/profile/atsushieno.bsky.social/post/3myzifghcek2a
これでダウンロードフォルダをsoundpack-provider-for-androidでもロードできるところに指定してみたところ、無事自分のアプリの側でもサンプルファイルを共有できるようでした。
aap-ara now based on real ARA_API
aap-araの開発はだいぶAI slopで進めていて、ドキュメントモデルの更新さえできていれば問題ないだろうと思っていのですが、実際にuapmdのARAサポートにaap-araを合わせてみようとして、「そういえば何でaap-araはARA_SDKを参照していないんだ…?」となって、まともにARAのAPIを実装しているのではなく「ARA相当のAPI」を勝手にでっち上げて実装しているだけだこいつ…!と気付いて、きちんとARA_APIを実装させるように、根本的に直しました。
今のサンプルアプリケーションはARA_SDKから引っ張ってきています。もっともARA_Examplesに含まれる機能…に相当するもの…はとっくに実装されていたようなので、結局のところサンプルアプリケーションはこれまで通りのものを使っています。
uapmd improvements
今月はあらゆる方面でAAPの作業を進めるプレッシャーだけがかかっていたので、uapmdの更新は少な目です。
JSFX wasm compiler
uapmdのJSFX統合は、ysfxの実装を使いまわしているのですが、このwasm実装が実はめちゃくちゃ遅いということに気が付いて、直すことになりました。根本的な原因は、そもそもysfxのeel2のエンジンがwasm未対応だったから、ということになるのですが、オーディオスレッド上で実行されるコードだけJITコンパイル出来るようにして（それ以外もやると大変だとClaude Codeに言われて引き下がりました）、wasm上でも無難なパフォーマンスが出せるようになりました。
track properties: color, path, order
uapmdをデモで見せる時に、同じ配色のトラックが30本近く続いたりするのは視認性が悪いので、重い腰を上げてtrack colorを付けられるようにしました。あとトラックのグループ化と並び順の変更を実現するために、pathとorderというプロパティを用意しました。基本的にはpathはプラグインパラメーターのpathと同じで、グループ化の役に立ちつつ、並び順も揃えられるという役割を持っています。ただ同じpathに複数のトラックが来ることがあるので、orderも付けるようにしました。
自分が既存の曲を取り込む時は木管、金管、打、弦で色分けするようになったので、わかりやすくなりました。
Audio Plugins For Androidの設計と実装 第2版 @ M3 2026
M3と技術書典向けの新刊としてAAP本の改訂版をリリースしました。また、それにかこつけてそもそもAAPとは何なのか、なぜこれが必要なのかといった記事を公開しました。
https://zenn.dev/atsushieno/articles/5b956734858766
↑の記事にも多少書いたのですが、2023年の初版発行時にはできなかったことが現在ではほぼ全てできるようになりました。今月のAAPの成果としてfeature completeが見えたという話とも繋がっています。今回は特にGUIサポートまわりは、Web UI路線からnative UI路線に移行したり、拡張機能がBinderとAAPXS SysEx8 (MIDI2) と双方向メッセージング、ホスト拡張機能も含めて実現している辺りが新しいといえます。また多数のプラグインの紹介もGUI込みで追加できたので、実物が動いている感が高まったと思います。
本当はUAPMD関係でも1册書きたかったのですが、2册書いている暇はさすがにありませんでした。
Music Tech Meetup Tokyo 2026.10
前回書いたのですが、「C++でつくる」の刊行に合わせて、音楽技術勉強会を開催しました。今回もCRI社さまにはお世話になりっぱなしでした。
https://music-tech.connpass.com/event/408908/
前回すぐ埋まってしまったので今回はそんなに宣伝していなかった(?)のですが、今度は当日が近づくまで全然埋まってこなくて、両極端すぎる…と思っていたのですが、当日になってみるとLT3枠は埋まり、さらにゲリラLT(!?)まで行われて、今回も刺激的な内容のものが多くて、満足度の高い内容になったのではないかと思います。
来月の予定
先月書いた通り、DroidKnightsで登壇した後、ADC Bristolに参加してきます（これだけで11月は半分くらい終わる感じですね…）。DroidKnightsが終わるまで先送りにしているAAPのタスクが割とあるのですが、ADCまでにやっておきたいこともあって、何が出てくるかは未知数です。