JP4211750B2 - 電子音楽装置 - Google Patents

Description

この発明は、通信ネットワークを介して他の電子音楽装置との間で演奏データを相互に交換するセッションを行う機能を有する電子音楽装置に関する。

従来から、ＭＩＤＩ（Musical Instruments Digital Interface：登録商標）データのような、楽曲の演奏内容を示す演奏データを取り扱う装置を複数ケーブルで接続し、これらの間で演奏データを送受信させ、共同的に動作させることが行われている。
また、例えばＭＩＤＩデータを転送する場合には、従来は専用のインタフェースとケーブルを使用することが行われていた。しかし近年では、他の通信プロトコル上にＭＩＤＩメッセージを載せて転送を行うことにより、従来の専用インタフェースの場合と比べ、遠距離に、かつ大容量のデータを転送できるようにすることが提案されている。このような技術として、本件出願人は、インタフェースとしてＩＥＥＥ（Institute of Electrical and Electronic Engineers）１３９４を利用した通信規格ｍＬＡＮ（登録商標）を提案している。

また、通信プロトコルとしてＴＣＰ（Transmission Control Protocol）やＵＤＰ（User Datagram Protocol）及びＩＰ（Internet Protocol）を用いることにより、インターネットを介してＭＩＤＩデータを送受信できるようにすることも提案されている。
このような技術については、例えば特許文献１に記載されている。そして、この特許文献１には、インターネット上でＭＩＤＩデータを交換するセッションを実行する場合に、接続用サーバがセッションに参加する端末それぞれにＩＤを割り当てて通知し、各端末がＭＩＤＩデータを送信する際、そのＩＤと同じチャンネル番号を付して送信するようにすることが記載されている。
特開２００４−３０１９９７号公報

しかしながら、上述したＩＥＥＥ１３９４を利用した通信規格は、予め特定の参加装置を指定してセッショングループを形成し、その参加装置間に限定されたＭＩＤＩメッセージの交換を行う規格であり、セッショングループへの「飛び入り」ができないという問題があった。
また、特許文献１に記載の技術には、各端末をセッションに参加させる際に、ユーザが手動でグループを作成し、その後他の端末のユーザがそのグループを選択して参加を要求するといった、煩雑な操作が必要であるという問題があった。
この発明は、このような問題を解決し、複数の装置間で演奏データを送受信させる場合に、データの送受信のためのセッション形成の自由度を高めると共に、各装置を簡単な操作でセッションに参加させられるようにすることを目的とする。

上記の目的を達成するため、この発明は、通信ネットワークを介して他の電子音楽装置との間で演奏データを相互に交換するセッションを行う機能を有する電子音楽装置において、上記セッションを管理するマスタ装置を検索する検索手段と、その検索によりマスタ装置を発見できなかった場合に自身をマスタ装置として動作させ、マスタ装置を発見できた場合には、その発見したマスタ装置に対して自身の識別情報を含む参加要求及び自身の音源設定情報を送信する手段と、上記セッションの情報として、そのセッションに参加している電子音楽装置毎にその電子音楽装置の識別情報とチャンネルの情報と音源設定情報とを記憶する記憶手段と、マスタ装置として動作している場合に、他の電子音楽装置から参加要求を受け取ったことに応じて、自身が管理するセッションにおいて上記参加要求を送信してきた電子音楽装置に一意なチャンネルを割り当て、上記参加要求を送信してきた電子音楽装置の識別情報及びその装置が送信してきた音源設定情報とともにその割り当てたチャンネルの情報を上記記憶手段に追加記憶させ、その追加記憶させた割り当てチャンネルの情報に加え、上記自身が管理するセッションに参加している電子音楽装置のうち少なくとも前記参加要求を送信してきた電子音楽装置以外の全ての電子音楽装置の識別情報とチャンネルの情報及び音源設定情報を、上記参加要求を送信してきた電子音楽装置に通知すると共に、上記自身が管理するセッションに参加している電子音楽装置のうち上記参加要求を送信してきた電子音楽装置以外の電子音楽装置に、上記追加記憶した識別情報とチャンネルの情報及び音源設定情報を通知するセッション情報通知手段と、マスタ装置として動作していない場合に、上記発見したマスタ装置から、上記参加通知に対する応答としてチャンネルの割り当てを受け付けると共に、その発見したマスタ装置から通知された電子音楽装置の識別情報とチャンネルの情報及び音源設定情報を上記記憶手段に記憶させる手段と、上記記憶手段に記憶している識別情報により特定される他の電子音楽装置との間で上記マスタ装置により割り当てられたチャンネルを用いて上記演奏データを相互に交換する手段と、上記記憶手段に記憶している識別情報により特定される全ての電子音楽装置についてのチャンネルの情報及び音源設定情報と上記交換される演奏データとに基づき楽音信号を形成する手段とを設けたものである。

このような電子音楽装置において、マスタ装置として動作している場合に、他の電子音楽装置から離脱通知を受信したことに応じて、上記他の電子音楽装置の情報を上記記憶手段から削除し、上記記憶手段に記憶している識別情報に基づいて、その記憶手段に記憶している情報の変更内容を、上記自身が管理するセッションに参加している各電子音楽装置に通知する手段を設けるとよい。

あるいは、マスタ装置として動作していない場合に、参加中のセッションを管理するマスタ装置である電子音楽装置から離脱通知を受信したことに応じて、その電子音楽装置の情報を上記記憶手段から削除すると共に、自身を、上記参加中のセッションを管理するマスタ装置として動作させ、さらに、上記記憶手段に記憶している識別情報に基づいて、自身がマスタ装置であることを示す情報及び上記記憶手段に記憶している情報の変更内容を、自身が管理するセッションに参加している各電子音楽装置に通知する手段を設けるとよい。

以上のようなこの発明の電子音楽装置によれば、複数の装置間で演奏データを送受信させる場合に、データの送受信のためのセッション形成の自由度を高めると共に、各装置を簡単な操作でセッションに参加させられるようにすることができる。

以下、この発明を実施するための最良の形態を図面に基づいて具体的に説明する。
〔第１の実施形態：図１乃至図１８〕
まず、演奏データ通信管理システムの第１の実施形態について説明する。図１は、その演奏データ通信管理システムの概略構成を示すブロック図である。
この図に示す演奏データ通信管理システム１は、複数の端末装置１０の間で演奏データであるＭＩＤＩデータを送受信させる場合において、管理サーバ１００を設け、その管理サーバにより、ＭＩＤＩデータの送受信に係るセッションを管理させるようにしたものである。また、各端末装置１０が電子音楽装置に該当し、管理サーバ１００が演奏データ通信管理装置に該当する。

ここで、セッションとは、複数の端末装置１０が特定のグループ内の通信相手との間でＭＩＤＩデータを送受信（相互に交換）することをいう。そして、各端末装置１０は、管理サーバ１００に要求を行うことにより、そのグループのメンバーとなってセッションに参加し、同じグループ内の端末装置との間でＭＩＤＩデータを送受信可能な状態になることができるようにしている。また、管理サーバ１００は、セッションを行うグループのメンバーの情報を管理するとともに、端末装置１０からの要求に応じて、要求元の端末装置１０をグループに登録し、グループのメンバーが変化した場合に、グループの各メンバーに必要な情報を通知することにより、各メンバーが正常にセッションを行うことができるようにしている。

なお、管理サーバ１００は、複数のセッションを同時に管理することも可能であり、この場合には、複数のグループについてメンバーの情報を管理することになる。また、端末装置１０側から見れば、同じ管理サーバ１００と通信する端末装置であっても、違うグループの端末装置とはＭＩＤＩデータの送受信を行わず、同じグループの端末装置との間でのみＭＩＤＩデータの送受信を行うことになる。
また、演奏データ通信管理システム１においては、ＭＩＤＩデータの送受信は、基本的には、管理サーバ１００を介さず、各端末装置１０間でピアツーピア（Ｐ２Ｐ）により行うようにしている。

ここで、ピアツーピアとは、各端末間（個人間）で直接データの交換を行う通信ネットワーク（一般にはインターネット）の利用形態である。本願発明においては、ピアツーピアの通信を行うための通信プロトコルについて特段の制限はないが、ＭＩＤＩデータの伝送を行う場合には、データの等時性を維持するためのタイムスタンプや同期クロック等が規定された通信プロトコルであることが望ましい。また、端末装置間で交換されるデータの種別に応じて異なる通信プロトコルを利用するようにしてもよい。

次に、図２に、図１に示した端末装置１０のハードウェア構成を示す。
この図に示すように、端末装置１０は、ＣＰＵ１１，ＲＯＭ１２，ＲＡＭ１３，不揮発性メモリ１４，ネットワークインタフェース（Ｉ／Ｆ）１５，演奏入力デバイス１６，音源部１７を備え、これらがシステムバス１８に接続されている。また、サウンドシステム１９を、音源部１７に接続して設けている。

そして、ＣＰＵ１１は、端末装置１０を統括制御する制御部であり、ＲＯＭ１２に記憶された所要の制御プログラムを実行することにより、不揮発性メモリ１４へのデータの読み書き、ネットワークＩ／Ｆ１５を介した通信、演奏入力デバイス１６による演奏入力操作の検知、音源部１７によるＭＩＤＩデータに基づいた波形データの生成等を制御する制御動作を行う。

