JP3493737B2

JP3493737B2 - 送信ノードおよび受信ノード

Info

Publication number: JP3493737B2
Application number: JP21074294A
Authority: JP
Inventors: 潤一藤森; 達利阿部
Original assignee: Yamaha Corp
Current assignee: Yamaha Corp
Priority date: 1994-08-12
Filing date: 1994-08-12
Publication date: 2004-02-03
Anticipated expiration: 2019-02-03
Also published as: JPH0854875A; US5652400A

Description

【発明の詳細な説明】

【０００１】

【産業上の利用分野】本発明は、複数の電子楽器がネッ
トワーク上に構築された論理的パスにより相互に接続さ
れるネットワークシステムに関するものである

【０００２】

【従来の技術】電子楽器において、電子楽器同士を接続
する場合は、一般にＭＩＤＩ（Musical Instrument Di
gital Interface ）と称される電子楽器同士を相互に接
続するためのインターフェースを用いてネットワークを
構成している。なお、このＭＩＤＩは国内外の楽器メー
カが協議して決めた統一規格であり、電子楽器を演奏す
ると、その演奏情報が楽器に設けられているＭＩＤＩ端
子からＭＩＤＩ規格に従って送出される。このＭＩＤＩ
を用いると、ステージ等において一人の演奏者で機種等
の異なる複数の電子楽器それぞれから演奏音を同時に出
力して合奏等の演奏効果を得ることができる。

【０００３】このＭＩＤＩにおいては、ネットワーク上
に直列に接続された複数の楽器のうちのあるものから他
のものにノートオン、ベロシティ等の演奏データをシリ
アルデータで一方向に伝送しているため多くの欠点があ
った。これを解決するために、一本の伝送ライン上に複
数の論理的パスを形成して目的の電子楽器に演奏情報を
伝送、あるいは目的の電子楽器から演奏情報を受信する
ようにしたネットワークシステムが、特願平６−０４９
９２７号として本出願人から出願されている。

【０００４】

【発明が解決しようとする課題】前記複数の電子楽器が
分散されて接続されたネットワークシステムによると、
演奏制御情報をパケットとして伝送路に送出している
が、パケットが伝送途中で消失した場合は、受信側は受
けるはずのない演奏制御情報を受信して正常な動作が行
われない恐れがあるという問題点があった。例えば、キ
ーオンデータが消失すると、その次に伝送されるキーオ
フデータはキーオンがされていないのに受信されるとい
ったような場合である。また、論理的パスの接続誤りが
あった場合も受信側は受けるはずのない演奏制御情報を
受信して正常な動作が行われない恐れがある。さらに、
送信側から次々と送信される演奏制御情報に受信側の動
作が追いつかない場合は、正常な動作が行われない恐れ
があるという問題点があった。

【０００５】そこで、本発明は不適切な制御情報を受信
したことを送信側が把握することのできるネットワーク
システムにおける送信ノードおよび受信ノードを提供す
ることを目的としている。さらに、本発明は制御情報を
受信した受信側の変化の状態を把握することのできるネ
ットワークシステムにおける送信ノードおよび受信ノー
ドを提供することを目的としている。

【０００６】

【課題を解決するための手段】前記目的を達成するため
に、本発明の送信ノードは、データを送信する送信ノー
ドと、前記データを受信する受信ノードである電子楽器
と、前記送信ノードと前記受信ノードとを接続する通信
ネットワークとからなるネットワークシステムにおける
送信ノードであって、１ないし複数の前記受信ノードに
対して前記データとして確認フラグを付加することので
きる楽音制御情報を送信する送信手段と、該送信手段に
より確認フラグが付加された前記楽音制御情報を送信し
た送信先の前記受信ノードから、当該受信ノードの楽音
制御に関する内部状態の状態情報を受信する受信手段
と、該受信手段により受信した状態情報が前記送信手段
から送信した確認フラグが付加された前記楽音制御情報
に対応して期待される内容であるか否かを判定する判定
手段と、該判定手段の判定に応じてエラー処理を実行す
るエラー処理手段とを備えるようにしたものである。

【０００７】また、本発明の送信ノードは、前記送信
手段から送信すべきデータのうちの一部の楽音制御情報
の種別についてのみ確認フラグを付加して前記受信ノー
ドに対して前記状態情報の返送を要求する返送要求手段
を、さらに備えるようにしてもよいものである。さら
に、本発明の送信ノードは、所定の時間が経過する毎
に、前記送信手段から送信すべき前記楽音制御情報に確
認フラグを付加して前記受信ノードに対して前記状態情
報の返送を要求する返送要求手段を、さらに備えるよう
にしてもよいものである。さらにまた、本発明の送信ノ
ードは、前記状態情報を返送しない受信ノードが存在す
るか否かを検出し、検出された前記状態情報を返送しな
い受信ノードに対して前記送信したデータの再送を行う
再送手段を、さらに備えるようにしてもよいものであ
る。

【０００８】次に、前記目的を達成するために、本発
明の受信ノードは、データを送信する送信ノードと、前
記データを受信する電子楽器である受信ノードと、前記
送信ノードと前記受信ノードとを接続する通信ネットワ
ークとからなるネットワークシステムにおける受信ノー
ドあって、前記送信ノードから前記データとして楽音制
御情報を受信する受信手段と、該受信手段により受信し
た前記楽音制御情報に確認フラグが付加されているか否
かに応じて、受信した前記楽音制御情報に対応した状態
情報の返送を前記送信ノードが要求しているか否か検出
する検出手段と、該検出手段において前記送信ノードが
状態情報の返送を要求していると検出された場合は、前
記楽音制御情報を受信した後の当該受信ノードの楽音制
御に関する内部状態を前記状態情報として前記送信ノー
ドに対して送信する送信手段とを備えるようにしたもの
である。また、前記本発明の受信ノードにおいて、前記
検出手段は、前記受信手段により受信した前記楽音制御
情報が不適切なデータであるか否か検出するようにされ
ており、該検出手段において受信した前記楽音制御情報
が不適切なデータであると検出された場合は、前記楽音
制御情報を受信した後の当該受信ノードの楽音制御に関
する内部状態を状態情報として、前記送信手段が前記送
信ノードに対して送信するようにしてもよいものであ
る。

