JP3180751B2 - データの通信装置、通信方法、通信システム及びプログラムを記録した媒体 - Google Patents

Description

【発明の詳細な説明】

【０００１】

【発明の属する技術分野】本発明は、データの通信技術
に関し、特に通信回線の混雑を回避することができるデ
ータの通信技術に関する。

【０００２】

【従来の技術】電子楽器間の通信の統一規格として、Ｍ
ＩＤＩ（music instrumental digitalinterface）規格
がある。ＭＩＤＩ規格のインターフェースを備えた電子
楽器は、ＭＩＤＩ用ケーブルを用いて、他の電子楽器と
接続することができる。電子楽器は、ＭＩＤＩ用ケーブ
ルを介して、ＭＩＤＩデータを通信することができる。

【０００３】例えば、一の電子楽器は、演奏者が演奏し
た情報をＭＩＤＩデータとして送信し、他の電子楽器
は、当該ＭＩＤＩデータを受信し、楽音を発音すること
ができる。一の電子楽器で演奏すると、他の電子楽器で
リアルタイムに発音することができる。

【０００４】また、複数の汎用コンピュータを接続する
通信ネットワークでは、種々の情報を通信することがで
きる。例えば、コンピュータに接続されているハードデ
ィスク等に生の楽音情報やＭＩＤＩデータ等の情報を一
度蓄積しておき、通信ネットワークを介して、当該情報
を送信することができる。他のコンピュータは、当該情
報を受信して、ハードディスク等の記憶装置に記憶す
る。汎用の通信ネットワークは、情報の通信を行うのみ
であり、ＭＩＤＩとは性質を異にする。

【０００５】

【発明が解決しようとする課題】ＭＩＤＩ規格は、電子
楽器間のリアルタイム通信を可能にするが、長距離の通
信及び多数ノード間の通信に適していない。一方、汎用
通信ネットワークは、長距離の通信及び多数ノード間の
通信に適しているが、電子楽器間のリアルタイム通信を
考慮したものではない。

【０００６】楽音情報のリアルタイム通信を行うと、時
間当たりの情報量が多くなり、通信回線が混雑しやす
い。また、１対１通信に比べ、多数のノードに楽音情報
を送信するとなると、さらに通信回線が混雑しやすくな
る。通信回線が混雑すると、通信速度の遅れが生じ、リ
アルタイム演奏に支障が生じる。

【０００７】本発明の目的は、通信回線の混雑を回避す
ることができるデータの通信技術を提供することであ
る。

【０００８】

【課題を解決するための手段】 本発明の一観点によれ
ば、データの通信装置は、少なくともＭＩＤＩデータを
含むデータを受信する受信手段と、外部から自己にアク
セス中である回線数を認識するアクセス数認識手段と、
前記回線数に応じて前記受信手段が受信したデータのう
ち特定のデータに対して、データの分離、データの差別
化、データの分解能操作、時間の分解能操作のいずれか
又はこれらの組み合わせによりデータを削減してアクセ
ス中の回線に送信する送信手段とを有する。

【０００９】アクセス中である回線数が多いときには、
受信したデータを削減して送信することにより、回線の
混雑を緩和させることができる。アクセス中である回線
数が少ないときには、必ずしもデータを削減する必要は
ない。

【００１０】本発明の他の観点によれば、各々が受信手
段と送信手段を有する複数の通信装置を含む通信システ
ムであって、該複数の通信装置において該受信手段はそ
れぞれ同一のデータを受信する手段であり、該複数の通
信装置において該送信手段はそれぞれ該受信手段が受信
したデータを削減して送信することができる手段であ
り、一の通信装置で削減するデータと他の通信装置で削
減するデータとが異なる通信システムが提供される。

【００１１】一の通信装置で削減するデータと他の通信
装置で削減するデータとが異なるので、各通信装置が送
信するデータの質が異なる。通信装置により、例えば、
削減されるデータ量やデータ対象が異なる。ユーザは、
アクセスする通信装置を選択することにより、所望の質
を有するデータを得ることができる。

【００１２】

【発明の実施の形態】図１は、楽音情報の通信ネットワ
ークを示す図である。

【００１３】演奏会場１には、ＭＩＤＩ楽器２、カメラ
４、エンコーダ３、５、及びルータ６が備えられる。演
奏会場１では、演奏者がＭＩＤＩ楽器２を演奏する。Ｍ
ＩＤＩ楽器２は、演奏者の演奏操作に応じてＭＩＤＩデ
ータを生成し、エンコーダ３に供給する。エンコーダ３
は、ＭＩＤＩデータを所定のデータ形式で、ルータ６を
介してインターネット上にパケット送信する。データ形
式は、後に図４を参照しながら説明する。

【００１４】カメラ４は、演奏者が演奏している様子を
撮影し、その様子を画像データとしてエンコーダ５に供
給する。エンコーダ５は、画像データを所定のデータ形
式で、ルータ６を介してインターネット上にパケット送
信する。マイク１３は、ボーカル、ピアノ等の生楽器、
電気楽器の音声をサンプリングし、このサンプリングデ
ータを音声データとしてエンコーダ１４に供給する。エ
ンコーダ１４は音声データを所定のデータ形成でルータ
６を介しインターネット上にパケット送信する。データ
形式は、後に図４を参照しながら説明する。

【００１５】ルータ６は、以下に示すインターネットを
介して、ＭＩＤＩデータ及び画像データを送信する。当
該データは、電話回線又は専用回線を通り、ルータ６か
らメインサーバ７に供給され、さらに複数の中継サーバ
１２ａ，１２ｂ，１２ｃ，・・・に供給され、さらにＷ
ＷＷ（world wide web）サーバ８に供給される。ＷＷＷ
サーバ８は、いわゆるプロバイダである。

【００１６】以下、中継サーバ１２ａ、１２ｂ、１２
ｃ、…の全て又は個々を中継サーバ１２という。中継サ
ーバ１２は、通信回線の混雑を回避させる役割を有す
る。中継サーバ１２は、通信回線の混み具合に応じて、
メインサーバ７から供給されるデータの量を調整してＷ
ＷＷサーバ８に供給する。例えば、中継サーバ１２にア
クセスするユーザの数（回線数）が多いときには、通信
回線が混雑していると判断し、データの間引きを行い、
データ量を減らす。データ量を減らすことにより、通信
回線の混雑を回避させることができる。

【００１７】複数の中継サーバ１２ａ，１２ｂ，１２ｃ
は、それぞれデータの削減量又は削減方法を異ならせる
ことができる。データの削減量は、そのデータに基づく
音質又は画質に影響する。削減量が多くなると、音質又
は画質が低くなる。

【００１８】例えば、中継サーバ１２ａでは、アクセス
できるユーザの数を少なくし、音質及び画質を高くする
ことができる。他の中継サーバ１２ｃでは、音質及び画
質を抑えることによって、アクセスできるユーザの数を
多くすることができる。この中継サーバ１２の働きによ
り、通信回線の混雑を緩和させることができる。

【００１９】ユーザは、ホームコンピュータ９をＷＷＷ
サーバ８に接続することにより、インターネットを使用
することができる。ホームコンピュータ９は、インター
ネットを使用し、ＭＩＤＩデータ及び画像データ、音声
データをリアルタイムで受信することができる。ホーム
コンピュータ９は、ディスプレイ装置及び内蔵又は外付
けのＭＩＤＩ音源を有し、ディスプレイ装置に画像デー
タを表示し、ＭＩＤＩ音源に楽音信号を生成させること
ができる。ＭＩＤＩ音源は、ＭＩＤＩデータを基に楽音
信号を生成し、当該楽音信号を音声出力装置１１に出力
する。音声出力装置１１は、Ｄ／Ａ変換器、アンプ及び
スピーカを有し、当該楽音信号に応じて発音する。又、
音声データはそのデータが再生され、Ｄ／Ａ変換後アン
プを通り、スピーカより音声として再現される。演奏会
場１で演奏される演奏音と同等の音が音声出力装置１１
からリアルタイムで発音される。

【００２０】また、ホームコンピュータ９の外部に、Ｍ
ＩＤＩ音源１０を接続すれば、ホームコンピュータ９
は、ＭＩＤＩ音源１０に楽音信号を生成させ、音声出力
装置１１から発音させることができる。

