atsushieno/ktmidiにMIDI-CIの機能をあらかた実装していた経験をもとに、しばらく時間をとってM3 2024春および技術書典16に向けて新刊「MIDI 2.0 MIDI-CIガイドブック」を執筆していた。並行してktmidiでMIDI 2.0トランスポートのプラットフォームMIDIアクセスAPIサポートを追加していたこともあって（これについては先日書いた）、これでMIDI-CIを含むMIDI 2.0関連技術は（USB-MIDI 2.0など個別のトランスポートを除いて）だいたい理解したと思う。
目次等はこちらから:
そういうわけで、今回は同書の宣伝として、本書はどんな知見を提供する意図で書かれているものなのかを解説したい。
MIDI 2.0の一部とされるMIDI-CIは、具体的に何をしたいのか、何ができるのか、よくわからない仕様だった。従来のMIDI 2.0仕様の解説を見ても「双方向的なやり取りができる」とか「MIDI2はMIDI1と後方互換になっている」など、あまり具体的ではない「ふわっとした」ものが大半だった。これはもちろん従来の解説が理解不足で書かれていたという意味ではなく、MIDI-CIで規定されるProfile ConfigurationやProperty Exchangeの具体的な応用が未整備だったために、基本的にMMAの発表をそのまま流すしかなかったはずなのだ。
MIDI 2.0の技術を採り入れることで具体的に何ができるようになったのかを説明できる人は、実のところ今でもあんましいないと思う。実態とはかけ離れた説明になってしまうこともある。わかりやすい例が「MIDI 2.0になると256チャンネルが利用可能になる」だ。202x年代のわれわれにとって、MIDIはすでに楽曲配信フォーマットではないし（MMAは楽曲のパッケージとしてのSMF2をまだ仕様策定できていない）、1つのチャンネルで1つの音色を割り当てて256音色使える!といっても響かない。純粋なMIDI 2.0対応デバイスなら不要だが、MPEデバイスは1音色で1グループ16チャンネルを消費したりする。MIDI 2.0なんて使わなくても、DAWを使えばトラックごとにチャンネルの限界を意識せずに打ち込みが可能だし、そもそもMIDI 2.0は256チャンネルを出力として利用可能にするための仕様ではない。これはFunction BlockとUMPエンドポイントのコンセプトについて理解していれば分かるかもしれないが、多分そんな人は滅多にいない。かくいう自分も最近までちゃんと理解していなかったし、MIDI 2.0が「こういう」仕様として公開されたのは2023年なので、MIDI 2.0の概要が公表された2019年当初から今のように理解していたらそれは予知能力者だ。
「MIDI-CIで楽器固有のプロファイルを実装した楽器には専用のコントローラーを割り当てることができる」というのもよく言われるけど、具体的なプロファイル仕様が存在せず、存在しないものを実装した楽器も無いのでは単なる画餅だ。いや正確に言うと、「ドローバーオルガン」と「ロータリースピーカー」の仕様は存在する。でもそれだけだ。他は従来のMIDI 1.0時代の仕様（GMやMPEなど）をMIDI-CIプロファイルとして組み込んだ程度のものしかない。
一方で、MIDI-CIプロパティは完全に単なる画餅というわけでもない。プログラムリストやコントローラー情報といった具体的なプロパティ仕様は標準として策定されていて、これらは実装さえあれば今すぐにでも相互運用できるといえる。現状で最先端と言えそうなのはKORGのKeyStageだと思うけど、KORGが公開しているKeyStageサポートファイルのProperty Exchange MIDI Implementationを見ると、標準の音色情報としてのProgramListはサポートされていて、どんな接続先でもやり取りできる一方で、標準のコントローラー情報であるAllCtrlListなどはサポートされていない（代わりにX-ParameterListという独自のパラメーターリストが実装されており、要するにこれを実装しているKORG製品としかやり取りできない）。
（これは多分良い側面と悪い側面があって、MMAによって標準化されれば全てのMIDI 2.0ソフトウェアが対応するデフォルトの選択肢として強力な存在になるし、逆にMMAの鈍重な委員会仕様策定が進むまではMIDI 2.0技術を採用しても現実的に使い物にならない可能性がある。）
プログラムリストを取得できるとかコントローラーの名前とかパラメーターの値域を知ることができるなら、それは進化なのだけど、オーディオプラグインの世界ではプリセット名やパラメーター名は当然のように取得できるので、あるオーディオプラグインのフォーマットの範囲で完結するやり取り（たとえばDAWとプラグインやり取り）であれば、MIDI-CIは何も付加的な価値をもたらさない。MIDIに基づく技術でも、MIDNAMを使えばかなりの情報が得られる。MIDNAMは全てではないが多くのDAWで採用されている。MIDI 2.0よりは普及しているし今すぐ使える。（追記: もちろん「MIDIプロトコルに乗せて相互運用できる」レベルではないので、MIDI-CIの完全な代替技術にはならない。限られた文脈での代替技術の話）
…といったようなことが、本書を書いていく過程でわかるようになった。これはMIDI-CI仕様と呼ばれるドキュメントだけを見ても理解できないと思う。Common Rules for MIDI-CI Profilesというプロファイル共通仕様、Common Rules for Property Exchangeというプロパティ共通仕様を理解して、その上で各論的に規定される個別のプロファイル仕様やプロパティ仕様を知ることで、ようやく具体的な目的と何が（仕様上）実現できているのかを把握できる。仕様書というものは正しさファーストで書かれているので、それとは別に、前例などを紹介しつつ、なるべく理解しやすくまとめたものがあるべき、というスタンスで本書は書かれている。「Get and Set Device Stateプロパティ」という仕様を説明無しで出されても大抵のMIDIユーザーには理解不能だと思うけど、「オーディオプラグインでも実装されている『状態』の保存と復元に相当する機能をMIDI-CIで実現したやつだ」と説明すれば理解できる可能性が高くなる。本書にはそういう説明をいろいろ盛り込んでみた。
本書ではMIDI-CI仕様に沿った具体的なSysExメッセージのやり取りについても解説しているし、MIDI-CIツールを使ってその具体的なやり取りを確認できることも示している。本書にひと通り目を通せば「MIDI 2.0よくわからん」っていう人が「MIDI 2.0完全に理解した」と言えるくらいにはMIDI 2.0が理解できると思う。
本書はMIDI-CIガイドブックという書名ではあるけど、実際にはUMP仕様の一部となったプロトコル制御まわりの話も付録としてまとめてあって（しかも割と量がある）、ここには2023年6月のアップデートで追加されたFunction Blockなどのコンセプトの解説なども含まれていて、MIDI 2.0デバイスを構成するとはどういうことかというレベルの疑問もそれなりに解決できる内容になっていると思う。
Initiatorの機能はむしろResponderより後に作り始めたものだったのですが、UIを含むアプリケーションとしての機能はむしろResponderより先にざっくり出来上がってしまいました。Responder側の機能は昨日ようやく開発が始動した感じです。年始の暇な時間に作り上げようと思っています。