Vol. 43

No. 2

Feb. 2002

情報処理学会論文誌

Open RemoteGIG：
遅延を考慮した不特定多数による遠隔セッションシステム
後

藤

真

孝†

根

山

亮††,☆

本論文では，Internet のような広域ネットワークを経由して，不特定多数のユーザが遠隔地間でジャムセッションできるシステム Open RemoteGIG を提案する．本研究は，物理的に 1 カ所に集まらな
くても，音楽的なインタラクションを楽し むことができるセッションを実現することを目的とする．
従来，遅延の小さいネットワークを介した MIDI 中継は実現されていたが，遅延の大きい Internet
等を介した双方向の MIDI 中継によって，調性とリズムのある音楽を合奏することはできなかった．
そこで本研究では，不可避な遅延を積極的に利用した，調性とリズムのある音楽のための新たな形態の遠隔セッションシステム Open RemoteGIG を実現した．Open RemoteGIG では，同一のコード 進行（ 12 小節のブルース進行等）の繰返しを，テンポ一定で演奏することを前提として，遠隔地にいる複数の演奏者が Internet 経由のセッションを行う．演奏者は，お互いの演奏をコード 進行の 1
周期の整数倍の時間だけ遅れて聞き合いながら，即興演奏する．コード 進行は繰り返すため，遅延した演奏は再び同じコード となり調和する．さらに，Open RemoteGIG は，演奏相手の発見環境や打合せ用のチャット機能も提供する．MIDI 中継は音楽用通信プロトコル RMCP に基づいて実装され，実際に遠隔地間で提案したセッションをできることが確認された．

Open RemoteGIG: An Open-to-the-public
Distributed Session System Overcoming Network Latency
Masataka Goto† and Ryo Neyama††,☆
This paper describes a distributed session system called Open RemoteGIG which enables
widely distributed musicians to join a worldwide jam session by using the Internet. Our goal
is to have musicians participating in a truly interactive jam session without getting together
physically. Although MIDI transmission via small-latency networks has been tried, performing a distributed jam session with tonality and rhythm has been considered diﬃcult when
we use a long-latency public network like the Internet. We therefore developed an innovative distributed session system for music with tonality and rhythm, Open RemoteGIG, whichturns the long inevitable network latency to its advantage. In Open RemoteGIG, distributed
musicians can interact over the Internet under the assumption that the tempo is constantand the chord progression is repetitive, like that of 12-bar blues. Each musician can improvise while listening to the others’ performances that are intentionally delayed for multiplesof the constant period of the repetitive chord progression; the delayed performance can ﬁt
the chords because the progression is repetitive. Open RemoteGIG also supports a musicianﬁnding and group-chatting environment. The MIDI transmission was implemented by using a
music network protocol called RMCP and we conﬁrmed that the proposed distributed session
was achieved.

1. は じ め にピューティングの普及にともない，専用回線や専用装

遠隔地間の人間同士のコミュニケーションは，In-

し，音楽による演奏者同士のコミュニケーションであternet のような広域ネットワークやネットワークコン

るジャムセッションや合奏は，依然として物理的に 1

置を用いずに実現できる環境が整いつつある．しかカ所に集まらなければ実施が困難な状況にある．遠隔† 独立行政法人産業技術総合研究所（旧電子技術総合研究所）
National Institute of Advanced Industrial Science andTechnology (former Electrotechnical Laboratory)†† 早稲田大学理工学部
School of Science and Engineering, Waseda University☆
現在，IBM
Presently with IBM

地間でジャムセッションや合奏を行うことができれば，物理的に異なる場所にいる相手と，距離の制約を超えて音楽的なインタラクションを楽し むことができる．
さらに，実世界では困難な，面識のない複数の演奏者と国境を超えたセッションも可能となる．本研究は，
299

300

情報処理学会論文誌

Feb. 2002

このような遠隔セッションを可能にするシステムを実

スター状のネットワーク接続によって，すべて中央に現することで，新たな形態の遠隔地間の合奏や，音楽集められる．そして，自分以外の演奏情報が，コードにおける新たなインタラクションを探求することを目

進行の 1 周期の整数倍の時間だけ遅延して送り返さ的とする．

れてくることで，全ユーザが互いの演奏を聞き合いな

従来，調性とリズムのある音楽を遠隔地間でセッショ

がらセッションできる．Open RemoteGIG ではさらンすることは，Internet のような遅延時間の長いネッに，演奏相手を発見するための環境や，演奏内容の打トワーク経由では困難と考えられていた．ISDN や In-

合せ等を可能にするチャット機能も提供する．なお，

ternet2，衛星中継等を用いて，MIDI あるいは演奏音

ユーザは演奏を行わずに，他人の演奏を観客としてを遠隔地間で中継した事例はあるが 1)∼3) ，遅延時間が鑑賞してもよい．これを活用すれば，Internet 上での小さいことを前提としており，長距離になると同時性

Open RemoteGIG の公開ライブパフォーマンスも実1)が失われて実用上問題があることが指摘されていた ．

施できる．

そのため，不特定多数が利用する Internet のような

以下，2 章において通信プロトコル RMCP を用い

ネットワークでは，実用的には企業等によって片方向

た RemoteGIG の実現方法を述べ，東京とニューヨーの MIDI 中継しか試みられていなかった．遠隔地にいク間で Internet を介して実施した実験コンサートのる複数のユーザに，演奏をリアルタイムに自動生成す結果を報告する．次に，3 章において本研究が提案するプロセスを制御させるアプローチ 4),5)や，楽音生成

