11月、いつも31日まであると思ってしまうのですが、これは一生治らないのかもしれん…
aap-core 0.8.0, almost there
2ヶ月以上前から取り掛かっていたAAP拡張機能の再編成ですが、今月初頭にようやくひと段落して、ABIに影響するAPIの変更はほぼ発生しなくなってきたので、バージョンを新たに0.8.0とする準備ができました。これに合わせて、AAP拡張機能のバージョンも全て v3 に統一されています。
（まだ最終リリースを出していないのは、Android Gradle PluginがAAPのAARをimplementation project("...")ではなくMavenLocalからパッケージとして解決したとき「だけ」各種の不具合が発生するという問題を解決してから、各種プラグイン移植のコードに影響を及ぼさずにリリースしたいという思いがあるためなのですが、これはAGPの深淵を掘り下げないと直せない気がするので、たぶん早々に諦めて現状でリリースすると思います。すでにaap-lv2プラグインはほぼ全てこのバグに対処済です。aap-juceプラグインは…特にProjucerベースのやつを直したくない…）
先月リストアップしたAAP拡張機能（とAAPXS = AAP拡張機能サービス機構）の課題はこんな感じでした:
- 拡張機能APIが同期メソッド前提なので、非同期前提にする
- リアルタイム処理時に文字列比較しなくてすむようにURIDを導入する
- プラグインコードもホストコードも直接認識していないような拡張機能操作のメッセージをやり取りする仕組み（AAPXS untyped runtime）
- Kotlinからの拡張機能のuntypedな呼び出し
- 動的にロード可能なAAPXS
- ホスト拡張機能
- 独立性の高いAAPXS実装用ヘルパーAPI
このうちまだ実現していないのはKotlinからの呼び出しのみです。まあ現状「呼び出せる可能性」さえあれば十分かなと思っています。
まだ拡張機能APIの非同期化がホストアプリケーション（androidaudioplugin-manager）のレベルまで浸透しているわけではないのですが（JNI越しに非同期呼び出しを実現するのはやや面倒）、リアルタイムAAPXSで拡張機能の呼び出し時にロック機構を導入せざるを得なくなってからaap-juce-byodでプリセット一覧の取得に何秒もかかっていたのが、v0.8.0ではミリ秒単位で完了するようになっています。
気が向いたらARA2サポートとか実装してみたいところですが、さすがに時間がかかりそうな気がします（APIそのものをあまり把握していない）。ARACLAP.hと同程度のことができればいいのであれば、もしかしたらすぐできるのかも…?
alsakt 0.3.3
先月ALSA 1.2.10対応として0.2.0を出したばかりのalsaktですが、JavaCPP力でライブラリをバンドルする方法を調べて、JavaCPPランタイムが自動的にjarから展開してロードできるようになりました。ローカルにインストールされているlibasound.soが1.2.10でなくても、Linux kernelが6.5以降であればUMPエンドポイントを構築できるようです。
ktmidi最新版（未リリース）のktmidi-jvm-desktopモジュールにはAlsaMidiAccessというクラスがありますが、このvirtual portを作るときにPortCreatorContext.midiProtocolを1にするとMIDI 1.0 UMPで、2にするとMIDI 2.0 UMPで、ALSA sequencerのポートが作成されます。
作成されたUMPポートではMIDI 1.0バイトストリームではなくUMPストリームを受け取れるようになっていると思うのですが、まだatsushieno/kmmkに手を加えたものしか手持ちのUMPアプリがなく、十分に試せていない状態です。
ktmidiのMIDI-CIアップデート
Twitterを見ないので最近まですっかり忘れていたのですが、12月はAdvent Calendarの季節…ということで、JUCE Advent Calendar 2023に参加します。実のところ今年はほとんどJUCEでコードを書いていないのでネタが無い…と思っていたのですが、最近そういえばMIDI-CIサポートが追加されたとJUCE開発者から聞いて眺めていたので、つい先日7.0.9で正式リリースもされたし、これがちょうどいいだろうと思って書くことにしました。
それで、その実験をやるためにはMIDI-CIの実装が必要だな?となって、ちょうどalsaktでUMP対応もしたしMIDI 2.0まわりの実験には向いているのではないかと思って、ktmidiに1年前に仕込んでいたMIDI-CIサポートを活用してみることにしました。当然ながら2023年6月アップデートには未対応だったので、そこから着手しています。一応繋がってパケットのやり取りは一部できていたようですが、まだ安定的に相互運用できる状態になっていない状態です。まあ詳しくはAdvent Calendar当日の記事を見てもらえればと思います（記事は作成済）。
ADC23（オフライン参加）
4年ぶりにaudio developers conferenceに現地参加してきました。10月の5回目ワクチンが効いたのか、混雑しているカンファレンスからも無傷で帰還しました（ロンドンの感染状況も悪くないですし）。
ADCオンラインでのコネクションは、正直3年間で全く増えなかったので、初めてリアルで会った知人はほとんどがTAP Discord等での繋がりだったと思います。旧知の知人も割と戻ってきているようでしたが、まだまだ回復しきっていない様子でした。まあ4年も開いたらその間に業界が変わった人もいるだろうし(?)
今年参加して気づいたのは、以前なら日本の楽器メーカー（Roland/YAMAHA/KORGあたり）から人が来ていたのですが、流石にまだ戻ってきていない感じでした。今年はDreamtonicsがSynthesizer Vの展示を出していたので、日本人参加者の大半はその方面だったと思います（SynthV関連のセッションもありました）。
自分の関連技術方面では、CLAPの開発者が来ていたので前日からいろいろ話を聞いたり（自分もプラグインフォーマットを作ってるんだ、みたいな話もしたり）、ask the JUCE teamでいろいろ相談したりはしましたが、主に他の分野の話を聞いてきた感じにはなりました。またADCの動画が公開されてきたらいろいろ話せるかもしれません。
12月の予定
AAP 0.8.0リリースがひとつ完了予定のタスクですね。多分その後にGradle/AGPまわりを調査することになって、コードの追加は控えめになると予想されます。
ktmidiのMIDI-CIサポートは、もう少し時間をかけて使い物になるようにするか、他の作業を進めるか（↑のGradle/AGPまわりの調査もかなり気合が必要）、迷っているところです。MIDI-CIそのものは、特にMIDI-CIからProtocol Negotiationが消えた今、自分のコードではほぼ不要になったので、優先度は低いです。とはいえ一般的なMIDI 2.0アプリケーションを書くには必須の技術とはいえそうです（だからこそJUCEでも内部的なMIDI 2.0サポートに先駆けて実装しているわけで）。まあ12月の方向性はそんな感じです。