【０００９】

【作用】本発明によれば、受信ノードが不適切な制御情
報を受信したことを受信ノードから送信側に返送するよ
うにしたので、送信ノードは制御情報の誤りや接続の誤
りを把握することができると共に、不適切な制御情報が
受信された時だけ返送すると、通信のトラヒックが増加
することを防止することができる。また、本発明におい
ては受信ノードが、制御情報を受信したことによって生
じる内部状態の変化を返送することにより、制御情報が
単に到着しただけではなく、送信ノードが期待した動作
を受信ノードが行っているかどうかを確認することがで
きる。これにより、接続誤りや受信ノードの内部的なエ
ラーを検出することができる。この場合、重要な制御情
報についてのみ返送を要求するようにすると、通信のト
ラヒックをほとんど増加させることなく前記処理を行う
ことができる。

【００１０】

【実施例】本発明の電子楽器ネットワークシステムによ
り構築したネットワークを、一例として図１に示す。こ
の図に示すラインＬ１〜Ｌ１０は、論理的パス１０であ
りネットワーク上に構築された仮想的な接続手段であっ
て、伝送線のごとき物理的な接続手段ではない。

【００１１】この図において、１〜６はそれぞれネット
ワークに接続されたノードであり、次のような各機能が
割り当てられていると共に、次のような構成とされてい
る。まず、１は鍵盤であり、キーデータ出力部（Key Da
ta Output）と送信専用のポート（PORT）＃１とから構
成されており、２はシーケンサ（ＳＥＱ；Multi Track
Sequencer ）であり、トラック１（Track 1 ；MIDI Me
sg. Input ）とその受信専用ポート（PORT）＃１ないし
トラック１６（Track 16；MIDI Mesg. Input）とその
受信専用ポート（PORT）＃１６，トラック１（Track 1
；MIDI Mesg.Output）とその送信専用ポート（PORT）
＃１７，トラック２（Track 2 ；MIDIMesg. Output）と
その送信専用ポート（PORT）＃１８，トラック３（Trac
k 3 ；MIDI Mesg. Output）とその送信専用ポート（PO
RT）＃１９，パス情報管理部（Path Information Mana
ger ）とその送受信ポート（PORT）＃５０，コントロー
ルデータ入出力部（Control Data Input / Output）と
その送受信ポート（PORT）＃６０とから構成されてい
る。この図においては、理解を容易にするため、いくつ
かのトラック及びその対応ポートの図示を省略してい
る。以下の各装置についても同じである。

【００１２】さらに、３はミキサ（8ch Digital Audio
Mixer ）であり、チャンネル１（Audio Data Input ）
とその受信専用ポート（PORT）＃１，チャンネル２（Au
dioData Input ）とその受信専用ポート（PORT）＃
２，チャンネル３（Audio DataInput ）とその受信専用
ポート（PORT）＃３，チャンネル４（Audio Data Inpu
t ）とその受信専用ポート（PORT）＃４，チャンネル５
（Audio Data Input）とその受信専用ポート（PORT）
＃５，チャンネル６（Audio Data Input ）とその受信
専用ポート（PORT）＃６，チャンネル７（Audio Data
Input ）とその受信専用ポート（PORT）＃７，チャンネ
ル８（Audio Data Input ）とその受信専用ポート（PO
RT）＃８，パス情報管理部（Path Information Manage
r ）とその送受信ポート（PORT）＃５０，コントロール
データ入出力部（Control DataInput / Output）とその
送受信ポート（PORT）＃６０とから構成されている。

【００１３】そして、４はＰＣＭ方式の音源１（PCM To
ne Generator ）であり、ＭＩＤＩメッセージ入力（MI
DI Mesg. Input ）とその受信専用ポート（PORT）＃
１，ＭＩＤＩメッセージ（MIDI Mesg. Input ）とその
受信専用ポート（PORT）＃２，オーディオデータ出力
（Audio Data Output(L) ）とその送信専用ポート（PO
RT）＃１０，オーディオデータ出力（Audio Data Outp
ut(R) ）とその送信専用ポート（PORT）＃１１，パス情
報管理部（Path Information Manager ）とその送受信
ポート（PORT）＃５０，コントロールデータ入出力部
（Control Data Input / Output）とその送受信ポート
（PORT）＃６０とから構成されている。また、５はＦＭ
方式の音源２（FM Tone Generator ）、６は音源３
（Tone Generator ）であり、これらの構成は音源１と
同様の構成とされている。なお、これらのノード１〜６
において、ポートはポートのプログラムにより独立して
動作しており、ポート以外の機能はアプリケーションプ
ログラムにより独立して動作している。

【００１４】このように構成された各部において、鍵盤
１の送信専用ポート（PORT）＃１は、パスＬ１によりシ
ーケンサ２の受信専用ポート（PORT）＃１，音源１の受
信専用ポート（PORT）＃２，音源２の受信専用ポート
（PORT）＃２，音源３の受信専用ポート（PORT）＃２に
接続されており、シーケンサ２の送信専用ポート（POR
T）＃１７は、パスＬ２により音源１の受信専用ポート
（PORT）＃１に接続されていると共に、図示しない他の
ノードのポートに接続されている。さらに、シーケンサ
２の送信専用ポート（PORT）＃１８は、パスＬ３により
音源２の受信専用ポート（PORT）＃１に接続されている
と共に、図示しない他のノードのポートに接続されてお
り、シーケンサ３の送信専用ポート（PORT）＃１９は、
パスＬ４により音源３の受信専用ポート（PORT）＃１に
接続されている。

