自作フットスイッチ・システムとKYMA・VCSのリレーション
KYMAはCMLab社のMotorMixを標準でサポートしている。 MotorMixは、90年代の終わりに登場した比較的安価なインターフェイスで、 MotorDrive フェーダーを実装した画期的で息の長い製品だ。これ無しにライブは不可能、と言い切るのは少し大袈裟だが、非常に便利な機材であることは間違いない。

ところで、僕のライブではMotorMixと共に、自身で製作した階段状のフットスイッチを使用している。スイッチ自体の動作には満足しているのだが、演奏中に時々戸惑うことがある。それは、ProgramChangeでVCSのシーンチェンジを行った際に、予めプリセットされたVCS上のスイッチの状態とフットスイッチ本体にLEDで表示されているスイッチのステイタス情報が、一致しないことだ。この問題をフィックスするためにはVCSの状態をフットスイッチ側に反映する何らかの仕掛けを作る必要がある。2004年、MotorMix社がMotorMix関連のMIDIプロトコルを公開したことを受けて、マイコンによるデータ受信・復調システムを工作することにした。
KYMA側のPreferenceでMotorMixの使用を選択している場合、Capybara のMIDI端子からは常にMotorMix用のコントロールデータが送信される。このデータのうち、MotorMix中央にあるLED群32個分の点滅情報をフットスイッチのOn/Offステイタス情報として流用する。

  □□□□□□□□  MotorMix上面中央からみて。この列のLEDは無視する
  ○○○○○○○○  これはロータリーエンコーダー。
この部分のデータも無視
  @ABCDEFG  この列のLEDからOn/Offのデータをフットスイッチの表示に対応させる。
  @ABCDEFG  正方形の4×4のマトリックスが左右バンクに別れているという設定をとる。
  @ABCDEFG  データ上では横一列の連番になっているところを、マイコンのレジスタ上で
  @ABCDEFG  
並べ替え、左右個別ののスイッチ・プリセット用データとして再構築する。

まず最初に、VCS上で設定するスイッチの位置を調整し、MotorMixのLED群と動作を一致させる。VCSでインターフェイスの形状をスイッチとしてプリセットした場合、そのステイタスは自動的にMotorMixのLED点滅情報として送信される。注意する点は、表示形態を優先してVCS側のスイッチを Switch_Fill に設定した場合、VCS側からはオルタネイト動作が一切行えなくなることだ。当然、VCSからもオルタネイト動作は(ハングアップ防止から)行えないので、オルタネイト/モーメンタリー動作の設定は、唯一フットスイッチ側から行うことになる。

VCSとMotorMixのリレーションを確認した後、フットスイッチをプリセットするためのマイコン・プログラミングを行う。要求される動作は、MIDI受信後に、LED点滅用のプロトコルを選別、結果をスイッチ駆動用LSI(CPLDで作成済み)のプリセット端子に入力する、といったところで、これに合わせて細かい仕様を決定していく。

仕様を決定する上で最初の問題点は、スイッチのプリセット情報をどのような時期に確定するか、そのタイミングの設定にある。VCSとMotorMixの動作を観察すると、シーンチェンジを行った直後のVCSの状態は画面全体が一気に変化する事はなく、左上方のデータから順を追ってスキャンしていることが判る。これは、グラフィックの状態変化をトリガーにイベントが発生し、それが順を追ってMIDIデータに反映されていることを示唆している。この事例から推測されることは、音響処理の全てをDSPをに依存しているKYMAではあるが、ことVCSに至ってはPC側の処理能力がVCS周りの動作速度を左右すると言う点だ。つまり、PCの速度差によってデータの確定時間にばらつきが出てしまうのだ。 

次に考慮する点はデータのロックアップである。 MotorMixはVCS(Capybara)→MotorMix→KYMA(Capybara)というMidiLoop内での使用を想定している。当然、ロックアップの危険があるため、MotorMix用のプリセットデータはMotorMixの下流には流れる事はない。しかし、FootSwitch使用時にはこれが、VCS(Capybara)→MotorMix→FootSwitch→KYMA(Capybara)というルーティンとなり、MortorMixで堰き止めたデータはFootSwitchで復活してしまう公算になる。つまり、FootSwitch側でデータを堰き止める機構を作らない限り、データのループが出来てしまうのだ。

