手持ちのUSDを半分売り捨ててだいぶ気持ちがすっきりしたatsushienoです（時候の挨拶）。
AAP 0.9.1 and co.
今月はM3 2025春に出展することもあって、現状で安定的に動かせるAAPをリリースしておく必要がありました（まあそれは自分のお気持ち次第ですが）。今回は先月実用化できたAAP APK Installerがあったので、ここからインストールして挙動を確認できることをマイルストーンとしてパッケージをリリースしています。Android SDK APIのPackageInstallerではインストールするパッケージについてさまざまなチェックが入るので、これを全プラグインパッケージについて確認するのはそれなりの作業になります。AIの雑な仕事が当てにならない領域でもあります。
最初はv0.10.0にするつもりだったのですが、本体の実装の改善はほぼ無く、Kotlin 2.0対応くらいしかしていなくて、ABIへの影響も無いはずなのでv0.9.1と控え目にしました。ABIが破壊的に変更されたKotlin 2.1にアップデートするときにはv0.10.xになるでしょう。
今回のリリースに合わせて、1年前に途中までやっつけたaap-airwindowsも、基本的に動作していそうなところまで進めてリリースに含めてあります。単にパラメーター処理まわりの実装が足りていなくて挙動が怪しかっただけでした。LV2経由でもJUCE経由でもないプラグイン移植は貴重なサンプルケースなので、今後も状況に応じて活用していく予定です。まあ1パッケージに448本もプラグインがあると邪魔なのは多少StandaloneアプリUIに手を加えた今でも変わらないのですが…!
some tech. sessions and lightning talks
今月はちょっと企業内ワークショップで講演依頼を受けていたので、モバイルプラットフォームオーディオフレームワークの開発者向けに、近年のオーディオ開発のトレンドを絡めたAAPみたいなプラグインフレームワーク開発の解説という割とウルトラC級のコンボを決めてきました。その2つ、基本的に交わらないじゃん…!?
わたしはそもそもオーディオ開発のトレンドのポピュラーなところの最先端に波乗りするタイプではないので（たとえばAI技術の話とかはほとんどしない）、去年COSCUPでしゃべってきたときもその肥やしとなる資料をまとめていたときも（1 2 3 4）、その妥当性は常に条件的ではあった（ある）わけです。とはいえ、先日開催されていたJUCE meetup TokyoではJUCEチームのメンバーから次のメジャーバージョンではMIDI 2.0 in AudioProcessorやCLAPサポートが来るという話をしていて、少なくとも「JUCEチームもこの方面ではｱﾂｼｴﾉと同じことを言っている」（この辺の情報自体は年初あたりの予告で既知だけど、わざわざ講演でも言及する）くらいの状況にはなったな、と思っています。
今月はついでにこのスライドの中で軽く言及していたSurfaceControlViewHostの話をmobile dev. meetupで5分でしゃべってきました（当日空いてたから滑り込んだ）。iOSのApp Extensionの代替を実現するにはどうすればいいか、という視点にしただけで、技術的目新しさは無いです。といってもSurfaceControlViewHostなんてここをよく見ている人でもなければほとんど知らないと思いますが。
uapmd
振り返ってみるとどうやら去年の9月あたりからコードを書き始めてはいたらしい独自プラグインホストですが、その目的は10月には書いていた通りで「ソフトウェアMIDI 2.0デバイスを任意のオーディオプラグインで作る」というものでした（この時点ではソース未公開）。VST3、AU、LV2のプラグイン列挙とごく簡単なオーディオ処理とパラメーターのサポートを実現してからは、ほぼWebView UIの実験場となり、その後は多忙になって全然いじる暇がなかったのですが、↑の講演が終わってようやくひと息つけた && 3月にjavacppからpanamaへの移行を済ませられたので、ようやくこっちに戻って来られました。
AAPではなくこっちに戻ってきたのは、M3の展示物として新しいものを出しておきたいという気持ちがあったからですが、そもそもMIDI 2.0仮想デバイスの構想は、ktmidiアプリであるところのkmdspをMIDI 2.0対応の楽曲で演奏できるようにしたい（きちんと動くことを確認したい）という動機によるものでした。MIDI 2.0音源が存在しなければ、MIDI 2.0プレイヤーがあっても試せないわけです。AAPではもう出来ている機能ですが、デスクトップでもMIDI 2.0ツールが開発できるようになってほしいところです。SMF2 Container Formatが完成すれば、標準技術にちょっとした上モノをプロジェクトファイルとしてかぶせるだけで、オーディオプラグイン+DAWに相当する創作環境が実現できる…というのを目指したいところです。オーディオプラグインによるバベルの塔崩壊（現在）の次の世代をこの辺の技術で実現したい…といった展望です。
ともあれ、ひさしぶりすぎてどこから手を付けたものか迷ったのですが、プラグインホストのデバッグがいまいち開発体験の悪いWebView経由のルートしか無くて、進捗が悪化していました。それで、プラグインホストの機能を追求するより、まずはPoCでごくプリミティブなレベルでもいいから、UMPでメッセージを送れる仮想MIDI 2.0デバイスを作れるようにすることが先決だろうと考えて、いったんプラグインホストの現状は放置して仮想デバイスとして動作させる部分に注力しました。
プラグインホスト部分も、とりあえずノートオン・オフと（上手くいくやつは）パラメータ設定までは出来ています。JUCE実装でも動くように作るか…とも思ったのですが、ライブラリとモジュールのパラダイムが違いすぎて、とりあえず思いつかなかったことにしました。このコードはJUCEみたいな異端ではなく各種プロジェクトで使えるまともなライブラリとして構成したいところです。
コードは12月には公開してあったのですが、README.mdの内容も全体的にHTMLコメント化して隠してあったので、全容が把握できるようになったのは今月からという感じです。
まだ実装済みのAPIすらいろいろ動かない機能だらけで、当然プラグインとの相性問題もあり、実用に耐えるプラグインは少ないかもしれません。今週からCLAP対応も追加しているのですが、5月は他のタスクに取り掛からなければならず（もともとM3までの予定だったし）、続きはしばらく先になりそうです。
