|
どシロートによる、オリジナルmidiシステム開発の記録
|
|||
| 関連項目： H8/3664 AKI-H8 PallarellPort増設 VHDL coding はじめに〜 最近は、パソコンとソフトウエアを使えば、様々なものが殆どなんでも手軽に製作できてしまうありがたい（反面、恐ろしいともいえる）時代です。電気工作に関しても、一昔前だったら、ハンダ鏝を握って脂(ヤニ)と重金属の混じったそれはそれは体に悪い蒸気を吸いながら「あーでもないこーでもない」と頭を捻ったものです。 僕が中高生だった当時の世の中は同一規格大量生産の時代であり、汎用性といわれる最大公約数の範疇から外れた特殊なことをやろうと思ったら、それは大変なことでした。何か面白いものを作ろうという情熱があっても、技術や知識の十分な裏打ちが無いシロートが「思いつき」で物を作り始めてしまった場合は悲惨です。中途で方向転換が効かなくなって、全てご破算という道を何回も歩んでしまったものです。しかし、その経験は楽しいものでもありました。荒削りながらも市販品に無い個性的な(I"電子楽器の作品群」を作れたことは幸せだったと思います。大学に入ってからぼちぼちコンピューターに触れる機会が出てきましたが、この時代はまだ９８の全盛期でオーディオへの応用など夢のまた夢でした。懐かしい。 そして、いまもって諦めが悪い僕は音楽を続けています。しかも、街角でギター１本で歌うシンプルなスタイルでもパソコンで完結するいま流行のDTMとも違うニッチな志向です。電化された(死語！？)ソロ楽器の生演奏をコンピュータの支援によって音響的な空間に演出する音楽、、、といえばよいのでしょうか？う〜ん、訳がわかりませんね。乱暴に要約すると「先祖がえり」な音楽かもしれません。ルネッサンス時代は当時最新のハイテク機材であるパイプオルガンなどの(I"楽器」の演奏のために物理的に最良な音響空間を建築したという、今からは考えられないゴージャス(苦笑）なことをやっていました。よく訳のわかんない人が、「ピアノは人間ぽくて自然でいいけどコンピューターとか電子楽器はダメ」なんて馬鹿なことを平気で言いますが、ピアノが出てきた当時はそれこそ最新の機材で最新の音楽をやっていたわけで、年月を経て良いもの（必ずしもそうとは言い切れないところが面白いんですが）が残るのは当然です。それを有り難がって新しいものを貶すのは簡単ですが、それじゃあなんにも面白いことは起こりません。ただ、最近の技術は進化のスピードが速すぎて、新しい何かを使いこなし、習熟することが難しくなっています。オペレーション・マニュアルのみが堆積するむなしい現実はなんとかならないものでしょうか。消費というサイクルから外れてじっくり考えていかないといけないなあと日々痛感しています 発端〜 さて、今回の企画「１６ｃｈスイッチボックスの開発」は演奏経験からの欲求が発端になっています。システム開発は基本的にやすすきいの個人的な演奏活動のために行っていますので、当然の事ながら対象になる楽器として(I"ギター」を中心に考えることになります。通常、ギター演奏を外部でエクスパンドする行為は、殆ど「手の空いている」足で行います。ギターは世の中で最も親しみやすい楽器のひとつなので、足を使ったコントロール・デバイスは楽器メーカー各社によって少なからぬ量が生産されています。ところが、この一見バラエティーに富む選択肢も、現実的には「ポピュラーミュージックにおける使用を想定する」というバイアスがかかっています。コンピューター化が進んで単なるスイッチにも機能を山のように実装できることから、各社製品にはほぼ例外なく分厚いマニュアルが添付され、それこそ何でもできるように錯覚してしまいます。しかし、演奏者のスタイルが想定されているものから外れた場合は、豊富なオプションでも対処できないことがあります。例えば、スイッチを踏んだときに音がしてしまうと いう物理的な問題は、「電気楽器は通常ラウドな音量で使われる」という暗黙の了解から無視されています。実装されるスイッチの個数の制限は、瞬時にアクセスできる柔軟性を制限しますが、これも、「エフェクタ群のプリセットの切り替え」という最大の需要を考えれば、全く問題になりません。要するにフットコントローラーという製品に、静音性や１６以上のアクセス(I%ポートを望んだ場合、自作するしか道は無いことになります。 では、実際のところ自分の欲しいデバイスをどのように開発していけばよいのでしょうか？ここからは、個人的な経験談になってしまいますが、ひとつの選択肢として参考にしてください 自分にあったシステムとは？ システム開発の手法〜 システム開発の手法といえば大げさですが、単純に言えば何をどう使うかという選択です。いま巷にある音響デバイス群をコントロールできる一番現実的な手段はMIDIであるといっても過言ではないでしょう。したがって、方法はわからないけれども、MIDI信号をジェネレートできるモノを作らねばなりません。 オリジナル・スイッチ製作にいたる前の段階で、僕はYAMAHAのフットコントローラーを選びました。これは、外部にフットヴォリュームを数個増設できるうえに、各スイッチにあらゆるMIDIステイタス・シグナルをアサインすることが出来るというかなり柔軟性に富んだデバイスでした。ただ、筐体にはスイッチが１０個しか存在しないことと、構造がプラスティックの箱のために踏み込んだときのアクセス音が大きく、パコンパコンという物理的なノイズを発生することが問題になったので、他のデバイスを探すことになりました。当初は市販品を物色し、RocktronのAll Accessを発見、これの発注を試みたのですが、生産ロットの狭間に遭い時間切れで敢無く購入を断念。家に転がっていた i-Cube を使ったシステムの自作を試みることになります。 i-Cubeは最大３２ｃｈのアナログ電圧をMIDI信号に変換してくれる賢いデバイスです。センサ接続用の端子群に電気的特性が合致した規格でインターフェイスを接続してやれば物事は簡単に解決します。しかし、たまたま家にありましたがi-Cubeは高価です。高価なうえにあまり融通が効きません。設定には必ずパソコン（Mac)を介する必要があり状況に応じて瞬時にMIDIチャンネルやMIDIステイタスの設定変更を行うような使い方はあまり得意ではありません。実際の運用にあたっては、外部電源にACアダプタが必要なことや、端子とスイッチの接続に強度的な問題があったりするので、システムとして完結したものを作るのには向いていないような気がします。ライブ会場での設置の煩雑さや信頼性（かなり怖い)の問題を考えると、新しいシステムの開発が望まれます。ちなみに、i-Cubeの設計思想はどちらかというとインスタレーション支援をメインに考えている感じがします。ステーブルな楽器コントロール用途向きでは無いのかもしれません。また、現在使用しているアクセスポイントにあたるスイッチ群はローランドの安価なフットスイッチの改造版です。スイッチの構造上、物理的な配置に制約があるので、ライブでは毎回セッティングに苦労していました。ライブの期日が迫り、切羽詰った中でのi-Cubeを使ったセンサ開発でしたが、とりあえず１年間の運用で役目を終えることになります。その間に感じたいろいろな不具合と運用経験がオリジナルのMIDIシステム開発に反映されています。 具体的な製作の前に〜 まずは巷で行われている自主制作記事の検索から始めてみました。これが意外とヒットしません。マイクロコントローラー(PIC)系のサイトが引っかかりはするものの、単機能のものが大半で複数の入力を操るものは殆どありません。最終的にはこの業界で有名な長嶋氏のページに行き着きました。長嶋氏はH８を使った音楽用センサの製作記事を多数アップロードされています。ただ、製作にはWindowsマシン、もしくはエミュレータが必要となります。MACユーザーの僕はWindowsマシンの購入を待たねばなりませんでした。 さて、諸般の事情からようやくWindowsノートを購入したのが2001年の10月。翌年1月から3月にかけて渡米していたのですが、その間に筐体の設計(I%試作を行いました。スペース効率を考た結果、筐体のシェイプは正方形になりました。また、アクセスミスを減らすために、各踏面を立体的に構成しました。これは、大正方形の中に16個の小正方形が斜め方向に１，２，３，４，３，２，１個ずつのグループレイヤーを階段状に構成する構造で、目的のスイッチへのアクセス確認を容易にすることと同時に、各踏面間の段差で生じるアングルを利用して、ミス・スイッチングの軽減を目指しています。アングルによって生じる距離を誤差動防止に役立てるため、スイッチにはフォトインターラプタ-による距離センサを選びました。このデバイスは1〜2ミリ単位の精度で特定の距離に反応するセンサでアングルによってミススイッチングをキャンセルするコンセプトには最適です。一方、機械的接点のない構造はスイッチ動作時の静音化にもつながり、一石二鳥です。問題は、フォトインターラプタ-のデバイス選択です。これは設計する筐体との兼ね合いもあって、決定が難航しました。また、光センサの最大の弱点、外乱によって動作が不安定になる問題が実験によって明らかになりました。直射日光下での運用はまず無いにしても、白熱灯に敏感に反応するのはいただけません。比較的安定度の高いデバイス、及び外乱防止のための回路の選定に悩むことになります。筐体の試作はプラスチックで行うことになり、アメリカニューハンプシャー州のダートマス大学工学部の協力を得て、3月に大まかな試作品が完成します。この試作品で、段差による快適で確実なアクセス感を実証できたため、引き続きこのコンセプトの継続を決定。帰国後、工業大学の友人に試作品2号の製作を相談することにしました 内部回路製作への体制が整ったのが3月下旬。丁度東京に出向く機会があったので、友人のN氏に相談したところ、やはりH８を薦められました。それではということで秋月電子にてキットを購入し、製作を開始します。 製作・センサ編 苦手なソフトウエア分野は後回しにして、とりあえず、センサ部分の製作に取り掛かることにしました。ベースになる回路は去年に作った電子オルタネイトスイッチの回路部分と光センサの組み合わせに決定しました。まず、Dタイプ・フリップの74HC74に負帰還をかけ、トグル動作を行います。スイッチの極性はクロック入力のアップエッジタイミングごとに反転します。このクロック入力にスイッチの出力を接続します。スイッチの立ち上がり動作で出力が反転するわけです。今回はスイッチ部に光センサを使い、波形整形のためのシュミット入力コンパレータを、追加しています。光センサにはHP製のHBCS1100を使用します。このセンサはフォトインターラプタ-と呼ばれる製品で、バーコードリーダーが主な使用用途になります。デバイスはメタルキャンタイプの8ピン・パッケージで、可視光波長のLEDとフォトダイオード、バッファ用のトランジスタ、それとLED光を一定の距離に収束させるレンズで構成されています。今回はバーゲン品を一個1000円あまりという格安で仕入れることが出来たのですが、通常は3000円／個という高価な部品です。 さて、このあまりポピュラーではないセンサの使用法ですが、フォトダイオードの感度調整とコンパレータ-入力とのインピーダンスマッチングに気をつける必要があります。まず、パッケージに封入されているトランジスタですが、片電源時の動作にはあまり向かないようです。そこで、ダイオードからの出力を直接コンパレーターの正入力端子で受けるのですが、入力インピーダンスを決定する抵抗値は８MΩ以上必要です。センサ(I%コンパレータ間の配線は、ノイズの影響を考慮して、出来るだけ短い距離にします。コンパレータはヒステリシス値を持った製品で、信号立ち上がり時のチャタリング発生を防止します。スレッショルドの設定は実際の動作から割り出しました。このあたりは、なかなか理論通りにはいかないものです。コンパレータの出力はオープンコレクタなので、ここを680Ωの抵抗でプルアップします。出力は、LED,D-FF,マイクロコントローラーのデータ入力、PGM接続時にスイッチ間の動作のリレーションを行う回路への接続と、負荷がかかります。実験で動作が不安定な場合は抵抗値を下げる必要があるかもしれません。 さて、センサが何とか形になってきたので思い切ってアセンブルコードを書き始めることにしました。とはいっても、シロートなので、何をやってよいのやら殆どわかりません。幸運にも、今回は友人が先生として雛型を書いてくれているのでかなり助かっているのですが、自分の考えている製品の仕様が固まっていないので、あまりあつかましいリクエストは出来ません。先方も多忙なので、とりあえずこの雛型をベースに要求仕様を満たすものを作り始めました。 テキストエディターで書いたコードはDOS窓を開いてa38h.exeというプログラムでコンパイルしなければなりません。DOS窓を開くなんて、学校の授業以来２年ほどやっておりません。（汗）まずは、このプログラムでアセンブルを行ってみるのですが、エラーコードが出て先に進めません。いろいろ試すうちに原因は小文字のLと数字の１のミスタイプであることが判明したのですが、このような凡ミスに気がつくのに丸一日かかってしまいました。これはエラーの読み方を理解していなかったためと、テキストエディターにMS純正のノートパッドを使用していたのが原因でした。これからコードを書く人へのお勧めですが、 Maruo などのちゃんとしたテキストエディターを最初から使用しましょう。これで作業効率がぐんとあがります。 さて、まずは送ってもらったサンプルプログラムを使って焼き込みの開始です。事前に秋月の開発キットを組み立ててあるのですが、MIDIの動作確認のための周辺機器の追加をしておく必要があります。通常、入力部には521等のフォトカップラー、出力部には74HC05などのオープンコレクタのバッファを使うのですが、今回は手持ちのHP製のハイスピードフォトカップラー2430と、Maxim社製のコンパレーター965を使用して、回路をシンプルにしました。2430は２回路なので、今回のようにMIDI入力をマージする用途には最適です。コンパレータは片電源動作保障のあるものが望ましいようです。 用意が出来たので、書き込みを開始します。この時点では秋月のキットに付属していたFlash.exeというプログラムを使いました。現在は更に使いやすいH8WriteTurboというアプリケーションがあるのでそちらを使っています。これらのアプリはアセンブルの過程で生成された.motファイルを読み込み、シリアル端子に接続されたライタに送り込みます。最近のコンピュータでシリアルが無い機種では予めUSB→シリアル変換のケーブルを購入しておく必要があります。アプリからデータを転送すると、変換ケーブルのTx/RxのLEDが点滅して書き込みを確認できます。最初のデバイス確認に手間取る場合がありますが、ライタ側をリセットしたりしているといずれは認識してくれます。デバイスが確認されたら、まず書き込み用のソフトウエアがデバイスに転送され、その後にプログラムを書き込んでいきます。プログラムの書き込み回数は公称では100回程度、実験では200回を軽く越えておりますが（汗）まだ可能なようです。 書き込み終了後に電源を落としてライタのスイッチを切り替え、動作の確認に入ります。とりあえずはちゃんと動いているはずなのですが、かなり挙動が怪しいです。これは端子がオープンになっていることで入力にノイズが飛びついていたのが原因でした。各端子を100K程の抵抗でプルダウンしたところ、動作が安定しました。ただ、AD部は相変わらずノイズの影響を受けています。そこで、この端子を10kほどの抵抗でプルダウンし、ノイズキャンセルのためこれと並列にコンデンサを付加します。今回の仕様では、直流しか扱わないので周波数特性を考慮する必要はありません。従ってコンデンサには10μF程度の大き目の容量を選びます。 動作を確認すると、出力はちゃんと出ているのですが、入力に対する反応がありません。推奨されているデバイスを使っていないことによるトラブルかと思ったのですが、コードをコピーするときに何らかのミスを犯していたことが判明、プログラムを書き換えて問題は解決しました。この例が示すように、アセンブルがエラー無しで問題なく完了しても、バグを内包していることが多々あるのです。この場合は地道に挙動を観察してバグをつぶしていくしかありません ハードウエア側の動作が確認できたので、デバイスにどのような機能を持たせるのか、ひとまず考慮することにしました 機能の設定 １）市販のmidiコントローラー群のような汎用性を持たせることは考えない. ２）コントロールチェンジ(cc)及びプログラムチェンジ(pgm)信号のジェネレートを行う. ３）スイッチの属性は横一列4個をグループとしてコントロールチェンジ・プログラムチェンジを切り替える. ４）コントロール・プログラムチェンジの開始番号はそれぞれプリセット可能。ただし、番号は連番とする. ５）ノート情報は扱わない. ６）外部midi機器からの信号を2chミックス（マージ）する. ７）可能な限り動作スピードを重視する. 以上が当初考えた仕様で、この時点（2002年7月末）では使用スイッチ数は１６でした。 これらの要求仕様からまず想定される問題は、各スイッチの属性の切り替えと番号の割り振りです。例えば、一列ずつ交互にccとpgmにスイッチを配置した場合、単純に番号をカウンタを使って割り振るオリジナルのプログラムでは対応できません。 ここで、問題を判りやすくする為に、後戻りになりますがオリジナル（雛型）のプログラムの説明をします。H8の入力ポートはグループ１から４までの４ポート３２端子をスイッチ入力端子として設計してあります。プログラムではこれらの端子をカウンタで順番にスキャンし、状態の変化があったときのみ信号を出力します。変化が検知されるとまずcc/pgm 信号であるという意味のステータス信号を送信バッファに送り、次にカウンタの値がそのまま出力する信号の端子番号になります。 cc及びpgmのプリセットされた開始番号がこの端子番号にオフセットとして追加され、送り出されます。その後、変化の方向によって、ゼロになった場合は数値０を、１になった場合は、１２７を出力に送ります。（コントロールチェンジ信号の場合は以上３ステップでデータが送られることになります）スイッチのセンシング部分はこのようなルーティンで信号を生成しているのですが、扱う端子の単位が８bit毎であるために、想定する仕様のようなcc/pgmの混在するシステムにおいて必要とされる４bit単位の運用には難があります。つまり、歯が抜けた分のカウントをどのように行うのかが問題になるわけです。 番号振り分けのための条件分岐など、いろいろと考えたのですが、構造が煩雑になるうえに上手く動作しそうにありません。この時点で作業は行き詰まってしまったのですがたまたま横浜に滞在したときにプログラマーのA氏(大先輩です)にこの件を相談に乗ってもらうことが出来ました。midiのことを知らない彼に機材の仕様を説明するのは大変だったのですが、こちらの要求を理解してもらった後、ルックアップ方式を提案していただけました。予めROMに参照用のテーブルを作り、そのつどそれを読みに行く方式です。この場合カウンタで示された場所にこちらの想定するデータを書き込んでおけば、混在するスイッチ・ステータスで番号を捌くことが出来ます 実際にプログラムを書く上で問題になったのが、データのフォーマットです。H8はロングワードを扱えるため、当初は32ビットでの処理を想定していました。ところが、これが何故か上手くいきません。32端子分の処理を一気行うには無理があったようです。 swaddr15: .data.b 1, 1, 1, 1, 1, 1, 1, 1 .data.b 0, 0, 0, 0, 0, 0, 0, 0 .data.b 1, 1, 1, 1, 1, 1, 1, 1 .data.b 0, 0, 0, 0, 0, 0, 0, 0 swnum15: .data.b 1, 2, 3, 4, 5, 6, 7, 8 .data.b 1, 2, 3, 4, 5, 6, 7, 8 .data.b 9,10,11,12,13,14,15,16 .data.b 9,10,11,12,13,14,15,16 扱う端子は１ポートごと８ビットを１グループとし、ポート選別用(合計4カウント）と端子選別用(32カウント）の二つのカウンタを使い分けてスイッチ入力ポートをスキャンします。１ポートスキャンをルーティンとして廻し、スキャン終了毎に次のポートに移るのですが、ポートのデータレジスタがロングワードのために実際のカウンタアドレスは４ずつ増加します。 とまあ、こんな感じで第一の難関アセンブルプログラムはなんとかクリアすることが出来ました。 |
|||
