SuperColliderによるネットワーク構築

はじめに

宇佐美理 — 2005-01-16T02:20:55+09:00

コンピュータによる音楽の制作・演奏形態において、ネットワークの環境を適用する場合には、大きく分けて2種類が考えられる。1つはローカルエリアでのネットワーク、もう1つはインターネットの活用である。この2つの違いは、そこから生み出される音楽の様式にも密接に係わっている。

歴史的に見れば、ローカルエリアでのネットワーク構築がコンピュータによるネットワーク音楽の出発点であった。それは1960年代から発展していたライヴ・エレクトロニクスの様式に70年代から普及し始めたパーソナル・コンピュータを応用しようとした実験の1つとして、70年代後半に登場した。サンフランシスコ湾岸地域を中心に活動したThe League of Automatic Music Composersがその担い手であり、彼らの活動は80年代から90年代にかけて活動したグループThe HUBへと引き継がれた。

その一方で、パーソナル・コンピュータが一般の家電製品として膾炙していったことを背景として、90年代にはインターネットが急速に拡大し、現在ではネットワーク音楽の舞台としても充分に環境が整ってきた。

ここでは、2種類のネットワークについて、リアルタイム音響合成のためのプログラミング・ツールである SuperColliderを使った制作の方法を具体的に述べたいと思う。

ローカルエリアでの形態

宇佐美理 — 2005-01-17T02:40:33+09:00

ローカルエリアにおいてコンピュータによるどのようなアンサンブルが可能であるかに関する実験は、前述の通り、 The League of Automatic Music Composers 及び The HUB などによって行なわれてきた。彼らによる様々な作品において多く見られる傾向として、個々のコンピュータにできる限り対等な役割を与えようとしているように思われる。それによって、コンピュータ間にインタラクティブな関係を築くことが可能となり、それこそが彼らの主な関心の対象であった。

しかし、複数のコンピュータの間に何らかの関係を持たせようとする場合に、まず考えられるのは、相互的で対等であるということよりも、一方のコンピュータで他方のコンピュータを一定の範囲で制御するということである。そのための代表的なプロトコルがMIDIであった。その意味において、The HUBによるMIDIの応用はかなり例外的であり、当然ながら、実験的なものであった。

恐らくMIDIが登場した際に最も画期的であったのは、複数の電子楽器による演奏において、1つのアンサンブルとしてリズムを同期させることが可能になったことであろう。これをSuperColliderでコンピュータ間のアンサンブルとして、どのように実現させることができるだろうか。

道具となるオブジェクトはSendTrigとOSCresponderである。まずはヘルプファイルを読むことにする。 SendTrigには以下のように書かれている。
「トリガ(0からゼロではない値への移行)を受け、クライアントに向けてサーバからトリガメッセージを送り返す。」

ここで「サーバ server」と「クライアント client」という関係が現れてくる。

「Serverオブジェクトは、サーバappをクライアント側で表現したものであり、SuperColliderランゲージ・アプリケーションからそのサーバappを制御するために用いられるものである。」
「. . . 、SC3はその操作をランゲージ・アプリケーション(SCを起動するためにダブルクリックする SuperCollider app)とシンセシス=サーバ・アプリケーション(scsynthというUNIXのコマンドラインによるアプリケーションで、[ランゲージ・アプリケーションの]起動時にデフォルトで作られるようになっている『ローカル』サーバのウィンドウ上にあるブート・ボタンを押した時、あるいはコードからServerをブートした時に起動する)との間で分割している。この2つのアプリケーションは、CNMATによって開発されたOpenSound Controlのサブセットを用い、UDPないしはTCPを通して互いに情報を伝達し合う。」

以上から分かるのは、ここで言われている「クライアント」とは、要するにランゲージ・アプリケーションを意味しているということである。SendTrigによってトリガを送るのは、そのSendTrigを含むSynthDefが送られ、それによって作られるsynthのノードを司るサーバであり、トリガが送られるのは、そのサーバを同じコンピュータ上から制御するランゲージappとなる。通常は指示を与える側であるクライアントがこの場合にはサーバからのトリガを受ける側になるため、SendTrigのヘルプファイルでは「クライアントへ送り返す send . . . back to the client」と表現されていたのである。

SendTrigのヘルプファイルに用例として挙げられていたものは、サーバappとランゲージappとが同じコンピュータ上のものとして扱われていたが、これを2つのコンピュータで行なうこともできる。

まずは、2台のコンピュータをハブを通してLAN接続するか、クロスケーブルで直接繋げるかし、ネットワークの設定を行なう。ここでは、192.168.0.1と192.168.0.2の2つをIPアドレスとして用いる。

