(57)【特許請求の範囲】
【請求項１】
ノートオン、ノートオフ等のイベントの内容を表すイベントデータに、該イベントデータを処理すべきタイミングを表す時間データを付加した前記イベントデータを音楽情報として順次送信する音楽情報送信装置によって送信された音楽情報を受信しながら処理していくことで演奏を行うための方法であって、
現在時間をカウントする第１の工程と、
前記音楽情報を受信する第２の工程と、
前記第２の工程で音楽情報が受信される度に前記第１の工程でカウントされた現在時間と前記第２の工程で受信した音楽情報中の時間データとの差時間を求め、求められた差時間が所定値を超える場合に、当該差時間に基づいた補正時間を生成する第３の工程と、
前記第２の工程で音楽情報が受信される度に前記第３の工程で生成された補正時間と前記差時間との差を抽出するとともに、当該差の所定数分の平均を求める第４の工程と、
前記第４の工程で求められた差の平均の値に基づいて前記第３の工程で生成された補正時間を変更する第５の工程と、
前記第２の工程にて受信された音楽情報のイベントデータに付加された時間データを前記補正時間に基づいて変更するとともに、当該変更された時間データに基づいてイベントデータを処理すべきタイミングを決定する第６の工程と、
前記第６の工程で決定したタイミングに従って、前記第２の工程で受信した音楽情報中のイベントデータを処理する第７の工程と、
を有することを特徴とする音楽情報受信処理方法。
【請求項２】
ノートオン、ノートオフ等のイベントの内容を表すイベントデータに、該イベントデータを処理すべきタイミングを表す時間データを付加した前記イベントデータを音楽情報として順次送信する音楽情報送信装置によって送信された音楽情報を受信しながら処理していくことで演奏を行うための方法であって、
前記音楽情報を受信する第１の工程と、
前記第１の工程で受信した前記音楽情報を所定の記憶手段に記憶させる第２の工程と、
前記第１の工程で受信した音楽情報中のイベントデータを処理するタイミングを、該イベントデータに付加された時間データ、及び前記記憶手段の空容量に基づいて決定する第３の工程と、
前記第３の工程で決定したタイミングに従って、前記第１の工程で受信した音楽情報中のイベントデータを処理する第４の工程と、
を有することを特徴とする音楽情報受信処理方法。
【請求項３】
ノートオン、ノートオフ等のイベントの内容を表すイベントデータに、該イベントデータを処理すべきタイミングを表す時間データを付加した前記イベントデータを音楽情報として順次送信する音楽情報送信装置によって送信された音楽情報を受信しながら処理していくことで演奏を行う装置であって、
現在時間をカウントする現時刻カウント手段と、
前記音楽情報を受信する受信手段と、
前記受信手段で音楽情報が受信される度に前記現時刻カウント手段でカウントされた現在時間と受信した音楽情報中の時間データとの差時間を求め、求められた差時間が所定値を超える場合に、当該差時間に基づいた補正時間を生成する補正時間生成手段と、
前記受信手段で音楽情報が受信される度に前記生成された補正時間と前記差時間との差を抽出するとともに、当該差の所定数分の平均を求める平均手段と、
前記平均手段で求められた差の平均の値に基づいて前記補正時間生成手段で生成された補正時間を変更する変更手段と、
前記受信された音楽情報のイベントデータに付加された時間データを前記補正時間に基づいて変更するとともに、当該変更された時間データに基づいてイベントデータを処理すべきタイミングを決定するタイミング決定手段と、
前記タイミング決定手段で決定したタイミングに従って、前記受信した音楽情報中のイベントデータを処理する処理手段と、
を具備したことを特徴とする音楽情報受信処理装置。
【請求項４】
ノートオン、ノートオフ等のイベントの内容を表すイベントデータに、該イベントデータを処理すべきタイミングを表す時間データを付加した前記イベントデータを音楽情報として順次送信する音楽情報送信装置によって送信された音楽情報を受信しながら処理していくことで演奏を行う装置であって、
前記音楽情報を受信する受信手段と、
前記受信手段が受信した前記音楽情報を記憶する記憶手段と、
前記受信手段が受信した音楽情報中のイベントデータを処理するタイミングを、該イベントデータに付加された時間データ、及び前記記憶手段の空容量に基づいて決定するタイミング決定手段と、
前記タイミング決定手段が決定したタイミングに従って、前記記憶手段に記憶された音楽情報中のイベントデータを処理する処理手段と、
を具備したことを特徴とする音楽情報受信処理装置。
【請求項５】
コンピュータを
現在時間をカウントする現時刻カウント手段と、
ノートオン、ノートオフ等のイベントの内容を表すイベントデータ毎に、該イベントデータを処理すべきタイミングを表す時間データが付加されたイベントデータを音楽情報として順次送信する音楽情報送信装置によって送信された音楽情報を受信する手段と、
前記受信手段で音楽情報が受信される度に前記現時刻カウント手段でカウントされた現在時間と受信した音楽情報中の時間データとの差時間を求め、求められた差時間が所定値を超える場合に、当該差時間に基づいた補正時間を生成する補正時間生成手段と、
前記受信手段で音楽情報が受信される度に前記生成された補正時間と前記差時間との差を抽出するとともに、当該差の所定数分の平均を求める平均手段と、
前記平均手段で求められた差の平均の値に基づいて前記補正時間生成手段で生成された補正時間を変更する変更手段と、
前記受信された音楽情報のイベントデータに付加された時間データを前記補正時間に基づいて変更するとともに、当該変更された時間データに基づいてイベントデータを処理すべきタイミングを決定するタイミング決定手段と、
前記タイミング決定手段で決定したタイミングに従って、前記受信した音楽情報中のイベントデータを処理する処理手段と、
として機能させるためのプログラムを記録したコンピュータ読み取り可能な記録媒体。
【請求項６】
コンピュータを
ノートオン、ノートオフ等のイベントの内容を表すイベントデータ毎に、該イベントデータを処理すべきタイミングを表す時間データが付加されたイベントデータを音楽情報として順次送信する音楽情報送信装置によって送信された音楽情報を受信する手段と、
該受信する手段によって受信された音楽情報を記憶手段に記録させる手段と、
前記受信する手段により受信された音楽情報中のイベントデータを処理するタイミングを、該イベントデータに付加された時間データ、及び前記記憶手段の空容量に基づいて決定する手段と、
該決定する手段によって決定されたタイミングに従って前記イベントデータを処理する手段と、
として機能させるためのプログラムを記録したコンピュータ読み取り可能な記録媒体。
【発明の詳細な説明】
【０００１】
【発明の属する技術分野】
本発明は、音楽情報の送受信により受信側で楽音を発音させて演奏を行わせるための技術に関する。
【０００２】
【従来の技術および発明が解決しようとする課題】
現在では、ＭＩＤＩ（Musical Instrument Digital Interface）が普及したこともあって、音楽情報を送信し、受信側で楽音を発音させることが広く行われている。
【０００３】
従来における音楽情報の送信は、例えば送信側がノートオンやノートオフといったイベントのデータ（ＭＩＤＩデータ）を、それを処理させるタイミングで受信側に順次送信することで行われている。しかし、そのような音楽情報の送信では、送信側の負荷の重さや、イベントデータを送る送信路等によって受信側がイベントデータを受信するタイミングが遅れ、演奏にズレが生じることがあるという問題点があった。
【０００４】
演奏（楽音の発音タイミング等）のズレは、その演奏から受ける印象を大きく変化させることが多く、音楽的な影響が大きい。そのため、演奏のズレが生じないようにすることは強く要請されている。
【０００５】
現在ではパーソナルコンピュータをシーケンサ（自動演奏装置）として用いることも一般的に行われており、様々な送信路を利用することができる状況となっている。周知のように、送信路によって送信に要する時間（送信時間）も様々に変化する。それ以外にも、送受信の過程で音楽情報（の一部）が消えたり、或いは、受信側で音楽情報（の一部）を正常に受信できないようなこともある。
【０００６】
音楽情報の送受信の過程により、上記したようなことが生じても、受信側での演奏に大きな影響を及ぼし、音楽的に大きな不具合を発生させる。そのため、これからは、イベントデータ（音楽情報）の送受信の過程により生じる音楽的な不具合の発生を回避できるようにする要請が高まることが予想される。
【０００７】
本発明の課題は、音楽情報の送受信の過程により生じる音楽的な不具合の発生を回避できるようにすることにある。
【０００８】
【課題を解決するための手段】
本発明の音楽情報受信処理方法は、ノートオン、ノートオフ等のイベントの内容を表すイベントデータに、該イベントデータを処理すべきタイミングを表す時間データを付加したイベントデータを音楽情報として順次送信する音楽情報送信装置によって送信された音楽情報を受信しながら処理していくことを前提とする。
【００１３】
第１の態様の音楽情報受信処理方法は、現在時間をカウントする第１の工程と、音楽情報を受信する第２の工程と、記第２の工程で音楽情報が受信される度に第１の工程でカウントされた現在時間と第２の工程で受信した音楽情報中の時間データとの差時間を求め、求められた差時間が所定値を超える場合に、当該差時間に基づいた補正時間を生成する第３の工程と、第２の工程で音楽情報が受信される度に第３の工程で生成された補正時間と差時間との差を抽出するとともに、当該差の所定数分の平均を求める第４の工程と、第４の工程で求められた差の平均の値に基づいて第３の工程で生成された補正時間を変更する第５の工程と、記第２の工程にて受信された音楽情報のイベントデータに付加された時間データを補正時間に基づいて変更するとともに、当該変更された時間データに基づいてイベントデータを処理すべきタイミングを決定する第６の工程と、第６の工程で決定したタイミングに従って、第２の工程で受信した音楽情報中のイベントデータを処理する第７の工程と、を有する。
【００１５】
本発明の第２の態様の音楽情報受信処理方法は、音楽情報を受信する第１の工程と、第１の工程で受信した音楽情報を所定の記憶手段に記憶させる第２の工程と、第１の工程で受信した音楽情報中のイベントデータを処理するタイミングを、該イベントデータに付加された時間データ、及び記憶手段の空容量に基づいて決定する第３の工程と、第３の工程で決定したタイミングに従って、第１の工程で受信した音楽情報中のイベントデータを処理する第４の工程と、を有する。
【００１７】
本発明の第１の態様の音楽情報受信処理装置は、ノートオン、ノートオフ等のイベントの内容を表すイベントデータに、該イベントデータを処理すべきタイミングを表す時間データを付加したイベントデータを音楽情報として順次送信する音楽情報送信装置によって送信された音楽情報を受信しながら処理していくことで演奏を行うことを前提とした装置であって、現在時間をカウントする現時刻カウント手段と、音楽情報を受信する受信手段と、受信手段で音楽情報が受信される度に現時刻カウント手段でカウントされた現在時間と受信した音楽情報中の時間データとの差時間を求め、求められた差時間が所定値を超える場合に、当該差時間に基づいた補正時間を生成する補正時間生成手段と、受信手段で音楽情報が受信される度に生成された補正時間と差時間との差を抽出するとともに、当該差の所定数分の平均を求める平均手段と、平均手段で求められた差の平均の値に基づいて補正時間生成手段で生成された補正時間を変更する変更手段と、記受信された音楽情報のイベントデータに付加された時間データを前記補正時間に基づいて変更するとともに、当該変更された時間データに基づいてイベントデータを処理すべきタイミングを決定するタイミング決定手段と、タイミング決定手段で決定したタイミングに従って、受信した音楽情報中のイベントデータを処理する処理手段と、を具備する。
【００１９】
本発明の第２の態様の音楽情報受信処理装置は、ノートオン、ノートオフ等のイベントの内容を表すイベントデータに、該イベントデータを処理すべきタイミングを表す時間データを付加したイベントデータを音楽情報として順次送信する音楽情報送信装置によって送信された音楽情報を受信しながら処理していくことで演奏を行うことを前提とした装置であって、音楽情報を受信する受信手段と、受信手段が受信した音楽情報を記憶する記憶手段と、受信手段が受信した音楽情報中のイベントデータを処理するタイミングを、該イベントデータに付加された時間データ、及び記憶手段の空容量に基づいて決定するタイミング決定手段と、タイミング決定手段が決定したタイミングに従って、記憶手段に記憶された音楽情報中のイベントデータを処理する処理手段と、を具備する。
【００２５】
本発明の第１の態様の記憶媒体は、コンピュータを、現在時間をカウントする現時刻カウント手段と、ノートオン、ノートオフ等のイベントの内容を表すイベントデータ毎に、該イベントデータを処理すべきタイミングを表す時間データが付加されたイベントデータを音楽情報として順次送信する音楽情報送信装置によって送信された音楽情報を受信する手段と、受信手段で音楽情報が受信される度に現時刻カウント手段でカウントされた現在時間と受信した音楽情報中の時間データとの差時間を求め、求められた差時間が所定値を超える場合に、当該差時間に基づいた補正時間を生成する補正時間生成手段と、受信手段で音楽情報が受信される度に生成された補正時間と差時間との差を抽出するとともに、当該差の所定数分の平均を求める平均手段と、平均手段で求められた差の平均の値に基づいて補正時間生成手段で生成された補正時間を変更する変更手段と、受信された音楽情報のイベントデータに付加された時間データを補正時間に基づいて変更するとともに、当該変更された時間データに基づいてイベントデータを処理すべきタイミングを決定するタイミング決定手段と、タイミング決定手段で決定したタイミングに従って、受信した音楽情報中のイベントデータを処理する処理手段と、として機能させるためのプログラムを記録している。
【００２６】
本発明の第２の態様の記憶媒体は、コンピュータを、ノートオン、ノートオフ等のイベントの内容を表すイベントデータ毎に、該イベントデータを処理すべきタイミングを表す時間データが付加されたイベントデータを音楽情報として順次送信する音楽情報送信装置によって送信された音楽情報を受信する手段と、受信する手段によって受信された音楽情報を記憶手段に記録させる手段と、受信する手段により受信された音楽情報中のイベントデータを処理するタイミングを、該イベントデータに付加された時間データ、及び記憶手段の空容量に基づいて決定する手段と、決定する手段によって決定されたタイミングに従ってイベントデータを処理する手段と、として機能させるためのプログラムを記録している。
【００３１】
本発明では、受信した音楽情報中の時間データから、該時間データが付加されたイベントデータを処理すべきタイミングを決定し、受信した音楽情報中のイベントデータを決定したタイミングに従って処理する。そのように、時間データを基にイベントデータを処理することから、受信したタイミングに関わらずにイベントデータを適切なタイミングで処理する、或いはイベントデータをより適切なタイミングで処理することが可能となる。
【００３２】
本発明では、受信した音楽情報中の時間データ、及びその音楽情報を記憶する記憶手段（音楽情報の格納用に割り当てられた記憶領域）の空容量に基づき、該時間データが付加されたイベントデータを処理すべきタイミングを決定し、そのタイミングに従って処理する。記憶手段の空容量を考慮してタイミングを決定することで、それに記憶させた音楽情報を確実に処理することが可能となる。
【００３５】
【発明の実施の形態】
以下、図面を参照しながら、本発明の実施の形態につき詳細に説明する。
＜第１の実施の形態＞
図１は、本実施の形態による音楽情報送受信装置の構成図である。本実施の形態による音楽情報送受信装置は、鍵盤等の演奏操作子群を備えた各種のコントローラや電子楽器といった外部の装置から出力された音楽（演奏）情報を入力し、それを他の外部の装置に出力する装置として実現されている。
【００３６】
その音楽情報送受信装置は、図１に示すように、装置全体の制御を行うＣＰＵ１０１と、プログラムや各種制御用データ等を格納したＲＯＭ１０２と、ＣＰＵ１０１が作業用に用いるＲＡＭ１０３と、特には図示しない外部の装置、例えば他の楽音情報送受信装置との間でデータの送受信を行う送受信装置１０４と、特には図示しないケーブルで接続された電子キーボード１１１が出力したＭＩＤＩデータを入力するＭＩＤＩ入力装置１０５と、時間を計時するタイマ１０６と、特には図示しないケーブルで接続された音源装置１１２にＭＩＤＩデータを出力するＭＩＤＩ出力装置１０７と、を備えて構成されている。
【００３７】
以上の構成において、その動作を説明する。
不図示の電源がオンされると、ＣＰＵ１０１はＲＯＭ１０２に格納されたプログラムを読み出して実行することにより、装置全体の制御を開始する。その後は、特には図示しない各種スイッチへのユーザの操作や電子キーボード１１１から受け取ったＭＩＤＩデータに応じて、ＲＡＭ１０３を作業用に使用しながら、ユーザが要求した機能を実現するための制御を行う。
【００３８】
電子キーボード１１１は、それが備えた鍵盤（キーボード）や各種スイッチに対してユーザが行った操作内容を、ＭＩＤＩデータの形でＭＩＤＩ入力装置１０５に出力（通知）する。ＣＰＵ１０１は、そのようにしてＭＩＤＩ入力装置１０５に入力されたＭＩＤＩデータを、ユーザの設定（指定）に応じてＭＩＤＩ出力装置１０７から音源装置１１２に出力させるか、或いは送受信装置１０４から他の音楽情報送受信装置に送信させる。
【００３９】
ユーザがＭＩＤＩ出力装置（音源装置１１２）１０７を指定した場合、ＣＰＵ１０１は、ＭＩＤＩ入力装置１０５がＭＩＤＩデータを入力する度に、そのＭＩＤＩデータを直ちにＭＩＤＩ出力装置１０７に送って音源装置１１２に出力させる。それにより、ユーザの電子キーボード１１１への操作に応じて音源装置１１２から楽音をリアルタイムに発音させる。
【００４０】
一方、ユーザが送受信装置１０４（例えば他の音楽情報送受信装置）を指定した場合には、例えばその指定が行われた時点でタイマ１０６を起動させるとともに、送信させるデータを一時格納しておく領域をＲＡＭ１０３内に確保する。その後は、ＭＩＤＩ入力装置１０５がＭＩＤＩデータを入力する度に、そのＭＩＤＩデータが入力したタイミングを表す時間データをタイマ１０６の値から生成し、その時間データとＭＩＤＩデータを１イベント分のデータとしてＲＡＭ１０３内に確保した領域に一旦格納しつつ、その領域にそれまでに格納した未送信分のデータを送受信装置１０４から送信させることを繰り返す。その時間データは、受信側ではＭＩＤＩデータを処理すべきタイミングを指定しているものとして扱われる。
【００４１】
その送受信装置１０４は、シリアルの送信経路に対応させるために、データをビット列に置換して直列に送信するようになっている（受信時はその逆）。そのようにして送信されたデータが、ケーブル、更には所定の通信回線（例えば公衆網）を介して外部の装置に送られる。以降、混乱を避けるために、その外部の装置は他の音楽情報送受信装置であるとして説明することにする。
【００４２】
なお、本実施の形態では、ＭＩＤＩデータが入力したタイミングを、直前のＭＩＤＩデータが入力されてから経過した時間（デルタタイム）で表す方法を採用している。その時間を表す値である時間データについては、以降、時間長データと呼ぶことにする。その時間長データは例えば２バイトのデータである。
【００４３】
送受信装置１０４は、他の音楽情報送受信装置にデータを送信する他に、それから送信されたデータを受信する。ＣＰＵ１０１は、送受信装置１０４が受信したデータを、例えば以下のように処理する。
【００４４】
送受信装置１０４が受信するデータは、上記したように、ＭＩＤＩデータに時間長データが付加されたものである。時間長データによって指定されたタイミングでＭＩＤＩデータを処理するために、ＣＰＵ１０１は、例えばデータの受信をユーザが指示した時点でタイマ１０６を起動するとともに、受信したデータを一時的に格納しておく領域をＲＡＭ１０３内に確保する。その後は、データを受信する度に、それをＲＡＭ１０３内に確保した領域に格納しつつ、時間長データからＭＩＤＩデータを処理すべきタイミングの時刻、即ちタイマ１０６の値を特定する一方、その特定したタイミングとなったＭＩＤＩデータを、ＭＩＤＩ出力装置１０７を介して音源装置１１２に出力する。それにより、音源装置１１２に楽音を発音させて演奏を行わせる。
【００４５】
このようにして、受信側は、時間長データで指定されたタイミングでＭＩＤＩデータを処理する。そのため、送信側はＭＩＤＩデータを適切なタイミングで送信する必要がなくなり、送信路等による遅延を考慮して早めにＭＩＤＩデータを送信することができるようになる。一方、ＭＩＤＩデータを送信するタイミングは、送信側はイベントのデータを一旦ＲＡＭ１０３に格納することから、そこから読み出すタイミングで変更することができる。これらのことから、受信側は常に時間長データで指定されたタイミングでＭＩＤＩデータを処理することができるようになり、演奏のズレは確実に回避されることになる。
【００４６】
ところで、例えば和音（コード）では、普通、それを構成する複数の楽音の発音タイミングが基本的には同時となる。従って、音楽情報をシリアルに送信すると、それらのイベントデータを送信する時点で既にタイミングにズレが生じることになる。そのズレは、通常はさほど問題にはならない。しかし、例えばマルチトラックの演奏時に複数のトラックで和音（コード）のようなイベントが重なり合うと、換言すれば、あるタイミングで送信すべきイベントデータの数が多くなると、それらを全て送信するのにより長い時間が必要となることから、送信時のズレが大きくなる。
【００４７】
上記のような状況で発生するズレは、処理させるべきタイミングで音楽情報（ＭＩＤＩデータ）を送信していく従来の方法では回避することはできない。しかし、本実施の形態では、上記したように、必ずしも処理させるべきタイミングで音楽情報（ＭＩＤＩデータ）を送信しなくとも良いことから、従来の方法では回避できなかったズレの発生も容易、且つ確実に回避することができる。
【００４８】
一方、音楽情報（ＭＩＤＩデータ）を受信してからそれを実際に処理するまでに要する処理時間は、装置によって異なる。このため、複数の装置に音楽情報を送信する場合には、送信側が適切なタイミングで音楽情報（ＭＩＤＩデータ）を送信しても、各装置毎に異なる演奏のズレが生じることがある。
【００４９】
音楽情報（ＭＩＤＩデータ）を受信してからそれを実際に処理するまでの工程は、音楽情報（ＭＩＤＩデータ）を受信する工程と、それを処理する工程とに大別することができる。本実施の形態では、処理させるべきタイミングの前に音楽情報（ＭＩＤＩデータ）を送信できる。そのため、少なくとも前者の工程に要する時間が演奏に影響するのを回避することができる。その結果、複数の異なる装置に音楽情報を送信する場合であっても、装置毎の演奏のズレをより抑えることができる。
【００５０】
次に、上記したＣＰＵ１０１の動作について、図２〜図９に示す動作フローチャートを参照して詳細に説明する。それらにフローチャートで示す処理は、ＣＰＵ１０１がＲＯＭ１０２からプログラムを読み出して実行することにより実現される。
【００５１】
図２〜図５は、送信処理の動作フローチャートである。この送信処理は、上記したように、ユーザが所定のスイッチを操作して送受信装置１０４からＭＩＤＩデータ（音楽情報）を送信させることを指定した場合に実行される。
【００５２】
先ず、ステップ２０１では、イニシャライズを行う。そのイニシャライズとしては、例えばタイマ１０６の起動、ＲＡＭ１０３に保持させる各種変数への初期値の代入、送信するデータを一時格納しておくＲＡＭ１０３内の領域の確保を行い、送受信装置１０４には受信側との回線の接続等を行わせる。それが終了した後、ステップ２０２に移行する。なお、データの送信用、或いは受信用にＲＡＭ１０３に確保した領域については、以降、送受信用領域と呼ぶことにする。
【００５３】
ステップ２０２では、電子キーボード１１１からＭＩＤＩデータが入力されたか否か判定する。ユーザが電子キーボード１１１に対して何らかの操作を行った場合、電子キーボード１１１はＭＩＤＩデータを出力することから判定がＹＥＳとなってステップ２０３に移行する。そうでない場合には、その判定はＮＯとなって図５のステップ２２４に移行する。なお、ＭＩＤＩ入力装置１０５がＭＩＤＩデータを入力したことは、例えばその旨を表す割り込み信号によってＣＰＵ１０１に通知される。
【００５４】
ステップ２０３〜ステップ２２３では、ＭＩＤＩ入力装置１０５がＭＩＤＩデータを入力したことに伴う処理が行われる。
先ず、ステップ２０３では、タイマ１０６の現在値の読み込みを行う。その読み込んだ値は変数ＴＩＭＥＲに代入し、続くステップ２０４では、新たに入力されたＭＩＤＩデータがその直前のＭＩＤＩデータが入力されてから経過した時間を算出し、その算出結果（時間長データ）を変数ＳＵＢＵＮに代入する。現在のタイマ１０６の値は変数ＴＩＭＥＲに、直前のＭＩＤＩデータが入力された際のタイマ１０６の値は変数ＦＴＩＭＥＲに代入されている。そのため、変数ＳＵＢＵＮには、変数ＴＩＭＥＲの値から変数ＦＴＩＭＥＲの値を減算した値が代入される。
【００５５】
なお、最初のＭＩＤＩデータの入力、即ちステップ２０４の実行が１回目であった場合には、ステップ２０１で変数ＦＴＩＭＥＲに０を代入し、タイマ１０６はユーザが送信先を指定した際に起動したとすると、変数ＳＵＢＵＮには送信先を指定してから電子キーボード１１１に何らかの操作を行うまでの時間（を表す値）が代入されることになる。
【００５６】
変数ＳＵＢＵＮに新たな値を代入した後は、ステップ２０５に移行して、変数ＴＩＭＥに変数ＳＵＢＵＮの値を代入する。続くステップ２０６では、変数ＷＲＩＴＥＣＯＵＮＴＥＲの値から、ＲＡＭ１０３の送受信用領域にデータを格納するアドレスを特定する。その後、ステップ２０７に移行する。
【００５７】
本実施の形態では、ＲＡＭ１０３の送受信用領域に、送信させるデータ、或いは受信したデータを先頭から順次格納していき、その領域にデータを全て格納した場合には、再度先頭から格納していくようにしている。上記変数ＷＲＩＴＥＣＯＵＮＴＥＲは、送受信用領域内において次のデータの格納先を管理するための変数である。データの読み出し先の管理用の変数は、変数ＲＥＡＤＣＯＵＮＴＥＲである。変数ＴＩＭＥは、時間長データを保持しておくための変数である。
【００５８】
ステップ２０７では、変数ＷＲＩＴＥＣＯＵＮＴＥＲの値と変数ＲＥＡＤＣＯＵＮＴＥＲの値とが等しくないか否か判定する。送信させるデータは送受信用領域内に一旦格納した後に送信させている。その領域に未送信分のデータが残っていないときにはそれらの変数の値は等しくなる。そのため、未送信分のデータが送受信用領域に残っていない場合、ステップ２０７の判定はＮＯとなって図４のステップ２１８に移行する。そうでない場合には、その判定はＹＥＳとなってステップ２０８に移行する。
【００５９】
図４のステップ２１８〜２２３では、新たなＭＩＤＩデータの入力に伴って送受信用領域に１イベント分のデータを格納するための処理が行われる。その１イベント分のデータは、ＭＩＤＩデータ、及び時間長データから構成される。
【００６０】
先ず、ステップ２１８では、変数ＷＲＩＴＥＣＯＵＮＴＥＲの値によって指定（特定）される送受信用領域内の格納先に、ステップ２０５で変数ＴＩＭＥに代入した時間長データ及びＭＩＤＩデータを書き込む。それが終了した後、ステップ２１９〜２２２で形成される処理ループを実行し、予め定めた上限値（送受新領域の大きさに対応する値である）を超えるときには０を代入しつつ、変数ＷＲＩＴＥＣＯＵＮＴＥＲの値の更新（カウントアップ）を、ステップ２１８で格納したデータのバイト数分だけ行う。
【００６１】
時間長データは２バイト、１イベント分のＭＩＤＩデータは通常２、３バイトである。そのため、普通、１イベントで変数ＷＲＩＴＥＣＯＵＮＴＥＲの値は４、５回更新（カウントアップ）されることになる。そのことから、送受信用領域は１バイトで表現できる大きさ（例えば１２８バイト）としても、そこには少なくとも２０イベント分以上のデータを格納でき、送信タイミングを調整するうえでは十分な時間を確保することができるようになる。そのため、本実施の形態では、変数ＷＲＩＴＥＣＯＵＮＴＥＲ、ＲＥＡＤＣＯＵＮＴＥＲの有効ビット数も８ビットとし、ＭＩＤＩの規格に合わせている。それにより、ＲＡＭ１０３に必要な記憶容量を抑えるとともに、後述する１イベント当たりに送信するデータ量も必要最小限に抑えるようにしている。
【００６２】
上記バイト数分の更新（カウントアップ）が終了すると、ステップ２２２の判定がＹＥＳとなって処理ループを抜け、ステップ２２３に移行する。そのステップ２２３では、変数ＦＴＩＭＥＲに変数ＴＩＭＥＲの値を代入、即ち変数ＦＴＩＭＥＲに現在時刻を表す値を代入してその値を更新する。その後、図２のステップ２０２に戻る。
【００６３】
一方、図２のステップ２０８〜図３のステップ２１７では、送受信用領域に格納されている未送信分のデータの送信に関わる処理が行われる。
先ず、ステップ２０８〜２１０では、現在の変数ＲＥＡＤＣＯＵＮＴＥＲの値、時間長データ、及びＭＩＤＩデータを１イベント分のデータ（上記したように、通常は５、６バイトである）として送信する。詳細については後述するが、変数ＲＥＡＤＣＯＵＮＴＥＲの値は、データの送受信が正常に行われているか否かを判定するために制御データとして送信しているものである。それが終了した後、図３のステップ２１１に移行する。なお、データの送信は、例えばＣＰＵ１０１が、それらを送受信装置１０４内のバッファに書き込むことで行われる。
【００６４】
図３のステップ２１１〜２１４で形成される処理ループでは、変数ＷＲＩＴＥＣＯＵＮＴＥＲのときと同様に、予め定めた上記の上限値を超えるときには０を代入するようにしつつ、変数ＲＥＡＤＣＯＵＮＴＥＲの値の更新（カウントアップ）を、ステップ２０８〜２１０で送信したデータのバイト数分だけ行う。そのバイト数分の更新（カウントアップ）が終了すると、ステップ２１４の判定がＹＥＳとなって処理ループを抜け、ステップ２１５に移行する。
【００６５】
ステップ２１５では、ステップ２０８〜２１０で送信したデータが最初のＭＩＤＩデータであるか否か判定する。そのステップ２１５は、ＭＩＤＩデータを送信した後に実行される。演奏フラグは、演奏中か否かを管理するための変数であり、ステップ２０１のイニシャライズで０が初期値として代入される。そのため、例えば変数フラグの値が０であった場合、その判定がＹＥＳとなってステップ２１６に移行する。そうでない場合には、即ち演奏フラグの値が１であった場合には、その判定はＮＯとなって図２のステップ２０７に戻る。
【００６６】
ステップ２１６では、受信側に演奏の開始を指示する演奏開始コードを送信する。続くステップ２１７では、演奏フラグに１を代入する。それが終了した後、図２のステップ２０７に戻る。
【００６７】
上記した処理ステップまでの処理動作を要約すると、以下のようになる。
最初のＭＩＤＩデータを入力したときには、変数ＷＲＩＴＥＣＯＵＮＴＥＲの値と変数ＲＥＡＤＣＯＵＮＴＥＲの値とは等しいことから、ステップ２０７の判定はＮＯとなって、送受信用領域にそのＭＩＤＩデータが時間長データとともに送受信用領域に格納される。
【００６８】
次のＭＩＤＩデータが入力したときには、それらの変数の値は異なっていることから、ステップ２０７の判定はＮＯとなって、送受信用領域に格納されている未送信分のデータの送信が行われる。データの送信は、イベント単位で行い、１イベント分のデータの送信が終了すると、ステップ２０７に戻る。そのため、データの送信は、ステップ２０７の判定がＮＯとなるまで繰り返し行われる。
【００６９】
そのようなデータの送信を行った結果、ステップ２０７の判定がＮＯとなると、新たに入力されたＭＩＤＩデータと時間長データとを送受信用領域に格納する。その格納が終了すると、ステップ２０２に戻る。そのため、それ以降は、新たにＭＩＤＩデータが入力する度に、未送信分のデータを送信した後、次に送信すべきデータを送受信用領域に格納するという動作を同様に繰り返すことになる。
【００７０】
図２の説明に戻って、ＭＩＤＩデータの新たな入力がなかった場合の動作について説明する。ＭＩＤＩデータの新たな入力がなかった場合には、ステップ２０２の判定がＮＯとなって図５のステップ２２４に移行する。
【００７１】
そのステップ２２４では、タイマ１０６の現在値の読み込み、その値を変数ＴＩＭＥＲに代入する。続くステップ２２５では、変数ＴＩＭＥＲの値から変数ＦＴＩＭＥＲの値を減算した値、即ち直前のＭＩＤＩデータが入力されてから経過した時間（を表す値）を変数ＳＵＢＵＮに代入する。その後、ステップ２２６に移行する。
【００７２】
本実施の形態では、予め定めた時間内にＭＩＤＩデータが入力されなかった場合、データの送信を中止し、外部の装置による演奏を停止させるようにしている。これは、ＭＩＤＩデータの入力（ユーザの電子キーボード１１１への操作）に応じてデータの送信を行うようにしていることから、ＭＩＤＩデータの入力間隔が開いても、受信側にＭＩＤＩデータを処理すべきタイミングより遅れて送信するようなことを回避するためである。その機能は、ステップ２２６〜２２９を実行することで実現される。
【００７３】
ステップ２２６では、変数ＳＵＢＵＮの値が予め定めた時間に対応する所定値より大きいか否か判定する。ユーザが電子キーボード１１１の操作をその時間以上行わなかった場合、その判定はＹＥＳとなってステップ２２７に移行する。そうでない場合には、その判定はＮＯとなって図２のステップ２０２に戻る。
【００７４】
ステップ２２７では、受信側に演奏の停止を指示する演奏停止コードを送信する。続くステップ２２８では、演奏フラグに０を代入する。演奏フラグに０を代入すると、ステップ２２９でＲＡＭ１０３内の不必要なデータの消去といったイニシャライズを行った後、一連の処理を終了する。
【００７５】
このようにして、電子キーボード１１１から出力されたＭＩＤＩデータは、時間長データが付加されるとともに、ＲＡＭ１０３を利用したタイミングの調整を行って送信される。
【００７６】
次に、上記のようにして送信されるデータの受信処理について、図６〜図９に示すその動作フローチャートを参照して詳細に説明する。その受信処理は、例えば送信処理と同様に、ユーザが所定のスイッチを操作して送受信装置１０４から音楽情報を取得するのを指定した場合に実行される。
【００７７】
先ず、ステップ６０１では、イニシャライズを行う。そのイニシャライズとしては、例えばタイマ１０６の起動、ＲＡＭ１０３に保持させる各種変数への初期値の代入、受信したデータを一時格納しておく送受信用領域をＲＡＭ１０３内に確保といったことを行う。それが終了した後、ステップ６０２に移行する。
【００７８】
ステップ６０２では、送受信装置１０４がデータを新たに受信していないか否か判定する。送受信装置１０４がデータを受信していた場合、その判定はＮＯとなって図８のステップ６１６に移行する。そうでない場合には、その判定はＹＥＳとなってステップ６０３に移行する。なお、データの受信は、例えば送受信装置１０４が、その旨を示す割り込み信号を出力することにより、ＣＰＵ１０１に通知される。
【００７９】
図８のステップ６１６〜６２６では、送受信装置１０４がデータを受信したことに伴う処理が行われる。
先ず、ステップ６１６では、受信したデータが演奏開始コードか否か判定する。送受信装置１０４がその演奏開始コードを受信した場合、その判定はＹＥＳとなってステップ６１７に移行する。そうでない場合には、その判定はＮＯとなってステップ６１８に移行する。
【００８０】
ステップ６１７では、演奏開始コードを受信したことから、演奏中か否かを管理するための演奏フラグに１を代入する。演奏開始コードは、上述したように、最初のイベントのデータを送信した後に送信される。そのために、続くステップ６１７−１では、既に格納されている最初のイベントの時間長データを読み込む。更には、続くステップ６１７−２において、その時間長データが付加されたＭＩＤＩデータを処理するタイミングの時刻を、変数である現在時刻カウンタに代入する。具体的には、現在時刻カウンタに、時間長データと変数ＴＩＭＥＲ（タイマ１０６の現在値）を加算した値を代入する。それが終了した後、図６のステップ６０３に戻る。
【００８１】
ステップ６１８では、データとしてイベントのデータを受信したか否か判定する。イベントのデータを受信した場合、その判定はＹＥＳとなってステップ６１９に移行する。そうでない場合には、即ち演奏開始コードやイベントのデータ以外のデータを受信した場合には、その判定はＮＯとなって図６のステップ６０３に戻る。
【００８２】
上記したように、１イベント分のデータは、変数ＲＥＡＤＣＯＵＮＴＥＲの値、時間長データ、ＭＩＤＩデータの順序で送信される。ＭＩＤＩデータの先頭はステータスバイトであり、その最上位ビットの値は１である。そのステータスバイトからＭＩＤＩデータ全体、更には１イベント分として送信されたデータの総バイト数が特定される。このことから、本実施の形態では、先頭から３バイト目のデータの最上位ビットの値が１、即ちステータスバイトで、且つそのステータスバイトから特定したバイト数のデータを受信した場合に、イベントのデータを受信したと判定している。
【００８３】
ステップ６１９では、変数ＷＲＩＴＥＣＯＵＮＴＥＲの値を読み込む。続くステップ６２０では、その変数の値が受信した変数ＲＥＡＤＣＯＵＮＴＥＲの値より大きいか否か判定する。変数ＷＲＩＴＥＣＯＵＮＴＥＲの値が受信した変数ＲＥＡＤＣＯＵＮＴＥＲの値より大きかった場合、その判定はＹＥＳとなって図９のステップ６２７に移行する。そうでない場合には、その判定はＮＯとなってステップ６２１に移行する。
【００８４】
ステップ６２１では、変数ＲＥＡＤＣＯＵＮＴＥＲの値が受信した変数ＲＥＡＤＣＯＵＮＴＥＲの値より大きいか否か判定する。変数ＲＥＡＤＣＯＵＮＴＥＲの値は送信側より受信側のほうが大きい場合、その判定はＹＥＳとなって図９のステップ６２７に移行する。そうでない場合には、その判定はＮＯとなってステップ６２２に移行する。
【００８６】
そのステップ６２７では、エラーが発生していることから、ＭＩＤＩ出力装置１０７を介して音源装置１１２に発音中の全ての楽音の消音（クリア）を指示する。全ての楽音の消音を指示すると、次に、ステップ６２８、６２９で形成される処理ループを実行して、演奏停止コードを受信するのを待つ。
【００８７】
演奏停止コードを受信すると、ステップ６２９の判定がＹＥＳとなってその処理ループを抜けてステップ６３０に移行する。そのステップ６３０では、ＲＡＭ１０３に保持させた各種変数や送受信用領域のクリアといったイニシャライズを行い、その後に一連の処理を終了する。
【００８８】
このように、エラーが発生した場合には、直ちに演奏を停止させている。そのため、エラーによって演奏に実際には発音されない楽音が発音されたり、何らかの楽音の発音が鳴りっぱなしになるといったことが回避される。
【００８９】
なお、本実施の形態では、制御データである変数ＲＥＡＤＣＯＵＮＴＥＲの値を各イベント毎に付加して送信しているが、例えば１０イベント毎といったように、ある決められた数のイベントのデータを送信する毎に制御データを送信するようにしても良い。制御データとしては、送信間隔をイベントといった単位で予め決めておくような場合には、本実施の形態のように、データの送信量を表す値としなくとも良い。
【００９０】
エラーの検出においては、送信側が送信した変数ＲＥＡＤＣＯＵＮＴＥＲの値が、受信側の変数ＷＲＩＴＥＣＯＵＮＴＥＲの値や変数ＲＥＡＤＣＯＵＮＴＥＲの値以下か否かによりエラーの検出を行っているが、それ以外の方法によってエラーを検出するようにしても良い。例えばデータが途中で消えるといったエラーも検出できるように、例えば変数ＷＲＩＴＥＣＯＵＮＴＥＲの値が受信した送信側の変数ＲＥＡＤＣＯＵＮＴＥＲの値よりも小さい（正常時と比較して）場合にもエラーが発生したと判定して良い。
【００９１】
一方、ステップ６２１の判定がＮＯ、即ちデータの送受信が正常と判定したときに実行されるステップ６２２では、変数ＲＥＡＤＣＯＵＮＴＥＲの値以外に受信した時間長データ及びＭＩＤＩデータを、変数ＷＲＩＴＥＣＯＵＮＴＥＲの値によって指定される送受信用領域の格納先に書き込む。それが終了した後、ステップ２１９〜２２２で形成される処理ループを実行し、予め定めた上限値（送受新領域の大きさに対応する値である）を超えるときには０を代入しつつ、変数ＷＲＩＴＥＣＯＵＮＴＥＲの値の更新（カウントアップ）を、ステップ２１８で格納したデータのバイト数分だけ行う。その更新が終了すると、図６のステップ６０３に戻る。
【００９２】
そのステップ６０３では、演奏フラグの値が１か否か判定する。送信側から演奏開始コードが送信、或いは既に送信されていた場合、その判定はＹＥＳとなってステップ６０４に移行する。そうでない場合には、その判定はＮＯとなってステップ６０２に戻る。
【００９３】
ステップ６０４では、タイマ１０６の現在値を読み込み、それを変数ＴＩＭＥＲに代入する。続くステップ６０５では、その変数ＴＩＭＥＲの値が、上記現在時刻カウンタの値よりも大きいか否か判定する。その現在時刻カウンタの値は、次のイベント（ＭＩＤＩデータ）を処理すべきタイマ１０６の値が代入されている変数である。そのため、次のイベントを処理すべきタイミングとなった場合には、その判定はＹＥＳとなってステップ６０６に移行する。そうでない場合には、即ち次のイベントを処理すべきタイミングがまだ来ていない場合には、その判定はＮＯとなってステップ６０２に戻る。
【００９４】
ステップ６０６では、次のイベントを処理すべきタイミングとなったことから、変数ＲＥＡＤＣＯＵＮＴＥＲの値を読み込み、続くステップ６０７では、その値に基づいて送受信用領域からＭＩＤＩデータを読み出す。それが終了した後、ステップ６０８に移行する。
【００９５】
ステップ６０８では、ステップ６０７で読み出したデータの種類を判別し、その判別結果に応じて処理の移行先を決定する。具体的には、読み出したデータが演奏停止コードであった場合はステップ６０１に戻り、読み出すべきデータが格納されていなかった場合はステップ６０２に戻り、読み出したデータがＭＩＤＩデータであった場合にはステップ６０９に移行する。読み出すべきデータが格納されていなかった場合にステップ６０２に戻ることで、その場合には変数ＲＥＡＤＣＯＵＮＴＥＲの値の更新（カウントアップ）を回避している。
【００９６】
ステップ６０９では、読み出したＭＩＤＩデータを、ＭＩＤＩ出力装置１０７を介して音源装置１１２に出力する。ＭＩＤＩデータを音源装置１１２に出力した後は図７のステップ６１０に移行する。
【００９７】
ステップ６１０〜６１３で形成される処理ループでは、変数ＲＥＡＤＣＯＵＮＴＥＲの値が予め定めた上記の上限値を超えるときには０を代入するようにしつつ、変数ＲＥＡＤＣＯＵＮＴＥＲの値の更新（カウントアップ）を、ステップ６０９で処理したイベントのバイト数分だけ行う。そのバイト数分の更新（カウントアップ）が終了すると、ステップ６１３の判定がＹＥＳとなって処理ループを抜け、ステップ６１４に移行する。ステップ６１４に移行時には、変数ＲＥＡＤＣＯＵＮＴＥＲの値は次に処理すべきイベントのデータの先頭バイトを指定する値となる。
【００９８】
ステップ６１４では、その変数ＲＥＡＤＣＯＵＮＴＥＲの値によって指定されるイベントの時間長データを送受信用領域から読み込む。続くステップ６１５では、その読み込んだ時間長データを用いて現在時刻カウンタの更新を行う。具体的には、変数ＴＩＭＥＲの値（タイマ１０６の現在値）に、読み込んだ時間長データを加算した値を現在時刻カウンタに代入する。それが終了した後、図２のステップ６０２に戻る。
【００９９】
このように、受信処理を実行することで、送信側が送信したイベント単位のデータは送受信用領域に一旦格納され、その格納したデータは、それに含まれている時間長データに従って処理される。それにより、受信したタイミングによって発生する演奏のズレは確実に回避される。
【０１００】
なお、本実施の形態では、電子キーボード１１１からＭＩＤＩデータが入力したタイミングで未送信分のデータを送信するようにしているが、データを送信するタイミングの取り方はこれに限定されるものではない。例えば、時間長データを基に、受信側が処理すべきタイミングより予め定めた時間だけ早く受信するようにデータを送信しても良い。或いは、最初のイベントのデータだけをある程度遅らせ、それ以外のイベントのデータは、入力後直ちに送信するようにしても良い。これらのように、データを送信するタイミングの取り方には様々な方法があることから、特に限定されるものではない。
【０１０１】
また、本実施の形態では、ユーザの演奏操作に応じて電子キーボード１１１が出力するＭＩＤＩデータ（イベントデータ）を送信するようにしているが、本発明は随時入力されるデータの送信に限定されるものでもない。イベントデータに時間長データが予め付加されている自動演奏用の音楽情報の送信に、本発明を適用しても良い。
＜第２の実施の形態＞
最近では、イベントデータにそれの処理の実行を制御するための第１の制御データを加えて処理単位となるデータ（命令）列を構成し、その処理単位のデータ列の実行を制御するための第２の制御データを更に加えて自動演奏用の演奏データ（音楽情報）を構成することが提案されている（特願平６−１４９９５８号参照）。第２の実施の形態は、そのようにしてデータがモジュール化されている演奏データ（音楽情報）を受信して処理できるようにしたものである。
【０１０２】
第２の実施の形態における構成は、上記第１の実施の形態のそれと基本的に同じである。動作については、上記のような構成の演奏データを受信して処理できるようになっていることだけが第１の実施の形態から異なっている。そのため、第１の実施の形態で付与した符号をそのまま使用して、第１の実施の形態から異なっている動作のみ説明することとする。
【０１０３】
上記第１の制御データとしては、次に処理すべきイベントデータ（ＭＩＤＩデータ）、或いは第１の制御データを指定するジャンプ命令、主に分岐命令に用いられるレジスタを対象とした演算命令等がある。第２の制御データとしては、処理単位のデータ（命令）列（以降、そのデータ（命令）列によって実行される処理をタスクと呼ぶ）の実行開始を指示する命令（タスク生成命令）、そのデータ（命令）列の実行終了を指示する命令（タスク終了命令）等がある。タスク生成命令によって実行の開始が指示された処理単位のデータ（命令）列は、処理対象としているタスクを時分割的に切り換えながら処理される。そのようにして各タスク（処理単位）のデータ（命令）列が処理されることから、タスク毎に演奏を行うタイミングや繰り返し等の設定が容易に行えるようになっている。
【０１０４】
上記したように、第２の実施の形態で受信するのを想定している演奏データ（音楽情報）はモジュール化され、また、ジャンプ命令等が用いることができるようになっている。そのため、送受信装置１０４を介したデータの受信を指示した場合、ＣＰＵ１０１は、１曲分の演奏データを格納できる大きさの送受信用領域をＲＡＭ１０３内に確保し、その送受信用領域に受信したデータを格納しつつ、それに格納されたデータをタスク別に順次時分割的に切り換えながら処理する。以降、図１０〜図１５を参照して、その動作について詳細に説明する。
【０１０５】
なお、特に詳細な説明は省略するが、上記演奏データの送信は、例えば第１の実施の形態における送信処理と同様に、最初に処理すべきイベントのデータ、演奏開始コードをこの順序で送信した後、処理すべきデータ或いはデータ列を順次シーケンシャルに送信していくことで進行する。それらデータ或いはデータ列には、ジャンプ命令等に受信側が対処できるように、それらの格納先を指示するアドレスの値も付加されている。
【０１０６】
図１０〜図１２は、第２の実施の形態による受信処理の動作フローチャートである。最初に、これら図１０〜図１２を参照して、受信処理について詳細に説明する。なお、その受信処理は、例えば第１の実施の形態と同様に、ユーザが所定のスイッチを操作して送受信装置１０４から演奏データ（音楽情報）を取得するのを指定した場合に、ＲＯＭ１０２に格納されたプログラムを実行することで実現される処理である。
【０１０７】
先ず、ステップ１００１では、イニシャライズを行う。そのイニシャライズとしては、例えばタイマ１０６の起動、ＲＡＭ１０３に保持させる各種変数への初期値の代入、受信したデータを格納しておく送受信用領域をＲＡＭ１０３に確保といったことを行う。それが終了した後、ステップ１００２に移行する。
【０１０８】
ステップ１００２では、送受信装置１０４がデータを新たに受信していないか否か判定する。送受信装置１０４がデータを受信していた場合、その判定はＮＯとなって図１２のステップ１０２０に移行する。そうでない場合には、その判定はＹＥＳとなってステップ１００３に移行する。なお、データの受信は、例えば送受信装置１０４が、その旨を示す割り込み信号を出力することにより、ＣＰＵ１０１に通知される。
【０１０９】
図１２のステップ１０２０〜１０３１では、送受信装置１０４がデータを受信したことに伴う処理が行われる。
先ず、ステップ１０２０では、受信したデータが演奏開始コードか否か判定する。送受信装置１０４がその演奏開始コードを受信した場合、その判定はＹＥＳとなってステップ１０２１に移行する。そうでない場合には、その判定はＮＯとなってステップ１０２４に移行する。
【０１１０】
ステップ１０２１では、演奏開始コードを受信したことから、演奏中か否かを管理するための演奏フラグに１を代入する。演奏開始コードは、上述したように、最初に処理すべきイベントデータ（ＭＩＤＩデータ）を送信した後に送信される。そのために、続くステップ１０２２では、既に格納されている最初のイベントの時間長データを読み込む。更には、ステップ１０２３において、その時間長データが付加されたＭＩＤＩデータを処理すべきタイミングの時刻を、変数である現在時刻カウンタに代入する。それが終了した後、図１０のステップ１００２に戻る。
【０１１１】
受信したデータをタスク別に処理していくために、第１の実施の形態とは異なり、データの読み出し先を管理するための変数ＲＥＡＤＣＯＵＮＴＥＲ、及び上記現在時刻カウンタを配列変数化している。現在処理対象としているタスクは変数であるタスクカウンタＴＣで管理しており、それらの配列変数もタスクカウンタＴＣによって管理されている。そのため、配列変数については、以降、それらの配列変数の最後には（ＴＣ）を付け加えることにする。
【０１１２】
一方、ステップ１０２４では、受信したのは演奏停止コードか否か判定する。送信側が演奏停止コードを送信した場合、その判定はＹＥＳとなってステップ１０２５に移行する。そうでない場合には、その判定はＮＯとなってステップ１０２７に移行する。
【０１１３】
ステップ１０２５では、演奏停止コードを受信したことから、演奏フラグに０を代入する。続くステップ１０２６では、ＲＡＭ１０３内の送受信用領域のクリアといったイニシャライズを行う。その後、一連の処理を終了する。このようにして、ステップ１０２５、それに続くステップ１０２６では、送信側からの演奏停止の指示に対処する処理が行われる。
【０１１４】
ステップ１０２４の判定がＹＥＳのときに移行するステップ１０２７では、演奏データを構成するデータを受信したか否か判定する。
上記したように、演奏データを構成するデータ（コマンド）は、大別して、イベントデータ、第１及び第２の制御データの３種類がある。それらのデータには、ジャンプ命令（第１の制御データ）等に受信側が対処できるように、送信側でそれを読み出したアドレスの値が付加されて送信されている。それらのデータの形式は予め定められている。そのため、変数ＲＥＡＤＣＯＵＮＴＥＲの値を含むデータを受信した場合、ステップ１０２４の判定はＹＥＳとなってステップ１０２８に移行する。そうでない場合には、その判定はＮＯとなって図１０のステップ１００２に戻る。
【０１１５】
ステップ１０２８では、受信したアドレスの値を変数ＷＲＩＴＥＣＯＵＮＴＥＲに書き込む。その変数ＷＲＩＴＥＣＯＵＮＴＥＲは、第１の実施の形態と同様に、データの書き込み先を管理するための変数である。
【０１１６】
ステップ１０２８に続くステップ１０２９では、受信したアドレスの値が変数ＷＲＩＴＥＣＯＵＮＴＥＲで示される最終アドレスの値よりも大きいか否か判定する。その最終アドレスの値は、ＲＡＭ１０３内に確保した送受信用領域の大きさ、より具体的にはバイト数に対応する。そのため、受信したアドレスの値が送受信用領域のバイト数よりも大きかった場合、その判定はＹＥＳとなってステップ１０３０に移行する。そうでない場合には、その判定はＮＯとなってステップ１０３１に移行する。
【０１１７】
受信したアドレスの値が送受信用領域のバイト数よりも大きかった場合、受信したデータを書き込む先が特定できないことから、送受信用領域にそのデータを書き込むことができない。そのため、ステップ１０３０では、データの送信、或いは受信にエラーが発生したとして、それに対処するための例外処理を実行する。その後、一連の処理を終了する。他方のステップ１０３１では、受信したアドレスの値、即ち変数ＷＲＩＴＥＣＯＵＮＴＥＲの値が指定するアドレスから時間長データ、それが付加されたＭＩＤＩデータ等のコマンドを送受信用領域に書き込む。それが終了した後、図１０のステップ１００２に戻る。
【０１１８】
図１０に戻って、ステップ１００３以降の処理について説明する。
ステップ１００３では、演奏フラグの値が１か否か判定する。送信側が送信した演奏開始コードを受信していた場合、その判定はＹＥＳとなってステップ１００４に移行する。そうでない場合には、その判定はＮＯとなってステップ１００２に戻る。
【０１１９】
ステップ１００４〜図１１のステップ１０１９では、受信したデータに従った自動演奏を実現するための処理が行われる。
先ず、ステップ１００４では、タスクカウンタＴＣの初期化、即ち予め定めた値の代入を行う。そのタスクカウンタＴＣは、上記したように、処理対象としているタスクを管理するための変数である。
【０１２０】
ステップ１００４に続くステップ１００５では、タイマ１０６の現在値を読み込み、それを変数ＴＩＭＥＲに代入する。続くステップ１００６では、タスクカウンタＴＣが指定するタスクに対応した現在時刻カウンタ（ＴＣ）の値が、その変数ＴＩＭＥＲの値以上か否か判定する。現在時刻カウンタ（ＴＣ）には、次のイベント（ＭＩＤＩデータ）を処理すべきタイミングとなったときのタイマ１０６の値が代入されている。そのため、次のイベントを処理すべきタイミングとなった場合には、その判定はＮＯとなって図１１のステップ１００９に移行する。そうでない場合には、即ち次のイベントを処理すべきタイミングがまだ来ていない場合には、その判定はＹＥＳとなってステップ１００７に移行する。
【０１２１】
ステップ１００７では、現在処理対象としているタスクでは次のイベントを処理すべきタイミングとなっていないことから、処理対象を他のタスクに変更するためにタスクカウンタＴＣのインクリメントを行う。その後、ステップ１００８に移行する。
【０１２２】
ステップ１００８では、インクリメント後のタスクカウンタＴＣの値が所定値より大きいか否か判定する。タスク生成命令によって実行を開始したタスクには、例えばシーケンシャルに数字が順次割り当てられる。このことから、上記所定値は、例えばそれまでにタスクに割り当てた数字の最大値である。そのため、現在実行中のタスクを一通り処理対象とした場合、その判定はＹＥＳとなってステップ１００２に戻る。そうでない場合には、その判定はＮＯとなってステップ１００５に戻る。
【０１２３】
このように、ステップ１００５〜１００８は処理ループを形成しており、その処理ループの実行を繰り返すことで、タスクカウンタＴＣによって指定されたタスクに対する処理が行われていく。そのタスクに処理すべきデータ（イベント）が存在していた場合、ステップ１００６の判定がＹＥＳとなって図１１のステップ１００９に移行し、そのデータに対する処理が以下のように行われる。
【０１２４】
先ず、ステップ１００９では、現在処理対象としているタスクに対応する変数ＲＥＡＤＣＯＵＮＴＥＲ（ＴＣ）の値を読み込む。続くステップ１０１０では、その変数ＲＥＡＤＣＯＵＮＴＥＲ（ＴＣ）の値に基づいて送受信用領域から処理すべきデータを読み込む。その後、ステップ１０１１に移行する。
【０１２５】
ステップ１０１１では、ステップ１０１０で読み込んだデータの種類（内容）を判定する。その種類がＭＩＤＩデータであった場合、次にステップ１０１２に移行して、ＭＩＤＩデータを処理する音楽処理を実行した後、ステップ１０１４に移行する。その種類が第１、或いは第２の制御データであった場合には、次にステップ１０１３に移行して、それらの制御データを処理するタスク処理を実行した後、ステップ１０１４に移行する。なお、音楽処理、タスク処理についての詳細は後述する。
【０１２６】
ステップ１０１４〜１０１６で形成される処理ループでは、変数ＲＥＡＤＣＯＵＮＴＥＲ（ＴＣ）を、その値がオーバーフロー、即ちその値がＲＡＭ１０１３の送受信用領域外のアドレスを示しているか否かを判定しつつ、ステップ１０１２の音楽処理、或いはステップ１０１３のタスク処理で処理したデータのバイト数だけインクリメントする。そのバイト数のインクリメントが終了すると、ステップ１０１７に移行する。
【０１２７】
ステップ１０１７では、インクリメント後の変数ＲＥＡＤＣＯＵＮＴＥＲ（ＴＣ）の値に基づいて、次に処理すべきデータに付加された時間長データを送受信用領域から読み込む。それが終了すると、続くステップ１０１８でそのデータを処理すべきタイミングとなったときのタイマ１０６の値を算出して現在時刻カウンタ（ＴＣ）に代入する。より具体的には、現在時刻カウンタ（ＴＣ）に、読み込んだ時間長データの値に変数ＴＩＭＥＲの値（タイマ１０６の現在値）を加算した値を代入する。その後、図１０のステップ１００７に戻る。
【０１２８】
一方、ステップ１０１４〜１０１６で形成される処理ループを実行中に変数ＲＥＡＤＣＯＵＮＴＥＲ（ＴＣ）の値がオーバーフローを起こした場合、ステップ１０１５の判定がＹＥＳとなってステップ１０１９に移行する。そのステップ１０１９では、データの送信、或いは受信に何らかのエラーが発生したとして例外処理を実行する。その後、一連の処理を終了する。
【０１２９】
このように、各種の制御データを含む演奏データ（音楽情報）を対象とした受信処理では、受信したデータは随時送受信用領域内に格納し、それに格納した受信データに対しては、処理対象とするタスクを順次変更しながら、各タスクで処理すべきタイミングとなったデータを随時処理することが行われる。
【０１３０】
次に、上記受信処理内で実行されるサブルーチン処理について、図１３〜図１５を参照して詳細に説明する。
図１３は、図１１のステップ１０１２で実行される音楽処理の動作フローチャートである。始めに、図１３を参照して音楽処理について詳細に説明する。
【０１３１】
この音楽処理は、ＭＩＤＩ出力装置１０７を介して音源装置１１２を制御するための処理である。その処理が開始すると、ステップ１３０１で処理すべきＭＩＤＩデータをＭＩＤＩ出力装置１０７に出力する。そのＭＩＤＩデータを出力した後、一連の処理を終了する。
【０１３２】
図１４は、図１１のステップ１０１３で実行されるタスク処理の動作フローチャートである。次に、図１４を参照してタスク処理について詳細に説明する。なお、図１４は、制御データのなかで使用頻度の高いもの、具体的にはジャンプ命令、指定したレジスタを用いた演算命令、及びタスク生成命令に対する処理の流れを抜粋して示したものである。
【０１３３】
このタスク処理を開始した後は、先ず、ステップ１４０１で処理すべきデータ（命令）の種類を判定する。その後は、その判定した種類に応じて処理が行われる。
【０１３４】
そのデータ（命令）の種類がジャンプ命令と判定した場合、ステップ１４０２に移行し、変数ＲＥＡＤＣＯＵＮＴＥＲ（ＴＣ）に、ジャンプ先となるデータの格納場所を示す値を代入する。その後、一連の処理を終了する。
【０１３５】
演奏データには、詳細な説明は省略するが、それ自体では何の機能も発揮しない制御コード（フラグ）を挿入することができ、ジャンプ命令は、その制御コードを指定してデータの実行個所を変更するようになっている。そのため、ステップ１４０２を実行することで、変数ＲＥＡＤＣＯＵＮＴＥＲ（ＴＣ）には、指定された制御コード（フラグ）の格納先に対応する値が代入される。
【０１３６】
ステップ１４０１で判定したデータ（命令）の種類が演算命令であった場合には、ステップ１４０３に移行する。そのステップ１４０３では、その命令に従って、その命令で指定したレジスタ（タスクワークレジスタ）の値に対する操作を行う。それを行った後、一連の処理を終了する。
【０１３７】
ステップ１４０１で判定したデータ（命令）の種類がタスク生成命令であった場合には、ステップ１４０４に移行する。そのステップ１４０４では、その命令で指定されたタスクを実行中のタスクとして登録することで、そのタスクを生成する。それを行った後、一連の処理を終了する。
【０１３８】
上記タスク処理を実行することで、各種制御データに割り当てた機能が実現され、タスクを単位とした演奏の開始や終了、それの繰り返し等が制御されることになる。
【０１３９】
図１５は、図１１のステップ１０１９、或いは図１２のステップ１０３０で実行される例外処理の動作フローチャートである。例外処理は、データの送信、或いは受信にエラーが発生したと判定した場合に、そのエラーに対処するために実行される。次に、この図１５を参照して、例外処理について詳細に説明する。
【０１４０】
先ず、ステップ１５０１では、エラーが発生したことから、ＭＩＤＩ出力装置１０７を介して音源装置１１２に発音中の全ての楽音の消音（クリア）を指示する。全ての楽音の消音を指示すると、次に、ステップ１５０２、１５０３で形成される処理ループを実行して、演奏停止コードを受信するのを待つ。
【０１４１】
送受信装置１０４が演奏停止コードを受信すると、ステップ１５０３の判定がＹＥＳとなってその処理ループを抜けてステップ１５０４に移行する。そのステップ１５０４では、演奏フラグに演奏中ではないことを示す０を代入する。続くステップ１５０５では、ＲＡＭ１０３に保持させた各種変数や送受信用領域のクリアといったイニシャライズを行い、その後に一連の処理を終了する。
【０１４２】
このように、エラーが発生した場合には、直ちに演奏を停止させている。そのため、エラーによって演奏に実際には発音されないはずの楽音が発音されたり、何らかの楽音が鳴りっぱなしになるといったことが確実に回避される。
＜第３の実施の形態＞
ＭＩＤＩデータの送信に用いる通信回線、或いはその使用状況等により、ＭＩＤＩデータが送信されてから受信されるまでの送信時間が変動することがある。この第３の実施の形態は、上記第１の実施の形態と比較して、そのような送信時間の変動により適応できるようにしたものである。
【０１４３】
第３の実施の形態における構成は、基本的に第１の実施の形態のそれ（図１参照）と同じである。そのため、第１の実施の形態の説明で用いた符号を流用して、第１の実施の形態から異なる部分のみ説明することにする。
【０１４４】
第３の実施の形態では、電源がオンされると、タイマ１０６を起動させるようになっている。ＣＰＵ１０１は、そのタイマ１０６の値を用いて、以下のように、ＭＩＤＩデータの送信、及び受信時の処理を行っている。ここでも、データの送受信の対象は他の音楽情報送受信装置であるとして説明する。
【０１４５】
送信の対象となるＭＩＤＩデータは、ＭＩＤＩ入力装置１０５を介して電子キーボード１１１から入力される。ＣＰＵ１０１は、そのＭＩＤＩデータに、タイマ１０６の値（電源がオンしてから経過した時間（を表す値））を時間データとして付加し、それらを１イベント分のデータとして送受信装置１０４から送信させる。
【０１４６】
送信側のタイマの値と受信側のタイマ１０６の値とは、通常は一致しない。そのため、第３の実施の形態では、送信側から送られてくる時間データ（送信時のタイマの値）から送信側のタイマの値との違いを補正するための値を算出し、その値を基に、送信側が付加した時間データに沿ってＭＩＤＩデータを処理するようにしている。その補正するための値は、変数である補正レジスタに保持させている。
【０１４７】
送信時間があるため、時間データとして送られてきた送信側のタイマの値からだけでは、送信側のタイマの値と受信側のタイマ１０６の値との間の違いを正確に特定することはできない。その送信時間自体も常に一定であるとは限らない。送信に用いる通信回線やその状態、或いは送信側と受信側の位置関係等によって、送信時間が比較的大きく変動することがある。その送信時間の変動は、楽音を発音させるタイミングのズレとなって表面化する。このことから、第３の実施の形態では、送信側から送られる時間データを基に、その変動の影響を低減させるようにしている。その影響の低減は、後述するようにして、上記補正レジスタの値を変更することで行っている。
【０１４８】
送信されてきたデータは、ＲＡＭ１０３に確保した送受信用領域に一旦格納する。その送受信用領域に格納したＭＩＤＩデータを処理するタイミングを、ＣＰＵ１０１は、それに付加された時間データ、及び補正レジスタの値から決定し、その決定したタイミングに従ってＭＩＤＩデータをＭＩＤＩ出力装置１０７に出力することで処理する。それにより、音源装置１１２から楽音を発音させる。
【０１４９】
ところで、送信時間の変動は、或る時間内に送信されたデータを、受信側にそれよりも短い時間内で集中的に受信させるようなことを起こすことがある。換言すれば、単位時間当たりのデータの受信量を異常に増大させることがある。
【０１５０】
それは、送受信用領域に多くのデータを短い時間内に格納する必要性が生じたことを意味する。その送受信用領域には、上記したように、データを書き込むアドレスをサイクリックに変更させている。このため、短い時間内で大量のデータを送受信用領域に格納させると、未処理のデータを消して上書きしてしまうことが起こり得る。それは、例えば或る楽音が鳴りっぱなしになるというようなことを生じさせるので、非常に望ましくない。
【０１５１】
このことから、第３の実施の形態では、送受信用領域の空容量（データが格納されていない領域、及び既に処理したデータが格納されている領域の容量を合計した量である）に応じて、データを処理するタイミングを早めたり遅くしたりしている。そのことについての詳細は後述する。
【０１５２】
なお、送受信用領域には、送信時間の変動の他に、送信側と受信側のタイマが時間を計時するスピードが異なることから未処理のデータが必要以上に大量に格納されることも考えられる。これは、例えば送信側のほうが受信側よりも計時のスピードが速い場合（単位時間当たりのデータの処理量が受信側よりも送信側のほうが大きい場合）である。その送受信用領域については、以降、リングバッファと呼ぶことにする。
【０１５３】
次に、上記したＣＰＵ１０１の動作について、図１６〜図２１に示す動作フローチャートを参照して詳細に説明する。それらフローチャートで示す処理は、ＣＰＵ１０１が、ＲＯＭ１０２からプログラムを読み出して実行することにより実現される処理である。
【０１５４】
図１６は、第３の実施の形態における送信処理の動作フローチャートである。この送信処理は、第１の実施の形態と同様に、ユーザが所定のスイッチを操作して送受信装置１０４からＭＩＤＩデータ（音楽情報）を送信させることを指定した場合に実行される。
【０１５５】
先ず、ステップ１６０１では、イニシャライズを行う。そのイニシャライズでは、例えば送受信装置１０４に受信側との回線の接続等を行わせる。その後、ステップ１６０２に移行する。
【０１５６】
ステップ１６０２では、ＭＩＤＩ入力装置１０５に電子キーボード１１１からＭＩＤＩデータが入力されるのを待って、ＭＩＤＩ入力装置１０５からＭＩＤＩデータを受け取る。続くステップ１６０３では、そのＭＩＤＩデータに、タイマ１０６の現在値を時間データとして付加する。その後、ステップ１６０４に移行する。なお、タイマ１０６の現在値（現在時刻）は、第１の実施の形態と同様に、変数ＴＩＭＥＲに保持して扱われる。ＭＩＤＩデータ、及び時間データについては、第３の実施の形態では共に４バイトを割り当てている。
【０１５７】
ステップ１６０４では、時間データを付加したＭＩＤＩデータを送受信装置１０４に送って送信させる。その後、ステップ１６０２に戻る。
ユーザが所定のスイッチを操作してデータの送信の終了を指示するまでの間、ステップ１６０２〜１６０４で形成される処理ループが繰り返し実行される。それにより、電子キーボード１１１への操作に応じて送受信装置１０４からデータが送信されることになる。
【０１５８】
図１７〜図２１は、第３の実施の形態における受信処理の動作フローチャートである。次に、図１７〜図２１を参照して、受信処理について詳細に説明する。その送信処理は、第１の実施の形態と同様に、ユーザが所定のスイッチを操作して送受信装置１０４から音楽情報を取得するのを指定した場合に実行される。
【０１５９】
先ず、ステップ１７０１〜１７０４では、イニシャライズに関わる処理を行う。それらの処理ステップを実行することで、補正レジスタ、平均カウンタ、平均レジスタ、及びリングバッファへのアクセスを管理するための各種レジスタ（変数）に、それぞれ０が代入され、リングバッファの内容はクリアされる。なお、平均カウンタは、補正レジスタの値を変更するタイミングを管理するための変数、平均レジスタは、その変更に用いるデータを保持させる変数である。リングバッファへのアクセスを管理するための各種レジスタ（変数）には、データを書き込むアドレスを管理するための書き込みアドレスや、それからデータを読み出すアドレスを管理するための読み込みアドレス等がある。
【０１６０】
ステップ１７０４に続くステップ１７０５以降では、送受信装置１０４がデータを受信したことに伴う処理が行われる。
先ず、ステップ１７０５では、送受信装置１０４がデータを受信したか否か判定する。送受信装置１０４がデータを受信した場合、その判定はＹＥＳとなってステップ１７０６に移行する。そうでない場合には、後述する図２１の図ステップ１７３１に移行する。なお、データの受信は、例えば送受信装置１０４が、その旨を示す割り込み信号を出力することにより、ＣＰＵ１０１に通知される。
【０１６１】
ステップ１７０６では、受信されたデータから時間データを取り出し、続くステップ１７０７では、タイマ１０６の現在値（変数ＴＩＭＥＲの値）から時間データの値を減算した値の絶対値を算出する。その後、ステップ１７０８に移行する。なお、以降では、混乱を避けるために、受信した時間データが示す時刻（時間）を演奏時刻、タイマ１０６の現在値（変数ＴＩＭＥＲの値）を現在時刻と呼ぶことにする。また、ステップ１７０７で算出した値については、絶対時刻差と呼ぶことにする。
【０１６２】
ステップ１７０８では、その絶対時刻差が所定時間ａ（ｍｓ）より大きいか否か判定する。その所定時間ａは、送信側と受信側との間に直ちに対処すべき大きな時刻差が有るのか否かを判定するために設定した時間である。そのため、送信側と受信側との間にそれ以上の時刻差が存在していた場合、その判定はＹＥＳとなってステップ１７０９に移行する。そうでない場合には、即ち送信側と受信側の時刻が比較的に一致している場合には、その判定はＮＯとなって図１８のステップ１７１２に移行する。なお、上記所定時間ａは、例えば５００（ｍｓ）相当の値である。
【０１６３】
ステップ１７０９〜１７１１では、送信側と受信側との間の大きな時刻差に対処するための処理が行われる。
先ず、ステップ１７０９では、受信した時間データが示す時刻である演奏時刻から現在のタイマ１０６が示す時刻である現在時刻を減算する。続くステップ１７１０では、その減算値の正負に応じて、更に所定時間ｂ（ｍｓ）を減算、或いは加算する。そのようにして算出した値（時間）を、ステップ１７１１で補正レジスタに代入する。その後、図１８のステップ１７１２に移行する。
【０１６４】
上記所定時間ｂは、送信時間の突出した変動の処理への影響を緩和するために設定した時間であり、ａ＞ｂの関係にある。例えばａが５００であれば、ｂは例えば２５０程度の値である。
【０１６５】
普通、送信側と受信側の時刻は大きく異なる。そのため、始めてのデータの受信では、その殆どの場合でステップ１７０９〜１７１１が実行され、補正レジスタに何らかの値が代入されることになる。
【０１６６】
図１８のステップ１７１２〜１７２０では、平均カウンタ、及び平均レジスタを用いた補正レジスタの値の補正に関わる処理が行われる。
先ず、ステップ１７１２では、平均カウンタの値が所定値ｎ以下か否か判定する。その所定値ｎは、補正レジスタの値の補正を間欠的に行うために設定した値である。平均カウンタの値が所定値ｎ以下であった場合、その判定はＹＥＳとなってステップ１７１３に移行する。そうでない場合には、その判定はＮＯとなってステップ１７１６に移行する。なお、図１８のステップ１７１２〜１７２０は送受信装置１０４がデータを受信する度に実行されることから、所定値ｎは、イベント数を表している。
【０１６７】
ステップ１７１３では、平均カウンタをインクリメントする。続くステップ１７１４では、演奏時刻から、現在時刻と補正レジスタの値を減算する。そのようにして算出した減算値は、現在の補正レジスタの値を用いて送信側と受信側との間の時刻差を調整させた際に生じた誤差であるといえる。その誤差を、ステップ１７１５で平均レジスタに累算、即ち元の値にステップ１７１４で算出の値を加算して得られた値を平均レジスタに代入した後、図１９のステップ１７２１に移行する。なお、上記の誤差は、送信時間の変動の他に、送信側と受信側との間の計時速度（タイマ１０６がその値を更新していく時間間隔）の違い等を原因にして生じることがある。
【０１６８】
一方、ステップ１７１２の判定がＮＯとなった場合に移行するステップ１７１６では、平均レジスタの値を所定数ｎで割って平均値を算出する。その平均値は、１回のデータの受信における誤差である。ステップ１７１６に続くステップ１７１７〜１７２９は、その誤差に応じて行われる。
【０１６９】
ステップ１７１７では、その平均値が０以上か否か判定する。その平均値が０以上であった場合、その判定はＹＥＳとなってステップ１７１８に移行する。そうでない場合には、その判定はＮＯとなってステップ１７１９に移行する。
【０１７０】
補正レジスタには、正、或いは負の値が保持される。平均値が０以上ということは、補正レジスタの値が正であれば、その値が小さすぎるということになる。補正レジスタの値が負であっても、その値が小さすぎるということになる。そのため、ステップ１７１８では、補正レジスタの値のインクリメントを行い、その後にステップ１７２０に移行する。他方のステップ１７１９では、逆に補正レジスタの値のデクリメントを行い、その後にステップ１７２０に移行する。それらのインクリメント、或いはデクリメントにより、補正レジスタが表す時間が、予め定めた時間を単位として修正される。このような修正を繰り返すことで、補正レジスタが表す時間はより適正な時間に収束していくことになる。
【０１７１】
ステップ１７２０では、平均カウンタ、及び平均レジスタに０をそれぞれ代入する。その後、図１９のステップ１７２１に移行する。それらのレジスタに０を代入することで、補正レジスタの値の誤差によるその補正が、所定値ｎで指定されたイベント数のデータが受信される毎に行われることになる。
【０１７２】
図１９のステップ１７２１では、リングバッファの空容量を求める。上記したように、リングバッファに次にデータを書き込むアドレスは書き込みアドレス、データを読み出すアドレスは読み込みアドレスによって管理している。そのため、空容量は、それらの値から求めることができる。
【０１７３】
なお、書き込みアドレス、及び読み込みアドレスは、データはイベント単位で送信されることから、イベントを単位としてリングバッファ内のアドレスを管理するために用いている。１イベントのデータは８バイトである。従って、それらの値は、８バイトを単位としてアドレスを指定する。
【０１７４】
ステップ１７２１に続くステップ１７２２では、ステップ１７２１で求めた空容量がリングバッファ全体の容量の半分以下か否か判定する。空容量がリングバッファ全体の容量の半分以下であった場合、その判定はＹＥＳとなってステップ１７２３に移行する。そうでない場合には、その判定はＮＯとなってステップ１７２４に移行する。
【０１７５】
第３の実施の形態では、空容量が全体の半分以下となっていた場合、未処理のデータを増える傾向、換言すれば、データの受信量が、それの処理量よりも大きくなる傾向にあるとみなしている。そのため、ステップ１７２３では、データの処理量を増やすために、補正レジスタの値のインクリメントを行う。他方のステップ１７２４では、その反対に補正レジスタの値のデクリメントを行う。そのような補正レジスタの値のインクリメント、或いはデクリメントが終了した後、図２０のステップ１７２５に移行する。
【０１７６】
上記のように、リングバッファの空容量に応じて補正レジスタの値を変更することで、リングバッファに格納されたデータの処理量を増減させる。それにより、リングバッファに格納させたデータは、それを処理するまで確実に残すことができ、発音させる楽音にヌケが生じたり、楽音が鳴りっぱなしになるといったことが回避される。
【０１７７】
ステップ１７２５〜１７３０では、受信データのリングバッファへの格納に関わる処理が行われる。
先ず、ステップ１７２５では、受信データ中の演奏時刻を、補正レジスタの値を用いて変更する。具体的には、演奏時刻から補正レジスタの値を減算し、その減算結果を新たな演奏時刻とする。補正レジスタには、上記したように、送信側と受信側の時刻差を基準とした値が保持されている。そのため、変更後の演奏時刻は、それが付加されたＭＩＤＩデータを処理すべき受信側における時刻を表すものとなる。
【０１７８】
ステップ１７２５に続くステップ１７２６では、書き込みアドレスの値から、リングバッファに受信データを書き込むアドレスを指定する。書き込みアドレスにはイベント単位の値を保持させている。そのため、指定されるアドレスは、書き込みアドレスが保持している値に８（１イベント分のデータのバイト数）を乗算して得られる値のアドレス（リングバッファの先頭を基準とした相対アドレス）となる。それが終了した後、ステップ１７２７に移行する。
【０１７９】
ステップ１７２７では、指定されたアドレスから受信データを書き込む。データの書き込み後は、ステップ１７２８で書き込みアドレスの値のインクリメントを行う。
【０１８０】
リングバッファには、第３の実施の形態では１０２４イベントのデータを格納できる領域を割り当てている。それに合わせて、書き込みレジスタの値域を０〜１０２３としている。０は、リングバッファの先頭に位置する１イベント分の記憶領域（８バイト）、１０２３は、その最後に位置する１イベント分の記憶領域を指定する値である。このことから、ステップ１７２８に続くステップ１７２９では、インクリメント後の書き込みアドレスの値が１０２３より大きいか否か判定する。変数ＷＲＩＴＥＣＯＵＮＴＥＲの値が１０２３より大きい場合、その判定はＹＥＳとなってステップ１７３０に移行する。そうでない場合には、その判定はＮＯとなって図２１のステップ１７３１に移行する。
【０１８１】
ステップ１７３０では、書き込みアドレスの値がリングバッファ内のアドレスを指定するように、その値を補正する。具体的には、書き込みアドレスに０を代入する。それが終了した後、図２１のステップ１７３１に移行する。
【０１８２】
ステップ１７３１〜１７３７では、リングバッファに格納したデータから実際に楽音を発音させることに関する処理が行われる。
先ず、ステップ１７３１では、読み込みアドレスの値から、リングバッファから受信データを読み出すアドレスを指定する。読み込みアドレスにはイベント単位の値を保持させている。そのため、指定されるアドレスは、書き込みアドレスと同様に、それが保持している値に８（１イベント分のデータのバイト数）を乗算して得られる値のアドレス（リングバッファの先頭を基準とした相対アドレス）となる。それが終了した後、ステップ１７３２に移行し、指定したアドレスから受信データを読み出す。その後は、ステップ１７３３に移行する。
【０１８３】
ステップ１７３３では、読み出したデータ中の演奏時刻（上記ステップ１７２５で変更された演奏時刻である）が、現在時刻（タイマ１０６が現在計時している時刻）と所定時間ｃとで特定される範囲内であるか否か判定する。演奏時刻がその範囲内であった場合、その判定はＹＥＳとなってステップ１７３４に移行する。そうでない場合には、その判定はＮＯとなって図１７のステップ１７０５に戻る。
【０１８４】
演奏時刻はそれが付加されたＭＩＤＩデータを処理すべきタイミングを必ずしも正確に表していない。そのことから、第３の実施の形態では、ＭＩＤＩデータを処理するタイミングに許容範囲を設けている。上記所定時間ｃは、その許容範囲を基に設定したものである。そのため、ステップ１７３３の判定がＹＥＳ、即ち演奏時刻が上記範囲内であった場合には、その演奏時刻が付加されたＭＩＤＩデータを処理すべきタイミングとなったとみなして、それを処理している。なお、所定時間ｃには、その絶対値が上記所定時間ａの絶対値を越えない範囲の値を設定している。
【０１８５】
ステップ１７３４では、そのＭＩＤＩデータをＭＩＤＩ出力装置１０７に出力することで処理する。続くステップ１７３５では、読み込みアドレスの値のインクリメントを行う。その後、ステップ１７３６に移行する。
【０１８６】
ステップ１７３６では、インクリメント後の読み込みアドレスの値が１０２３より大きいか否か判定する。その値が１０２３より大きい場合、その判定はＹＥＳとなってステップ１７３７に移行する。そうでない場合には、その判定はＮＯとなって図１７のステップ１７０５に移行する。
【０１８７】
ステップ１７３７では、読み込みアドレスの値がリングバッファ内のアドレスを指定するように、その値を補正する。具体的には、読み込みアドレスに、リングバッファの先頭に位置するアドレスを指定する０を代入する。それが終了した後、図１７のステップ１７０５に戻る。
【０１８８】
なお、第３の実施の形態では、ＭＩＤＩデータを処理するタイミングの決定に用いる補正レジスタの値を、それに付加された時間データ（演奏時刻）、及びリングバッファの空容量から、それぞれ独立的に補正しているが、それらのうちの一方だけに基づいて補正レジスタの値を補正するようにしても良い。リングバッファの空容量に注目した補正レジスタの値の補正では、演奏を開始した時の空容量の割合、受信されるデータ量の推移等を更に考慮して、その値を補正するようにしても良い。時間データに着目した補正レジスタの値の補正では、予め定めたイベント数のデータを受信する度にその補正を行っているが、その補正の頻度は、誤差の大きさに応じて増減させるようにしても良い。これら以外にも、様々な変形が可能である。
＜第４の実施の形態＞
ＭＩＤＩデータでは、そのデータを全て受信側が受信できなかった場合、それが受信側での演奏に大きく影響することがある。第４の実施の形態は、その影響を低減させるようにしたものである。
【０１８９】
第４の実施の形態における構成は、基本的に上記第３の実施の形態のそれ（図１参照）と同じである。そのため、第３の実施の形態の説明で用いた符号を流用して、第３の実施の形態から異なる部分のみ説明することにする。
【０１９０】
第４の実施の形態では、ＭＩＤＩデータのなかで受信側が受信できなかった際の影響が他と比較して大きい種類を選択し、その選択した種類のＭＩＤＩデータを送信すると、それを所定時間ｄ毎に繰り返し送信するようにしている。それにより、未受信時の影響が大きいデータを受信側に確実に受信させ、その影響を低減させている。
【０１９１】
他方のデータの受信時では、リングバッファに格納したデータを処理する際に、それが既に受信済みのデータか否か、換言すれば、それが処理すべきデータか否か判定し、その判定結果に従ってデータを処理するようにしている。それにより、データが繰り返し送信されても、それによる演奏上の不具合が発生するのを回避させている。以下、それらを実現させるＣＰＵ１０１の動作について、図２２〜図２５を参照して詳細に説明する。
【０１９２】
図２２、及び図２３は、第４の実施の形態による送信処理の動作フローチャートである。始めに、これら図２２、及び図２３を参照して、その送信処理について詳細に説明する。その送信処理は、第３の実施の形態と同様に、ユーザが所定のスイッチを操作して送受信装置１０４から音楽情報を送信させることを指定した場合に実行される。
【０１９３】
先ず、ステップ２２０１では、繰り返し送信すべきデータを送信するタイミングを種類別に管理するための変数であるカウンタをクリア、即ち０を代入する。続くステップ２２０２では、他のレジスタにそれぞれ０を代入する。そのレジスタとしては、読み込みレジスタや書き込みレジスタ等がある。それらステップ２２０１、及び２２０２は、送信処理におけるイニシャライズに関わる処理として実行される。
【０１９４】
ステップ２２０２に続くステップ２２０３では、ＭＩＤＩ入力装置１０５に電子キーボード１１１から新たに入力されたＭＩＤＩデータがあるか否か判定する。ＭＩＤＩデータがＭＩＤＩ入力装置１０５に新たに入力されていた場合、その判定はＹＥＳとなってステップ２２０４に移行する。そうでない場合には、その判定はＮＯとなって図２３の図２２１２に移行する。
【０１９５】
ステップ２２０４では、ＭＩＤＩ入力装置１０５からＭＩＤＩデータを受け取る。続くステップ２２０５〜２２１１では、ＭＩＤＩ入力装置１０５から受け取ったＭＩＤＩデータのイベントの種類を判別し、その判別結果に応じた繰り返し送信させるＭＩＤＩデータの保存、或いはＭＩＤＩデータの送信を行うための処理が行われる。ここでは、説明上、便宜的に、プログラムチェンジ、ベンダ（ベンド）チェンジ、ベンダ（ベンド）レンジチェンジ、ダンパ（ホールド１）が繰り返し送信させるＭＩＤＩデータのイベントの種類であるとして説明する。
【０１９６】
なお、その種類は、それらに限定されるものではなく、それら以外の種類を選択しても良い。具体的には、例えばコントロールチェンジのなかから、メインボリューム、バランスコントロール等を更に選択しても良い。更には、チャンネルプレッシャやリセット・オール・コントローラーズ等も選択に加えても良い。楽音の鳴りっぱなしを確実に防止するために、ノートオフを加えても良い。繰り返し送信させるイベントの種類をユーザが選択できるようにしても良い。
【０１９７】
先ず、ステップ２２０５では、ＭＩＤＩデータのイベントがプログラムチェンジか否か判定する。そのＭＩＤＩデータの１バイト目のデータ（ステータスバイト）がプログラムチェンジであることを示していた場合、その判定はＹＥＳとなってステップ２２０６に移行し、そのＭＩＤＩデータをＲＡＭ１０３内に予め用意した音色番号レジスタ（４バイトである）にストアする。その後、上記ステップ２２０３に戻る。
【０１９８】
ステップ２２０７以降では、同様にして、ＭＩＤＩデータのイベントがベンダチェンジであればそれをベンダレジスタにストアした後（ステップ２２０７→２２０８）、ステップ２２０３に戻る。ＭＩＤＩデータのイベントがダンパであれば、それをダンパレジスタにストアした後（ステップ２２０９→２２１０）、ステップ２２０３に戻る。ＭＩＤＩデータのイベントがベンダレンジチェンジであれば、それをベンダレンジレジスタにストアした後（ステップ２２１１→２２１２）、ステップ２２０３に戻る。そのようにして、繰り返し送信すべきと選択したイベントのＭＩＤＩデータを、ＲＡＭ１０３内に予め用意した領域に種類別に格納する。
【０１９９】
ＭＩＤＩ入力装置１０５から受け取ったＭＩＤＩデータのイベントが繰り返し送信すべきと選択していない種類であった場合、ステップ２２１１の判定がＮＯとなってステップ２２１３に移行する。そのステップ２２１３では、タイマ１０６の現在値（受信側における演奏時刻：変数ＴＩＭＥＲの値）を時間データとしてＭＩＤＩデータに付加し、それを送受信装置１０４から送信させる。その後、ステップ２２０３に戻る。
【０２００】
上記したように、ＭＩＤＩ入力装置１０５に電子キーボード１１１から新たなＭＩＤＩデータが送られていない場合、ステップ２２０３の判定がＮＯとなって図２３のステップ２２１４に移行する。そのステップ２２１４以降では、上述のようにして各種レジスタにストアした繰り返し送信すべきＭＩＤＩデータの送信に関わる処理が行われる。
【０２０１】
先ず、ステップ２２１４では、現在時刻を取得、即ちタイマ１０６から現在値を受け取ってそれを変数ＴＩＭＥＲに代入する。続くステップ２２１５では、その現在時刻が所定時間ｄを基に設定した所定時間ｅで割り切れるか否か判定する。そのステップ２２１５が、所定時間ｅで割り切れる時刻となってから次に割り切れる時刻がくるまでの間で始めての実行であった場合、その判定はＹＥＳとなってステップ２２１６に移行する。そうでない場合には、その判定はＮＯとなって図２２のステップ２２０３に戻る。ステップ２２１６以降の処理を実行することにより、カウンタの値で指定される種類のイベントのＭＩＤＩデータが送信される。
【０２０２】
そのステップ２２１６では、カウンタの値が０か否か判定する。カウンタが保持している値が０であった場合、その判定はＹＥＳとなってステップ２２１７に移行し、音色番号レジスタにストアされているＭＩＤＩデータに現在時刻を付加して送受信装置１０４から送信させる。その後、ステップ２２２４に移行する。そうでない場合には、その判定はＮＯとなってステップ２２１８に移行する。なお、当然のことながら、音色番号レジスタにＭＩＤＩデータがストアされていなければ、ステップ２２１７でデータの送信を行うことなくステップ２２２４に移行する。
【０２０３】
ステップ２２１８以降では、同様にして、カウンタの値が１であればベンダレジスタにストアされているＭＩＤＩデータを送信させた後（ステップ２２１８→２２１９）、ステップ２２２４に移行する。カウンタの値が２であればダンパレジスタにストアされているＭＩＤＩデータを送信させた後（ステップ２２２０→２２２１）、ステップ２２２４に移行する。カウンタの値が３であればベンダレンジレジスタにストアされているＭＩＤＩデータを送信させた後（ステップ２２２２→２２２３）、ステップ２２２４に移行する。そのようにして、各種レジスタにストアされているＭＩＤＩデータを、カウンタの値に応じて送信させる。
【０２０４】
ステップ２２２４では、カウンタをインクリメントする。それが終了すると、ステップ２２２５に移行して、カウンタの値が４か否か判定する。インクリメントによってカウンタの値が４となった場合、その判定はＹＥＳとなってステップ２２２６に移行し、カウンタに０を代入した後、図２２のステップ２２０３に戻る。そうでない場合には、その判定はＮＯとなって、カウンタの値を変更させることなく図２２のステップ２２０３に戻る。
【０２０５】
このように、第４の実施の形態では、繰り返し送信すべきと選択したイベントのＭＩＤＩデータを繰り返し送信させている。そのため、受信側では、それらのイベントのＭＩＤＩデータを確実に受信することができるようになる。それにより、たとえデータが途中で消えてしまうようなことがあったとしても、それの演奏への影響を最小限に抑えることができる。
【０２０６】
なお、上記所定時間ｄと所定時間ｅとは、第４の実施の形態では繰り返し送信すべきイベントの種類を４種類としていることから、ｄ＝４ｅの関係となっている。
【０２０７】
図２４、図２５は、第４の実施の形態における受信処理の動作フローチャートである。第４の実施の形態は、第３の実施の形態における受信処理から、図２１のステップ１７３１以降のみが異なっている。そのため、図２４、図２５を参照して、その異なっている部分のみ説明する。
【０２０８】
第４の実施の形態では、図１７のステップ１７０５の判定、或いは図２０のステップ１７２９の判定がＮＯとなるか、或いは図２０のステップ１７３０の処理が終了すると、図２４のステップ２４０１に移行する。そのステップ２４０１以降の処理を実行することにより、リングバッファに格納されたデータは、それを処理すべきか否か判定され、その判定結果に従って処理される。
【０２０９】
そのステップ２４０１では、読み込みアドレスの値から、リングバッファから受信データを読み出すアドレスを指定する。続くステップ２４０２では、そのアドレスから受信データを読み出す。それが終了した後は、ステップ２４０３に移行する。
【０２１０】
ステップ２４０３では、読み出したデータ中の演奏時刻（上記ステップ１７２５で変更された演奏時刻である）が、現在時刻（タイマ１０６の現在値）と所定時間ｃとで特定される範囲内であるか否か判定する。演奏時刻がその範囲内であった場合、その判定はＹＥＳとなってステップ２４０４に移行する。そうでない場合には、その判定はＮＯとなって図１７のステップ１７０５に戻る。
【０２１１】
ステップ２４０４では、ステップ２４０２で読み出したＭＩＤＩデータのイベントがプログラムチェンジか否か判定する。そのＭＩＤＩデータのステータスバイトがプログラムチェンジであることを表していた場合、判定はＹＥＳとなってステップ２４０５に移行する。そうでない場合には、その判定はＮＯとなってステップ２４０６に移行する。
【０２１２】
ステップ２４０５では、ＭＩＤＩデータが有する音色番号が、現在音源装置１１２に設定中の音色番号と一致するか否か判定する。それらが一致していた場合、その判定はＹＥＳとなって図２５のステップ２４１３に移行する。そうでない場合には、その判定はＮＯとなってステップ２４０６に移行する。なお、それらの音色番号が一致しているか否かは、プログラムチェンジのＭＩＤＩデータを処理（ＭＩＤＩ出力装置１０７を介して音源装置１１２に送出）した際に、そのＭＩＤＩデータを音色番号レジスタにストアさせることで行えるようにしている。これは、他の繰り返し送信すべきと選択されているイベントのＭＩＤＩデータにおいても同様である。
【０２１３】
ステップ２４０６では、リングバッファから読み出したＭＩＤＩデータのイベントがベンダチェンジか否か判定する。そのイベントがベンダチェンジであった場合、判定はＹＥＳとなってステップ２４０７に移行する。そうでない場合には、その判定はＮＯとなってステップ２４０８に移行する。なお、イベントがベンダチェンジか否かは、ステータスバイトから判定される。
【０２１４】
ステップ２４０７では、ＭＩＤＩデータ中のベンダの値が音源装置１１２に設定中のベンダの値と一致するか否か判定する。それらの値が一致した場合、その判定はＹＥＳとなって図２５のステップ２４１３に移行する。そうでない場合には、その判定はＮＯとなってステップ２４０８に移行する。
【０２１５】
ステップ２４０８では、リングバッファから読み出したＭＩＤＩデータのイベントがダンパ（ホールド１）か否か判定する。そのイベントがダンパであった場合、判定はＹＥＳとなってステップ２４０９に移行する。そうでない場合には、その判定はＮＯとなって図２５のステップ２４１０に移行する。なお、イベントがダンパか否かは、ステータスバイトとそれに続く１バイトのデータバイトから判定される。
【０２１６】
ステップ２４０９では、ＭＩＤＩデータ中のダンパの値（０か１２７である）が音源装置１１２に設定中のダンパの値と一致するか否か判定する。それらの値が一致した場合、その判定はＹＥＳとなって図２５のステップ２４１３に移行する。そうでない場合には、その判定はＮＯとなって図２５のステップ２４１０に移行する。
【０２１７】
図２５のステップ２４１０では、リングバッファから読み出したＭＩＤＩデータのイベントがベンダレンジチェンジか否か判定する。ＭＩＤＩデータのイベントがベンダレンジチェンジであった場合、その判定はＹＥＳとなってステップ２４１１に移行する。そうでない場合には、その判定はＮＯとなってステップ２４１２に移行する。
【０２１８】
ステップ２４１１では、ＭＩＤＩデータ中のベンダレンジの値が音源装置１１２に設定中のベンダレンジの値と一致するか否か判定する。それらの値が一致した場合、その判定はＹＥＳとなってステップ２４１３に移行する。そうでない場合には、その判定はＮＯとなってステップ２４１２に移行する。
【０２１９】
ステップ２４１２では、ステップ２４０２でリングバッファから読み出したＭＩＤＩデータは処理すべきとして、ＭＩＤＩ出力装置１０７を介して音源装置１１２に送出する。このとき、そのＭＩＤＩデータのイベントが繰り返し送信すべきＭＩＤＩデータのイベントとして選択されていた場合には、そのイベントの種類別に用意したレジスタのなかで対応するレジスタに、そのＭＩＤＩデータをストアする。
【０２２０】
ステップ２４１２に続くステップ２４１３では、読み込みアドレスの値のインクリメントを行う。そのインクリメント後は、ステップ１７３６に移行して、読み込みアドレスの値が１０２３より大きいか否か判定する。読み込みアドレスの値が１０２３より大きい場合、その判定はＹＥＳとなり、ステップ２４１５に移行して読み込みレジスタに０を代入した後、図１７のステップ１７０５に戻る。そうでない場合には、その判定はＮＯとなって、読み込みレジスタの値を変更させることなく図１７のステップ１７０５に戻る。
【０２２１】
なお、第４の実施の形態では、繰り返し送信すべきと選択されているイベントのＭＩＤＩデータを、無条件で繰り返し送信するようにしているが、例えば送信を繰り返す回数を設定しておき、その回数だけ送信を繰り返すようにしても良い。また、受信時には、既に処理したデータと一致しているか否か判定することで、繰り返し送信されてくるデータを重ねて音源装置１１２に送出するのを回避しているが、必ずしもそうしなくて良い。ＭＩＤＩデータには、重ねて処理しても実際の演奏には影響しないものがあることから、処理（音源装置１１２に送出）すべきか否かの判定を、その影響の有無で行うようにしても良い。しかし、繰り返し送信されてくるデータを重ねて音源装置１１２に送出するのを回避させた場合には、音源装置１１２の負荷をより抑えることができるという効果がある。
【０２２２】
また、第４の実施の形態では、ＭＩＤＩデータに時間データを付加しているが、時間データは必ずしもＭＩＤＩデータに付加しなくて良い。無視できない送信時間がある伝送路（例えば公衆網）を介してＭＩＤＩデータ（音楽情報）を送信するといったような場合にだけ、時間データを選択的に付加するようにしても良い。
【０２２３】
本実施の形態（第１〜第４の実施の形態）は、音楽情報の送受信を行う専用の装置として実現させたものであるが、電子楽器や各種コントローラ、シーケンサ、更にはパーソナルコンピュータ等に本発明を適用させても良い。そのときには、当然のことながら、音楽情報の送受信を行う機能を必ずしも搭載させる必要はなく、音楽情報を送信する機能、及び受信する機能の何れか一方だけを搭載するようにしても良い。
【０２２４】
パーソナルコンピュータへの本発明の適用は、基本的には上記した動作を実現させるためのプログラムをロードさせることで行うことができる。そのプログラムは、ＣＤ−ＲＯＭやフロッピーディスクといった携帯性に優れた記録媒体に記録して配布しても良く、何らかの通信回線を介して配信しても良い。
【０２２５】
【発明の効果】
以上説明したように、本発明では、受信した音楽情報中の時間データから、該時間データが付加されたイベントデータを処理すべきタイミングを決定し、受信した音楽情報中のイベントデータを決定したタイミングに従って処理する。そのため、受信したタイミングに関わらずにイベントデータを適切なタイミングで処理する、或いはイベントデータをより適切なタイミングで処理することができる。
【０２２７】
本発明では、受信した音楽情報中の時間データ、及びその音楽情報を記憶する記憶手段（音楽情報の格納用に割り当てられた記憶領域）の空容量に基づき、該時間データが付加されたイベントデータを処理すべきタイミングを決定し、そのタイミングに従って処理する。そのため、記憶手段に記憶させた音楽情報を確実に処理することができる。
【図面の簡単な説明】
【図１】本実施の形態による音楽情報送受信装置の構成図である。
【図２】送信処理の動作フローチャートである。
【図３】送信処理の動作フローチャートである（続き１）。
【図４】送信処理の動作フローチャートである（続き２）。
【図５】送信処理の動作フローチャートである（続き３）。
【図６】受信処理の動作フローチャートである。
【図７】受信処理の動作フローチャートである（続き１）。
【図８】受信処理の動作フローチャートである（続き２）。
【図９】受信処理の動作フローチャートである（続き３）。
【図１０】受信処理の動作フローチャートである（第２の実施の形態）
【図１１】受信処理の動作フローチャートである（第２の実施の形態：続き１）。
【図１２】受信処理の動作フローチャートである（第２の実施の形態：続き２）。
【図１３】音楽処理の動作フローチャートである。
【図１４】タスク処理の動作フローチャートである。
【図１５】例外処理の動作フローチャートである。
【図１６】送信処理の動作フローチャートである（第３の実施の形態）。
【図１７】受信処理の動作フローチャートである（第３の実施の形態）。
【図１８】受信処理の動作フローチャートである（第３の実施の形態：続き１）。
【図１９】受信処理の動作フローチャートである（第３の実施の形態：続き２）。
【図２０】受信処理の動作フローチャートである（第３の実施の形態：続き３）。
【図２１】受信処理の動作フローチャートである（第３の実施の形態：続き４）。
【図２２】送信処理の動作フローチャートである（第４の実施の形態）。
【図２３】送信処理の動作フローチャートである（第４の実施の形態：続き１）。
【図２４】受信処理の動作フローチャートである（第４の実施の形態：第３の実施の形態からの変更分１）。
【図２５】受信処理の動作フローチャートである（第４の実施の形態：第３の実施の形態からの変更分２）。
【符号の説明】
１０１  ＣＰＵ
１０２  ＲＯＭ
１０３  ＲＡＭ
１０４  送受信装置
１０５  ＭＩＤＩ入力装置
１０６  タイマ
１０７  ＭＩＤＩ出力装置
１１１  電子キーボード
１１２  音源装置
【図１】
0003671666.tif 000002
【図２】
0003671666.tif 000003
【図３】
0003671666.tif 000004
【図４】
0003671666.tif 000005
【図５】
0003671666.tif 000006
【図６】
0003671666.tif 000007
【図７】
0003671666.tif 000008
【図８】
0003671666.tif 000009
【図９】
0003671666.tif 000010
【図１０】
0003671666.tif 000011
【図１１】
0003671666.tif 000012
【図１２】
0003671666.tif 000013
【図１３】
0003671666.tif 000014
【図１４】
0003671666.tif 000015
【図１５】
0003671666.tif 000016
【図１６】
0003671666.tif 000017
【図１７】
0003671666.tif 000018
【図１８】
0003671666.tif 000019
【図１９】
0003671666.tif 000020
【図２０】
0003671666.tif 000021
【図２１】
0003671666.tif 000022
【図２２】
0003671666.tif 000023
【図２３】
0003671666.tif 000024
【図２４】
0003671666.tif 000025
【図２５】
0003671666.tif 000026