JPH11133957A - 音楽情報送信方法、音楽情報送信装置、音楽情報受信処理方法、音楽情報受信処理装置、及び音楽情報送受信装置 - Google Patents

Abstract

(57)【要約】 【課題】 音楽情報の送受信の過程により生じる音楽的
な不具合の発生を回避できるようにする。 【解決手段】 ＣＰＵ１０１は、送受信装置１０４から
音楽情報を送信する場合、ＭＩＤＩ入力装置１０５を介
して入力されたＭＩＤＩデータにタイマ１０６を用いて
生成したそれを処理すべきタイミングを指定する時間長
データを付加し、それらを１イベント分のデータ（音楽
情報）としてＲＡＭ１０３に一旦格納した後、随時イベ
ント単位で送信する。その音楽情報を送受信装置１０４
で受信する場合には、受信したデータをＲＡＭ１０３に
一旦格納する一方、時間長データからそれが付加された
ＭＩＤＩデータの処理すべきタイミングを決定し、その
決定したタイミングに従ってＭＩＤＩデータを処理す
る。

Description

【発明の詳細な説明】

【０００１】

【発明の属する技術分野】本発明は、音楽情報の送受信
により受信側で楽音を発音させて演奏を行わせるための
技術に関する。

【０００２】

【従来の技術および発明が解決しようとする課題】現在
では、ＭＩＤＩ（Musical Instrument Digital Interfa
ce）が普及したこともあって、音楽情報を送信し、受信
側で楽音を発音させることが広く行われている。

【０００３】従来における音楽情報の送信は、例えば送
信側がノートオンやノートオフといったイベントのデー
タ（ＭＩＤＩデータ）を、それを処理させるタイミング
で受信側に順次送信することで行われている。しかし、
そのような音楽情報の送信では、送信側の負荷の重さ
や、イベントデータを送る送信路等によって受信側がイ
ベントデータを受信するタイミングが遅れ、演奏にズレ
が生じることがあるという問題点があった。

【０００４】演奏（楽音の発音タイミング等）のズレ
は、その演奏から受ける印象を大きく変化させることが
多く、音楽的な影響が大きい。そのため、演奏のズレが
生じないようにすることは強く要請されている。

【０００５】現在ではパーソナルコンピュータをシーケ
ンサ（自動演奏装置）として用いることも一般的に行わ
れており、様々な送信路を利用することができる状況と
なっている。周知のように、送信路によって送信に要す
る時間（送信時間）も様々に変化する。それ以外にも、
送受信の過程で音楽情報（の一部）が消えたり、或い
は、受信側で音楽情報（の一部）を正常に受信できない
ようなこともある。

【０００６】音楽情報の送受信の過程により、上記した
ようなことが生じても、受信側での演奏に大きな影響を
及ぼし、音楽的に大きな不具合を発生させる。そのた
め、これからは、イベントデータ（音楽情報）の送受信
の過程により生じる音楽的な不具合の発生を回避できる
ようにする要請が高まることが予想される。

【０００７】本発明の課題は、音楽情報の送受信の過程
により生じる音楽的な不具合の発生を回避できるように
することにある。

【０００８】

【課題を解決するための手段】本発明の音楽情報送信方
法は、受信側が受信しながら処理していくことで演奏を
行うための音楽情報を送信することを前提とする。

【０００９】第１の態様の音楽情報送信方法は、ノート
オン、ノートオフ等のイベントの内容を表すイベントデ
ータに、該イベントデータを処理すべきタイミングを表
す時間データを付加する第１の工程と、第１の工程で時
間データを付加したイベントデータを音楽情報として受
信側に順次送信する第２の工程と、を有する。

【００１０】第２の態様の音楽情報送信方法は、少なく
とも、ノートオン、ノートオフ等のイベントの内容を表
すイベントデータを、該イベントデータを処理させるべ
きタイミングに基づいて音楽情報として順次送信する第
１の工程と、第１の工程で送信されたイベントデータの
なかから予め定めた種類のイベントデータを抽出する第
２の工程と、第２の工程で抽出したイベントデータを所
定のタイミングで再度音楽情報として送信する第３の工
程と、を有する。

【００１１】本発明の音楽情報送信装置は、受信側が受
信しながら処理していくことで演奏を行うための音楽情
報を送信することを前提とする装置である。第１の態様
の音楽情報送信装置は、ノートオン、ノートオフ等のイ
ベントの内容を表すイベントデータに、該イベントデー
タを処理すべきタイミングを表す時間データを付加する
時間データ付加手段と、時間データ付加手段によって時
間データが付加されたイベントデータを音楽情報として
受信側に順次送信する送信手段と、を具備する。

【００１２】第２の態様の音楽情報送信装置は、少なく
とも、ノートオン、ノートオフ等のイベントの内容を表
すイベントデータを、該イベントデータを処理させるべ
きタイミングに基づいて音楽情報として順次送信する第
１の送信手段と、第１の送信手段によって送信されたイ
ベントデータのなかから予め定めた種類のイベントデー
タを抽出する抽出手段と、抽出手段が抽出したイベント
データを所定のタイミングで再度音楽情報として送信す
る第２の送信手段と、を具備する。

【００１３】本発明の第１の態様の音楽情報受信方法
は、第１の態様の音楽情報送信方法、或いは第１の態様
の音楽情報送信装置によって送信された音楽情報を受信
しながら処理していくことで演奏を行うことを前提と
し、音楽情報を受信する第１の工程と、第１の工程で受
信した音楽情報中の時間データから、該時間データが付
加されたイベントデータを処理すべきタイミングを決定
する第２の工程と、第２の工程で決定したタイミングに
従って、第１の工程で受信した音楽情報中のイベントデ
ータを処理する第３の工程と、を有する。

【００１４】なお、上記第２の工程では、時間データか
ら、音楽情報が送信されてから受信されるまでに要した
送信時間の変動を求め、該求めた送信時間の変動をタイ
ミングの決定に反映させる、ことが望ましい。また、受
信した音楽情報中の制御データを基に、該音楽情報を正
常に受信しているか否か判定し、該音楽情報を正常に受
信していないと判定した場合に、該音楽情報による演奏
を中止する、ことが望ましい。

【００１５】本発明の第２の態様の音楽情報受信方法
は、第１の態様の音楽情報送信方法、或いは第１の態様
の音楽情報送信装置によって送信された音楽情報を受信
しながら処理していくことで演奏を行うことを前提と
し、音楽情報を受信する第１の工程と、第１の工程で受
信した音楽情報を所定の記憶手段に記憶させる第２の工
程と、第１の工程で受信した音楽情報中のイベントデー
タを処理するタイミングを、該イベントデータに付加さ
れた時間データ、及び記憶手段の空容量に基づいて決定
する第３の工程と、第３の工程で決定したタイミングに
従って、第１の工程で受信した音楽情報中のイベントデ
ータを処理する第４の工程と、を有する。

【００１６】本発明の第３の態様の音楽情報受信方法
は、第２の態様の音楽情報送信方法、或いは第２の態様
の音楽情報送信装置によって送信された音楽情報を受信
しながら処理していくことで演奏を行うことを前提と
し、音楽情報を受信する第１の工程と、第１の工程で受
信した音楽情報中のイベントデータを処理すべきか否か
判定する第２の工程と、第２の工程の判定結果に従っ
て、第１の工程で受信した音楽情報中のイベントデータ
を処理する第３の工程と、を有する。

【００１７】本発明の第１の態様の音楽情報受信装置
は、第１の態様の音楽情報送信方法、或いは第１の態様
の音楽情報送信装置によって送信された音楽情報を受信
しながら処理していくことで演奏を行うことを前提とし
た装置であって、音楽情報を受信する受信手段と、該受
信手段が受信した音楽情報中の時間データから、該時間
データが付加されたイベントデータを処理すべきタイミ
ングを決定するタイミング決定手段と、タイミング決定
手段によって決定されたタイミングに従ってイベントデ
ータを処理する処理手段と、を具備する。

【００１８】なお、上記の構成において、タイミング決
定手段は、時間データから、音楽情報が送信されてから
受信されるまでに要した送信時間の変動を求め、該求め
た送信時間の変動をタイミングの決定に反映させる、こ
とが望ましい。また、処理手段は、受信手段が受信した
音楽情報中の制御データを基に、該音楽情報を正常に受
信しているか否か判定し、該音楽情報を正常に受信して
いないと判定した場合に、該音楽情報による演奏を中止
する、ことが望ましい。

【００１９】本発明の第２の態様の音楽情報受信装置
は、第１の態様の音楽情報送信方法、或いは第１の態様
の音楽情報送信装置によって送信された音楽情報を受信
しながら処理していくことで演奏を行うことを前提とし
た装置であって、音楽情報を受信する受信手段と、受信
手段が受信した音楽情報を記憶する記憶手段と、受信手
段が受信した音楽情報中のイベントデータを処理するタ
イミングを、該イベントデータに付加された時間デー
タ、及び記憶手段の空容量に基づいて決定するタイミン
グ決定手段と、タイミング決定手段が決定したタイミン
グに従って、記憶手段に記憶された音楽情報中のイベン
トデータを処理する処理手段と、を具備する。

【００２０】本発明の第３の態様の音楽情報受信装置
は、第２の態様の音楽情報送信方法、或いは第２の態様
の音楽情報送信装置によって送信された音楽情報を受信
しながら処理していくことで演奏を行うことを前提とし
た装置であって、音楽情報を受信する受信手段と、受信
手段が受信した音楽情報中のイベントデータを処理すべ
きか否か判定する判定手段と、判定手段の判定結果に従
って、受信手段が受信した音楽情報中のイベントデータ
を処理する処理手段と、を具備する。

【００２１】本発明の音楽情報送受信装置は、受信側が
受信しながら処理していくことで演奏を行うための音楽
情報を送受信することを前提とした装置であって、ノー
トオン、ノートオフ等のイベントの内容を表すイベント
データに、該イベントデータを処理すべきタイミングを
表す時間データを付加する時間データ付加手段と、時間
データ付加手段によって時間データが付加されたイベン
トデータを音楽情報として受信側に順次送信する送信手
段と、音楽情報を受信する受信手段と、該受信手段が受
信した音楽情報中の時間データから、該時間データが付
加されたイベントデータを処理すべきタイミングを決定
するタイミング決定手段と、該タイミング決定手段によ
って決定されたタイミングに従ってイベントデータを処
理する処理手段と、を具備する。

【００２２】なお、上記の構成において、送信手段は、
受信側に、音楽情報の送信量を表す制御データを随時送
信し、処理手段は、受信手段が受信した音楽情報中の制
御データを基に、該音楽情報を正常に受信しているか否
か判定し、該音楽情報を正常に受信していないと判定し
た場合に、該音楽情報による演奏を中止する、ことが望
ましい。

【００２３】本発明の第１の態様の記録媒体は、ノート
オン、ノートオフ等のイベントの内容を表すイベントデ
ータ毎に、該イベントデータを処理すべきタイミングを
表す時間データを付加する手段と、該付加する手段によ
って時間データが付加されたイベントデータを音楽情報
として順次送信する手段と、を実現させるためのプログ
ラムを記録している。

【００２４】本発明の第２の態様の記録媒体は、少なく
とも、ノートオン、ノートオフ等のイベントの内容を表
すイベントデータを、該イベントデータを処理させるべ
きタイミングに基づいて音楽情報として順次送信する手
段と、該送信する手段によって送信されたイベントデー
タのなかから予め定めた種類のイベントデータを抽出す
る手段と、該抽出する手段によって抽出されたイベント
データを音楽情報として所定のタイミングで再送する手
段と、を実現させるためのプログラムを記録している。

【００２５】本発明の第３の態様の記録媒体は、音楽情
報を受信する手段と、該受信する手段によって音楽情報
が受信された場合に、該受信された音楽情報中の時間デ
ータから、該時間データが付加されたイベントデータを
処理すべきタイミングを決定する手段と、該決定する手
段によって決定されたタイミングに従ってイベントデー
タを処理する手段と、を実現させるためのプログラムを
記録している。

【００２６】本発明の第４の態様の記録媒体は、音楽情
報を受信する手段と、該受信する手段によって受信され
た音楽情報を記憶手段に記録させる手段と、受信する手
段により受信された音楽情報中のイベントデータを処理
するタイミングを、該イベントデータに付加された時間
データ、及び記憶手段の空容量に基づいて決定する手段
と、該決定する手段によって決定されたタイミングに従
ってイベントデータを処理する手段と、を実現させるた
めのプログラムを記録している。

【００２７】本発明の第５の態様の記録媒体は、音楽情
報を受信する手段と、該受信する手段により受信された
音楽情報中のイベントデータを処理すべきか否か判定す
る手段と、該判定する手段の判定結果に従って、受信す
る手段により受信された音楽情報中のイベントデータを
処理する手段と、を実現させるためのプログラムを記録
している。

【００２８】本発明の第６の態様の記録媒体は、ノート
オン、ノートオフ等のイベントの内容を表すイベントデ
ータに、該イベントデータを処理すべきタイミングを表
す時間データを付加する手段と、該付加する手段によっ
て時間データが付加されたイベントデータを音楽情報と
して順次送信する手段と、該音楽情報を受信する手段
と、該受信する手段によって音楽情報が受信された場合
に、該受信された音楽情報中の時間データから、該時間
データが付加されたイベントデータを処理すべきタイミ
ングを決定する手段と、該決定する手段によって決定さ
れたタイミングに従ってイベントデータを処理する手段
と、を実現させるためのプログラムを記録している。

【００２９】本発明では、受信側が受信しながら処理し
ていくことで演奏を行うための音楽情報を構成するイベ
ントデータに、該イベントデータを処理すべきタイミン
グを表す（指定する）時間データを付加して順次送信す
る。その時間データを付加することで、イベントデータ
を受信側に処理させるべき適切なタイミングで必ずしも
送信する必要はなくなり、また、受信側ではイベントデ
ータをより適切なタイミングで処理することが可能とな
る。

【００３０】本発明では、送信したイベントデータのな
かから、予め定めた種類のイベントデータを抽出し、抽
出したイベントデータを再送させる。それにより、抽出
したイベントデータを受信側に確実に受信させられるよ
うになる。

【００３１】本発明では、受信した音楽情報中の時間デ
ータから、該時間データが付加されたイベントデータを
処理すべきタイミングを決定し、受信した音楽情報中の
イベントデータを決定したタイミングに従って処理す
る。そのように、時間データを基にイベントデータを処
理することから、受信したタイミングに関わらずにイベ
ントデータを適切なタイミングで処理する、或いはイベ
ントデータをより適切なタイミングで処理することが可
能となる。

【００３２】本発明では、受信した音楽情報中の時間デ
ータ、及びその音楽情報を記憶する記憶手段（音楽情報
の格納用に割り当てられた記憶領域）の空容量に基づ
き、該時間データが付加されたイベントデータを処理す
べきタイミングを決定し、そのタイミングに従って処理
する。記憶手段の空容量を考慮してタイミングを決定す
ることで、それに記憶させた音楽情報を確実に処理する
ことが可能となる。

【００３３】本発明では、受信した音楽情報中のイベン
トデータを処理すべきか否か判定し、その判定結果に従
ってイベントデータを処理する。それにより、たとえ繰
り返し同じイベントデータが送信されたとしても、その
送信の繰り返しの演奏への影響を確実に回避させられる
ようになる。