ＲＯＭ１２は、ＣＰＵ１１が実行する制御プログラムや、変更する必要のないデータ等を記憶する記憶手段である。このＲＯＭ１２をフラッシュメモリ等の書き換え可能な不揮発性記憶手段によって構成し、これらのデータを更新できるようにすることも考えられる。
ＲＡＭ１３は、ＣＰＵ１１のワークメモリとして使用したり、音源部１７でのＭＩＤＩデータの処理（波形データの合成）に使用するパラメータの値を記憶する記憶領域を設けたり、その他一時的に使用するデータを記憶したりする記憶手段である。

また、不揮発性メモリ１４は、不揮発ＲＡＭやＨＤＤ（ハードディスクドライブ）等による不揮発性の記憶手段であり、ＣＰＵ１１が実行する制御プログラムや、自動演奏用のＭＩＤＩ楽曲データ等、比較的容量が大きく、電源を切断しても保持しておく必要があるデータを記憶させるようにしている。

ネットワークＩ／Ｆ１５は、ＬＡＮ（ローカルエリアネットワーク）やインターネット等のネットワークを介して管理サーバ１００や他の端末装置１０と通信を行うためのインタフェースであり、例えばイーサネット（登録商標）方式の通信を行うためのインタフェースとすることができる。ただし、端末装置１０が使用する通信経路はこれに限られることはなく、ネットワークＩ／Ｆ１５は、通信経路の規格や使用する通信プロトコル等に応じて適切なものを用意する。また、複数の規格に対応させて複数の通信Ｉ／Ｆ１５を設けることも当然可能である。

演奏入力デバイス１６は、鍵盤や弦、パッド、マウスピース等、演奏のための操作を受け付けるためのデバイスであり、ユーザがこの演奏入力デバイス１６に対して行なった操作は、各種センサを備えた検出回路によって電気信号に変換されてＣＰＵ１１に伝えられる。そして、ＣＰＵ１１は、その信号をもとに、ユーザの演奏操作に応じた発音を音源部１７に指示するためのＭＩＤＩイベントを生成し、音源部１７に送信する。また、他の端末装置と通信中である場合には、その端末装置にも同じＭＩＤＩイベントを送信する。

音源部１７は、ＧＭ（ジェネラルＭＩＤＩ）対応の音源であり、ＣＰＵ１１から送られてくるＭＩＤＩイベントに基づき、複数の発音チャンネルでデジタル音響信号である波形データを生成する音源手段である。このＭＩＤＩイベントには、発音の開始や停止を指示するデータの他、音色等の、発音内容に関する設定の変更を指示するデータも含まれる。また、ＭＩＤＩイベントには、ＣＰＵ１１が生成したものも、他の端末装置１０から受信したものも含まれる。そして、後述するように、ＣＰＵ１１が生成したＭＩＤＩイベントと、他の端末装置１０から受信したＭＩＤＩイベントとを、チャンネルによって区別できるようにし、かつチャンネル毎に発音内容に関する設定を適切に行うことにより、音源部１７に、全体として、複数の端末装置１０による合奏のような波形データを生成させることができる。
サウンドシステム１９は、スピーカ等の発音手段であり、音源部１７から供給される波形データに従った発音を行う機能を有する。

以上のような構成を有する端末装置１０としては、具体的には、キーボード、電子オルガン、電子ピアノを始めとし、その他打楽器、弦楽器、管楽器等も含む電子楽器とすることが考えられる。あるいは、ＭＩＤＩシーケンサや、その機能を実現するためのアプリケーションを備えたＰＣ（パーソナルコンピュータ）等、演奏操作子を備えない装置であってもよい。また、携帯電話やＰＤＡ（Personal Digital Assistance）のような携帯型の端末であっても、ＭＩＤＩデータを取り扱う機能を有していれば、端末装置１０として機能し得る。
そして、端末装置１０は、ＭＩＤＩデータを送信する機能と受信する機能のいずれか一方を有していれば、必ずしも送信と受信の双方が可能である必要はない。また、音源部１７やサウンドシステム１９についても、必須ではない。

また、管理サーバ１００のハードウェアについては、ＣＰＵ，ＲＯＭ，ＲＡＭ，ＨＤＤ，ネットワークＩ／Ｆ等を備えた公知のコンピュータを用いることができる。そして、これらの各部の機能は、上述した端末装置１０における対応する構成要素の場合と同様であるので、詳細な説明は省略する。また、管理サーバ１００は、処理能力の高いＣＰＵや大容量のＨＤＤを備えていることが好ましいが、これに限られることはない。また、いずれかの端末装置１０に、管理サーバ１００の機能を兼ねさせることも考えられる。

次に、図３に、管理サーバ１００がセッションの管理のために記憶しておく情報の例を示す。
この図に示すとおり、管理サーバ１００は、ＨＤＤあるいはＲＡＭのような記憶手段に、セッションの管理のための情報として、グループ管理テーブル及び端末装置管理テーブルを記憶している。

そして、前者は、管理サーバ１００の管理下でセッションを行っているグループの情報を管理するためのテーブルであり、各グループのＩＤと共に、そのメンバー、すなわちセッションに参加している端末装置の情報を、その端末装置のＩＤにより登録している。ここで、グループＩＤは、管理サーバ１００の内部でのみ使用する情報である。また、同時に１つのグループのメンバーになれる端末装置１０の数に特に制限はないが、ジェネラルＭＩＤＩにおいては、使用できるチャンネル数が１６であるので、これに合わせて１６台に制限するようにするとよい。

一方、後者は、管理サーバ１００の管理下でセッションを行っている端末装置１０の情報を管理するためのテーブルであり、各端末装置１０について、そのＩＤと対応させて、セッションへの参加を要求してきた際に指定した通信相手のＩＤ、その端末装置が使用する音源設定の情報、その端末装置に割り当てたチャンネルの番号、およびその端末装置が属するグループのＩＤを登録している。
なお、管理サーバ１００の管理下で全くセッションが行われていない場合には、どちらのテーブルにも情報は登録されない。

また、図３に示した各テーブルにおいて、装置のＩＤとしては、機番や登録番号等、装置自体を識別するための情報を用いてもよいが、ＩＰアドレス等、該当する装置と通信する際に使用する宛先情報を使用するようにすることが好ましい。この点については後に詳述する。
また、音源設定の情報としては、例えばＭＩＤＩプログラムチェンジイベントにより設定する音色の情報を、プログラム番号により登録することが考えられるが、これに限られることはない。複数項目の情報を登録してもよい。

次に、図４及び図５に、上述した管理サーバ１００のＣＰＵが実行する受信データに関する処理のフローチャートを、セッションの管理のために行う処理の部分を中心に示す。なお、以下に説明する処理は、特に断らない限り全て、いずれかの装置のＣＰＵが所要の制御プログラムを実行することにより行うものである。
管理サーバ１００のＣＰＵは、端末装置１０等の外部装置から受信したデータを、一旦受信バッファに貯めておき、定期的なタイミングで図４及び図５のフローチャートに示す処理を行うことにより、それらのデータに応じた処理を行う。
そして、この処理においては、まず受信バッファを確認する（Ｓ１１）。そして、参加通知があれば（Ｓ１２）、ステップＳ１３乃至Ｓ２０の、参加通知に関する処理を行う。

ここで、図６に参加通知のデータ構成を示す。
参加通知は、端末装置１０が管理サーバ１００に対してセッションへの参加を要求する場合に送信してくる通知であり、図６に示す通り、参加通知であることを示す情報と、その通知の送信元の装置（通知元装置）のＩＤ（自機ＩＤ）と、通信を希望する通信相手のＩＤと、通知元装置における音源設定情報とを含むものである。

なお、端末装置１０から管理サーバ１００への情報の転送をパケット転送で行う場合、参加通知であることを示す情報は、パケット内に記載してもよいが、パケットのＩＤを利用することが考えられる。また、自機ＩＤとしては、パケットに付されるパケット送信元装置のＩＤの情報を利用することができる。ＩＤとしてＩＰアドレスを利用するのであれば、パケット送信元装置のＩＰアドレスを利用することができる。
また、音源設定情報は、通知元装置がセッションにおいて送信するＭＩＤＩイベントに係る発音を音源部１７に行わせる際に必要な範囲の設定内容（ここでは１チャンネル分の設定内容）の情報であり、通知元装置の音源に設定する全ての設定内容を含める必要はない。

図４の説明に戻ると、上記の参加通知に関する処理においてはまず、通知元装置が端末装置管理テーブルに登録済であれば、そのまま処理を抜けてステップＳ１２に戻る（Ｓ１３）。この場合、通知元装置は既にいずれかのセッションに参加していると考えられるので、同じ装置を二重にセッションに参加させてしまうことを防止するためである。なお、この判断は、グループ管理テーブルに登録済か否かによって行うようにしてもよい。

そして、登録済でなければ、次に、「通信相手ＩＤ」の示す装置が端末装置管理テーブル（又はグループ管理テーブル）に登録済か否か判断し（Ｓ１４）、登録されていなければ、現状ではその装置とセッションを行うことはできないため、新規にグループを作成して通知元装置をそのグループに登録し（Ｓ１５）、通信相手がセッションへの参加を要求してくるのを待たせることになる。逆に言えば、新規にグループを作成することを希望する場合には、参加通知にダミーの通信相手ＩＤを記載しておけばよいことになる。なお、新規グループのＩＤは、連番や乱数等、適当な方法で作成すればよい。一方、登録済であれば、通知元装置を通信相手の属するグループに登録する（Ｓ１６）。これらの登録は、グループ情報テーブルへのＩＤの登録により行うことができる。

