DroidKaigiが終わって、自分が何らかのロールをもって参加するカンファレンスの類が一通りリセットされたのですが、「DroidKaigiが終わったらやる」予定だった作業がいろいろ襲いかかってきていて、あっぷあっぷしています。まあいつも台湾にいる間にやってたiOSDC 2025が今年は9月だったので遊びに行く、みたいな時間はありましたが。
Android Audio: Beyond Winning On It @ DroidKaigi 2025
予告通りDroidKaigi 2025でセッションやってきました。動画（会期中にもう公開されてた!）、スライド、それと事後公開の解説記事があります:
本当はさらに解説記事の英語版を用意したかったのですが、冒頭のような事情で後回しになっています(!)
セッションについての所感は解説記事にちょこっと書いたのでここで追記することはあまりないのですが、やはり全部解説するためには少なくとも2倍くらいは時間が無いと無理だな、という気持ちになりました。たとえばAndroidのMIDI 2.0サポートの意義がどの辺にあるか、みたいな話は完全に省いていますが、90分あれば5〜10分くらいは「オーディオプラグイン機能の肩代わりが標準的な技術で可能になる」ことに言及できたでしょう（そのためにはオーディオプラグインのAPIにどんなものがあるか、みたいな話もしなければならなくなるのですが、これも今回は言及していません）。
AAPのForeground Service対応
DroidKaigiではほとんどAAP自体の話をしなかったのですが（とはいえ「オーディオプラグインが無い」というトピックに大きく言及すること自体が現状ではほぼAAPの話をしていることになるでしょう）、会場でAAPがどんなものか見せられるようにしておくことは必要だと思って、一番わかりやすい例としてDAW = aap-juce-helioの動作クオリティを向上させる作業に取り掛かりました…が、ここしばらくuapmdとmidicciにかかりっきりだったせいで、アップデート作業がAndroidのメジャーリリースとKotlin 2.2のリリースを跨ぐことになってしまい、そこに時間を食われることに…
ここまではKotlin 2.0.x系列と互換性のあるKotlin 1.8のABIで続けてきたのですが、kotlinx-coroutinesがKotlin 2.1 ABIに移行してしまったのを無視し続けるわけにもいかないので、今回あきらめてABIをアップグレードすることにしました。
それからようやくAAPの作業に着手できたのですが、半年くらいノータッチだった間に自分もC++の書き方やAndroidオーディオでいろいろ学びを得たので、いろいろ書き直したい部分が噴出してきています。とはいえ時間が無かったので、とりあえず「最低限動作するDAW」を目指して、めちゃくちゃ今更感がある話ですが、AAPをForeground Service化させました。そうしないとバックグラウンド処理になって優先度が下がるし、最悪いつの間にか落ちてしまうので…。そういうわけで今AAPプラグインのいくつかは（全てではない）利用中に何をできるわけでもない通知アイコンが出るようになっています。
helio-workstation改めhelio-sequencerもひさびさに更新して、現状では最善のバージョンとして動作しています。このDAWもプラグインのインスタンスの扱いがいまいちよくわからないので(!)、もう少し直感的にトラックごとのプラグインを設定できるようになっているDAWがほしいところですが、Androidで動作するOSSのDAWは他にほとんど無いので如何ともしがたいところです。新しく何か移植できるとして、JUCEホスティング依存になるのも微妙なので、uapmdみたいな独自ホスティング機構に基づくMIDI 2.0シーケンサーがほしいという話もあり…（気の長い話）
本当はこのタイミングでktmidi-ciを使ったMidiDeviceServiceのMIDI-CI対応を済ませようと思っていたのですが、ktmidi-ciのAPIがまだ成熟していないのと、Android Native MIDI APIのアプリケーションでも使えるようにするならmidicci統合で対応すべきかなと思ったこともあって、今回は見送っています。uapmdベースのアプリケーションが動くようになった時に、ネイティブ接続したときだけMIDI-CI前提の機能が使えないのはいただけないので…(!?)
ktmidi 0.11.2
2025年9月は、待ちに待ったJava 25リリースがありました。Javaに思い入れがあるという話では全くなく、Java 25は正式版のPanamaが含まれる初めてのLTSリリースなので、これでlibremidi-javacppを切り捨ててlibremidi-panamaを全面的に採用したktmidi(-jvm-desktop)を使ってくれと言えるようになったわけです。正確にはktmidi 0.11.0の時点でPanamaへの移行は済んでいたのですが、「JDK 22はLTSじゃないからやめてほしいんだけど…」と言われていて、こればかりはJavaリリースを待つしか無い、という状況でした。
Java25になったことで実装が大きく変わることはないのですが（Java 22でAPI自体はstableになっているはずなので）、libremidi-panamaはJava 25で動作させたjextractで生成したソースでビルドされています。
これは少し悩んだのですが、Kotlin 2.1 ABIに移行する必然性は無かったのと、Android専用でユーザーがほぼいないであろうAAPとは異なり、ktmidiはどれくらい古いKotlinが使われているかわからなかったので、とりあえずKotlin 1.8 ABI前提のktmidi 0.11系列の最後のリリースとなるでしょう。
本当はこのタイミングでktmidi-ciのAPIをもう少し使いやすくしたmusicdeviceというサブパッケージのAPIを使って、ktmidi-ci-toolを全面的に書き換えたかったのですが、そこまでの時間は作れませんでした。JUCEのjuce_midi_ciもそうですが、MIDI-CIライブラリはどれもまだまだアプリケーションに統合しやすいAPIにはなっていないので、もう1段階高レベルなAPIが構築されるべきだと思っています。現状どのベンダーも実現できていないです。
uapmd: パラメーターとプリセットの再整理
midicciでProgramListをサポートするためには、まずProgram ListをきちんとサポートできるMIDI 2.0デバイスが必要…というわけで、今月はuapmdのProgramListをきちんと使えるようにするための作業を進めていました。
ちなみにmidicciは現状ではProgramListを要求してデバイスからSysExとしては取得できているものの、それをUIに反映する部分が正しく実装されていない状態です。自分で書いているコードではなくClaude Codeに書かせているプロジェクトなので、Claudeがまともに修正できないうちは、（どうせろくでもないコードが生成されているので）自分では読みたくないので後回しです(!) Sonnet 4.5なら直せるようになっている可能性はあります（今日発表を見たばかり）
uapmdではprogram changeはpresetsに対応する機能ということになっているのですが、そもそもuapmdはプリセット対応機能をろくに実装していなかったので、プラットフォーム中立のAPIを模索するところからスタートしています。大抵のフォーマットではstate APIと連動するのですが、VST3には（MIDI 1.0のProgram Changeも無理やりVST3のAPIで置き換えさせていることもあって）ProgramListという独自のコンセプトもあって、これがパラメーターサポートと連動するものになっています。
VST3のパラメーターサポートを使うところで試行錯誤していて気付いたのですが、VST3以外のパラメーターAPIへのマッピングとそのプラグインでの実際の使われ方もきちんと把握できていなかったので、これを機に整理しました。remidy-plugin-hostというサンプルホストでは、パラメーター設定操作をuapmdの仮想MIDIデバイスが利用するNRPNに置き換えてプラグインインスタンスに処理させていたのですが、これをそのままAUなどに渡しても処理してもらえない（前提が違う）ので、パラメーターAPIを呼ぶかたちに修正…といった、フォーマットごとの対応の確認をやっていました。それでも現状VST3のパラメーターAPIのサポートは機能していない状態で、まだ安心して使えるとは言い難い状態です。この辺は引き続き作業が必要でしょう。
uapmd: native plugin host GUI
それから、プラグインホストremidy-plugin-hostの開発を未成熟なWeb UIの荒野で進めるのはしんどいので、とりあえず各種の問題に目をつぶってImGuiで作り変えることにしました。といってもGUIをゼロから構築するのは面倒なので「既存のWeb UIのソースを見てImGuiに置き換えて」とClaudeにやらせています（それなりに仕事はしてくれたはず）。
ネイティブUIを使うようにしてから、GUIの機能追加は雑にClaudeに投げるようになってしまい、結果的にどっちが原因とは判断しがたいところですが、「GUIをいじるのがめんどくさいから…」という理由で作業が停滞することはなくなったので、これはやってよかったと思っています。
ちなみにImGuiは日本語入力ができないんだよなあ…とbskyでぼやいていたら作者の人から「使えるはず」というreplyが届いて、調べてみたら新しいSDL3バックエンドでは使えるようになっているようでした。ただSDL3は新しすぎてGitHub Actionsのubuntu-24.04 (latest) でも使えないので、i18n-readyになるにはまだ時間がかかりそうです。とはいってもubuntu 26.04が出る頃にある程度完成していればむしろ良いほうかな…?という感じのプロジェクトなので、とりあえずは現状でいきます。もっと高水準のGUIフレームワークに乗り換えるかもしれないですし。ただ、ImGuiを使うことによって、host as pluginとして動かすこともできるようになったはずなので、他に移行したとしても実装は残しておくかもしれません。
10月の予定
10月は差し迫って忙しいわけではないはずですが、M3-2025秋に出展するので新刊を作る作業が発生するでしょう。とはいえ、現時点ではAAP本のバージョンアップくらいで済ませようかなあと考えている程度です。むしろaap-juce-helioやuapmdなど展示できるものを充実させておきたいですね。
