先月に続き2月も自分の開発に100%集中できていて、生産的な時間を過ごしています。といっても生産性の亡霊みたいに生きたい願望は皆無ですし、生産性を最大化して日々過ごしているわけでもないですが。

あとADC Japan 2026がいつの間にかCFPを出していたので1つだけ投稿しましたが、3/2まで時間があるのでもしかしたらもう2つくらい作るかもしれません。

audio.dev

正直どちらかといえばLinux Audio Conference 2026のほうが自分のあり方に近いので、そっちでしゃべったほうがいいのかもしれません。スケジュールを見る限りADCの採択からLACの締切まで1日の猶予があるので、落ちても再利用できそうですが、ちゃんとスケジュール通りに動いていれば…という前提がありますね。

lac26.mucs.club

UAPMD v0.2.0 and MIDICCI v0.2.0 released

2月中旬にUAPMDとMIDICCIのv0.2.0をリリースしました。実際には、v0.1.4を2月初頭にリリースして、その2週間後にv0.2.0をリリースして、実際にはちょっとやらかしててuapmdはv0.2.1をリリースしているのですが、まあ誤差でしょう。

UAPMD v0.1の主要なアチーブメントが「任意のオーディオプラグインをMIDI 2.0デバイス化する」にあるとしたら、v0.2は「マルチトラックのオーディオ / MIDI (2.0) クリッププレイヤー」を実現できたことをもって決定されたリリースです。SMF2 Container Formatはこういうフォーマットとして作られているはずなので、それを実現したものである、ということもできます。これを実現するために、UAPMD v0.2.0にはいくつか新機能が追加されました:

• プラグインにUMPイベントを送信できるSMF2クリップをトラックの一部として再生できるようになりました。SMF2クリップの送信対象はプラグインであり、オーディオクリップと並列に走らせることもできるので、エフェクトプラグインオートメーションに相当する処理もSMF2クリップで実現します。
• UAPMDプロジェクトファイルのロードとセーブ: SMF2 Containerフォーマットはまだ仕様が公開されていないので、独自形式で保存されています。
• SMF importer: SMFで制作された楽曲の各トラックをSMF2Clipに分解できる（保存はプロジェクト保存と同時に行われる）。これで既存のSMFファイルからSMF2ファイルをカジュアルに作成できるようになりました。
• マスタートラック: SMFでは明確な仕様ではないのですが、テンポや拍子の管理は1つのトラックに吸収して管理されています。管理といっても現状では全トラックから吸い上げているだけで、正直これを編集可能にするときにどうしたものかはわかりません。MIDI 2.0の場合テンポや拍子の設定はUMPの一部 (Flex Data) なので情報の保持は難しくないのですが。
• トラックのタイムラインのコンセプトがほぼクリアになりました。具体的には、オーディオI/Oからのオーディオグラフにおける位置付けが、再生時にはいったんトラックの内容から「今回のオーディオ処理に含まれるサンプルとイベント」を切り出して、プラグイングラフに渡す（プラグイングラフの構築と処理は実装次第）、というかたちが明確になりました。
• SMF2クリップの内容を表示するMIDIダンプリストを表示できるようになりました。

MIDI 2.0楽曲ファイルの作成と再生については、ktmidiにSMFをそのまま延長したような構成のAPIがあったのですが、UAPMDというかたちで音源というかプラグインホストを作成してみると、明らかにこの構成では足りないことが明白になったので、先月ktmidiからumppiとして取り込んだばかりのMidi2Musicクラスは消えて無くなる事になりました。

UAPMD & MIDICCI app design polish

UAPMDは元々GUIアプリケーションにするつもりが無かったこともあって、GUIとしての見てくれはUIテーマをBootstrapっぽいやつにしたりフォントをRobotoにした以上のことはしてこなかったのですが、MIDICCIと併せて今回はもう少し手を加えることにしました:

• Lightテーマ対応: ImGuiにデスクトップからlight/dark themeを判別する機能は用意されていないようなので手動切替になりますが、一応ホワイト中心の配色を用意しました。ただImTimelineの中は調べきれていなくてそこだけ暗いです（逆効果かもしれん）
• GUI上の機能が増えすぎて文字ボタンがスペースを取りすぎるのが無視できなくなってきたので、FontAwesome + fontaudioを使って画像で代用することにしました…のつもりが、fontaudioはまだ出番が来ていません（取り込みはしましたが）。カスタムフォントとしてImGuiに統合するのはjuliettef/IconFontCppHelpersと組み合わせてC++ヘッダー化したフォントファイルのリソースを使えば簡単…というわけでAIにC++ blob headerを自動生成させていたのですが、最近公開されたeyalamicmusic/ResEmbedを使うとさらにクリーンなかたちで統合できたので、公開が告知されたその日のうちに対応しています。
• アプリアイコン: v0.1の時点ではアイコンの類を何も用意しなかったのですが、アプリケーションとしてインストールできるようにしているわけだしもう少し実用品っぽくしておこう…と思って用意することにしました。とはいえ考えるのめんどいしどうしようかなあ…とぼやいていたらmuojpせんせいから天啓が…

最近ClaudeでAndroid用のXMLアイコン描かせてるんですが、妙に味があって気に入ってしまい困る事案にw

— muo (@muo.jp) 2026-02-14T06:19:49.867Z

bsky.app

DroidKaigi 2025の関連セッションなどを見ているとわかりみが出てくると思いますが、完全にそれっぽい…!と思って真似してみました。おかげさまでそれっぽいものが生成できています:

VST3/AU host on macOS: every plugin loads

UAPMDの大きな弱点のひとつはremidyのプラグインホスト機能がjuce_audio_plugin_clientなどと比べると安定的にあらゆるプラグインを利用可能になっていなかったことでした。具体的には、Absynth5のAUがインスタンス生成に失敗したり、Kontakt 6/7/8のGUIがAUでのみクラッシュしたり、KORG M1やVienna EnsembleのVST3がインスタンス生成時にクラッシュしたりといった問題が起こっていました。