る Open RemoteGIG の機能を紹介し，システムの構プロセスのパラメータ時変化を共同作曲（指定）させ成と具体的な実装方法を説明する．本実装では，演奏るアプローチ 6) も提案されたが，制約が大きく，演奏

情報の中継機能は C 言語で実装されているが，ユー者が通常の楽器（ MIDI コントローラ）を用いてセッ

ザは WWW ブラウザを用いて Open RemoteGIG のションに加わることはできなかった．音響信号のスト

WWW ページにアクセスすることで，遠隔セッション

リームに複数のユーザが各自の演奏を順次混合していに参加することができる．最後に，4 章において Re-

くシステム7) もあるが，演奏中のユーザ間のインタラ

moteGIG や Open RemoteGIG による遠隔セッショ

クションは得られなかった．このように，Internet をンの意義を議論し，5 章でまとめと今後の研究の方向経由した遠隔地間で，調性とリズムのある音楽の合奏性を述べる．

（ 双方向の MIDI 中継）を可能にするシステムは，実現されていなかった．
このような遠隔セッションを可能にするために，我々

2. 遅延を考慮した遠隔セッション：RemoteGIG

は文献 8)，9) において，RemoteGIG を提案した．

RemoteGIG は，遠隔地間で遅延が大きい状況を考

RemoteGIG は，Internet 等で不可避な遅延を積極的慮した，新たな演奏のモデルに基づくセッションであに利用した，新たな形態の遠隔地間のセッションである．演奏者が 1 カ所に集まってセッションを行うとき

る．RemoteGIG では，同一のコード 進行（ 12 小節のの伝統的なモデルは，他者の演奏音を小さい遅延時

ブルース進行等）の繰返しを，テンポ一定で演奏する

間で聞くことができ，それに反応して演奏する自分のことを前提とし ，遠隔地にいる 2 人の演奏者が即興

演奏音も小さい遅延時間で相手に届くことを前提とでネットワーク経由のセッションを行う．演奏者はおしている．しかし，光速でさえ地球を半周するのに約互いの演奏を，コード 進行のちょうど 1 周期分の時間
コード 進行は繰り返すため，演奏が 1 周期分遅れれば66 msec もかかってしまうことから分かるように，遠隔地間で通信する際には，ネットワークの遅延時間を回避することは不可能である☆ ．したがって，遠隔地

再び同じコード となり調和することが期待できる．

間のセッションのためには，伝統的なモデルに代わるだけ遅れて聞き合うことでインタラクションを行う．

本論文では，この RemoteGIG を不特定多数のユーザが演奏できるように拡張した遠隔セッションシステ

演奏のモデルが必要となる．
遠隔地にいる 2 人の演奏者がセッションする際のム Open RemoteGIG を提案する．RemoteGIG は

RemoteGIG のモデルを，図 1 に示す．本モデルは，知人同士でしか実施できず，運用場面が限定されてい同一のコード 進行の繰返しを，その 1 周期分の時間

たが，Open RemoteGIG によって面識のないユーザ(D) を一定にして演奏することを前提とする．そし間のセッションを達成することで，より現実的な場面に適用可能とする．Open RemoteGIG では，遠隔地にいる全ユーザの演奏情報が，Internet 等を経由した☆

将来的に，地球と月にいる演奏者がセッションをする場合には，光速でも地球から月へ届くのに約 1.28 sec かかる．

Vol. 43

No. 2

Open RemoteGIG：遅延を考慮した不特定多数による遠隔セッションシステム

Fig. 2301

図 2 RMCP による遠隔地間のパケット中継
RMCP-based packet relay between remote sites.

図 1 RemoteGIG のモデル
Fig. 1 RemoteGIG session model.

分散音楽情報処理に適した効率が良く実用的な情報共て，演奏者はお互いの演奏を，ちょうど 周期 D 分の有を達成している．具体的には，Ethernet 等の LAN

時間だけ遅れて聞き合い，それに反応して即興演奏す（ Local Area Network ）内の通信には UDP/IP を用る．たとえば，図 1 において，演奏者 A の A-1 の区

いて，ブロードキャストによるオーバヘッドの小さい間の演奏音は，演奏者 B のもとでは B-2 の区間で鳴情報共有を実現する一方，Internet 等の WAN（ Wideる．コード 進行は繰り返すため，A-1 のある演奏音がで鳴るときのコードと一致して調和する．このように，

Area Network ）経由の通信には TCP/IP を用いることで，信頼性を確保した情報共有を可能にしている．
2.2 RMCP による RemoteGIG の実装

RemoteGIG のモデルは遅延がコード 進行 1 周期分の時間よりも短ければよく，遠隔地間のセッションに適

RMCP によって RemoteGIG を実現する際の，プロセス構成の例を図 2 に示す．RemoteGIG は，MIDIしている．

メッセージを MIDI 機器から受信するための RMCP

鳴っているときのコードは，その音が伝送されて B-2

2.1 実 現 方 法
RemoteGIG を実現するには，大別して，音響信号て演奏するための RMCP MIDI Station，受信パケッを直接中継する方法と，MIDI 信号のようなシンボル

ト中の MIDI メッセージを MIDI 機器へ送信するた化した演奏情報を中継する方法の 2 種類が考えられ

めの RMCP Sound Server，WAN で結ばれた 2 つMIDI Receiver，計算機のキーボード とマウスを用いる．音響信号の中継は，使用楽器の制約がない反面，の LAN 間で双方向に RMCP パケットを中継するた

MIDI 信号に比べて非常に伝送量が多く，受信側で演