【００３４】上記の発明を基に音楽情報の送受信を行う
ことにより、音楽情報の送受信の過程（送信路等だけで
なく、送信側、或いは受信側の装置の状態も含む）によ
り生じる音楽的な不具合の発生を回避、或いはそれを低
減させられるようになる。

【００３５】

【発明の実施の形態】以下、図面を参照しながら、本発
明の実施の形態につき詳細に説明する。 ＜第１の実施の形態＞図１は、本実施の形態による音楽
情報送受信装置の構成図である。本実施の形態による音
楽情報送受信装置は、鍵盤等の演奏操作子群を備えた各
種のコントローラや電子楽器といった外部の装置から出
力された音楽（演奏）情報を入力し、それを他の外部の
装置に出力する装置として実現されている。

【００３６】その音楽情報送受信装置は、図１に示すよ
うに、装置全体の制御を行うＣＰＵ１０１と、プログラ
ムや各種制御用データ等を格納したＲＯＭ１０２と、Ｃ
ＰＵ１０１が作業用に用いるＲＡＭ１０３と、特には図
示しない外部の装置、例えば他の楽音情報送受信装置と
の間でデータの送受信を行う送受信装置１０４と、特に
は図示しないケーブルで接続された電子キーボード１１
１が出力したＭＩＤＩデータを入力するＭＩＤＩ入力装
置１０５と、時間を計時するタイマ１０６と、特には図
示しないケーブルで接続された音源装置１１２にＭＩＤ
Ｉデータを出力するＭＩＤＩ出力装置１０７と、を備え
て構成されている。

【００３７】以上の構成において、その動作を説明す
る。不図示の電源がオンされると、ＣＰＵ１０１はＲＯ
Ｍ１０２に格納されたプログラムを読み出して実行する
ことにより、装置全体の制御を開始する。その後は、特
には図示しない各種スイッチへのユーザの操作や電子キ
ーボード１１１から受け取ったＭＩＤＩデータに応じ
て、ＲＡＭ１０３を作業用に使用しながら、ユーザが要
求した機能を実現するための制御を行う。

【００３８】電子キーボード１１１は、それが備えた鍵
盤（キーボード）や各種スイッチに対してユーザが行っ
た操作内容を、ＭＩＤＩデータの形でＭＩＤＩ入力装置
１０５に出力（通知）する。ＣＰＵ１０１は、そのよう
にしてＭＩＤＩ入力装置１０５に入力されたＭＩＤＩデ
ータを、ユーザの設定（指定）に応じてＭＩＤＩ出力装
置１０７から音源装置１１２に出力させるか、或いは送
受信装置１０４から他の音楽情報送受信装置に送信させ
る。

【００３９】ユーザがＭＩＤＩ出力装置（音源装置１１
２）１０７を指定した場合、ＣＰＵ１０１は、ＭＩＤＩ
入力装置１０５がＭＩＤＩデータを入力する度に、その
ＭＩＤＩデータを直ちにＭＩＤＩ出力装置１０７に送っ
て音源装置１１２に出力させる。それにより、ユーザの
電子キーボード１１１への操作に応じて音源装置１１２
から楽音をリアルタイムに発音させる。

【００４０】一方、ユーザが送受信装置１０４（例えば
他の音楽情報送受信装置）を指定した場合には、例えば
その指定が行われた時点でタイマ１０６を起動させると
ともに、送信させるデータを一時格納しておく領域をＲ
ＡＭ１０３内に確保する。その後は、ＭＩＤＩ入力装置
１０５がＭＩＤＩデータを入力する度に、そのＭＩＤＩ
データが入力したタイミングを表す時間データをタイマ
１０６の値から生成し、その時間データとＭＩＤＩデー
タを１イベント分のデータとしてＲＡＭ１０３内に確保
した領域に一旦格納しつつ、その領域にそれまでに格納
した未送信分のデータを送受信装置１０４から送信させ
ることを繰り返す。その時間データは、受信側ではＭＩ
ＤＩデータを処理すべきタイミングを指定しているもの
として扱われる。

【００４１】その送受信装置１０４は、シリアルの送信
経路に対応させるために、データをビット列に置換して
直列に送信するようになっている（受信時はその逆）。
そのようにして送信されたデータが、ケーブル、更には
所定の通信回線（例えば公衆網）を介して外部の装置に
送られる。以降、混乱を避けるために、その外部の装置
は他の音楽情報送受信装置であるとして説明することに
する。

【００４２】なお、本実施の形態では、ＭＩＤＩデータ
が入力したタイミングを、直前のＭＩＤＩデータが入力
されてから経過した時間（デルタタイム）で表す方法を
採用している。その時間を表す値である時間データにつ
いては、以降、時間長データと呼ぶことにする。その時
間長データは例えば２バイトのデータである。

【００４３】送受信装置１０４は、他の音楽情報送受信
装置にデータを送信する他に、それから送信されたデー
タを受信する。ＣＰＵ１０１は、送受信装置１０４が受
信したデータを、例えば以下のように処理する。

【００４４】送受信装置１０４が受信するデータは、上
記したように、ＭＩＤＩデータに時間長データが付加さ
れたものである。時間長データによって指定されたタイ
ミングでＭＩＤＩデータを処理するために、ＣＰＵ１０
１は、例えばデータの受信をユーザが指示した時点でタ
イマ１０６を起動するとともに、受信したデータを一時
的に格納しておく領域をＲＡＭ１０３内に確保する。そ
の後は、データを受信する度に、それをＲＡＭ１０３内
に確保した領域に格納しつつ、時間長データからＭＩＤ
Ｉデータを処理すべきタイミングの時刻、即ちタイマ１
０６の値を特定する一方、その特定したタイミングとな
ったＭＩＤＩデータを、ＭＩＤＩ出力装置１０７を介し
て音源装置１１２に出力する。それにより、音源装置１
１２に楽音を発音させて演奏を行わせる。

【００４５】このようにして、受信側は、時間長データ
で指定されたタイミングでＭＩＤＩデータを処理する。
そのため、送信側はＭＩＤＩデータを適切なタイミング
で送信する必要がなくなり、送信路等による遅延を考慮
して早めにＭＩＤＩデータを送信することができるよう
になる。一方、ＭＩＤＩデータを送信するタイミング
は、送信側はイベントのデータを一旦ＲＡＭ１０３に格
納することから、そこから読み出すタイミングで変更す
ることができる。これらのことから、受信側は常に時間
長データで指定されたタイミングでＭＩＤＩデータを処
理することができるようになり、演奏のズレは確実に回
避されることになる。

【００４６】ところで、例えば和音（コード）では、普
通、それを構成する複数の楽音の発音タイミングが基本
的には同時となる。従って、音楽情報をシリアルに送信
すると、それらのイベントデータを送信する時点で既に
タイミングにズレが生じることになる。そのズレは、通
常はさほど問題にはならない。しかし、例えばマルチト
ラックの演奏時に複数のトラックで和音（コード）のよ
うなイベントが重なり合うと、換言すれば、あるタイミ
ングで送信すべきイベントデータの数が多くなると、そ
れらを全て送信するのにより長い時間が必要となること
から、送信時のズレが大きくなる。

【００４７】上記のような状況で発生するズレは、処理
させるべきタイミングで音楽情報（ＭＩＤＩデータ）を
送信していく従来の方法では回避することはできない。
しかし、本実施の形態では、上記したように、必ずしも
処理させるべきタイミングで音楽情報（ＭＩＤＩデー
タ）を送信しなくとも良いことから、従来の方法では回
避できなかったズレの発生も容易、且つ確実に回避する
ことができる。

【００４８】一方、音楽情報（ＭＩＤＩデータ）を受信
してからそれを実際に処理するまでに要する処理時間
は、装置によって異なる。このため、複数の装置に音楽
情報を送信する場合には、送信側が適切なタイミングで
音楽情報（ＭＩＤＩデータ）を送信しても、各装置毎に
異なる演奏のズレが生じることがある。

【００４９】音楽情報（ＭＩＤＩデータ）を受信してか
らそれを実際に処理するまでの工程は、音楽情報（ＭＩ
ＤＩデータ）を受信する工程と、それを処理する工程と
に大別することができる。本実施の形態では、処理させ
るべきタイミングの前に音楽情報（ＭＩＤＩデータ）を
送信できる。そのため、少なくとも前者の工程に要する
時間が演奏に影響するのを回避することができる。その
結果、複数の異なる装置に音楽情報を送信する場合であ
っても、装置毎の演奏のズレをより抑えることができ
る。

【００５０】次に、上記したＣＰＵ１０１の動作につい
て、図２〜図９に示す動作フローチャートを参照して詳
細に説明する。それらにフローチャートで示す処理は、
ＣＰＵ１０１がＲＯＭ１０２からプログラムを読み出し
て実行することにより実現される。

【００５１】図２〜図５は、送信処理の動作フローチャ
ートである。この送信処理は、上記したように、ユーザ
が所定のスイッチを操作して送受信装置１０４からＭＩ
ＤＩデータ（音楽情報）を送信させることを指定した場
合に実行される。

【００５２】先ず、ステップ２０１では、イニシャライ
ズを行う。そのイニシャライズとしては、例えばタイマ
１０６の起動、ＲＡＭ１０３に保持させる各種変数への
初期値の代入、送信するデータを一時格納しておくＲＡ
Ｍ１０３内の領域の確保を行い、送受信装置１０４には
受信側との回線の接続等を行わせる。それが終了した
後、ステップ２０２に移行する。なお、データの送信
用、或いは受信用にＲＡＭ１０３に確保した領域につい
ては、以降、送受信用領域と呼ぶことにする。

【００５３】ステップ２０２では、電子キーボード１１
１からＭＩＤＩデータが入力されたか否か判定する。ユ
ーザが電子キーボード１１１に対して何らかの操作を行
った場合、電子キーボード１１１はＭＩＤＩデータを出
力することから判定がＹＥＳとなってステップ２０３に
移行する。そうでない場合には、その判定はＮＯとなっ
て図５のステップ２２４に移行する。なお、ＭＩＤＩ入
力装置１０５がＭＩＤＩデータを入力したことは、例え
ばその旨を表す割り込み信号によってＣＰＵ１０１に通
知される。

【００５４】ステップ２０３〜ステップ２２３では、Ｍ
ＩＤＩ入力装置１０５がＭＩＤＩデータを入力したこと
に伴う処理が行われる。先ず、ステップ２０３では、タ
イマ１０６の現在値の読み込みを行う。その読み込んだ
値は変数ＴＩＭＥＲに代入し、続くステップ２０４で
は、新たに入力されたＭＩＤＩデータがその直前のＭＩ
ＤＩデータが入力されてから経過した時間を算出し、そ
の算出結果（時間長データ）を変数ＳＵＢＵＮに代入す
る。現在のタイマ１０６の値は変数ＴＩＭＥＲに、直前
のＭＩＤＩデータが入力された際のタイマ１０６の値は
変数ＦＴＩＭＥＲに代入されている。そのため、変数Ｓ
ＵＢＵＮには、変数ＴＩＭＥＲの値から変数ＦＴＩＭＥ
Ｒの値を減算した値が代入される。

【００５５】なお、最初のＭＩＤＩデータの入力、即ち
ステップ２０４の実行が１回目であった場合には、ステ
ップ２０１で変数ＦＴＩＭＥＲに０を代入し、タイマ１
０６はユーザが送信先を指定した際に起動したとする
と、変数ＳＵＢＵＮには送信先を指定してから電子キー
ボード１１１に何らかの操作を行うまでの時間（を表す
値）が代入されることになる。

【００５６】変数ＳＵＢＵＮに新たな値を代入した後
は、ステップ２０５に移行して、変数ＴＩＭＥに変数Ｓ
ＵＢＵＮの値を代入する。続くステップ２０６では、変
数ＷＲＩＴＥＣＯＵＮＴＥＲの値から、ＲＡＭ１０３の
送受信用領域にデータを格納するアドレスを特定する。
その後、ステップ２０７に移行する。

【００５７】本実施の形態では、ＲＡＭ１０３の送受信
用領域に、送信させるデータ、或いは受信したデータを
先頭から順次格納していき、その領域にデータを全て格
納した場合には、再度先頭から格納していくようにして
いる。上記変数ＷＲＩＴＥＣＯＵＮＴＥＲは、送受信用
領域内において次のデータの格納先を管理するための変
数である。データの読み出し先の管理用の変数は、変数
ＲＥＡＤＣＯＵＮＴＥＲである。変数ＴＩＭＥは、時間
長データを保持しておくための変数である。

【００５８】ステップ２０７では、変数ＷＲＩＴＥＣＯ
ＵＮＴＥＲの値と変数ＲＥＡＤＣＯＵＮＴＥＲの値とが
等しくないか否か判定する。送信させるデータは送受信
用領域内に一旦格納した後に送信させている。その領域
に未送信分のデータが残っていないときにはそれらの変
数の値は等しくなる。そのため、未送信分のデータが送
受信用領域に残っていない場合、ステップ２０７の判定
はＮＯとなって図４のステップ２１８に移行する。そう
でない場合には、その判定はＹＥＳとなってステップ２
０８に移行する。

【００５９】図４のステップ２１８〜２２３では、新た
なＭＩＤＩデータの入力に伴って送受信用領域に１イベ
ント分のデータを格納するための処理が行われる。その
１イベント分のデータは、ＭＩＤＩデータ、及び時間長
データから構成される。

【００６０】先ず、ステップ２１８では、変数ＷＲＩＴ
ＥＣＯＵＮＴＥＲの値によって指定（特定）される送受
信用領域内の格納先に、ステップ２０５で変数ＴＩＭＥ
に代入した時間長データ及びＭＩＤＩデータを書き込
む。それが終了した後、ステップ２１９〜２２２で形成
される処理ループを実行し、予め定めた上限値（送受新
領域の大きさに対応する値である）を超えるときには０
を代入しつつ、変数ＷＲＩＴＥＣＯＵＮＴＥＲの値の更
新（カウントアップ）を、ステップ２１８で格納したデ
ータのバイト数分だけ行う。

【００６１】時間長データは２バイト、１イベント分の
ＭＩＤＩデータは通常２、３バイトである。そのため、
普通、１イベントで変数ＷＲＩＴＥＣＯＵＮＴＥＲの値
は４、５回更新（カウントアップ）されることになる。
そのことから、送受信用領域は１バイトで表現できる大
きさ（例えば１２８バイト）としても、そこには少なく
とも２０イベント分以上のデータを格納でき、送信タイ
ミングを調整するうえでは十分な時間を確保することが
できるようになる。そのため、本実施の形態では、変数
ＷＲＩＴＥＣＯＵＮＴＥＲ、ＲＥＡＤＣＯＵＮＴＥＲの
有効ビット数も８ビットとし、ＭＩＤＩの規格に合わせ
ている。それにより、ＲＡＭ１０３に必要な記憶容量を
抑えるとともに、後述する１イベント当たりに送信する
データ量も必要最小限に抑えるようにしている。

【００６２】上記バイト数分の更新（カウントアップ）
が終了すると、ステップ２２２の判定がＹＥＳとなって
処理ループを抜け、ステップ２２３に移行する。そのス
テップ２２３では、変数ＦＴＩＭＥＲに変数ＴＩＭＥＲ
の値を代入、即ち変数ＦＴＩＭＥＲに現在時刻を表す値
を代入してその値を更新する。その後、図２のステップ
２０２に戻る。

