(57)【特許請求の範囲】
【請求項１】
ネットワークを介して接続された少なくとも２台以上からなるコンピュータシステムを用いて、発生楽音の特性を定めるパラメータを編集する楽音パラメータ編集装置であって、
前記コンピュータシステムのうちの一のコンピュータにおいて、
前記パラメータを定義付ける情報を入力するための編集画面データを、前記コンピュータシステムのうち、他のコンピュータより受信して前記編集画面データに基づく編集画面を表示する表示手段と、
前記表示手段により表示された編集画面を用いて前記パラメータを定義付ける情報を入力する入力手段と、
前記入力手段により入力された情報を、前記他のコンピュータに送信する第１の送信手段と、
前記他のコンピュータにより、前記情報に基づいて生成されたパラメータあるいはサンプリングデータを受信する第１の受信手段と
を具備することを特徴とする楽音パラメータ編集装置。
【請求項２】
ネットワークを介して接続された少なくとも２台以上からなるコンピュータシステムを用いて、発生楽音の特性を定めるパラメータを編集する楽音パラメータ編集装置であって、
前記パラメータを定義付ける情報を、前記コンピュータシステムのうちの一のコンピュータから受信する第２の受信手段と、
前記第２の受信手段により受信された情報に基づいてパラメータあるいはサンプリングデータを生成する生成手段と、
前記生成手段により生成されたパラメータあるいはサンプリングデータを、前記一のコンピュータに送信する第２の送信手段と
を前記コンピュータシステムのうちの他のコンピュータにおいて具備する
ことを特徴とする楽音パラメータ編集装置。
【請求項３】
ネットワークを介して接続された少なくとも２台以上からなるコンピュータシステムを用いて、発生楽音の特性を定めるパラメータを編集する楽音パラメータ編集装置であって、
前記コンピュータシステムのうちの一のコンピュータにおいて、
前記パラメータを定義付ける情報を入力するための編集画面データを、前記コンピュータシステムのうち、他のコンピュータより受信して前記編集画面データに基づく編集画面を表示する表示手段と、
前記表示手段により表示された編集画面を用いて前記パラメータを定義付ける情報を入力する入力手段と、
前記入力手段により入力された情報を、前記他のコンピュータに送信する第１の送信手段と、
前記他のコンピュータにより、前記情報に基づいて生成されたパラメータあるいはサンプリングデータを受信する第１の受信手段とを具備する一方、前記他のコンピュータにおいて、前記パラメータを定義付ける情報を、前記コンピュータシステムのうちの一のコンピュータから受信する第２の受信手段と、
前記第２の受信手段により受信された情報に基づいてパラメータあるいはサンプリングデータを生成する生成手段と、
前記生成手段により生成されたパラメータあるいはサンプリングデータを、前記一のコンピュータに送信する第２の送信手段と
を具備することを特徴とする楽音パラメータ編集装置。
【請求項４】
前記編集画面データは、楽音に対応して複数用意されるものであり、
入力する情報にかかる楽音に応じて、前記複数の編集画面データのうちのいずれかを選択して用いる
ことを特徴とする請求項１または３記載の楽音パラメータ編集装置。
【請求項５】
前記生成手段は、楽音に対応して複数用意されるものであり、
前記第２の受信手段により受信された情報にかかる楽音に応じて、前記複数の生成手段のうちのいずれかを選択して用いる
ことを特徴とする請求項２または３記載の楽音パラメータ編集装置。
【請求項６】
前記第２の受信手段により受信された情報にかかる楽音が、前記複数の生成手段のいずれにも対応しない場合、
前記第２の送信手段は、当該情報をさらに別のコンピュータに送信し、前記第２の受信手段は、当該情報に基づいて前記別のコンピュータによって生成されたパラメータあるいはサンプリングデータを受信し、
前記第２の送信手段は、当該パラメータあるいはサンプリングデータを前記一のコンピュータに送信する
ことを特徴とする請求項５記載の楽音パラメータ編集装置。
【請求項７】
ネットワークを介して接続された少なくとも２台以上からなるコンピュータシステムを用いて、発生楽音の特性を定めるパラメータを編集する楽音パラメータ編集方法であって、
前記コンピュータシステムのうちの一のコンピュータにおいて、ユーザによる楽音パラメータを定義付ける情報の入力を受け付ける段階と、
前記一のコンピュータにおいて、前記入力された情報を前記コンピュータシステムのうちの他のコンピュータに送信する段階と、
前記他のコンピュータにおいて、前記一のコンピュータにより送信された情報を受信する段階と、
前記他のコンピュータにおいて、前記受信した情報に基づいて楽音パラメータあるいはサンプリングデータを生成する段階と、
前記他のコンピュータにおいて、前記生成した楽音パラメータあるいはサンプリングデータを前記一のコンピュータに送信する段階と、
前記一のコンピュータにおいて、前記他のコンピュータにより送信された楽音パラメータあるいはサンプリングデータを受信する段階と
を備えることを特徴とする楽音パラメータ編集方法。
【発明の詳細な説明】
【０００１】
【発明の属する技術分野】
本発明は、コンピュータネットワークを介して、発生楽音の特性を定めるパラメータを編集する楽音パラメータ編集装置および楽音パラメータ編集方法に関する。
【０００２】
【従来の技術】
従来より、発生楽音の特性を定める楽音パラメータを変化させて、様々な音づくりを可能とする楽音パラメータ編集装置が存在している。この種のパラメータ編集装置においては、図９に示すように、楽音パラメータの一覧を表示させて、それら各値を適宜変更して編集するタイプや、これらの値に規定されるパラメータ形状等もグラフィック表示させて、楽音パラメータの各値とグラフィックとを対比させ、設定値とそれによって規定される形状との対応関係を表示させて編集するタイプもある。
【０００３】
【発明が解決しようとする課題】
しかしながら、楽音パラメータの設定項目は、音色属性や、種類、付加する効果などによって異なるため、ひとつの編集装置で、多数の音色にわたる楽音パラメータをすべて編集するのは、編集装置の複雑化を招く一方、楽音パラメータのうち最大公約数的な項目のみを編集する構成とすると、ある音色については設定できない項目が生じて、ユーザが不満を感じる、という欠点がある。
かといって、編集の対象となる楽音パラメータのすべてをカバーするように、複数の編集装置を用意するのは、ユーザにとっては大きな負担となる、という欠点がある。
以上の欠点については、編集プログラムを用いてソフトウェア的に編集する場合においても同様である。
さらに最近では、自然楽器の発音原理を電気的モデルによりシミュレートする物理モデル音源の登場により（例えば、特開平５−８０７６１号公報参照）、実際には存在しない楽器の音色についても生成可能となっている。このため、楽音パラメータにおいては設定項目の多様化・複雑化が増す傾向にあり、多数の音色にわたって楽音パラメータを編集するのは、より困難となっている。
【０００４】
本発明は、上述した事情に背景に鑑みてなされたものであり、その目的とするところは、ユーザにとって、多数の音色にかかる楽音パラメータを、編集装置や編集プログラムなどを複数用意することなく編集可能とする楽音パラメータ編集装置および楽音パラメータ編集方法を提供することにある。
【０００５】
【課題を解決するための手段】
上記目的を達成するために本発明にあっては、ネットワークを介して接続された少なくとも２台以上からなるコンピュータシステムを用いて、発生楽音の特性を定めるパラメータを編集する楽音パラメータ編集装置であって、前記コンピュータシステムのうちの一のコンピュータにおいて、前記パラメータを定義付ける情報を入力するための編集画面データを、前記コンピュータシステムのうち、他のコンピュータより受信して前記編集画面データに基づく編集画面を表示する表示手段と、前記表示手段により表示された編集画面を用いて前記パラメータを定義付ける情報を入力する入力手段と、前記入力手段により入力された情報を、前記他のコンピュータに送信する第１の送信手段と、前記他のコンピュータにより、前記情報に基づいて生成されたパラメータあるいはサンプリングデータを受信する第１の受信手段とを具備する一方、前記他のコンピュータにおいて、前記パラメータを定義付ける情報を、前記コンピュータシステムのうちの一のコンピュータから受信する第２の受信手段と、前記第２の受信手段により受信された情報に基づいてパラメータあるいはサンプリングデータを生成する生成手段と、前記生成手段により生成されたパラメータあるいはサンプリングデータを、前記一のコンピュータに送信する第２の送信手段とを具備することを特徴としている。
【０００６】
【発明の実施の形態】
以下、本発明の実施形態について、図面を参照して説明する。
【０００７】
＜１：実施形態の構成＞
本実施形態にかかる楽音パラメータ編集装置は、ネットワークを介したコンピュータシステムに適用されるものであり、ユーザがクライアントマシンを操作して、楽音パラメータを定義付けるデータを入力すると、当該クライアントマシンが当該データをサーバマシンに送信する一方、サーバマシン等が当該データから楽音パラメータを生成して、当該クライアントマシンに返送し、これを楽音パラメータとして設定するものである。
【０００８】
図１は、この楽音パラメータ編集装置が適用されるネットワークの一例を示すブロック図である。この図に示すように、ネットワークにおいては、サーバマシンＳ１、Ｓ２、Ｓ３が、それぞれ基幹系回線Ｐを介して接続され、これらのサーバマシンの各々には、さらに、多数のクライアントマシン１１０1〜、１２０1〜、１３０1〜がそれぞれ一般系回線Ｑを介して接続されており、サーバマシンおよびクライアントマシン間では、相互通信が可能となっている。
【０００９】
なお、サーバマシンＳ２およびＳ３は、インターネットを介して接続されているが、この図では、インターネットへの接続に必要な構成、例えば、ルータや、ターミナルアダプタなどの構成については、本願と直接関係しないので省略している。
また、図に示すネットワークは、あくまでも一例であり、本発明はネットワークの形式を特定するものではない。したがって、上記ネットワークは、インターネットを介した世界規模なものである必要はなく、単なる社内ＬＡＮであっても良い。
くわえて、説明では、説明の便宜上、サーバマシンとクライアントマシンとに分けるが、いわゆるピア・トゥ・ピア型のように、これらを区別しないネットワークでも良い。要は、少なくとも２台以上の端末からなるネットワークであれば良い。
【００１０】
＜１−１：クライアントマシン等の構成＞
まず、クライアントマシンの構成の一例について、図２を参照して説明する。なお、ここでいうクライアントマシンとは、ユーザが操作するコンピュータという意味合いで用いている。
この図において、ＣＰＵ２００は、ＯＳ（オペレーティング・システム）にしたがって、バスＢを介してクライアントマシン内の各部を制御するものであり、その動作の詳細については後述することとする。なお、本実施形態におけるＯＳは、いわゆるＧＵＩ（グラフィカル・ユーザ・インターフェイス）を用いたマルチ・ウィンドウ形式である。
ＲＡＭ２０１は、ＣＰＵ２００による制御において発生したデータや、後述する音色データなどを一時的に記憶するものである。
ストレージ・ユニット２０２は、上記ＯＳや、後述するアプリケーションプログラムなどを記憶するものである。
ネットワークＩ／Ｆ（インターフェイス）２０３は、例えばイーサネットボートからなり、上述したネットワークとバスＢとの接続を果たすものである。
【００１１】
一方、音源回路２０４は、Ｄ／Ａ変換回路を内蔵して、ＣＰＵ２００の制御に基づいて楽音信号をアナログ信号に変換して出力するものであり、例えば、ネットワークＩ／Ｆ２０３と同様にボード形式で提供される。この音源回路２０４は、また、Ａ／Ｄ変換回路を内蔵しており、必要に応じて接続されるマイク２０５によるアナログ信号をディジタル信号に変換して、各種の制御や入力などに用いることが可能となっている。
ＭＩＤＩ・Ｉ／Ｆ２０６は、ＭＩＤＩデータにしたがって楽音信号を生成するＭＩＤＩ機器２０７を、マシン本体と接続するためのものである。
サウンドシステム２０８は、アンプや、スピーカなどからなり、楽音信号を実際に発音させるものである。
クライアントマシンには、その他に、ユーザが各種入力や指示まどをするために必要なマウス２０９やキーボード２１０が接続され、また、表示を行なうためのディスプレイ２１１が接続されている。
【００１２】
さて、本実施形態におけるアプリケーションプログラムとしては、音源回路２０４やＭＩＤＩ機器２０７を用いて演奏や楽音発生などを行なうための第１のプログラムや、楽音パラメータを定義付ける情報を入力や、修正、編集等して、楽音パラメータを生成するための第２のプログラム（エディタ）、ネットワークを介した文字画像情報の閲覧や、リンク、送受信などを制御するための第３のプログラム（ブラウザ）などがある。
このうち、エディタは、従来の技術で述べたようなもの、すなわち、音色の属性や種類などに応じて用意されるものであるため、必須ではない。また、ブラウザは、エディタの選択や、楽音パラメータを定義付ける情報の入力、修正、編集機能のみを有し、当該楽音パラメータを直接生成する機能は有していない。この点において、エディタとは相違する。
【００１３】
さて、図２に示す構成から判るように、クライアントマシンは、何らかの形で楽音の発生する機能を有するものである。この意味で、クライアントマシンは、音源回路２０４およびＭＩＤＩ機器２０７の双方を備える必要はなく、いずれか一方だけも良い。
一方、サーバマシンの構成は、次の点以外、クライアントマシンと同等である。すなわち、サーバマシンは、楽音発生機能を必須としない点と、楽音パラメータを定義付ける情報から当該楽音パラメータを生成するプログラム（すなわち、エディタ）を、クライアントマシンにおいて選択される可能性のあるエディタのすべてに対応して記憶する点とにおいて相違している。なお、ここでいうサーバマシンとは、ユーザが関与しないコンピュータという意味合いで用いている。
また、エディタのプログラムについては、当該サーバマシンのストレージ・ユニットと、その配下にあるクライアントマシンであって、ユーザが関与しないクライアントマシンのストレージ・ユニットとに分散されて記憶されている。図１に示す例にあっては、サーバマシンＳ１が、基本的な音色の編集に用いる汎用のエディタ（プログラム）を記憶し、また、その配下にあるクライアントマシン１１０nが、特殊な音色（例えば、後述する物理モデル音源による音色）の編集に用いる特殊エディタや、固有の音色のみを専用的に編集する専用エディタ、音色を高精度に編集する高精度エディタなどをそれぞれ記憶して、これらの各マシンが、それぞれのエディタに対応している様子を示す。
【００１４】
＜１−１−１：音色データのメモリマップ＞
次に、ユーザによって操作されるクライアントマシンにおいて、ＲＡＭ２０１に割り当てられるデータバッファについて説明する。このデータバッファは、音色データ等を記憶するための領域であり、そのメモリマップについては、図３に示す通りである。この図に示すように、データバッファは、使用音色データバッファ３１０、演奏イベントデータバッファ３２０および音色編集データバッファ３３０の３つの領域に分けられる。
【００１５】
このうち、使用音色データバッファ３１０には、音色に関する音色データが、演奏の際に用いる音色の数だけ、それぞれボイス（音色）バッファ（１）〜（ｎ）にセットされる。すなわち、演奏の際に用いる音色の数だけ、それらの音色に対応する音色データが、ボイスバッファ（１）〜（ｎ）にそれぞれセットされる。いま、ひとつボイスバッファについてみると、ヘッダを記憶するための領域と、楽音パラメータに関するデータを記憶するための領域とから構成される。ここで、ヘッダには、その音色の名称や、その音色を発生すべき音源、発音チャンネル、ＭＩＤＩチャンネルなどの管理情報等を含む。また、楽音パラメータとは、その音色の特性を規定するデータであって、本発明において編集対象とするデータをいい、通常、複数である。
【００１６】
次に、演奏イベントデータバッファ３２０には、演奏の過程において発音や消音などのイベントを時系列的に示すイベントデータと、そのイベント間隔を示すデュレーションデータ（いずれも図示省略）とが対になってセットされる。演奏の際には、この演奏イベントバッファにセットされたデータが参照されるようになっている。
【００１７】
また、音色編集データバッファ３３０には、ボイスバッファ（１）〜（ｎ）にセットされた音色データのうち、編集の対象となった音色データのみが、当該ボイスバッファからエディトバッファ（１）〜（ｍ）のいずれかに複写されてセットされる。いま、ひとつのエディトバッファについてみると、イニシャルデータを記憶するための領域と、エディトデータを記憶するための領域とに分けられる。ここで、イニシャルデータとは、編集前の音色データをいい、エディトデータとは、ユーザの操作にしたがって編集されて、値が変更された音色データをいい、いずれも、ヘッダおよびパラメータからなる。
【００１８】
したがって、編集の対象とする音色を選択した直後であって、実際に編集する前においては、イニシャルデータを記憶する領域とエディトデータを記憶する領域とにおいては、編集の対象となった音色データがそれぞれセットされることになる。
また、編集終了後、エディトデータを複写元のボイスバッファに返送して格納すれば、編集された音色で楽音を発生することになる。
くわえて、編集終了後、エディトデータを別途セーブすれば、新規音色を登録することになる。
なお、ＲＡＭ２０１には、音色データおよび演奏イベントデータ以外のデータもセットされるが、本発明とは直接関係しないので、その説明を省略することとする。
【００１９】
＜２：動作フロー＞
次に、本実施形態にかかる楽音パラメータ編集装置の動作フローについて説明する。ここでは、説明の便宜上、クライアントマシンとサーバマシンとに分けて動作を説明する。
【００２０】
＜２−１：クライアントの動作フロー＞
まず、ユーザが操作するクライアントマシンの動作フローについて、図４を参照して説明する。
はじめに、クライアントマシンに電源が投入されると、そのＣＰＵ２００は、ステップＳａ１において、ＲＡＭ２０１におけるメモリチェックやデータバッファの領域確保など、ＯＳにしたがった初期化処理を実行する。
この後、ＣＰＵ２００は、ステップＳａ２において、タスク起動イベント検出を行なう。詳細には、ユーザがマウス２０９やキーボード２１０を用いて操作することなどによって発生する状態変化（イベント）を検出する。ここで、ユーザは、例えば、タスクを図像化したアイコンをダブルクリックしてタスクの起動指示を行なったり、所定のキー操作で各種の指示を行なったりする。このような各種の指示は、一般にＯＳに依存するものである。
そして、ＣＰＵ２０１は、ステップＳａ３において、アプリケーション・タスク管理を実行して、検出イベントに応じて処理の分岐を行なう。なお、ステップＳａ３における管理内容は、クライアントマシンの環境によって異なるので、図示の例は、単なる一例に過ぎない。
【００２１】
以下、この分岐について説明する。
ステップＳａ２において検出されたイベントが音源処理に関する指示であれば、ＣＰＵ２００は、ステップＳａ４において、上述した第１のプログラムにより、音源処理あるいは音源制御処理を実行する。ここで、音源処理とは、例えば、現時点において設定されている楽音パラメータにより規定されている音色を音源回路２０４やＭＩＤＩ機器２０７などを用いて試験的に発音させる処理などをいい、また、音源制御処理とは、例えば、音源回路２０４あるいはＭＩＤＩ機器２０７に関する状態の設定や変更などの処理をいう。このような音源処理あるいは音源制御処理は、従来より一般的に行なわれているものであり、本発明とは、特に関係しないので、これ以上の説明を省略することとする。なお、この音源処理あるいは音源制御処理が終了すると、ＣＰＵ２００は、処理手順を再びステップＳａ２に戻して、新たな指示を待ち受ける。
また、ステップＳａ２において検出されたイベントが音色編集処理に関する指示であれば、ＣＰＵ２００は、ステップＳａ５において、上述した第２のプログラムにより、後述するボイス・エディタ処理をオフラインで実行する。
【００２２】
一方、ステップＳａ２において検出されたイベントが演奏情報処理に関する指示であれば、ＣＰＵ２００は、ステップＳａ６において、上述した第１のプログラムにより、音源回路２０４やＭＩＤＩ機器２０７を用いて演奏情報処理を実行する。ここで、演奏情報処理とは、例えば、音源回路２０４やＭＩＤＩ機器２０７を用いて、曲データをロードし、これにしたがって実際に演奏を行なう処理などをいう。このような演奏情報処理についても、従来より一般的に行なわれているものであり、本発明とは、特に関係しないので、これ以上の説明を省略することとする。なお、この演奏情報処理が終了すると、ＣＰＵ２００は、処理手順を再びステップＳａ２に戻して、新たな指示を待ち受ける。
あるいは、ステップＳａ２において検出されたイベントがブラウザ処理に関する指示であれば、ＣＰＵ２００は、ステップＳａ７において、上述した第３のプログラムにより、後述するブラウザ処理を実行する。
なお、ステップＳａ２において検出されたイベントがこれら以外の処理に関する指示であれば、ＣＰＵ２００は、それに応じた処理を実行した後、処理手順を再びステップＳａ２に戻して、新たなイベントを待ち受ける。ただし、終了指示であれば、ＣＰＵ２００は、所定の終了処理を実行した後、処理手順をステップＳａ２に戻さないで、そのまま終了するものとする。
【００２３】
＜２−１−１：ボイス・エディタ処理＞
ここで、上述したステップＳａ５において実行されるボイス・エディタ処理の詳細について図５を参照して説明する。
なお、このプログラムは、上述したように必須ではないが、従来技術との比較する意味で説明することとする。
まず、ＣＰＵ２００は、ステップＳａ５０１において、ユーザによる操作や、タスク管理状態などのイベントを解析し、さらに、ステップＳａ５０２において、それに応じて処理の分岐を行なう。
【００２４】
詳細には、当該イベントが、編集の対象とする音色（ボイス）データを選択する旨の操作イベントであれば、ＣＰＵ２００は、ステップＳａ５０３において、編集対象にされた音色データを当該ボイスバッファから、エディトバッファのうちのイニシャルデータを記憶する領域とエディトデータを記憶する領域とにそれぞれ複写して格納する。この後、ＣＰＵ２００は、ステップＳａ５０４において、当該音色データを編集するための編集初期（ウィンドウ）画面を新規作成して、ディスプレイ２１１に表示させる処理を実行する。したがって、ボイス・エディタ処理では、編集対象となっている音色データの数だけウィンドウ画面が開くことになる。
【００２５】
また、解析されたイベントが、ウィンドウを切り換える指示イベントであれば、ＣＰＵ２００は、ステップＳａ５０５において、指示された音色データに対応するウィンドウ画面をアクティブとし、他を非アクティブとする処理を実行する。
あるいは、当該イベントが、編集処理に関する指示イベントであれば、ＣＰＵ２００は、ステップＳａ５０６において、対応する設定変更編集処理を実行する。例えば、楽音パラメータの値を変更する指示であれば、当該エディトデータにおける値を変更後の値に書き換える。また、楽音パラメータの値を転写する指示であれば、転写先のデータを転写元のデータに書き換える。またあるいは、楽音パラメータの値を登録する指示であれば、そのデータをストレージ・ユニット２０２に記憶させる。このように、ステップＳａ５０６においては、編集処理に関する処理が実際に実行される。
その他、当該イベントが、ボイス・エディタ処理を終了させる指示イベントであれば、ＣＰＵ２００は、ステップＳａ５０７において、すべてのウィンドウ画面を閉じるとともに、このボイス・エディタ処理自体を終了させる終了処理を実行する。
【００２６】
なお、ステップＳａ５０４〜Ｓａ５０７のいずれかの処理を実行すると、ＣＰＵ２００は処理手順を図４におけるステップＳａ２に戻し、新たなイベントを待ち受けることとなる。
このように、ボイス・エディタ処理では、楽音パラメータを含む音色データの編集が、ネットワークを介することなくオフラインで、すなわち、クライアントマシン単体で実行できるので、一見、都合が良いよう思われる。
しかし、これは、編集の対象となった音色がクライアントマシンにインストールされたボイス・エディタに対応している場合だけに限っての話であり、非対応の場合には、編集ができない。また、編集の対象として想定される音色のすべてに対応するボイス・エディタを用意するのは、ユーザにとって酷となるばかりでなく、ストレージユニット２０２の記憶容量を圧迫することにもなる。
【００２７】
＜２−１−２：ブラウザ処理＞
そこで、次に、本実施形態において重要なブラウザ処理の詳細について図６を参照して説明する。
まず、ＣＰＵ２００は、ステップＳａ７０１において、ユーザによる操作や、タスク管理状態などのイベントを解析し、次のステップＳａ７０２において、それに応じて処理の分岐を行なう。
【００２８】
＜２−１−２−１：起動＞
詳細には、当該イベントが、ブラウザ処理を起動する操作イベントであれば、ＣＰＵ２００は、ステップＳａ７０３においてブラウザの初期画面を表示して、以後、次の指示等を受けるべく、処理手順を図４のステップＳａ２に戻す。
【００２９】
＜２−１−２−２：エディタ選択＞
一方、ステップＳａ７０１において解析されたイベントが、エディタを選択する操作イベントであれば、ＣＰＵ２００は、ステップＳａ７０４において、エディタリンク処理を実行する。
ここで、ブラウザ処理においては、多数の音色にかかる楽音パラメータを編集するための複数のエディタについてリンクするようになっている。このため、ユーザが楽音パラメータを編集する場合、複数のエディタのうちのいずれかを、編集の対象となる音色に応じて選択することになる。いま、ユーザによりエディタが選択されると、ＣＰＵ２００は、当該エディタを示すデータEDITyや、当該エディタの編集画面データを送信する旨の要求などを、ネットワークにおいて汎用のエディタを記憶するサーバマシンＳ１に向けて送信する。なお、サーバマシンＳ１にデータを送信する方法としては、当該サーバマシンに相当するＩＰ（インターネット・プロトコル）アドレスを指定することなどで可能である。また、編集画面データとしては、例えばＨＴＭＬ（ハイパー・テキスト・マークアップ・ランゲージ）形式が好適である。
そして、ＣＰＵ２００は、エディタリンク処理を実行した後、ステップＳａ７０５において、動作モードを後述する受信モードに移行させ、サーバマシンＳ１からのデータ返送に備えるべく、処理手順を図４のステップＳａ２に戻す。
【００３０】
＜２−１−２−３：編集モード＞
また、ステップＳａ７０１において解析されたイベントが、編集モードへの移行を示す管理イベントであれば、ＣＰＵ２００は、ステップＳａ７０６において、編集画面上での編集入力操作に対応した処理を実行する。
なお、ここでの編集画面は、後述する受信モードにおいてサーバマシンＳ１から受信したデータに基づいて作成されたものであって、ユーザが選択したエディタに対応するものである。また、この編集入力操作においては、少なくとも編集対象の音色がユーザによって選択されるものとする。したがって、この時点においては、編集対象となった音色にかかる音色データが当該ボイスバッファからエディトバッファのうちのイニシャルデータを記憶する領域とエディトデータを記憶する領域とにそれぞれ格納されている。
ここで、ステップＳａ７０６における編集入力操作は、様々な態様が考えられる。例えば、編集対象となった音色がピアノ音であって、その楽音パラメータのうちの振幅エンベロープに関するものを編集する場合、図１０に示すように、その振幅エンベロープの時間的変化を示す形状を、ユーザがマウス２０９を操作して、そのポインタＰをＰ’に移動させ、任意に変化させることで行なわれる。
この場合において図１０に示す編集画面も、後述するように、選択したエディタに対応して、サーバマシンＳ１から返送されたデータに基づいて作成されたものである。
【００３１】
次に、ＣＰＵ２００は、ステップＳａ７０７において、ユーザによる編集入力作業が完了したか否かを判別し、この判別結果が「Ｎｏ」であれば、当該編集入力作業が完了するまで待ち受けるべく、処理手順を図４のステップＳａ２に戻す一方、「Ｙｅｓ」であれば、次のステップＳａ７０８において、当該編集入力結果を示すデータDATASETをサーバマシンＳ１に送信する。
なお、ここでいう編集入力結果とは、図１０に示す編集画面を例にとって説明すれば、振幅エンベロープの時間的変化を示す形状を定める各座標点であって、ユーザにより形状変化させられた後の各座標点をいう。すなわち、編集入力結果を示すデータDATASETとは、楽音パラメータの値そのものではなく、楽音パラメータを間接的に定義付ける得るデータであって、ユーザにより編集操作された後のデータをいう。このため、ステップＳａ７０６においてＣＰＵ２００は、ユーザによる編集操作からデータDATASETを求める処理も同時に実行している。
そして、この後、ＣＰＵ２００は、ステップＳａ７０９において動作モードを後述する受信モードに移行させ、サーバマシンＳ１からのデータ返送に備えるべく、処理手順を図４のステップＳａ２に戻す。
【００３２】
＜２−１−２−４：受信モード＞
一方、ステップＳａ７０１において解析されたイベントが、受信モードへの移行を示す管理イベントであれば、ＣＰＵ２００は、ステップＳａ７１０において、サーバマシンＳ１からの返送されたデータを受信して、解析するとともに、このデータに基づき実際にディスプレイ２１１に画面の表示等を行なう。この後、ＣＰＵ２００は、ステップＳａ７１１において、サーバマシンＳ１から関連するすべてのデータを受信したか否かを判別し、その判別結果が「Ｎｏ」であれば、以後、データ受信を完了すべく、処理手順を図４のステップＳａ２に戻す。
一方、この判別結果が「Ｙｅｓ」であれば、ＣＰＵ２００は、ステップＳａ７１２において、受信したデータがデータPARSETであったか否かを判別する。ここで、データPARSETとは、楽音パラメータそのものを示すデータであって、データDATASETに基づく演算結果というべきものである。
【００３３】
この判別結果が「Ｎｏ」であれば、それは、サーバマシンＳ１から受信すべきデータをすべて受信した状態であって、かつ、受信データが例えば編集画面データであり、以降、ユーザによる編集入力待ちとすべき状態であることを意味するから、ＣＰＵ２００は、ステップＳａ７１３において、今までの受信モードを解除して、編集モードへ移行させる。
一方、ステップＳａ７１２の判別結果が「Ｙｅｓ」であれば、それは、サーバマシンＳ１から受信すべきデータをすべて受信した状態であって、かつ、受信データがサーバマシンＳ１等によって生成されたデータPARSETであるから、ＣＰＵ２００は、ステップＳａ７１４において、当該データPARSETをエディトバッファに転送し、対応するエディトデータを記憶する領域にそれぞれ複写して格納する処理や、当該楽音パラメータおよびそれに合わせた時間的形状をディスプレイ２１１に表示する処理する処理などを実行する。
なお、この判別結果が「Ｙｅｓ」となる場合は、前述した編集モードにおいて、少なくとも、編集対象となる音色が選択され、その編集作業が完了し、その編集結果がサーバマシンＳ１に送信された状態を前提としている。このため、編集対象にされた音色にかかる音色データが当該ボイスバッファからエディトバッファにおけるイニシャルデータを記憶する領域とエディトデータを記憶する領域とにそれぞれ格納されている。したがって、ステップＳａ７１４において、対応するエディトデータを記憶する領域とは、編集対象となった音色データが格納されたボイスバッファにかかるものである。
そして、ＣＰＵ２００は、ステップＳａ７１５において受信モードを解除し、以後、新たな操作指示等を待ち受けるべく、処理手順を図４のステップＳａ２に戻す。
【００３４】
＜２−１−２−５：終了モード＞
最後に、ステップＳａ７０１において解析されたイベントが、ブラウザ処理を終了する指示であれば、ＣＰＵ２００は、ステップＳａ７１６において、このブラウザ処理に関連して開いたウィンドウ画面をすべて閉じるなどの終了処理を実行した後、新たなタスクの起動検出等を行なうべく、処理手順を図４におけるステップＳａ２に戻す。
【００３５】
＜２−２：サーバの動作＞
次に、ユーザが関与しないサーバマシンの動作フローについて、図７を参照して説明する。
はじめに、サーバマシンに電源が投入されると、そのＣＰＵ２００は、ステップＳｂ１においてＯＳにしたがった初期化処理を実行した後、次のステップＳｂ２において、受信状態や操作状態などのタスクに関するイベントを検出する。
そして、ＣＰＵ２００は、ステップＳｂ３において、当該イベントに応じて処理を分岐して、当該イベントがオンライン・エディタ処理に関するものであれば、ステップＳｂ４においてオンライン・エディタ処理を実行する一方、その他のイベントに関するもの（例えば、当該サーバの電源終了指示など）であれば、ステップＳｂ５において、そのイベントに応じた処理（例えば、当該サーバの電源終了処理）を実行する。そして、サーバマシンのＣＰＵは、ステップＳｂ４あるいはＳｂ５の処理を実行すると、新たなタスクに関するイベントを検出すべく、処理手順をステップＳｂ２に戻す。
【００３６】
＜２−２−１：オンライン・エディタ処理＞
ここで、ステップＳｂ２において実行されるオンライン・エディタ処理の詳細について図８を参照して説明する。
まず、サーバマシンのＣＰＵ２００は、ステップＳｂ４０１において、このオンライン・エディタ処理に関するイベントの解析を行ない、ステップＳｂ４０２において、当該イベントに応じたタスク管理を実行する。詳細には、以下の処理が実行される。
【００３７】
＜２−２−１−１：受信したデータEDITyのチェック＞
すなわち、ステップＳｂ４０１において解析されたイベントが、ステップＳａ７０４（図６参照）においてクライアントマシンにより送信されたデータEDITyの受信を示すイベントであれば、当該サーバマシンのＣＰＵ２００は、ステップＳｂ４０３において、自身のサーバマシンが当該データEDITyにより示されるエディタに対応しているか否かを判別する。すなわち、クライアントマシンにおいて編集の対象とする音色に応じてエディタが選択され、そのエディタを示すデータEDITyがサーバマシンを特定して送信されるが、この際に特定されたサーバマシンが、そのエディタを用いて編集入力されたデータDATASETに基づいて、楽音パラメータのデータPARSETを生成することが可能であるか否かを、当該サーバマシンのＣＰＵ２００が判別するのである。
例えば、図１に示すネットワークの例にあっては、サーバマシンＳ１が汎用エディタのみに対応しているから、データEDITyにより示されるエディタが汎用エディタであって、これをサーバマシンＳ１が受信したならば、判別結果が「Ｙｅｓ」となる。一方、データEDITyにより示されるエディタが特殊エディタであって、これをサーバマシンＳ１が受信したならば、当該サーバマシンは特殊エディタに対応していないので判別結果が「Ｎｏ」となる。
【００３８】
実際に判別結果が「Ｙｅｓ」であれば、当該サーバマシンのＣＰＵ２００は、ステップＳｂ４０４において、動作モードを、以降の処理を自身のサーバマシンで実行するサーバ・エディトモードに移行させ、次のステップＳｂ４０５において、受信したデータEDITyに対応するエディタのプログラムを起動するとともに、そのエディタに対応する編集画面データを、当該データEDITyの発信元であるクライアントマシンに返送する。
一方、この判別結果が「Ｎｏ」であれば、当該サーバマシンのＣＰＵ２００は、ステップＳｂ４０６において、動作モードを、以降の処理を他のマシンで実行させるローカル・エディトモードに移行させ、次のステップＳｂ４０７において、第１に、当該データEDITyで示されるエディタに対応するマシンをネットワーク上でサーチし、あるいは、予め登録しておいた中から特定し、第２に、そのマシンに対して、当該データEDITyに対応するエディタプログラムの起動を指示する。
例えば、図１に示すネットワークの例において、データEDITyにより示されるエディタが特殊エディタであって、これをサーバマシンＳ１が受信したならば、当該マシンは、特殊エディタに対応するクライアントマシン１１０nに対して上記指示を行なう。
【００３９】
そして、ステップＳｂ４０５あるいはＳｂ４０７の処理を実行すると、当該サーバマシンのＣＰＵは、以後、新たなイベントを待ち受けるべく、処理手順を図７に示すステップＳｂ２に戻す。
このように、クライアントマシンからデータEDITyを受信したサーバマシンは、自身が当該データEDITyに対応しているか否かに応じて、動作モードを、サーバ・エディトモードあるいはローカル・エディトモードのいずれかに移行させ、以後、この移行を管理イベントとして検出・解析して、その動作モードに応じた処理を実行することとなる。
【００４０】
＜２−２−１−２：サーバ・エディトモード＞
そこでまず、動作モードがサーバ・エディトモードに移行した場合の動作について説明する。
ステップＳｂ４０１において解析されたイベントが、サーバ・エディトモードへの移行を示す管理イベントであれば、サーバマシンのＣＰＵ２００は、ステップＳｂ４０８においてデータDATASETを受信する。すなわち、データEDITyで示されるエディタを用いて編集入力された結果を示すデータを受信する。
次に、ＣＰＵ２００は、ステップＳｂ４０９において、データDATASETをすべて受信したか否かを判定し、判別結果が「Ｎｏ」であれば、以後、受信を完了すべく、処理手順を図７のステップＳｂ２に戻す一方、この判別結果が「Ｙｅｓ」であれば、次のステップＳｂ４１０において、データEDITyに対応して起動したエディタプログラムを用いて、受信の完了したデータDATASETから楽音パラメータを示すデータPARSETを生成する。
そして、ＣＰＵ２００は、ステップＳｂ４１１において、生成したデータPARSETをデータEDITyの発信元であるクライアントマシンに返送する。以後、ＣＰＵは、新たな編集入力結果や他のイベントなどを検出すべく、処理手順を図７のステップＳｂ２に戻す。
このように、サーバ・エディトモードでは、楽音パラメータを示すデータPARSETが、クライアントマシンによる編集入力結果を示すデータDATASETから生成されて、当該クライアントマシンに返送されることとなる。
【００４１】
＜２−２−１−３：ローカル・エディトモード＞
次に、動作モードがローカル・エディトモードに移行した場合の動作について説明する。
ステップＳｂ４０１において解析されたイベントが、ローカル・エディトモードへの移行を示す管理イベントであれば、サーバマシンのＣＰＵ２００は、ステップＳｂ４１２において、クライアントマシンと、先のステップＳｂ４０７でサーチあるいは特定した他のマシンとの間において、データの中継を行なう。
【００４２】
ここで、中継されるデータとしては、クライアントマシンから他のマシンへの方向にあっては、データEDITyや、そのエディタによる編集入力結果を示すデータDATASETなどがある一方、他のマシンからクライアントマシンへの方向にあっては、エディタに対応する編集画面データや、当該他のマシンにより生成された楽音パラメータのデータPARSETなどがある。
以後、ＣＰＵは、新たな編集入力結果や他のイベントなどを検出すべく、処理手順を図７のステップＳｂ２に戻す。
このように、ローカル・エディトモードにおいてサーバマシンは、クライアントマシンと他のマシンとのデータ中継のみを行なう。これは、サーバマシンがデータEDITyで示されるエディタに対応していないので、編集入力結果を示すデータDATASETから楽音パラメータのデータPARSETを生成することができないためである。
【００４３】
＜３：具体的動作＞
次に、本実施形態の具体的動作について、実際にユーザが楽音パラメータをオンラインで編集する場合を例にとって説明する。
前提として、ネットワーク上におけるクライアントマシンおよびサーバマシンは電源が投入されて、すでに初期化処理（ステップＳａ１、Ｓｂ１）は実行されているものとする。
【００４４】
まず、ユーザは、例えばクライアントマシン１３０1を操作して、マウス２０９やキーボード２１０などを用いてブラウザの起動を指示する。すると、当該クライアントマシンでは、その起動指示がイベントとして検出される結果、ステップＳａ７（図４参照）においてブラウザ処理が実行され、そのステップＳａ７０３（図６参照）においてブラウザの初期画面が当該クライアントマシンのディスプレイ２１１に表示される。
次に、ユーザは、この初期画面において、編集の対象とする音色に対応して例えば汎用エディタを選択するとともに、とりあえず相手先としてサーバマシンＳ１を指定する。すると、当該クライアントマシンでは、その選択指示がイベントとして解析され、ステップＳａ７０４（図６参照）において当該エディタを示すデータEDITy、および、そのデータEDITyに対応する編集画面データを要求する旨の情報がサーバマシンＳ１に送信され、続くステップＳａ７０５において動作モードが受信モードに移行する。
【００４５】
一方、サーバマシンＳ１において、クライアントマシンからのデータEDITy等が受信されると、これがイベントとして検出される結果、ステップＳｂ４（図７参照）においてオンライン・エディタ処理が実行され、そのステップＳｂ４０３〜Ｓｂ４０５（図８参照）の処理が実行される。すなわち、動作モードがサーバ・エディトモードに設定され、当該データEDITyに対応するエディタプログラムが起動され、さらに、当該データEDITyに対応する編集画面データが、当該クライアントマシンに返送される。
【００４６】
これに対し、クライアントマシン１３０1においては、すでに動作モードが受信モードに移行しているので、編集画面データの受信が検出されると、これがイベントとして検出される結果、ステップＳａ７１０〜７１３（図６参照）の処理が実行される。この結果、当該編集画面データに基づく表示画面がディスプレイ２１１に表示されるとともに、受信モードが解除されて、動作モードが編集入力モードに移行される。そして、この動作モードの移行が管理イベントとして検出される結果、ユーザは、当該クライアントマシンにおいてステップＳａ７０４の編集入力が可能となる。
そこで、ユーザは、例えば編集表示画面（図１０参照）において、時間的変化の形状を定める各座標点のような、楽音パラメータを間接的に定義付ける編集操作を行なう。すると、クライアントマシンでは、ステップＳａ７０８において編集入力結果を示すデータDATASETがサーバマシンＳ１に送信され、続くステップＳａ７０９において、動作モードが再び受信モードに移行される。
【００４７】
一方、サーバマシンＳ１においては、すでに動作モードがサーバ・エディトモードに移行しているので、データDATASETが受信されると、これがイベントとして検出される結果、ステップＳｂ４０８〜４１１（図８参照）の処理が実行される。この結果、データDATASETがすべて受信されると、これに基づき楽音パラメータPARSETが生成されて、クライアントマシン１３０1に送信される。
【００４８】
これに対し、クライアントマシン１３０1においては、動作モードが再び受信モードに移行しているので、楽音パラメータを示すデータPARSETが受信されると、これがイベントとして検出される結果、今度は、ステップＳａ７１０〜７１２、７１４、７１５（図６参照）の処理が実行される。この結果、すべて受信された楽音パラメータを示すデータPARSETが、編集対象となった音色データが格納されたボイスバッファであって、そのエディトデータを記憶する領域に複写されて記憶されるとともに、その値や形状などがディスプレイ２１１の画面に表示された後、受信モードが解除される。すなわち、ユーザは、編集入力の結果たる楽音パラメータのデータPARSETを得ることになる。
なお、この楽音パラメータによって規定される音色を実際に発音させたり、実際に演奏に用いるのは、音源処理や演奏情報処理など（いずれも図４参照）を実行すれば良い。
【００４９】
以後、新たな編集入力を指示することによって、編集入力が繰り返し可能であり、また、別の音色に関して楽音パラメータを編集の対象とすることも可能となる。
なお、以上述べた具体例においては、ユーザが汎用エディタを選択した場合であったが、エディタとして特殊エディタや、専用エディタ、高機能エディタなどを選択した場合にあっても、その選択に際しユーザはサーバマシンＳ１を指定すれば良い。
この場合、サーバマシンＳ１は、これらのエディタに対応していないので、ローカル・エディトモードとなる。しかし、この場合であっても、これらのエディタに対応するクライアントマシン１１０nがネットワーク上にあれば、サーバマシンＳ１の代わりに、同じ処理を実行して、当該エディタに対応する編集画面データの送信や、データDATASETに基づいて楽音パラメータのデータPARSETの生成・送信を行なう一方、サーバマシンＳ１がデータ中継を行なうようにすれば良い。このようにすれば、ユーザにとって、選択したエディタがサーバマシンＳ１において対応するか否かを意識する必要はない。
【００５０】
以上のように、ユーザは、編集対象とする音色にあわせてエディタを選択すれば、当該エディタに対応する編集画面データがサーバマシンＳ１から返送され、さらに、その編集画面においてその音色の楽音パラメータに関する操作編集を行なうと、それに応じた楽音パラメータを得るので、自身のクライアントマシン１３０1が選択したエディタに対応する必要がなくなる。すなわち、ユーザは、クライアントマシン１３０1において、編集の対象として想定される音色を、すべてカバーする分のエディタをインストールしなくても、本実施形態にかかかるブラウザだけをインストールしておけば良いのである。
通常、サーバマシンＳ１や、その配下にあるクライアントマシン１１０1のようなマシンは、ユーザが管理する必要がなく、ネットワークを介して、メーカやいわゆるサードパーティーなどが管理すれば良いのである。
したがって、ユーザにとっては、エディタプログラムのような編集プログラムなどを複数用意することなく、多数の音色にかかる楽音パラメータに関して編集可能となる。
【００５１】
＜４：応用形態＞
上述した実施形態においては、編集の対象とする音色をピアノ音として、その振幅エンベロープを編集する例にとって説明した。
しかし、本発明はこれに限られず、自然楽器における空気の流れを電気的モデルによりシミュレートする物理モデル音源のような、複雑な演算を必要とする楽音パラメータも、もちろん編集可能である。
そこで、応用形態として、物理モデル音源の楽音パラメータを編集する場合について説明する。
【００５２】
＜４−１：物理モデル音源＞
まず、動作の説明する前に、物理モデル音源の概要について簡単に説明しておく。図１１は、自然楽器のうちの管楽器の楽音を合成する物理モデル音源の一例を示すブロック図である。この物理モデル音源は、同図に示すように、管楽器における管体の物理的性質を電気的に模擬したシミュレートした管体シミュレート部２０と、演奏者による演奏操作等に基づいて励起信号を生成し、管体シミュレート部２０に供給する励振回路１０とから構成される。なお、この物理モデル音源は、たとえば、ユーザが操作するクライアントマシンのＣＰＵ２００によりソフトウェア的に構築されたり、ＭＩＤＩ機器２０７においてハードウェア的に実現されるものであり、励振回路１０および管体シミュレート部２０における種々のパラメータは、後述するように、ユーザの編集入力結果や、演奏操作に基づいて制御されるようになっている。
【００５３】
図１１に示すように、この励振回路１０における減算器１１の減算入力端（−）には、マウスピースに吹き込まれる圧力ｐ（口内圧力）に相当する信号が、演奏操作を検出するセンサ（図示省略）に従って生成されて供給される。一方、減算器１１の加算入力端（＋）には、後述するように、マウスピース内の圧力ｑを示す信号であって、管体の反射がシミュレートされた信号が供給される。このため、減算器１１の出力信号は、マウスピースとリードとの間隙における空気圧力差Δｐに相当する信号となる。ローパスフィルタ１２は、リードの動きをシミュレートするものであり、入力信号を帯域制限して出力する。このように、帯域制限を行なうのは、圧力変化に対するリードの追従性をシミュレートするためである。より詳細には、リードの圧力が変化した場合、リード自身には慣性等が働くため、リードの変位に遅れが生じ、さらに、圧力変化の周波数が高くなるとリードは徐々に反応しなくなるという特性をシミュレートするためである。
【００５４】
また、ローパスフィルタ１２には、その特性を演奏操作等にしたがって制御するためのパラメータＦｃ、Ｑが供給され、これらパラメータによりそれぞれカットオフ周波数、Ｑ値が設定されるようになっている。
ローパスフィルタ１２の出力には、リードに加える圧力を示すアンブシュアデータたる信号Ｅが加算器１３によって加算され、実際にリードに加えられる圧力に相当する信号が求められる。そして、この信号は、非線形テーブル１４によって、マウスピースとリードとの間隙部分の断面積Ｓに相当する信号に変換されて、乗算器１５の一方の入力端に供給される。
【００５５】
一方、マウスピースとリードとの間隙における空気圧力差Δｐを示す信号は、非線形テーブル１６にも供給される。この非線形テーブル１６は、空気の圧力差が大きくなっても狭い管路では流速が飽和して差圧と流速とが比例しないことをシミュレートするものであり、これにより、リード部での空気圧が流速に与える影響を考慮して補正した、空気圧に相当する信号が得られるようになっている。
そして、かかる非線形テーブル１６の出力信号は乗算器１５の他方の入力端に供給されて、リードの間隙（部分の断面積）Ｓを示す信号と乗算され、この乗算結果が、マウスピースとリードとの間隙における体積流速に相当する信号ｆとなって、乗算器１７に供給される。この信号ｆは、乗算器１７によって、マウスピースの（抵抗に相当する）特性インピーダンスｚを示す信号と乗算され、マウスピースから管体に送り込まれる空気に相当する音圧信号ｆｚとなり、励振信号として管体シミュレート部２０に供給される。このようにして、励振回路１０では、管楽器のリードを含む励振部が電気的にシミュレートされるようになっている。
【００５６】
＜４−２：管体シミュレート部＞
次に、管体シミュレート部２０について説明する。
この管体シミュレート部２０は、音圧信号ｆｚを信号ｑとして帰還するものであり、該帰還路には、ローパスフィルタや遅延回路が介挿されている。このうちのローパスフィルタは、管体、特に共鳴管の形状をシミュレートするものであり、また、遅延回路は、共鳴管の長さ、および、トーンホールの長さに対応してマウスピースからの入射波が反射波としてマウスピースに戻ってくる状態をシミュレートするものである。この場合、遅延回路の遅延時間は、発生楽音の音高により制御されるようになっている。厳密に言えば、帰還路のローパスフィルタにおいても遅延が発生するので、発生楽音の音高の制御は、管体シミュレート部２０の一巡当たりの遅延時間が音高に対応したものとなるように、ローパスフィルタによる遅延時間を考慮しつつ、遅延回路の遅延時間を制御することにより行なわれる。
なお、この応用形態においては、シミュレートする管体の形状、種類等に応じていくつかのアルゴリズムが用意され、いずれか１つが選択可能なように構成されているが、以下においては、説明の関係上、代表的なアルゴリズムを例にとって説明する。
【００５７】
＜４−２−１：代表的なアルゴリズム＞
この代表的なアルゴリズムについて図１２を参照して説明する。このアルゴリズムは、図１５に示すような管体形状（径が異なる円筒の集合）をシミュレートして、管楽器のすべてのトーンホールおよびレジスタチューブの開閉（中途半端に開いた状態も含める）の組合せを近似し、なおかつ、任意形状の管体を実現しうるアコースティック楽器に最も近いものである。
図１２において、記号ＳＲと添字で示されるものは、シフトレジスタであり、管体における空気圧力波の伝搬遅延をシミュレートするものである。記号Ｊと添字で示されるものは、ジャンクション部であり、管体の径が変化している地点において発生する空気圧力波の散乱をシミュレートするものである。また、ＬＰＦはローパスフィルタであり、管体の終端部において空気圧力波が反射する際にエネルギー損失等をシミュレートするものである。
【００５８】
また、ジャンクション部Ｊ１、Ｊ２、Ｊ５は、トーンホールを有さず段差のみを有するもの（２ポート・ジャンクション）であり、その構成については、例えば、図１３（イ）〜（ロ）のいずれかに示すものとなっている。また、ジャンクション部Ｊ３、Ｊ４、Ｊ６は、高さのあるトーンホールがついたもの（３ポート・ジャンクション）であり、その構成については、図１４に示すものとなっている。
ここで、パラメータα、β、γは、図１５における管の直径φおよびトーンホールの径ψに依存し、また、シフトレジスタＳＲt3等の段数ｍ３、ｍ４、ｍ６は、トーンホールの高さｔ（ｔ３、ｔ４、ｔ６）により決定される。さらに、各シフトレジスタＳＲの各遅延時間は、図１５における各管部の長さｌ１〜ｌ７に対応するとともに、合成すべき楽音の音高に対応するように制御される。また、パラメータγt1、γt2、γt3は、図１５におけるトーンホールが開のときには負、閉のときには正となるように反映される。なお、このアルゴリズムにおいては、ジャンクション部におけるトーンホールの有無なども任意に設定できるようになっている。
以上が物理モデル音源の概要であるが、このアルゴリズムについては、先に述べた特開平５−８０７６１号公報が詳しい。
【００５９】
＜４−２：物理モデルにおける楽音パラメータの編集入力＞
さて、物理モデル音源により発生される音色に関して、ユーザは、上述した管体形状などを編集入力することにより、実際には存在しない楽器の音色を作成することが可能となる。そのためにユーザは、まず、例えば、図１におけるクライアントマシン１３０1を操作して、物理モデル音源に対応する特殊エディタを選択する。これにより、当該クライアントマシンは、選択されたエディタを示すデータEDITyを、サーバマシンＳ１に送信することとなる。ここで、サーバマシンＳ１は、汎用エディタにしか対応していないので、ローカル・エディトモードに設定され、物理モデル音源の特殊エディタに対応するクライアントマシン１１０nに対して、特殊エディタの起動を指示する。これにより、クライアントマシン１１０nは、特殊エディタを起動するとともに、それに対応する編集画面データを送信し、サーバマシンＳ１により中継されて、当該クライアントマシンに返送される。
【００６０】
この場合、編集入力画面としては、例えば、図１５に相当する画面など、シミュレートすべき管体の形状を実際に表示するものが望ましい。このような編集画面上において、ユーザは、各管の直径φ、各管部の長さｌ、トーンホールの有無、その径ψ、および、その高さｔをマウス２０９やキーボード２１０などで指定して入力する。すると、クライアントマシンは、編集入力された値をデータDATASETとしてサーバマシンＳ１に送信し、サーバマシンＳ１はこれを中継して、クライアントマシン１１０nに送信する。これをクライアントマシン１１０nは受信すると、起動した特殊エディタによりデータPARSETを生成して送信し、サーバマシンＳ１はこれを中継して、ユーザが操作したクライアントマシン１３０1に返送する。ここで、データPARSETは、先に説明した図１３のブロック図におけるシフトレジスタＳＲの各段数や、ジャンクション部Ｊの各係数などのパラメータを定めるものである。
そして、クライアントマシン１３０1は、データPARSETを受信して、これに基づいて楽音パラメータを設定するとともに、そのディスプレイ２１１には、設定編集入力した後の管体形状が視覚的に表示されることとなる。
【００６１】
したがって、ユーザにとっては、物理モデル音源用エディタのような特殊なエディタを、自身が操作するクライアントマシンにインストールしておかなくても、物理モデル音源にかかる音色の楽音パラメータを編集することが可能となる。
【００６２】
なお、以上説明した実施形態および応用形態にあっては、編集入力結果を示すデータDATASETから楽音パラメータを示すデータPARSETを、ユーザにより選択されたエディタに対応するマシン等が生成することとしていたが、データDATASETから、その楽音パラメータで規定される音色そのもののサンプリングデータを演算結果として生成する構成としても良い。これにより、ユーザがＭＩＤＩ機器２０７を持たなくても、当該サンプリングデータを再生する機能のみを有していれば、自身が編集入力した結果に基づいて実際に得られるであろう楽音を再生できる一方、メーカ側にしてみれば、それによってユーザが興味をもってＭＩＤＩ機器を購入するであろうと、期待することができる、といった利点もある。
【００６３】
また、ユーザが操作するクライアントマシンの仕様（ユーザ環境）によって、実際にエディタプログラムを実行するネットワーク上のマシンの処理内容や送受するデータ量、種類などを適宜変更するようにしても良い。例えば、エディタの選択状況を送信する際に、選択されたエディタを示すデータEDITyとともに、ユーザ環境や使用機器に関する情報を送信し、実際にエディタ処理を実行するサーバマシンあるいはクライアントマシンにユーザ環境を認知させて、エディタ処理の内容や、規模、送受するデータの形式などをユーザ環境に適合するように指示することが考えられる。具体例としては、ユーザマシンのグラフィック画像表示能力が低い場合（ユーザが意識的にグラフィックデータが不要という設定した場合を含む）に、エディット処理実行マシンからユーザマシンへのエディット結果としての楽音パラメータを示すデータPARSETを送信する処理だけを実行し、関連表示させる画像表示データの生成や送信などの処理については省略するなどして、ユーザ環境に合わせて処理を実行するようにしても良い。この具体例では、各マシンの負荷やネットワークにおけるデータトラフィック量の軽減化も期待できる。
【００６４】
くわえて、実施形態および応用形態にあっては、説明の便宜上、サーバマシンとクライアントマシンとに分けたが、これらは、名称や形態で区別されるべきものではなく、機能で区別されるべき性格のものである。したがって、これらに上述した構成を有する汎用コンピュータや、パーソナルコンピュータなどの機器を用いることができる。さらに、コンピュータの名称に限られず、上述した構成を備える電子楽器に適用して、電子楽器用のパラメータ編集装置として用いても良い。
【００６５】
【発明の効果】
以上説明したように、本発明によれば、多数の音色にかかる楽音パラメータを、編集装置や編集プログラムなどを複数用意することなく編集することが可能となる。また、ユーザは、相手先のコンピュータを一つ特定しておけば、選択したエディタに対応するコンピュータがいずれであるかを、常に意識する必要がなくなる。
【図面の簡単な説明】
【図１】  本発明の実施形態にかかる楽音パラメータ編集装置の構成を示すブロック図である。
【図２】  同実施形態におけるクライアントマシンあるいはサーバマシンの構成を示すブロック図である。
【図３】  同クライアントマシンにおけるＲＡＭ内のメモリマップを示す図である。
【図４】  同実施形態におけるクライアントマシンの動作を示すフローチャートである。
【図５】  同クライアントマシンのボイス・エディタ処理を示すフローチャートである。
【図６】  同ブラウザ処理を示すフローチャートである。
【図７】  同実施形態におけるサーバマシンの動作を示すフローチャートである。
【図８】  同サーバマシンのオンライン・エディタ処理を示すフローチャートである。
【図９】  同実施形態におけるクライアントマシンの編集画面の一例を示す図である。
【図１０】  従来あるいはオフラインボイスエディタ処理の編集画面の一例を示す図である。
【図１１】  本発明の応用形態にかかる物理モデル音源の一例を示すブロック図である。
【図１２】  同物理モデル音源における管体シミュレート部の一例を示すブロック図である。
【図１３】  （イ）、（ロ）、（ハ）は、それぞれ同管体シミュレート部の２ポート・ジャンクション部の一例を示すブロック図である。
【図１４】  同管体シミュレート部の３ポート・ジャンクション部の一例を示すブロック図である。
【図１５】  同管体シミュレート部によってシミュレートされる管体の形状を説明するための図である。
【符号の説明】
Ｓ１……サーバマシン（他のコンピュータ）、１３０1……クライアントマシン（一のコンピュータ）、２００……ＣＰＵ（生成手段）、２０３……ネットワークＩ／Ｆ（第１および第２の送信手段、第１および第２の受信手段）、２０９……マウス、２１０……キーボード
【図１】
0003690173.tif 000002
【図２】
0003690173.tif 000003
【図３】
0003690173.tif 000004
【図４】
0003690173.tif 000005
【図５】
0003690173.tif 000006
【図６】
0003690173.tif 000007
【図７】
0003690173.tif 000008
【図８】
0003690173.tif 000009
【図９】
0003690173.tif 000010
【図１０】
0003690173.tif 000011
【図１１】
0003690173.tif 000012
【図１２】
0003690173.tif 000013
【図１３】
0003690173.tif 000014
【図１４】
0003690173.tif 000015
【図１５】
0003690173.tif 000016