そして、いずれの場合も、登録したグループにおいて空いているチャンネル（ＣＨ）を通知元装置に割り当てる（Ｓ１７）と共に、通知元装置の情報を端末装置管理テーブル（Ｓ１８）に登録する。チャンネルやグループの情報は、ステップＳ１５乃至Ｓ１７で定めたものを登録する。また、チャンネルの割り当ては、任意の方法でよいが、例えば、端末装置管理テーブルを参照して同じグループの端末装置に割り当てられているチャンネルをリストアップし、それ以外のチャンネルの中からランダムで選択して行うようにすることが考えられる。いずれにせよ、同じグループ内の複数の端末装置に同じチャンネルを割り当てないような、一意な割り当てを行うことができるようにすればよい。

そしてその後、通知元装置に状態通知を送信し、同じグループの全端末装置の情報を通知する（Ｓ１９）と共に、通知元装置と同じグループの（通知元装置以外の）全端末装置に状態通知を送信し、通知元装置の情報を通知する（Ｓ２０）。
そして、以上の後、ステップＳ１２に戻って処理を繰り返し、受信バッファに他にもデータがあればそのデータに関する処理を行う。
なお、以上のステップＳ１３乃至Ｓ２０の処理において、管理サーバ１００のＣＰＵがセッション情報通知手段として機能する。

ここで、図７に状態通知のデータ構成を示す。
この図に示す通り、状態通知は、管理サーバ１００が端末装置１０に対してセッションに参加している端末装置１０の情報を伝えるために送信する通知であり、状態通知であることを示す情報と、その状態通知がどの装置の状態を通知するものであるかを示す情報（装置ＩＤ）と、その装置に割り当てられているチャンネルの番号と、その装置における音源設定情報とを含む。

そして、この状態通知は、端末装置管理テーブルに登録されている情報に基づいて作成することができる。また、複数の装置に関する情報を通知する状態通知を送信することになる場合（主としてステップＳ１９）には、各装置ごとに状態通知を送信してもよいし、１つの状態通知に複数装置分の情報を含めるようにしてもよい。端末装置１０側では、この状態通知に含まれている情報に基づいて音源の設定を行う。
また、状態通知であることをパケットのＩＤにより示してよいこと、音源の設定の内容として全設定内容を含んでいなくてよいことは、上述の参加通知の場合と同様である。

再度図４の説明に戻ると、ステップＳ１２で参加通知がなかった場合には、ステップＳ２１に進み、ここで設定変更通知があれば、ステップＳ２２及びＳ２３の、設定変更通知に関する処理を行う。
設定変更通知は、端末装置１０が、自身の音源設定（のうち参加通知により管理サーバ１００に通知した部分）を変更した場合に、その内容を管理サーバ１００に通知するものである。そして、管理サーバ１００は、この通知を受けると、通知内容に基づいて端末装置管理テーブルの情報を更新する（Ｓ２２）と共に、通知元機器と同じグループの全端末装置に設定変更通知を送信し、音源設定の変更内容を通知する（Ｓ２３）。
そして、その後、ステップＳ１２に戻って処理を繰り返し、受信バッファに他にもデータがあればそのデータに関する処理を行う。

ここで、図８に設定変更通知のデータ構成を示す。
この図に示す通り、設定変更通知は、設定の変更内容を示すＭＩＤＩイベントであり、ここではＭＩＤＩプログラムチェンジイベントとしている。そして、端末装置１０から管理サーバ１００に送信する際には、通知送信元の装置のＩＤ（自機ＩＤ）を付するようにしている。自機ＩＤとして、パケットに付されるパケット送信元装置のＩＤの情報を利用することができることは、上述の参加通知の場合と同様である。
また、ＭＩＤＩプログラムチェンジイベントには、そのＭＩＤＩデータがＭＩＤＩプログラムチェンジイベントであることを示すステータスバイトと、設定を変更するチャンネルを示すチャンネル番号と、そのチャンネルに新たに適用すべき設定の内容を示すプログラム番号の情報を含む。

ＭＩＤＩプログラムチェンジイベントは、ＭＩＤＩイベントの一種であり、同じセッションに参加している端末装置間では管理サーバ１００を介さずに送受信されるものであるので、管理サーバ１００が関与しなくても、各端末装置は、他の端末装置から受信したＭＩＤＩプログラムチェンジイベントに従って音源部に適切な内容の設定を行うことができる。

しかし、ここで示したように、ＭＩＤＩプログラムチェンジイベントの内容を管理サーバ１００にも送信させ、また管理サーバ１００から通知送信元の装置と同じグループの端末装置にその内容を通知させることにより、データの冗長性を増し、端末装置間の転送あるいは管理サーバ１００から端末装置への転送のどちらかに不具合が生じた場合であっても、他方の経路で転送したデータを利用して音源部に適切な内容に設定を行うことができる。また、管理サーバ１００側で端末装置における音源の設定内容を把握し、ステップＳ１９で送信する状態通知により、新たにセッションに参加した端末装置に対し、グループ内の他の装置における音源部１７の設定の状態を通知し、適切な設定を行わせることができる。
なお、音源の設定に関する情報であれば、ＭＩＤＩプログラムチェンジイベントだけでなく、他のイベント、例えばＭＩＤＩコントロールチェンジイベントも上記のような設定変更通知として送受信するようにしてよいことは、もちろんである。

再度図４の説明に戻ると、ステップＳ２１で設定変更通知がなかった場合には、図５のステップＳ３１に進み、ここで離脱通知があれば、ステップＳ３２乃至Ｓ３５の、離脱通知に関する処理を行う。
離脱通知は、端末装置１０が、セッションから離脱する旨を管理サーバ１００に伝える通知である。そして、管理サーバ１００は、この通知を受けると、端末装置管理テーブル及びグループ管理テーブルから通知元装置の情報を削除する（Ｓ３２，Ｓ３３）。このことにより、通知元装置に対するチャンネルの割り当ても解消され、そのチャンネルは別の装置に割り当てることができる状態になる。そして、その削除の結果グループにメンバーがいなくなった場合には、グループ管理テーブルからそのグループ自体も削除する（Ｓ３４，Ｓ３５）。
そしてその後、図４のステップＳ１２に戻って処理を繰り返し、受信バッファに他にもデータがあればそのデータに関する処理を行う。

ここで、図９に離脱通知のデータ構成を示す。
この図に示す通り、離脱通知は、離脱通知であることを示す情報と、その通知元装置のＩＤとを含むが、特にこれ以上の情報を含める必要はない。また、これらの情報として、パケットのＩＤやパケット送信元装置のＩＤを利用できることは、上述の参加通知の場合と同様である。
なお、離脱通知を行った端末装置１０は、その後他の端末装置との間のＭＩＤＩデータの送受信をやめれば、セッションから離脱することができる。また、ＭＩＤＩデータの送受信に関して、ある時点から離脱した端末装置が応答を返さなくなることにより通信エラーが起こるようになれば、その端末装置がセッションから離脱したと認識することができる。また、離脱した端末装置に割り当てられていたチャンネルのＭＩＤＩデータはもはや送られてこないので、そのチャンネルの設定内容は、特に変更しなくても問題ない。

従って、管理サーバ１００側から、離脱通知の送信元の装置と同じグループの装置に対して、離脱に関する通知を行う必要は特にない。また、端末装置１０から管理サーバ１００に対して離脱通知を行うのは、グループ管理テーブルや端末装置管理テーブルの内容を、実際のセッションの内容に合ったものに保てるようにするためである。

図５の説明に戻ると、ステップＳ３１で設定変更通知がなかった場合には、ステップＳ３６に進み、ここで他のデータがあれば、その内容に応じた処理を行い（Ｓ３７）、図４のステップＳ１２に戻る。しかし、他のデータがなければ、もはや受信バッファ内の全てのデータに関する処理が終了しているため、フローチャートに係る処理を終了する。
管理サーバ１００は、以上のような処理を行うことにより、グループ管理テーブル及び端末装置管理テーブルにより、各端末装置が行っているセッションの状況や、各端末装置における音源の設定内容を把握し、また必要な場合に端末装置にこれらの情報を通知することができる。

次に、図１０に、端末装置１０が実行する受信データに関する処理のフローチャートを、セッションの実行のために行う処理の部分を中心に示す。
端末装置１０も、管理サーバ１００や他の端末装置等の外部装置から受信したデータは、一旦受信バッファに貯めておき、定期的なタイミングで図１０のフローチャートに示す処理を行うことにより、それらのデータに応じた処理を行う。

そして、この処理においては、まず受信バッファを確認する（Ｓ４１）。そして、装置ＩＤとして自身のＩＤを含む状態通知があれば（Ｓ４２）、その通知は、管理サーバ１００が、端末装置１０に割り当てたチャンネルを通知してきたものであるとわかる。そこで、演奏入力デバイス１６に、その状態通知で通知されたチャンネルを割り当てる（Ｓ４３）。すなわち、ＣＰＵ１１が演奏入力デバイス１６の操作に応じて生成するＭＩＤＩイベントに付すチャンネル番号を、管理サーバ１００によって割り当てられたチャンネルの番号に設定する。そしてさらに、音源部１７において、その通知されたチャンネルに、自機で使用する設定を行う（Ｓ４４）。この設定は、参加通知の送信時に管理サーバ１００に通知してある内容である。そして、例えば音色の設定を行えば、演奏入力デバイス１６の操作に応じて音源部１７に所望の音色で発音を行わせることができる。
ステップＳ４４の後は、ステップＳ４２に戻って処理を繰り返し、受信バッファに他にもデータがあればそのデータに関する処理を行う。

