ミラー・パケット
Maxパラダイムは、事前に設計された部品ブロックを、リアルタイムのコンピュータ音楽演奏に役立つ構成へと組み合わせるやり方として説明できる。これは、コントロールおよびオーディオサンプルの演算をスケジュールするためのプロトコル、モジュール化および構成要素の相互通信の手法、パッチの視覚的表現とエディタを含む。これらの構成要素は、実装ごとに異なる方法でつくられる。また各実装は、共通のパラダイムへのさまざまな拡張機能も提供する。Maxは表面的には、MIDIとオーディオをリアルタイムで演算するための適切な「GUI」を提供するものであると、たいていは捉えられているようだ。しかし、Maxの視覚的な外見と編集機能は完全にオリジナルというわけではなく、Maxの本質といえるほとんどのものは、表面下にある。
少なくとも私の経験によれば、コンピュータ音楽ソフトウェアは、アーティストとソフトウェア制作者（同一人物のこともあるが、私の場合は違う）間の相互作用の結果として生まれるのがほとんどである。この相互作用とは、せいぜいが相互貢献と相互尊重である。コンピュータ音楽がどのように聞こえるかに、ソフトウェア設計は影響を与えざるをえない。しかしソフトウェア制作者は、ソフトを通して自分の音楽的アイデアを投影しないようにしなければならない。アーティストがニーズを私たちに気づかせてくれるのが、最も良い状況である。そしてそのニーズは、私たちのどちらもが当初想像したのとかなり異なったものになることが多い。したがって、コンピュータ音楽ソフトウェア制作者として成功するためには、視野の広い高水準なアーティストの近くにいる必要がある。それにより、まったく違うアーティストの手に渡ったときの様々な問題を解決する機能を特定できるのだ。
Maxの表面下にある根本的なアイデアの多くは、1980年代初頭の（当初はMITメディアラボの一部だった）MIT実験音楽スタジオの豊かな雰囲気のなかで生まれた。1985年から1990年のIRCAMで、研究者やミュージシャン、作曲家、パフォーマの小さなグループによる熱く興奮した相互作用と発酵の時代に、Maxは今日の形を得た。刺激と要求の少ない環境では、Maxを開発するのはおそらく不可能だっただろう。同様に10年後のPdの開発は、私が参加していたグローバル・ビジュアル・ミュージック・プロジェクトのアーティストや他の研究者の参加なしには不可能だっただろう。Maxとその実装に関する私の仕事は、本質的に、こうした出会いをソフトウェアに記録する試みである。そして設計に関する問題と芸術に関する問題を一緒に考えるとき、Maxの研究は最もうまくいくだろう。
背景と影響
Maxのパラダイムとその最初の完全な実装は、ほとんどが1980年から1990年にかけて、さまざまな影響を受けながら発展した。最も重要だったのは、おそらくマックス・マシューズのRTSKEDプログラム［Mathews and Pasquale 1981］であり、そのキーアイデアの一部はカーティス・アボットの初期の4CEDプログラム［Abbott 1980］にも見られる。RTSKEDは、ポリフォニックシンセサイザを制御操作するリアルタイムスケジューリングの問題に取り組んでいた。
マシューズの初期GROOVEプログラム［Mathews and Moore 1970］は、定期的にサンプリングされる「電圧制御」信号の扱いを重要視していた。一方でRTSKEDの制御の概念は、シンセサイザの状態変化を引き起こす散発的に発生するイベントだった。たとえば、RTSKEDで音符を開始するには、オシレータの周波数を設定し、エンベロープジェネレータをトリガする必要があるだろう。これは、Music N言語の「ノートカード」アプローチと同様の方式であり、動作時間が明確で瞬間的である。したがって、たとえば位置と下向きの力が連続的に変化するヴァイオリンの弓よりも、鍵盤楽器を表現するのに適している。
RTSKEDで取り組まれた主な課題は、動作時間が事前にわからないリアルタイム演奏の状況で、どのようにノートカードを取り替えるかである。（他のパラメータも事前にはわからないかもしれないが、主な難しさは時間パラメータに見られるようだ。）RTSKEDは、並行して実行されるタスクのまとまりとして演奏をモデル化した。たとえば、各タスクは特定の合成音に対応するだろう。タスクのタイミングは、待機関数とトリガによって制御される。一度に実行されるタスクは1つだけだが、トリガの待機時間を設定した待機関数を呼ぶことで、実行中のタスクはいつでも制御を放棄できる。リアルタイム入力（たとえばキーボード）や他のタスクから「着火」して、トリガを引くことができる。
このようにリアルタイム制御の問題を別々のタスクに分離することは、コンピュータが楽器として機能するために必要となる重要な進歩だった。それ以前は、コンピュータ音楽プログラム（および実際、ほぼすべてのコンピュータプログラム）は動作のシーケンスをユーザに強要していた。プログラムを並列タスクに分離すると、次にどちらのタスクをトリガするかを選ぶことで、プログラムの実行シーケンスをユーザが制御できるようになる。たとえば、マルチタスク環境ではピアノを、キーとペダルごとに1つずつ、91のタスクとして捉えられる。演奏者——ピアノのユーザ——は、91のタスクをトリガする順序と回数を選択する。事前に決められたシーケンスをピアノは強制しない。
このタスクの概念は、接続を介して互いに「トリガ」し合うMaxパラダイムのボックスで明確に見られる。このアイデアはMIDIの発明に先行している（そしてMaxをMIDIプログラムであると捉えたことはない）が、初期のMaxユーザにとってMacintoshコンピュータのMIDI入出力を使えることは好都合であった。なぜならMIDIは、もっと以前の「MUSIC N」プログラムに（さらにもっと以前の、MIDIがモデルにした平均律鍵盤に）ルーツを持つ、制御イベントの散発的な性質を共有していたからだ。Maxパッチに明らかな視覚的並列性は、プログラムのではなくユーザの選択に従うコンピュータプログラムを、ユーザがつくれるように意図したものである。これは、Maxパッチ（プログラム）が楽器として機能するために必要だった。
2番目に重要なのは、1979年から1987年にかけて私が学んだ教師のバリー・バーコーの影響である。自身もマシューズの学生であったバーコーは、Csound（もともとはMusic 11と呼ばれていた）の作者として最も広く知られている。だが、リアルタイムコンピュータ音楽システムにおける彼のあまり広くは知られていない業績は、1970年代のリアルタイム・デジタルシンセサイザの設計から現在に至るまで、この分野での彼の最も重要な貢献だといつの日か認められるだろう。
それまでのMUSIC Nに比較してCsoundが最も進化した点は、高度に洗練された制御構造である。他のMUSIC Nシステム（たとえばMusic 10）はいくつかの点でより柔軟であるが、それは実装言語（多くはアセンブラ言語）下にあるコードを直接ユーザが書けることに起因する。一方のCsoundは、音楽制御の問題を解決するために独自言語の構文を与える。これらの構文の一部はいびつ（たとえばtigoto）に見える。しかし初期化と再初期化、実行といった中心概念は、制御構造とサンプル演算を緊密に統合したやり方で指定する方法を提供する。
制御問題についてよく考えられたこのアプローチは、バーコーによるSynthetic Performer［Vercoe 1984，Vercoe and Puckette 1985］の開発を導くことにもなった。これは、IRCAMの4Xマシンで最初に実行された。Synthetic Performerは、別のパートを演奏するライブ演奏者にコンピュータパフォーマが自動で同期する、リアルタイムのスコアフォローを実演した。ロジャー・ダンネンベルクは独自にスコアフォローを見いだし、同年に発表した［Dannenberg 1984］。ダンネンベルクのアルゴリズムは、バーコーのアルゴリズムよりも課題の分析面を堅牢に実行した。しかし、ダンネンベルクの設計はシーケンサのテンポ制御のみを考慮するが、バーコーのシステムはオーディオレベルで機能しており、テンポの変化にあたってエンベロープジェネレータを管理する課題に取り組む必要がある。この課題の代表的な例は、将来の強拍にある特定の音符に至るグリッサンドを、新しいテンポ情報にあたって到達時間を継続的に再見積もりしながら導くことだろう。
1986年にハーグで開催されたICMCまでに、リアルタイムのコンピュータ演奏をスケジューリングする理論上の課題に関する研究を、多くのセンターの研究者が発表していた［Anderson and Kuivila 1986，Boynton et al. 1986，Favreau et al. 1986，Puckette 1986］。提案されたシステムは、コンテキストスイッチとプリエンプションの使用または非使用や、スケジュールされた将来のタスクのためのキューの設計、実装プラットフォームと言語、およびその他の多くの点で異なっていた。しかしMaxの設計に取り込まれた多くの特徴はそこに見られる。
Maxのもう1つの側面は、グラフィカル・ユーザーインターフェース（「GUI」）である。 MaxのGUIには多くの先例がある。1980年にバリー・バーコーの下で学んでいたときに、リチャード・シュタイガーとロジャー・ハレによるOeditシステムを見た。視覚的「パッチ言語」を用いてMusic 11オーケストラを設計したもので、それは公開された論文で解説されたことはないようだ。ほかの多くの視覚的パッチ言語は、音楽用や他の用途どちらも、私がMaxの「パッチ」GUIを書き始めた1987年までには現れていた。いくつかの特殊な要素は斬新だったかもしれないが、少なくともコンピュータ音楽の文脈において、視覚的パッチ言語の全体的なアイデアはそうではなかった。
Max、Jmax、Pdの開発
Maxのような言語がどうやって現在の状況にたどり着いたかという話は、おそらく主観的な理解ではうまく表現できないだろう。しかし以下の主観的な歴史は、少なくともある一面に光を当てるに違いない。他の人はこれに付け足したり修正したいかもしれない。
今となってはMaxと呼べるかもしれない最初のインスタンスは、Music500だった。1982年くらいからバーコーのラボで私が取り組み始めたもので、詳細について一つの側面は発表している［Puckette 1984］。視覚的フロントエンドはなかった。RTSKEDに着想を得た制御構造でこのシステムは成り立っており、音合成エンジンはMusic 11から抽出している。制御と音合成の環境は別々である。制御は（少なくとも論理的には）並行して実行されるプロセスのまとまりとして考えられ、並列処理プロセッサに実装できる。「オーケストラ」（または音合成プロセス）は他の制御プロセスと似ており、他の制御プロセスとのやりとりは、同様の規則に従う。
このシステムは、高水準言語では数値演算ができないマシンで実行するように設計されている。想定された特定のハードウェアであるAnalogic AP500アレイプロセッサは、ビットスライスされたマイクロコーディング可能な数値演算エンジンと「制御」マイクロプロセッサを備えていた。オーケストラ言語は、数値演算ユニット内（のベクトルユニットジェネレータ内）で解釈されるように記述した。マルチタスク制御構造のプロセスは、RTSKEDから直接もたらされた。
Music500はリアルタイムで音を出すには至らなかった。私がまだMusic500について報告していた1984年までに、バリー・バーコーはIRCAMでSynthetic Performerを開発し、1985年の夏に彼と一緒にパリで仕事をするように招いてくれた。こうして使うことのできた4Xマシンは、プリント基板のバージョンでやってきた時と同様、世界で最も強力なシンセサイザー／オーディオプロセッサだった。4Xにはジャンプ命令がなかったので、Music500のオーケストラモデルは適用させられなかった（またいずれにせよ、素晴らしいテキストベースの「パッチ言語」［Favreau et al 1986］があった）。そこで私は、4XのプログラミングではMusic500の制御構造だけを残し、RTSKEDの根本的な影響を認めるために名前を「Max」と改めた。グラフィカルなプログラミング言語ではなかった（4Xの制御コンピュータはGUIをサポートしていなかったし、当時の私はGUIベースのソフトにまだ懐疑的だった）。「パッチ」はMaxのコマンドラインで定義し、必要なすべてのオブジェクトの作成アーギュメントを単純に連結した。当時のバージョンでは、オブジェクトはそれぞれに1つのインレットと1つのアウトレットしか持てなかった。それゆえ各オブジェクトに名前をつけ、アーギュメントに接続先の名前を並べることで、単純に接続を定義した。
Maxを最初に組み込んだのは、バーコーのSynthetic Performerをサポートするもので、1985年にIRCAMで共同開発したバージョンである。コマンドラインのパッチは基本的に4つのオブジェクトからなる。ピッチトラッカー、（ピッチを受け取りテンポを出力する）スコアフォロワーそれ自体、テンポ制御可能なシーケンサ、4Xで実行するサンプリングシンセサイザのコントローラ（Maxのnoteoutにおおよそ類似する出力装置として機能する）である。
この「Max」の4Xバージョンは、1987年4月にティエリー・ランチーノの《アローン》とフィリップ・マヌリの《ジュピター》で舞台デビューした。どちらもIRCAMの10周年記念コンサートで初演された。そのMaxの初期バージョンには、ほとんど気が遠くなるような制限があった。Maxが使用できるように4Xのパラメータ更新を準備するための、複雑で柔軟性を欠くコンパイルプロセスがあった。デバッグは時として困難を極めた。
この経験の後、1987年の夏に始まるMacintosh上でのCプログラムとしての再設計前に、2つの別々のLisp環境でMaxの制御パラダイムを実装しようとした。（当該のMacintoshはデヴィッド・ウェッセルがIRCAMに持ち込んだ。彼の努力なしには私も他のIRCAMスタッフも、パソコン革命を完全に見過ごしてしまっただろう。）現在のMax/MSPにやがて成長するMaxの新しいMacintoshバージョンは、1988年だと思うが、フレデリック・デュリューの作品で初めて舞台で使用された。しかし使える音楽ツールに発展する引き金となったのは、1987年の秋に制作が始まり1988年7月に初演された、フィリップ・マヌリの《プルトン》である。いまでは様々な形で存在する《プルトン》のパッチこそ、本質的には最初のMaxパッチである。
《プルトン》を実現するために、Macintoshを4XにMIDIケーブルで接続して、Macintoshを「制御コンピュータ」として使用し、すべてのオーディオ演算は4Xで行った。したがって、オーディオ信号パッチをグラフィカルに定義する課題に直面せずに済んだ。この時はまだ、MIDIメッセージを4Xのパラメータ変更に変換するためのアドホックCコードと一緒に、4Xのパッチ言語を使用していた。そのため（GUIまたはプログラム可能なDSPエンジンが使えたものの、同じアドレス空間で両方は無理だった）当時の限界により、Maxは「MIDIプログラム」となった。Maxの根本にMIDIから派生したものはまったく無いのだが。Maxに関する限り、MIDIはI/Oインターフェースに過ぎなかった。
次の2つのステップは並行して行われた。最初に、Maxはデイヴィッド・ジッカレリの努力によって商品化された。ジッカレリはこのプロジェクトを約13年間貫き通し、2つの会社の破産に耐え、ついに自分の会社Cycling74を始めた。コンピュータ音楽ソフトウェアの世界では、ジッカレリよりも献身的で忍耐強い開発者はめったに見られない。
同時に私は、4Xの後継機の開発を担当するエリック・リンデマンが指揮を執る、IRCAMのチームに加わった。マヌリの云うように「4Xは今では老婦人だ。まだ美しいが、高価すぎる」のだ。リンデマンは、IRCAMシグナル・プロセッシング・ワークステーションまたはISPWと呼ばれる、非常に強力なオーディオ信号プロセッサを設計した［Lindemann et al. 1991］。4Xを凌ぐ多くの進歩のなかで、ISPWはジャンプ命令が使えた。私はこれを利用して、オーディオ信号処理を実行するためのチルダオブジェクトのコレクションをMaxに追加した［Puckette 1991a］。
これは、Maxに関するIRCAMの分岐点に2つの変化をもたらした。まず、グラフィックレイヤを別のウィンドウシステムに移植する必要があった。そしてもっと根本的に、Maxの「リアルタイム」部分をGUIから分離することが必要になった。リアルタイム部分はISPW上で、GUIはホストコンピュータのNeXT Cube上で実行した。さらに、「Faster Than Sound」またはFTS［Puckette 1991b］と私が名付けたリアルタイムコンポーネントは、共有メモリの利点を抜きに、複数のプロセッサ上で実行せざるを得なかった。
1991年までに、ISPW以外のアーキテクチャ上でMax/FTSを利用できる機が熟してきた。次の2年間で、ヨセフ・フランシスとポール・フォーリーが、Max/FTSをUnixとXウィンドウシステムで実行した。Max/FTSプロジェクトは、フランソワ・デシェルが指揮を執るIRCAMのチームにより大幅に作り直され、拡張され、現在はJmaxという名前で彼らのバージョンを配布している。
一方で、私は1994年にUCSDに移り、Maxで改善したかったことをいくつか見据えながら、Pure DataまたはPd［Puckette 1997］という名前の新しいプログラムの作成を開始した。私はPdを最初からオープンソースにした（そしてIRCAMも後にJmaxで同じことをした）。Pdのために、Max/FTSのような新しいチルダオブジェクトを作成した。これをジッカレリは「MSP」と名付けた出発点として使用し、Cycling74のMaxもオーディオ信号処理が可能になった。（1996年頃までに、一般的なパーソナルコンピュータはとうとう、これが実用的であるほど十分強力になった。）
1995年頃、マーク・ダンクスが開発を始めたGEM［Danks 1997］は、Pdの3Dグラフィカルレンダリング拡張機能に成長し、現在はヨハネス・ツメールニヒが管理している。他にもさまざまな方法でビデオを扱う、外部の拡張機能がMax/MSPおよびPdで利用できる。そのため、Maxプログラムは現在、オーディオ領域だけでなくビジュアル領域にも向けられている。
今日、MaxとJmax、Pdは、同じ基本的なアイデアの非常に異なる3つの実装と見なすことができ、それぞれが、他では利用できない独自の拡張機能を備えている。状況は常に変化しているため、ここで3つの実装の相対的な利点を議論することは勧められない。しかし、実際には3つの間でパッチを移植することが可能なので、共通の基盤に落ち着いているユーザは、使用している特定の実装が修理不能になった場合、少なくともいくつかのオプションがあると感じられる。
Maxの設計について
1993年までに、コンピュータサイエンスの研究者の困惑した注目を引き付けるのに、Maxは十分広く使用されていた。例えば「しばらくの間、Maxの成功とそのユーザの熱意に驚いていた」［Desain and Honig 1993］。Maxの設計は、コンピュータサイエンスの正統的なルールの多くを破っている。その理由は、時に実用性であったり、スタイルであったりする。以下の節では、Maxの設計の基本的要素の論理的根拠と批評を提供しよう。［Puckette 1991a］で説明されている設計に読者が精通していることを想定する。
Maxは、データよりもプロセスに向けられている。（たとえば、音楽「スコア」の組み込み概念がない。）Maxパッチを、線で相互接続されたボックスの集まりと考えると、Maxの表現性は相互接続および相互通信機能に由来する。その一方で、ボックスの内容自体は通常ユーザから隠されている。大量のデータを保存するための唯一の機能は個々のボックスにカプセル化されているため、データのまとまりを表示または編集するようなことにMaxは使えない。データ処理機能の明確なニーズに対応するために、tableなどの特定の種類のボックスには、独自のウィンドウと方法でエディタが提供される。（Pdはデータ表現の課題に対する新しいアプローチを提供するが、ここで説明するのは時期尚早だろう。）
ボックスの各タイプはそれぞれの方法でデータを保存できるので、Maxではデータ保存の仕方に統一性がない。一部のアドホック機能も、データ共有のためにボックスごとに考案している。アプローチの統一性の欠如は問題であるが、一方で、統一されたアプローチを強要するのはさらに大きな問題を示し得た。
少なくとも公式には、ボックス間の通信はすべてMaxメッセージを介して行われる。Maxメッセージは非常に単純な構造で、内容が標準化されている。メッセージは、数字または文字列が順番に並ぶアトムの線形リストである。（MaxとJmaxでは、数字に2つの異なる型がある。Pdではこの区別をなくした。）Smalltalkスタイルのメッセージセレクタとして機能するシンボルが、常にメッセージの先頭に付く。（メッセージは数字で始まるように見えることもあるが、こうしたメッセージにMaxはリストのように常に理解可能なセレクタを付ける。）人によって意見が異なるのは、このメッセージ通過型インターフェースに照らしてMaxを「オブジェクト指向」と考慮すべきか、あるいはオブジェクト指向プログラミング言語に共通する他の多くの機能を欠いているとしてその肩書きを否定すべきかという点である。
ボックスの左端のインレットは、ボックスの動作を定義したあらゆるセレクタメッセージを受け取る。この方法により、ボックスはインレットの数より遙かに多くの動作をする。そして新しいインレットが、ボックスの変更を伴わず非互換的に追加されうる。ほかの（左端以外の）インレットは、それぞれ1つだけのセレクタを扱い、数は適切に少ない方が良く、（MIDIアウトボックスのチャンネル番号のように）パッチで頻繁に必要となるメッセージのために確保されるのがベストである。ボックスが取り得るセレクタ数を基本的には制限せずに、相互接続の容易さを向上させるための妥協を、この設計は表している。そこで最も重大な不便さはおそらく、隠れたセレクタが引き起こす混乱であり、また時としてメッセージの先頭にセレクタのリストやシンボルの挿入が必要な点である。
メッセージの非常に単純な構造と、bangなどのセレクタ使用の標準化は、ボックス間の相互接続性を最大化し、必要な接着剤の量を最小化することを目的とする。メッセージは入力も読むのも簡単である。実際、「メッセージボックス」は単純にメッセージを保持する。
この原則からの顕著な逸脱は、オーディオ信号の処理にある。もともとMaxの設計では、リアルタイムのコンピュータ音楽演奏の課題を、本質的には制御の問題と見なしている。そしてあるボックスから別のボックスにオーディオ信号をパッチする機能は、この体系から根本的に逸脱する。Maxは、オーディオ信号に別のデータ型を与えるが、これはメッセージとスムーズに混ざらない。オーディオ信号からメッセージへの変換には問題があり、また「コントロール」と「オーディオ」の処理をスケジューラは別々に扱う。Maxよりも優れた解決法を私は提供できない。私はかつて、ひとつの共通概念で両方の様式を実際に取り込むメッセージ文法を設計した。しかし実用上はあまりにも一般的すぎるように思えた。
概してMaxの設計は、ボックスの内容を定義するメッセージをタイピングする、テキストボックス（オブジェクトとメッセージ）を重要視している。この点で、Maxはグラフィカルプログラミング環境としては非常に特殊である。この選択には少なくとも3つの合理性がある。第1に、パラメータ（Maxではアーギュメントと呼ぶ）を設定するのにテキストのインターフェースを要求するので、テキストに全体的に頼るのは、考えられる最もシンプルな解決策である。第2に、ひとたび10や20の異なるアイコンがあると、どのアイコンがどの機能に対応するのか、覚えるのが難しくなる。テキストは覚えやすいのだ。
第3に、テキスト表現はアイコンよりも、画面のスペースあたりずっと多くの情報を伝えているように見える。ほとんどの場合にMaxのボックスは、ダイアログまたはその他の形式の表示方法に、本質的には依存しない。理想的にはボックスのテキスト内容を、少なくともその作成時に決定する必要がある。Maxの中心的な設計原則は、可能な範囲で、いま起きていることを画面上のパッチで完全に記述することである。これが、隠された状態（たとえば、ダイアログボックスを介して管理する）を回避し、オブジェクトボックスの状態すべてをボックス内のテキストで（少なくともスタートアップ時には）表示すべきという考えの理由である。
これもまた、頑固にオブジェクト内の状態を変更しないという選択の背後にある理由だ。以前に保存したMaxパッチを再度開くと、ボックスのインレットに送られていた値はすべて忘れられ、作成アーギュメントにより与えられた（失敗したらデフォルトの）値で新しく置き換えられる。なぜなら、そうしないとバッチの挙動は、たとえば「+」ボックスであれば、特定の値がその出所の目に見えるすべての痕跡を失った後もインレットに残ったままであるという事実に、決定的に依拠してしまい得るからだ。
特定のケース（テーブル、qlistなど）では、ユーザがそれを使う文脈で見たいものよりも、多くの状態を表示する必要がでてくる。こうした場合にMaxは原則から離れ、データを管理するためのサブウインドウにある特殊なエディタを提供する。これは妥協した、審美的不幸ではあるが、Maxの根本的な設計がデータ管理の問題を扱っていないために必要なのである。
図1：2つの波形テーブルオシレータがあるPdパッチ
スケジューリング
Maxのスケジューリングアルゴリズムは非常に単純だが、開発には数年かかった。最終形は、主にデータ処理のアプローチが、RTSKEDのスケジューリングアルゴリズムと異なる。Maxでは、オブジェクトは通常、ほかのオブジェクトからメッセージを渡すことで動作する。動作を「トリガ」し、オブジェクト間でデータをやり取りする仕組みは統一されている。（メッセージは空データ〈例：bang〉の可能性があり、その場合、メッセージは純粋なトリガと見なされるだろう。）データ「フロー」とトリガリングの統一は、音符を演奏するヴェロシティが、音符が演奏されているという事実の一端を自然に含んでいるという、ピアノの隠喩から提案されている。（このことによりMaxは真のデータフロー言語にはならないのだが、一般的に、データフロー言語はリアルタイムのイベント処理をうまく捉えられないようである。）
目に見えるパッチコードに加えて、トリガのもう1つの発生源は論理時間の経過である。正式には、単にオブジェクトへの別のトリガに見えるが、速度と簡素化のために、単純なコールバック関数としてコーディングしている。論理時間は、CPU負荷またはOSによって生じるリアルタイムの遅延に関係なく、純粋に決定論的な方法で進む。この決定論は、Maxパッチをデバッグ可能にするために重要である。問題が発生した場合、問題の再現と追跡はたいてい容易である。パッチがリハーサルで機能する場合、演奏時に機能する可能性が高くなる。
Maxがピアノの隠喩に従うのは、オブジェクトが何を待つのかを指定せず、むしろオブジェクトがトリガするオブジェクトを明確に選択する点にもある。言い換えれば、選択権はトリガするオブジェクトにあり、トリガされるものにではない（演奏者であり、ピアノではない）。視覚的には、オブジェクトのメインインレットにファンイン（入力）することで示される。オブジェクトは次にどの線が動作するかを制御しないのだ。したがって、視覚的設計とスケジューラはよく合っている。
一方で、ファンアウト（出力）の接続では深刻な問題が生じ、完全に適切な解決策はないように思える。ファンアウトされた複数のトリガが起動する順番は、全体の結果に影響を与える可能性がある。ファンアウトされたメッセージに明示的な実行順序が与えられていない限り、ファンアウトは予期せぬ振る舞いをする確率が高くなる。この問題への一つの解決策は、Cycling74 Maxで実装されている、画面上の位置に従って各個のアウトレットにつながれた受信ボックスを並べ替えることだ。これは理論的には、画面上の見た目から直接パッチがどのように動くのかが分かる利点がある。しかし画面上のボックスを単に動かす（たとえば整理する）ことでパッチの振る舞いが変わってしまい得るのが欠点である。（さらに、send/receiveのような、ローカルでない接続がどんなルールに従うかは不明である。）JmaxとPdは、それぞれに利点と欠点がある別の挙動をとる。最良の解決法は、ファンアウトの実行順が問題になる場合に状況を曖昧にしないよう、triggerオブジェクトをユーザが使うことである。おそらく、いつの日かこうした状況を自動的に検出してユーザに警告を与えるのが、一つの良い方法となるだろう。
Maxのユーザは、1つのボックスにある複数のアウトレットが慣習的に右から左の順序で出力するのによく驚く。これはボックスの「メイン」インレット（左端のもの）が出力をトリガし、ほかのインレットはほぼいつもボックスの内部状態を設定するためだけに使われるのが理由である。したがって、計算が正しく機能するには、関連するすべてのメッセージが他のインレットに送信された後に、左端のインレットをトリガする必要がある。最初のインレットが「ホット」インレットであることを受け入れるなら、それがメッセージを最後に受信すべきであり、単一のオブジェクトが2つ以上のメッセージを提供する場合、右から左の順序が正しいことになる。
多くの厄介なスケジューリング問題は、Maxでのオーディオとコントロールの演算の危うい融合が原因である。オーディオ信号は、少なくとも1サンプル（通常は効率のために64以上）のブロックで計算される。その事実は、コントロール演算がグレインを必然的に持ち、別々のサンプルブロックの境界でのみDSP処理に影響を及ぼせることを示す。たとえば個々のグレインのオンセット時間を決定するためにコントロール演算が必要なグラニュラー合成パッチを構築する場合に、これは深刻な問題になる可能性がある。
別の問題は単純に、オーディオ演算をコントロール演算とは異なるセマンティクス（意味論）に準拠させるのは、洗練されていないということだ。コントロール演算は本質的に順序依存である。一方でオーディオサンプルのクロックは予測可能であるため、オーディオ処理ではMaxがコントロール演算に使っているメッセージ通過モデルよりもデータフロー・セマンティクスがより適している。2つの世界は同じパッチになんとか共存しているが、混乱を招き、コンピュータ科学者を怒らせる。Cycling74 MaxおよびJmaxでは、オーディオ接続はコントロールと異なる見た目で描画され、少なくとも混乱を減らすのには役立っている。
さらに別の問題は、たとえばオーディオ信号のゼロ交差でコントロール演算をトリガするといった、サンプル依存の意思決定プロセスを実行するのが非常に面倒だということだ。コントロール演算がオーディオ演算に割り込むのを許可されている場合、結果を予測または解釈するのは困難な場合がある。
これらすべての問題は、ビデオやコンピュータグラフィックスの演算が追加されると深刻度が増す。それらを克服しようとすれば、将来の実り多い研究分野が開かれるかもしれない。しかし現時点では、Maxパラダイムはその制限にもかかわらず、実用的なシステムとして、少なくとも状況の大部分を十分にうまく扱うことができているようだ。チャーチルを言い換えると、Maxは考え得る最悪の解決策だが、これまでに試みられたすべてを別にすればの話である。
Maxでのプログラミング
音楽家はMaxを、とてもぎこちなくしかうまくいかない中で、プログラミング環境として頻繁に使ってきた。Maxにはスコープや名前空間の概念がない。すべてのシンボルとそのバインディングは、1つのフラットスペースに存在する。この決定は、コンピュータ音楽制作のコンテキストでは厳密には必要ないように見えた、複雑さのレイヤをなくすために行われた。プロのコンピュータプログラマでない人々にもできるだけMaxを使えるようにするためである。
さらにMaxには、あらゆる現実のプログラミング環境では基本的な、線形の「制御フロー」という概念がない。ループや条件、およびサブルーチンを使用した制御フローの概念全体は、テキスト言語では簡単に表現できる。しかしグラフィカルプログラミング環境では、テキスト言語のような表現の流暢さや無駄のない体系がまだ見つかっていない。
プログラミング環境というよりも、Maxは基本的に、リアルタイムタスクをスケジュールし、タスク間の相互通信を管理するためのシステムである。このような（訳者注：制御フロー）プログラミングは、既存のタスクのネットワークを構築するよりも、タスクの下で行う方が適切である。これは、CまたはC++で「エクスターナル」を作成するか、インタープリター全体（たとえばForthやScheme）をインポートするという形をとることができる。厳密な可能性は実装による。
音楽的構成
Maxのデザインは、偏った様式を音楽家のアウトプットに押しつけるのを避けるために、いかなる労も惜しんでいない。ピアノの隠喩に戻ると、ピアノは作曲家やピアニストに制限を課すこともあるが、それを通して多種多様な様式を表現できる。音楽家にとって、ピアノはエンパワーメントの媒体であり、制約ではない。アウトプットがピアノ音楽としてほとんど常に認識可能であるという事実は、批判の対象ではない。コンピュータソフトウェアの隠喩では、（たとえば）Maxは、「Max」らしく聞こえるように音楽家の行為を制限すべきではない。コンピュータらしく聞こえることがいかなる様式的傾向も意味しない限り、コンピュータらしく聞こえることは許容すべきかもしれないが。
Maxはこれをどの程度達成しているだろう？ 音楽様式の発展のタイムスケールで考えると、まだMaxは最近の事象にすぎないため、答えを出すには時期尚早かもしれない。それでも、Maxのデザインがどうやって様式的中立性を目指し、どこが成功しどこがうまくいっていないかについて、議論は可能である。
Maxを立ち上げると、空白のページのほかにユーザは何も目にしない。譜表や拍子記号、調号、それどころか「音符」の概念すらなく、また確実に、楽器の「声部」も「シーケンス」もない。この空白のページでさえ、すくなくとも一つの興味深い事項において、様式や文化を担っているのだ。音楽制作の試みに紙を取り入れるアイデアの全体は、西洋芸術音楽の発明であり、ほかの多くの音楽にはまったくない。紙に頼らない音楽実践は、場合によって、西洋化されたものよりコンピュータの使用がずっと少ないだろう。
おそらく、どれほど困難であろうとも文化的に中立なソフトウェアプログラムを作ろうとして、常に紛れもなく明らかな（様式や文化の）前提が見つかるであろうと、私たちは最終的に結論づけるだろう。しかしこれは新しいソフトウェアの設計をやめる理由にはならない。それどころか、さらに根本的な前提が問われ、それがなんとか剥ぎ取られるにつれ、たくさんのわくわくする発見がまだなされうるかもしれないという希望を与えてくれる。
ソフトウェアと技術
あるレベルでは、コンピュータ音楽を行うプロセスは、まずソフトウェアを作成し、次にそれで音楽を制作する。ソフトウェアの有用性における第一の尺度は、その寿命である。ただし、寿命を念頭に置いてソフトウェアを作成するだけでは、音楽制作者へ直接には寄与しない。コンピュータ音楽ソフトウェアはさらに、個々の実装を超えたアイデアをエンコードすることもできる。コンピュータ音楽ソフトウェアが提供するものには2つのタイプがある。これらは、作業環境としての提示形式を通じてユーザーを直接エンパワーする。しかしまた、それらはコンピュータ音楽実践の進歩もエンコードする。ソフトウェア設計者の最も直接的な挑戦は、多種多様なタスクに対して有用で、可能な限り長く使えるものを作ることである。しかしとにかく、優れた永続的なアイデアは、いずれにせよ実装から実装にジャンプしてゆくだろう。
たとえば、図1で使用されている波形テーブル発振器は、1950年代後半にマシューズのMusic II（11ではなく2）で初めて登場した。Music IIは、MUSIC Nプログラムの長い血脈の1つにすぎなかったが、波形テーブル合成のアイデアは、コンピュータ音楽の分野全体に広く影響を与えてきた。
最良の場合、ソフトウェア制作とは、こんにちの発明をユーザが使用できるようにすることである。そしてソフトウェア開発者の心から湧き出る別の発明を彼らに与えることではない。発明は文化的発展の重要な部分だが、ソフトウェアの設計と発明を混同してはならない。またソフトウェア設計者は、ソフトウェアで個人的な発明を組み立ててはならない。ソフトウェア開発の一環として何かを発明する必要があったMusic IIなどの状況では、（マシューズのような）最高の発明家は、発明とそれを載せるソフトウェアを、二つの別個のものとして提示している。
永続性
ソフトウェア開発者は2つの競合する欲望に引っ張られる。一方では、私たちは何でもできるソフトウェアを望んでおり、「何でも」の定義は年々広がってゆく。他方では、昨年の電子メールを開いたり、6か月前に作成したコンピュータ音楽を上演できるような、安定性を望む。各ソフトウェア設計者は、可能な限り幅広い機能の選択肢を提供しようとし、同時にメンテナンスから外れるリスクを最小限に抑えようとする。新しいソフトウェアが提供する機能の幅広さは、ほとんどその設計者の野心によるようだ。一方でその寿命は部分的に、運や、設計者（および彼または彼女の雇用者）の忍耐力、そして設計者の先見性による。
Maxなどのメディアで表現される音楽のアイデアの耐久性は、Maxの特定の実装によって必ずしも制限されない。たとえば図1のパッチは、その機能をほぼ完全に説明している。残りの不正確なところは、テキストのドキュメント（これは2つのテーブルの正確な数値的内容を明らかにするだろう）を見れば迅速に解決する。これら数行のテキストを再解釈するのに、MaxまたはPdのコピーを実行する必要はない。Maxで表現したアイデアは、原理的にその実装より寿命が長いのだ。
こうした実践とアイデアの伝達性は、コンピュータサイエンス界の主張に反して、コードの再利用におけるいかなる本質的方法にも依存しない。実際、継承構造という意味でのオブジェクト指向プログラミングが、本質的にコードの再利用に関するものである場合、オブジェクト指向コーディング構成の使用は本質的な理由ではないようだ。もちろん、コードの優雅さは考慮すべき良いことである。しかしそれは、より広くわたしたちの文化へコンピュータ音楽を真に寄与させる、隠れた偉大なアイデアの創造的な適応には何も役立たない。優雅さについては他の人に任せて、さまざまなプログラミング技術と言語の相対的なメリットを議論しよう。
ライト兄弟の最初の飛行機が動力飛行の概念を組み込んでいないのと同様に、音楽ソフトウェアは絶望的に音楽実践を組み込んでいない。最初の飛行機を発掘できても、今よりももっとうまく飛行できる助けには決してならないだろう。重要なのは、実践を続けることである。もちろん、工芸品が周りにあるのは楽しいが、美術館に置くものとしてのみである。
外部の問題
多くの場合、理論設計の外部にあるソフトウェアの側面は、その最終的な有用性に強いプラスまたはマイナスの影響を及ぼす。これはソーシャルファブリックでのソフトウェアの位置づけに、部分的に依拠するだろう。この点で、Maxのさまざまな実装は、さまざまなニッチを占めている。「Max」と名付けられた元々のプログラムは、今日とはまったく異なるソフトウェア利用のモダリティと普及があった、非常に異なる世界で書かれている。現在の3つの実装の存在は、過去17年間に行われた多くの変化を反映している。大きな変化のひとつは、コンピュータ音楽ソフトウェアが、1985年にはかなり孤立していた「コンピュータ音楽界」の境界を打ち破ったことだ。
今日のコンピュータの低廉さは、たとえば西洋人と彼らの旧植民地の住民との間に、かつてなく巧妙な邂逅を可能にしそうである。現地のアーティストを記録するためにコンピュータを持って（西洋中心主義文化が少なくともバルトークの時代から行ってきたように）森林へ分け入る代わりに、今では私たちはEメールで会話を始める。いまや地球上のほとんどあらゆる共同体の人々が、現代版バルトークの助けなしに自分たちの音楽を記録できる。そしてまもなくほとんどあらゆる場所の人々がコンピュータを手にして、自分たちの音楽制作に取り込めるようになるだろう。
これにより、世界の音楽にますます可聴的な変化が生じるだろう。西洋人が非西洋人を録音スタジオに招き、彼らの楽器演奏の録音を後で編集するテープを、もう聞くことはない。新しい音楽がどのようなものになるかを予測するのは時期尚早であるが、単なる素材として以上に重大な痕跡を電子音楽に残す、非西洋の実践の扉が開かれていることは明らかだ。電子音楽における非西洋的なアプローチは、近い将来、大きなエネルギー源になると期待している。
しかし、コンピュータハードウェアの低廉化によって交わされた約束に、私たちはまだ追いついていない。確かに、いまやすべての道具が入ったコンピュータを400ドル程度で購入でき、アンプとスピーカを追加すればコンピュータ音楽制作の準備が整う。しかしこれは、システムを構築し、フリーの良いソフト見つけてインストールし実行するために必要な知識があることを前提としている。コンピュータを数千ドルに、ソフトウェアを数千ドルにしたいという多くの商業的な関心が、私たちの前に立ちはだかる。
コンピューティングとコンピュータ音楽の民主化に不可欠な要素は、地域の知識ベースを育成することだ。将来を見据えた音楽教育者は、学生が自分のコンピュータを構築するのを促すために何時間も割いている。自家製コンピュータと自家製コンピュータ音楽ソフトウェアの国際的な文化を、いつか見たいと私は思う。過去に裕福な西側はソフトウェアを開発し、何百万ものCDを作り、買う人には誰にでも販売した。将来的には、他の世界から輸入されたソフトウェアを研究し学習するセンターを見てみたい。
知識を育てるコミュニティが、特にLinuxのような非商用OSでは必要である。もしLinuxを使う友人がいなければ、動かすまでには障害があるだろう。しかし、世界の多くで少なくとも村の1人や2人に、コンピュータ音楽の専門知識（マシンの組み立て方法、OSのインストール方法、ソフトウェアの実行方法など）がある未来を想像できる。
コンピュータ音楽コミュニティは、モデムが提供できる範囲を超えて外部に接触する必要のあまりない小さなグループの中で成長できるという点で、Linuxコミュニティと似ている。これをエンパワーするために重要なのは、ソフトウェアが、自身の文化的な荷物を運んで来るのではなく、ユーザが生活するところに存在するあらゆる現実に適合することだ。これはまさしく、優れたソフトウェア開発に一般的な特徴を示すものである。
これは今日の巨大なソフトウェア製品にはないものだ。たとえば市販のスプレッドシートプログラムでは、Maxが提供する空の用紙とは全く異なるものをユーザに見せる。また、ページは最初は空白ではなく構造化されているため、ユーザはその定められた構造内で動くように制限される。ソフトウェア支配者のビジネスの全体は、独自のファイル形式、OS機能、およびその他の斯様な構成でコンテキストを課すことだ。彼らの関心は人々に自分のことをさせない点にあり、彼らの製品は進歩を促進するのではなく、常に妨げる。
人々がソフトウェアを販売すべきでない理由はない。（ジョエル・チャダベがかつて私に言ったように、検索し、ダウンロードしてコンパイルするという私のやっていることができない人々に使えるようにするのでさえ、［ソフトウェア販売は］とても有効な方法である。）音楽店舗にソフトウェアがあるのは良いことであり、Cycling74のような会社があることはとても幸運である。たとえマダガスカルに住んでいたとしても、あるバージョンをダウンロードし、自分のマシンで実行し、もし最初のMIDI入力がうまくいかなかったらEメールで訊くことができるのだ。ソフトウェア会社の存在は、利己的な行為に与しない限り、支え手である。
これは、商用ソフトよりもずっと大きな範囲であなた自身の目標をねじ込めるという、オープンソースのソフトウェアで得られる別種の可能性により補完される。単純に、商用ソフトの販売者によるいかなる制限もないからだ。商用ソフトウェア販売者は、製品へ特徴的な機能を搭載するよう、市場に強制される。これらの機能は、移植性や、それをPalmPilotとか冷蔵庫や自動車のマイクロプロセッサで実行できるようにすることへの、潜在的な障壁である。もっと一般的に、ソフトウェアの機能が多くなればなるほど、ソフトウェア設計者が想像していたものとは異なる可能性のある独自の目的への適用や、柔軟であることが難しくなる。優れたソフトウェア制作者は自身で多くを夢見ることができるが、ユーザはいつでも他のことを考えられる。私たちソフトウェア設計者は、制限や障害を課すことはなによりも避けようとするものの、完全に成功することはない。今日のソフトウェアが示す障害のいくつかは非常に根本的なものであり、私たちはそれらを見ることさえできないのかもしれない。
コンピュータ科学かコンピュータ音楽か？
ソフトウェアはスタイルが重要である。プログラミング内部のスタイルではなく、ソフトウェアがユーザを惹きつけるスタイルである。その外部スタイルが気に入れば、私たちはソフトウェアを歓迎する。適切に設計されたソフトウェアは、優れたデザインの家具と同じように仕事場をより良くする。それは機能性のみならず、私たちの環境の質を高め、気落ちさせない、スタイル上の選択においてである。
カラーより白黒、ひな形より空白のページ、階層構造より柔軟性が勝る、Maxの根底にあるスタイル上の傾向を説明するための合理的な論拠を見つけるのは難しい。Maxはコンピュータサイエンスではなく、コンピュータ音楽に関するものだ。多くのコンピューターサイエンスの成果が、Maxの設計に反映されている。しかしその設計は、コンピュータサイエンスの正統やソフトウェア設計および実装の厳格な教条に従わない。コンピュータ音楽のほかの多くのソフトウェアプロジェクトは、コンピュータサイエンスの路線をもっと密接に守っている。ただし、最も成功したもの（たとえば、Csound）は、コンピュータサイエンスの基準よりもまず文体に従った。
Csoundの成功（およびまだそれほど証明されてはいないMaxの成功）が、コンピュータサイエンス界を困惑させたり時にいらつかせているのなら、その失敗は、ソフトウェア設計と実装における、スタイルやさらには美学の重要性を理解することの欠如である。コンピュータサイエンスでは、コンピュータプログラムが使っていて楽しいかどうかを左右する尺度を、これまでに見つけてこなかった。
私たちはバイオリンを「演奏する」と言い、「作業する」とは言わない。音楽制作はものすごい量の作業を伴うが、そのミュージシャンが練習やリハーサルの試練を切り抜けられるのなら（少しもあるいは全く注力しないのはともかく）、演奏のように見えるべき、さらには感じられるべきですらある。コンピュータプログラムを使用するのが、銀行とかハンバーガーショップで働くことのように感じられるなら、ミュージシャンはそれを行わない（し、頼んではいけない）だろう。
理想的にはコンピュータは、調律が必要なだけですぐに演奏できる楽器のように、ミュージシャンの手に感じられる必要がある。Maxはこの理想に達しただろうか？ 確かにそれはなく、他のコンピュータ音楽ソフトウェアもまだだろう。少なくとも、長期的には良い方向への一歩であったと証明されることを願っている。
参考文献