【００１５】また、音源１の送信専用ポート（PORT）＃
１０は、パスＬ５によりミキサ３の受信専用ポート（PO
RT）＃１に接続されており、音源１の送信専用ポート
（PORT）＃１１は、パスＬ６によりミキサ３の受信専用
ポート（PORT）＃２に接続されており、音源２の送信専
用ポート（PORT）＃１０は、パスＬ７によりミキサ３の
受信専用ポート（PORT）＃３に接続されており、音源２
の送信専用ポート（PORT）＃１１は、パスＬ８によりミ
キサ３の受信専用ポート（PORT）＃４に接続されてお
り、音源３の送信専用ポート（PORT）＃１０は、パスＬ
９によりミキサ３の受信専用ポート（PORT）＃５に接続
されており、音源３の送信専用ポート（PORT）＃１１
は、パスＬ１０によりミキサ３の受信専用ポート（POR
T）＃６に接続されている。

【００１６】このように各ポート間を論理的パスＬ１〜
Ｌ１０により接続することにより、ＭＩＤＩで接続した
ネットワークと同様の動作を行うことができる。この論
理的パスは、前記したように仮想的な伝送路であるが、
例えば送信ポートは送信データにグループアドレスを付
与して送信データをブロードキャストし、グループアド
レスが設定された受信ポートが送信データを受信するこ
とにより論理的パスが構成されている。従って、この論
理的パス上に送信ポートから送出されたデータは、複数
の受信ポートにより受信することができる。そして、ネ
ットワークを構築している論理的パスは、一度ユーザが
設定しておき、その論理的パスの情報を受信ポートが記
憶するようにすれば、電源投入時やリセット時には、元
の論理的パスをネットワーク上に復活させて再構築する
ことができるものである。さらに、論路的パス情報を可
搬型の記憶媒体、例えば、フロッピーディスクに記憶し
ておき、このフロッピーディスクを接続管理装置にセッ
トすることにより論理的パスをネットワーク上に再構築
することもできるものである。

【００１７】次に、フローチャートを用いて、本発明の
電子楽器ネットワークシステムを詳細に説明する。本発
明の電子楽器ネットワークシステムに接続されるノード
のうち、ある特定のノードのメインルーチンのフローチ
ャートを図２に示す。この図において、電源を投入する
とメインルーチンがスタートされ、ステップＳ１００に
て機能の初期化、例えば音源モジュールの場合は異音が
発音されないようにダンプ処理等の通常機能初期化が行
われ、次にステップＳ１１０にて自ノードのアドレス等
の認識、および他ノードに何が接続されているか等の後
述するネットワーク機能初期化が行われる。そして、ス
テップＳ１２０にてネットワークから入ってきたデータ
が格納されたバッファが走査され、そのデータがネット
ワーク関連のデータか否かがステップＳ１３０にて判断
され、ネットワーク関連のデータと判断されると、ステ
ップＳ１４０にてネットワーク動作の管理を行うデータ
として、その受信処理が行なわれる。

【００１８】この受信処理では、ネットワーク処理のう
ちアプリケーションレベルまで上がらなければ処理でき
ないネットワーク関係の受信データの処理を行ってい
る。さらに、受信した相手が正常に動作しているか否か
の確認もこの処理で行われている。また、ネットワーク
関連のデータでないと判断された場合は、受信したデー
タは楽音制御情報と判断されて、この楽音制御情報によ
り音源の発音処理や消音処理等の発音状態に関する楽器
制御処理がステップＳ１５０にて行われる。ただし、こ
のステップＳ１５０の動作はノードが音源の場合の例で
あり、他のノードにおいてはその機能に応じた処理が行
われるようにされている。そして、ステップＳ１４０、
あるいはステップＳ１５０のステップが終了すると、ス
テップＳ１６０にてパネル処理が行われる。このパネル
処理には、パネル設定によりユーザがネットワーク上に
論理的パスを手動により構築する処理等が含まれてい
る。

【００１９】このパネル処理により、一旦パス管理テー
ブルが各ノードに作成されれば、その後はパス管理テー
ブルを基に論理的パスを再構築することができる。次
に、ステップＳ１７０にて外部への送信が必要なデータ
を送信バッファに記録したり、そのデータが重要なデー
タの場合は確認フラグの設定を行う等の電子楽器通常処
理が行われ、次いでステップＳ１８０にて送信バッファ
に記録されたデータのネットワークへの送信処理が行わ
れる。なお、ネットワークへの送信は、ポートと云う仮
想的なプログラムのポートを作成しておき、アプリケー
ションプログラムからポートに送信することによって行
われる。また、ポート情報テーブルのプロトコル（prot
ocol）がマルチキャスト（multicast ）になっているも
のは、通信相手のアドレスを指定せずに対応するグルー
プ番号を指定してブロードキャストする。そして、ステ
ップＳ１２０に戻り、ステップＳ１２０〜ステップＳ１
８０の前記した処理が循環して行われている。

【００２０】次に、パネル処理のフローチャートを図３
に示す。このパネル処理は通常のパネル処理を行うと同
時に、最初に構築するパスの設定を行う処理であり、パ
ネル処理がスタートされると、ステップＳ２００にて通
常のパネル処理が行われる。次に、ステップＳ２１０に
てパス接続処理を行うか否かが判断され、パス接続処理
を行うと判断されると、ステップＳ２２０にてノードテ
ーブルを基にネットワークに接続されているノードをデ
ィスプレイ上に表示する。この時、ノードテーブルから
では接続するポート情報が得られていないため、ステッ
プＳ２３０にてユーザの指定したノードに関するポート
情報を該当するノードから取り寄せて、このポート情報
をディスプレイに表示する。次に、ユーザがディスプレ
イを参照しながら指定したポート間をパスとしてステッ
プＳ２４０にて接続する。この接続はポート間を、前述
したように送信ポートのグループ番号に受信ポートのグ
ループ番号を合わせることにより接続する。さらに、ス
テップＳ２５０にて接続されたパスに基づいてパス管理
テーブルを書き替えリターンされる。また、ステップＳ
２１０にてパス接続処理は行わないと判断された場合は
そのままリターンされる。