【００２１】なお、ユーザにとっては、画像データより
もＭＩＤＩデータ及び音声データの方が重要な情報であ
るので、画像データよりもＭＩＤＩデータ及び音声デー
タを優先して処理を行う。画像データは、画質が悪く、
コマ数が少なくてもさほど気にならないが、ＭＩＤＩデ
ータ及び音声データに基づく楽音情報及び音声情報は高
品質が要求される。

【００２２】ユーザは、自宅のホームコンピュータ９を
インターネットに接続すれば、誰でも演奏を聴くことが
できる。さらに、ユーザは、演奏会場１に赴かなくて
も、自宅にいながらディスプレイ装置で演奏会場１の光
景を見ながら、リアルタイムで演奏を聴くことができ
る。演奏会場１でコンサートを行った場合には、不特定
多数人が自宅でそのコンサートを楽しむことができる。

【００２３】演奏会場１からＭＩＤＩデータをユーザの
自宅に送信することにより、演奏者が複数のユーザのそ
れぞれの自宅で電子楽器を演奏（演奏操作）しているか
のような状況を作り出すことができる。

【００２４】コンサートの主催者は、コンサートの定員
を決めて、ユーザにチケットを発行することができる。
チケットには、例えばランクＡ（特等席）、ランクＢ
（普通席）、ランクＣ（立見席）等のランクをつけるこ
とができる。ランクＡのユーザは中継サーバ１２ａにア
クセスでき、高い質の楽音情報及び画像情報が得られ
る。ランクＢのユーザは、中継サーバ１２ｂにアクセス
でき、データ量を削減した楽音情報及び画像情報が得ら
れる。ランクＣのユーザは、中継サーバ１２ｃにアクセ
スでき、データ量を削減した楽音情報だけが得られ、画
像情報は得られない。

【００２５】さらに、インターネットでは、生の楽音情
報ではなく、ＭＩＤＩデータを通信するので、雑音によ
り音質を下げることはない。ただし、インターネット
は、長距離通信を行い、かつ種々の通信ポイントを経由
するので、エンコーダ３、５におけるデータ送信時及び
ホームコンピュータ９におけるデータ受信時に、以下に
示す通信エラー対策を行う必要がある。通信エラーは、
例えば、データ化け、データ欠落、データ重複、データ
の順序入れ替え等である。

【００２６】図２は、エンコーダ３、５及びホームコン
ピュータ９のハードウエアの構成を示す図である。これ
らは、汎用コンピュータを用いることができる。

【００２７】バス３１には、キーボードやマウス等の入
力装置２６、表示器２７、ＭＩＤＩ音源２８、インター
ネットを行うための通信インターフェース２９、ＭＩＤ
Ｉインターフェース３０、ＲＡＭ２１、ＲＯＭ２２、Ｃ
ＰＵ２３、外部記憶装置２５が接続されている。

【００２８】入力装置２６は、種々の設定を指示するこ
とができる。ホームコンピュータ９においては、表示器
２７は演奏会場の模様を表示し、ＭＩＤＩ音源２８は受
信したＭＩＤＩデータを基に楽音信号を生成し、外部に
出力する。

【００２９】通信インターフェース２９は、インターネ
ットにより、ＭＩＤＩデータ及び画像データを送受信す
るためのインターフェースである。ＭＩＤＩインターフ
ェース３０は、外部に対してＭＩＤＩデータを送受信す
るためのインターフェースである。

【００３０】外部記憶装置２５は、例えばハードディス
クドライブ、フロッピーディスクドライブ、ＣＤ−ＲＯ
Ｍドライブ、光磁気ディスクドライブ等であり、ＭＩＤ
Ｉデータ、画像データ又はコンピュータプログラム等を
記憶することができる。

【００３１】ＲＯＭ２２は、コンピュータプログラムや
各種パラメータを記憶することができる。ＲＡＭ２１
は、キーオンバッファ２１ａと音源設定バッファ２１ｂ
を有する。キーオンバッファ２１ａは、ＭＩＤＩデータ
中のキーオンイベントを格納し、音源設定バッファ２１
ｂは、ＭＩＤＩデータ中の音源設定情報を格納する。

【００３２】ＲＡＭ２１は、その他、バッファやレジス
タ等のワーキングエリアを有し、ＲＯＭ２２や外部記憶
装置２５に記憶されている内容をコピーして記憶するこ
とができる。ＣＰＵ２３は、ＲＯＭ２２又はＲＡＭ２１
に記憶されているコンピュータプログラムに従って、各
種演算または処理を行う。ＣＰＵ２３は、タイマ２４か
ら時間情報を得ることができる。

【００３３】外部記憶装置２５は、例えばハードディス
クドライブ（ＨＤＤ）である。ＨＤＤ２５は動作プログ
ラムやＭＩＤＩデータ等の各種データを記憶することが
できる。ＲＯＭ２２に動作プログラムが記憶されていな
い場合、このＨＤＤ２５内のハードディスクに動作プロ
グラムを記憶させておき、それをＲＡＭ２１に読み込む
ことにより、ＲＯＭ２２に動作プログラムを記憶してい
る場合と同様の動作をＣＰＵ２３にさせることができ
る。このようにすると、動作プログラムの追加やバージ
ョンアップ等が容易に行える。また、外部記憶装置２５
は、ＨＤＤ及びＣＤ−ＲＯＭ（コンパクトディスク−リ
ード・オンリィ・メモリ）ドライブを含むＣＤ−ＲＯＭ
ドライブは、ＣＤ−ＲＯＭに記憶されている動作プログ
ラムや各種データを読み出すことができる。読み出した
動作プログラムや各種データは、ＨＤＤ内のハードディ
スクにストアされる。動作プログラムの新規インストー
ルやバージョンアップ等が容易に行える。なお、このＣ
Ｄ−ＲＯＭドライブ以外にも、外部記憶装置２５とし
て、フロッピィディスクドライブ、光磁気ディスク（Ｍ
Ｏ）装置等、様々な形態のメディアを利用するための装
置を設けるようにしてもよい。

【００３４】通信インターフェイス２９はＬＡＮ（ロー
カルエリアネットワーク）やインターネット、電話回線
等の通信ネットワーク３２に接続されており、該通信ネ
ットワーク３２を介して、サーバコンピュータ３３と接
続される。ＨＤＤ２５内に上記動作プログラムや各種デ
ータが記憶されていない場合、サーバコンピュータ３３
からプログラムやデータをダウンロードするために用い
られる。クライアントとなるエンコーダ３，５又はホー
ムコンピュータ９は、通信インターフェイス２９及び通
信ネットワーク３２を介してサーバコンピュータ３３へ
と動作プログラムやデータのダウンロードを要求するコ
マンドを送信する。サーバコンピュータ３３は、このコ
マンドを受け、要求された動作プログラムやデータを、
通信ネットワーク３２を介してエンコーダ３，５又はホ
ームコンピュータ９へと配信し、エンコーダ３，５又は
ホームコンピュータ９が通信インターフェイス２９を介
して、これらプログラムやデータを受信してＨＤＤ２５
に蓄積することにより、ダウンロードが完了する。

【００３５】なお、本実施例は、本実施例に対応する動
作プログラムや各種データをインストールした市販のパ
ーソナルコンピュータ等によって、実施させるようにし
てもよい。その場合には、本実施例に対応する動作プロ
グラムや各種データを、ＣＤ−ＲＯＭやフロッピィディ
スク等のパーソナルコンピュータが読み込むことができ
る記憶媒体に記憶させた状態で、ユーザーに提供しても
よい。そのパーソナルコンピュータ等が、ＬＡＮ、イン
ターネット、電話回線等の通信ネットワークに接続され
ている場合には、通信ネットワークを介して、動作プロ
グラムや各種データ等をパーソナルコンピュータ等に提
供してもよい。

【００３６】図３は、ＭＩＤＩデータの通信エラー対策
を示す図である。図では、模式的に、キーオン中をハイ
レベルで表し、キーオフ中をローレベルで表す。

【００３７】時刻ｔ１においてキーオンを送信し、時刻
ｔ４においてキーオフを送信する場合を説明する。時刻
ｔ１において送信したキーオンが通信エラーを起こし、
欠落する場合がある。その場合、受信側のホームコンピ
ュータ９は、キーオンを受け取らず、キーオフのみを受
け取ることになってしまう。これでは、正常な演奏を再
現することができない。キーオンが生成されず、キーオ
フのみが生成されることは、演奏規則上ありえない。