以上のことを鑑みて、FootSwitchのプリセットデータ読み込みのタイミングは、FootSwitch本体から中継するProgramChange信号の発生タイミングをリタードして行うことを想定した。以下に信号の流れを説明していく。

まず、FootSwitchは接続されたProgramChange信号発生用のデバイス(MidiMouse、及び、FootSwitchのスイッチをProgramChange信号にプリセットした場合)からの信号を受け、Midi信号を中継する。この時にFootSwitch内のマイコンはProgramChangeStatusを判別し、フラッグを立てる。中継されたMidi信号はCapybaraに到達、VCSのシーンチェンジを行う。この間、FootSwitchのマイコンではフラッグをトリガーとしてWDT(番犬タイマー)が作動し、FootSwitchコントロールLSI用のデータラッチ信号を発生させる。一方、KYMA側ではVCSの状態が段階的にシーンチェンジに反映し始め、それに伴ってMotorMixのLED点滅データが送信される。 FootSwitch側ではKYMA側の状態に関係なくプリセットされたパルス幅を経過した後、データラッチ信号がリセットされる。 つまり、ここでSwitch側で設定されているパルス幅は「あくまで見込み」時間であって、パソコンの処理能力を反映したものではない点に注意しよう。

さて、マイコンのプログラミングであるが、こちらは、FootSwitch本体用マイコンの改変と、受信専用のマイコンの新設、この二つの作業が必要となる。まず、オリジナルのマイコンには、ProgramChange信号のステータスを検知し、WDTを作動させるルーティン、トリガー発生用のデータポート、及びパルス幅設定用のロータリーエンコーダーと入力ポートを追加する。今回はあと一台、データプリセット用のマイコンを増設する。こちらは、KYMAから送られてくるMotorMix用のデータを検知/復調し、その状態をポートに出力している。バッファーの容量設定を1kバイトとすれば、遅延は殆ど生じないようだ。

下の表がMotorMixのLEDを点灯させるためのアドレスである。MotorMixのデータはヘッダーがB0となっているて、Midiチャンネル#01のコントロール・チェンジ用ステイタスバイトと誤認する恐れがある。結果として、MotorMixはMidiチャンネル#01を占有することに注意しよう。

CENTRAL CHANNEL SECTION:
CENTRAL CHANNEL SECTION
L.E.D. ON/BLINK
L.E.D. OFF
MUTE (1 thru 8) B0-0C-(00thru07)-2C-(42/52) B0-0C-(00thru07)-2C-02
SOLO (1 thru 8) B0-0C-(00thru07)-2C-(43/53) B0-0C-(00thru07)-2C-03
BYPASS (1 thru 8) B0-0C-(00thru07)-2C-(44/54) B0-0C-(00thru07)-2C-04
REC/RDY (1 thru 8) B0-0C-(00thru07)-2C-(45/55) B0-0C-(00thru07)-2C-05



実際とのところ、僕はプログラミングに関してはシロートなので、プログラムを公開することに気が引けてしまうが、怪しげな構造ながらもひとまず動作を確認出来たので、勇気ある人は今後の工作の参考にして欲しい。

まず、下敷きとなるプログラムは、以前作った階段スイッチボックスのものを拝借している。ただ、このプログラムには、受信した2chのMIDI信号をマージし、スイッチボックス本体に入力される8chのアナログ信号と、32chのデジタル信号をミックスして送信するという多機能なものなので、このうちのMIDI受信1chを除いて、全ての機能を割愛している。代わりに追加されるのは、MIDIデータ受信部分のMotorMix用データフラッグ識別・判定機能と、受信データを反映する32chのデジタル・出力ポートとなる。

MotorMix 用の MIDI 信号の判定を行うには、最初に受信・復調した信号のヘッダー "B0-0C" に注目する。 "B0" を検知した後、先頭データの受信を示すフラッグが立てられる。次に送られてきたデータが "0C" の場合次のフラッグを立て、そうでなければ、最初のフラッグを含めて消去する。その次に来たデータ "00〜07" で、スイッチの「列」を確認、オン、オフ情報を次の次に来るデータ "42 or 02" で判定して、スイッチの状態を確定する、、、という流れとなる。

