JP3518647B2 - 電子機器用ネットワークにおける通信方法 - Google Patents

Description

【発明の詳細な説明】 【０００１】 【発明の属する技術分野】本発明は、複数の電子機器を
相互に接続するネットワークにおける通信方法に関す
る。 【０００２】 【従来の技術】電子楽器の分野においては、一般的に、
ＭＩＤＩ（musical instrument digital interface）規
格に基づいて複数の電子楽器またはそれらの付属装置を
接続し、ネットワークを構築している。ＭＩＤＩは、主
要楽器メーカの協議の下に定められた統一規格である。
ＭＩＤＩでは、データ形式、通信プロトコルおよびケー
ブル端子等が定められている。 【０００３】しかし、ＭＩＤＩは、単方向通信であるこ
と、および通信速度が現在の技術水準から言えば比較的
低速となってしまったこと等の欠点がある。そこで、新
しいネットワークシステムを用いた通信方法が、特開平
８−５４８７５号公報で示されている。 【０００４】当該公報は、通信エラーを検出するため、
以下に示す方法で通信を行うことを示している。送信側
は、受信側に向けてデータを送信する。受信側は、送信
側からのデータを受信し、そのデータを受信することに
よって生じた状態の変化を送信側に返送する。送信側
は、受信側から返送された状態変化を受信し、自己の送
信したデータと比べて当該状態変化の妥当性を判断し、
必要に応じて受信側にデータを再送する。 【０００５】 【発明が解決しようとする課題】上記のように、受信側
は、データを受信したとき、そのデータに誤りがあるか
否かにかかわらず、常に自己の状態変化を送信側に通知
する。受信側は、常に自己の状態変化を送信側に通知す
るので、必要なデータのみを送受信する場合に比べ、通
信量は２倍近くに増えてしまう。 【０００６】通信量の増大は、一般的に通信速度の低下
または通信条件の制限を招き、通信帯域幅を広く確保で
きない状況においては通信不能になることもあり得る。
本発明の目的は、通信量を大幅に増加させることなく、
通信の信頼性を向上させることができる電子機器用ネッ
トワークにおける通信方法を提供することである。 【０００７】 【課題を解決するための手段】 本発明の一観点によれ
ば、情報を送信するための送信ノードと、送信された情
報を受信して発音指示情報に応じて楽音信号を形成する
受信ノードとを接続する電子機器用ネットワークにおけ
る通信方法は、（ａ）前記受信ノードが前記送信ノード
から発音指示情報と前記送信ノードにおいて発音指示中
の楽音の個数に関する情報とを含むＭＩＤＩデータをそ
れぞれ同期方式のプロトコルにより受信する工程と、
（ｂ）前記受信した楽音の個数に関する情報と当該受信
ノードにおいて形成されている楽音信号の個数とが一致
しない場合に、前記受信したＭＩＤＩデータの内容が妥
当性にかけ有意性がないと判断する工程と、（ｃ）前記
判断する工程（ｂ）が、前記受信したＭＩＤＩデータの
内容について妥当性に欠け有意性がないと判断した場合
には非同期方式のプロトコルにより送信ノードに当該受
信ノードにおいて形成されている楽音信号の音高列に関
する情報を通知する工程と、（ｄ）送信ノードが前記通
知に応じて、当該送信ノードにおいて形成されている楽
音信号の音高列とを比較し、受信ノードにおいてのみ存
在する音高の楽音信号の消音を指示する情報または送信
ノードにおいてのみ存在する音高の楽音信号の形成を指
示する発音指示情報を前記受信ノードに送信する工程と
を含む。 【０００８】受信ノードが受信した情報に誤りがある可
能性が高いと判断したときには、非同期方式のプロトコ
ルにより誤りがある可能性が高い旨を通知するので、通
常の情報の通信の信頼性を確保することができる。ま
た、受信ノードは、情報を受信する毎に毎回送信ノード
に通知するのではなく、受信したデータに誤りがある可
能性が高いと判断したときのみ誤りがある可能性が高い
旨を通知するので、通信情報量は比較的少なくてすむ。 【０００９】 【００１０】 【発明の実施の形態】図１は、本発明の実施例による電
子機器用ネットワークの構成を示すブロック図である。
電子機器の一例として、電子楽器の場合を説明する。ま
た、ネットワークの例として、ＩＥＥＥ１３９４規格に
よるものを説明する。ＩＥＥＥ１３９４は、デジタル通
信の代表的な規格である。 【００１１】音源１と５、シーケンサ２、ミキサ３、テ
ープレコーダ４は、それぞれが１つのノードを構成す
る。各ノードは、例えばネットワーク接続用の３つのポ
ートを有し、どのポートも同じ役割を果たす。したがっ
て、各ノードは、最大３つの他のノードと接続すること
ができる。上記の５つのノードは、バス接続によりネッ
トワークを構成する。 【００１２】ネットワークを構成する際、物理的なツリ
ー構造（木構造）は任意である。ノードの接続により、
各ノードには、ノードＩＤ（識別子）が自動的に設定さ
れる。このノードＩＤが一番大きなノードがルートノー
ドとして設定され、論理的なツリー構造が自動的に構成
される。つまり、論理的ツリー構造と物理的ツリー構造
とは異なる。ルートノードは、各ノードに対して通信の
開始を許可するためのサイクルスタートパケット等をバ
スに発行する役割を有する。 【００１３】ＩＥＥＥ１３９４では、２種類の通信方法
が規定されている。１つは、アイソクロナス（同期）通
信であり、もう１つは非同期パケット通信である。アイ
ソクロナス通信は、１２５μｓ毎に一定の通信帯域が確
保されている通信であり、送信ノードはブロードキャス
トで通信先を特定せずにチャンネルを指定してデータを
送信する。他の全てのノードは、チャンネルに基づく判
断によってデータを取り込むので、１つの送信データを
複数の受信ノードが受け取ることができる。送信ノード
は、データを送りっぱなしで受信側からの応答がないの
で、原則として、正常な通信が行われたか否かを確認す
ることができない。そこで、本実施例では、アイソクロ
ナス通信で行った通信のエラーチェックを、非同期パケ
ット通信を用いて行う。 【００１４】非同期パケット通信は、一定の通信帯域が
確保されておらず、アイソクロナス通信の合間を縫って
行われる。アイソクロナス通信は１２５μｓ毎に行われ
るので、非同期パケット通信は約１２５μｓ毎に通信の
機会が与えられる。非同期パケット通信は、通信相手を
特定してデータを送信することができる。受信ノード
は、アイソクロナス通信で受信したデータの信頼性が低
い（誤りがある可能性が高い）場合、同じデータを再送
するように非同期パケット通信で送信ノードに知らせ
る。 【００１５】ＩＥＥＥ１３９４規格においては、ネット
ワークに新たなノードが追加された場合、バスリセット
の信号が発行され、接続されているノードのネットワー
クが再構成される。再構成が行われた後は、ノード間の
通信は復旧するが、バスリセットには２００μｓ程度の
時間がかかるので、その間に通信していたデータに関し
ては、消滅してしまうことが考えられる。アイソクロナ
ス通信のサイクルは１２５μｓであるので、２サイクル
分のデータが消滅する可能性がある。このようにして消
滅したデータについても、救済する必要がある。 【００１６】次に、ＩＥＥＥ１３９４方式でＭＩＤＩデ
ータまたはオーディオデータを通信する場合において、
通信データの信頼性を保証（エラーチェックおよび回
復）する方法を３つ概略的に説明する。各方法の詳細
は、後にフローチャートを参照しながら説明する。 【００１７】（１）受信ノードは、送信ノードからＭＩ
ＤＩデータを受け取った際に常に返答するのではなく、
受け取ったＭＩＤＩデータの信頼性が欠けるときのみ返
答し、必要であれば送信ノードが受信ノードにＭＩＤＩ
データを再送する。常に返答するのではなく、データの
信頼性が欠けるときのみ返答することにより、通信量を
それほど増加させることなく通信の信頼性を向上させる
ことができる。 【００１８】具体的には、受信ノードは、受け取ったＭ
ＩＤＩデータが非妥当性を有するか否かを判断する。例
えば、ＭＩＤＩデータの規則によれば、必ずキーオン
（押鍵）があってからその後にキーオフ（離鍵）があ
る。そこで、キーオフのデータを受信したが、それに対
応するキーオンを未だに受信していないときには、キー
オフすべき対象がないのでキーオフの受信データが誤り
ではないかとの判断を行う。また、シーケンサ停止のデ
ータを受信したが、シーケンサが既に停止しているとき
にも、シーケンサ停止の受信データが誤りではないかと
の判断を行う。 【００１９】（２）送信ノードは、例えば５秒に１回現
在キーオン中のキーの数を受信ノードに知らせる。受信
ノードは、受け取ったキーオンの数と自己においてキー
オン中のキーの数を比較する。両者の数が一致するとき
には正常な通信が行われていると推定することができ
る。両者の数が一致しないときには、受信ノードがキー
オンのリストを送信ノードに送信する。送信ノードは、
受け取ったキーオンリストには含まれているが、自己の
キーオンリストには含まれていないものをキーオフする
ように指示し、いつまでもキーオンの状態で発音しっぱ
なしのキーの存在をなくす。 【００２０】キーオンまたはキーオフの受信を誤ったに
もかかわらず、キーオン数が偶然一致してしまうことも
あるが、そのような場合でも、後にはキーオンリストが
変化して行くので、将来的にはいつかエラーを検出する
ことができる。 【００２１】なお、例えば音源がＭＩＤＩデータを鍵盤
とシーケンサの両方から受信する場合には、鍵盤による
キーオンリストとシーケンサによるキーオンリストを別
々に作成するため、ＭＩＤＩデータがどこから送信され
てきたのかを判断する必要がある。 【００２２】また、キーオフが送信されてこなくても、
発音チャンネルが足りないために強制的なトランケート
によりキーオフしてしまう場合がある。そのような場合
は、トランケートによりキーオン状態が解除されている
ので、送信側および受信側の双方のキーオンリストから
削除する必要がある。 【００２３】（３）オーディオデータを送信する場合、
送信ノードは、オーディオデータにシリアル番号とタイ
ムスタンプを付して送信する。受信ノードは、オーディ
オデータを受け取る際にシリアル番号が前に受信したオ
ーディオデータのものに対して非連続か否かをチェック
する。途中の番号が抜けてシリアル番号がとんでいれ
ば、途中のオーディオデータが抜けたことを意味するの
で、受信ノードは抜けたシリアル番号に対応するオーデ
ィオデータの再送を送信ノードに依頼する。送信ノード
は、所定時間だけ送信済データを保存しているので、抜
けたシリアル番号のオーディオデータを再送することが
できる。 【００２４】受信ノードのバッファには、オーディオデ
ータが到着順に記憶される。途中で抜けたオーディオデ
ータは当該バッファの最後に記憶されるので、順番を正
すため、受信ノードは、オーディオデータに付されたタ
イムスタンプの順番に読み出し発音処理を行う。ビデオ
データも同様に扱うことができる。 【００２５】なお、オーディオデータやビデオデータだ
けでなく、ＭＩＤＩデータにもシリアル番号を付けるこ
とができる。ＭＩＤＩデータは、オーディオデータなど
と異なり、データの時間順序を守ることが必要な場合
と、厳密には必要であるが重要ではない場合とが存在す
る。よってＭＩＤＩデータの伝送時にシリアル番号によ
りデータの抜けが検出された場合は、処理の簡略化のた
めに基本的にはデータを再送することにより対処し、時
間順序を守ることが必要なデータについては、処理を異
ならせる。 【００２６】例えば、キーオン（ＫＯＮ）、ピッチベン
ド（ＰｉｔｃｈＢｅｎｄ）、音色を示すプログラムチェ
ンジ（ＰＣ）、キーオフ（ＫＯＦＦ）を含むＭＩＤＩデ
ータに、１０４５、１０４６、１０４７のシリアル番号
を以下のように付して送信する場合を考える。 【００２７】シリアル番号１０４５：KON(64),PitchBen
d(45),KON(43),PC(34) シリアル番号１０４６：PitchBend(50) シリアル番号１０４７：KOFF(43),PC(35) 【００２８】ここで、シリアル番号１０４５が抜けたと
する。シリアル番号の抜けが受信側によって検出され、
抜けたことが送信側に通知された場合は、シリアル番号
１０４６と１０４７のデータを参照して、「KON(64) 」
のみを再送する。PitchBend(45) とKON(43) とPC(34)
は、以下の理由により再送しない。 【００２９】シリアル番号１０４７においてKOFF(43)が
既に送信されているので、この後にシリアル番号１０４
５におけるKON(43) を再送すると、発音が終了しなくな
るので、KON(43) は再送する必要がない。 【００３０】また、PitchBend(45) とPC(34)を再送して
しまうと、それぞれシリアル番号１０４６のPichBend(5
0)とシリアル番号１０４７のPC(35)と前後関係が逆にな
り、実際の操作内容と対応しなくなってしまうので、再
送する必要がない。 【００３１】図２は、図１に示す複数のノードのうちの
１つのノードの例を示す。ここでは、ノードが音源であ
る場合を例に説明する。ノードは、ＣＰＵ１１とＲＯＭ
１２とＲＡＭ１３と通信インターフェース（Ｉ／Ｆ）１
４と楽音合成回路１６とサウンドシステム１７を有し、
それぞれはバス１８を介して接続されている。 【００３２】通信インターフェース１４は、３つのポー
ト１５を有する。ポート１５を介して他のノードと接続
することにより、ネットワークを構成することができ
る。ＲＡＭ１３は、送信データと受信データをそれぞれ
バッファリングするための送信バッファと受信バッファ
と、各種レジスタおよびバッファ等を含むＣＰＵ１１の
ワーキングエリアとを有する。 【００３３】ＲＯＭ１２は、各種パラメータおよびコン
ピュータプログラムを記憶する。ＣＰＵ１１は、ＲＯＭ
１２に記憶されているコンピュータプログラムに従って
演算または制御を行う。 【００３４】楽音合成回路１６は、ＣＰＵ１１の制御に
より供給される楽音パラメータに応じて楽音信号を生成
する。サウンドシステム１７は、楽音合成回路１６で生
成された楽音信号を発音可能な信号に変換する。 【００３５】サウンドシステム１７で生成された楽音信
号は、例えばＲＡＭ１３中の送信バッファを介して、通
信インターフェース１４から外部に送信される。楽音信
号は、その後、ミキサによりミキシングされたり、スピ
ーカから発音されたりする。 【００３６】また、外部から通信インターフェース１４
に供給されるＭＩＤＩデータは、ＲＡＭ１３中の受信バ
ッファを介して、楽音合成回路１６に供給される。楽音
合成回路１６は、当該ＭＩＤＩデータに応じて楽音信号
を生成する。 【００３７】図３は、ネットワークを構成する電子楽器
システムの全体的な処理を説明するためのフローチャー
トである。パネルを有するノードと鍵盤を有するノード
がネットワークに含まれているものとする。例えば、音
源１と５が、パネル、鍵盤を有する電子楽器であるとす
る。 【００３８】ステップＳＡ１では、全てのノードが独自
の初期設定を行う。ステップＳＡ２では、パネル処理を
行う。パネル処理は、音色を設定するためのスイッチを
含む各種操作用スイッチを有するパネルスイッチと、音
色番号を含む各種情報を表示するためのパネルディスプ
レイに関連する処理を行う。 【００３９】ステップＳＡ３では、鍵盤処理を行う。鍵
盤処理は、演奏者が行う鍵盤操作を検出する。例えば、
押鍵、離鍵、ピッチベンドホイール操作等を検出し、キ
ーオン／オフ、キーコード等のＭＩＤＩデータを生成す
る。 【００４０】ステップＳＡ４では、音源処理を行う。音
源処理は、上記のパネル処理および鍵盤処理により生成
されたＭＩＤＩデータに応じて、楽音信号を生成する。
ステップＳＡ５では、各種機能処理を行う。例えば、シ
ーケンサ処理やオートリズム処理である。その後、ステ
ップＳＡ２へ戻り、処理を繰り返す。 【００４１】図４は、ネットワーク割り込み処理を示す
フローチャートである。この割り込み処理は、アイソク
ロナス通信のサイクル（１２５μｓ）で割り込み実行さ
れる。 【００４２】ステップＳＢ１では、ネットワーク処理を
行い、処理を終了すると割り込み前の処理に戻る。ネッ
トワーク処理は、ネットワーク送信処理およびネットワ
ーク受信処理を含む。ネットワーク送信処理は、送信バ
ッファに蓄積されたデータを外部に送信する処理であ
る。ネットワーク受信処理は、受信により受信バッファ
に蓄積されたデータを取り出す処理である。それぞれの
処理の詳細は、後に別のフローチャートを参照しながら
説明する。 【００４３】図５は、図４のステップＳＢ１のネットワ
ーク送信処理の詳細を示すフローチャートである。ステ
ップＳＣ１では、ＲＡＭ中の送信バッファより送信デー
タを取り出す。 【００４４】ステップＳＣ２では、ポート情報テーブル
より送信ポートに対応する情報を取り出す。図６に、ポ
ート情報テーブルの例を示す。ポート（ｐｏｒｔ）番号
が１であれば、プロトコル（ｐｒｏｔｏｃｏｌ）がアイ
ソクロナス（ｉｓｏｃｈｒｏｎｏｕｓ）通信であり、送
信データがＭＩＤＩデータである。ポート番号が２であ
れば、プロトコルが非同期パケット（ｐａｃｋｅｔ）通
信であり、送信データがデータ確認または再送のための
情報である。ポート番号が３であれば、プロトコルがア
イソクロナス通信であり、送信データがオーディオ（ａ
ｕｄｉｏ）データである。ポート番号が４であれば、プ
ロトコルがアイソクロナス通信であり、送信データがビ
デオ（ｖｉｄｅｏ）データである。 【００４５】ポート情報テーブルは、各ノードのＲＡＭ
に記憶されるテーブルであり、それらの内容は同一であ
る。また、ポート情報テーブルには、アイソクロナス通
信においては、アイソクロナスチャンネル番号も記録さ
れている。パケット通信における受信ノードのアドレス
については、別途用意されるテーブルにより設定され
る。例えば、ＭＩＤＩデータを送信しようとする場合
は、ポート番号として１を指定しておけば、データを作
成するプログラムは、通信プロトコルや、受信側のアド
レスなどを知る必要はなく、データを作成するプログラ
ムに共通に利用されるネットワーク送信処理のみが、そ
れらの情報をまとめて管理することになり、データを作
成するプログラムの簡略化を図ることができる。例え
ば、ノードがシーケンサの場合、ポート番号１を指定し
たＭＩＤＩデータを送信バッファに記録するのみで、シ
ーケンサプログラムは、ネットワークについて関知する
必要がない。 【００４６】ステップＳＣ３では、当該取り出したデー
タを送信バッファより消去する。消去することにより、
送信バッファ中の次の送信データを取り出す準備をす
る。ステップＳＣ４では、上記のポート情報テーブルの
プロトコル（ｐｒｏｔｏｃｏｌ）が非同期パケット（ｐ
ａｃｋｅｔ）通信であるか否かをチェックする。非同期
パケット（ｐａｃｋｅｔ）通信でなければ、アイソクロ
ナス（ｉｓｏｃｈｒｏｎｏｕｓ）通信であるので、ステ
ップＳＣ５へ進む。 【００４７】ステップＳＣ５では、指定されたアイソク
ロナスチャンネルにシリアル番号を付したデータを送信
する。アイソクロナスチャンネルは、例えば６４チャン
ネルあり、１つのアイソクロナスチャンネルには、ＭＩ
ＤＩの１６チャンネル分の帯域を確保することができ
る。シリアル番号は、受信ノードがデータを抜けなく受
信したか否かを判断する際に用いられるものであり、Ｍ
ＩＤＩデータ、オーディオデータ等を区別するため、ア
イソクロナスチャンネル毎に別個に付される。 【００４８】ステップＳＣ６では、ＲＡＭ中の送信済バ
ッファにシリアル番号とデータと現在時刻とを記憶す
る。これらの情報は、受信ノードから確認要求／再送要
求がきたときに参照され、データの再送などの制御に利
用される。 【００４９】ステップＳＣ７では、送信済バッファ中の
データのうち所定時間経過した物を消去し、図４の処理
に戻る。所定時間とは、受信ノードが再送要求すること
を許容する時間である。例えば、通信ネットワークの端
から端までの通信時間が５００μｓであるとすれば、往
復の通信時間（１ｍｓ）に受信ノードの処理時間を加え
た時間を考慮して、所定時間を１．５ｍｓとすればよ
い。 【００５０】ステップＳＣ４において、プロトコル（ｐ
ｒｏｔｏｃｏｌ）が非同期パケット（ｐａｃｋｅｔ）通
信であると判断されたときには、ステップＳＣ８へ進
む。ステップＳＣ８では、指定されたノードにデータを
送信し、図４の処理に戻る。図６のポート情報テーブル
に示すように、例えば送信データがデータ確認または再
送を指示するものであれば、送信先ノードを指定して非
同期パケット通信を行う。 【００５１】以上は、ノードが送信バッファ中の送信デ
ータを送信する処理を示した。次に、上記の処理を行う
前に、送信バッファ中に送信データを生成する例を示
す。特に、ノードがシーケンサの場合を例に説明する。 【００５２】図７は、シーケンサが送信バッファ中に送
信データを生成する処理を示すフローチャートである。
ステップＳＤ１では、シーケンサが動作中であるか否か
をチェックする。シーケンサが動作中でなければ、何も
処理せずに終了する。シーケンサが動作中であるときに
は、ステップＳＤ２へ進む。 【００５３】ステップＳＤ２では、時間情報に応じてメ
モリ（ＲＡＭ）よりシーケンスデータを読み出すための
動作を指示する。このメモリは、シーケンスデータを記
憶するためのメモリであり、送信バッファとは別であ
る。 【００５４】ステップＳＤ３では、メモリから読み出し
た情報中にその時間に対応するイベントがあるか否かを
チェックする。対応するイベントがないときには、処理
を終了する。対応するイベントがあるときには、ステッ
プＳＤ４へ進む。 【００５５】ステップＳＤ４では、ポート（ｐｏｒｔ）
番号＝１を指定して、読み出されたイベント（ＭＩＤＩ
データ）を送信バッファに書き込み、処理を終了する。
図６のポート情報テーブルに示すように、送信データが
ＭＩＤＩデータの場合はポート番号が１である。 【００５６】以上は、ネットワーク送信処理について説
明した。次に、ネットワーク受信処理について説明す
る。図８は、図４のステップＳＢ１のネットワーク受信
処理の詳細を示すフローチャートである。大きく分け
て、ステップＳＥ１〜ＳＥ５がアイソクロナス通信によ
る受信処理であり、ステップＳＥ６〜ＳＥ１０が非同期
パケット通信による受信処理である。ＲＡＭ中の受信バ
ッファは、アイソクロナス受信バッファと非同期パケッ
ト受信バッファとに別れている。 【００５７】まず、アイソクロナス通信による受信処理
を行う。ステップＳＥ１では、ＲＡＭ中のアイソクロナ
ス受信バッファからのデータ取り出しを指示し、受信テ
ーブルを作成する。受信テーブルは、後の処理を行いや
すいように受信データを再構成したものである。 【００５８】ステップＳＥ２では、受信バッファにデー
タがあるか否かをチェックする。受信バッファからのデ
ータ読み出し動作を行っても、データがなければ受信テ
ーブルにデータはないことになる。受信バッファにデー
タがある場合には、ステップＳＥ３へ進む。 【００５９】ステップＳＥ３では、データに付されてい
るシリアル番号が以前に受信したデータのシリアル番号
に連続しているか否かをチェックする。シリアル番号が
連続していなければ、あるデータを抜かしてデータを受
信したことを意味するので、ステップＳＥ５へ進む。 【００６０】ステップＳＥ５では、抜けたシリアル番号
を送信側に通知し、ステップＳＥ６へ進む。この後、送
信側は、当該通知を受けて、抜けたシリアル番号のデー
タを再送する。 【００６１】ステップＳＥ３において、シリアル番号が
連続していると判断されたときは、受信データが抜けて
いないことを意味するので、ステップＳＥ４へ進む。 【００６２】ステップＳＥ４では、受信データ処理を行
う。受信データ処理は、例えば現在キーオン中でないキ
ーコードのキーオフを受信したことに対して通信エラー
ではないかとの予測を行う処理である。詳細は、後に図
９を参照しながら説明する。その後、ステップＳＥ６へ
進む。 【００６３】ステップＳＥ２において、受信バッファに
データがなかったと判断したときには、上記の処理を行
わずに、ステップＳＥ６へ進む。以上がアイソクロナス
通信による受信処理である。次に、非同期パケット通信
による受信処理を示す。ネットワーク受信処理は、各ノ
ードに共通して用意され、そのプログラムも共通であ
る。情報を送信するノードと受信するノードとを考えた
場合、そのそれぞれのノードでネットワーク受信処理が
実行されている。本実施例でＭＩＤＩ信号が誤って送信
され、受信側が確認要求を返答するような場合では、ま
ず、受信側においてネットワーク受信処理が起動され、
ステップＳＥ４にて誤りの可能性が検出され、送信側に
それが通知される。送信側では、その通知を受けてネッ
トワーク受信処理が起動され、以下に説明する非同期パ
ケット通信による受信処理の部分で通知内容が処理され
る。このように図８のフローチャートは、異なるノード
の処理を共通に説明している。 【００６４】ステップＳＥ６では、非同期パケット受信
バッファより受信データの取り出しを指示する。非同期
パケット通信は、図６に示すように、例えばデータ確認
または再送を指示するためのデータを通信する際に行わ
れる。 【００６５】ステップＳＥ７において、受信バッファに
データがあるか否かをチェックする。データがなければ
処理を終了する。データがあるときには、ステップＳＥ
８へ進む。 【００６６】ステップＳＥ８では、データがデータ確認
またはデータ再送を指示するためのものであるか否かを
チェックする。データがデータ確認または再送のための
ものであれば、ステップＳＥ９へ進む。 【００６７】ステップＳＥ９では、送付されたデータお
よび送信済バッファ中のデータに基づき新たなデータを
生成し、送信バッファに記録し、処理を終了する。例え
ば、キーオン中でないキーコードのキーオフがノード２
からノード１へ送信されてきたときには、ノード１から
ノード２へ本当に当該キーオフを送信したか否かのデー
タ確認が送付される。その送付されてきたデータと送信
済バッファとの間で照合を行い、必要に応じて新たなデ
ータを生成し送信バッファに記録する。 【００６８】または、送付されたデータのみに基づき新
たなデータを生成し、送信バッファに記録し、処理を終
了することもできる。例えば、オーディオデータを受信
する際にあるシリアル番号が抜けて受信したので、その
抜けたシリアル番号のデータ再送を要求する旨が送信さ
れてきたときには、送付されたデータ（シリアル番号）
に基づき新たなデータを送信バッファに記録する。ＣＤ
やシーケンサ等がデータの供給源である場合は、データ
時間的な位置を指定しての再作成（再読み出し）が比較
的容易であるので、データ再送要求を受けた時点で、デ
ータを再作成し返送することができ、送信済データを記
憶するためのバッファを省略することもできる。ただ
し、これらの場合においても処理の共通化と、データの
再作成の高速化を図るために、前述のように送信済バッ
ファを利用するようにしてもよい。 【００６９】ステップＳＥ８において、受信バッファよ
り取り出したデータがデータ確認または再送のためのも
のでなければ、ステップＳＥ１０へ進む。ステップＳＥ
１０では、その他のパケット処理を行い、処理を終了す
る。例えば、音色の問い合わせに対して返答する処理を
行う。また、その他のパケット処理は、アイソクロナス
受信を行った受信側がその後に非同期パケット受信した
ときのパケット処理も含む。 【００７０】図９は、図８のステップＳＥ４における受
信データ処理の詳細を示すフローチャートである。ステ
ップＳＦ１では、受信テーブルをスキャンする。受信テ
ーブルは、図８のステップＳＥ１にて生成されたもので
ある。 【００７１】ステップＳＦ２では、スキャンされたデー
タがＭＩＤＩデータか否かをチェックする。ＭＩＤＩデ
ータであるときには、ステップＳＦ３へ進む。ステップ
ＳＦ３では、受信テーブル中のデータをＭＩＤＩコマン
ドとして取り出し、対応するデータを消去する。 【００７２】ステップＳＦ４では、ＭＩＤＩコマンドに
応じてＭＩＤＩコマンド解釈テーブルを参照し、ＭＩＤ
Ｉコマンドの有意性を判断する。有意性がないときに
は、ステップＳＦ６において、ＭＩＤＩコマンド解釈テ
ーブルを参照し、当該ＭＩＤＩコマンドに応じた対応処
理を実行し、その後ステップＳＦ９へ進む。 【００７３】図１０に、ＭＩＤＩコマンド解釈テーブル
の例を示す。図１０（Ａ）は、ＭＩＤＩコマンド解釈テ
ーブル（１）を示す。受信したＭＩＤＩコマンドがキー
オフ（ＫＯＦＦ）であれば、キーオンバッファに対応す
るキーオン（ＫＯＮ）があるか否かをチェックする。対
応するキーオンがなければ、妥当なコマンドとは考えら
れず、有意性なしと判断し、キーオン中のキーコード列
を返送する。 【００７４】また、受信したＭＩＤＩコマンドがシーケ
ンサ停止（Sequencer Stop）であれば、シーケンサが動
作中であるか否かをチェックする。動作中でなければ、
妥当なコマンドとは考えられず、有意性なしと判断し、
シーケンサが停止中であることを送信側に通知する。 【００７５】また、受信したＭＩＤＩコマンドがダンパ
オン（Dumper On ）であれば、ダンパが既にオンされて
いるか否かをチェックする。既にオンされていれば、妥
当なコマンドとは考えられず、有意性なしと判断し、受
信したＭＩＤＩコマンドを返送する。 【００７６】また、受信したＭＩＤＩコマンドがダンパ
オフ（Dumper Off）であれば、ダンパが既にオフされて
いるか否かをチェックする。既にオフされていれば、妥
当なコマンドとは考えられず、有意性なしと判断し、受
信したＭＩＤＩコマンドを返送する。 【００７７】また、受信したＭＩＤＩコマンドが拡張コ
マンドでありキーオン数の確認を要求するものであれ
ば、受信側のキーオン数と異なるか否かをチェックす
る。キーオン数が異なるときには、有意性なしと判断
し、キーオン中のキーコード列を返送する。この処理に
関連する処理は、後に図１２および図１３を参照しなが
ら説明する。 【００７８】以上のように、受信したＭＩＤＩコマンド
を実行するための制御対象がない場合や、既にその制御
後の状態になっている場合や、キーオン数等のチェック
コードが一致しない場合に、当該ＭＩＤＩコマンドの有
意性がない（誤りの可能性が高い）と判断することがで
きる。 【００７９】図１０（Ｂ）に、ＭＩＤＩコマンド解釈テ
ーブル（２）を示す。受信したＭＩＤＩコマンドがキー
オン（ＫＯＮ）であれば、設定されている音色では通常
演奏しない範囲の音高であるか否かをチェックする。キ
ーオンは、音高の情報を含む。当該範囲の音高でなけれ
ば、妥当なコマンドとは考えられず、有意性なしと判断
し、送信側に通常発音しない範囲の音高であることを通
知する。例えば、トランペットの音色が指定された場合
には、トランペットの音域が制限されている性質を利用
して、その音域を外れる音高は通信エラーである可能性
があると判断する。 【００８０】また、受信したＭＩＤＩコマンドがキーオ
ン（ＫＯＮ）であれば、指定されているベロシティがあ
るレベル以上であるか否かをチェックする。キーオン
は、ベロシティの情報を含む。ベロシティがあるレベル
以上でなければ、演奏情報としての妥当性に欠けると考
えられ、有意性なしと判断し、送信側に指定されている
ベロシティが小さすぎることを通知する。 【００８１】その他、キーオンに対応するキーコードを
受信することにより、その楽曲の調を判断することがで
きる。例えば、ハ長調であれば、ドとミとソの出現頻度
が高く、ド♯とミ♭の出現頻度が低い。出現頻度が低い
キーコードを受信したときには、通信エラーの可能性が
あると判断することができる。 【００８２】また、極端に低い音または高い音の場合、
極端にイニシャルタッチやアフタタッチが大きい場合や
小さい場合、または和音の構成音が突飛な場合は、通信
エラーの可能性があると判断することができる。 【００８３】以上のように、受信したＭＩＤＩコマンド
による制御の対象は存在するが、指定された制御が妥当
でない場合に、当該ＭＩＤＩコマンドの有意性がないと
判断することができる。 【００８４】上記の判断は、個々の判断結果に応じて対
応処理を行ってもよいし、それぞれの判断に通信エラー
の可能性の大きさを点数付けし、総合点に応じて処理を
行ってもよい。 【００８５】受信側が、有意性なしと判断したときには
それぞれの受信ＭＩＤＩコマンドに応じた処理を行う。
テーブル右欄に示した情報を返送する。送信側は、返送
されてきた情報が送信したものと異なる場合には、伝送
路の途中で信号誤りを生じたと判断し、正しい情報を再
度送信する。返送されてきた情報が送信した情報と同種
類である場合は、（１）再度送信する、（２）値を変更
して再度送信する、（３）送信を取り止める、等の処理
を行えばよい。 【００８６】（２）と（３）の場合、受信側は特別の処
理を必要としない。（１）の場合、受信側は、有意性判
断条件に、「有意性がないと判断した場合でも、複数回
同じ判断が続く場合は、そのＭＩＤＩコマンドを無視す
る（送信側に返送しない）」等の条件を加えておけばよ
い。 【００８７】図９に戻り、ステップＳＦ５において、Ｍ
ＩＤＩコマンドに有意性ありと判断されたときには、当
該ＭＩＤＩデータが正常に受信したものであるとして、
ステップＳＦ７へ進み、ＭＩＤＩコマンドの実行を行
い、ステップＳＦ９へ進む。 【００８８】ステップＳＦ２において、受信テーブルを
スキャンしたデータがＭＩＤＩデータでないと判断され
たときには、ステップＳＦ８へ進み、その他データ処理
を行い、ステップＳＦ９へ進む。その他データ処理と
は、例えばオーディオデータ処理やビデオデータ処理で
ある。 【００８９】ステップＳＦ９では、全データの処理が終
了したか否かをチェックする。全データの処理が終了し
ていないときには、ステップＳＦ１に戻り、上記の処理
を繰り返す。全データの処理が終了したときには、図８
の処理へ戻る。 【００９０】図１１は、図９のステップＳＦ８における
オーディオ処理の詳細を示すフローチャートである。ス
テップＳＧ１では、受信したデータをＲＡＭ中のオーデ
ィオデータバッファに記録する。オーディオデータバッ
ファは、例えば２０フレーム分のデータをバッファリン
グする。 【００９１】ステップＳＧ２では、オーディオデータバ
ッファから各オーディオデータに付されているタイムス
タンプを参照して、必要なデータを読み出す。オーディ
オデータを受信する際にデータ抜けがあり当該データを
再送してもらったときには、オーディオデータバッファ
にはオーディオデータがシリアル番号順に記録されてい
ない。そこで、タイムスタンプに基づいた順番で読み出
すことにより、正常な順番でオーディオデータを読み出
すことができる。 【００９２】ステップＳＧ３では、読み出したデータを
利用し、図９の処理へ戻る。例えば、読み出したデータ
をＤ／Ａ変換したり、ミキシングしたりする。図１２
は、キーオン確認用のタイマ割り込み処理を示すフロー
チャートである。この割り込み処理は、約５〜１０秒間
隔の低頻度の割り込み処理であり、ＭＩＤＩデータの送
信側の処理である。割り込みを低頻度にすることによ
り、処理負担を軽減することができる。また、この処理
は、通信エラーにより永久にキーオンのままになってし
まうことを防止するための処理である。誤ったキーオン
により連続して発音しっぱなしの時間が５〜１０秒程度
までであれば、許容できるとの判断によるものである。
もちろん、より頻繁に行ってもよい。 【００９３】ステップＳＨ１では、ＲＡＭ中のキーオン
バッファより現時点でのキーオン数を得る。このキーオ
ン数は、送信側のキーオン数である。ステップＳＨ２で
は、上記のキーオン数を記載したＭＩＤＩのエクスクル
ーシブメッセージを作成する。エクスクルーシブメッセ
ージは、ＭＩＤＩの拡張用コマンドであり、ＭＩＤＩ規
格で既に決められている以外の信号を定義可能である。
ここでは、キーオン数の確認を要求するために用いる。 【００９４】ステップＳＨ３では、ポート番号＝１を指
定して、作成したＭＩＤＩデータ（エクスクルーシブメ
ッセージ）を送信バッファに書き込み、割り込み処理を
終了する。図６のテーブルに示すように、ＭＩＤＩデー
タを送信するには、ポート番号＝１を指定する必要があ
る。 【００９５】図１０（Ａ）のテーブルに示すように、受
信側が上記のエクスクルーシブメッセージを受信したと
きには、キーオン数の確認の要求に応えるため、送信側
のキーオン数と受信側のキーオン数が同じか否かをチェ
ックする。ここにおいて、送信側から受信側に直接キー
オン中のキーコード列をエクスクルーシブメッセージと
して送らないのは、不要にデータ量を増加させないため
である。そして、キーオン数が異なるときには、受信側
のキーオン中のキーコード列を返送する。このキーコー
ド列を送信側が受け取ったときの処理を、次に示す。 【００９６】図１３は、送信側が受信側のキーコード列
を受信したときの処理を示すフローチャートである。ス
テップＳＩ１では、受信側のキーオン中のキーコード列
と送信側のキーオン中のキーコード列とを比較し、受信
側のキーコード列にのみ存在するキーコードを探す。ス
テップＳＩ２では、受信側のキーコード列にのみ存在す
るキーコードに対し、キーオフ（ＫＯＦＦ）のＭＩＤＩ
データを作成する。 【００９７】ステップＳＩ３では、ポート番号＝１を指
定して作成したイベント（ＭＩＤＩデータ）を送信バッ
ファに書き込み、処理を終了する。送信バッファに書き
込まれたキーオフのＭＩＤＩデータは、受信側に送信さ
れる。受信側は、当該ＭＩＤＩデータを受けて、キーオ
フの処理を行う。ＫＯＦＦを送信することより、ＫＯＮ
だけを受け付けて発音しっぱなしになっている楽音を発
音停止させることができる。 【００９８】なお、受信側のキーコード列にのみ存在す
るキーコードに対してＫＯＦＦを送るようにしたが、送
信側のキーコード列にのみ存在するキーコードを再送す
るようにしてもよい。これらの場合、発音のタイミング
は、元々の楽音が発音されるべきタイミングと全く異な
ってしまうので、音量情報を小さく補正するのが望まし
い。 【００９９】本実施例によれば、（１）データの妥当性
を判断、（２）キーオン数等のチェックコードを判断、
（３）データに付するシリアル番号を判断することによ
り、通信データの有意性の判断を行い、それに対する救
済を行うことができる。 【０１００】データの有意性がない場合のみに返答を行
ったり、５秒に１回だけキーオン数を確認するので、通
信量をそれほど増加させることなく、通信の信頼性を向
上させることができる。 【０１０１】なお、本実施例では、電子機器の例として
電子楽器について説明したが、その他の電子機器を接続
するネットワークに適用することもできる。 【０１０２】以上実施例に沿って本発明を説明したが、
本発明はこれらに制限されるものではない。例えば、種
々の変更、改良、組み合わせ等が可能なことは当業者に
自明であろう。 【０１０３】 【発明の効果】以上説明したように、本発明によれば、
受信ノードが受信した情報に誤りがある可能性が高いと
判断したときには、非同期方式のプロトコルにより誤り
がある可能性が高い旨を通知するので、同期方式のプロ
トコルによる通常の情報の通信の信頼性を確保すること
ができる。 【０１０４】また、受信ノードは、情報を受信する毎に
毎回送信ノードに通知するのではなく、受信したデータ
に誤りがある可能性が高いと判断したときのみ誤りがあ
る可能性が高い旨を通知するので、通信情報量は比較的
少なくてすむ。