めの RMCP Gateway，標準 MIDI ファイル（ SMF:

奏情報を再利用・加工しにくいという欠点がある．そStandard MIDI File ）を再生するための RMCP SMF
Player によって実現される．
演奏者が MIDI 楽器等を弾いて生成した MIDI メッ

こで本研究では，MIDI 信号を双方向に中継することで RemoteGIG を実現する．
一定の遅延時間で双方向の MIDI 中継を行うには，セージが，どのように伝送されて RemoteGIG が実施

ネットワーク経由で MIDI 信号を伝送し，適切な時刻されるかを，LAN と WAN の場合を分けて説明する．

となるまでバッファリングして再生する必要がある．
プロトコル RMCP（ Remote Music Control Proto-• LAN 上での MIDI メッセージの伝送
演奏者は，RMCP MIDI Receiver か RMCP MIDI
Station を用いて演奏する．これらがブロードキャ

8)∼12)
col ）を用いた．RMCP では，演奏情報は RMCP
パケットという単位で伝送され，MIDI note on/oﬀ 等

すると，パケットに含まれる MIDI メッセージをの各 MIDI メッセージは，1 つの RMCP パケットのMIDI 楽器へ送り，演奏音として出力する☆ ．

本研究では，このために，我々が設計した音楽用通信

ストしたパケットを RMCP Sound Server が受信中に包まれて送信される．RMCP は，• タイムスタンプを用いたパケットの時間管理• 信頼性を確保した遠隔地間の双方向パケット中継の 2 つの機能を提供できることから，今回の目的に適している．さらに RMCP は，運用するネットワークの性質・信頼性に応じて下位レイヤを使い分けることで，☆

詳しい記述は文献 8)，9) に譲るが，これらのパケットを RMCP
Display Server が 同 時に 受 信し て 視 覚 化し た り，RMCP
Packet Recorder が 受信し て 記 録し た りで き る ．これ は ，
RMCP がブロードキャストによって LAN 上で通信する利点の1 つである．

302

Feb. 2002

情報処理学会論文誌• WAN を経由した MIDI メッセージの伝送
図 2 のように，双方向のパケット中継をする WANの MIDI 音源（ Roland SC-55mkII ）により演奏音を出力した．また，会場にいる聴衆が，日米のどちらのの両端で RMCP Gateway を実行し，TCP/IP の演奏者が弾いた音かを容易に確認できるよう，画面上

コネクションを確立する☆ ．各 RMCP Gateway は，の鍵盤の色を変えて MIDI 情報を視覚化する RMCP

自分の LAN 上にブロードキャストされた RMCP

Display Server を動作させた．さらに，ビデオカメラ

パケットを，他方の RMCP Gateway へ送信する．

で撮影した動画を Internet を経由して中継し ，演奏

逆に，他方からのパケットを受信すると，遅延時間

会場の風景をお互いに見ることを可能にした．

が一定となるようにタイムスタンプ（パケットがRMCP Gateway による中継用遅延時間は，両会場処理されるべき時刻を表す）を書き換えて，自分の間のネットワークの遅延時間（ 約 0.25 秒）に比べてLAN 上にブロードキャストする☆☆ ．これにより，十分大きい値である 30.72 秒に設定した．そして，こ一方の演奏者が RMCP MIDI Receiver 等を用い

れがコード 進行 1 周期となるようなテンポで，伴奏て演奏した MIDI メッセージは，RMCP Gateway

用のベースとド ラムス等が含まれた SMF を再生しによって中継されて他方の LAN の RMCP Sound

た．具体的には，1 曲目（ 後藤真孝作曲）は 4/4 拍

Server にも届き，演奏音として出力される．

子 12 小節のブルース進行の曲であったため，テンポ

以上のように，自分の演奏音が，自分と相手のもと93.75 M.M.（ 4 分音符 = 640 msec ）で演奏した．2 曲にある MIDI 楽器によって出力されることで，遅延目（ Rick Bassett 作曲）は 4/4 拍子 16 小節のコード付きの遠隔地間のセッションが行える．なお，コード進行を持っていたため，テンポ 125 M.M.（ 4 分音符

進行の周期を遅延時間と同一に保つためには，コードを SMF に記録しておき，RMCP SMF Player を用い= 480 msec ）で演奏した．
実験の結果，知覚できるテンポの揺らぎやパケットロスは発生せず，実際に遠隔地間で RemoteGIG が行ていずれかの LAN 上で再生するとよい．この伴奏もえることを確認した．

とリズムが分かるような伴奏（ベースとド ラムス等）

RMCP Gateway によって中継され，両者で共有される．

2.4 考

察

2.3 実
験
RemoteGIG の有効性を実証するために，日米イン
ターカレッジ・コンピュータ音楽フェスティバル（第RemoteGIG の実験を通じて得られた考察を以下にまとめる．
• 演奏の形態

13),14)
23 回音楽情報科学研究会）の一環として，日本
時間 1997 年 12 月 14 日（日）午前 11 時（ニューヨー

RemoteGIG では，演奏開始時，ソロ演奏時，演奏終了時において，1 カ所に集まって行うセッションとはクでは 13 日（土）午後 9 時）より，コンサート形式で異なる演奏形態が求められた．その一例を図 3 に示す．

の公開実験 “Internet RemoteGIG” を実施した☆☆☆ ．

まず演奏開始時には，B-1 の演奏が演奏者 A に届くま

東京の NTT ICC（ InterCommunication Center ）とでに 2 コーラス（コード 進行 2 周期分）かかってしま

