6月は雨が多くて好きじゃないという人も少なくありませんが、わたしは好きじゃないですね（時候の挨拶）。
AAPのPrefabパッケージ化とlibcxx-provider
AAPの開発がAndroid Studioのデバッグ実行まわりの不安定さに引っ張られてスムーズに進まないので、今月は少し周辺的なタスクを片付けていました。その過程で、本来やるつもりではなかったAARのPrefab化が完了しました。Prefabパッケージ、当初は問題だらけで、こんなの採用しようがないと思っていたわけです。2020年に一度詳しく書いています。
ここで列挙した問題のうち、いくつかは未解決のままですが、2022年現在、少なくともAAPについては「Prefabとnon-Prefabは共存できるようになった」「project(...)を使ったモジュールの参照がまともに解決されるようになった」「ビルドタスクの依存関係はbuild.gradleの依存関係を手作業で書き加えて何とか解決できる」「ヘッダファイルのディレクトリは1つになったし、その後AGPも対応したっぽい」「STLの競合は解決するアプローチを見つけた」というレベルでざっくり解決しつつあります。そして、
デバッグ時も含めたライブラリの正しい参照解決がNDKを使った開発の課題になるのに、Prefabを使わないビルドの場合はCMakeビルドの調整でクリーンにならない、という事態は好ましくなかったので、それならPrefab荷移行したほうがマシだろう、と考えたのでした。
上記の解決課題のうち「STLの競合は解決するアプローチを見つけた」については、今月新しく公開したlibcxx-providerというAARのパッケージのREADMEで具体的に解説しています。
本当はブログエントリにしようと思っていた（思っている…）のですが、READMEでほぼ説明しきってしまったので、それで終わりかもしれません。7月もカンファレンストークの準備（調べ物）などをしないといけないので、落ち着くのは8月になってから…?
AAPクライアントAPI再構築（未了）
4月にAAPで汎用的な拡張機構を実現するAAP extensions APIを構築した話を書きましたが、今月はこれをstate APIにも適用して拡張機能化する破壊的変更を実装しました。ただ、これに伴って、Kotlin APIを抜本的に書き換える必要があることが分かって、思いのほか大掛かりな作業になりつつあって完了していません。
AAPはホストアプリケーション（DAWなど）をKotlinでも構築できることになっているのですが、現状ではAIDLで定義したAPIを叩くクライアントのレベルでKotlinとC++の両面で実装している状態です。4月に具体的に書いたのですが、AAP拡張機能は一般的なオーディオプラグインの拡張機能APIとは異なり、拡張機能の提供者が（まあこれは現状標準拡張を規定している自分だけなのですが）AIDLで定義された拡張機能操作メソッドextension()を呼び出すネイティブ実装も提供する必要があります。その実態は「渡された命令コードがn番だったら、共有メモリバッファの0..mは引数xとして扱う」といったプリミティブな処理になります。
これらはC/C++レベルで実装されますが、Kotlin側には対応する機能が現状ありません。Kotlinのプラグインクライアント(DAW)が使うAPIは、あくまでAIDLで生成されたKotlin APIでしかないので、Kotlinでこれらの拡張機能を使おうと思っても、再実装するか拡張機能そのもののラッパーを作るしかありません。前者はそもそもKotlinで拡張機能の作者がC/C++でやっていることを再実装するということなので筋が悪く、特にC/C++の拡張機能の作者と別人でありうるKotlin API実装者が同じURIで拡張機能を実装している状態は治安が悪いので、誰でもKotlinでC/C++ APIのバインディングを作る必要がある（けど治安が悪いとまではいえない）後者のほうがまだマシということになります。
Kotlinで拡張機能のラッパーを作るとしても、そもそも何に対して「ラッパー」を作らなければならないかというと、実のところlibandroidaudioplugin.soに含まれる非公式のC++ hosting実装に対するラッパーとならざるを得ない状態でした。これは、拡張機能のサービスAPIがlibandroidaudioplugin.soのC++ hosting APIの実装に深く依存していたためです。そういうわけで、今月は少なからず時間を割いて、4月に実装していたこのAPIを再構築して、拡張機能のAPIとホスティング実装のAPIを切り離しました。
本当はこの切り離しが完了（変更したAPIに合わせてaap-lv2もaap-juceもそれらを使ったアプリを全部変更）したら、その続きとしてKotlin APIで純粋に拡張機能を呼び出せるような仕組みを構築するつもりだったのですが、前述の通りその方式では拡張機能の再実装ということになってしまって筋が悪いことに気がついたので、やはりKotlin APIもlibandroidaudiopluginのhosting APIのラッパーにせざるを得ないかな…となっているところです。
オーディオプラグイン勉強会#1（準備）
そろそろまたオーディオ開発の勉強会をやりたいと思っていた頃に、6月にCLAP 1.0がリリースされたので、それならCLAP 1.0を肴に勉強会をやると良いだろうと思って開催することにしました。オンラインで7/6 20:00スタートです。今回もこの分野に関心がある人には大いに刺激になる勉強会になると思うので、ぜひ参加してもらえればと思います。
勉強会のスタイルを設計するというのは（少なくとも自分としては）割と考慮事項がたくさんあっていつも悩むところで、今回は特に以下のような設計方針にしました。いずれ書こうと思っていたので、今回ここでまとめることにします。
- 勉強会は「参加者のため」にやる
- みんながしゃべれるようにする
- 発表者がしゃべるだけの会にしない
- ただし雑談に依存しない
- カジュアルからどっぷりまで各人の好きな度合いで参加できる
1.〜3.はざっくりセットです。聞いているだけ、質問・コメントでしかやり取りできない勉強会になってしまうと、どうしても「数字」（人数）・養分にしかなっていない感じになってしまいます。自分の場合、コメントが半分拾われなくなったら「他人事」になってストリームを閉じることが多いですが、ホスト側になったら全部拾っていられないですよね。自分の場合、資料を読み上げて発表したいのであれば1人でしゃべって動画をうｐすればいいし、文章やスライドとして公開したほうが読む側も助かるだろうし、「参加人数」にKPIが無くて、どちらかといえば「せっかく関連技術に詳しい人が集まってくれるので、そこから最大限いいシナジーが生み出されてほしい」わけです。
これは普遍的な話ではなく、たとえば「多人数向けに話すためならたっぷり時間をかけて最高の資料とセッショントークを準備して最高のマテリアルを遺すことができる／業務時間なども使える」という環境にいる人にとっては、多人数向けのオンライン勉強会などが最適解になるわけです。わたしは「みんなを引っ張り上げる」立場にもないので、共同体的な勉強会が向いています。
このやり方は多分名目30人くらいが限度だと思うので、ストリーミングの制限にかかわらず最大30人としています（10〜15人くらいは完全に聞き専と想定）。トピック的にはもっと集められてもおかしくないですが、それは全くKPIに基づく別のスタイルになるでしょう（複数人に事前にセッションをお願いして人づての窓口も増やす）。まあイベント感ある勉強会もそれはそれで楽しいですよね。
資料発表の時間は全体の1/2〜1/3くらいにして、ざっくりにして、いつでもしゃべりを中断して質問・コメントできるようにしています。何なら「ちなみに…」と直接関係ない話をされても、経験上、これで治安が悪くなる（話題が逸れすぎる）ことはほぼありません。話題が逸れ過ぎたらいつでも「スライド（本題）に戻りましょう」といって元に戻れるのです。何なら話題が逸れ過ぎても、それがみんなの話したいことならそれが話題の本質なのかもしれません。予定時間をタイトにするとみんなしゃべらなくなるし、盛り上がっても話の腰を折ることになるので、避けたいところです。
一方で、勉強会の場が「100%ただの雑談場」になってしまうと、それはそれで「何しに来ているのかよくわからない」状態になってやっぱり満足度が上がりません。われわれには多かれ少なかれ「自分のためになる時間」である勉強会に参加するという建前が必要です。雑談だけの時間は予定時間の後に十分にあるので、「勉強会では何もしゃべらなかったけど終わった後にみんなで晩飯に行ったら急に喋りだす人」ムーブも全然OKですし歓迎です（オンラインなのであくまで晩飯云々は完全に比喩です）。
勉強会は録画しようと思っていますが、公開は前提ではないです。まず、役に立つ情報を公開したければ1人で録画できます。公開するとなると私的な話などを出しづらくなって、参加者が非参加者を意識して発言を遠慮するという本末転倒の事態になります。参加者が楽しめることが最優先です。その上で、「録画して可能なら公開する」ことにしています。これは、経験上この種の読書会スタイルで共有される情報はやっぱりめちゃくちゃ参考になる話が多く出てくるためです。
CLAP JUCE hostingの試験実装
CLAPはオーディオプラグイン勉強会ではあくまで「肴」という位置付けなのですが、発表資料をふわっとしたレベルで終わらせるのは躊躇われるので、ちょっと自分でもコードを書いてみることにしました。JUCEでプラグインを作るモジュールはclap-juce-extensionsという公式リポジトリで公開されているのですが、ホスト側で利用できる実装がないようなので、先週くらいから自分で作ってみようと思ってチマチマと作っています。現状、リポジトリにするほどメンテする意思も無いのでgistです。
https://gist.github.com/atsushieno/d47a82739c64595da2f15cd8bc87673a
CLAPホストは実際にOSSではまともに存在しないのが現状です（公式リポジトリのclap-hostは機能しません）…というのが作り始めた頃の状況だったのですが、作っている間にQTractorで実装されました。いずれにしろJUCEモジュールにすれば、AudioPluginHostで使えたりtracktion_engineやhelio-workstationに組み込んだりできるのであってほしいところです。LV2には（JUCE7で正式にサポートされる以前から）jlv2というホスト側実装のプロジェクトがあって、これでtracktion_engineに組み込んでLV2プラグインをロードしていたので、CLAPでも同じことが出来るとたぶん便利でしょう。
もっとも、LV2と違ってCLAPでやりたいことは特に無いので、これを進めたいという動機もメンテしたいという動機もほぼありません。勉強会資料作成の肥やしのひとつです。
CLAPに関してはもうひとつ技術調査の動機があって、AAPのネイティブAPIの実装を、Binderでやり取りするのとは別のレイヤーでCLAPに置き換えて実用できるかどうか評価する、という目的がありました。CLAPにはAPI設計で参考になる部分もあるのですが、現状ではホストとクライアントの相互運用（API呼び出し）が頻繁にあって、プロセス境界をまたぐ必要があるAAPには馴染まなそうだというのが現時点での評価です。
その他
6月の最初は内閣官房デジタル市場競争本部事務局の力作に応えるべくパブリックコメントを書いたり本文を読んだりしていました。これは前回書いたので詳細はまあ今回書くまでもないでしょう。
あと、7月末に台北のCOSCUP 2022でMIDI 2.0に関するセッションをひとつ担当します（英語）。観光ビザでは相変わらず入国できない状態ですが、今回は渡航できる予定なので、問題が発生しなければ現地でしゃべることになると思います。来月はその発表準備や渡航準備で多少ごたごたする予定です。
