JP3630106B2 - 音データ転送方法、音データ転送装置およびプログラム - Google Patents

Description

【０００１】
【発明の属する技術分野】
この発明は、ハードディスク等、比較的低速な記憶媒体からの波形データの読み出し等に基づき、楽音あるいは音声若しくはその他任意の音の波形を生成する音データ転送方法、音データ転送装置およびプログラムに関し、特に、演奏者により行われた自然楽器固有の各種奏法若しくはアーティキュレーションによる音色変化を忠実に表現した波形を生成するものに関する。この発明は、電子楽器は勿論のこと、自動演奏装置、コンピュータ、電子ゲーム装置その他のマルチメディア機器等、楽音あるいは音声若しくはその他任意の音を発生する機能を有するあらゆる分野の機器若しくは装置または方法において広範囲に応用できるものである。なお、この明細書において、楽音波形という場合、音楽的な音の波形に限るものではなく、音声あるいはその他任意の音の波形を含んでいてもよい意味合いで用いるものとする。
【０００２】
【従来の技術】
波形メモリにおいて、ＰＣＭ（パルス符号変調）あるいはＤＰＣＭ（差分ＰＣＭ）又はＡＤＰＣＭ（適応差分ＰＣＭ）等の任意の符号化方式で符号化した波形データ（つまり波形サンプルデータ）を記憶しておき、これを所望の音楽ピッチに対応して読み出すことにより、楽音波形を形成するようにした、いわゆる「波形メモリ読み出し」技術は既に公知であり、また、様々なタイプの「波形メモリ読み出し方式」技術が知られている。従来知られた「波形メモリ読み出し方式」技術のほとんどは、発音開始から終了までの１つの音の波形を発生するためのものである。一例として、発音開始から終了までの１音の全波形の波形データを記憶する方式がある。また、別の例として、変化の複雑なアタック部などについてはその全波形の波形データを記憶し、変化のあまりないサステイン部などについては所定のループ波形を記憶する方式がある。なお、本明細書において、「ループ波形」とは繰り返し読出し（ループ読出し）される波形という意味で用いるものとする。
【０００３】
波形データを記憶するための手段としては、ＲＯＭ、ＲＡＭ、ハードディスク、ＣＤ−ＲＯＭ等が知られている。ハードディスク、ＣＤ−ＲＯＭ等は単位記憶容量あたりの単価が安価であり大容量のデータ記憶に適している。しかし、ハードディスク等はアクセス時間が遅く、かつ一定していないため、楽音信号を出力するタイミングで必要な波形データを即座に読み出すことは不可能である。このため、以下のように様々な技術が提案されている。
まず、特開平６−３０８９６４号公報においては、ハードディスク等に記憶した複数の波形データの先頭部分を予めＲＡＭに転送しておく技術が開示されている。すなわち、発音指示が供給されると、ハードディスク等の当該波形データの後続部分の読み出しが開始されるとともに予めＲＡＭに記憶された先頭部分が再生される。そして、先頭部分の再生が終了した後に、後続部分の波形データが再生されるのである。
【０００４】
また、特開昭６３−１８１１８８号公報においては、順次発音すべき波形データがシーケンスデータとして予め定義されている場合に、各波形データを順次読み出しながら再生する技術が開示されている。この技術においては、各波形データの読出しを開始する時刻が発音タイミングよりも早くなるように、シーケンスタイミングに対応して予め定められる。
【０００５】
【発明が解決しようとする課題】
しかし、特開平６−３０８９６４号公報に係る技術によれば、予め全ての波形データの先頭部分を予めＲＡＭに転送しておく必要があるため、ＲＡＭの使用効率が低くなるという問題があった。また、特開昭６３−１８１１８８号公報に係る技術は、一回のイベント毎にハードディスク等が必ずアクセスされるため、ハードディスク等の騒音が大きくなり、寿命も短くなる。しかも、ハードディスク等が頻繁にアクセスされることにより、他の処理に割り当てるリソースが少なくなる。
本発明は上述した事情に鑑みてなされたものであり、ハードディスク等に対するアクセス頻度を低減させることができる音データ転送方法、音データ転送装置およびプログラムを提供することを目的としている。
【０００６】
【課題を解決するための手段】
上記課題を解決するため本発明にあっては、下記構成を具備することを特徴とする。なお、括弧内は例示である。
請求項１記載の構成にあっては、楽音波形の音データ（ベクトルデータ）を記憶する低速記憶装置（ハードディスク１０９）と、該音データをキャッシングする高速記憶装置（キャッシュメモリ４４）とを用いて、前記低速記憶装置に記憶された音データのうちの一部を波形合成のために前記高速記憶装置に転送する音データ転送方法であって、使用されることが決定され、または使用されると予測される音データについて順次準備指示を行う（予測制御部４１または奏法合成部１０１Ｃから先読みプリフェッチ部４２へのベクトルＩＤまたはパケットを供給する）準備過程と、予め準備指示され、かつ前記高速記憶装置に記憶されている音データを用いて波形合成の開始指示を行う合成開始指示過程と、前記順次準備指示された音データが前記高速記憶装置に記憶されていない場合に、前記低速記憶装置から前記高速記憶装置に該音データを転送するとともに、該転送された音データに対応するカウント値（メンバdwCount）を初期値（１）に設定する転送過程（ステップＳ４２，Ｓ４３）と前記順次準備指示された音データが前記高速記憶装置に既に記憶されている場合に、該音データに対応するカウント値（メンバdwCount）を増加させるカウントアップ過程と、前記合成開始指示過程による開始指示に応じて、前記音データを用いた波形合成を開始する波形合成過程であって、使用済みの音データに係るカウント値（メンバdwCount）を減少させる（FILLED状態：Ｓ６４におけるプリフェッチ）ものと、前記高速記憶装置に記憶された音データのうち今後の開始指示の予定の無い音データを各音データに対応するカウント値に基づいて決定し、決定した音データを消去可能な状態に設定する（メンバdwCountが「０」に達するとFILLED状態Ｓ６４からUSED状態Ｓ６３に遷移させる）設定過程とを有することを特徴とする。
さらに、請求項２記載の構成にあっては、請求項１記載の音データ転送方法において、イベントシーケンス（演奏データ）から再生開始時刻に先立ってイベントデータを先読みする先読み過程をさらに有し、前記準備過程においては該先読みされたイベントデータに基づいて準備指示に係る音データが決定され、これによって共通の音データが使用される複数のイベントデータに対して、前記転送過程を共用することを特徴とする。
さらに、請求項３記載の構成にあっては、請求項１記載の音データ転送方法において、イベントデータが供給された時刻から所定時間遅れた時刻を再生開始時刻として設定する過程をさらに有し、前記準備過程においては該供給されたイベントデータに基づいて準備指示に係る音データが決定され、これによって共通の音データが使用される複数のイベントデータに対して、前記転送過程を共用することを特徴とする。
さらに、請求項４記載の構成にあっては、請求項１記載の音データ転送方法において、前記準備過程においては、一つのイベントデータに基づいて、同一の音データに対する複数回の前記準備指示が行われ、前記波形合成過程においては、前記一つのイベントデータに対応して前記音データが使用される毎に、前記カウント値がその都度減少されることを特徴とする。
また、請求項５記載の構成にあっては、請求項１ないし４の何れかに記載の方法を実行することを特徴とする。
また、請求項６記載の構成にあっては、請求項１ないし４の何れかに記載の方法を実行することを特徴とする。
【０００７】
【発明の実施の形態】
１．実施形態のハードウエア構成
以下、この発明の一実施形態を添付図面に従って詳細に説明する。
図１は、この発明に係る波形生成装置のハードウエア構成例を示すブロック図である。ここに示されたハードウエア構成例はコンピュータを用いて構成されており、そこにおいて、波形生成処理は、コンピュータがこの発明に係る波形生成処理を実現する所定のプログラム（ソフトウエア）を実行することにより実施される。勿論、この波形生成処理はコンピュータソフトウエアの形態に限らず、ＤＳＰ（ディジタル・シグナル・プロセッサ）によって処理されるマイクロプログラムの形態でも実施可能であり、また、この種のプログラムの形態に限らず、ディスクリート回路又は集積回路若しくは大規模集積回路等を含んで構成された専用ハードウエア装置の形態で実施してもよい。また、この波形生成装置は、電子楽器あるいはカラオケ装置又は電子ゲーム装置又はその他のマルチメディア機器又はパーソナルコンピュータ等、任意の製品応用形態をとっていてよい。
【０００８】
図１に示されたハードウエア構成例においては、コンピュータのメイン制御部としてのＣＰＵ１０１に対して、バスラインＢＬ（データあるいはアドレスバス等）を介してリードオンリメモリ（ＲＯＭ）１０２、ランダムアクセスメモリ（ＲＡＭ）１０３、パネルスイッチ１０４、パネル表示器１０５、ドライブ１０６、波形取込部１０７、波形出力部１０８、ハードディスク１０９、通信インタフェース１１１がそれぞれ接続されている。ＣＰＵ１０１は、後述する「波形データベース作成」や「制作したデータベースに基づく楽音合成（ソフトウエア音源）」等の処理を、所定のプログラムに基づいて実行する。これらのプログラムは、通信インタフェース１１１を介したネットワークあるいはドライブ１０６に装着されたＣＤやＭＯ等の外部記憶メディア１０６Ａ等から供給されてハードディスク１０９に記憶される。そして、実行時にハードディスク１０９からＲＡＭ１０３にロードされる。あるいは、ＲＯＭ１０２にプログラムが記録されていてもよい。ＲＯＭ１０２は、ＣＰＵ１０１により実行あるいは参照される各種プログラムや各種データ等を格納するものである。ＲＡＭ１０３は、演奏に関する各種情報やＣＰＵ１０１がプログラムを実行する際に発生する各種データを一時的に記憶するワーキングメモリとして、あるいは現在実行中のプログラムやそれに関連するデータを記憶するメモリとして使用される。ＲＡＭ１０３の所定のアドレス領域がそれぞれの機能に割り当てられ、レジスタやフラグ、テーブル、メモリなどとして利用される。パネルスイッチ１０４は、楽音をサンプリングする指示やサンプリングされた波形データ等のエディットや各種情報の入力等を行うための各種の操作子を含んで構成される。例えば、数値データ入力用のテンキーや文字データ入力用のキーボード、あるいはパネルスイッチ等である。この他にも音高、音色、効果等を選択・設定・制御するための各種操作子を含んでいてよい。パネル表示器１０５は、パネルスイッチ１０４により入力された各種情報やサンプリングされた波形データ等を表示する、例えば液晶表示パネル（ＬＣＤ）やＣＲＴ等のディスプレイである。
【０００９】
波形取込部１０７はＡ／Ｄ変換器を内蔵し、外部波形入力（例えば、マイクロフォンなどからの入力）されたアナログ楽音信号をデジタルデータに変換（サンプリング）してＲＡＭ１０３あるいはハードディスク１０９に該デジタル波形データをオリジナル波形データ（生成すべき波形データの素材となる波形データ）として取り込むものである。ＣＰＵ１０１によって実行する「波形データベース作成」処理では、上記取り込んだオリジナル波形データを基にして本発明に従う「波形データベース」の作成を行う。また、ＣＰＵ１０１によって実行する「データベースに基づく楽音合成」処理では、上記「波形データベース」を使用して演奏情報に応じた任意の楽音信号の波形データを生成する。勿論、複数の楽音信号の同時発生が可能である。生成された楽音信号の波形データはバスラインＢＬを介して波形出力部１０８に与えられ、適宜バッファ記憶される。波形出力部１０８ではバッファ記憶された波形データを所定の出力サンプリング周波数にしたがって出力し、これをＤ／Ａ変換してサウンドシステム１０８Ａに送出する。こうして、波形出力部１０８から出力された楽音信号は、サウンドシステム１０８Ａを介して発音される。ハードディスク１０９は、波形データや奏法に応じた波形を合成するためのデータ（後述する奏法テーブル、コードブック等のデータ）、各種音色パラメータ等からなる音色データなどのような演奏に関する複数種類のデータを記憶したり、前記ＣＰＵ１０１が実行する各種プログラム等の制御に関するデータを記憶したりするものである。
【００１０】
ドライブ１０６は、波形データや奏法に応じた波形を合成するためのデータ（後述する奏法テーブル、コードブック等の各種データ）、多種多様な音色パラメータ等からなる音色データなどのような演奏に関する複数種類のデータを記憶したり、前記ＣＰＵ１０１が実行する各種プログラム等の制御に関するデータを記憶したりするための着脱可能なディスク（外部記憶メディア１０６Ａ）をドライブするものである。なお、前記ドライブ１０６によりドライブされる外部記憶メディア１０６Ａはフロッピーディスク（ＦＤ）の他に、コンパクトディスク（ＣＤ−ＲＯＭ・ＣＤ−ＲＡＭ）、光磁気ディスク（ＭＯ）、あるいはＤＶＤ（Ｄｉｇｉｔａｌ Ｖｅｒｓａｔｉｌｅ Ｄｉｓｋの略）等の着脱自在な様々な形態の記憶メディアであってよい。制御プログラムを記憶した外部記憶メディア１０６Ａをドライブ１０６にセットし、その内容（制御プログラム）をハードディスク１０９に落とさずに、ＲＡＭ１０３に直接ロードしてもよい。なお、外部記憶メディア１０６Ａを用いて、あるいはネットワークを介して制御プログラムを提供するやり方は、制御プログラムの追加やバージョンアップ等を容易に行うことができるので好都合である。
【００１１】
通信インタフェース１１１は、例えばＬＡＮやインターネット、電話回線等の通信ネットワーク（図示せず）に接続されており、該通信ネットワークを介して、サーバコンピュータ等（図示せず）と接続され、当該サーバコンピュータ等から制御プログラムや各種データあるいは演奏情報などを波形生成装置側に取り込むためのものである。すなわち、ＲＯＭ１０２やハードディスク１０９に制御プログラムや各種データが記憶されていない場合に、サーバコンピュータから制御プログラムや各種データをダウンロードするために用いられる。クライアントとなる波形生成装置は、通信インタフェース１１１を介してサーバコンピュータへと制御プログラムや各種データのダウンロードを要求するコマンドを送信する。サーバコンピュータは、このコマンドを受け、要求された制御プログラムやデータなどを通信インタフェース１１１を介してハードディスク１０９に蓄積することにより、ダウンロードが完了する。更に、ＭＩＤＩインタフェースを含み、ＭＩＤＩの演奏情報を受け取るようにしてもよいのは勿論である。また、音楽演奏用キーボードや演奏操作機器をバスラインＢＬに接続し、リアルタイム演奏によって演奏情報を供給するようにしてもよいのは言うまでもない。勿論、所望の音楽曲の演奏情報を記憶した外部記憶メディア１０６Ａを使用して、演奏情報を供給するようにしてもよい。
【００１２】
２．波形データベース作成処理
２．１．処理の概要
図２は、上述した波形生成装置において実行される「波形データベース作成処理」の一実施形態を示すフローチャートである。当該処理は、いろいろな奏法（若しくはアーティキュレーション）に対応するために、いろいろな奏法（若しくはアーティキュレーション）で演奏された演奏音の波形を素材としてベクトルデータを作成するための処理である。
ステップＳ１では、後述する奏法テーブル及びコードブックを記憶するためのデータベースを準備する。このデータベースとなる媒体としては、例えばハードディスク１０９を使用する。そして、様々な自然楽器の様々な演奏態様による波形データを収集する（ステップＳ２）。すなわち、様々な自然楽器の様々な実際の演奏音を外部波形入力（例えば、マイクロフォン等）から波形取込部１０７を介して取り込み、それらの演奏音の波形データ（オリジナル波形データ）をハードディスク１０９の所定のエリアに記憶する。この際に取り込む演奏音の波形データは演奏全体の波形データであってもよいし、あるフレーズ、あるいは１音、あるいはアタック部やリリース部といった特徴のある演奏の一部の波形データだけであってもよい。
【００１３】
次に、こうして得られた自然楽器固有の様々な演奏態様による演奏音の波形データを特徴的な部分毎に切り分けて、チューニング及びファイル名付けする（ステップＳ３）。すなわち、取り込んだオリジナル波形データを波形形状の変化を代表する一部の波形（例えば、アタック部波形、ボディ部波形、リリース部波形、ジョイント部波形等）毎に分離して（▲１▼切り分け）、分離した１周期乃至複数周期の波形データがそれぞれいかなるピッチであるかを判定し（▲２▼チューニング）、さらにそれぞれ分離した波形データに対してファイル名を付与する（▲３▼ファイル名付け）。ただし、アタック部分やリリース部分といった演奏の一部の波形データを取り込んでいる場合には、このような波形の分離（▲１▼切り分け）を省略できる。
次に、周波数分析による成分分離を行う（ステップＳ４）。すなわち、ステップＳ３で分離生成された一部の波形データをＦＦＴ（高速フーリエ変換）分析して複数成分に分離し（この実施形態では、調和成分と調和外成分に分離する）、さらに各成分（調和成分、調和外成分等）から波形、ピッチ、振幅の各要素毎の特徴抽出、つまり特徴分離を行う（ただし、調和成分と調和外成分に分離する場合、調和外成分はピッチを持たないものであることから調和外成分についてのピッチ分離は行わなくてよい）。例えば「波形」（Ｔｉｍｂｒｅ）要素は、ピッチと振幅をノーマライズした波形形状のみ特徴を抽出したものである。「ピッチ」（Ｐｉｔｃｈ）要素は、基準ピッチに対するピッチ変動特性を抽出したものである。「振幅」（Ａｍｐｌｉｔｕｄｅ）要素は、振幅エンベロープ特性を抽出したものである。
【００１４】
ステップＳ５では、ベクトルデータの作成が行われる。すなわち、分離された各成分（調和成分、調和外成分等）の波形（Ｔｉｍｂｒｅ）やピッチ（Ｐｉｔｃｈ）や振幅（Ａｍｐｌｉｔｕｄｅ）の各要素毎に複数のサンプル値を分散的に又は必要に応じて連続的に抽出し、当該サンプル値列に対して各々異なったベクトルＩＤ（識別情報）を付与して、サンプル値の時刻位置のデータとともにコードブックに記憶する（以下、このようなサンプルデータをベクトルデータと呼ぶ）。この実施形態では、調和成分の波形（Ｔｉｍｂｒｅ）要素のベクトルデータ、ピッチ（Ｐｉｔｃｈ）要素のベクトルデータ、振幅（Ａｍｐｌｉｔｕｄｅ）要素のベクトルデータと、調和外成分の波形（Ｔｉｍｂｒｅ）要素のベクトルデータ、振幅（Ａｍｐｌｉｔｕｄｅ）要素のベクトルデータとがそれぞれ作成される。このように、これらの各成分要素毎のベクトルデータは、時間軸の進行に伴い変化しうるデータである。次に、奏法モジュールのデータ（詳しい内容については後述する）を作成して奏法モジュールを奏法テーブルに記憶する。こうして作成された奏法モジュール及びベクトルデータは、データベースにおける奏法テーブル及びコードブックへ書き込まれ（ステップＳ６）、データベースへのデータ蓄積がはかられる。上述したように、ベクトルデータは取り込んだオリジナル波形データそのままではなく取り込んだオリジナル波形の形状を代表する波形を各要素毎に分離したデータであって、このベクトルデータは各々が最終的には奏法モジュールの単位となるデータである。このように、コードブックには抽出した波形形状の変化を代表する一部の波形データを圧縮した形で記憶する。一方、奏法テーブルには、奏法モジュールのデータ（つまり、圧縮された形で記憶されたベクトルデータを元の波形形状の波形データに戻すために必要な各種のデータや、コードブックに記憶されたベクトルデータを指定するためのＩＤデータ）などが記憶される（詳しくは後述する）。
【００１５】
上述した特徴分離（ステップＳ４参照）の際に、振幅、ピッチ、波形要素の他に時間を要素として特徴抽出を行う（以下、抽出された時間要素のベクトルデータのことを「タイムベクトルデータ」と呼ぶ）。この時間要素については、分離生成された一部の波形データの時間区間におけるオリジナル波形データの時間長をそのまま用いる。従って、当該時間区間のオリジナルの時間長（可変値である）を比「１」で示すこととすれば、当該「波形データベース作成処理」時においてこの時間長をあえて分析・測定する必要はない。その場合、時間要素についてのデータ（すなわち、「タイムベクトルデータ」）はどの時間区間でも同じ値“１”であるから、これをコードブックにあえて記憶しておかなくてもよい。勿論、これに限らず、この実際の時間長を分析・測定し、これを「タイムベクトルデータ」としてコードブックに記憶するようにする変形例も実施可能である。
【００１６】
そして、データベース作成が充分に行われたか否かを判定する（ステップＳ７）。すなわち、外部波形入力から得られた様々な自然楽器の様々な演奏態様による演奏音のオリジナル波形データの収集を充分に行って、様々な奏法モジュールのデータ及びベクトルデータを充分に得たか否かを判定する。この判定は自動判定に限らず、ユーザによるスイッチ入力操作に基づく処理続行可否指示に従って行うようにしてもよい。オリジナル波形データの収集とそれに基づくベクトルデータの作成が充分に行われたと判定されたならば（ステップＳ７のＹＥＳ）、当該処理を終了する。引き続き、オリジナル波形データの収集とそれに基づくベクトルデータの作成を行う場合（ステップＳ７のＮＯ）、ステップＳ２の処理へ戻り、上述した各処理（ステップＳ２〜ステップＳ７）を繰り返し実行する。上記「ベクトルデータの作成が充分に行われたか否か」の判定（ステップＳ７）は、「作成したベクトルデータを実際に使用して楽音を生成してみる」ことにより行われてもよい。すなわち、ステップＳ７で一旦「ベクトルデータを充分作成した」（ステップＳ７のＹＥＳ）と判断して図２に示すフローを抜けた後に、「その作成したベクトルデータを使用して楽音を再生してみたら満足できなかったので、再びステップＳ２以降の処理を行ってベクトルデータを追加する」というような処理を行ってもよい。つまり、「ベクトルデータを作成してデータベースに追加する」という処理は、必要に応じて随時行われる。
なお、上述の「波形データベース作成処理」において、奏法モジュールを任意に追加・削除したり、あるいは奏法モジュールのデータ等の編集を行うことができるようにしてもよい。
【００１７】
２．２．奏法モジュールのデータ構成
ここで、奏法モジュールのデータについて具体的に説明する。
奏法モジュールはハードディスク１０９上にデータベース化されて構成される奏法テーブルに記憶され、１つの奏法モジュールは「奏法ＩＤ」と「奏法パラメータ」の組み合わせによって指定することができるようになっている。「奏法ＩＤ」は、その中に楽器情報及びモジュールパーツ名を含む。例えば、「奏法ＩＤ」は次のように定義される。例えば、１つの「奏法ＩＤ」が３２ビット（第０〜３１ビット）列で表現されているとすると、そのうちの６ビットを使用して楽器情報を表現する。例えば、当該６ビット列が「００００００」であればＡｌｔｏＳａｘ（アルト・サックス）を示し、「００１０００」であればＶｉｏｌｉｎ（バイオリン）を示す楽器情報である。この楽器情報は前記６ビット列のうち上位３ビット列を楽器種類の大分類に使用し、下位３ビット列を楽器種類の小分類のために使用するなどしてよい。また、３２ビット列の別の６ビットを使用してモジュールパーツ名を表現する。例えば、当該６ビット列が「００００００」であればＮｏｒｍａｌＡｔｔａｃｋ、「０００００１」であればＢｅｎｄＡｔｔａｃｋ、「００００１０」であればＧｒａｃｅＮｏｔｅＡｔｔａｃｋ、「００１０００」であればＮｏｒｍａｌＳｈｏｒｔＢｏｄｙ、「００１００１」であればＶｉｂＢｏｄｙ、「００１０１０」であればＮｏｒｍａｌＬｏｎｇＢｏｄｙ、「０１００００」であればＮｏｒｍａｌＲｅｌｅａｓｅ、「０１１０００」であればＮｏｒｍａｌＪｏｉｎｔ、「０１１００１」であればＧｒａｃｅＮｏｔｅＪｏｉｎｔを示すモジュールパーツ名である。勿論、上述した構成に限られないことは言うまでもない。
【００１８】
上述したように、個々の奏法モジュールは、上記「奏法ＩＤ」と「奏法パラメータ」との組み合わせで特定される。すなわち、「奏法ＩＤ」に応じて所定の奏法モジュールが特定され、その内容が「奏法パラメータ」に応じて可変設定される。この「奏法パラメータ」は該奏法モジュールに対応する波形データを特徴付ける、若しくは制御するパラメータであり、各奏法モジュール毎に所定の種類の「奏法パラメータ」が存在している。例えば、ＡｌｔｏＳａｘ ［ＮｏｒｍａｌＡｔｔａｃｋ］モジュールの場合にはＡｔｔａｃｋ直後の絶対音高やＡｔｔａｃｋ直後の音量などの種類の奏法パラメータが与えられてよいし、ＡｌｔｏＳａｘ ［ＢｅｎｄＵｐＡｔｔａｃｋ］モジュールの場合にはＢｅｎｄＵｐＡｔｔａｃｋ終了時の絶対音高、ＢｅｎｄＵｐＡｔｔａｃｋ時のＢｅｎｄ深さの初期値、ＢｅｎｄＵｐＡｔｔａｃｋ開始（ノートオンタイミング）〜終了までの時間、Ａｔｔａｃｋ直後の音量、あるいはＢｅｎｄＵｐＡｔｔａｃｋ中のデフォルトのカーブの時間的な伸縮などの種類の奏法パラメータが与えられてよい。また、ＡｌｔｏＳａｘ ［ＮｏｒｍａｌＳｈｏｒｔＢｏｄｙ］モジュールの場合には当該モジュールの絶対音高、ＮｏｒｍａｌＳｈｏｒｔＢｏｄｙの終了時刻−開始時刻、ＮｏｒｍａｌＳｈｏｒｔＢｏｄｙ開始時のダイナミクス、ＮｏｒｍａｌＳｈｏｒｔＢｏｄｙ終了時のダイナミクスなどの種類の奏法パラメータが与えられてよい。なお、奏法モジュールには、「奏法パラメータ」の採りうる全ての値に対応するデータ（後述する要素データ）を必ずしも有しない。「奏法パラメータ」の飛び飛びの一部の値だけに応じたデータを記憶している場合もある。すなわち、例えばＡｌｔｏＳａｘ ［ＮｏｒｍａｌＡｔｔａｃｋ］モジュールの場合、Ａｔｔａｃｋ直後の絶対音高やＡｔｔａｃｋ直後の音量の全ての値ではなく、一部のデータだけに対応したデータを記憶していてもよい。
このように、奏法モジュールを「奏法ＩＤ」と「奏法パラメータ」で指定できるようにすることで、例えばＡｌｔｏＳａｘ ［ＮｏｒｍａｌＡｔｔａｃｋ］であればアルトサックスのノーマルアタック部を示す複数データ（後述する要素データ）の中から所望の奏法パラメータに応じたデータを指定することができるし、Ｖｉｏｌｉｎ［ＢｅｎｄＡｔｔａｃｋ］であればバイオリンのベンドアタック部を示す複数データ（後述する要素データ）の中から所望の奏法パラメータに応じたデータを指定することができる。
【００１９】
２．３．奏法テーブルのデータ構成
奏法テーブルにおいては、個々の奏法モジュールにつき、当該奏法モジュールに対応する波形を生成するために必要なデータ、例えば各成分要素毎のベクトルデータ（波形要素、ピッチ要素（ピッチエンベロープ）、振幅要素（振幅エンベロープ）等）を指定するためのベクトルＩＤや代表点値列（複数サンプル列の中の補正のための代表的サンプル点を指示するデータ）あるいは各成分要素毎のベクトルデータ（波形要素、ピッチ要素（ピッチエンベロープ）、振幅要素（振幅エンベロープ））の開始時間位置や終了時間位置などの情報等を記憶している。つまり、ベクトルデータという圧縮された形でデータベースに記憶されている波形から通常形状の波形を再生するために必要な各種のデータを記憶している（以下、このようなデータを「要素データ」とも呼ぶ）。奏法テーブルにおいて、１つの奏法モジュールに対応して記憶する具体的なデータの一例をＡｌｔｏＳａｘ ［ＮｏｒｍａｌＡｔｔａｃｋ］モジュールの場合について説明すると、次の通りである。
データ１：奏法モジュールのサンプル長。
データ２：ノートオンタイミングの位置。
データ３：調和成分の振幅（Ａｍｐｌｉｔｕｄｅ）要素のベクトルＩＤと代表点値列。
データ４：調和成分のピッチ（Ｐｉｔｃｈ）要素のベクトルＩＤと代表点値列。
データ５：調和成分の波形（Ｔｉｍｂｒｅ）要素のベクトルＩＤ。
データ６：調和外成分の振幅（Ａｍｐｌｉｔｕｄｅ）要素のベクトルＩＤと代表点値列。
データ７：調和外成分の波形（Ｔｉｍｂｒｅ）要素のベクトルＩＤ。
データ８：調和成分の波形（Ｔｉｍｂｒｅ）要素の塊部の開始位置。
データ９：調和成分の波形（Ｔｉｍｂｒｅ）要素の塊部の終了位置（調和成分の波形（Ｔｉｍｂｒｅ）要素のループ部の開始位置）。
データ１０：調和外成分の波形（Ｔｉｍｂｒｅ）要素の塊部の開始位置。
データ１１：調和外成分の波形（Ｔｉｍｂｒｅ）要素の塊部の終了位置（調和外成分の波形（Ｔｉｍｂｒｅ）要素のループ部の開始位置）。
データ１２：調和外成分の波形（Ｔｉｍｂｒｅ）要素のループ部の終了位置。
【００２０】
上記データ１〜１２について、図３を参照して説明する。
図３は、当該奏法モジュールに対応する実波形区間を構成する各成分及び要素の一例を模式的に示す図であり、上から当該区間における調和成分の振幅（Ａｍｐｌｉｔｕｄｅ）要素、調和成分のピッチ（Ｐｉｔｃｈ）要素、調和成分の波形（Ｔｉｍｂｒｅ）要素、調和外成分の振幅（Ａｍｐｌｉｔｕｄｅ）要素、調和外成分の波形（Ｔｉｍｂｒｅ）要素の一例を示す。なお、図に示している数字は上記各データの番号に対応するように付してある。
１は、当該奏法モジュールに該当する波形のサンプル長（波形区間長）である。例えば、当該奏法モジュールの基となったオリジナル波形データの全体の時間長さに対応している。２はノートオンタイミングの位置であり、当該奏法モジュールのどの時間位置にも可変に設定することが可能である。原則的には、このノートオンタイミングの位置から当該波形に従った演奏音の発音が開始されるが、ベンドアタックなどの奏法によってはノートオンタイミングよりも波形成分の立ち上がり開始時点が先行する場合がある。
【００２１】
３は、コードブックに記憶された調和成分の振幅（Ａｍｐｌｉｔｕｄｅ）要素のベクトルデータを指し示すためのベクトルＩＤ及び代表点値列を示す（図において、黒く塗りつぶした正方形で示す２点が代表点を示す）。４は、調和成分のピッチ（Ｐｉｔｃｈ）要素のベクトルデータを指し示すためのベクトルＩＤ及び代表点値列を示す。６は、調和外成分の振幅（Ａｍｐｌｉｔｕｄｅ）要素のベクトルデータを指し示すためのベクトルＩＤ及び代表点値列を示す。代表点値列データはベクトルＩＤによって指示されるベクトルデータ（複数サンプル列からなる）を変更制御するためのデータであり、代表的サンプル点のいくつかを指示（特定）するものである。特定された代表的サンプル点に関してその時間位置（横軸）とレベル軸（縦軸）を変更若しくは補正することにより、他の残りのサンプル点も連動して変更し、もってベクトルの形状を変更する。例えば、そのサンプル数より少ない数の分散的サンプルを示すデータであるが、勿論これに限らず、代表点値列データはサンプルとサンプルの間の中間位置のデータであってもよいし、あるいは所定の範囲（連続的な複数サンプル）にわたるデータであってもよい。また、サンプル値そのものでなく、差分や乗数等のデータであってもよい。この代表点を横軸及び／又は縦軸（時間軸）に移動することによって、各ベクトルデータの形状を変えることができる。つまり、エンベロープ波形の形状を変えることができる。
【００２２】
５は、調和成分の波形（Ｔｉｍｂｒｅ）要素のベクトルデータを指し示すためのベクトルＩＤである。７は、調和外成分の波形（Ｔｉｍｂｒｅ）要素のベクトルデータを指し示すためのベクトルＩＤである。８は、調和成分の波形（Ｔｉｍｂｒｅ）要素の波形の塊部の開始位置である。９は、調和成分の波形（Ｔｉｍｂｒｅ）要素の波形の塊部の終了位置（あるいは、調和成分の波形（Ｔｉｍｂｒｅ）要素の波形のループ部の開始位置）である。すなわち、８から開始する三角形は特徴のある波形形状が連続的に記憶されているノンループ波形の部分を示し、その後に続く９から開始する長方形は繰り返し読み出しすることのできるループ波形の部分を示す。ノンループ波形は、奏法（若しくはアーティキュレーション）等の特徴を有する高品質な波形である。ループ波形は、１周期または適当な複数周期分の波形からなる比較的単調な音部分の単位波形である。１０は、調和外成分の波形（Ｔｉｍｂｒｅ）要素の波形の塊部の開始位置である。１１は、調和外成分の波形（Ｔｉｍｂｒｅ）要素の波形の塊部の終了位置（あるいは、調和外成分の波形（Ｔｉｍｂｒｅ）要素の波形のループ部の開始位置）である。１２は、調和外成分の波形（Ｔｉｍｂｒｅ）要素の波形のループ部の終了位置である。上記データ３〜データ７は各成分要素毎にコードブックに記憶されているベクトルデータを指し示すための識別情報のデータであり、上記データ２及びデータ８〜データ１２はベクトルデータから元の（分離前の）波形を組み立てるための時間情報のデータである。
【００２３】
このように、奏法モジュールのデータはベクトルデータを指し示すためのデータと時間情報のデータとから構成される。このような奏法テーブルに記憶されている奏法モジュールのデータを使用することにより、コードブックに記憶されている波形の素材（ベクトルデータ）を使って、波形を自由に組み立てることができることになる。つまり、奏法モジュールは、奏法（若しくはアーティキュレーション）に応じて生成する波形の挙動を表すデータである。なお、奏法モジュールのデータの種類や数は各奏法モジュール毎に異なっていてよい。また、上述したデータ以外にも他の情報等を具えていてよい。例えば、波形の時間軸を伸長／圧縮制御するためのデータなどを持っていてもよい。
【００２４】
また、上述の例では説明を理解しやすくするために、１つの奏法モジュールが調和成分の各要素（波形、ピッチ、振幅）及び調和外成分の各要素（波形、振幅）の全てを具備している例について説明したが、これに限らず、奏法モジュールが調和成分の各要素（波形、ピッチ、振幅）や調和外成分の各要素（波形、振幅）の１つからなっていてもよいのは勿論である。例えば、奏法モジュールが調和成分の波形（Ｔｉｍｂｒｅ）要素、調和成分のピッチ（Ｐｉｔｃｈ）要素、調和成分の振幅（Ａｍｐｌｉｔｕｄｅ）要素、調和外成分の波形（Ｔｉｍｂｒｅ）要素、調和外成分の振幅（Ａｍｐｌｉｔｕｄｅ）要素のいずれか１つの要素からなっていてもよい。こうすると、各成分毎に奏法モジュールを自由に組み合わせて使用することができることになり好ましい。
【００２５】
このように、様々な自然楽器の様々な演奏態様による演奏音の波形データを全波形データで持つのではなく、波形形状の変化に必要な一部の波形（例えば、アタック部波形、ボディ部波形、リリース部波形、ジョイント部波形等）のみを抽出し、さらに成分、要素、代表点といった階層的な圧縮手法を用いて、データ圧縮された形で波形データをハードディスク１０９に記憶することから、波形データを記憶するために必要なハードディスク１０９の記憶容量を削減することができるようになっている。
【００２６】
３．波形合成処理
図１に示す波形生成装置において、波形の合成はコンピュータがこの発明に係る波形合成処理を実現する所定のプログラム（ソフトウエア）を実行することにより実施される。図４は、前記波形合成処理を実現する所定のプログラム（「データベースに基づく楽音合成処理」）のフローチャートの一実施形態を示したものである。
但し、本実施形態においては、プログラムによって実現される様々な機能は相互に独立しているため、図５に示す機能ブロック図に基づいて動作を説明する。また、この種のプログラムの形態に限らず、波形合成処理を専用ハードウエア装置の形態で実施するようにしてもよい。この場合、図５は、図４と同様の波形合成処理を専用ハードウエア装置の形態で構成した場合のブロック図になる。そこで、以降は、主に、図５に従って説明し、図４については対応するステップを括弧書きして示す。
【００２７】
３．１．曲データ再生部１０１Ａ
曲データ再生部１０１Ａは、奏法記号付き曲データの再生処理を行う（ステップＳ１１）。最初に、曲データ再生部１０１Ａは奏法記号付き曲データ（演奏情報）を受信する。通常の楽譜には、そのままではＭＩＤＩデータとならないような強弱記号（クレッシェンドやデクレッシェンド等）、テンポ記号（アレグロやリタルダンド等）、スラー記号、テヌート記号、アクセント記号等の音楽記号が付されている。そこで、これらの記号を「奏法記号」としてデータ化して、この「奏法記号」を含むＭＩＤＩ曲データが「奏法記号付き曲データ」である。「奏法記号」は、チャートＩＤとチャートパラメータとから構成する。チャートＩＤは楽譜に記載される音楽記号を示すＩＤであり、チャートパラメータはチャートＩＤで示される音楽記号の内容の程度を示すパラメータである。例えば、チャートＩＤが“ビブラート”を示す場合にはビブラートの速さや深さ等がチャートパラメータとして付与され、チャートＩＤが“クレッシェンド”を示す場合にはクレッシェンドのスタート時の音量、クレシェンドのエンド時の音量、音量変化する時間長等がチャートパラメータとして付与される。
【００２８】
３．２．楽譜解釈部１０１Ｂ
楽譜解釈部（プレーヤー）１０１Ｂでは、楽譜解釈処理を行う（ステップＳ１２）。具体的には、曲データに含まれるＭＩＤＩデータと上述した「奏法記号」（チャートＩＤとチャートパラメータ）を奏法指定情報（奏法ＩＤと奏法パラメータ）に変換し、時刻情報とともに奏法合成部（アーティキュレーター）１０１Ｃに出力する。一般的に、同じ音楽記号でも演奏家により記号の解釈が異なって、演奏家毎に異なった演奏方法（すなわち、奏法若しくはアーティキュレーション）で演奏が行われることがある。あるいは、音符の並び方等によっても、演奏家毎に異なった演奏方法で演奏が行われることもある。そこで、そのような楽譜上の記号（音楽記号や音符の並び方等）を解釈する知識をエキスパートシステム化したものが楽譜解釈部１０１Ｂである。
【００２９】
楽譜解釈部１０１Ｂにおける楽譜上の記号を解釈する際の基準の一例としては、以下のようなものがある。例えば、ビブラートは８分音符以上でないとかけられない。スタッカートでは自然にダイナミクスが大きくなる。テヌート度で音符の減衰率が決まる。レガートは１音中で減衰しない。８分音符ビブラートのスピードは音価でほぼ決まる。音高によってダイナミクスは異なる。更には、１フレーズ内の音高の上昇又は下降によるダイナミクスの変化、減衰ダイナミクスはｄｂリニア、テヌートやスタッカート等に応じた音符の長さの変化、アタック部のベンドアップの記号に応じたベンドアップの幅とカーブ、といったような各種の解釈基準がある。楽譜解釈部１０１Ｂはこのような基準に従って解釈を楽譜に対して行うことにより、楽譜を演奏データに変換する。更に、楽譜解釈部１０１Ｂは、ユーザからのプレーヤー指定、すなわちユーザにより誰の演奏か（奏法か）の指定に応じて上述の楽譜解釈処理を行う。楽譜解釈部１０１Ｂは、このプレーヤー指定に応じて楽譜の解釈方法を異ならせて楽譜を解釈する。例えば、この複数プレーヤーに対応した異なる楽譜解釈方法はデータベースに蓄積されており、楽譜解釈部１０１Ｂはユーザからのプレーヤー指定に応じて選択的に楽譜解釈方法を異ならせて楽譜の解釈を行う。
【００３０】
なお、楽譜の解釈結果を示すデータを予め含むように曲データ（演奏情報）を構成してもよい。そのような予め楽譜を解釈した結果のデータを含む曲データを入力した場合には、上述した処理を行う必要がないことは言うまでもない。また、楽譜解釈部１０１Ｂ（ステップＳ１２）における楽譜の解釈処理は全自動で行うようにしてもよいし、ユーザによる人為的入力操作を適宜介在させて行うようにしてもよい。
【００３１】
ここで、楽譜解釈部１０１Ｂにおいて作成される演奏データの内容を図２１を参照し説明する。
演奏データは、通常のＳＭＦ（スタンダードＭＩＤＩフォーマット）と同様に、ヘッダと複数のトラックとから構成されている。各トラックには、プログラムチェンジおよびイベントデータ（ノートオン、ノートオフ等）が含まれているが、本実施形態においては、アタック部、ボディ部、ジョイント部およびリリース部のモジュールを指定するモジュール指定部（奏法ＩＤと奏法パラメータを含む奏法指定情報）が含まれている。これらモジュール指定部は、実際には未定義のシステム・エクスクルーシブ・メッセージやメタイベント、１４ビットのコントロールチェンジ等が用いられる。さらに、各トラックには、これらイベントデータまたはモジュール指定部間の時間差を指定する時間差データが含まれている。
【００３２】
ここで、各トラックに音色を指定するプログラムチェンジ、すなわち新しいデータベース（奏法テーブル＋コードブック）を指定するプログラムチェンジが含まれていた場合には、楽譜解釈部１０１Ｂは該プログラムチェンジを予測データとして波形合成部１０１Ｄに供給する。これは、波形合成部１０１Ｄは、次に使用されるベクトルデータを予測してコードブックから読み出すため、予測範囲をある程度絞りこむためにプログラムチェンジを特定したものである（詳細は後述する）。なお、予測データには、他の種々のデータも含まれる。楽譜解釈部１０１Ｂにおいては曲データに基づいて、「その後の奏法指定を示すデータ」が予測データとして波形合成部１０１Ｄに供給される。その予測データの一つとして上記プログラムチェンジが含まれるのである。
【００３３】
３．３．奏法合成部１０１Ｃ
奏法合成部（アーティキュレーター）１０１Ｃは楽譜解釈部（プレーヤー）１０１Ｂにより変換された奏法指定（奏法ＩＤ＋奏法パラメータ）に基づいて奏法テーブルを参照して、奏法指定（奏法ＩＤ＋奏法パラメータ）に応じたパケットストリーム（あるいはベクトルストリームとも呼ぶ）及び奏法パラメータに応じた該ストリームに関するベクトルパラメータを生成し、波形合成部１０１Ｄに供給する（ステップＳ１３）。パケットストリームとして波形合成部１０１Ｄに供給されるデータは、ピッチ（Ｐｉｔｃｈ）要素及び振幅（Ａｍｐｌｉｔｕｄｅ）要素に関してはパケットの時刻情報、ベクトルＩＤ、代表点値列などであり、波形（Ｔｉｍｂｒｅ）要素に関してはベクトルＩＤ、時刻情報などである（詳しくは後述する）。
【００３４】
次に、波形合成部１０１Ｄはパケットストリームに応じてコードブックからベクトルデータを取り出し、該ベクトルデータをベクトルパラメータに応じて変形し、変形したベクトルデータに基づいて波形を合成する（ステップＳ１４）。それから、他パートの波形生成処理を行う（ステップＳ１５）。ここで、他パートとは、複数の演奏パートのうち奏法合成処理を行わない、通常の楽音波形合成処理が適用される演奏パートである。例えば、これらの他のパートは通常の波形メモリ音源方式で楽音生成を行う。この「他パートの波形生成処理」は、専用のハードウエア音源（外部の音源ユニットやコンピュータに装着可能な音源カード）に行わせてもよい。説明を簡略化するために、この実施形態では奏法（若しくはアーティキュレーション）に応じた楽音生成を行うのは１パートのみの場合とする。勿論、複数パートで奏法再生してもよい。
【００３５】
図６は、上述した奏法合成部１０１Ｃにおける奏法合成処理の流れを説明するためのブロック図である。ただし、図６では奏法モジュールとコードブックが別々に記憶されているように図示したが、実際には両方ともハードディスク１０９のデータベース内に記憶されている。
奏法合成部１０１Ｃは、楽譜解釈部１０１Ｂからの奏法指定（奏法ＩＤ＋奏法パラメータ）と時刻情報のデータに基づいて、波形合成部１０１Ｄに供給する各種パケットストリームを作成する。奏法合成部１０１Ｃで各音色毎に使用している奏法モジュールは固定的ではなく、ユーザが新たに奏法モジュールを使用中の奏法モジュールに追加したり、使用している奏法モジュールの一部の奏法モジュールの使用を中止したりすることができる。また、奏法合成部１０１Ｃでは、選択された要素データと奏法パラメータの値との間のズレ分を補正するための補正情報を作成する処理や、前後の奏法モジュールの波形特性を滑らかに接続する接続部の平滑化などの処理も行う（詳しくは後述する）。
なお、標準的には楽譜解釈部１０１Ｂから奏法合成部１０１Ｃに対してデータが与えられるがそれに限らず、前述のとおり、楽譜解釈部１０１Ｂにより既に解釈の終わっている奏法指定付き曲データ乃至人間が楽譜の解釈をして奏法ＩＤや奏法パラメータを付与した奏法指定付き曲データを用意して、それを再生したデータを奏法合成部１０１Ｃに供給するようにしてもよい。
【００３６】
図７は、奏法合成処理の一実施形態を詳細に示したフローチャートである。
奏法合成部１０１Ｃは、奏法ＩＤ及び奏法パラメータに応じて奏法テーブルから奏法モジュールの選択を行う（ステップＳ２１）。すなわち、楽譜解釈部１０１Ｂから送信された奏法ＩＤ（楽器情報＋モジュールパーツ名）と奏法パラメータに応じて１つの奏法モジュールを選択する。この際に、楽譜解釈部１０１Ｂは楽譜を解釈する前に楽器情報の示す音色に対応してどのようなモジュールパーツが奏法テーブルに存在するかを予めデータベースをチェックして確認し、存在しているパーツの範囲で奏法ＩＤを指定する。なお、存在しないパーツが指定された場合には、その代わりに類似の特性を有する奏法ＩＤが選択されるようにしてもよい。次に、該指定された奏法ＩＤと奏法パラメータに応じて複数の要素データを選択する（ステップＳ２２）。すなわち、指定された奏法ＩＤと奏法パラメータとにより奏法テーブルを参照することにより、奏法モジュールを特定し、該モジュールから該奏法パラメータに対応した複数の要素データを選択する。この際に、奏法モジュール中に奏法パラメータに完全一致する要素データが存在しない場合には、その値に近い奏法パラメータに対応した要素データが選択される。
【００３７】
次に、時刻情報に応じて要素データ中の各位置の時刻を算出する（ステップＳ２３）。すなわち、各要素データを、時刻情報に基づいて絶対的な時間位置に配置する。具体的には、時刻情報に基づいて、各相対的な時間位置を示す要素データから対応する絶対時間を算出する。こうして、各要素データのタイミングを決定する（図３参照）。そして、奏法パラメータに応じて各要素データの値を補正する（ステップＳ２４）。すなわち、選択された要素データと奏法パラメータの値との間のずれ分を補正する。例えば、楽譜解釈部１０１Ｂから送信されたＡｌｔｏＳａｘ ［ＮｏｒｍａｌＡｔｔａｃｋ］モジュールのＡｔｔａｃｋ直後の音量（奏法パラメータ）が「９５」であり、奏法テーブルに存在するＡｌｔｏＳａｘ ［ＮｏｒｍａｌＡｔｔａｃｋ］モジュールのＡｔｔａｃｋ直後の音量が「１００」である場合、奏法合成部１０１ＣはＡｔｔａｃｋ直後の音量が「１００」であるＡｌｔｏＳａｘ ［ＮｏｒｍａｌＡｔｔａｃｋ］モジュールの要素データを選択する。しかし、このままではＡｔｔａｃｋ直後の音量が「１００」のままであることから、選択された要素データの代表点に対して補正を行うことによってＡｔｔａｃｋ直後の音量を「９５」に補正する。このように、選択された要素データの値を送信された奏法パラメータの値に近づけるようにして補正を行う。また、設定されているマイクロチューニング（楽器の調律）の値に応じた補正や楽器の音量変化特性に応じた音量の補正等も行う。これらの補正は各要素データの代表点値を変化することにより行われ、代表点値を大きく変化することもある。すなわち、補正を行うのに必要十分なデータが代表点であり、この代表点をコントロールすることによって各種の補正を行う。
【００３８】
なお、上記ステップＳ２３では、上記奏法パラメータのような補正情報によって、上記時刻情報が示す時間位置を補正するようにしてもよい。例えば、演奏データに基づいて得られる時間位置と上記時刻情報が示す時間位置とが一致しない場合に、演奏データに基づいて得られる時間位置に近い時間位置を示す時刻情報を選択して、そこで取得した時刻位置情報を演奏データに応じて補正することで、演奏データの意図する時刻位置情報を得ることができる。また、演奏データがタッチやベロシティのような可変制御ファクタを含む場合は、その可変制御ファクタに応じて時刻位置情報を補正することで、演奏データに応じた時刻位置情報の可変制御を行うことができる。補正情報は、このような時刻位置補正を行うための情報を含む。
【００３９】
更に、各要素データを調整して隣り合う奏法モジュールの接続部を平滑化するためにリンク処理を行う（ステップＳ２５）。すなわち、前後の奏法モジュールにおける接続部の代表点を互いに接近させて接続することによって、前後の奏法モジュールの波形特性が滑らかになるようにする。このような接続若しくはリンク処理は、調和成分の波形（Ｔｉｍｂｒｅ）、振幅（Ａｍｐｌｉｔｕｄｅ）、ピッチ（Ｐｉｔｃｈ）等の各要素毎に、あるいは調和外成分の波形（Ｔｉｍｂｒｅ）、振幅（Ａｍｐｌｉｔｕｄｅ）の各要素毎に、別々に行われる。
【００４０】
この際、前の奏法モジュールの「リンク開始点」から、後の奏法モジュールの「リンク終了点」までの範囲で調整を行う。すなわち、「リンク開始点」から「リンク終了点」の範囲内にある代表点を「歩みより率」に基づいて調整する。この「歩みより率」は、前の奏法モジュールと後の奏法モジュールからそれぞれどれだけ歩み寄ったところで接続するかを制御するためのパラメータであり、後述するように前後の奏法モジュールの組み合わせに従って決定される。また、前後の奏法モジュールを接続した際に、波形の接続がうまく行かない場合には、前後いずれかの奏法モジュールでその波形特性のベクトルＩＤを間引くことにより接続を滑らかにする。この間引きを実現するために、「奏法モジュール組み合わせテーブル」と、これから参照される「間引き実行パラメータ範囲テーブル」と、さらにこれから参照される「間引き時間テーブル」を用意する。
【００４１】
この他にも、以下のような楽譜解釈部１０１Ｂにおけるリンク処理により波形特性を滑らかに接続することができる。例えば、奏法モジュールとは関係なく、奏法パラメータ（ダイナミクス値、ピッチパラメータ値等）の不連続部分を滑らかに接続する。あるいは、ビブラートからリリースへと移行する場合にビブラートを早めに減少させることにより、滑らかに接続する。
【００４２】
ここで、上述のリンク処理について詳しく説明する。すなわち、前後の奏法モジュールの接続部を平滑化する（ステップＳ２５参照）ための各要素データの調整について簡単に説明する。まず、図８を用いて奏法モジュールが振幅（Ａｍｐｌｉｔｕｄｅ）要素又はピッチ（Ｐｉｔｃｈ）要素と対応する場合のリンク処理について説明する。
【００４３】
前の奏法モジュールと後の奏法モジュールとの接続部における代表点の値の不連続により両者間の接続点に段差が生じている場合、まずダイナミクス接続点（Ａｍｐｌｉｔｕｄｅの場合）あるいはピッチ接続点（Ｐｉｔｃｈの場合）の目標値を、前後どちらの奏法モジュール側の値により近づけるかという指標の「歩みより率」を決定する。本実施形態では「歩みより率」が図示のようなテーブルによって与えられるとする。例えば前の奏法モジュールのベクトルＩＤが「３」であり、後の奏法モジュールのベクトルＩＤが「７」である場合の「歩みより率」はテーブルから「３０」と決定される。こうして決定された「歩みより率」により前の奏法モジュールの「リンク開始点」から「奏法モジュールの終了点」まで、徐々に目標値に向けてエンベロープ形状を変形する。また、後の奏法モジュールの「リンク終了点」から「奏法モジュール開始点」まで、徐々に目標値に向けてエンベロープ形状を変形する。例えば「歩みより率」が「３０」と決定された場合、前の奏法モジュールに対する目標値は「３０」であり、前の奏法モジュールは後の奏法モジュール側に「３０」％歩みよりを行う（本実施形態では、前の奏法モジュールにおける最後の代表点が下方に「３０」％歩みよりする）。
【００４４】
一方、後の奏法モジュールは前の奏法モジュール側に「７０」（１００−３０）％歩みよりを行う（本実施形態では、後の奏法モジュールにおける最初の代表点が上方に「７０」％歩みよりする）。また、リンク開始点からリンク終了点までに存在する前後の奏法モジュールの複数代表点が上記歩みよりに伴って各々上下に歩みよりを行う。このように、歩みよりは前後する奏法モジュールの複数の代表点で行われる。なお、リンク開始点とリンク終了点は適宜定めてよいが、リンク開始点やリンク終了点を所望の代表点と同一の点に設定すると、図に示したようなリンク開始点やリンク終了点におけるエンベロープ形状の折れ曲がりがなくなるので望ましい。勿論、リンク開始点やリンク終了点を所望の代表点と同一の点に設定していない場合でも、エンベロープ形状に折れ曲がりが生じないように歩みよりを行うようにしてよいことは言うまでもない。
【００４５】
なお、「歩みより率」の決定は上述した例に限られるものではない。例えば、接続点の前後で指定された奏法パラメータに基づいて決定してもよい。または、奏法ＩＤや奏法パラメータになる前の演奏データに基づいて決定してもよい。あるいは、それらのデータの組み合わせに基づいて決定してもよい。また、上述の例では「歩みより率」により歩みよりする代表点は１つであり、その他の代表点はその歩みよりに伴って適量だけ歩みよりするようにしたが、複数の代表点各々について別々に「歩みより率」を決定し、それに従って複数の代表点を各々「歩みより率」分だけ歩みよりするようにしてもよい。
【００４６】
次に、奏法モジュールが波形（Ｔｉｍｂｒｅ）要素である場合のリンク処理について説明する。図９〜図１２は、奏法モジュールが波形（Ｔｉｍｂｒｅ）要素である場合のリンク処理を説明するための概念図である。図９はアタック部波形とボディ部波形とを接続した場合の波形の間引きを説明するための概念図であり、図１０はボディ部波形とリリース部波形とを接続した場合における波形の間引きを説明するための概念図である。図９では、ボディ部波形は５つのループ波形Ｌ１〜Ｌ５からなり、各々所定の時間範囲でループ再生されるものとする。同様に、図１０のボディ部波形は６つのループ波形Ｌ１´〜Ｌ６´からなるものとする。
【００４７】
波形に関する要素データの調整（つまり、波形のリンク処理）の方法には種々あるが、その一例として、例えばアタック部あるいはジョイント部の奏法モジュールとボディ部の奏法モジュールとの接続（あるいは、ボディ部の奏法モジュールとリリース部あるいはジョイント部の奏法モジュールとの接続）において、波形の部分的間引きにより滑らかに接続する方法を提案する。波形と波形とを接続する際に、クロスフェード合成することはよく知られている。しかし、図９の例の場合のように、接続時点から最初のループ波形Ｌ１の開始位置までの時間ｔが短い場合、短い時間ｔ内で急なクロスフェード合成をしなければならなくなる。そのような急なクロスフェード波形合成、つまり接続する波形と波形との間の時間が非常に接近している場合に当該波形間でクロスフェード波形合成を行うと、それに伴って大きなノイズを発生する波形を生ずることになり、好ましくない。
【００４８】
そこで、波形の一部を間引き（削除）して接続する波形と波形との時間間隔を広げることにより、急なクロスフェード波形合成を行わないようにする。この場合に、アタック部やリリース部あるいはジョイント部における波形は１つの塊であって、波形を間引くことができないので、この場合はボディ部側のループ波形の間引きを行う。図９及び図１０では、黒く塗りつぶした長方形で示したループ波形Ｌ１、Ｌ６´を間引きする。例えば、図９では接続時点からの時間差が比較的長い２番目のループ波形Ｌ２とアタック部波形の末尾波形とをクロスフェード合成し、最初のループ波形Ｌ１は使用しない。同様に、図１０ではループ波形Ｌ５´とリリース部波形との間でクロスフェード合成を行い、波形Ｌ６´は使用しない。
なお、ジョイント部とは音と音の間（又は音部分と音部分の間）を任意の奏法でつなぐ波形区間のことである。
【００４９】
また、アタック部の奏法モジュールとリリース部あるいはジョイント部の奏法モジュールとの接続を波形間引きにより滑らかにする。図１１及び図１２は、アタック部波形とリリース部波形とを接続する場合における波形の間引きを説明するための概念図である。
この場合には、アタック部あるいはリリース部等の奏法モジュールが波形間引きできる場合とできない場合とがある。アタック部の奏法モジュールが波形間引きできる例としてはベンドアタック部（後半にいくつかのループ波形を持つ）がある。また、前半にいくつかのループ波形を持つリリース部の場合も波形間引きが行える。このように、波形間引きできる側の奏法モジュールを波形間引きする。例えば、ベンドアタック部とリリース部とを接続する場合には、図１１に示すようにベンドアタック部側のループ波形を間引きする（図１１では、ベンドアタック部側の黒く塗りつぶした長方形で示したループ波形を１つ間引きする）。また、ノーマルアタック部とループ波形を有するリリース部とを接続する場合には図１２に示すようにリリース部側のループ波形を間引きする（図１２では、リリース部側の黒く塗りつぶした長方形で示したループ波形を１つ間引きする）。
なお、間引く対象とするループ波形は奏法モジュールと奏法モジュールとの接続部に最も近いループ波形（先頭あるいは最後に位置するループ波形）とすることに限らず、複数ループ波形から所定の優先順位に従って間引く対象とするループ波形を特定するようにしてもよい。
【００５０】
このように、ある奏法モジュールの組み合わせにおいて、ある奏法パラメータの範囲で接続がうまく行かない場合に波形を間引くが、これを実現するために、例えば「奏法モジュール組み合わせテーブル」と、これから参照される「間引き実行パラメータ範囲テーブル」と、更にこれから参照される「間引き時間テーブル」を用意する。「奏法モジュール組み合わせテーブル」は、接続する前後の奏法モジュールの組み合わせにより所定のパラメータを決定するためのテーブルである。「間引き実行パラメータ範囲テーブル」は、上記パラメータ毎に間引きを行う時間の範囲を決定するためのテーブルである。「間引き時間テーブル」は、間引き時間を決定するためのテーブルである。接続時点と最初の（又は最後の）ループ波形Ｌ１（又はＬ６´）との時間差（図９〜図１２に示す時間ｔ）が基準の間引き時間より短い場合に、該ループ波形を間引く。
【００５１】
さらに、奏法モジュールのサンプル長が短く、当該奏法モジュールの後に続く奏法モジュールが開始されるよりも前に終了してしまう場合の波形接続について図１３を用いて説明する。ただし、図１３では、図の左側から右側に時系列にＡ．Ｓａｘ［ＢｅｎｄＵｐＡｔｔａｃｋ］、Ａ．Ｓａｘ［ＮｏｒｍａｌＳｈｏｒｔＢｏｄｙ］、Ａ．Ｓａｘ［ＶｉｂｒａｔｏＢｏｄｙ］、Ａ．Ｓａｘ［ＮｏｒｍａｌＲｅｌｅａｓｅ］の４つの奏法モジュールで波形（Ｔｉｍｂｒｅ）要素のパケットストリームを形成している場合について説明する。各奏法モジュールのサンプル長（区間長）は、“ｌｅｎｇｔｈ”で示す長さで表せられる。図１３において、最上段に記載されている「ノートオン」と「ノートオフ」は、ＭＩＤＩデータのイベントタイミングである。また、中段に記載されているＡ．Ｓａｘ［ＢｅｎｄＵｐＡｔｔａｃｋ］等はそれぞれ奏法ＩＤの発生タイミングであり、ｎｏｔｅ、ｄｙｎａｍｉｃｓ、ｄｅｐｔｈ等はそれぞれ奏法パラメータの発生タイミングを示す。
【００５２】
Ａ．Ｓａｘ ［ＢｅｎｄＵｐＡｔｔａｃｋ］モジュールは、時刻ｔ０から開始される。また、時刻ｔ１は当該モジュール内のノートオンのタイミングであり、指示されたノートオンタイミングにあわせる。また、当該モジュールのパケットストリームの内容は、上記ｎｏｔｅ、ｄｙｎａｍｉｃｓ、ｄｅｐｔｈ等の奏法パラメータに基づいて制御される。Ａ．Ｓａｘ［ＮｏｒｍａｌＳｈｏｒｔＢｏｄｙ］モジュールは、アタックモジュール直後の時刻ｔ２から開始される。時刻ｔ３は、接続部において、その途中からビブラート奏法がスタートしているタイミングである。このタイミングは、例えば、曲データに付与されたビブラート記号の開始タイミングに基づいて決定される。時刻ｔ５は、Ａ．Ｓａｘ［ＮｏｒｍａｌＲｅｌｅａｓｅ］ モジュール内のノートオフタイミングであり、指示されたノートオフタイミングにあわせる。Ａ．Ｓａｘ［ＮｏｒｍａｌＲｅｌｅａｓｅ］モジュールの始まりの時刻ｔ４はそれに応じて特定される。
【００５３】
すなわち、時刻ｔ１においてノートオンされ、時刻ｔ５においてノートオフされることから、実際に当該パケットストリームから生成される波形に従って発音される時間は時刻ｔ１から時刻ｔ５までの時間である。このようなパケットストリームの場合に、時刻ｔ２から時刻ｔ４までの時間長と、その間のＡ．Ｓａｘ［ＮｏｒｍａｌＲｅｌｅａｓｅ］ モジュールとＡ．Ｓａｘ［ＶｉｂｒａｔｏＢｏｄｙ］ モジュールの各サンプル長ｌｅｎｇｔｈの合計が合わないことが多く、適切に対処する必要が生ずる。このような場合、同じ奏法モジュールを繰り返すことによってサンプル長ｌｅｎｇｔｈの合計を前記時間長にあわせるか、奏法モジュールのサンプル長を可変して前記時間長に合わせるか、あるいは前記両方を組み合わせて用いて前記時間長を合わせる。このようにして、各モジュール間で調節して波形接続を行うようになっている。上述の例では、Ａ．Ｓａｘ［ＮｏｒｍａｌＳｈｏｒｔＢｏｄｙ］モジュールを繰り返すことにより、その後に続くＡ．Ｓａｘ［ＶｉｂｒａｔｏＢｏｄｙ］ モジュールと波形接続を行っている。同様に、Ａ．Ｓａｘ［ＶｉｂｒａｔｏＢｏｄｙ］ モジュールを繰り返すことにより、その後に続くＡ．Ｓａｘ［ＮｏｒｍａｌＲｅｌｅａｓｅ］モジュールとの波形接続を行っている。
【００５４】
上記のように、奏法モジュールを複数回繰り返して波形接続を行う場合、複数繰り返す側の奏法モジュールの時間長を可変する。この時間長の可変制御は、上述した例ではＡ．Ｓａｘ［ＮｏｒｍａｌＳｈｏｒｔＢｏｄｙ］モジュールあるいはＡ．Ｓａｘ［ＶｉｂｒａｔｏＢｏｄｙ］ モジュールにおける代表点を移動することによってなされる。すなわち、Ａ．Ｓａｘ［ＮｏｒｍａｌＳｈｏｒｔＢｏｄｙ］モジュールあるいはＡ．Ｓａｘ［ＶｉｂｒａｔｏＢｏｄｙ］ モジュールを構成する複数のループ波形間のクロスフェード接続の時間を変化するなどの適宜の方法によって実現する。ループ波形の場合は、ループ回数乃至ループ継続時間を可変することによって、比較的簡単に、ループ再生波形全体の時間長を可変制御することができる。一方、ノンループ波形の場合は、時間軸上におけるその存在長を可変制御することはそれほど簡単ではない。従って、上記のように、ノンループ波形とループ波形とからなる一連の音の波形において、ループ読出区間の波形データの時間軸を伸縮可変制御することで全体の発音時間長を可変制御するように工夫することは、時間伸縮制御を容易にするので極めて好ましい。そのために、特開平１０‐３０７５８６号で本出願人が先に提案した「Ｔｉｍｅ Ｓｔｒｅｔｃｈ ＆ Ｃｏｍｐｒｅｓｓ」制御（略して「ＴＳＣ制御」）を用いるとよい。特に、特殊な奏法に対応するノンループ波形において時間軸の長さを可変するために、上記「ＴＳＣ制御」は好ましく応用できる。
【００５５】
このようにして作成されるパケットストリームの一例を概念的に示すと、図１４のようである。図１４では、上から順に調和成分の振幅（Ａｍｐｌｉｔｕｄｅ）要素、ピッチ（Ｐｉｔｃｈ）要素、波形（Ｔｉｍｂｒｅ）要素、調和外成分の振幅（Ａｍｐｌｉｔｕｄｅ）要素、波形（Ｔｉｍｂｒｅ）要素における各パケットストリームを示す。また、調和成分の振幅（Ａｍｐｌｉｔｕｄｅ）要素、ピッチ（Ｐｉｔｃｈ）要素、調和外成分の振幅（Ａｍｐｌｉｔｕｄｅ）要素において、黒く塗りつぶした正方形は代表点であり、これらを結ぶ曲線はパケットストリームの中のパケットに含まれるベクトルＩＤで示されたベクトルの形状を示す。調和成分の波形（Ｔｉｍｂｒｅ）要素、調和外成分の波形（Ｔｉｍｂｒｅ）要素において、白抜きの長方形Ｌはループ波形を示すものであり、その他の長方形ＮＬはノンループ波形を示すものである。なお、ノンループ波形のうち、斜線を引いたものは特に特徴のあるノンループ波形を示すものである。さらに、この実施形態では、ＮｏｒｍａｌＡｔｔａｃｋモジュールにおける調和成分と調和外成分の波形（Ｔｉｍｂｒｅ）要素をそれぞれ２個のベクトルで構成し、調和成分の振幅（Ａｍｐｌｉｔｕｄｅ）要素とピッチ（Ｐｉｔｃｈ）要素及び調和外成分の振幅（Ａｍｐｌｉｔｕｄｅ）要素をそれぞれ１個のベクトルで構成している。
【００５６】
本実施形態では、調和成分、調和外成分とも、波形（Ｔｉｍｂｒｅ）要素がノンループ波形となっている部分については、振幅（Ａｍｐｌｉｔｕｄｅ）要素及びピッチ（Ｐｉｔｃｈ）要素がベクトルを持たないようになっている。しかしながら、波形（Ｔｉｍｂｒｅ）要素がノンループ波形であるところでも、振幅（Ａｍｐｌｉｔｕｄｅ）要素、ピッチ（Ｐｉｔｃｈ）要素のベクトルを持ち生成波形を制御するようにしてもよい。ＶｉｂｒａｔｏＢｏｄｙモジュールでは、調和成分の波形（Ｔｉｍｂｒｅ）要素を５個のベクトルで構成し、調和成分の振幅（Ａｍｐｌｉｔｕｄｅ）要素とピッチ（Ｐｉｔｃｈ）要素及び調和外成分の波形（Ｔｉｍｂｒｅ）要素と振幅（Ａｍｐｌｉｔｕｄｅ）要素をそれぞれ１個のベクトルで構成している。ここで、ＶｉｂｒａｔｏＢｏｄｙモジュールは３回繰り返されているが、各繰り返し毎に各ベクトルの形状が異なっていることに注意してほしい。これは各繰り返し毎に異なる奏法パラメータが指定されたからである。異なる奏法パラメータに応じて異なる要素データが選択されたり、異なる奏法パラメータに応じて異なるレベル制御、時間軸制御が行われたりする。ＮｏｒｍａｌＪｏｉｎｔモジュールでは、調和成分と調和外成分の波形（Ｔｉｍｂｒｅ）要素をそれぞれ３個のベクトルで構成し、調和成分の振幅（Ａｍｐｌｉｔｕｄｅ）要素とピッチ（Ｐｉｔｃｈ）要素及び調和外成分の振幅（Ａｍｐｌｉｔｕｄｅ）要素をそれぞれ２個のベクトルで構成している。なお、ＮｏｒｍａｌＢｏｄｙモジュールの説明は省略する。
【００５７】
奏法合成部１０１Ｃは、上述したようにパケットストリームを各成分（調和成分及び調和外成分）毎に生成する。これらのパケットストリームは複数個のパケットで構成されてなり、１個１個のパケットはベクトルＩＤとパケットの時刻情報とを具える。それに加えて、調和成分の振幅（Ａｍｐｌｉｔｕｄｅ）要素、ピッチ（Ｐｉｔｃｈ）要素、調和外成分の振幅（Ａｍｐｌｉｔｕｄｅ）要素の場合には各代表点の確定値などを具える。勿論、これに限られるものではなく、ベクトルＩＤとパケットの時刻情報に加えて他の情報を具えていてよい。このような１つ１つのパケットの内容に従って、各成分毎にパケットストリームが構成されている。このように、パケットストリームには複数のパケット及びその各パケットの時刻情報（開始時刻）が含まれる。
なお、楽器の種類等によってパケットストリームの数が異なっていてよいことは言うまでもない。
【００５８】
３．４．波形合成部１０１Ｄ
３．４．１．波形合成部１０１Ｄの全般動作
波形合成部１０１Ｄは、奏法合成部１０１Ｃから供給される各成分毎のパケットストリーム（ベクトルＩＤ、時刻情報、補正情報等を含む複数のパケットの列）に基づいて波形を合成する。図１５は、波形合成部１０１Ｄにおける動作を説明するために全体構成を示した概念図である。図１６〜図１９，図２２，図２３は、波形合成部１０１Ｄにおける各動作を詳細に説明するための図面である。図１６は、波形合成の全体の流れを簡単に示すブロック図である。図１７は、ベクトルローダを説明するためのブロック図である。図１８は、ベクトルオペレータを説明するためのブロック図である。図１９は、ベクトルデコーダを説明するためのブロック図である。図２２は、奏法合成部１０１Ｃから波形合成部１０１Ｄに各パケットが供給されるタイミングを示す図であり、図２３はキャッシュ制御部４０を説明するためのブロック図である。
【００５９】
図１５において、奏法合成部（アーティキュレーター）１０１Ｃで作成された各成分要素毎のパケットストリームは、波形合成部１０１Ｄにおける各成分要素毎に対応して設けられる所定のパケットキューバッファ２１〜２５に順次にパケット入力（つまり、パケット単位での入力）される。入力されたパケットはパケットキューバッファ２１〜２５に蓄積され、順次所定の順番でベクトルローダ２０に送られる。ベクトルローダ２０ではパケット内のベクトルＩＤを参照して、当該ベクトルＩＤに対応するオリジナルのベクトルデータをキャッシュ制御部４０を介してコードブック２６から読出し（ロード）する。読出しされたベクトルデータは、各成分要素毎に対応して設けられる所定のベクトルデコーダ３１〜３５へ送られ、ベクトルデコーダ３１〜３５で各成分要素毎の波形が生成される。
【００６０】
さらに、ベクトルデコーダ３１〜３５では、生成された各成分要素毎の波形を各ベクトルデコーダ３１〜３５間で同期しながら各成分毎（調和成分及び調和外成分）の波形を生成する。こうして生成された各成分毎の波形は、ミキサ３８に送られる。奏法合成部（アーティキュレーター）１０１Ｃでは、パケットキューバッファ２１〜２５に対してパケットを入力する他、ストリーム管理（個々のベクトルデータの生成や削除あるいはベクトルデータ間の接続に関する管理）や再生コントロール（所望の波形生成の実行あるいは生成された所望の波形の再生／停止などのコントロール）などの各種の制御を波形合成部１０１Ｄに対して実行する。
【００６１】
上述したように、ベクトルローダ２０にはパケットキューバッファ２１に蓄積されたパケットストリームを構成するパケットを順次に入力され、ベクトルローダ２０は各パケット内のベクトルＩＤに基づいて、キャッシュ制御部４０を介してコードブック２６から当該ベクトルＩＤに対応するベクトルデータを読み出し、読み出したベクトルデータをベクトルデコーダ３１に送る（図１６参照）。この際に、読み出した各パケット内に補正情報（例えば、代表点に関する補正情報）が付されている場合がある。このような場合、ベクトルローダ２０では読み出したオリジナルのベクトルデータを補正情報に従って変形し、変形したベクトルデータ（これをオリジナルのベクトルデータと区別するためにベクトル情報データと呼ぶ）を情報として持つパケット（これを奏法合成部１０１Ｃから入力されたパケットと区別するためにベクトルパケットと呼ぶ）をベクトルデコーダ３１〜３５へ出力する。このように、ベクトルローダ２０は奏法合成部（アーティキュレーター）１０１Ｃから入力されたパケットのベクトルＩＤに基づきオリジナルのベクトルデータをコードブック２６から読出し、必要に応じて補正情報でベクトルデータの補正を行った上でベクトルデコーダ３１〜３５にベクトルパケットを渡す（図１７参照）。上述したようなベクトルデータの代表点に関する補正情報には、例えば乱数に基づいて時刻情報をずらすための補正情報等いろいろな補正情報がありうる。
【００６２】
図１８に示すように、ベクトルデコーダ３１〜３５は入力されたベクトルパケットを処理するためのベクトルオペレータの生成や破棄、ベクトルオペレータ間の接続・同期管理、時刻管理、他ベクトルＩＤストリームからの入力のベクトルオペレータ毎のパラメータへの変換設定などの各種のオペレータ動作管理を行うものである。ベクトルオペレータ３６及び３７では、ベクトル情報データの読み出し、あるいはベクトル情報データの読み出し位置制御（Ｓｐｅｅｄ入力）やゲイン制御（Ｇａｉｎ入力）などが行われる。このベクトルオペレータ３６及び３７に設定される各種のパラメータは、ベクトルデコーダ３１〜３５で管理される。各成分要素毎に対応するようにベクトルデコーダ３１〜３５が設けられており、当該ベクトルデコーダ３１〜３５がベクトルパケット内のベクトル情報データを読み出して所望の波形の時系列的生成を行う。
【００６３】
例えば、図１９に示すように、ベクトルデコーダ３１は調和成分の振幅（Ａｍｐｌｉｔｕｄｅ）要素のエンベロープ波形を生成し、ベクトルデコーダ３２は調和成分のピッチ（Ｐｉｔｃｈ）要素のエンベロープ波形を生成し、ベクトルデコーダ３３は調和成分の波形（Ｔｉｍｂｒｅ）要素の波形を生成し、ベクトルデコーダ３４は調和外成分の振幅（Ａｍｐｌｉｔｕｄｅ）要素のエンベロープ波形を生成し、ベクトルデコーダ３５は調和外成分の波形（Ｔｉｍｂｒｅ）要素のエンベロープ波形を生成する。ベクトルデコーダ３３は、ベクトルデコーダ３１及び３２で生成された調和成分の振幅（Ａｍｐｌｉｔｕｄｅ）要素のエンベロープ波形と調和成分のピッチ（Ｐｉｔｃｈ）要素のエンベロープ波形を付与した調和成分の波形を生成してミキサ３８へ出力する。すなわち、ベクトルデコーダ３３に対して、調和成分の振幅（Ａｍｐｌｉｔｕｄｅ）要素のエンベロープ波形をゲイン制御（Ｇａｉｎ入力）を行うためのベクトルオペレータとして、調和成分のピッチ（Ｐｉｔｃｈ）要素のエンベロープ波形をベクトル情報データの読み出し位置制御（Ｓｐｅｅｄ入力）を行うためのベクトルオペレータとして入力する。また、ベクトルデコーダ３５では、ベクトルデコーダ３４で生成された調和外成分の振幅（Ａｍｐｌｉｔｕｄｅ）要素のエンベロープ波形を付与した調和外成分の波形を生成してミキサ３８へ出力する。すなわち、ベクトルデコーダ３５に対しては、調和外成分の振幅（Ａｍｐｌｉｔｕｄｅ）要素のエンベロープ波形をゲイン制御（Ｇａｉｎ入力）を行うための制御命令として入力する。
【００６４】
さらに、各成分、要素における波形の時系列的生成の際には、各ベクトルデコーダ３１〜３５間で波形の同期を行いながら波形生成が行われる。例えば、波形（Ｔｉｍｂｒｅ）要素のベクトルパケットと振幅（Ａｍｐｌｉｔｕｄｅ）要素のベクトルパケットを入力した場合、波形（Ｔｉｍｂｒｅ）要素のベクトルパケットに基づく波形合生成の時間を基準として、それに同期して振幅（Ａｍｐｌｉｔｕｄｅ）要素のベクトルパケットに基づく振幅波形を生成する。該振幅波形により、波形（Ｔｉｍｂｒｅ）要素のベクトルパケットに基づいて生成される波形の振幅が制御される。波形（Ｔｉｍｂｒｅ）要素のベクトルパケットとピッチ（Ｐｉｔｃｈ）要素のベクトルパケットを入力した場合、波形（Ｔｉｍｂｒｅ）要素のベクトルパケットに基づく波形生成の時間を基準として、それに同期してピッチ（Ｐｉｔｃｈ）要素のベクトルパケットに基づくピッチ波形を合成する。
【００６５】
該ピッチ波形により、波形（Ｔｉｍｂｒｅ）要素のベクトルパケットに基づいて生成される波形のピッチが制御される。調和成分の波形（Ｔｉｍｂｒｅ）要素のベクトルパケットと調和外成分の波形（Ｔｉｍｂｒｅ）要素のベクトルパケットを入力する場合、調和成分の波形（Ｔｉｍｂｒｅ）要素のベクトルパケットに基づく調和成分合成の時間を基準として、それに同期して調和外成分の波形（Ｔｉｍｂｒｅ）要素のベクトルパケットに基づく調和外成分が合成される。合成された調和成分と調和外成分の波形を混合することにより、所望の楽音波形を生成する。
なお、この実施形態において、調和成分と調和外成分の同期または非同期を選択できるように構成し、同期が選択された場合にのみにおいて、上述の調和成分の波形（Ｔｉｍｂｒｅ）要素のベクトルパケットに基づいて生成される調和成分の波形合成の時間を基準として、それに同期して調和外成分の波形（Ｔｉｍｂｒｅ）要素のベクトルパケットに基づいて生成される調和外成分の波形を合成するようにしてもよい。
【００６６】
上述したように、パケットストリームは複数パケット列で構成されており、ベクトルバケットのパケットストリームの場合、各パケットには各々ベクトルデータが含まれている。すなわち、パケットストリームとはベクトルデータが時間方向に並んだものであり、振幅（Ａｍｐｌｉｔｕｄｅ）要素のベクトルデータもピッチ（Ｐｉｔｃｈ）要素のベクトルデータも波形（Ｔｉｍｂｒｅ）要素のベクトルデータもデータ構造や意味は違うが、ベクトルオペレータ３６及び３７から見た場合は基本的に同じものである。
【００６７】
３．４．２．ベクトルデータの構造
図２０は、ベクトルデータのデータ構造の一実施形態を概念的に示す概念図である。例えば、ベクトルデータの読み出し位置の単位は［ＳＥＣ］で、読み出し速度を等速とした場合、ベクトルデータ上での１サンプルは出力波形の１サンプルと一致する。また、読み出し速度の単位は１／１２００［ｃｅｎｔ］（＝２のｎ乗）で、指数ｎが０だと等速、１．０だと２倍（例えば、波形（Ｔｉｍｂｒｅ）要素の場合には１オクターブ上がる）、−１．０だと０．５倍（例えば、波形（Ｔｉｍｂｒｅ）要素の場合には１オクターブ下がる）となる（図２０の上段図参照）。また、コードブック２６には実際のベクトルデータが格納される。例えば、振幅（Ａｍｐｌｉｔｕｄｅ）要素のベクトルデータあるいはピッチ（Ｐｉｔｃｈ）要素のベクトルデータはＶＥＣＴＯＲＰＯＩＮＴ構造体の配列と、代表点データとからなっている。
【００６８】
ＶＥＣＴＯＲＰＯＩＮＴ構造体の配列には各点のサンプル位置と値が順番に入っており、例えば振幅（Ａｍｐｌｉｔｕｄｅ）要素のベクトルデータの値は［ｄｂ］単位であり、ピッチ（Ｐｉｔｃｈ）要素のベクトルデータの値はＭＩＤＩのノートナンバ０を０．０としたときの１／１２００［ｃｅｎｔ］単位である。また、代表点データはＤＷＯＲＤ型の配列で、代表点となるＶＥＣＴＯＲＰＯＩＮＴ構造体の配列のインデックス番号が格納されている（図２０の下段図参照）。勿論、上述した例に限られるものでないことは言うまでもない。
【００６９】
３．４．３．キャッシュ制御部４０の詳細
（１）キャッシュ制御部４０の全体構成
次に、キャッシュ制御部４０の全体構成を図２３を参照し説明するが、このキャッシュ制御部４０を設けた意義について説明しておく。コードブック２６はハードディスク１０９内に格納されているため、ベクトルデコーダ３１〜３５が必要とするベクトルデータはハードディスク１０９から読み出されることになる。しかし、ハードディスク等はアクセス時間が遅く、かつ一定していないため、ベクトルデコーダ３１〜３５が当該ベクトルデータを加工するタイミングで即座に読み出すことは不可能である。そこで、本実施形態においては、波形合成部１０１Ｄ内にキャッシュ制御部４０を設け、将来使用される（または使用が予測されている）ベクトルデータを予めキャッシュメモリにロードすることとしている。
【００７０】
図２３において４２は先読みプリフェッチ部であり、奏法合成部１０１Ｃから波形合成部１０１Ｄに供給されるパケットからベクトルＩＤを抽出し、コードブック２６からこのベクトルＩＤに係るベクトルデータをプリフェッチ（先読み）するようにハードディスク１０９に読み出し制御を行う。上述したように、これらパケットはパケットキューバッファ２１〜２５内のパケットストリームを構成し、やがてベクトルローダ２０によって読み出されることになるが、これと並行してプリフェッチ処理が行われることになる。
【００７１】
４１は予測制御部であり、楽譜解釈部１０１Ｂから供給される予測データ（プログラムチェンジ等）と、先読みプリフェッチ部４２から供給される予測条件とに基づいて、将来使用される可能性の高いベクトルデータを予測し、予測したベクトルデータに係るベクトルＩＤを先読みプリフェッチ部４２に供給する。ここで、「予測条件」とは、使用されることが確定した（すなわち奏法合成部１０１Ｃから供給された）ベクトルＩＤ等である。このように、先読みプリフェッチ部４２においては、奏法合成部１０１Ｃおよび予測制御部４１の双方からベクトルＩＤが供給される。そして、先読みプリフェッチ部４２は、使用されることが確定しているベクトルデータのロード（すなわち奏法合成部１０１Ｃから指定されたベクトルデータのロード）を優先しつつ、双方のベクトルＩＤに係るベクトルデータについてプリフェッチ処理を行う。以下、使用されることが確定しているベクトルデータのロードを「指定ロード」と呼び、使用されることが確定していない（単に予測されたのみの）ベクトルデータのロードを「予測ロード」と呼ぶ。４４はキャッシュメモリであり、プリフェッチされたベクトルデータを格納する。４３は読出し制御部であり、ベクトルローダ２０からベクトルＩＤを受信すると、このベクトルＩＤに対応するベクトルデータを主としてキャッシュメモリ４４から読出し、ベクトルローダ２０に供給する。４５は時刻管理部であり、プリフェッチ等のタイミング制御を行う。
【００７２】
（２）予測制御部４１の動作
次に、予測制御部４１における処理内容を図２４の状態遷移図を参照し説明する。この予測制御部４１の状態は、ベクトルデコーダ３１〜３５において波形合成が行われているか否か、および合成が行われている場合にはどのモジュールに係るものかに応じて決定される。初期状態においては、ベクトルデコーダ３１〜３５において何ら波形合成が行われていないため、予測制御部４１においてはステップＳ３０の処理が行われる。ここでは、アタック部のベクトルデータの候補が予測され、予測されたベクトルＩＤが先読みプリフェッチ部４２に逐次供給される。但し、ステップＳ３０においては、楽譜解釈部１０１Ｂから予測データとして「プログラムチェンジ」が供給されていない限り、アタック部の予測は実行されない。プログラムチェンジが未定であれば、指定される可能性のあるアタック部のベクトルデータは膨大な数になるからである。従って、初期状態においては、楽譜解釈部１０１Ｂからプログラムチェンジが供給されると、直ちに該プログラムチェンジに応じたアタック部のベクトルデータの予測ロードが開始されることになる。
【００７３】
例えば、該プログラムチェンジとして「ピアノ」が指定され、「ピアノ」に係るアタック部のベクトルデータが１００種類あれば、１００種類のベクトルデータの予測ロードが開始されることになる。アタック部に係るパケットが確定されると、やがてベクトルローダ２０およびベクトルデコーダ３１〜３５においてアタック部の波形合成処理が開始される。その際、予測制御部４１の状態はステップＳ３１に遷移する。
【００７４】
ステップＳ３１においては、確定されているアタック部のベクトルＩＤに基づいて、ボディ部のベクトルデータの候補について予測ロードが行われる。すなわち、アタック部のピッチは既知であるから、候補となるベクトルデータはアタック部と同一のピッチに対応するものに限られる。さらに、確定されているアタック部のエンベロープ波形等に対応して、これに繋がる可能性があるボディ部のベクトルデータは、さらに限定される。ステップＳ３１においては、このような条件に応じて絞りこまれた候補が予測ロードされるのである。ここで、ボディ部に係るパケットが実際に奏法合成部１０１Ｃから供給され、当該ボディ部のパケットが確定されると、予測制御部４１の状態はステップＳ３３に遷移する。
【００７５】
ステップＳ３３においては、確定されているボディ部のベクトルＩＤに基づいて、次のベクトルデータの候補について予測ロードが行われる。上述したように、ボディ部に繋がるモジュールは、他のボディ部、ジョイント部あるいはリリース部のうち何れかである。従って、予測制御部４１においては、これらのベクトルデータが予測ロードされる。なお、予測ロードされるベクトルデータの候補は、確定されたボディ部のピッチやエンベロープ波形等に応じて絞りこまれることはステップＳ３１と同様である。
【００７６】
ステップＳ３３の実行中に実際に奏法合成部１０１Ｃからパケットが供給されると、当該パケットに応じて予測制御部４１の状態が遷移する。まず、供給されたパケットがボディ部のパケットであった場合には、状態はステップＳ３３に留まり、再び当該ボディ部に基づいて、他のボディ部、ジョイント部あるいはリリース部の予測ロードが実行される。また、供給されたパケットがジョイント部のパケットであった場合には、予測制御部４１の状態はステップＳ３２に遷移する。
【００７７】
ステップＳ３２においては、ボディ部のベクトルデータの候補が予測ロードされる。ここで、予測ロードされるベクトルデータの候補は、確定されているジョイント部に繋がる可能性のあるボディ部のベクトルデータに絞りこまれる。ここで、奏法合成部１０１Ｃから次のボディ部に係るパケットが供給されると、予測制御部４１の状態は再びステップＳ３３に戻り、他のボディ部、ジョイント部あるいはリリース部のベクトルデータが予測ロードされる。ここで、奏法合成部１０１Ｃからリリース部のパケットが供給されると、予測制御部４１の状態はステップＳ３０に遷移する。
【００７８】
ステップＳ３０においては、上述したように、アタック部のベクトルデータの候補が予測ロードされる。但し、その直前のリリース部のピッチが既に確定されているならば、次に来るアタック部のピッチはあまり大きく外れない可能性が高い。従って、リリース部の合成中において、予測ロードされるアタック部のベクトルデータは、当該リリース部のピッチの周辺（例えば±１オクターブの範囲）に対応するものに限定してもよい。
【００７９】
（３）先読みプリフェッチ部４２の動作
（３．１）ロード処理（図２５）
次に、先読みプリフェッチ部４２の動作を説明する。まず、先読みプリフェッチ部４２においては、所定周期毎に図２５に示すロード処理が実行される。図において処理がステップＳ４１に進むと、未だ実行されていない指定ロード要求を受けているか否かが判定される。ここで「ＹＥＳ」と判定されると、処理はステップＳ４２に進み、要求を受けたベクトルデータの指定ロードが実行される。これにより、暫くの読出し時間が経過すると、ハードディスク１０９からこれらベクトルデータが読出されキャッシュメモリ４４に格納されることになる。
【００８０】
一方、ステップＳ４１において「ＮＯ」と判定されると、処理はステップＳ４３に進み、予測ロードが実行される。すなわち、予測ロード要求のあったベクトルデータのうち、キャッシュメモリ４４内への読出し指令が行われているもの（既にキャッシュメモリ４４内にロードされているものと、他のロード要求に応じてロードが予定されているもの）と、未だハードディスク１０９に読出し指令が行われていないものとが検出され、後者のみについてハードディスク１０９に読出し指令が供給される。なお、予測ロードされるベクトルデータが多い場合には、予測ロードの途中で再び本ルーチンが呼び出される場合もある。かかる場合にも、要求された指定ロードが存在する限りは、当該予測ロードが中断され、ステップＳ４２を介して指定ロードが実行されることになる。このように、先読みプリフェッチ部４２においては、予測ロードよりも指定ロードの方が優先的に実行される。
【００８１】
（３．２）パケット受信処理（図２６）
また、先読みプリフェッチ部４２においては、奏法合成部１０１Ｃからパケットが供給される毎に図２５に示すパケット受信処理が実行される。図において処理がステップＳ５１に進むと、供給されたパケットからベクトルＩＤが抽出され、該ベクトルＩＤに対応するベクトルデータがヒットしているか否かが判定される。ここで、「ヒットした場合」とは、（１）既にキャッシュメモリ４４内に予測ロードされたベクトルデータのうち何れかが的中した場合、（２）未だキャッシュメモリ４４にロードされいないが、当該ベクトルデータの予測ロードが予定されていた場合、（３）過去にロードされ使用済みになった（ＵＳＥＤ状態の）ベクトルデータがそのまま使用できる場合、のうち何れかである。
【００８２】
なお、本実施形態においては、使用済みのベクトルデータは直ちに解放されるのではなく、「ＵＳＥＤ状態」のベクトルデータとして一応キャッシュメモリ４４内に残される。そして、他のベクトルデータを記憶する記憶容量が足りなくなった場合等において、ＵＳＥＤ状態のベクトルデータの領域が解放され、新たなベクトルデータが記憶されるのである。なお、その詳細については後述する。
【００８３】
さて、ヒットするベクトルデータが存在しなかった場合は、ステップＳ５１において「ＮＯ」と判定され、処理はステップＳ５３に進む。ここでは、上記パケットに含まれていたベクトルＩＤについて、指定ロード要求が発生する。従って、次に上述したパケット受信処理（図２６）が実行される際に、該ベクトルデータが指定ロードされることになる。
【００８４】
一方、ヒットしたベクトルデータが存在する場合は「ＹＥＳ」と判定され処理はステップＳ５２に進む。ここでは、該ベクトルデータに係る予測ロードが完了していなければ、該予測ロード要求が指定ロード要求に変更される。これは、その後にパケット受信処理が実行される際、優先的にロードされるからである。次に、処理がステップＳ５４に進むと、奏法合成部１０１Ｃに対して、指定ロード要求されたベクトルデータのハンドルが返される。このハンドルは、ベクトルデータに対して一意に対応するものである。仮に指定ロード要求されたベクトルデータが既にキャッシュメモリ４４に格納されていればそのベクトルデータのハンドルが返され、格納されていなければ、新たなハンドルが生成され奏法合成部１０１Ｃに返されることになる。
【００８５】
次に、処理がステップＳ５５に進むと、先に発生した予測ロード要求のうち外れたものがキャンセルされる。ここで、「キャンセル」の具体的内容については後述する。次に、処理がステップＳ５６に進むと、予測制御部４１における予測条件が変更される。すなわち、奏法合成部１０１Ｃから供給されたパケットに応じて、図２４の各状態における予測ロードの候補が絞りこまれ、あるいは予測制御部４１における状態が遷移される。
【００８６】
このパケット受信処理は、奏法合成部１０１Ｃ側から見れば図２８に示す「ＧｅｔＶｅｃｔｏｒ指令」になる。すなわち、奏法合成部１０１Ｃが波形合成部１０１Ｄに対してパケットを供給する動作は、該パケットに含まれるベクトルＩＤに基づいて「ベクトルデータを得よ」という意味のＧｅｔＶｅｃｔｏｒ指令を送信することに他ならない。このベクトルデータは後にベクトルローダ２０において読み出されるまでに準備しなければならないが、その時点において多数のベクトルデータの中から所要のベクトルデータを特定するためにハンドルが必要なのである。
【００８７】
（４）キャッシュメモリ４４内のデータ構造
（４．１）キャッシュページ（図２７）
キャッシュメモリ４４に格納されるベクトルデータのうち同時に使用されるものは、パッキングされ、１ファイル（あるいはベクトルデータの総数以下の複数ファイル）に変換される。この変換は、ユーザの指示あるいは作成された曲データに応じて、演奏に先立って自動的に実行される。その例を図２７に示す。図において、コードブック２６から読み出されるベクトルデータのうち指定ロードされるものは、時刻情報が含まれている。従って、同時に使用される複数のベクトルデータを抽出することができる。コードブック２６から読み出された各ベクトルデータは個々にヘッダを有している。同時に使用されるベクトルデータは、例えば１つのファイルにまとめられ、このファイルに対して共通のヘッダが付与される。これにより、ベクトルローダ２０が各ベクトルデータにアクセスする時間を短縮することができる。
【００８８】
このファイルのヘッダには、以下のような情報が記憶される。
データＩＤ：ここには、ファイルの種類を識別する４バイトの識別文字「ＰＡＣＫ」が記憶される。
Ｄａｔａ Ｓｉｚｅ：ファイルのデータサイズを示す
ＶＱ Ｔｙｐｅ：記憶されているベクトルデータの種別を示す。
Ｖｅｒｓｉｏｎ：ファイルフォーマットのバージョンを示す。
なお、パッキングされる前のベクトルデータについても同様のヘッダが設けられているが、データＩＤは「ＰＡＣＫ」ではなく、個々のベクトルデータの種別を識別するデータＩＤが付与される。
【００８９】
本実施形態の波形生成装置は、パーソナルコンピュータ上のアプリケーションプログラムによって実現されており、そのキャッシュはシステムメモリ上に存在する。ベクトルデータをキャッシュに記憶する場合、一つのベクトルデータ単位（サイズが不均一）で制御するのではなく、所定サイズのキャッシュページを単位としてキャッシュ制御が行われる。つまり、一つのキャッシュデータは複数のキャッシュページに分割され、キャッシュページ単位でキャッシュに記憶され管理される。また、システムメモリには、各キャッシュページに対応するキャッシュ管理データ（ページヘッダ）が記憶されている。なお、ハードディスクへのデータ記憶は、通常、固定サイズのクラスタ単位で行われているので、キャッシュページのサイズは、そのサイズと同じか、あるいはその整数倍にするとよい。ベクトルデータの容量等を考慮すると、キャッシュページのサイズは１ｋ〜１０ｋバイトにすることが好適である。
【００９０】
（４．２）ページヘッダのデータ構造
次に、各キャッシュページに付与されているヘッダのデータ構造について説明する。各ヘッダは、「ＶＤＤＬＣＳＰＡＧＥ」なる構造体によって構成されており、該構造体のメンバは以下の通りである。
ｄｗＰａｇｅ：当該キャッシュページに対して一意に付与されるページ番号である。
ｄｗＩＤ：このキャッシュページに含まれるベクトルデータのベクトルＩＤである。
ｄｗＳｉｚｅ： このキャッシュページのデータサイズである。
ｄｗＣｏｕｎｔ：プリフェッチ回数を示す。このメンバｄｗＣｏｕｎｔは、指定ロードによってプリフェッチされる毎に「１」づつインクリメントされ、ベクトルローダ２０によって読み出される毎に「１」づつデクリメントされる。
ｄｗＳｔａｔｕｓ： 当該キャッシュページの状態を示す。キャッシュページの状態は、ＦＲＥＥ，ＡＬＬＯＣＡＴＥＤ，ＵＳＥＤ，ＦＩＬＬＥＤ，ＬＯＣＫＥＤのうち何れかである。
ｌｐＢｕｆ： 当該キャッシュページにおけるベクトルデータの実体（ヘッダ以外の部分）の先頭アドレスを指標するポインタである。
ｌｐＦｏｒｗａｒｄ／ｌｐＢａｃｋｗａｒｄ：本実施形態においては、複数のＶＤＤＬＣＳＰＡＧＥ構造体によって双方向リンクドリストが形成される。メンバｌｐＦｏｒｗａｒｄは、リンクの前方向に存在する他のＶＤＤＬＣＳＰＡＧＥ構造体へのポインタであり、メンバｌｐＢａｃｋｗａｒｄ：は、リンクの後方向に存在する他のＶＤＤＬＣＳＰＡＧＥ構造体へのポインタである。
ｌｐＮｅｘｔ： 上述したように、波形生成装置を専用のハードウエア上で実現する場合等においては、同時の使用される複数のベクトルデータが複数のキャッシュページに分割される。これら複数のキャッシュページは「グループ」を構成しており、メンバｌｐＮｅｘｔは同一グループに属する他のＶＤＤＬＣＳＰＡＧＥ構造体を順次指標してゆくポインタである。
【００９１】
ここで、上記メンバｄｗＣｏｕｎｔの役割について述べておく。例えば、一連のパケットストリームにおいて、同一のベクトルデータが２回使用されるならば、該ベクトルデータについて２回の指定ロード要求が発生することになる。しかし、ベクトルローダ２０によって１回目に読出された際に該キャッシュページをＵＳＥＤ状態に設定してしまうと、２回目の読出しができなくなる。そこで、該キャッシュページがあと何回読み出されるのかをカウントすることにより、かかる不具合を防止したものである。
ところで、ベクトルデータが複数回用いられる場合としては、同一のイベントデータに対する波形合成処理において同一のベクトルデータが複数回用いられる場合と、複数のイベントデータに対する波形合成処理において同一のベクトルデータが複数回用いられる場合とが考えられる。本実施形態においては、何れの場合においてもメンバｄｗＣｏｕｎｔによって残りの使用回数が判別されるから、キャッシュメモリ４４内のキャッシュページに対して統一的な取扱が可能になる。
【００９２】
（４．３）ページヘッダのリンク構造（図２９）
次に、ポインタｌｐＦｏｒｗａｒｄとポインタｌｐＢａｃｋｗａｒｄによって実現される双方向リンクドリストの構造を図２９に示す。本実施形態においては、データの並べ替えや、追加／削除を自由にかつ高速に実行するため、図示のようなリスト構造を採用した。
図においてＡ−１は双方向リンクドリストの先頭に位置するページヘッダであり、その先頭は所定のポインタｌｐＴｏｐによって指標され、末尾はポインタｌｐＴａｉｌによって指標されている。Ａ−２，Ａ−３はページヘッダＡ−１と同一のグループに属するページヘッダである。すなわち、この「グループ」は、一つのファイルが分割されて形成された個々のキャッシュページのデータに相当する。ページヘッダＡ−２の先頭アドレスはページヘッダＡ−１のメンバｌｐＮｅｘｔによって指標され、ページヘッダＡ−３の先頭アドレスはページヘッダＡ−２のメンバｌｐＮｅｘｔによって指標されている。
【００９３】
また、Ｂ−１はページヘッダＡ−１の次段にリンクされているページヘッダであり、ページヘッダＢ−１の先頭アドレスはページヘッダＡ−１のメンバｌｐＦｏｒｗａｒｄによって指標されている。そして、このページヘッダＢ−１のメンバｌｐＮｅｘｔによって、同一グループに属するページヘッダＢ−２の先頭アドレスが指標されている。また、ページヘッダＢ−１のメンバｌｐＦｏｒｗａｒｄによって、次段にリンクされているページヘッダＣ−１の先頭アドレスが指標され、ページヘッダＣ−１，Ｃ−２のメンバｌｐＮｅｘｔによって、各々ページヘッダＣ−２，Ｃ−３の先頭アドレスが指標されている。ここで、ＦＲＥＥ状態のキャッシュページも１グループを構成するため、例えばグループＡ，ＢはＦＩＬＬＥＤ状態、グループＣはＦＲＥＥ状態に設定される。新しいベクトルデータをキャッシングしようとするときは、ＦＲＥＥ状態あるいはＵＳＥＤ状態のグループからキャッシュページが取得され、そのキャッシュページが新たなベクトルデータのキャッシュページに設定されることになる。
【００９４】
また、システムメモリ上に新たなキャッシュページおよび対応するページヘッダを作成し、これを新たなベクトルデータのキャッシュページにしてもよい。但し、その場合には、キャッシュページの総量を指定値に制限し、メモリ資源を消費しすぎないようにしておくと好適である。この指定値は、システムメモリ量に応じて自動設定してもよく、ユーザが手動設定してもよい。また、ＦＲＥＥ状態のグループのメモリ量としてある一定値を常に確保するように制御すると、新たなベクトルデータのキャッシュページへの割当を高速化することができる。
【００９５】
図２９の双方向リンクドリストによれば、メンバｌｐＦｏｒｗａｒｄを参照してゆくことにより、リストを構成する各グループの先頭のページヘッダＡ−１，Ｂ−１，Ｃ−１を順番に辿ることができる。また、メンバｌｐＢａｃｋｗａｒｄを参照してゆくことにより、該双方向リンクドリストを逆方向に辿ることができる。従って、あるベクトルデータがキャッシュされているか否かを調査する場合は、リストを構成する先頭のページヘッダを順次辿ってゆき、ページヘッダ内のメンバｄｗＩＤが該ベクトルデータと同一のベクトルＩＤと一致するか否かを判定してゆくとよい。もし一致するものが存在すれば、そのページヘッダに係るキャッシュページが、該ベクトルデータをキャッシングしているグループの先頭のキャッシュページになる。なお、同時に使用される全ベクトルデータが必ず１ページに格納される場合には、上記双方向リンクドリストはページヘッダＡ−１，Ｂ−１，Ｃ−１のみによって構成されることになり、これらページヘッダのメンバｌｐＮｅｘｔには、ヌルデータが格納されることになる。
【００９６】
なお、上記メンバｄｗＳｔａｔｕｓで示される各状態を重要度順に配列すると、「ＬＯＣＫＥＤ≧ＦＩＬＬＥＤ＞ＡＬＬＯＣＡＴＥＤ＞ＵＳＥＤ＞ＦＲＥＥ」の順になる。そこで、この重要度順でキャッシュページの順序を設定しておけば、新たなベクトルデータに対するキャッシュページの割当を高速化することができる。さらに、メンバｄｗＣｏｕｎｔの値をそのまま重要度に反映させてもよい。すなわち、メンバｄｗＣｏｕｎｔが大きいほど重要度を高くするとよい。また、ＵＳＥＤ状態のキャッシュページ間では、先にＵＳＥＤ状態に遷移したものの重要度がより低くなるように設定しておくと好適である。
【００９７】
（５）読出し制御部４３における動作
次に、読出し制御部４３の動作を再び図２８を参照し説明する。
ベクトルローダ２０においては、パケットストリームの内容すなわち各パケット内のベクトルＩＤに基づいて、キャッシュメモリ４４を読み出すように読出し制御部４３にコマンドが送信される。このコマンドをＬｏｃｋＶｅｃｔｏｒ指令と呼ぶ。このＬｏｃｋＶｅｃｔｏｒ指令には、先にＧｅｔＶｅｃｔｏｒ指令に応じて返したハンドルが付随されている。通常の動作状態であれば、該ベクトルデータはキャッシュメモリ４４内に格納されている筈であるから、該ベクトルデータに係るキャッシュページの先頭アドレスのポインタがベクトルローダ２０に返される。
【００９８】
これにより、ベクトルローダ２０およびベクトルデコーダ３１〜３５によって、キャッシュメモリ４４の内容が適宜読み出され、波形合成処理が実行される。このように、ベクトルローダ２０等によって読み出され得るキャッシュページは、ＬＯＣＫＥＤ状態（詳細は後述する）に設定され、他の処理によって内容が改変されないよう設定されている。
【００９９】
ところで、状況によっては、ベクトルローダ２０からＬｏｃｋＶｅｃｔｏｒ指令を受信した際にキャッシュメモリ４４上に必要なベクトルデータが未だロードされていない場合がある。特に本実施形態の波形生成装置をパーソナルコンピュータのアプリケーションプログラムによって実現した場合には、パーソナルコンピュータのオペレーティングシステムの都合によって比較的長時間ハードディスク１０９が占有されることがあり、かかる状況がしばしば発生し得る。この場合には、波形生成装置の動作モードによって異なる処理が実行される。
【０１００】
まず、ノンリアルタイムで波形合成を行っている場合は、指定されたベクトルデータがロードされるまで以降の処理を停止することが好適である。そこで、読出し制御部４３においては、ハードディスク１０９に対する同期読出しが実行される。この同期読出しは、所望のデータが読み出されるまで他の処理を行わないことを意味する。
【０１０１】
一方、波形生成装置がリアルタイムで動作している場合には、同期読出しを実行することは楽音が途切れることになりかねないため、代替ページのポインタがベクトルローダ２０に返される。本実施形態においては、様々な音色変化を忠実に表現するために多種類のベクトルデータを用いているが、プログラムチェンジで選択された音色について、奏法表現等を伴わない基本的な発音を行うためのベクトルに限定すれば、その容量はあまり大きくない。そのようなベクトル（複数）が、その音色のデフォルトのベクトルとして予めＲＡＭ１０３内に格納されており、キャッシュメモリ４４内に準備できなかったベクトルデータの代替として用いられる。
【０１０２】
なお、リアルタイム合成を行う場合であっても、波形合成処理Ｓ１４（波形合成部１０１Ｄ）における時間遅延が充分確保されており、その範囲内で必要なベクトルのロードおよび波形合成が可能な場合は、ノンリアルタイムで波形合成を行う場合と同様に、必要なベクトルデータがロードされていないことが判明した段階で、該ベクトルデータを緊急に読み出して波形合成を行うことができる。ベクトルローダ２０およびベクトルデコーダ３１〜３５による使用が終了したキャッシュページについては、ベクトルローダ２０から読出し制御部４３にハンドルを伴ったＲｅｌｅａｓｅ指令が供給される。このＲｅｌｅａｓｅ指令が供給されると、該キャッシュページのＬＯＣＫＥＤ状態が解消され、ハンドルが解放される。
【０１０３】
（６）キャッシュページに対する状態遷移動作
次に、図３０の状態遷移図を参照し、各キャッシュページの状態を遷移させてゆく動作について説明する。
まず、初期状態においては、全キャッシュページはＦＲＥＥ状態（Ｓ６１）に設定される。すなわち該キャッシュページのヘッダのメンバｄｗＳｔａｔｕｓが‘ＦＲＥＥ’に設定される。これは、未使用状態であって、内容が保証されていないことを意味する。このキャッシュページに対して、ベクトルデータのロードが行われる場合は、該キャッシュページがＡＬＬＯＣＡＴＥＤ状態（Ｓ６２）に設定される。ＡＬＬＯＣＡＴＥＤ状態は、未だデータの格納は完了していないが、コードブック２６からのデータ読出しのために予約されていることを意味する。その際、メンバｄｗＣｏｕｎｔに「１」が格納される。
【０１０４】
その後、ベクトルデータが該ページに格納されると、キャッシュページの状態はＦＩＬＬＥＤ状態に遷移する。ＡＬＬＯＣＡＴＥＤ状態またはＦＩＬＬＥＤ状態において、同一のベクトルデータについて再び指定ロード要求が発生すると、その度にメンバｄｗＣｏｕｎｔが「１」づつインクリメントされる。また、ＡＬＬＯＣＡＴＥＤ状態またはＦＩＬＬＥＤ状態において、予測ロード要求がキャンセルされると（ロード処理（図２５）のステップＳ５５）、メンバｄｗＣｏｕｎｔが「１」づつデクリメントされる。そして、これらの状態においてメンバｄｗＣｏｕｎｔの値が「０」になると、該キャッシュページはＵＳＥＤ状態（Ｓ６３）に設定される。
【０１０５】
キャッシュページがＦＩＬＬＥＤ状態に遷移した後、ベクトルローダ２０からＬｏｃｋＶｅｃｔｏｒ指令が供給されると、該キャッシュページがＬＯＣＫＥＤ状態（Ｓ６５）に設定される。そして、ベクトルローダ２０およびベクトルデコーダ３１〜３５による当該キャッシュページの使用が終了しＲｅｌｅａｓｅ指令が供給されると、ＬＯＣＫＥＤ状態が解消され（ＵｎＬｏｃｋされ）、該キャッシュページが再びＦＩＬＬＥＤ状態（Ｓ６４）に設定される。その際、該キャッシュページのメンバｄｗＣｏｕｎｔが「１」だけデクリメントされる。その際、メンバｄｗＣｏｕｎｔが「０」になった場合には、該キャッシュページの状態は直ちにＵＳＥＤ状態（Ｓ６３）に設定される。
【０１０６】
また、キャッシュページがＵＳＥＤ状態に設定された後、該キャッシュページに対して再び予測ロード要求または指定ロード要求（プリフェッチ）が発生すると、該キャッシュページは再びＦＩＬＬＥＤ状態に戻される。以上のような処理が続行すると、やがてキャッシュメモリ４４内にＵＳＥＤ状態のキャッシュページが増加してゆき、ＦＲＥＥ状態のキャッシュページが減少してゆく。そして、ＦＲＥＥ状態のキャッシュページが無くなった後に、新たなベクトルデータについてプリフェッチが発生すると、ＵＳＥＤ状態であるキャッシュページのうち最も古くＵＳＥＤ状態になったものから順にキャンセル（ＳｗａｐＯｕｔ）され、ＦＲＥＥ状態（Ｓ６１）に戻される。そして、このＦＲＥＥ状態に戻されたキャッシュページが、上記新たなベクトルデータのロードのためにＡＬＬＯＣＡＴＥＤ状態に設定される。
【０１０７】
ここで、ＵＳＥＤ状態であるキャッシュページのうち最も古いものを速やかに特定する方法として、先に図２９において説明した双方向リンクドリストを用いるとよい。すなわち、何れかのキャッシュページがＵＳＥＤ状態に設定されると、リンクドリストの先頭に該キャッシュページを追加し、ＦＲＥＥ状態のキャッシュページが不足する場合には、リンクドリストの末尾のキャッシュページから順次リンクドリストから外し、ＦＲＥＥ状態に変更してゆくとよい。
【０１０８】
（７）時刻管理部４５
時刻管理部４５は波形合成部１０１Ｄ全体のタイミングを制御する。ここで、本実施形態におけるタイミング制御の概要を図３１を参照し説明する。
図において、時刻ｔ３０に再生開始が指示された（例えばユーザにより再生ボタンが押下された）こととし、実際に楽音出力が開始される時刻をｔ４０とする。この時刻ｔ３０からｔ４０に至るまでの時間をレーテンシβと呼ぶ。レーテンシβは、例えば２０００ｍｓｅｃ程度に設定されるが、特に設定しなくてもよい。
【０１０９】
再生開始が指示されると、ＣＰＵ１０１において再生スレッドが所定時間毎に生成される。この再生スレッドにおいては曲データが読み出され、その内容に応じてハードディスク１０９等に対するプリフェッチ処理が実行される。ある曲データが読み出される時刻ｔ３２から実際の発音開始時刻ｔ４０までの時間を先送り時間γと呼ぶ。先送り時間γの基準値は例えば４０００ｍｓｅｃ程度にしておき、処理状況に応じて１０００〜１００００ｍｓｅｃ程度の範囲で伸縮できるようにしておくとよい。
【０１１０】
このように、先送り時間γをある程度確保しておくことにより、再生スレッドを断続的に発生させ曲データの読出しを断続的に（ある程度づつまとめて）行うことが可能になる。再生スレッドが発生する間隔を再生スレッド発生間隔εと呼ぶ。再生スレッド発生間隔εの基準値は例えば２０ｍｓｅｃにしておき、処理状況に応じて５〜１００ｍｓｅｃ程度の範囲で伸縮できるようにしておくとよい。
【０１１１】
時刻ｔ３２に曲データが読み出されると、上述したようにステップＳ１１において曲データの一部が取り出され、ステップＳ１２において楽譜が解釈され、しかる後にステップＳ１３において奏法合成が実行される。この結果、時刻ｔ３４においてベクトルデータのプリフェッチが行われる。プリフェッチ時刻ｔ３４から発音開始時刻ｔ４０までの時間をプリフェッチ時間αと呼ぶ。
【０１１２】
ハードディスク１０９から読み出されたベクトルデータは、やがてキャッシュメモリ４４に書き込まれる。その後、時刻ｔ３６において、ベクトルローダ２０によって読出し制御部４３を介してキャッシュメモリ４４から該ベクトルデータが読み出され、波形合成が開始される。この波形合成開始時刻ｔ３６から発音開始時刻ｔ４０までの時間を出力レーテンシδと呼ぶ。出力レーテンシδの基準値は例えば３００ｍｓｅｃ程度にしておき、処理状況に応じて１０〜１０００ｍｓｅｃ程度の範囲で伸縮できるようにしておくとよい。
【０１１３】
なお、かかる波形合成処理についても、再生スレッドの場合と同様に、ある程度の時間範囲をまとめて断続的に実行すると好適である。この波形合成処理の起動頻度間隔の基準値は例えば５０ｍｓｅｃにしておき、処理状況に応じて１０〜５００ｍｓｅｃ程度の範囲で伸縮できるようにしておくとよい。
【０１１４】
図３１から明らかなように、先送り時間γ、プリフェッチ時間αおよび出力レーテンシδには、「γ＞α＞δ」の関係がある。ここで、プリフェッチ時刻ｔ３４から波形合成開始時刻ｔ３６までの時間間隔「α−δ」は、ハードディスク１０９からベクトルデータをロードできる程度に設定しておく必要がある。ベクトルデータのロード量のピーク値が高い場合には、この時間間隔「α−δ」を長くすることにより、ノイズの発生等を防止することができる。
【０１１５】
４．変形例
本発明は上述した実施形態に限定されるものではなく、例えば以下のように種々の変形が可能である。
（１）上述したような波形生成装置を電子楽器に用いた場合、電子楽器は鍵盤楽器の形態に限らず、弦楽器や管楽器、あるいは打楽器等どのようなタイプの形態でもよい。また、その場合に、曲データ再生部１０１Ａ、楽譜解釈部１０１Ｂ、奏法合成部１０１Ｃ、波形合成部１０１Ｄ等を１つの電子楽器本体内に内蔵したものに限らず、それぞれが別々に構成され、ＭＩＤＩインタフェースや各種ネットワーク等の通信手段を用いて各構成部を接続するように構成されたものにも同様に適用できることはいうまでもない。また、パソコンとアプリケーションソフトウェアという構成であってもよく、この場合処理プログラムを磁気ディスク、光ディスクあるいは半導体メモリ等の記録媒体に格納して供給したり、ネットワークを介して供給するものであってもよい。さらに、自動演奏ピアノのような自動演奏装置などにも適用してよい。
【０１１６】
（２）上記実施形態においては、一つのキャッシュページに複数のベクトルデータを格納したが、一つのキャッシュページに一つのベクトルデータを格納するようにしても良いことは言うまでもない。
【０１１７】
（３）上記実施形態においては、キャッシュページのヘッダのメンバｄｗＣｏｕｎｔをインクリメントあるいはデクリメントすることによって、ＵＳＥＤ状態に遷移させるものを判定した。しかし、かかる方法では、未使用状態のキャッシュページが増大した時にキャッシュメモリ４４が容量不足になる可能性がある。かかる場合には、ＦＩＬＬＥＤ状態であるキャッシュページに対して「優先度」を定義し、優先度の低いＦＩＬＬＥＤ状態のキャッシュページを順次ＵＳＥＤ状態そしてＦＲＥＥ状態に遷移させてもよい。この場合、ＦＲＥＥ状態に遷移させたキャッシュページに対してベクトルローダ２０からＬｏｃｋＶｅｃｔｏｒ指令を受信すると、上述した代替ページが使用されることになる。「優先度」の具体例としては、メンバｄｗＣｏｕｎｔの値をそのまま用いてもよい（値が大きいほど優先度が高いこととする）。また、過去に当該キャッシュページが使用された回数、メンバｄｗＣｏｕｎｔの最大値（過去の履歴上での最大値）を加味してもよい。
【０１１８】
（４）上記実施形態においては、ＵＳＥＤ状態であるキャッシュページを双方向リンクドリストによって結合し、ＦＲＥＥ状態のキャッシュページが不足する場合には、リンクドリストの末尾のキャッシュページから（最も古いものから）順次外してゆき、ＦＲＥＥ状態に変更した。しかし、ＦＲＥＥ状態に遷移させる順序はこれに限定されるものではない。例えば、使用された累積回数の多いキャッシュページ、メンバｄｗＣｏｕｎｔの履歴上の最大値の大きいキャッシュページ、あるいは各モジュールの先頭部分において使用されるベクトルデータについては、なるべくＦＲＥＥ状態に遷移しないように、換言すればキャッシュメモリ４４内に優先的に残すように設定してもよい。また、実際に使用された使用済みのベクトルデータを、実際には使用されなかった（予測が外れた）ベクトルデータよりも優先的に残すようにしてもよい。
【０１１９】
また、モジュールの先頭部分で使用されるベクトルデータを優先的に残しておくことにより、ハードディスク１０９の動作に対する余裕が大きくなり、代替ページを使わざるを得なくなるような事態を減らすことができる。
具体的には、優先的に残すべきキャッシュページをＵＳＥＤ状態に遷移させる時は当該キャッシュページをリンクドリストの先頭に追加し、それ以外のキャッシュページをＵＳＥＤ状態に遷移させる時は該キャッシュページをリンクドリストの中間部分に挿入するようにするとよい。
【０１２０】
（５）上記実施形態においては、音データの具体例としてベクトルデータを用いた例を示したが、該音データはベクトルデータに限定されるものではなく、楽音波形を規定する種々の波形データあるいはパラメータを音データとして用いてもよいことは言うまでもない。
【０１２１】
（６）上記実施形態においては、図１５ないし図２３において説明したように、奏法合成部１０１Ｃからのパケットストリームが先読みプリフェッチ部４２に直接入力された。しかし、かかる動作に代えて、一旦パケットキューバッファ２１〜２５に書き込まれたパケットストリームを先読みプリフェッチ部４２が読み出すようにしてもよい。その場合、先読みプリフェッチ部４２は、ベクトルローダ２０がパケットキューバッファに記憶されたパケットを読み出して処理するタイミングよりも所定時間前のタイミングで、同パケットキューバッファから同パケットを読み出して処理することが好適である。
【０１２２】
【発明の効果】
以上説明したように本発明によれば、高速記憶装置に転送された音データが将来も利用されるか否かをカウント値に基づいて判定できるから、実際に当該音データが後に使用された場合にはハードディスク等の低速記憶装置をアクセスする必要がなくなる。これにより、ハードディスク等の低速記憶装置に対するアクセス頻度を低下させることができる。
【図面の簡単な説明】
【図１】この発明に係る波形生成装置のハードウエア構成例を示すブロック図。
【図２】波形生成装置において実行される「波形データベース作成処理」の一実施形態を示すフローチャート。
【図３】奏法モジュールに対応する実波形区間を構成する各成分及び要素の一例を模式的に示す図。
【図４】「データベースに基づく楽音合成処理」の一実施形態を示すフローチャート。
【図５】図４と同様の波形合成処理を専用ハードウエアの形態で構成した場合の一実施形態を示すブロック図。
【図６】上述した奏法合成部における奏法合成処理の流れを説明するためのブロック図。
【図７】奏法合成部で行われる奏法合成処理の一実施形態を詳細に示したフローチャート。
【図８】奏法モジュールが振幅要素又はピッチ要素に対応する場合におけるリンク処理を説明するための概念図。
【図９】アタック波形とボディ波形とを接続した場合の波形の間引きを説明するための概念図。
【図１０】ボディ波形とリリース波形とを接続した場合の波形の間引きを説明するための概念図。
【図１１】ベンドアタック波形とリリース波形とを接続した場合の波形の間引きを説明するための概念図。
【図１２】ノーマルアタック波形とループ部を有するリリース波形とを接続した場合の波形の間引きを説明するための概念図。
【図１３】後に続く奏法モジュールが開始されるよりも前の奏法モジュールが終了してしまう場合の波形接続について説明するための概念図。
【図１４】奏法合成部で生成されるパケットストリームを説明するための概念図。
【図１５】波形合成部における動作を説明するために全体構成の一実施形態を示した概念図。
【図１６】波形合成の全体の流れを簡単に示すブロック図。
【図１７】ベクトルローダを説明するためのブロック図。
【図１８】ベクトルオペレータを説明するためのブロック図。
【図１９】ベクトルレコーダを説明するためのブロック図。
【図２０】ベクトルデータのデータ構造の一実施形態を概念的に示す概念図。
【図２１】楽譜解釈部１０１Ｂにおいて作成される演奏データの内容を示す図。
【図２２】奏法合成部１０１Ｃから波形合成部１０１Ｄに各パケットが供給されるタイミングを示す図。
【図２３】キャッシュ制御部４０の全体構成を示すブロック図。
【図２４】予測制御部４１の予測動作の状態遷移図。
【図２５】先読みプリフェッチ部４２において実行されるロード処理のフローチャート。
【図２６】先読みプリフェッチ部４２において実行されるパケット受信処理のフローチャート。
【図２７】キャッシュページの構成方法を示す動作説明図。
【図２８】奏法合成部１０１Ｃおよび波形合成部１０１Ｄ間のシグナルフロー図。
【図２９】キャッシュメモリ４４内におけるページヘッダのリンク構造を示す図。
【図３０】キャッシュメモリ４４内における各ページの状態遷移図。
【図３１】上記実施形態のタイミング制御の概要を示すタイミングチャート。
【符号の説明】
１〜１２……データ、２０……ベクトルローダ、２１〜２５……パケットキューバッファ、２６……コードブック、３１〜３５……ベクトルデコーダ、３６，３７……ベクトルオペレータ、３８……ミキサ、４０……キャッシュ制御部、４１……予測制御部、４２……先読みプリフェッチ部、４３……読出し制御部、４４……キャッシュメモリ（高速記憶装置）、４５……時刻管理部、５０……アタック部奏法モジュール、１０１……ＣＰＵ、１０１Ａ……曲データ再生部、１０１Ｂ……楽譜解釈部、１０１Ｃ……奏法合成部、１０１Ｄ……波形合成部、１０２……ＲＯＭ、１０３……ＲＡＭ、１０４……パネルスイッチ、１０５……パネル表示器、１０６……ドライブ、１０６……前記ドライブ、１０６Ａ……外部記憶メディア、１０７……波形取込部、１０８……波形出力部、１０８Ａ……サウンドシステム、１０９……ハードディスク（低速記憶装置）、１１１……通信インタフェース。

