8月、ひさりぶりに開発に時間をとれたような気がします。たくさんってほどでもないけど。最近は割と長期戦の前提で新刊(?)を書くのに勤しんでいて、フルタイムで開発はやっていない感じです（これは出せる目処が立ったら改めて書こうと思います）。
Catching up Trends in Audio App Development at COSCUP 2024
先月ひたすら準備で苦しんでいたセッションですが、何とかやってきました。最終的なスライドはこれです。
今回いつもオーディオの話をしている仲間がカンファレンス自体に参加できなくて、こりゃ誰も来ないかな…とか思っていたのですが、現場には15-20人位の人が来てくれてありがたい限りでした。今回トピックを5つに絞ったわけですが、泣く泣くスライドから落としたPipeWireとアプリケーション コンテナまわりでなぜか質問が出てきて、それな、それな…!みたいな感じで答えているうちにタイムアップしてしまい、終わってからも教室（カンファレンス会場は大学）の外で延々と話し込んで、これはセッションやった甲斐があったな〜ってなりました。
KMDSP
ktmidiはもともと半分はC#を書いていた時代に作っていたmanaged-midiをKotlinに持ってきたプロジェクトなわけですが、.NETでやっていたビジュアルプレイヤーのxmdspだけはKMPでGUIをどうするかという問題があって棚上げになっていました。以前にcompose-audio-controlsを作った頃に実験的に作ってあったのですが、ローカルファイルI/Oなどの部分で解が無くてやはり途中で放置していました。最近ktmidiのMIDI 2.0 I/Oをカジュアルに試せるやつがほしい…そういえばKotlin 2.0が出てCompose Multiplatformも落ち着いてきたし、FileKitなんてのも出てきたしwasm版も出せるな…!となって、最低限の再生機能だけ追加して公開しました。
Web MIDI API対応版もあります。GitHub Actionsで毎回ビルドするので常に最新版です。デスクトップ版と比べてあまり遜色なく動いています（ただCompose WasmがノートPCのタップに反応しなくなっているリグレッションが出ていて不便）:
公開してから、パンポットやキーオンメーターを追加していったので、元のxmdspの機能は概ね実現しています。FileSystemWatcherで更新を自動検出して自動再生するモードだけありません（Webでは無理だけど、これもKMPライブラリがあればいけそうな気がする）。
ただ当初の目的だったMIDI 2.0対応まわりは宙ぶらりんで、再生くらいしか実装していません。パラメーターディスプレイヤーが完全にMIDI 1.0の値域を前提にしているので、そこから作り直す必要があります。多分floatにしたほうがいいやつです。MIDI 2.0対応音源も手元に無いので、こっちを先にどうにかしないとな…となっています。時間が無限にほしいところ…
libremidiバインディング (-javacpp, -panama) - 試行中
KMDSPでMIDI 2.0に対応するには、MIDI 2.0に対応するMidiAccess実装が必要ですが、現状MIDI 2.0に対応しているのはAndroidMidiAccess2とNativeのCoreMidiAccessのみです。ALSAバインディング実装はちゃんと機能してくれず、原因はまだわからずじまいです。Compose MultiplatformはJVMなのでこのCoreMidiAccessは使えず、デスクトップでPoCを実現するための環境すらないことになります。
そういうわけで、そろそろlibremidiのバインディングでも作って対応しよう…と思ってまずjavacppバインディングを作ってみたのですが、rtmidiとlibremidiは（rtmidiが由来なのに）どうも文字列のマーシャリングまわりがjavacppのやり方と相性が悪く、const castに失敗してコピーが返ってこないみたいな問題と格闘することになります（issueにするためにreproを作ろうとしているんだけどなかなか期待通りにならない…）。javacppのコード生成のやり方を変えてみようとローカルで試そうとしてみたり、いろいろ試行錯誤で時間を溶かしています（進行形?）。
そんなわけで、メモリ操作まわりで安心して使えないのであれば、より低レベルで操作できるpanamaのほうが良いのではないか…と思ってjextractを使ってpanamaバインディングも作ってみたのですが、こちらはjextract自体がまだ完成度が低くて生成コードもコンパイルできず、手動でコードを書き換えてようやくビルドできる…みたいな感じでした。ただこれはjextractの問題なので大したことはないです。一方でpanamaのほうはjavacppとは異なりそもそもビルドしたライブラリをバンドルできない（そもそもJNAと同じでネイティブライブラリのビルドを要しない）ので、ライブラリを自動的にロードできるようにバンドルする仕組みがない問題にぶち当たり、対応を考えるのがめんどくさい…で止まっています。jextractはどうも問題を報告できる窓口が bugreport.java.com に存在しないらしく、発見した問題も報告できずみたいな状態です。
そんなわけでどっちのバインディングが先に実現するか、まだ見えないところです。
あとMIDI 2.0対応デバイスが無い問題がここでも関わってきて、まずはMIDI 2.0仮想デバイスになるアプリケーションをでっち上げないと駄目かなあ、となりつつあります。
AAP: AAudioの使い方の調整
最近裏稼業でAOSPのオーディオシステムの調べ物をいろいろやっていた関係で、AAPで適当に使っていたAAudio（API的にはOboe）のオーディオI/Oについて、以前よりだいぶまともに使えるようになってきました。そういうわけで、AAPの特に規範的アプリケーションにもなっているモジュール (androidaudioplugin-manager) やMidiDeviceService実装 (androidaudioplugin-midi-device-service) を見直して、まずはLow LatencyストリームでExclusiveモードを使うのを止めました。Sharedストリームでも十分なパフォーマンスが出るはずだし、Exclusiveを使ったところでBinderが/usr/binderのドメインでmutex lockをかけてしまう現状では意味がないでしょう。
Androidオーディオシステムについてはここ数ヶ月でだいぶ詳しくなった…何なら大抵の中華系の情報源より詳しくなったと思うので（これは分かる人にしか分からない言い方かもしれないけど、要するにだいぶ自負がある）、次の技術書典あたりを目処に何か書いて出したい気持ちがちょっとあります。ただM3秋にサークル参加申し込みし損ねてしまったので（6月が忙しすぎて忘れてた）、やる気ゲージが貯まるかと作業時間が取れるかどうか次第です。
書き物
今月は2つくらい書いてました:
後者はたまに「MTS-ESPが多数に使われるようになったらAndroidでも使えるようにする必要があるな…作っておくか…?」みたいに思うことがちょいちょいあって（主にsurgeのコードを読んだりいじったりしているとき）、一度まともに調べておこうと思ってがっつり時間をとって、やっぱりこれは無いか…となった時の備忘録でした。時間が無限にあればこっち方面でも新しいものを作りたいところですが、自分がまず微分音作曲やらないしな…という感じで優先度が高くないです。