【００６３】一方、図２のステップ２０８〜図３のステ
ップ２１７では、送受信用領域に格納されている未送信
分のデータの送信に関わる処理が行われる。先ず、ステ
ップ２０８〜２１０では、現在の変数ＲＥＡＤＣＯＵＮ
ＴＥＲの値、時間長データ、及びＭＩＤＩデータを１イ
ベント分のデータ（上記したように、通常は５、６バイ
トである）として送信する。詳細については後述する
が、変数ＲＥＡＤＣＯＵＮＴＥＲの値は、データの送受
信が正常に行われているか否かを判定するために制御デ
ータとして送信しているものである。それが終了した
後、図３のステップ２１１に移行する。なお、データの
送信は、例えばＣＰＵ１０１が、それらを送受信装置１
０４内のバッファに書き込むことで行われる。

【００６４】図３のステップ２１１〜２１４で形成され
る処理ループでは、変数ＷＲＩＴＥＣＯＵＮＴＥＲのと
きと同様に、予め定めた上記の上限値を超えるときには
０を代入するようにしつつ、変数ＲＥＡＤＣＯＵＮＴＥ
Ｒの値の更新（カウントアップ）を、ステップ２０８〜
２１０で送信したデータのバイト数分だけ行う。そのバ
イト数分の更新（カウントアップ）が終了すると、ステ
ップ２１４の判定がＹＥＳとなって処理ループを抜け、
ステップ２１５に移行する。

【００６５】ステップ２１５では、ステップ２０８〜２
１０で送信したデータが最初のＭＩＤＩデータであるか
否か判定する。そのステップ２１５は、ＭＩＤＩデータ
を送信した後に実行される。演奏フラグは、演奏中か否
かを管理するための変数であり、ステップ２０１のイニ
シャライズで０が初期値として代入される。そのため、
例えば変数フラグの値が０であった場合、その判定がＹ
ＥＳとなってステップ２１６に移行する。そうでない場
合には、即ち演奏フラグの値が１であった場合には、そ
の判定はＮＯとなって図２のステップ２０７に戻る。

【００６６】ステップ２１６では、受信側に演奏の開始
を指示する演奏開始コードを送信する。続くステップ２
１７では、演奏フラグに１を代入する。それが終了した
後、図２のステップ２０７に戻る。

【００６７】上記した処理ステップまでの処理動作を要
約すると、以下のようになる。最初のＭＩＤＩデータを
入力したときには、変数ＷＲＩＴＥＣＯＵＮＴＥＲの値
と変数ＲＥＡＤＣＯＵＮＴＥＲの値とは等しいことか
ら、ステップ２０７の判定はＮＯとなって、送受信用領
域にそのＭＩＤＩデータが時間長データとともに送受信
用領域に格納される。

【００６８】次のＭＩＤＩデータが入力したときには、
それらの変数の値は異なっていることから、ステップ２
０７の判定はＮＯとなって、送受信用領域に格納されて
いる未送信分のデータの送信が行われる。データの送信
は、イベント単位で行い、１イベント分のデータの送信
が終了すると、ステップ２０７に戻る。そのため、デー
タの送信は、ステップ２０７の判定がＮＯとなるまで繰
り返し行われる。

【００６９】そのようなデータの送信を行った結果、ス
テップ２０７の判定がＮＯとなると、新たに入力された
ＭＩＤＩデータと時間長データとを送受信用領域に格納
する。その格納が終了すると、ステップ２０２に戻る。
そのため、それ以降は、新たにＭＩＤＩデータが入力す
る度に、未送信分のデータを送信した後、次に送信すべ
きデータを送受信用領域に格納するという動作を同様に
繰り返すことになる。

【００７０】図２の説明に戻って、ＭＩＤＩデータの新
たな入力がなかった場合の動作について説明する。ＭＩ
ＤＩデータの新たな入力がなかった場合には、ステップ
２０２の判定がＮＯとなって図５のステップ２２４に移
行する。

【００７１】そのステップ２２４では、タイマ１０６の
現在値の読み込み、その値を変数ＴＩＭＥＲに代入す
る。続くステップ２２５では、変数ＴＩＭＥＲの値から
変数ＦＴＩＭＥＲの値を減算した値、即ち直前のＭＩＤ
Ｉデータが入力されてから経過した時間（を表す値）を
変数ＳＵＢＵＮに代入する。その後、ステップ２２６に
移行する。

【００７２】本実施の形態では、予め定めた時間内にＭ
ＩＤＩデータが入力されなかった場合、データの送信を
中止し、外部の装置による演奏を停止させるようにして
いる。これは、ＭＩＤＩデータの入力（ユーザの電子キ
ーボード１１１への操作）に応じてデータの送信を行う
ようにしていることから、ＭＩＤＩデータの入力間隔が
開いても、受信側にＭＩＤＩデータを処理すべきタイミ
ングより遅れて送信するようなことを回避するためであ
る。その機能は、ステップ２２６〜２２９を実行するこ
とで実現される。

【００７３】ステップ２２６では、変数ＳＵＢＵＮの値
が予め定めた時間に対応する所定値より大きいか否か判
定する。ユーザが電子キーボード１１１の操作をその時
間以上行わなかった場合、その判定はＹＥＳとなってス
テップ２２７に移行する。そうでない場合には、その判
定はＮＯとなって図２のステップ２０２に戻る。

【００７４】ステップ２２７では、受信側に演奏の停止
を指示する演奏停止コードを送信する。続くステップ２
２８では、演奏フラグに０を代入する。演奏フラグに０
を代入すると、ステップ２２９でＲＡＭ１０３内の不必
要なデータの消去といったイニシャライズを行った後、
一連の処理を終了する。

【００７５】このようにして、電子キーボード１１１か
ら出力されたＭＩＤＩデータは、時間長データが付加さ
れるとともに、ＲＡＭ１０３を利用したタイミングの調
整を行って送信される。

【００７６】次に、上記のようにして送信されるデータ
の受信処理について、図６〜図９に示すその動作フロー
チャートを参照して詳細に説明する。その受信処理は、
例えば送信処理と同様に、ユーザが所定のスイッチを操
作して送受信装置１０４から音楽情報を取得するのを指
定した場合に実行される。

【００７７】先ず、ステップ６０１では、イニシャライ
ズを行う。そのイニシャライズとしては、例えばタイマ
１０６の起動、ＲＡＭ１０３に保持させる各種変数への
初期値の代入、受信したデータを一時格納しておく送受
信用領域をＲＡＭ１０３内に確保といったことを行う。
それが終了した後、ステップ６０２に移行する。

【００７８】ステップ６０２では、送受信装置１０４が
データを新たに受信していないか否か判定する。送受信
装置１０４がデータを受信していた場合、その判定はＮ
Ｏとなって図８のステップ６１６に移行する。そうでな
い場合には、その判定はＹＥＳとなってステップ６０３
に移行する。なお、データの受信は、例えば送受信装置
１０４が、その旨を示す割り込み信号を出力することに
より、ＣＰＵ１０１に通知される。

【００７９】図８のステップ６１６〜６２６では、送受
信装置１０４がデータを受信したことに伴う処理が行わ
れる。先ず、ステップ６１６では、受信したデータが演
奏開始コードか否か判定する。送受信装置１０４がその
演奏開始コードを受信した場合、その判定はＹＥＳとな
ってステップ６１７に移行する。そうでない場合には、
その判定はＮＯとなってステップ６１８に移行する。

【００８０】ステップ６１７では、演奏開始コードを受
信したことから、演奏中か否かを管理するための演奏フ
ラグに１を代入する。演奏開始コードは、上述したよう
に、最初のイベントのデータを送信した後に送信され
る。そのために、続くステップ６１７−１では、既に格
納されている最初のイベントの時間長データを読み込
む。更には、続くステップ６１７−２において、その時
間長データが付加されたＭＩＤＩデータを処理するタイ
ミングの時刻を、変数である現在時刻カウンタに代入す
る。具体的には、現在時刻カウンタに、時間長データと
変数ＴＩＭＥＲ（タイマ１０６の現在値）を加算した値
を代入する。それが終了した後、図６のステップ６０３
に戻る。

【００８１】ステップ６１８では、データとしてイベン
トのデータを受信したか否か判定する。イベントのデー
タを受信した場合、その判定はＹＥＳとなってステップ
６１９に移行する。そうでない場合には、即ち演奏開始
コードやイベントのデータ以外のデータを受信した場合
には、その判定はＮＯとなって図６のステップ６０３に
戻る。

【００８２】上記したように、１イベント分のデータ
は、変数ＲＥＡＤＣＯＵＮＴＥＲの値、時間長データ、
ＭＩＤＩデータの順序で送信される。ＭＩＤＩデータの
先頭はステータスバイトであり、その最上位ビットの値
は１である。そのステータスバイトからＭＩＤＩデータ
全体、更には１イベント分として送信されたデータの総
バイト数が特定される。このことから、本実施の形態で
は、先頭から３バイト目のデータの最上位ビットの値が
１、即ちステータスバイトで、且つそのステータスバイ
トから特定したバイト数のデータを受信した場合に、イ
ベントのデータを受信したと判定している。

【００８３】ステップ６１９では、変数ＷＲＩＴＥＣＯ
ＵＮＴＥＲの値を読み込む。続くステップ６２０では、
その変数の値が受信した変数ＲＥＡＤＣＯＵＮＴＥＲの
値より大きいか否か判定する。変数ＷＲＩＴＥＣＯＵＮ
ＴＥＲの値が受信した変数ＲＥＡＤＣＯＵＮＴＥＲの値
より大きかった場合、その判定はＹＥＳとなって図９の
ステップ６２７に移行する。そうでない場合には、その
判定はＮＯとなってステップ６２１に移行する。

【００８４】ステップ６２１では、変数ＲＥＡＤＣＯＵ
ＮＴＥＲの値が受信した変数ＲＥＡＤＣＯＵＮＴＥＲの
値より大きいか否か判定する。変数ＲＥＡＤＣＯＵＮＴ
ＥＲの値は送信側より受信側のほうが大きい場合、その
判定はＹＥＳとなって図９のステップ６２７に移行す
る。そうでない場合には、その判定はＮＯとなってステ
ップ６２２に移行する。

【００８５】データの送受信が正常に行われていれば、
本実施の形態では、変数ＲＥＡＤＣＯＵＮＴＥＲの受信
時において、その値は受信側の変数ＷＲＩＴＥＣＯＵＮ
ＴＥＲの値と等しくなる。変数ＷＲＩＴＥＣＯＵＮＴＥ
Ｒの値と変数ＲＥＡＤＣＯＵＮＴＥＲの値とでは、後者
の値は大きくても前者の値である。これらのことから判
るように、何れにしても、データの送受信が正常に行わ
れていれば、送信側の変数ＲＥＡＤＣＯＵＮＴＥＲの値
が、受信側の変数ＷＲＩＴＥＣＯＵＮＴＥＲの値や変数
ＲＥＡＤＣＯＵＮＴＥＲの値以下、即ちステップ６２０
や６２１の判定結果がＹＥＳとなることは有り得ない。
そのため、ステップ６２０、或いは６２１の判定がＹＥ
Ｓとなった場合には、エラーが発生したとして、図９の
ステップ６２７に移行してそのエラーへの対処が行われ
る。

【００８６】そのステップ６２７では、エラーが発生し
ていることから、ＭＩＤＩ出力装置１０７を介して音源
装置１１２に発音中の全ての楽音の消音（クリア）を指
示する。全ての楽音の消音を指示すると、次に、ステッ
プ６２８、６２９で形成される処理ループを実行して、
演奏停止コードを受信するのを待つ。

【００８７】演奏停止コードを受信すると、ステップ６
２９の判定がＹＥＳとなってその処理ループを抜けてス
テップ６３０に移行する。そのステップ６３０では、Ｒ
ＡＭ１０３に保持させた各種変数や送受信用領域のクリ
アといったイニシャライズを行い、その後に一連の処理
を終了する。

【００８８】このように、エラーが発生した場合には、
直ちに演奏を停止させている。そのため、エラーによっ
て演奏に実際には発音されない楽音が発音されたり、何
らかの楽音の発音が鳴りっぱなしになるといったことが
回避される。

【００８９】なお、本実施の形態では、制御データであ
る変数ＲＥＡＤＣＯＵＮＴＥＲの値を各イベント毎に付
加して送信しているが、例えば１０イベント毎といった
ように、ある決められた数のイベントのデータを送信す
る毎に制御データを送信するようにしても良い。制御デ
ータとしては、送信間隔をイベントといった単位で予め
決めておくような場合には、本実施の形態のように、デ
ータの送信量を表す値としなくとも良い。

【００９０】エラーの検出においては、送信側が送信し
た変数ＲＥＡＤＣＯＵＮＴＥＲの値が、受信側の変数Ｗ
ＲＩＴＥＣＯＵＮＴＥＲの値や変数ＲＥＡＤＣＯＵＮＴ
ＥＲの値以下か否かによりエラーの検出を行っている
が、それ以外の方法によってエラーを検出するようにし
ても良い。例えばデータが途中で消えるといったエラー
も検出できるように、例えば変数ＷＲＩＴＥＣＯＵＮＴ
ＥＲの値が受信した送信側の変数ＲＥＡＤＣＯＵＮＴＥ
Ｒの値よりも小さい（正常時と比較して）場合にもエラ
ーが発生したと判定して良い。

【００９１】一方、ステップ６２１の判定がＮＯ、即ち
データの送受信が正常と判定したときに実行されるステ
ップ６２２では、変数ＲＥＡＤＣＯＵＮＴＥＲの値以外
に受信した時間長データ及びＭＩＤＩデータを、変数Ｗ
ＲＩＴＥＣＯＵＮＴＥＲの値によって指定される送受信
用領域の格納先に書き込む。それが終了した後、ステッ
プ２１９〜２２２で形成される処理ループを実行し、予
め定めた上限値（送受新領域の大きさに対応する値であ
る）を超えるときには０を代入しつつ、変数ＷＲＩＴＥ
ＣＯＵＮＴＥＲの値の更新（カウントアップ）を、ステ
ップ２１８で格納したデータのバイト数分だけ行う。そ
の更新が終了すると、図６のステップ６０３に戻る。

【００９２】そのステップ６０３では、演奏フラグの値
が１か否か判定する。送信側から演奏開始コードが送
信、或いは既に送信されていた場合、その判定はＹＥＳ
となってステップ６０４に移行する。そうでない場合に
は、その判定はＮＯとなってステップ６０２に戻る。

【００９３】ステップ６０４では、タイマ１０６の現在
値を読み込み、それを変数ＴＩＭＥＲに代入する。続く
ステップ６０５では、その変数ＴＩＭＥＲの値が、上記
現在時刻カウンタの値よりも大きいか否か判定する。そ
の現在時刻カウンタの値は、次のイベント（ＭＩＤＩデ
ータ）を処理すべきタイマ１０６の値が代入されている
変数である。そのため、次のイベントを処理すべきタイ
ミングとなった場合には、その判定はＹＥＳとなってス
テップ６０６に移行する。そうでない場合には、即ち次
のイベントを処理すべきタイミングがまだ来ていない場
合には、その判定はＮＯとなってステップ６０２に戻
る。

【００９４】ステップ６０６では、次のイベントを処理
すべきタイミングとなったことから、変数ＲＥＡＤＣＯ
ＵＮＴＥＲの値を読み込み、続くステップ６０７では、
その値に基づいて送受信用領域からＭＩＤＩデータを読
み出す。それが終了した後、ステップ６０８に移行す
る。