Claims (6)

1. 楽音波形の音データを記憶する低速記憶装置と、該音データをキャッシングする高速記憶装置とを用いて、前記低速記憶装置に記憶された音データのうちの一部を波形合成のために前記高速記憶装置に転送する音データ転送方法であって、
   使用されることが決定され、または使用されると予測される音データについて順次準備指示を行う準備過程と、
   予め準備指示され、かつ前記高速記憶装置に記憶されている音データを用いて波形合成の開始指示を行う合成開始指示過程と、
   前記順次準備指示された音データが前記高速記憶装置に記憶されていない場合に、前記低速記憶装置から前記高速記憶装置に該音データを転送するとともに、該転送された音データに対応するカウント値を初期値に設定する転送過程と
   前記順次準備指示された音データが前記高速記憶装置に既に記憶されている場合に、該音データに対応するカウント値を増加させるカウントアップ過程と、
   前記合成開始指示過程による開始指示に応じて、前記音データを用いた波形合成を開始する波形合成過程であって、使用済みの音データに係るカウント値を減少させるものと、
   前記高速記憶装置に記憶された音データのうち今後の開始指示の予定の無い音データを各音データに対応するカウント値に基づいて決定し、決定した音データを消去可能な状態に設定する設定過程と
   を有することを特徴とする音データ転送方法。
2. イベントシーケンスから再生開始時刻に先立ってイベントデータを先読みする先読み過程をさらに有し、
   前記準備過程においては該先読みされたイベントデータに基づいて準備指示に係る音データが決定され、これによって共通の音データが使用される複数のイベントデータに対して、前記転送過程を共用することを特徴とする請求項１記載の音データ転送方法。
3. イベントデータが供給された時刻から所定時間遅れた時刻を再生開始時刻として設定する過程をさらに有し、
   前記準備過程においては該供給されたイベントデータに基づいて準備指示に係る音データが決定され、これによって共通の音データが使用される複数のイベントデータに対して、前記転送過程を共用することを特徴とする請求項１記載の音データ転送方法。
4. 前記準備過程においては、一つのイベントデータに基づいて、同一の音データに対する複数回の前記準備指示が行われ、
   前記波形合成過程においては、前記一つのイベントデータに対応して前記音データが使用される毎に、前記カウント値がその都度減少される
   ことを特徴とする請求項１記載の音データ転送方法。
5. 請求項１ないし４の何れかに記載の方法を実行することを特徴とする音データ転送装置。
6. 請求項１ないし４の何れかに記載の方法を実行することを特徴とするプログラム。

Images