【００２１】次に、前記メインルーチンにおけるステッ
プＳ１１０で行われているネットワーク機能初期化のフ
ローチャートを図４に示す。このネットワーク機能初期
化がスタートされると、ステップＳ３００にてネットワ
ークが立ち上がった時に、ノード番号を認識するアルゴ
リズムにより自機のノード番号を得る。次に、ステップ
Ｓ３１０にて後述するバックグランドネットワーク処理
が起動されるが、バックグランドネットワーク処理にお
いては、構成管理ノードになったノードは、パケットを
監視して、各パケットからのノード番号のブロードキャ
ストや、ノード番号を収集し、さらにパケットを上位層
に転送したり、パケットのサービス要求に応じた処理等
を行っている。そして、ステップＳ３００にて得られた
自機のノード番号を、ステップＳ３２０にてネットワー
ク上にブロードキャストする。このブロードキャストさ
れたノード番号のデータは、前記構成管理ノードとなっ
たノードが受けて自動的に記録する。

【００２２】さらに、ネットワークの構成を認識し、認
識後に構成情報完成のパケットを構成管理ノードはブロ
ードキャストするが、この構成情報完成のパケットを待
つステップがステップＳ３３０であり、構成管理ノード
の構成情報完成まで待機するステップである。なお、構
成管理ノードには、ネットワークに接続されたノードの
内余裕のあるノードがなるようなアルゴリズムとされて
いる。そして、ネットワークの構成情報が完成したこと
を示すパケットを得ると、ステップＳ３４０にて自ノー
ドのノード固有情報を構成管理ノードにネットワークを
通じて通知する。このノード固有情報は、自ノードのユ
ニークアドレス、ノード情報、機器固有番号であり、ユ
ニークアドレスは低位の電子機器の固有番号であり、製
品毎に異なる番号とされており、ノード情報はどのよう
な機能のノードであるかを表す情報であり、機器固有番
号は上位の機器に固有の番号であり、同じ機能の電子機
器には同じ番号が与えられている。

【００２３】このようなノード固有情報からなるノード
テーブルを図５に示す。この図において、例えばノード
番号１のユニークアドレスは「aaaa．aaaa」、ノード情
報は「MIDI Keyboard」、機器固有番号は「AAAAAAAA」
とされており、このノードテーブルのノード番号は、図
１に示す各ノードに付した１〜６の符号に対応してい
る。そして、構成管理ノードはすべてのノードから前記
したようなノード管理情報を受け取ると、ノード情報完
成のパケットをネットワーク上にブロードキャストす
る。このパケットを待つステップがステップＳ３５０で
あり、管理ノードが全ノードのノード固有情報を収集し
終るまで待機する。そこで、前記ノード情報完成のパケ
ットが得られると、ステップＳ３６０にて構成管理ノー
ドより他のノードのノード固有情報を取得し、自ノード
のノードテーブルとする。このノードテーブルは図５に
示すようなノードテーブルとされる。

【００２４】次に、ステップＳ３７０において自ノード
の機能に応じてポートを作成していくが、まず、ポート
番号を割当て、そのポートが入力ポートなのか、出力ポ
ートなのか、あるいは入力／出力ポートなのかの情報を
作成し、これにより図７に示すようなポート情報テーブ
ル（ＳＥＱの例を示している）を作成する。このポート
作成にあたり、送信専用ポートが各々一意なグループ番
号をステップＳ３７０にて取得している。そして、ステ
ップＳ３８０にて、例えば図８に示すようなパス管理テ
ーブル（ミキサの例を示している）が自ノードにあるか
否かが判断され、パス管理テーブルがあると判断された
場合には、ステップＳ３９０にてパスが再構成される。

【００２５】さらに、ステップＳ３９０にてパケット喪
失や相手ノードが反応しなかった場合のため、１回目で
構成できなかったパスについて再度パスの接続（パス再
構成リトライ）がステップＳ４００にて試みられる。ま
た、パス再構成リトライによっても接続できなったパス
は、該当するノードがなかったものとし、ステップＳ４
１０にて同一の機能を持つノードと強制的に接続されて
リターンされる。また、ステップＳ３８０にてパス管理
テーブルがないと判断された場合はそのままリターンさ
れる。なお、全く新たにノードをネットワークに接続し
た場合は、パス管理テーブルは存在しない。ここで、受
信用のポートを持たないノードは、図示する破線で囲ん
だステップＳ３８０ないしステップＳ４１０の処理ステ
ップは実装していない。

【００２６】ところで、前記ネットワーク機能初期化に
おけるステップＳ３１０にてバックグラウンドネットワ
ーク処理を起動しているが、起動されるバックグラウン
ドネットワーク処理とは、上位の電子楽器に関する処理
で行わなくても処理することのできる処理を表に出さず
バックグラウンドで行う処理であり、バックグラウンド
ネットワーク処理が起動されると、図１０に示すよう
に、ステップＳ５００にて自ノードの送信ポートからの
送信がいずれのノードで受信されているかを認識するた
めのmulticast テーブルを更新するタイミングか否かが
判断される。更新タイミングと判断されるとステップＳ
５１０にてmulticast テーブルを作成するために、更新
すべきポート番号の１つを取得し、ステップＳ５２０に
てグループ番号を指定してノード番号返答要求をブロー
ドキャストする。

