CC 102 = 100 と表示する MIDI モニタは、正確ですが、あまり役に立ちません。Korg opsix では、CC 102 はオペレーター 1 のレベルです。別のシンセでは別の意味か、何の意味もありません。機材が何を伝えているかを理解するには、モニタの横に取扱説明書を開くことになります。
MIDIFabric は、その知識をデバイス定義に持たせています。1 台の楽器の MIDI を記述した JSON のファイルです。モニタ、MIDI Debugger、アプリのほかの道具が同じ定義を読むので、一度足した名前が、どこにでも表示されます。
CC に名前を付ける
opsix のコントローラーは、opsix、opsix SE、opsix module、opsix mk II の定義が共通で読み込むライブラリのファイルにあります。CC 102 はこう書かれています。
"102": { "name": "OP1 Level", "category": "Operator", "range": [0, 127] }CC 103〜107 も、同じ形で OP2〜OP6 Level です。番号は、Korg の取扱説明書と MIDI インプリメンテーション・チャートから取りました。この定義が opsix のポートに割り当てられていると、モニタにはこう表示されます。
OP1 Level(#102) = 100名前が番号の代わりに表示され、CC の番号も括弧の中に残ります。コントローラーには、値の意味(ラベル)も書けます。たとえば opsix の Glide Mode は、値をモードの名前に対応させているので、モニタには数ではなくモードの名前が表示されます。ラベルのない値は、数のままです。
どの定義を、どのポートに使うか
MIDIFabric は、ポートに使う定義を次の順で決めます。利用者が自分で選んだ定義、機器が MIDI の識別の問い合わせに返した答え、ポートの名前、の順で、どれにも当てはまらなければ定義なしです。定義のないポートでも、Modulation や Sustain のような一般的なコントローラーは、標準の名前で表示します。
4 つのメッセージを、1 つのパラメータに
128 の CC で足りないパラメータには、NRPN を使うシンセがあります。NRPN の 1 回の変更は、4 つの CC に分かれています。CC 99 と 98 でパラメータを選び、CC 6 と 38 で値を送ります。普通のモニタでは 4 行が並び、頭の中で組み合わせることになります。
MIDIFabric は、これをまとめます。ポートとチャンネルごとに CC 99 と 98 で選ばれたパラメータを覚えておき、CC 6 と 38 が届いたら 1 つの値にまとめます。定義では、パラメータを 2 つの選択の番号で名付けます。Sequential Prophet Rev2 の例です。
"0:36": { "name": "VCA Env Release", "range": [0, 127], "category": "Amp Envelope" }CC 99 = 0、CC 98 = 36、CC 6 = 0、CC 38 = 8 は、1 行になります。
VCA Env Release = 8
その行を開くと、元の 4 つのメッセージが見えます。まとめ方は NRPN の一般的な決まりに沿っています。選択の番号 127 / 127(ヌル)はパラメータの選択を解除し、選択の後 0.5 秒以内にデータが来なければ選択を忘れるので、後から無関係な CC 6 が届いても結び付けません。MIDIFabric が送ったメッセージも、受け取ったものとは別に、同じようにまとめます。
定義を編集する
付属の定義をコピーしてアプリの中で編集することも、自分で書くこともできます。同じ ID の付属の定義より、自分のコピーが優先され、コピーを削除すると付属の定義に戻ります。アプリで保存した変更はすぐに反映され、アプリの外で編集したファイルは次の起動時に読み込まれます。MIDI Debugger でメッセージを入力するときも、同じ名前が補完の候補に出ます。
MIDIFabric には、今のところ 31 台分のデバイス定義が付属しています。すべての定義は、検査ツールで構造と一貫性(ID、読み込み、CC と NRPN の番号と範囲、SysEx の形、メーカー ID)を確かめています。ただし、定義が楽器と本当に合っているかまでは、検査ツールでは証明できません。それは、メーカーの資料と、できる限り実機で確かめます。opsix の CC の番号は Korg の資料と照合しましたが、実機ですべてのつまみを操作して確かめたわけではありません。
なぜこう作ったか
MIDIFabric は、機材についての知識をアプリの中に作り込んでいません。opsix の CC 102 が「OP1 Level」であることも、アプリのコードではなく、デバイス定義というデータに書いてあります。アプリは、そのデータを読んで動いています。
そのため、定義を直したり足したりすると、アプリを作り直さなくても、モニタの表示も MIDI Debugger の補完も変わります。アプリの中で保存すれば、その場で変わります。付属の定義と利用者が書いた定義は同じ形式で、同じ仕組みで読み込まれます。手元の機材の定義が付属していなくても、自分で書けば、付属の機材と同じように扱えます。
デバイス定義は、MIDIFabric とは別に、オープンソースで公開する予定です。アプリのコードから切り離したデータなので、MIDIFabric 以外の道具からも使えるように設計しています。
エフェクトも同じ考え方です。付属のものも利用者が作るものも、同じ Lua のプログラムです(「AI に MIDI アプリを扱わせる、Mac の外へ出さずに」)。機材の知識はデータとして、振る舞いはプログラムとして、アプリの上に載せていきます。MIDIFabric は、そうした部品を足して育てていく場所として作っています。
同じ考え方を SysEx に広げたのが、「JUNO-D の SysEx を名前で送り、名前で読む」です。