一方、ステップＳ４２で自身のＩＤを含む状態通知がなければ、ステップＳ４５に進む。そして、ここで装置ＩＤとして他機のＩＤを含む状態通知があれば、その通知は、管理サーバ１００が、同じセッションに参加している（又は新たに参加した）他の端末装置に割り当てたチャンネル及びそのチャンネルに係る音源設定内容を通知してきたものであるとわかる。そこで、その他機がまだ送信先リストに登録されていなければ、登録を行う（Ｓ４６，Ｓ４７）。また、どちらの場合も、通知内容に従って、音源部１７において通知されたチャンネルに通知された内容の設定を行い（Ｓ４８）、その後ステップＳ４２に戻って処理を繰り返す。

なお、上記の送信先リストは、同じセッションに参加し、ＭＩＤＩデータを送信する相手となる端末装置を登録するリストであり、データの送信時に使用するＩＰアドレス等の宛先情報を登録するようにする。そして、機器のＩＤとして宛先情報を使用している場合には、その宛先情報をそのまま登録すればよいが、そうでない場合には、何らかの手段で宛先情報を取得するようにする。例えば、管理サーバ１００にＩＤと宛先情報の対応関係を記憶させておき、各端末装置１０は、送信先リストへの登録を行う際に、管理装置１００へ問い合わせを行う等である。しかし、このようにすると、処理が複雑になるし、多少なりとも余分な時間を要するので、この点で、各端末装置のＩＤとして、ＩＰアドレス等の宛先情報を用いることが好ましいと言える。また、送信先リストに登録する情報は、必ずしも宛先そのものを示す情報でなくてもよく、どんな情報であれ、それをキーにしてデータの送信に必要な宛先を取得できるような情報であれば、宛先情報と呼ぶことにする。

また、管理サーバ１００からは、同じセッションに参加している各端末装置に同じ状態通知が送信されているはずであるから、各端末装置がその状態通知に従って音源部１７の設定を行うことにより、音源部１７の設定内容を揃えることができる。従って、セッションに参加している全ての端末装置が、同じ端末装置からのＭＩＤＩイベントに対して同じ音を発音できる状態にすることができる。もしこのような統一が取れていないと、例えば各チャンネルについて装置ごとに設定されている音色が違うと、同じＭＩＤＩイベントに対して送信先ごとに違った音が発音されてしまうことになり、セッションを利用して合奏を行うような用途には極めて不都合である。しかし、このシステムにおいては、このような不具合を避けることができる。

一方、ステップＳ４５で他機のＩＤを含む状態通知がなければ、ステップＳ４９に進む。そして、設定変更通知があれば、その内容に従って音源部１７に設定を行う（Ｓ５０）。管理サーバ１００側の説明で述べたように、この通知は、同じセッションに参加している端末装置からＭＩＤＩイベントとして受け取るものと同じであるから、ここで改めて設定変更を行うことは必須ではないが、設定変更を確実に行うことができるようにするため、あえて処理を二重にしたものである。
また、ステップＳ４９で設定変更通知がなければ、ステップＳ５１に進む。そして、ＭＩＤＩデータがあれば、そのデータをアンパケットして音源部１７に供給する（Ｓ５２）。このＭＩＤＩデータには、発音の開始や停止を指示するものもあれば、音源部１７の設定変更を指示するものもある。

また、ステップＳ５１でＭＩＤＩデータがなければ、ステップＳ５３に進む。そして、特定の送信先へのＭＩＤＩデータの送信に関して所定回数の送信エラーがあれば、エラーとなった送信先を送信先リストから削除する（Ｓ５４）。セッションから離脱した端末装置があった場合、その端末装置に対するＭＩＤＩデータの送信はエラーになると考えられるので、このような場合にその装置との通信を止めるためである。所定回数としたのは、偶然生じるエラーの発生をセッションからの離脱と認識してしまわないようにするためである。

図１０の説明に戻ると、ステップＳ５３で送信エラーがなかった場合には、ステップＳ５５に進み、ここで他のデータがあれば、その内容に応じた処理を行う（Ｓ５５，Ｓ５６）。しかし、他のデータがなければ、もはや受信バッファ内の全てのデータに関する処理が終了しているため、フローチャートに係る処理を終了する。
また、ステップＳ５０，Ｓ５２，Ｓ５４，Ｓ５６の後は、それぞれステップＳ４２に戻って処理を繰り返す。

次に、図１１に、端末装置１０が実行するデータ送信に関する処理のフローチャートを、セッションの実行のために行う処理の部分を中心に示す。
端末装置１０は、演奏入力デバイス１６の操作に応じて生成したＭＩＤＩデータ、あるいは管理サーバ１００に送信する通知等を、一旦送信バッファに貯めておき、定期的なタイミングで図１１のフローチャートに示す処理を行うことにより、それらのデータの送信を行う。

なお、管理サーバ１００に送信する通知には、参加通知、設定変更通知、離脱通知等がある。このうち、参加通知は、図示しない操作子等の操作により、通信相手のＩＤが特定され、セッション開始が指示された時点で、端末装置１０自身で生成するＭＩＤＩデータに基づく発音に使用する予定の設定内容（音色番号等）を取得して、これらの情報に基づいて生成するようにしている。

また、設定変更通知は、音源部１７における、自身に割り当てられているチャンネルの設定内容を監視し、その内容が変更された場合にその旨の通知を生成するようにしたり、送信バッファに書き込まれるＭＩＤＩデータの内容を監視し、プログラムチェンジ等、音源部１７の設定内容の変更に係るものがあった場合に、そのＭＩＤＩデータを管理サーバ１００宛てのパケットデータとして複製するようにすることも考えられる。ＣＰＵ１１が設定内容の変更に係るＭＩＤＩデータを生成した場合に、同時に管理サーバ１００宛てのパケットデータの生成も行うようにしてもよい。
また、離脱通知は、図示しない操作子等の操作により、セッションの終了が指示された場合に生成するようにしている。

そして、図１１に示す処理においては、まず送信バッファを確認する（Ｓ６１）。そして、ＭＩＤＩデータがあれば、そのＭＩＤＩデータを、送信先リストに登録された装置、すなわち同じセッションに参加している全ての端末装置に、ピアツーピアで直接送信する（Ｓ６２，Ｓ６３）。また、ＭＩＤＩデータがない場合、管理サーバ１００に送信する通知があれば、その通知を管理サーバ１００に送信する（Ｓ６４，Ｓ６５）。そして、どちらの場合も、ステップＳ６２に戻って処理を繰り返し、送信バッファに他にもデータがあればそのデータに関する処理を行う。また、ステップＳ６４で通知がなければ、もはや送信バッファ内の全てのデータに関する処理が終了しているため、フローチャートに係る処理を終了する。

端末装置１０は、以上の図１０及び図１１に示したような処理を行うことにより、管理サーバ１００にセッションへの参加を要求したり、管理サーバ１００から取得したデータに基づき、自身が使用するチャンネルと、通信相手となる装置の宛先情報と、その通信相手が使用するチャンネルの情報を設定し、それらの設定に基づいてＭＩＤＩデータの送受信を行ったりすることができる。

次に、図１２乃至図１８を用いて、管理サーバ１００及び端末装置１０が上述した処理により行う動作シーケンスの例について説明する。なお、これらの各図において、複数の端末装置を個別に区別するため、それぞれ異なる端末装置についてＡ，Ｂ，Ｃの符号を付して説明する。
まず、図１２に、管理サーバ１００に全く端末装置が登録されていない状態で最初の端末装置（端末装置Ａ）が参加通知を行う場合の処理シーケンス例を示す。
この場合、端末装置Ａ（ＩＤは「ＩＤ＃１」とする）は、自機ＩＤとしてＩＤ＃１を、通信相手ＩＤとしてＩＤ＃２（端末装置ＢのＩＤ）を、音源設定情報としてＰｒｏｇ＃１を含む参加通知を管理サーバ１００に送信する（Ｓ１０１）。

そして、これを受けた管理サーバ１００は、図４のステップＳ１３以下の処理により、通信相手として指定されたＩＤ＃２の装置が登録されていないため、グループ（ＩＤは「ＧＲＰ＃１」とする）を新規に作成し（Ｓ１０２）、作成したグループのメンバーとしてグループ管理テーブルに端末装置Ａを登録し（Ｓ１０３）、端末装置Ａにチャンネルを割り当てる（Ｓ１０４）と共に、端末装置管理テーブルに端末装置Ａの情報を登録し（Ｓ１０５）、端末装置Ａに状態通知を送信して割り当てたチャンネルを通知する（Ｓ１０６）。なお、端末装置Ａを登録したグループには他に端末装置が登録されていないため、他の装置への状態通知は行わない。
そして、端末装置Ａは、ステップＳ１０６の通知に応じて、図１０のステップＳ４３以下の処理により、演奏入力デバイス１６にＣＨ＃１を割り当て、音源部１７においてＣＨ＃１のチャンネルにＰｒｏｇ＃１の内容の設定を行う（Ｓ１０７）。

図１３に、この処理の終了時のグループ管理テーブル及び端末装置管理テーブルの状態を示す。
この図に示すとおり、グループ管理テーブルにはグループＧＲＰ＃１が新規作成されると共に端末装置ＡのＩＤであるＩＤ＃１が追加され、端末装置管理テーブルにも、端末装置Ａの情報が登録される。チャンネル番号は、管理サーバ１００が動的に割り当てたものである。なお、通信相手の情報は、テーブルに登録された後は特に意味を持たない。