【００３８】このような状況を回避するため、時刻ｔ１
においてキーオンを送信した後、所定時間が経過する
度、すなわち時刻ｔ２及び時刻ｔ３においてリカバリー
キーデータを送信する。

【００３９】リカバリーキーデータは、只今キーオン中
であることを確認的に伝えるデータである。時刻ｔ１に
おけるキーオンが受信されなかった場合でも、時刻ｔ２
におけるリカバリーキーデータを受信することにより、
時刻ｔ１からわずか遅れるがキーオンさせることができ
る。さらに、時刻ｔ１及びｔ２の両方のデータを受信で
きない場合であっても、時刻ｔ３におけるリカバリーキ
ーデータによりキーオンさせることができる。

【００４０】ただし、楽音信号は、一般的に時間の経過
と共に減衰する。したがって、リカバリーキーデータを
送信する際には、時間経過を考慮し、ベロシティ（音
量）の減少したキーオンを送信することが好ましい。具
体的には、時刻ｔ１，ｔ２，ｔ３の順で、徐々にベロシ
ティを小さくしたキーオンを送信すればよい。

【００４１】上記のリカバリーキーデータによりキーオ
ンの通信エラーをリカバリーすることができる。次に、
時刻ｔ４のキーオフが通信エラーを起こした場合のリカ
バリー方法を説明する。

【００４２】キーオフが生じた後、キーオンと同様にキ
ーオフのリカバリーデータを送信することも可能であ
る。ただし、各鍵において、キーオフ中の時間はキーオ
ン中の時間より著しく長い。一旦キーオフされた後、次
のキーオンまでリカバリーデータを送ると、そのデータ
量が莫大なものになってしまう。

【００４３】キーオンのリカバリーキーデータは、キー
オンの時刻ｔ１からキーオフの時刻ｔ４の間送信され、
時刻ｔ４の後は送信されない。すなわち、リカバリーキ
ーデータが送信されないことは既にキーオフが生じたこ
とを意味する。もし、ホームコンピュータ９が時刻ｔ４
におけるキーオフを受信できなかったときには、その後
にリカバリーキーデータが送信されてこないことを確認
し、現在キーオフ中であると判断すればよい。

【００４４】ホームコンピュータ９は、現在キーオン中
であるにもかかわらずリカバリーキーデータが送信され
てこなくなったときには、キーオフし、音が誤って鳴り
つづける現象を防止することができる。これらの判断
は、図２のキーオンバッファ２１ａを参照することによ
り行う。詳細は、後にフローチャートを参照しながら説
明する。

【００４５】キーオン／オフの場合と同様に、図２の音
源設定バッファ２１ｂを参照することにより、音源設定
情報をリカバリーするためのリカバリー音源設定情報を
通信することもできる。

【００４６】図４は、通信パケットのフォーマットを示
す図である。図１のエンコーダ３、５は当該パケットを
送信し、ホームコンピュータ９は当該パケットを受信す
る。

【００４７】パケットは、ヘッダ部４１とデータ部４２
からなる。ヘッダ部４１は、２ワード（１ワードは１６
ビット）のチェックサム４３、４ワードのデータＩＤ４
４、４ワードのシーケンスナンバー４５、４ワードの時
間情報４６、２ワードのイベントデータ長４７を有す
る。

【００４８】チェックサム４３は、チェックサムを除く
ヘッダ部４１とデータ部４２のデータの合計値である。
送信側は、当該合計値を計算し、チェックサム４３とし
てパケット中に付与する。受信側は、当該合計値を計算
し、チェックサム４３の値と合っていれば、通信エラー
がないことを確認することができる。

【００４９】データＩＤ４４は、データ部４２の種類を
番号で表す。番号０、１、２はＭＩＤＩデータであり、
番号３は画像データであり、番号４は音声データであ
る。ＭＩＤＩデータのうち、番号０は実イベントのデー
タ（通常のＭＩＤＩデータ）であり、番号１はリカバリ
ーキーデータ（図３）であり、番号２はリカバリー音源
設定情報である。

【００５０】シーケンスナンバー４５は、パケット単位
で付与されるシーケンスナンバーである。受信側は、シ
ーケンスナンバー４５を確認することにより、通信エラ
ーによりデータの順序が入れ替った場合でもリカバリー
することができる。

【００５１】時間情報４６は、１ビットが１ｍｓを示す
再生時間である。４ワードあれば１００時間以上の時間
情報を表現することができる。時間情報４６を用いれ
ば、複数の演奏会場での同時セッションが可能になる。
各演奏会場毎に演奏時間を時間情報４６として付与すれ
ば、演奏会場同士の同期をとりながら自宅で同時演奏を
聴くことができる。時間情報４６は、絶対時間が望まし
いが、全ての演奏会場の共通時間であれば相対時間でも
よい。

【００５２】イベントデータ長４７は、データ部４２の
データ長を表す。データ部４２は、実データ４８からな
る。実データ４８は、ＭＩＤＩデータ又は画像データで
ある。

【００５３】通信速度は、高速であることが好ましい。
例えば６４Ｋビット／ｓ（ＩＳＤＮ回線）である。１パ
ケットのデータ長は、限定されないが、通信効率を考慮
すれば約１Ｋバイト又は５１２バイトが好ましい。

【００５４】図５は、エンコーダ３が行う送信処理を示
すフローチャートである。ステップＳＡ１において、Ｍ
ＩＤＩ楽器２からＭＩＤＩデータを受信する。ステップ
ＳＡ２では、受信したデータをＲＡＭにバッファリング
する。

【００５５】ステップＳＡ３では、受信したデータのイ
ベントの種類を識別する。キーオンであれば、ステップ
ＳＡ６へ進み、当該キーオンをキーオンバッファ２１ａ
（図２）に登録し、ステップＳＡ７へ進む。

【００５６】キーオフであれば、ステップＳＡ４へ進
み、キーオンバッファ２１ａをサーチして、同一のキー
コードがあればそのキーオンをキーオンバッファ２１ａ
から削除する。その後、ステップＳＡ７へ進む。

【００５７】音源設定情報であれば、ステップＳＡ５へ
進み、当該音源設定情報を音源設定バッファ２１ｂ（図
２）に登録し、ステップＳＡ７へ進む。音源設定情報
は、プログラムチェンジ、コントロールデータ、イクス
クルーシブメッセージ、その他のデータである。

【００５８】ステップＳＡ７では、図４に示すように、
チェックサム４３、実イベントデータ（番号０）を示す
データＩＤ４４、シーケンスナンバー４５、タイマに応
じた時間情報４６、イベントデータ長４７を、受信した
ＭＩＤＩデータに付加し、パケット化して送信する。こ
の際、ほぼ同時間に発生した同種類の複数のイベントを
１つにまとめてパケット化し、送信することができる。
その後、送信処理を終了する。

【００５９】なお、エンコーダ５は、上記の処理と同様
にして、画像データを送信する。その場合、データＩＤ
４４の番号は３である。

【００６０】図６（Ａ）、（Ｂ）は、エンコーダ３が行
う割り込み処理を示すフローチャートである。当該割り
込み処理は、タイマに応じた所定時間間隔で行われる。
例えば、１００〜２００μｓの間隔で割り込み処理が行
われる。

【００６１】図６（Ａ）は、リカバリーキーデータの送
信処理を示すフローチャートである。

【００６２】ステップＳＢ１では、キーオンバッファ２
１ａ（図２）をサーチする。ステップＳＢ２では、キー
オンバッファ２１ａ中のイベントデータを、リカバリー
キーデータとして、図４に示すようにパケット化して送
信する。ただし、リカバリーキーデータは、時間経過を
考慮して、キーオンバッファ２１ａ中のキーオンよりも
減少させたベロシティを設定する。

【００６３】パケット中のデータＩＤ４４は、リカバリ
ーキーデータを示す番号１である。シーケンスナンバー
４５は、実イベントデータ（図５）とリカバリーキーデ
ータ（図６（Ａ））との共通のシーケンスナンバーであ
る。送信後、割り込み前の処理に戻る。

【００６４】図６（Ｂ）は、リカバリー音源設定情報の
送信処理を示すフローチャートである。当該送信処理
は、比較的時間的精度が要求されないので、リカバリー
キーデータの送信処理（図６（Ａ））よりも長い周期で
行ってもよい。