【００２７】ここで、multicast テーブル（ＳＥＱの例
を示す）を図６に示すが、ポート番号１７にはノード番
号４，７，８，１０のノードが接続されており、ポート
番号１８にはノード番号５，９，１５，１８のノードが
接続されており、ポート番号１９にはノード番号６，１
０のノードが接続されていることを表している。なお、
ノード番号７以降のノードは図１には図示されていな
い。また、グループ番号とは図７に示すポート情報テー
ブルにおけるグループ番号を指しており、このグループ
番号、例えば『１０』のグループ番号をパケットにつけ
て送信するとこのグループ番号を持つ受信ポートを備え
たノード４（音源１）がこのパケットを受信するように
なる。

【００２８】ステップＳ５２０の処理が終了すると、ス
テップＳ５３０にてパケットの監視が行なわれ、さらに
ステップＳ５４０にて特殊処理が行われる。この特殊処
理には構成管理ノードになったノードが、各パケットか
らのノード番号のブロードキャストの収集や、ノード固
有情報の収集を行う。ただし、構成管理ノードなどの特
殊な機能を実現しないノードはこの特殊処理を実装して
いない。次いで、ステップＳ５５０にて、そのパケット
がブロードキャストか否か、あるいは自ノード宛なのか
否かが判断され、ブロードキャスト、あるいは自ノード
宛と判断された場合は、ステップＳ５６０にて上位層に
渡すべきパケットか否かが判断され、上位層に渡す例え
ば発音処理等のパケットでないと判断された場合は、さ
らにステップＳ５７０にてノード番号返答のパケットで
あるか否かが判断され、ノード番号返答のパケットと判
断された場合は、ステップＳ５９０にてノード番号とグ
ループ番号をパケットから取り出し、グループ番号に対
応するポート番号をポート情報テーブルを参照して検索
し、検索したポート番号に対応するmulticast テーブル
の欄にノード番号を書き込むことによりmulticast テー
ブルを作成する。

【００２９】また、ステップＳ５７０においてノード番
号返答のパケットと判断されない場合は、ステップＳ６
００にてサービス要求に応じて各種テーブルを参照し、
自ノードのデータを返送する。ここでは、パス設定時の
ポート属性の問い合わせに対する返答や、ユーザによる
ポート情報テーブルの要求に対する返答、および確認返
答要求に対する返答、さらにはmulticast の受信ノード
の確認の返答等が返送される。また、ステップＳ５６０
にて上位層に渡すべきパケットと判断された場合は、ス
テップＳ５８０にてパケットを上位層へ転送する。そし
て、ステップＳ５５０にてブロードキャストではなく、
かつ、自ノード宛ではないと判断された場合、およびス
テップＳ５８０、ステップＳ５９０あるいはステップＳ
６００の処理が終了した場合はステップＳ５００に戻
り、前記処理が循環して行われることにより、図６に示
すようなようなmulticast テーブルができ上がるように
なる。なお、ノードを構成する機器の接続状態は頻繁に
変更されるわけではないため、前記更新タイミングは十
分な時間間隔を取るようにしても良い。

【００３０】次に、図２に示すフローチャートのステッ
プＳ１７０にて処理されている電子楽器通常処理のフロ
ーチャートを図１１に示す。この電子楽器通常処理がス
タートされると、ステップＳ７００にて鍵盤を弾いたり
パネルを操作したことを検出するよう、楽器パネル／鍵
盤がスキャンされ、ステップＳ７１０にてパネル操作に
応じた電子楽器のモードに変更される。この場合、キー
オンやシーケンサ（ＳＥＱ）のスタートの操作が行われ
た時のように、モードの変更に伴い外部への送信が必要
となることがステップＳ７２０にて判断され、ステップ
Ｓ７３０にてポート番号を指定しデータを送信バッファ
に記録する。これにより、アプリケーションプログラム
の下位の層が送信バッファ内のデータを送信するように
なる。

【００３１】そして、ステップＳ７４０にて送信バッフ
ァに記録したデータが重要データか否かが判断され、重
要データと判断された場合はステップＳ７５０に進み、
送信バッファのデータに確認フラグをセットするように
する。また、重要データと判断されない場合はステップ
Ｓ７６０に進み、最後のmulticast 確認から所定の時間
が経過したか否かが判断され、所定時間が経過したと判
断されるとステップＳ７５０に進み、前記と同様に送信
バッファのデータに確認フラグをセットする。これは、
所定時間毎に確認フラグをmulticast で送信することに
より、相手ノードを少なくとも所定時間毎に調べるよう
にするためである。

【００３２】次いで、ステップＳ７６０にて所定時間が
経過してないと判断された場合、およびステップＳ７２
０にて外部への送信が必要でないと判断された場合と同
様に、ステップＳ７７０にてその他の楽器処理が行われ
てりターンされる。なお、重要データの例を図１８に示
す送信データと返答データの例を上げた表の左側に示す
が、○印を付した『KOFF』，『TONE change 』，『ALL
NOTE OFF』等のデータが重要なデータとされて、確認フ
ラグが付されて送信されるものである。

【００３３】次に、図２に示すフローチャートのステッ
プＳ１８０にて処理されているネットワーク送信処理の
フローチャートを図１２に示すが、この送信処理は、前
記電子楽器通常処理において送信バッファに記録された
データを送信する処理である。このネットワーク送信処
理が開始されると、ステップＳ８００にて送信バッファ
に記録された送信データが取り出され、ステップＳ８１
０にてポート情報テーブルより送信ポートに対応する情
報が取り出される。これは、ポート番号ではデータを送
信することができないので、図７に示すポート番号に対
応するグループ番号を取り出すようにする処理である。
次いで、ステップＳ８２０に進み『protocol』が『mult
icast 』、かつ、『type』が『TX ONLY』か否かが判断
され、『protocol』が『multicast 』、かつ、『type』
が『TX ONLY』と判断されると、さらに、ステップＳ８
３０にて確認フラグがあるか否かが判断される。なお、
『protocol』はポート情報テーブルに示されており、
『type』はポートが送信専用ポートか、受信専用ポート
か、送受信ポートであるかの種類を示しており、『TX
ONLY』は送信専用ポートであることを示している。

