JP3671274B2 - 音楽情報送受信装置、受信装置及び記憶媒体 - Google Patents

Description

【０００１】
【発明の属する技術分野】
本発明は、音楽情報の送受信により受信側で楽音を発音させて演奏を行わせるための技術に関する。
【０００２】
【従来の技術および発明が解決しようとする課題】
現在では、ＭＩＤＩ（Musical Instrument Digital Interface）が普及したこともあって、音楽情報を送信し、受信側で楽音を発音させることが広く行われている。このことから、電子楽器や音源装置、或いはシンセサイザ等の楽音発生装置には、音楽情報送受信装置（或いは、音楽情報送信装置、及び音楽情報受信装置の一方）が幅広く搭載されている。
【０００３】
上記音楽情報には、様々な種類がある。送信側と受信側とで実際にやりとりされる音楽情報の多くは、ノートオンやノートオフといったイベントのデータであり、そのデータ量は２、３バイトと比較的に小さい。しかし、楽音の波形データのように、大量のデータを１音楽情報として送信することもある。
【０００４】
そのようなデータを音楽情報として送信する場合、送信を開始してから終了するまでにかかる送信時間が長くなる。その送信時間は、エラーの発生や送信経路の状況等の理由によって変動する。このため、波形データを送信して直ちに再生させるような場合、その送信時間によって再生を開始するタイミング（発音開始タイミング）が変化するという問題点があった。
【０００５】
演奏（楽音の発音タイミング等）のズレは、その演奏から受ける印象を大きく変化させることが多く、音楽的な影響が大きい。そのため、従来は、波形データを前もって送信しておき、その波形データの再生を指示するコマンドを必要に応じて送信するといったように、波形データの使用方法には実質的に大きな制限があった。このことから、波形データをより有効に使用できるようにすることが強く要請されていた。
【０００６】
ところで、ＭＩＤＩの普及は、楽器の演奏スタイルや音楽制作方法、音楽のスタイルをも変化させている。楽音発生装置の利用方法の幅を広げて、これまでになかった音楽の楽しみ方を提供している。その利用方法の幅をより広げて、ユーザにとっての利便性を更に向上させるという要請も継続して存在していた。
【０００７】
本発明の第１の課題は、音楽的な不具合の発生を回避しつつ、送受信される波形データの使用方法をより広げることにある。
また、本発明の第２の課題は、音楽情報の送受信を通して楽音発生装置の利用方法の幅をより広げることにある。
【０００８】
なお、本発明の参考技術文献としては、特願平１０−１０２４９４号が挙げられる。
【０００９】
【課題を解決するための手段】
本発明の音楽情報送受信装置は、時間データの付加された音楽情報を送信可能な演奏装置、及び受信された音楽情報に基づいて再生を行う受信装置に接続され、時間データが付加された音楽情報を記憶する記憶手段と、現時刻をカウントする現時刻カウント手段と、演奏時刻をカウントする演奏時刻カウント手段と、記憶手段に記憶されている音楽情報を、当該音楽情報に付加された時間データと現時刻カウント手段でカウントされた現時刻とに基づいて決定されるタイミングで演奏装置に送信する第１の送信手段と、演奏装置から送信された時間データの付加された音楽情報を受信する受信手段と、受信手段にて受信された音楽情報を受信装置に送信する第２の送信手段と、受信手段により最初に受信された音楽情報に付加された時間データに基づいて、演奏時刻カウント手段でカウントされる演奏時刻を変更する変更手段と、記憶手段に記憶されている音楽情報を、当該音楽情報に付加された時間データと変更手段で変更された演奏時刻とに基づいて決定されるタイミングでかつ当該演奏時刻を付加して前記受信装置に送信する第 3 の送信手段と、を具備する。
【００１３】
また本発明の記録媒体は、時間データの付加された音楽情報を送信可能な演奏装置、及び受信された音楽情報に基づいて再生を行う受信装置に接続された送受信装置に適用されるプログラムを記憶した記憶媒体であって、現時刻をカウントするステップと、演奏時刻をカウントするステップと、記憶手段に記憶されている時間データが付加された音楽情報を、当該音楽情報に付加された時間データとカウントされた現時刻とに基づいて決定されるタイミングで演奏装置に送信するステップと、演奏装置から送信された時間データの付加された音楽情報を受信するステップと、受信された音楽情報を受信装置に送信するステップと、最初に受信された音楽情報に付加された時間データに基づいて、カウントされた演奏時刻を変更するステップと、記憶手段に記憶されている音楽情報を、当該音楽情報に付加された時間データと前記変更された演奏時刻とに基づいて決定されるタイミングでかつ当該演奏時刻を付加して前記受信装置に送信するステップと、を有するプログラムを記録している。
【００２６】
本発明では、例えばパート別に音楽情報を分けて送信するといったように、複数の外部装置に送信する音楽情報の内容を外部装置単位で異ならせつつ、音楽情報をそれが有する時間データで指定されるタイミングに基づいて送信する。そのように、音楽情報の内容を異ならせられるようにすることにより、装置を使用するうえでの選択の幅が広がって利便性が向上し、ユーザは音楽情報を受信させる各装置をより所望する形で使用することが可能となる。
【００２８】
【発明の実施の形態】
以下、図面を参照しながら、本発明の実施の形態につき詳細に説明する。
＜第１の実施の形態＞
図１は、第１の実施の形態による音楽情報送受信装置を搭載した楽音発生装置の回路構成図である。
【００２９】
その楽音発生装置１００は、図１に示すように、装置１００全体の制御を行うＣＰＵ１０１と、時間を計時するタイマ（ＴＩＭＥＲ）１０２と、プログラムや演奏データ、及び各種制御用データ等を格納したＲＯＭ１０３と、ＣＰＵ１０１が作業用に用いるＲＡＭ１０４と、画面上に表示するカーソルの位置を指示するカーソルポインタ１０５と、そのポインタ１０５が指示する位置にカーソルを表示する液晶表示器１０６と、所定の送信経路を介して外部装置から送信された音楽情報を受信する受信器１０７と、その送信経路を介して外部装置に音楽情報を送信する送信器１０８と、ＣＰＵ１０１から送られたデジタルの波形データをＤ／Ａ変換するＤＡコンバータ１０９と、そのコンバータ１０９が出力したアナログの波形信号を音声に変換して出力するスピーカ１１０と、周囲の音を集音してアナログの音声信号を出力するマイク１１１と、そのマイク１１１が出力した音声信号をデジタルの波形データに変換するＡＤコンバータ１１２と、音源装置１２０にＣＰＵ１０１から受け取ったＭＩＤＩデータを出力するＭＩＤＩ ＯＵＴ端子１１３と、鍵盤装置（キーボード）１３０から出力されたＭＩＤＩデータを入力するＭＩＤＩ ＩＮ端子１１４と、各種スイッチを有するスイッチ群１１５と、を備えて構成されている。
【００３０】
上記送信経路は、例えば、ＬＡＮやＷＡＮ、或いは公衆網等のネットワークである。本実施の形態による音楽情報送受信装置は、上述した構成を有する楽音発生装置１００において、ＭＩＤＩ ＩＮ端子１１４、及びＭＩＤＩ ＯＵＴ端子１１３を介して外部装置との間でＭＩＤＩデータの送受信を行う一方、受信器１０７、及び送信器１０８を介してネットワークに接続されたノード（装置）との間で音楽情報の送受信を行う装置として実現されている。
【００３１】
ここでは、便宜的に、受信器１０７、及び送信器１０８は送信経路としてＬＡＮを介して他の装置とデータの受信、或いは送信を行うことを前提とすることにする。その前提では、受信器１０７と送信器１０８は一つの装置として存在することになるが、データの受信と送信の区別を明確にするために、それらの用語はそのまま用いることにする。ＬＡＮを介してデータを送受信する方法には、幾つかあるが、便宜的に、ここでは特に図示しないサーバを介してデータを送受信することを前提とすることにする。
【００３２】
なお、ＭＩＤＩ ＯＵＴ端子１１３、或いはＭＩＤＩ ＩＮ端子１１４に接続させる外部装置は、音源装置１２０、或いは鍵盤装置１３０に限定されるものではない。自動演奏装置や電子楽器、或いはコントローラ等のＭＩＤＩ端子を有する装置と任意に接続させることができる。
【００３３】
上記の構成において、その動作を説明する。
不図示の電源がオンされると、ＣＰＵ１０１はＲＯＭ１０３に格納されたプログラムを読み出して実行することにより、装置１００全体の制御を開始する。このとき、例えばタイマ１０２を起動させて、時間の計時を開始させる。その後は、ＲＡＭ１０４を作業用に使用しながら、スイッチ群１１５、ＭＩＤＩ ＩＮ端子１１５（鍵盤装置１３０）、ＡＤコンバータ１１２、及び受信器１０７の各入力装置により得られた情報に応じた制御を行う。
【００３４】
スイッチ群１１５は、特に詳細な説明は省略するが、例えば液晶表示器１０６に表示させる情報の種類や音色、或いは送信先等を指定できるようにするためのスイッチ（以降、種類選択スイッチと呼ぶ）、送信先や音色、液晶表示器１０６に楽譜として表示させる曲等を指定するための複数のボタン（以降、便宜的に汎用ボタン群と呼ぶ）等の各種スイッチと、それらの操作状態を検出する検出回路と、から構成されたものである。その検出回路は、例えば、ＣＰＵ１０１の指示に従ってそれらのスイッチの走査（スキャン）を行い、その走査結果を操作情報としてＣＰＵ１０１に送出する。
【００３５】
ＣＰＵ１０１は、スイッチ群１１５から送られた操作情報の解析を行い、ユーザが操作したスイッチ、及びその操作内容を特定する。それにより、ユーザの指示内容を認識し、その認識結果に応じて各種の設定を行い、その設定に従って装置１００全体の制御を行う。例えば楽譜の表示を指示された場合には、その画像データをＲＯＭ１０３から読み出し、それを液晶表示器１０６が備えたＶＲＡＭ（図示せず）に転送することにより、液晶表示器１０６にユーザが指定した楽譜を表示させる。種類選択スイッチで送信先の指定を選択した後、汎用ボタン群をユーザが操作した場合には、汎用ボタン群への操作に応じて送信先を設定する。なお、各種の設定は、通常、その種類別に用意した変数の値を書き換えることで行われる。
【００３６】
鍵盤装置１３０は、搭載された鍵盤や各種スイッチに対してユーザが行った操作内容を、ＭＩＤＩデータの形で出力する。ＣＰＵ１０１は、ＭＩＤＩ ＩＮ端子１１４を介してそのＭＩＤＩデータを受け取ると、それをＭＩＤＩ ＯＵＴ端子１１３に出力することにより、音源装置１２０に楽音の発音、或いは消音を行わせる。音楽情報の送信先が指定されている場合には、ＭＩＤＩ ＩＮ端子１１４を介して受信したＭＩＤＩデータに、ＭＩＤＩデータを送信することを表す識別子、及びそれを処理すべきタイミングを表す時間データを付加して送信器１０８から音楽情報として送信する。その時間データは、例えばタイマ１０２の値を参照して更新する変数（現在時刻レジスタ）の値である。
【００３７】
特に図示しないジャック等の端子にマイク１１１が接続されている場合、ＡＤコンバータ１１２はマイク１１１から出力される音声信号をサンプリングして、デジタルの波形データを出力する。
【００３８】
ＣＰＵ１０１は、ＡＤコンバータ１１２から受け取った波形データをＤＡコンバータ１０９に出力する。それにより、マイク１１１が集音した音をリアルタイムでスピーカ１１０から発音させる。送信先が指定されている場合には、その波形データを格納する２つの領域をＲＡＭ１０４に確保して、それらの領域に波形データを交互に格納（ＰＣＭ録音）しつつ、そのうちの一方に格納した波形データを順次、送信器１０８から音楽情報として送信する。波形データを送信することを表す識別子は、それを送信する際に付加する。
【００３９】
本実施の形態では、上述したようにして、波形データは確保した領域の容量を単位として分割し送信している。これは、波形データの送信を間欠的にし、その送信間隔の間に他の音楽情報（例えばＭＩＤＩデータ）の送信を行えるようにするためである。言い換えれば、どのような送信経路を用いたとしても、異なる種類の音楽情報を並行して送信できるようにするためである。
【００４０】
なお、波形データの格納（及び送信）用に確保した２つの領域については、以降、便宜的に波形バッファＡ、波形バッファＢと呼ぶことにする。それらを明確に区別する必要がないときには、単に波形バッファと呼ぶことにする。本実施の形態では、波形バッファの容量を２５６バイトとしている。
【００４１】
その波形バッファの容量単位で波形データを送信する度に、その再生を指示するコマンド（以降、再生指示コマンドと呼ぶ）を送信する。受信側が波形データを正常に受信できていない場合、結果としてノイズを再生してしまう恐れがある。このことから、そのコマンドには、それまでに送信したデータ量が正常に受信できたか否かを受信側が判別するためのデータを付加して送信している。更には、その再生を開始すべきタイミングを表す時間データを付加している。それらのデータを付加して、送信器１０８から音楽情報として送信している。なお、その時間データは、例えばタイマ１０２の値を基に更新する変数（録音時刻レジスタ）の値である。
【００４２】
再生指示コマンドに時間データを付加して波形データを再生するタイミングを送信先に指定することにより、たとえ波形データ毎に送信時間が変動しても、受信側でその変動を吸収することができる。それにより、送信時間に変動が生じる送信路を用いても波形データを受信側がより適切なタイミングで再生することができることから、送信路や状況等による音楽的な不具合の発生が回避され、波形データを演奏に適切に用いることができる。従って、波形データの使用方法の幅も広がることになる。
【００４３】
ところで、波形データを送信する場合、受信側が発音できる音の制限がなくなり、様々な音を鳴らせるようになる。このため、音楽表現の幅が広がり、新しい音楽スタイルの創造にも寄与することができるという効果もある。
【００４４】
ここで、上述したようにして送信される音楽情報のデータ構成について説明する。ここでは、便宜的に、音楽情報として、ＭＩＤＩデータ、波形データ、再生指示コマンド、楽譜の画像（ビットマップ）データ、及びその楽譜上における演奏位置を示すポイントデータ、の計４種類の音楽情報を送信するものとして説明することにする。
【００４５】
上記ＭＩＤＩデータは、例えばエクスクルーシブ・メッセージを除いたものである。そのメッセージを除くＭＩＤＩデータは、１〜３バイトの可変長のデータである。しかし、本実施の形態では、処理を簡単にするため、ＭＩＤＩデータを４バイトの固定長のデータとして扱っている。それに付加する時間データは、例えば時間をｍｓ単位で表す４バイトのデータとしている。従って、ＭＩＤＩデータを音楽情報として送信する場合、そのデータ量は計８バイトとなる。
【００４６】
それ以外のデータを音楽情報として送信する場合、上記ＭＩＤＩデータと時間データの替わりに各々１バイトが割り当てられる。それら（計２バイトのデータ）は、音楽情報の種類を表す識別子（送信先に対するコマンドに相当する）を格納するためのものである。その識別子の内容を（１バイト目の値，２バイト目の値）の形で表現すると、（０，０）は波形データを表し、（１，０）は再生指示コマンド、（２，０）は画像データ、（３，０）はポイントデータをそれぞれ表している。これらの識別子が付加される音楽情報のデータ構成は、以下のようになっている。
【００４７】
先ず、識別子（０，０）が割り当てられた波形データでは、その識別子に、４バイトを割り当てた波形データのバイト数を表すデータ、同じく４バイトを割り当てた波形データのシリアル番号を表すデータ、が続き、その後に波形データが付加される。ここでは、音楽情報を構成するデータの単位（識別子や波形データのバイト数を表すデータ等）をワードと呼ぶことにする。
【００４８】
識別子（１，０）が割り当てられた再生指示コマンドでは、その識別子自体が再生指示コマンドを表している。そのコマンドを兼ねた識別子に、４バイトを割り当てた波形データの総バイト数を表すデータ、同じく４バイトを割り当てた再生のタイミングを指定する時間データが付加される。２番目のワードが、それまでも含めて波形データが正常に受信できたか否かを送信先が判別するためのデータである。
【００４９】
識別子（２，０）が割り当てられた画像データでは、その識別子に、その画像データが付加される。時間データは付加しない。これは、画像データとして楽譜を送信することを想定しており、その楽譜は演奏が始まる前に送信しておく必要があるためである。
【００５０】
識別子（３，０）が割り当てられたポイントデータでは、その識別子に、４バイトを割り当てたＸ座標上の位置を指定するＸ座標データ、同じく４バイトを割り当てたＹ座標上の位置を指定するＹ座標データが付加される。ここでも、時間データは付加しない。これは、楽音の発音と比較して、画像データの表示の切り換え等に要求される時間的精度は低いためである。
【００５１】
ＣＰＵ１０１は、音楽情報を、上記した形式で送信器１０８から送信させる。そのような音楽情報は、他のノードで楽音発生装置１００が送信先として指定された場合、受信器１０７によって受信される。
【００５２】
なお、音楽情報は、実際には、送信先や送信元等の各種送信に係わる制御データが格納されたヘッダが付加して送信される。その送信された音楽情報は、サーバに保持される。その音楽情報の送信先は、サーバに自分宛に送信されたデータがあるか否かを確認する問い合わせを行う。それによって新たに送信されたデータがあることが判明した場合に、サーバからダウンロードすることで取得する。このように、音楽情報はサーバを介してやりとりされる。
【００５３】
受信器１０７は、音楽情報を受信すると、その旨をＣＰＵ１０１に通知した後、受信した音楽情報をＣＰＵ１０１に送る。
ＣＰＵ１０１は、音楽情報を受信器１０７から受け取ると、その先頭に位置する２バイトの値から音楽情報の種類を判別する。その後は、以下のように、判別結果に従って音楽情報の処理を行う。
【００５４】
なお、ＭＩＤＩデータの場合、１バイト目のデータの値はＦ０Ｈ（Ｈは１６進数での表現であることを表す）以上であり、識別子は２バイトのデータである。このことから明らかなように、先頭の２バイトの値から音楽情報の種類を判別することができる。
【００５５】
音楽情報がＭＩＤＩデータと判別した場合、ＣＰＵ１０１は、そのＭＩＤＩデータを、それに付加された時間データで指定されるタイミングでＭＩＤＩ ＯＵＴ端子を介して音源装置１２０に送出する。
【００５６】
波形データを送信する場合と同様に、受信した波形データを格納する２つの領域をＲＡＭ１０４に確保する。音楽情報が波形データと判別した場合には、それらの領域に、波形データを受信する度に交互に切り替えながらそれを格納する。その一方では、それまでに受信した波形データの総バイト数を算出し、その算出結果を変数ＨＳＳＲに代入する。なお、それらの領域については、以降、受信波形バッファＡ、受信波形バッファＢと呼ぶことにする。それらを区別する必要がないときには、単に受信波形バッファと呼ぶことにする。本実施の形態では、受信波形バッファの容量を波形バッファと同じく、２５６バイトとしている。
【００５７】
音楽情報が再生指示コマンドと判別した場合には、その音楽情報中で先頭から２番目のワードの値と上記変数ＨＳＳＲの値とを比較し、それらが一致するか否か判定する。それまでに送信された波形データを正常に受信していたときには、それらの値は一致する。このことから、それらの値が一致していれば、音楽情報中の時間データで指定されるタイミングとなるのを待って、受信波形バッファに格納した波形データの再生を開始する。反対に一致していなければ、波形データの受信にエラーが発生しているとして、波形データの再生を終了する。それにより、演奏を損なわせる音の再生を回避する。なお、波形データの再生は、ＣＰＵ１０１が、受信波形バッファから１サンプリング分の波形データを、サンプリング周期毎に順次読み出してＤＡコンバータ１０９に送出することで行われる。
【００５８】
音楽情報が画像データと判別した場合には、そのことを示す識別子に続く画像データを液晶表示器１０６が備えたＶＲＡＭ（図示せず）に格納する。カーソルポインタ１０５には、画像データを先頭から表示することを示す初期値を設定する。それにより、液晶表示器１０６の画面上に、画像データとして送られた楽譜の先頭部分を表示させる。
【００５９】
特に詳細な説明は省略するが、その画像データは、ＲＯＭ１０３に複数格納されており、スイッチ群１１５を介してユーザが選択するようになっている。それにより、ＣＰＵ１０１は、ユーザが選択した画像データを音楽情報として送信する。
【００６０】
上記カーソルポインタ１０５は、カーソル（図示せず）の表示位置をＸＹ座標上の位置で指定する。Ｘ座標上の位置を示す値を格納したレジスタをカーソルＸレジスタ、Ｙ座標上の位置を示す値を格納したレジスタをカーソルＹレジスタと呼ぶことにすると、それらの値を、演奏の進行に応じて更新する。その更新は、例えば、液晶表示器１０６に表示された楽譜（演奏データ）の内容、タイマ１０２が計時した時間、設定されているテンポ値等を基に行う。それにより、演奏の進行に合わせて、カーソルを表示させる楽譜上の位置を移動させ、楽譜の表示内容を更新（例えばスクロール）させる。なお、上記のレジスタは、当然のことながら、変数であっても良い。
【００６１】
音楽情報として画像データを受信した場合には、ＣＰＵ１０１は、ポイントデータと判別される音楽情報が受信される度に、音楽情報中の２ワード目のデータをカーソルＸレジスタに格納し、３ワード目のデータをカーソルＹレジスタに格納する。それにより、液晶表示器１０６の画面上に表示させたカーソルの位置を、受信されたポイントデータが指定する位置に移動させる。
【００６２】
次に、上述した制御を行うＣＰＵ１０１の動作について、図２〜図１２に示す各種動作フローチャートを参照して詳細に説明する。本発明は音楽情報の送受信に特に係わるものであることから、ここでは、理解を容易にするために、音楽情報の送信、及びそれの受信に着目して説明することにする。
【００６３】
図２は、音楽情報送信処理の動作フローチャートである。音楽情報の送信に着目して、その処理の流れを抜粋して示したものである。ここでは、便宜的に、音楽情報として、波形データ、画像データ（楽譜）、及びポイントデータを送信することを前提としている。始めに、図２、更には図３、及び図４を参照して、音楽情報を送信する際のＣＰＵ１０１の動作について詳細に説明する。
【００６４】
なお、図２に示す音楽情報送信処理（図３及び図４のそのサブルーチン処理を含む）は、ユーザがスイッチ群１１５を操作して送信先を指定した場合に、ＣＰＵ１０１がＲＯＭ１０３に格納されているプログラムを実行することで実現される。
【００６５】
先ず、ステップ２０１では、変数ＦＸ、及びＦＹにそれぞれ０を代入する。続くステップ２０２では、変数Ｘ、Ｙにそれぞれ０を代入する。それが終了した後、ステップ２０３に移行する。
【００６６】
上記変数ＦＸ、及びＦＹは、カーソルの表示位置をＣＰＵ１０１が管理するための変数である。変数Ｘ、及びＹは、それらの変数ＦＸ、ＦＹを更新する作業を行うために用いられる変数である。
【００６７】
ステップ２０３では、２バイトの定数（２，０）（２は１バイト目の値、０は２バイト目の値である。以降、同様）を送信させる。その定数（２，０）は、音楽情報として画像データ（本実施の形態では楽譜のビットマップデータ）を送信することを表す識別子である。
【００６８】
ステップ２０３に続くステップ２０４では、ユーザがスイッチ群１１５を介して選択した画像データをＲＯＭ１０３から読み出し、それを送信器１０８に送って送信させる。次のステップ２０５では、その画像データの送信が終了したか否か判定する。その送信が終了していない場合、判定はＮＯとなり、ステップ２０４に戻って送信を継続して行わせる。そうでない場合には、判定はＹＥＳとなってステップ２０６に移行する。
【００６９】
このようにして、ステップ２０１〜２０５では、カーソルの表示位置の初期設定に係わる処理、及び画像データの送信に係わる処理が行われる。なお、本実施の形態では、ステップ２０４で送信する画像データを液晶表示器１０６のＶＲＡＭに転送して、その画面上に楽譜を表示するようにしている。これは、その楽譜を見て行ったユーザの演奏内容を音楽情報として送信することを想定しているためである。
【００７０】
ステップ２０６では、分割して送信する波形データの送信回数をカウントするための変数ＳＣに０を代入する。続くステップ２０７では、送信した波形データの総バイト数を保持しておくための変数ＢＣに０を代入する。それが終了すると、ステップ２０８に移行して、波形データの格納先を管理するための変数ＲＨＢＦに、波形バッファＡを示す値を代入する。その値を代入した後、ステップ２０９に移行する。
【００７１】
なお、変数ＲＨＢＦに代入する値は、便宜的に、波形バッファＡを示す値のときにはＡ、波形バッファＢを示す値のときにはＢと表現することにする。波形バッファ、及び受信波形バッファに係わる他の変数においても同様に表現することにする。
ステップ２０９では、ＡＤコンバータ１１２から出力された波形データを入力する。続くステップ２１０では、その波形データを、変数ＲＨＢＦによって指定される波形バッファに格納する。その格納を行った後、ステップ２１１に移行する。なお、ＡＤコンバータ１１２はマイク１１１が出力する音声信号をＡＤ変換して出力することから、以降、波形データは音声データと呼ぶことにする。
【００７２】
ステップ２１１では、状況の変化に応じて音楽情報を送信するラベル１処理を実行する。続くステップ２１２では、音楽情報の送信の終了が指示されたか否か判定する。スイッチ群１１５の所定のスイッチを操作して音楽情報の送信の終了をユーザが指示した場合、判定はＹＥＳとなって一連の処理を終了する。そうでない場合には、判定はＮＯとなってステップ２１１に戻る。それにより、ユーザが送信の終了を指示するまで、ステップ２１１のラベル１処理を継続して実行する。
【００７３】
上述のステップ２０１〜２１０は、音楽情報の送信を開始するうえでの初期設定を行うための処理、或いはその開始に伴う処理として実行される。ＭＩＤＩデータの受信、音声データを格納している波形バッファの空容量が無くなったといった状況の変化はステップ２１１のラベル１処理の実行によって対処される。
【００７４】
図３は、上記ステップ２１１として実行されるラベル１処理の動作フローチャートである。次に、図３を参照して、上記音楽情報送信処理中で実行されるサブルーチン処理について説明する。
【００７５】
上述したように、時間データはｍｓ単位でタイミングを表すデータとしている。タイマ１０２は、それよりも細かい単位で時間の計時を行う。このことから、本実施の形態では、現在時刻を保持させる変数を用意し、その変数の値を、タイマ１０２による時間の計時の進行に応じて更新するようにしている。その変数については、以降、現在時刻レジスタと呼ぶことにする。
【００７６】
先ず、ステップ３０１では、現在時刻レジスタの値を１ｍｓが経過する毎に更新するために、そのレジスタの値を更新してから１ｍｓが経過したか否か判定する。現在のタイマ１０２の値が、現在時刻レジスタの値を前回、更新したときの値から１ｍｓに対応する値以上大きくなっていた場合、判定はＹＥＳとなり、ステップ３０２に移行してそのレジスタの値のインクリメントを行った後、ステップ３０３に移行する。そうでない場合には、判定はＮＯとなってステップ３０６に移行する。
【００７７】
ステップ３０３では、ＭＩＤＩ ＩＮ端子１１４がＭＩＤＩデータを受信したか否か判定する。ユーザが鍵盤装置１３０を操作した場合、鍵盤装置１３０はＭＩＤＩデータを出力することから、判定はＹＥＳとなってステップ３０４に移行する。そうでない場合には、即ちユーザが鍵盤装置１３０の操作を行っていないような場合には、判定はＮＯとなってステップ３０６に移行する。
【００７８】
ステップ３０４では、ＭＩＤＩ ＩＮ端子１１４が受信したＭＩＤＩデータを送信器１０８に送って送信させる。続くステップ３０５では、現在時刻レジスタの現在値を送信器１０８に送り、それを時間データとして送信させる。その後、ステップ３０６に移行する。なお、実際には、ＭＩＤＩデータ、及び時間データは、一つのパケットとして送信器１０８から送信される。
【００７９】
ステップ３０６では、カーソルポインタ１０２のカーソルＸレジスタ、及びカーソルＹレジスタの各値を読み出し、それらを変数Ｘ、及びＹにそれぞれ対応させて代入する。続くステップ３０７では、変数ＦＸの値が変数Ｘの値と等しく、且つ変数ＦＹの値が変数Ｙの値と等しいか否か判定する。カーソルポインタ１０２が指示するカーソルの表示位置がそれまでから変化した場合、変数ＦＸの値と変数Ｘの値、或いは変数ＦＹの値と変数Ｙの値が異なることから、判定はＹＥＳとなってステップ３０８に移行する。そうでない場合には、判定はＮＯとなってステップ３１１に移行する。
【００８０】
カーソルの表示位置が変化したことは、受信側のカーソルの表示位置を変更させる必要が生じたことを意味する。このことから、ステップ３０８〜３１０では、ポイントデータを音楽情報として送信するための処理が行われる。
【００８１】
先ず、ステップ３０８では、変数ＦＸに変数Ｘの値を代入し、変数ＦＹに変数Ｙの値を代入することにより、変数ＦＸ、及びＦＹの値の更新を行う。続くステップ３０９では、ポイントデータを音楽情報として送信することを表す定数（３，０）を送信器１０８に送信させる。それを送信させると、ステップ３１０に移行して、変数Ｘ、及びＹの値を送信器１０８に送信させる。それら変数の値を送信した後、ステップ３１１に移行する。なお、それら識別子、及び変数は、実際には１つのパケットで送信器１０８から送信される。
【００８２】
ステップ３１１以降では、波形バッファへの音声データの格納やその波形バッファの切り換え、及び波形バッファに格納させた音声データの送信に係わる処理が行われる。
【００８３】
先ず、ステップ３１１では、波形バッファの容量単位の録音が終了したか否か判定する。変数ＲＨＢＦの値が指定する波形バッファの空容量が無くなった場合、判定はＹＥＳとなってステップ３１２に移行し、そうでない場合には、判定はＮＯとなってステップ３１６に移行する。
【００８４】
ステップ３１２では、録音時刻レジスタに現在時刻レジスタの値を代入する。続くステップ３１３では、送信する音声データを格納した波形バッファを管理するための変数ＳＨＢＦに、変数ＲＨＢＦの値を代入する。その後は、ステップ３１４に移行する。
【００８５】
ステップ３１４では、変数ＲＨＢＦの値を反転させる。具体的には、それまでの値がＡであればＢに、それまでの値がＢであればＡに書き換える。その書き換えを終了すると、ステップ３１５に移行して、音声データを含む音楽情報の送信を行うラベル２処理を実行する。その実行を終了した後は、ステップ３１６に移行する。
【００８６】
ステップ３１６では、音声データを入力するタイミングとなったか否か判定する。ＣＰＵ１０１は、予め定められたサンプリング周期でＡＤコンバータ１１２が出力する音声データを取り込む。このことから、前回ＡＤコンバータ１１２の出力を取り込んでから１サンプリング周期に対応する時間が経過した場合、判定はＹＥＳとなってステップ３１７に移行する。そうでない場合には、判定はＮＯとなって一連の処理を終了する。
【００８７】
このようにして、本実施の形態では、波形バッファの容量単位の録音が終了する度に、音声データを格納する波形バッファを切り換えてその録音（格納）を継続して行うようにしている。切り換え前の波形バッファ、即ちそれまで音声データの格納を行っていた波形データに格納された音声データは、後述するラベル２処理の実行時に送信するようにしている。それにより、音声データを格納する波形バッファと音声データを送信する波形バッファとが一致するようなことを回避している。
【００８８】
図４は、上記ステップ３１５として実行されるラベル２処理の動作フローチャートである。次に、図４を参照して、ラベル２処理について詳細に説明する。なお、そのラベル２処理には、上記ラベル１処理から現在時刻レジスタや録音時刻レジスタ等が引数として渡される。
【００８９】
先ず、ステップ４０１では、現在時刻レジスタの値を１ｍｓが経過する毎に更新するために、そのレジスタの値を更新してから１ｍｓが経過したか否か判定する。現在のタイマ１０２の値が、現在時刻レジスタの値を前回、更新したときの値から１ｍｓに対応する値以上大きくなっていた場合、判定はＹＥＳとなり、ステップ４０２に移行してそのレジスタの値のインクリメントを行った後、ステップ４０３に移行する。そうでない場合には、判定はＮＯとなってステップ４０６に移行する。
【００９０】
ステップ４０３では、ＭＩＤＩ ＩＮ端子１１４がＭＩＤＩデータを受信したか否か判定する。ユーザが鍵盤装置１３０を操作した場合、鍵盤装置１３０はＭＩＤＩデータを出力することから、判定はＹＥＳとなってステップ４０４に移行する。そうでない場合には、即ちユーザが鍵盤装置１３０の操作を行っていないような場合には、判定はＮＯとなってステップ４０６に移行する。
【００９１】
ステップ４０４では、ＭＩＤＩ ＩＮ端子１１４が受信したＭＩＤＩデータを送信器１０８に送って送信させる。続くステップ４０５では、現在時刻レジスタの現在値を送信器１０８に送り、それを時間データとして送信させる。その後、ステップ４０６に移行する。なお、上述したように、ＭＩＤＩデータ、及び時間データは一つのパケットにまとめて送信される。
【００９２】
ステップ４０６〜４１１では、音楽情報として音声データ（波形データ）を送信するための処理が行われる。
先ず、ステップ４０６では、音声情報として音声データを送信することを示す定数（０，０）を送信器１０８に送信させる。以降、同様に、波形バッファの容量を示すバイト数である２５６を音声データのバイト数として送信させ、続いてシリアル番号として変数ＳＣの値を送信させる（ステップ４０７、４０８）。変数ＳＣの値を送信させると、ステップ４０９でその値のインクリメントを行った後、ステップ４１０に移行する。
【００９３】
ステップ４１０では、変数ＳＨＢＦの値が指定する波形バッファに格納された波形データを送信器１０８に送って送信させる。その後は、ステップ４１１に移行して、変数ＢＣの値の更新を行う。その更新は、音声データとして２５６バイトを送信することから、それまでの値に２５６を加算して得られる値を新たに変数ＢＣに代入することで行う。なお、識別子である定数（０，０）から音声データは、実際には一つのパケットにまとめて送信される。
【００９４】
ステップ４１１に続くステップ４１２では、ステップ４１０で送信器１０８に依頼した音声データの送信が終了するのを待つ。その送信が終了するのを待って、ステップ４１３に移行する。
【００９５】
音声データを送信することにより、音楽情報としての音声データの送信が完了する。このことから、ステップ４１３以降では、送信した音声データの再生を指示する再生指示コマンドを音楽情報として送信するための処理が行われる。
【００９６】
先ず、ステップ４１３では、音楽情報として再生指示コマンドを送信することを示す定数（１，０）を送信器１０８に送信させる。以降は、変数ＢＣの値を音声データの総バイト数として送信させ、続けて録音時刻レジスタの値を時間データとして送信させる（ステップ４１４、４１５）。そのようにして再生指示コマンドを音楽情報として送信した後、一連の処理を終了する。なお、再生指示コマンドを兼ねる定数（１，０）から時間データの送信は、実際には一つのパケットにまとめて行われる。
【００９７】
このように、本実施の形態では、画像データ（楽譜のビットマップデータ）は実際の演奏に係わる音楽情報の送信に先だって送信し、ＭＩＤＩデータはそれを受信する度に送信し、ポイントデータは必要に応じて送信し、音声データは波形バッファの空容量がなくなる度に送信し、再生指示コマンドは音声データを送信する度に送信するようにしている。
【００９８】
なお、本実施の形態では、便宜的に音声データと再生指示コマンドを別にして送信するようにしているが、その再生指示コマンドは送信しなくても良い。音声データに、時間データ、及びそれを再生すべきか否かを判定するための各種データを付加して送信するようにしても良い。
【００９９】
次に、音楽情報を受信した場合のＣＰＵ１０１の動作について、図５を参照して詳細に説明する。その図５は、音楽情報受信処理の動作フローチャートである。
【０１００】
自分宛にデータが何時、送信されるかを予め知ることはできない。このことから、音楽情報受信処理は、受信器１０７がネットワーク（ここではＬＡＮを想定）に接続されている場合に、電源がオンされた後、ＣＰＵ１０１がＲＯＭ１０３に格納されているプログラムを実行することで実現される。
【０１０１】
なお、上述したようにして送信された音楽情報は、サーバに保持されることから、音楽情報の受信はサーバからそれをダウンロードすることで行われる。自分宛に送信されたデータの有無は、サーバに問い合わせることで確認する。
【０１０２】
先ず、ステップ５０１では、音楽情報の受信開始に備えて、各種変数に初期値を代入することを含むイニシャライズを行う。各種変数への初期値の代入としては、送られてきた音声データのバイト数を保持するための変数ＪＢＣ、音声データのシリアル番号を管理するための変数ＪＳＣ、及び、送られてきた音声データの総バイト数を管理するための変数ＨＳＳＲには各々０を代入し、受信した音声データを格納するための受信波形バッファを確保し、受信した音声データの格納先を管理するための変数ＪＨＢＦには受信波形バッファＡを示すＡを代入する。そのようなことを行ってイニシャライズが終了すると、次にステップ５０２に移行する。
【０１０３】
ステップ５０２では、受信器１０７により受信した音楽情報の内容を判別してそれに応じた処理を行うラベル３処理を実行する。続くステップ５０３では、サーバとの接続が断たれたか否か判定する。サーバとの接続を切断する操作をユーザが行ったような場合、音楽情報の受信は終了したとして判定はＹＥＳとなり、一連の処理を終了する。そうでない場合には、判定はＮＯとなってステップ５０２に戻り、ラベル３処理を実行する。それにより、音楽情報の受信が終了するまでの間、ステップ５０２のラベル３処理を繰り返し実行する。
【０１０４】
図６は、上記ステップ５０２として実行されるラベル３処理の動作フローチャートである。次に、図６を参照して、ラベル３処理について詳細に説明する。
送信元では、音楽情報の種類によって時間データを付加して送信する。その時間データは、送信元が１ｍｓ単位で単に計時した時刻である。このことから、本実施の形態では、音楽情報の処理用の変数を用意し、その変数を用いて時刻を計時し、そのようにして計時した時刻を時間データとして受信した時刻と比較することにより、時間データで指定されるタイミングで音楽情報を処理するようにしている。なお、その変数については、以降、便宜的に発音時刻レジスタと呼ぶことにする。
【０１０５】
先ず、ステップ６０１では、上記発音時刻レジスタの値を前回、更新してから１ｍｓ経過したか否か判定する。タイマ１０２の現在値が、そのレジスタの値を前回、更新したときの値から１ｍｓに対応する値以上大きかった場合、判定はＹＥＳとなり、ステップ６０２でその値のインクリメントを行った後、ステップ６０３に移行する。そうでない場合には、判定はＮＯとなってステップ６０３に移行する。
【０１０６】
本実施の形態では、音楽情報として受信したＭＩＤＩデータを格納する領域（以降、音楽データバッファと呼ぶ）をＲＡＭ１０４に確保し、ＭＩＤＩデータを受信する度に、そのバッファにＭＩＤＩデータを時間データとともに格納して、時間データで指定されるタイミングでＭＩＤＩデータを処理するようにしている。ステップ６０３では、その音楽データバッファに格納された未処理のＭＩＤＩデータのなかで処理タイミングとなったものがあるか否か判定する。時間データとして付加された時刻が発音時刻レジスタの値で表される時刻よりも早いＭＩＤＩデータが音楽データバッファに格納されていた場合、判定はＹＥＳとなり、ステップ６０４で該当するＭＩＤＩデータを処理した後、ステップ６０５に移行する。そうでない場合には、判定はＮＯとなってステップ６０６に移行する。なお、ＭＩＤＩデータの処理は、ＣＰＵ１０１が、ＲＡＭ１０４のその音楽データバッファから該当するＭＩＤＩデータを読み出し、それをＭＩＤＩ ＯＵＴ端子１１３を介して音源装置１２０に送出することで行われる。
【０１０７】
ステップ６０５では、受信器１０７を介してサーバに問い合わせを行い、自分宛に送信されたデータがあればダウンロードさせて受け取り、そのデータ中の先頭の２ワード分を取り出す。その２ワードのデータは、音楽情報がＭＩＤＩデータであればそのＭＩＤＩデータと時間データであり、それ以外の音楽情報では２バイトの識別子である。ステップ６０５に続くステップ６０６以降の処理は、そのデータから特定される音楽情報の種類に応じて行われる。
【０１０８】
先ず、ステップ６０６では、そのデータで表現された値が（０，０）か否か判定する。音楽情報として音声データを受信器１０７が受信（サーバからダウンロード）した場合、判定はＹＥＳとなり、ステップ６０７で音声データの受信に対応するためのラベル４処理を実行した後、一連の処理を終了する。そうでない場合には、即ち音声データ以外の音楽情報を受信した場合には、判定はＮＯとなってステップ６０８に移行する。
【０１０９】
ステップ６０８では、２ワード分のデータで表現された値が（１，０）か否か判定する。音楽情報として再生指示コマンドを受信器１０７が受信した場合、判定はＹＥＳとなり、ステップ６０９で再生指示コマンドの受信に対応するためのラベル５処理を実行した後、一連の処理を終了する。そうでない場合には、即ち音声データ、及び再生指示コマンド以外の音楽情報を受信した場合には、判定はＮＯとなってステップ６１０に移行する。
【０１１０】
ステップ６１０では、２ワード分のデータで表現された値が（２，０）か否か判定する。音楽情報として画像データを受信器１０７が受信した場合、判定はＹＥＳとなり、ステップ６１１で画像データの受信に対応するためのラベル６処理を実行した後、一連の処理を終了する。そうでない場合には、即ち音声データ、再生指示コマンド、及び画像データ以外の音楽情報を受信した場合には、判定はＮＯとなってステップ６１２に移行する。
【０１１１】
ステップ６１２では、２ワード分のデータで表現された値が（３，０）か否か判定する。音楽情報としてポイントデータを受信器１０７が受信した場合、判定はＹＥＳとなり、ステップ６１３で再生指示コマンドの受信に対応するためのラベル７処理を実行した後、一連の処理を終了する。そうでない場合には、即ち音楽情報としてＭＩＤＩデータを受信した場合には、判定はＮＯとなってステップ６１４に移行する。
【０１１２】
ステップ６１４では、音楽情報として受信したＭＩＤＩデータを時間データとともにＲＡＭ１０４の音楽データバッファに格納する。その格納を行った後、一連の処理を終了する。
【０１１３】
このようにして、ラベル３処理では、時間データで指定されたタイミングとなったか否か確認しながら、音楽情報の処理、その受信に対処するための処理を行うようになっている。以降は、そのラベル３処理内で実行される各種サブルーチン処理について詳細に説明する。
【０１１４】
図７は、上記ステップ６０７として実行されるラベル４処理の動作フローチャートである。次に、図７を参照して、ラベル４処理について詳細に説明する。そのラベル４処理は、音声データであることを示す識別子、音声データのバイト数、シリアル番号、音声データの順に並べられた音楽情報の受信に対応するための処理である。
【０１１５】
先ず、ステップ７０１では、受信器１０７から受け取った受信データ中から、識別子である定数の次に位置するバイト数を取り出し、続くステップ７０２でそれを変数ＪＢＣに代入する。それが終了すると、ステップ７０３で受信データ中からシリアル番号を取り出した後、ステップ７０４に移行して、受信したシリアル番号が音声データの受信回数のカウント用に用意した変数ＪＳＣの値と等しいか否か判定する。送信元から送信された音声データを全て正常に受信していた場合、それらの値が一致することから判定はＹＥＳとなってステップ７０５に移行する。そうでない場合には、判定はＮＯとなってステップ７０９に移行する。
【０１１６】
ステップ７０５では、シリアル番号の次に位置する２５６バイトの音声データを受信データ中から取り出す。続くステップ７０６では、それを変数ＪＨＢＦの値で指定される受信波形バッファに格納する。それが終了すると、ステップ７０７で変数ＪＳＣの値をインクリメントし、次にステップ７０８で変数ＨＳＳＲの値を更新した後、一連の処理を終了する。
【０１１７】
上記ステップ７０４でのＮＯの判定は、送信元から送信された音声データのなかで正常に受信できなかったものが存在していることを意味する。音声データの受信にエラーが発生していることを意味する。このことから、ステップ７０９では、そのエラーに対応するためのラベル８処理を実行する。そのラベル８処理を実行した後、一連の処理を終了する。
【０１１８】
図８は、上記ラベル８処理の動作フローチャートである。
音声データの受信にエラーが発生した場合、そのエラーによって異常な音を発音させてしまう可能性が生じる。このことから、ラベル８処理では、受信した音声データを破棄する処理をステップ８０１で行う。それを行った後、一連の処理を終了する。
【０１１９】
図９は、上記音楽情報受信処理でステップ６０９として実行されるラベル５処理の動作フローチャートである。次に、図９を参照して、その処理について詳細に説明する。
【０１２０】
ラベル５処理は、再生指示コマンドの受信に対応するための処理である。送信元は、音その再生指示コマンドを示す識別子、それまでに送信した音声データの総バイト数、時間データの順に並べて音楽情報として送信する。なお、その総バイト数は、変数ＢＣの値である。
【０１２１】
先ず、ステップ９０１では、受信器１０７から受け取った受信データ中から、識別子である定数の次に位置する総バイト数を取り出す。続くステップ９０２では、その総バイト数が変数ＨＳＳＲの値と等しいか否か判定する。再生指示コマンドを送信したときの送信元における変数ＢＣの値が変数ＨＳＳＲの値と一致していた場合、判定はＹＥＳとなってステップ９０３に移行する。そうでない場合には、判定はＮＯとなってステップ９０７に移行する。
【０１２２】
ステップ９０３では、総バイト数の次に位置する時間データを受信データ中から取り出して、それを発音時刻レジスタに代入する。その後、ステップ９０４に移行する。
【０１２３】
再生指示コマンドに先だって送信される音声データは、マイク１１１が集音した音のデータであり、ＡＤコンバータ１１２から随時ＣＰＵ１０１に送られる。このことから、普通は受信器１０７が最初に受信する種類の音楽情報となる。その音声データは他のデータと比較してバイト数が多いため、送信時間が最も変動すると予想される。このようなことから、本実施の形態では再生指示コマンドに付加された時間データを発音時刻レジスタに代入している。それにより、受信側での音楽情報の受信による演奏は、音声データの再生を基準として行うようにしている。再生指示コマンドに付加された時間データを発音時刻レジスタに代入することにより、ＭＩＤＩデータを処理するタイミングは、図６のラベル３処理のステップ６０３で説明したように、それに付加された時間データを発音時刻レジスタの値と単に比較することで特定できることになる。
【０１２４】
ステップ９０４では、再生する対象となる音声データが格納された受信波形バッファを管理するための変数ＯＨＢＦに変数ＪＨＢＦの値を代入する。即ち直前に受信された音声データの格納先の受信波形バッファを示す値を変数ＯＨＢＦに代入する。続くステップ９０５では、変数ＪＨＢＦの値の反転、即ちそれまでの値がＡであればＢに、或いは、それまでの値がＢであればＡにする書き換えを行う。そうした後、ステップ９０６に移行して、変数ＯＨＢＦの値で指定される受信波形バッファに格納された音声データの再生を開始する。その再生を開始した後に一連の処理を終了する。
【０１２５】
なお、特に詳細な説明は省略するが、音声データの再生は、その受信波形バッファに格納された音声データ中の１サンプリング分のデータを、サンプリング周期に合わせて順次読み出し、それをＤＡコンバータ１０９に出力することで行っている。
【０１２６】
ステップ９０２でのＮＯの判定は、上述したように、音声データの受信に何らかのエラーが発生した可能性があることを意味する。このことから、ステップ９０７では、そのエラーに対応するためのラベル９処理を実行して、音声データの再生を中止させる。そのラベル９処理を実行した後、一連の処理を終了する。
【０１２７】
図１０は、そのラベル９処理の動作フローチャートである。
このラベル９処理では、図１０に示すように、ステップ１００１で受信データ中の時間データを取り出すと、次に変数ＪＢＣ、及びＨＳＳＲの値をクリア、即ち０を代入（ステップ１００２、１００３）した後、一連の処理を終了する。変数ＨＳＳＲの値をクリアすることにより、それ以降では、上記ステップ９０２の判定は常にＮＯとなる。このため、正常に受信することができた音声データの再生の終了とともに、音声データの再生が行われなくなる。それにより、エラーの発生によって異常な音を発音させるようなことが回避される。
【０１２８】
図１１は、図６のラベル３処理でステップ６１１として実行されるラベル６処理の動作フローチャートである。
画像データ（ここでは、楽譜のビットマップデータが前提）の受信に対応するためのラベル６処理では、識別子（２，０）の次に位置する画像データを受信データ中から取り出し、それを液晶表示器１０６が備えたＶＲＡＭに転送する処理をステップ１１０１で行う。それにより、液晶表示器１０６に楽譜の表示が行えるようにした後、一連の処理を終了する。
【０１２９】
図１２は、図６のラベル３処理でステップ６１３として実行されるラベル７処理の動作フローチャートである。
ポイントデータ（ここでは、楽譜上の演奏位置を示すカーソルの表示位置を指定するデータである）の受信に対応するためのラベル７処理では、識別子（３，０）の次に位置するＸ座標データを受信データ中から取り出してカーソルポインタ１０５のカーソルＸレジスタに格納した（ステップ１２０１、１２０２）後、同様に、Ｙ座標データを受信データ中から取り出してカーソルＹレジスタに格納する（ステップ１２０３、１２０４）ことを行う。そのようにしてカーソルの表示位置の変更を指示した後、一連の処理を終了する。
【０１３０】
なお、第１の実施の形態では、イベントデータとしてＭＩＤＩデータ、音声データ、再生指示コマンド、画像データ、及びポイントデータの計５種類を送受信することを想定しているが、当然のことながら、音楽情報として送信する内容は、それに限定するものではない。それ以上であっても、それ以下であっても良い。また、それらを送信する際の形式も任意に変更して良い。
【０１３１】
上記音声データについては、本実施の形態では常に送信するようにしているが、必ずしもそうしなくて良い。例えば音量レベルを設定しておき、その音量レベルよりも大きな音量の音をマイク１１１が拾っているときだけ音声データを送信するようにしても良い。音声データを圧縮して送信するようにしても良い。そのようにして受信側で再生すべき価値のある音声データだけを送信したり、或いはそのデータ量を低減させた場合には、それ以外の種類の音楽情報をより大量に送信することができる。音声データの受信にエラーが発生した場合の処置については、直ちにミュートさせるのではなく、クロスフェードさせてエラーの発生を目立たなくさせても良い。
【０１３２】
また、第１の実施の形態では、音楽情報の送受信を行えるようになっているが、音楽情報の送信だけ、或いはそれの受信だけを行えるようにしても良い。その送受信では、処理（送信、或いは受信）の対象とする音楽情報の種類を任意に選択できるようにすることが望ましい。
＜第２の実施の形態＞
近年、自動演奏（ここでは自動伴奏を含む）を行う自動演奏機能は、その専用の装置であるシーケンサーを始めとして、様々な装置に搭載されている。ユーザは、その機能を用いることにより、合奏を楽しむことができる。
【０１３３】
自動演奏は、それを行うための演奏データ（シーケンスデータ）を処理することで行われる。その演奏データは、普通、演奏上のイベントの内容を表すイベントデータ（例えばＭＩＤＩデータ）とそれを処理すべきタイミングを表す時間データとからなるデータ対を１つの処理単位として、それを処理する順序に並べた形で構成される。そのような構成であることから、或るパートを演奏させないというようなことはできるが、別のパートを付加して演奏を行うといったようなことはできない。第２の実施の形態は、そのことに着目し、自動演奏として行える内容を付加できるようにしたものである。
【０１３４】
第２の実施の形態は、上記第１の実施の形態による音楽情報受信装置に、自動演奏の内容を付加できる機能（音楽情報編集装置）を搭載させることで実現させたものである。その構成は、基本的に第１の実施の形態のそれ（図１参照）と同じである。このことから、第２の実施の形態の説明は、第１の実施の形態の説明で用いた符号をそのまま流用して、図１を参照しつつ行うことにする。
【０１３５】
図１３は、第２の実施の形態による音楽情報送受信装置を搭載した楽音発生装置の利用方法を説明する図である。先ず、図１３を参照して、その利用方法、及びそれを可能にさせる動作について説明する。
【０１３６】
図１３中の１３０１〜１３０４は、例えば、それぞれが図１に示す構成を有する楽音発生装置である。矢印は、音楽情報がどこからどこに送信されるのかを示している。即ち、楽音発生装置１３０１に、各楽音発生装置１３０２〜１３０４が音楽情報を送信することを示している。
【０１３７】
各楽音発生装置１３０２〜１３０４は、それのユーザがスイッチ群１１５を操作して指定した送信先に、同じくスイッチ群１１５を操作して選択した演奏データを送信する。その送信は、ＣＰＵ１０１が、選択された演奏データをＲＯＭ１０３から読み出し、それを送信器１０８に送ることで行われる。
【０１３８】
それらの装置１３０２〜１３０４から送信された演奏データは、それらとは別の楽音発生装置１３０１に受信される。その装置１３０１のＣＰＵ１０１は、受信した演奏データを格納する領域（以降、便宜的に音楽データバッファと呼ぶ）をＲＡＭ１０４に前もって確保し、そのバッファに、受信器１０７が受信した演奏データを格納する。本実施の形態では、演奏データの受信は各装置１３０２〜１３０４毎にハンドシェイクで行うようにしている。
【０１３９】
各装置１３０２〜１３０４からの演奏データの受信が終了すると、装置１３０１のＣＰＵ１０１は、イベントデータ（ここではＭＩＤＩデータである）に付加された時間データを基に、その時間データで指定される処理タイミングが早い順にソートする。イベントデータと時間データからなるデータ対の処理順序に従った並べ換えを行う。その並べ換えを行った後、それを行った演奏データの再生を開始する。
【０１４０】
上記時間データによるタイミングの管理方法は、或る基準となる時間的位置から経過した時間で表す絶対時間系の管理方法と、直前のイベントが発生してから経過した時間で表す相対時間系の管理方法と、の２種類に大別される。本実施の形態で採用しているのは前者である。このため、上記ソートに応じた時間データへの操作は行っていない。
【０１４１】
上記のように、時間データを基にソートを行うことで、各演奏データを構成するイベントデータの処理タイミングを維持させつつ、複数の演奏データを適切な形で一つにまとめることができる。このため、ユーザは、様々な演奏データを任意に組み合わせるとともに、それらの演奏データを各々、適切に再生させられるようになる。それにより、ユーザが行える音楽表現の幅が広がるとともに、より多様な楽しみ方ができるようになることから、ユーザにとっての利便性が向上することになる。それ以外には、演奏データを分割して保存することができることから、その全てを盗難されたり、その全てを削除するといったことが一度に行えなくなる。そのため、安全面上の効果も得ることができる。
【０１４２】
なお、本実施の形態では、組み合わせる演奏データを他の装置から受信するようにしているが、別の方法でその演奏データを取得するようにして良い。フロッピーディスクやＣＤ−ＲＯＭ、或いはＩＣカード等の記録媒体にアクセスして演奏データを取得しても良い。当然のことながら、ＲＯＭ１０３、或いは記録媒体に格納された演奏データを複数選択させ、選択された演奏データを組み合わせられるようにしても良い。
【０１４３】
次に、上述した制御を行うＣＰＵ１０１の動作について、図１４〜図１９に示す各種動作フローチャートを参照して詳細に説明する。ここでは、理解を容易にするために、音楽情報の送信、及びそれの受信と編集に着目して説明することにする。
【０１４４】
図１４は、音楽情報送信処理の動作フローチャートである。音楽情報（ここでは演奏データ）の送信に着目して、その処理の流れを抜粋して示したものである。始めに、図１４、及び図１５を参照して、演奏データを送信する際のＣＰＵ１０１の動作について詳細に説明する。
【０１４５】
なお、図１４に示す音楽情報送信処理（図１５のそのサブルーチン処理を含む）は、ユーザがスイッチ群１１５を操作して、送信させる演奏データを指定した場合に、ＣＰＵ１０１がＲＯＭ１０３に格納されているプログラムを実行することで実現される。
【０１４６】
先ず、ステップ１４０１では、ＲＡＭ１０４に音楽データバッファを確保するといったイニシャライズを行う。続くステップ１４０２では、その音楽データバッファに、ユーザが指定した演奏データをＲＯＭ１０３から読み出して格納する。その格納が終了すると、ステップ１４０３に移行する。
【０１４７】
本実施の形態では、編集に用いられることを前提とする演奏データは、その送信を要求してきた相手先に、その要求を待って行っている。このことから、ステップ１４０３では、その要求が送信されてきたか否か判定する。送信先がその要求を送信した場合、判定はＹＥＳとなり、ステップ１４０４で演奏データを送信するラベル１処理を実行した後、ステップ１４０５に移行する。そうでない場合には、判定はＮＯとなってステップ１４０５に移行する。
【０１４８】
ステップ１４０５では、演奏データの送信が終了したか否か判定する。送信すべき演奏データを送信先に全て送信した、或いはその送信の中止をユーザがスイッチ群１１５を介して指示したような場合、判定はＹＥＳとなって一連の処理を終了する。そうでない場合には、判定はＮＯとなってステップ１４０３に戻り、演奏データの送信を継続させる必要があるか否か判定する。それにより、送信を要求してきた全ての送信先に、送信すべき演奏データを全て送信するようにしている。
【０１４９】
図１５は、上記ステップ１４０４として実行されるラベル１処理の動作フローチャートである。
このラベル１処理では、先ず、ステップ１５０１で楽音データバッファに格納した演奏データの送信を行う。続くステップ１５０２では、そのバッファ内に送信すべきデータが無いか否か判定する。全てのデータを送信した場合、判定はＹＥＳとなり、全てのデータを送信した旨を示すメッセージを送信先に送信した後、一連の処理を終了する。そうでない場合には、判定はＮＯとなってステップ１５０１に戻り、未送信分のデータの送信を行う。
【０１５０】
上記のように、ラベル１処理では、ステップ１５０１と１５０２で処理ループを形成しており、未送信分のデータが存在している間、その処理ループが繰り返し実行される。それにより、演奏データを、予め定めたデータ量に分けて送信するようにしている。なお、その送信は、ＣＰＵ１０１が音楽データバッファから読み出したデータにヘッダを付加して送信器１０８に送ることで行われる。
【０１５１】
図１６は、音楽情報受信処理の動作フローチャートである。次に、この図１６、更には図１７〜図１９を参照して、演奏データの受信に係わるＣＰＵ１０１の制御動作について詳細に説明する。
【０１５２】
演奏データは、ユーザがスイッチ群１１５を介して指定した送信元から受信するようになっている。音楽情報受信処理は、その送信元を指定した後、スイッチ群１１５を介して演奏データの受信を指示した場合に、ＣＰＵ１０１がＲＯＭ１０３に格納されているプログラムを実行することで実現される処理である。
【０１５３】
先ず、ステップ１６０１では、演奏データの受信開始に備えてイニシャライズを行う。それにより、演奏データの送信元を管理するための変数ＳＡＲの値はクリア、即ち０を代入し、受信した演奏データを格納する領域をＲＡＭ１０４に確保する。それが終了すると、ステップ１６０２に移行する。なお、上記領域については、以降、便宜的に受信音楽データバッファと呼ぶことにする。
【０１５４】
ステップ１６０２では、送信元に演奏データの送信を要求してその演奏データを受信するラベル２処理を実行する。続くステップ１６０３では、演奏データに対する全ての処理が終了したか否か判定する。受信した演奏データは、編集を行った後、再生するようにしている。このため、その再生が終了した、或いはその途中でユーザがスイッチ群１１５を介して終了を指示した場合、判定はＹＥＳとなって一連の処理を終了する。そうでない場合には、判定はＮＯとなり、ステップ１６０２に戻ってラベル２処理を実行する。
【０１５５】
図１７は、上記ステップ１６０２として実行されるラベル２処理の動作フローチャートである。次に、図１７を参照して、ラベル２処理について詳細に説明する。
【０１５６】
演奏データの送信元は複数、指定することができるようになっている。ＣＰＵ１０１は、ユーザがスイッチ群１１５により送信元として入力したデータ（ここではアドレス）をＲＡＭ１０４に格納して参照することにより、送信元を順次、切り替えながら演奏データを受信する。変数ＳＡＲは、そのような演奏データの送信元の切り換えを実現するために用いられる。
【０１５７】
先ず、ステップ１７０１では、変数ＳＡＲの値で指定される送信元に演奏データの送信を要求する。続くステップ１７０２では、受信器１０７を介してサーバに問い合わせを行い、演奏データが送信されたか否か判定する。送信元が演奏データを送信した場合、判定はＹＥＳとなってステップ１７０３に移行する。そうでない場合には、判定はＮＯとなってステップ１７０１に戻る。それにより、演奏データが送信されるのを待つ。
【０１５８】
ステップ１７０３では、受信器１０７によりサーバから演奏データを受信して、その演奏データと同一の演奏データが受信音楽データバッファに格納されていないか否か判定する。受信された演奏データ中のＭＩＤＩデータ、及びそれに付加された時間データの内容が受信音楽データバッファに格納されている演奏データ中のそれらとっていた場合、判定はＹＥＳとなり、ステップ１７０４で受信された演奏データを格納した後、ステップ１７０５に移行する。そうでない場合には、判定はＮＯとなってステップ１７０１に戻り、演奏データの送信を要求する。
【０１５９】
ステップ１７０５では、受信すべきデータがないか否か判定する。受信したデータ中に演奏データの送信が終了した旨を示す識別子が挿入されていた場合、判定はＹＥＳとなり、ステップ１７０６で変数ＳＡＲの値をインクリメントした後、ステップ１７０７に移行する。そうでない場合には、判定はＮＯとなってステップ１７０１に戻る。
【０１６０】
ステップ１７０７では、演奏データを受信していない送信元がないか否か判定する。変数ＳＡＲの値に対応する送信元が存在していない場合、判定はＹＥＳとなってステップ１７０８に移行し、そうでない場合には、判定はＮＯとなってステップ１７０１に戻る。
【０１６１】
ステップ１７０７でのＹＥＳの判定は、ユーザが指定した全ての送信元からの演奏データの受信が終了したことを意味する。このことから、ステップ１７０８では、受信した演奏データを編集して再生するラベル３処理を実行する。そのラベル３処理を実行した後、一連の処理を終了する。
【０１６２】
図１８は、上記ステップ１７０８として実行されるラベル３処理の動作フローチャートである。次に、図１８を参照して、ラベル３処理について詳細に説明する。
【０１６３】
ラベル３処理の実行時には、受信音楽データバッファに、受信された演奏データを送信元別に格納している。ラベル３処理は、それらの演奏データを対象に行われる。
【０１６４】
先ず、ステップ１８０１では、ＭＩＤＩデータに付加された時間データを参照することにより、各演奏データ中からＭＩＤＩデータを処理すべきタイミングが早い順に取り出して並べるソートを行う。それにより、複数の演奏データを、ＭＩＤＩデータの処理タイミングを維持させつつ一つにまとめる。
【０１６５】
ステップ１８０１に続くステップ１８０２では、演奏時刻レジスタに、時間データのなかで最も指定するタイミングが早い時間データを代入する。言い換えれば、最初に処理すべきＭＩＤＩデータに付加されている時間データを演奏時刻レジスタに代入する。なお、上記演奏時刻レジスタは、ＭＩＤＩデータを時間データに従って処理するために用いる変数であり、例えばタイマ１０２の値を参照して、１ｍｓが経過する毎にその値をインクリメントするようになっている。
【０１６６】
上記ステップ１８０２は、演奏データを再生を開始するうえでのイニシャライズとして行われる。それに続くステップ１８０３では、演奏データを再生するラベル４処理を実行する。ラベル３処理を構成する一連の処理は、そのラベル４処理を実行した後に終了する。
【０１６７】
図１９は、上記ステップ１８０３として実行されるラベル４処理の動作フローチャートである。次に、その処理について詳細に説明する。このラベル４処理は、編集後の演奏データを対象にして行われる。
【０１６８】
先ず、ステップ１９０１では、演奏時刻レジスタの値の更新を行ってから１ｍｓが経過したか否か判定する。その更新を行ったときのタイマ１０２の値とそれの現在値に１ｍｓに対応する値以上の差があった場合、判定はＹＥＳとなり、ステップ１９０２でその値をインクリメントした後、ステップ１９０３に移行する。そうでない場合には、判定はＮＯとなってステップ１９０３に移行する。
【０１６９】
ステップ１９０３では、演奏データ中で次に処理すべきＭＩＤＩデータの処理タイミングがきたか否か判定する。そのＭＩＤＩデータに付加された時間データの値が演奏時刻レジスタの値以下であった場合、判定はＹＥＳとなり、ステップ１９０４でそのＭＩＤＩデータを処理した後、ステップ１９０５に移行する。そうでない場合には、判定はＮＯとなってステップ１９０１に戻る。なお、ＭＩＤＩデータの処理は、ＣＰＵ１０１が、それをＭＩＤＩ ＯＵＴ端子１１３に送出することで行われる。
【０１７０】
ステップ１９０５では、処理の対象としている演奏データ中に、未処理のＭＩＤＩデータがあるか否か判定する。全てのＭＩＤＩデータを処理していない場合、判定はＹＥＳとなり、ステップ１９０６で次に処理すべきＭＩＤＩデータに処理対象を変更した後、ステップ１９０１に戻る。そうでない場合には、即ち演奏データの再生が終了した場合には、判定はＮＯとなって一連の処理を終了する。なお、上記処理対象の変更は、例えば処理対象とするＭＩＤＩデータを管理するための変数に、次に処理すべきＭＩＤＩデータが格納されているアドレスの値を代入することで行われる。
【０１７１】
このように、ラベル４処理は、演奏時刻レジスタの値を随時、更新しつつ、時間データで指定されたタイミングでＭＩＤＩデータを処理していくようになっている。
【０１７２】
なお、第２の実施の形態では、複数の演奏データを一つにまとめる編集を行うようにしているが、その編集を行う替わりに、例えばＭＩＤＩデータを処理する毎に複数の演奏データのなかから次に処理すべきＭＩＤＩデータを探しだすようにしても良い。しかし、相対時間系の管理方法を採用している場合には、そのようにするとタイミングを特定するために面倒な操作を演奏データの再生と並行に行わなければならないことから、編集を行った後に演奏データを再生することが望ましい。
【０１７３】
また、第２の実施の形態では、ＭＩＤＩデータで構成された演奏データを編集の対象としているが、当然のことながら、その演奏データはＭＩＤＩデータ以外のデータ、例えば音声データを用いて構成されていても良い。その演奏データは送信元に予め格納されたものであるが、演奏を開始した時点を基準とした時間データを付加するといったように、各送信元が計時の基準とする時点を予め決めておいた場合には、随時、生成して送信される音楽情報を編集の対象とすることもできる。
【０１７４】
また、送信させる演奏データについては、各装置１３０２〜１３０４のユーザが指定するようにしているが、その演奏データの送信を要求する側が演奏データを指定できるようにしても良い。
【０１７５】
更に、本実施の形態では、送信されてきた演奏データを対象にその編集を行うようにしているが、同じ記録媒体に格納されている演奏データを対象に編集を行うようにしても良い。このことから明らかなように、音楽情報編集装置は、音楽情報を受信できる装置だけでなく、様々な装置に搭載することができる。
＜第３の実施の形態＞
ＭＩＤＩの普及、即ち音楽情報を容易に送受信することができるようになったことは、装置を特定の用途で使うといったように、装置の用途の選択範囲を広げている。このことから、複数の装置を組み合わせてユーザが自分に合ったシステムを構築し、そのシステムを通して音楽を楽しむことも広く行われている。第３の実施の形態は、音楽情報の送受信によって創造される音楽の可能性に着目して、用途の選択範囲をより広げられるようにしたものである。
【０１７６】
第３の実施の形態による音楽情報送受信装置を搭載した楽音発生装置の構成は、上記第１の実施の形態におけるそれ（図１参照）と基本的に同じである。このことから、第３の実施の形態の説明は、第１の実施の形態の説明で用いた符号を基本的にはそのまま流用して、図１を参照しつつ行うことにする。
【０１７７】
図２０は、第３の実施の形態による音楽情報送受信装置を搭載した楽音発生装置の利用方法を説明する図である。先ず、図２０を参照して、その利用方法、及びそれを可能にさせる動作について説明する。
【０１７８】
図２０中の２００１〜２００５は、例えば、それぞれが図１に示す構成を有する楽音発生装置である。矢印は、音楽情報がどこからどこに送信されるのかを示している。即ち、楽音発生装置２００１は楽音発生装置２００２と音楽情報の送受信を行い、その楽音発生装置２００２は、楽音発生装置２００３〜２００５に音楽情報を送信することを示している。第１及び第２の実施の形態と同様に、それらの装置２００１〜２００５はＬＡＮを介して接続されている。
【０１７９】
図２０に示すシステムにおいて、上記楽音発生装置２００１は、演奏に用いられることを前提とし、楽音発生装置２００２は、各装置２００１、及び２００３〜２００５に音楽情報を提供することを前提とし、楽音発生装置２００３〜２００５は、受信した音楽情報を再生することを前提として用いられる。このことから、以降、便宜的に、楽音発生装置２００１は演奏装置、楽音発生装置２００２はデータベース装置、楽音発生装置２００３〜２００５は受信装置と呼ぶことにする。
【０１８０】
図２０に示すシステムを構成する各装置２００１〜２００５は、以下のように動作する。
各装置２００１〜２００５が前提とする動作は、例えばユーザがスイッチ群１１５を操作してそれに対応するモードを設定することで行われる。各装置２００１〜２００５間の接続は、例えばデータベース装置として動作することを指定するモードが設定された装置２００２において、演奏装置２００１と受信装置２００３〜２００５とで分けて相手先をスイッチ群１１５により指定することで行われる。データベース装置２００２は、各装置２００１、及び２００３〜２００５に、ユーザがスイッチ群１１５を介して指定した演奏データをＲＯＭ１０３から読み出し、それを以下のように音楽情報として提供する。
【０１８１】
演奏装置２００１に対しては、その演奏データを構成するＭＩＤＩデータに付加された時間データを参照し、その時間データで指定されるタイミングでＭＩＤＩデータを時間データとともに随時送信する。
【０１８２】
そのようにして演奏データが送信されてくる演奏装置２００１は、時間データに基づいてＭＩＤＩデータを処理する。それにより、データベース装置２００２から送信された演奏データを再生する。データベース装置２００２へは、演奏データの再生に応じて行ったユーザの合奏内容を送信する。具体的には、鍵盤装置１３０に対して行った操作内容を示すＭＩＤＩデータに時間データを付加して送信する。その時間データは、データベース装置２００２から送信されてきた時間データを基に生成したものである。
【０１８３】
本実施の形態では、上述したように、データベース装置２００２にはユーザが行った演奏内容のみを送信している。これは、演奏装置２００１が受信した演奏データはデータベース装置２００２が持っているためである。言い換えれば、それを送信しなくても不具合が生じることをデータベース装置２００２側で回避することができるためである。そのように、データベース装置２００２から受信した演奏データの送信を回避することにより、データベース装置２００２と演奏装置２００１間で送受信するデータ量が全体的に見て低減することから、それらを接続する伝送路の使用効率を向上させることができる。
【０１８４】
データベース装置２００２は、各受信装置２００３〜２００５に対しては、演奏装置２００１に送信した演奏データに加えて、その演奏装置２００１から受信した演奏データを送信する。その送信は、演奏装置２００１との間のデータ送信に或る程度の時間がかかることから、その演奏装置２００１から送信されてきた時間データを基に行っている。それにより、それらの演奏データを再生する際にタイミング的なズレが発生するのを回避させている。
【０１８５】
そのようにして演奏データが送信されてくる各受信装置２００３〜２００５は、演奏装置２００１と同様に、時間データに基づいてＭＩＤＩデータを処理する。それにより、データベース装置２００２自体が持っている演奏データの再生による演奏と、演奏装置２００１の鍵盤装置１３０に対してユーザが行った演奏の合奏を再現する。
【０１８６】
このように、データベース装置２００２は、各送信先に対して異なる内容の演奏データ（音楽情報）を送信できるようになっている。これは、各送信先（装置）毎に役割を異ならせたり、その役割の内容をより細かく指定するといったことが容易に行えることを意味する。それにより、例えば或る装置は演奏用、複数の装置をそれぞれ異なるパートの発音用にといったように、各装置の用途を細かく設定することができる。このため、装置を使用するうえでの選択の幅が広がって利便性が向上し、ユーザはシステムを構成する装置をより所望する形で使用することができる。また、その利便性の向上によって、ユーザが行える音楽表現の幅を広げられることから、新しい音楽の創造にも貢献することができる。
【０１８７】
次に、上記各装置２００１〜２００５の動作を実現させるそれに搭載されたＣＰＵ１０１の制御動作について、図２１〜図２６を参照して詳細に説明する。ここでは、理解を容易にするために、演奏装置２００１、データベース装置２００２、受信装置２００３〜２００５の各装置の機能を実現させる制御動作を、装置別に分けて説明することにする。
【０１８８】
図２１は、演奏装置２００１に搭載されたＣＰＵ１０１が実行する音楽情報送受信処理の動作フローチャートである。始めに、図２１を参照して、演奏装置２００１に搭載されたＣＰＵ１０１の動作について詳細に説明する。
【０１８９】
なお、その音楽情報送受信処理は、楽音発生装置が演奏装置として機能することをスイッチ群１１５によりユーザが指定した場合に、ＣＰＵ１０１がＲＯＭ１０３に格納されたプログラムを実行することで実現される。
【０１９０】
先ず、ステップ２１０１では、イニシャライズを行う。それにより、各種変数にはその値のクリアを含めて予め定められた値を代入し、受信した演奏データを一時的に保持しておく領域（以降、受信音楽データバッファと呼ぶ）をＲＡＭ１０４に確保する。続くステップ２１０２では、データベース装置２００２との間で音楽情報（ここでは、ＭＩＤＩデータ単位でやりとりする演奏データ）の送受信を行うためのラベル１処理を実行する。ステップ２１０３にはその後に移行する。
【０１９１】
ステップ２１０３では、音楽情報の送受信が終了したか否か判定する。例えばデータベース装置２００２から予め定めた時間以上、演奏データが送信されなかった、或いはユーザがスイッチ群１１５を介して演奏データの送受信の中止を指示したような場合、判定はＹＥＳとなり、ここで一連の処理を終了する。そうでない場合には、判定はＮＯとなってステップ２１０２に戻り、ラベル１処理を再度実行する。
【０１９２】
上記ステップ２１０２とステップ２１０３とは処理ループを形成しており、そのステップ２１０３の判定がＹＥＳとなるまで繰り返し実行される。それにより、データベース装置２００２からＭＩＤＩデータを順次受信して処理することによる自動演奏を行うとともに、ユーザが鍵盤装置１３０を操作した行った演奏内容をＭＩＤＩデータの形でデータベース装置２００２に送信する。
【０１９３】
図２２は、上記ステップ２１０２として実行されるラベル１処理の動作フローチャートである。次に、図２２を参照して、ラベル１処理について詳細に説明する。
【０１９４】
データベース装置２００２は、ＭＩＤＩデータに時間データを付加して送信する。その時間データで指定されるタイミングでＭＩＤＩデータを処理するために、時間の進行に応じて値を更新する変数（現在時刻レジスタ）を用意し、その変数の値を時間データの値と対比することで、時間データで指定されたタイミングでＭＩＤＩデータを処理するようにしている。
【０１９５】
先ず、ステップ２２０１では、現在時刻レジスタの値を前回、更新してから１ｍｓが経過したか否か判定する。前回の更新時のタイマ１０２の値とそのタイマ１０２の現在値の間に１ｍｓに対応する値以上の差があった場合、判定はＹＥＳとなり、ステップ２２０２で現在時刻レジスタの値のインクリメントを行った後、ステップ２２０３に移行する。そうでない場合には、判定はＮＯとなってステップ２２０３に移行する。
【０１９６】
ステップ２２０３では、受信音楽データバッファに格納したＭＩＤＩデータのなかで次に処理すべきＭＩＤＩデータを処理するタイミングとなったか否か判定する。そのＭＩＤＩデータに付加された時間データの値が現在時刻レジスタの値以下となった場合、判定はＹＥＳとなり、ステップ２２０４でそのＭＩＤＩデータをＭＩＤＩ ＯＵＴ端子１１３に出力した後、ステップ２２０５に移行する。そうでない場合には、判定はＮＯとなってステップ２２０５に移行する。
【０１９７】
ステップ２２０５では、受信器１０７を介してサーバに対する問い合わせを行い、自分宛に新たに送信されたデータがあればそれダウンロードさせる。続くステップ２２０６では、受信器１０７から受け取った受信データ中のＭＩＤＩデータ、及び時間データを受信音楽データバッファに格納する。そのようにして、受信器１０７のＭＩＤＩデータの受信に対応する処理を行った後、ステップ２２０７に移行する。
【０１９８】
ステップ２２０７では、ステップ２２０５で受信したＭＩＤＩデータがデータベース装置２００２から音楽情報として送信されてきた最初のデータか否か判定する。データベース装置２００２が演奏データの最初に位置しているＭＩＤＩデータを送信した場合、判定はＹＥＳとなり、ステップ２２０８でそれに付加されている時間データを現在時刻レジスタに代入した後、ステップ２２０９に移行する。そうでない場合には、判定はＮＯとなり、そのままステップ２２０９に移行する。
【０１９９】
このように、演奏装置２００１は、データベース装置２００２から最初に送信されてきた時間データを現在時刻レジスタに代入している。それにより、受信したＭＩＤＩデータに付加された時間データの値を現在時刻レジスタの値と単に対比するだけで、その時間データで指定されたタイミングでＭＩＤＩデータを処理できるようにしている。
【０２００】
ステップ２２０９では、ＭＩＤＩ ＩＮ端子１１４が鍵盤装置１３０からＭＩＤＩデータを受信したか否か判定する。ユーザが鍵盤装置１３０を操作した場合、判定はＹＥＳとなってステップ２２１０に移行する。そうでない場合には、判定はＮＯとなって一連の処理を終了する。
【０２０１】
ステップ２２１０では、ＭＩＤＩ ＩＮ端子１１４が受信したＭＩＤＩデータを受け取り、それをＭＩＤＩ ＯＵＴ端子１１３に出力して音源装置１２０に処理させるとともに、そのＭＩＤＩデータに現在時刻レジスタの値を時間データとして付加して送信器１０８に送り、データベース装置２００２を送信先にして送信させる。それが終わった後、一連の処理を終了する。
【０２０２】
このようにして、演奏装置２００１では、データベース装置２００２から送信されてきた演奏データに対する処理、その装置２００２への演奏データの送信を行う。それにより、上述した動作が実現されることになる。
【０２０３】
図２３は、データベース装置２００２に搭載されたＣＰＵ１０１が実行する音楽情報送受信処理の動作フローチャートである。次に、図２３、更には図２４を参照して、そのＣＰＵ１０１の制御動作について詳細に説明する。
【０２０４】
なお、このデータベース装置２００２で実行される音楽情報送受信処理は、ユーザがスイッチ群１１５を介して、楽音発生装置がデータベース装置として機能することや送信の対象とする演奏データ、更には演奏装置２００１及び受信装置２００３〜２００５等の送信先を指定した後、その演奏データの送信の開始を指示した場合に、ＣＰＵ１０１がＲＯＭ１０３に格納されたプログラムを実行することで実現される。
【０２０５】
先ず、ステップ２３０１では、イニシャライズを行う。それにより、現在時刻レジスタや演奏時刻レジスタ等の演奏データの送信に用いる変数にはその値のクリアを含む初期値の代入を行うとともに、ＲＡＭ１０４に送信すべき演奏データの格納に用いる領域（以降、音楽データバッファと呼ぶ）の確保を行う。そのようなことを行った後、ステップ２３０２に移行する。
【０２０６】
ステップ２３０２では、ユーザが指定した演奏データをＲＯＭ１０３から読み出し、それを音楽データバッファに格納する。続くステップ２３０３では、指定された送信先と演奏データの送受信、或いは送信を行うためのラベル２処理を実行する。それが終了した後、ステップ２３０４に移行する。
【０２０７】
ステップ２３０４では、音楽情報の送受信が終了したか否か判定する。演奏装置２００１は、データベース装置２００２から送信された演奏データによる演奏と合奏したユーザの演奏内容を演奏データとして送信することから、ユーザが指定した演奏データの送信の終了は演奏装置２００１よりも各受信装置２００３〜２００５のほうが後になる。このことから、その演奏データの各受信装置２００３〜２００５への送信が終了してから予め定めた時間以上、演奏データを演奏装置２００１が送信してこなかった、或いはユーザがスイッチ群１１５を介して演奏データの送信の中止を指示したような場合、判定はＹＥＳとなり、ここで一連の処理を終了する。そうでない場合には、判定はＮＯとなってステップ２３０３に戻り、ラベル２処理を再度実行する。
【０２０８】
上記ステップ２３０３とステップ２３０４とは処理ループを形成しており、そのステップ２３０４の判定がＹＥＳとなるまで繰り返し実行される。それにより、演奏装置２００１との間の演奏データの送受信、各受信装置２００３〜２００５への演奏データの送信が行われる。
【０２０９】
図２４は、上記ステップ２３０３として実行されるラベル２処理の動作フローチャートである。次に、図２４を参照して、ラベル２処理について詳細に説明する。
【０２１０】
データベース装置２００２は、演奏装置２００１と各受信装置２００３〜２００５に同一の演奏データをＭＩＤＩデータ単位で順次送信するが、その送信のタイミングは少なからず送信に時間がかかることから異なる。同じＭＩＤＩデータを送信するタイミングは演奏装置２００１のほうが早い。上記現在時刻レジスタ、及び演奏時刻レジスタは、このために用意した変数である。それらの変数を用いて演奏装置２００１と各受信装置２００３〜２００５にＭＩＤＩデータを送信するタイミングを別々に管理している。
【０２１１】
先ず、ステップ２４０１では、現在時刻レジスタの値を前回、更新してから１ｍｓが経過したか否か判定する。前回の更新時のタイマ１０２の値とそのタイマ１０２の現在値の間に１ｍｓに対応する値以上の差があった場合、判定はＹＥＳとなり、現在時刻レジスタ、及び演奏時刻レジスタの各値のインクリメント（ステップ２４０２及び２４０３）を行った後、ステップ２４０４に移行する。そうでない場合には、判定はＮＯとなり、次にステップ２４０４に移行する。
【０２１２】
ステップ２４０４では、音楽データバッファに格納したＭＩＤＩデータのなかで次に演奏装置２００１に送信すべきＭＩＤＩデータを送信するタイミングとなったか否か判定する。そのＭＩＤＩデータに付加された時間データの値が現在時刻レジスタの値以下となった場合、判定はＹＥＳとなり、ステップ２４０５でそのＭＩＤＩデータと時間データを送信器１０８から演奏装置２００１に送信させた後、ステップ２４０６に移行する。そうでない場合には、判定はＮＯとなり、次にステップ２４０６に移行する。
【０２１３】
ステップ２４０６では、受信器１０７を介してサーバに問い合わせを行い、自分宛にデータが送信されてきていればそれをダウンロードして、それが演奏装置２００１から送信されたＭＩＤＩデータか否か判定する。受信したデータに付加されている送信元が演奏装置２００１を示していた場合、判定はＹＥＳとなってステップ２４０７に移行する。そうでない場合には、判定はＮＯとなってステップ２４１０に移行する。
【０２１４】
ステップ２４０７では、受信器１０７が受信したＭＩＤＩデータが演奏装置２００１から音楽情報として送信されてきた最初のデータか否か判定する。演奏装置２００１への演奏データの送信を開始した後、ユーザがそれの鍵盤装置１３０への操作を開始した場合、最初のＭＩＤＩデータが受信されることから、判定はＹＥＳとなり、ステップ２４０８でそのＭＩＤＩデータに付加されている時間データを演奏時刻レジスタに代入した後、ステップ２４０９に移行する。そうでない場合には、判定はＮＯとなってステップ２４０９に移行する。そのステップ２４０９では、送信器１０８に、演奏装置２００１から受信したＭＩＤＩデータ、及び時間データを各受信装置２００３〜２００５に送信させる。
【０２１５】
このように、データベース装置２００２は、演奏装置２００１から最初に送信されてきた時間データを演奏時刻レジスタに代入している。その時間データは、データベース装置２００２から最初に送信された時間データの値を初期値にして計時した時刻を表すデータである。このため、後述するように、演奏時刻レジスタの値を時間データと単に対比して送信するタイミングを特定するだけで、ユーザが指定した演奏データ、及び演奏装置２００１から受信した演奏データを各受信装置２００３〜２００５にＭＩＤＩデータ単位で送信するタイミングのズレが回避される。それにより、それらの演奏データの再生は同期して各受信装置２００３〜２００５で行われることになる。
【０２１６】
ステップ２４０９に続くステップ２４１０では、音楽データバッファに格納したＭＩＤＩデータのなかで次に各受信装置２００３〜２００５に送信すべきＭＩＤＩデータを送信するタイミングとなったか否か判定する。そのＭＩＤＩデータに付加された時間データの値が演奏時刻レジスタの値以下となった場合、判定はＹＥＳとなり、ステップ２４１１でそのＭＩＤＩデータと時間データを送信器１０８から各受信装置２００３〜２００５に送信させた後、一連の処理を終了する。そうでない場合には、判定はＮＯとなり、ここで一連の処理を終了する。
【０２１７】
図２５は、各受信装置２００３〜２００５にそれぞれ搭載されたＣＰＵ１０１が実行する音楽情報受信処理の動作フローチャートである。次に、図２５を参照して、各受信装置２００３〜２００５にそれぞれ搭載されたＣＰＵ１０１の動作について詳細に説明する。
【０２１８】
なお、その音楽情報受信処理は、音楽情報送受信装置が受信装置として機能することをスイッチ群１１５によりユーザが指定した場合に、ＣＰＵ１０１がＲＯＭ１０３に格納されたプログラムを実行することで実現される。
【０２１９】
先ず、ステップ２５０１では、イニシャライズを行う。それにより、各種変数にはその値のクリアを含めて予め定められた値を代入し、受信した演奏データを一時的に保持しておく領域（以降、受信音楽データバッファと呼ぶ）をＲＡＭ１０４に確保する。続くステップ２５０２では、データベース装置２００２から送信された演奏データを受信してそれを再生するためのラベル３処理を実行する。ステップ２５０３にはその後に移行する。
【０２２０】
ステップ２５０３では、音楽情報の受信が終了したか否か判定する。データベース装置２００２から予め定めた時間以上、演奏データが送信されなかった、或いはユーザがスイッチ群１１５を介して演奏データの受信の中止を指示したような場合、判定はＹＥＳとなり、ここで一連の処理を終了する。そうでない場合には、判定はＮＯとなってステップ２５０２に戻り、ラベル３処理を実行する。
【０２２１】
上記ステップ２５０２とステップ２５０３は処理ループを形成しており、そのステップ２５０３の判定がＹＥＳとなるまで繰り返し実行される。それにより、データベース装置２００２から送信されたＭＩＤＩデータを順次受信して処理することによる自動演奏を行うようになっている。
【０２２２】
図２６は、上記ステップ２５０２として実行されるラベル３処理の動作フローチャートである。次に、図２６を参照して、ラベル３処理について詳細に説明する。
【０２２３】
先ず、ステップ２６０１では、現在時刻レジスタの値を前回、更新してから１ｍｓが経過したか否か判定する。前回の更新時のタイマ１０２の値とそのタイマ１０２の現在値の間に１ｍｓに対応する値以上の差があった場合、判定はＹＥＳとなり、ステップ２６０２で現在時刻レジスタの値のインクリメントを行った後、ステップ２６０３に移行する。そうでない場合には、判定はＮＯとなってステップ２６０３に移行する。
【０２２４】
ステップ２６０３では、受信音楽データバッファに格納したＭＩＤＩデータのなかで次に処理すべきＭＩＤＩデータを処理するタイミングとなったか否か判定する。そのＭＩＤＩデータに付加された時間データの値が現在時刻レジスタの値以下となった場合、判定はＹＥＳとなり、ステップ２６０４でそのＭＩＤＩデータをＭＩＤＩ ＯＵＴ端子１１３に出力した後、ステップ２６０５に移行する。そうでない場合には、判定はＮＯとなってステップ２６０５に移行する。
【０２２５】
ステップ２６０５では、受信器１０７を介してサーバに問い合わせを行い、自分宛にデータが送信されてきたか否か判定する。データベース装置２００２がＭＩＤＩデータを自分宛に送信した場合、判定はＹＥＳとなり、ステップ２６０６でそのデータをダウンロードさせ、それを受信器１０７から受け取って受信音楽データバッファに格納した後、ステップ２６０７に移行する。そうでない場合には、判定はＮＯとなり、ここで一連の処理を終了する。
【０２２６】
ステップ２６０７では、直前に実行したステップ２６０６で受信音楽データバッファに格納したデータがデータベース装置２００２から音楽情報として送信されてきた最初のデータか否か判定する。そのデータの前にデータベース装置２００２からＭＩＤＩデータを受信していなかった場合、判定はＹＥＳとなり、ステップ２６０８でそれに付加されている時間データを現在時刻レジスタに代入した後、一連の処理を終了する。そうでない場合には、判定はＮＯとなり、ここで一連の処理を終了する。
【０２２７】
このように、各受信装置２００３〜２００５は、データベース装置２００２から最初に送信されてきた時間データを現在時刻レジスタに代入している。それにより、受信したＭＩＤＩデータに付加された時間データの値を現在時刻レジスタの値と単に対比するだけで、ユーザが指定した演奏データか演奏装置２００１で生成された演奏データかに係わらず、それを構成するＭＩＤＩデータを適切なタイミングで処理できるようにしている。その結果、各受信装置２００３〜２００５では、演奏装置２００１で行われた合奏が忠実に再現される。
【０２２８】
なお、第３の実施の形態では、データベース装置２００２が演奏装置２００１と受信装置２００３〜２００５の２つに分けて異なる音楽情報を送信するようにしているが、それ以上に分けて異なる音楽情報を送信できるようにしても良い。その音楽情報の内容については、パートや音色等に着目して指定できるようにしても良い。
【０２２９】
そのデータベース装置２００２は、演奏装置２００１から音楽情報を受信するようになっているが、外部装置から音楽情報を受信せず、単に音楽情報を外部装置に送信するものとして使用できるようにしても良い。そのような使用方法に限定する場合には、受信器１０７は備えなくても良い。
＜第４の実施の形態＞
合奏、或いは競演等（これらをまとめてセッションと表現する）は、複数の演奏者が一個所に集まらなければ行うことができず、場所的な制約がある。第４の実施の形態は、そのような制約を解消して、複数の演奏者が一個所に集まらなくてもセッションを行えるようにしたものである。
【０２３０】
第４の実施の形態による音楽情報送受信装置を搭載した楽音発生装置の構成は、上記第１の実施の形態におけるそれ（図１参照）と基本的に同じである。このことから、第４の実施の形態でも、上記第２及び第３の実施の形態と同様に、第１の実施の形態の説明で用いた符号を基本的にはそのまま流用して、図１を参照しつつ説明することにする。
【０２３１】
図２７は、第４の実施の形態による音楽情報送受信装置を搭載した楽音発生装置の利用方法を説明する図である。先ず、図２７を参照して、その利用方法、及びそれを可能にさせる動作について説明する。
【０２３２】
図２７中の２７０１〜２７０３は、例えば、それぞれが図１に示す構成を有する楽音発生装置である。矢印は、音楽情報がどこからどこに送信されるのかを示している。即ち、楽音発生装置２７０１は楽音発生装置２７０２及び２７０３と音楽情報の送受信を行い、楽音発生装置２７０２は楽音発生装置２７０１の他に楽音発生装置２７０３と音楽情報の送受信を行うことを示している。第１〜第３の実施の形態と同様に、それらの装置２７０１〜２７０３はＬＡＮに接続されている。
【０２３３】
比較的に遠く離れた位置にいる演奏者に音楽情報を送る場合、少なからず遅延が生じることから、実時間処理では原理的に演奏者間の演奏のズレを回避することができない。自身の演奏と、聴こえてくる他の演奏者の演奏との間のタイミング的なズレが生じている演奏者が必ず存在してしまう。
【０２３４】
しかし、実際のセッションには、例えば楽譜に忠実な演奏から始めて、各演奏者が演奏（テイク）を繰り返す毎にそれぞれの演奏内容を調整していくといったように、同じ曲の演奏を繰り返し行うこともある。第４の実施の形態では、実時間処理では演奏者間の演奏のズレを回避できないことから、テイクを繰り返すセッションを行う場合に、以下のようにして各テイクをより適切に行えるようにしている。ここでは、便宜的に、図２７に示す各装置２７０１〜２７０３が持つ演奏データに対応する曲でセッションを行う場合を例にとって説明する。また、各装置２７０１〜２７０３の動作は基本的には同じであることから、装置２７０１に注目して説明することにする。
【０２３５】
上記演奏データは複数のパートを持つ各演奏者の演奏意図を含まないデータである。その演奏データは、スイッチ群１１５への操作によって楽音発生装置２７０１のユーザ（演奏者）に指定されると、ＣＰＵ１０１によってＲＯＭ１０３から読み出されて、ＲＡＭ１０４に確保した領域（以降、音楽トラックバッファと呼ぶ）に格納される。
【０２３６】
楽音発生装置２７０１のユーザ（演奏者）は、例えば、自身が演奏するパートの発音のミュートを指定して演奏データの再生（マイナスワン演奏）を行わせ、その演奏に合わせて所望のパートの演奏を行う。ＣＰＵ１０１は、そのパートの演奏内容を示すＭＩＤＩデータをＭＩＤＩ ＩＮ端子１１４から受け取り、そのＭＩＤＩデータにそれの処理タイミングを指定する時間データを付加し、それらを音楽情報として随時、各装置２７０２及び２７０３に送信する。
【０２３７】
演奏データ中のＭＩＤＩデータには、演奏の開始時を基準として処理タイミングを表す時間データを付加するようになっている。このことから、送信するＭＩＤＩデータには、演奏データの再生開始を基準として計時した時刻を時間データとして付加している。その時刻の計時には、変数である演奏時刻レジスタを用いている。
【０２３８】
各楽音発生装置２７０２及び２７０３でも同様に、それのユーザが行った演奏内容を示す音楽情報を他の装置に送信する。楽音発生装置２７０１は、楽音発生装置２７０２或いは２７０３から送信された音楽情報を受信すると、それをＲＡＭ１０４に確保した領域（以降、受信音楽データバッファと呼ぶ）に装置（パート（トラック）に対応する）別に格納する。それにより、そのバッファに、各楽音発生装置２７０２及び２７０３から送信された各パートの演奏データを格納する。
【０２３９】
受信音楽データバッファに格納した演奏データは、ユーザの演奏の終了を待って、音楽トラックバッファに格納した演奏データ中のそのパートに対応しているデータと入れ換える。音楽トラックバッファに格納した演奏データに、各演奏者（ここでは二人）が直前に行った演奏の内容を取り込む更新を行う。それにより、楽音発生装置２７０１のユーザが、楽音発生装置２７０２及び２７０３の各ユーザが直前に行った演奏との合奏を行えるようにしている。それらの装置２７０２及び２７０３はＭＩＤＩデータに時間データを付加して送信する。このため、更新後の演奏データを再生させての合奏を行っても、それらの装置２７０２及び２７０３で直前に行われた演奏との間のタイミング的なズレは回避される。その結果、楽音発生装置２７０１のユーザは、他の演奏者（他の装置２７０２及び２７０３の各ユーザ）がその場所に居るような感覚で快適にテイクを繰り返すことができるようになる。
【０２４０】
なお、上述したような演奏データの送受信、及び演奏データの更新は、ユーザがスイッチ群１１５を操作して所定のモード（以降、便宜的にセッションモードと呼ぶ）を設定した場合に行われる。また、本実施の形態では、上記演奏データの更新を容易に行えるように、パート単位に分けて編成された演奏データを採用し、それをＲＯＭ１０３に格納させている。
【０２４１】
次に、上記各楽音発生装置２７０１〜２７０３の動作を実現させるそれに搭載されたＣＰＵ１０１の制御動作について、図２８〜図３３を参照して詳細に説明する。それらの装置２７０１〜２７０３の動作は基本的に同じであることから、ここでも装置２７０１に着目して説明することにする。
【０２４２】
図２８は、楽音発生装置２７０１に搭載されたＣＰＵ１０１が実行する音楽情報送受信処理の動作フローチャートである。始めに、図２８を参照して、その処理の内容について詳細に説明する。
【０２４３】
なお、その音楽情報送受信処理は、楽音発生装置２７０１のユーザが、スイッチ群１１５を操作して、上記セッションモードを設定するとともに、再生させる演奏データ（曲）、及び音楽情報（ここでは演奏データ）の送信先を各々指定した場合に、ＣＰＵ１０１がＲＯＭ１０３に格納されたプログラムを実行することで実現される。指定する演奏データ（曲）は、セッションを行う演奏者（ユーザ）間で予め決めておくことで、各装置２７０１〜２７０３間で統一させることができる。
【０２４４】
先ず、ステップ２８０１では、イニシャライズを行う。それにより、演奏時刻レジスタの値のクリアを含めて各種変数に予め定められた値を代入し、ＲＯＭ１０３から読み出した演奏データの格納に用いる音楽トラックバッファ、及び受信した演奏データを一時的に保持しておく受信音楽データバッファ等をＲＡＭ１０４に確保する。続くステップ２８０２では、ユーザが指定した演奏データをＲＯＭ１０３から読み出して音楽トラックバッファに格納する。その後、ステップ２８０３に移行する。
【０２４５】
ステップ２８０３では、上記演奏時刻レジスタの値を随時、更新しつつ、他の装置２７０２及び２７０３との間で演奏データの送受信や演奏データの更新、更には演奏データの再生を行うためのラベル１処理を実行する。それを実行すると、ステップ２８０４に移行する。
【０２４６】
ステップ２８０４では、ユーザがセッションの終了を指示したか否か判定する。ユーザがスイッチ群１１５を操作してセッションモードの解除、或いは演奏データの再生の終了を指示したような場合、判定はＹＥＳとなって一連の処理を終了する。そうでない場合には、判定はＮＯとなってステップ２８０３に戻ってラベル１処理を実行する。
【０２４７】
上記のように、ステップ２８０３とステップ２８０４は処理ループを形成しており、ステップ２８０４の判定がＹＥＳとなるまでの間、繰り返し実行される。それにより、他の装置２７０２や２７０３との間の演奏データの送受信、演奏データを更新しての再生が行われることになる。
【０２４８】
図２９は、上記ステップ２８０３として実行されるラベル１処理の動作フローチャートである。次に、図２９を参照して、ラベル２処理について詳細に説明する。
【０２４９】
先ず、ステップ２９０１では、前回、演奏時刻レジスタの値を更新（インクリメント）してから１ｍｓ経過したか否か判定する。その更新を行ったときのタイマ１０２の値と現在のそれの値との間に１ｍｓに対応する値以上の差があった場合、判定はＹＥＳとなり、ステップ２９０２でその演奏時刻レジスタの値をインクリメントした後、ステップ２９０３に移行する。そうでない場合には、判定はＮＯとなり、次にステップ２９０３に移行する。
【０２５０】
ステップ２９０３では、他の装置２７０２及び２７０３との間で演奏データの送受信や演奏データの更新、更には演奏データの再生を行うためのラベル２処理を実行する。それを実行した後、一連の処理を終了する。
【０２５１】
図３０は、上記ステップ２９０３として実行されるラベル２処理の動作フローチャートである。次に、図３０を参照して、ラベル２処理について詳細に説明する。
【０２５２】
各楽音発生装置２７０１〜２７０３間でのデータの送受信は、サーバを介して行われる。このことから、先ず、ステップ３００１でサーバに問い合わせを行うことにより、自分宛に送信されたデータがあるか否か判定する。そのサーバが楽音発生装置２７０２、或いは２７０３から楽音発生装置２７０１に宛てたデータを新たに保持していた場合、判定はＹＥＳとなってステップ３００２に移行する。そうでない場合には、判定はＮＯとなってステップ３００５に移行する。
【０２５３】
ステップ３００２では、受信器１０７を介してサーバからデータをダウンロードする。続くステップ３００３では、そのダウンロードしたデータを、それぞれ、それの送信元により特定される受信音楽データバッファ内の領域に格納する。その後、ステップ３００４に移行してサーバに対する問い合わせを行い、サーバから更にダウンロードすべきデータがないか否か判定する。その問い合わせの結果、サーバから更にダウンロードすべきデータのないことが確認された場合、判定はＹＥＳとなってステップ３００５に移行する。そうでない場合には、判定はＮＯとなってステップ３００２に戻り、ダウンロードすべきデータのダウンロードを行う。
【０２５４】
このようにして、他の楽音発生装置２７０２或いは２７０３から送信されたデータを受信した後のステップ３００５では、音楽トラックバッファに格納された演奏データを再生したり、ユーザが行った演奏の内容を示すＭＩＤＩデータを各楽音発生装置２７０２及び２７０３に随時送信するといったことを行うためのラベル３処理を実行する。それが終了した後に一連の処理を終了する。
【０２５５】
図３１は、上記ステップ３００５として実行されるラベル３処理の動作フローチャートである。次に、図３１を参照して、そのラベル３処理について詳細に説明する。
【０２５６】
上述したように、本実施の形態では、音楽トラックバッファに格納した演奏データの更新を容易に行えるように、パートに対応するトラック別に分けて構成されている演奏データを採用している。このことから、演奏データの再生は、トラック単位で再生の対象とするトラックを変更しながら行っている。再生の対象とするトラックは、変数であるトラックアドレスレジスタで管理している。そのようにして行う演奏データの再生は、ステップ３１０１〜３１０６の処理を実行することで実現される。
【０２５７】
先ず、ステップ３１０１では、トラックアドレスレジスタの値で指定されるトラックの演奏データ中で次の処理対象のＭＩＤＩデータに付加された時間データの値が、演奏時刻レジスタの値以上か否か判定する。その時間データで指定される処理タイミングとなった場合、判定はＹＥＳとなってステップ３１０２に移行し、それが付加されたＭＩＤＩデータをＭＩＤＩ ＯＵＴ端子１１３に出力するとともに、処理対象をそのＭＩＤＩデータの次に位置しているＭＩＤＩデータに変更した後、ステップ３１０３に移行する。そうでない場合には、判定はＮＯとなり、次にステップ３１０３を実行する。
【０２５８】
そのステップ３１０３では、現在再生の対象としているトラックで処理の対象とすべきＭＩＤＩデータがもうないか否か判定する。上記ステップ３１０１の判定がＮＯ、或いはそのトラックの演奏データ中の全てのＭＩＤＩデータを処理していた場合、判定はＹＥＳとなり、次にステップ３１０４でトラックアドレスレジスタの値をインクリメントした後、ステップ３１０５に移行する。そうでない場合には、判定はＮＯとなってステップ３１０１に戻り、次の処理対象のＭＩＤＩデータの処理タイミングについての判定を行う。
【０２５９】
ステップ３１０５では、再生の対象とするトラックがもうないか否か判定する。トラックアドレスレジスタの値がトラック番号の最大値よりも大きい場合、言い換えれば全てのトラックの演奏データを対象に現時点での処理が終了した場合、判定はＹＥＳとなり、ステップ３１０６でトラックアドレスレジスタの値をクリア（０を代入）した後、ステップ３１０７に移行する。そうでない場合には、判定はＮＯとなり、ステップ３１０１に戻って新たに対象になったトラックの演奏データを再生するための処理を行う。
【０２６０】
ステップ３１０７では、ＭＩＤＩ ＩＮ端子１１４が鍵盤装置１３０からＭＩＤＩデータを入力したか否か判定する。ＭＩＤＩ ＩＮ端子１１４がＭＩＤＩデータを受信した旨を示す信号を出力していた場合、判定はＹＥＳとなり、ステップ３１０８でＭＩＤＩ ＩＮ端子１１４からＭＩＤＩデータを受け取って一時バッファに格納し、更にそれをＭＩＤＩ ＯＵＴ端子１１３に出力した後、ステップ３１０９に移行する。そうでない場合には、判定はＮＯとなり、次にステップ３１０９を実行する。なお、上記一時バッファは、鍵盤装置１３０が出力したＭＩＤＩデータを一時、保持しておくために、ＲＡＭ１０４に予め確保した領域である。
【０２６１】
ステップ３１０９では、ステップ３１０８で一時バッファに格納したＭＩＤＩデータの送信や演奏データの再生の終了等に対処するためのラベル４処理を実行する。それが終了した後、一連の処理を終了する。
【０２６２】
図３２は、そのステップ３１０９として実行されるラベル４処理の動作フローチャートである。次に、ラベル４処理について、図３２を参照して詳細に説明する。
【０２６３】
ＣＰＵ１０１は、ユーザがスイッチ群１１５を介して指定（入力）した送信先（アドレス）のリスト（以降、送信先リストと呼ぶ）をＲＡＭ１０４に格納する。鍵盤装置１３０から入力したＭＩＤＩデータの送信は、そのリストを参照して行われる。送信先リストのなかでデータの送信対象とする送信先は、変数である送信アドレスレジスタにより管理している。
【０２６４】
先ず、ステップ３２０１では、一時バッファに格納されたＭＩＤＩデータを読み出してそれに時間データとして演奏時刻レジスタの値を付加し、その時間データを付加したＭＩＤＩデータを送信アドレスレジスタの値で指定される送信先リスト中の送信先に送信する。なお、その送信は、送信先のアドレスを格納したヘッダを送信対象のデータ（ＭＩＤＩデータ、及び時間データ）に付加し、それを送信器１０８に出力することで行われる。
【０２６５】
上記演奏時刻レジスタは、演奏データ中のＭＩＤＩデータの処理タイミングを特定するために、時刻の計時に用いている変数である。そのレジスタの値を時間データとしてＭＩＤＩデータに付加することにより、楽音発生装置２７０１で行ったパートの演奏が、送信先で他のパートの演奏と同期して再現されることになる。それにより、各演奏者がそれぞれ異なる場所に居ても、一個所に集まっているような感覚でテイク（セッション）を繰り返すことができる。
【０２６６】
ステップ３２０１に続くステップ３２０２では、送信アドレスレジスタの値をインクリメントする。それが終了すると、ステップ３２０３に移行して、データを送信していない送信先がないか否か判定する。送信アドレスレジスタの値が送信先リストに載っている送信先の番号の最大値よりも大きい場合、それは送信先リストに載っている全ての送信先にデータを送信したことを意味することから、判定はＹＥＳとなり、ステップ３２０４で一時バッファ内のＭＩＤＩデータを全て消去するとともに、送信アドレスレジスタの値をクリア（０を代入）した後、ステップ３２０５に移行する。そうでない場合には、判定はＮＯとなってステップ３２０１に戻り、次の送信先にデータを送信する。
【０２６７】
ラベル４処理の実行時に一時バッファにＭＩＤＩデータが格納されていない場合もある。その場合には、上述のステップ３２０１〜３２０４は実際上、実行することなくステップ３２０５に移行することになる。
【０２６８】
ステップ３２０５では、音楽トラックバッファに格納した演奏データ中に処理していないＭＩＤＩデータが存在するか否か判定する。その演奏データの再生が完了していない場合、判定はＹＥＳとなり、ここで一連の処理を終了する。そうでない場合には、判定はＮＯとなってステップ３２０６に移行する。
【０２６９】
ステップ３２０６では、他の楽音発生装置３２０７及び３２０３から随時、受信した演奏データを音楽トラックバッファに格納した演奏データ中にコピーするラベル５処理を実行する。それが終了した後、一連の処理を終了する。
【０２７０】
このように、本実施の形態では、ユーザが演奏データの再生による演奏との合奏を行うとの前提から、その演奏データの再生の完了を待って、それの更新を行うようにしている。その更新を行うことにより、演奏者各自が自身の演奏を他の演奏者の演奏と合わせていくことが可能となる。
【０２７１】
図３３は、上記ステップ３２０６として実行されるラベル５処理の動作フローチャートである。次に、ラベル５処理について、図３３を参照して詳細に説明する。
【０２７２】
上述したように、他の楽音発生装置２７０２及び２７０３から受信した演奏データは、受信音楽データバッファに装置（パート）別に格納している。このことから、音楽トラックバッファに格納されている演奏データ中への受信した演奏データのコピーは、装置（パート）単位で順次、行うようになっている。そのコピーの対象としている演奏データの管理は、その演奏データは送信先リストに載っている各送信先から送信されてくるのを前提としていることから、上記送信アドレスレジスタを用いて行っている。
【０２７３】
先ず、ステップ３３０１では、音楽トラックバッファの演奏データ中で送信アドレスレジスタの値により特定されるトラックに、そのトラックに対応する受信音楽データバッファ内の演奏データを書き込む（上書きする）。それにより、１パート分の演奏データをコピーする。なお、当然のことながら、そのコピーは、受信音楽データバッファ中にコピーの対象となる演奏データが無い場合には行わない。
【０２７４】
ステップ３３０１に続くステップ３３０２では、送信アドレスレジスタの値をインクリメントする。それを行うと、次にステップ３３０３に移行して、受信音楽データバッファ中に格納されている演奏データを全てコピーしたか否か判定する。その送信アドレスレジスタの値が送信先リストに載っている送信先の番号の最大値よりも大きい場合、それは送信先リストに載っている送信先から受信した演奏データを全てコピーしたことを意味することから、判定はＹＥＳとなってステップ３３０４に移行する。そうでない場合には、判定はＮＯとなってステップ３３０１に戻り、受信音楽データバッファ中のコピー対象を替えて演奏データを音楽トラックバッファの演奏データ中にコピーする。
【０２７５】
上記のように、ステップ３３０１〜３３０３は処理ループを形成している。その処理ループを実行することにより、音楽トラックバッファに格納された演奏データの更新がパート（装置）単位で行われる。
【０２７６】
ステップ３３０３の判定がＹＥＳとなった後は、送信アドレスレジスタ、及び演奏時刻レジスタの値をそれぞれクリア（０を代入）する（ステップ３３０４、３３０５）。そのクリアを行った後、一連の処理を終了する。
【０２７７】
ラベル５処理が終了すると、図２８に示す音楽情報送受信処理でステップ２８０３として実行されるラベル１処理も終了することになる。そのステップ２８０３に続くステップ２８０４の判定がＮＯの場合、即ちユーザが演奏の中止を指示しないような場合、演奏を行った後、ユーザに直ちに次の演奏を開始させることになる。しかし、そのようにすることは、各演奏者の都合を無視することになるから望ましくない。このため、演奏データの再生が終了した場合には、ステップ２８０４からステップ２８０３への移行は、演奏データの再生が終了してから所定の時間が経過するのを待った後、或いは全ての演奏者が用意できたことを示す操作を行うのを待った後、といったように、予め定めた条件が満たされた後に行うことが望ましい。そのようにした場合には、各演奏者に一個所に集まっているときのようにテイク（セッション）を繰り返させることができる。
【０２７８】
なお、第４の実施の形態では、３人の演奏者がセッションを行う場合を例にとって説明を行っているが、当然のことながら、その人数は３人に限定されるものではない。また、セッションを繰り返す毎に演奏データの更新を行うようになっているが、その更新は、例えば予め定めた時間毎といったように、他の基準で行うようにしても良い。そのようにした場合には、各自に演奏の調整のための練習時間を与えることができる。
【０２７９】
また、第４の実施の形態では、複数の装置と音楽情報の送受信を行えるようになっているが、１つの装置とのみそれを行えるようにしても良い。更には、自分の力量に応じて、音楽情報の送信、及び受信の一方のみを選択できるようにしても良い。このように、様々な変形を行うことができる。
【０２８０】
本実施の形態（第１〜第４の実施の形態）は、楽音発生装置に搭載される装置として実現させたものであるが、本発明を適用した装置の搭載対象は、電子楽器や各種コントローラ、シーケンサ等の楽音発生装置に限定されるものではない。パーソナルコンピュータ等にも搭載させることができる。その本発明を適用した装置には、当然のことながら、音楽情報の送受信を行う機能を必ずしも搭載させる必要はなく、想定する利用環境に応じて、音楽情報を送信する機能、及び受信する機能の何れか一方だけを搭載するようにしても良い。
【０２８１】
パーソナルコンピュータへの搭載は、基本的には上記した動作を実現させるためのプログラムをロードすることで行うことができる。そのプログラムは、ＣＤ−ＲＯＭやフロッピーディスクといった携帯性に優れた記録媒体に記録して配布しても良く、何らかの通信回線を介して配信しても良い。
【０２８２】
【発明の効果】
以上説明したように、本発明は、例えばパート別に音楽情報を分けて送信するといったように、複数の外部装置に送信する音楽情報の内容を外部装置単位で異ならせつつ、音楽情報をそれが有する時間データで指定されるタイミングに基づいて送信する。このため、ユーザは音楽情報を受信させる各装置（それを搭載した装置）をより所望する形で使用することができる。
【図面の簡単な説明】
【図１】第１の実施の形態による音楽情報送受信装置を搭載した楽音発生装置の回路構成図である。
【図２】音楽情報送信処理の動作フローチャートである。
【図３】ラベル１処理の動作フローチャートである。
【図４】ラベル２処理の動作フローチャートである。
【図５】音楽情報受信処理の動作フローチャートである。
【図６】ラベル３処理の動作フローチャートである。
【図７】ラベル４処理の動作フローチャートである。
【図８】ラベル８処理の動作フローチャートである。
【図９】ラベル５処理の動作フローチャートである。
【図１０】ラベル９処理の動作フローチャートである。
【図１１】ラベル６処理の動作フローチャートである。
【図１２】ラベル７処理の動作フローチャートである。
【図１３】第２の実施の形態による音楽情報送受信装置を搭載した楽音発生装置の利用方法を説明する図である。
【図１４】音楽情報送信処理の動作フローチャートである（第２の実施の形態）。
【図１５】ラベル１処理の動作フローチャートである（第２の実施の形態）。
【図１６】音楽情報受信処理の動作フローチャートである（第２の実施の形態）。
【図１７】ラベル２処理の動作フローチャートである（第２の実施の形態）。
【図１８】ラベル３処理の動作フローチャートである（第２の実施の形態）。
【図１９】ラベル４処理の動作フローチャートである（第２の実施の形態）。
【図２０】第３の実施の形態による音楽情報送受信装置を搭載した楽音発生装置の利用方法を説明する図である。
【図２１】演奏装置で実行される音楽情報送受信処理の動作フローチャートである（第３の実施の形態）。
【図２２】ラベル１処理の動作フローチャートである（第３の実施の形態）。
【図２３】データベース装置で実行される音楽情報送受信処理の動作フローチャートである（第３の実施の形態）。
【図２４】ラベル２処理の動作フローチャートである（第３の実施の形態）。
【図２５】受信装置で実行される音楽情報受信処理の動作フローチャートである（第３の実施の形態）。
【図２６】ラベル３処理の動作フローチャートである（第３の実施の形態）。
【図２７】第４の実施の形態による音楽情報送受信装置を搭載した楽音発生装置の利用方法を説明する図である。
【図２８】音楽情報送受信処理の動作フローチャートである（第４の実施の形態）。
【図２９】ラベル１処理の動作フローチャートである（第４の実施の形態）。
【図３０】ラベル２処理の動作フローチャートである（第４の実施の形態）。
【図３１】ラベル３処理の動作フローチャートである（第４の実施の形態）。
【図３２】ラベル４処理の動作フローチャートである（第４の実施の形態）。
【図３３】ラベル５処理の動作フローチャートである（第４の実施の形態）。
【符号の説明】
１００、１３０１〜１３０４、２７０１〜２７０３ 楽音発生装置
１０１ ＣＰＵ
１０２ タイマ
１０３ ＲＯＭ
１０４ ＲＡＭ
１０５ カーソルポインタ
１０６ 液晶表示器
１０７ 受信器
１０８ 送信器
１０９ ＤＡコンバータ
１１０ スピーカ
１１１ マイク
１１２ ＡＤコンバータ
１１３ ＭＩＤＩ ＯＵＴ端子
１１４ ＭＩＤＩ ＩＮ端子
１１５ スイッチ群
２００１ 演奏装置
２００２ データベース装置
２００３〜２００５ 受信装置

