4月は終わっただなんて、またまたそんな嘘を…（時候の挨拶）
4月は（予告通り）あんまし開発に時間を割いていない感じで、AAPの宣伝活動強化月間みたいになっていました。リリース作業も行っていたので、生産期から収穫期に移ったような感じです。
「(AAP) の設計と実装」の執筆
予定通り、昨日のうちに（ギリギリでしたが）boothで販売を始めました。
来月は技術書典14があるので、それまでにもしかしたらアップデートがあるかもしれません。無いかもしれません。実は技術書典オンラインのほうはCLAP本もアップデートが半年弱くらい反映されない状態なので（イベントが終わった途端全くレビューしないフェーズに入るとは思ってなかった）、AAP本も今後は同じように著者から自由にアップデートできない可能性が高いです。そういうわけで、基本はアップデートの体制が整っているboothでの購入をおすすめします。技術書典オンラインにそれを期待するのは無理かなと。
AAPの設計と実装の執筆作業は、設計に関する思索を巡らせる契機になることも多く、今月は特に「AAPは仕組みとしてはAUv3に近づけてもいい気がする」とか「AAPの仕組みをAPIから独立させて実装アプローチとしても規定したいが、具体的に何が考えられるか」とか（関連issue）、「拡張APIとして規定するとして、実質的に『必須』の拡張があるならそれは任意とは言えないので、明確に準拠プロファイルとして規定すべき」、みたいなことを考えました。
執筆したことの半分くらいは前提知識を埋めるためのものだったのですが、残りの部分は設計の取捨選択とか設計の理由とかに関するもので、これは公式ドキュメント…とはならないまでも公式参考資料として、英訳して使い回したいと思っています。LV2 Bookが近いコンセプトでしょうか。AAPの宣伝本なんだから無償でいいんじゃないの、等も考えましたが、内容的には公式ドキュメントに載せるべき情報とは異質な技術読み物としての側面が強いので、今のところは普通に(?)趣味の技術書として読まれてほしいです。
AAP 0.7.6 Released
本当は5月でいいかなとか、GUIサポートの問題がいろいろ修正されてからでもいいと思っていたのですが、2月初頭にリリースしてから2ヶ月以上経って、これ以上変更を溜め込んだら周辺プロジェクトが追従するときに追いきれなくなると思って、早目にやっておくことにしました。
リリースノートはここにまとめてあるのですが、今回もずいぶん更新が多かったです。
前回0.7.5の時に「これはずいぶんでかいリリースになったな」と思いましたが、0.7.6もそれと同程度以上のインパクトがあったと思います。個人的には、AAPのクオリティ面での修正が多く含まれていて、long-standing issueも多く閉じることが出来て、いい傾向だったと思います。クオリティというのは、実装の安定度もそうですが、仕様も着実にブラッシュアップされています。（今までが雑だっただけかもしれませんが…!）
aap-juce improvements
最近のaap-juceのホスティングまわりの改善は効果が著しく、最近はhelio-workstationの移植の上で初回起動時に出てくるサンプル楽曲のInstrumentを全部mda-lv2のプラグインで置き換えてもちゃんと再生できるレベルまで来ています。これは先月書いたJUCE_DONT_AUTO_OPEN_MIDI_DEVICES_ON_MOBILEに加え、「JUCE on AndroidアプリがデフォルトでOboeを使うようになっていない問題」と、次のJUCEのリリースには含まれているであろう「Oboeオーディオループで毎回calloc()が呼ばれている問題」のバグフィックスを個別パッチとして取り込んだためです。
「JUCEでもそんなレベルのバグがあるんだ」って思われるかもしれませんが、やっぱりリアルタイムオーディオ処理って簡単ではないし、フレームワーク開発者はアプリケーションのレベルまでdogfoodingする機会がなかなか無いのと、Androidサポートの優先度が高いプロジェクトではなさそうなこともあって、ユーザー（この場合は開発者）が発見する機会が少なからずあると思います。JUCEチームは小さくてAndroidの問題にきちんと取り組める程度までスケールしないので、この状況を打破するにはJUCEと戦える競争相手が必要そうな気がします。といっても商用製品としてのJUCEは適切な価格設定だと思うので（v5くらいの頃なら「価格の割に価値が大きい」くらいは書いていたと思う）、収益のために競争相手を作るよりは、「プラットフォームネイティブでいいものを作る」みたいな「競争」のほうが現実的かなと思います。
rtmidi-jnaのFFIをどうにかしたい問題に取り組む（進行形?）
NAMM 2023のタイミングに合わせてMIDI 2.0のバージョンアップが出ると見込んでいたのが5月以降までずれ込んで（見込みが妥当だったかは別としてNAMMのMIDI2関連セッションでもそれくらいと言及されています）、それだったらktmidiというかkmmkをもうちょっとブラッシュアップしてPer-Note pitchbendくらい扱えるようにしておきたいなあとか思っています。
ただ、現状でktmidiがrtmidi-jnaで利用しているJNAeratorでブロックされている側面が割とあって（たとえばSiliconで動作させるのに必要なネイティブビルドが無かったり）、さすがにFFI機構でJNAeratorに依存している部分を置き換えたいなあと思っています。手軽に対応するならJavaCPPあたりが正解だと思いますが（ただ過去に一度失敗していて理由を思い出せない）、最近はPanamaもだいぶ使えるようになってきているようだしなあ…と思って、いろいろ調べたりしている感じです。
Panamaは割と面白いですね。BridJをいじってた頃、あるいはそれ以前に自分でdyncallなどを使ってJNAの代替を作ろうとしていた頃を思い出します。Panamaは、libffiでのfallback実装（があります）を越えてやっている部分はBridJに近そうだし（BridJはdyncallを使っていたけどPanamaはJavaでmanaged solution的に実装している）、そこにMemorySegmentとMemoryLayoutのコンセプトを持ち込んでBridJが扱えなかったstruct return by valueの問題にも対応できています。array return by valueだけまだ怪しそう。JNRもその辺はBridJより新規性に乏しい設計でした。この辺の話は、（Mastodonにも書きましたが）JVM language summit '19のセッション動画が参考になります。
まあrtmidiバインディングをJNAからPanamaにしてしまうとKotlin/JVMでの動作要件が厳しくなりすぎてしまうので、そうはならないような選択肢に落ち着くと思います。JavaCPPにするか、バインディングを生成済みのやつに切り替えるか…
5月の予定
そんなわけで、AAPの作業よりktmidiの作業をメインにしている可能性がそれなりにあります。5月は技術書典14もあるので、そっち方面で原稿を書いてるかもしれませんし、MIDI2のアップデートも出てくるかもしれないし、Google I/Oで何か出てくるかもしれないし、思いのほかAAPに「戻ってくる」まで時間がかかるかもしれません。