これらについては毎月のように修正を試みていたのですが、今月はついに自分の手元にあるプラグインについては全て解決しました（そんなに大量に抱えているわけではありませんが）:

• Absynth5 AUとKontakt 6/7/8のUIを妨げていたのはAUのインプロセスモードの明示が原因でした(!)　プラグインインスタンスの生成は時間がかかるので非同期のAudioComponentInstantiate()で行うべきですが、その引数にkAudioComponentInstantiation_LoadInProcessを指定すると、インプロセスモードで実装されていないプラグインの機能が全て死にます。
  • Absynth5 AUが死んだ理由はこれがarm64ではなくx64のABIでビルドされた旧時代のプラグインであり、Rosetta2経由で動いていたため、別のプロセスでロードしなければならず失敗していた（クラッシュまではしなかった）ということになります。
  • Kontaktのほうは、おそらくmulti outの機能を実現するうえで1つのGUIプロセスが複数のプラグイン インスタンスとやり取りするかたちになっていて、DSP側のインスタンスだけなら正常に動作できてもGUIを表示しようとした瞬間にAUのフレームワーク側から想定外のブロックを食らって死んでいたのでしょう。
• VST3のM1とViennaのほうは、単純にremidyのオーディオバス調整まわりでプラグインとの不一致が原因でした。

そんなわけで、VST3とAUのプラグインホスト機能は少なくともmacOS上ではだいぶ安定感が出てきました。とはいえ何もかもが動くようになったというわけではなく、CLAPプラグインではFloeが動かず、またLinuxではyoshimiが自分の知る限りでは動いていません。この辺はもう少し修正が続いていきそうです。とはいえ互換性地獄のプラグインホスト開発でここまで順調にいろいろ使えるようになったことを考えると、だいぶいい戦果を出しているのではないかと思います。

MIDI Message Report: The Latest Parameter Value Saga

先月の作業の最大の成果は、プラグインのパラメーターリストの動的な変更とホスト側への最新パラメーター情報の通知を何とか実装したことだったのですが、これがuapmd-appからmidicci-appへの通知となるとまだまだ完成していませんでした。これは、簡単にいえば「仮想MIDIデバイス生成時にはプラグインパラメーターの値が既に初期値から動いてしまっているため」です。同様の問題はuapmd-app自身がホストとしてプラグインのパラメーターの現在値を通知してもらう流れでも発生していました。

この問題を解決するために、仮想MIDIデバイスにMIDI-CI接続が新たに発生した時に、MIDI-CIの機能の一番目立たないMIDI Message Reportという機能を使って、現在のプラグインのパラメーター…に対応するAssignable ControllerとPer-Note Assignable Controllerのリストをmidicci-appからリクエストできるようにして、またuapmd-appもMIDI Message Reportに応答できるようにしました。

Process Inquiryの機能を実装しているのはktmidiとmidicci（とuapmd）だけなので、juce_midi_ci（と呼ばれていたモジュール）を使っていると実現できません。

あと関連項目として、UAPMDのAllCtrlListプロパティでは、パラメーターの最大値と最小値を指定するminMaxという項目を生成しなくなりました。これが指定されると、パラメーターのnormalized valueの値域が0..1からシンプルに0..UINT32_MAXに対応しなくなってしまい、ユーザーに余計な混乱を与えることになります。MIDIデバイスとしてやり取りするのは常にnormalized value、enumなどのdiscrete valueに変換するときも0.0..1.0にマッピングしていたのと同じことをする、という前提で再構成しています。

midicci diverged: UMP type migration from uint8_t to uint32_t

midicciはそのアイデンティティが「C++プロジェクトに組み込めるktmidi相当のMIDI-CI機能を実現するライブラリ」にあって、これまではずっと「ktmidiに新機能を実装し、それをコーディングAIエージェントに移植させる」というモデルで進めてきました。

このアプローチは現状でも破綻しているわけではないのですが、今月になってmidicciはついにAAPにも組み込まれるようになり…さまざまな問題が噴出しました。現時点でもAAPのMIDI-CI統合は期待通りに動作していません。uapmdとmidicciは2026年の今を生きる人類として開発が進められているライブラリで、libremidiなど2026年のライブラリを想定して設計されています。

ktmidiがUMPサポートを追加したとき、あるいはAAPがMidiUmpDeviceServiceサポートを追加したとき、それらのAPIが念頭に置いていたのは「MIDI 1.0とのシームレスな互換性」でした。そのため、これらのAPIはMIDI 1.0のAPIと同様、1バイト単位（kotlin.Byte, uint8_t）でUMPを受け渡しています。これがlibremidi、ALSA、CoreMIDIなどとデータのやり取りをする場面ではuint32_tなど4バイト単位の受け渡しが必要になります。この変換は単なるポインタのキャストではうまくいきません。なぜならエンディアンネスの問題が発生するためです。UMPのuint8_t*のストリームとしては40 90 2B 00 F0 00 00 00のように渡さないといけないのに、4バイトのlittle endianのメモリには00 2B 90 40 00 00 00 F0のように格納されているためです。こういった複雑な前提の違いは、特にコーディングAIがすぐ間違えます。人類も間違えるでしょう。

そういうわけで、midicciはUMPを扱うAPIの一般的な潮流に合わせて、uint8_tからuint32_tの単位でUMPを表現することにしました。これは結果的にktmidiに追従する開発方針からの転換ということになります。まあ実際これで困ることはもう無いでしょう。midicciの実装は、可読性はともかく、挙動としてはだいぶ信頼できるコードになってきました。

ktmidiもそのうち追従するかもしれませんが、ktmidiのほうをいじっている暇がないので、しばらくは現状の1バイトAPIを維持することになりそうです。

UAPMD: U is for Ubiquitous