【００６５】ステップＳＣ１では、音源設定バッファ２
１ｂ（図２）をサーチする。ステップＳＣ２では、音源
設定バッファ２１ｂ中のイベントデータを、リカバリー
音源設定情報として、図４に示すようにパケット化して
送信する。

【００６６】パケット中のデータＩＤ４４は、リカバリ
ー音源設定情報を示す番号２である。シーケンスナンバ
ー４５は、実イベントデータ（図５）とリカバリーキー
データ（図６（Ａ））とリカバリー音源設定情報（図６
（Ｂ））との共通のシーケンスナンバーである。送信
後、割り込み前の処理に戻る。

【００６７】図７は、ホームコンピュータ９が行う受信
処理を示すフローチャートである。ステップＳＤ１にお
いて、インターネット上のデータを受信する。ステップ
ＳＤ２では、パケット中のチェックサム４３（図４）を
確認する。

【００６８】ステップＳＤ３では、チェックサムの結果
をチェックする。チェックサムがエラーであれば、パケ
ット中にデータの誤りがあることを示すので、ステップ
ＳＤ９へ進み、何もせずに処理を終了する。信頼性に欠
けるデータは捨てることにより、誤った発音や設定をな
くすことが効果的である。

【００６９】チェックサムが正常であれば、データの信
頼性があるので、ステップＳＤ４へ進む。ステップＳＤ
４では、パケット中のシーケンスナンバー４５（図４）
を確認する。正常な通信では、受信毎にシーケンスナン
バー４５が順次増加するが、通信エラーにより受信デー
タの順番が入れ替わることがある。

【００７０】ステップＳＤ５では、受信したデータが再
生すべきシーケンスナンバー４５であり、かつホームコ
ンピュータ９の現時刻が再生すべき時間情報４６（図
４）以降であるか否かをチェックする。複数の演奏会場
での同時セッションを行う場合には、ある演奏会場の時
間情報４６が未だ再生すべき時間になっていないことが
ある。

【００７１】未だ再生すべきでないときには、ステップ
ＳＤ１０へ進み、受信したデータをＲＡＭにバッファリ
ングし、後の適正なタイミングでの処理に備える。その
後、処理を終了する。

【００７２】再生すべきであるときには、ステップＳＤ
６へ進み、イベント処理を行う。イベント処理は、ＭＩ
ＤＩデータや画像データ等のイベントに応じた処理であ
る。その詳細は、後に図８のフローチャートを参照しな
がら説明する。

【００７３】ステップＳＤ７では、シーケンスナンバー
をカウントアップする。ステップＳＤ８では、ステップ
ＳＤ１０でバッファリングしたバッファ内のデータが、
再生すべきシーケンスナンバー４５であり、かつ現時刻
が再生すべき時間情報４６以降のものがあるか否かをチ
ェックする。

【００７４】再生すべきものがないときには、処理を終
了する。再生すべきものがあるときには、ステップＳＤ
６へ進み、当該データについての処理を繰り返す。バッ
ファ内に再生すべきデータがなくなるまで、当該処理を
繰り返す。この処理により、通信エラーによりデータの
順序が入れ替わって受信したデータをも適切に処理する
ことができる。

【００７５】なお、バッファ内に所定以上のデータが蓄
積されたときには、次に処理すべきシーケンスナンバー
のデータが欠落したと判断し、そのデータの処理を飛ば
し、その次のシーケンスナンバーのデータの処理を進め
る。

【００７６】図８は、図７のステップＳＤ６に示すイベ
ント処理の詳細を示すフローチャートである。

【００７７】ステップＳＥ１では、データＩＤの番号を
識別する。番号が０であれば、実イベントデータを示
し、ステップＳＥ２へ進む。ステップＳＥ２では、イベ
ントの種類を識別する。

【００７８】キーオンであれば、ステップＳＥ３へ進
み、当該キーオンをキーオンバッファ２１ａ（図２）に
登録し、音源へ転送する。音源は、キーオンを受けて、
発音開始のための処理を行う。その後、図７の処理へ戻
る。

【００７９】キーオフであれば、ステップＳＥ４へ進
み、キーオンバッファ２１ａをサーチして、同一のキー
コードがあれば、キーオンバッファ２１ａ中のキーオン
を削除し、当該キーオフを音源へ転送する。音源は、キ
ーオフを受けて、消音のための処理を行う。その後、図
７の処理へ戻る。

【００８０】音源設定情報であれば、ステップＳＥ５へ
進み、当該音源設定情報を音源設定バッファ２１ｂに登
録し、音源へ転送する。音源は、音源設定情報を受け
て、音色、音量等を設定する。その後、図７の処理へ戻
る。

【００８１】データＩＤの番号が１であれば、受信した
データがリカバリーキーデータであることを意味し、ス
テップＳＥ６へ進む。当該リカバリーキーデータを現在
のキーオンバッファ２１ａと比較し、その差分をイベン
ト化してキーオンバッファ２１ａに登録して、音源へ転
送する。この処理により、通信エラーにより欠落したキ
ーオンをリカバリーすることができる。

【００８２】ステップＳＥ７では、当該リカバリーキー
データを受信したことを登録する。キーオフ後は、リカ
バリーキーデータが送信されてこなくなるので、この登
録を行うことにより、対応するキーオンが現在もキーオ
ン中であることを確認することができる。キーオンバッ
ファにキーオンが存在するにもかかわらず、リカバリー
キーデータが送信されてこなくなったら、キーオフが欠
落していることを示す。その後、図７の処理へ戻る。

【００８３】データＩＤの番号が２であれば、受信した
データがリカバリー音源設定情報であることを意味し、
ステップＳＥ８へ進む。当該リカバリー音源設定情報を
現在の音源設定バッファ２１ｂと比較し、その差分をイ
ベント化して音源設定バッファ２１ｂに登録して、音源
へ転送する。この処理により、通信エラーにより欠落し
た音源設定情報をリカバリーすることができる。

【００８４】データＩＤの番号が３であれば、受信した
データが画像データであることを意味し、ステップＳＥ
９へ進む。ステップＳＥ９では、当該画像データを表示
器に表示する処理を行う。ただし、画像データは、ＭＩ
ＤＩデータよりも優先度を低くして処理を行う。表示す
る画像は、原則として１画面を単位として処理を行う。
ＭＩＤＩデータを優先させるため、画像は静止画像でも
よい。その後、図７の処理へ戻る。データＩＤが４２で
あれば、受信データは音声データであることを意味し、
ステップＳＥ１０へ進む。ステップＳＥ１０では音声デ
ータを再生する処理を行なう。

【００８５】図９は、ホームコンピュータ９が行う割り
込み処理を示すフローチャートである。当該割り込み処
理は、タイマに応じて所定時間間隔で行われる。例え
ば、１００〜２００μｓの間隔で割り込み処理が行われ
る。

【００８６】ステップＳＦ１では、キーオンバッファ２
１ａ（図２）をサーチする。ステップＳＦ２では、キー
オンバッファ２１ａ中のキーオンの中で、一定時間、対
応するリカバリーキーデータを受信しないものについて
は、当該キーオンを削除し、対応するキーオフを音源に
転送する。当該転送後、割り込み前の処理に戻る。この
一定時間は、少なくとも引続く２回のリカバリーデータ
を受信するのに十分な時間とすることができる。

【００８７】この処理により、通信エラーによりキーオ
フが欠落した際にも、誤って音が鳴り続けることを防止
することができる。なお、一定時間リカバリーキーデー
タを受信しないことの判断は、図８のステップＳＥ７で
リカバリーキーデータの受信を登録することにより、可
能となる。

【００８８】上記のリカバリーキーデータ及びリカバリ
ー音源設定情報（以下、両者をまとめてリカバリーデー
タと呼ぶ）を送信することにより、データの欠落又は化
けが生じた場合にも、適切なリカバリーを行うことがで
きる。

【００８９】次に、回線の混雑を緩和させる方法を説明
する。ネットワーク上で演奏情報及び上記のリカバリー
データを通信する場合、かなり多くのデータが回線を流
れる。また、上記のコンサートを行う場合、サーバに同
時にアクセスするユーザの数もかなりの数になる。

【００９０】このような状況下においては、ユーザが所
有するホームコンピュータにおいてスムーズな演奏を再
現する保証を確保できない場合が生じえる。そこで、図
１に示すように中継サーバを複数設け、それぞれの中継
サーバが回線の混み具合に応じて独自にデータを削減
し、回線の混雑を緩和させる。