まず、片方のコンピュータ(master)が用いるコードは以下の通りである。

// 相手のコンピュータ。
t = Server.new(\remote, NetAddr(“192.168.0.2”, 57110));

// 4秒毎にトリガが送られるようにする。
SynthDef(“trig”, { SendTrig.kr(Impulse(0.25), 0, 1) }
).send(t); // 定義を相手のコンピュータへ送る。

// トリガを送る。
t.sendMsg(“/s_new”, “trig”, x = t.nextNodeID, 1, 1);

そしてもう一方のコンピュータ(slave)が用いるコードは次のようになる。

s = Server.local; // こちら(クライアント)のIPアドレスは192.168.0.2

s.boot;

OSCresponder(
s.addr, 　// サーバからのメッセージを受けるようにする。
'/tr', // SendTrigから受けるOSCメッセージのコマンド名。
{arg time, responder, msg;
[time, responder, msg].postln;
} // ここで引数となっているものを画面に出力する。
).add;

この場合には、OSCresponderのactionを単なる引数の画面への出力にしているが、この部分を音響の出力に関係する処理にすれば、片方のコンピュータのリズムをもう一方のコンピュータのリズムに同期させることができる。

SendTrigによって送られるトリガは、'/tr'というコマンド名でOSCresponderによって受けることになるが、トリガ以外のデータ、つまり'/tr'以外のコマンド名を持つデータでも、OSCresponderによって受けることができる。その場合に、データを送るものとしてはNetAddrオブジェクトを使う。
メッセージを送る側の一般的な形は、

NetAddr(t.addr.hostname, 57120).sendMsg(“message”, 任意のデータ);
// ここではtがメッセージを受ける側のコンピュータを指す。
// ポート番号は57120を使用する。

となり、受ける側のOSCresponderは、

OSCresponder(
t.addr.port_(57120),
// ここではtがメッセージを送る側のコンピュータ
// を指す。ポート番号は57120。デフォルトでは
// 57110になっているので、変更が必要。
“message”, // コマンド名はmessage。
{arg time, responder, msg;
. . . // msg.at(1)で「任意のデータ」を取り出すことができる。
}
).add;

となる。

SendTrigの例とは違い、OSCresponderの一番目の引数はメッセージを送ってくる相手のコンピュータのNetAddrとなる。

こうした仕組みを使った、2台のコンピュータによる合奏の例を以下に挙げる。

ここでは、片方のコンピュータ(master)がメロディを奏で、もう一方のコンピュータ(slave)がそのメロディに合わせて別のメロディを奏でるようにしたい。そして、masterとなるコンピュータによって、両方のコンピュータのテンポを制御できるようにする。

まずはmasterから。

s = Server.local;

// slave
t = Server.new(\remote, NetAddr("192.168.0.2", 57110));

s.boot;

(
var timeValue;

// テンポを制御するためのGUIを作る。
w = SCWindow("tempo_control", Rect(100, 200, 300, 60));
w.view.decorator = FlowLayout(w.view.bounds);

EZSlider(
w,
250@20,
"tempo",
ControlSpec(80, 160, \lin, 1),
{arg ez;
~tempo = ez.value;
s.sendMsg("/n_set", 1000, "tempo", ~tempo/60);
NetAddr(t.addr.hostname, 57120).sendMsg("tempo", ~tempo)
},
120
);

w.front;

// テンポの初期設定
~tempo = 120;

//トリガと音のためのsynth定義を両方のサーバに送る。
SynthDef("trig", {arg tempo;
SendTrig.kr(Impulse.kr(tempo), 0, 1)
}).send(s);

SynthDef("trig", {arg tempo;
SendTrig.kr(Impulse.kr(tempo), 0, 1)
}).send(t);

SynthDef("sound", {arg freq;
Out.ar(
0,
SinOsc.ar(freq.midicps, 0, 0.1)
*EnvGen.kr(Env.perc, levelScale: [0.5, 0.5], doneAction: 2)
)
}).send(s);

SynthDef("sound", {arg freq;
Out.ar(
0,
SinOsc.ar(freq.midicps, 0, 0.1)
*EnvGen.kr(Env.perc, levelScale: [0.5, 0.5], doneAction: 2)
)
}).send(t);

// トリガを受けて音を繰り出す。
OSCresponder(
s.addr,
'/tr',
{ arg time, responder, msg;
r.stop;
r = Routine({
loop({
timeValue = 60/~tempo;
s.sendMsg(
"/s_new",
"sound",
s.nextNodeID + 1,
1,
1,
"freq",
[59, 60, 64, 65, 67].choose
);
(timeValue*[1, 1, 0.5, 0.25].choose).wait;
})
});
r.play;
}
).add;

// トリガを両方のサーバ上に作る。
s.sendMsg("/s_new", "trig", 1000, 1, 1, "tempo", ~tempo/60);
t.sendMsg("/s_new", "trig", 1000, 1, 1, "tempo", ~tempo/60);

);