UAPMDは特にWindowsがMIDI 2.0をサポートしていない現状ほぼLinuxとmacOSで動かすために作られたものですが、次世代プラグインホストに相応しい立ち位置を実現するために開発しています。これは特にAndroidを含め「デスクトップ限定のホスティングライブラリで終わらない」という側面があります。UAPMDのUはubiquitous（遍在）のUであり、元々は「どんなオーディオプラグインでも」UMPデバイス化する、という意図だったものですが、今月はさまざまなプラットフォームで動かせる可能性が見えてきました。

uapmd-android

まずはAndroid版です。リポジトリはuapmdに統合される可能性がありますが、とりあえずは独立して作られています（雑にAndroid Studio Pandaで作られていますがAGPのバージョンさえ調整すればNarwhalでもいけるはず）:

github.com

どのプラットフォームでも一番問題になるのは「ImGuiが動くかどうか」ですが、Android上ではSDL3 on Androidがそこそこ本気で作られているので、この上で動かしています。SDL3 on Androidは特にSDL3のメイン開発者が積極的にコミットしていることもあって、今後が期待できそうです。ただ現時点では「SDL3のメインスレッド」がAndroidのメインスレッドではないという問題があって、挙動が安定しません。Flutterがv3.29で大改修を実現したやつと同根ですが、こちらは単なるリグレッションのようなので、そこまで時間がかからずに直るかもしれません。

Android版のuapmd-appは、ImGuiアプリケーションとしては概ね問題なく動いていたので（最近はやや不安定でしたがこれはuapmd-app本体が不安定という可能性が高いです）、新たにPluginFormatAAPのAPIを作ってmainブランチにも取り込まれていますが、まだプラグインの列挙から先は未確認です。というのも、現状uapmd-appはファイルをロードできないとプロジェクトに取り込むことすらできないわけですが、AndroidでファイルI/Oというわけにはいかないので…

uapmd on Windows

次にWindows版です。Windows MIDI Servicesがついに出る出る詐欺を脱して正式リリースされそうということもあって、だんだんこの界隈が賑やかになってきました。先月libremidiの仮想ポートサポートがまだ出来ていないという話を書きましたが、今月になってこのissueにmicrosoft/MIDIの設計開発者も参戦してきて、実装されたけど動作確認できない〜、みたいな状態で来月に持ち越しそうです。

Windows版はまだまだ全体的に安定しないのですが、プラグインホストまわりでは大きく2つの修正を加えた結果、そこそこプラグインが使えるようになりました:

• Native Instrumentsのプラグインが全て使えていなかったのですが、これはVST3のバンドルで呼び出すべきInitDll() ExitDll()の関数名が間違っていたのが原因で、これらを修正したら正しく使えるようになりました。
• 先月までImGuiのバックエンドがGLFWだったのですが、まずSDL3を使うようになり、さらにDirectX11を使うようになり、その後安定性の観点でSDL3に戻ったものの、プラグインUIの描画に問題が出たため、現時点ではDX11に戻っています。SDL3の描画問題はかつてはmacOSでも出ていたので、似たような問題で解決可能かもしれませんが、現状DX11もSDL3も同じくらい不安定なので、今後DX11からさらに動くかはわかりません。

uapmd WebAssembly build

現状まだ本気で取り組むつもりはないのですが、uapmdにはEmscriptenビルドも存在していました。ただ古いブランチのままで、その後のuapmdの成長に全く追従していなかったため、mainブランチに取り込めるようなものではありませんでした。今週ちょっとCodexのトークンが余りすぎていたので一念発起して「ちゃんとmainブランチに取り込んで維持できる」前提のものを作ろうと思い至って、何とかCodexのweekly limitの範囲内で実現できました。

wasm版では意外にもchocのAudioFileReaderが（基本的にファイルI/Oで動いていたのでそのまま動かないのは当然として）iostreamでも期待通りに動かないという問題が出て、miniaudioの組み込みAPIでようやく再生できる（miniaudio自体はWeb Audioバックエンドもサポートしているのでそのまま使える）が、flacは再生できてもoggが再生できない…という事態に陥っています。

また当然ですがwasm版では現状利用可能なプラグインフォーマットが無く、WebCLAPかもしかしたらWAM2が今後サポートできるかどうかわからない状態にある、という感じです。どちらもプラグインを列挙するAPIがまだ無いはず。

AAP midicci integration

AAPには元々ktmidiを利用してMIDI-CI機能を実現するつもりでした。これを実行に移していなかったのは、Kotlinで実装してしまうとMIDI-CI処理をAAPから操作したい場合にややこしい事態になると想定されたためです。この考え方がmidicciの成長を見ていくうちに変わってきました。midicciを使ってAAPのC++実装から調整したほうがuapmdに近いことが出来そうな目論見が立ってきたので、ktmidiの代わりにmidicciを使うルートで実装することにしました。

ただ、midicci-appが存在しているデスクトップ環境とは異なり、midicci-appはまだAndroidに移植されていないので、接続確認にはktmidi-ci-toolを使っています。これがまだAAPのmidicci統合と相互接続できず、まだ試行錯誤している段階です。AAP側にも、インスタンス生成時にパラメーターリストを取得できない問題などがあり、AAPもいろいろ再設計したいという気持ちが高まってきました。ただそれは抜本的な再設計になるので、UAPMDが落ち着いてからがっつり時間を取って着手したいところです。

3月の予定

11月から3ヶ月ほどuapmdとmidicciに集中できていたのですが、4月には技術書典20とM3 2026春があるので、新刊の準備をしないといけなそうです。プラグインホストの設計解説書あたりが良いかと考えていたのですが、Windows MIDI Services正式公開の流れに乗るならMIDI 2.0総合開発本あたりが良いのかもしれません。まあ来月末には告知できる段階にあろうかと思います。

年始にはこの月報スタイルでまとめていくスタイルもどうかと思う、変えるかも、などと書いておきながらまるっと1年経ってしまいましたが、何もかも忘れたふりをして書いていきます。

