JP3685805B2

JP3685805B2 - 分散型リアルタイム通信システム

Info

Publication number: JP3685805B2
Application number: JP53502997A
Authority: JP
Inventors: ドナルドソンモーラー，マシュー
Original assignee: アビッドテクノロジー，インコーポレイティド
Priority date: 1996-04-01
Filing date: 1997-03-27
Publication date: 2005-08-24
Anticipated expiration: 2017-03-27
Also published as: CA2250855C; AU730214B2; AU2298597A; CA2250855A1; DE69735054D1; HK1018142A1; ATE315301T1; JP2000507715A; WO1997037476A1; EP0891665B1; DE69735054T2; EP0891665A1

Description

発明の分野
本発明は、クライアント・サーバ式ネットワークとしての分散クライアント間のリアルタイム通信に関する。また、排他的なものとしてで無く、本発明は特に、クライアント・ユーザ同士がリアルタイムで相互に音楽演奏を行うのを可能とするに適している。
発明の背景
クライアント・サーバ構造とは、データの転送および操作の為に共通のサーバを複数の分散クライアントが使用するコンピュータシステムである。図１には典型例が示されており、サーバ10は３台の分散クライアント・コンピュータ12と通信を行っている。このサーバはプログラムを実行しながら、特に何も行わない（dumb）単なるデータ転送ハブとしても作用し得る。クライアントの各々は、サーバに接続された他のクライアントに対し、サーバを介してデータを送出することにより、コンピュータネットワーク等の共通のデータ転送システムを介して他のクライアントとの相互情報交換を許容されている。
クライアント・サーバ技術は十分に確立され、例えば、株価の動きに関して最新のものを保持すべく株式仲買人がリアルタイムのデータサービスを使用するという金融分野において広く使用されている。これらのシステムにおいて受信された情報は、一切の遅延が最小限であると共に重要でないことから、リアルタイムであると知覚される。しかしながら、クライアント・サーバ構造が例えば多くの国々における複数の分散クライアントに対して通信し得る様に開発されれば、時的遅延が重要になる可能性がある。これは特に、例えば音楽を合奏する場合において各クライアントの動作が他のクライアントの動作を決定しもしくはそれに影響を与えると共にこれらの動作が高度に時間依存的であるという、各クライアントが互いにリアルタイムで協力し合いかつ相互作用を行う場合に顕著である。斯かるシステムにおいては、課せられるべき本来的な時的遅延により、即時かつ瞬間的な応答が不可能となる。これは特に、数秒までの遅延が生じ得る最近のコンピュータネットワークに当てはまる。この遅延長さは、分散された演奏家たちの間におけるリアルタイム音楽演奏を不可能にする。この点、数ミリ秒の遅延でさえも、芸術的には望ましく無い。
従って、演奏家同士がコンピュータネットワーク上で相互に作用することにより分散箇所においてリアルタイムで共に演奏を行えることが望ましい。しかしながら、複数のクライアントに同時にデータを送受信させる手段は無い。光速でデータを伝送する最速のネットワークによってさえも大陸間のデータ転送には遅延が伴うが、これは、多くの音楽的状況において認識されてしまい、受入れられるものでない。
発明の摘要
従って、本発明の目的は、分散箇所における各クライアントがリアルタイムで相互に作用し得るシステムを提供するにある。
本発明の更なる目的は、複数の情報源からの時間依存情報を同期させる方法および装置を提供するにある。
本発明の更なる目的は、複数の演奏者が分散箇所から共にリアルタイムで演奏するのを許容する方法および装置を提供するにある。
本発明の更なる目的は、１台のクライアントが即時演奏の非反復的データストリームを提供しながら、分散箇所からリアルタイムで各クライアントが相互に作用するのを許容する方法および装置を提供するにある。
本発明は、参照されるべき独立の請求項により定義される。
本発明の第１の特徴に依る好適実施例においては、複数の情報源からのデータを同期させる方法および装置が提供される。データストリームは第１情報源から生成されてサーバに送出され、其処で全ての関与クライアントに対して配信される。各クライアントはそれ自身のデータストリームを送出する一方、それは各クライアントに対してエコーが送られる。各クライアントにて受信されたデータストリームはローカル・クロックに対して同期させ、且つ、各々が複数回に亙り反復される如くデータストリームをループバックすることにより連続性は維持される。
この実施例によれば、例えばコンピュータネットワーク上におけるサーバと個々のクライアントとの間の時的遅延の差に関わらず、同期したインタラクティブな通信が可能となる。これは、各クライアントのデータストリームがひとつの音楽的パートを表すと共にサーバが各クライアントに対して合奏のエコーを送るという音楽などの状況に適用され得る。各クライアントにより生成されたデータストリームは、音楽シーケンスを表す。本発明の一実施例においては、ひとつ以上のクライアントが一連のシーケンスもしくはマクロシーケンスを生成する。これにより、音楽的に更に複雑なパターンが演奏され得る様になり、本発明の柔軟性および有用性が高められる。
本発明の第１の特徴は各データストリームのループバックに基づいて連続性を達成し、故にリアルタイム演奏を実現することから、各クライアントからの即時演奏もしくは非連続的データを必然的に排除する。これは、音楽の演奏においては不都合である、と言うのも、いずれかの演奏者により表現され得る創造性および芸術性を制限するからである。
本発明の第２の特徴は、各クライアントのひとつからのデータストリームが非連続的で非反復的なストリームであって、ループバックされず且つ即時演奏された音楽的旋律を表すことを許容する方法および装置を提供する。
本発明の第２の特徴に係る好適実施例においては、即時演奏された旋律もしくは‘ソロ’旋律を提供するクライアントは、残りのクライアントより早く、サーバに対する自身のデータストリームの送出を開始する。サーバはこのデータのエコーを各クライアントに送り、各クライアントはそれをローカルバッファに保持してから自身のローカル・クロックに対して同期させる。残りのクライアントの相対的同期は、本発明の第１特徴と同様の手法で処理される。この様にして、全てのパートが全てのクライアントにて同期する。ソロ旋律が開始された後に非ソロデータストリームがソロクライアントに到達するという事実は問題でない、と言うのも、それらの旋律は反復的なものであり、ローカル・クロックへの同期のみを必要とするからである。
好適には、ソロクライアント・データの送出と残りのデータストリームの送出との間の遅延は、クライアントとサーバとの間の最長遅延に略々等しいものである。
図面の説明
以下に添付図面を参照し、本発明の好適実施例を単なる例示的なものとして記述する。
図１は、上述の如く、クライアント・サーバ構造の概略図である。
図２は、クライアント・ターミナルの概略図である。
図３は、データストリームのルーピングを示すと共に本発明の第１特徴を実施する概略図である。
図４は、複数のデータストリームがループされる方法を示す概略図である。
図５は、データストリームとして表現された４パート楽譜を示す図である。
図６は、図５の楽譜がクライアント・ソフトウェアによりプレイバックされたときに如何にサウンド発生するかを示す図である。
図７は、更に長いデータストリームを有する第５パートが上記楽譜に如何にして導入されるかを示す図である。
図８は、サーバの作用の概略を示すフロー図である。
図９は、各クライアントにおいてローカル・クロックが如何にして使用されるかを示すフロー図である。
図１０は、クライアントがシーケンスを生成してそれをサーバに送ると共にサーバはそれを各クライアントにエコーバックする方法を従来の楽譜記入法を用いて示す図である。
図１１は、２つの別体シーケンスを備えたシーケンスを上記システムが処理する方法を従来の楽譜記入法を用いて示す図である。
図１２は、クライアント・サーバにより受信されるシーケンスと４台のクライアントが存在するときの該シーケンスの相対的タイミングとを従来の楽譜記入法を用いて示す図である。
図１３は、図１乃至図１２のシステムで使用される方法および処理単位の模式的概略図である。
図１４は、即時演奏されたソロパートが図７の５パート合奏に付加される方法を示すと共に本発明の第２特徴を実現した概略図である。
図１５は、上記ソロパートが残りのクライアントより早く開始される方法を示す図である。
図１６は、本発明の第２特徴に関する図１５と同様の概略図である。
最良形態の説明
先に示した問題は伝送速度に関するものであった；この点、物理法則では光速が最大の伝送速度であるが、大陸間の箇所における複数のクライアントを同期させるには不十分な速さである。
本発明者等は、情報ラインもしくはデータを各クライアントにおけるひとつ以上のストリームに分割すると共にこれらのストリームをサーバに送出することにより上記問題が回避され得ると判断した。送出クライアント以外の全てのクライアントに対してサーバが別体データストリームの全てのエコーを送ることから、各クライアントは他のクライアントにより生成されたデータストリームの全てを受信する。個々のクライアントは次にデータを再構築しながら、夫々のローカル・クロックにより相互に対するストリームの同期を保持する。
残りの説明箇所においては、データストリームを音楽的パートに関して論ずる。但し、本発明は複数の音楽的パートの同期に限定されるもので無く、デジタル的に表され得ると共に例えばオーディオおよびビデオデータを含む任意の時間依存もしくは時間順的データにも適用されることは理解されよう。本発明はまた、各クライアントが単一パートを生成する様に記述されている。但し、所定のクライアントが合奏のひとつ以上のパートに寄与しない理由は無い。
従って、音楽的情報は複数の音楽的要素の組合せとして表されるが、これは、多数の楽器が別個の旋律を同期して演奏することにより単一の楽曲を生成するというオーケストラに類似している。本発明においては各楽器のパートがデータストリームにより表されている。
データストリームが如何にして構築されるかを記述する前に、当該システムのハードウェアの要件を考察することは有用であろう。その最も単純な形態において、ネットワークは図１に示された如く１台のサーバコンピュータおよび複数のクライアントコンピュータを備えて成る。
而して、典型的なクライアントは図２に示されている。コンピュータ20は任意のタイプであり、例えば、MIDI（楽器デジタルインタフェース）インタフェース22およびモデム24を有するPCもしくはMACである。そのMIDIインタフェースはデータの入力手段の役割を果たす。また、上記クライアントコンピュータはCPU 23を含むが、これは他のタスクとは別に、MIDI、ハードディスク25およびランダム・アクセス・メモリ（RAM）27からのデータ入力を読取り得るものである。而して、クライアント・ソフトウェアは、TCP/IP（送出制御プロトコル／インターネットプロトコル）によりサーバとのデータ転送を確立かつ管理する。音楽的情報はサーバとの間で送受信の両者が行われる。クライアント・ソフトウェアは、標準的なMIDIインタフェースを介してユーザが音楽的情報を記録するのを許容する。
この情報はローカル実行クロック26に関してタイムスタンプ付与されてからサーバに送出され、各クライアントにそのエコーが送られる。クライアント・ターミナルは、所望のカウント周波数にクロックをセットする為の（不図示の）手段を含んでいる。記述実施例においては、MIDI入力が使用されるのが好適である、と言うのも、データが送出用にコンパクトで効率的であり、厳密な帯域幅要求内で作動する上で理想的だからである。但し、デジタルのオーディオもしくはビデオ入力などの他の入力も使用され得る。
上記クライアント・ソフトウェアはまた、サーバからMIDIデータを受信してMIDIデータを出力する。これは全てのクライアントからのデータである。従って、任意の標準的なMIDI装置に記録されながら、それは任意の標準的MIDI装置でプレイバックされる。MIDIイベントは、ローカルクロック26に対して同期させそしてプレイバックされる。再度述べるが、MIDI装置は好適なプレイバック手段に過ぎない。
各クライアントMIDIにより受信されてタイムスタンプ付与されるデータのフォーマットは種々のものがある。また、各音符は例えば４種の情報により表される：音符がいつ演奏されたか（相対的タイミング）、それはどの音符であったか（その音程）、それはどれだけの時間に亙り演奏されたか、および、その音符は如何に大きく演奏されたか（その強度）、である。デジタルオーディオなどの更に洗練されたデータ表示も使用され得るが、これらのものは高容量情報に関する不利益を有すると共に、消費者用インターネットユーザが利用し得る比較的に小容量のネットワーク上では効率が良くない。本質的な指定データは、音符の相対的タイミングである。他のパラメータとしては、ビブラート、アクセント、スタッカート等が挙げられる。
データ構造に再度言及すると、各クライアントはベースもしくは主旋律等のひとつのパートを表す音楽的情報の時間依存ストリームを生成するが、これは、他のクライアントにより生成されつつある他のストリームの全てに対してローカル的に同期させねばならない。クライアント・ソフトウェアは、自身が出力するデータに対してローカル・クロックによりタイムスタンプ付与を行う。既に論じた如く自由な即時演奏は行い得ない、と言うのも、複数のクライアントに対してデータを転送する上での本来的な遅延は芸術的に受入れられないからである。また、音楽が連続的に流れることも重要である。しかしこれは困難である、と言うのも、連続性は本来的でないからである。即ち、もし各人が直ちに応答し得なければ、本来的な遅延が合成されると共に音の連続性は維持され得ない。
然るに、本発明者等は、ループ・ポイントを設定することにより連続的な音の流れを生成し得ると判断した。例えば、２小節長さのベースドラム・パターンを設定し得る。このパターンはサーバによりクライアントに送られ、その後にそれらのクライアントはこの２小節パターンを連続的に反復する。これは図３に示されているが、同図における参照番号30はクライアントにより生成されてサーバに送られるデータストリームを表している。また、参照番号32はクライアントにより幾度も繰り返して演奏される同一のデータストリームを表している。
従って、上記サーバは一定長さ時間の部分もしくは音楽フレーズを、それが生成されたクライアント以外のクライアントの各々に対して送出する。それらのクライアントはデータを受信してそれを自身のローカル・クロックに同期させる。フレーズもしくはパターンは幾度も反復される。各クライアント自身が生成したシーケンスは、サーバに送出される前にタイムスタンプ付与されたローカル・クロックに対して既に同期している。
各クライアントが同一の音楽的事象を有することは理解されよう。本来的な伝搬遅延があることは問題でない、と言うのも、音楽シーケンスは各ローカル・クロックにより設定された相対的時間にのみ依存するからである。従って、各クライアントに対する本来的遅延が異なったとしても問題とはならない。
シーケンスのルーピングにより遅延の問題は克服されるが、場合に依ってはそれが音楽面の制約となり或いは不適切となることもある。図４は、一連のシーケンスを生成すると共にこの一連のシーケンスを幾度も反復することにより如何にして特別の格調が付加され得るかを示している。図４においては３つのシーケンスＡ、ＢおよびＣが生成されている。勿論、これらの３つのシーケンスは任意の順番で生成され得るが、此処ではＡ、Ａ、Ｂ、Ｃである。これらの４つの部分的シーケンスはサーバに送出され、サーバは他のクライアントの各々に配信し、其処で連続的にループされる。従って、各クライアントで演奏されるストリームはＡＡＢＣＡＡＢＣなどである。
図５は、４台のクライアントのネットワークが如何にして４パート楽譜を生成するかを示している。４つのパート１乃至パート４は例えば、スネアドラム、ベース、ギターおよびピアノであり得る。スネアドラム旋律40はシーケンスＡＡＢＣであり、ベース42は単純なシーケンスＡであり、ギター44はＡＢであり、且つ、ピアノ46はＡＢＣＤである。夫々のクライアントはシーケンスをサーバに送出し、サーバは一連のシーケンスを他のクライアントの各々に対して配信する。各クライアントによりプレイバックされる最終的な楽譜は図６に示されている。
図示実施例においては、シーケンスの各々は等しい長さである。これがそうである必要は無い。図７は、他のパートの各々により使用されたシーケンスの長さの４倍となる単一シーケンスが付加された第５パート48の一例を示している。従って、この例においては第５パートのシーケンスＡは８小節のシーケンスであり得る。而して、それが異なる長さであっても問題とならない、と言うのも、そのデータは相対的クロック値により既にタイムスタンプ付与されているからである。シーケンスの長さもまた任意であるが、異常な長さであれば、位相効果、すなわち他のパターンとの調和が乱れ、が生じ得る。シーケンス長さに関しては、コード進行等の音楽特性と関連付けるのが更に一般的であり、また、更に長いシーケンスに対しては最短のシーケンスの整数倍とするのが通常である。
単一のシーケンスもしくは一連のシーケンスの生成におけるクライアントの作用は図８に示されている。第１シーケンスは先ずステップ50にて生成されると共に適切であれば引続くシーケンスが追隨し、その全体が次にステップ52にてタイムスタンプ付与され、ステップ54にてサーバに送出される。
タイムスタンプおよびローカル・クロックの作用は図９のフローチャートにより示されている。先に説明した如く、ローカル・クロックは、ローカル的に生成されたシーケンスと共にサーバから受信した同期データストリーム（シーケンス）により使用される相対的クロックである。このクロックは、可変時間間隔の一連のビートもしくはパルスを発生すべく設定される。これらのビートは数ミリ秒の間隔とされるのが通常であり、シーケンスデータはこのクロックに整列される。
ステップ60にてクライアントはクロックにより発生されるべき次のビートを待つと共に、現在のビートを監視する。ステップ62にてクライアントは演奏すべきストリームが残存しているか否かをチェックし、もし無ければ、ルーチンはステップ60に戻り次のビートを待つ。クライアントはストリームの各々をチェックし、演奏すべき更なるデータがあるか否かを調べる。ステップ62における判断がYESであれば、ソフトウェアはステップ64に行き、其処で次のデータストリームが入手される。ステップ66においてクライアントは、現在のストリームに対する現在のビートに関してプレイバックすべきデータがあるか否かをチェックして調べる。もし無ければ、ルーチンはステップ62に戻る。もし出力されるべきデータがあれば、そのビートおよびストリームに対する全てのデータが必要な形態で出力される。ステップ60乃至66が受信シーケンスをクライアントのローカル・クロックに同期させる手段の役割を果たすことは理解されよう。
与えられた実施例においてデータフォーマットはMIDIフォーマットであるが、それはひとつ以上のデータ出力における任意のオーディオもしくはビデオフォーマットまたはデジタル的に制御された光出力とさえもされ得る。
クライアントは次に、出力すべき残存データがあるか否かをチェックする。無ければ、それは次のビートを待つ。
上記システムは、相対的時間値である‘ビート（beat）’に関して記述された。これは好都合なものである、と言うのも、２小節もしくはｎ小節のシーケンスは等しく離間された整数のビートを通常は有するからである。但し、更に複雑なものではあるが絶対時間値も使用され得る。而して、タイミングは依然として相対的なもものである、と言うのも、サーバからのデータはローカル・クロックに同期させるからである。
単一のシーケンスもしくは一連のシーケンスの後にクロックを再設定するのでは無く、ビート値が増加されて行く。図２から理解される如く、クロック26はカウンタ29を含んでいる。
以下の表１は、上記システムが異なる長さのパートの同期を維持すべく如何に作動するかを示す助けとなる。例えばベースパートを考察する。表１は、ベースパートのデータが如何に見えるかを示している。
パターン長：１６

