M3 2022秋の出展
10/30のM3 2022秋 (50回目だったらしい）に「オーディオプラグイン研究所」として出展参加しました。技術書典13で発行した「CLAPオーディオプラグイン開発ガイド」に加筆修正を加えた「正式版」の印刷版・電子版と、「Linux DTMガイドブック」の電子版が新刊ということになります。前者はboothで取扱開始しました。技術書典のときに「紙版がほしかった」という方はこちらからどうぞ。本当は無償配布にしたいところですが、印刷代だけでも「売れば売るほど赤字になる」設定なので、ひとつよしなに…
Linux DTMガイドブックも同様に「完成版」を発行したかったのですが（たとえば、サンプラーなど「器」だけ言及していて楽器サンプルへの言及がゼロなのを何とかしたい）、時間的に厳しくあきらめました。M3では新刊の頒布に合わせてAndroidプラグインの展示も行う計画で開発を進めていて、そこまで手が回らなかったためです。（Androidプラグインの展示に合わせて最新版を安定させる計画は間に合わず、少し古いバージョンにしたのですが…!）
このLinux DTM本と既刊の「MIDI 2.0エコシステム構築術」「MML to MIDI 2.0 to DAW」も含め、展示では幻の「印刷版」を見本として用意しましたが、これらの印刷版はありません。デジタル版でお求めください。（この2冊は割と「自由研究をまとめてみた」性格の本で、現状ではそれなりに時代とともに価値が薄れていく過渡的な内容だと思っています。）
DroidKaigi2022（遊びに行っただけ）
10月上旬にはDroidKaigi2022もありましたね。今回はトーク応募すらしなかったので、単純に東京ドームシティまで遊びに行きました。開催地が遠くなってしまったこともあって、宗教上の理由で午後からの参加のみでしたが、いつものDroidKaigiのふいんきがだいぶ戻ってきていて（ランチとかコーヒーとか夜のパーティが戻ってくるのはまだ無理そう）、開催してくれてありがたい〜という感じでした。年単位で会っていなかった知人のみなさんとも久々に顔合わせできたし、新しく開発者のみなさんとも知り合いになれました。
「Gradle Managed Virtual Devicesで変化するエミュレータ活用術」の外山さんに「GitHub ActionsのLinuxホストで使えるようになってほしい（KVMのnested virtualizationをサポートしてほしい）んだよ〜」とか詮無きことを言ったり、「Jetpack Composeを用いて、Canvasを直接触るようなコンポーネントを作成する方法」を見て自分がComposeで作っていたWaveform描画コードを直したり、「Android "を" ビルドしてAndroid Systemを覗いてみよう]」みたいなそこそこ低レイヤーのセッションが聞けるのうれしい〜とか言いながらAOSPアプリのビルドに手を加えるのを眺めたり、「Considerate App Update Delivery」で相変わらず多種多様な他人のアプリをビルドしないといけない仕事やべえ知見がたまりそう〜とか思いながら眺めたり、「人の声を可視化する」でオーディオAPIの話したい〜と思ってask the speakersでお話ししてみたらここの読者の方だと判明したり（そんなことあるんだ…!ってなりました）、「Android アプリの内と外をつなぐ UI」を見ながら自分のアプリのonBackPressed()をonBackPressedDispatcherで書き換えたり、あと他の人と雑談していて気がついたらセッションを見逃したり()みたいないつもの体験を楽しみました。
全部かはわからないけどYouTubeでセッション動画も公開されているようなので、裏番組とかで見られなかったやつを少しずつ追っかけようと思います（昨日まではさすがにそんな余裕なかった）。
ktmidi 0.4.0
今月は先月から続いていたktmidiの実装を直す作業がひと段落して、新しくバージョン0.4.0を公開しました。
Kotlin Native環境用にRtMidiのcinteropバインディングを作って、RtMidiNativeAccessという実装を追加して（JNAを使ったKotlin/JVM用バインディングもあることを考えるとだいぶ二度手間感…）、Midi2Playerをネイティブでも意味あるものにしたという変更が大きいですが、UMPベースの楽曲データのフォーマットやAPIに破壊的変更を加えたからバージョンを0.1上げたというのが建前上の理由です。
楽曲データの問題はlong-standing issueで、元々トラックヘッダーにUMPの件数を指定していたのですが、これでは読み飛ばしができないのでバイト数に変更したものです。楽曲のMETAイベント…に対応するSysex8データ…も間違っていて、テンポ指定が適切に反映できなかった問題があり、今回新たに追加したUMP to MIDI1 translatorの実装と合わせて、ようやくMIDI 1.0と同等のMidi2Playerの動作がreal-worldなやつとして確認できました。mugene-ngもこれを反映しているので、MMLからMIDI 2.0楽曲を引き続き生成できます。
この過程でAPIドキュメントジェネレーターのdokkaがビルドエラーを引き起こす問題にしばらく悩まされて、結局Kotlin Slackで開発者にいろいろ助けてもらって何とかしました。自分の中でdokkaの評価がだいぶうなぎのぼりに上がりました(!?)
AAP: プロトコル変更"V2"の再設計
8月にオーディオプラグインのパラメーター変更にMIDI 2.0 UMPを使ってプロトコルを再設計する話を書いたのですが、その手助けとなるはずだった上記のMidi2Playerをプラグイン試用のアプリに組み込もうとしたものの、ネイティブコード側の実装には使えず、デバッグに使うにも微妙なので、そっちの路線は一旦留め置いて、まずmidi2プロトコルで従来どおりの固定のメッセージを処理できるPoCを（今度はUMPで）作って、それをaap-lv2やaap-juceに適用していこうと考えました。
それで、最初は従来の「midi1ポートもmidi2ポートもサポートする」方向で実装を練っていたのですが、早晩「これは開発体験が悪い」と気づきました。これまではむしろ「MIDI2ポートはいらない。UMPをサポートしたければ、MIDI1ポートでMIDI-CIのSet New Protocolを送って切り替えればよい」と考えていたのですが、プラグイン開発者が「どっちで来るかわからないから両方サポートする」ことになるのは理不尽ですし、「MIDI2を処理できるプラグインは現状ほぼ無い」にしても、「パラメーター変更はMIDI2でしか受け付けられない」、「パラメーター変更をサポートしないプラグインはほぼ無い」、「MIDI2をMIDI1に（可能な範囲で）変換するのは難しくない」…という状況を鑑みて、むしろ「MIDI2ポートのみ存在すれば良い」という考えに至りました（ここまでで何日かかかった）。
これは相互運用性の観点ではドラスティックな変更になる（完全に別物になる）ので、AAPのプロトコルのバージョンを上げて対応すべきところですが、現行バージョン0.7.4までで "V2" として作り直しが進んでいるので、そのままV2プロトコルがこの設計を反映したものになるでしょう。
一方でAndroidAudioPluginMidiDeviceServiceがUMPを前提にするわけにはいかないので、MidiDeviceServiceからの入力を8月に実装したUMP Translatorを使ってUMPに変換し、逆にプラグイン実装側ではUMPからMIDI1にダウンコンバートするTranslatorの真面目な実装を新たに作って使ったり、プラグインプレビューのアプリではパラメーター変更入力をポートへの直接入力から新しいUMPのAssignable Controllersメッセージに変更したり（これでようやくCLAPやAtom Sequenceのような新しいイベント処理のスキームに切り替えられたといえます）、同じダウンコンバーターをaap-lv2の実装にも適用したり…といったことをやっていました。実のところまだ完了しておらず、LV2 portとAAP portのマッピングどうしよう…みたいなところで現在でも泥沼にハマっています。先にaap-juceで対応したほうが早かったかも…
11月の予定
11月は正直まだどうするか決めていません。「どうする」というのは具体的には例年11月にロンドンでやっているアレです…多分オンライン参加で妥協すると思います。去年より自由になったとはいえ、まだ一生後遺症が残り得るLong-Covidの問題が続いていることに変わりはなく、現地で自己アッピール()に使えるようなソフトウェアはまだ完成していない状態なので、今行くと「オーディオクラスタにしては妙にAndroid開発に詳しいやつ」というビミョい位置付けで固まってしまう気がします（正しいのですが）。まあ何か理由があれば現地参加する可能性もあります。
あと11月のうちに1回オンライン勉強会をやっておきたいですね。ネタはあるといえばあるのですが、状況次第です。何か準備できたら改めてTwitter（いつまで使うかわからないけど）などで告知します。