Claims (2)

1. 時間データの付加された音楽情報を送信可能な演奏装置、及び受信された音楽情報に基づいて再生を行う受信装置に接続され、
   時間データが付加された音楽情報を記憶する記憶手段と、
   現時刻をカウントする現時刻カウント手段と、
   演奏時刻をカウントする演奏時刻カウント手段と、
   前記記憶手段に記憶されている音楽情報を、当該音楽情報に付加された時間データと現時刻カウント手段でカウントされた現時刻とに基づいて決定されるタイミングで前記演奏装置に送信する第１の送信手段と、
   前記演奏装置から送信された時間データの付加された音楽情報を受信する受信手段と、
   前記受信手段にて受信された音楽情報を前記受信装置に送信する第２の送信手段と、
   前記受信手段により最初に受信された音楽情報に付加された時間データに基づいて、前記演奏時刻カウント手段でカウントされる演奏時刻を変更する変更手段と、
   前記記憶手段に記憶されている音楽情報を、当該音楽情報に付加された時間データと前記変更手段で変更された演奏時刻とに基づいて決定されるタイミングでかつ当該演奏時刻を付加して前記受信装置に送信する第 3 の送信手段と、
   を具備したことを特徴とする送受信装置。
2. 時間データの付加された音楽情報を送信可能な演奏装置、及び受信された音楽情報に基づいて再生を行う受信装置に接続された送受信装置に適用されるプログラムを記憶した記憶媒体であって、
   現時刻をカウントするステップと、
   演奏時刻をカウントするステップと、
   記憶手段に記憶されている時間データが付加された音楽情報を、当該音楽情報に付加された時間データとカウントされた現時刻とに基づいて決定されるタイミングで前記演奏装置に送信するステップと、
   前記演奏装置から送信された時間データの付加された音楽情報を受信するステップと、
   前記受信された音楽情報を前記受信装置に送信するステップと、
   前記最初に受信された音楽情報に付加された時間データに基づいて、前記カウントされた演奏時刻を変更するステップと、
   前記記憶手段に記憶されている音楽情報を、当該音楽情報に付加された時間データと前記変更された演奏時刻とに基づいて決定されるタイミングでかつ当該演奏時刻を付加して前記受信装置に送信するステップと、
   を有するプログラムを記録したコンピュータ読み取り可能な記録媒体。

Images