【００９１】ただし、データを削減すると、音質又は画
質が低下するので、中継サーバは、独自に許容できるデ
ータ削減率や削減方法、及び自己にアクセス可能なユー
ザの数を設定することができる。

【００９２】中継サーバは、自己にアクセスする数が少
ないときにはデータを削減しないでユーザに送信し、ア
クセスする数が多くなるとデータを削減してユーザに送
信することができる。

【００９３】データを削減する方法には、以下のものが
ある。 （１）データの分離 中継サーバは、楽音情報（ＭＩＤＩデータ）と画像情報
（画像データ）と音声情報（オーディオデータ）を受信
する。画像情報は、楽音情報及び音声情報に比べればデ
ータの質がそれほど要求されないので、中継サーバは受
信した情報を楽音情報及び音声情報と、画像情報とに分
離し、楽音情報及び音声情報のみをユーザに送信するこ
とができる。同様にして、楽音情報、音声情報又は画像
情報中のデータについて更に細かく分離し、必要なデー
タのみを送信するようにしてもよい。重要な情報のみを
送信してデータを削減することにより、回線の混雑を緩
和させることができる。

【００９４】（２）データの差別化 中継サーバは、データの優先度を規定し、重要なデータ
を優先的に送信する。すなわち、回線が混雑していると
きには重要なデータのみをその時に送信し、重要でない
データは後に時間をずらして送信し、回線の混雑を緩和
させる。この方法は、全体的には必ずしもデータ量が削
減されていないが、その時点で送信するデータ量は削減
される。

【００９５】例えば、キーオフの欠落は、キーオンの欠
落に比べ、致命的なエラーである。つまり、キーオフの
情報は、データの重要度が高い。中継サーバは、受信し
たパケットをキーオフとそれ以外のデータに分割し、前
者をまず優先的に送信し、その後に後者を送信する。

【００９６】なお、キーオンとそれに対応するキーオフ
が同一のパケット内に存在するときに、キーオンとキー
オフを分割して先にキーオフを送信し後にキーオンを送
信すると不都合が生じるので、その場合は両者とも送信
しないことが好ましい。同様にして、優先的に送信する
ことの不都合がある場合には、それに対処した処理が必
要である。

【００９７】（３）データの分解能操作 中継サーバは、データの分解能を低くしてユーザに送信
し、データ量を減らす。例えば、ボリュームが時間の経
過と共に１ステップずつ増加する場合、データの分解能
を低くし、２ステップずつ増加するデータを送信し、デ
ータ量を１／２にする。ボリュームの他、ピッチベンド
やアフタタッチ等のコントロールデータ（コントローラ
のデータ）の分解能を下げることができる。コントロー
ラの種類に応じて異なる分解能を設定し、複数のコント
ロールデータの分解能を下げるようにしてもよい。

【００９８】（４）時間の分解能操作 上記のリカバリーデータは、周期的に送信される。中継
サーバは、リカバリーデータを送信する周期を長くし、
リカバリーデータのデータ量を減らす。また、画像の送
信レートを下げることができる。例えば、秒間８コマか
ら４コマに下げることにより、データ量を減らすことが
できる。

【００９９】中継サーバについて説明する。中継サーバ
は、図２に示すコンピュータと同様な構成を有する。た
だし、音源２８、ＭＩＤＩインターフェース３０は、必
ずしも必要でない。

【０１００】図１０は、図１に示す中継サーバ１２が有
するＲＡＭの構成を示す。複数の中継サーバ１２ａ，１
２ｂ，１２ｃは、それぞれＲＡＭに以下の情報を記憶す
る。

【０１０１】（１）現在のアクセス数５１ 現在のアクセス数５１は、自己の中継サーバに現在アク
セス中であるユーザの数（回線数）を示し、アクセス状
況に応じて変化する。アクセス数は、初期時には０であ
り、ユーザがアクセスを開始する度に増え、アクセスを
解除すれば減る。

【０１０２】（２）オーバーフローフラグ５２ オーバーフローフラグ５２は、当該中継サーバがオーバ
ーフローしたか否かを示すフラグである。初期時には、
オーバーフローフラグ５２は０に設定される。オーバー
フローフラグ５２が０であることは、オーバーフローし
ていないことを示す。当該中継サーバにアクセスするユ
ーザの数が後に示す許容アクセス数５４に達すると、オ
ーバーフローフラグ５２が１になる。

【０１０３】（３）現在の間引き係数５３ 現在の間引き係数５３は、現在設定されている間引き係
数を示す。間引き係数は、データを削減する（以下、間
引くともいう）割合や間引く方法を示す係数である。間
引き係数５３は、初期時には０に設定される。間引き係
数５３が０であることは、間引きを行わないことを示
す。表１に間引き係数の例を示す。

【０１０４】

【表１】 なお、上記の間引き係数を複合したものを、１つの間引
き係数としてもよい。

【０１０５】（４）許容アクセス数５４ 許容アクセス数５４は、当該中継サーバにアクセス可能
なユーザ数（回線数）の最大値を示し、任意の定数を設
定することができる。許容アクセス数５４は、当該中継
サーバの定員に相当する。

【０１０６】（５）許容間引き係数５５ 許容間引き係数５５は、当該中継サーバにおいて許容で
きる間引き係数の最大値を示す。例えば、間引き係数
は、間引く割合に相当し、係数が大きくなればなるほど
間引く割合が大きくなる。中継サーバ毎にアクセス数に
応じて、許容できる間引きの程度を決めることができ
る。

【０１０７】（６）テーブル番号５６ テーブル番号５６は、アクセス数と間引き係数を対応付
けるテーブルの番号を示す。図１１に、３種類のテーブ
ルを示す特性線６０ａ，６０ｂ，６０ｃの例を示す。テ
ーブルは、アクセス数と間引き係数を対応付けるもので
ある。アクセス数が多くなるに従って、データの削減量
が多くなることが好ましい。特性線６０は、線で表され
る連続値である必要はなく、離散値であってもよい。ま
た、間引き係数の大きさは、必ずしもデータ削減量を示
すものではないので、アクセス数が多くなるに従って、
必ずしも間引き係数が大きくなる必要なない。これらの
テーブルは、メモリに記憶される。

【０１０８】テーブルは複数用意されており（例えば、
３種類のテーブル６０ａ，６０ｂ，６０ｃ）、自己の中
継サーバに最適なテーブルの番号をテーブル番号５６と
する。

【０１０９】（７）次候補中継サーバアドレス５７ 次候補中継サーバアドレス５７は、当該中継サーバがオ
ーバーフローしたときに移行する他の中継サーバのアド
レスを示す。ユーザがある中継サーバにアクセスしたと
き、その中継サーバがオーバーフローしていれば、次候
補中継サーバアドレスが示す中継サーバに自動的に移行
する。

【０１１０】図１２は、ユーザが中継サーバにアクセス
したときに行う中継サーバの処理を示すフローチャート
である。

【０１１１】ステップＳＧ１において、ユーザ（クライ
アント）からのアクセスを検知したときにはステップＳ
Ｇ２以降の処理を行う。ユーザは、中継サーバにアクセ
スすることにより、楽音情報、音声情報又は画像情報を
得ることができる。

【０１１２】ステップＳＧ２では、オーバーフローフラ
グ５２（図１０）が０か１かをチェックする。オーバー
フローフラグが１であるときには、自己へのアクセス数
が許容アクセス数を超えているので、ステップＳＧ６へ
進む。

【０１１３】ステップＳＧ６では、次候補中継サーバア
ドレス５７（図１０）に従い、他の中継サーバへアドレ
スを移動させる。すなわち、ユーザのアクセスは、自動
的に他の中継サーバへ移される。ユーザは、結果として
当該他の中継サーバへアクセスすることになる。当該他
の中継サーバにおいてもオーバーフローしているときに
は、さらに他の中継サーバへ移される。このようにし
て、アクセスした中継サーバが混雑しているときには、
混雑していない他の中継サーバへ自動的に移される。中
継サーバは、他の中継サーバへ移行させた後に、処理を
終了する。

【０１１４】ステップＳＧ２においてオーバーフローフ
ラグが０であると判断されたときには、当該中継サーバ
へのアクセス数が許容アクセス数よりも少ないことを意
味するので、ステップＳＧ３へ進む。