次に、図１４に、図１２の処理の後、次の端末装置（端末装置Ｂ）が、端末装置Ａとのセッションを希望する参加通知を行う場合の処理シーケンス例を示す。
この場合、端末装置Ｂ（ＩＤは「ＩＤ＃２」とする）は、自機ＩＤとしてＩＤ＃２を、通信相手ＩＤとしてＩＤ＃１を、音源設定情報としてＰｒｏｇ＃２を含む参加通知を管理サーバ１００に送信する（Ｓ１１１）。

そして、これを受けた管理サーバ１００は、やはり図４のステップＳ１３以下の処理を行い、通信相手として指定されたＩＤ＃１の装置がグループＧＲＰ＃１に登録されているので、そのグループのメンバーとしてグループ管理テーブルに端末装置Ｂを登録し（Ｓ１１２）、端末装置Ｂに端末装置Ａと重ならないようにチャンネルを割り当てる（Ｓ１１３）と共に、端末装置管理テーブルに端末装置Ｂの情報を登録し（Ｓ１１４）、端末装置Ｂに状態通知を送信して、割り当てたチャンネルと、同じグループの端末装置Ａの情報を通知する（Ｓ１１５）。

そして、端末装置Ｂは、この通知に応じて、図１０のステップＳ４３以下の処理及びＳ４６以下の処理により、演奏入力デバイス１６にＣＨ＃２を割り当て、音源部１７においてＣＨ＃１，ＣＨ＃２のチャンネルにそれぞれＰｒｏｇ＃１とＰｒｏｇ＃２の内容の設定を行い、端末装置Ａの宛先情報を送信先リストに登録する（Ｓ１１６）。

また、管理サーバ１００は、端末装置Ａにも状態通知を送信し、新たに同じグループに登録された端末装置Ｂの情報を通知する（Ｓ１１７）。そして、端末装置Ａは、図１０のステップＳ４６以下の処理により、この通知に応じて音源部１７においてＣＨ＃２のチャンネルにそれぞれＰｒｏｇ＃２の内容の設定を行い、端末装置Ｂの宛先情報を送信先リストに登録する（Ｓ１１８）。
そして、以上により、端末装置Ａと端末装置Ｂは互いにピアツーピアでＭＩＤＩデータを送受信できる状態になり、通信を開始する（Ｓ１１９）。

図１５に、この処理の終了時のグループ管理テーブル及び端末装置管理テーブルの状態を示す。
この図に示すとおり、グループ管理テーブルにはグループＧＲＰ＃１のメンバーとして端末装置ＢのＩＤであるＩＤ＃２が追加され、端末装置管理テーブルにも、端末装置Ｂの情報が登録される。また、端末装置Ｂが通信相手として指定したＩＤ＃１の装置がグループＧＲＰ＃１のメンバーであることは、端末装置管理テーブルを参照すればわかるし、直接グループ管理テーブルを参照してもわかる。

次に、図１６に、図１４の処理の後、次の端末装置（端末装置Ｃ）が、端末装置Ａとのセッションを希望する参加通知を行う場合の処理シーケンス例を示す。
この場合、端末装置Ｃ（ＩＤは「ＩＤ＃３」とする）は、自機ＩＤとしてＩＤ＃３を、通信相手ＩＤとしてＩＤ＃１を、音源設定情報としてＰｒｏｇ＃３を含む参加通知を管理サーバ１００に送信する（Ｓ１２１）。なお、通信相手ＩＤをＩＤ＃２とした場合でも以下の動作は同様となる。

そして、これを受けた管理サーバ１００は、やはり図４のステップＳ１３以下の処理を行い、通信相手として指定されたＩＤ＃１の装置がグループＧＲＰ＃１に登録されているので、そのグループのメンバーとしてグループ管理テーブルに端末装置Ｃを登録し（Ｓ１２２）、端末装置Ｃに端末装置Ａや端末装置Ｂと重ならないようにチャンネルを割り当てる（Ｓ１２３）と共に、端末装置管理テーブルに端末装置Ｃの情報を登録し（Ｓ１２４）、端末装置Ｃに状態通知を送信して、割り当てたチャンネルと、同じグループの端末装置Ａや端末装置Ｂの情報を通知する（Ｓ１２５）。

そして、端末装置Ｃは、この通知に応じて、図１０のステップＳ４３以下の処理及びＳ４６以下の処理により、演奏入力デバイス１６にＣＨ＃３を割り当て、音源部１７においてＣＨ＃１，ＣＨ＃２，ＣＨ＃３のチャンネルにそれぞれＰｒｏｇ＃１，Ｐｒｏｇ＃２，Ｐｒｏｇ＃３の内容の設定を行い、端末装置Ａと端末装置Ｂの宛先情報を送信先リストに登録する（Ｓ１２６）。

また、管理サーバ１００は、端末装置Ａ及び端末装置Ｂにも状態通知を送信し、新たに同じグループに登録された端末装置Ｃの情報を通知する（Ｓ１２７，Ｓ１２８）。そして、端末装置Ａ及び端末装置Ｂはそれぞれ、この通知に応じて図１０のステップＳ４６以下の処理を行うことにより、音源部１７においてＣＨ＃３のチャンネルにそれぞれＰｒｏｇ＃３の内容の設定を行い、端末装置Ｃの宛先情報を送信先リストに登録する（Ｓ１２９，Ｓ１３０）。

そして、以上により、端末装置Ｃは端末装置Ａ及び端末装置Ｂと互いにピアツーピアでＭＩＤＩデータを送受信できる状態になり、通信を開始する（Ｓ１３１）。また、端末装置Ａと端末装置Ｂは、それまで通り通信を継続する（Ｓ１３２）。従って、上記の処理により、端末装置Ａ，Ｂ，Ｃは互いにピアツーピアの通信が可能な状態になる。
また、端末装置Ｃから見れば、１台の通信相手を指定するのみで、その通信相手と通信中の相手とも、同時に通信が可能な状態にすることができる。

次に、図１７に、図１６の処理の後、端末装置Ａにおいて音源部１７の設定変更操作がなされた場合の処理シーケンス例を示す。
この場合、端末装置Ａは、設定変更操作を検出すると、対応するＭＩＤＩイベント（ここではチャンネルＣＨ＃１の設定をＰｒｏｇ＃４に変更するＭＩＤＩプログラムチェンジイベントとする）を生成して音源部１７に供給し、音源部１７の設定を変更する（Ｓ１４１）。また、送信先リストに登録されている送信先に、同じＭＩＤＩイベントを送信する（Ｓ１４２）。そして、これを受け取った他の端末装置も、図１０のステップＳ５２の処理により、ＭＩＤＩイベントに従って音源の設定を変更する（Ｓ１４３）。

一方、端末装置Ａは、管理サーバ１００にもチャンネルＣＨ＃１の設定をＰｒｏｇ＃４に変更することを示す設定変更通知を送信する（Ｓ１４４）。そして、管理サーバ１００は、図４のステップＳ２２以下の処理により、端末装置管理テーブルの端末装置Ａの情報を通知の内容に従って変更する（Ｓ１４５）と共に、端末装置Ａと同じグループの各端末装置に、設定変更通知を送信して設定の変更を通知する（Ｓ１４６）。そして、これを受信した各端末装置はそれぞれ、図１０のステップＳ５０の処理により、通知内容に従って音源部１７の設定を変更する（Ｓ１４７）。上述の通り、ステップＳ１４７の処理は、通常はステップＳ１４１やＳ１４３の処理と重複するが、誤り防止のために行うものである。
以上の処理により、１台の端末装置での音源部１７の設定変更を、他の端末装置にも反映させることができる。

次に、図１８に、図１７の処理の後、端末装置Ａにおいてセッションの終了操作がなされた場合の処理シーケンス例を示す。
この場合、端末装置Ａは、終了操作を検出すると、管理サーバ１００に離脱通知を送信する（Ｓ１５１）と共に、他の端末装置との間の通信を中止する（Ｓ１５２）。そして、管理サーバ１００側では、離脱通知に応じて、図５のステップＳ３２以下の処理により、通知元の端末装置Ａの情報をグループ管理テーブルや端末装置管理テーブルから削除する（Ｓ１５３）。

また、それまで端末装置Ａとセッションを行っていた端末装置Ｂや端末装置Ｃは、端末装置Ａとの間の通信が失敗するようになるため（Ｓ１５４）、図１０のステップＳ５４の処理により送信先リストから端末装置Ａを削除する（Ｓ１５５，Ｓ１５６）。ただし、端末装置Ｂと端末装置Ｃの間の通信は継続する（Ｓ１５７）。
以上の処理により、端末装置Ａはセッションから離脱することができる。

以上説明してきたような演奏データ通信管理システム１によれば、各端末装置１０は、セッションに参加する場合、データを送受信したい相手の端末装置のうちいずれか１つを指定して管理サーバ１００に対して参加を要求するだけで、指定した端末装置が参加しているセッションに参加し、同じセッションに参加している全ての端末装置との間でデータを送受信できる状態となる。また、希望の通信相手がセッションを行っていない場合には、自動的に新しいセッショングループを作成することができる。従って、セッションへの参加に当たり、セッションルームの設定といった煩雑な操作は不要であり、セッション形成の自由度を高めると共に、各装置を簡単な操作でセッションに参加させられるようにすることができる。

また、音源設定の情報も管理サーバ１００で管理するようにすれば、セッションに新たに参加した端末装置に、既にセッションに参加している端末装置における音源部の設定内容を通知し、逆に、既にセッションに参加している端末装置にも、セッションに新たに参加した端末装置おける音源部の設定内容を通知できる。従って、各装置がこの通知に基づいて音源部の設定を行うようにすれば、セッションへの参加時にユーザが特に設定操作を行わなくても、同じセッションに参加している装置間で音源部の設定内容を共通化し、ＭＩＤＩイベントをどの装置に送信した場合でも、そのＭＩＤＩイベントに従って同じ音が発音されるようにすることができる。
また、端末装置間のＭＩＤＩデータの転送は、管理サーバ１００を介さずにピアツーピアで行うようにしているから、情報伝送の遅延量を抑えることができる。

