電子楽器演奏システムの楽音発生端末および演奏端末
【課題】楽音発生端末から演奏端末へ宛先アドレスを自動的に割り当てる。
【解決手段】楽音発生端末1はネットワーク12を経由して演奏端末2から受信した演奏データに基づいて楽音データを作成し、ネットワーク12を経由して演奏端末2に送信する。演奏端末2は、立ち上げ時に、広域アドレスを用いてアドレス要求をネットワーク12に送信する。楽音発生端末1は宛先として広域アドレスを受信した場合、その広域アドレスを送信した演奏端末2に対してアドレスを割り当てるためネットワーク12にアドレスを送出する。演奏端末2はアドレス要求に応じてネットワークに送出されたアドレスを宛先アドレスとして演奏データをネットワークに送出する。
【解決手段】楽音発生端末1はネットワーク12を経由して演奏端末2から受信した演奏データに基づいて楽音データを作成し、ネットワーク12を経由して演奏端末2に送信する。演奏端末2は、立ち上げ時に、広域アドレスを用いてアドレス要求をネットワーク12に送信する。楽音発生端末1は宛先として広域アドレスを受信した場合、その広域アドレスを送信した演奏端末2に対してアドレスを割り当てるためネットワーク12にアドレスを送出する。演奏端末2はアドレス要求に応じてネットワークに送出されたアドレスを宛先アドレスとして演奏データをネットワークに送出する。
【発明の詳細な説明】
【技術分野】
【0001】
本発明は、電子楽器演奏システムに関し、特に、電子楽器演奏システムに含まれる楽音データ発生端末と複数の演奏データ発生端末に関する。
【背景技術】
【0002】
複数の楽器をMIDIケーブルを用いて接続する方法が知られる。MIDIでは、基本的に1対1の接続しか考慮されていないため、複数台の電子楽器を接続する場合は接続数に応じたMIDIケーブルを必要とする。また、電子楽器には限定された数のMIDI端子しか設けられていないので、接続される電子楽器の台数はあまり多くできない。例えば、MIDIチャネルが16チャネルであることから、同時に17台以上の電子楽器を相互に接続することはできない。さらに、MIDI規格では通信速度が演奏情報を転送するように決定されており、それ以上の高速転送は困難である。
【0003】
一方、特許文献1において、上記MIDIによる接続の問題点を解消するシステムとして、LANを経由して複数の電子楽器局、操作子局、音源局、およびシーケンサ局を互いに接続したシステムが提案されている。
【先行技術文献】
【特許文献】
【0004】
【特許文献1】特開平6−252928号公報
【発明の概要】
【発明が解決しようとする課題】
【0005】
上記特許文献1に開示された従来技術のようにLANを経由して複数の電子楽器等を互いに接続したシステムでは、例えば、操作子局から送出されるリアルタイム演奏データに基づいて電子楽器局で楽音を発生させたり、リアルタイム演奏データに基づいて音源局で楽音を合成して電子楽器で楽音を発生させたりするように構成することが考えられる。
【0006】
しかし、従来技術では、他端末で発生した楽音データによって自端末で発音することはできるが、演奏データを送出した演奏端末が、その演奏データに基づいて他端末で発生された楽音データによってリアルタイムで楽音を発生するということはできなかった。すなわち、演奏端末間で音源を共有しているものではなかった。
【0007】
例えば、学校や音楽教室等で複数の電子鍵盤楽器をLANを経由して接続してレッスンをしたり合奏をしたりする場合、複数の生徒が操作子としての鍵盤装置を持つだけではこれらの生徒は自分の演奏音を聞くことができない。各自が自己の演奏音をモニタするためには、全ての生徒が鍵盤装置とともに楽音データを生成する音源を備えた電子鍵盤楽器をそれぞれ持たなければならない。また、自己の演奏音だけでなく他の生徒との合奏音を聞きたいという要望もある。そのために、大勢の生徒が簡易な鍵盤装置などの演奏端末を使って同時に電子楽器のレッスンを行うことができるシステムが望まれる。
【0008】
本発明は、上記課題に鑑み、音源を重複して設けるという無駄を省きつつ、複数の演奏者による演奏を可能にする電子楽器演奏システムに含まれる楽音発生端末および演奏端末を提供することを目的とする。
【課題を解決するための手段】
【0009】
上記の課題を解決し、目的を達成するための本発明は、ネットワークを経由して演奏端末から演奏データを受信し、該演奏データに基づく楽音データを発生し、該楽音データを、前記ネットワークを経由して前記演奏端末に送信する楽音発生端末において、前記演奏端末から送信された宛先アドレスを受信する受信手段と、前記受信手段が受信した宛先アドレスが個別の送信先を示さない広域アドレスかどうかを検出する検出手段と、前記検出手段が検出した広域アドレスを送信した演奏端末に対してアドレスを割り当てる割り当て手段と、前記割り当て手段が割り当てたアドレスを前記ネットワークに送出する送出手段とを備えている楽音発生端末である点に第1の特徴がある。
【0010】
また、本発明は、ネットワークを経由して演奏者による演奏データを楽音発生端末に送信し、前記ネットワークを経由して前記演奏データに基づいて前記楽音発生端末で発生された楽音データを受信して発音する演奏端末において、前記演奏端末の立ち上げ時に、個別に送信先を示さない広域アドレスを用いてアドレス要求を前記ネットワークに送信する送信手段と、前記アドレス要求に応じてネットワークに送出されたアドレスを受信する受信手段と、前記受信したアドレスを宛先アドレスとして前記演奏データを前記ネットワークに送出する送出手段とを備えている演奏端末である点に第2の特徴がある。
【発明の効果】
【0011】
上記第1および第2の特徴を有する本発明によれば、演奏端末と楽音発生端末とをネットワークを介して接続している電子楽器演奏システムにおいて、演奏端末の立ち上げ時に、演奏端末が立ち上げた広域通信に応答して楽音発生端末から演奏端末に宛先アドレスとしてのアドレスを自動的に割り当てることができる。
【図面の簡単な説明】
【0012】
【図1】本発明の一実施形態に係る電子楽器演奏システムのブロック図である。
【図2】本発明の一実施形態に係るシステムの端末に含まれる制御部のブロック図である。
【図3】IPパケットの構造例を示す図である。
【図4】IPヘッダの内容およびその意味を示す図である。
【図5】楽音発生端末のメインフローチャートである。
【図6】イベント処理のフローチャートである。
【図7】通信処理のフローチャートである。
【図8】タイマ処理のフローチャートである。
【図9】演奏端末における初期化のフローチャートである。
【図10】演奏端末におけるイベント処理のフローチャートである。
【図11】パケット処理のフローチャートである。
【図12】鍵処理のフローチャートである。
【図13】パケット送信処理のフローチャートである。
【図14】楽音発生端末の操作パネル4の要部を示す図である。
【図15】操作パネルの要部機能を示すブロック図である。
【図16】変形例に係る操作パネルの要部機能を示すブロック図である。
【図17】操作パネル上のスイッチの状態を示す図である。
【図18】不着時処理の要部機能を示すブロック図である。
【図19】発音タイミングまでにパケットが到着しなかったときのクロスフェード処理に係るフローチャートである。
【図20】パケットの受信処理のフローチャートである。
【図21】発音処理のフローチャートである。
【図22】復帰処理のフローチャートである。
【発明を実施するための形態】
【0013】
以下、図面を参照して本発明を詳細に説明する。図1は本発明の一実施形態に係る電子楽器演奏システムのブロック図である。同図において、この演奏システムは、例えば、複数の生徒のための電子楽器のレッスンシステムである。この演奏システムは、教師が使用する楽音データ発生端末(以下、「楽音発生端末」という)1と生徒が使用する複数の演奏データ発生端末(以下、「演奏端末」という)2とからなる。
【0014】
楽音発生端末1は、鍵盤3、操作パネル4、音源(TG)5、サウンドシステム6、および制御部7を備える。鍵盤3は押鍵・離鍵を検出して演奏データ(キーナンバおよびベロシティを含む)を演奏者の演奏に応じてリアルタイムに出力する図示しないキーセンサを備える。操作パネル4は各種指示入力のためのスイッチや液晶パネル等の表示画面を有する。音源5は複数設けられ、演奏データに基づいて楽音データを発生する。サウンドシステム6は楽音データのD/A変換器(DAC)61、増幅器(AMP)62およびスピーカ(SP)63を備える。ヘッドフォン端子を設けて増幅器62の出力をスピーカ63だけでなくヘッドフォン端子(図示しない)にも供給できるようにする。
【0015】
演奏端末2は、鍵盤8、操作パネル9、サウンドシステム10、および制御部11を備える。演奏端末2は、音源5並びに音源5で使用する波形データやパラメータを保持していない点で楽音発生端末1と異なる。また、楽音発生端末1の操作パネル4には、演奏端末2の操作パネル9にないスイッチ(後述)を設ける。なお、楽音発生端末1には、必ずしも鍵盤3を設けなくてもよい。
【0016】
楽音発生端末1および演奏端末2の制御部7,11は、回線12に接続される。回線12は、IEEE802.3標準のLANつまりイーサネット(登録商標)で、伝送速度100メガビット/秒の100BASE−T仕様のものを使用するのがよい。なお、以下の説明は、回線12がLANであることを前提に説明するが、本発明は回線の種類はLANに限定されない。つまり、分離された複数の教室同士を接続した広域ネットワーク(WAN)であってもよい。
【0017】
楽音波形のサンプリング周波数を44.1kHz、サンプル精度を18ビット×2(ステレオを考慮する)、演奏端末数nを48として、楽音データ送出による情報量Sは、44100×18×2×48=76,204,800(ビット/秒)となる。この情報量Sにアドレスやヘッダなどのオーバヘッドを例えば30%見込んでも回線12上に送出されるデータ量は99,066,240ビット/秒となり、100BASE−T仕様の回線12の許容能力を上回らない。なお、演奏端末2からの演奏データ送出による情報量は、楽音データ送出による情報量と比べて桁違いに小さいので計算上無視できる。
【0018】
図2は制御部7の構成を示すブロック図である。制御部7は、CPU13、ROM14、RAM15、デジタルシグナルプロセッサ(DSP)16、および入出力インタフェース(SIO)17を有する。これらCPU13、ROM14、RAM15、DSP16およびSIO17はバス18を介して接続される。CPU13には、鍵盤3、操作パネル4、および音源5が接続され、音源5はDSP16に接続される。制御部7はSIO17を通じて回線12と接続される。ROM14には音源5で使用する波形データやパラメータが予め格納される。
【0019】
演奏端末2の制御部11も、音源5との接続並びにROM14に保持するデータの違いを除いて制御部7と同様に構成される。制御部7,11ではインタネットプロトコル(IP)を使用してデータを送受する。
【0020】
図3は、IPパケットの構造例を示す図である。パケット19は、イーサネット(登録商標)ヘッダ、IPヘッダ、MIDI/PCMヘッダ、MIDI/PCMボディ、イーサネット(登録商標)トレーラを含む。IPヘッダの内容およびその役割を図4に示す。
【0021】
図5は、楽音発生端末1のメインルーチンを示すフローチャートである。ステップS1では、各種レジスタ、カウンタ、フラグなどの初期化を行う。ステップS2では、鍵盤3の操作(鍵盤イベント)や操作パネル4の操作(パネルイベント)等、イベントの有無を判別する。パネルイベントの有無は、操作パネル4に備えられるスイッチやボリューム類の状態の監視動作によって判別される。鍵盤イベントの有無判別は、鍵盤3の各鍵毎に設けられるキーセンサの出力監視動作によって行われ、各鍵毎に押鍵・離鍵の有無、ならびにベロシティが検出される。なんらかのイベントが検出されれば、ステップS3で、そのイベントに対応する処理が実行される。イベント処理が終われば、ステップS4でタイマ処理が行われる。
【0022】
図6は、イベント処理のフローチャートである。ステップS10では、本体イベントか否か、つまり楽音発生端末1側で生じたイベントか、演奏端末2で生じたイベントかが判別される。本体イベントならば、ステップS11で発音のための通常の処理を行う。例えば、鍵盤イベントの押鍵か離鍵かによって発音または消音のための処理が行われる。なお、鍵盤イベントに従って、通常の発音とともに、予定の伴奏データによる自動伴奏を行うようにしてもよい。本体イベントでない場合は、ステップS12に進んで通信処理を行う。
【0023】
図7は、通信処理のフローチャートである。ステップS20では、パケットが自局宛てかどうか、つまりパケットの宛先アドレスTADDが楽音発生端末1のアドレスか否かを判別する。自局宛てならば、ステップS21に進んで受信パケットからMIDIデータを取り出す。ステップS22では、このMIDIデータに基づいて楽音データを作成する。
【0024】
ステップS20が否定(自局アドレスでない)ならば、ステップS23に進んで広域通信か否か、つまり楽音発生端末1がアドレスを割り当てた演奏端末2からの通信か、それ以外からの通信かを判断する。広域通信でないならば、この処理はスルーし、広域通信ならば、各演奏端末の立ち上げ時もしくは新たに演奏端末が発生した場合であり、ステップS24に進んでその演奏端末にアドレスを割り当てる。ステップS25では、ステップS24で割り当てたアドレスを回線12に送出する。
【0025】
図8は、タイマ処理のフローチャートである。ステップS30では、楽音データの有無が判断される。ステップS22で楽音データが作成された場合は、この判断は肯定であり、ステップS31に進んでこの楽音データを送信するためにパケットを作成する。ステップS32では、作成されたパケットを回線12に送出する。
【0026】
続いて、演奏端末2の処理を説明する。演奏端末2のメインフローチャートは楽音発生端末1のものと同様であるので省略し、メインフローチャートの各ステップの具体的な処理のみを説明する。
【0027】
図9は、演奏端末2の初期化のフローチャートである。この初期化の処理は演奏端末2の立ち上げ時に毎回行われる。ステップS40では、パケットを格納するパケット・バッファをクリアする。ステップS41では楽音発生端末1にアドレスを要求する。前記ステップS24は、このアドレス要求に対応する処理である。ステップS42では、その他のパラメータ等を初期化する。
【0028】
図10、演奏端末2におけるイベント処理のフローチャートである。ステップS50では、パケット受信か否かを判断する。パケットを受信したのであれば、ステップS51に進んでパケット処理(後述)を行う。
【0029】
パケットを受信したのでないならば、ステップS52に進んで鍵盤イベントか否かを判断する。鍵盤イベントであれば、ステップS53に進んで鍵処理(後述)を行う。鍵盤イベントでなければステップS54に進んでパネルイベントか否かを判断する。パネルイベントであれば、ステップS55に進んでパネル処理を行う。パネル処理では、例えば音色データやエクスプレッション等の制御データを制御パケットデータとして作成し、パケット・バッファに書き込む。パネルイベントでなければステップS56に進んでその他のイベントか否かを判断し、その他のイベントであればステップS57で予定されたその他の処理を行う。
【0030】
図11は、パケット処理のフローチャートである。ステップS60では、アドレス受信か否かを判断する。アドレスを受信したのであれば、ステップS61に進み、受信したアドレスをRAM15上の所定の記憶領域に書き込むアドレス処理を行う。アドレス受信でなければ、ステップS60からステップS62に進んで楽音データの受信か否かを判断する。楽音データを受信したのであれば、ステップS63に進んで楽音発生のための楽音処理を行う。楽音処理では、パケットを分解してMIDI/PCMボディからPCMデータを取り出し、RAM15のバッファに蓄積する。このバッファに蓄積されたPCMデータはサウンドシステム6のD/A変換器61および増幅器62を介してスピーカ63に入力され、発音に供される。
【0031】
図12は、鍵処理のフローチャートである。ステップS70では、押鍵か否かが判別され、押鍵であればステップS71に進んで押鍵パケットデータを生成する。つまり押鍵された鍵のキーナンバおよびベロシティをパケットのデータフィールドに書き込むためにパケット・バッファに格納する。押鍵でなければ、ステップS72に進んで離鍵か否かが判別され、離鍵であればステップS73に進んで離鍵パケットデータを生成する。離鍵パケットデータは押鍵パケットデータと同様、パケット・バッファに格納される。
【0032】
図13は、パケット送信処理のフローチャートである。この処理はタイマ処理として予定の割り込み時間毎に行われる。ステップS80では、パケット・バッファ内のデータ有無を判断する。パケット・バッファ内にデータがあればステップS81に進んでパケットを作成する。つまり押鍵パケットデータ、離鍵パケットデータ、および制御パケットデータにヘッダやトレーラ等を付加してパケットを完成させる。ステップS82では、このパケットを回線12に送出する。
【0033】
次に、上記レッスンシステムによる具体的なレッスンの例を説明する。図14は、教師が使用する楽音発生端末1の操作パネル4の要部を示す図である。この操作パネル4の要部は、生徒が使用する演奏端末2の操作パネル9には設けない。ここでは、最大生徒数24名を想定する。但し、生徒が使用する演奏端末2は、全員が単一の教室に収容されているのに限らず、複数の部屋に分かれて収容されていてもよいし、演奏端末2が個々にブースつまり小部屋に収容されていてもよい。要は、生徒数24名の使用する演奏端末および楽音発生端末1がLANまたはWANの回線12で互いに接続されていればよい。
【0034】
操作パネル4には、マイクロフォン(マイク)20、並びにマイクスイッチ21、モニタスイッチ22、合奏スイッチ23、および自己演奏スイッチ24が設けられる。各スイッチは最大生徒数分の24個設けられる。各スイッチ21〜24は、オン・オフの切り替えができ、その切り替え位置が目で認識できるものがよい。プッシュスイッチ、トグルスイッチ、タッチスイッチ等、その種類は問わない。
【0035】
マイク20から入力された音声は、デジタル化されて楽音データと加算されたうえ、マイクスイッチ21をオンにしている生徒の演奏端末2に送信される。モニタスイッチ22は、このスイッチ22をオンにしている演奏端末2からの演奏データによる発音をモニタするためのものであり、教師はスピーカ63および図示しないヘッドフォンにより演奏を聞くことができる。
【0036】
合奏スイッチ23は、生徒が、自分の演奏と他の生徒の演奏との合奏音を聞くことができるように設けられる。合奏スイッチ23がオンになっている演奏端末2からの演奏データによって楽音発生端末1で形成された楽音データは互いに加算されて該演奏端末2に送信される。
【0037】
自己演奏スイッチ24は、このスイッチ24をオンにしている演奏端末2からの演奏データのみが有効になって楽音発生端末1で処理されるもので、このスイッチ24をオンにしていない演奏端末2からの演奏データは無視される。
【0038】
図14における各スイッチの状態(黒丸はオン、白丸はオフ)によれば、マイクスイッチ21は全てオンなので、教師の音声はマイク20を通して全生徒の演奏端末2に届く。合奏スイッチ23は2番および4番の演奏端末2のみについてオンになっているので、2番および4番の演奏端末2の生徒は互いに両生徒の演奏を合奏として聞くことができる。また、自己演奏スイッチ24は全ての演奏端末2を選択しているので、2番および4番の演奏端末の生徒以外の生徒は自分の演奏のみを聞くことができる。したがって、2番および4番のみの合奏を評価したいときに、他の生徒が演奏をしても、その音は2番および4番の生徒の合奏に影響しない。また、モニタスイッチ22は2番の演奏端末2のみを選択しているので、教師は2番の演奏のみをモニタしている状況である。
【0039】
図15は、図14に示した操作パネル4の要部機能を示すブロック図である。図15において、A/D変換器25が設けられ、マイクスイッチ(SW1)21がオンの間、マイク20からの入力音声信号はこのA/D変換器25でデジタル変換されて加算器26に入力される。
【0040】
自己演奏スイッチ(SW4)24で選択されている演奏端末2からの演奏データが回線12を経由して音源5に入力される。音源5は演奏データに基づいて楽音データを生成する。音源5からは、モニタスイッチ(SW2)22がオンになっている演奏端末2の演奏データによる楽音データがモニタ信号Moutとして出力される。モニタスイッチ(SW2)22がオンになっている全ての演奏端末2からの演奏データに基づくモニタ信号Moutが加算されて前記サウンドシステム6のD/A変換器61に入力される。この加算はD/A変換器61の出力側で行ってもよい。
【0041】
音源5で生成された楽音データEoutは、合奏スイッチ(SW3)23を介して合成部26へ出力される。合成部26は、合奏スイッチ(SW3)23がオンになっている演奏端末2の楽音データを互いに加算(好ましくはデジタル加算)して、合成楽音データEinを出力する。合成楽音データEinは、デジタル変換されたマイク20からの前記入力音声信号に加算器26で加算されてパケット生成部28でパケット化され、さらに転送ユニット29を介して回線12に送出される。
【0042】
音源5からの出力はスイッチ(SW2)22およびスイッチ(SW3)23の状態にかかわらず回線12に常時送出される。したがって、音源5からのこの出力が加算器27で合成楽音データEinに加算されて二重加算になるのを防止するため、減算器30を介して予め音源5から直接送出される楽音データを除くようにしている。
【0043】
減算器30は音源5の出力を常時回線12に送出するため加算器27を設けたために必要となるのであり、同様の機能は減算器30によらずに果たすこともできる。例えば、音源5の出力を合奏スイッチ(SW3)23の逆の論理で出力し、合成楽音データEinをそのまま加算器27に入力してもよい(図16参照)。図16において、スイッチSW3'(スイッチ23a)は合奏スイッチ(SW3)23の逆論理スイッチを示す。
【0044】
図17は、スイッチ21〜24の、他の状態を示す図である。この図のスイッチの状態によれば、合奏スイッチ23は全ての生徒の分がオンになっているので、全ての生徒は楽音データを受け取って再生できる。しかし、自己演奏スイッチ24は2番と4番の生徒の分しかオンになっていないので、演奏データはこれら2番および4番の生徒の演奏端末2の分しか有効にならない。したがって、これら2番と4番の生徒の演奏が合奏されるだけであり、その他の生徒もこの合奏音を聴けることになる。自己演奏スイッチ24の機能により、いたずらや誤りによって2番および4番以外の生徒が演奏してもそれは無視され、合奏に反映されないという効果がある。
【0045】
なお、操作パネル4上のスイッチの構成は上記実施例に限定されない。例えば、合奏スイッチ23は省略してもよい。また、合奏スイッチ23を省略するとともに、合奏および独奏の選択スイッチを一つ設け、この選択スイッチによって合奏か独奏かを選択できるようにする。この場合、合奏端末として選択された演奏端末のみが自らの演奏を含む合奏音を聞くことができる。
【0046】
次に、楽音データの通信エラーを補正する装置について説明する。インタネットプロトコルを使って行われるパケット通信では、データに誤りが含まれることがある。また、パケットが送出順に着信しないこと(遅着)があったり、パケットが着信しないこと(不着)があったりする。
【0047】
そこで、本実施形態では、パケットの遅着、不着およびデータの誤りに対して次のように対処する。まず、発音タイミングまでに当該パケットが到着しないときには遅着および不着のいずれの場合も不着とみなして、そのタイミング以後に到着してもそのパケットは廃棄する。不着に対してパケットの再送は要求しない。そして、廃棄したパケットに代えて、直前のパケットをループして発音させる。再送を要求しないのは、再送要求に応答してパケットが再送されてくるまで待っていては発音が途切れるからである。
【0048】
直前のパケットを使用するために、まず、前提として、発音は常に1パケット分遅延させて行う。したがって、不着とみなされた時点で直前のパケットが到着しているが、発音はまだ実行されていない。直前のパケットによる発音を開始するまでに該パケットが到着しなかったら、直前のパケットを自己ループして発音し、不着パケットに代えて発音する。そして、次のパケットが到着したら、ループしている直前のパケットとこの到着パケットとをクロスフェードして発音する。
【0049】
図を参照して不着時の処理を説明する。図18は、不着時処理の要部機能を示すブロック図である。なお、この図では、理解の容易のため、パケットとパケットに収容された楽音データは同義として扱う。受信されたパケットは到着順にバッファ31に蓄積され、パケットは読み出し部32で到着順に分解されて発音に供するためD/A変換器61に入力される。判別部33は、発音開始時にその発音に供しているパケットの次のパケットが不着かどうかを判別する。そして、不着のときは後述するように第1演算手段としての第1クロスフェード部34で楽音データをクロスフェードし、不着パケットに代える。第1クロスフェード部34で演算された楽音データによる発音開始時に後続パケットが到着していることを判別部33で判別したときには、後述するように第2クロスフェード部35で楽音データをクロスフェードし、後続パケットに代える。
【0050】
図18の例では、先行パケットp[j−1]、現パケットp[j]、後続パケットp[y]が到着している。現パケットp[j]と後続パケットp[y]との間に到着するはずのパケットp[j+1]およびp[j+2]が到着していない。
【0051】
ここで、現パケットp[j]が発音処理開始されているものとする。この現パケットp[j]による発音開始時にその次のパケットp[j+1]が到着しているか否かが判別部33で判別される。ここでパケットp[j+1]が到着していないときは、第1クロスフェード部34によって先行パケットp[j−1]および現パケットp[j]をクロスフェードさせてパケットp[x]を得る。パケットp[j]の発音が終わると、クロスフェードして得られたパケットp[x]をパケットp[j+1]の楽音データに代えて使用し、楽音を発生させる。
【0052】
そして、このパケットp[x]による発音開始時にパケットp[j+2]が到着しているか否かが判断され、不着時はパケットp[x]を再度ループさせる。さらにこのループの開始時に、後続パケットp[y]の到着有無を判断する。ここでは、後続パケットp[y]が到着しているので、判別部33は第2クロスフェード部35によって現在ループ中のパケットp[x]および後続パケットp[y]をクロスフェードさせ、このクロスフェードされたパケットを後続パケットp[y]に代えて使用し、発音させる。このように、楽音データをクロスフェードして代替の楽音データを作成することによって、本来連続していない楽音データを連続性をもったものにする。
【0053】
図19は、不着処理つまり発音タイミングまでにパケットが到着しなかったときのクロスフェード処理に係るフローチャートである。ステップS90では、楽音データのパケット内のサンプル番号を示す変数iに「0」をセットする。サンプル数つまり変数iの最大値はnである。ステップS91では、不着パケットの直前パケットp[j]より一つ前のパケット[j−1]のサンプル番号iに対応する振幅として値aをセットする。ステップS92では、サンプル番号iとサンプル数n(例えば「256個」)との比の値i/nを振幅aに乗算して新たに振幅aとしてセットする。ステップS93では、直前パケット[j]のサンプル番号iに対応する振幅を示す値bとしてセットする。ステップS94では、補数「1−i/n]を振幅bに乗算して新たに振幅bとしてセットする。ステップS95では、クロスフェードされたパケットp'のサンプル番号iの振幅として「a+b」をセットする。ステップS96では、サンプル番号iを更新(+1)してその値iがサンプル数nに等しいか否かによってn個のサンプルを処理したかどうかが判断される。サンプル番号iがサンプル数nと等しくなるまでステップS91に進み、サンプル番号iがサンプル数nと等しくなればステップS97に進んで、クロスフェードモードであることを示すフラグxfmodeに「1」をセットする。フラグxfmodeの初期値は「0」である。
【0054】
図20は、パケットを受信したときの受信処理のフローチャートである。ステップS100では、受信したパケットが、不着とみなされて廃棄されたのものかどうかを判断する。廃棄されたものであれば、このフローチャートはスルーされる。ステップS101では、フラグxfmodeが判別される。フラグxfmodeが「0」ならば、正常な受信であると判断してステップS102に進み、パリティエラーの有無を判断する。パリティエラーが発生しているときは、ステップS103で、エラーのあるサンプルの直前および直後のサンプル間で補間値をとり、その補間値をエラーのあるサンプルに代えて使用する。そして、ステップS104に進む。ステップS103のサンプル補間は、エラーのあるデータの前後のパリティエラーがないときは省略される。ステップS104では、受信したパケットを保存する。ステップS101でフラグxfmodeが「1」と判別されたときは、ステップS105に進み、復帰処理のために受信したパケットを復帰処理部に転送する。
【0055】
図21は、発音処理のフローチャートである。ステップS110では、発音すべきパケットの有無を判別して、パケットがある場合はステップS111に進む。ステップS111では、次のパケットが到着しているか否かを判断する。次のパケットも到着している場合は、ステップS112に進んでフラグxfmodeを判別する。フラグxfmodeが「1」であれば、ステップS113に進んで次のパケットの復帰処理を行ってステップS114に進み、復帰処理が行われたパケットの楽音データを、発音のためD/A変換器61に転送する。フラグxfmodeが「0」であれば、ステップS113の復帰処理をスキップしてステップS114に進み、先頭パケットの楽音データを、発音のためD/A変換器61に転送する。
【0056】
次のパケットが到着していないときは、ステップS111からステップS115に進む。ステップS115では、不着イベントとして、不着処理でクロスフェードされたパケットを読み出す。ステップS114では、ステップS115で読み出されたパケットの楽音データを発音のためD/A変換器61に転送する。
【0057】
図22は、復帰処理のフローチャートである。ステップS120では、楽音データのパケット内のサンプル番号を示す変数iに「0」をセットする。サンプル数つまり変数iの最大値はnである。ステップS121では、ループしているパケットp[x]のサンプル番号iに対応する振幅として値aをセットする。ステップS122では、サンプル番号iとサンプル数n(例えば「256個」)との比の値i/nを振幅aに乗算して新たに振幅aとしてセットする。ステップS123では、到着パケット[y]のサンプル番号iに対応する振幅を示す値bとしてセットする。ステップS124では、補数「1−i/n]を振幅bに乗算して新たに振幅bとしてセットする。ステップS125では、クロスフェードされたパケットp'のサンプル番号iの振幅として「a+b」をセットする。ステップS126では、サンプル番号iを更新(+1)してその値iがサンプル数nに等しいか否かによってn個のサンプルを処理したかどうかが判断される。サンプル番号iがサンプル数nと等しくなるまでステップS121に進み、サンプル番号iがサンプル数nと等しくなればステップS127に進んで、クロスフェードモードが終了したことを示すためフラグxfmodeに「0」をセットする。
【0058】
なお、パリティエラーのあったサンプルを、直前のサンプルと直後のサンプルとの間の補間値に置き換えるのに代えて、次のように処置をしてもよい。例えば、誤りのあったパケットを廃棄する。また、誤りの個数が予定値以下ならば、補間値を使うようにし、誤りの個数が予定値以上ならばパケットを廃棄するようにして両者を使い分けることもできる。さらに、パリティデータの量を増やして、誤りデータを論理的に回復するようにしてもよい。
【0059】
以上、本発明を実施形態に従って説明したが、本発明はこれに限定されない。例えば、楽音発生端末から操作パネルや鍵盤を除いてもよい。要は、演奏データを作成して送出できる演奏端末からネットワークを経由して送出した演奏端末に基づいて作成された楽音データがネットワークを経由して同じ演奏端末で受信・発音できればよい。
【符号の説明】
【0060】
1…楽音発生端末、 2…演奏端末鍵盤、 4,9…操作パネル、 5…音源、 6、10…サウンドシステム、 7,11…制御部、 12…LAN、 20…マイクロフォン、 21…マイクスイッチ、 22…モニタスイッチ、 23…合奏スイッチ、 24…自己演奏スイッチ、 31…バッファ、 33…判別部、 34…第1クロスフェード部、 35…第2クロスフェード部
【技術分野】
【0001】
本発明は、電子楽器演奏システムに関し、特に、電子楽器演奏システムに含まれる楽音データ発生端末と複数の演奏データ発生端末に関する。
【背景技術】
【0002】
複数の楽器をMIDIケーブルを用いて接続する方法が知られる。MIDIでは、基本的に1対1の接続しか考慮されていないため、複数台の電子楽器を接続する場合は接続数に応じたMIDIケーブルを必要とする。また、電子楽器には限定された数のMIDI端子しか設けられていないので、接続される電子楽器の台数はあまり多くできない。例えば、MIDIチャネルが16チャネルであることから、同時に17台以上の電子楽器を相互に接続することはできない。さらに、MIDI規格では通信速度が演奏情報を転送するように決定されており、それ以上の高速転送は困難である。
【0003】
一方、特許文献1において、上記MIDIによる接続の問題点を解消するシステムとして、LANを経由して複数の電子楽器局、操作子局、音源局、およびシーケンサ局を互いに接続したシステムが提案されている。
【先行技術文献】
【特許文献】
【0004】
【特許文献1】特開平6−252928号公報
【発明の概要】
【発明が解決しようとする課題】
【0005】
上記特許文献1に開示された従来技術のようにLANを経由して複数の電子楽器等を互いに接続したシステムでは、例えば、操作子局から送出されるリアルタイム演奏データに基づいて電子楽器局で楽音を発生させたり、リアルタイム演奏データに基づいて音源局で楽音を合成して電子楽器で楽音を発生させたりするように構成することが考えられる。
【0006】
しかし、従来技術では、他端末で発生した楽音データによって自端末で発音することはできるが、演奏データを送出した演奏端末が、その演奏データに基づいて他端末で発生された楽音データによってリアルタイムで楽音を発生するということはできなかった。すなわち、演奏端末間で音源を共有しているものではなかった。
【0007】
例えば、学校や音楽教室等で複数の電子鍵盤楽器をLANを経由して接続してレッスンをしたり合奏をしたりする場合、複数の生徒が操作子としての鍵盤装置を持つだけではこれらの生徒は自分の演奏音を聞くことができない。各自が自己の演奏音をモニタするためには、全ての生徒が鍵盤装置とともに楽音データを生成する音源を備えた電子鍵盤楽器をそれぞれ持たなければならない。また、自己の演奏音だけでなく他の生徒との合奏音を聞きたいという要望もある。そのために、大勢の生徒が簡易な鍵盤装置などの演奏端末を使って同時に電子楽器のレッスンを行うことができるシステムが望まれる。
【0008】
本発明は、上記課題に鑑み、音源を重複して設けるという無駄を省きつつ、複数の演奏者による演奏を可能にする電子楽器演奏システムに含まれる楽音発生端末および演奏端末を提供することを目的とする。
【課題を解決するための手段】
【0009】
上記の課題を解決し、目的を達成するための本発明は、ネットワークを経由して演奏端末から演奏データを受信し、該演奏データに基づく楽音データを発生し、該楽音データを、前記ネットワークを経由して前記演奏端末に送信する楽音発生端末において、前記演奏端末から送信された宛先アドレスを受信する受信手段と、前記受信手段が受信した宛先アドレスが個別の送信先を示さない広域アドレスかどうかを検出する検出手段と、前記検出手段が検出した広域アドレスを送信した演奏端末に対してアドレスを割り当てる割り当て手段と、前記割り当て手段が割り当てたアドレスを前記ネットワークに送出する送出手段とを備えている楽音発生端末である点に第1の特徴がある。
【0010】
また、本発明は、ネットワークを経由して演奏者による演奏データを楽音発生端末に送信し、前記ネットワークを経由して前記演奏データに基づいて前記楽音発生端末で発生された楽音データを受信して発音する演奏端末において、前記演奏端末の立ち上げ時に、個別に送信先を示さない広域アドレスを用いてアドレス要求を前記ネットワークに送信する送信手段と、前記アドレス要求に応じてネットワークに送出されたアドレスを受信する受信手段と、前記受信したアドレスを宛先アドレスとして前記演奏データを前記ネットワークに送出する送出手段とを備えている演奏端末である点に第2の特徴がある。
【発明の効果】
【0011】
上記第1および第2の特徴を有する本発明によれば、演奏端末と楽音発生端末とをネットワークを介して接続している電子楽器演奏システムにおいて、演奏端末の立ち上げ時に、演奏端末が立ち上げた広域通信に応答して楽音発生端末から演奏端末に宛先アドレスとしてのアドレスを自動的に割り当てることができる。
【図面の簡単な説明】
【0012】
【図1】本発明の一実施形態に係る電子楽器演奏システムのブロック図である。
【図2】本発明の一実施形態に係るシステムの端末に含まれる制御部のブロック図である。
【図3】IPパケットの構造例を示す図である。
【図4】IPヘッダの内容およびその意味を示す図である。
【図5】楽音発生端末のメインフローチャートである。
【図6】イベント処理のフローチャートである。
【図7】通信処理のフローチャートである。
【図8】タイマ処理のフローチャートである。
【図9】演奏端末における初期化のフローチャートである。
【図10】演奏端末におけるイベント処理のフローチャートである。
【図11】パケット処理のフローチャートである。
【図12】鍵処理のフローチャートである。
【図13】パケット送信処理のフローチャートである。
【図14】楽音発生端末の操作パネル4の要部を示す図である。
【図15】操作パネルの要部機能を示すブロック図である。
【図16】変形例に係る操作パネルの要部機能を示すブロック図である。
【図17】操作パネル上のスイッチの状態を示す図である。
【図18】不着時処理の要部機能を示すブロック図である。
【図19】発音タイミングまでにパケットが到着しなかったときのクロスフェード処理に係るフローチャートである。
【図20】パケットの受信処理のフローチャートである。
【図21】発音処理のフローチャートである。
【図22】復帰処理のフローチャートである。
【発明を実施するための形態】
【0013】
以下、図面を参照して本発明を詳細に説明する。図1は本発明の一実施形態に係る電子楽器演奏システムのブロック図である。同図において、この演奏システムは、例えば、複数の生徒のための電子楽器のレッスンシステムである。この演奏システムは、教師が使用する楽音データ発生端末(以下、「楽音発生端末」という)1と生徒が使用する複数の演奏データ発生端末(以下、「演奏端末」という)2とからなる。
【0014】
楽音発生端末1は、鍵盤3、操作パネル4、音源(TG)5、サウンドシステム6、および制御部7を備える。鍵盤3は押鍵・離鍵を検出して演奏データ(キーナンバおよびベロシティを含む)を演奏者の演奏に応じてリアルタイムに出力する図示しないキーセンサを備える。操作パネル4は各種指示入力のためのスイッチや液晶パネル等の表示画面を有する。音源5は複数設けられ、演奏データに基づいて楽音データを発生する。サウンドシステム6は楽音データのD/A変換器(DAC)61、増幅器(AMP)62およびスピーカ(SP)63を備える。ヘッドフォン端子を設けて増幅器62の出力をスピーカ63だけでなくヘッドフォン端子(図示しない)にも供給できるようにする。
【0015】
演奏端末2は、鍵盤8、操作パネル9、サウンドシステム10、および制御部11を備える。演奏端末2は、音源5並びに音源5で使用する波形データやパラメータを保持していない点で楽音発生端末1と異なる。また、楽音発生端末1の操作パネル4には、演奏端末2の操作パネル9にないスイッチ(後述)を設ける。なお、楽音発生端末1には、必ずしも鍵盤3を設けなくてもよい。
【0016】
楽音発生端末1および演奏端末2の制御部7,11は、回線12に接続される。回線12は、IEEE802.3標準のLANつまりイーサネット(登録商標)で、伝送速度100メガビット/秒の100BASE−T仕様のものを使用するのがよい。なお、以下の説明は、回線12がLANであることを前提に説明するが、本発明は回線の種類はLANに限定されない。つまり、分離された複数の教室同士を接続した広域ネットワーク(WAN)であってもよい。
【0017】
楽音波形のサンプリング周波数を44.1kHz、サンプル精度を18ビット×2(ステレオを考慮する)、演奏端末数nを48として、楽音データ送出による情報量Sは、44100×18×2×48=76,204,800(ビット/秒)となる。この情報量Sにアドレスやヘッダなどのオーバヘッドを例えば30%見込んでも回線12上に送出されるデータ量は99,066,240ビット/秒となり、100BASE−T仕様の回線12の許容能力を上回らない。なお、演奏端末2からの演奏データ送出による情報量は、楽音データ送出による情報量と比べて桁違いに小さいので計算上無視できる。
【0018】
図2は制御部7の構成を示すブロック図である。制御部7は、CPU13、ROM14、RAM15、デジタルシグナルプロセッサ(DSP)16、および入出力インタフェース(SIO)17を有する。これらCPU13、ROM14、RAM15、DSP16およびSIO17はバス18を介して接続される。CPU13には、鍵盤3、操作パネル4、および音源5が接続され、音源5はDSP16に接続される。制御部7はSIO17を通じて回線12と接続される。ROM14には音源5で使用する波形データやパラメータが予め格納される。
【0019】
演奏端末2の制御部11も、音源5との接続並びにROM14に保持するデータの違いを除いて制御部7と同様に構成される。制御部7,11ではインタネットプロトコル(IP)を使用してデータを送受する。
【0020】
図3は、IPパケットの構造例を示す図である。パケット19は、イーサネット(登録商標)ヘッダ、IPヘッダ、MIDI/PCMヘッダ、MIDI/PCMボディ、イーサネット(登録商標)トレーラを含む。IPヘッダの内容およびその役割を図4に示す。
【0021】
図5は、楽音発生端末1のメインルーチンを示すフローチャートである。ステップS1では、各種レジスタ、カウンタ、フラグなどの初期化を行う。ステップS2では、鍵盤3の操作(鍵盤イベント)や操作パネル4の操作(パネルイベント)等、イベントの有無を判別する。パネルイベントの有無は、操作パネル4に備えられるスイッチやボリューム類の状態の監視動作によって判別される。鍵盤イベントの有無判別は、鍵盤3の各鍵毎に設けられるキーセンサの出力監視動作によって行われ、各鍵毎に押鍵・離鍵の有無、ならびにベロシティが検出される。なんらかのイベントが検出されれば、ステップS3で、そのイベントに対応する処理が実行される。イベント処理が終われば、ステップS4でタイマ処理が行われる。
【0022】
図6は、イベント処理のフローチャートである。ステップS10では、本体イベントか否か、つまり楽音発生端末1側で生じたイベントか、演奏端末2で生じたイベントかが判別される。本体イベントならば、ステップS11で発音のための通常の処理を行う。例えば、鍵盤イベントの押鍵か離鍵かによって発音または消音のための処理が行われる。なお、鍵盤イベントに従って、通常の発音とともに、予定の伴奏データによる自動伴奏を行うようにしてもよい。本体イベントでない場合は、ステップS12に進んで通信処理を行う。
【0023】
図7は、通信処理のフローチャートである。ステップS20では、パケットが自局宛てかどうか、つまりパケットの宛先アドレスTADDが楽音発生端末1のアドレスか否かを判別する。自局宛てならば、ステップS21に進んで受信パケットからMIDIデータを取り出す。ステップS22では、このMIDIデータに基づいて楽音データを作成する。
【0024】
ステップS20が否定(自局アドレスでない)ならば、ステップS23に進んで広域通信か否か、つまり楽音発生端末1がアドレスを割り当てた演奏端末2からの通信か、それ以外からの通信かを判断する。広域通信でないならば、この処理はスルーし、広域通信ならば、各演奏端末の立ち上げ時もしくは新たに演奏端末が発生した場合であり、ステップS24に進んでその演奏端末にアドレスを割り当てる。ステップS25では、ステップS24で割り当てたアドレスを回線12に送出する。
【0025】
図8は、タイマ処理のフローチャートである。ステップS30では、楽音データの有無が判断される。ステップS22で楽音データが作成された場合は、この判断は肯定であり、ステップS31に進んでこの楽音データを送信するためにパケットを作成する。ステップS32では、作成されたパケットを回線12に送出する。
【0026】
続いて、演奏端末2の処理を説明する。演奏端末2のメインフローチャートは楽音発生端末1のものと同様であるので省略し、メインフローチャートの各ステップの具体的な処理のみを説明する。
【0027】
図9は、演奏端末2の初期化のフローチャートである。この初期化の処理は演奏端末2の立ち上げ時に毎回行われる。ステップS40では、パケットを格納するパケット・バッファをクリアする。ステップS41では楽音発生端末1にアドレスを要求する。前記ステップS24は、このアドレス要求に対応する処理である。ステップS42では、その他のパラメータ等を初期化する。
【0028】
図10、演奏端末2におけるイベント処理のフローチャートである。ステップS50では、パケット受信か否かを判断する。パケットを受信したのであれば、ステップS51に進んでパケット処理(後述)を行う。
【0029】
パケットを受信したのでないならば、ステップS52に進んで鍵盤イベントか否かを判断する。鍵盤イベントであれば、ステップS53に進んで鍵処理(後述)を行う。鍵盤イベントでなければステップS54に進んでパネルイベントか否かを判断する。パネルイベントであれば、ステップS55に進んでパネル処理を行う。パネル処理では、例えば音色データやエクスプレッション等の制御データを制御パケットデータとして作成し、パケット・バッファに書き込む。パネルイベントでなければステップS56に進んでその他のイベントか否かを判断し、その他のイベントであればステップS57で予定されたその他の処理を行う。
【0030】
図11は、パケット処理のフローチャートである。ステップS60では、アドレス受信か否かを判断する。アドレスを受信したのであれば、ステップS61に進み、受信したアドレスをRAM15上の所定の記憶領域に書き込むアドレス処理を行う。アドレス受信でなければ、ステップS60からステップS62に進んで楽音データの受信か否かを判断する。楽音データを受信したのであれば、ステップS63に進んで楽音発生のための楽音処理を行う。楽音処理では、パケットを分解してMIDI/PCMボディからPCMデータを取り出し、RAM15のバッファに蓄積する。このバッファに蓄積されたPCMデータはサウンドシステム6のD/A変換器61および増幅器62を介してスピーカ63に入力され、発音に供される。
【0031】
図12は、鍵処理のフローチャートである。ステップS70では、押鍵か否かが判別され、押鍵であればステップS71に進んで押鍵パケットデータを生成する。つまり押鍵された鍵のキーナンバおよびベロシティをパケットのデータフィールドに書き込むためにパケット・バッファに格納する。押鍵でなければ、ステップS72に進んで離鍵か否かが判別され、離鍵であればステップS73に進んで離鍵パケットデータを生成する。離鍵パケットデータは押鍵パケットデータと同様、パケット・バッファに格納される。
【0032】
図13は、パケット送信処理のフローチャートである。この処理はタイマ処理として予定の割り込み時間毎に行われる。ステップS80では、パケット・バッファ内のデータ有無を判断する。パケット・バッファ内にデータがあればステップS81に進んでパケットを作成する。つまり押鍵パケットデータ、離鍵パケットデータ、および制御パケットデータにヘッダやトレーラ等を付加してパケットを完成させる。ステップS82では、このパケットを回線12に送出する。
【0033】
次に、上記レッスンシステムによる具体的なレッスンの例を説明する。図14は、教師が使用する楽音発生端末1の操作パネル4の要部を示す図である。この操作パネル4の要部は、生徒が使用する演奏端末2の操作パネル9には設けない。ここでは、最大生徒数24名を想定する。但し、生徒が使用する演奏端末2は、全員が単一の教室に収容されているのに限らず、複数の部屋に分かれて収容されていてもよいし、演奏端末2が個々にブースつまり小部屋に収容されていてもよい。要は、生徒数24名の使用する演奏端末および楽音発生端末1がLANまたはWANの回線12で互いに接続されていればよい。
【0034】
操作パネル4には、マイクロフォン(マイク)20、並びにマイクスイッチ21、モニタスイッチ22、合奏スイッチ23、および自己演奏スイッチ24が設けられる。各スイッチは最大生徒数分の24個設けられる。各スイッチ21〜24は、オン・オフの切り替えができ、その切り替え位置が目で認識できるものがよい。プッシュスイッチ、トグルスイッチ、タッチスイッチ等、その種類は問わない。
【0035】
マイク20から入力された音声は、デジタル化されて楽音データと加算されたうえ、マイクスイッチ21をオンにしている生徒の演奏端末2に送信される。モニタスイッチ22は、このスイッチ22をオンにしている演奏端末2からの演奏データによる発音をモニタするためのものであり、教師はスピーカ63および図示しないヘッドフォンにより演奏を聞くことができる。
【0036】
合奏スイッチ23は、生徒が、自分の演奏と他の生徒の演奏との合奏音を聞くことができるように設けられる。合奏スイッチ23がオンになっている演奏端末2からの演奏データによって楽音発生端末1で形成された楽音データは互いに加算されて該演奏端末2に送信される。
【0037】
自己演奏スイッチ24は、このスイッチ24をオンにしている演奏端末2からの演奏データのみが有効になって楽音発生端末1で処理されるもので、このスイッチ24をオンにしていない演奏端末2からの演奏データは無視される。
【0038】
図14における各スイッチの状態(黒丸はオン、白丸はオフ)によれば、マイクスイッチ21は全てオンなので、教師の音声はマイク20を通して全生徒の演奏端末2に届く。合奏スイッチ23は2番および4番の演奏端末2のみについてオンになっているので、2番および4番の演奏端末2の生徒は互いに両生徒の演奏を合奏として聞くことができる。また、自己演奏スイッチ24は全ての演奏端末2を選択しているので、2番および4番の演奏端末の生徒以外の生徒は自分の演奏のみを聞くことができる。したがって、2番および4番のみの合奏を評価したいときに、他の生徒が演奏をしても、その音は2番および4番の生徒の合奏に影響しない。また、モニタスイッチ22は2番の演奏端末2のみを選択しているので、教師は2番の演奏のみをモニタしている状況である。
【0039】
図15は、図14に示した操作パネル4の要部機能を示すブロック図である。図15において、A/D変換器25が設けられ、マイクスイッチ(SW1)21がオンの間、マイク20からの入力音声信号はこのA/D変換器25でデジタル変換されて加算器26に入力される。
【0040】
自己演奏スイッチ(SW4)24で選択されている演奏端末2からの演奏データが回線12を経由して音源5に入力される。音源5は演奏データに基づいて楽音データを生成する。音源5からは、モニタスイッチ(SW2)22がオンになっている演奏端末2の演奏データによる楽音データがモニタ信号Moutとして出力される。モニタスイッチ(SW2)22がオンになっている全ての演奏端末2からの演奏データに基づくモニタ信号Moutが加算されて前記サウンドシステム6のD/A変換器61に入力される。この加算はD/A変換器61の出力側で行ってもよい。
【0041】
音源5で生成された楽音データEoutは、合奏スイッチ(SW3)23を介して合成部26へ出力される。合成部26は、合奏スイッチ(SW3)23がオンになっている演奏端末2の楽音データを互いに加算(好ましくはデジタル加算)して、合成楽音データEinを出力する。合成楽音データEinは、デジタル変換されたマイク20からの前記入力音声信号に加算器26で加算されてパケット生成部28でパケット化され、さらに転送ユニット29を介して回線12に送出される。
【0042】
音源5からの出力はスイッチ(SW2)22およびスイッチ(SW3)23の状態にかかわらず回線12に常時送出される。したがって、音源5からのこの出力が加算器27で合成楽音データEinに加算されて二重加算になるのを防止するため、減算器30を介して予め音源5から直接送出される楽音データを除くようにしている。
【0043】
減算器30は音源5の出力を常時回線12に送出するため加算器27を設けたために必要となるのであり、同様の機能は減算器30によらずに果たすこともできる。例えば、音源5の出力を合奏スイッチ(SW3)23の逆の論理で出力し、合成楽音データEinをそのまま加算器27に入力してもよい(図16参照)。図16において、スイッチSW3'(スイッチ23a)は合奏スイッチ(SW3)23の逆論理スイッチを示す。
【0044】
図17は、スイッチ21〜24の、他の状態を示す図である。この図のスイッチの状態によれば、合奏スイッチ23は全ての生徒の分がオンになっているので、全ての生徒は楽音データを受け取って再生できる。しかし、自己演奏スイッチ24は2番と4番の生徒の分しかオンになっていないので、演奏データはこれら2番および4番の生徒の演奏端末2の分しか有効にならない。したがって、これら2番と4番の生徒の演奏が合奏されるだけであり、その他の生徒もこの合奏音を聴けることになる。自己演奏スイッチ24の機能により、いたずらや誤りによって2番および4番以外の生徒が演奏してもそれは無視され、合奏に反映されないという効果がある。
【0045】
なお、操作パネル4上のスイッチの構成は上記実施例に限定されない。例えば、合奏スイッチ23は省略してもよい。また、合奏スイッチ23を省略するとともに、合奏および独奏の選択スイッチを一つ設け、この選択スイッチによって合奏か独奏かを選択できるようにする。この場合、合奏端末として選択された演奏端末のみが自らの演奏を含む合奏音を聞くことができる。
【0046】
次に、楽音データの通信エラーを補正する装置について説明する。インタネットプロトコルを使って行われるパケット通信では、データに誤りが含まれることがある。また、パケットが送出順に着信しないこと(遅着)があったり、パケットが着信しないこと(不着)があったりする。
【0047】
そこで、本実施形態では、パケットの遅着、不着およびデータの誤りに対して次のように対処する。まず、発音タイミングまでに当該パケットが到着しないときには遅着および不着のいずれの場合も不着とみなして、そのタイミング以後に到着してもそのパケットは廃棄する。不着に対してパケットの再送は要求しない。そして、廃棄したパケットに代えて、直前のパケットをループして発音させる。再送を要求しないのは、再送要求に応答してパケットが再送されてくるまで待っていては発音が途切れるからである。
【0048】
直前のパケットを使用するために、まず、前提として、発音は常に1パケット分遅延させて行う。したがって、不着とみなされた時点で直前のパケットが到着しているが、発音はまだ実行されていない。直前のパケットによる発音を開始するまでに該パケットが到着しなかったら、直前のパケットを自己ループして発音し、不着パケットに代えて発音する。そして、次のパケットが到着したら、ループしている直前のパケットとこの到着パケットとをクロスフェードして発音する。
【0049】
図を参照して不着時の処理を説明する。図18は、不着時処理の要部機能を示すブロック図である。なお、この図では、理解の容易のため、パケットとパケットに収容された楽音データは同義として扱う。受信されたパケットは到着順にバッファ31に蓄積され、パケットは読み出し部32で到着順に分解されて発音に供するためD/A変換器61に入力される。判別部33は、発音開始時にその発音に供しているパケットの次のパケットが不着かどうかを判別する。そして、不着のときは後述するように第1演算手段としての第1クロスフェード部34で楽音データをクロスフェードし、不着パケットに代える。第1クロスフェード部34で演算された楽音データによる発音開始時に後続パケットが到着していることを判別部33で判別したときには、後述するように第2クロスフェード部35で楽音データをクロスフェードし、後続パケットに代える。
【0050】
図18の例では、先行パケットp[j−1]、現パケットp[j]、後続パケットp[y]が到着している。現パケットp[j]と後続パケットp[y]との間に到着するはずのパケットp[j+1]およびp[j+2]が到着していない。
【0051】
ここで、現パケットp[j]が発音処理開始されているものとする。この現パケットp[j]による発音開始時にその次のパケットp[j+1]が到着しているか否かが判別部33で判別される。ここでパケットp[j+1]が到着していないときは、第1クロスフェード部34によって先行パケットp[j−1]および現パケットp[j]をクロスフェードさせてパケットp[x]を得る。パケットp[j]の発音が終わると、クロスフェードして得られたパケットp[x]をパケットp[j+1]の楽音データに代えて使用し、楽音を発生させる。
【0052】
そして、このパケットp[x]による発音開始時にパケットp[j+2]が到着しているか否かが判断され、不着時はパケットp[x]を再度ループさせる。さらにこのループの開始時に、後続パケットp[y]の到着有無を判断する。ここでは、後続パケットp[y]が到着しているので、判別部33は第2クロスフェード部35によって現在ループ中のパケットp[x]および後続パケットp[y]をクロスフェードさせ、このクロスフェードされたパケットを後続パケットp[y]に代えて使用し、発音させる。このように、楽音データをクロスフェードして代替の楽音データを作成することによって、本来連続していない楽音データを連続性をもったものにする。
【0053】
図19は、不着処理つまり発音タイミングまでにパケットが到着しなかったときのクロスフェード処理に係るフローチャートである。ステップS90では、楽音データのパケット内のサンプル番号を示す変数iに「0」をセットする。サンプル数つまり変数iの最大値はnである。ステップS91では、不着パケットの直前パケットp[j]より一つ前のパケット[j−1]のサンプル番号iに対応する振幅として値aをセットする。ステップS92では、サンプル番号iとサンプル数n(例えば「256個」)との比の値i/nを振幅aに乗算して新たに振幅aとしてセットする。ステップS93では、直前パケット[j]のサンプル番号iに対応する振幅を示す値bとしてセットする。ステップS94では、補数「1−i/n]を振幅bに乗算して新たに振幅bとしてセットする。ステップS95では、クロスフェードされたパケットp'のサンプル番号iの振幅として「a+b」をセットする。ステップS96では、サンプル番号iを更新(+1)してその値iがサンプル数nに等しいか否かによってn個のサンプルを処理したかどうかが判断される。サンプル番号iがサンプル数nと等しくなるまでステップS91に進み、サンプル番号iがサンプル数nと等しくなればステップS97に進んで、クロスフェードモードであることを示すフラグxfmodeに「1」をセットする。フラグxfmodeの初期値は「0」である。
【0054】
図20は、パケットを受信したときの受信処理のフローチャートである。ステップS100では、受信したパケットが、不着とみなされて廃棄されたのものかどうかを判断する。廃棄されたものであれば、このフローチャートはスルーされる。ステップS101では、フラグxfmodeが判別される。フラグxfmodeが「0」ならば、正常な受信であると判断してステップS102に進み、パリティエラーの有無を判断する。パリティエラーが発生しているときは、ステップS103で、エラーのあるサンプルの直前および直後のサンプル間で補間値をとり、その補間値をエラーのあるサンプルに代えて使用する。そして、ステップS104に進む。ステップS103のサンプル補間は、エラーのあるデータの前後のパリティエラーがないときは省略される。ステップS104では、受信したパケットを保存する。ステップS101でフラグxfmodeが「1」と判別されたときは、ステップS105に進み、復帰処理のために受信したパケットを復帰処理部に転送する。
【0055】
図21は、発音処理のフローチャートである。ステップS110では、発音すべきパケットの有無を判別して、パケットがある場合はステップS111に進む。ステップS111では、次のパケットが到着しているか否かを判断する。次のパケットも到着している場合は、ステップS112に進んでフラグxfmodeを判別する。フラグxfmodeが「1」であれば、ステップS113に進んで次のパケットの復帰処理を行ってステップS114に進み、復帰処理が行われたパケットの楽音データを、発音のためD/A変換器61に転送する。フラグxfmodeが「0」であれば、ステップS113の復帰処理をスキップしてステップS114に進み、先頭パケットの楽音データを、発音のためD/A変換器61に転送する。
【0056】
次のパケットが到着していないときは、ステップS111からステップS115に進む。ステップS115では、不着イベントとして、不着処理でクロスフェードされたパケットを読み出す。ステップS114では、ステップS115で読み出されたパケットの楽音データを発音のためD/A変換器61に転送する。
【0057】
図22は、復帰処理のフローチャートである。ステップS120では、楽音データのパケット内のサンプル番号を示す変数iに「0」をセットする。サンプル数つまり変数iの最大値はnである。ステップS121では、ループしているパケットp[x]のサンプル番号iに対応する振幅として値aをセットする。ステップS122では、サンプル番号iとサンプル数n(例えば「256個」)との比の値i/nを振幅aに乗算して新たに振幅aとしてセットする。ステップS123では、到着パケット[y]のサンプル番号iに対応する振幅を示す値bとしてセットする。ステップS124では、補数「1−i/n]を振幅bに乗算して新たに振幅bとしてセットする。ステップS125では、クロスフェードされたパケットp'のサンプル番号iの振幅として「a+b」をセットする。ステップS126では、サンプル番号iを更新(+1)してその値iがサンプル数nに等しいか否かによってn個のサンプルを処理したかどうかが判断される。サンプル番号iがサンプル数nと等しくなるまでステップS121に進み、サンプル番号iがサンプル数nと等しくなればステップS127に進んで、クロスフェードモードが終了したことを示すためフラグxfmodeに「0」をセットする。
【0058】
なお、パリティエラーのあったサンプルを、直前のサンプルと直後のサンプルとの間の補間値に置き換えるのに代えて、次のように処置をしてもよい。例えば、誤りのあったパケットを廃棄する。また、誤りの個数が予定値以下ならば、補間値を使うようにし、誤りの個数が予定値以上ならばパケットを廃棄するようにして両者を使い分けることもできる。さらに、パリティデータの量を増やして、誤りデータを論理的に回復するようにしてもよい。
【0059】
以上、本発明を実施形態に従って説明したが、本発明はこれに限定されない。例えば、楽音発生端末から操作パネルや鍵盤を除いてもよい。要は、演奏データを作成して送出できる演奏端末からネットワークを経由して送出した演奏端末に基づいて作成された楽音データがネットワークを経由して同じ演奏端末で受信・発音できればよい。
【符号の説明】
【0060】
1…楽音発生端末、 2…演奏端末鍵盤、 4,9…操作パネル、 5…音源、 6、10…サウンドシステム、 7,11…制御部、 12…LAN、 20…マイクロフォン、 21…マイクスイッチ、 22…モニタスイッチ、 23…合奏スイッチ、 24…自己演奏スイッチ、 31…バッファ、 33…判別部、 34…第1クロスフェード部、 35…第2クロスフェード部
【特許請求の範囲】
【請求項1】
ネットワークを経由して演奏端末から演奏データを受信し、該演奏データに基づく楽音データを発生し、該楽音データを、前記ネットワークを経由して前記演奏端末に送信する電子楽器演奏システムの楽音発生端末において、
前記演奏端末から送信された宛先アドレスを受信する受信手段と、
前記受信手段が受信した宛先アドレスが個別の送信先を示さない広域アドレスかどうかを検出する検出手段と、
前記検出手段が検出した広域アドレスを送信した演奏端末に対してアドレスを割り当てる割り当て手段と、
前記割り当て手段が割り当てたアドレスを前記ネットワークに送出する送出手段とを備えていることを特徴とする電子楽器演奏システムの楽音発生端末。
【請求項2】
ネットワークを経由して演奏者による演奏データを楽音発生端末に送信し、前記ネットワークを経由して前記演奏データに基づいて前記楽音発生端末で発生された楽音データを受信して発音する電子楽器演奏システムの演奏端末において、
前記演奏端末の立ち上げ時に、個別に送信先を示さない広域アドレスを用いてアドレス要求を前記ネットワークに送信する送信手段と、
前記アドレス要求に応じてネットワークに送出されたアドレスを受信する受信手段と、
前記受信したアドレスを宛先アドレスとして前記演奏データを前記ネットワークに送出する送出手段とを備えていることを特徴とする電子楽器演奏システムの演奏端末。
【請求項1】
ネットワークを経由して演奏端末から演奏データを受信し、該演奏データに基づく楽音データを発生し、該楽音データを、前記ネットワークを経由して前記演奏端末に送信する電子楽器演奏システムの楽音発生端末において、
前記演奏端末から送信された宛先アドレスを受信する受信手段と、
前記受信手段が受信した宛先アドレスが個別の送信先を示さない広域アドレスかどうかを検出する検出手段と、
前記検出手段が検出した広域アドレスを送信した演奏端末に対してアドレスを割り当てる割り当て手段と、
前記割り当て手段が割り当てたアドレスを前記ネットワークに送出する送出手段とを備えていることを特徴とする電子楽器演奏システムの楽音発生端末。
【請求項2】
ネットワークを経由して演奏者による演奏データを楽音発生端末に送信し、前記ネットワークを経由して前記演奏データに基づいて前記楽音発生端末で発生された楽音データを受信して発音する電子楽器演奏システムの演奏端末において、
前記演奏端末の立ち上げ時に、個別に送信先を示さない広域アドレスを用いてアドレス要求を前記ネットワークに送信する送信手段と、
前記アドレス要求に応じてネットワークに送出されたアドレスを受信する受信手段と、
前記受信したアドレスを宛先アドレスとして前記演奏データを前記ネットワークに送出する送出手段とを備えていることを特徴とする電子楽器演奏システムの演奏端末。
【図1】
【図2】
【図3】
【図4】
【図5】
【図6】
【図7】
【図8】
【図9】
【図10】
【図11】
【図12】
【図13】
【図14】
【図15】
【図16】
【図17】
【図18】
【図19】
【図20】
【図21】
【図22】
【図2】
【図3】
【図4】
【図5】
【図6】
【図7】
【図8】
【図9】
【図10】
【図11】
【図12】
【図13】
【図14】
【図15】
【図16】
【図17】
【図18】
【図19】
【図20】
【図21】
【図22】
【公開番号】特開2010−191458(P2010−191458A)
【公開日】平成22年9月2日(2010.9.2)
【国際特許分類】
【出願番号】特願2010−90040(P2010−90040)
【出願日】平成22年4月9日(2010.4.9)
【分割の表示】特願2008−234739(P2008−234739)の分割
【原出願日】平成16年4月2日(2004.4.2)
【出願人】(000001410)株式会社河合楽器製作所 (563)
【Fターム(参考)】
【公開日】平成22年9月2日(2010.9.2)
【国際特許分類】
【出願日】平成22年4月9日(2010.4.9)
【分割の表示】特願2008−234739(P2008−234739)の分割
【原出願日】平成16年4月2日(2004.4.2)
【出願人】(000001410)株式会社河合楽器製作所 (563)
【Fターム(参考)】
[ Back to top ]