slaveは以下のようになる。

s = Server.local;
t = Server.new(\remote, NetAddr("192.168.0.1", 57110)); // master

s.boot;

(
var timeValue;

// テンポの初期設定
~tempo = 120;

// トリガを受けて音を繰り出す。
OSCresponder(
s.addr,
'/tr',
{ arg time, responder, msg;
r = Routine({
loop({
timeValue = 60/~tempo;
s.sendMsg(
"/s_new",
"sound",
s.nextNodeID,
1,
1,
"freq",
[71, 72, 76, 77, 79].choose
);
(timeValue*[1, 1, 0.5, 0.25].choose).wait;
})
});
r.play;
}
).add;

// テンポのデータを受け、それを反映させる。
OSCresponder(
t.addr.port_(57120),
"tempo",
{arg time, responder, msg;
~tempo = msg.at(1)
}
).add;

);

こうしたローカルエリアでの利用によって、１台のコンピュータの能力を超えるような処理も、複数のコンピュータを使って行なうことができるようになる。コンピュータの性能が飛躍的に向上しているとはいっても、技術的な面で作り手の想像力を完全に満足させることはあり得ない。限界は常に存在する。それが意識できない作り手は、無自覚なまま経済の機構に飼い馴らされているに過ぎない。かと言って、高性能な機械が生産されるのを受動的に待ち、やがてそれを消費するというのも、作り手の態度としては消極的過ぎるだろう。本当の意味で実験的な作品とは、経済の領域と正しく対峙したものだと思われる。

インターネットを使った形態

宇佐美理 — 2005-01-17T02:41:51+09:00

新しい環境は新しい可能性を含むと同時に、それまでの可能性を排除することがある。しかし、従来の在り方ができる限り保たれるようにしようとするならば、インターネットを音楽の舞台として用いる場合、その前提となる条件として考えられるのは、まず以下のことであろう。すなわち、ローカルエリアと違い、複数のコンピュータが遠隔に位置することから、コンピュータを操作する演奏者の全ては同じ音を共有しているということが、プログラム上で実現されていなければならないということである。それによって、各演奏者はこれまでの音楽と同じように、アンサンブルの一員としての役割を果たすことができる。

理想的なコラボレーションの状態を考えると、インターネットを介してアンサンブルを構成する個々の演奏者がプログラミングの技術を持っていて、各々のプログラムを自ら作ることができれば、従来のラップトップ・アンサンブルと全く同じ形態が可能になるだろう。しかし、その際に気をつけなければならないのは、１台のコンピュータが行なう処理は自分のプログラムだけではなく、他のメンバーのプログラムも含まれるということである。そのため、ネットワークを用いない場合よりも、個々のプログラムにより実現可能な範囲は限定されることになる。

その一方で、インターネットを利用したアンサンブルの環境としてより一般的なものと思われる形態は、全ての演奏者が同じプログラムを使うものであろう。そこにおいては、全ての演奏者に対して同じだけのことが可能なこととして提供される。John Bischoffの"Aperture"(http://crossfade.walkerart.org/brownbischoff2/aperture/index.html, 2003)とChris Brownの"Eternal Music"(http://crossfade.walkerart.org/brownbischoff2/eternal/index.html, 2003)が、その例として挙げられる。

これらの作品は、JSyn(http://www.softsynth.com/jsyn/)とTransJam(http://www.transjam.com/)を用いて作られており、ウェブブラウザ上に演奏のためのインターフェイスが用意される。「作品」とは言っても、音楽として完成された形が既にあるわけではなく、ウェブサイト上にアップロードされている間は、誰もが自由に演奏者として参加できるようになっており、その意味では、固定されたアンサンブルよりも、インタラクティヴな音響彫刻に近い形態であると言える。

SuperColliderを用いる場合は、ウェブブラウザに依存することなくインターネットにおけるネットワーク構築を行なうことができる。ローカルエリアの項において既に触れたように、ランゲージappから制御するサーバappをネットワークを介して繋がっている他のコンピュータ上のものにすれば、インターネット上でも簡単にアンサンブルを作ることができる。ただ、ファイアウォールがポートフィルタリングによってOSCのパケットを破棄する場合もあり、セキュリティの設定を変更しなければならないこともある。

（未了）