〔第２の実施形態：図１９乃至図２７〕
次に、演奏データ通信管理システムの第２の実施形態について説明する。図１９は、その演奏データ通信管理システムの概略構成を示すブロック図である。
この図に示す演奏データ通信管理システム２は、複数の端末装置２０をネットワーク３０を介して通信可能とし、各端末装置２０に、第１の実施形態で説明した端末装置１０の機能と、管理サーバ１００の機能を併せ持たせたものである。すなわち、各端末装置２０が、電子音楽装置にも演奏データ通信管理装置にも該当する。ただし、１グループのセッションにつき１台の端末装置２０をマスタノードとし、そのマスタノードでのみ、管理サーバ１００としての機能を有効にし、他の端末装置２０では管理サーバ１００としての機能を無効にするようにしている。

なお、万一、１グループのセッションにおいて２台以上の端末装置２０が同時にマスタとなるような事態が発生した場合には、適宜ネゴシエーションを行わせ、マスタとなった時刻のタイムスタンプが早い方を優先、あるいはランダム等により、いずれか１台のみをマスタノードとして機能させるようにする。２以上の端末装置２０が同時にセッションへの参加を試みた場合には、このような事態が発生しうる。また、マスタは、ネットワーク３０を介して通信可能な範囲内に１台のマスタノードしか存在できないようにしてもよい。
また、ネットワーク３０としては、ＬＡＮやインターネットを始め、種々の通信経路を利用可能である。ネットワークトポロジーも任意である。
このような端末装置２０は、ハードウェア構成は第１の実施形態の端末装置１０と同様であるので、その説明は省略する。また、対応する構成要素の符号としては、図２に示したものを用いる。

以下、図２０乃至図２４のフローチャートにより、端末装置２０が実行する種々の処理について説明する。なお、第１の実施形態で説明した処理と共通する部分については、説明を簡単にするか省略する。
まず、図２０に、セッション参加時の処理のフローチャートを示す。
端末装置２０は、図示しない操作子により、セッションへの参加指示を受け付けると、図２０のフローチャートに示す処理を開始する。そして、まずネットワーク３０上の全ノード、あるいはセッションにより通信しようとする相手が存在すると想定されるアドレス範囲等に、マスタ検索通知をブロードキャストし、既にマスタノード（以下単に「マスタ」ともいう）となっている端末装置２０があるか否かの検索を行なう（Ｓ２０１）。通信しようとする相手が個別に把握できるのであれば、個別にマスタ検索通知を送信してもよい。このステップＳ２０１の処理において、端末装置２０のＣＰＵが検索手段として機能する。

そして、マスタがあれば、その装置から応答が帰ってくるはずであるので、その有無に基づいてマスタの有無を判断し（Ｓ２０２）、あれば、そのマスタに対して参加通知を送信して（Ｓ２０３）処理を終了する。この参加通知は図６に示したものと同様な形式でよいが、ここでは少なくともマスタが通信相手であることは明らかであるから、通信相手ＩＤを含める必要はない。

一方、マスタがなければ、自機をマスタとし（Ｓ２０４）、自身で使用するチャンネルを決定し（Ｓ２０５）、音源部１７において、決定したチャンネルに自機で使用する設定を行う（Ｓ２０６）。そしてさらに、ノード情報テーブルを作成して必要な情報を登録し（Ｓ２０７）、処理を終了する。

次に、図２１に、ノード情報テーブルの例を示す。
ノード情報テーブルは、各端末装置２０が記憶するテーブルで、第１の実施形態における端末装置管理テーブルと対応するものである。そして、自身が参加しているセッションについて、そのセッションに参加している各端末装置の情報と、そのセッションにおけるマスタのＩＤとの情報を含むものである。

端末装置の情報としては、ＩＤとチャンネル番号と音源設定情報を登録するようにしている。ここでは、１つのセッションに参加している端末装置の情報を扱うので、通信相手ＩＤとグループ番号については不要であり、登録していない。
このノード情報テーブルは、最低限マスタのみが記憶していればよいが、ここでは、マスタがセッションから離脱する場合の処理の単純化を考慮し、セッションに参加している全端末装置２０に記憶させるようにしている。

次に、図２２に、マスタとなった端末装置２０が実行する、受信データに関する処理のフローチャートを示す。
端末装置２０は、他の端末装置２０等の外部装置から受信したデータは、一旦受信バッファに貯めておき、自機がマスタとなっている場合、定期的なタイミングで図２２のフローチャートに示す処理を行うことにより、それらのデータに応じた処理を行う。

そして、この処理においては、まず受信バッファを確認する（Ｓ２１１）。そして、参加通知があれば（Ｓ２１２）、ステップＳ２１３乃至Ｓ２１８の、参加通知に関する処理を行う。この処理は、参照するテーブルがノード情報テーブルである点と、グループに関する処理がない点、通知元装置に対する情報の通知の際に、ノード情報テーブルの内容を全て送信する点、自身でも図１０のステップＳ４７及びＳ４８の場合のように送信先リストの更新や音源の設定を行う点（Ｓ２１８）が異なるが、それ以外の点は、図４のステップＳ１３乃至Ｓ２０の処理と同様なものである。

また、これらのステップＳ２１３乃至Ｓ２１８の処理において、端末装置２０のＣＰＵがセッション情報通知手段として機能する。また、マスタ以外の端末装置２０は、後述のようにこの部分の処理は行わないので、マスタとして動作する状態になると、セッション情報通知手段の機能は有効になると言える。逆もまた成り立つ。
そして、ステップＳ２１８の後は、ステップＳ２１２に戻って処理を繰り返し、受信バッファに他にもデータがあればそのデータに関する処理を行う。

一方、ステップＳ２１２で参加通知がなかった場合には、ステップＳ２１９に進み、ここで離脱通知があれば、ステップＳ２２０及びＳ２２１の、離脱通知に関する処理を行う。この処理は、図５のステップＳ１３２以下の処理と対応する処理であるが、ここでは、各端末装置２０がノード情報テーブルを記憶するようにしているので、他の端末装置にもテーブルの変更内容を通知するようにしている（Ｓ２２１）。
また、ステップＳ２１９で離脱通知がなかった場合には、ステップＳ２２２に進む。そして、マスタ検索通知があれば、応答として自機のＩＤを返送する（Ｓ２２３）。

また、ステップＳ２２２でマスタ検索通知がなかった場合には、ステップＳ２２４以降の処理に進み、ＭＩＤＩデータ、通信エラーあるいはその他のデータがあった場合にそれらに応じた処理を行う（Ｓ２２４〜Ｓ２２９）が、この処理は、図１０のステップＳ５１乃至Ｓ５６の場合と同様なものである。
また、ステップＳ２２１，Ｓ２２３，Ｓ２２５，Ｓ２２７，Ｓ２２９の後は、ステップＳ２１２に戻って処理を繰り返す。

次に、図２３に、マスタ以外の端末装置２０が実行する、受信データに関する処理のフローチャートを示す。
マスタ以外の端末装置２０は、定期的なタイミングで、図２２のフローチャートに代えて、図２３のフローチャートに示す処理を行うことにより、受信バッファに貯めておいたデータに応じた処理を行う。

そして、この処理においては、まず受信バッファを確認する（Ｓ２３１）。そして、状態通知があれば（Ｓ２３２）、通知内容に従って自身で記憶しているノード情報テーブルを更新する（Ｓ２３３）と共に、演奏入力デバイス１６へのチャンネルの割り当て、音源部の設定及び送信先リストの更新を行う（Ｓ２３４）。このステップＳ２３４の処理は、図１０のステップＳ４２乃至Ｓ４８の処理と対応するものである。

一方、ステップＳ２３２で状態通知がなければ、ステップＳ２３５に進む。そして、ここで離脱通知があれば、ステップＳ２３６乃至Ｓ２３８の離脱通知に関する処理を行う。なお、マスタ以外の端末装置２０は、セッションから離脱する場合にマスタに離脱通知を送信するので、マスタ以外の端末装置２０が離脱通知を受信するのは、マスタからのみである。逆に、マスタは、セッションから離脱しようとする場合に、セッションに参加している端末装置２０の中で、次にマスタにしたい端末装置２０に、離脱通知を送信するようにしている。

そして、離脱通知に関する処理においては、まずノード情報テーブルに自機をマスタとして登録し（Ｓ２３６）、ノード情報テーブルから離脱した端末装置（前のマスタ）の情報を削除する（Ｓ２３７）。このことにより、以後この処理を実行中の端末装置２０はマスタとして機能するようになり、離脱した装置に対するチャンネルの割り当ても解消される。そしてその後、ノード情報テーブルに登録されている他の全端末装置に状態通知を送信し、テーブルの変更内容を通知する（Ｓ２３８）。以上の処理により、マスタの変更を行うことができる。

また、ステップＳ２３５で離脱通知がなかった場合には、ステップＳ２３９以降の処理に進み、ＭＩＤＩデータ、通信エラーあるいはその他のデータがあった場合にそれらに応じた処理を行う（Ｓ２３９〜Ｓ２４４）が、この処理は、図１０のステップＳ５１乃至Ｓ５６の場合と同様なものである。
また、ステップＳ２３４，Ｓ２３８，Ｓ２４０，Ｓ２４２，Ｓ２４４の後は、ステップＳ２３２に戻って処理を繰り返す。