【０１１５】ステップＳＧ３では、現在のアクセス数５
１（図１０）をインクリメントする。アクセス数５１
は、自己の中継サーバにアクセス中であるユーザの数を
示す。中継サーバは、ユーザからアクセスを許す度に、
アクセス数５１をインクリメントする。

【０１１６】次に、テーブル番号５６（図１０）が示す
テーブル（図１１）を用いて、上記のアクセス数５１に
対応する間引き係数を求め、現在の間引き係数５３とし
てメモリに書き込む。間引き係数が変化しない時は、書
き込みを省略してもよい。アクセス数が多くなると、間
引き率の大きい間引き係数が選ばれる。

【０１１７】ステップＳＧ４では、現在のアクセス数５
１が許容アクセス数５４（図１０）に達したか否かをチ
ェックする。達したときには、ステップＳＧ５へ進み、
オーバーフローフラグ５２に１をセットし、これ以上ア
クセス数を増やさないようにする。達していないときに
は、オーバーフローフラグを０のままにする。その後、
処理を終了する。

【０１１８】図１３は、ユーザが中継サーバへのアクセ
スを解除したときに行う中継サーバの処理を示すフロー
チャートである。

【０１１９】ステップＳＨ１において、ユーザ（クライ
アント）がアクセスを解除したことを検知したときには
ステップＳＨ２以降の処理を行う。

【０１２０】ステップＳＨ２では、現在のアクセス数５
１（図１０）をデクリメントする。中継サーバは、ユー
ザがアクセスを解除する度に、アクセス数５１をデクリ
メントする。

【０１２１】次に、テーブル番号５６（図１０）が示す
テーブル（図１１）を用いて、上記のアクセス数５１に
対応する間引き係数を求め、現在の間引き係数５３とし
てメモリに書き込む。間引き係数が変化しない時は、書
き込みを省略してもよい。アクセス数が減ると、間引き
率の少ない間引き係数へ変更することができる。

【０１２２】ステップＳＨ３では、オーバーフローフラ
グ５２（図１０）が０か１かをチェックする。オーバー
フローフラグが１であるときには、ステップＳＨ４へ進
み、オーバーフローフラグを０にセットし、新たなアク
セスを受け付け可能にする。オーバーフローフラグが０
であるときには、オーバーフローフラグを０のままにす
る。その後、処理を終了する。

【０１２３】なお、ステップＳＨ３においてオーバフロ
ーフラグをチェックせずに、オーバーフローフラグが０
であっても１であってもオーバーフローフラグを１にセ
ットしてもよい。この場合も、上記と同一の動作を行う
ことができる。

【０１２４】図１４は、中継サーバがメインサーバから
データを受信する際の中継サーバの処理を示すフローチ
ャートである。

【０１２５】ステップＳＩ１では、メインサーバ７（図
１）からデータをパケット形式で受信する。データは、
楽音情報（リカバリーデータを含む）と音声情報と画像
情報を含む。中継サーバは、間引きされていないデータ
を受信する。複数の中継サーバは、全て同一のデータを
受信する。

【０１２６】ステップＳＩ２では、現在の間引き係数５
３（図１０）を基に間引き方法（状態）を決定する。例
えば、間引き係数が０であれば、データの間引きを行わ
ない（表１）。

【０１２７】ステップＳＩ３では、決定した間引き方法
に応じ、受信パケットのデータ部４２（図４）から、所
定のデータを削除する。

【０１２８】ステップＳＩ４では、パケットヘッダ部４
１（図４）のチェックサム４３、データ長４７等を書き
換える。チェックサム４３及びデータ長４７等は、上記
所定のデータを削除した後のデータに対応するものに書
き換えられる。

【０１２９】処理を簡略化する場合には、パケット内の
シーケンスナンバー４５と時間４６は書き換えなくても
よい。逆に、データの質を高めたい場合には、シーケン
スナンバー４５及び時間４６を適正値に書き換えればよ
い。書き換えを行えば、データの欠落や入れ替え等の通
信エラーをより充分にリカバリーすることができる。

【０１３０】ステップＳＩ５では、ＷＷＷサーバ８（図
１）へ書き換えたパケットを転送する。ＷＷＷサーバ
は、所定の間引きが行われたデータを受信する。複数の
中継サーバは、同じデータをメインサーバ７から受信
し、各々異なる間引きを行い、ＷＷＷサーバ８へ転送す
ることができる。以上で、処理を終了する。

【０１３１】図１５は、中継サーバがリカバリーデータ
を間引く際の中継サーバの処理を示すフローチャートで
ある。

【０１３２】ステップＳＪ１では、メインサーバ７から
受信したパケットがリカバリーデータであるか否かをチ
ェックする。当該チェックは、データＩＤ４４（図４）
を参照することにより行う。データＩＤの値が１又は２
であればリカバリーデータである。このフローチャート
は、リカバリーデータの間引きを行うためのものである
ので、リカバリーデータ以外のデータを受信したときに
は、直ちに処理を終了する。リカバリーデータを受信し
たときには、ステップＳＪ２へ進む。

【０１３３】ステップＳＪ２では、レジスタｒｅｃｏｖ
ｅｒ＿ｔｉｍｅｒの値が、間引き係数が指定する時間よ
りも大きいか否かをチェックする。レジスタｒｅｃｏｖ
ｅｒ＿ｔｉｍｅｒは、前回のリカバリーデータを受信し
てからの経過時間を示す。間引き係数が指定する時間
は、リカバリーデータを送信する周期に相当する。

【０１３４】レジスタｒｅｃｏｖｅｒ＿ｔｉｍｅｒが、
間引き係数が指定する時間よりも大きくなっていたとき
には、ステップＳＪ３へ進む。

【０１３５】ステップＳＪ３では、当該受信したパケッ
トをそのままＷＷＷサーバ８へ転送する。ステップＳＪ
４では、レジスタｒｅｃｏｖｅｒ＿ｔｉｍｅｒに０をセ
ットし、処理を終了する。

【０１３６】レジスタｒｅｃｏｖｅｒ＿ｔｉｍｅｒは、
この後、割り込み処理により、所定時間間隔でカウント
アップされる。割り込み処理は、図２に示すタイマ２４
により所定時間間隔で処理の開始を指示される。

【０１３７】ステップＳＪ２においてレジスタｒｅｃｏ
ｖｅｒ＿ｔｉｍｅｒが、間引き係数が指定する時間より
も大きくなっていないときには、未だ所定時間を経過し
ていないことを意味するので、ステップＳＪ５へ進む。

【０１３８】ステップＳＪ５では、受信したパケットの
データ部を全て削除し、ヘッダ部のみを残す。ステップ
ＳＪ６では、上記のヘッダ部のみからなるパケットをＷ
ＷＷサーバ８へ転送し、処理を終了する。

【０１３９】なお、上記の処理でヘッダ部を転送する場
合を説明したが、パケットそのものを転送しないように
して、さらにデータ量を減らしてもよい。ただし、その
場合は、間引きによりパケットが削除されたのか、通信
エラーによりパケットが欠落したのかを判断する必要が
ある。通信エラーによりパケットが欠落したときにはデ
ータを回復させる必要があるが、間引きによりパケット
を削除したときにはデータを回復させる必要はない。

【０１４０】また、レジスタｒｅｃｏｖｅｒ＿ｔｉｍｅ
ｒの値を割り込み処理によりカウントアップする代わり
に、メインサーバからリカバリーデータを受信した回数
をカウントしてもよい。例えば、メインサーバからリカ
バリーデータを３回受信する際、１回目と２回目のデー
タはリカバリーデータを削除して転送し、３回目のデー
タはリカバリーデータを削除せずに転送する。この処理
によれば、レジスタｒｅｃｏｖｅｒ＿ｔｉｍｅｒの値を
割り込み処理によりカウントアップさせる必要がなくな
る。

【０１４１】図１６は、中継サーバがキーオフを優先的
に送信する際の中継サーバの処理を示すフローチャート
である。

【０１４２】ステップＳＫ１では、メインサーバから受
信したパケット中からキーオフデータを抽出し、ステッ
プＳＫ２へ進む。なお、パケットにキーオフデータが含
まれていないときには、受信したパケットをそのままＷ
ＷＷサーバへ転送する。

【０１４３】ステップＳＫ２では、抽出したキーオフデ
ータのみをデータ部としたパケットを新規に作成する。