【００３４】そして、確認フラグが送信データに付され
ているとステップＳ８３０にて判断されると、ステップ
Ｓ８４０にてポート番号を元にmulticast テーブルを参
照し、対応ノード番号に対応するリターンテーブル領域
を確保し、その領域の全てにデータ待ちを示す「０」を
書き込むと共に、センドテーブルに対応情報を書き込む
ようにする。このセンドテーブルを図１７（ａ）に示す
が、例えばポート番号が「１７」とされて送信したデー
タとして『ALL NOTE OFF』データが書き込まれている。
さらに、リターンテーブルを図１７（ｂ）に示すが、こ
のテーブルの『状態』の欄に返答待ちを示す「０」を書
き込んでいる。なお、この図に示すリターンテーブルは
返答を受けて出来上がったテーブルである。次に、ステ
ップＳ８５０にてグループ番号を指定してデータをブロ
ードキャストし、ステップＳ８６０にてタイムアウト割
込みがenebleされリターンされる。これにより、タイマ
ーが起動されて返答を一定時間だけ待つようにされる。

【００３５】また、ステップ８２０にて『protocol』が
『multicast 』、かつ、『type』が『TX ONLY』と判断
されない場合は、ステップＳ８７０に進み『protocol』
が『transaction 』か否かが判断され、『transaction
』と判断されるとステップＳ８８０にて『transaction
』によるデータ通信が行われリターンされる。なお、
『transaction 』とは相互に通信相手がわかっている通
信である。また、ステップＳ８７０にて『transaction
』でもないと判断された場合は、ステップＳ８９０に
てエラー処理が行われリターンされる。この場合のエラ
ー処理は本発明における後述するエラー処理とは異なる
処理である。なお、ネットワーク上に送出するパケット
のフォーマットを示すが、ヘッダ部におけるマークには
スタートアドレスが設定され、受信アドレスには例えば
ブロードキャストを示すアドレスが設定され、送信アド
レスには自ノードのアドレス、グループ番号にはmultic
ast を示すグループ番号が設定され、確認フラグには前
記したように重要なデータの場合にフラグが付される。
また、データ部には送出すべきデータを設定し、フッタ
部には誤り訂正用のコードやエンドマークが設定され
る。

【００３６】次に、図２に示すフローチャートのステッ
プＳ１５０にて処理されている楽器制御処理のフローチ
ャートを図１４に示す。この楽器制御処理がスタートさ
れると、ステップＳ９００にて受信した楽音制御情報、
例えばキーオンやキーオフにより電子楽器の動作状態が
制御され、ステップＳ９１０にて確認フラグが付されて
いるか否かが判断され、確認フラグが付されていると判
断された場合は、受信した楽音制御情報が不適切か否か
がステップＳ９２０にて判断される。この場合、楽音制
御情報が不適切と判断されると、受信した楽音制御情報
により変化した楽器の内部状態を返答するデータ、例え
ばアサインしたらアサインしたとのデータ、アサインで
きなかったらアサインできなかったとのデータをステッ
プＳ９３０にて作成し、元々のパケットの送信アドレス
に対して上記データを確認返答としてステップＳ９４０
にて返送し、リターンされる。

【００３７】また、受信した楽音制御情報が不適切とス
テップＳ９２０にて判断されない場合、および確認フラ
グが付されているとステップＳ９１０にて判断されない
場合はそのままリターンされる。このように、破線で囲
ったステップＳ９２０を設けるようにすると、受信した
楽音制御情報が不適切な場合に限り、すなわちエラーが
発生した時にだけ確認返答を返送する第１実施例とする
ことができる。この場合には通信トラヒックをほとんど
増加させることなく受信側が正常に受信したか否かを確
認することができる。しかしながら、前記したmulticas
t テーブルは使用しないものである。また、ステップＳ
９２０を省略するようにすると、確認フラグが付されて
いる場合に全て確認返答を返送する第２実施例とするこ
とができ、受信側が正常に受信したことおよび正常に動
作したことを確認することができ、後述するようにmult
icast テーブルを使用してリターンテーブルを作成する
処理等が行われるものである。

【００３８】次に、図２に示すメインルーチンにおける
ステップＳ１４０にて処理されるネットワーク受信処理
のフローチャートを図１５に示す。ネットワーク受信処
理がスタートされると、ステップＳ１０００にてネット
ワークから受信されたデータがリセット信号か否かが判
断され、リセット信号と判断された場合は、ステップＳ
１０２０において自ノードのすべての機能をリセットす
る。このリセット信号は、新たなノードがネットワーク
に接続された時にネットワークをリセットするためのも
のである。なお、前記した図１に示すように、各ノード
はアプリケーションプログラムの部分とポートのプログ
ラムの部分とに独立して分離されたプログラムにより動
作されているため、ポートのプログラムだけをリセット
することが可能ではあるが、リセット信号の送出がネッ
トワークの端部から送出された場合等においては、ネッ
トワークの伝播遅延時間の影響により、他のノードが送
出したデータと衝突して音が鳴り続けたり暴走したりす
る恐れがあるため、ここではノードのすべての機能をリ
セットしている。

