シーケンサのUIとデータ構造
(あとでちゃんと書く)
ゲームBGMとシーケンサ
非常に特殊なケースを除いて、近年のゲームはBGMの演奏にゲーム内シーケンサを使用していない。
筆者を古くから知る人はご承知のとおり(笑)、MIDI(Musical Instrument Digital Interface)は実は筆者の専門分野でもあるので細かく聞いてみたところ、グラフィックスに影響を与えるイベントデータはMIDIのコントロールチェンジ(Control Change)を使用しているという。
Child of Eden(や、その前身に相当するDreamcastのRez)は例外的にゲーム内にMIDIベースのシーケンサを持っており、ゲームプレイと同期して動作させている。
他に、楽曲フレーズを組み合わせて戦闘BGMをリミックスする試みもある
「R.A.H.」は戦闘中の状況変化に呼応するように、場面に合った楽曲をリアルタイムに組んでいくシステムです。楽曲の元素材は4小節の区切りを1つのデータとして膨大な量が用意されていて、コーラス、ボーカル、インスト、リード、リズム、エクストラなど様々なタイプが存在します。
CoEやアルトネリコのケースは、ゲーム中のフレーズ素材を順番に鳴らすためにシーケンサを使っているに過ぎない。
しかし、従来のゲーム機は本当に一音一音をソフトウェアで制御して鳴らす必要があった。これはBGMをPCMで格納するだけのストレージの余裕が存在しなかった事に因る。
ゲームBGMフォーマット
ゲームにBGMが付いた時から、BGMのためのデータ構造はかなり考察されてきた。実はファミコンぐらいまでの世代のゲーム機では、ゲーム内でのBGMの鳴らし方は個々の工夫に任せられており、BGMを鳴らすためのライブラリ等が提供されなかった。BGMを鳴らすためのライブラリ(= 音源ドライバ等と呼ばれる)はメーカー内で使いまわされていたことも多かったため、"コナミの音"とか"サンソフトの音"のようにメーカー毎の個性となっていた。
ロックマンのBGM構造を解析した資料がある。
このロックマンのBGM構造を簡単に分類すると
- チャンネル毎に独立した構造
- フレーズ志向でない
- コマンドベース(可変長)
- インストゥルメント(楽曲と独立した音色データセット)無し
のように分類できる。
この４分類は個人的な分類で、多くの音源ドライバはこの分類に落としこむことができると考えている。
固定長 / 可変長、コマンドベース
原始的な音源ドライバは、固定長の楽曲フォーマットを採用する。曲の複雑さでシーケンサ的なデータ量が変わることが無い。
これが端的に観察されるのはAmigaのいわゆるMODフォーマットで、
この動画はMODエディタ(ProTracker)の画面を録画しているが、楽曲が一定区間に区切られた、チャンネルの独立していないイベントストリームであることが観察できる。実際MODフォーマットはこの動画で見たままの構造をしている。
(Amigaの音源チップは同時発音数が4であることに注意する。MODフォーマットはAmigaのハードウェア構造をそのまま反映しているので、ProTrackerも4chのエディタになっている。)
これは、伝統的なアナログシーケンサに近い。
手前側のつまみが並んだ物体がシーケンサであり、このシーケンサは、一定時間ごとにつまみのデータをアナログ的に切り替えながら出力することしかしない。MODは、これにパターンの切り替え機能をつけた程度の機能性しかない。
ロックマンの例や、普通のMIDI音源を採用する多くのゲームは可変長の楽曲フォーマットを採用する。この場合はシーケンサの一音一音が一定のデータ量になり、楽曲中に音符が多いほどシーケンサ的なデータ量も多くなることになる。
例えば、ローランドMC-8は5000音程度を記録することができた。50秒とか50分のような時間単位でないことに注意する。シーケンサの記憶できるデータ量は、純粋に音符の数に制約される。
このように、ゲーム内シーケンサ = 音源ドライバの採用するデータ構造は、どのような入力インターフェースを模倣したかに依るように見える。その黎明期に、プラットフォーマーが標準ライブラリという正解を与えなかったゆえに、様々なデータ構造を持った音源ドライバが生まれ、様々な楽曲が生み出されていったという背景がある。
