JP2008310363A - 電子楽器演奏システム - Google Patents

Abstract

【課題】より多くの複数の楽器を含む演奏システムを簡素化する。
【解決手段】複数の演奏端末２は生徒が演奏する楽器であり、楽音発生端末１は教師が管理する端末である。楽音発生端末１並びに複数の演奏端末２はＬＡＮ１２に接続される。演奏端末２で演奏によって作成された演奏データはＬＡＮ１２を経由して楽音発生端末１で受信される。楽音発生端末１は、受信した演奏データに基づいて楽音データを作成し、その楽音データはＬＡＮ１２を経由して演奏端末２に送信される。演奏端末２は受信した楽音データに従って楽音を発生する。楽音発生端末１の操作パネル４には演奏端末２の任意のものを選択するスイッチを設ける。
【選択図】図１

Description

本発明は、電子楽器演奏システムに関し、特に、楽音データ発生端末と複数の演奏データ発生端末を備えた電子楽器演奏システムに関する。

複数の楽器をＭＩＤＩケーブルを用いて接続する方法が知られる。ＭＩＤＩでは、基本的に１対１の接続しか考慮されていないため、複数台の電子楽器を接続する場合は接続数に応じたＭＩＤＩケーブルを必要とする。また、電子楽器には限定された数のＭＩＤＩ端子しか設けられていないので、接続される電子楽器の台数はあまり多くできない。例えば、ＭＩＤＩチャネルが１６チャネルであることから、同時に１７台以上の電子楽器を相互に接続することはできない。さらに、ＭＩＤＩ規格では通信速度が演奏情報を転送するように決定されており、それ以上の高速転送は困難である。

一方、上記ＭＩＤＩによる接続の問題点を解消するシステムとして、ＬＡＮを経由して複数の電子楽器局、操作子局、音源局、およびシーケンサ局を互いに接続したシステムが提案されている（特開平６−２５２９２８号公報）。
特開平６−２５２９２８号公報

上記特許文献１に開示された従来技術のようにＬＡＮを経由して複数の電子楽器等を互いに接続したシステムでは、例えば、操作子局から送出されるリアルタイム演奏データに基づいて電子楽器局で楽音を発生させたり、リアルタイム演奏データに基づいて音源局で楽音を合成して電子楽器で楽音を発生させたりするように構成することが考えられる。

しかし、従来技術では、他端末で発生した楽音データによって自端末で発音することはできるが、演奏データを送出した演奏端末が、その演奏データに基づいて他端末で発生された楽音データによってリアルタイムで楽音を発生するということはできなかった。すなわち、演奏端末間で音源を共有しているものではなかった。

例えば、学校や音楽教室等で複数の電子鍵盤楽器をＬＡＮを経由して接続してレッスンをしたり合奏をしたりする場合、複数の生徒が操作子としての鍵盤装置を持つだけではこれらの生徒は自分の演奏音を聞くことができない。各自が自己の演奏音をモニタするためには、全ての生徒が鍵盤装置とともに楽音データを生成する音源を備えた電子鍵盤楽器をそれぞれ持たなければならない。また、自己の演奏音だけでなく他の生徒との合奏音を聞きたいという要望もある。そのために、大勢の生徒が簡易な鍵盤装置などの演奏端末を使って同時に電子楽器のレッスンを行うことができるシステムが望まれる。

本発明は、上記課題に鑑み、音源を重複して設けるという無駄を省きつつ、複数の演奏者による演奏を可能にする電子楽器演奏システムを提供することを目的とする。

上記の課題を解決し、目的を達成するための本発明は、演奏データを作成し、ネットワークを経由して前記演奏データを楽音発生端末に送信する手段、前記演奏データに基づいて前記楽音発生端末で作成された楽音データをネットワークを経由して受信する手段、および受信した楽音データに従って発音するサウンドシステムを有する複数の演奏端末と、前記演奏端末から送信された演奏データを受信する手段、および該演奏データに基づいて楽音データを作成してネットワークを経由して該演奏端末に送信する手段を有する楽音発生端末とを備え、前記楽音データがパケット通信によってネットワーク上に送出されるとともに、前記演奏端末が、受信した前記パケットの誤りを検出する誤り検出手段と、前記誤り検出手段で検出された誤りを補正する補正手段とを備えている点に第１の特徴がある。

また、本発明は、パリティデータの検査によって誤りを検出する手段を有する点に第２の特徴があり、パケットの不着を誤りとして検出する手段を有する点に第３の特徴がある。