【００９５】ステップ６０８では、ステップ６０７で読
み出したデータの種類を判別し、その判別結果に応じて
処理の移行先を決定する。具体的には、読み出したデー
タが演奏停止コードであった場合はステップ６０１に戻
り、読み出すべきデータが格納されていなかった場合は
ステップ６０２に戻り、読み出したデータがＭＩＤＩデ
ータであった場合にはステップ６０９に移行する。読み
出すべきデータが格納されていなかった場合にステップ
６０２に戻ることで、その場合には変数ＲＥＡＤＣＯＵ
ＮＴＥＲの値の更新（カウントアップ）を回避してい
る。

【００９６】ステップ６０９では、読み出したＭＩＤＩ
データを、ＭＩＤＩ出力装置１０７を介して音源装置１
１２に出力する。ＭＩＤＩデータを音源装置１１２に出
力した後は図７のステップ６１０に移行する。

【００９７】ステップ６１０〜６１３で形成される処理
ループでは、変数ＲＥＡＤＣＯＵＮＴＥＲの値が予め定
めた上記の上限値を超えるときには０を代入するように
しつつ、変数ＲＥＡＤＣＯＵＮＴＥＲの値の更新（カウ
ントアップ）を、ステップ６０９で処理したイベントの
バイト数分だけ行う。そのバイト数分の更新（カウント
アップ）が終了すると、ステップ６１３の判定がＹＥＳ
となって処理ループを抜け、ステップ６１４に移行す
る。ステップ６１４に移行時には、変数ＲＥＡＤＣＯＵ
ＮＴＥＲの値は次に処理すべきイベントのデータの先頭
バイトを指定する値となる。

【００９８】ステップ６１４では、その変数ＲＥＡＤＣ
ＯＵＮＴＥＲの値によって指定されるイベントの時間長
データを送受信用領域から読み込む。続くステップ６１
５では、その読み込んだ時間長データを用いて現在時刻
カウンタの更新を行う。具体的には、変数ＴＩＭＥＲの
値（タイマ１０６の現在値）に、読み込んだ時間長デー
タを加算した値を現在時刻カウンタに代入する。それが
終了した後、図２のステップ６０２に戻る。

【００９９】このように、受信処理を実行することで、
送信側が送信したイベント単位のデータは送受信用領域
に一旦格納され、その格納したデータは、それに含まれ
ている時間長データに従って処理される。それにより、
受信したタイミングによって発生する演奏のズレは確実
に回避される。

【０１００】なお、本実施の形態では、電子キーボード
１１１からＭＩＤＩデータが入力したタイミングで未送
信分のデータを送信するようにしているが、データを送
信するタイミングの取り方はこれに限定されるものでは
ない。例えば、時間長データを基に、受信側が処理すべ
きタイミングより予め定めた時間だけ早く受信するよう
にデータを送信しても良い。或いは、最初のイベントの
データだけをある程度遅らせ、それ以外のイベントのデ
ータは、入力後直ちに送信するようにしても良い。これ
らのように、データを送信するタイミングの取り方には
様々な方法があることから、特に限定されるものではな
い。

【０１０１】また、本実施の形態では、ユーザの演奏操
作に応じて電子キーボード１１１が出力するＭＩＤＩデ
ータ（イベントデータ）を送信するようにしているが、
本発明は随時入力されるデータの送信に限定されるもの
でもない。イベントデータに時間長データが予め付加さ
れている自動演奏用の音楽情報の送信に、本発明を適用
しても良い。 ＜第２の実施の形態＞最近では、イベントデータにそれ
の処理の実行を制御するための第１の制御データを加え
て処理単位となるデータ（命令）列を構成し、その処理
単位のデータ列の実行を制御するための第２の制御デー
タを更に加えて自動演奏用の演奏データ（音楽情報）を
構成することが提案されている（特願平６−１４９９５
８号参照）。第２の実施の形態は、そのようにしてデー
タがモジュール化されている演奏データ（音楽情報）を
受信して処理できるようにしたものである。

【０１０２】第２の実施の形態における構成は、上記第
１の実施の形態のそれと基本的に同じである。動作につ
いては、上記のような構成の演奏データを受信して処理
できるようになっていることだけが第１の実施の形態か
ら異なっている。そのため、第１の実施の形態で付与し
た符号をそのまま使用して、第１の実施の形態から異な
っている動作のみ説明することとする。

【０１０３】上記第１の制御データとしては、次に処理
すべきイベントデータ（ＭＩＤＩデータ）、或いは第１
の制御データを指定するジャンプ命令、主に分岐命令に
用いられるレジスタを対象とした演算命令等がある。第
２の制御データとしては、処理単位のデータ（命令）列
（以降、そのデータ（命令）列によって実行される処理
をタスクと呼ぶ）の実行開始を指示する命令（タスク生
成命令）、そのデータ（命令）列の実行終了を指示する
命令（タスク終了命令）等がある。タスク生成命令によ
って実行の開始が指示された処理単位のデータ（命令）
列は、処理対象としているタスクを時分割的に切り換え
ながら処理される。そのようにして各タスク（処理単
位）のデータ（命令）列が処理されることから、タスク
毎に演奏を行うタイミングや繰り返し等の設定が容易に
行えるようになっている。

【０１０４】上記したように、第２の実施の形態で受信
するのを想定している演奏データ（音楽情報）はモジュ
ール化され、また、ジャンプ命令等が用いることができ
るようになっている。そのため、送受信装置１０４を介
したデータの受信を指示した場合、ＣＰＵ１０１は、１
曲分の演奏データを格納できる大きさの送受信用領域を
ＲＡＭ１０３内に確保し、その送受信用領域に受信した
データを格納しつつ、それに格納されたデータをタスク
別に順次時分割的に切り換えながら処理する。以降、図
１０〜図１５を参照して、その動作について詳細に説明
する。

【０１０５】なお、特に詳細な説明は省略するが、上記
演奏データの送信は、例えば第１の実施の形態における
送信処理と同様に、最初に処理すべきイベントのデー
タ、演奏開始コードをこの順序で送信した後、処理すべ
きデータ或いはデータ列を順次シーケンシャルに送信し
ていくことで進行する。それらデータ或いはデータ列に
は、ジャンプ命令等に受信側が対処できるように、それ
らの格納先を指示するアドレスの値も付加されている。

【０１０６】図１０〜図１２は、第２の実施の形態によ
る受信処理の動作フローチャートである。最初に、これ
ら図１０〜図１２を参照して、受信処理について詳細に
説明する。なお、その受信処理は、例えば第１の実施の
形態と同様に、ユーザが所定のスイッチを操作して送受
信装置１０４から演奏データ（音楽情報）を取得するの
を指定した場合に、ＲＯＭ１０２に格納されたプログラ
ムを実行することで実現される処理である。

【０１０７】先ず、ステップ１００１では、イニシャラ
イズを行う。そのイニシャライズとしては、例えばタイ
マ１０６の起動、ＲＡＭ１０３に保持させる各種変数へ
の初期値の代入、受信したデータを格納しておく送受信
用領域をＲＡＭ１０３に確保といったことを行う。それ
が終了した後、ステップ１００２に移行する。

【０１０８】ステップ１００２では、送受信装置１０４
がデータを新たに受信していないか否か判定する。送受
信装置１０４がデータを受信していた場合、その判定は
ＮＯとなって図１２のステップ１０２０に移行する。そ
うでない場合には、その判定はＹＥＳとなってステップ
１００３に移行する。なお、データの受信は、例えば送
受信装置１０４が、その旨を示す割り込み信号を出力す
ることにより、ＣＰＵ１０１に通知される。

【０１０９】図１２のステップ１０２０〜１０３１で
は、送受信装置１０４がデータを受信したことに伴う処
理が行われる。先ず、ステップ１０２０では、受信した
データが演奏開始コードか否か判定する。送受信装置１
０４がその演奏開始コードを受信した場合、その判定は
ＹＥＳとなってステップ１０２１に移行する。そうでな
い場合には、その判定はＮＯとなってステップ１０２４
に移行する。

【０１１０】ステップ１０２１では、演奏開始コードを
受信したことから、演奏中か否かを管理するための演奏
フラグに１を代入する。演奏開始コードは、上述したよ
うに、最初に処理すべきイベントデータ（ＭＩＤＩデー
タ）を送信した後に送信される。そのために、続くステ
ップ１０２２では、既に格納されている最初のイベント
の時間長データを読み込む。更には、ステップ１０２３
において、その時間長データが付加されたＭＩＤＩデー
タを処理すべきタイミングの時刻を、変数である現在時
刻カウンタに代入する。それが終了した後、図１０のス
テップ１００２に戻る。

【０１１１】受信したデータをタスク別に処理していく
ために、第１の実施の形態とは異なり、データの読み出
し先を管理するための変数ＲＥＡＤＣＯＵＮＴＥＲ、及
び上記現在時刻カウンタを配列変数化している。現在処
理対象としているタスクは変数であるタスクカウンタＴ
Ｃで管理しており、それらの配列変数もタスクカウンタ
ＴＣによって管理されている。そのため、配列変数につ
いては、以降、それらの配列変数の最後には（ＴＣ）を
付け加えることにする。

【０１１２】一方、ステップ１０２４では、受信したの
は演奏停止コードか否か判定する。送信側が演奏停止コ
ードを送信した場合、その判定はＹＥＳとなってステッ
プ１０２５に移行する。そうでない場合には、その判定
はＮＯとなってステップ１０２７に移行する。

【０１１３】ステップ１０２５では、演奏停止コードを
受信したことから、演奏フラグに０を代入する。続くス
テップ１０２６では、ＲＡＭ１０３内の送受信用領域の
クリアといったイニシャライズを行う。その後、一連の
処理を終了する。このようにして、ステップ１０２５、
それに続くステップ１０２６では、送信側からの演奏停
止の指示に対処する処理が行われる。

【０１１４】ステップ１０２４の判定がＹＥＳのときに
移行するステップ１０２７では、演奏データを構成する
データを受信したか否か判定する。上記したように、演
奏データを構成するデータ（コマンド）は、大別して、
イベントデータ、第１及び第２の制御データの３種類が
ある。それらのデータには、ジャンプ命令（第１の制御
データ）等に受信側が対処できるように、送信側でそれ
を読み出したアドレスの値が付加されて送信されてい
る。それらのデータの形式は予め定められている。その
ため、変数ＲＥＡＤＣＯＵＮＴＥＲの値を含むデータを
受信した場合、ステップ１０２４の判定はＹＥＳとなっ
てステップ１０２８に移行する。そうでない場合には、
その判定はＮＯとなって図１０のステップ１００２に戻
る。

【０１１５】ステップ１０２８では、受信したアドレス
の値を変数ＷＲＩＴＥＣＯＵＮＴＥＲに書き込む。その
変数ＷＲＩＴＥＣＯＵＮＴＥＲは、第１の実施の形態と
同様に、データの書き込み先を管理するための変数であ
る。

【０１１６】ステップ１０２８に続くステップ１０２９
では、受信したアドレスの値が変数ＷＲＩＴＥＣＯＵＮ
ＴＥＲで示される最終アドレスの値よりも大きいか否か
判定する。その最終アドレスの値は、ＲＡＭ１０３内に
確保した送受信用領域の大きさ、より具体的にはバイト
数に対応する。そのため、受信したアドレスの値が送受
信用領域のバイト数よりも大きかった場合、その判定は
ＹＥＳとなってステップ１０３０に移行する。そうでな
い場合には、その判定はＮＯとなってステップ１０３１
に移行する。

【０１１７】受信したアドレスの値が送受信用領域のバ
イト数よりも大きかった場合、受信したデータを書き込
む先が特定できないことから、送受信用領域にそのデー
タを書き込むことができない。そのため、ステップ１０
３０では、データの送信、或いは受信にエラーが発生し
たとして、それに対処するための例外処理を実行する。
その後、一連の処理を終了する。他方のステップ１０３
１では、受信したアドレスの値、即ち変数ＷＲＩＴＥＣ
ＯＵＮＴＥＲの値が指定するアドレスから時間長デー
タ、それが付加されたＭＩＤＩデータ等のコマンドを送
受信用領域に書き込む。それが終了した後、図１０のス
テップ１００２に戻る。

【０１１８】図１０に戻って、ステップ１００３以降の
処理について説明する。ステップ１００３では、演奏フ
ラグの値が１か否か判定する。送信側が送信した演奏開
始コードを受信していた場合、その判定はＹＥＳとなっ
てステップ１００４に移行する。そうでない場合には、
その判定はＮＯとなってステップ１００２に戻る。

【０１１９】ステップ１００４〜図１１のステップ１０
１９では、受信したデータに従った自動演奏を実現する
ための処理が行われる。先ず、ステップ１００４では、
タスクカウンタＴＣの初期化、即ち予め定めた値の代入
を行う。そのタスクカウンタＴＣは、上記したように、
処理対象としているタスクを管理するための変数であ
る。

【０１２０】ステップ１００４に続くステップ１００５
では、タイマ１０６の現在値を読み込み、それを変数Ｔ
ＩＭＥＲに代入する。続くステップ１００６では、タス
クカウンタＴＣが指定するタスクに対応した現在時刻カ
ウンタ（ＴＣ）の値が、その変数ＴＩＭＥＲの値以上か
否か判定する。現在時刻カウンタ（ＴＣ）には、次のイ
ベント（ＭＩＤＩデータ）を処理すべきタイミングとな
ったときのタイマ１０６の値が代入されている。そのた
め、次のイベントを処理すべきタイミングとなった場合
には、その判定はＮＯとなって図１１のステップ１００
９に移行する。そうでない場合には、即ち次のイベント
を処理すべきタイミングがまだ来ていない場合には、そ
の判定はＹＥＳとなってステップ１００７に移行する。

【０１２１】ステップ１００７では、現在処理対象とし
ているタスクでは次のイベントを処理すべきタイミング
となっていないことから、処理対象を他のタスクに変更
するためにタスクカウンタＴＣのインクリメントを行
う。その後、ステップ１００８に移行する。

【０１２２】ステップ１００８では、インクリメント後
のタスクカウンタＴＣの値が所定値より大きいか否か判
定する。タスク生成命令によって実行を開始したタスク
には、例えばシーケンシャルに数字が順次割り当てられ
る。このことから、上記所定値は、例えばそれまでにタ
スクに割り当てた数字の最大値である。そのため、現在
実行中のタスクを一通り処理対象とした場合、その判定
はＹＥＳとなってステップ１００２に戻る。そうでない
場合には、その判定はＮＯとなってステップ１００５に
戻る。

【０１２３】このように、ステップ１００５〜１００８
は処理ループを形成しており、その処理ループの実行を
繰り返すことで、タスクカウンタＴＣによって指定され
たタスクに対する処理が行われていく。そのタスクに処
理すべきデータ（イベント）が存在していた場合、ステ
ップ１００６の判定がＹＥＳとなって図１１のステップ
１００９に移行し、そのデータに対する処理が以下のよ
うに行われる。

【０１２４】先ず、ステップ１００９では、現在処理対
象としているタスクに対応する変数ＲＥＡＤＣＯＵＮＴ
ＥＲ（ＴＣ）の値を読み込む。続くステップ１０１０で
は、その変数ＲＥＡＤＣＯＵＮＴＥＲ（ＴＣ）の値に基
づいて送受信用領域から処理すべきデータを読み込む。
その後、ステップ１０１１に移行する。