【図面の簡単な説明】 【図１】 本発明の実施例による電子機器用ネットワー
クの構成を示すブロック図である。 【図２】 図１に示す複数のノードのうちの１つのノー
ドの例を示すブロック図である。 【図３】 ネットワークを構成する電子楽器システムの
全体的な処理を説明するためのフローチャートである。 【図４】 ネットワーク割り込み処理を示すフローチャ
ートである。 【図５】 図４のステップＳＢ１のネットワーク送信処
理の詳細を示すフローチャートである。 【図６】 ポート情報テーブルの例を示す図である。 【図７】 シーケンサが送信バッファ中に送信データを
生成する処理を示すフローチャートである。 【図８】 図４のステップＳＢ１のネットワーク受信処
理の詳細を示すフローチャートである。 【図９】 図８のステップＳＥ４における受信データ処
理の詳細を示すフローチャートである。 【図１０】 ＭＩＤＩコマンド解釈テーブルの例を示す
図である。 【図１１】 図９のステップＳＦ８におけるオーディオ
処理の詳細を示すフローチャートである。 【図１２】 キーオン確認用のタイマ割り込み処理を示
すフローチャートである。 【図１３】 送信側が受信側のキーコード列を受信した
ときの処理を示すフローチャートである。 【符号の説明】 １、５ 音源、 ２ シーケンサ、 ３ ミキサ、
４ テープレコーダ、 １１ ＣＰＵ、 １２
ＲＯＭ、 １３ ＲＡＭ、 １４ 通信インター
フェース（Ｉ／Ｆ）、 １６ 楽音合成回路、 １
７ サウンドシステム、 １８ バス