また、本発明は、前記サウンドシステムによる発音を、少なくとも楽音データの１パケット分遅延させる手段と、前記誤りが検出されたときに、誤りが検出されたパケットに先行するパケットの楽音データをループさせて、誤りが検出されたパケットの楽音データに代えるループ手段とを備えて誤りを補正する点に第４の特徴がある。

また、本発明は、前記ループさせる楽音データを、該楽音データを収容したパケットに先行するパケットの楽音データとクロスフェードさせる第１演算手段と、前記ループさせる楽音データを、該楽音データを収容したパケットの後続パケットの楽音データとクロスフェードさせる第２演算手段とを備え、前記ループ中は、前記第１演算手段でクロスフェードされた楽音データに従って発音し、前記ループ終了後は第２演算手段でクロスフェードされた楽音データに従って発音するように構成された点に第５の特徴がある。

上記特徴を有する本発明によれば、演奏端末は演奏データによって楽音を作成する手段を備えなくてもよいので、例えば、複数の演奏端末を生徒が使用し、楽音発生端末を教師が使用するようにした音楽教室などにおいて、演奏端末を簡素化することができる。また、ＬＡＮもしくはＷＡＮを通じて楽音発生端末並びに演奏端末を接続するので、より多くの演奏端末を簡単に接続することができる。特に、楽音データをパケットにして通信する際の誤りを補正することができる。

第２の特徴によれば、パリティエラーとして誤りを検出し、補正することができる。第３の特徴によれば、パケットの不着を検出して補正をすることができる。

第４の特徴によれば、不着パケットに代えてその直前のパケットをループして使用することができる。第５の特徴によれば、楽音データのクロスフェードにより、ループして使用するパケットとその前後のパケットとの連続性を確保することができる。

以下、図面を参照して本発明を詳細に説明する。図１は本発明の一実施形態に係る電子楽器演奏システムのブロック図である。同図において、この演奏システムは、例えば、複数の生徒のための電子楽器のレッスンシステムである。この演奏システムは、教師が使用する楽音データ発生端末（以下、「楽音発生端末」という）１と生徒が使用する複数の演奏データ発生端末（以下、「演奏端末」という）２とからなる。

楽音発生端末１は、鍵盤３、操作パネル４、音源（ＴＧ）５、サウンドシステム６、および制御部７を備える。鍵盤３は押鍵・離鍵を検出して演奏データ（キーナンバおよびベロシティを含む）を演奏者の演奏に応じてリアルタイムに出力する図示しないキーセンサを備える。操作パネル４は各種指示入力のためのスイッチや液晶パネル等の表示画面を有する。音源５は複数設けられ、演奏データに基づいて楽音データを発生する。サウンドシステム６は楽音データのＤ／Ａ変換器（ＤＡＣ）６１、増幅器（ＡＭＰ）６２およびスピーカ（ＳＰ）６３を備える。ヘッドフォン端子を設けて増幅器６２の出力をスピーカ６３だけでなくヘッドフォン端子（図示しない）にも供給できるようにする。

演奏端末２は、鍵盤８、操作パネル９、サウンドシステム１０、および制御部１１を備える。演奏端末２は、音源５並びに音源５で使用する波形データやパラメータを保持していない点で楽音発生端末１と異なる。また、楽音発生端末１の操作パネル４には、演奏端末２の操作パネル９にないスイッチ（後述）を設ける。なお、楽音発生端末１には、必ずしも鍵盤３を設けなくてもよい。

楽音発生端末１および演奏端末２の制御部７，１１は、回線１２に接続される。回線１２は、ＩＥＥＥ８０２．３標準のＬＡＮつまりイーサネット（登録商標）で、伝送速度１００メガビット／秒の１００ＢＡＳＥ−Ｔ仕様のものを使用するのがよい。なお、以下の説明は、回線１２がＬＡＮであることを前提に説明するが、本発明は回線の種類はＬＡＮに限定されない。つまり、分離された複数の教室同士を接続した広域ネットワーク（ＷＡＮ）であってもよい。

楽音波形のサンプリング周波数を４４．１ｋＨｚ、サンプル精度を１８ビット×２（ステレオを考慮する）、演奏端末数ｎを４８として、楽音データ送出による情報量Ｓは、４４１００×１８×２×４８＝７６，２０４，８００（ビット／秒）となる。この情報量Ｓにアドレスやヘッダなどのオーバヘッドを例えば３０％見込んでも回線１２上に送出されるデータ量は９９，０６６，２４０ビット／秒となり、１００ＢＡＳＥ−Ｔ仕様の回線１２の許容能力を上回らない。なお、演奏端末２からの演奏データ送出による情報量は、楽音データ送出による情報量と比べて桁違いに小さいので計算上無視できる。