【０１２５】ステップ１０１１では、ステップ１０１０
で読み込んだデータの種類（内容）を判定する。その種
類がＭＩＤＩデータであった場合、次にステップ１０１
２に移行して、ＭＩＤＩデータを処理する音楽処理を実
行した後、ステップ１０１４に移行する。その種類が第
１、或いは第２の制御データであった場合には、次にス
テップ１０１３に移行して、それらの制御データを処理
するタスク処理を実行した後、ステップ１０１４に移行
する。なお、音楽処理、タスク処理についての詳細は後
述する。

【０１２６】ステップ１０１４〜１０１６で形成される
処理ループでは、変数ＲＥＡＤＣＯＵＮＴＥＲ（ＴＣ）
を、その値がオーバーフロー、即ちその値がＲＡＭ１０
１３の送受信用領域外のアドレスを示しているか否かを
判定しつつ、ステップ１０１２の音楽処理、或いはステ
ップ１０１３のタスク処理で処理したデータのバイト数
だけインクリメントする。そのバイト数のインクリメン
トが終了すると、ステップ１０１７に移行する。

【０１２７】ステップ１０１７では、インクリメント後
の変数ＲＥＡＤＣＯＵＮＴＥＲ（ＴＣ）の値に基づい
て、次に処理すべきデータに付加された時間長データを
送受信用領域から読み込む。それが終了すると、続くス
テップ１０１８でそのデータを処理すべきタイミングと
なったときのタイマ１０６の値を算出して現在時刻カウ
ンタ（ＴＣ）に代入する。より具体的には、現在時刻カ
ウンタ（ＴＣ）に、読み込んだ時間長データの値に変数
ＴＩＭＥＲの値（タイマ１０６の現在値）を加算した値
を代入する。その後、図１０のステップ１００７に戻
る。

【０１２８】一方、ステップ１０１４〜１０１６で形成
される処理ループを実行中に変数ＲＥＡＤＣＯＵＮＴＥ
Ｒ（ＴＣ）の値がオーバーフローを起こした場合、ステ
ップ１０１５の判定がＹＥＳとなってステップ１０１９
に移行する。そのステップ１０１９では、データの送
信、或いは受信に何らかのエラーが発生したとして例外
処理を実行する。その後、一連の処理を終了する。

【０１２９】このように、各種の制御データを含む演奏
データ（音楽情報）を対象とした受信処理では、受信し
たデータは随時送受信用領域内に格納し、それに格納し
た受信データに対しては、処理対象とするタスクを順次
変更しながら、各タスクで処理すべきタイミングとなっ
たデータを随時処理することが行われる。

【０１３０】次に、上記受信処理内で実行されるサブル
ーチン処理について、図１３〜図１５を参照して詳細に
説明する。図１３は、図１１のステップ１０１２で実行
される音楽処理の動作フローチャートである。始めに、
図１３を参照して音楽処理について詳細に説明する。

【０１３１】この音楽処理は、ＭＩＤＩ出力装置１０７
を介して音源装置１１２を制御するための処理である。
その処理が開始すると、ステップ１３０１で処理すべき
ＭＩＤＩデータをＭＩＤＩ出力装置１０７に出力する。
そのＭＩＤＩデータを出力した後、一連の処理を終了す
る。

【０１３２】図１４は、図１１のステップ１０１３で実
行されるタスク処理の動作フローチャートである。次
に、図１４を参照してタスク処理について詳細に説明す
る。なお、図１４は、制御データのなかで使用頻度の高
いもの、具体的にはジャンプ命令、指定したレジスタを
用いた演算命令、及びタスク生成命令に対する処理の流
れを抜粋して示したものである。

【０１３３】このタスク処理を開始した後は、先ず、ス
テップ１４０１で処理すべきデータ（命令）の種類を判
定する。その後は、その判定した種類に応じて処理が行
われる。

【０１３４】そのデータ（命令）の種類がジャンプ命令
と判定した場合、ステップ１４０２に移行し、変数ＲＥ
ＡＤＣＯＵＮＴＥＲ（ＴＣ）に、ジャンプ先となるデー
タの格納場所を示す値を代入する。その後、一連の処理
を終了する。

【０１３５】演奏データには、詳細な説明は省略する
が、それ自体では何の機能も発揮しない制御コード（フ
ラグ）を挿入することができ、ジャンプ命令は、その制
御コードを指定してデータの実行個所を変更するように
なっている。そのため、ステップ１４０２を実行するこ
とで、変数ＲＥＡＤＣＯＵＮＴＥＲ（ＴＣ）には、指定
された制御コード（フラグ）の格納先に対応する値が代
入される。

【０１３６】ステップ１４０１で判定したデータ（命
令）の種類が演算命令であった場合には、ステップ１４
０３に移行する。そのステップ１４０３では、その命令
に従って、その命令で指定したレジスタ（タスクワーク
レジスタ）の値に対する操作を行う。それを行った後、
一連の処理を終了する。

【０１３７】ステップ１４０１で判定したデータ（命
令）の種類がタスク生成命令であった場合には、ステッ
プ１４０４に移行する。そのステップ１４０４では、そ
の命令で指定されたタスクを実行中のタスクとして登録
することで、そのタスクを生成する。それを行った後、
一連の処理を終了する。

【０１３８】上記タスク処理を実行することで、各種制
御データに割り当てた機能が実現され、タスクを単位と
した演奏の開始や終了、それの繰り返し等が制御される
ことになる。

【０１３９】図１５は、図１１のステップ１０１９、或
いは図１２のステップ１０３０で実行される例外処理の
動作フローチャートである。例外処理は、データの送
信、或いは受信にエラーが発生したと判定した場合に、
そのエラーに対処するために実行される。次に、この図
１５を参照して、例外処理について詳細に説明する。

【０１４０】先ず、ステップ１５０１では、エラーが発
生したことから、ＭＩＤＩ出力装置１０７を介して音源
装置１１２に発音中の全ての楽音の消音（クリア）を指
示する。全ての楽音の消音を指示すると、次に、ステッ
プ１５０２、１５０３で形成される処理ループを実行し
て、演奏停止コードを受信するのを待つ。

【０１４１】送受信装置１０４が演奏停止コードを受信
すると、ステップ１５０３の判定がＹＥＳとなってその
処理ループを抜けてステップ１５０４に移行する。その
ステップ１５０４では、演奏フラグに演奏中ではないこ
とを示す０を代入する。続くステップ１５０５では、Ｒ
ＡＭ１０３に保持させた各種変数や送受信用領域のクリ
アといったイニシャライズを行い、その後に一連の処理
を終了する。

【０１４２】このように、エラーが発生した場合には、
直ちに演奏を停止させている。そのため、エラーによっ
て演奏に実際には発音されないはずの楽音が発音された
り、何らかの楽音が鳴りっぱなしになるといったことが
確実に回避される。 ＜第３の実施の形態＞ＭＩＤＩデータの送信に用いる通
信回線、或いはその使用状況等により、ＭＩＤＩデータ
が送信されてから受信されるまでの送信時間が変動する
ことがある。この第３の実施の形態は、上記第１の実施
の形態と比較して、そのような送信時間の変動により適
応できるようにしたものである。

【０１４３】第３の実施の形態における構成は、基本的
に第１の実施の形態のそれ（図１参照）と同じである。
そのため、第１の実施の形態の説明で用いた符号を流用
して、第１の実施の形態から異なる部分のみ説明するこ
とにする。

【０１４４】第３の実施の形態では、電源がオンされる
と、タイマ１０６を起動させるようになっている。ＣＰ
Ｕ１０１は、そのタイマ１０６の値を用いて、以下のよ
うに、ＭＩＤＩデータの送信、及び受信時の処理を行っ
ている。ここでも、データの送受信の対象は他の音楽情
報送受信装置であるとして説明する。

【０１４５】送信の対象となるＭＩＤＩデータは、ＭＩ
ＤＩ入力装置１０５を介して電子キーボード１１１から
入力される。ＣＰＵ１０１は、そのＭＩＤＩデータに、
タイマ１０６の値（電源がオンしてから経過した時間
（を表す値））を時間データとして付加し、それらを１
イベント分のデータとして送受信装置１０４から送信さ
せる。

【０１４６】送信側のタイマの値と受信側のタイマ１０
６の値とは、通常は一致しない。そのため、第３の実施
の形態では、送信側から送られてくる時間データ（送信
時のタイマの値）から送信側のタイマの値との違いを補
正するための値を算出し、その値を基に、送信側が付加
した時間データに沿ってＭＩＤＩデータを処理するよう
にしている。その補正するための値は、変数である補正
レジスタに保持させている。

【０１４７】送信時間があるため、時間データとして送
られてきた送信側のタイマの値からだけでは、送信側の
タイマの値と受信側のタイマ１０６の値との間の違いを
正確に特定することはできない。その送信時間自体も常
に一定であるとは限らない。送信に用いる通信回線やそ
の状態、或いは送信側と受信側の位置関係等によって、
送信時間が比較的大きく変動することがある。その送信
時間の変動は、楽音を発音させるタイミングのズレとな
って表面化する。このことから、第３の実施の形態で
は、送信側から送られる時間データを基に、その変動の
影響を低減させるようにしている。その影響の低減は、
後述するようにして、上記補正レジスタの値を変更する
ことで行っている。

【０１４８】送信されてきたデータは、ＲＡＭ１０３に
確保した送受信用領域に一旦格納する。その送受信用領
域に格納したＭＩＤＩデータを処理するタイミングを、
ＣＰＵ１０１は、それに付加された時間データ、及び補
正レジスタの値から決定し、その決定したタイミングに
従ってＭＩＤＩデータをＭＩＤＩ出力装置１０７に出力
することで処理する。それにより、音源装置１１２から
楽音を発音させる。

【０１４９】ところで、送信時間の変動は、或る時間内
に送信されたデータを、受信側にそれよりも短い時間内
で集中的に受信させるようなことを起こすことがある。
換言すれば、単位時間当たりのデータの受信量を異常に
増大させることがある。

【０１５０】それは、送受信用領域に多くのデータを短
い時間内に格納する必要性が生じたことを意味する。そ
の送受信用領域には、上記したように、データを書き込
むアドレスをサイクリックに変更させている。このた
め、短い時間内で大量のデータを送受信用領域に格納さ
せると、未処理のデータを消して上書きしてしまうこと
が起こり得る。それは、例えば或る楽音が鳴りっぱなし
になるというようなことを生じさせるので、非常に望ま
しくない。

【０１５１】このことから、第３の実施の形態では、送
受信用領域の空容量（データが格納されていない領域、
及び既に処理したデータが格納されている領域の容量を
合計した量である）に応じて、データを処理するタイミ
ングを早めたり遅くしたりしている。そのことについて
の詳細は後述する。

【０１５２】なお、送受信用領域には、送信時間の変動
の他に、送信側と受信側のタイマが時間を計時するスピ
ードが異なることから未処理のデータが必要以上に大量
に格納されることも考えられる。これは、例えば送信側
のほうが受信側よりも計時のスピードが速い場合（単位
時間当たりのデータの処理量が受信側よりも送信側のほ
うが大きい場合）である。その送受信用領域について
は、以降、リングバッファと呼ぶことにする。

【０１５３】次に、上記したＣＰＵ１０１の動作につい
て、図１６〜図２１に示す動作フローチャートを参照し
て詳細に説明する。それらフローチャートで示す処理
は、ＣＰＵ１０１が、ＲＯＭ１０２からプログラムを読
み出して実行することにより実現される処理である。

【０１５４】図１６は、第３の実施の形態における送信
処理の動作フローチャートである。この送信処理は、第
１の実施の形態と同様に、ユーザが所定のスイッチを操
作して送受信装置１０４からＭＩＤＩデータ（音楽情
報）を送信させることを指定した場合に実行される。

【０１５５】先ず、ステップ１６０１では、イニシャラ
イズを行う。そのイニシャライズでは、例えば送受信装
置１０４に受信側との回線の接続等を行わせる。その
後、ステップ１６０２に移行する。

【０１５６】ステップ１６０２では、ＭＩＤＩ入力装置
１０５に電子キーボード１１１からＭＩＤＩデータが入
力されるのを待って、ＭＩＤＩ入力装置１０５からＭＩ
ＤＩデータを受け取る。続くステップ１６０３では、そ
のＭＩＤＩデータに、タイマ１０６の現在値を時間デー
タとして付加する。その後、ステップ１６０４に移行す
る。なお、タイマ１０６の現在値（現在時刻）は、第１
の実施の形態と同様に、変数ＴＩＭＥＲに保持して扱わ
れる。ＭＩＤＩデータ、及び時間データについては、第
３の実施の形態では共に４バイトを割り当てている。

【０１５７】ステップ１６０４では、時間データを付加
したＭＩＤＩデータを送受信装置１０４に送って送信さ
せる。その後、ステップ１６０２に戻る。ユーザが所定
のスイッチを操作してデータの送信の終了を指示するま
での間、ステップ１６０２〜１６０４で形成される処理
ループが繰り返し実行される。それにより、電子キーボ
ード１１１への操作に応じて送受信装置１０４からデー
タが送信されることになる。

【０１５８】図１７〜図２１は、第３の実施の形態にお
ける受信処理の動作フローチャートである。次に、図１
７〜図２１を参照して、受信処理について詳細に説明す
る。その送信処理は、第１の実施の形態と同様に、ユー
ザが所定のスイッチを操作して送受信装置１０４から音
楽情報を取得するのを指定した場合に実行される。

【０１５９】先ず、ステップ１７０１〜１７０４では、
イニシャライズに関わる処理を行う。それらの処理ステ
ップを実行することで、補正レジスタ、平均カウンタ、
平均レジスタ、及びリングバッファへのアクセスを管理
するための各種レジスタ（変数）に、それぞれ０が代入
され、リングバッファの内容はクリアされる。なお、平
均カウンタは、補正レジスタの値を変更するタイミング
を管理するための変数、平均レジスタは、その変更に用
いるデータを保持させる変数である。リングバッファへ
のアクセスを管理するための各種レジスタ（変数）に
は、データを書き込むアドレスを管理するための書き込
みアドレスや、それからデータを読み出すアドレスを管
理するための読み込みアドレス等がある。

【０１６０】ステップ１７０４に続くステップ１７０５
以降では、送受信装置１０４がデータを受信したことに
伴う処理が行われる。先ず、ステップ１７０５では、送
受信装置１０４がデータを受信したか否か判定する。送
受信装置１０４がデータを受信した場合、その判定はＹ
ＥＳとなってステップ１７０６に移行する。そうでない
場合には、後述する図２１の図ステップ１７３１に移行
する。なお、データの受信は、例えば送受信装置１０４
が、その旨を示す割り込み信号を出力することにより、
ＣＰＵ１０１に通知される。

【０１６１】ステップ１７０６では、受信されたデータ
から時間データを取り出し、続くステップ１７０７で
は、タイマ１０６の現在値（変数ＴＩＭＥＲの値）から
時間データの値を減算した値の絶対値を算出する。その
後、ステップ１７０８に移行する。なお、以降では、混
乱を避けるために、受信した時間データが示す時刻（時
間）を演奏時刻、タイマ１０６の現在値（変数ＴＩＭＥ
Ｒの値）を現在時刻と呼ぶことにする。また、ステップ
１７０７で算出した値については、絶対時刻差と呼ぶこ
とにする。