パターン長が１６ビートであることから、このパターンは１６ビート毎に反復する。従って、各ループの第１ビートでC2が演奏され、第３ビートでD2が且つ第９ビートでE2が演奏される。クロックは異なる時点で到来する複数長さのシーケンスを制御しかつ同期させるが、これは、パターン長でビートカウント全体を除算した剰余もしくは余りを取ることにより行われる。従って、表１のパターンは、ローカル・クロックが０、１６、３２、４８等をカウントするときに反復される。もしクロックカウントが１１５にあれば、ローカルクライアントは上記シーケンスの第３ビートを演奏している、と言うのも、シーケンスが１６ビート長であり且つ１１５／１６＝７余り３だからである。同一の例において、３２のパターン長であれば第１９ビートに在る、と言うのも、１１５／３２＝３余り１９だからである。
上記の記述からは、タイムスタンプは相対的時間値であることが理解される。従って、各データセットに対し、すべてのクロック値はゼロ値からのオフセット値であると見做される。クライアントは単に、各ストリームに対する現在パターンへのポインタおよび現在パターンにおけるカウントを保持するだけである。カウンタはローカル・クロックの刻時毎にインクリメントされる。カウンタがストリームに対する現在パターンの長さと等しい場合、それは０にリセットされてパターンポインタは次のパターンへとインクリメントされる（もしパターンがマクロパターンの最後のもの、即ち、“ＡＢＣＤ”における“Ｄ”であったとすれば、パターンポインタはマクロパターンの第１パターンを再び指し示すべく設定される）。尚、ローカル・クロック値を変換して使用し得る方法には多くのものがある。上記で言及した剰余方法は、好適実施例で用いられた全て同じ長さのパターンに対して機能するものである。
クライアントは、データセットの順序（パターン）、各パターンの長さ、および、定常的にインクリメントされているローカル・マスタクロックの値、を認識していることから、自身が各ストリームのいずれのパターン（データセット）を演奏中であり且つデータセットの内のいずれの位置（カウント）を演奏中であるかを、簡単な算術を用いて容易に決定することができる。各ストリームは、他のストリームに対して整列された一連のパターンおよびマクロパターン（パターンのパターン）を有している、と言うのも、各ストリームはその出力を同一の手順および同一のローカル・クロックに基づかせているからである。
尚、他の同期方法が可能であると共に当業者は想起し得るであろうことを銘記されたい。記述された方法は、可変長の複数ストリームを制約無しで同期かつループすることを許容するものである。
以上の記述からは、個々のクライアントからのデータストリームが各クライアント箇所でまとめられるのが理解されよう。出力がオーディオの場合にはデータストリームは組み合わされてサウンドが発生される。尚、データが組み合わされねばならない理由は無い。
クライアントにおけるデータストリームの処理は、以下の単純例から理解され得る。
特定のセッションの中に、バス、キーボード及びトランペットの３つのデータストリームが存在するものと考えてみよう。３つの楽器のためのデータセットは、以下のとおりであってよい：
bass：ＡＳ
kbd ：ＡＢＣＤ
trpt：Ａ
各々１つのデータストリームと対になった合計７つの異なるデータセットが存在し、これらのパターンを、以下のような任意の順序で配置することができる。
bass：ＡＳ
kbd ：ＡＢＣＤ
trpt：Ａ
これらのマクロパターンは、前述の要領でくり返す。
ローカルクロックが時を刻む度毎に、クライアントは各ストリーム内をステップし、出力すべき何らかのデータが存在するか否かを決定し、必要に応じてそれを出力する。例えば１つの音符を演奏することもできる。
組合わされるのではなくむしろ、データストリームがローカルクライアントにおいて組合わされているものと知覚されるものの、クライアントは各ストリームについてのデータを別々のエンティティとして保持することがわかる。補遺にあるコードリストの中で、１つのコードが１つのストリームオブジェクトのために与えられている。この例における各々のストリームオブジェクトはその独自のデータを保持する。該データがその他のストリームオブジェクトと組合わされることは決してない。それは、あたかも組合わされたかのように聞こえるだけである。
ここで記述されるシステムは、データのエコーをローカルクライアントに送るサーバに基づいている。各クライアントは、データを送受する能力を有し、送られるデータは、タイムスタンプ付与された事象のシーケンスを表わす任意の数のデータストリームから成る：該タイムスタンプは、任意の相対的クロック値である。データシーケンスは、一定の音楽の流れの印象を与えるべくローカルクライアントによりループされる。送られるシーケンスはそれ自体、より複雑な音楽パターンを構築できるようにするためシーケンスのシーケンスであって良い。プレイバックは、クライアント/ サーバ/ クライアントの時間的遅延とは無関係にデータストリームをプレイできるようにする相対的クロック値を用いてデータがそれに合わせて同期化されるクライアントのローカルクロックによって制御される。
第１のクライアントがサーバに情報を送り、それに続いて第２のクライアントが創出するといった状況を想定してここまで説明を行ってきた。
全てのパターンは、時間０からオフセットされたものとして仮定される時間の値を有する。ローカルクロックの時間は、全てのパターンがこれらの相対的クロック値を使用することから、全てのプレイバックと同様に任意である。このことはすなわち、クライアントのローカルクロックが開始する時間が任意であることを意味する。全てが作動するために、クライアントのうちのいずれか一人が開始するのを待つ必要はない。問題なのは、ローカルクライアントが、そこから相対的クロック値をオフセットできる何らかのクロック値を有していることである。
ここで、データストリームの構造をさらに詳細に考えてみる。表２は、データストリームのうちの１つについての１つの適切な書式の例を示している。該ストリームは、ヘッダセクションとデータセクションを含む。