ニューヨークのコロンビア大学との間で，Internet をう．その A-1 と A-2 の期間，演奏者 A は 1 人で演奏経由して RemoteGIG を行った．日本側の会場となっをする必要があった．

た NTT ICC では，Rick Bassett が MIDI キーボード

次にソロ演奏に関しては，1 カ所のセッションだと数で演奏した．一方，USA 側の会場となったコロンビア

コーラス交代でソロを弾いても問題は起きないが，Re-大学では，2 曲演奏した中で，1 曲目を Brad Garton

moteGIG では問題になる．たとえば演奏者 A が A-1

が MIDI キーボード で演奏し ，2 曲目を Perry Cookと A-2 のソロ演奏の後に A-3 で演奏者 B のバッキンが自作の MIDI コントローラーを用いて演奏した．
それぞれの会場では SGI O2（ IRIX-6.3 ）を 1 台占有使用し，RMCP Gateway，RMCP Sound Server，

RMCP MIDI Receiver を動作させた．そして，同種☆

RMCP Gateway の実装方法は，文献 9) に述べられている．
中継の無限ループを回避するために，パケットヘッダ 中の中継禁止フラグをセットしてからブロード キャストする．
☆☆☆
調性とリズムのある音楽を Internet を経由して遠隔地間でセッションしたコンサートとしては，我々の知る限り世界で初めての試みであった．
☆☆

Fig. 3図 3 RemoteGIG の演奏形態の一例
An example of RemoteGIG performance.

Vol. 43

No. 2

Open RemoteGIG：遅延を考慮した不特定多数による遠隔セッションシステム

303

グに移るとすると，本来は演奏者 B は B-1 でソロを

moteGIG に基づいているが，RemoteGIG をそのま弾いていなければならず，演奏者 B のもとでは A-1

ま不特定多数のユーザに対して運用しようとすると，のソロと B-1 のソロが重なってしまう問題が生じる．

以下のような問題が生じてしまう．

そこで今回は，2 小節交代あるいは 4 小節交代で，ソ(1)

演奏者を増やすためには，すべての演奏者のロとバッキングを繰り返し 演奏する形式を考案した．

LAN 間で，RMCP Gateway による全対全結合

たとえば，16 小節のコード 進行を 4 小節ずつに分割のコネクションを確立しなければならなかった．

して，「 A のソロを 4 小節 → B のソロを 4 小節 → A(2)

遅延時間等はコネクションを確立した後に変更のソロを 4 小節 → B のソロを 4 小節」という形式でできなかったため，コネクションを張ったまま演奏した．さらに，演奏の進行にともない，交代するで様々な曲を演奏するには，コード 進行の周期

小節数を短くしていくような形式も効果的であった．

を合わせなければならないという制約があった．

演奏終了時には，伴奏の終了とともに演奏を終えるた(3)めの工夫が必要であった．そこで，図 3 の S-6 と S-8の伴奏の位置にフィルイン等の合図を入れておき，演
奏者 B は S-6 を聞くと演奏を終了し，演奏者 A は S-8

事前に演奏相手を定め，両者の LAN 間でコネク
ションを確立しておく必要があった．そのため，面識のない相手と演奏することはできなかった．

(4)

伴奏に用いる SMF の情報は，事前に内容が確を聞くと演奏を終了することとした．

定しているにもかかわらず，演奏中に伝送して以上をふまえた RemoteGIG の拡張案としては，SMF

いた．これは汎用性を持たせるためには有効なを事前に送っておいて，両者の演奏開始時刻を合わせ設計であったが，Open RemoteGIG のようにる機能を実装することがあげられる．これにより，図 3

多数の演奏者が参加する場合には，伝送容量をの演奏者 B の演奏開始を 1 コーラス早めることができる（演奏者 A のもとでは A-2 と B-1 が重なる）．そ

圧迫してしまう点が問題となる．

(5)

2.4 節でも指摘したように，音楽以外のコミュ

して，両者が奇数番目のコーラスにソロを演奏し，偶ニケーション手段は提供していなかった．しか数番目のコーラスにバッキングを演奏することで，1も，演奏者が 3 人以上の場合は，多対多のコ

コーラスごとに交代する演奏形式も可能となる．また，ミュニケーション手段が必要となる．

RMCP Gateway に MIDI 中継を途中で中止する機能

そこで本研究では，これらの問題を以下のように解を実装すれば，MIDI 中継を S-8 の直後にやめること

決することで，Open RemoteGIG を実現する．

ができ，両者が伴奏の最後まで演奏できるようになる．

(1)

スター状のネット ワーク接続• 音楽以外のコミュニケーション手段の必要性

Open RemoteGIG では，演奏中継用のセンタ

演奏前後の準備等でお互いの状況を的確に伝達するたを用意する．そして，各ユーザは自分の計算機

めには，演奏音以外のコミュニケーション手段も不可から，Internet 等の WAN 経由でセンタに接続欠であった．そこで今回は，UNIX の talk コマンド（コネクションを確立）するだけで，他の複数によりテキストベースでリアルタイムチャットを行っのユーザの演奏音を同時に聞きながら即興演奏

た．このような手段の確保は，コンサート形式で実施ができる．4 人の演奏者がセッションする際のする場合必ず考慮する必要がある．