図２は制御部７の構成を示すブロック図である。制御部７は、ＣＰＵ１３、ＲＯＭ１４、ＲＡＭ１５、デジタルシグナルプロセッサ（ＤＳＰ）１６、および入出力インタフェース（ＳＩＯ）１７を有する。これらＣＰＵ１３、ＲＯＭ１４、ＲＡＭ１５、ＤＳＰ１６およびＳＩＯ１７はバス１８を介して接続される。ＣＰＵ１３には、鍵盤３、操作パネル４、および音源５が接続され、音源５はＤＳＰ１６に接続される。制御部７はＳＩＯ１７を通じて回線１２と接続される。ＲＯＭ１４には音源５で使用する波形データやパラメータが予め格納される。

演奏端末２の制御部１１も、音源５との接続並びにＲＯＭ１４に保持するデータの違いを除いて制御部７と同様に構成される。制御部７，１１ではインタネットプロトコル（ＩＰ）を使用してデータを送受する。

図３は、ＩＰパケットの構造例を示す図である。パケット１９は、イーサネット（登録商標）ヘッダ、ＩＰヘッダ、ＭＩＤＩ／ＰＣＭヘッダ、ＭＩＤＩ／ＰＣＭボディ、イーサネット（登録商標）トレーラを含む。ＩＰヘッダの内容およびその役割を図４に示す。

図５は、楽音発生端末１のメインルーチンを示すフローチャートである。ステップＳ１では、各種レジスタ、カウンタ、フラグなどの初期化を行う。ステップＳ２では、鍵盤３の操作（鍵盤イベント）や操作パネル４の操作（パネルイベント）等、イベントの有無を判別する。パネルイベントの有無は、操作パネル４に備えられるスイッチやボリューム類の状態の監視動作によって判別される。鍵盤イベントの有無判別は、鍵盤３の各鍵毎に設けられるキーセンサの出力監視動作によって行われ、各鍵毎に押鍵・離鍵の有無、ならびにベロシティが検出される。なんらかのイベントが検出されれば、ステップＳ３で、そのイベントに対応する処理が実行される。イベント処理が終われば、ステップＳ４でタイマ処理が行われる。

図６は、イベント処理のフローチャートである。ステップＳ１０では、本体イベントか否か、つまり楽音発生端末１側で生じたイベントか、演奏端末２で生じたイベントかが判別される。本体イベントならば、ステップＳ１１で発音のための通常の処理を行う。例えば、鍵盤イベントの押鍵か離鍵かによって発音または消音のための処理が行われる。なお、鍵盤イベントに従って、通常の発音とともに、予定の伴奏データによる自動伴奏を行うようにしてもよい。本体イベントでない場合は、ステップＳ１２に進んで通信処理を行う。

図７は、通信処理のフローチャートである。ステップＳ２０では、パケットが自局宛てかどうか、つまりパケットの宛先アドレスＴＡＤＤが楽音発生端末１のアドレスか否かを判別する。自局宛てならば、ステップＳ２１に進んで受信パケットからＭＩＤＩデータを取り出す。ステップＳ２２では、このＭＩＤＩデータに基づいて楽音データを作成する。

ステップＳ２０が否定（自局アドレスでない）ならば、ステップＳ２３に進んで広域通信か否か、つまり楽音発生端末１がアドレスを割り当てた演奏端末２からの通信か、それ以外からの通信かを判断する。広域通信でないならば、この処理はスルーし、広域通信ならば、各演奏端末の立ち上げ時もしくは新たに演奏端末が発生した場合であり、ステップＳ２４に進んでその演奏端末にアドレスを割り当てる。ステップＳ２５では、ステップＳ２４で割り当てたアドレスを回線１２に送出する。

図８は、タイマ処理のフローチャートである。ステップＳ３０では、楽音データの有無が判断される。ステップＳ２２で楽音データが作成された場合は、この判断は肯定であり、ステップＳ３１に進んでこの楽音データを送信するためにパケットを作成する。ステップＳ３２では、作成されたパケットを回線１２に送出する。

続いて、演奏端末２の処理を説明する。演奏端末２のメインフローチャートは楽音発生端末１のもの（図５）と同様であるので省略し、メインフローチャートの各ステップの具体的な処理のみを説明する。

図９は、演奏端末２の初期化のフローチャートである。この初期化の処理は演奏端末２の立ち上げ時に毎回行われる。ステップＳ４０では、パケットを格納するパケット・バッファをクリアする。ステップＳ４１では楽音発生端末１にアドレスを要求する。前記ステップＳ２４では、このアドレス要求に対応する処理である。ステップＳ４２では、その他のパラメータ等を初期化する。

