ラック内の回廊

モジュラー・シンセサイザーは、常にカテゴリーの枠を越える発想に報いてきた。クロックがメロディーになり、ループするエンベロープがリズムになり、ユーティリティーが個性を露呈するまで追い込まれる。いまや、id Softwareの1993年の回廊型アクションゲームであるDoomが、Workshop Computerモジュール上で動作するよう仕向けられたと報じられている。MusicTechによれば、あるエンジニアがこのモジュールをゲームに対応させるウェブサイトを構築したという。

このニュースは、目印のないパネルの奥に小さなアーケードを見つけたような感覚をもたらす。最初の反応として笑いが起きるのは自然だろう。その後に好奇心が続く。ゲームの移植は、通常の機能一覧では見えにくい性質を浮かび上がらせることがある。ユーザーが楽器の内部にあるマシンへ到達できるのか、開発への道筋が近づきやすいものか、そして明らかに音楽的価値のないアイデアでも試してみようとコミュニティーが感じられるのか、といった点だ。

この実験は、隠れた約束を目に見える形にする。楽器の中には、フロントパネルがうたっている以上のものへと変わるだけの、扱いやすいコンピューティング能力を備えたものがある。

Doom移植の儀式

id Softwareが1990年代後半にゲームのソースコードを公開すると、Doomは移植可能なフォークロアとなった。開発者たちはそれをさまざまなOSへ、さらにはますます意外なハードウェアへと移植していった。「これでDoomは動くのか」というお決まりの挑戦は、エンジニアやホビイスト、そして道理にかなった制限を個人的な侮辱と受け取る人々の間で、共同体の握手のようなものになった。

その魅力の多くは、分かりやすさにある。人々は、動きがどのような感触になるべきか、回廊がどのように見えるべきかを、おおよそ知っている。移植では、プログラムのロジック、入力、表示、メモリー、タイミングを連携させなければならない。別の目的のために作られたハードウェア上でそれらを協調させることは、ソフトウェアツールチェーンと実装の柔軟性を明らかにする。少なくとも、報じられたWorkshop Computerでの動作は、このモジュールが本来の音楽用途の説明をはるかに超えた使い方に応じられることを示唆している。

ゲームのフレームを描画することと、低レイテンシーのオーディオを生成することでは、システムに求められるものが異なる。このデモでは、コンバーターの品質、ノイズ、レイテンシー、制御の正確さ、ステージ上での安定性は測定されていない。Doomはアクセス可能性を試せても、楽器としての性能を証明するものではない。

パネルの裏にあるコンピューター

アナログオシレーターは、所有者と簡潔な契約を結ぶ。電源と制御電圧を供給すれば、波形が返ってくる。プログラム可能なモジュールでは、その動作を書き換えられるため、この契約が複雑になる。Workshop ComputerによるDoomへの寄り道は、この抽象的な可能性を目に見える形に変える。パッチケーブルが再配置を明確にし、ソフトウェアはパネルの裏に二つ目のパッチベイを隠している。

それでも、物理的な制約を決めるのはパネルだ。コードでソケットを増やしたり、電気設計の不備を修復したりはできない。利用可能なコントロール、タイミング、ディスプレイ、オーディオ機能の連携方法を組み替えることはできる。この二重性には、長い系譜がある。初期の電子音楽スタジオは、本来の用途を超えることを求められた機器で組み上げられていた。その後、ホームコンピューターを使う音楽家たちも、サウンドチップやトラッカー、ゲームに同じ探究心を向けた。

入手可能な報告では、いくつかの興味深い疑問が未解決のままだ。ポートが制御電圧を受け付けるのか、ゲーム音声をモジュール経由で出力するのか、それとも単に内蔵インターフェース上で実行するだけなのかは明らかにされていない。こうした違いによって、Doomをパッチ素材にできるかどうかが決まる。実装によって別の事実が示されるまでは、CVで制御するモンスターやゲーム状態によるモジュレーションは、機能一覧ではなくスケッチブックに属するものだ。

オープン性には地味な証拠が必要