• ネット ワークト ラフィックの問題
コンサート中は問題が起きなかったが，Internet の混Open RemoteGIG のモデルを図 4 に示す．このようなシステムでは時間軸方向の制御が重要であるが，Open RemoteGIG では全ユーザ間雑状況によっては，演奏中の遅延時間がコード 進行 1
周期よりも突然長くなってしまうことがあった．コン
サート前に早稲田大学とコロンビア大学間でリハーサ
ルを繰り返した際には，日本時間の夕方等に，ほとん
ど TCP/IP パケットが通らない状況も発生した．

3. 不特定多数のユーザが参加できる遠隔セッ
ション：Open RemoteGIGOpen RemoteGIG は，多数の人が自由に RemoteGIG に参加することを可能にする遠隔セッションシ
ステムである．これは，基本的には 2 章で述べた Re-

図 4 Open RemoteGIG のモデル
Fig. 4 Open RemoteGIG session model.

304

Fig. 5図 5 Open RemoteGIG のシステム構成
System configuration of Open RemoteGIG.

るようにする．

SMF の事前伝送
コード 進行 1 周期分が記録された SMF を演奏
前にダウンロードしておき，各ユーザのもとで

中継用遅延時間を動的に変更できる演奏中継

繰り返しループさせて再生する．その際，ユーRemoteGIG と同様に同一のコード 進行を繰りザ同士の即興演奏が時間軸上で調和するために，返し演奏することを前提とし，コード 進行 1 周

SMF の再生開始時刻が全ユーザのもとで同一の仮想時刻となるように調整する．なお，SMFが使用する MIDI チャネルは，上記の割当て用で共通の仮想時刻（たとえばセンタの時刻）を(4)

設定し，仮想時刻上で図 4 のような演奏が行え(2)

期の整数倍の遅延時間で演奏情報（ MIDI メッセージ）を中継する．その際，コネクション確立

MIDI チャネル以外を使用しなければならない（現在の実装では，伴奏が 10〜16 チャネルを使後の任意の時点で遅延時間を変更できるようにすることで，様々なコード 進行の異なる周期に対応可能とする．また中継用遅延時間は，ネッ
トワークの遅延時間よりも十分長くなければな(3)

Feb. 2002

情報処理学会論文誌

用する）
．

(5)

テキストベースのリアルタイムグループチャット

らないという前提を考慮しながら，コード 進行

演奏音以外のコミュニケーション手段として，の何周期分とすべきかを決定する．

任意のユーザ間の多対多のチャットを実現し ，演奏相手の発見環境

演奏内容の打合せ（たとえば，ソロを何小節ごセンタに接続している他のユーザを見つけ，一緒に演奏を開始できる環境を用意することで，面識のない相手との遠隔セッションを可能にする．

とに交代するか ）等を可能にする．
本研究ではさらに，Open RemoteGIG の機能として以下の 2 つを提案する．

プログラム番号）で正し く再生されるために，• 仮想演奏スタジオの切替え（ 入退室）機能
複数の仮想演奏スタジオ（ GIG チャネルと呼ぶ）

ユーザに対して MIDI チャネルを排他的に割を用意し ，異なるユーザグループが独立に Re-

ただし ，各ユーザの演奏が異なる音色（ MIDI

り当てるよう管理する（ 現在の実装では，1〜moteGIG セッションを行うことを可能にする．

9 チャネルを割り当てている）．そのため，同時に演奏できる人数は割当て MIDI チャネル数に制限される．なお，全ユーザのもとでプログ

GIG チャネルごとに異なる伴奏の SMF を用意しておけば，ユーザは GIG チャネルを切り替えることで，好みの伴奏に合わせて即興演奏ができる☆ ．

ラム番号と音色の対応の一貫性を保つために，

前述の MIDI チャネルの割当ては，この GIG チャ

MIDI 音源として GM（ General MIDI ）音源を用いることを前提とする．

☆

GIG チャネル 1 はフュージョン風，GIG チャネル 2 はジャズ
風，GIG チャネル 3 はロック風，といったように，様々なジャンルの伴奏をセンタ側で用意しておくと効果的である．

Vol. 43

No. 2

Open RemoteGIG：遅延を考慮した不特定多数による遠隔セッションシステム

ネルごとに独立に行う．
• 観客の立場での演奏の鑑賞機能

305

示を受信し，それに応じた処理を行う．

– 「伴奏用 SMF のダウンロード 」

演奏に参加せずに，他のユーザの演奏音だけを聞

RMCP RGIG Center との接続時に，全 GIG チャ

く機能（鑑賞モード ）を提供する．これにより，即ネル分の SMF （テンポ，コード 進行 1 周期の興演奏のできないユーザでも観客の立場で Open

長さ，開始仮想時刻も含む）を受信する．

RemoteGIG を利用できる．あるいは，すべてのMIDI チャネルが割当て済みのときに，MIDI チャ– 「 GIG チャネルの指定」
指定チャネルの伴奏用 SMF に切り替え，そのネルが空くまでは観客として待機してもよい．こコード 進行の周期とネットワークの遅延時間にの機能を活用すれば，大勢の観客に対し ，Open

基づいて，新たな中継用の遅延時間を決定する．
– 「 SMF の演奏開始/演奏停止」

RemoteGIG の公開ライブパフォーマンスを Internet 上で実施できる．
3.1 システム構成
Open RemoteGIG のシステムは，演奏中継用のセンタである RemoteGIG Center と，各ユーザがセンタに接続するための RemoteGIG Transceiverで構成される．システムの構成図を図 5 に示す．Open

演奏開始を受信すると，開始仮想時刻とコード進行の周期から次回の伴奏開始実時刻を計算し，演奏停止を受信するまで無限に繰り返しながらSMF を再生する．
– 「鑑賞モード /演奏モード（ 割当て MIDI チャ
ネルの指定付き）の変更」