実際に組み立てたマイコンでKYMA との連動試験を行ったところ、予想通り幾つかの問題点が判明した。その最大のポイントは、KYMA の VCS から出力される MotorMix の LED 点滅用プロトコルのデータ確定方法が厳密には存在しないことでだ。VCS と Capybara はスクリーンショットの切り替えを外部からの program change message を受信後に Firewire を経由してを行っているが、受信確定後に MIDIが出力される仕様ではないと思われる。そのため、前述したようにデータ確定のタイミングはローカルで決定(推定)する事になる。また、VCS のスピードはホストコンピ ューターの処理能力に依存するので、受信部でデータが確定するタイミングを推定する事は難しいのだが、Pentium 3/600Mhz の環境ではおおよそ2秒、余裕を見て3秒あまりの遅延を測定した。一番確度の高 い方法はVCSの表示を見て手動でプリセット読み込みトリガーを発生させる事だが、ライブ演奏時にはある程度自動化し、作業を単純化したシステ ムの方がよいので、プログラムチェンジ信号そのものをトリガーにする事を考えた。 問題は、VCS の遅延時間設定だ。VCS スクリーンショット切り替えトリガーの発生から、プリセット・ データがスイッチに降りてくるまで MIDI 信号は信号ループを一巡することになるのだが、その間も MIDI 送受信用 H8 の内部ではデータが処理されている。処理の遅れを発生させないためには、遅延時間の計測をメインの処理ループから分離する必要があるのだ。今回は遅延時間計測用に WDT(番犬タイマー)をインターバルタイマーとして使用している。ただ、WDT は8ビットカウンターで構成されているために、マスタークロックの分周設定を最大値の4096 にセットしてもフルスケールで 40ms 程度の遅延時間が得られるに過ぎない。そこで、カウンターオー ヴァーフロー毎のインターラプト時に6ビットの時間計測用カウンタを廻すことで、最大2.5秒の遅延時間を獲得し、WDTオーヴァーフロー64カウント分のインターラプトを終えた後、データ取り込み用のトリガーを発信する。

その他、MotorMix の下流には LED 点灯メッセージが流れてこないので、MotorMix 本体を改造して Midi Thru 回路を追加する必要があった。配線は未使用の DIN 5pin の空き端子1番と3番を使用する。 MotorMix と併用しない場合はクロスケーブルを自作する必要がある。 ディテクトからスイッチプリセットまでのシーケンスを説明すると、、、、

1) H8 MIDI 送受信デバイスの    
   A:フットスイッチのプログラムチェンジ割り当てスイッチにアクセス   
   B:もしくは MIDI 入力端子に外部入力されたプログラムチェンジ信号を検知

2) A:スイッチ状態判定ルーティン内でプログラムチェンジ出力を識別
   B:外部入力の MIDI 受けルーティンでプログラムチェンジ信号を選別

3) プログラムチェンジ信号発生フラッグに書き込み

4) フラッグ検知後、リトリガーが可能なように、スタートルーティン頭でタイマーのリセットを
   行った後、WDT をスタート。マイコンのバックグラウンドで2.5秒(タイム可変)をカウント

5) 一方、スイッチ・プリセットデータ受信部(H8別体)で、MotorMix 用の LED 点灯デー
   タを受信、スイッチ本体のプリセットデータポートにデータをアップロードする

6) アップロードには KYMA の VCS(ヴァーチャルコントローラー)の状態が反映されるため、
   約2秒あまりの遅延が生じる

7) タイミングリタードされたトリガーをスイッチコントローラー(CPLD) のプリセット クロック端子
   に入力。プリセットデータがスイッチの状態に反映される。

というルーティンになっている。



焼き込み用 .MOT ファイルのH8/3052版のダウンロードはこちら。右クリックでリンク先を名前を付けて保存すればよいだろう。

より小型の H8Tiny/3664版のダウンロードはこちら。何れのプラットフォームでも動作は確認済みであるが、3664版はRev.1なので動作が不安定かも知れない。

MotherBoardには秋月電子から発売されているAKI-H8の3052版の使用を想定している。このボードを使う場合、
RS232C関連の配線パターンに若干の変更を要するので注意して欲しい。ライティング用のソフトウエアは、AKI-H8に付属している。

ただし、このプログラムの使用に於いて発生する如何なるトラブルに関しても、当方は一切関知しない のでその点はご了承頂きたい。