このデータストリームは、クライアントからサーバに又はサーバからクライアントに送られる１つのパケット又はパターンとして考えることができる。これは、以下の要素から成る：
Ａ）以下のものを含むヘッダ：
１．ストリームＩＤ：新しいストリームが新規作成された時点で、曲の例の中の新しい楽器が一意的ＩＤ値と結びつけられる。ＩＤが割当てされる方法は、ここでは問題にならない。唯一問題なのは、各ストリームが一意的ＩＤ値をもち、全てのクライアント及びサーバがこのＩＤを該ストリームと結びつけるということである。従って、データが該ストリームについて送り出された時点で、ヘッダの中のストリームＩＤ要素は、該データが該ストリームと適切に対となるのを可能にする。
２．パターンＩＤ：各ストリームについて、多重パターンが存在する。ストリームと同様、各パターンは識別されなくてはならない。すなわち各パターンはその独自のＩＤを有していなければならない。例えば、バスパターンは、パターン「Ａ」とパターン「Ｂ」を有することができる。この場合、「Ａ」及び「Ｂ」はパターンＩＤである。パターンを識別する方法については、パターンを識別し区別する何らかの標準的方法が存在する場合にかぎり重要である。例えば、ワードや数字を用いることができる。補遺１に含まれているコード例は、パターンを識別するのに文字Ａ〜Ｅを使用する。
３．パターン長：１つのパターンの長さは、そのパターン内で最後にタイムスタンプ付与された要素の時間によって決定されるわけではない。１つのパターンは、１６秒の長さをもちしかも全く事象をもたない（すなわちバスパートパターンは完全にサイレントであり得る）。パターンの長さは、次の２つの方法のうちの１つで設定できる：
（ｉ）パターンは、予め定められた長さを有する可能性がある。例えば音楽プログラムで、全てのパターンがつねに４小節の長さをもつ可能性がある。補遺１に含まれているコードはこの仮定を行なっている。
（ii）パターンは、データヘッダ内にパラメータとして内含されている可能性がある。
Ｂ）データ：残りのデータはタイムスタンプ付与されたデータ対である。楽器のパートの場合、これは、時間/ 音符の事象で構成され得る。もう１つの場合、例えばデジタルビデオの場合においては、これは時間/ フレーム事象で構成されていてよい。データに対する制約条件は全くない。タイムスタンプは相対的時間値である。すなわち、パターンは時間０で開始すると仮定される。こうして、パターンがローカルクロックとの関係においてクライアントによりプレイバックされ得ることになる。絶対時間に左右されることは全くない。
最大の制約条件は、タイムスタンプ値の１つが、パターン長よりも高い可能性があるということである。すなわち、パターン長が５秒である場合、１０秒で起こる事象はないことになる。
かくして、データがクライアントソフトウェアに入ったとき、以下のような手順が発生する：
１．クライアントはデータを受理する；
２．クライアントは、データパケットのヘッダからストリームＩＤを読取ることにより、データがどのストリームに結びつけられているかを決定する；
３．クライアントは、データパケットのヘッダからパターンＩＤを読み取ることにより、データがそのストリームについてどのパターンであるかを決定する；
４．クライアントは、データパケット内のパターン長データ要素を読取ることによりパターン長を決定する；
５．クライアントは、データの終りまでタイムスタンプ/ データ対を読み込む（注：パターンは空である可能性がある。これは、ストリームＩＤ，パターンＩＤ，パターン長を有するもののデータを全くもたない可能性がある。）
従って：１つのデータパケット例が以下の通りとなる可能性がある。