【０１６２】ステップ１７０８では、その絶対時刻差が
所定時間ａ（ｍｓ）より大きいか否か判定する。その所
定時間ａは、送信側と受信側との間に直ちに対処すべき
大きな時刻差が有るのか否かを判定するために設定した
時間である。そのため、送信側と受信側との間にそれ以
上の時刻差が存在していた場合、その判定はＹＥＳとな
ってステップ１７０９に移行する。そうでない場合に
は、即ち送信側と受信側の時刻が比較的に一致している
場合には、その判定はＮＯとなって図１８のステップ１
７１２に移行する。なお、上記所定時間ａは、例えば５
００（ｍｓ）相当の値である。

【０１６３】ステップ１７０９〜１７１１では、送信側
と受信側との間の大きな時刻差に対処するための処理が
行われる。先ず、ステップ１７０９では、受信した時間
データが示す時刻である演奏時刻から現在のタイマ１０
６が示す時刻である現在時刻を減算する。続くステップ
１７１０では、その減算値の正負に応じて、更に所定時
間ｂ（ｍｓ）を減算、或いは加算する。そのようにして
算出した値（時間）を、ステップ１７１１で補正レジス
タに代入する。その後、図１８のステップ１７１２に移
行する。

【０１６４】上記所定時間ｂは、送信時間の突出した変
動の処理への影響を緩和するために設定した時間であ
り、ａ＞ｂの関係にある。例えばａが５００であれば、
ｂは例えば２５０程度の値である。

【０１６５】普通、送信側と受信側の時刻は大きく異な
る。そのため、始めてのデータの受信では、その殆どの
場合でステップ１７０９〜１７１１が実行され、補正レ
ジスタに何らかの値が代入されることになる。

【０１６６】図１８のステップ１７１２〜１７２０で
は、平均カウンタ、及び平均レジスタを用いた補正レジ
スタの値の補正に関わる処理が行われる。先ず、ステッ
プ１７１２では、平均カウンタの値が所定値ｎ以下か否
か判定する。その所定値ｎは、補正レジスタの値の補正
を間欠的に行うために設定した値である。平均カウンタ
の値が所定値ｎ以下であった場合、その判定はＹＥＳと
なってステップ１７１３に移行する。そうでない場合に
は、その判定はＮＯとなってステップ１７１６に移行す
る。なお、図１８のステップ１７１２〜１７２０は送受
信装置１０４がデータを受信する度に実行されることか
ら、所定値ｎは、イベント数を表している。

【０１６７】ステップ１７１３では、平均カウンタをイ
ンクリメントする。続くステップ１７１４では、演奏時
刻から、現在時刻と補正レジスタの値を減算する。その
ようにして算出した減算値は、現在の補正レジスタの値
を用いて送信側と受信側との間の時刻差を調整させた際
に生じた誤差であるといえる。その誤差を、ステップ１
７１５で平均レジスタに累算、即ち元の値にステップ１
７１４で算出の値を加算して得られた値を平均レジスタ
に代入した後、図１９のステップ１７２１に移行する。
なお、上記の誤差は、送信時間の変動の他に、送信側と
受信側との間の計時速度（タイマ１０６がその値を更新
していく時間間隔）の違い等を原因にして生じることが
ある。

【０１６８】一方、ステップ１７１２の判定がＮＯとな
った場合に移行するステップ１７１６では、平均レジス
タの値を所定数ｎで割って平均値を算出する。その平均
値は、１回のデータの受信における誤差である。ステッ
プ１７１６に続くステップ１７１７〜１７２９は、その
誤差に応じて行われる。

【０１６９】ステップ１７１７では、その平均値が０以
上か否か判定する。その平均値が０以上であった場合、
その判定はＹＥＳとなってステップ１７１８に移行す
る。そうでない場合には、その判定はＮＯとなってステ
ップ１７１９に移行する。

【０１７０】補正レジスタには、正、或いは負の値が保
持される。平均値が０以上ということは、補正レジスタ
の値が正であれば、その値が小さすぎるということにな
る。補正レジスタの値が負であっても、その値が小さす
ぎるということになる。そのため、ステップ１７１８で
は、補正レジスタの値のインクリメントを行い、その後
にステップ１７２０に移行する。他方のステップ１７１
９では、逆に補正レジスタの値のデクリメントを行い、
その後にステップ１７２０に移行する。それらのインク
リメント、或いはデクリメントにより、補正レジスタが
表す時間が、予め定めた時間を単位として修正される。
このような修正を繰り返すことで、補正レジスタが表す
時間はより適正な時間に収束していくことになる。

【０１７１】ステップ１７２０では、平均カウンタ、及
び平均レジスタに０をそれぞれ代入する。その後、図１
９のステップ１７２１に移行する。それらのレジスタに
０を代入することで、補正レジスタの値の誤差によるそ
の補正が、所定値ｎで指定されたイベント数のデータが
受信される毎に行われることになる。

【０１７２】図１９のステップ１７２１では、リングバ
ッファの空容量を求める。上記したように、リングバッ
ファに次にデータを書き込むアドレスは書き込みアドレ
ス、データを読み出すアドレスは読み込みアドレスによ
って管理している。そのため、空容量は、それらの値か
ら求めることができる。

【０１７３】なお、書き込みアドレス、及び読み込みア
ドレスは、データはイベント単位で送信されることか
ら、イベントを単位としてリングバッファ内のアドレス
を管理するために用いている。１イベントのデータは８
バイトである。従って、それらの値は、８バイトを単位
としてアドレスを指定する。

【０１７４】ステップ１７２１に続くステップ１７２２
では、ステップ１７２１で求めた空容量がリングバッフ
ァ全体の容量の半分以下か否か判定する。空容量がリン
グバッファ全体の容量の半分以下であった場合、その判
定はＹＥＳとなってステップ１７２３に移行する。そう
でない場合には、その判定はＮＯとなってステップ１７
２４に移行する。

【０１７５】第３の実施の形態では、空容量が全体の半
分以下となっていた場合、未処理のデータを増える傾
向、換言すれば、データの受信量が、それの処理量より
も大きくなる傾向にあるとみなしている。そのため、ス
テップ１７２３では、データの処理量を増やすために、
補正レジスタの値のインクリメントを行う。他方のステ
ップ１７２４では、その反対に補正レジスタの値のデク
リメントを行う。そのような補正レジスタの値のインク
リメント、或いはデクリメントが終了した後、図２０の
ステップ１７２５に移行する。

【０１７６】上記のように、リングバッファの空容量に
応じて補正レジスタの値を変更することで、リングバッ
ファに格納されたデータの処理量を増減させる。それに
より、リングバッファに格納させたデータは、それを処
理するまで確実に残すことができ、発音させる楽音にヌ
ケが生じたり、楽音が鳴りっぱなしになるといったこと
が回避される。

【０１７７】ステップ１７２５〜１７３０では、受信デ
ータのリングバッファへの格納に関わる処理が行われ
る。先ず、ステップ１７２５では、受信データ中の演奏
時刻を、補正レジスタの値を用いて変更する。具体的に
は、演奏時刻から補正レジスタの値を減算し、その減算
結果を新たな演奏時刻とする。補正レジスタには、上記
したように、送信側と受信側の時刻差を基準とした値が
保持されている。そのため、変更後の演奏時刻は、それ
が付加されたＭＩＤＩデータを処理すべき受信側におけ
る時刻を表すものとなる。

【０１７８】ステップ１７２５に続くステップ１７２６
では、書き込みアドレスの値から、リングバッファに受
信データを書き込むアドレスを指定する。書き込みアド
レスにはイベント単位の値を保持させている。そのた
め、指定されるアドレスは、書き込みアドレスが保持し
ている値に８（１イベント分のデータのバイト数）を乗
算して得られる値のアドレス（リングバッファの先頭を
基準とした相対アドレス）となる。それが終了した後、
ステップ１７２７に移行する。

【０１７９】ステップ１７２７では、指定されたアドレ
スから受信データを書き込む。データの書き込み後は、
ステップ１７２８で書き込みアドレスの値のインクリメ
ントを行う。

【０１８０】リングバッファには、第３の実施の形態で
は１０２４イベントのデータを格納できる領域を割り当
てている。それに合わせて、書き込みレジスタの値域を
０〜１０２３としている。０は、リングバッファの先頭
に位置する１イベント分の記憶領域（８バイト）、１０
２３は、その最後に位置する１イベント分の記憶領域を
指定する値である。このことから、ステップ１７２８に
続くステップ１７２９では、インクリメント後の書き込
みアドレスの値が１０２３より大きいか否か判定する。
変数ＷＲＩＴＥＣＯＵＮＴＥＲの値が１０２３より大き
い場合、その判定はＹＥＳとなってステップ１７３０に
移行する。そうでない場合には、その判定はＮＯとなっ
て図２１のステップ１７３１に移行する。

【０１８１】ステップ１７３０では、書き込みアドレス
の値がリングバッファ内のアドレスを指定するように、
その値を補正する。具体的には、書き込みアドレスに０
を代入する。それが終了した後、図２１のステップ１７
３１に移行する。

【０１８２】ステップ１７３１〜１７３７では、リング
バッファに格納したデータから実際に楽音を発音させる
ことに関する処理が行われる。先ず、ステップ１７３１
では、読み込みアドレスの値から、リングバッファから
受信データを読み出すアドレスを指定する。読み込みア
ドレスにはイベント単位の値を保持させている。そのた
め、指定されるアドレスは、書き込みアドレスと同様
に、それが保持している値に８（１イベント分のデータ
のバイト数）を乗算して得られる値のアドレス（リング
バッファの先頭を基準とした相対アドレス）となる。そ
れが終了した後、ステップ１７３２に移行し、指定した
アドレスから受信データを読み出す。その後は、ステッ
プ１７３３に移行する。

【０１８３】ステップ１７３３では、読み出したデータ
中の演奏時刻（上記ステップ１７２５で変更された演奏
時刻である）が、現在時刻（タイマ１０６が現在計時し
ている時刻）と所定時間ｃとで特定される範囲内である
か否か判定する。演奏時刻がその範囲内であった場合、
その判定はＹＥＳとなってステップ１７３４に移行す
る。そうでない場合には、その判定はＮＯとなって図１
７のステップ１７０５に戻る。

【０１８４】演奏時刻はそれが付加されたＭＩＤＩデー
タを処理すべきタイミングを必ずしも正確に表していな
い。そのことから、第３の実施の形態では、ＭＩＤＩデ
ータを処理するタイミングに許容範囲を設けている。上
記所定時間ｃは、その許容範囲を基に設定したものであ
る。そのため、ステップ１７３３の判定がＹＥＳ、即ち
演奏時刻が上記範囲内であった場合には、その演奏時刻
が付加されたＭＩＤＩデータを処理すべきタイミングと
なったとみなして、それを処理している。なお、所定時
間ｃには、その絶対値が上記所定時間ａの絶対値を越え
ない範囲の値を設定している。

【０１８５】ステップ１７３４では、そのＭＩＤＩデー
タをＭＩＤＩ出力装置１０７に出力することで処理す
る。続くステップ１７３５では、読み込みアドレスの値
のインクリメントを行う。その後、ステップ１７３６に
移行する。

【０１８６】ステップ１７３６では、インクリメント後
の読み込みアドレスの値が１０２３より大きいか否か判
定する。その値が１０２３より大きい場合、その判定は
ＹＥＳとなってステップ１７３７に移行する。そうでな
い場合には、その判定はＮＯとなって図１７のステップ
１７０５に移行する。

【０１８７】ステップ１７３７では、読み込みアドレス
の値がリングバッファ内のアドレスを指定するように、
その値を補正する。具体的には、読み込みアドレスに、
リングバッファの先頭に位置するアドレスを指定する０
を代入する。それが終了した後、図１７のステップ１７
０５に戻る。

【０１８８】なお、第３の実施の形態では、ＭＩＤＩデ
ータを処理するタイミングの決定に用いる補正レジスタ
の値を、それに付加された時間データ（演奏時刻）、及
びリングバッファの空容量から、それぞれ独立的に補正
しているが、それらのうちの一方だけに基づいて補正レ
ジスタの値を補正するようにしても良い。リングバッフ
ァの空容量に注目した補正レジスタの値の補正では、演
奏を開始した時の空容量の割合、受信されるデータ量の
推移等を更に考慮して、その値を補正するようにしても
良い。時間データに着目した補正レジスタの値の補正で
は、予め定めたイベント数のデータを受信する度にその
補正を行っているが、その補正の頻度は、誤差の大きさ
に応じて増減させるようにしても良い。これら以外に
も、様々な変形が可能である。 ＜第４の実施の形態＞ＭＩＤＩデータでは、そのデータ
を全て受信側が受信できなかった場合、それが受信側で
の演奏に大きく影響することがある。第４の実施の形態
は、その影響を低減させるようにしたものである。

【０１８９】第４の実施の形態における構成は、基本的
に上記第３の実施の形態のそれ（図１参照）と同じであ
る。そのため、第３の実施の形態の説明で用いた符号を
流用して、第３の実施の形態から異なる部分のみ説明す
ることにする。

【０１９０】第４の実施の形態では、ＭＩＤＩデータの
なかで受信側が受信できなかった際の影響が他と比較し
て大きい種類を選択し、その選択した種類のＭＩＤＩデ
ータを送信すると、それを所定時間ｄ毎に繰り返し送信
するようにしている。それにより、未受信時の影響が大
きいデータを受信側に確実に受信させ、その影響を低減
させている。

【０１９１】他方のデータの受信時では、リングバッフ
ァに格納したデータを処理する際に、それが既に受信済
みのデータか否か、換言すれば、それが処理すべきデー
タか否か判定し、その判定結果に従ってデータを処理す
るようにしている。それにより、データが繰り返し送信
されても、それによる演奏上の不具合が発生するのを回
避させている。以下、それらを実現させるＣＰＵ１０１
の動作について、図２２〜図２５を参照して詳細に説明
する。

【０１９２】図２２、及び図２３は、第４の実施の形態
による送信処理の動作フローチャートである。始めに、
これら図２２、及び図２３を参照して、その送信処理に
ついて詳細に説明する。その送信処理は、第３の実施の
形態と同様に、ユーザが所定のスイッチを操作して送受
信装置１０４から音楽情報を送信させることを指定した
場合に実行される。

【０１９３】先ず、ステップ２２０１では、繰り返し送
信すべきデータを送信するタイミングを種類別に管理す
るための変数であるカウンタをクリア、即ち０を代入す
る。続くステップ２２０２では、他のレジスタにそれぞ
れ０を代入する。そのレジスタとしては、読み込みレジ
スタや書き込みレジスタ等がある。それらステップ２２
０１、及び２２０２は、送信処理におけるイニシャライ
ズに関わる処理として実行される。

【０１９４】ステップ２２０２に続くステップ２２０３
では、ＭＩＤＩ入力装置１０５に電子キーボード１１１
から新たに入力されたＭＩＤＩデータがあるか否か判定
する。ＭＩＤＩデータがＭＩＤＩ入力装置１０５に新た
に入力されていた場合、その判定はＹＥＳとなってステ
ップ２２０４に移行する。そうでない場合には、その判
定はＮＯとなって図２３の図２２１２に移行する。