RemoteGIG の機能は，演奏中継機能と GUI・コミュ

RMCP RGIG Center への MIDI メッセージのニケーション機能に二分でき，前者は RemoteGIG と送信に関して，鑑賞モード のときはいっさい送同様に RMCP を用いて実現し ，後者は WWW ブラ

信せず，演奏モード のときは指定 MIDI チャネ

ウザ上で動作するように Java Applet として実現す

ルのみ送信する．

る．実際の MIDI 楽器との入出力には，2.2 節で述べたように RMCP Sound Server，RMCP MIDI Receiver等を用いる．

– 「 MIDI のオールノートオフ/プログラム番号
変更の送信命令」
当該 MIDI メッセージをブロードキャストする．

3.1.1 RemoteGIG Transceiver
RemoteGIG Transceiver は，ユーザの演奏情報を• GUI Client
ユーザ用の GUI は，演奏管理ウィンドウ（図 6 ）とネットワークを経由して送受信するための RMCP RGIG

コミュニケーションウィンド ウ（図 7 ）で構成されTransceiver と，ユーザからの指示を伝達したり他のる．ユーザは，GUI Client を起動して GUI Server

ユーザの属性を表示したりする GUI Client から成る．

に接続した後に，コミュニケーションウィンド ウで

ただし ，図 5 に示したように，両者は直接通信せず，演奏相手を見つけて希望の GIG チャネルに切り替

つねに RemoteGIG Center を経由する．

え，演奏管理ウィンド ウで演奏状態を変更して演奏• RMCP RGIG Transceiver
演奏中継に関しては RMCP Gateway と同等の機能を開始する．

を持ち，後述する RMCP RGIG Center と TCP/IP（図 7 ）の左下で，名前を入力して login する．するを用いて RMCP パケットを送受信する☆ ．その際，と，右の “All Users” のサブウィンド ウに，全参加

RMCP RGIG Center へ送信する前に，パケットのタ
イムスタンプを実時刻（ローカル時刻）から仮想時刻に変換する☆☆ ．また，RMCP RGIG Center からを指定してチャット可能となる．グループチャットを

ユーザは参加時に，コミュニケーションウィンド ウ

ユーザの一覧が表示され，任意のユーザ（複数も可）
簡便に行うために，新たなサブウィンド ウ（ “Chat

受信したパケットのタイムスタンプを仮想時刻からGroup:番号” ）を作成し ，選択したユーザを登録し実時刻に変換し，中継用遅延時間を加えた後に LANておく機能もある．チャット相手を切り替えるには，

上にブロード キャストする．

このサブウィンド ウをクリックするだけでよい．そさらに，RMCP RGIG Center から以下のような指して，“GIG Channel” のメニューから GIG チャネ☆

ド ウが現れ，そこで演奏/鑑賞しているユーザの一

ル番号を選ぶと，“GIG Channel:番号” のサブウィン
異なる RMCP サーバ番号やソケットポート番号を用いれば，同一 LAN 上で複数の RMCP RGIG Transceiver を独立に運用できる．
☆☆
これは，文献 9) の RMCP Gateway による内部時計の時刻差の補正と同等の処理である．

覧が表示される．その後，演奏管理ウィンド ウの操作に移れるようになる．
演奏管理ウィンドウ（図 6 ）では，SMF の演奏開始

306

情報処理学会論文誌

図6
Fig. 6

Feb. 2002

GUI Client の演奏管理ウィンド ウ
Manager window of GUI Client.

図 7 GUI Client のコミュニケーションウィンド ウ
Fig. 7 Communication window of GUI Client.

（ “Start” ）・停止（ “Stop” ），鑑賞モード（ “Listen” ）は，演奏開始/停止命令，MIDI オールノートオフ送と演奏モード（ “Play” ）の切替え，割当て希望 MIDI

信命令がある．

トオフの送信を指示できる．

• RMCP RGIG Center
全 RMCP RGIG Transceiver からのコネクションを受
け付け，GIG チャネルごとに分けて管理する．RMCP

3.1.2 RemoteGIG Center
RemoteGIG Center は，演奏情報を全ユーザのもた後は，受信したユーザの演奏（ RMCP パケット ）とへ中継する RMCP RGIG Center と，全ユーザの属を，それ以外の全ユーザへ送信する処理を行う．ま

性を管理・中継する GUI Server から成る．ユーザの属

た，GUI Server からユーザ属性の変更や動作指示をチャネルの指定を指示する．他にも，MIDI プログ
ラム番号の変更（ 音色切替え ），MIDI オールノー

RGIG Transceiver の接続時に伴奏用 SMF を送信し性の変更や RMCP RGIG Transceiver への動作指示は，通知されると，対応する処理をしたり，当該 RMCP

図 5 のように GUI Server から RMCP RGIG Center

RGIG Transceiver へ送信したりする．
• GUI Server

へ一方向に通知される．ユーザの属性には，ユーザ

ID，GIG チャネル，鑑賞モード /演奏モード，MIDI
チャネル，MIDI プログラム番号があり，動作指示に

全 GUI Client のユーザの属性管理と変更の通知，チャットの中継を行う．GUI Client の操作による属Vol. 43

No. 2

Open RemoteGIG：遅延を考慮した不特定多数による遠隔セッションシステム

307

性変更や動作指示は GUI Server へ集められ，RMCP
RGIG Center へ通知される．同時に，画面表示を更