図１０は、演奏端末２におけるイベント処理のフローチャートである。ステップＳ５０では、パケット受信か否かを判断する。パケットを受信したのであれば、ステップＳ５１に進んでパケット処理（後述）を行う。

パケットを受信したのでないならば、ステップＳ５２に進んで鍵盤イベントか否かを判断する。鍵盤イベントであれば、ステップＳ５３に進んで鍵処理（後述）を行う。鍵盤イベントでなければステップＳ５４に進んでパネルイベントか否かを判断する。パネルイベントであれば、ステップＳ５５に進んでパネル処理を行う。パネル処理では、例えば音色データやエクスプレッション等の制御データを制御パケットデータとして作成し、パケット・バッファに書き込む。パネルイベントでなければステップＳ５６に進んでその他のイベントか否かを判断し、その他のイベントであればステップＳ５７で予定されたその他の処理を行う。

図１１は、パケット処理のフローチャートである。ステップＳ６０では、アドレス受信か否かを判断する。アドレスを受信したのであれば、ステップＳ６１に進み、受信したアドレスをＲＡＭ１５上の所定の記憶領域に書き込むアドレス処理を行う。アドレス受信でなければ、ステップＳ６０からステップＳ６２に進んで楽音データの受信か否かを判断する。楽音データを受信したのであれば、ステップＳ６３に進んで楽音発生のための楽音処理を行う。楽音処理では、パケットを分解してＭＩＤＩ／ＰＣＭボディからＰＣＭデータを取り出し、ＲＡＭ１５のバッファに蓄積する。このバッファに蓄積されたＰＣＭデータはサウンドシステム６のＤ／Ａ変換器６１および増幅器６２を介してスピーカ６３に入力され、発音に供される。

図１２は、鍵処理のフローチャートである。ステップＳ７０では、押鍵か否かが判別され、押鍵であればステップＳ７１に進んで押鍵パケットデータを生成する。つまり押鍵された鍵のキーナンバおよびベロシティをパケットのデータフィールドに書き込むためにパケット・バッファに格納する。押鍵でなければ、ステップＳ７２に進んで離鍵か否かが判別され、離鍵であればステップＳ７３に進んで離鍵パケットデータを生成する。離鍵パケットデータは押鍵パケットデータと同様、パケット・バッファに格納される。

図１３は、パケット送信処理のフローチャートである。この処理はタイマ処理として予定の割り込み時間毎に行われる。ステップＳ８０では、パケット・バッファ内のデータ有無を判断する。パケット・バッファ内にデータがあればステップＳ８１に進んでパケットを作成する。つまり押鍵パケットデータ、離鍵パケットデータ、および制御パケットデータにヘッダやトレーラ等を付加してパケットを完成させる。ステップＳ８２では、このパケットを回線１２に送出する。

次に、上記レッスンシステムによる具体的なレッスンの例を説明する。図１４は、教師が使用する楽音発生端末１の操作パネル４の要部を示す図である。この操作パネル４の要部は、生徒が使用する演奏端末２の操作パネル９には設けない。ここでは、最大生徒数２４名を想定する。但し、生徒が使用する演奏端末２は、全員が単一の教室に収容されているのに限らず、複数の部屋に分かれて収容されていてもよいし、演奏端末２が個々にブースつまり小部屋に収容されていてもよい。要は、生徒数２４名の使用する演奏端末および楽音発生端末１がＬＡＮまたはＷＡＮの回線１２で互いに接続されていればよい。

操作パネル４には、マイクロフォン（マイク）２０、並びにマイクスイッチ２１、モニタスイッチ２２、合奏スイッチ２３、および自己演奏スイッチ２４が設けられる。各スイッチは最大生徒数分の２４個設けられる。各スイッチ２１〜２４は、オン・オフの切り替えができ、その切り替え位置が目で認識できるものがよい。プッシュスイッチ、トグルスイッチ、タッチスイッチ等、その種類は問わない。

マイク２０から入力された音声は、デジタル化されて楽音データと加算されたうえ、マイクスイッチ２１をオンにしている生徒の演奏端末２に送信される。モニタスイッチ２２は、このスイッチ２２をオンにしている演奏端末２からの演奏データによる発音をモニタするためのものであり、教師はスピーカ６３および図示しないヘッドフォンにより演奏を聞くことができる。

合奏スイッチ２３は、生徒が、自分の演奏と他の生徒の演奏との合奏音を聞くことができるように設けられる。合奏スイッチ２３がオンになっている演奏端末２からの演奏データによって楽音発生端末１で形成された楽音データは互いに加算されて該演奏端末２に送信される。