【０１４４】ステップＳＫ３では、当該新規に作成した
パケットをＷＷＷサーバへ転送する。

【０１４５】ステップＳＫ４では、キーオフデータを削
除した受信パケットをＷＷＷサーバへ転送し、処理を終
了する。すなわち、パケット内のデータをキーオフデー
タとそれ以外のデータに分離し、まずステップＳＫ３で
キーオフデータを優先的に転送し、その後にステップＳ
Ｋ４でそれ以外のデータを転送する。

【０１４６】ステップＳＫ３で転送する時期に比べ、ス
テップＳＫ４で転送する時期を遅らせることにより、デ
ータを分散して転送することができるので、データをあ
る時期に集中して転送する場合に比べ回線の混雑を緩和
させることができる。

【０１４７】図１７は、中継サーバが画像データを削除
して転送する際の中継サーバの処理を示すフローチャー
トである。

【０１４８】ステップＳＬ１では、メインサーバから受
信したパケットが画像データであるか否かをチェックす
る。当該チェックは、データＩＤ４４（図４）を参照す
ることにより行う。データＩＤの値が３であれば画像デ
ータである。このフローチャートは、画像データを削除
するためのものであるので、画像データ以外のデータを
受信したときには、直ちに処理を終了する。画像データ
を受信したときには、ステップＳＬ２へ進む。

【０１４９】ステップＳＬ２では、受信したパケット内
のデータ部を全て削除し、ヘッダ部のみを残す。ステッ
プＳＬ３では、上記のヘッダ部のみからなるパケットを
ＷＷＷサーバ８へ転送し、処理を終了する。

【０１５０】この場合も、ヘッダ部のみを転送する代わ
りに、パケットそのものを転送しないようにして、さら
にデータ量を減らしてもよい。

【０１５１】図１８は、中継サーバがデータの分解能を
落として転送する際の中継サーバの処理を示すフローチ
ャートである。

【０１５２】ステップＳＭ１では、メインサーバから受
信したパケット中から間引き対象のデータを抽出し、ス
テップＳＭ２へ進む。対象データは、例えばボリュー
ム、ピッチベンド、アフタタッチ等のコントロールデー
タである。パケットに対象データが含まれていないとき
には、受信したパケットをそのままＷＷＷサーバ８へ転
送する。

【０１５３】ステップＳＭ２では、データを指定分解能
に応じた値に換算する。例えば、分解能を１／４にする
ときには、パケット内の同種類の対象データの全てを１
／４倍し、小数部を切り捨てた値に換算する。

【０１５４】ステップＳＭ３では、換算値が同じになっ
たものは１つのデータのみをパケット内に残し、他のも
のは削除し、ＷＷＷサーバへ転送する。

【０１５５】なお、対象データをモジュロ（ｍｏｄｕｌ
ｏ）演算して、演算結果が０のもののみを残し、他のも
のを削除するようにしてもよい。

【０１５６】また、対象データを複数設け、それぞれ個
別の分解能を指定できるようにしてもよい。

【０１５７】本実施例は、インターネットを用いること
により、演奏会場における演奏情報（ＭＩＤＩデー
タ）、音声データ（オーディオデータ）及び演奏映像
（画像データ）を、不特定多数のユーザに供給すること
ができる。ユーザは、演奏会場に赴かなくても、自宅に
いながらリアルタイムでＭＩＤＩデータ及び画像データ
を得ることができる。

【０１５８】複数の演奏会場において、各エンコーダが
ＭＩＤＩデータ等に共通の時間情報を付与すれば、複数
の会場間でのセッションが可能になる。

【０１５９】中継サーバを複数設け、それぞれの中継サ
ーバのアクセス数に応じて独自にデータを削減し、回線
の混雑を緩和させることができる。中継サーバの数を増
やせば、データの間引きを行わなくても回線の混雑を緩
和させることができるが、データの間引きを行えば中継
サーバの数が少なくても回線の混雑を緩和させることが
できる。

【０１６０】ただし、データを削減すると、音質又は画
質が低下するので、中継サーバは、独自に許容できるデ
ータ間引き率や間引き方法、及び自己にアクセス可能な
ユーザの数を設定することができる。

【０１６１】中継サーバは、データの間引き率や間引き
方法に関する情報をユーザに提供し、ホームコンピュー
タのディスプレイに表示させることができる。例えば、
「只今、音質を落としています。」、又は「只今、楽音
情報のみ提供しています。」等を表示させることができ
る。当該表示は、ユーザがアクセスした際に表示するこ
とが好ましい。ユーザは、当該表示を参考すれば、所望
の中継サーバにアクセスすることができる。

【０１６２】中継サーバは、インターネットにおけるミ
ラーサーバに類似するものであるが、ミラーサーバー
は、複数のものが全て同じ動作をし同じデータを供給す
る点で本実施例の中継サーバと異なる。

【０１６３】なお、本実施例は、インターネットに限定
されない。例えば、ＩＥＥＥ１３９４規格のデジタルシ
リアル通信や通信衛星等の他の通信にも適用することが
できる。

【０１６４】以上実施例に沿って本発明を説明したが、
本発明はこれらに制限されるものではない。例えば、種
々の変更、改良、組み合わせ等が可能なことは当業者に
自明であろう。

【０１６５】

【発明の効果】以上説明したように、本発明によれば、
アクセス中である回線数が多いときには、受信したデー
タを削減して送信することができるので、回線の混雑を
緩和させることができる。

【０１６６】また、一の通信装置で削減するデータと他
の通信装置で削減するデータとが異なるので、各通信装
置が送信するデータの質が異なる。ユーザは、アクセス
する通信装置を選択することにより、所望の質を有する
データを得ることができる。

【図面の簡単な説明】

【図１】 楽音情報の通信ネットワークを示す図であ
る。

【図２】 エンコーダ及びホームコンピュータのハード
ウエアの構成を示す図である。

【図３】 ＭＩＤＩデータの通信エラー対策の方法を示
す図である。

【図４】 通信パケットのフォーマットを示す図であ
る。

【図５】 エンコーダが行う送信処理を示すフローチャ
ートである。

【図６】 エンコーダが行う割り込み処理を示すフロー
チャートである。図６（Ａ）はリカバリーキーデータの
送信処理を示すフローチャートであり、図６（Ｂ）はリ
カバリー音源設定情報の送信処理を示すフローチャート
である。

【図７】 ホームコンピュータが行う受信処理を示すフ
ローチャートである。

【図８】 図７のステップＳＤ６に示すイベント処理の
詳細を示すフローチャートである。

【図９】 ホームコンピュータが行う割り込み処理を示
すフローチャートである。

【図１０】 中継サーバ内のメモリの構成を示す図であ
る。

【図１１】 アクセス数と間引き係数の関係を示すグラ
フである。

【図１２】 ユーザが中継サーバにアクセスしたときに
行う中継サーバの処理を示すフローチャートである。

【図１３】 ユーザが中継サーバへのアクセスを解除し
たときに行う中継サーバの処理を示すフローチャートで
ある。

【図１４】 中継サーバがメインサーバからデータを受
信する際の中継サーバの処理を示すフローチャートであ
る。

【図１５】 中継サーバがリカバリーデータを間引く際
の中継サーバの処理を示すフローチャートである。

【図１６】 中継サーバがキーオフを優先的に送信する
際の中継サーバの処理を示すフローチャートである。

【図１７】 中継サーバが画像データを削除して転送す
る際の中継サーバの処理を示すフローチャートである。

【図１８】 中継サーバがデータの分解能を落として転
送する際の中継サーバの処理を示すフローチャートであ
る。

【符号の説明】

１ 演奏会場、 ２ ＭＩＤＩ楽器、 ３，５ エ
ンコーダ、 ４ カメラ、 ６ ルータ、 ７
メインサーバ、 ８ ＷＷＷサーバ、 ９ホームコ
ンピュータ、 １０ ＭＩＤＩ音源、 １１ 音声
出力装置、１２ 中継サーバ、 ２１ ＲＡＭ、
２１ａ キーオンバッファ、２１ｂ 音源設定情報バッ
ファ、 ２２ ＲＯＭ、 ２３ ＣＰＵ、 ２４
タイマ、 ２５ 外部記憶装置、 ２６ 入力装
置、 ２７ 表示器、 ２８ 音源、 ２９ イ
ンターネット用インターフェース、 ３０ＭＩＤＩイ
ンターフェース、 ３１ バス、 ４１ ヘッダ
部、 ４２データ部、 ４３ チェックサム、
４４ データＩＤ、 ４５ シーケンスナンバー、
４６ 時間情報、 ４７ イベントデータ長、
４８ＭＩＤＩデータ又は画像データ、 ５１ 現在の
アクセス数、 ５２ オーバーフローフラグ、 ５
３ 現在の間引き係数、 ５４ 許容アクセス数、５
５ 許容間引き係数、 ５６ テーブル番号、 ５
７ 次候補中継サーバアドレス