4.1 距離の制約を超えた新たな形態のセッション実現した遠隔地間のセッションは，まず第 1 に，異新するために全 GUI Client にも通知される．RMCP
RGIG Transceiver が RMCP RGIG Center に接続されていることを確認する処理（ IP アドレスに基づを即興演奏することを可能にした点で意義がある．従いて同定する）や，MIDI チャネルの割当ての排他ていた．

処理も行う．

3.2 実
装
RMCP RGIG Center と RMCP RGIG Transceiver は
C 言語で実装し ，両者間の通信には RemoteGIG となる場所にいる演奏者同士が調性とリズムのある音楽
来は，そのようなセッションは実施困難だと考えられ
第 2 に，このセッションのモデルは，従来の演奏者
が 1 カ所に集まるセッションのモデルとは大きく異なるため，音楽演奏に対して新たな観点を与える点で意義がある．従来の音楽では，演奏者は全員ほぼ同時に同様に TCP/IP 上の RMCP を用いた．RMCP RGIG

同じ演奏を聞くものという暗黙の前提があったが，こTransceiver は UDP/IP 上の RMCP により，RMCPの遠隔セッションのモデルでは，全員が同じ演奏を聞Sound Server，RMCP MIDI Receiver 等と通信する．
一方，GUI Server と GUI Client は Java 言語で実装した．GUI Client は Java Applet として実装さ状況下での，従来なかった音楽的なインタラクション

くことがなく相手の反応もすぐには分からないというの方法論が求められる．

れ，WWW ブラウザ（ Netscape Communicator 等）

たとえば，RemoteGIG で当初達成されるのは，各や appletviewer 上で動作する．HTTP（ Hyper Text

自の音が調和するレベルでの演奏だと考えられる．おTransfer Protocol ）によってダウンロードした GUI
Client は，RMI（ Java Remote Method Invocation ）を利用して GUI Server との通信を行う．GUI の実装

互いに，相手の過去の演奏に影響は受けているものの，る方向性の 1 つとして考えられるのは，自分と相手のには，JFC（ Java Foundation Classes ）を利用した．

過去の演奏の記憶も考慮した高度なインタラクション

インタラクションの範囲は限られている．その先にあ

また，GUI Server から RMCP RGIG Center へのユーである．コード 進行の 1 周期分だけ遅れて聞き合うとザ属性変更・動作指示の通知には，JNI（ Java Native

き，自分が聞いている相手の演奏は，自分の 2 周期前Interface ）を用いた．
3.3 実 験 結 果れたかを記憶に基づいて判断して次の演奏内容を決定の演奏への反応である．そこで，ど ういう反応が得らOpen RemoteGIG によって実際に遠隔地間でセッションが実施できることを確認するために，電子技できれば，より緊密なインタラクションを行える．将術総合研究所（ 電総研 ）と早稲田大学（ 早大 ）間でるように，演奏者がセッション中の過去の演奏を記憶

Internet を経由した遠隔セッションを試みた．Open

し，それに基づいて即興演奏できれば，このような新RemoteGIG を運用する OS には，SGI IRIX および
SUN Solaris を用いた．RemoteGIG Center を電総研
あるいは早大に設置し，電総研と早大において複数のたなインタラクションも達成できる可能性がある．

棋や囲碁の棋士が対局中の過去の指し手を記憶してい4.2 不特定多数のユーザによる音楽演奏
Open RemoteGIG では，不特定多数のユーザによRemoteGIG Transceiver を動作させて実験した．伴る音楽的なインタラクションを，遅延時間を管理する

奏用 SMF には，2.3 節の実験の際の SMF 等を使用ことによって実現した点で意義がある．すでに，不特し，1 周期の時間は 30 秒前後で SMF ごとに異なる値

定多数のユーザが，テキストベースのチャット・掲示を設定した．

板やゲーム等に参加することを可能にするシステム

実験の結果，遠隔地間で全ユーザの演奏が適切に中は広く普及している．しかし，そのほどんどは，リア

継され，チャット等の GUI に関連した機能も設計ど

ルタイム性があまり要求されない（同時性が要求されおり動作することを確認した．特に，GUI やチャット

ず，遅延時間が小さいけれど不定な）情報共有か，掲等を利用して，他のユーザの状況を把握しながら遠隔示板のような完全に非リアルタイムな（遅延時間が非セッションをできる点が有効であった．

4. 遠隔地間のセッションに関する議論

常に大きく不定な）情報共有に基づいている．それらを直接音楽に適用しようとしても，前者の情報共有では各ユーザの演奏音がずれて問題があり，後者の情報

RemoteGIG や Open RemoteGIG で実現した遠隔共有では調性とリズムのある音楽を即興演奏できない．

地間のセッションは，様々な意義を持ち，新たな展開

Open RemoteGIG では，遅延時間を意図的に長く一定にし，伝送内容に応じて管理することで，そのようも期待できる．以下，主要な 2 つの観点から議論する．

308

情報処理学会論文誌

な音楽的なインタラクションを可能にした．

5. お わ り に
本論文では，1997 年 12 月の RemoteGIG の公開実験の結果と考察を述べ，それをふまえたうえで，面識のない多数の人が Internet 経由で RemoteGIG の遠隔セッションに参加できるシステム Open RemoteGIGを提案した．Open RemoteGIG では，複数のユーザ
間の演奏中継を実現しただけでなく，仮想演奏スタジオ（ GIG チャネル）の切替えや，鑑賞モードにより公開ライブパフォーマンスを行うことも可能にした．また，演奏相手の発見環境やグループチャット機能により，演奏音以外のコミュニケーション手段も提供した．