今月はちょいちょい勉強会に参加して4回 くらい しゃべったり して いたのですが、どれも5分LTくらいでスライドはナシでいったので、あんまし特筆すべきことがありません。compose-audio-control、uapmd、ADC25、uapmd（だいたい1回目と同じ）の話をしただけでした。

あとは9割9分uapmdの開発しかしていなかったので、uapmdの進展について書きます。

UAPMD v0.1 released with installable packages

時系列としては月末の話からになってしまいますが、ついにv0.1をリリースしました。

https://github.com/atsushieno/uapmd/releases/tag/v0.1

といってもこれからリリースノート的なブログを書いて公開することになります（昨日書ききれなかった）。リリースに合わせて、ソースコードから手作業でビルドする必要が無いように、Linux用パッケージとmacOS用のhomebrewパッケージをセットアップしたので、誰でも試せるようになりました。homebrewではソースからビルドすることになるのでまあまあ時間がかかります。

UAPMDの開発を始めてから15ヶ月くらい経っているらしいのですが、今年は裏稼業で時間を取られてしまい（まあそれでギリギリの社会性を維持しているという話もあります）、code frequencyを見るとまだ実質6人月くらいの工数でここまできているようです。いろいろ動くようになったので、v0.1に合わせてスクショを取って使いまわしています。

パッケージングはCPackやhomebrew前提でやっていて自分が頑張った部分はあまり無いのですが、公開APIに含まれるヘッダファイルからchocやconcurrentqueueのような外部ライブラリの参照を引きはがず作業が発生し、これはそれなりに設計を調整することになりました。公開APIがstableになったわけではありませんが、それでも余計な依存ファイルが追加されると、余計なファイルがインストールされることになるので、きちんと回避しておくべきものです。これは日頃から「公開APIのクラスや関数のレベルでは、なるべく外部ライブラリのAPIを含まない」という設計方針にしてあったので、大して無理無く実現できたことです（自画自賛）。

midicci / cmidi2の改善

UAPMD v0.1としてリリースするに至った最大の理由は、Stateの保存と復元がついにMIDI-CI経由で機能するようになったためです。先月remidyのレベルではStateの保存と復元が全フォーマットで実現できていたので、今月はuapmdの段階のみを意識して対応できました。大部分はcmidi2のsysex処理からmidicciのMIDI-CI処理に至るまでのさまざまなバグフィックス作業でした。

Stateまわりは、当初は「StateListプロパティを取得して、その中に含まれているStateのresIdを全部拾って、それらを全部取得して、最後に結合する…全部集める並列リクエストの統合が必要…」という面倒な作業を想定していましたが、MIDI-CI Get and Set State Property仕様を眺めていて、「fullStateというresIdが全てのStateを含むバイナリとして指定できる」と書かれていることに気づき、現在はこのfullStateのStateのリクエスト1発で済ませています。

あと、もう1つ仕様の見落としがあった話になるのですが、当初の計画ではState Propertyの実装で得られたバイナリデータはSMF2Clipで保存できるつもりでした。しかしSMF2Clip仕様書では、Property Exchangeの内容はClip FileではなくContainer Fileに含めるべきものとして明言されている、ということに気付いたため、「じゃあSysExに変換して保存しなくてもいいか…」となって、むしろ想定していたよりもシンプルな、通信経路での変換のみを気にするという作業になりました。

そんな感じで、Stateサポートの作業が思っていたよりだいぶ軽くなったので（それでも主なメッセージングトラブルはここで発生するのですが）、リリースを早められたことになります。

Stateサポートは、Property Exchange実装の中でも特にresIdを使用する初めてのユースケースだったので、MIDI-CI実装をktmidi、midicciともに改善する機会になりました。また、StateプロパティはmutualEncodingにMcoded7を使用してmediaTypeにapplication/octet-streamを使用する実用例でもあって、MIDI-CI基盤をいろいろ修正することにもなりました。また、Mcoded7は単純な変換で済むのですが、zlib+Mcoded7にはzlib圧縮が必要になるので、zlibを使って解決…とシンプルに済ませるはずがWindowsビルドで躓き、zlib-ngなどで回避策をとることにもなりました。

さらに、MIDI-CIプロパティの値はこれまで静的なものばかりだったので（AllCtrlListなどはパラメーターメタデータのみで、実際のパラメーターの変更はAssignable Controllerで送ることになります）、プロパティの値も事前に溜め込まれていたものを返す方式だったのですが、Stateの値はuapmd側でGUI等で設定したStateが随時反映されることになるので、プロパティの値を動的に返せる仕組みをMIDI-CI基盤に導入することになりました。実際のところ、Property Exchangeはこの方式だけで実装するほうが良いでしょう。

remidy GUI container fixes

先月書いていたのですが、今月の当初の課題はKontakt 8 AUのUIが出せなかったり、GUIのリサイズができなかったり、GUIを表示した後でインスタンスを削除したらクラッシュしたり、といったGUIにまつわるさまざまな問題があり、今月はこれを全て解決していました。uapmdのホストは目下のところImGuiであり、バックエンドとしては主にSDL3（またはSDL2）なので、OpenGL contextの扱いが問題になることが多かったのですが（概ね先月解決していたはずです）、

uapmd-appへの一本化

uapmdの開発作業で面倒だったのが、remidy-plugin-hostではホスト上でパラメーターやプリセットをGUI以外からも簡単に変更できるのにuapmd-serviceではできないとか、逆にuapmd-serviceでだけオーディオグラフを構築するUIが実装されていたりといった、2つの概ね同じ機能を実現しているホスト間での細かい機能の違いでした。Stateのバイナリデータの比較など、1つのプロセスのデバッグ中であれば簡単にできるのに、別々にデバッグするとなると一旦ファイルに出力して…といった面倒が生じます。

そういうわけで、今月ついにこの2つを統合してuapmd-appという1つのGUIアプリケーションだけ提供することにしました。uapmd-serviceはもともとCUIで動作する前提だったので、その頃から比べると方針の大転換といえますが、GUIなしにプラグインの設定を調整するのは無理があるわけで、これは現時点であきらめています。