注：パターン長は６秒であるが、最後の事象は５秒で発生する。
ループ長が決定される要領については以下で説明する。ストリームのためのパターンが異なる長さである場合、前述のように整相が発生する。例えば、バス、キーボード、トランペットの３ストリームがあり、これらが、それぞれ合計長が１小節、２小節及び３小節であるマクロパターンを有する場合、シーケンスは５小節毎にくり返すことになる。換言すると、ループ長は６小節である。かくして、ループの長さは、各ストリームの合計長の全てが１つの因数である最小数である。長さ１，２及び３について、これら全てが因数である最小数は６である。時間の尺度として秒を用いた場合で、しかもそれぞれ合計長２０，４０，６０及び８０秒のマクロパターンをもつ４つのストリームを有する場合、ループの長さは、全ての長さが共通因数である最小数が２４０であることから、２４０秒となる。
ループ長は動的に変化でき、例えば、１つのストリームのためのマクロパターンを、その長さを２倍にして「ＡＢ」から「ＡＢＡＣ」へと単純に変更することができる。ストリームの残りの部分がわずか「Ａ」のマクロパターンに設定された場合、これはループの長さを２倍にすることになる。
偶数の境界上に整列しないパターンを処理する場合、整相が発生することになる。
図１０〜１２は、実際の音楽シーケンスに関して記述された方法を例示している。図１０では、方法は実時間を表わす軸７１に対して示されている。第１段は、クライアントが自らのシーケンスを記録するためのものである。これは４つの四分音符：Ｇ，Ｃ，Ｇ’Ｂフラットの１小節を含むバスパートを第２のクライアントが記録する７２において発生する。このシーケンスは次に７４においてサーバに送られ、このサーバがそのパターンのエコーをもう１人のクライアントへと送る。クライアントは各々、作動する独自のローカルクロックを有し、受信したデータは、そのシーケンスを何度もくり返すことによって第１のクライアントにおいて、又、生成されたシーケンスを何度もくり返すことによって第２のクライアントにおいてプレイバックされる。図を見ると、１小節のシーケンスが４回くり返されていることがわかるが、実際にはこれよりはるかに多くの小節数がある。シーケンス内の音符の相対的タイミングは、第１のクライアントがそのローカルクロックにより制御される通りに維持される。ただし、第１及び第２のクライアントのローカルクロックの比較により、２つが互いに同期していないことがわかる。前述の通り、プレイヤーが他のいずれかのクライアントにおいて聞こえているものについて全く知覚していないことから、これは全く問題にならないことである。
図１１は、２つのシーケンスのパターンがクライアントの１人によって生成されたときに起こることを、さらに詳しく例示している。この例示においては、便宜上、１人のクライアントのみが示されている。サーバーは、シーケンスＡとそれに続くシーケンスＢを含む１つのパターンを受理した。この例示からわかるように、シーケンスＡは、前の図で記述されている通り、同じ４つの音符の組合せである。シーケンスＢは、低Ｃの四分音符とそれに続くＧの八分音符及びＤの八分音符、その後、Ａの四分音符、八分休止及びＧ’の八分音符を含む。囲み８０，８２により例示されているように、サーバは、２シーケンスパターンをクライアントに送り、該クライアントはそのプレイバックパターンを受理されたシーケンスＡＢに設定する。シーケンスＡがまず最初に受理され、プレイバックされ、シーケンスＢは、２つのシーケンス間に音楽的不連続性が全く無い状態で受理されプレイバックされる。次に該クライアントは、必要とされる回数だけシーケンスＡＢＡＢＡＢＡＢＡＢなどのシーケンスをくり返す
図１２は、９０に概略的に示された４クライアントセッションの記譜法を示す。最初のパートは、４小節分持続する単一のシーケンスを含む；第２のパートは、各々１小節分持続し図１１のシーケンスに対応するシーケンス対ＡＢを含み、第３のパートは、単一の１小節シーケンスを含み、第４のパートは、４つの１小節シーケンスＡ，Ｂ，Ｃ，Ｄを含む。クライアントは、４小節毎に第１のパートが反復され、２小節毎に第２のパートが反復され、１小節毎に第３のパートが反復され、４小節毎に第４のパートが反復されるのを開くことになる。
記述された実施形態においては、サーバはシーケンスを、それを送ったクライアントへエコーバックすることはしない。送信クライアントのローカルクロックにすでに同期しているデータを受理する必要性が全くないことから、これは好ましいことである。しかしながら、サーバはデータを送信クライアントへと送り戻すことができるが、これにより、サーバが送る必要のあるデータ量が増えることになる。
添付の補遺は、単純ストリームオブジェクトのためのコードリストを示す。各々のストリームオブジェクトは別々であるが、同じコードを用い、並行して実行する。このコードは、固定したパターン長を伴うルーピングコンセプトのきわめて単純な実現を示す。これは、相対的ローカルクロック値を用いて作動する；ローカルクロックはつねにサイクル動作し、従って実行につれてコードを参照しても絶対時間が決定できるわけではない。コードは同様にパターンのパターンを通してもサイクル動作する。
図１３は、記述された方法における機能的ステップを要約している。これは同様に、ソフトウェアにより実施されるステップに対するハードウェア等価物又はシステムのハードウェア必要条件の機能的ブロックダイヤグラムとみなすこともできる。かくして、１２０において、クライアントのコンピュータは、データシーケンス又はシーケンスのシーケンスを生成する。このデータは、ステップ１２２においてタイムスタンプ付与され、ステップ１２４でサーバに送られる。サーバは次に、ステップ１２６で各々のさらなるクライアントに対しデータのエコーを送って出す。鎖線１２８で表わされているステップにおいては、代表的ローカルクライアントが、独自のローカルクライアントに同期したデータを受信し、そのデータをプレイバックする。より特定的に言うと、データはステップ１３０及びステップ１３２で同期化される。ローカルクライアントはビート長を設定し、各ビートについて、以下のステップを実行する：
（ｉ）ステップ１３２は、データストリームを検索する。
（ii）ステップ１３４は、データを検査する。
（iii）ステップ１３６は、データを出力する。そして
（iv）ステップ１３８は、クロックカウンタをインクリメントする。
ステップ１２０〜１３８は、クライアントコンピュータの各々について実行される。
記述されている実施形態の１つの欠点は、それが即興演奏を許容しないということにある。各々のプレイヤは、各ループの構造に或る程度の柔軟性があるものの、記述されたルーピング構造を用いて演奏しなくてはならない。添付のコードリストは１つの実施例にすぎず、その他の実現アプローチも受容可能でありかつ当業者にとっては明白となるはずであるということを理解すべきである。
本発明のさらなる形態によると、１人のプレイヤは、ルーピング手順による制約を受けることなく自由に即興演奏を行うことが可能である。このことは、６番目のプレイヤ１００（「ソロ」として示されている）がその他５人のプレイヤの上で自由に即興演奏をするソリストである、図１４に例示されている。換言すると、６番目のラインは、一連の反復ループではなく、連続する音楽ラインである。
ローカルクライアントは、サーバにより各クライアントに送られる開始コマンドにより自らのクロックを開始されることができる。開始コマンドは各クライアントに同時に送ることができるため、クライアントは、大まかに同期することになる。同期は正確ではないが、いずれのクライアントについても最大の転送遅延内にある。例えば、３人のクライアントについての平均ネットワーク遅延がそれぞれ１００ｍｓ，１５００ｍｓ及び５００ｍｓである場合、それぞれのクロックは１５００ｍｓ以内に同期することになる。クライアントは各々サーバにより個々にトリガーされ得ることから、クライアントグループを別々の時間に同期させることが可能である。かくしてサーバーは１人以外の全てのクライアントを遅延させることができる。このことは（即興演奏者のクロックである）ソリストのクロックがサーバからそれに送られた開始コマンドにより開始されている、図１５において例示されている。このとき、一時経ってから、その他のクライアントの各々はサーバからの開始コマンドにより開始される。
この場合、１人以外の全てのクライアントは、この１人のクライアント（ソロライン）に遅れて大ざっぱに同期する。このときソリストは、バッファ７０（図２）内でソロクライアントからのデータを緩衝する残りのクライアントに対し連続するデータストリームを送り出し、それを彼らのローカルクロックと同期させることができる。楽器パートの残りのデータストリームは前述の要領でループされることから、ソロクライアントと残りの同期したパートの間の遅延は、いずれのクライアントについても時間依存型データの連続性を妨害しない。全てのクライアントの間の遅延の問題は、記述されたルーピング手順により処理される。ソロクライアントに送られた非ソロデータは、ソロラインが開始した後に到着する一方で、これは一組の反復的シーケンスであり、従ってソロクライアントにおいてローカルクロックに同期することができる。
かくして、ソロクライアントは、ソリストローカルクロックとの関係においてタイムスタンプ付与された連続的データストリームを送り出す。このデータは、サーバに送られ、サーバの方は、ソロクライアントに遅れてそのローカルクロックが大ざっぱに同期化されているその他のクライアント全てに対しそのデータのエコーを送る。データはローカルクロックとの関係において同期することから、ソリストの自由な即興演奏は、ループされたデータと同期的に聞こえることになる。ルーピング技術は、ソリスト及び相対的に遅延された大ざっぱに同期化されたクライアントの両方共が、絶対時間におけるその差異にもかかわらず、音楽的連続性を同じように知覚することができるようにする。
ソリストのタイムスタンプ付与は、前述の手順の特殊なケースである。ソリストは、パートの形でクライアントに送られる１つの巨大なパターンとして扱かわれ、それは、実際上それ自体ループしない。これは、つねに増大しつつあるパターンのパターンとしてか、又は塊の形で送られる１つのパターンとして考えることができる。
ループ長の可変性及びループ長の決定は、ソリストラインと少し異なっている。フリーソリストパートは単純に、塊の形で送られる１つのきわめて長いパターンとして考えることができる。クライアントはソリストのデータを単に、織り込むだけである。ソリストを用いる場合は、それが必ずしも美的に快くはないものの面白い結果を生み出す可能性があるにせよ、実行中にプレイするソリストのアラインメントを変更しないように、すでに設定済みのループ長を有することが恐らく望まれるだろう。
図１６は、図１３のものに類似した本発明のソロライン実施形態の概略を示している。
本発明は、自由に即興演奏する１人のクライアントに関して記述されてきた。これはすなわち、１つのソロクライアントコンピュータが即興演奏されたラインを提供することを意味している。これは、一度に一人のみの人間がソロを行なうことを意味していない。充分に強力なコンピュータ及び充分に高い帯域幅を用いて複数のプレイヤグループがそのクライアントへと演奏することができ、同じクライアントによって録音されているかぎりにおいて、オーケストラ全体がソロを行なうことができるだろう。
同様にして、その他のクライアントのうちのいずれか又は第１の実施形態における全てのクライアントについてのシーケンスが、全て同じクライアントによって録音されつつある一定数のプレイヤによって提供されることも可能である。
ステップ１４０では、ソロクライアントは、サーバから送られた開始コマンドによって開始される。このときソロクライアントは、１４２においてサーバに対し連続的データストリームを送る。時間Ｔ＝０＋ｎで、サーバは、ステップ１４４において非ソロクライアントに対し開始コマンドを送る。これらのクライアントは、ステップ１４６においてデータシーケンスを生成しそれをサーバに送る。ステップ１４８で、サーバは、非ソロクライアントの各々に対しソロクライアントからの連続的データストリームのエコーを送り、クライアントは受信データを、本発明の第１の形態に関係して記述された要領でそれぞれのローカルクロックと再同期させる。サーバは、ステップ１５０で同様に、非ソロクライアントから受信したデータシーケンスをソロクライアントに、そしてデータを生成したクライアントを含めた又は除外した非ソロクライアントに対してそのエコーを送る。この受信データはそれ自体ステップ１５２で再同期させ、ソロ及び非ソロクライアントからのデータは、前述の要領で各クライアントにおいて出力することができる。