なお、端末装置２０は、管理サーバ１００の場合と異なり、セッションに参加している各端末装置における音源設定が変更された場合、ＭＩＤＩイベントによりその通知を受ける。また、その内容を別途保管しておかなくても、自身の音源部１７における設定内容を参照すれば、各端末装置に割り当てたチャンネルにどのような設定がなされているかを把握することができる。従って、第１の実施形態の場合のように設定変更通知を用いなくても、これらの情報に基づいて、ノード情報テーブルにおける音源設定情報の内容を、各端末装置の現状に合った状態に保つことができる（この処理の図示は省略した）。しかし、この実施形態でも、ＭＩＤＩイベントの送受信とは別に、設定変更通知の送受信を行うようにしてもよい。これは、マスタについても、マスタ以外の端末装置２０についても、同様である。

次に、図２４に、端末装置２０のＣＰＵが実行するデータ送信に関する処理のフローチャートを示す。
この処理は、マスタも、マスタ以外の端末装置も共通に実行するものである。そして、この処理で送信する通知には、参加通知、離脱通知、マスタ検索通知等があり、送信先は一意ではないため、ステップＳ２５４，Ｓ２５５においては通知を送信すべき相手（例えばマスタ）を特定して通知の送信を行うが、その他の点では第１の実施形態で図１１に示した処理とほぼ同様なものである。

マスタとなった端末装置２０は、以上の図２２及び図２４に示したような処理を行うことにより、第１の実施形態における端末装置１０と管理サーバ１００の機能を兼ねたような動作を行うことができる。
また、マスタ以外の端末装置２０は、以上の図２３及び図２４に示したような処理を行うことにより、第１の実施形態における端末装置１０と同様な機能を実現しつつ、マスタから要求された場合に次のマスタとして機能するようになる動作を行うことができる。

次に、図２５乃至図２７を用いて、各端末装置２０が上述した処理により行う動作シーケンスの例について説明する。なお、これらの各図において、複数の端末装置を個別に区別するため、それぞれの端末装置についてＡ，Ｂ，Ｃの符号を付して説明する。
まず、図２５に、マスタとなった端末装置Ａ（ＩＤは「ＩＤ＃１」とする）に対して２番目の端末装置（端末装置Ｂ）が参加通知を行う場合の処理シーケンス例を示す。

この場合、端末装置Ｂ（ＩＤは「ＩＤ＃２」とする）は、図２０のステップＳ２０１の処理によりブロードキャストでマスタ検索を行い（Ｓ３１１）、これに対してマスタである端末装置Ａは、図２２のステップＳ２２３の処理により応答を返す（Ｓ３１２）。すると、端末装置Ｂはその応答を返してきた端末装置Ａに対し、図２０のステップＳ２０３の処理により、自機ＩＤとしてＩＤ＃２を、音源設定情報としてＰｒｏｇ＃２を含む参加通知を送信する（Ｓ３１３）。

そして、これを受けた端末装置Ａは、図２２のステップＳ２１４以下の処理により、端末装置Ｂに端末装置Ａと重ならないようにチャンネルＣＨ＃２を割り当てる（Ｓ３１４）と共に、ノード情報テーブルに端末装置Ｂの情報を登録し（Ｓ３１５）、通知内容に従って音源部１７のＣＨ＃２のチャンネルにＰｒｏｇ＃２の内容の設定を行い、端末装置Ｂの宛先情報を送信先リストに登録する（Ｓ３１６）。そしてその後、端末装置Ｂに状態通知を送信して、ノード情報テーブルの内容を通知する（Ｓ３１７）。

そして、端末装置Ｂは、この通知に応じて、図２３のステップＳ２３３以下の処理により、ノード情報テーブルを更新（この場合は新規作成）し（Ｓ３１８）、演奏入力デバイス１６にＣＨ＃２を割り当て、音源部１７においてＣＨ＃１，ＣＨ＃２のチャンネルにそれぞれＰｒｏｇ＃１とＰｒｏｇ＃２の内容の設定を行い、端末装置Ａの宛先情報を送信先リストに登録する（Ｓ３１９）。
そして、以上により、端末装置Ａと端末装置Ｂは互いにピアツーピアでＭＩＤＩデータを送受信できる状態になり、通信を開始する（Ｓ３２０）。

次に、図２６に、図２５の処理の後、次の端末装置（端末装置Ｃ）が、端末装置Ａに対して参加通知を行う場合の処理シーケンス例を示す。
この場合、端末装置Ｃ（ＩＤは「ＩＤ＃３」とする）は、図２５の場合と同様、端末装置Ａとの間でマスタ検索と応答を交換し（Ｓ３３１，Ｓ３３２）、その後、自機ＩＤとしてＩＤ＃３を、音源設定情報としてＰｒｏｇ＃３を含む参加通知を端末装置Ａに送信する（Ｓ３３３）。

そして、これを受けた端末装置Ａは、やはり図２２のステップＳ２１４以下の処理により、端末装置Ｃに端末装置Ａや端末装置Ｂと重ならないようにチャンネルＣＨ＃３を割り当てる（Ｓ３３４）と共に、ノード情報テーブルに端末装置Ｃの情報を登録し（Ｓ３３５）、通知内容に従って音源部１７のＣＨ＃３のチャンネルにＰｒｏｇ＃３の内容の設定を行い、端末装置Ｃの宛先情報を送信先リストに登録する（Ｓ３３６）。そしてその後、端末装置Ｃに状態通知を送信して、ノード情報テーブルの内容を通知する（Ｓ３３７）。また、同じセッションに参加している端末装置Ｂにも、ノード情報テーブルの変更内容を通知する（Ｓ３３８）。

そして、端末装置Ｂ及び端末装置Ｃは、それぞれ、状態通知に応じてノード情報テーブルを更新する（Ｓ３３９）と共に送信先や音源等の設定を行う（Ｓ３４０）。そして、以上により、端末装置Ｃは端末装置Ａ及び端末装置Ｂと互いにピアツーピアでＭＩＤＩデータを送受信できる状態になり、通信を開始する（Ｓ３４１）。また、端末装置Ａと端末装置Ｂは、それまで通り通信を継続する（Ｓ３４２）。従って、上記の処理により、端末装置Ａ，Ｂ，Ｃは互いにピアツーピアの通信が可能な状態になる。
また、端末装置Ｃから見れば、マスタに参加通知を送信するのみで、そのマスタが管理するセッションに参加している全ての端末装置と、同時に通信が可能な状態にすることができる。

次に、図２７に、図２６の処理の後、端末装置Ａにおいてセッションの終了操作がなされた場合の処理シーケンス例を示す。
この場合、端末装置Ａは、終了操作を検出すると、セッションに参加しているいずれかの端末装置に、離脱通知を送信する（Ｓ３５１）と共に、他の端末装置との間の通信を中止する（Ｓ３５２）。どの装置に送信するかは、ランダムでも、ユーザの指示に従っても、適宜定めればよい。

ここでは端末装置Ｂに送信したとすると、端末装置Ｂは、図２３のステップＳ２３６以下の処理により、ノード情報テーブルに自機をマスタとして登録し（Ｓ３５３）、ノード情報テーブルから端末装置Ａの情報を削除する（Ｓ３５４）。そして、ノード情報テーブルに登録されている他のノードの状態通知を送信し、ノード情報テーブルの変更内容（ここでは変更後のテーブルそのもの）を通知する（Ｓ３５５）。
ここでは通知先は端末装置Ｃであり、この通知を受けた端末装置Ｃは、図２３のステップＳ２３３以下の処理により、通知内容に従ってノード情報テーブルを更新する（Ｓ３５６）。

また、それまで端末装置Ａとセッションを行っていた端末装置Ｂや端末装置Ｃは、端末装置Ａの通信中止により、端末装置Ａとの間の通信が失敗するようになるため（Ｓ３５７）、図２３のステップＳ２４２の処理により端末装置Ａを送信先リストから削除する（Ｓ３５８，Ｓ３５９）。ただし、端末装置Ｂと端末装置Ｃの間の通信は継続する（Ｓ３６０）。
なお、ステップＳ３５４やＳ３５６の直後に端末装置Ａの送信先リストからの削除を行ってしまうことも考えられる。

以上の処理により、端末装置Ａは、セッションから離脱した上で、マスタとしての動作を端末装置Ｂに引き継ぐことができる。この場合において、各端末装置にノード情報テーブルを記憶させてあるので、離脱する側は、単に離脱通知を行うのみでよい。従って、離脱時に負荷の大きい処理が発生しないようにすることができる。

以上で実施形態の説明を終了するが、装置の構成、具体的な処理内容やデータの形式等が上述の各実施形態で説明したものに限られないことはもちろんである。
例えば、取り扱う演奏データの形式が、ＭＩＤＩ形式でなくても構わないし、ＭＩＤＩデータの転送を、ピアツーピア形式で行うシステムに限られることもない。端末装置１０間のデータの転送を、管理サーバ１００や、別の転送サーバを介して行うようにすることも考えられる。

また、第１の実施形態において、上述の音源部１７の設定変更につき、各端末装置１０が、セッションに参加中に音源部１７の設定変更を行う場合、その内容を他の端末装置には送信せず、管理サーバ１００のみに通知するようにし、他の端末装置は、管理サーバ１００から送信されてくる設定変更通知に従って音源部１７の設定を変更するようにすることも考えられる。
この場合、設定を変更しようとした端末装置１０は、自機の音源部１７については、自身で生成したＭＩＤＩイベントに従って設定を変更できるようにしてもよいが、自機の音源部１７についても、管理サーバ１００からの設定変更通知に従って変更するようにしてもよい。このようにすれば、セッションに参加している全端末装置の音源部１７の設定を、一律の内容に保ちやすくなる。