2つのアプリケーションが統合されたことで、このアプリ自体の機能改善が気軽に加えられるようになって（後述）、開発速度がだいぶ上がったといえます。

あとmidicciでも現在同じような作業を行っています。midicciには、ktmidi-ci-toolの移植であるmidicci-guiと、UMP+MIDI-CIキーボードであるmidicci-keyboardの2つのQtアプリケーションが含まれているのですが、これらをImGuiに書き換えた上で統合する作業を行っているところです（進行中）。これが完了したら、midicciもuapmdのようにLinuxパッケージやhomebrewパッケージを作って公開することになるでしょう。

オーディオファイル再生機能等の実装

uapmd-appは（あるいはremidy-plugin-hostとしてもuapmd-serviceとしても）、エフェクトプラグインもMIDI 2.0デバイスとして外部から操作できることを想定しています。ただ、この場合、エフェクトを適用した結果というのは何らかのオーディオ入力が無ければわからず、これまではインストゥルメントプラグインの出力に繋げるしかありませんでした。アプリ上はオーディオファイルを再生できるかのように見えていたのですが、Claude Codeが勝手に生成したスタブ(!)でしかなかったわけです。SMF2 Container Fileにはオーディオクリップも含まれることになるので、オーディオファイルを指定して再生しながらエフェクトを適用できる機能は、いずれにせよあるべきです。

そういうわけで、今月は単一のオーディオファイルながら、外部ファイルを指定して再生できる機能が追加されました。また、再生中のオーディオ波形等を視覚的に確認できるようなミニマムなスペアナも追加されたので、エフェクトプラグインが想定通りにオーディオ波形を生成できているか、簡単に確認できるようになりました。v0.1のスクショにも盛り込まれています。

この機能は、将来的にはシーケンサー機能として、複数のオーディオクリップやSMF2Clipをタイムスタンプ付きで指定できるようにすると良いのですが、それってつまりDAWなのでは…?と思わなくもないです（意図的）。これを大過無く実現するには、複数のトラックを効率的に再生できる仕組みが必要になり、レイテンシーレポートを受け取って調整するオーディオグラフの機能が必要になってきます（現在は単なる直列グラフを複数本直列処理しているだけ）。

オーディオファイルの再生に加えて、オーディオデバイス設定の機能も実装しました。これも長らくスタブだったのですが、正しいデバイスリストを取得して適用できるようになっています。

UapmdUmpMapperとIMidiMapping2サポート

UAPMDの今月の最大の課題が、UMP経由でパラメーター変更を問題なくやり取りできるようにすることでした。これまではオーディオ処理のprocess()関数で渡されたUMPシーケンスをプラグインフォーマットごとに処理する実装になっていました。AUの場合、UMP入力をそのままMIDIEventListとして渡せるので、内容を見ずにそのままコピーできますが、VST3はMIDIイベントを全てプラグインのイベントにマッピングするので、1つずつ内容を見て対応する機能を呼び出す必要があります。といっても、対応しない機能はスルーするしかありません。

UAPMDの場合、プラグインのパラメーター変更を全てAssignable Controllerにマッピングしますが、これらはVST3イベントの処理でパラメーター変更に復元されていました。この復元処理はAUでも必要になるはずなのに、AUの実装ではUMPがそのままMIDIEventListに渡されてしまい、復元されていませんでした。そもそもプラグインパラメーターとのマッピングはフォーマットを問わずに行われるべきものであり、受信したUMPのAssignable Controllerを復元する処理と、パラメーター変更イベントをUMPとして送信するために変換する処理は、機能的に一対になっているべきものです。

これと関連して、MIDI mapping機能をremidyの機能の一部として取り込むべきか否かを検討していました。というのは、VST3の他にCLAPもMIDI mapping拡張機能のドラフト版を追加していたからです。しかし最新版の仕様ではこれは「MIDI 2.0を使えば十分」として削除されていたため、この機能はもしremidyでサポートするとしてもVST3 plugin instanceのExtensibilityに含める、という方針にしました。

VST3のUMPからの変換では、プラグインが提供するIMidiMapping対応が実装されていましたが、VST3.8.0ではMIDI 2.0のUMPに対応するIMidiMapping2インターフェースが新たに追加されたので、これを実装したプラグインがもしあれば（現時点でまず無いでしょう）IMidiMappingより先にマッピングを取得するようにしました。これで期待通りなのかはわからないところですが、IMidiMapping2をサポートするOSSのホストは他に無いので、とりあえずは十分でしょう(何)。

ノート別コントローラーの実装

UAPMDの存在意義は仮想MIDI 2.0デバイスを実現することであり、MIDI 2.0デバイス「らしい」機能として、ノート別コントローラーの機能は実現しておきたいところでした。単なるパラメーターとは異なり、ノート別コントローラーではパラメーターを操作する対象を選択できなければなりません。ノート別コントローラーといいつつ、実際にはチャンネルを指定することもあります。uapmd-app GUI上でもノート別コントローラーをサポートする必要があるため、パラメーターの対象セレクターが追加され、「単なるパラメーター」はグローバルパラメーターとしてサポートされることになりました。

ノート別コントローラーをサポートするプラグインはあまり多くありませんが、VST3のSerum 2（AUのSerum 2は未対応）、CLAP版Surge XTやZebralette（VST3版は未対応）などが対応しています。midicci-keyboardではPer-Note Assignable Controllerをまだ実装していないので、これから対応することになります。

その他

今月はこれら以外に、JavaScript/TypeScriptバインディングAPIを実験的に作って追加したりしています。これはremidyとuapmdをスクリプトで操作できるようにしたいという目論見があってのことなのですが、その後興味本位でremidy-plugin-hostをWeb UIで再実装しようとして、GUIループの問題に全く上手く立ち向かえずに爆死したので（GUIコンテナの実装を別途構築する必要がありそう）、これは今やることではないと思って放置しています。JSバインディング自体は、QuickJSなどを組み込めば便利に使えるようになるでしょう。