【００３９】また、リセット信号でないと判断された場
合は、パス管理テーブル処理がステップＳ１０１０にて
行われる。このパス管理テーブル処理では、例えばフロ
ッピーディスクに記憶されているパス管理テーブルによ
りパスを構築する場合の処理が行われる。次に、受信さ
れたデータが確認返答であるか否かがステップ１０３０
にて判断され、受信されたデータが確認返答と判断され
た場合は、受信されたパケットの送信アドレスから、ノ
ードテーブル等を参照してノード番号をステップＳ１０
４０にて得る。さらに返答データを、前記したネットワ
ーク送信処理において領域確保したリターンテーブルに
ステップＳ１０５０にて書き込む。次いで、返答データ
が期待されたデータか否かがステップＳ１０６０にて判
断され、期待された正常なデータの場合はリターンテー
ブルの該当箇所に成功を示す「１」がステップＳ１０７
０にて書き込まれてリターンされ、期待されたデータで
なく異常なデータの場合はリターンテーブルの該当箇所
にステップＳ１０８０にて失敗を示す「２」が書き込ま
れてリターンされる。

【００４０】この場合における送信データと返答データ
の例を図１８に示す。この表において、送信データとし
て例えば『KON 』信号が送信された場合は、期待された
正常な返答データはアサインされたことを示す『assign
ed』であり、期待されていない異常なデータはアサイン
されなかったことを示す『no assign channel 』とされ
る。また、『ALL NOTE OFF』信号が送信された場合は、
期待された正常な返答データは停止したことを示す『st
opped 』であり、期待されていない異常なデータは何の
データかわからないことを示す『what？』とされる（例
えば、接続誤りで演奏操作子のノードに『ALL NOTE OF
F』信号が送信された場合、このノードはデータを理解
することができない。）。このように判断して、リター
ンテーブルの状態の欄に返答データに応じた数字を書き
込んだものが図１７（ｂ）に示されている。なお、状態
が「０」とされているものは返答がなかったことを示し
ている。

【００４１】次に、リターンテーブルの状態欄に失敗を
示す「２」が書き込まれた場合に、異常なデータに対す
る処理を行うタイムアウト割込処理のフローチャートを
図１６に示す。このタイムアウト割込処理は、前記した
ネットワーク送信処理におけるステップＳ８６０にてen
ableされたものであり、タイマーが一定時間経過した時
に起動されて、ステップＳ１１００にて一度だけの割込
とされるようにタイムアウト割込がdisable される。次
いで、ステップＳ１１１０にてリターンテーブルより状
態欄のデータが取り出され、状態を示すデータが何であ
るか判断される。そして、「１」の場合は正常な返答デ
ータであるので、そのままステップＳ１１４０に進む
が、「２」の場合は異常な返答データの場合であるの
で、返送データに応じて予め決められたエラー処理をス
テップＳ１１３０にて実行した後、ステップＳ１１４０
に進み、「０」の場合は返答がなかった場合であるの
で、該アドレスに対してデータをステップＳ１１２０に
て再送した後、ステップＳ１１４０に進むようにされ
る。

【００４２】なお、ステップ１１３０にて行われるエラ
ー処理は、図１８に示す送信データと返答データの例の
表における右端の欄の「異常なデータへの対応」に示さ
れる処理である。例えば、『KOFF』信号を送信した場合
のエラー処理としてはこの返答データを無視する処理で
あり、『ALL NOTE OFF』信号を送信した場合のエラー処
理は、接続誤りがあることになるので、ユーザの確認を
得た後、ネットワークをリセットする処理とされる。そ
して、リターンテーブルよりデータをとり出していない
ノードが残っているとステップＳ１１４０にて判断され
た場合は、ステップＳ１１１０に戻りステップＳ１１４
０までの処理が循環して処理され、全てのノードの処理
が実行されると、ノードが残っていないとステップＳ１
１４０にて判断され、センドテーブルおよびリターンテ
ーブルをステップＳ１１５０にて消去した後、割込が復
帰される。

【００４３】以上説明したように、本発明においては２
つの実施例があり、第１の実施例においてはネットワー
ク上のあるノードからmulticast で複数のノードに対し
同時に楽音制御情報を与えた場合、その楽音制御情報が
自ノードにとって不適切なものである場合に限り、確認
返答データを返送するようにしたものであり、この場合
楽音制御情報が重要なものに限って確認返答を返送する
ようにしてもよいものである。さらに、一定時間ごとに
各multicast 出力ポートに対してどのノードがその情報
を受信しているが調べるようにしてもよいものである。

【００４４】本発明の第２の実施例においては、multic
ast の送信側が予め自分の情報を受信しているノードの
リストを用意しておき、重要なデータや正常に接続され
ているかを調べたい時に送信データに確認フラグを付し
てmulticast し、確認フラグを受信した受信ノードは、
そのデータによって変化した自分の状態を送信ノードに
返答する。送信側はこれを受けて、次々に返ってくるノ
ードの状態をノードリストに書き込み、ノードリストを
検査して期待したデータが返送されないノードに対して
所定の対応を行うようにしたものである。この場合、一
定時間ごとに各multicast 出力ポートに対してどのノー
ドがその情報を受信しているが調べるようにしてもよい
ものである。

【００４５】なお、前記第２実施例において、各ノード
の演算速度は十分速いものとされているためセンドテー
ブル・リターンテーブルが複数作成されることはなく、
楽音処理の間において前記一連の返答確認処理およびエ
ラー対応処理を行うことができ、前記一連の処理が他の
処理に支障を与えることはないようにされている。以上
の説明においては電子楽器のネットワークシステムにつ
いて説明したが、本発明は電子楽器のネットワークシス
テムに限らず民生用の電子機器、例えばテレビジョン、
ビデオテープレコーダ、オーディオ装置、カラオケ装置
等を接続したネットワークシステムに適用することがで
きる。

【００４６】