自己演奏スイッチ２４は、このスイッチ２４をオンにしている演奏端末２からの演奏データのみが有効になって楽音発生端末１で処理されるもので、このスイッチ２４をオンにしていない演奏端末２からの演奏データは無視される。

図１４における各スイッチの状態（黒丸はオン、白丸はオフ）によれば、マイクスイッチ２１は全てオンなので、教師の音声はマイク２０を通して全生徒の演奏端末２に届く。合奏スイッチ２３は２番および４番の演奏端末２のみについてオンになっているので、２番および４番の演奏端末２の生徒は互いに両生徒の演奏を合奏として聞くことができる。また、自己演奏スイッチ２４は全ての演奏端末２を選択しているので、２番および４番の演奏端末の生徒以外の生徒は自分の演奏のみを聞くことができる。したがって、２番および４番のみの合奏を評価したいときに、他の生徒が演奏をしても、その音は２番および４番の生徒の合奏に影響しない。また、モニタスイッチ２２は２番の演奏端末２のみを選択しているので、教師は２番の演奏のみをモニタしている状況である。

図１５は、図１４に示した操作パネル４の要部機能を示すブロック図である。図１５において、Ａ／Ｄ変換器２５が設けられ、マイクスイッチ（ＳＷ１）２１がオンの間、マイク２０からの入力音声信号はこのＡ／Ｄ変換器２５でデジタル変換されて加算器２６に入力される。

自己演奏スイッチ（ＳＷ４）２４で選択されている演奏端末２からの演奏データが回線１２を経由して音源５に入力される。音源５は演奏データに基づいて楽音データを生成する。音源５からは、モニタスイッチ（ＳＷ２）２２がオンになっている演奏端末２の演奏データによる楽音データがモニタ信号Ｍｏｕｔとして出力される。モニタスイッチ（ＳＷ２）２２がオンになっている全ての演奏端末２からの演奏データに基づくモニタ信号Ｍｏｕｔが加算されて前記サウンドシステム６のＤ／Ａ変換器６１に入力される。この加算はＤ／Ａ変換器６１の出力側で行ってもよい。

音源５で生成された楽音データＥｏｕｔは、合奏スイッチ（ＳＷ３）２３を介して合成部２６へ出力される。合成部２６は、合奏スイッチ（ＳＷ３）２３がオンになっている演奏端末２の楽音データを互いに加算（好ましくはデジタル加算）して、合成楽音データＥｉｎを出力する。合成楽音データＥｉｎは、デジタル変換されたマイク２０からの前記入力音声信号に加算器２６で加算されてパケット生成部２８でパケット化され、さらに転送ユニット２９を介して回線１２に送出される。

音源５からの出力はスイッチ（ＳＷ２）２２およびスイッチ（ＳＷ３）２３の状態にかかわらず回線１２に常時送出される。したがって、音源５からのこの出力が加算器２７で合成楽音データＥｉｎに加算されて二重加算になるのを防止するため、減算器３０を介して予め音源５から直接送出される楽音データを除くようにしている。

減算器３０は音源５の出力を常時回線１２に送出するため加算器２７を設けたために必要となるのであり、同様の機能は減算器３０によらずに果たすこともできる。例えば、音源５の出力を合奏スイッチ（ＳＷ３）２３の逆の論理で出力し、合成楽音データＥｉｎをそのまま加算器２７に入力してもよい（図１６参照）。図１６において、スイッチＳＷ３’（スイッチ２３ａ）は合奏スイッチ（ＳＷ３）２３の逆論理スイッチを示す。

図１７は、スイッチ２１〜２４の、他の状態を示す図である。この図のスイッチの状態によれば、合奏スイッチ２３は全ての生徒の分がオンになっているので、全ての生徒は楽音データを受け取って再生できる。しかし、自己演奏スイッチ２４は２番と４番の生徒の分しかオンになっていないので、演奏データはこれら２番および４番の生徒の演奏端末２の分しか有効にならない。したがって、これら２番と４番の生徒の演奏が合奏されるだけであり、その他の生徒もこの合奏音を聴けることになる。自己演奏スイッチ２４の機能により、いたずらや誤りによって２番および４番以外の生徒が演奏してもそれは無視され、合奏に反映されないという効果がある。

なお、操作パネル４上のスイッチの構成は上記実施例に限定されない。例えば、合奏スイッチ２３は省略してもよい。また、合奏スイッチ２３を省略するとともに、合奏および独奏の選択スイッチを一つ設け、この選択スイッチによって合奏か独奏かを選択できるようにする。この場合、合奏端末として選択された演奏端末のみが自らの演奏を含む合奏音を聞くことができる。