総括

今月は先月以上にUAPMDの開発が随分がっつり進められて、だいぶ進捗を出せました。v0.1では現在サポートしているプラグインフォーマットについては、プラグインホストの機能面でUAPMDがやるべきことの大部分をカバーしたように思います。次のマイルストーンでは、簡単なシーケンサー機能を実装して、レイテンシーレポートやオフラインレンダリングの挙動を確認・調整することになるでしょう。それから、このプラグインホストをAAPで使えるようにするのも目標の1つです。

ADC Bristolと技術書典19

2年ぶりにADCにオフライン参加してきました。今年のセッションはあんまり強い傾向の見えないラインアップだったように思いますが、強いて言えばAccessibilityまわりは充実していました。MIDI 2.0、空間オーディオ、AI技術あたりの話題は見ていません（AIはさすがに皆無ではない）。個人的に良かったのは最終日のキーノートでした。Strudelコミュニティの隆盛を紹介した話だったのですが、いろんな意味でフリーダムすぎるんだけど（「誰でも好きに変更できる。何なら全部消すこともできる」）、でもそれがうまく回っている、みたいな話で、めちゃくちゃ面白かったです。これは幅広く見られてほしいです。技術的なトピックとしては、み ん な std::memory_orderの話をしているな??という感じでした。あと初日がワークショップと1トラックのセッションの並列進行だったので、ワークショップに興味のない自分はセッションをつまみ食いできてよかったです。

セッションの時間以外は今回は何かと政治的に(?)振る舞っていました:

• the VST3 developerが来ていたので、AAPを見せて「これをVST3に手を加えてできるようにすべき」という話をしてきました(　Androidの元リーダーも来ているから相談してみてよ、って言ったら実際相談するようになって、「DSPはいけそうだ、って話をした」と言っていたので（GUIも技術的にはいけるんだけど）、もしかしたらこの方面で進展が見られるかもしれません。
• Androidオーディオチームの元リーダー（最近辞めてしまった）には2019年にもうAAPを見せていたので、今回はむしろuapmdで仮想MIDI 2.0デバイスでMIDI-CIでプラグインのパラメーターリストを取り出したりするのを見せたりしていました（MIDI 2.0の導入も関与していたので）
• AudioUnitの開発者も来ていたので、AAPを見せて「iOSではどうやってXNU Turnstilesを導入してもらったんだ…?」と訊いたりしていました（ほとんどカーネルチーム主導でオーディオチームからの働きかけは無かったらしいとか）。ADC 2023ではthe CLAP developerにもAAPを見せていたので（今年はいなかった）、あとはLV2開発者に見せればフルコンです(違)
• Cmajorの開発者に「Androidで使いたいんだけどビルドできると思う…?」って訊いたら「一度やったことがあるからやってみて出来たら教える」となって、その後すぐリリースに含めるようにしてもらえました(!)　最新版からAndroidビルドも入っています。ただ個人的に動かしたいのはPro-54とかで、これをやるにはchoc WebViewあたりから移植する覚悟が必要そうです。
• JUCEの開発者に「AndroidでプラグインのStandaloneをMIDI 2.0デバイスとして使えるようにしたんだから、同じことをデスクトップでやればいいじゃん?」と提案したら割と好感覚だったので、もしかしたら来るかもしれません。ちなみにuapmdでAllCtrlListを取得できるのを見せて「これもやればできるのでは?」と言ったら「それは方向性が違うかも…」となったので、そっちは来なそうです()

あと他人と雑談しているときはMML to Tracktionでコレからコレを生成したのとか、技術書を売るイベントがあって早く帰らなきゃいけないんだ…こういうイベントでな…とそのまま技術書典を説明したり（「CLAPの本もあるのか!?」みたいになっていました）、そろそろ小ネタは困らなくなってきました。

日本からはDreamtonicsとRolandが出展していて（どちらも半分くらいは「日本から」ではないかも）、あとYAMAHA方面から参加者が来ているという感じでした。Dreamtonicsブースは会場に近かったので空いてるときは便利に立ち寄らせてもらいました(!?)

ADCから帰国したらすぐ技術書典19で（当日来てくださった皆様ありがとうございました）、1週間前に日本にいなくて既刊を自宅から発送できなかったり、当日はスタッフ業もあって早朝から夜まで…という感じでしんどかったのですが、何とか生きてます。今回は「理想のオーディオプラグインフォーマット」にGUIの章を追加しただけで新刊扱いなのですが、在庫切れしたMIDI-CIガイドブックを後から印刷して出すので（紙で売っているのは技術書典期間中だけ）、それだけやれば完了です。おつかれさまでした。

今月は大きなイベントだけでもKotlin Festとか東京楽器博とかJJUG CCCとかFOMとかいろいろ遊びに行ってたので、妙に忙しかったような気持ちでしたが、そんな余裕があったということは割と暇だったということかもしれません(?)

UAPMD & midicci progress

今月はADC参加期間以外の大部分をUAPMD開発に費やしていたのと、GUI関連をAI agentsにやらせて割と「プラグインフォーマットのようにドキュメントのある仕様を実装する」のにはだいぶ役に立つことがわかったので（あと基本APIを自分で策定していて変なものを他所からまるっと持ってこられないことがわかっているので）、今月はさらにいろいろやらせてみていて、だいぶ進展がありました。

先月は「Serum2が動くようになった!」「NI製品がだいたい死ぬ」というレベルでしたが、現時点でremidy-plugin-hostは手持ちのプラグインの大部分をインスタンス生成できています。AU版KontaktがGUI表示でクラッシュするのが目下の最大の問題で、VST3版は問題なく使えています。

各論的に改善点を挙げていくと、こんな感じです:

• だいぶ実装すべき機能が揃ってきたので、問題のある挙動をissuesに登録するようにしました。もう「自分が把握している問題だけでも多すぎて困る」状態ではなくなりつつあります。
• ユーザー向けドキュメントを追加して、開発者用ライブラリ（なのにAPIが不安定）という位置付けから脱却しつつあります。
• トランスポートコントロールが実装されたので、再生中の楽曲の位置情報などをプラグインに渡せるようになりました。remidy-plugin-host上で Play を指示するとSynthesizer V Studioが再生を開始するみたいなことが可能になります（これはGUIだけですが）
• オーディオバスの接続処理が整理され、マルチチャンネルレイアウトも（可能な範囲で）正しい実装を作り直しました。
• Stateのセーブとロードが（全フォーマットで）実装されました。VST3のIComponentとIEditControllerなど複数のStateデータを1つのファイルに含めるためのバイナリフォーマットは、今後変更があるかもしれません。
• パラメーターの列挙型のサポートが整理され、remidy-plugin-host GUI上でも選択できるようになりました。discreteでない列挙値も、スライダーと併用して選択できます。
• パラメーターの扱いを整理して、normalizedとplainのセマンティクスを整理しました。
• プリセットのロードが全面的に可能になりました（ただしプラグインがプラグインAPIに基づいて公開している場合のみ。実例は多くありません）
• パラメーター変更の挙動を包括的に検証し、プラグインUI、プリセットロード、ホストからの直接操作を問わず、DSPを経由して、プラグインUIにもホストにも正しく通知・反映できるようになっています。
• VST3のRestartComponentなどのインターフェースがいろいろ実装されました（パラメーター変更通知のついでのようなもの）
• midicci-keyboardはMIDI-CIセッションの確立とAllCtrlListプロパティの取得、ProgramListの取得を別々の操作によって取得する方式に（暫定的に）移行しました。これが安定的なリストの取得に大いに貢献しています。
• remidyで挙動が安定したパラメーター操作を、midicci-keyboardでも行えるようになりました（float - uint32のみ確認）

上記どの項目もどれももう少し細かく解説したほうが良い内容ではあるのですが、そこに無限に時間を割くわけにもいかないので、気が向いたら書けるものは書いていこうと思います。

だいぶいろいろ動くようになってはきたものの、GUIまわりでいくつか 問題が あるのと、MIDIイベントをどうプラグインに直渡ししつつ他のMIDIイベントをプラグインAPI呼び出しに変換していくのかという問題があるので、来月はその辺を片付けて、UAPMDをMIDI 2.0アプリケーションの基盤として使えるように周辺アプリケーションを整備していきたいところです。

DroidKaigiが終わって、自分が何らかのロールをもって参加するカンファレンスの類が一通りリセットされたのですが、「DroidKaigiが終わったらやる」予定だった作業がいろいろ襲いかかってきていて、あっぷあっぷしています。まあいつも台湾にいる間にやってたiOSDC 2025が今年は9月だったので遊びに行く、みたいな時間はありましたが。

Android Audio: Beyond Winning On It @ DroidKaigi 2025

予告通りDroidKaigi 2025でセッションやってきました。動画（会期中にもう公開されてた!）、スライド、それと事後公開の解説記事があります:

www.youtube.com

speakerdeck.com

zenn.dev

本当はさらに解説記事の英語版を用意したかったのですが、冒頭のような事情で後回しになっています(!)

セッションについての所感は解説記事にちょこっと書いたのでここで追記することはあまりないのですが、やはり全部解説するためには少なくとも2倍くらいは時間が無いと無理だな、という気持ちになりました。たとえばAndroidのMIDI 2.0サポートの意義がどの辺にあるか、みたいな話は完全に省いていますが、90分あれば5〜10分くらいは「オーディオプラグイン機能の肩代わりが標準的な技術で可能になる」ことに言及できたでしょう（そのためにはオーディオプラグインのAPIにどんなものがあるか、みたいな話もしなければならなくなるのですが、これも今回は言及していません）。

AAPのForeground Service対応

DroidKaigiではほとんどAAP自体の話をしなかったのですが（とはいえ「オーディオプラグインが無い」というトピックに大きく言及すること自体が現状ではほぼAAPの話をしていることになるでしょう）、会場でAAPがどんなものか見せられるようにしておくことは必要だと思って、一番わかりやすい例としてDAW = aap-juce-helioの動作クオリティを向上させる作業に取り掛かりました…が、ここしばらくuapmdとmidicciにかかりっきりだったせいで、アップデート作業がAndroidのメジャーリリースとKotlin 2.2のリリースを跨ぐことになってしまい、そこに時間を食われることに…

ここまではKotlin 2.0.x系列と互換性のあるKotlin 1.8のABIで続けてきたのですが、kotlinx-coroutinesがKotlin 2.1 ABIに移行してしまったのを無視し続けるわけにもいかないので、今回あきらめてABIをアップグレードすることにしました。

それからようやくAAPの作業に着手できたのですが、半年くらいノータッチだった間に自分もC++の書き方やAndroidオーディオでいろいろ学びを得たので、いろいろ書き直したい部分が噴出してきています。とはいえ時間が無かったので、とりあえず「最低限動作するDAW」を目指して、めちゃくちゃ今更感がある話ですが、AAPをForeground Service化させました。そうしないとバックグラウンド処理になって優先度が下がるし、最悪いつの間にか落ちてしまうので…。そういうわけで今AAPプラグインのいくつかは（全てではない）利用中に何をできるわけでもない通知アイコンが出るようになっています。

helio-workstation改めhelio-sequencerもひさびさに更新して、現状では最善のバージョンとして動作しています。このDAWもプラグインのインスタンスの扱いがいまいちよくわからないので(!)、もう少し直感的にトラックごとのプラグインを設定できるようになっているDAWがほしいところですが、Androidで動作するOSSのDAWは他にほとんど無いので如何ともしがたいところです。新しく何か移植できるとして、JUCEホスティング依存になるのも微妙なので、uapmdみたいな独自ホスティング機構に基づくMIDI 2.0シーケンサーがほしいという話もあり…（気の長い話）

本当はこのタイミングでktmidi-ciを使ったMidiDeviceServiceのMIDI-CI対応を済ませようと思っていたのですが、ktmidi-ciのAPIがまだ成熟していないのと、Android Native MIDI APIのアプリケーションでも使えるようにするならmidicci統合で対応すべきかなと思ったこともあって、今回は見送っています。uapmdベースのアプリケーションが動くようになった時に、ネイティブ接続したときだけMIDI-CI前提の機能が使えないのはいただけないので…(!?)

ktmidi 0.11.2

2025年9月は、待ちに待ったJava 25リリースがありました。Javaに思い入れがあるという話では全くなく、Java 25は正式版のPanamaが含まれる初めてのLTSリリースなので、これでlibremidi-javacppを切り捨ててlibremidi-panamaを全面的に採用したktmidi(-jvm-desktop)を使ってくれと言えるようになったわけです。正確にはktmidi 0.11.0の時点でPanamaへの移行は済んでいたのですが、「JDK 22はLTSじゃないからやめてほしいんだけど…」と言われていて、こればかりはJavaリリースを待つしか無い、という状況でした。

Java25になったことで実装が大きく変わることはないのですが（Java 22でAPI自体はstableになっているはずなので）、libremidi-panamaはJava 25で動作させたjextractで生成したソースでビルドされています。

これは少し悩んだのですが、Kotlin 2.1 ABIに移行する必然性は無かったのと、Android専用でユーザーがほぼいないであろうAAPとは異なり、ktmidiはどれくらい古いKotlinが使われているかわからなかったので、とりあえずKotlin 1.8 ABI前提のktmidi 0.11系列の最後のリリースとなるでしょう。

本当はこのタイミングでktmidi-ciのAPIをもう少し使いやすくしたmusicdeviceというサブパッケージのAPIを使って、ktmidi-ci-toolを全面的に書き換えたかったのですが、そこまでの時間は作れませんでした。JUCEのjuce_midi_ciもそうですが、MIDI-CIライブラリはどれもまだまだアプリケーションに統合しやすいAPIにはなっていないので、もう1段階高レベルなAPIが構築されるべきだと思っています。現状どのベンダーも実現できていないです。

uapmd: パラメーターとプリセットの再整理

midicciでProgramListをサポートするためには、まずProgram ListをきちんとサポートできるMIDI 2.0デバイスが必要…というわけで、今月はuapmdのProgramListをきちんと使えるようにするための作業を進めていました。

ちなみにmidicciは現状ではProgramListを要求してデバイスからSysExとしては取得できているものの、それをUIに反映する部分が正しく実装されていない状態です。自分で書いているコードではなくClaude Codeに書かせているプロジェクトなので、Claudeがまともに修正できないうちは、（どうせろくでもないコードが生成されているので）自分では読みたくないので後回しです(!)　Sonnet 4.5なら直せるようになっている可能性はあります（今日発表を見たばかり）

uapmdではprogram changeはpresetsに対応する機能ということになっているのですが、そもそもuapmdはプリセット対応機能をろくに実装していなかったので、プラットフォーム中立のAPIを模索するところからスタートしています。大抵のフォーマットではstate APIと連動するのですが、VST3には（MIDI 1.0のProgram Changeも無理やりVST3のAPIで置き換えさせていることもあって）ProgramListという独自のコンセプトもあって、これがパラメーターサポートと連動するものになっています。

VST3のパラメーターサポートを使うところで試行錯誤していて気付いたのですが、VST3以外のパラメーターAPIへのマッピングとそのプラグインでの実際の使われ方もきちんと把握できていなかったので、これを機に整理しました。remidy-plugin-hostというサンプルホストでは、パラメーター設定操作をuapmdの仮想MIDIデバイスが利用するNRPNに置き換えてプラグインインスタンスに処理させていたのですが、これをそのままAUなどに渡しても処理してもらえない（前提が違う）ので、パラメーターAPIを呼ぶかたちに修正…といった、フォーマットごとの対応の確認をやっていました。それでも現状VST3のパラメーターAPIのサポートは機能していない状態で、まだ安心して使えるとは言い難い状態です。この辺は引き続き作業が必要でしょう。

uapmd: native plugin host GUI

それから、プラグインホストremidy-plugin-hostの開発を未成熟なWeb UIの荒野で進めるのはしんどいので、とりあえず各種の問題に目をつぶってImGuiで作り変えることにしました。といってもGUIをゼロから構築するのは面倒なので「既存のWeb UIのソースを見てImGuiに置き換えて」とClaudeにやらせています（それなりに仕事はしてくれたはず）。

ネイティブUIを使うようにしてから、GUIの機能追加は雑にClaudeに投げるようになってしまい、結果的にどっちが原因とは判断しがたいところですが、「GUIをいじるのがめんどくさいから…」という理由で作業が停滞することはなくなったので、これはやってよかったと思っています。

ちなみにImGuiは日本語入力ができないんだよなあ…とbskyでぼやいていたら作者の人から「使えるはず」というreplyが届いて、調べてみたら新しいSDL3バックエンドでは使えるようになっているようでした。ただSDL3は新しすぎてGitHub Actionsのubuntu-24.04 (latest) でも使えないので、i18n-readyになるにはまだ時間がかかりそうです。とはいってもubuntu 26.04が出る頃にある程度完成していればむしろ良いほうかな…?という感じのプロジェクトなので、とりあえずは現状でいきます。もっと高水準のGUIフレームワークに乗り換えるかもしれないですし。ただ、ImGuiを使うことによって、host as pluginとして動かすこともできるようになったはずなので、他に移行したとしても実装は残しておくかもしれません。

10月の予定

10月は差し迫って忙しいわけではないはずですが、M3-2025秋に出展するので新刊を作る作業が発生するでしょう。とはいえ、現時点ではAAP本のバージョンアップくらいで済ませようかなあと考えている程度です。むしろaap-juce-helioやuapmdなど展示できるものを充実させておきたいですね。