機体を追加する
機体を測定する前に、確定させておくことです。測定プロトコルが測定の段階を説明するのに対し、ここでは段階 1 を走らせる前に、機体とその記録がどういう状態になっているべきかを説明します。
識別子とディレクトリ
機体は <manufacturer>-<model>-<n> の小文字で識別し、そこから測ったものはすべて data/units/<unit-id>/ に置きます。末尾の番号は同一モデルの 2 台を区別するためのもので、このアーカイブはその場合のために作ってあります。測定が記述するのはモデルではなく、その測定を採った個体です。
そのディレクトリの下には、測定段階ごとに 1 つのサブディレクトリを置きます。名前は、その中の記録を書いたコマンドです。sweep/、write-probe/、alias-scan/、contrast/、block/、そして soundings --help が挙げる残りのコマンドです。記録は、それを生成したコマンドの下に置き、何についてのものかで名付けます。つまり、その測定が対象としたアドレス、ブロック、エフェクトタイプ、コントローラで、16 進の大文字・小文字は記録の中身の書き方に合わせます。アドレス空間の一部ではなく全体をカバーする測定は whole-map.json です。
段階ディレクトリのうち 1 つは測定を持ちません。watch-set/ は、その機体自身のスイープ記録とオフセット記録から組み立てたもので、以降の段階がどのアドレスを見張るべきかを述べます。他と同じく「それを書いたコマンド」の名前を持ち、各ファイルは自身の言葉で「これは測定ではない」ことと、何から作られたかを述べます。元の記録が変わったら作り直してください。古いままの集合を狙った段階は、その機体がもう当てはまらない空間で範囲を区切られます。
段階ディレクトリと同じ階層に、ファイルを 2 つ置きます。これらは測定ではなく機体そのものについてのものだからです。meta.json はその識別情報、measurements.json はその機体について確定した挙動で、こちらは手で保守します。3 つめの index.json はディレクトリの中身の一覧で、こちらは生成物です。soundings index data/units/<unit-id> --out data/units/<unit-id>/index.json で書き直され、中身と食い違っている間はテストが落ちます。
何が見つかったかでファイルを名付けることはしません。判定を名前にしたファイルは、開く前から信じてもらう必要があり、次の機体では別の名前になり、記録を出し直せば嘘になります。
電源を入れる前に
背面の定格表示を読み、書いてあるとおりに記録してください。 型番のサフィックスとシリアル番号は、読めたとおりに記録し、解釈を加えません。仕向地や電源仕様のバリアントを示すサフィックスは、定格表示の表記のまま specifications_claimed に入れます。
バックアップ電池を確認してください。 測定する価値があるほど古い機体は、内部電池が切れているほど古い、ということでもあります。問題は設定が失われることではありません。電源投入時の状態は、すべてのリセット測定を比較する基準であり、他の機体と比べるときの土台でもあります。電池切れのせいで電源投入時の状態が違っている機体を測ると、その個体の故障を、モデルの性質として記録してしまいます。いったん基準として採ってしまえば、両者はもう区別できません。
電池の交換が必要なら、最初の電源投入時の状態を取得する前に交換します。
MIDI 経路の往復
自己診断に通ったことは、機体が受信できている証拠になりません。このアーカイブのある機体は、背面セレクタの 4 ポジションのうち 3 つで、DIN MIDI IN が音源部まで届きません。一方、MIDI OUT はどのポジションでも Active Sensing を出し続けます。外から見ると、送信側が何も送っていないだけの、正常な経路に見えます。セレクタは電源投入時にしか読まれません。
MIDI が往復することを明示的に確認し、使ったセレクタのポジションを meta.json に記録します。
どのアドレス空間に応答するか
機体は複数のモデル ID に応答しうるものです。モデル ID ごとに別のアドレス空間があり、同じ 3 バイトがそれぞれの空間で別のものを指します。この機体がどの空間に応答するかは、スイープより前に、問い合わせて確定させます。スイープは 1 つの空間に向けられるものなので、誰も問い合わせなかった空間は、何も失敗しないまま、アーカイブから抜け落ちます。
rye run soundings --model-id <id> read <address>公開された文書が複数のモデル ID の下にブロックを挙げているなら、まずそれを試します。文書が挙げているのは探す場所であって、そこにあるものの境界ではありません。応答したモデル ID をすべて meta.json の識別返答の隣に記録し、問い合わせて応答しなかったものも記録します。否定は、それを生んだ問いと一緒でなければ使えないからです。
最初の測定
最初のいくつかの段階が、以降のすべての基準になるものを確定させます。そのうち 2 つは、後からやり直せません。
- 電源投入時の状態。どれか 1 つの段階が機体へ書き込んだあとでは、もう取得できません。
repeat。音の検出下限を確定させます。2 台の機体を比べるとき、比較の精度は両者の検出下限のうち悪いほうで頭打ちになるので、両者の差を主張する前に、この数値が揃っている必要があります。
記録の適用範囲
測定が記述するのは、その測定を採った個体です。所見は、その個体について、あるいは実際に測定した個体群について書きます。測定していないモデル、ファームウェアリビジョン、製造ロットについては書きません。
meta.json は Identity Reply、機体が報告するファームウェア情報、定格表示、測定経路、関係する機体側の設定を持ちます。機体が使える情報を報告しない場合——たとえばソフトウェアリビジョンが全ゼロの場合——記録はその項目を空けるのではなく、ファームウェアが特定できなかったと明記します。