次に、楽音データの通信エラーを補正する装置について説明する。インタネットプロトコルを使って行われるパケット通信では、データに誤りが含まれることがある。また、パケットが送出順に着信しないこと（遅着）があったり、パケットが着信しないこと（不着）があったりする。

そこで、本実施形態では、パケットの遅着、不着およびデータの誤りに対して次のように対処する。まず、発音タイミングまでに当該パケットが到着しないときには遅着および不着のいずれの場合も不着とみなして、そのタイミング以後に到着してもそのパケットは廃棄する。不着に対してパケットの再送は要求しない。そして、廃棄したパケットに代えて、直前のパケットをループして発音させる。再送を要求しないのは、再送要求に応答してパケットが再送されてくるまで待っていては発音が途切れるからである。

直前のパケットを使用するために、まず、前提として、発音は常に１パケット分遅延させて行う。したがって、不着とみなされた時点で直前のパケットが到着しているが、発音はまだ実行されていない。直前のパケットによる発音を開始するまでに該パケットが到着しなかったら、直前のパケットを自己ループして発音し、不着パケットに代えて発音する。そして、次のパケットが到着したら、ループしている直前のパケットとこの到着パケットとをクロスフェードして発音する。

図を参照して不着時の処理を説明する。図１８は、不着時処理の要部機能を示すブロック図である。なお、この図では、理解の容易のため、パケットとパケットに収容された楽音データは同義として扱う。受信されたパケットは到着順にバッファ３１に蓄積され、パケットは読み出し部３２で到着順に分解されて発音に供するためＤ／Ａ変換器６１に入力される。判別部３３は、発音開始時にその発音に供しているパケットの次のパケットが不着かどうかを判別する。そして、不着のときは後述するように第１演算手段としての第１クロスフェード部３４で楽音データをクロスフェードし、不着パケットに代える。第１クロスフェード部３４で演算された楽音データによる発音開始時に後続パケットが到着していることを判別部３３で判別したときには、後述するように第２クロスフェード部３５で楽音データをクロスフェードし、後続パケットに代える。

図１８の例では、先行パケットｐ［ｊ−１］、現パケットｐ［ｊ］、後続パケットｐ［ｙ］が到着している。現パケットｐ［ｊ］と後続パケットｐ［ｙ］との間に到着するはずのパケットｐ［ｊ＋１］およびｐ［ｊ＋２］が到着していない。

ここで、現パケットｐ［ｊ］が発音処理開始されているものとする。この現パケットｐ［ｊ］による発音開始時にその次のパケットｐ［ｊ＋１］が到着しているか否かが判別部３３で判別される。ここでパケットｐ［ｊ＋１］が到着していないときは、第１クロスフェード部３４によって先行パケットｐ［ｊ−１］および現パケットｐ［ｊ］をクロスフェードさせてパケットｐ［ｘ］を得る。パケットｐ［ｊ］の発音が終わると、クロスフェードして得られたパケットｐ［ｘ］をパケットｐ［ｊ＋１］の楽音データに代えて使用し、楽音を発生させる。

そして、このパケットｐ［ｘ］による発音開始時にパケットｐ［ｊ＋２］が到着しているか否かが判断され、不着時はパケットｐ［ｘ］を再度ループさせる。さらにこのループの開始時に、後続パケットｐ［ｙ］の到着有無を判断する。ここでは、後続パケットｐ［ｙ］が到着しているので、判別部３３は第２クロスフェード部３５によって現在ループ中のパケットｐ［ｘ］および後続パケットｐ［ｙ］をクロスフェードさせ、このクロスフェードされたパケットを後続パケットｐ［ｙ］に代えて使用し、発音させる。このように、楽音データをクロスフェードして代替の楽音データを作成することによって、本来連続していない楽音データを連続性をもったものにする。