───────────────────────────────────────────────────── フロントページの続き (56)参考文献 特開 平４−316294（ＪＰ，Ａ) 特開 平６−44155（ＪＰ，Ａ) 特開 平６−351006（ＪＰ，Ａ) 特開 平７−123132（ＪＰ，Ａ) 特開 平７−152668（ＪＰ，Ａ) 特開 平８−289251（ＪＰ，Ａ) 特開 平９−244979（ＪＰ，Ａ) 特開 平10−257124（ＪＰ，Ａ) (58)調査した分野(Int.Cl.⁷，ＤＢ名) G10H 1/00 - 7/12 G06F 13/00 - 13/42

Claims (21)

(57)【特許請求の範囲】
1. 【請求項１】 少なくともＭＩＤＩデータを含むデータ
   を受信する受信手段と、 外部から自己にアクセス中である回線数を認識するアク
   セス数認識手段と、 前記回線数に応じて前記受信手段が受信したデータのう
   ち特定のデータに対して、データの分離、データの差別
   化、データの分解能操作、時間の分解能操作のいずれか
   又はこれらの組み合わせによりデータを削減してアクセ
   ス中の回線に送信する送信手段とを有するデータの通信
   装置。
2. 【請求項２】 各々が受信手段と送信手段を有する複数
   の通信装置を含む通信システムであって、 該複数の通信装置において該受信手段はそれぞれ同一の
   データを受信する手段であり、 該複数の通信装置において該送信手段はそれぞれ該受信
   手段が受信したデータを削減して送信することができる
   手段であり、 一の通信装置で削減するデータと他の通信装置で削減す
   るデータとが異なる通信システム。
3. 【請求項３】 各々が受信手段とアクセス数認識手段と
   送信手段を有する複数の通信装置を含む通信システムで
   あって、 該複数の通信装置において該受信手段はそれぞれ同一の
   データを受信する手段であり、 該アクセス数認識手段は外部から自己の通信装置にアク
   セス中である回線数を認識する手段であり、 該複数の通信装置において該送信手段はそれぞれ該回線
   数に応じて該受信手段が受信したデータを削減してアク
   セス中の回線に送信する手段であり、 一の通信装置で削減するデータと他の通信装置で削減す
   るデータとが異なる通信システム。
4. 【請求項４】 前記一の通信装置の送信手段が削減する
   データの対象又は割合が前記他の通信装置の送信手段が
   削除するものとは異なる請求項３記載の通信システム。
5. 【請求項５】 前記複数の通信装置の送信手段は、さら
   にそれぞれデータの削減に関する情報をも送信すること
   ができる請求項３又は４記載の通信システム。
6. 【請求項６】 さらに、各通信装置は、前記アクセス中
   である回線数が所定数より少ないときには新たなアクセ
   スを受け付け、該アクセス中である回線数が所定数以上
   であるときには新たなアクセスを他の通信装置に移す移
   行手段を有する請求項３〜５のいずれか１項に記載の通
   信システム。
7. 【請求項７】 前記各通信装置の受信手段が受信するデ
   ータは、少なくともＭＩＤＩデータを含む請求項３〜６
   のいずれか１項に記載の通信システム。
8. 【請求項８】 ａ）少なくともＭＩＤＩデータを含むデ
   ータを受信する工程と、 ｂ）外部から自己にアクセス中である回線数を認識する
   工程と、 ｃ）前記回線数に応じて前記受信したデータのうち特定
   のデータに対して、データの分離、データの差別化、デ
   ータの分解能操作、時間の分解能操作のいずれか又はこ
   れらの組み合わせによりデータを削減してアクセス中の
   回線に送信する工程とを含むデータの通信方法。
9. 【請求項９】 ａ）複数の通信装置が同一のデータを受
   信する工程と、 ｂ）前記複数の通信装置中の一の通信装置と他の通信装
   置とで該受信したデータ中から異なるデータを削減して
   送信する工程とを含むデータの通信方法。
10. 【請求項１０】 ａ）複数の通信装置が同一のデータを
    受信する工程と、 ｂ）前記複数の通信装置がそれぞれ外部から自己にアク
    セス中である回線数を認識する工程と、 ｃ）前記複数の通信装置がそれぞれ前記回線数に応じて
    前記受信したデータを削減してアクセス中の回線に送信
    する工程であって、該複数の通信装置中の一の通信装置
    と他の通信装置とで該受信したデータ中から異なるデー
    タを削減して送信する工程とを含むデータの通信方法。
11. 【請求項１１】 前記工程ｃ）は、一の通信装置で削減
    するデータの対象又は割合が他の通信装置のものとは異
    なる請求項１０記載のデータの通信方法。
12. 【請求項１２】 前記工程ｃ）は、さらにデータの削減
    に関する情報をも送信する請求項１０又は１１記載のデ
    ータの通信方法。
13. 【請求項１３】 さらに、ｄ）前記複数の通信装置が、
    それぞれ前記アクセス中である回線数が所定数より少な
    いときには新たなアクセスを受け付け、該アクセス中で
    ある回線数が所定数以上であるときには新たなアクセス
    を他の通信装置に移す工程を含む請求項１０〜１２のい
    ずれか１項に記載のデータの通信方法。
14. 【請求項１４】 前記工程ａ）は、少なくともＭＩＤＩ
    データを含むデータを受信する請求項１０〜１３のいず
    れか１項に記載のデータの通信方法。
15. 【請求項１５】 ａ）少なくともＭＩＤＩデータを含む
    データを受信する手順と、 ｂ）外部から自己にアクセス中である回線数を認識する
    手順と、 ｃ）前記回線数に応じて前記受信したデータのうち特定
    のデータに対して、データの分離、データの差別化、デ
    ータの分解能操作、時間の分解能操作のいずれか又はこ
    れらの組み合わせによりデータを削減してアクセス中の
    回線に送信する手順とをコンピュータに実行させるため
    のプログラムを記録した媒体。
16. 【請求項１６】 ａ）複数の通信装置が同一のデータを
    受信する手順と、 ｂ）前記複数の通信装置中の一の通信装置と他の通信装
    置とで該受信したデータ中から異なるデータを削減して
    送信する手順とをコンピュータに実行させるためのプロ
    グラムを記録した媒体。
17. 【請求項１７】 ａ）複数の通信装置が同一のデータを
    受信する手順と、 ｂ）前記複数の通信装置がそれぞれ外部から自己にアク
    セス中である回線数を認識する手順と、 ｃ）前記複数の通信装置がそれぞれ前記回線数に応じて
    前記受信したデータを削減してアクセス中の回線に送信
    する手順であって、該複数の通信装置中の一の通信装置
    と他の通信装置とで該受信したデータ中から異なるデー
    タを削減して送信する手順とをコンピュータに実行させ
    るためのプログラムを記録した媒体。
18. 【請求項１８】 前記手順ｃ）は、一の通信装置で削減
    するデータの対象又は割合が他の通信装置のものとは異
    なる請求項１７記載のプログラムを記録した媒体。
19. 【請求項１９】 前記手順ｃ）は、さらにデータの削減
    に関する情報をも送信する請求項１７又は１８記載のプ
    ログラムを記録した媒体。
20. 【請求項２０】 さらに、ｄ）前記複数の通信装置が、
    それぞれ前記アクセス中である回線数が所定数より少な
    いときには新たなアクセスを受け付け、該アクセス中で
    ある回線数が所定数以上であるときには新たなアクセス
    を他の通信装置に移す手順を含む請求項１７〜１９のい
    ずれか１項に記載のプログラムを記録した媒体。
21. 【請求項２１】 前記手順ａ）は、少なくともＭＩＤＩ
    データを含むデータを受信する請求項１７〜２０のいず
    れか１項に記載のプログラムを記録した媒体。