RemoteGIG および Open RemoteGIG は，将来普及するであろう遠隔セッションの 1 つの新しい方向性を示すものであるといえる．
謝辞 村岡洋一教授には，本研究を様々な面からご支援いただいた．また菊地淑晃氏からは，本研究に対し 有益なご 示唆をいただいた．1997 年 12 月の Re-

moteGIG の公開実験においては，Rick Bassett 氏，Brad Garton 氏，Perry Cook 氏に演奏者として協力していただき，莱孝之氏にはコンサートの機会を与えていただいた．また，松田周氏をはじめとする国立音楽大学の方々には NTT ICC での準備に協力していただき，興梠正克氏には動画像の伝送で協力していただ
いた．本研究に協力していただいたすべての方々に，心から感謝の意を表する．

参 考 文 献1) 高山 明，千葉雅之，三木恵造，首藤一彦：遠隔同時演奏システム，日本音響学会音楽音響研究会 MA89-10, Vol.8, No.3, pp.23–28 (1989).
2) Nielsen, O.: MIDI and Audio via ISDN, Proc.
1994 International Computer Music Conference, pp.451–454 (1994).
3) Helmuth, M.: Sound Exchange and Performance on Internet2, Proc. 2000 International Computer Music Conference, pp.121–
124 (2000).
4) Burk, P.L.: Jammin’ on the Web—A new
Client/Server Architecture for Multi-User
Musical Performance, Proc. 2000 International Computer Music Conference, pp.117–
120 (2000).
5) Pazel, D.P., Abrams, S., Fuhrer, R.M.,
Oppenheim, D.V. and Wright, J.: A Distributed Interactive Music Application Using Harmonic Constraint, Proc. 2000 International Computer Music Conference, pp.113–

Feb. 2002

116 (2000).
6) Jordà, S.: Faust Music On Line: An Approach
to Real-Time Collective Composition on the Internet, Leonardo Music Journal, Vol.9, pp.5–12(1999).
7) Giuli, D., Pirri, F. and Bussotti, P.: Orchestra!: A Distributed Platform for Virtual Musical Groups and Music Distance Learning overthe Internet in Java Technology, Proc. IEEE
International Conference on Multimedia Computing and Systems, Vol.2, pp.987–988 (1999).
8) Goto, M., Neyama, R. and Muraoka, Y.:
RMCP: Remote Music Control Protocol—
Design and Applications, Proc. 1997 International Computer Music Conference, pp.446–
449 (1997).
9) 後藤真孝，根山 亮，村岡洋一：RMCP：遠隔音楽制御用プロトコルを中心とした音楽情報処理，
情報処理学会論文誌，Vol.40, No.3, pp.1335–1345(1999).
10) 後藤真孝：MIDI 制御のための分散協調システ
ム，jus 設立 10 周年記念 UNIX 国際シンポジウ
ム論文集，pp.161–171 (1992).
11) 後藤真孝：分散協調インタラクティブシステム—
音と CG による遠隔地間の インタラクション ，
NICOGRAPH’93 CG 教育シンポジウムプロシー
デ ィングス，pp.44–49 (1993).
12) 後藤真孝，橋本裕司：MIDI 制御のための分散
協調システム—遠隔地間の合奏を目指して，情報処理学会研究報告音楽情報科学 93-MUS-4-1,
Vol.93, No.109, pp.1–8 (1993).
13) Rai, T. and Bassett, R.: Program book of
U.S.A./Japan InterCollege Computer Music
Festival: Computer Music Concerts and Lectures (1998).
14) Hashimoto, S., Moon, B., DuBois, R.L. andCastle, H.: Regional news, ARRAY: Communications of the ICMA, Vol.18, No.1, pp.2–4(1998).
(平成 13 年 6 月 6 日受付)
(平成 13 年 12 月 18 日採録)

Vol. 43

No. 2

Open RemoteGIG：遅延を考慮した不特定多数による遠隔セッションシステム

後藤 真孝（ 正会員）

根山

309

亮（ 正会員）1993 年早稲田大学理工学部電子1997 年早稲田大学理工学部情報通信学科卒業．1998 年同大学大学学科卒業．1999 年同大学大学院修院博士後期課程修了．同年，電子技士課程修了．同年，日本アイ・ビー・

術総合研究所（ 2001 年に独立行政法

エム（株）東京基礎研究所に入所し，

人産業技術総合研究所に改組）に入現在に至る．音楽情報処理，分散コ

所し ，現在に至る．2000 年より科学技術振興事業団

ンピューティング，Web サービ ス，SOAP 等に興味

．音楽情
さきがけ研究 21 研究員を兼任．博士（工学）を持つ．1999 年情報処理学会大会奨励賞受賞．著書

報処理，音声言語情報処理等に興味を持つ．1992 年『 Building Web Services with Java — Making Sense

jus 設立 10 周年記念 UNIX 国際シンポジウム論文賞，1993 年 NICOGRAPH’93 CG 教育シンポジウム最優of XML, SOAP, WSDL and UDDI 』（ SAMS Publishing ）．日本ソフトウェア科学会会員．

秀賞，1997 年情報処理学会山下記念研究賞，1999 年
平成 10 年電気関係学会関西支部連合大会奨励賞，2000
年 WISS2000 論文賞・発表賞，2001 年日本音響学会第18 回粟屋潔学術奨励賞・第 5 回ポスター賞各受賞．電子情報通信学会，日本音響学会，日本ソフトウェア科
学会，日本音楽知覚認知学会，IEEE，ICMA，ISCA各会員．