【０１９５】ステップ２２０４では、ＭＩＤＩ入力装置
１０５からＭＩＤＩデータを受け取る。続くステップ２
２０５〜２２１１では、ＭＩＤＩ入力装置１０５から受
け取ったＭＩＤＩデータのイベントの種類を判別し、そ
の判別結果に応じた繰り返し送信させるＭＩＤＩデータ
の保存、或いはＭＩＤＩデータの送信を行うための処理
が行われる。ここでは、説明上、便宜的に、プログラム
チェンジ、ベンダ（ベンド）チェンジ、ベンダ（ベン
ド）レンジチェンジ、ダンパ（ホールド１）が繰り返し
送信させるＭＩＤＩデータのイベントの種類であるとし
て説明する。

【０１９６】なお、その種類は、それらに限定されるも
のではなく、それら以外の種類を選択しても良い。具体
的には、例えばコントロールチェンジのなかから、メイ
ンボリューム、バランスコントロール等を更に選択して
も良い。更には、チャンネルプレッシャやリセット・オ
ール・コントローラーズ等も選択に加えても良い。楽音
の鳴りっぱなしを確実に防止するために、ノートオフを
加えても良い。繰り返し送信させるイベントの種類をユ
ーザが選択できるようにしても良い。

【０１９７】先ず、ステップ２２０５では、ＭＩＤＩデ
ータのイベントがプログラムチェンジか否か判定する。
そのＭＩＤＩデータの１バイト目のデータ（ステータス
バイト）がプログラムチェンジであることを示していた
場合、その判定はＹＥＳとなってステップ２２０６に移
行し、そのＭＩＤＩデータをＲＡＭ１０３内に予め用意
した音色番号レジスタ（４バイトである）にストアす
る。その後、上記ステップ２２０３に戻る。

【０１９８】ステップ２２０７以降では、同様にして、
ＭＩＤＩデータのイベントがベンダチェンジであればそ
れをベンダレジスタにストアした後（ステップ２２０７
→２２０８）、ステップ２２０３に戻る。ＭＩＤＩデー
タのイベントがダンパであれば、それをダンパレジスタ
にストアした後（ステップ２２０９→２２１０）、ステ
ップ２２０３に戻る。ＭＩＤＩデータのイベントがベン
ダレンジチェンジであれば、それをベンダレンジレジス
タにストアした後（ステップ２２１１→２２１２）、ス
テップ２２０３に戻る。そのようにして、繰り返し送信
すべきと選択したイベントのＭＩＤＩデータを、ＲＡＭ
１０３内に予め用意した領域に種類別に格納する。

【０１９９】ＭＩＤＩ入力装置１０５から受け取ったＭ
ＩＤＩデータのイベントが繰り返し送信すべきと選択し
ていない種類であった場合、ステップ２２１１の判定が
ＮＯとなってステップ２２１３に移行する。そのステッ
プ２２１３では、タイマ１０６の現在値（受信側におけ
る演奏時刻：変数ＴＩＭＥＲの値）を時間データとして
ＭＩＤＩデータに付加し、それを送受信装置１０４から
送信させる。その後、ステップ２２０３に戻る。

【０２００】上記したように、ＭＩＤＩ入力装置１０５
に電子キーボード１１１から新たなＭＩＤＩデータが送
られていない場合、ステップ２２０３の判定がＮＯとな
って図２３のステップ２２１４に移行する。そのステッ
プ２２１４以降では、上述のようにして各種レジスタに
ストアした繰り返し送信すべきＭＩＤＩデータの送信に
関わる処理が行われる。

【０２０１】先ず、ステップ２２１４では、現在時刻を
取得、即ちタイマ１０６から現在値を受け取ってそれを
変数ＴＩＭＥＲに代入する。続くステップ２２１５で
は、その現在時刻が所定時間ｄを基に設定した所定時間
ｅで割り切れるか否か判定する。そのステップ２２１５
が、所定時間ｅで割り切れる時刻となってから次に割り
切れる時刻がくるまでの間で始めての実行であった場
合、その判定はＹＥＳとなってステップ２２１６に移行
する。そうでない場合には、その判定はＮＯとなって図
２２のステップ２２０３に戻る。ステップ２２１６以降
の処理を実行することにより、カウンタの値で指定され
る種類のイベントのＭＩＤＩデータが送信される。

【０２０２】そのステップ２２１６では、カウンタの値
が０か否か判定する。カウンタが保持している値が０で
あった場合、その判定はＹＥＳとなってステップ２２１
７に移行し、音色番号レジスタにストアされているＭＩ
ＤＩデータに現在時刻を付加して送受信装置１０４から
送信させる。その後、ステップ２２２４に移行する。そ
うでない場合には、その判定はＮＯとなってステップ２
２１８に移行する。なお、当然のことながら、音色番号
レジスタにＭＩＤＩデータがストアされていなければ、
ステップ２２１７でデータの送信を行うことなくステッ
プ２２２４に移行する。

【０２０３】ステップ２２１８以降では、同様にして、
カウンタの値が１であればベンダレジスタにストアされ
ているＭＩＤＩデータを送信させた後（ステップ２２１
８→２２１９）、ステップ２２２４に移行する。カウン
タの値が２であればダンパレジスタにストアされている
ＭＩＤＩデータを送信させた後（ステップ２２２０→２
２２１）、ステップ２２２４に移行する。カウンタの値
が３であればベンダレンジレジスタにストアされている
ＭＩＤＩデータを送信させた後（ステップ２２２２→２
２２３）、ステップ２２２４に移行する。そのようにし
て、各種レジスタにストアされているＭＩＤＩデータ
を、カウンタの値に応じて送信させる。

【０２０４】ステップ２２２４では、カウンタをインク
リメントする。それが終了すると、ステップ２２２５に
移行して、カウンタの値が４か否か判定する。インクリ
メントによってカウンタの値が４となった場合、その判
定はＹＥＳとなってステップ２２２６に移行し、カウン
タに０を代入した後、図２２のステップ２２０３に戻
る。そうでない場合には、その判定はＮＯとなって、カ
ウンタの値を変更させることなく図２２のステップ２２
０３に戻る。

【０２０５】このように、第４の実施の形態では、繰り
返し送信すべきと選択したイベントのＭＩＤＩデータを
繰り返し送信させている。そのため、受信側では、それ
らのイベントのＭＩＤＩデータを確実に受信することが
できるようになる。それにより、たとえデータが途中で
消えてしまうようなことがあったとしても、それの演奏
への影響を最小限に抑えることができる。

【０２０６】なお、上記所定時間ｄと所定時間ｅとは、
第４の実施の形態では繰り返し送信すべきイベントの種
類を４種類としていることから、ｄ＝４ｅの関係となっ
ている。

【０２０７】図２４、図２５は、第４の実施の形態にお
ける受信処理の動作フローチャートである。第４の実施
の形態は、第３の実施の形態における受信処理から、図
２１のステップ１７３１以降のみが異なっている。その
ため、図２４、図２５を参照して、その異なっている部
分のみ説明する。

【０２０８】第４の実施の形態では、図１７のステップ
１７０５の判定、或いは図２０のステップ１７２９の判
定がＮＯとなるか、或いは図２０のステップ１７３０の
処理が終了すると、図２４のステップ２４０１に移行す
る。そのステップ２４０１以降の処理を実行することに
より、リングバッファに格納されたデータは、それを処
理すべきか否か判定され、その判定結果に従って処理さ
れる。

【０２０９】そのステップ２４０１では、読み込みアド
レスの値から、リングバッファから受信データを読み出
すアドレスを指定する。続くステップ２４０２では、そ
のアドレスから受信データを読み出す。それが終了した
後は、ステップ２４０３に移行する。

【０２１０】ステップ２４０３では、読み出したデータ
中の演奏時刻（上記ステップ１７２５で変更された演奏
時刻である）が、現在時刻（タイマ１０６の現在値）と
所定時間ｃとで特定される範囲内であるか否か判定す
る。演奏時刻がその範囲内であった場合、その判定はＹ
ＥＳとなってステップ２４０４に移行する。そうでない
場合には、その判定はＮＯとなって図１７のステップ１
７０５に戻る。

【０２１１】ステップ２４０４では、ステップ２４０２
で読み出したＭＩＤＩデータのイベントがプログラムチ
ェンジか否か判定する。そのＭＩＤＩデータのステータ
スバイトがプログラムチェンジであることを表していた
場合、判定はＹＥＳとなってステップ２４０５に移行す
る。そうでない場合には、その判定はＮＯとなってステ
ップ２４０６に移行する。

【０２１２】ステップ２４０５では、ＭＩＤＩデータが
有する音色番号が、現在音源装置１１２に設定中の音色
番号と一致するか否か判定する。それらが一致していた
場合、その判定はＹＥＳとなって図２５のステップ２４
１３に移行する。そうでない場合には、その判定はＮＯ
となってステップ２４０６に移行する。なお、それらの
音色番号が一致しているか否かは、プログラムチェンジ
のＭＩＤＩデータを処理（ＭＩＤＩ出力装置１０７を介
して音源装置１１２に送出）した際に、そのＭＩＤＩデ
ータを音色番号レジスタにストアさせることで行えるよ
うにしている。これは、他の繰り返し送信すべきと選択
されているイベントのＭＩＤＩデータにおいても同様で
ある。

【０２１３】ステップ２４０６では、リングバッファか
ら読み出したＭＩＤＩデータのイベントがベンダチェン
ジか否か判定する。そのイベントがベンダチェンジであ
った場合、判定はＹＥＳとなってステップ２４０７に移
行する。そうでない場合には、その判定はＮＯとなって
ステップ２４０８に移行する。なお、イベントがベンダ
チェンジか否かは、ステータスバイトから判定される。

【０２１４】ステップ２４０７では、ＭＩＤＩデータ中
のベンダの値が音源装置１１２に設定中のベンダの値と
一致するか否か判定する。それらの値が一致した場合、
その判定はＹＥＳとなって図２５のステップ２４１３に
移行する。そうでない場合には、その判定はＮＯとなっ
てステップ２４０８に移行する。

【０２１５】ステップ２４０８では、リングバッファか
ら読み出したＭＩＤＩデータのイベントがダンパ（ホー
ルド１）か否か判定する。そのイベントがダンパであっ
た場合、判定はＹＥＳとなってステップ２４０９に移行
する。そうでない場合には、その判定はＮＯとなって図
２５のステップ２４１０に移行する。なお、イベントが
ダンパか否かは、ステータスバイトとそれに続く１バイ
トのデータバイトから判定される。

【０２１６】ステップ２４０９では、ＭＩＤＩデータ中
のダンパの値（０か１２７である）が音源装置１１２に
設定中のダンパの値と一致するか否か判定する。それら
の値が一致した場合、その判定はＹＥＳとなって図２５
のステップ２４１３に移行する。そうでない場合には、
その判定はＮＯとなって図２５のステップ２４１０に移
行する。

【０２１７】図２５のステップ２４１０では、リングバ
ッファから読み出したＭＩＤＩデータのイベントがベン
ダレンジチェンジか否か判定する。ＭＩＤＩデータのイ
ベントがベンダレンジチェンジであった場合、その判定
はＹＥＳとなってステップ２４１１に移行する。そうで
ない場合には、その判定はＮＯとなってステップ２４１
２に移行する。

【０２１８】ステップ２４１１では、ＭＩＤＩデータ中
のベンダレンジの値が音源装置１１２に設定中のベンダ
レンジの値と一致するか否か判定する。それらの値が一
致した場合、その判定はＹＥＳとなってステップ２４１
３に移行する。そうでない場合には、その判定はＮＯと
なってステップ２４１２に移行する。

【０２１９】ステップ２４１２では、ステップ２４０２
でリングバッファから読み出したＭＩＤＩデータは処理
すべきとして、ＭＩＤＩ出力装置１０７を介して音源装
置１１２に送出する。このとき、そのＭＩＤＩデータの
イベントが繰り返し送信すべきＭＩＤＩデータのイベン
トとして選択されていた場合には、そのイベントの種類
別に用意したレジスタのなかで対応するレジスタに、そ
のＭＩＤＩデータをストアする。

【０２２０】ステップ２４１２に続くステップ２４１３
では、読み込みアドレスの値のインクリメントを行う。
そのインクリメント後は、ステップ１７３６に移行し
て、読み込みアドレスの値が１０２３より大きいか否か
判定する。読み込みアドレスの値が１０２３より大きい
場合、その判定はＹＥＳとなり、ステップ２４１５に移
行して読み込みレジスタに０を代入した後、図１７のス
テップ１７０５に戻る。そうでない場合には、その判定
はＮＯとなって、読み込みレジスタの値を変更させるこ
となく図１７のステップ１７０５に戻る。

【０２２１】なお、第４の実施の形態では、繰り返し送
信すべきと選択されているイベントのＭＩＤＩデータ
を、無条件で繰り返し送信するようにしているが、例え
ば送信を繰り返す回数を設定しておき、その回数だけ送
信を繰り返すようにしても良い。また、受信時には、既
に処理したデータと一致しているか否か判定すること
で、繰り返し送信されてくるデータを重ねて音源装置１
１２に送出するのを回避しているが、必ずしもそうしな
くて良い。ＭＩＤＩデータには、重ねて処理しても実際
の演奏には影響しないものがあることから、処理（音源
装置１１２に送出）すべきか否かの判定を、その影響の
有無で行うようにしても良い。しかし、繰り返し送信さ
れてくるデータを重ねて音源装置１１２に送出するのを
回避させた場合には、音源装置１１２の負荷をより抑え
ることができるという効果がある。

【０２２２】また、第４の実施の形態では、ＭＩＤＩデ
ータに時間データを付加しているが、時間データは必ず
しもＭＩＤＩデータに付加しなくて良い。無視できない
送信時間がある伝送路（例えば公衆網）を介してＭＩＤ
Ｉデータ（音楽情報）を送信するといったような場合に
だけ、時間データを選択的に付加するようにしても良
い。

【０２２３】本実施の形態（第１〜第４の実施の形態）
は、音楽情報の送受信を行う専用の装置として実現させ
たものであるが、電子楽器や各種コントローラ、シーケ
ンサ、更にはパーソナルコンピュータ等に本発明を適用
させても良い。そのときには、当然のことながら、音楽
情報の送受信を行う機能を必ずしも搭載させる必要はな
く、音楽情報を送信する機能、及び受信する機能の何れ
か一方だけを搭載するようにしても良い。

【０２２４】パーソナルコンピュータへの本発明の適用
は、基本的には上記した動作を実現させるためのプログ
ラムをロードさせることで行うことができる。そのプロ
グラムは、ＣＤ−ＲＯＭやフロッピーディスクといった
携帯性に優れた記録媒体に記録して配布しても良く、何
らかの通信回線を介して配信しても良い。

【０２２５】

【発明の効果】以上説明したように、本発明では、受信
側が受信しながら処理していくことで演奏を行うための
音楽情報を構成するイベントデータに、該イベントデー
タを処理すべきタイミングを表す（指定するための）時
間データを付加して順次送信する。そのため、イベント
データを受信側に処理させるべき適切なタイミングで送
信しなければならない必要性を回避させることができ
る。他方の受信側では、その時間データを基に、イベン
トデータをより適切なタイミングで処理することができ
るようになる。本発明では、送信したイベントデータの
なかから、予め定めた種類のイベントデータを抽出し、
抽出したイベントデータを再送させる。そのため、抽出
したイベントデータを受信側に確実に受信させることが
できる。