【発明の効果】本発明は以上説明したように、受信ノー
ドが不適切な制御情報を受信したことを受信ノードから
送信ノードに返送するようにしたので、送信ノードは制
御情報の誤りや接続の誤りを把握することができると共
に、不適切な制御情報が受信された時だけ返送すると、
通信のトラヒックが増加することを防止することができ
る。また、本発明において受信ノードが、制御情報を受
信したことによって生じる内部状態の変化を返送するよ
うにすると、制御情報が単に到着しただけではなく、送
信ノードが期待した動作を受信ノードが行っているかど
うかを確認することができる。これにより、接続誤りや
受信ノードの内部的なエラーを検出することができる。
また、重要な制御情報についてのみ返送を要求するよう
にすれば、通信のトラヒックを余り増加させることなく
前記処理を行うことができる。

【００４７】この際に、通信相手を確認する手段を動的
に行っているので、利用の途中でmulticast 対応のノー
ドが増加したり減少したりする事態にも問題なく対処す
ることができる。さらに、通信回線の問題で正常に通信
できなかったノードと、受信ノードの接続の矛盾によっ
て正常に処理できなかったノードとに分けて処理してい
るので、適切なエラー処理が可能となる。

【図面の簡単な説明】

【図１】本発明のネットワークシステムを用いて構築
した電子楽器のネットワークを示す図である。

【図２】メインルーチンのフローチャートである。

【図３】パネル処理のフローチャートである。

【図４】ネットワーク機能初期化のフローチャートで
ある。

【図５】ノードテーブルを示す図である。

【図６】 multicast テーブルの例を示す図である。

【図７】ポート情報テーブルを示す図である。

【図８】パス管理テーブルを示す図である。

【図９】パス設定状態の状態内容を表す図表である。

【図１０】バックグラウンドネットワーク処理のフロ
ーチャートを示す図である。

【図１１】電子楽器通常処理のフローチャートを示す
図である。

【図１２】ネットワーク送信処理を示す図である。

【図１３】パケットのフォ−マットを示す図である。

【図１４】楽器制御処理のフローチャートを示す図で
ある。

【図１５】ネットワーク受信処理のフローチャートを
示す図である。

【図１６】タイムアウト割込処理のフローチャートを
示す図である。

【図１７】センドテーブルおよびリターンテーブルを
示す図である。

【図１８】送信データと返答データの例を示す図表であ
る。

【符号の説明】

１鍵盤、２シーケンサ、３ミキサ、４音源１、
５音源２、６音源３、Ｌ１〜Ｌ１０論理的パス

───────────────────────────────────────────────────── フロントページの続き (58)調査した分野(Int.Cl.⁷，ＤＢ名) G10H 1/00

Claims

(57)【特許請求の範囲】

【請求項１】データを送信する送信ノードと、前記デ
ータを受信する受信ノードである電子楽器と、前記送信
ノードと前記受信ノードとを接続する通信ネットワーク
とからなるネットワークシステムにおける送信ノードで
あって、１ないし複数の前記受信ノードに対して前記データとし
て確認フラグを付加することのできる楽音制御情報を送
信する送信手段と、該送信手段により確認フラグが付加された前記楽音制御
情報を送信した送信先の前記受信ノードから、当該受信
ノードの楽音制御に関する内部状態の状態情報を受信す
る受信手段と、該受信手段により受信した状態情報が前記送信手段から
送信した確認フラグが付加された前記楽音制御情報に対
応して期待される内容であるか否かを判定する判定手段
と、該判定手段の判定に応じてエラー処理を実行するエラー
処理手段と、を備えたことを特徴とする送信ノード。
【請求項２】前記送信手段から送信すべきデータのう
ちの一部の楽音制御情報の種別についてのみ確認フラグ
を付加して前記受信ノードに対して前記状態情報の返送
を要求する返送要求手段を、さらに備えるようにしたこ
とを特徴とする請求項１記載の送信ノード。
【請求項３】所定の時間が経過する毎に、前記送信手
段から送信すべき前記楽音制御情報に確認フラグを付加
して前記受信ノードに対して前記状態情報の返送を要求
する返送要求手段を、さらに備えるようにしたことを特
徴とする請求項１記載の送信ノード。
【請求項４】前記状態情報を返送しない受信ノードが
存在するか否かを検出し、検出された前記状態情報を返
送しない受信ノードに対して前記送信したデータの再送
を行う再送手段を、さらに備えるようにしたことを特徴
とする請求項１ないし３のいずれかに記載の送信ノー
ド。
【請求項５】データを送信する送信ノードと、前記デ
ータを受信する電子楽器である受信ノードと、前記送信
ノードと前記受信ノードとを接続する通信ネットワーク
とからなるネットワークシステムにおける受信ノードあ
って、前記送信ノードから前記データとして楽音制御情報を受
信する受信手段と、該受信手段により受信した前記楽音制御情報に確認フラ
グが付加されているか否かに応じて、受信した前記楽音
制御情報に対応した状態情報の返送を前記送信ノードが
要求しているか否か検出する検出手段と、該検出手段において前記送信ノードが状態情報の返送を
要求していると検出された場合は、前記楽音制御情報を
受信した後の当該受信ノードの楽音制御に関する内部状
態を前記状態情報として前記送信ノードに対して送信す
る送信手段と、を備えたことを特徴とする受信ノード。
【請求項６】前記検出手段は、前記受信手段により受
信した前記楽音制御情報が不適切なデータであるか否か
検出するようにされており、該検出手段において受信し
た前記楽音制御情報が不適切なデータであると検出され
た場合は、前記楽音制御情報を受信した後の当該受信ノ
ードの楽音制御に関する内部状態を状態情報として、前
記送信手段が前記送信ノードに対して送信するようにし
たことを特徴とする請求項５記載の受信ノード。