図１９は、不着処理つまり発音タイミングまでにパケットが到着しなかったときのクロスフェード処理に係るフローチャートである。ステップＳ９０では、楽音データのパケット内のサンプル番号を示す変数ｉに「０」をセットする。サンプル数つまり変数ｉの最大値はｎである。ステップＳ９１では、不着パケットの直前パケットｐ［ｊ］より一つ前のパケット［ｊ−１］のサンプル番号ｉに対応する振幅として値ａをセットする。ステップＳ９２では、サンプル番号ｉとサンプル数ｎ（例えば「２５６個」）との比の値ｉ／ｎを振幅ａに乗算して新たに振幅ａとしてセットする。ステップＳ９３では、直前パケット［ｊ］のサンプル番号ｉに対応する振幅を示す値ｂとしてセットする。ステップＳ９４では、補数「１−ｉ／ｎ］を振幅ｂに乗算して新たに振幅ｂとしてセットする。ステップＳ９５では、クロスフェードされたパケットｐ’のサンプル番号ｉの振幅として「ａ＋ｂ」をセットする。ステップＳ９６では、サンプル番号ｉを更新（＋１）してその値ｉがサンプル数ｎに等しいか否かによってｎ個のサンプルを処理したかどうかが判断される。サンプル番号ｉがサンプル数ｎと等しくなるまでステップＳ９１に進み、サンプル番号ｉがサンプル数ｎと等しくなればステップＳ９７に進んで、クロスフェードモードであることを示すフラグｘｆｍｏｄｅに「１」をセットする。フラグｘｆｍｏｄｅの初期値は「０」である。

図２０は、パケットを受信したときの受信処理のフローチャートである。ステップＳ１００では、受信したパケットが、不着とみなされて廃棄されたのものかどうかを判断する。廃棄されたものであれば、このフローチャートはスルーされる。ステップＳ１０１では、フラグｘｆｍｏｄｅが判別される。フラグｘｆｍｏｄｅが「０」ならば、正常な受信であると判断してステップＳ１０２に進み、パリティエラーの有無を判断する。パリティエラーが発生しているときは、ステップＳ１０３で、エラーのあるサンプルの直前および直後のサンプル間で補間値をとり、その補間値をエラーのあるサンプルに代えて使用する。そして、ステップＳ１０４に進む。ステップＳ１０３のサンプル補間は、エラーのあるデータの前後のパリティエラーがないときは省略される。ステップＳ１０４では、受信したパケットを保存する。ステップＳ１０１でフラグｘｆｍｏｄｅが「１」と判別されたときは、ステップＳ１０５に進み、復帰処理のために受信したパケットを復帰処理部に転送する。

図２１は、発音処理のフローチャートである。ステップＳ１１０では、発音すべきパケットの有無を判別して、パケットがある場合はステップＳ１１１に進む。ステップＳ１１１では、次のパケットが到着しているか否かを判断する。次のパケットも到着している場合は、ステップＳ１１２に進んでフラグｘｆｍｏｄｅを判別する。フラグｘｆｍｏｄｅが「１」であれば、ステップＳ１１３に進んで次のパケットの復帰処理を行ってステップＳ１１４に進み、復帰処理が行われたパケットの楽音データを、発音のためＤ／Ａ変換器６１に転送する。フラグｘｆｍｏｄｅが「０」であれば、ステップＳ１１３の復帰処理をスキップしてステップＳ１１４に進み、先頭パケットの楽音データを、発音のためＤ／Ａ変換器６１に転送する。

次のパケットが到着していないときは、ステップＳ１１１からステップＳ１１５に進む。ステップＳ１１５では、不着イベントとして、不着処理でクロスフェードされたパケットを読み出す。ステップＳ１１４では、ステップＳ１１５で読み出されたパケットの楽音データを発音のためＤ／Ａ変換器６１に転送する。

図２２は、復帰処理のフローチャートである。ステップＳ１２０では、楽音データのパケット内のサンプル番号を示す変数ｉに「０」をセットする。サンプル数つまり変数ｉの最大値はｎである。ステップＳ１２１では、ループしているパケットｐ［ｘ］のサンプル番号ｉに対応する振幅として値ａをセットする。ステップＳ１２２では、サンプル番号ｉとサンプル数ｎ（例えば「２５６個」）との比の値ｉ／ｎを振幅ａに乗算して新たに振幅ａとしてセットする。ステップＳ１２３では、到着パケット［ｙ］のサンプル番号ｉに対応する振幅を示す値ｂとしてセットする。ステップＳ１２４では、補数「１−ｉ／ｎ］を振幅ｂに乗算して新たに振幅ｂとしてセットする。ステップＳ１２５では、クロスフェードされたパケットｐ’のサンプル番号ｉの振幅として「ａ＋ｂ」をセットする。ステップＳ１２６では、サンプル番号ｉを更新（＋１）してその値ｉがサンプル数ｎに等しいか否かによってｎ個のサンプルを処理したかどうかが判断される。サンプル番号ｉがサンプル数ｎと等しくなるまでステップＳ１２１に進み、サンプル番号ｉがサンプル数ｎと等しくなればステップＳ１２７に進んで、クロスフェードモードが終了したことを示すためフラグｘｆｍｏｄｅに「０」をセットする。