【０２２６】本発明では、受信した音楽情報中の時間デ
ータから、該時間データが付加されたイベントデータを
処理すべきタイミングを決定し、受信した音楽情報中の
イベントデータを決定したタイミングに従って処理す
る。そのため、受信したタイミングに関わらずにイベン
トデータを適切なタイミングで処理する、或いはイベン
トデータをより適切なタイミングで処理することができ
る。

【０２２７】本発明では、受信した音楽情報中の時間デ
ータ、及びその音楽情報を記憶する記憶手段（音楽情報
の格納用に割り当てられた記憶領域）の空容量に基づ
き、該時間データが付加されたイベントデータを処理す
べきタイミングを決定し、そのタイミングに従って処理
する。そのため、記憶手段に記憶させた音楽情報を確実
に処理することができる。

【０２２８】本発明では、受信した音楽情報中のイベン
トデータを処理すべきか否か判定し、その判定結果に従
ってイベントデータを処理する。このため、たとえ繰り
返し同じイベントデータが送信されたとしても、その送
信の繰り返しが演奏に影響するのを確実に回避させるこ
とができる。

【０２２９】上記の発明を基に音楽情報の送受信を行う
ことにより、音楽情報の送受信の過程（送信路等だけで
なく、送信側、或いは受信側の装置の状態も含む）によ
り生じる音楽的な不具合（演奏（楽音の発音開始やその
終了といった発音タイミング等）のズレ、発音させる楽
音のヌケ、など）の発生を回避、或いはそれを低減させ
ることができる。

【図面の簡単な説明】

【図１】本実施の形態による音楽情報送受信装置の構成
図である。

【図２】送信処理の動作フローチャートである。

【図３】送信処理の動作フローチャートである（続き
１）。

【図４】送信処理の動作フローチャートである（続き
２）。

【図５】送信処理の動作フローチャートである（続き
３）。

【図６】受信処理の動作フローチャートである。

【図７】受信処理の動作フローチャートである（続き
１）。

【図８】受信処理の動作フローチャートである（続き
２）。

【図９】受信処理の動作フローチャートである（続き
３）。

【図１０】受信処理の動作フローチャートである（第２
の実施の形態）

【図１１】受信処理の動作フローチャートである（第２
の実施の形態：続き１）。

【図１２】受信処理の動作フローチャートである（第２
の実施の形態：続き２）。

【図１３】音楽処理の動作フローチャートである。

【図１４】タスク処理の動作フローチャートである。

【図１５】例外処理の動作フローチャートである。

【図１６】送信処理の動作フローチャートである（第３
の実施の形態）。

【図１７】受信処理の動作フローチャートである（第３
の実施の形態）。

【図１８】受信処理の動作フローチャートである（第３
の実施の形態：続き１）。

【図１９】受信処理の動作フローチャートである（第３
の実施の形態：続き２）。

【図２０】受信処理の動作フローチャートである（第３
の実施の形態：続き３）。

【図２１】受信処理の動作フローチャートである（第３
の実施の形態：続き４）。

【図２２】送信処理の動作フローチャートである（第４
の実施の形態）。

【図２３】送信処理の動作フローチャートである（第４
の実施の形態：続き１）。

【図２４】受信処理の動作フローチャートである（第４
の実施の形態：第３の実施の形態からの変更分１）。

【図２５】受信処理の動作フローチャートである（第４
の実施の形態：第３の実施の形態からの変更分２）。

【符号の説明】

１０１ ＣＰＵ １０２ ＲＯＭ １０３ ＲＡＭ １０４ 送受信装置 １０５ ＭＩＤＩ入力装置 １０６ タイマ １０７ ＭＩＤＩ出力装置 １１１ 電子キーボード １１２ 音源装置

Claims (22)

【特許請求の範囲】
1. 【請求項１】 受信側が受信しながら処理していくこと
   で演奏を行うための音楽情報を送信する方法であって、 ノートオン、ノートオフ等のイベントの内容を表すイベ
   ントデータに、該イベントデータを処理すべきタイミン
   グを表す時間データを付加する第１の工程と、 前記第１の工程で時間データを付加した前記イベントデ
   ータを前記音楽情報として前記受信側に順次送信する第
   ２の工程と、 を有することを特徴とする音楽情報送信方法。
2. 【請求項２】 受信側が受信しながら処理していくこと
   で演奏を行うための音楽情報を送信する方法であって、 少なくとも、ノートオン、ノートオフ等のイベントの内
   容を表すイベントデータを、該イベントデータを処理さ
   せるべきタイミングに基づいて前記音楽情報として順次
   送信する第１の工程と、 前記第１の工程で送信されたイベントデータのなかから
   予め定めた種類のイベントデータを抽出する第２の工程
   と、 前記第２の工程で抽出したイベントデータを所定のタイ
   ミングで再度前記音楽情報として送信する第３の工程
   と、 を有することを特徴とする音楽情報送信方法。
3. 【請求項３】 受信側が受信しながら処理していくこと
   で演奏を行うための音楽情報を送信する装置であって、 ノートオン、ノートオフ等のイベントの内容を表すイベ
   ントデータに、該イベントデータを処理すべきタイミン
   グを表す時間データを付加する時間データ付加手段と、 前記時間データ付加手段によって時間データが付加され
   たイベントデータを前記音楽情報として前記受信側に順
   次送信する送信手段と、 を具備したことを特徴とする音楽情報送信装置。
4. 【請求項４】 受信側が受信しながら処理していくこと
   で演奏を行うための音楽情報を送信する装置であって、 少なくとも、ノートオン、ノートオフ等のイベントの内
   容を表すイベントデータを、該イベントデータを処理さ
   せるべきタイミングに基づいて前記音楽情報として順次
   送信する第１の送信手段と、 前記第１の送信手段によって送信されたイベントデータ
   のなかから予め定めた種類のイベントデータを抽出する
   抽出手段と、 前記抽出手段が抽出したイベントデータを所定のタイミ
   ングで再度前記音楽情報として送信する第２の送信手段
   と、 を具備したことを特徴とする音楽情報送信装置。
5. 【請求項５】 請求項１記載の音楽情報送信方法、或い
   は請求項３記載の音楽情報送信装置によって送信された
   音楽情報を受信しながら処理していくことで演奏を行う
   ための方法であって、 前記音楽情報を受信する第１の工程と、 前記第１の工程で受信した音楽情報中の時間データか
   ら、該時間データが付加されたイベントデータを処理す
   べきタイミングを決定する第２の工程と、 前記第２の工程で決定したタイミングに従って、前記第
   １の工程で受信した音楽情報中のイベントデータを処理
   する第３の工程と、 を有することを特徴とする音楽情報受信処理方法。
6. 【請求項６】 前記第２の工程は、前記時間データか
   ら、前記音楽情報が送信されてから受信されるまでに要
   した送信時間の変動を求め、該求めた送信時間の変動を
   前記タイミングの決定に反映させる、 ことを特徴とする請求項５記載の音楽情報受信処理方
   法。
7. 【請求項７】 前記受信した音楽情報中の制御データを
   基に、該音楽情報を正常に受信しているか否か判定し、
   該音楽情報を正常に受信していないと判定した場合に、
   該音楽情報による演奏を中止する、 ことを特徴とする請求項５、または６記載の音楽情報受
   信処理方法。
8. 【請求項８】 請求項１記載の音楽情報送信方法、或い
   は請求項３記載の音楽情報送信装置によって送信された
   音楽情報を受信しながら処理していくことで演奏を行う
   ための方法であって、 前記音楽情報を受信する第１の工程と、 前記第１の工程で受信した前記音楽情報を所定の記憶手
   段に記憶させる第２の工程と、 前記第１の工程で受信した音楽情報中のイベントデータ
   を処理するタイミングを、該イベントデータに付加され
   た時間データ、及び前記記憶手段の空容量に基づいて決
   定する第３の工程と、 前記第３の工程で決定したタイミングに従って、前記第
   １の工程で受信した音楽情報中のイベントデータを処理
   する第４の工程と、 を有することを特徴とする音楽情報受信処理方法。
9. 【請求項９】 請求項２記載の音楽情報送信方法、或い
   は請求項４記載の音楽情報送信装置によって送信された
   音楽情報を受信しながら処理していくことで演奏を行う
   ための方法であって、 前記音楽情報を受信する第１の工程と、 前記第１の工程で受信した音楽情報中のイベントデータ
   を処理すべきか否か判定する第２の工程と、 前記第２の工程の判定結果に従って、前記第１の工程で
   受信した音楽情報中のイベントデータを処理する第３の
   工程と、 を有することを特徴とする音楽情報受信処理方法。
10. 【請求項１０】 請求項１記載の音楽情報送信方法、或
    いは請求項３記載の音楽情報送信装置によって送信され
    た音楽情報を受信しながら処理していくことで演奏を行
    う装置であって、 前記音楽情報を受信する受信手段と、 該受信手段が受信した音楽情報中の時間データから、該
    時間データが付加されたイベントデータを処理すべきタ
    イミングを決定するタイミング決定手段と、 前記タイミング決定手段によって決定されたタイミング
    に従って前記イベントデータを処理する処理手段と、 を具備したことを特徴とする音楽情報受信処理装置。
11. 【請求項１１】 前記タイミング決定手段は、前記時間
    データから、前記音楽情報が送信されてから受信される
    までに要した送信時間の変動を求め、該求めた送信時間
    の変動を前記タイミングの決定に反映させる、 ことを特徴とする請求項１０記載の音楽情報受信処理装
    置。
12. 【請求項１２】 前記処理手段は、前記受信手段が受信
    した音楽情報中の制御データを基に、該音楽情報を正常
    に受信しているか否か判定し、該音楽情報を正常に受信
    していないと判定した場合に、該音楽情報による演奏を
    中止する、 ことを特徴とする請求項１０、または１１記載の音楽情
    報受信処理装置。
13. 【請求項１３】 請求項１記載の音楽情報送信方法、或
    いは請求項３記載の音楽情報送信装置によって送信され
    た音楽情報を受信しながら処理していくことで演奏を行
    う装置であって、 前記音楽情報を受信する受信手段と、 前記受信手段が受信した前記音楽情報を記憶する記憶手
    段と、 前記受信手段が受信した音楽情報中のイベントデータを
    処理するタイミングを、該イベントデータに付加された
    時間データ、及び前記記憶手段の空容量に基づいて決定
    するタイミング決定手段と、 前記タイミング決定手段が決定したタイミングに従っ
    て、前記記憶手段に記憶された音楽情報中のイベントデ
    ータを処理する処理手段と、 を具備したことを特徴とする音楽情報受信処理装置。
14. 【請求項１４】 請求項２記載の音楽情報送信方法、或
    いは請求項４記載の音楽情報送信装置によって送信され
    た音楽情報を受信しながら処理していくことで演奏を行
    う装置であって、 前記音楽情報を受信する受信手段と、 前記受信手段が受信した音楽情報中のイベントデータを
    処理すべきか否か判定する判定手段と、 前記判定手段の判定結果に従って、前記受信手段が受信
    した音楽情報中のイベントデータを処理する処理手段
    と、 を具備したことを特徴とする音楽情報受信処理装置。
15. 【請求項１５】 受信側が受信しながら処理していくこ
    とで演奏を行うための音楽情報を送受信する装置であっ
    て、 ノートオン、ノートオフ等のイベントの内容を表すイベ
    ントデータに、該イベントデータを処理すべきタイミン
    グを表す時間データを付加する時間データ付加手段と、 前記時間データ付加手段によって時間データが付加され
    たイベントデータを前記音楽情報として前記受信側に順
    次送信する送信手段と、 前記音楽情報を受信する受信手段と、 該受信手段が受信した音楽情報中の時間データから、該
    時間データが付加されたイベントデータを処理すべきタ
    イミングを決定するタイミング決定手段と、 該タイミング決定手段によって決定されたタイミングに
    従って前記イベントデータを処理する処理手段と、 を具備したことを特徴とする音楽情報送受信装置。
16. 【請求項１６】 前記送信手段は、前記受信側に、前記
    音楽情報の送信量を表す制御データを随時送信し、 前記処理手段は、前記受信手段が受信した音楽情報中の
    制御データを基に、該音楽情報を正常に受信しているか
    否か判定し、該音楽情報を正常に受信していないと判定
    した場合に、該音楽情報による演奏を中止する、 ことを特徴とする請求項１５記載の音楽情報送受信装
    置。
17. 【請求項１７】 ノートオン、ノートオフ等のイベント
    の内容を表すイベントデータ毎に、該イベントデータを
    処理すべきタイミングを表す時間データを付加する手段
    と、 該付加する手段によって時間データが付加されたイベン
    トデータを音楽情報として順次送信する手段と、 を実現させるためのプログラムを記録したコンピュータ
    読み取り可能な記録媒体。
18. 【請求項１８】 少なくとも、ノートオン、ノートオフ
    等のイベントの内容を表すイベントデータを、該イベン
    トデータを処理させるべきタイミングに基づいて前記音
    楽情報として順次送信する手段と、 該送信する手段によって送信されたイベントデータのな
    かから予め定めた種類のイベントデータを抽出する手段
    と、 該抽出する手段によって抽出されたイベントデータを前
    記音楽情報として所定のタイミングで再送する手段と、 を実現させるためのプログラムを記録したコンピュータ
    読み取り可能な記録媒体。
19. 【請求項１９】 音楽情報を受信する手段と、 該受信する手段によって音楽情報が受信された場合に、
    該受信された音楽情報中の時間データから、該時間デー
    タが付加されたイベントデータを処理すべきタイミング
    を決定する手段と、 該決定する手段によって決定されたタイミングに従って
    前記イベントデータを処理する手段と、 を実現させるためのプログラムを記録したコンピュータ
    読み取り可能な記録媒体。
20. 【請求項２０】 音楽情報を受信する手段と、 該受信する手段によって受信された音楽情報を記憶手段
    に記録させる手段と、 前記受信する手段により受信された音楽情報中のイベン
    トデータを処理するタイミングを、該イベントデータに
    付加された時間データ、及び前記記憶手段の空容量に基
    づいて決定する手段と、 該決定する手段によって決定されたタイミングに従って
    前記イベントデータを処理する手段と、 を実現させるためのプログラムを記録したコンピュータ
    読み取り可能な記録媒体。
21. 【請求項２１】 音楽情報を受信する手段と、 該受信する手段により受信された音楽情報中のイベント
    データを処理すべきか否か判定する手段と、 該判定する手段の判定結果に従って、前記受信する手段
    により受信された音楽情報中のイベントデータを処理す
    る手段と、 を実現させるためのプログラムを記録したコンピュータ
    読み取り可能な記録媒体。
22. 【請求項２２】 ノートオン、ノートオフ等のイベント
    の内容を表すイベントデータに、該イベントデータを処
    理すべきタイミングを表す時間データを付加する手段
    と、 該付加する手段によって時間データが付加されたイベン
    トデータを音楽情報として順次送信する手段と、 該音楽情報を受信する手段と、 該受信する手段によって音楽情報が受信された場合に、
    該受信された音楽情報中の時間データから、該時間デー
    タが付加されたイベントデータを処理すべきタイミング
    を決定する手段と、 該決定する手段によって決定されたタイミングに従って
    前記イベントデータを処理する手段と、 を実現させるためのプログラムを記録したコンピュータ
    読み取り可能な記録媒体。