5月の記録ですが、今日書いている余裕はあんまりないです。簡潔に書きます。
AAP: V4 protocol, and GUI change notifiers
先月「プラグインAPIに破壊的な変更が加えられている」と書いてきましたが、M3での展示のために実装を調整していた先月の段階では、いったん破壊的変更は先送りにして多数のプラグインが動くようにrevertされていました。一連のイベントが一区切りしたので、今月はいよいよBinderのレベルで破壊的変更を加えて、パラメーターやStateのAPIのクライアントが非同期的に呼び出せるようになり、uapmd上で楽曲データの保存などが正常に動作するようになりました。
今月はさらにプラグインからのGUIの動的なサイズ変更などに対応できるようにしました。aap-juce-ysfxはしばらく前にAAPに移植してみたもののまともに使えなかったプラグインでしたが、JSFXをいくつかapkにバンドルして、GUIのサイズ変更に対応出来るようにした結果、instrumentプラグインのほうは一応音が出るようになりました。正しい音が出ているかどうかは正直わかりません（そこまで確認している余裕がない）。
uapmd-kmpとKotlinConf 2026
下旬にKotlinConfに遊びに行くことに決めたものの、ここ1年くらいずっとC++でMIDI 2.0の開発をやっていたり、その後はプラグインホスト(uapmd)の開発に注力し、最近はADC JapanのセッションのためにAAPに注力していたので、Kotlinは全然やっていないんですね…せめて何かKotlinで使えるものを適当に作っておこうと思って、uapmdのKotlin Multiplatformバインディングを作りました。ついでにComposeでGUIを作れるようにしてみました。
どれくらい使い物になるかというと、デスクトップとAndroidでは一応音楽がそのまま再生できます（再生エンジンはC++実装を叩いているだけなので）。uapmd-appに相当するものを作るつもりだったCMPアプリは、現状とてもuapmd-appのマルチウィンドウのUXに敵わない使用感ですが、一応プラグインUIを出せるようにはなっているようです。この部分はCMPで独自対応しなければならなかったので、だいぶ苦労しました。しかしSDL以外のGUIフレームワークでもプラグインUIのホスティングが可能であることを証明できたのは大きいです。
KMPバインディングは、いったんC APIを（AIで）生成させてから、そのC APIをcinteropで自動生成できるようにして、それをJNAやemscriptingバインディングの入力ソースにしています。cinteropは「その出力ならKotlinバインディングは間違いなく作れるだろう」という意図で挟んだものですが、不要だったかもしれません。プロファイリングはしていませんが、uapmd-kmpだけ妙に重い部分があります。uapmd-kmpでバインドしているのはプラグインホスティングのクライアントAPIが中心なので、C++で高負荷な処理を行っている部分は無いと思って作ったのですが、実際にはどこかにあるのでしょう（確認している暇がない）。
一応ネタが出来たので今年もKotlinConfのKotlin FoundationのブースでLTしてきました。ただ実際には今年はQ&Aコーナーみたいな感じの運営になっていて、LTしたければすれば??みたいな感じだったので、スライドを準備していったものの、半分も使っていません。そんなスライドですが一応置いておきます。
augene2
uapmdはDAWとして作り込まれる予定が無いのですが、楽曲再生エンジンについては機能してもらいたいですし、どこまでの楽曲を再現できるのかは未知数です。そのためには.uapmdの楽曲データを生成できる必要があるでしょう。
現状でSMFのインポートは可能になっているのですが、既存の打ち込みデータで自分が一番作り込んでいたのはMMLから作成されたホルストの火星なので、MMLから.uapmdにコンパイルできる新しいaugene-ngが必要となります。augene-ngはTracktion Engineをターゲットにしていましたが、.uapmdは概ねSMF2 Containerと同じ発想で作られているので、今後SMF2 Containerの正式版が公開されたら簡単に追従できるようにしておきたいところです。
uapmdに拡張機能として組み込むことも想定して、C++に移植してみましたが、uapmd-appに拡張機能をどう組み込むかをまだ設計していないので、まだ実現していません。uapmd-appの拡張機能は、どちらかといえばMIDI2クリップのエディタ機能を念頭に置いているものですが、まだ構想段階です。AndroidでもDAWの拡張機能として実現する方法が必要であり、AAPと同様の構成は考えられますが、SurfaceControlViewHostでIMEがサポートできないという問題もあり、現状まだ棚上げです。
uapmd: project loader changes, generic audio nodes
uapmdでは今月は地味な変更が中心で、主にAAPのAPI変更に伴って、プロジェクトローダーがStateをロードする処理を書き換えたり、uapmd-kmpに合わせた変更などが中心でしたが、ひとつ大きな変更を加えた部分があります。音量調整のためにGainノードをオーディオグラフに追加したのですが、uapmdのプロジェクトファイルフォーマットはDAWprojectより汎用的なフォーマットを志しているので、UAPMD独自の方式でGainのノードを規定して値を設定させるというのは、好ましいとはいえません。何らかの汎用的な仕様が必要だろうと考えました。
そこで、uapmd-appはWebブラウザもターゲットにしている程度に汎用的であるべきだと思い出して、Web Audio APIのノードに使われている仕様と同等のものであれば、「標準でサポートすべきもの」という位置付けにしても良いのではないかと考えました。Web Audio APIにはGain以外にもいくつかノードがありますが、それらを含むノードグラフのカタログであれば、実装してもらう前提でも悪くはないでしょう。この仕様のために、(lib)uapmdに含まれていたAudioGraphのAPIは新たにuapmd-graphというライブラリに切り出されて、Gainノード等の実装とともに独自に管理されることになりました。
データのシリアライゼーションは別途uapmd-dataで行われていますが、もしかしたらこれもuapmd-graphから呼び出すかたちにして一般化するかもしれません。このデータフォーマットはまだまだ未完成ですが、最終的に汎用フォーマットとして納得感のある仕様を目指したいところです。
6月の予定
明日からADC Japan 2026が始まるので、忙しくなります。自分のセッションは3日目の後半なので、気の抜けない日々になりそうです。台風も近いですし、参加される方は気をつけておいで下さい。