また、管理サーバ１００は、特に変更がなくても、セッション毎に、セッションに参加している全端末装置における設定内容を、そのセッションに参加している全端末装置に定期的に通知するようにしてもよい。このように定期的に通知を行うようにすれば、一部のデータが通信異常により欠落したような場合でも、その後の通知時にその欠落を補うことができる。
また、各端末装置が、セッションに参加する際に使用するＩＤを、インターネット上のポータルサイト等に登録・蓄積・公開できるようにしておき、そのポータルサイトのユーザリストを検索する等により、ユーザがセッションの相手を探すことができるようにすることも考えられる。この場合、検索で得られたＩＤを通信相手のＩＤとして指定して管理サーバ１００にセッションへの参加を要求すればよい。

また、管理サーバ１００の機能として、音源部の設定内容の管理及び通知を行うことは必須ではなく、最低限、セッションを行っているグループ毎に、端末装置のＩＤを管理し、端末装置にチャンネルを割り当て、上述したような状態通知により、ＩＤ及びチャンネルの通知を行うようにすればよい。
また、ここではセッションに参加する各端末装置に対してチャンネルを１チャンネルずつ割り当てる例について説明したが、これに限られることはなく、複数チャンネルを割り当てることができるようにしてもよい。

また、端末装置１０と管理サーバ１００の双方の機能を有する装置を設ける場合に、第２の実施形態のように、これらを組み合わせた機能を有する装置を用意するのではなく、単にこれらの双方の機能を別々に有する装置を用意するようにしてもよい。このようにした場合には、端末装置１０が、自身が参加していないセッションの管理を行う場合もありうる。また、この場合、管理サーバ１００の機能を有する端末装置１０は、１台でよい。
また、第２の実施形態においては、各端末装置２０に、送信先リストを設けず、ノード情報テーブルに登録されている端末装置が送信先であるとして取り扱って、ＭＩＤＩデータの送信を行うようにしてもよい。

さらに、コンピュータを上述したような端末装置１０，２０や管理サーバ１００として機能させるためのプログラムを、予めＲＯＭやＨＤＤ等に記憶させておくほか、ＣＤ−ＲＯＭあるいはフレキシブルディスク等の不揮発性記録媒体（メモリ）に記録して提供し、そのメモリからこのプログラムをＲＡＭに読み出させてＣＰＵに実行させたり、プログラムを記録した記録媒体を備える外部機器あるいはプログラムをＨＤＤ等の記憶手段に記憶した外部機器からダウンロードして実行させたりしても、同様の効果を得ることができる。
また、各実施形態や変形例の内容は、矛盾しない範囲で組み合わせて適用できることも、もちろんである。

以上の説明から明らかなように、この発明の電子音楽装置によれば、複数の装置間で演奏データを送受信させる場合に、データの送受信のためのセッション形成の自由度を高めると共に、各装置を簡単な操作でセッションに参加させられるようにすることができる。
従って、操作性の高い通信環境を提供することができる。

演奏データ通信管理システムの第１の実施形態の構成を示すブロック図である。 図１に示した端末装置のハードウェア構成を示す図である。 図１に示した管理サーバがセッションの管理のために記憶しておく情報を示す図である。 図１に示した管理サーバが実行する受信データに関する処理の一部のフローチャートである。 図４の続きの処理のフローチャートである。

参加通知のデータ構成を示す図である。 状態通知のデータ構成を示す図である。 設定変更通知のデータ構成を示す図である。 離脱通知のデータ構成を示す図である。 図１に示した端末装置が実行する受信データに関する処理のフローチャートである。

同じくデータ送信に関する処理のフローチャートである。 管理サーバに全く端末装置が登録されていない状態で最初の端末装置Ａが参加通知を行う場合の処理シーケンス例を示す図である。 図１２に示した処理の終了時のグループ管理テーブル及び端末装置管理テーブルの状態を示す図である。 図１２の処理の後、次の端末装置Ｂが、端末装置Ａとのセッションを希望する参加通知を行う場合の処理シーケンス例を示す図である。 図１４に示した処理の終了時のグループ管理テーブル及び端末装置管理テーブルの状態を示す図である。

図１４の処理の後、次の端末装置Ｃが、端末装置Ａとのセッションを希望する参加通知を行う場合の処理シーケンス例を示す図である。 図１６の処理の後、端末装置Ａにおいて音源部の設定変更操作がなされた場合の処理シーケンス例を示す図である。 図１７の処理の後、端末装置Ａにおいてセッションの終了操作がなされた場合の処理シーケンス例を示す図である。 演奏データ通信管理システムの第２の実施形態の概略構成を示すブロック図である。 図１９に示した端末装置がセッション参加時に実行する処理のフローチャートである。

ノード情報テーブルの例を示す図である。 図１９に示したシステムにおいて、マスタとなった端末装置が実行する、受信データに関する処理のフローチャートを示す。 同じくマスタ以外の端末装置が実行する、受信データに関する処理のフローチャートである。 同じく端末装置が実行するデータ送信に関する処理のフローチャートである。 マスタとなった端末装置Ａに対して２番目の端末装置Ｂが参加通知を行う場合の処理シーケンス例を示す図である。 図２５の処理の後、次の端末装置Ｃが、端末装置Ａに対して参加通知を行う場合の処理シーケンス例を示す図である。 図２６の処理の後、端末装置Ａにおいてセッションの終了操作がなされた場合の処理シーケンス例を示す図である。

符号の説明

１，２…演奏データ通信管理システム、１０，２０…端末装置、１１…ＣＰＵ，１２…ＲＯＭ、１３…ＲＡＭ、１４…不揮発性メモリ、１５…ネットワークＩ／Ｆ、１６…演奏入力デバイス、１７…音源部、１８…システムバス、１９…サウンドシステム、３０…ネットワーク、１００…管理サーバ

Claims (3)

1. 通信ネットワークを介して他の電子音楽装置との間で演奏データを相互に交換するセッションを行う機能を有する電子音楽装置であって、
   前記セッションを管理するマスタ装置を検索する検索手段と、
   該検索によりマスタ装置を発見できなかった場合に自身をマスタ装置として動作させ、マスタ装置を発見できた場合には、その発見したマスタ装置に対して自身の識別情報を含む参加要求及び自身の音源設定情報を送信する手段と、
   前記セッションの情報として、該セッションに参加している電子音楽装置毎に該電子音楽装置の識別情報とチャンネルの情報と音源設定情報とを記憶する記憶手段と、
   マスタ装置として動作している場合に、他の電子音楽装置から参加要求を受け取ったことに応じて、自身が管理するセッションにおいて前記参加要求を送信してきた電子音楽装置に一意なチャンネルを割り当て、前記参加要求を送信してきた電子音楽装置の識別情報及び該装置が送信してきた音源設定情報とともにその割り当てたチャンネルの情報を前記記憶手段に追加記憶させ、該追加記憶させた割り当てチャンネルの情報に加え、前記自身が管理するセッションに参加している電子音楽装置のうち少なくとも前記参加要求を送信してきた電子音楽装置以外の全ての電子音楽装置の識別情報とチャンネルの情報及び音源設定情報を、前記参加要求を送信してきた電子音楽装置に通知すると共に、前記自身が管理するセッションに参加している電子音楽装置のうち前記参加要求を送信してきた電子音楽装置以外の電子音楽装置に、前記追加記憶した識別情報とチャンネルの情報及び音源設定情報を通知するセッション情報通知手段と、
   マスタ装置として動作していない場合に、前記発見したマスタ装置から、前記参加通知に対する応答としてチャンネルの割り当てを受け付けると共に、該発見したマスタ装置から通知された電子音楽装置の識別情報とチャンネルの情報及び音源設定情報を前記記憶手段に記憶させる手段と、
   前記記憶手段に記憶している識別情報により特定される他の電子音楽装置との間で前記マスタ装置により割り当てられたチャンネルを用いて前記演奏データを相互に交換する手段と、
   前記記憶手段に記憶している識別情報により特定される全ての電子音楽装置についてのチャンネルの情報及び音源設定情報と前記交換される演奏データとに基づき楽音信号を形成する手段とを設けたことを特徴とする電子音楽装置。
2. 請求項１記載の電子音楽装置であって、
   マスタ装置として動作している場合に、他の電子音楽装置から離脱通知を受信したことに応じて、該他の電子音楽装置の情報を前記記憶手段から削除し、前記記憶手段に記憶している識別情報に基づいて、該記憶手段に記憶している情報の変更内容を、前記自身が管理するセッションに参加している各電子音楽装置に通知する手段を設けたことを特徴とする電子音楽装置。
3. 請求項１記載の電子音楽装置であって、
   マスタ装置として動作していない場合に、参加中のセッションを管理するマスタ装置である電子音楽装置から離脱通知を受信したことに応じて、該電子音楽装置の情報を前記記憶手段から削除すると共に、自身を、前記参加中のセッションを管理するマスタ装置として動作させ、さらに、前記記憶手段に記憶している識別情報に基づいて、自身がマスタ装置であることを示す情報及び前記記憶手段に記憶している情報の変更内容を、自身が管理するセッションに参加している各電子音楽装置に通知する手段を設けたことを特徴とする電子音楽装置。

Images