9月はDroidKaigiやらiOSDCやらで始まって（どちらも参加しただけ）、何となく慌ただしく始まったかのようでしたが、実際には余裕があるので今のうちにやるべきことをやっておこう、みたいな1ヶ月になりました。
とはいえ、11月の冒頭に韓国のDroidKnightsというイベントでAAPの話をしてくることになったので（KotlinConf、COSCUP、DroidKaigiの3つで会って「こっちのイベントでもしゃべって〜」みたいな話になったのでした）、M3 2026秋の新刊準備と合わせて10月はすっかり余裕がなくなった感じです。何とか乗り切らないと…
DroidKnightsが終わったらその足でADC Bristol 2026に向かうことにしたので（参加するだけ）、その先もまだ自由にならない感じです。
AAP 1.0 Preview post-mortem
これを書いたのは月末頃だったのですが、AAP 1.0 Previewを出してから、いろいろフィードバックを受け取っていて、そのほとんどは肯定的だったのですが（ありがたい限りです）、AAPが期待通りのものになっていないという向きのコメントもいろいろ受け取っていたので、AAPがそもそもどういう立ち位置で開発されているのか整理してメッセージとして伝えておく必要があると思ってまとめていました。
https://monogatari.audiopluginlab.com/posts/monogatari-ng/2026/09/20260927/
今月はAAPエコシステムの新しいメンバーとしてgreenhouseというプラグインホストが公開されました。AAPのためだけに、本格的に使えるプラグインホストアプリを、コミュニティ開発者から作ってもらえるというのは嬉しい限りです。めちゃくちゃ使いやすいのでAAPを体験する最初の一歩としてプッシュしていくことになるでしょう。
https://github.com/meteaurestudios/greenhouse
あと最近AAPコミュニティでなぜか「Android用のDAWとプラグインフォーマットを作っている／作りたい」という西アジアの中高生の面倒を見ている（と言っていいと思う）のですが、Discordのチャットだけだと十分に説明しきれない話とかもあるので、Androidでプラグインフォーマットを作るうえでの技術資料として残している側面もあります（英語版はまだ公には出していないのですが）。
UAPMD: copy-pasting and grouped edits on PianoRoll and Clips
今月はuapmd-appとuapmd-cmpにいろいろ改善の手を加えることになってしまいました。UAPMDは「使えるDAW」の開発を目指しているわけではないので、この辺は完全に回り道なのですが、結局ユーザーはそこを見て判断してしまうので…
copy-pastingは実のところプラグインAPIと全く無関係な機能というわけではなく、たとえばCLAPにはさまざまなユースケースで無駄のないstateの複製を実現するためのstate-contextというAPIがstate APIの（実質）刷新版として規定されています。remidyもuapmdもこのAPIを積極的に支持するためにstate APIに細かいモードオプションを指定できるようになっているので、トラックの複製を実装したら（クリップの複製とはまた別）、この辺に手を出すことになるでしょう。
また複数のノートを範囲選択してコピーしたり移動したりもできるようになりました。今月は他にもzoom/scrollingまわりのUXを改善したり、いろいろ改善が加えられており、これでまた少し「打ち込めるDAW」に近付いたと思います。それを目指しているわけではないのですが…!（2度目）
AAP native UIにおけるIMEサポートの実現
AAPの native UIの大きな制約のひとつとして、IMEの呼び出しが発生するとUIが応答不能になる、という問題があったのですが（正確には今でもあるのですが）、今月はこれを解消しました。Remote Composeで解決していないレベルの技術的課題だったので無理なんじゃないの…と思っていましたが、InputTransferToken という API Level 35のクラスとfocusableの調整を何とかすることで解決できたようです。API Level 35以上では。今月ちょろっとしゃべってきたLTスライドでもう少し詳しく書いています:
https://speakerdeck.com/atsushieno/enabling-text-inputs-on-any-remote-gui-on-android-lt
ともあれ、これがAAP native UIの目下の最大の問題という認識だったので（テキスト入力が「一切できない」プラグインUIシステムというのはさすがに…）、これが（API Level的な意味で）まあだいぶ未来形であるとはいえども解決できたことは大きいです。
DrumScriptのC++ portとMIRサポート実装の追加
先月uapmd-mirモジュールとしてbasic-pitchとpitch-detectionのサポートを追加しましたが、これだけでは譜面化できないパートがありました（まあそもそも典型的なパートでしか出来ないのですが）。ドラムです。さまざまな音階で推測することができないので、ピッチからのノート分析とはだいぶ異なるアプローチが必要になります。
これをlibrosaのonsetsから独自に推論しているDrumScriptというPythonライブラリがあって、大して大きいものではなかったので、これをC++に移植させてドラムパートのMIDIイベント推論のコマンドを実装したDrumScript addinを追加しました。DrumScript自体まだ全然実験的なプロジェクトでデータ収集しているレベルのようなので、信用度はそれなりのつもりで使うと良いでしょう。
MIRサポートまわりは、スクリプティングAPIで楽曲のデータ自体を渡せるようになっているUAPMDでは、わざわざC++で実装する必要はなく、MCPクライアントからUAPMDのMCPサーバーに接続すればPythonのオリジナルでやってくれるとは思いますが、トラックのコンテキストメニューから一発で呼び出せるのであれば、わざわざテキストで指示する理由もないでしょう。
UAPMD v0.6.0 release
v0.5.0リリースから3ヶ月くらい経過していて、これはそれまでのペースに比べたらだいぶ時間がかかっていたのですが、今月ついにv0.6.0をリリースしました。本当はv0.6.0は楽曲プロジェクトデータの定式化やARAサポートの安定化などいろいろ盛り込みたかったのですが、どちらかといえばUndo/Redoやグループ選択を含むプロジェクトドキュメントモデルの整備や、オーディオグラフの切り離し等モジュールを再整備したAPIとしてリリースすることに意義があるだろうと考えてのリリースです。データの定式化はSMF2 Container Formatが出てから改めて検討することにしました。2026年Q3のうちに出る予定となっていましたが、どうなるやらです。（今日Q3が終わります）
JSFX Plugin Format addin
UAPMD 0.6.0でアドイン機構がそれなりに定着したのですが、この中でやっていなかった残件として、カスタムオーディオプラグインフォーマットのアドインを実現していなかったということがありました。これは理由があって、uapmd-plugin-hostingのAPIがきちんと整備されていなくて、カスタムフォーマットをサポートするのがremidyのレイヤーにしか無かったから、という事情です。今月はこの辺を整備し直して、アドインとしてプラグインフォーマットを追加できるようにしました。
ここに追加できればしたかったものとしてはSFZファイルのサポートがあるのですが、WebプラットフォームだとSFZはまだ転送量の関係でしんどそうな気がするので後回しにして、とりあえずReaper JSFXのサポートをysfx経由で追加しました。
ただ、ysfx自体はJUCE GUIを使って構築されていて、gfx統合の実装でも使われていて、uapmdではこれをそのまま再利用するわけにもいかないので、GUI統合の部分だけはImGuiを使ってClaude Codeに書き換えさせています。ysfxがGUI実装のAPIを抽象化していたので、ysfxに対する小規模なパッチで済んでいるレベルです。
JSFX統合には思いがけないアドバンテージがあって、全プラットフォームで利用できるプラグインフォーマットとしては初めてのものなので、これ（だけ）を使えば文字通りどの環境でも同じuapmdzプロジェクトがそのまま再現できるようになりました(!)
一方で、JSFXサポートを追加した途端、プラグインリストに数百件のプリセットが出現するようになってしまい、単純なフラットリストしかサポートしていなかったGUIは完全に使い物にならなくなってしまいました(!) これでは困るので、今月新たにプラグインフォーマットやdeveloper等でツリー表示できるようなリストに作り変えてあります。
UAPMD: augene2 MML compiler integration addin
先月はUAPMDアドイン機構を活用して、シーケンサーの「エディター」部分を全てアドインとして実装できるようにして、既存のピアノロールとMIDIイベントリストをアドイン化しました。今月はv0.6.0をリリースしたこともあって、新たにMMLからMIDIクリップを生成・更新できるAugene2 Integration addin(!)を追加しています。さすがにこのビルドはデフォルトでoffにしてあります。
augene2統合は、アドイン上でコンパイルするとその打ち込み内容でシーケンスが全部更新される、そこにトラックのプラグイン編成の調整は含まれない、というかたちで実現しているので、augene-ngでHot Reloadとして実現していた更新時間の短縮は考える必要がなくなりました(!) MMLは別のテキストエディターで編集してコンパイルする方式で良いので、これは「MMLクラスタが求めていたもの」にだいぶ近くなったと思います。file watcherを使って自動更新みたいな機能はまだサポートしていないのですが（WebやAndroidでどうしようもないので後回し）、どうせ再生操作のためにuapmdに戻るのでそこでコンパイルして再生するワークフローでも十分かなと思っています。エディター上だけでコンパイルして再生するアドインも作れると思いますが、
UAPMD is capable enough to play full orchestra
augene2統合が実現したので、満を持してaugene-ngを作っていた頃に打ち込んだホルストの火星を持ってきました。ただ何もかも元通りというわけにはいきませんでした。
https://www.youtube.com/watch?v=pKiR55SHfXc
一番問題になったのはsfizzが昔のaugene-ngがUbuntu 20.24 + Tracktion Engineで動いていた頃のようには演奏できなくなってしまっていたことです。今や開発者がarchivedにしてしまったプロジェクトでさすがに昔のバージョンのビルドを試そうとまでは思えず、あきらめて最近LinuxもサポートするようになったSforzandoを上記の動画では使っています。31トラックのSforzando + マスタートラックのDragonfly Reverbというシンプルな構成であれば問題なく演奏できるようです。動画はmacOSですがLinux版のSforzandoでも問題ないです。一方でsfizzは後継のforkもいくつか試しましたが全滅でした。sfizzは（後で言及しますが）AAPでも引き続き使っているので、何とか使い物になる状態まで戻したいところではあります…余裕があれば。
あと打ち込み内容は多少手を加えてありますが、概ね昔作った通りです。昔はTenor Tubaだけ無かったのでFreepatsから引っ張ってきたりしていましたが、やはりこれだけが妙に浮いてしまっていたので、今回はVPO3のAllBrassを使っています。地味になって全体的なアンサンブルの厚みが出たので、最初からこっちにしておけばよかった…
Sforzando、これまでまともに使ったことは無かったのですが、パフォーマンスも申し分なく、プロプライエタリでAAPに持っていけない点などを除けば便利だなと思いました。
aap-lv2-sfizz, aap-sfz-vpo3, aap-sfz-salamander-drumkit
sfizzのパフォーマンス問題はあるものの、sfizzはAAPにも移植してあるので、トラックフリーズ等を上手く活用すればAAPでもフルオーケストラの打ち込みができる…という状態に持っていきたいところです。そのためには、まずSfizz AAPが任意のSFZを使えるようにする必要があります。これはオリジナルのコードだけではいかんともしがたいのですが、SFZで必要になるサンプルファイル等はContent Providerで取り出せるようにする仕組みを作ることで、一応演奏くらいはできるようになるはず、と思いました。
sfizz本家はもうメンテされていないので、多少大掛かりなコードの変更を加えても、独自進化ということにしていいだろうと割り切って、Claude Codeに適当に手を加えさせて、任意のAPKからリソースを提供させてファイルをロードできるようになりました。SFZサンプラーの中でSFZやオーディオファイルやをロードする部分はごく一部なので、パッチ全体としてはそれほど大掛かりな変更ではなかったようです。
とりあえず、この変更をもとに、GUIからも任意のSFZを（あたかもAAPホストがAAPプラグインをクエリするような感じで）外部アプリケーションのContent Providerからリストアップしてロードできるようにしたので、あとは無限にSFZのパッケージバンドルを作ることができます。ローカルファイルシステムからもロードできるようにしたので、無理にAPKにする必要もないです。
aap-juce-usf2plugin
AAP 1.0 Preview post mortemでも言及しているのですが、既存のDAWの類ではサードパーティプラグインをサポートせずに自前で軽量のSF2サンプラーなどを提供するかたちで完結しているのに対して、AAPはAudioUnitに近いルートを突き進んでいます。なのでSF2サンプラーだけで構築された世界よりはパフォーマンスが悪くなるのは避けられないわけですが、SF2サンプラーだけで解決するトラックがあってもいいのは確かなので、デスクトップで作ってあったUSF2PluginをAAPに持ってきたものを作りました。これも任意のSF2を使えるようにしたかったので、とりあえずAndroid SAFでSF2フォルダを指定できるようにして、USF2Pluginと同様にカジュアルにSF2を切り替えて音色を選択できるUIをそのまま利用できるようにしてあります。
AAPには昔aap-lv2-fluidsynthというプラグインが存在していたのですが、これはFluidsynthがCMakeでなかった頃に作られたもので、gstreamerで使われていたCerberoというクロスプラットフォームのビルドシステムを再利用していて、ビルド体験は良くありませんでした（多分もう動作しないでしょう）。FluidsynthはLGPLv2で多少使いにくい側面もあったので、USF2PluginではTinySoundFontを使っています。ただあんましリアルタイム演奏を意識した設計にはなっておらず、開発者の反応も良くないので、独自のforkで一時的に実現しているという感じです。SF2をサポートするアプリケーションには、sfizzやSFZeroなどSFZのエンジンを使いまわしているものも少なくないので、その路線に切り替えるのもアリだと思っています（それで軽量なマルチトラックDSPが実現できるかは未知数ですが）。
uapmd-cmp（Compose Multiplatform版）のキャッチアップ
uapmd 0.6.0リリースでは、uapmd-kmpがUAPMD本体にきっちり追従してほぼ同時にリリースできることを意識して作業していました。0.6.0リリースの後にピアノロールやトラックリストの改善などをいろいろuapmd-appに施していますが、uapmd-cmpにも一歩遅れ程度で追従するようにしています。
今月はuapmd-kmpでのみ発生していた、GUIインスタンスのライフサイクルに関連したさまざまな問題を解決していったこともあって、Compose Multiplatform版は特にAndroid上でのUXはかなりImGui版より快適になったといえます。最近Android上でデモを見せるときはこのKotlin版を中心に見せるようになりました。もしかしたらuapmdという名前で後悔しているPlay Store上のアプリはこちらに差し替えるかもしれません。
来月の予定
そんなわけで今月はだいぶ「UAPMDで現実的なトラック編集環境が整った」1ヶ月になったように思います。そろそろ自分の制作環境として利用し始めても良いという気がしています。SF2もSFZもNAMも使えるプラグインフォーマットは、エコシステムとしてDAWにフォーマットとして包括的に組み込む価値のある技術である、と主張しても許されそうです。
冒頭にも書いたのですが、10月は最終日曜日にM3が、11/2にDroidKnightsの登壇があって、どちらもまだ全然準備できていないので、この2つに忙殺される予定です。SMF2 Containerが公開されたらその対応作業はするかもしれません。あと他にもちょっと仕掛っているものがあるので、出来たら出すかもしれません。期待値はまだ高くないです。