Claims

a) あるクライアントにおいてデータシーケンスを生成する段階と、
b) 前記データシーケンスをサーバに送出する段階と、
c) 前記サーバに接続される複数の更なるクライアントの各々に対して、該サーバから前記データシーケンスのエコーを送る段階と、
d) 前記更なるクライアントの各々において、前記の受信したデータシーケンスを夫々のローカル・クロックと同期させる段階と、
e) 前記あるクライアントにおいてはローカル的に生成された前記シーケンスを、且つ、前記更なるクライアントの各々においては受信してローカル的に同期させられた前記シーケンスを、複数回反復する段階と、
f) 異なるクライアントにて各々生成された複数の更なるシーケンスに対して段階a)乃至e)を反復する段階であって、これにより各クライアントが複数のローカル的に同期させられたデータシーケンスを受信する、前記の段階と、
を備えて成る、クライアント・サーバ式ネットワークを介しての複数の情報源からのデータを同期させる方法。
前記データシーケンスのひとつ以上のものは、一連のデータシーケンスから成る、請求項１記載の方法。
各データシーケンスは音楽的旋律を表す、請求項１記載の方法。
前記データシーケンスのひとつ以上のものは、楽器デジタルインタフェース（MIDI）装置により生成される、請求項３記載の方法。
受信したデータシーケンスを前記MIDI装置上でプレイバックする段階を備えて成る、請求項４記載の方法。
データシーケンスの各々は前記サーバに送出される前にタイムスタンプ付与される、請求項１記載の方法。
各クライアントから前記サーバに送出された前記データシーケンスは、ひとつ以上の音符のシーケンスに関するデータから成ると共に音符の相対的タイミングを含む、請求項３記載の方法。
各データシーケンスの長さは可変である、請求項１記載の方法。
各クライアントにより生成された前記データシーケンスの長さは同一である、請求項１記載の方法。
ひとつ以上のクライアントは前記第１データシーケンスと異なる長さのデータシーケンスを生成する、請求項１記載の方法。
前記一連のシーケンスのうちの各シーケンスの長さは同一である、請求項２記載の方法。
前記一連のシーケンスを構成する各シーケンスは、異なる長さを有する、請求項２記載の方法。
長いシーケンスの各々の長さは、最短シーケンスの長さの整数倍である、請求項１０記載の方法。
各ローカル・クロックに対して、ビート長さを設定する段階と、
各ビート時に、
a) 前記サーバからデータストリームを検索する段階と、
b) プレイバックされるべきデータに対して前記データストリームを検査する段階と、
c) 前記プレイバック用データを出力する段階と、
d) 残存データストリームに対して段階a)乃至c)を反復する段階と、
を備えて成る、請求項１記載の方法。
各ローカル・クロックはカウンタを含み、
ビート毎に前記カウンタをインクリメントする段階を備えて成る、
請求項１４記載の方法。
各クライアントに送出された前記データシーケンスはシーケンス長データを含み、
前記カウンタの累積カウントを前記シーケンス長で除算してその残余から現在のシーケンスビートを決定する段階を備えて成る、
請求項１５記載の方法。
サーバから第１開始コマンドを第１クライアントに送出して、該第１クライアントにおけるローカル・クロックを始動させる段階と、
前記第１クライアントから前記サーバに対して連続的データストリームを送出する段階と、
更なる開始コマンドを前記サーバから複数の更なるクライアントに対して送出して、前記更なるクライアントの各々におけるローカル・クロックを始動させる段階であって、前記更なる開始コマンドが前記第１開始コマンドに関して遅延された、前記の段階と、
前記複数の更なるクライアントの各々から前記サーバに対してデータシーケンスを送出する段階と、
前記複数の更なるクライアントの各々に対して前記サーバから前記連続的データストリームを送出する段階と、
前記複数の更なるクライアントの各々において前記受信した連続的データストリームを再同期させる段階と、
前記複数の更なるクライアントの各々と前記第１クライアントとに対して前記サーバから前記データシーケンスを送出する段階であって、該送出する段階が、所与のデータシーケンスを送出した元の更なるクライアントに対して該所与のデータシーケンスを送出する段階を含むかもしくは除外する、前記の送出する段階と、
前記クライアントの各々において前記受信したデータシーケンスをローカル・クロックに再同期させる段階と、
前記クライアントの各々において前記受信したデータシーケンスおよびローカル的に生成されたデータシーケンスを複数回反復する段階と、
を備えて成る、クライアント・サーバ式ネットワークを介しての複数の情報源からのデータを同期させる方法。
前記データシーケンスのひとつ以上のものは、一連のデータシーケンスから成る、請求項１７記載の方法。
各データシーケンスは楽器パートを表す、請求項１７記載の方法。
前記データシーケンスのひとつ以上のものは楽器デジタルインタフェース（MIDI）装置により生成される、請求項１９記載の方法。
前記受信したデータシーケンスを前記MIDI装置上でプレイバックする段階を備えて成る、請求項２０記載の方法。
各クライアントから前記サーバに送出された前記データシーケンスは、ひとつ以上の音符のシーケンスに関するデータから成ると共に、音符の相対的タイミングおよび音符を記述する他のパラメータを含む、請求項１７記載の方法。
各データシーケンスの長さは可変である、請求項１７記載の方法。
各クライアントにより生成された前記データシーケンスの長さは同一である、請求項１７記載の方法。
ひとつ以上のクライアントは前記第１データシーケンスと異なる長さのデータシーケンスを生成する、請求項１７記載の方法。
前記一連のシーケンスのうちの各シーケンスの長さは同一である、請求項１８記載の方法。
前記一連のシーケンスを構成する各シーケンスは異なる長さを有する、請求項１８記載の方法。
長いシーケンスの各々の長さは、最短シーケンスの長さの整数倍である、請求項２５記載の方法。
各ローカル・クロックに対して、ビート長さを設定する段階と、
各ビート時に、
a) 前記サーバからデータストリームを検索する段階と、
b) プレイバックされるべきデータに対して前記データストリームを検査する段階と、
c) 前記プレイバック用データを出力する段階と、
d) 残存データストリームに対して段階a)乃至c)を反復する段階と、
を備えて成る、請求項１７記載の方法。
各ローカル・クロックはカウンタを含み、
ビート毎に前記カウンタをインクリメントする段階を備えて成る、
請求項２９記載の方法。
各クライアントに送出された前記データシーケンスはシーケンス長データを含み、
前記カウンタの累積カウントを前記シーケンス長で除算してその残余から現在のシーケンスビートを決定する段階を備えて成る、
請求項３０記載の方法。
コンピュータに、
入力装置から前記コンピュータへデータシーケンスを入力する段階と、
前記入力されたデータシーケンスをローカル・クロックに同期させる段階と、
前記データシーケンスをリモートサーバに送出する段階と、
複数のデータシーケンスを受信する段階であって、該前記複数のデータシーケンスが、異なったクライアントにより作成され、そして前記異なったクライアントが前記複数のデータシーケンスを前記サーバに送ったとき、前記サーバを通して分配される、前記の受信する段階と、
前記受信したシーケンスを前記ローカル・クロックに同期させる段階と、
前記入力されたデータシーケンスおよび前記受信したデータシーケンスを複数回反復して出力データを生成する段階と、
前記出力データを出力に送出する段階と、
を実行させるためのプログラムを記録したコンピュータ読取可能記憶媒体。
前記コンピュータにより実行される前記データシーケンス入力段階は、一連のデータシーケンスを入力する段階から成る、請求項３２記載のコンピュータ読取可能記憶媒体。
前記入力装置から前記コンピュータに入力された前記データシーケンス、および、前記サーバからの前記データシーケンスは、各々、ひとつ以上の音符を指定すると共に音符の相対的タイミングと音符を記述する他のパラメータとを含むデータ、を含む、請求項３２記載のコンピュータ読取可能記憶媒体。
前記入力データシーケンスと、前記サーバから受信した前記データシーケンスとの長さは可変である、請求項３２記載のコンピュータ読取可能記憶媒体。
前記一連のシーケンスを構成する各シーケンスは、異なる長さである、請求項３３記載のコンピュータ読取可能記憶媒体。
前記一連のシーケンスのうちの各シーケンスの長さは同一である、請求項３３記載のコンピュータ読取可能記憶媒体。
前記同期段階は、
a) 前記サーバからデータシーケンスを検索する段階と、
b) 前記出力装置に出力されるべきデータに対して前記データシーケンスを検査する段階と、
c) 前記出力データを出力する段階と、
d) 更なるデータシーケンスに対して段階a)乃至c)を反復する段階と、
を備えて成る、請求項３２記載のコンピュータ読取可能記憶媒体。
前記連続的データストリームは前記複数の更なるクライアントの各々におけるバッファに記憶され、且つ、前記再同期段階は、前記バッファから検索されたデータを前記ローカル・クロックと再同期させる、請求項１７記載の方法。
コンピュータシステムであって、中央処理ユニットおよびこれと関連するメモリと、ローカル・クロックと、当該システムにデータを入力する為の入力装置とを備え、
前記入力装置からデータシーケンスを受信すると共に該入力シーケンスを前記ローカル・クロックと同期させる手段と、
前記データシーケンスをリモートサーバに対して送出する手段と、
複数の更なるデータシーケンスを受信する手段であって、前記複数の更なるデータシーケンスは、異なったコンピュータシステムにより作成され、そして前記異なったコンピュータシステムが前記複数の更なるデータシーケンスを前記サーバに送ったとき、前記サーバを通して分配される、前記の受信する手段と、
前記受信シーケンスを前記ローカル・クロックと同期させる手段と、
前記の入力シーケンスと受信データシーケンスの各々とを、複数回反復する手段と、
反復された前記複数の入力シーケンスおよび受信シーケンスを出力装置に送出する手段と、
を含む、コンピュータシステム。
前記出力装置および前記入力装置は、音符を生成して演奏する手段から成る、請求項４０記載のコンピュータシステム。
前記出力装置および前記入力装置はMIDI装置である、請求項４１記載のコンピュータシステム。
前記送出手段は、モデムもしくは他のネットワーク接続である、請求項４０記載のコンピュータシステム。
前記シーケンス受信および送出手段は、一連のシーケンスを受信および送出する手段から成る、請求項４０記載のコンピュータシステム。
前記シーケンス受信および送出手段は、長さ、音程、強度および相対的タイミングを各々有する一連の音符から成るデータを表す手段を備えて成る、請求項４０記載のコンピュータシステム。
データを出力装置に出力する前記手段は、
クロックの各ビート時に前記シーケンスからデータストリームを検索する手段と、
出力されるべきデータに対して所与のデータストリームを検査する手段と、
出力されるべき前記データを出力する手段と、
を備えて成る、請求項４０記載のコンピュータシステム。
バッファと、
該バッファ内に連続的データストリームを受信する手段と、
前記バッファからの前記データストリームを前記ローカル・クロックに対して同期させる手段と、
前記連続的データストリームを前記反復データシーケンスと同期させて前記出力装置に出力する手段と、
を更に備えて成る、請求項４０記載のコンピュータシステム。
a) クライアントにおいてデータシーケンスを生成する手段と、
b) 前記データシーケンスをサーバに送出する手段と、
c) 前記データシーケンスが生成された前記クライアントを含む、前記サーバに取り付けられた複数のクライアントの各々に対し、前記サーバから前記データシーケンスのエコーを送る手段と、
d) クライアントの各々において、前記受信されたデータシーケンスを夫々のローカル・クロックに同期させる手段と、
e) クライアントの各々において前記受信してローカル的に同期させたシーケンスを複数回反復する手段と、
f) 別個のクライアントにおいて各々生成された複数の更なるシーケンスに対して段階a)乃至e)を反復する手段であって、これにより、各クライアントがローカル的に同期させた複数のデータシーケンスを各クライアントに受信する、前記の反復する手段と、
を備えて成る、クライアント・サーバ式ネットワークを介しての複数の情報源からのデータを同期させる装置。
前記データシーケンスのうちのひとつ以上のものは、一連のデータシーケンスから成る、請求項４８記載の装置。
各データシーケンスは音楽的旋律を表す、請求項４８記載の装置。
前記生成手段は楽器デジタルインタフェース（MIDI）装置から成る、請求項５０記載の装置。
前記受信したデータシーケンスを前記MIDI装置上でプレイバックする手段を備えて成る、請求項５１記載の装置。
前記サーバに送出されつつあるデータシーケンスの各々にタイムスタンプ付与する手段を備えて成る、請求項４８記載の装置。
各クライアントから前記サーバに送出された前記データシーケンスは、ひとつ以上の音符のシーケンスに関するデータから成ると共に音符の相対的タイミングを含む、請求項５０記載の装置。
各データシーケンスの長さは可変である、請求項４８記載の装置。
各クライアントにより生成された前記データシーケンスの長さは同一である、請求項４８記載の装置。
ひとつ以上のクライアントにおいて前記第１データシーケンスと異なる長さのデータシーケンスを生成する手段を備えて成る、請求項４８記載の装置。
前記一連のシーケンスのうちの各シーケンスの長さは同一である、請求項４９記載の装置。
前記一連のシーケンスを構成する前記シーケンスは異なる長さを有する、請求項４９記載の装置。
長いシーケンスの各々の長さは、最短シーケンスの長さの整数倍である、請求項５７記載の装置。
各ローカル・クロックに対し、
ビート長さを設定する手段と、
各ビート時に前記サーバからデータストリームを検索する手段と、
プレイバックされるべきデータに対して各ビート時に前記データストリームを検査する手段と、
各ビート時に前記プレイバック用データを出力する手段と、
を備えて成る、請求項４８記載の装置。
各ローカル・クロックはカウンタを含み、
当該装置は、ビート毎に前記カウンタをインクリメントする手段を更に備えて成る、請求項６１記載の装置。
各クライアントに送出された前記データシーケンスはシーケンス長データを含み、
当該装置は、前記カウンタの累積カウントを前記シーケンス長で除算する手段と、その残余から現在のシーケンスビートを決定する手段とを更に備えて成る、
請求項６２記載の装置。
サーバから第１開始コマンドを第１クライアントに送出して、該第１クライアントにおけるローカル・クロックを始動させる手段と、
前記第１クライアントから前記サーバに対して連続的データストリームを送出する手段と、
更なる開始コマンドをサーバから複数の更なるクライアントに対して送出して、前記更なるクライアントの各々におけるローカル・クロックを始動させる手段であって、前記更なる開始コマンドが前記第１開始コマンドに関して遅延された、前記の始動させる手段と、
前記複数の更なるクライアントの各々から前記サーバに対してデータシーケンスを送出する手段と、
前記複数の更なるクライアントの各々に対して前記サーバから前記連続的データストリームを送出する手段と、
前記複数の更なるクライアントの各々において前記受信連続的データストリームを再同期させる手段と、
前記複数の更なるクライアントの各々と前記第１クライアントとに対して前記サーバから前記データシーケンスを送出する手段と、
前記クライアントの各々において前記受信データシーケンスをローカル・クロックに再同期させる手段と、
前記クライアントの各々において前記受信されたデータシーケンスを複数回反復する手段と、
を備えて成る、クライアント・サーバ式ネットワークを介しての複数の情報源からのデータを同期させる装置。
前記データシーケンスのうちのひとつ以上のものは一連のデータシーケンスから成る、請求項６４記載の装置。
各データシーケンスは楽器パートを表す、請求項６４記載の装置。
前記生成手段は楽器デジタルインタフェース（MIDI）装置から成る、請求項６６記載の装置。
前記受信したデータシーケンスを前記MIDI装置上でプレイバックする手段を備えて成る、請求項６７記載の装置。
各クライアントから前記サーバに送出された前記データシーケンスは、ひとつ以上の音符のシーケンスに関するデータから成ると共に音符の相対的タイミングおよび音符を記述する他のパラメータを含む、請求項６６記載の装置。
各データシーケンスの長さは可変である、請求項６４記載の装置。
各クライアントにより生成された前記データシーケンスの長さは同一である、請求項６４記載の装置。
ひとつ以上のクライアントは前記第１データシーケンスと異なる長さのデータシーケンスを生成する、請求項６４記載の装置。
前記一連のシーケンスのうちの各シーケンスの長さは同一である、請求項６５記載の装置。
前記一連のシーケンスを構成する前記シーケンスは異なる長さを有する、請求項６５記載の装置。
長いシーケンスの各々の長さは、最短シーケンスの長さの整数倍である、請求項７２記載の装置。
各ローカル・クロックに対し、
ビート長さを設定する手段と、
各ビート時に前記サーバからデータストリームを検索する手段と、
プレイバックされるべきデータに対して各ビート時に前記データストリームを検査する手段と、
各ビート時に前記プレイバック用データを出力する手段と、
を備えて成る、請求項６４記載の装置。
各ローカル・クロックはカウンタを含み、
当該装置は、ビート毎に前記カウンタをインクリメントする手段を更に備えて成る、請求項７６記載の装置。
各クライアントに送出された前記データシーケンスは、シーケンス長データを含み、
当該装置は、前記カウンタの累積カウントを前記シーケンス長で除算してその残余から現在のシーケンスビートを決定する手段を更に備えて成る、
請求項７７記載の装置。