───────────────────────────────────────────────────── フロントページの続き (56)参考文献 特開 平７−250084（ＪＰ，Ａ) 特開 平８−54875（ＪＰ，Ａ) 木下篤著，10年目で変わるＳＣＳＩシ リアルの台頭始まる，日経バイト，日 本，日経ＢＰ社，1995年３月１日，第 136号，ｐ198−209 シリアルＳＣＳＩがいよいよ市場へ, 日経エレクトロニクス，日本，日経ＢＰ 社，1995年７月３日，第639号，ｐ95− 105

Claims (1)

1. (57)【特許請求の範囲】 【請求項１】 情報を送信するための送信ノードと、送
   信された情報を受信するための受信ノードとを接続する
   電子機器用ネットワークにおける通信方法であって、 前記受信ノードは受信した発音指示情報に応じて楽音信
   号を形成し、 （ａ）前記受信ノードが前記送信ノードから発音指示情
   報と前記送信ノードにおいて発音指示中の楽音の個数に
   関する情報とを含むＭＩＤＩデータをそれぞれ同期方式
   のプロトコルにより受信する工程と、 （ｂ）前記受信した楽音の個数に関する情報と当該受信
   ノードにおいて形成されている楽音信号の個数とが一致
   しない場合に、前記受信したＭＩＤＩデータの内容が妥
   当性にかけ有意性がないと判断する工程と、 （ｃ）前記判断する工程（ｂ）が、前記受信したＭＩＤ
   Ｉデータの内容について妥当性に欠け有意性がないと判
   断した場合には非同期方式のプロトコルにより送信ノー
   ドに当該受信ノードにおいて形成されている楽音信号の
   音高列に関する情報を通知する工程と、 （ｄ）送信ノードが前記通知に応じて、当該送信ノード
   において形成されている楽音信号の音高列とを比較し、
   受信ノードにおいてのみ存在する音高の楽音信号の消音
   を指示する情報または送信ノードにおいてのみ存在する
   音高の楽音信号の形成を指示する発音指示情報を前記受
   信ノードに送信する工程とを含む通信方法。