なお、パリティエラーのあったサンプルを、直前のサンプルと直後のサンプルとの間の補間値に置き換えるのに代えて、次のように処置をしてもよい。例えば、誤りのあったパケットを廃棄する。また、誤りの個数が予定値以下ならば、補間値を使うようにし、誤りの個数が予定値以上ならばパケットを廃棄するようにして両者を使い分けることもできる。さらに、パリティデータの量を増やして、誤りデータを論理的に回復するようにしてもよい。

以上、本発明を最良の実施形態に従って説明したが、本発明はこれに限定されない。例えば、楽音発生端末から操作パネルや鍵盤を除いてもよい。要は、演奏データを作成して送出できる演奏端末からネットワークを経由して送出した演奏端末に基づいて作成された楽音データがネットワークを経由して同じ演奏端末で受信・発音できればよい。

本発明の一実施形態に係る電子楽器演奏システムのブロック図である。 本発明の一実施形態に係るシステムの端末に含まれる制御部のブロック図である。 ＩＰパケットの構造例を示す図である。 ＩＰヘッダの内容およびその意味を示す図である。 楽音発生端末のメインフローチャートである。 イベント処理のフローチャートである。 通信処理のフローチャートである。 タイマ処理のフローチャートである。 演奏端末における初期化のフローチャートである。 演奏端末におけるイベント処理のフローチャートである。 パケット処理のフローチャートである。 鍵処理のフローチャートである。 パケット送信処理のフローチャートである。 楽音発生端末の操作パネル４の要部を示す図である。 操作パネルの要部機能を示すブロック図である。 変形例に係る操作パネルの要部機能を示すブロック図である。 操作パネル上のスイッチの状態を示す図である。 不着時処理の要部機能を示すブロック図である。 発音タイミングまでにパケットが到着しなかったときのクロスフェード処理に係るフローチャートである。 パケットの受信処理のフローチャートである。 発音処理のフローチャートである。 復帰処理のフローチャートである。

符号の説明

１…楽音発生端末、 ２…演奏端末鍵盤、 ４，９…操作パネル、 ５…音源、 ６、１０…サウンドシステム、 ７，１１…制御部、 １２…ＬＡＮ、 ２０…マイクロフォン、 ２１…マイクスイッチ、 ２２…モニタスイッチ、 ２３…合奏スイッチ、 ２４…自己演奏スイッチ、 ３１…バッファ、 ３３…判別部、 ３４…第１クロスフェード部、 ３５…第２クロスフェード部

Claims (5)

1. 演奏データを作成し、ネットワークを経由して前記演奏データを楽音発生端末に送信する手段、前記演奏データに基づいて前記楽音発生端末で作成された楽音データをネットワークを経由して受信する手段、および受信した楽音データに従って発音するサウンドシステムを有する複数の演奏端末と、
   前記演奏端末から送信された演奏データを受信する手段、および該演奏データに基づいて楽音データを作成してネットワークを経由して該演奏端末に送信する手段を有する楽音発生端末とを備え、
   前記楽音データがパケット通信によってネットワーク上に送出されるとともに、
   前記演奏端末が、
   受信した前記パケットの誤りを検出する誤り検出手段と、
   前記誤り検出手段で検出された誤りを補正する補正手段とを備えたことを特徴とする電子楽器演奏システム。
2. 前記誤り検出手段が、前記楽音データとともに送出されたパリティデータの検査によって誤りを検出するものであることを特徴とする請求項１記載の電子楽器演奏システム。
3. 前記誤り検出手段が、パケットの遅着および不着を誤りとして検出するものであることを特徴とする請求項１記載の電子楽器演奏システム。
4. 前記補正手段が、
   前記サウンドシステムによる発音を、少なくとも楽音データの１パケット分遅延させる手段と、
   前記誤りが検出されたときに、誤りが検出されたパケットに先行するパケットの楽音データをループさせて、誤りが検出されたパケットの楽音データに代えるループ手段とを備えたことを特徴とする請求項３記載の電子楽器演奏システム。
5. 前記ループさせる楽音データを、該楽音データを収容したパケットに先行するパケットの楽音データとクロスフェードさせる第１演算手段と、
   前記ループさせる楽音データを、該楽音データを収容したパケットの後続パケットの楽音データとクロスフェードさせる第２演算手段とを備え、
   前記ループ中は、前記第１演算手段でクロスフェードされた楽音データに従って発音し、前記ループ終了後は第２演算手段でクロスフェードされた楽音データに従って発音するように構成されたことを特徴とする請求項４記載の電子楽器演奏システム。

Images