個人の技量があれば、ビルダーは一度限りの移植版を動かせる。しかし、一般の所有者が追従できるかどうかを左右するのは、明確な手順、バージョン表示、そして信頼できる復旧手段だ。MusicTechの報道では、このプロジェクトへの入口としてウェブサイトが示されている。そこでは、対応する正確なハードウェア、インストール手順、ソースまたはビルドの出所、通常の動作へ戻すための記録された手順を確認したい。

それらが欠けているなら、このプロジェクトはデモンストレーションとして扱い、より明確なドキュメントが出るまで待つべきだ。音楽家が関心を持つ理由は、同じソフトウェア基盤で別のシーケンサーやユーティリティ、バグ修正、さらにはまったく新しい楽器まで動かせる可能性があるからだ。コミュニティによるコードは、モジュールの実用寿命を延ばせる。一方で、ハードウェアが放置されたページや、所有者のほとんどが再構築できないツールチェーンに依存する事態を招くこともある。

オープン性と保守性は、別々のチェック項目として考えるべきだ。公開されたソース、ダウンロード可能なビルド、読みやすい変更履歴、復旧用ファイルは、それぞれ異なる将来の問題を解決する。冗談として話題になってから数か月後、最も価値ある光景は、日付入りのビルドと読みやすい復旧メモが入った、地味なフォルダーかもしれない。

目新しさを試す前に

好奇心を持つのは健全なことです。モニターに接続された通電中のラックでも、手順を踏んだ慎重な取り扱いが必要です。プログラム可能な音楽ハードウェアにコミュニティ製ビルドを読み込む前に、短い作業チェックリストを確認しておきましょう。

  • 対象を確認する。 プロジェクトに記載されたモジュールとハードウェアのリビジョンが完全に一致しているか確認します。似た名称でも、メモリ構成や起動手順、ファームウェア要件が異なる場合があります。
  • まず復旧方法を確認する。 現在のプログラムの保存方法と、通常の動作に戻す方法を把握します。プロジェクトにリカバリー用データが用意されている場合は、あらかじめダウンロードしておきます。
  • 信号経路を静かにする。 初めて不慣れなコードを起動する際は、モニター音量を下げ、モジュールの出力を切り離します。動作が安定しているように見えてから、アッテネーションを通して再接続します。
  • 書き込み処理を保護する。 安定したラック電源と信頼できるデータ接続を使用します。ファームウェアの処理を途中で中断せず、ソーシャルメディアへの投稿をもとに即興で進めるのではなく、プロジェクトに記載された手順に従います。
  • 作業メモを残す。 ビルドのバージョン、既存のファームウェア、日付、復旧手順を記録します。この小さなテキストファイルは、後でブラウザーやオペレーティングシステム、ローダーが変わったときに役立ちます。
  • 楽器を再テストする。 通常のソフトウェアに戻した後、起動時の動作、コントロール、想定される出力レベルを確認します。モジュールを演奏用リグに戻す前に、最初の音楽パッチを静かな動作確認として使います。

ジョークの有用なその後

このポートが長く残す貢献は、ジョークが一通り話題になった後に現れるのかもしれない。Doom目当てで手に入れた所有者は、モジュールがコードをどう受け付けるのか、復旧はどう行うのか、アーキテクチャ上の境界はどこにあるのかを学ぶ理由を得る。その知識は、専用ハードウェアを用意するほどではないクロックツールや風変わりなシーケンサー、小規模な演奏用ユーティリティへと活かせる。

モジュラー文化は、意図的な誤用を通じて常に発展してきた。フィルターにパルスを送り、ディレイをクロック同期させ、ミキサーを過入力にし、コントロール信号を無作法な送り先へと迷い込ませる。ここでは、その誤用がパネルの裏側、つまりソフトウェアへと移ったのだ。

明日になれば、このモジュールはクロックやコントロール電圧、そして所有者が任せたいと思う音楽的な役割へと戻れる。ブロック状の回廊は、脇道が存在することを示す有用な証拠であり続ける。次のプログラマブルボックスを購入する前に、その扉に説明書きと、外へ戻る手段があることを確かめておきたい。