2010年10月28日に開催されたSuperCollider・Max/MSP・PICnomeそれぞれのユーザーグループによる合同忘年会イベントにて、SuperColliderの発表時間に拙作「RAIN TOWER IV」の演奏会を開いていただきました。itaruさん本当にありがとう！
今日の演奏のハイライト部分
この作品はかんたんに言うと、「Twitterで参加できるオープンな音楽作品」です。
技術的には、特定のハッシュタグのツイートをTwitter Search APIから取得してツイートの内容をOSCメッセージに変換。OSCメッセージを受信したSuperColliderのプログラムで、特定のコマンドに反応して音楽を変化させる、というものです。
音楽は芸術なので、純粋に芸術的な要請によってどういう音楽なのかが決まっているのだろうか？音楽家の側はそうは思っていないが、一般的にはあまりそうは思われていないような気がする。一般的ないわゆる「曲」の長さが3〜5分前後なのは、なにか芸術的な要請があって決まっているという感覚を持っている人は多いのではないだろうか。しかし、音楽の姿は聴かれ方、受け取られ方によって決まる。
音楽が一部の特権階級の楽しみだった場合。
庶民にはない教養が観賞に必要な方が望ましい。そのため、音楽には格式高さと、美的センスの高さが求められる。ベートーベン以降のソナタがこの聴き方の最高峰だろう。
作曲理論的な構成が分かれば、この手の音楽は実に面白い。もっとも、複雑な曲の構成を記憶しながら聴くのは一苦労なので、繰り返しと言うシステムが考案された。呈示部を２回繰り返して演奏して覚えさせて、展開部で「おおこう展開したか！」と楽しみ再現部で「おおこう戻って来たか！」と楽しむ。クラシックに縁のない人には何を言っているのか分からないと思う。なかなかマニアックな世界だ。
また、日本の雅楽のテンポがやたらめったら遅いのも同じ様な理由。もともとは踊りに使うような軽快なテンポだったが、いちど廃れたものを儀式用として復活させたのが雅楽。格式高い儀式で使うため、厳かな雰囲気の演出のためテンポが限界まで遅くなったらしい。
音楽を聴くためにコンサートホールに行く場合。
当然わざわざ出かけて行くわけだから、すぐ帰されるわけにはいかない。移動時間、開演を待つ時間を考えたら、30分で終わったら不満だろう。だから1時間〜2時間のプログラムになる。それが人間が何かを楽しんで満足したと感じ、なおかつお尻が痛くて座ってられなくなる時間の境なのだろう。映画の上映時間も同じような理由で決まってると思う。選ばれる曲もある程度分かりやすく派手なものになる。ショパンとかリストとかね。
音楽を聴くためにCD・レコードをかける場合。
CDの再生時間がベートーベンの第九が入る長さというのは有名な話だが、このCDというフォーマットがアルバムという売り方を作った。流通の都合で値段が決まり、この値段を出すからには再生時間が短いと困る…ということで、アーティストはアルバムに10曲くらいは入れなきゃいけなくなった。
音楽を聴くためにテレビをつける場合。
この用途のために曲の長さは3〜5分、サビは30秒以内とかの決まりができた。5分くらいなら興味が無い歌手でも待てるので、お茶の間にぴったりってことでは？と勘ぐっている。サビの長さは言うまでもなくCMの長さだ。
その他にも、農作業で息を合わせるのに使う場合だったり、宗教儀式に使う場合だったり、飲食店の居心地を良くするためだったり、そりゃあもう考えられるありとあらゆる場所で音楽は存在して、人間に取って欠かせないものだと思う。だから、音楽のフォーマットは音楽自身の内側からの芸術的な要請によって決定されるのではなく、音楽の外側からの実用的な要請によって決定されるのだ。
もちろんそのことで音楽はつまらない、と言いたいのではない。それぞれの制約のもとで、音楽家はすばらしい作品を作って来た。むしろ、新しい音楽の聴取のあり方はなんだろう？と考えることで新たな制約が生じ、結果すばらしい作品が作れるんじゃないか？と考えることができる。
そのひとつとして、Twitterのような聴かれ方はアリじゃないだろうか？
いつでも会話に参加できるTwitterのゆるいつながりのように、時々つまみ食いのように参加してみるも良し。TLをぼーっと眺めているときのようにただ音を流しておくも良し。１時間聴いても１分聴いても同じ聴取体験といえる聴き方。
そう、つまり今作っている作品、RAIN TOWER IVの宣伝です。すいません。
まだベータ版ですがだいぶ作品が完成しましたので、5月15日（土）の午後から、ゆるーく聴けてTwitterから参加できる音楽をやります。聴くにはUSTREAM、参加するにはTwitterのアカウントが必要です。15日までにも突発的にプレ演奏（？）を行ないます。どちらもTwitter上で告知します。フォローミー！
Twitterの投稿（Tweet）から操作することにより、世界中の誰でもが同時に演奏に参加できる音楽を作曲していることは前回の記事で書いた。僕はこの作品を「RAIN TOWER IV」と名付け、開発中のベータ版テストとして2010年3月27日、午前1時〜3時にかけて事前予告無しにUSTREAM上に音楽を配信し、Twitter上で参加を募った。その結果、深夜であるにも関わらず10人以上のTwitterユーザーに積極的に演奏に参加してもらうことができ、USTREAM上での視聴も常に20人近くに上った。
その1時間50分に及ぶ公開演奏の最後の10分をUSTREAMで録画している。
画面にはSuperColliderのウィンドウが表示されている。後ろのウィンドウにはtweetを受信するたびに処理が行なわれたことを示す表示が現れる。前のウィンドウには、僕がTLを読んで反応したことを書き込んだりしている。
まぁ実際、あとから録音した音楽を聴いても全然、面白くない。しかし、再生しても面白くない音楽を面白く聴ける手段があるのだとすれば、これまで面白くないと切り捨てられていた荒野に無限の可能性が広がっていると言えないだろうか！わくわくしますね！
TwitterとUSTREAMの組み合わせの強力さに大きな可能性があることは、おそらくたくさんの人が感じていると思う。DOMMUNEを代表格として、音楽を配信することも多く行なわれるようになった。僕は個人的に「複数の人数で自由に参加できる音楽」というものをずっと研究して来たので、このTwitterとUSTREAMの登場にはまさに心が躍った！
そして、ある程度の完成度に達しながらも不満の残った前作「rain tower 3」の次のバージョンとして、現在「RAIN TOWER IV」という作品を開発している。
では前作のrain tower 3は何がダメだったか。それは参加する際の敷居の高さであった。
2006年のインターカレッジ・コンピュータ音楽コンサートで発表したrain tower 3は、ドラムマシンのようなシーケンサ状のGUIを複数人数で共有し、リズムパターンを変えたり、エフェクトをかけたりして遊ぶ音楽として設計された。当然、参加者が行なったGUIに対する操作をどうやって音楽に反映させるか、そして共有している音楽をどうやって参加者全員に配信するかと言う問題が発生する。
rain tower 3では、参加者が行なった操作をOSCメッセージ[1]としてホストコンピュータに集約し、参加者全員に再配信するという方法をとっている。しかし、これには参加者がまずホストコンピュータにログインすることが必要で、そのためにはまずSuperColliderとログイン用のプログラムをインストールする必要があり、さらに自分のマシンのIPアドレスを調べる必要があった。これは非常に敷居が高いと言わざるを得ない。演奏を行なう際はほぼ必ず、開発者の僕が参加者のマシンへのインストールをサポートする必要があった。これは無様だ。
このダメダメな作品を改善すべく、ログイン周りのプログラムの書き直しと簡単なチャットシステムをSuperColliderで書き進めていたのだが、ある日突然、そんなことをする気持ちが完全に失せた。もちろん、Twitterの存在を知ったからである。Twitterを、オープンなメッセージ送受信プラットフォームとして使用すれば、わざわざ新しいアプリケーションを参加者にインストールしてもらう必要は無い。また、多人数で音楽を共有する手段も、USTREAMの登場によって解決された。いやー、実にいい時代ですね！
しかし、TwitterとUSTREAMというツールを使うことにより、新たな問題も発生させた。昨年12月に行なった最初の実験でも明らかになった問題点は以下の3点だ。
もちろん、この作品専用のGUIを開発してもいいのだが、敷居を下げるというコンセプトには合わない。できれば、誰もが普段使っているTwitterクライアントでも参加できるのが望ましい。となると、どういう方法で参加すれば良いか。
とりあえず、音楽に反映されるまでの時間のダイナミックさを損なわないよう、短いコマンドと数値の組み合わせをツイートするという手段をとることにした。これに関しては色んなアプローチがあると思うので、いいアイディアを探しているところだ。
SuperColliderでOSCをやり取りする場合、高速なUDP/IP通信を用いるため、タイムラグはほとんど問題にならなかった。しかし、Twitterではそうはいかない。通信プロトコル以前にツイートしてから検索結果に反映されるまで、どうしても数秒のタイムラグは発生してしまう。また、Twitter APIへのリクエスト回数も、Twitterは明らかにしていないが制限があると思われるので、１秒間に何回もリクエストするわけにはいかない。さらに、USTREAMでもタイムラグは存在するので、結局ツイートしてから音楽に反映されるまで10秒以上かかってしまう。
この問題に関しては、タイムラグがあっても構わない方法を探るほかない。また、よりリアルタイムに近い検索を可能にするTwitter Streaming APIの実用化も探っている。
ユーザーのマシンにアプリケーションをインストールし、そのアプリケーションが音楽を再生する場合はもちろん音質は問題ない。しかし、USTREAMでの配信では限界がある。
この問題に関しても、USTREAMを使うということは、モバイル機器からでも参加可能な音楽になるということで、高音質が前提の音楽では似合わないだろう。ふさわしい音楽にするしかない。
以上の問題を踏まえて、バージョンアップしたRAIN TOWER IVのベータテストを2010年3月27日、午前1時〜3時にかけて行なった。のだが、長くなってしまったのでこの詳細については次の記事でご報告したい。
[1] 音響合成のためのプログラミング言語「SuperCollider」はマシン上のサーバーに対してメッセージを送り、サーバーがそのメッセージを処理して音を発すると言う特殊な仕組みを採用している。ローカルマシン上のサーバーだけでなく、Open Sound Control（OSC）というプロトコルにより、ネットワークを介して他のマシンのSuperColliderサーバーに対してもローカルマシンと同様にメッセージを送信することができる。