JP3649141B2 - SOUND DATA TRANSFER METHOD, SOUND DATA TRANSFER DEVICE, AND PROGRAM - Google Patents

SOUND DATA TRANSFER METHOD, SOUND DATA TRANSFER DEVICE, AND PROGRAM Download PDF

Info

Publication number
JP3649141B2
JP3649141B2 JP2001086163A JP2001086163A JP3649141B2 JP 3649141 B2 JP3649141 B2 JP 3649141B2 JP 2001086163 A JP2001086163 A JP 2001086163A JP 2001086163 A JP2001086163 A JP 2001086163A JP 3649141 B2 JP3649141 B2 JP 3649141B2
Authority
JP
Japan
Prior art keywords
waveform
data
vector
time
performance
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Expired - Fee Related
Application number
JP2001086163A
Other languages
Japanese (ja)
Other versions
JP2002287754A (en
Inventor
元一 田邑
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Yamaha Corp
Original Assignee
Yamaha Corp
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Priority to JP2001086163A priority Critical patent/JP3649141B2/en
Application filed by Yamaha Corp filed Critical Yamaha Corp
Priority to EP02005887.1A priority patent/EP1260964B1/en
Priority to TW091104809A priority patent/TWI228704B/en
Priority to US10/098,670 priority patent/US6576827B2/en
Priority to EP09180304A priority patent/EP2175440A3/en
Priority to SG200201610A priority patent/SG102667A1/en
Priority to CN2006100735605A priority patent/CN1838234B/en
Priority to CNB021080259A priority patent/CN1258751C/en
Publication of JP2002287754A publication Critical patent/JP2002287754A/en
Priority to HK02109273.7A priority patent/HK1048011B/en
Application granted granted Critical
Publication of JP3649141B2 publication Critical patent/JP3649141B2/en
Anticipated expiration legal-status Critical
Expired - Fee Related legal-status Critical Current

Links

Images

Landscapes

  • Electrophonic Musical Instruments (AREA)

Description

【０００１】
【発明の属する技術分野】
この発明は、ハードディスク等、比較的低速な記憶媒体からの波形データの読み出し等に基づき、楽音あるいは音声若しくはその他任意の音の波形を生成する音データ転送方法、音データ転送装置およびプログラムに関し、特に、演奏者により行われた自然楽器固有の各種奏法若しくはアーティキュレーションによる音色変化を忠実に表現した波形を生成するものに関する。この発明は、電子楽器は勿論のこと、自動演奏装置、コンピュータ、電子ゲーム装置その他のマルチメディア機器等、楽音あるいは音声若しくはその他任意の音を発生する機能を有するあらゆる分野の機器若しくは装置または方法において広範囲に応用できるものである。なお、この明細書において、楽音波形という場合、音楽的な音の波形に限るものではなく、音声あるいはその他任意の音の波形を含んでいてもよい意味合いで用いるものとする。
【０００２】
【従来の技術】
波形メモリにおいて、ＰＣＭ（パルス符号変調）あるいはＤＰＣＭ（差分ＰＣＭ）又はＡＤＰＣＭ（適応差分ＰＣＭ）等の任意の符号化方式で符号化した波形データ（つまり波形サンプルデータ）を記憶しておき、これを所望の音楽ピッチに対応して読み出すことにより、楽音波形を形成するようにした、いわゆる「波形メモリ読み出し」技術は既に公知であり、また、様々なタイプの「波形メモリ読み出し方式」技術が知られている。従来知られた「波形メモリ読み出し方式」技術のほとんどは、発音開始から終了までの1つの音の波形を発生するためのものである。一例として、発音開始から終了までの1音の全波形の波形データを記憶する方式がある。また、別の例として、変化の複雑なアタック部などについてはその全波形の波形データを記憶し、変化のあまりないサステイン部などについては所定のループ波形を記憶する方式がある。なお、本明細書において、「ループ波形」とは繰り返し読出し（ループ読出し）される波形という意味で用いるものとする。
【０００３】
波形データを記憶するための手段としては、ＲＯＭ、ＲＡＭ、ハードディスク、ＣＤ−ＲＯＭ等が知られている。ハードディスク、ＣＤ−ＲＯＭ等は単位記憶容量あたりの単価が安価であり大容量のデータ記憶に適している。しかし、ハードディスク等はアクセス時間が遅く、かつ一定していないため、楽音信号を出力するタイミングで必要な波形データを即座に読み出すことは不可能である。このため、以下のように様々な技術が提案されている。
まず、特開平６−３０８９６４号公報においては、ハードディスク等に記憶した複数の波形データの先頭部分を予めＲＡＭに転送しておく技術が開示されている。すなわち、発音指示が供給されると、ハードディスク等の当該波形データの後続部分の読み出しが開始されるとともに予めＲＡＭに記憶された先頭部分が再生される。そして、先頭部分の再生が終了した後に、後続部分の波形データが再生されるのである。
【０００４】
また、特開昭６３−１８１１８８号公報においては、順次発音すべき波形データがシーケンスデータとして予め定義されている場合に、各波形データを順次読み出しながら再生する技術が開示されている。この技術においては、各波形データの読出しを開始する時刻が発音タイミングよりも早くなるように、シーケンスタイミングに対応して予め定められる。
【０００５】
【発明が解決しようとする課題】
しかし、特開平６−３０８９６４号公報に係る技術によれば、予め全ての波形データの先頭部分を予めＲＡＭに転送しておく必要があるため、ＲＡＭの使用効率が低くなるという問題があった。また、特開昭６３−１８１１８８号公報に係る技術は、一回のイベント毎にハードディスク等が必ずアクセスされるため、ハードディスク等の騒音が大きくなり、寿命も短くなる。しかも、ハードディスク等が頻繁にアクセスされることにより、他の処理に割り当てるリソースが少なくなる。
本発明は上述した事情に鑑みてなされたものであり、ハードディスク等に対するアクセス頻度を低減させることができる音データ転送方法、音データ転送装置およびプログラムを提供することを目的としている。
【０００６】
【課題を解決するための手段】
上記課題を解決するため本発明にあっては、下記構成を具備することを特徴とする。なお、括弧内は例示である。
請求項１記載の構成にあっては、楽音波形の所定区間（モジュール）毎の波形合成のために用いられる音データ（ベクトルデータ）を記憶する低速記憶装置（ハードディスク１０９）と、該音データをキャッシングする高速記憶装置（キャッシュメモリ４４）とを用いて、前記低速記憶装置に記憶された音データのうちの一部を波形合成のために前記高速記憶装置に転送する音データ転送方法であって、発音指示（ノートオン）が発生すると、前記高速記憶装置に新たに転送される音データを記憶するための空き領域が不足するか否かを検出する空き領域検出過程と、前記空き領域検出過程において空き領域が不足すると判定された場合に、前記高速記憶装置に先に保持された音データの記憶領域を解放優先度の高い順に（リンクドリストの末尾にあるものから順に）空き領域として解放する（メンバ dwStatus を‘ FREE ’に設定する）解放過程と、前記空き領域検出過程において検出された空き領域または前記解放過程において得られた空き領域に対して、前記低速記憶装置から新たに転送される音データを転送する転送過程（ステップＳ４３）と、該音データが波形合成のために使用された後、該音データが前記各区間の先頭部分で使用される音データである場合には前記解放優先度が低く、該音データが他の部分で使用される音データである場合には前記解放優先度が高くなるように、前記解放優先度を設定しつつ（リンクドリストの先頭または途中に追加しつつ）、該音データを将来も利用可能な状態で前記高速記憶装置に保持する（メンバdwStatusを‘USED’に設定する）保持過程とを有することを特徴とする。
また、請求項２記載の構成にあっては、請求項１記載の方法を実行することを特徴とする。
また、請求項３記載の構成にあっては、請求項１記載の方法を実行することを特徴とする。
【０００７】
【発明の実施の形態】
１．実施形態のハードウエア構成
以下、この発明の一実施形態を添付図面に従って詳細に説明する。
図１は、この発明に係る波形生成装置のハードウエア構成例を示すブロック図である。ここに示されたハードウエア構成例はコンピュータを用いて構成されており、そこにおいて、波形生成処理は、コンピュータがこの発明に係る波形生成処理を実現する所定のプログラム（ソフトウエア）を実行することにより実施される。勿論、この波形生成処理はコンピュータソフトウエアの形態に限らず、ＤＳＰ（ディジタル・シグナル・プロセッサ）によって処理されるマイクロプログラムの形態でも実施可能であり、また、この種のプログラムの形態に限らず、ディスクリート回路又は集積回路若しくは大規模集積回路等を含んで構成された専用ハードウエア装置の形態で実施してもよい。また、この波形生成装置は、電子楽器あるいはカラオケ装置又は電子ゲーム装置又はその他のマルチメディア機器又はパーソナルコンピュータ等、任意の製品応用形態をとっていてよい。
【０００８】
図1に示されたハードウエア構成例においては、コンピュータのメイン制御部としてのＣＰＵ１０１に対して、バスラインＢＬ（データあるいはアドレスバス等）を介してリードオンリメモリ（ＲＯＭ）１０２、ランダムアクセスメモリ（ＲＡＭ）１０３、パネルスイッチ１０４、パネル表示器１０５、ドライブ１０６、波形取込部１０７、波形出力部１０８、ハードディスク１０９、通信インタフェース１１１がそれぞれ接続されている。ＣＰＵ１０１は、後述する「波形データベース作成」や「制作したデータベースに基づく楽音合成（ソフトウエア音源）」等の処理を、所定のプログラムに基づいて実行する。これらのプログラムは、通信インタフェース１１１を介したネットワークあるいはドライブ１０６に装着されたＣＤやＭＯ等の外部記憶メディア１０６Ａ等から供給されてハードディスク１０９に記憶される。そして、実行時にハードディスク１０９からＲＡＭ１０３にロードされる。あるいは、ＲＯＭ１０２にプログラムが記録されていてもよい。ＲＯＭ１０２は、ＣＰＵ１０１により実行あるいは参照される各種プログラムや各種データ等を格納するものである。ＲＡＭ１０３は、演奏に関する各種情報やＣＰＵ１０１がプログラムを実行する際に発生する各種データを一時的に記憶するワーキングメモリとして、あるいは現在実行中のプログラムやそれに関連するデータを記憶するメモリとして使用される。ＲＡＭ１０３の所定のアドレス領域がそれぞれの機能に割り当てられ、レジスタやフラグ、テーブル、メモリなどとして利用される。パネルスイッチ１０４は、楽音をサンプリングする指示やサンプリングされた波形データ等のエディットや各種情報の入力等を行うための各種の操作子を含んで構成される。例えば、数値データ入力用のテンキーや文字データ入力用のキーボード、あるいはパネルスイッチ等である。この他にも音高、音色、効果等を選択・設定・制御するための各種操作子を含んでいてよい。パネル表示器１０５は、パネルスイッチ１０４により入力された各種情報やサンプリングされた波形データ等を表示する、例えば液晶表示パネル（ＬＣＤ）やＣＲＴ等のディスプレイである。
【０００９】
波形取込部１０７はＡ／Ｄ変換器を内蔵し、外部波形入力（例えば、マイクロフォンなどからの入力）されたアナログ楽音信号をデジタルデータに変換（サンプリング）してＲＡＭ１０３あるいはハードディスク１０９に該デジタル波形データをオリジナル波形データ（生成すべき波形データの素材となる波形データ）として取り込むものである。ＣＰＵ１０１によって実行する「波形データベース作成」処理では、上記取り込んだオリジナル波形データを基にして本発明に従う「波形データベース」の作成を行う。また、ＣＰＵ１０１によって実行する「データベースに基づく楽音合成」処理では、上記「波形データベース」を使用して演奏情報に応じた任意の楽音信号の波形データを生成する。勿論、複数の楽音信号の同時発生が可能である。生成された楽音信号の波形データはバスラインＢＬを介して波形出力部１０８に与えられ、適宜バッファ記憶される。波形出力部１０８ではバッファ記憶された波形データを所定の出力サンプリング周波数にしたがって出力し、これをＤ／Ａ変換してサウンドシステム１０８Ａに送出する。こうして、波形出力部１０８から出力された楽音信号は、サウンドシステム１０８Ａを介して発音される。ハードディスク１０９は、波形データや奏法に応じた波形を合成するためのデータ（後述する奏法テーブル、コードブック等のデータ）、各種音色パラメータ等からなる音色データなどのような演奏に関する複数種類のデータを記憶したり、前記ＣＰＵ１０１が実行する各種プログラム等の制御に関するデータを記憶したりするものである。
【００１０】
ドライブ１０６は、波形データや奏法に応じた波形を合成するためのデータ（後述する奏法テーブル、コードブック等の各種データ）、多種多様な音色パラメータ等からなる音色データなどのような演奏に関する複数種類のデータを記憶したり、前記ＣＰＵ１０１が実行する各種プログラム等の制御に関するデータを記憶したりするための着脱可能なディスク（外部記憶メディア１０６Ａ）をドライブするものである。なお、前記ドライブ１０６によりドライブされる外部記憶メディア１０６Ａはフロッピーディスク（ＦＤ）の他に、コンパクトディスク（ＣＤ−ＲＯＭ・ＣＤ−ＲＡＭ）、光磁気ディスク（ＭＯ）、あるいはＤＶＤ（Ｄｉｇｉｔａｌ Ｖｅｒｓａｔｉｌｅ Ｄｉｓｋの略）等の着脱自在な様々な形態の記憶メディアであってよい。制御プログラムを記憶した外部記憶メディア１０６Ａをドライブ１０６にセットし、その内容（制御プログラム）をハードディスク１０９に落とさずに、ＲＡＭ１０３に直接ロードしてもよい。なお、外部記憶メディア１０６Ａを用いて、あるいはネットワークを介して制御プログラムを提供するやり方は、制御プログラムの追加やバージョンアップ等を容易に行うことができるので好都合である。
【００１１】
通信インタフェース１１１は、例えばＬＡＮやインターネット、電話回線等の通信ネットワーク（図示せず）に接続されており、該通信ネットワークを介して、サーバコンピュータ等（図示せず）と接続され、当該サーバコンピュータ等から制御プログラムや各種データあるいは演奏情報などを波形生成装置側に取り込むためのものである。すなわち、ＲＯＭ１０２やハードディスク１０９に制御プログラムや各種データが記憶されていない場合に、サーバコンピュータから制御プログラムや各種データをダウンロードするために用いられる。クライアントとなる波形生成装置は、通信インタフェース１１１を介してサーバコンピュータへと制御プログラムや各種データのダウンロードを要求するコマンドを送信する。サーバコンピュータは、このコマンドを受け、要求された制御プログラムやデータなどを通信インタフェース１１１を介してハードディスク１０９に蓄積することにより、ダウンロードが完了する。更に、ＭＩＤＩインタフェースを含み、ＭＩＤＩの演奏情報を受け取るようにしてもよいのは勿論である。また、音楽演奏用キーボードや演奏操作機器をバスラインＢＬに接続し、リアルタイム演奏によって演奏情報を供給するようにしてもよいのは言うまでもない。勿論、所望の音楽曲の演奏情報を記憶した外部記憶メディア１０６Ａを使用して、演奏情報を供給するようにしてもよい。
【００１２】
２．波形データベース作成処理
２．１．処理の概要
図２は、上述した波形生成装置において実行される「波形データベース作成処理」の一実施形態を示すフローチャートである。当該処理は、いろいろな奏法（若しくはアーティキュレーション）に対応するために、いろいろな奏法（若しくはアーティキュレーション）で演奏された演奏音の波形を素材としてベクトルデータを作成するための処理である。
ステップＳ１では、後述する奏法テーブル及びコードブックを記憶するためのデータベースを準備する。このデータベースとなる媒体としては、例えばハードディスク１０９を使用する。そして、様々な自然楽器の様々な演奏態様による波形データを収集する（ステップＳ２）。すなわち、様々な自然楽器の様々な実際の演奏音を外部波形入力（例えば、マイクロフォン等）から波形取込部１０７を介して取り込み、それらの演奏音の波形データ（オリジナル波形データ）をハードディスク１０９の所定のエリアに記憶する。この際に取り込む演奏音の波形データは演奏全体の波形データであってもよいし、あるフレーズ、あるいは１音、あるいはアタック部やリリース部といった特徴のある演奏の一部の波形データだけであってもよい。
【００１３】
次に、こうして得られた自然楽器固有の様々な演奏態様による演奏音の波形データを特徴的な部分毎に切り分けて、チューニング及びファイル名付けする（ステップＳ３）。すなわち、取り込んだオリジナル波形データを波形形状の変化を代表する一部の波形（例えば、アタック部波形、ボディ部波形、リリース部波形、ジョイント部波形等）毎に分離して（▲１▼切り分け）、分離した１周期乃至複数周期の波形データがそれぞれいかなるピッチであるかを判定し（▲２▼チューニング）、さらにそれぞれ分離した波形データに対してファイル名を付与する（▲３▼ファイル名付け）。ただし、アタック部分やリリース部分といった演奏の一部の波形データを取り込んでいる場合には、このような波形の分離（▲１▼切り分け）を省略できる。
次に、周波数分析による成分分離を行う（ステップＳ４）。すなわち、ステップＳ３で分離生成された一部の波形データをＦＦＴ（高速フーリエ変換）分析して複数成分に分離し（この実施形態では、調和成分と調和外成分に分離する）、さらに各成分（調和成分、調和外成分等）から波形、ピッチ、振幅の各要素毎の特徴抽出、つまり特徴分離を行う（ただし、調和成分と調和外成分に分離する場合、調和外成分はピッチを持たないものであることから調和外成分についてのピッチ分離は行わなくてよい）。例えば「波形」（Timbre）要素は、ピッチと振幅をノーマライズした波形形状のみ特徴を抽出したものである。「ピッチ」（Pitch）要素は、基準ピッチに対するピッチ変動特性を抽出したものである。「振幅」（Amplitude）要素は、振幅エンベロープ特性を抽出したものである。
【００１４】
ステップＳ５では、ベクトルデータの作成が行われる。すなわち、分離された各成分（調和成分、調和外成分等）の波形（Timbre）やピッチ（Pitch）や振幅（Amplitude）の各要素毎に複数のサンプル値を分散的に又は必要に応じて連続的に抽出し、当該サンプル値列に対して各々異なったベクトルＩＤ（識別情報）を付与して、サンプル値の時刻位置のデータとともにコードブックに記憶する（以下、このようなサンプルデータをベクトルデータと呼ぶ）。この実施形態では、調和成分の波形（Timbre）要素のベクトルデータ、ピッチ（Pitch）要素のベクトルデータ、振幅（Amplitude）要素のベクトルデータと、調和外成分の波形（Timbre）要素のベクトルデータ、振幅（Amplitude）要素のベクトルデータとがそれぞれ作成される。このように、これらの各成分要素毎のベクトルデータは、時間軸の進行に伴い変化しうるデータである。次に、奏法モジュールのデータ（詳しい内容については後述する）を作成して奏法モジュールを奏法テーブルに記憶する。こうして作成された奏法モジュール及びベクトルデータは、データベースにおける奏法テーブル及びコードブックへ書き込まれ（ステップＳ６）、データベースへのデータ蓄積がはかられる。上述したように、ベクトルデータは取り込んだオリジナル波形データそのままではなく取り込んだオリジナル波形の形状を代表する波形を各要素毎に分離したデータであって、このベクトルデータは各々が最終的には奏法モジュールの単位となるデータである。このように、コードブックには抽出した波形形状の変化を代表する一部の波形データを圧縮した形で記憶する。一方、奏法テーブルには、奏法モジュールのデータ（つまり、圧縮された形で記憶されたベクトルデータを元の波形形状の波形データに戻すために必要な各種のデータや、コードブックに記憶されたベクトルデータを指定するためのＩＤデータ）などが記憶される（詳しくは後述する）。
【００１５】
上述した特徴分離（ステップＳ４参照）の際に、振幅、ピッチ、波形要素の他に時間を要素として特徴抽出を行う（以下、抽出された時間要素のベクトルデータのことを「タイムベクトルデータ」と呼ぶ）。この時間要素については、分離生成された一部の波形データの時間区間におけるオリジナル波形データの時間長をそのまま用いる。従って、当該時間区間のオリジナルの時間長（可変値である）を比「１」で示すこととすれば、当該「波形データベース作成処理」時においてこの時間長をあえて分析・測定する必要はない。その場合、時間要素についてのデータ（すなわち、「タイムベクトルデータ」）はどの時間区間でも同じ値“１”であるから、これをコードブックにあえて記憶しておかなくてもよい。勿論、これに限らず、この実際の時間長を分析・測定し、これを「タイムベクトルデータ」としてコードブックに記憶するようにする変形例も実施可能である。
【００１６】
そして、データベース作成が充分に行われたか否かを判定する（ステップＳ７）。すなわち、外部波形入力から得られた様々な自然楽器の様々な演奏態様による演奏音のオリジナル波形データの収集を充分に行って、様々な奏法モジュールのデータ及びベクトルデータを充分に得たか否かを判定する。この判定は自動判定に限らず、ユーザによるスイッチ入力操作に基づく処理続行可否指示に従って行うようにしてもよい。オリジナル波形データの収集とそれに基づくベクトルデータの作成が充分に行われたと判定されたならば（ステップＳ７のＹＥＳ）、当該処理を終了する。引き続き、オリジナル波形データの収集とそれに基づくベクトルデータの作成を行う場合（ステップＳ７のＮＯ）、ステップＳ２の処理へ戻り、上述した各処理（ステップＳ２〜ステップＳ７）を繰り返し実行する。上記「ベクトルデータの作成が充分に行われたか否か」の判定（ステップＳ７）は、「作成したベクトルデータを実際に使用して楽音を生成してみる」ことにより行われてもよい。すなわち、ステップＳ７で一旦「ベクトルデータを充分作成した」（ステップＳ７のＹＥＳ）と判断して図２に示すフローを抜けた後に、「その作成したベクトルデータを使用して楽音を再生してみたら満足できなかったので、再びステップＳ２以降の処理を行ってベクトルデータを追加する」というような処理を行ってもよい。つまり、「ベクトルデータを作成してデータベースに追加する」という処理は、必要に応じて随時行われる。
なお、上述の「波形データベース作成処理」において、奏法モジュールを任意に追加・削除したり、あるいは奏法モジュールのデータ等の編集を行うことができるようにしてもよい。
【００１７】
２．２．奏法モジュールのデータ構成
ここで、奏法モジュールのデータについて具体的に説明する。
奏法モジュールはハードディスク１０９上にデータベース化されて構成される奏法テーブルに記憶され、１つの奏法モジュールは「奏法ＩＤ」と「奏法パラメータ」の組み合わせによって指定することができるようになっている。「奏法ＩＤ」は、その中に楽器情報及びモジュールパーツ名を含む。例えば、「奏法ＩＤ」は次のように定義される。例えば、１つの「奏法ＩＤ」が３２ビット（第０〜３１ビット）列で表現されているとすると、そのうちの６ビットを使用して楽器情報を表現する。例えば、当該６ビット列が「００００００」であればAltoSax（アルト・サックス）を示し、「００１０００」であればViolin（バイオリン）を示す楽器情報である。この楽器情報は前記６ビット列のうち上位３ビット列を楽器種類の大分類に使用し、下位３ビット列を楽器種類の小分類のために使用するなどしてよい。また、３２ビット列の別の６ビットを使用してモジュールパーツ名を表現する。例えば、当該６ビット列が「００００００」であればNormalAttack、「０００００１」であればBendAttack、「００００１０」であればGraceNoteAttack、「００１０００」であればNormalShortBody、「００１００１」であればVibBody、「００１０１０」であればNormalLongBody、「０１００００」であればNormalRelease、「０１１０００」であればNormalJoint、「０１１００１」であればGraceNoteJointを示すモジュールパーツ名である。勿論、上述した構成に限られないことは言うまでもない。
【００１８】
上述したように、個々の奏法モジュールは、上記「奏法ＩＤ」と「奏法パラメータ」との組み合わせで特定される。すなわち、「奏法ＩＤ」に応じて所定の奏法モジュールが特定され、その内容が「奏法パラメータ」に応じて可変設定される。この「奏法パラメータ」は該奏法モジュールに対応する波形データを特徴付ける、若しくは制御するパラメータであり、各奏法モジュール毎に所定の種類の「奏法パラメータ」が存在している。例えば、AltoSax [NormalAttack]モジュールの場合にはAttack直後の絶対音高やAttack直後の音量などの種類の奏法パラメータが与えられてよいし、AltoSax [BendUpAttack]モジュールの場合にはBendUpAttack終了時の絶対音高、BendUpAttack時のBend深さの初期値、BendUpAttack開始（ノートオンタイミング）〜終了までの時間、Attack直後の音量、あるいはBendUpAttack中のデフォルトのカーブの時間的な伸縮などの種類の奏法パラメータが与えられてよい。また、AltoSax [NormalShortBody]モジュールの場合には当該モジュールの絶対音高、NormalShortBodyの終了時刻−開始時刻、NormalShortBody開始時のダイナミクス、NormalShortBody終了時のダイナミクスなどの種類の奏法パラメータが与えられてよい。なお、奏法モジュールには、「奏法パラメータ」の採りうる全ての値に対応するデータ（後述する要素データ）を必ずしも有しない。「奏法パラメータ」の飛び飛びの一部の値だけに応じたデータを記憶している場合もある。すなわち、例えばAltoSax [NormalAttack]モジュールの場合、Attack直後の絶対音高やAttack直後の音量の全ての値ではなく、一部のデータだけに対応したデータを記憶していてもよい。
このように、奏法モジュールを「奏法ＩＤ」と「奏法パラメータ」で指定できるようにすることで、例えばAltoSax [NormalAttack]であればアルトサックスのノーマルアタック部を示す複数データ（後述する要素データ）の中から所望の奏法パラメータに応じたデータを指定することができるし、Violin[BendAttack]であればバイオリンのベンドアタック部を示す複数データ（後述する要素データ）の中から所望の奏法パラメータに応じたデータを指定することができる。
【００１９】
２．３．奏法テーブルのデータ構成
奏法テーブルにおいては、個々の奏法モジュールにつき、当該奏法モジュールに対応する波形を生成するために必要なデータ、例えば各成分要素毎のベクトルデータ（波形要素、ピッチ要素（ピッチエンベロープ）、振幅要素（振幅エンベロープ）等）を指定するためのベクトルＩＤや代表点値列（複数サンプル列の中の補正のための代表的サンプル点を指示するデータ）あるいは各成分要素毎のベクトルデータ（波形要素、ピッチ要素（ピッチエンベロープ）、振幅要素（振幅エンベロープ））の開始時間位置や終了時間位置などの情報等を記憶している。つまり、ベクトルデータという圧縮された形でデータベースに記憶されている波形から通常形状の波形を再生するために必要な各種のデータを記憶している（以下、このようなデータを「要素データ」とも呼ぶ）。奏法テーブルにおいて、１つの奏法モジュールに対応して記憶する具体的なデータの一例をAltoSax [NormalAttack]モジュールの場合について説明すると、次の通りである。
データ１：奏法モジュールのサンプル長。
データ２：ノートオンタイミングの位置。
データ３：調和成分の振幅（Amplitude）要素のベクトルＩＤと代表点値列。
データ４：調和成分のピッチ（Pitch）要素のベクトルＩＤと代表点値列。
データ５：調和成分の波形（Timbre）要素のベクトルＩＤ。
データ６：調和外成分の振幅（Amplitude）要素のベクトルＩＤと代表点値列。
データ７：調和外成分の波形（Timbre）要素のベクトルＩＤ。
データ８：調和成分の波形（Timbre）要素の塊部の開始位置。
データ９：調和成分の波形（Timbre）要素の塊部の終了位置（調和成分の波形（Timbre）要素のループ部の開始位置）。
データ１０：調和外成分の波形（Timbre）要素の塊部の開始位置。
データ１１：調和外成分の波形（Timbre）要素の塊部の終了位置（調和外成分の波形（Timbre）要素のループ部の開始位置）。
データ１２：調和外成分の波形（Timbre）要素のループ部の終了位置。
【００２０】
上記データ１〜１２について、図３を参照して説明する。
図３は、当該奏法モジュールに対応する実波形区間を構成する各成分及び要素の一例を模式的に示す図であり、上から当該区間における調和成分の振幅（Amplitude）要素、調和成分のピッチ（Pitch）要素、調和成分の波形（Timbre）要素、調和外成分の振幅（Amplitude）要素、調和外成分の波形（Timbre）要素の一例を示す。なお、図に示している数字は上記各データの番号に対応するように付してある。
１は、当該奏法モジュールに該当する波形のサンプル長（波形区間長）である。例えば、当該奏法モジュールの基となったオリジナル波形データの全体の時間長さに対応している。２はノートオンタイミングの位置であり、当該奏法モジュールのどの時間位置にも可変に設定することが可能である。原則的には、このノートオンタイミングの位置から当該波形に従った演奏音の発音が開始されるが、ベンドアタックなどの奏法によってはノートオンタイミングよりも波形成分の立ち上がり開始時点が先行する場合がある。
【００２１】
３は、コードブックに記憶された調和成分の振幅（Amplitude）要素のベクトルデータを指し示すためのベクトルＩＤ及び代表点値列を示す（図において、黒く塗りつぶした正方形で示す２点が代表点を示す）。４は、調和成分のピッチ（Pitch）要素のベクトルデータを指し示すためのベクトルＩＤ及び代表点値列を示す。６は、調和外成分の振幅（Amplitude）要素のベクトルデータを指し示すためのベクトルＩＤ及び代表点値列を示す。代表点値列データはベクトルＩＤによって指示されるベクトルデータ（複数サンプル列からなる）を変更制御するためのデータであり、代表的サンプル点のいくつかを指示（特定）するものである。特定された代表的サンプル点に関してその時間位置（横軸）とレベル軸（縦軸）を変更若しくは補正することにより、他の残りのサンプル点も連動して変更し、もってベクトルの形状を変更する。例えば、そのサンプル数より少ない数の分散的サンプルを示すデータであるが、勿論これに限らず、代表点値列データはサンプルとサンプルの間の中間位置のデータであってもよいし、あるいは所定の範囲（連続的な複数サンプル）にわたるデータであってもよい。また、サンプル値そのものでなく、差分や乗数等のデータであってもよい。この代表点を横軸及び／又は縦軸（時間軸）に移動することによって、各ベクトルデータの形状を変えることができる。つまり、エンベロープ波形の形状を変えることができる。
【００２２】
５は、調和成分の波形（Timbre）要素のベクトルデータを指し示すためのベクトルＩＤである。７は、調和外成分の波形（Timbre）要素のベクトルデータを指し示すためのベクトルＩＤである。８は、調和成分の波形（Timbre）要素の波形の塊部の開始位置である。９は、調和成分の波形（Timbre）要素の波形の塊部の終了位置（あるいは、調和成分の波形（Timbre）要素の波形のループ部の開始位置）である。すなわち、８から開始する三角形は特徴のある波形形状が連続的に記憶されているノンループ波形の部分を示し、その後に続く９から開始する長方形は繰り返し読み出しすることのできるループ波形の部分を示す。ノンループ波形は、奏法（若しくはアーティキュレーション）等の特徴を有する高品質な波形である。ループ波形は、１周期または適当な複数周期分の波形からなる比較的単調な音部分の単位波形である。１０は、調和外成分の波形（Timbre）要素の波形の塊部の開始位置である。１１は、調和外成分の波形（Timbre）要素の波形の塊部の終了位置（あるいは、調和外成分の波形（Timbre）要素の波形のループ部の開始位置）である。１２は、調和外成分の波形（Timbre）要素の波形のループ部の終了位置である。上記データ３〜データ７は各成分要素毎にコードブックに記憶されているベクトルデータを指し示すための識別情報のデータであり、上記データ２及びデータ８〜データ１２はベクトルデータから元の（分離前の）波形を組み立てるための時間情報のデータである。
【００２３】
このように、奏法モジュールのデータはベクトルデータを指し示すためのデータと時間情報のデータとから構成される。このような奏法テーブルに記憶されている奏法モジュールのデータを使用することにより、コードブックに記憶されている波形の素材（ベクトルデータ）を使って、波形を自由に組み立てることができることになる。つまり、奏法モジュールは、奏法（若しくはアーティキュレーション）に応じて生成する波形の挙動を表すデータである。なお、奏法モジュールのデータの種類や数は各奏法モジュール毎に異なっていてよい。また、上述したデータ以外にも他の情報等を具えていてよい。例えば、波形の時間軸を伸長／圧縮制御するためのデータなどを持っていてもよい。
【００２４】
また、上述の例では説明を理解しやすくするために、１つの奏法モジュールが調和成分の各要素（波形、ピッチ、振幅）及び調和外成分の各要素（波形、振幅）の全てを具備している例について説明したが、これに限らず、奏法モジュールが調和成分の各要素（波形、ピッチ、振幅）や調和外成分の各要素（波形、振幅）の１つからなっていてもよいのは勿論である。例えば、奏法モジュールが調和成分の波形（Timbre）要素、調和成分のピッチ（Pitch）要素、調和成分の振幅（Amplitude）要素、調和外成分の波形（Timbre）要素、調和外成分の振幅（Amplitude）要素のいずれか１つの要素からなっていてもよい。こうすると、各成分毎に奏法モジュールを自由に組み合わせて使用することができることになり好ましい。
【００２５】
このように、様々な自然楽器の様々な演奏態様による演奏音の波形データを全波形データで持つのではなく、波形形状の変化に必要な一部の波形（例えば、アタック部波形、ボディ部波形、リリース部波形、ジョイント部波形等）のみを抽出し、さらに成分、要素、代表点といった階層的な圧縮手法を用いて、データ圧縮された形で波形データをハードディスク１０９に記憶することから、波形データを記憶するために必要なハードディスク１０９の記憶容量を削減することができるようになっている。
【００２６】
３．波形合成処理
図１に示す波形生成装置において、波形の合成はコンピュータがこの発明に係る波形合成処理を実現する所定のプログラム（ソフトウエア）を実行することにより実施される。図４は、前記波形合成処理を実現する所定のプログラム（「データベースに基づく楽音合成処理」）のフローチャートの一実施形態を示したものである。
但し、本実施形態においては、プログラムによって実現される様々な機能は相互に独立しているため、図５に示す機能ブロック図に基づいて動作を説明する。また、この種のプログラムの形態に限らず、波形合成処理を専用ハードウエア装置の形態で実施するようにしてもよい。この場合、図５は、図４と同様の波形合成処理を専用ハードウエア装置の形態で構成した場合のブロック図になる。そこで、以降は、主に、図５に従って説明し、図４については対応するステップを括弧書きして示す。
【００２７】
３．１．曲データ再生部１０１Ａ
曲データ再生部１０１Ａは、奏法記号付き曲データの再生処理を行う（ステップＳ１１）。最初に、曲データ再生部１０１Ａは奏法記号付き曲データ（演奏情報）を受信する。通常の楽譜には、そのままではＭＩＤＩデータとならないような強弱記号（クレッシェンドやデクレッシェンド等）、テンポ記号（アレグロやリタルダンド等）、スラー記号、テヌート記号、アクセント記号等の音楽記号が付されている。そこで、これらの記号を「奏法記号」としてデータ化して、この「奏法記号」を含むＭＩＤＩ曲データが「奏法記号付き曲データ」である。「奏法記号」は、チャートＩＤとチャートパラメータとから構成する。チャートＩＤは楽譜に記載される音楽記号を示すＩＤであり、チャートパラメータはチャートＩＤで示される音楽記号の内容の程度を示すパラメータである。例えば、チャートＩＤが“ビブラート”を示す場合にはビブラートの速さや深さ等がチャートパラメータとして付与され、チャートＩＤが“クレッシェンド”を示す場合にはクレッシェンドのスタート時の音量、クレシェンドのエンド時の音量、音量変化する時間長等がチャートパラメータとして付与される。
【００２８】
３．２．楽譜解釈部１０１Ｂ
楽譜解釈部（プレーヤー）１０１Ｂでは、楽譜解釈処理を行う（ステップＳ１２）。具体的には、曲データに含まれるＭＩＤＩデータと上述した「奏法記号」（チャートＩＤとチャートパラメータ）を奏法指定情報（奏法ＩＤと奏法パラメータ）に変換し、時刻情報とともに奏法合成部（アーティキュレーター）１０１Ｃに出力する。一般的に、同じ音楽記号でも演奏家により記号の解釈が異なって、演奏家毎に異なった演奏方法（すなわち、奏法若しくはアーティキュレーション）で演奏が行われることがある。あるいは、音符の並び方等によっても、演奏家毎に異なった演奏方法で演奏が行われることもある。そこで、そのような楽譜上の記号（音楽記号や音符の並び方等）を解釈する知識をエキスパートシステム化したものが楽譜解釈部１０１Ｂである。
【００２９】
楽譜解釈部１０１Ｂにおける楽譜上の記号を解釈する際の基準の一例としては、以下のようなものがある。例えば、ビブラートは８分音符以上でないとかけられない。スタッカートでは自然にダイナミクスが大きくなる。テヌート度で音符の減衰率が決まる。レガートは１音中で減衰しない。８分音符ビブラートのスピードは音価でほぼ決まる。音高によってダイナミクスは異なる。更には、１フレーズ内の音高の上昇又は下降によるダイナミクスの変化、減衰ダイナミクスはｄｂリニア、テヌートやスタッカート等に応じた音符の長さの変化、アタック部のベンドアップの記号に応じたベンドアップの幅とカーブ、といったような各種の解釈基準がある。楽譜解釈部１０１Ｂはこのような基準に従って解釈を楽譜に対して行うことにより、楽譜を演奏データに変換する。更に、楽譜解釈部１０１Ｂは、ユーザからのプレーヤー指定、すなわちユーザにより誰の演奏か（奏法か）の指定に応じて上述の楽譜解釈処理を行う。楽譜解釈部１０１Ｂは、このプレーヤー指定に応じて楽譜の解釈方法を異ならせて楽譜を解釈する。例えば、この複数プレーヤーに対応した異なる楽譜解釈方法はデータベースに蓄積されており、楽譜解釈部１０１Ｂはユーザからのプレーヤー指定に応じて選択的に楽譜解釈方法を異ならせて楽譜の解釈を行う。
【００３０】
なお、楽譜の解釈結果を示すデータを予め含むように曲データ（演奏情報）を構成してもよい。そのような予め楽譜を解釈した結果のデータを含む曲データを入力した場合には、上述した処理を行う必要がないことは言うまでもない。また、楽譜解釈部１０１Ｂ（ステップＳ１２）における楽譜の解釈処理は全自動で行うようにしてもよいし、ユーザによる人為的入力操作を適宜介在させて行うようにしてもよい。
【００３１】
ここで、楽譜解釈部１０１Ｂにおいて作成される演奏データの内容を図２１を参照し説明する。
演奏データは、通常のＳＭＦ（スタンダードＭＩＤＩフォーマット）と同様に、ヘッダと複数のトラックとから構成されている。各トラックには、プログラムチェンジおよびイベントデータ（ノートオン、ノートオフ等）が含まれているが、本実施形態においては、アタック部、ボディ部、ジョイント部およびリリース部のモジュールを指定するモジュール指定部（奏法ＩＤと奏法パラメータを含む奏法指定情報）が含まれている。これらモジュール指定部は、実際には未定義のシステム・エクスクルーシブ・メッセージやメタイベント、１４ビットのコントロールチェンジ等が用いられる。さらに、各トラックには、これらイベントデータまたはモジュール指定部間の時間差を指定する時間差データが含まれている。
【００３２】
ここで、各トラックに音色を指定するプログラムチェンジ、すなわち新しいデータベース（奏法テーブル＋コードブック）を指定するプログラムチェンジが含まれていた場合には、楽譜解釈部１０１Ｂは該プログラムチェンジを予測データとして波形合成部１０１Ｄに供給する。これは、波形合成部１０１Ｄは、次に使用されるベクトルデータを予測してコードブックから読み出すため、予測範囲をある程度絞りこむためにプログラムチェンジを特定したものである（詳細は後述する）。なお、予測データには、他の種々のデータも含まれる。楽譜解釈部１０１Ｂにおいては曲データに基づいて、「その後の奏法指定を示すデータ」が予測データとして波形合成部１０１Ｄに供給される。その予測データの一つとして上記プログラムチェンジが含まれるのである。
【００３３】
３．３．奏法合成部１０１Ｃ
奏法合成部（アーティキュレーター）１０１Ｃは楽譜解釈部（プレーヤー）１０１Ｂにより変換された奏法指定（奏法ＩＤ＋奏法パラメータ）に基づいて奏法テーブルを参照して、奏法指定（奏法ＩＤ＋奏法パラメータ）に応じたパケットストリーム（あるいはベクトルストリームとも呼ぶ）及び奏法パラメータに応じた該ストリームに関するベクトルパラメータを生成し、波形合成部１０１Ｄに供給する（ステップＳ１３）。パケットストリームとして波形合成部１０１Ｄに供給されるデータは、ピッチ（Pitch）要素及び振幅（Amplitude）要素に関してはパケットの時刻情報、ベクトルＩＤ、代表点値列などであり、波形（Timbre）要素に関してはベクトルＩＤ、時刻情報などである（詳しくは後述する）。
【００３４】
次に、波形合成部１０１Ｄはパケットストリームに応じてコードブックからベクトルデータを取り出し、該ベクトルデータをベクトルパラメータに応じて変形し、変形したベクトルデータに基づいて波形を合成する（ステップＳ１４）。それから、他パートの波形生成処理を行う（ステップＳ１５）。ここで、他パートとは、複数の演奏パートのうち奏法合成処理を行わない、通常の楽音波形合成処理が適用される演奏パートである。例えば、これらの他のパートは通常の波形メモリ音源方式で楽音生成を行う。この「他パートの波形生成処理」は、専用のハードウエア音源（外部の音源ユニットやコンピュータに装着可能な音源カード）に行わせてもよい。説明を簡略化するために、この実施形態では奏法（若しくはアーティキュレーション）に応じた楽音生成を行うのは１パートのみの場合とする。勿論、複数パートで奏法再生してもよい。
【００３５】
図６は、上述した奏法合成部１０１Ｃにおける奏法合成処理の流れを説明するためのブロック図である。ただし、図６では奏法モジュールとコードブックが別々に記憶されているように図示したが、実際には両方ともハードディスク１０９のデータベース内に記憶されている。
奏法合成部１０１Ｃは、楽譜解釈部１０１Ｂからの奏法指定（奏法ＩＤ＋奏法パラメータ）と時刻情報のデータに基づいて、波形合成部１０１Ｄに供給する各種パケットストリームを作成する。奏法合成部１０１Ｃで各音色毎に使用している奏法モジュールは固定的ではなく、ユーザが新たに奏法モジュールを使用中の奏法モジュールに追加したり、使用している奏法モジュールの一部の奏法モジュールの使用を中止したりすることができる。また、奏法合成部１０１Ｃでは、選択された要素データと奏法パラメータの値との間のズレ分を補正するための補正情報を作成する処理や、前後の奏法モジュールの波形特性を滑らかに接続する接続部の平滑化などの処理も行う（詳しくは後述する）。
なお、標準的には楽譜解釈部１０１Ｂから奏法合成部１０１Ｃに対してデータが与えられるがそれに限らず、前述のとおり、楽譜解釈部１０１Ｂにより既に解釈の終わっている奏法指定付き曲データ乃至人間が楽譜の解釈をして奏法ＩＤや奏法パラメータを付与した奏法指定付き曲データを用意して、それを再生したデータを奏法合成部１０１Ｃに供給するようにしてもよい。
【００３６】
図７は、奏法合成処理の一実施形態を詳細に示したフローチャートである。
奏法合成部１０１Ｃは、奏法ＩＤ及び奏法パラメータに応じて奏法テーブルから奏法モジュールの選択を行う（ステップＳ２１）。すなわち、楽譜解釈部１０１Ｂから送信された奏法ＩＤ（楽器情報＋モジュールパーツ名）と奏法パラメータに応じて１つの奏法モジュールを選択する。この際に、楽譜解釈部１０１Ｂは楽譜を解釈する前に楽器情報の示す音色に対応してどのようなモジュールパーツが奏法テーブルに存在するかを予めデータベースをチェックして確認し、存在しているパーツの範囲で奏法ＩＤを指定する。なお、存在しないパーツが指定された場合には、その代わりに類似の特性を有する奏法ＩＤが選択されるようにしてもよい。次に、該指定された奏法ＩＤと奏法パラメータに応じて複数の要素データを選択する（ステップＳ２２）。すなわち、指定された奏法ＩＤと奏法パラメータとにより奏法テーブルを参照することにより、奏法モジュールを特定し、該モジュールから該奏法パラメータに対応した複数の要素データを選択する。この際に、奏法モジュール中に奏法パラメータに完全一致する要素データが存在しない場合には、その値に近い奏法パラメータに対応した要素データが選択される。
【００３７】
次に、時刻情報に応じて要素データ中の各位置の時刻を算出する（ステップＳ２３）。すなわち、各要素データを、時刻情報に基づいて絶対的な時間位置に配置する。具体的には、時刻情報に基づいて、各相対的な時間位置を示す要素データから対応する絶対時間を算出する。こうして、各要素データのタイミングを決定する（図３参照）。そして、奏法パラメータに応じて各要素データの値を補正する（ステップＳ２４）。すなわち、選択された要素データと奏法パラメータの値との間のずれ分を補正する。例えば、楽譜解釈部１０１Ｂから送信されたAltoSax [NormalAttack]モジュールのAttack直後の音量（奏法パラメータ）が「９５」であり、奏法テーブルに存在するAltoSax [NormalAttack]モジュールのAttack直後の音量が「１００」である場合、奏法合成部１０１ＣはAttack直後の音量が「１００」であるAltoSax [NormalAttack]モジュールの要素データを選択する。しかし、このままではAttack直後の音量が「１００」のままであることから、選択された要素データの代表点に対して補正を行うことによってAttack直後の音量を「９５」に補正する。このように、選択された要素データの値を送信された奏法パラメータの値に近づけるようにして補正を行う。また、設定されているマイクロチューニング（楽器の調律）の値に応じた補正や楽器の音量変化特性に応じた音量の補正等も行う。これらの補正は各要素データの代表点値を変化することにより行われ、代表点値を大きく変化することもある。すなわち、補正を行うのに必要十分なデータが代表点であり、この代表点をコントロールすることによって各種の補正を行う。
【００３８】
なお、上記ステップＳ２３では、上記奏法パラメータのような補正情報によって、上記時刻情報が示す時間位置を補正するようにしてもよい。例えば、演奏データに基づいて得られる時間位置と上記時刻情報が示す時間位置とが一致しない場合に、演奏データに基づいて得られる時間位置に近い時間位置を示す時刻情報を選択して、そこで取得した時刻位置情報を演奏データに応じて補正することで、演奏データの意図する時刻位置情報を得ることができる。また、演奏データがタッチやベロシティのような可変制御ファクタを含む場合は、その可変制御ファクタに応じて時刻位置情報を補正することで、演奏データに応じた時刻位置情報の可変制御を行うことができる。補正情報は、このような時刻位置補正を行うための情報を含む。
【００３９】
更に、各要素データを調整して隣り合う奏法モジュールの接続部を平滑化するためにリンク処理を行う（ステップＳ２５）。すなわち、前後の奏法モジュールにおける接続部の代表点を互いに接近させて接続することによって、前後の奏法モジュールの波形特性が滑らかになるようにする。このような接続若しくはリンク処理は、調和成分の波形（Timbre）、振幅（Amplitude）、ピッチ（Pitch）等の各要素毎に、あるいは調和外成分の波形（Timbre）、振幅（Amplitude）の各要素毎に、別々に行われる。
【００４０】
この際、前の奏法モジュールの「リンク開始点」から、後の奏法モジュールの「リンク終了点」までの範囲で調整を行う。すなわち、「リンク開始点」から「リンク終了点」の範囲内にある代表点を「歩みより率」に基づいて調整する。この「歩みより率」は、前の奏法モジュールと後の奏法モジュールからそれぞれどれだけ歩み寄ったところで接続するかを制御するためのパラメータであり、後述するように前後の奏法モジュールの組み合わせに従って決定される。また、前後の奏法モジュールを接続した際に、波形の接続がうまく行かない場合には、前後いずれかの奏法モジュールでその波形特性のベクトルＩＤを間引くことにより接続を滑らかにする。この間引きを実現するために、「奏法モジュール組み合わせテーブル」と、これから参照される「間引き実行パラメータ範囲テーブル」と、さらにこれから参照される「間引き時間テーブル」を用意する。
【００４１】
この他にも、以下のような楽譜解釈部１０１Ｂにおけるリンク処理により波形特性を滑らかに接続することができる。例えば、奏法モジュールとは関係なく、奏法パラメータ（ダイナミクス値、ピッチパラメータ値等）の不連続部分を滑らかに接続する。あるいは、ビブラートからリリースへと移行する場合にビブラートを早めに減少させることにより、滑らかに接続する。
【００４２】
ここで、上述のリンク処理について詳しく説明する。すなわち、前後の奏法モジュールの接続部を平滑化する（ステップＳ２５参照）ための各要素データの調整について簡単に説明する。まず、図８を用いて奏法モジュールが振幅（Amplitude）要素又はピッチ（Pitch）要素と対応する場合のリンク処理について説明する。
【００４３】
前の奏法モジュールと後の奏法モジュールとの接続部における代表点の値の不連続により両者間の接続点に段差が生じている場合、まずダイナミクス接続点（Amplitudeの場合）あるいはピッチ接続点（Pitchの場合）の目標値を、前後どちらの奏法モジュール側の値により近づけるかという指標の「歩みより率」を決定する。本実施形態では「歩みより率」が図示のようなテーブルによって与えられるとする。例えば前の奏法モジュールのベクトルＩＤが「３」であり、後の奏法モジュールのベクトルＩＤが「７」である場合の「歩みより率」はテーブルから「３０」と決定される。こうして決定された「歩みより率」により前の奏法モジュールの「リンク開始点」から「奏法モジュールの終了点」まで、徐々に目標値に向けてエンベロープ形状を変形する。また、後の奏法モジュールの「リンク終了点」から「奏法モジュール開始点」まで、徐々に目標値に向けてエンベロープ形状を変形する。例えば「歩みより率」が「３０」と決定された場合、前の奏法モジュールに対する目標値は「３０」であり、前の奏法モジュールは後の奏法モジュール側に「３０」％歩みよりを行う（本実施形態では、前の奏法モジュールにおける最後の代表点が下方に「３０」％歩みよりする）。
【００４４】
一方、後の奏法モジュールは前の奏法モジュール側に「７０」（１００−３０）％歩みよりを行う（本実施形態では、後の奏法モジュールにおける最初の代表点が上方に「７０」％歩みよりする）。また、リンク開始点からリンク終了点までに存在する前後の奏法モジュールの複数代表点が上記歩みよりに伴って各々上下に歩みよりを行う。このように、歩みよりは前後する奏法モジュールの複数の代表点で行われる。なお、リンク開始点とリンク終了点は適宜定めてよいが、リンク開始点やリンク終了点を所望の代表点と同一の点に設定すると、図に示したようなリンク開始点やリンク終了点におけるエンベロープ形状の折れ曲がりがなくなるので望ましい。勿論、リンク開始点やリンク終了点を所望の代表点と同一の点に設定していない場合でも、エンベロープ形状に折れ曲がりが生じないように歩みよりを行うようにしてよいことは言うまでもない。
【００４５】
なお、「歩みより率」の決定は上述した例に限られるものではない。例えば、接続点の前後で指定された奏法パラメータに基づいて決定してもよい。または、奏法ＩＤや奏法パラメータになる前の演奏データに基づいて決定してもよい。あるいは、それらのデータの組み合わせに基づいて決定してもよい。また、上述の例では「歩みより率」により歩みよりする代表点は１つであり、その他の代表点はその歩みよりに伴って適量だけ歩みよりするようにしたが、複数の代表点各々について別々に「歩みより率」を決定し、それに従って複数の代表点を各々「歩みより率」分だけ歩みよりするようにしてもよい。
【００４６】
次に、奏法モジュールが波形（Timbre）要素である場合のリンク処理について説明する。図９〜図１２は、奏法モジュールが波形（Timbre）要素である場合のリンク処理を説明するための概念図である。図９はアタック部波形とボディ部波形とを接続した場合の波形の間引きを説明するための概念図であり、図１０はボディ部波形とリリース部波形とを接続した場合における波形の間引きを説明するための概念図である。図９では、ボディ部波形は５つのループ波形Ｌ１〜Ｌ５からなり、各々所定の時間範囲でループ再生されるものとする。同様に、図１０のボディ部波形は６つのループ波形Ｌ１´〜Ｌ６´からなるものとする。
【００４７】
波形に関する要素データの調整（つまり、波形のリンク処理）の方法には種々あるが、その一例として、例えばアタック部あるいはジョイント部の奏法モジュールとボディ部の奏法モジュールとの接続（あるいは、ボディ部の奏法モジュールとリリース部あるいはジョイント部の奏法モジュールとの接続）において、波形の部分的間引きにより滑らかに接続する方法を提案する。波形と波形とを接続する際に、クロスフェード合成することはよく知られている。しかし、図９の例の場合のように、接続時点から最初のループ波形Ｌ１の開始位置までの時間ｔが短い場合、短い時間ｔ内で急なクロスフェード合成をしなければならなくなる。そのような急なクロスフェード波形合成、つまり接続する波形と波形との間の時間が非常に接近している場合に当該波形間でクロスフェード波形合成を行うと、それに伴って大きなノイズを発生する波形を生ずることになり、好ましくない。
【００４８】
そこで、波形の一部を間引き（削除）して接続する波形と波形との時間間隔を広げることにより、急なクロスフェード波形合成を行わないようにする。この場合に、アタック部やリリース部あるいはジョイント部における波形は１つの塊であって、波形を間引くことができないので、この場合はボディ部側のループ波形の間引きを行う。図９及び図１０では、黒く塗りつぶした長方形で示したループ波形Ｌ１、Ｌ６´を間引きする。例えば、図９では接続時点からの時間差が比較的長い２番目のループ波形Ｌ２とアタック部波形の末尾波形とをクロスフェード合成し、最初のループ波形Ｌ１は使用しない。同様に、図１０ではループ波形Ｌ５´とリリース部波形との間でクロスフェード合成を行い、波形Ｌ６´は使用しない。
なお、ジョイント部とは音と音の間（又は音部分と音部分の間）を任意の奏法でつなぐ波形区間のことである。
【００４９】
また、アタック部の奏法モジュールとリリース部あるいはジョイント部の奏法モジュールとの接続を波形間引きにより滑らかにする。図１１及び図１２は、アタック部波形とリリース部波形とを接続する場合における波形の間引きを説明するための概念図である。
この場合には、アタック部あるいはリリース部等の奏法モジュールが波形間引きできる場合とできない場合とがある。アタック部の奏法モジュールが波形間引きできる例としてはベンドアタック部（後半にいくつかのループ波形を持つ）がある。また、前半にいくつかのループ波形を持つリリース部の場合も波形間引きが行える。このように、波形間引きできる側の奏法モジュールを波形間引きする。例えば、ベンドアタック部とリリース部とを接続する場合には、図１１に示すようにベンドアタック部側のループ波形を間引きする（図１１では、ベンドアタック部側の黒く塗りつぶした長方形で示したループ波形を１つ間引きする）。また、ノーマルアタック部とループ波形を有するリリース部とを接続する場合には図１２に示すようにリリース部側のループ波形を間引きする（図１２では、リリース部側の黒く塗りつぶした長方形で示したループ波形を１つ間引きする）。
なお、間引く対象とするループ波形は奏法モジュールと奏法モジュールとの接続部に最も近いループ波形（先頭あるいは最後に位置するループ波形）とすることに限らず、複数ループ波形から所定の優先順位に従って間引く対象とするループ波形を特定するようにしてもよい。
【００５０】
このように、ある奏法モジュールの組み合わせにおいて、ある奏法パラメータの範囲で接続がうまく行かない場合に波形を間引くが、これを実現するために、例えば「奏法モジュール組み合わせテーブル」と、これから参照される「間引き実行パラメータ範囲テーブル」と、更にこれから参照される「間引き時間テーブル」を用意する。「奏法モジュール組み合わせテーブル」は、接続する前後の奏法モジュールの組み合わせにより所定のパラメータを決定するためのテーブルである。「間引き実行パラメータ範囲テーブル」は、上記パラメータ毎に間引きを行う時間の範囲を決定するためのテーブルである。「間引き時間テーブル」は、間引き時間を決定するためのテーブルである。接続時点と最初の（又は最後の）ループ波形Ｌ１（又はＬ６´）との時間差（図９〜図１２に示す時間ｔ）が基準の間引き時間より短い場合に、該ループ波形を間引く。
【００５１】
さらに、奏法モジュールのサンプル長が短く、当該奏法モジュールの後に続く奏法モジュールが開始されるよりも前に終了してしまう場合の波形接続について図１３を用いて説明する。ただし、図１３では、図の左側から右側に時系列にA.Sax[BendUpAttack]、A.Sax[NormalShortBody]、A.Sax[VibratoBody]、A.Sax[NormalRelease]の４つの奏法モジュールで波形（Timbre）要素のパケットストリームを形成している場合について説明する。各奏法モジュールのサンプル長（区間長）は、“length”で示す長さで表せられる。図１３において、最上段に記載されている「ノートオン」と「ノートオフ」は、ＭＩＤＩデータのイベントタイミングである。また、中段に記載されているA.Sax[BendUpAttack]等はそれぞれ奏法ＩＤの発生タイミングであり、note、dynamics、depth等はそれぞれ奏法パラメータの発生タイミングを示す。
【００５２】
A.Sax [BendUpAttack]モジュールは、時刻ｔ０から開始される。また、時刻ｔ１は当該モジュール内のノートオンのタイミングであり、指示されたノートオンタイミングにあわせる。また、当該モジュールのパケットストリームの内容は、上記note、dynamics、depth等の奏法パラメータに基づいて制御される。A.Sax[NormalShortBody]モジュールは、アタックモジュール直後の時刻ｔ2から開始される。時刻ｔ３は、接続部において、その途中からビブラート奏法がスタートしているタイミングである。このタイミングは、例えば、曲データに付与されたビブラート記号の開始タイミングに基づいて決定される。時刻ｔ５は、A.Sax[NormalRelease] モジュール内のノートオフタイミングであり、指示されたノートオフタイミングにあわせる。A.Sax[NormalRelease]モジュールの始まりの時刻ｔ４はそれに応じて特定される。
【００５３】
すなわち、時刻ｔ１においてノートオンされ、時刻ｔ５においてノートオフされることから、実際に当該パケットストリームから生成される波形に従って発音される時間は時刻ｔ１から時刻ｔ５までの時間である。このようなパケットストリームの場合に、時刻ｔ２から時刻ｔ４までの時間長と、その間のA.Sax[NormalRelease] モジュールとA.Sax[VibratoBody] モジュールの各サンプル長lengthの合計が合わないことが多く、適切に対処する必要が生ずる。このような場合、同じ奏法モジュールを繰り返すことによってサンプル長lengthの合計を前記時間長にあわせるか、奏法モジュールのサンプル長を可変して前記時間長に合わせるか、あるいは前記両方を組み合わせて用いて前記時間長を合わせる。このようにして、各モジュール間で調節して波形接続を行うようになっている。上述の例では、A.Sax[NormalShortBody]モジュールを繰り返すことにより、その後に続くA.Sax[VibratoBody] モジュールと波形接続を行っている。同様に、A.Sax[VibratoBody] モジュールを繰り返すことにより、その後に続くA.Sax[NormalRelease]モジュールとの波形接続を行っている。
【００５４】
上記のように、奏法モジュールを複数回繰り返して波形接続を行う場合、複数繰り返す側の奏法モジュールの時間長を可変する。この時間長の可変制御は、上述した例ではA.Sax[NormalShortBody]モジュールあるいはA.Sax[VibratoBody] モジュールにおける代表点を移動することによってなされる。すなわち、A.Sax[NormalShortBody]モジュールあるいはA.Sax[VibratoBody] モジュールを構成する複数のループ波形間のクロスフェード接続の時間を変化するなどの適宜の方法によって実現する。ループ波形の場合は、ループ回数乃至ループ継続時間を可変することによって、比較的簡単に、ループ再生波形全体の時間長を可変制御することができる。一方、ノンループ波形の場合は、時間軸上におけるその存在長を可変制御することはそれほど簡単ではない。従って、上記のように、ノンループ波形とループ波形とからなる一連の音の波形において、ループ読出区間の波形データの時間軸を伸縮可変制御することで全体の発音時間長を可変制御するように工夫することは、時間伸縮制御を容易にするので極めて好ましい。そのために、特開平１０‐３０７５８６号で本出願人が先に提案した「Time Stretch ＆ Compress」制御（略して「ＴＳＣ制御」）を用いるとよい。特に、特殊な奏法に対応するノンループ波形において時間軸の長さを可変するために、上記「ＴＳＣ制御」は好ましく応用できる。
【００５５】
このようにして作成されるパケットストリームの一例を概念的に示すと、図１４のようである。図１４では、上から順に調和成分の振幅（Amplitude）要素、ピッチ（Pitch）要素、波形（Timbre）要素、調和外成分の振幅（Amplitude）要素、波形（Timbre）要素における各パケットストリームを示す。また、調和成分の振幅（Amplitude）要素、ピッチ（Pitch）要素、調和外成分の振幅（Amplitude）要素において、黒く塗りつぶした正方形は代表点であり、これらを結ぶ曲線はパケットストリームの中のパケットに含まれるベクトルＩＤで示されたベクトルの形状を示す。調和成分の波形（Timbre）要素、調和外成分の波形（Timbre）要素において、白抜きの長方形Ｌはループ波形を示すものであり、その他の長方形ＮＬはノンループ波形を示すものである。なお、ノンループ波形のうち、斜線を引いたものは特に特徴のあるノンループ波形を示すものである。さらに、この実施形態では、NormalAttackモジュールにおける調和成分と調和外成分の波形（Timbre）要素をそれぞれ２個のベクトルで構成し、調和成分の振幅（Amplitude）要素とピッチ（Pitch）要素及び調和外成分の振幅（Amplitude）要素をそれぞれ１個のベクトルで構成している。
【００５６】
本実施形態では、調和成分、調和外成分とも、波形（Timbre）要素がノンループ波形となっている部分については、振幅（Amplitude）要素及びピッチ（Pitch）要素がベクトルを持たないようになっている。しかしながら、波形（Timbre）要素がノンループ波形であるところでも、振幅（Amplitude）要素、ピッチ（Pitch）要素のベクトルを持ち生成波形を制御するようにしてもよい。VibratoBodyモジュールでは、調和成分の波形（Timbre）要素を５個のベクトルで構成し、調和成分の振幅（Amplitude）要素とピッチ（Pitch）要素及び調和外成分の波形（Timbre）要素と振幅（Amplitude）要素をそれぞれ１個のベクトルで構成している。ここで、VibratoBodyモジュールは３回繰り返されているが、各繰り返し毎に各ベクトルの形状が異なっていることに注意してほしい。これは各繰り返し毎に異なる奏法パラメータが指定されたからである。異なる奏法パラメータに応じて異なる要素データが選択されたり、異なる奏法パラメータに応じて異なるレベル制御、時間軸制御が行われたりする。NormalJointモジュールでは、調和成分と調和外成分の波形（Timbre）要素をそれぞれ３個のベクトルで構成し、調和成分の振幅（Amplitude）要素とピッチ（Pitch）要素及び調和外成分の振幅（Amplitude）要素をそれぞれ２個のベクトルで構成している。なお、NormalBodyモジュールの説明は省略する。
【００５７】
奏法合成部１０１Ｃは、上述したようにパケットストリームを各成分（調和成分及び調和外成分）毎に生成する。これらのパケットストリームは複数個のパケットで構成されてなり、１個１個のパケットはベクトルＩＤとパケットの時刻情報とを具える。それに加えて、調和成分の振幅（Amplitude）要素、ピッチ（Pitch）要素、調和外成分の振幅（Amplitude）要素の場合には各代表点の確定値などを具える。勿論、これに限られるものではなく、ベクトルＩＤとパケットの時刻情報に加えて他の情報を具えていてよい。このような１つ１つのパケットの内容に従って、各成分毎にパケットストリームが構成されている。このように、パケットストリームには複数のパケット及びその各パケットの時刻情報（開始時刻）が含まれる。
なお、楽器の種類等によってパケットストリームの数が異なっていてよいことは言うまでもない。
【００５８】
３．４．波形合成部１０１Ｄ
３．４．１．波形合成部１０１Ｄの全般動作
波形合成部１０１Ｄは、奏法合成部１０１Ｃから供給される各成分毎のパケットストリーム（ベクトルＩＤ、時刻情報、補正情報等を含む複数のパケットの列）に基づいて波形を合成する。図１５は、波形合成部１０１Ｄにおける動作を説明するために全体構成を示した概念図である。図１６〜図１９，図２２，図２３は、波形合成部１０１Ｄにおける各動作を詳細に説明するための図面である。図１６は、波形合成の全体の流れを簡単に示すブロック図である。図１７は、ベクトルローダを説明するためのブロック図である。図１８は、ベクトルオペレータを説明するためのブロック図である。図１９は、ベクトルデコーダを説明するためのブロック図である。図２２は、奏法合成部１０１Ｃから波形合成部１０１Ｄに各パケットが供給されるタイミングを示す図であり、図２３はキャッシュ制御部４０を説明するためのブロック図である。
【００５９】
図１５において、奏法合成部（アーティキュレーター）１０１Ｃで作成された各成分要素毎のパケットストリームは、波形合成部１０１Ｄにおける各成分要素毎に対応して設けられる所定のパケットキューバッファ２１〜２５に順次にパケット入力（つまり、パケット単位での入力）される。入力されたパケットはパケットキューバッファ２１〜２５に蓄積され、順次所定の順番でベクトルローダ２０に送られる。ベクトルローダ２０ではパケット内のベクトルＩＤを参照して、当該ベクトルＩＤに対応するオリジナルのベクトルデータをキャッシュ制御部４０を介してコードブック２６から読出し（ロード）する。読出しされたベクトルデータは、各成分要素毎に対応して設けられる所定のベクトルデコーダ３１〜３５へ送られ、ベクトルデコーダ３１〜３５で各成分要素毎の波形が生成される。
【００６０】
さらに、ベクトルデコーダ３１〜３５では、生成された各成分要素毎の波形を各ベクトルデコーダ３１〜３５間で同期しながら各成分毎（調和成分及び調和外成分）の波形を生成する。こうして生成された各成分毎の波形は、ミキサ３８に送られる。奏法合成部（アーティキュレーター）１０１Ｃでは、パケットキューバッファ２１〜２５に対してパケットを入力する他、ストリーム管理（個々のベクトルデータの生成や削除あるいはベクトルデータ間の接続に関する管理）や再生コントロール（所望の波形生成の実行あるいは生成された所望の波形の再生／停止などのコントロール）などの各種の制御を波形合成部１０１Ｄに対して実行する。
【００６１】
上述したように、ベクトルローダ２０にはパケットキューバッファ２１に蓄積されたパケットストリームを構成するパケットを順次に入力され、ベクトルローダ２０は各パケット内のベクトルＩＤに基づいて、キャッシュ制御部４０を介してコードブック２６から当該ベクトルＩＤに対応するベクトルデータを読み出し、読み出したベクトルデータをベクトルデコーダ３１に送る（図１６参照）。この際に、読み出した各パケット内に補正情報（例えば、代表点に関する補正情報）が付されている場合がある。このような場合、ベクトルローダ２０では読み出したオリジナルのベクトルデータを補正情報に従って変形し、変形したベクトルデータ（これをオリジナルのベクトルデータと区別するためにベクトル情報データと呼ぶ）を情報として持つパケット（これを奏法合成部１０１Ｃから入力されたパケットと区別するためにベクトルパケットと呼ぶ）をベクトルデコーダ３１〜３５へ出力する。このように、ベクトルローダ２０は奏法合成部（アーティキュレーター）１０１Ｃから入力されたパケットのベクトルＩＤに基づきオリジナルのベクトルデータをコードブック２６から読出し、必要に応じて補正情報でベクトルデータの補正を行った上でベクトルデコーダ３１〜３５にベクトルパケットを渡す（図１７参照）。上述したようなベクトルデータの代表点に関する補正情報には、例えば乱数に基づいて時刻情報をずらすための補正情報等いろいろな補正情報がありうる。
【００６２】
図１８に示すように、ベクトルデコーダ３１〜３５は入力されたベクトルパケットを処理するためのベクトルオペレータの生成や破棄、ベクトルオペレータ間の接続・同期管理、時刻管理、他ベクトルＩＤストリームからの入力のベクトルオペレータ毎のパラメータへの変換設定などの各種のオペレータ動作管理を行うものである。ベクトルオペレータ３６及び３７では、ベクトル情報データの読み出し、あるいはベクトル情報データの読み出し位置制御（Speed入力）やゲイン制御（Gain入力）などが行われる。このベクトルオペレータ３６及び３７に設定される各種のパラメータは、ベクトルデコーダ３１〜３５で管理される。各成分要素毎に対応するようにベクトルデコーダ３１〜３５が設けられており、当該ベクトルデコーダ３１〜３５がベクトルパケット内のベクトル情報データを読み出して所望の波形の時系列的生成を行う。
【００６３】
例えば、図１９に示すように、ベクトルデコーダ３１は調和成分の振幅（Amplitude）要素のエンベロープ波形を生成し、ベクトルデコーダ３２は調和成分のピッチ（Pitch）要素のエンベロープ波形を生成し、ベクトルデコーダ３３は調和成分の波形（Timbre）要素の波形を生成し、ベクトルデコーダ３４は調和外成分の振幅（Amplitude）要素のエンベロープ波形を生成し、ベクトルデコーダ３５は調和外成分の波形（Timbre）要素のエンベロープ波形を生成する。ベクトルデコーダ３３は、ベクトルデコーダ３１及び３２で生成された調和成分の振幅（Amplitude）要素のエンベロープ波形と調和成分のピッチ（Pitch）要素のエンベロープ波形を付与した調和成分の波形を生成してミキサ３８へ出力する。すなわち、ベクトルデコーダ３３に対して、調和成分の振幅（Amplitude）要素のエンベロープ波形をゲイン制御（Gain入力）を行うためのベクトルオペレータとして、調和成分のピッチ（Pitch）要素のエンベロープ波形をベクトル情報データの読み出し位置制御（Speed入力）を行うためのベクトルオペレータとして入力する。また、ベクトルデコーダ３５では、ベクトルデコーダ３４で生成された調和外成分の振幅（Amplitude）要素のエンベロープ波形を付与した調和外成分の波形を生成してミキサ３８へ出力する。すなわち、ベクトルデコーダ３５に対しては、調和外成分の振幅（Amplitude）要素のエンベロープ波形をゲイン制御（Gain入力）を行うための制御命令として入力する。
【００６４】
さらに、各成分、要素における波形の時系列的生成の際には、各ベクトルデコーダ３１〜３５間で波形の同期を行いながら波形生成が行われる。例えば、波形（Timbre）要素のベクトルパケットと振幅（Amplitude）要素のベクトルパケットを入力した場合、波形（Timbre）要素のベクトルパケットに基づく波形合生成の時間を基準として、それに同期して振幅（Amplitude）要素のベクトルパケットに基づく振幅波形を生成する。該振幅波形により、波形（Timbre）要素のベクトルパケットに基づいて生成される波形の振幅が制御される。波形（Timbre）要素のベクトルパケットとピッチ（Pitch）要素のベクトルパケットを入力した場合、波形（Timbre）要素のベクトルパケットに基づく波形生成の時間を基準として、それに同期してピッチ（Pitch）要素のベクトルパケットに基づくピッチ波形を合成する。
【００６５】
該ピッチ波形により、波形（Timbre）要素のベクトルパケットに基づいて生成される波形のピッチが制御される。調和成分の波形（Timbre）要素のベクトルパケットと調和外成分の波形（Timbre）要素のベクトルパケットを入力する場合、調和成分の波形（Timbre）要素のベクトルパケットに基づく調和成分合成の時間を基準として、それに同期して調和外成分の波形（Timbre）要素のベクトルパケットに基づく調和外成分が合成される。合成された調和成分と調和外成分の波形を混合することにより、所望の楽音波形を生成する。
なお、この実施形態において、調和成分と調和外成分の同期または非同期を選択できるように構成し、同期が選択された場合にのみにおいて、上述の調和成分の波形（Timbre）要素のベクトルパケットに基づいて生成される調和成分の波形合成の時間を基準として、それに同期して調和外成分の波形（Timbre）要素のベクトルパケットに基づいて生成される調和外成分の波形を合成するようにしてもよい。
【００６６】
上述したように、パケットストリームは複数パケット列で構成されており、ベクトルバケットのパケットストリームの場合、各パケットには各々ベクトルデータが含まれている。すなわち、パケットストリームとはベクトルデータが時間方向に並んだものであり、振幅（Amplitude）要素のベクトルデータもピッチ（Pitch）要素のベクトルデータも波形（Timbre）要素のベクトルデータもデータ構造や意味は違うが、ベクトルオペレータ３６及び３７から見た場合は基本的に同じものである。
【００６７】
３．４．２．ベクトルデータの構造
図２０は、ベクトルデータのデータ構造の一実施形態を概念的に示す概念図である。例えば、ベクトルデータの読み出し位置の単位は[SEC]で、読み出し速度を等速とした場合、ベクトルデータ上での１サンプルは出力波形の１サンプルと一致する。また、読み出し速度の単位は１／１２００[cent]（＝２のｎ乗）で、指数ｎが０だと等速、1.0だと２倍（例えば、波形（Timbre）要素の場合には１オクターブ上がる）、-1.0だと0.5倍（例えば、波形（Timbre）要素の場合には１オクターブ下がる）となる（図２０の上段図参照）。また、コードブック２６には実際のベクトルデータが格納される。例えば、振幅（Amplitude）要素のベクトルデータあるいはピッチ（Pitch）要素のベクトルデータはVECTORPOINT構造体の配列と、代表点データとからなっている。
【００６８】
VECTORPOINT構造体の配列には各点のサンプル位置と値が順番に入っており、例えば振幅（Amplitude）要素のベクトルデータの値は[db]単位であり、ピッチ（Pitch）要素のベクトルデータの値はMIDIのノートナンバ０を0.0としたときの1/1200[cent]単位である。また、代表点データはDWORD型の配列で、代表点となるVECTORPOINT構造体の配列のインデックス番号が格納されている（図２０の下段図参照）。勿論、上述した例に限られるものでないことは言うまでもない。
【００６９】
３．４．３．キャッシュ制御部４０の詳細
（１）キャッシュ制御部４０の全体構成
次に、キャッシュ制御部４０の全体構成を図２３を参照し説明するが、このキャッシュ制御部４０を設けた意義について説明しておく。コードブック２６はハードディスク１０９内に格納されているため、ベクトルデコーダ３１〜３５が必要とするベクトルデータはハードディスク１０９から読み出されることになる。しかし、ハードディスク等はアクセス時間が遅く、かつ一定していないため、ベクトルデコーダ３１〜３５が当該ベクトルデータを加工するタイミングで即座に読み出すことは不可能である。そこで、本実施形態においては、波形合成部１０１Ｄ内にキャッシュ制御部４０を設け、将来使用される（または使用が予測されている）ベクトルデータを予めキャッシュメモリにロードすることとしている。
【００７０】
図２３において４２は先読みプリフェッチ部であり、奏法合成部１０１Ｃから波形合成部１０１Ｄに供給されるパケットからベクトルＩＤを抽出し、コードブック２６からこのベクトルＩＤに係るベクトルデータをプリフェッチ（先読み）するようにハードディスク１０９に読み出し制御を行う。上述したように、これらパケットはパケットキューバッファ２１〜２５内のパケットストリームを構成し、やがてベクトルローダ２０によって読み出されることになるが、これと並行してプリフェッチ処理が行われることになる。
【００７１】
４１は予測制御部であり、楽譜解釈部１０１Ｂから供給される予測データ（プログラムチェンジ等）と、先読みプリフェッチ部４２から供給される予測条件とに基づいて、将来使用される可能性の高いベクトルデータを予測し、予測したベクトルデータに係るベクトルＩＤを先読みプリフェッチ部４２に供給する。ここで、「予測条件」とは、使用されることが確定した（すなわち奏法合成部１０１Ｃから供給された）ベクトルＩＤ等である。このように、先読みプリフェッチ部４２においては、奏法合成部１０１Ｃおよび予測制御部４１の双方からベクトルＩＤが供給される。そして、先読みプリフェッチ部４２は、使用されることが確定しているベクトルデータのロード（すなわち奏法合成部１０１Ｃから指定されたベクトルデータのロード）を優先しつつ、双方のベクトルＩＤに係るベクトルデータについてプリフェッチ処理を行う。以下、使用されることが確定しているベクトルデータのロードを「指定ロード」と呼び、使用されることが確定していない（単に予測されたのみの）ベクトルデータのロードを「予測ロード」と呼ぶ。４４はキャッシュメモリであり、プリフェッチされたベクトルデータを格納する。４３は読出し制御部であり、ベクトルローダ２０からベクトルＩＤを受信すると、このベクトルＩＤに対応するベクトルデータを主としてキャッシュメモリ４４から読出し、ベクトルローダ２０に供給する。４５は時刻管理部であり、プリフェッチ等のタイミング制御を行う。
【００７２】
（２）予測制御部４１の動作
次に、予測制御部４１における処理内容を図２４の状態遷移図を参照し説明する。この予測制御部４１の状態は、ベクトルデコーダ３１〜３５において波形合成が行われているか否か、および合成が行われている場合にはどのモジュールに係るものかに応じて決定される。初期状態においては、ベクトルデコーダ３１〜３５において何ら波形合成が行われていないため、予測制御部４１においてはステップＳ３０の処理が行われる。ここでは、アタック部のベクトルデータの候補が予測され、予測されたベクトルＩＤが先読みプリフェッチ部４２に逐次供給される。但し、ステップＳ３０においては、楽譜解釈部１０１Ｂから予測データとして「プログラムチェンジ」が供給されていない限り、アタック部の予測は実行されない。プログラムチェンジが未定であれば、指定される可能性のあるアタック部のベクトルデータは膨大な数になるからである。従って、初期状態においては、楽譜解釈部１０１Ｂからプログラムチェンジが供給されると、直ちに該プログラムチェンジに応じたアタック部のベクトルデータの予測ロードが開始されることになる。
【００７３】
例えば、該プログラムチェンジとして「ピアノ」が指定され、「ピアノ」に係るアタック部のベクトルデータが１００種類あれば、１００種類のベクトルデータの予測ロードが開始されることになる。アタック部に係るパケットが確定されると、やがてベクトルローダ２０およびベクトルデコーダ３１〜３５においてアタック部の波形合成処理が開始される。その際、予測制御部４１の状態はステップＳ３１に遷移する。
【００７４】
ステップＳ３１においては、確定されているアタック部のベクトルＩＤに基づいて、ボディ部のベクトルデータの候補について予測ロードが行われる。すなわち、アタック部のピッチは既知であるから、候補となるベクトルデータはアタック部と同一のピッチに対応するものに限られる。さらに、確定されているアタック部のエンベロープ波形等に対応して、これに繋がる可能性があるボディ部のベクトルデータは、さらに限定される。ステップＳ３１においては、このような条件に応じて絞りこまれた候補が予測ロードされるのである。ここで、ボディ部に係るパケットが実際に奏法合成部１０１Ｃから供給され、当該ボディ部のパケットが確定されると、予測制御部４１の状態はステップＳ３３に遷移する。
【００７５】
ステップＳ３３においては、確定されているボディ部のベクトルＩＤに基づいて、次のベクトルデータの候補について予測ロードが行われる。上述したように、ボディ部に繋がるモジュールは、他のボディ部、ジョイント部あるいはリリース部のうち何れかである。従って、予測制御部４１においては、これらのベクトルデータが予測ロードされる。なお、予測ロードされるベクトルデータの候補は、確定されたボディ部のピッチやエンベロープ波形等に応じて絞りこまれることはステップＳ３１と同様である。
【００７６】
ステップＳ３３の実行中に実際に奏法合成部１０１Ｃからパケットが供給されると、当該パケットに応じて予測制御部４１の状態が遷移する。まず、供給されたパケットがボディ部のパケットであった場合には、状態はステップＳ３３に留まり、再び当該ボディ部に基づいて、他のボディ部、ジョイント部あるいはリリース部の予測ロードが実行される。また、供給されたパケットがジョイント部のパケットであった場合には、予測制御部４１の状態はステップＳ３２に遷移する。
【００７７】
ステップＳ３２においては、ボディ部のベクトルデータの候補が予測ロードされる。ここで、予測ロードされるベクトルデータの候補は、確定されているジョイント部に繋がる可能性のあるボディ部のベクトルデータに絞りこまれる。ここで、奏法合成部１０１Ｃから次のボディ部に係るパケットが供給されると、予測制御部４１の状態は再びステップＳ３３に戻り、他のボディ部、ジョイント部あるいはリリース部のベクトルデータが予測ロードされる。ここで、奏法合成部１０１Ｃからリリース部のパケットが供給されると、予測制御部４１の状態はステップＳ３０に遷移する。
【００７８】
ステップＳ３０においては、上述したように、アタック部のベクトルデータの候補が予測ロードされる。但し、その直前のリリース部のピッチが既に確定されているならば、次に来るアタック部のピッチはあまり大きく外れない可能性が高い。従って、リリース部の合成中において、予測ロードされるアタック部のベクトルデータは、当該リリース部のピッチの周辺（例えば±１オクターブの範囲）に対応するものに限定してもよい。
【００７９】
（３）先読みプリフェッチ部４２の動作
（３．１）ロード処理（図２５）
次に、先読みプリフェッチ部４２の動作を説明する。まず、先読みプリフェッチ部４２においては、所定周期毎に図２５に示すロード処理が実行される。図において処理がステップＳ４１に進むと、未だ実行されていない指定ロード要求を受けているか否かが判定される。ここで「ＹＥＳ」と判定されると、処理はステップＳ４２に進み、要求を受けたベクトルデータの指定ロードが実行される。これにより、暫くの読出し時間が経過すると、ハードディスク１０９からこれらベクトルデータが読出されキャッシュメモリ４４に格納されることになる。
【００８０】
一方、ステップＳ４１において「ＮＯ」と判定されると、処理はステップＳ４３に進み、予測ロードが実行される。すなわち、予測ロード要求のあったベクトルデータのうち、キャッシュメモリ４４内への読出し指令が行われているもの（既にキャッシュメモリ４４内にロードされているものと、他のロード要求に応じてロードが予定されているもの）と、未だハードディスク１０９に読出し指令が行われていないものとが検出され、後者のみについてハードディスク１０９に読出し指令が供給される。なお、予測ロードされるベクトルデータが多い場合には、予測ロードの途中で再び本ルーチンが呼び出される場合もある。かかる場合にも、要求された指定ロードが存在する限りは、当該予測ロードが中断され、ステップＳ４２を介して指定ロードが実行されることになる。このように、先読みプリフェッチ部４２においては、予測ロードよりも指定ロードの方が優先的に実行される。
【００８１】
（３．２）パケット受信処理（図２６）
また、先読みプリフェッチ部４２においては、奏法合成部１０１Ｃからパケットが供給される毎に図２５に示すパケット受信処理が実行される。図において処理がステップＳ５１に進むと、供給されたパケットからベクトルＩＤが抽出され、該ベクトルＩＤに対応するベクトルデータがヒットしているか否かが判定される。ここで、「ヒットした場合」とは、(１)既にキャッシュメモリ４４内に予測ロードされたベクトルデータのうち何れかが的中した場合、(２)未だキャッシュメモリ４４にロードされいないが、当該ベクトルデータの予測ロードが予定されていた場合、(３)過去にロードされ使用済みになった（USED状態の）ベクトルデータがそのまま使用できる場合、のうち何れかである。
【００８２】
なお、本実施形態においては、使用済みのベクトルデータは直ちに解放されるのではなく、「USED状態」のベクトルデータとして一応キャッシュメモリ４４内に残される。そして、他のベクトルデータを記憶する記憶容量が足りなくなった場合等において、USED状態のベクトルデータの領域が解放され、新たなベクトルデータが記憶されるのである。なお、その詳細については後述する。
【００８３】
さて、ヒットするベクトルデータが存在しなかった場合は、ステップＳ５１において「ＮＯ」と判定され、処理はステップＳ５３に進む。ここでは、上記パケットに含まれていたベクトルＩＤについて、指定ロード要求が発生する。従って、次に上述したパケット受信処理（図２６）が実行される際に、該ベクトルデータが指定ロードされることになる。
【００８４】
一方、ヒットしたベクトルデータが存在する場合は「ＹＥＳ」と判定され処理はステップＳ５２に進む。ここでは、該ベクトルデータに係る予測ロードが完了していなければ、該予測ロード要求が指定ロード要求に変更される。これは、その後にパケット受信処理が実行される際、優先的にロードされるからである。次に、処理がステップＳ５４に進むと、奏法合成部１０１Ｃに対して、指定ロード要求されたベクトルデータのハンドルが返される。このハンドルは、ベクトルデータに対して一意に対応するものである。仮に指定ロード要求されたベクトルデータが既にキャッシュメモリ４４に格納されていればそのベクトルデータのハンドルが返され、格納されていなければ、新たなハンドルが生成され奏法合成部１０１Ｃに返されることになる。
【００８５】
次に、処理がステップＳ５５に進むと、先に発生した予測ロード要求のうち外れたものがキャンセルされる。ここで、「キャンセル」の具体的内容については後述する。次に、処理がステップＳ５６に進むと、予測制御部４１における予測条件が変更される。すなわち、奏法合成部１０１Ｃから供給されたパケットに応じて、図２４の各状態における予測ロードの候補が絞りこまれ、あるいは予測制御部４１における状態が遷移される。
【００８６】
このパケット受信処理は、奏法合成部１０１Ｃ側から見れば図２８に示す「GetVector指令」になる。すなわち、奏法合成部１０１Ｃが波形合成部１０１Ｄに対してパケットを供給する動作は、該パケットに含まれるベクトルＩＤに基づいて「ベクトルデータを得よ」という意味のGetVector指令を送信することに他ならない。このベクトルデータは後にベクトルローダ２０において読み出されるまでに準備しなければならないが、その時点において多数のベクトルデータの中から所要のベクトルデータを特定するためにハンドルが必要なのである。
【００８７】
（４）キャッシュメモリ４４内のデータ構造
（４．１）キャッシュページ（図２７）
キャッシュメモリ４４に格納されるベクトルデータのうち同時に使用されるものは、パッキングされ、１ファイル（あるいはベクトルデータの総数以下の複数ファイル）に変換される。この変換は、ユーザの指示あるいは作成された曲データに応じて、演奏に先立って自動的に実行される。その例を図２７に示す。図において、コードブック２６から読み出されるベクトルデータのうち指定ロードされるものは、時刻情報が含まれている。従って、同時に使用される複数のベクトルデータを抽出することができる。コードブック２６から読み出された各ベクトルデータは個々にヘッダを有している。同時に使用されるベクトルデータは、例えば１つのファイルにまとめられ、このファイルに対して共通のヘッダが付与される。これにより、ベクトルローダ２０が各ベクトルデータにアクセスする時間を短縮することができる。
【００８８】
このファイルのヘッダには、以下のような情報が記憶される。
データID：ここには、ファイルの種類を識別する４バイトの識別文字「PACK」が記憶される。
Data Size:ファイルのデータサイズを示す
VQ Type：記憶されているベクトルデータの種別を示す。
Version:ファイルフォーマットのバージョンを示す。
なお、パッキングされる前のベクトルデータについても同様のヘッダが設けられているが、データIDは「PACK」ではなく、個々のベクトルデータの種別を識別するデータIDが付与される。
【００８９】
本実施形態の波形生成装置は、パーソナルコンピュータ上のアプリケーションプログラムによって実現されており、そのキャッシュはシステムメモリ上に存在する。ベクトルデータをキャッシュに記憶する場合、一つのベクトルデータ単位（サイズが不均一）で制御するのではなく、所定サイズのキャッシュページを単位としてキャッシュ制御が行われる。つまり、一つのキャッシュデータは複数のキャッシュページに分割され、キャッシュページ単位でキャッシュに記憶され管理される。また、システムメモリには、各キャッシュページに対応するキャッシュ管理データ（ページヘッダ）が記憶されている。なお、ハードディスクへのデータ記憶は、通常、固定サイズのクラスタ単位で行われているので、キャッシュページのサイズは、そのサイズと同じか、あるいはその整数倍にするとよい。ベクトルデータの容量等を考慮すると、キャッシュページのサイズは１ｋ〜１０ｋバイトにすることが好適である。
【００９０】
（４．２）ページヘッダのデータ構造
次に、各キャッシュページに付与されているヘッダのデータ構造について説明する。各ヘッダは、「VDDLCSPAGE」なる構造体によって構成されており、該構造体のメンバは以下の通りである。
dwPage：当該キャッシュページに対して一意に付与されるページ番号である。
dwID：このキャッシュページに含まれるベクトルデータのベクトルＩＤである。
dwSize: このキャッシュページのデータサイズである。
dwCount:プリフェッチ回数を示す。このメンバdwCountは、指定ロードによってプリフェッチされる毎に「１」づつインクリメントされ、ベクトルローダ２０によって読み出される毎に「１」づつデクリメントされる。
dwStatus: 当該キャッシュページの状態を示す。キャッシュページの状態は、FREE，ALLOCATED，USED，FILLED，LOCKEDのうち何れかである。
lpBuf: 当該キャッシュページにおけるベクトルデータの実体（ヘッダ以外の部分）の先頭アドレスを指標するポインタである。
lpForward／lpBackward：本実施形態においては、複数のVDDLCSPAGE構造体によって双方向リンクドリストが形成される。メンバlpForwardは、リンクの前方向に存在する他のVDDLCSPAGE構造体へのポインタであり、メンバlpBackward：は、リンクの後方向に存在する他のVDDLCSPAGE構造体へのポインタである。
lpNext: 上述したように、波形生成装置を専用のハードウエア上で実現する場合等においては、同時の使用される複数のベクトルデータが複数のキャッシュページに分割される。これら複数のキャッシュページは「グループ」を構成しており、メンバlpNextは同一グループに属する他のVDDLCSPAGE構造体を順次指標してゆくポインタである。
【００９１】
ここで、上記メンバdwCountの役割について述べておく。例えば、一連のパケットストリームにおいて、同一のベクトルデータが２回使用されるならば、該ベクトルデータについて２回の指定ロード要求が発生することになる。しかし、ベクトルローダ２０によって１回目に読出された際に該キャッシュページをUSED状態に設定してしまうと、２回目の読出しができなくなる。そこで、該キャッシュページがあと何回読み出されるのかをカウントすることにより、かかる不具合を防止したものである。
ところで、ベクトルデータが複数回用いられる場合としては、同一のイベントデータに対する波形合成処理において同一のベクトルデータが複数回用いられる場合と、複数のイベントデータに対する波形合成処理において同一のベクトルデータが複数回用いられる場合とが考えられる。本実施形態においては、何れの場合においてもメンバdwCountによって残りの使用回数が判別されるから、キャッシュメモリ４４内のキャッシュページに対して統一的な取扱が可能になる。
【００９２】
（４．３）ページヘッダのリンク構造（図２９）
次に、ポインタlpForwardとポインタlpBackwardによって実現される双方向リンクドリストの構造を図２９に示す。本実施形態においては、データの並べ替えや、追加／削除を自由にかつ高速に実行するため、図示のようなリスト構造を採用した。
図においてＡ−１は双方向リンクドリストの先頭に位置するページヘッダであり、その先頭は所定のポインタlpTopによって指標され、末尾はポインタlpTailによって指標されている。Ａ−２，Ａ−３はページヘッダＡ−１と同一のグループに属するページヘッダである。すなわち、この「グループ」は、一つのファイルが分割されて形成された個々のキャッシュページのデータに相当する。ページヘッダＡ−２の先頭アドレスはページヘッダＡ−１のメンバlpNextによって指標され、ページヘッダＡ−３の先頭アドレスはページヘッダＡ−２のメンバlpNextによって指標されている。
【００９３】
また、Ｂ−１はページヘッダＡ−１の次段にリンクされているページヘッダであり、ページヘッダＢ−１の先頭アドレスはページヘッダＡ−１のメンバlpForwardによって指標されている。そして、このページヘッダＢ−１のメンバlpNextによって、同一グループに属するページヘッダＢ−２の先頭アドレスが指標されている。また、ページヘッダＢ−１のメンバlpForwardによって、次段にリンクされているページヘッダＣ−１の先頭アドレスが指標され、ページヘッダＣ−１，Ｃ−２のメンバlpNextによって、各々ページヘッダＣ−２，Ｃ−３の先頭アドレスが指標されている。ここで、FREE状態のキャッシュページも１グループを構成するため、例えばグループＡ，ＢはFILLED状態、グループＣはFREE状態に設定される。新しいベクトルデータをキャッシングしようとするときは、FREE状態あるいはUSED状態のグループからキャッシュページが取得され、そのキャッシュページが新たなベクトルデータのキャッシュページに設定されることになる。
【００９４】
また、システムメモリ上に新たなキャッシュページおよび対応するページヘッダを作成し、これを新たなベクトルデータのキャッシュページにしてもよい。但し、その場合には、キャッシュページの総量を指定値に制限し、メモリ資源を消費しすぎないようにしておくと好適である。この指定値は、システムメモリ量に応じて自動設定してもよく、ユーザが手動設定してもよい。また、FREE状態のグループのメモリ量としてある一定値を常に確保するように制御すると、新たなベクトルデータのキャッシュページへの割当を高速化することができる。
【００９５】
図２９の双方向リンクドリストによれば、メンバlpForwardを参照してゆくことにより、リストを構成する各グループの先頭のページヘッダＡ−１，Ｂ−１，Ｃ−１を順番に辿ることができる。また、メンバlpBackwardを参照してゆくことにより、該双方向リンクドリストを逆方向に辿ることができる。従って、あるベクトルデータがキャッシュされているか否かを調査する場合は、リストを構成する先頭のページヘッダを順次辿ってゆき、ページヘッダ内のメンバdwIDが該ベクトルデータと同一のベクトルＩＤと一致するか否かを判定してゆくとよい。もし一致するものが存在すれば、そのページヘッダに係るキャッシュページが、該ベクトルデータをキャッシングしているグループの先頭のキャッシュページになる。なお、同時に使用される全ベクトルデータが必ず１ページに格納される場合には、上記双方向リンクドリストはページヘッダＡ−１，Ｂ−１，Ｃ−１のみによって構成されることになり、これらページヘッダのメンバlpNextには、ヌルデータが格納されることになる。
【００９６】
なお、上記メンバdwStatusで示される各状態を重要度順に配列すると、「LOCKED≧FILLED＞ALLOCATED＞USED＞FREE」の順になる。そこで、この重要度順でキャッシュページの順序を設定しておけば、新たなベクトルデータに対するキャッシュページの割当を高速化することができる。さらに、メンバdwCountの値をそのまま重要度に反映させてもよい。すなわち、メンバdwCountが大きいほど重要度を高くするとよい。また、USED状態のキャッシュページ間では、先にUSED状態に遷移したものの重要度がより低くなるように設定しておくと好適である。
【００９７】
（５）読出し制御部４３における動作
次に、読出し制御部４３の動作を再び図２８を参照し説明する。
ベクトルローダ２０においては、パケットストリームの内容すなわち各パケット内のベクトルＩＤに基づいて、キャッシュメモリ４４を読み出すように読出し制御部４３にコマンドが送信される。このコマンドをLockVector指令と呼ぶ。このLockVector指令には、先にGetVector指令に応じて返したハンドルが付随されている。通常の動作状態であれば、該ベクトルデータはキャッシュメモリ４４内に格納されている筈であるから、該ベクトルデータに係るキャッシュページの先頭アドレスのポインタがベクトルローダ２０に返される。
【００９８】
これにより、ベクトルローダ２０およびベクトルデコーダ３１〜３５によって、キャッシュメモリ４４の内容が適宜読み出され、波形合成処理が実行される。このように、ベクトルローダ２０等によって読み出され得るキャッシュページは、LOCKED状態（詳細は後述する）に設定され、他の処理によって内容が改変されないよう設定されている。
【００９９】
ところで、状況によっては、ベクトルローダ２０からLockVector指令を受信した際にキャッシュメモリ４４上に必要なベクトルデータが未だロードされていない場合がある。特に本実施形態の波形生成装置をパーソナルコンピュータのアプリケーションプログラムによって実現した場合には、パーソナルコンピュータのオペレーティングシステムの都合によって比較的長時間ハードディスク１０９が占有されることがあり、かかる状況がしばしば発生し得る。この場合には、波形生成装置の動作モードによって異なる処理が実行される。
【０１００】
まず、ノンリアルタイムで波形合成を行っている場合は、指定されたベクトルデータがロードされるまで以降の処理を停止することが好適である。そこで、読出し制御部４３においては、ハードディスク１０９に対する同期読出しが実行される。この同期読出しは、所望のデータが読み出されるまで他の処理を行わないことを意味する。
【０１０１】
一方、波形生成装置がリアルタイムで動作している場合には、同期読出しを実行することは楽音が途切れることになりかねないため、代替ページのポインタがベクトルローダ２０に返される。本実施形態においては、様々な音色変化を忠実に表現するために多種類のベクトルデータを用いているが、プログラムチェンジで選択された音色について、奏法表現等を伴わない基本的な発音を行うためのベクトルに限定すれば、その容量はあまり大きくない。そのようなベクトル（複数）が、その音色のデフォルトのベクトルとして予めＲＡＭ１０３内に格納されており、キャッシュメモリ４４内に準備できなかったベクトルデータの代替として用いられる。
【０１０２】
なお、リアルタイム合成を行う場合であっても、波形合成処理Ｓ１４（波形合成部１０１Ｄ）における時間遅延が充分確保されており、その範囲内で必要なベクトルのロードおよび波形合成が可能な場合は、ノンリアルタイムで波形合成を行う場合と同様に、必要なベクトルデータがロードされていないことが判明した段階で、該ベクトルデータを緊急に読み出して波形合成を行うことができる。ベクトルローダ２０およびベクトルデコーダ３１〜３５による使用が終了したキャッシュページについては、ベクトルローダ２０から読出し制御部４３にハンドルを伴ったRelease指令が供給される。このRelease指令が供給されると、該キャッシュページのLOCKED状態が解消され、ハンドルが解放される。
【０１０３】
（６）キャッシュページに対する状態遷移動作
次に、図３０の状態遷移図を参照し、各キャッシュページの状態を遷移させてゆく動作について説明する。
まず、初期状態においては、全キャッシュページはFREE状態（Ｓ６１）に設定される。すなわち該キャッシュページのヘッダのメンバdwStatusが‘FREE’に設定される。これは、未使用状態であって、内容が保証されていないことを意味する。このキャッシュページに対して、ベクトルデータのロードが行われる場合は、該キャッシュページがALLOCATED状態（Ｓ６２）に設定される。ALLOCATED状態は、未だデータの格納は完了していないが、コードブック２６からのデータ読出しのために予約されていることを意味する。その際、メンバdwCountに「１」が格納される。
【０１０４】
その後、ベクトルデータが該ページに格納されると、キャッシュページの状態はFILLED状態に遷移する。ALLOCATED状態またはFILLED状態において、同一のベクトルデータについて再び指定ロード要求が発生すると、その度にメンバdwCountが「１」づつインクリメントされる。また、ALLOCATED状態またはFILLED状態において、予測ロード要求がキャンセルされると（ロード処理（図２５）のステップＳ５５）、メンバdwCountが「１」づつデクリメントされる。そして、これらの状態においてメンバdwCountの値が「０」になると、該キャッシュページはUSED状態（Ｓ６３）に設定される。
【０１０５】
キャッシュページがFILLED状態に遷移した後、ベクトルローダ２０からLockVector指令が供給されると、該キャッシュページがLOCKED状態（Ｓ６５）に設定される。そして、ベクトルローダ２０およびベクトルデコーダ３１〜３５による当該キャッシュページの使用が終了しRelease指令が供給されると、LOCKED状態が解消され（UnLockされ）、該キャッシュページが再びFILLED状態（Ｓ６４）に設定される。その際、該キャッシュページのメンバdwCountが「１」だけデクリメントされる。その際、メンバdwCountが「０」になった場合には、該キャッシュページの状態は直ちにUSED状態（Ｓ６３）に設定される。
【０１０６】
また、キャッシュページがUSED状態に設定された後、該キャッシュページに対して再び予測ロード要求または指定ロード要求（プリフェッチ）が発生すると、該キャッシュページは再びFILLED状態に戻される。以上のような処理が続行すると、やがてキャッシュメモリ４４内にUSED状態のキャッシュページが増加してゆき、FREE状態のキャッシュページが減少してゆく。そして、FREE状態のキャッシュページが無くなった後に、新たなベクトルデータについてプリフェッチが発生すると、USED状態であるキャッシュページのうち最も古くUSED状態になったものから順にキャンセル（SwapOut）され、FREE状態（Ｓ６１）に戻される。そして、このFREE状態に戻されたキャッシュページが、上記新たなベクトルデータのロードのためにALLOCATED状態に設定される。
【０１０７】
ここで、USED状態であるキャッシュページのうち最も古いものを速やかに特定する方法として、先に図２９において説明した双方向リンクドリストを用いるとよい。すなわち、何れかのキャッシュページがUSED状態に設定されると、リンクドリストの先頭に該キャッシュページを追加し、FREE状態のキャッシュページが不足する場合には、リンクドリストの末尾のキャッシュページから順次リンクドリストから外し、FREE状態に変更してゆくとよい。
【０１０８】
（７）時刻管理部４５
時刻管理部４５は波形合成部１０１Ｄ全体のタイミングを制御する。ここで、本実施形態におけるタイミング制御の概要を図３１を参照し説明する。
図において、時刻ｔ30に再生開始が指示された（例えばユーザにより再生ボタンが押下された）こととし、実際に楽音出力が開始される時刻をｔ40とする。この時刻ｔ30からｔ40に至るまでの時間をレーテンシβと呼ぶ。レーテンシβは、例えば2000ｍｓｅｃ程度に設定されるが、特に設定しなくてもよい。
【０１０９】
再生開始が指示されると、ＣＰＵ１０１において再生スレッドが所定時間毎に生成される。この再生スレッドにおいては曲データが読み出され、その内容に応じてハードディスク１０９等に対するプリフェッチ処理が実行される。ある曲データが読み出される時刻ｔ32から実際の発音開始時刻ｔ40までの時間を先送り時間γと呼ぶ。先送り時間γの基準値は例えば4000ｍｓｅｃ程度にしておき、処理状況に応じて1000〜10000ｍｓｅｃ程度の範囲で伸縮できるようにしておくとよい。
【０１１０】
このように、先送り時間γをある程度確保しておくことにより、再生スレッドを断続的に発生させ曲データの読出しを断続的に（ある程度づつまとめて）行うことが可能になる。再生スレッドが発生する間隔を再生スレッド発生間隔εと呼ぶ。再生スレッド発生間隔εの基準値は例えば２０ｍｓｅｃにしておき、処理状況に応じて５〜１００ｍｓｅｃ程度の範囲で伸縮できるようにしておくとよい。
【０１１１】
時刻ｔ32に曲データが読み出されると、上述したようにステップＳ１１において曲データの一部が取り出され、ステップＳ１２において楽譜が解釈され、しかる後にステップＳ１３において奏法合成が実行される。この結果、時刻ｔ34においてベクトルデータのプリフェッチが行われる。プリフェッチ時刻ｔ34から発音開始時刻ｔ40までの時間をプリフェッチ時間αと呼ぶ。
【０１１２】
ハードディスク１０９から読み出されたベクトルデータは、やがてキャッシュメモリ４４に書き込まれる。その後、時刻ｔ36において、ベクトルローダ２０によって読出し制御部４３を介してキャッシュメモリ４４から該ベクトルデータが読み出され、波形合成が開始される。この波形合成開始時刻ｔ36から発音開始時刻ｔ40までの時間を出力レーテンシδと呼ぶ。出力レーテンシδの基準値は例えば３００ｍｓｅｃ程度にしておき、処理状況に応じて１０〜１０００ｍｓｅｃ程度の範囲で伸縮できるようにしておくとよい。
【０１１３】
なお、かかる波形合成処理についても、再生スレッドの場合と同様に、ある程度の時間範囲をまとめて断続的に実行すると好適である。この波形合成処理の起動頻度間隔の基準値は例えば５０ｍｓｅｃにしておき、処理状況に応じて１０〜５００ｍｓｅｃ程度の範囲で伸縮できるようにしておくとよい。
【０１１４】
図３１から明らかなように、先送り時間γ、プリフェッチ時間αおよび出力レーテンシδには、「γ＞α＞δ」の関係がある。ここで、プリフェッチ時刻ｔ34から波形合成開始時刻ｔ36までの時間間隔「α−δ」は、ハードディスク１０９からベクトルデータをロードできる程度に設定しておく必要がある。ベクトルデータのロード量のピーク値が高い場合には、この時間間隔「α−δ」を長くすることにより、ノイズの発生等を防止することができる。
【０１１５】
４．変形例
本発明は上述した実施形態に限定されるものではなく、例えば以下のように種々の変形が可能である。
（１）上述したような波形生成装置を電子楽器に用いた場合、電子楽器は鍵盤楽器の形態に限らず、弦楽器や管楽器、あるいは打楽器等どのようなタイプの形態でもよい。また、その場合に、曲データ再生部１０１Ａ、楽譜解釈部１０１Ｂ、奏法合成部１０１Ｃ、波形合成部１０１Ｄ等を１つの電子楽器本体内に内蔵したものに限らず、それぞれが別々に構成され、ＭＩＤＩインタフェースや各種ネットワーク等の通信手段を用いて各構成部を接続するように構成されたものにも同様に適用できることはいうまでもない。また、パソコンとアプリケーションソフトウェアという構成であってもよく、この場合処理プログラムを磁気ディスク、光ディスクあるいは半導体メモリ等の記録媒体に格納して供給したり、ネットワークを介して供給するものであってもよい。さらに、自動演奏ピアノのような自動演奏装置などにも適用してよい。
【０１１６】
（２）上記実施形態においては、一つのキャッシュページに複数のベクトルデータを格納したが、一つのキャッシュページに一つのベクトルデータを格納するようにしても良いことは言うまでもない。
【０１１７】
（３）上記実施形態においては、キャッシュページのヘッダのメンバdwCountをインクリメントあるいはデクリメントすることによって、USED状態に遷移させるものを判定した。しかし、かかる方法では、未使用状態のキャッシュページが増大した時にキャッシュメモリ４４が容量不足になる可能性がある。かかる場合には、FILLED状態であるキャッシュページに対して「優先度」を定義し、優先度の低いFILLED状態のキャッシュページを順次USED状態そしてFREE状態に遷移させてもよい。この場合、FREE状態に遷移させたキャッシュページに対してベクトルローダ２０からLockVector指令を受信すると、上述した代替ページが使用されることになる。「優先度」の具体例としては、メンバdwCountの値をそのまま用いてもよい（値が大きいほど優先度が高いこととする）。また、過去に当該キャッシュページが使用された回数、メンバdwCountの最大値（過去の履歴上での最大値）を加味してもよい。
【０１１８】
（４）上記実施形態においては、USED状態であるキャッシュページを双方向リンクドリストによって結合し、FREE状態のキャッシュページが不足する場合には、リンクドリストの末尾のキャッシュページから（最も古いものから）順次外してゆき、FREE状態に変更した。しかし、FREE状態に遷移させる順序はこれに限定されるものではない。例えば、使用された累積回数の多いキャッシュページ、メンバdwCountの履歴上の最大値の大きいキャッシュページ、あるいは各モジュールの先頭部分において使用されるベクトルデータについては、なるべくFREE状態に遷移しないように、換言すればキャッシュメモリ４４内に優先的に残すように設定してもよい。また、実際に使用された使用済みのベクトルデータを、実際には使用されなかった（予測が外れた）ベクトルデータよりも優先的に残すようにしてもよい。
【０１１９】
また、モジュールの先頭部分で使用されるベクトルデータを優先的に残しておくことにより、ハードディスク１０９の動作に対する余裕が大きくなり、代替ページを使わざるを得なくなるような事態を減らすことができる。
具体的には、優先的に残すべきキャッシュページをUSED状態に遷移させる時は当該キャッシュページをリンクドリストの先頭に追加し、それ以外のキャッシュページをUSED状態に遷移させる時は該キャッシュページをリンクドリストの中間部分に挿入するようにするとよい。
【０１２０】
（５）上記実施形態においては、音データの具体例としてベクトルデータを用いた例を示したが、該音データはベクトルデータに限定されるものではなく、楽音波形を規定する種々の波形データあるいはパラメータを音データとして用いてもよいことは言うまでもない。
【０１２１】
（６）上記実施形態においては、図１５ないし図２３において説明したように、奏法合成部１０１Ｃからのパケットストリームが先読みプリフェッチ部４２に直接入力された。しかし、かかる動作に代えて、一旦パケットキューバッファ２１〜２５に書き込まれたパケットストリームを先読みプリフェッチ部４２が読み出すようにしてもよい。その場合、先読みプリフェッチ部４２は、ベクトルローダ２０がパケットキューバッファに記憶されたパケットを読み出して処理するタイミングよりも所定時間前のタイミングで、同パケットキューバッファから同パケットを読み出して処理することが好適である。
【０１２２】
【発明の効果】
以上説明したように本発明によれば、音データが波形合成のために使用された後、該音データが各区間の先頭部分で使用される音データであるか否かに基づいて解放優先度を設定しつつ、該音データを将来も利用可能な状態で高速記憶装置に保持するから、実際に当該音データが後に使用された場合にはハードディスク等の低速記憶装置をアクセスする必要がなくなる。これにより、ハードディスク等の低速記憶装置に対するアクセス頻度を低下させることができる。
【図面の簡単な説明】
【図１】 この発明に係る波形生成装置のハードウエア構成例を示すブロック図。
【図２】 波形生成装置において実行される「波形データベース作成処理」の一実施形態を示すフローチャート。
【図３】 奏法モジュールに対応する実波形区間を構成する各成分及び要素の一例を模式的に示す図。
【図４】 「データベースに基づく楽音合成処理」の一実施形態を示すフローチャート。
【図５】 図４と同様の波形合成処理を専用ハードウエアの形態で構成した場合の一実施形態を示すブロック図。
【図６】 上述した奏法合成部における奏法合成処理の流れを説明するためのブロック図。
【図７】 奏法合成部で行われる奏法合成処理の一実施形態を詳細に示したフローチャート。
【図８】 奏法モジュールが振幅要素又はピッチ要素に対応する場合におけるリンク処理を説明するための概念図。
【図９】 アタック波形とボディ波形とを接続した場合の波形の間引きを説明するための概念図。
【図１０】 ボディ波形とリリース波形とを接続した場合の波形の間引きを説明するための概念図。
【図１１】 ベンドアタック波形とリリース波形とを接続した場合の波形の間引きを説明するための概念図。
【図１２】 ノーマルアタック波形とループ部を有するリリース波形とを接続した場合の波形の間引きを説明するための概念図。
【図１３】 後に続く奏法モジュールが開始されるよりも前の奏法モジュールが終了してしまう場合の波形接続について説明するための概念図。
【図１４】 奏法合成部で生成されるパケットストリームを説明するための概念図。
【図１５】 波形合成部における動作を説明するために全体構成の一実施形態を示した概念図。
【図１６】 波形合成の全体の流れを簡単に示すブロック図。
【図１７】 ベクトルローダを説明するためのブロック図。
【図１８】 ベクトルオペレータを説明するためのブロック図。
【図１９】 ベクトルレコーダを説明するためのブロック図。
【図２０】 ベクトルデータのデータ構造の一実施形態を概念的に示す概念図。
【図２１】 楽譜解釈部１０１Ｂにおいて作成される演奏データの内容を示す図。
【図２２】 奏法合成部１０１Ｃから波形合成部１０１Ｄに各パケットが供給されるタイミングを示す図。
【図２３】 キャッシュ制御部４０の全体構成を示すブロック図。
【図２４】 予測制御部４１の予測動作の状態遷移図。
【図２５】 先読みプリフェッチ部４２において実行されるロード処理のフローチャート。
【図２６】 先読みプリフェッチ部４２において実行されるパケット受信処理のフローチャート。
【図２７】 キャッシュページの構成方法を示す動作説明図。
【図２８】 奏法合成部１０１Ｃおよび波形合成部１０１Ｄ間のシグナルフロー図。
【図２９】 キャッシュメモリ４４内におけるページヘッダのリンク構造を示す図。
【図３０】 キャッシュメモリ４４内における各ページの状態遷移図。
【図３１】 上記実施形態のタイミング制御の概要を示すタイミングチャート。
【符号の説明】
１〜１２……データ、２０……ベクトルローダ、２１〜２５……パケットキューバッファ、２６……コードブック、３１〜３５……ベクトルデコーダ、３６，３７……ベクトルオペレータ、３８……ミキサ、４０……キャッシュ制御部、４１……予測制御部、４２……先読みプリフェッチ部、４３……読出し制御部、４４……キャッシュメモリ（高速記憶装置）、４５……時刻管理部、５０……アタック部奏法モジュール、１０１……ＣＰＵ、１０１Ａ……曲データ再生部、１０１Ｂ……楽譜解釈部、１０１Ｃ……奏法合成部、１０１Ｄ……波形合成部、１０２……ＲＯＭ、１０３……ＲＡＭ、１０４……パネルスイッチ、１０５……パネル表示器、１０６……ドライブ、１０６……前記ドライブ、１０６Ａ……外部記憶メディア、１０７……波形取込部、１０８……波形出力部、１０８Ａ……サウンドシステム、１０９……ハードディスク（低速記憶装置）、１１１……通信インタフェース。[0001]
BACKGROUND OF THE INVENTION
The present invention relates to a sound data transfer method, a sound data transfer device, and a program for generating a waveform of a musical tone, a voice, or any other sound based on reading of waveform data from a relatively low-speed storage medium such as a hard disk. Further, the present invention relates to a device that generates a waveform that faithfully represents timbre changes caused by various performance techniques or articulations performed by a performer. The present invention is not limited to electronic musical instruments, but also in devices, apparatuses or methods in all fields having a function of generating musical sounds, voices, or other arbitrary sounds, such as automatic performance apparatuses, computers, electronic game apparatuses and other multimedia devices. It can be applied in a wide range. In this specification, the term “musical sound waveform” is not limited to a musical sound waveform, but is used in a sense that may include a sound waveform or any other sound waveform.
[0002]
[Prior art]
In the waveform memory, waveform data (that is, waveform sample data) encoded by an arbitrary encoding method such as PCM (pulse code modulation), DPCM (differential PCM), or ADPCM (adaptive differential PCM) is stored. The so-called “waveform memory readout” technology that forms a musical sound waveform by reading out in accordance with a desired music pitch is already known, and various types of “waveform memory readout method” technologies are known. ing. Most of the conventionally known “waveform memory reading method” techniques are for generating a single sound waveform from the beginning to the end of sound generation. As an example, there is a method of storing waveform data of all waveforms of one sound from the start to the end of sound generation. As another example, there is a method of storing waveform data of all waveforms for an attack portion having a complicated change, and storing a predetermined loop waveform for a sustain portion having little change. In this specification, “loop waveform” is used to mean a waveform that is repeatedly read (loop read).
[0003]
As means for storing waveform data, ROM, RAM, hard disk, CD-ROM and the like are known. Hard disks, CD-ROMs, etc. have a low unit price per unit storage capacity and are suitable for large-capacity data storage. However, since a hard disk or the like has a slow access time and is not constant, it is impossible to immediately read out necessary waveform data at the timing of outputting a musical sound signal. For this reason, various techniques have been proposed as follows.
First, Japanese Patent Application Laid-Open No. 6-308964 discloses a technique for transferring the head portions of a plurality of waveform data stored in a hard disk or the like to a RAM in advance. That is, when a sound generation instruction is supplied, reading of the subsequent portion of the waveform data such as a hard disk is started and the head portion stored in the RAM in advance is reproduced. Then, after the reproduction of the head portion is completed, the waveform data of the subsequent portion is reproduced.
[0004]
Japanese Patent Application Laid-Open No. 63-181188 discloses a technique for reproducing each waveform data while sequentially reading the waveform data to be sounded sequentially as sequence data. In this technique, the time at which reading of each waveform data is started is determined in advance corresponding to the sequence timing so as to be earlier than the sound generation timing.
[0005]
[Problems to be solved by the invention]
However, according to the technique disclosed in Japanese Patent Application Laid-Open No. 6-308964, since it is necessary to transfer in advance the head portion of all waveform data to the RAM in advance, there is a problem that the use efficiency of the RAM is lowered. In the technique disclosed in Japanese Patent Laid-Open No. Sho 63-181188, since the hard disk or the like is always accessed for each event, the noise of the hard disk or the like is increased and the life is shortened. In addition, the hard disk or the like is frequently accessed, so that resources allocated to other processes are reduced.
The present invention has been made in view of the above-described circumstances, and an object thereof is to provide a sound data transfer method, a sound data transfer apparatus, and a program that can reduce the frequency of access to a hard disk or the like.
[0006]
[Means for Solving the Problems]
  In order to solve the above problems, the present invention is characterized by having the following configuration. The parentheses are examples.
  In the configuration according to claim 1, the tone waveformUsed for waveform synthesis for each predetermined section (module)Of the sound data stored in the low-speed storage device, a low-speed storage device (hard disk 109) for storing sound data (vector data) and a high-speed storage device (cache memory 44) for caching the sound data are used. A sound data transfer method for transferring a part to the high-speed storage device for waveform synthesis, comprising:Occurs, a free area detection process for detecting whether or not a free area for storing sound data to be newly transferred to the high-speed storage device is insufficient, and a determination that the free area is insufficient in the free area detection process In this case, the sound data storage areas previously held in the high-speed storage device are released as free areas in descending order of release priority (in order from the end of the linked list) (members). dwStatus ' FREE The sound data newly transferred from the low-speed storage device is transferred to the release process and the free area detected in the free area detection process or the free area obtained in the release process.The transfer process (step S43) and the sound data are used for waveform synthesis.After being used, when the sound data is sound data used in the head part of each section, the release priority is low, and when the sound data is sound data used in another part While setting the release priority so that the release priority becomes high (adding to the top or middle of the linked list), the sound data isAnd holding in the high-speed storage device in a usable state in the future (setting the member dwStatus to “USED”).
  Claims2In the described configuration, the claim1It is characterized by performing the described method.
  Claims3In the described configuration, the claim1It is characterized by performing the described method.
[0007]
DETAILED DESCRIPTION OF THE INVENTION
1. Hardware configuration of the embodiment
Hereinafter, an embodiment of the present invention will be described in detail with reference to the accompanying drawings.
FIG. 1 is a block diagram showing a hardware configuration example of a waveform generating apparatus according to the present invention. The hardware configuration example shown here is configured by using a computer, and in the waveform generation process, the computer executes a predetermined program (software) for realizing the waveform generation process according to the present invention. Is implemented. Of course, this waveform generation processing is not limited to the form of computer software, but can be implemented in the form of a microprogram processed by a DSP (digital signal processor), and is not limited to this form of program. You may implement in the form of the dedicated hardware apparatus comprised including the discrete circuit or the integrated circuit or the large-scale integrated circuit. The waveform generation device may take any product application form such as an electronic musical instrument, a karaoke device, an electronic game device, another multimedia device, or a personal computer.
[0008]
In the hardware configuration example shown in FIG. 1, a read only memory (ROM) 102, a random access memory (through a bus line BL (data or address bus, etc.), a random access memory (a RAM) 103, panel switch 104, panel display 105, drive 106, waveform capture unit 107, waveform output unit 108, hard disk 109, and communication interface 111 are connected to each other. The CPU 101 executes processing such as “waveform database creation” and “musical tone synthesis (software sound source) based on the produced database”, which will be described later, based on a predetermined program. These programs are supplied from a network via the communication interface 111 or an external storage medium 106 A such as a CD or MO attached to the drive 106 and stored in the hard disk 109. Then, it is loaded from the hard disk 109 to the RAM 103 at the time of execution. Alternatively, the program may be recorded in the ROM 102. The ROM 102 stores various programs executed by or referred to by the CPU 101, various data, and the like. The RAM 103 is used as a working memory that temporarily stores various information related to performance and various data generated when the CPU 101 executes the program, or as a memory that stores a program currently being executed and related data. A predetermined address area of the RAM 103 is assigned to each function and used as a register, flag, table, memory, or the like. The panel switch 104 is configured to include various operators for performing an instruction to sample a musical tone, editing sampled waveform data, and inputting various information. For example, a numeric keypad for inputting numeric data, a keyboard for inputting character data, or a panel switch. In addition to these, various operators for selecting, setting, and controlling the pitch, timbre, effect, and the like may be included. The panel display 105 is a display such as a liquid crystal display panel (LCD) or a CRT that displays various information input by the panel switch 104, sampled waveform data, and the like.
[0009]
The waveform capturing unit 107 includes an A / D converter, converts (samples) an analog musical tone signal input from an external waveform (for example, input from a microphone) into digital data, and stores the digital waveform in the RAM 103 or the hard disk 109. Data is taken in as original waveform data (waveform data that is the material of the waveform data to be generated). In the “waveform database creation” process executed by the CPU 101, a “waveform database” according to the present invention is created based on the captured original waveform data. In the “musical tone synthesis based on database” process executed by the CPU 101, waveform data of an arbitrary musical tone signal corresponding to performance information is generated using the “waveform database”. Of course, a plurality of musical sound signals can be generated simultaneously. The waveform data of the generated musical sound signal is given to the waveform output unit 108 via the bus line BL, and stored in a buffer as appropriate. The waveform output unit 108 outputs the waveform data stored in the buffer in accordance with a predetermined output sampling frequency, D / A converts this, and sends it to the sound system 108A. Thus, the musical tone signal output from the waveform output unit 108 is sounded via the sound system 108A. The hard disk 109 stores a plurality of types of performance-related data such as waveform data and data for synthesizing waveforms according to performance styles (data such as performance style tables and codebooks described later), timbre data composed of various timbre parameters, and the like. It stores data, and stores data related to control of various programs executed by the CPU 101.
[0010]
The drive 106 has a plurality of types relating to performance such as waveform data and data for synthesizing waveforms in accordance with performance styles (various data such as performance style tables and codebooks to be described later), timbre data composed of various timbre parameters, etc. And a removable disk (external storage medium 106A) for storing data relating to the control of various programs executed by the CPU 101 and the like. The external storage medium 106A driven by the drive 106 is an abbreviation of a compact disk (CD-ROM / CD-RAM), a magneto-optical disk (MO), or a DVD (Digital Versatile Disk) in addition to a floppy disk (FD). ) And other removable storage media in various forms. The external storage medium 106 </ b> A storing the control program may be set in the drive 106, and the contents (control program) may be directly loaded into the RAM 103 without being dropped on the hard disk 109. Note that the method of providing the control program using the external storage medium 106A or via the network is advantageous because the control program can be easily added or upgraded.
[0011]
The communication interface 111 is connected to a communication network (not shown) such as a LAN, the Internet, or a telephone line, and is connected to a server computer or the like (not shown) via the communication network. The control program, various data, performance information, and the like are taken into the waveform generation device side. That is, when the control program and various data are not stored in the ROM 102 and the hard disk 109, it is used for downloading the control program and various data from the server computer. The waveform generation device as a client transmits a command requesting download of a control program and various data to the server computer via the communication interface 111. Upon receiving this command, the server computer stores the requested control program and data in the hard disk 109 via the communication interface 111, thereby completing the download. Further, of course, a MIDI interface may be included to receive MIDI performance information. Needless to say, a performance keyboard may be connected to the bus line BL and performance information may be supplied by real-time performance. Of course, the performance information may be supplied by using the external storage medium 106A that stores the performance information of a desired music piece.
[0012]
2. Waveform database creation process
2.1. Process overview
FIG. 2 is a flowchart showing an embodiment of “waveform database creation processing” executed in the waveform generation apparatus described above. This process is a process for creating vector data using a waveform of a performance sound played by various performance methods (or articulations) as a material in order to cope with various performance methods (or articulations).
In step S1, a database for storing a performance style table and a code book, which will be described later, is prepared. As a medium serving as this database, for example, a hard disk 109 is used. Then, waveform data according to various performance modes of various natural musical instruments is collected (step S2). That is, various actual performance sounds of various natural instruments are captured from an external waveform input (for example, a microphone or the like) via the waveform capture unit 107, and waveform data (original waveform data) of these performance sounds is stored in the hard disk 109. Store in a predetermined area. The waveform data of the performance sound to be captured at this time may be waveform data of the entire performance, or only a certain phrase, one sound, or only a part of waveform data of a characteristic performance such as an attack part or a release part. Also good.
[0013]
Next, the waveform data of the performance sound according to various performance modes unique to the natural musical instrument obtained in this way are divided into characteristic portions, and are tuned and named (step S3). That is, the captured original waveform data is separated for each part of the waveform (for example, the attack part waveform, the body part waveform, the release part waveform, the joint part waveform, etc.) that represents the change in the waveform shape (1). Then, it is determined what pitch each of the separated waveform data of one period or plural periods is (2) tuning, and a file name is assigned to each separated waveform data (3) File naming. However, when waveform data of a part of performance such as an attack portion or a release portion is taken in, such waveform separation (1) separation can be omitted.
Next, component separation by frequency analysis is performed (step S4). That is, a part of the waveform data separated and generated in step S3 is analyzed by FFT (Fast Fourier Transform) and separated into a plurality of components (in this embodiment, separated into harmonic components and non-harmonic components), and each component ( Performs feature extraction, that is, feature separation for each element of waveform, pitch, and amplitude from harmonic components, non-harmonic components, etc. (However, when separating into harmonic components and non-harmonic components, the non-harmonic components do not have a pitch.) Therefore, it is not necessary to perform pitch separation for non-harmonic components). For example, a “waveform” (Timbre) element is obtained by extracting features only from a waveform shape with normalized pitch and amplitude. The “Pitch” element is a pitch variation characteristic with respect to the reference pitch. The “Amplitude” element is an amplitude envelope characteristic extracted.
[0014]
In step S5, vector data is created. In other words, multiple sample values are continuously distributed as needed for each element of the waveform (Timbre), pitch (Pitch), and amplitude (Amplitude) of each separated component (harmonic component, non-harmonic component, etc.) Are extracted and given different vector IDs (identification information) to the sample value sequences, and stored in the code book together with the data of the time positions of the sample values (hereinafter, such sample data is stored as vector data). Called). In this embodiment, vector data of harmonic component waveform (Timbre) elements, pitch (Pitch) element vector data, amplitude (Amplitude) element vector data, non-harmonic component waveform (Timbre) element vector data, amplitude (Amplitude) element vector data is created. Thus, the vector data for each of these component elements is data that can change as the time axis progresses. Next, the rendition style module data (details will be described later) are created, and the rendition style module is stored in the rendition style table. The rendition style module and vector data created in this way are written in the rendition style table and code book in the database (step S6), and data accumulation in the database is attempted. As described above, the vector data is data obtained by separating the waveform representing the shape of the imported original waveform for each element, not the original waveform data taken as it is. This is the unit of data. In this way, the code book stores a part of the waveform data representing the extracted waveform shape change in a compressed form. On the other hand, in the rendition style table, the rendition style module data (that is, various data necessary to return the vector data stored in the compressed form to the waveform data of the original waveform shape, and the vector stored in the code book) ID data for designating data) is stored (details will be described later).
[0015]
In the above feature separation (see step S4), feature extraction is performed using time as an element in addition to amplitude, pitch, and waveform elements (hereinafter, the extracted time element vector data is referred to as “time vector data”). Call). For this time element, the time length of the original waveform data in the time interval of a part of the waveform data that is separated and generated is used as it is. Therefore, if the original time length (variable value) of the time interval is indicated by the ratio “1,” it is not necessary to analyze and measure this time length at the time of the “waveform database creation process”. In this case, since the data on the time element (that is, “time vector data”) has the same value “1” in any time interval, it may not be stored in the codebook. Of course, the present invention is not limited to this, and it is possible to implement a modification in which the actual time length is analyzed / measured and stored in the code book as “time vector data”.
[0016]
Then, it is determined whether or not the database has been sufficiently created (step S7). That is, whether or not sufficient performance data and vector data of various performance modules have been obtained by sufficiently collecting original waveform data of performance sounds in various performance modes of various natural instruments obtained from external waveform input. judge. This determination is not limited to automatic determination, but may be performed in accordance with an instruction to determine whether or not to continue processing based on a switch input operation by the user. If it is determined that the collection of the original waveform data and the generation of vector data based thereon have been sufficiently performed (YES in step S7), the processing is terminated. Subsequently, when collecting original waveform data and creating vector data based thereon (NO in step S7), the process returns to step S2, and the above-described processes (steps S2 to S7) are repeatedly executed. The determination of “whether or not the vector data has been sufficiently generated” (step S7) may be performed by “trying to generate a musical sound by actually using the generated vector data”. That is, in step S7, once it is determined that “vector data has been sufficiently created” (YES in step S7) and the flow shown in FIG. 2 is exited, “play the musical sound using the created vector data. Then, since it was not satisfactory, the process of step S2 and the subsequent steps may be performed again to add vector data. That is, the process of “creating vector data and adding it to the database” is performed as needed.
In the above-described “waveform database creation process”, rendition style modules may be arbitrarily added or deleted, or rendition style module data may be edited.
[0017]
2.2. Data structure of rendition style module
Here, the data of the rendition style module will be specifically described.
The rendition style modules are stored in a rendition style table formed as a database on the hard disk 109, and one rendition style module can be specified by a combination of "replay style ID" and "replay style parameters". “Performance ID” includes instrument information and module part names. For example, “playing style ID” is defined as follows. For example, if one “playing style ID” is expressed by a 32-bit (0th to 31st bit) string, 6 bits of them are used to express the musical instrument information. For example, if the 6-bit string is “000000”, the instrument information indicates AltoSax (alto sax), and if “001000”, the instrument information indicates Violin (violin). For the instrument information, the upper 3 bit string of the 6-bit string may be used for the major classification of the instrument type, and the lower 3 bit string may be used for the minor classification of the instrument type. Further, the module part name is expressed using another 6 bits of the 32-bit string. For example, if the 6-bit string is “000000”, NormalAttack, if “00000” is BendAttack, if “000010” is GraceNoteAttack, if “001000” is NormalShortBody, if “001001” is VibBody, “001010”. The module part name indicates NormalLongBody if present, NormalRelease if “010000”, NormalJoint if “011000”, and GraceNoteJoint if “011001”. Of course, it is needless to say that the present invention is not limited to the above-described configuration.
[0018]
As described above, each rendition style module is specified by a combination of the above “play style ID” and “replay style parameter”. In other words, a predetermined rendition style module is specified according to the “performance style ID”, and the contents are variably set according to the “performance style parameter”. This “performance style parameter” is a parameter that characterizes or controls the waveform data corresponding to the performance style module, and there is a predetermined type of “performance style parameter” for each performance style module. For example, in the case of the AltoSax [NormalAttack] module, various performance parameters such as the absolute pitch immediately after the attack and the volume immediately after the attack may be given, and in the case of the AltoSax [BendUpAttack] module, the absolute sound at the end of the BendUpAttack Gives performance parameters such as high, initial value of Bend depth at BendUpAttack, time from BendUpAttack start (note on timing) to end, volume immediately after Attack, or time expansion / contraction of default curve during BendUpAttack May be. In the case of the AltoSax [NormalShortBody] module, various performance parameters such as the absolute pitch of the module, the end time-start time of NormalShortBody, the dynamics at the start of NormalShortBody, and the dynamics at the end of NormalShortBody may be given. Note that the rendition style module does not necessarily have data (element data to be described later) corresponding to all values that can be taken by the “replay style parameters”. In some cases, data corresponding to only a part of the values of “playing style parameters” is stored. That is, for example, in the case of the AltoSax [NormalAttack] module, data corresponding to only a part of data may be stored instead of all values of the absolute pitch immediately after the attack and the volume immediately after the attack.
In this way, by allowing the rendition style module to be designated by “replay style ID” and “replay style parameters”, for example, if AltoSax [NormalAttack], a plurality of data (element data to be described later) indicating the normal attack part of the alto sax It is possible to specify data according to the desired rendition style parameter from the inside, and if Violin [BendAttack], according to the desired rendition style parameter from a plurality of data (element data to be described later) indicating the bent attack portion of the violin Data can be specified.
[0019]
2.3. Data structure of rendition style table
In the rendition style table, for each performance style module, data necessary to generate a waveform corresponding to the performance style module, for example, vector data (waveform element, pitch element (pitch envelope), amplitude element (amplitude) for each component element Envelope) etc.) vector ID and representative point value string (data indicating a representative sample point for correction in a plurality of sample strings) or vector data for each component element (waveform element, pitch element) Information such as the start time position and end time position of (pitch envelope) and amplitude element (amplitude envelope) is stored. That is, various data necessary for reproducing a waveform having a normal shape from a waveform stored in the database in a compressed form called vector data is stored (hereinafter, such data is also referred to as “element data”). Call). An example of specific data stored corresponding to one rendition style module in the rendition style table will be described as follows for the case of the AltoSax [NormalAttack] module.
Data 1: Sample length of rendition style module.
Data 2: Note-on timing position.
Data 3: Vector ID and representative point value sequence of amplitude components of harmonic components.
Data 4: Vector ID and representative point value string of the pitch component of harmonic components.
Data 5: Vector ID of the waveform (Timbre) element of the harmonic component.
Data 6: Vector ID and representative point value string of amplitude elements of non-harmonic components.
Data 7: Vector ID of waveform (Timbre) element of non-harmonic component.
Data 8: Start position of the lump of harmonic component waveform (Timbre) element.
Data 9: End position of the lump portion of the harmonic component waveform (Timbre) element (start position of the loop portion of the harmonic component waveform (Timbre) element).
Data 10: Start position of a lump of a waveform (Timbre) element of an out-of-harmonic component.
Data 11: End position of the lump portion of the waveform (Timbre) element of the non-harmonic component (start position of the loop portion of the waveform (Timbre) element of the non-harmonic component).
Data 12: End position of loop portion of waveform (Timbre) element of non-harmonic component.
[0020]
The data 1 to 12 will be described with reference to FIG.
FIG. 3 is a diagram schematically showing an example of each component and element constituting the actual waveform section corresponding to the rendition style module. From the top, the harmonic component amplitude (Amplitude) element and harmonic component pitch ( An example of a Pitch) element, a harmonic component waveform (Timbre) element, an out-of-harmonic component amplitude (Amplitude) element, and an out-of-harmonic component waveform (Timbre) element are shown. The numbers shown in the figure are attached so as to correspond to the numbers of the respective data.
1 is the sample length (waveform section length) of the waveform corresponding to the rendition style module. For example, it corresponds to the entire time length of the original waveform data that is the basis of the rendition style module. 2 is a note-on timing position, which can be variably set at any time position of the rendition style module. In principle, sounding of the performance sound according to the waveform starts from the position of the note-on timing, but depending on the playing method such as bend attack, the rise start time of the waveform component may precede the note-on timing. is there.
[0021]
Reference numeral 3 denotes a vector ID and a representative point value sequence for indicating vector data of the amplitude element of the harmonic component stored in the code book (in the figure, two points indicated by black squares indicate representative points) ). Reference numeral 4 denotes a vector ID and a representative point value string for indicating vector data of a pitch element of the harmonic component. 6 shows a vector ID and a representative point value string for indicating vector data of an amplitude element of an out-of-harmonic component. The representative point value sequence data is data for changing and controlling vector data (consisting of a plurality of sample sequences) indicated by the vector ID, and indicates (specifies) some representative sample points. By changing or correcting the time position (horizontal axis) and level axis (vertical axis) for the identified representative sample point, other remaining sample points are also changed in conjunction with each other, thereby changing the vector shape. . For example, it is data indicating a smaller number of distributed samples than the number of samples. However, the present invention is not limited to this, and the representative point value sequence data may be data at an intermediate position between samples, or a predetermined value. May be data over a range (sequential multiple samples). Further, not the sample value itself but data such as a difference and a multiplier may be used. By moving the representative point along the horizontal axis and / or the vertical axis (time axis), the shape of each vector data can be changed. That is, the shape of the envelope waveform can be changed.
[0022]
Reference numeral 5 denotes a vector ID for indicating vector data of a harmonic component waveform (Timbre) element. Reference numeral 7 denotes a vector ID for indicating vector data of a waveform (Timbre) element of an out-of-harmonic component. Reference numeral 8 denotes the start position of the waveform block of the harmonic component waveform (Timbre) element. 9 is the end position of the waveform block of the harmonic component waveform (Timbre) element (or the start position of the loop portion of the waveform of the harmonic component waveform (Timbre) element). That is, a triangle starting from 8 indicates a non-loop waveform portion in which characteristic waveform shapes are continuously stored, and a subsequent rectangle starting from 9 indicates a loop waveform portion that can be repeatedly read. The non-loop waveform is a high-quality waveform having characteristics such as performance style (or articulation). The loop waveform is a unit waveform of a relatively monotonous sound portion composed of a waveform for one period or a plurality of suitable periods. Reference numeral 10 denotes the start position of the waveform block of the waveform (Timbre) element of the non-harmonic component. 11 is the end position of the waveform block of the waveform (Timbre) element of the non-harmonic component (or the start position of the loop portion of the waveform of the waveform (Timbre) element of the non-harmonic component). Reference numeral 12 denotes the end position of the loop portion of the waveform of the non-harmonic component waveform (Timbre) element. The data 3 to data 7 are identification information data for indicating the vector data stored in the code book for each component element, and the data 2 and data 8 to data 12 are the original (before separation) from the vector data. (B) Time information data for assembling the waveform.
[0023]
In this way, the rendition style module data is composed of data for indicating vector data and time information data. By using the rendition style module data stored in such a rendition style table, the waveform can be freely assembled using the waveform material (vector data) stored in the codebook. That is, the rendition style module is data representing the behavior of the waveform generated according to the rendition style (or articulation). The type and number of performance style module data may be different for each performance style module. In addition to the data described above, other information may be provided. For example, it may have data for expanding / compressing the time axis of the waveform.
[0024]
In the above example, in order to make the explanation easy to understand, one rendition style module has all the elements of the harmonic component (waveform, pitch, amplitude) and each element of the non-harmonic component (waveform, amplitude). However, the present invention is not limited to this, and the rendition style module may consist of one of the harmonic components (waveform, pitch, amplitude) or one of the nonharmonic components (waveform, amplitude). Of course. For example, if the rendition style module is a harmonic component waveform (Timbre) element, harmonic component pitch (Pitch) element, harmonic component amplitude (Amplitude) element, non-harmonic component waveform (Timbre) element, non-harmonic component amplitude (Amplitude) It may consist of any one element. In this case, it is preferable that the rendition style modules can be freely combined and used for each component.
[0025]
In this way, instead of having the waveform data of the performance sound in various performance modes of various natural instruments as a whole waveform data, some of the waveforms necessary for changing the waveform shape (for example, attack part waveform, body part waveform) , Release part waveform, joint part waveform, etc.), and waveform data is stored in the hard disk 109 in a compressed form using a hierarchical compression method such as component, element, representative point, and so on. The storage capacity of the hard disk 109 necessary for storing data can be reduced.
[0026]
3. Waveform synthesis processing
In the waveform generation apparatus shown in FIG. 1, the synthesis of the waveform is performed by the computer executing a predetermined program (software) that realizes the waveform synthesis process according to the present invention. FIG. 4 shows an embodiment of a flowchart of a predetermined program (“musical tone synthesis process based on a database”) for realizing the waveform synthesis process.
However, in this embodiment, since various functions realized by the program are independent of each other, the operation will be described based on the functional block diagram shown in FIG. Further, the present invention is not limited to this type of program, and the waveform synthesis processing may be performed in the form of a dedicated hardware device. In this case, FIG. 5 is a block diagram in the case where the same waveform synthesizing process as in FIG. 4 is configured in the form of a dedicated hardware device. Therefore, the following description will be mainly given according to FIG. 5, and the corresponding steps in FIG. 4 are shown in parentheses.
[0027]
3.1. Song data playback unit 101A
The music data playback unit 101A performs playback processing of music data with performance style symbols (step S11). First, the music data reproducing unit 101A receives music data with performance style symbols (performance information). Normal music scores are accompanied by musical symbols such as dynamic symbols (such as crescendo and decrescendo), tempo symbols (such as Allegro and ritardando), slur symbols, tenuto symbols, and accent symbols that cannot be converted to MIDI data as they are. . Therefore, these symbols are converted into “playing style symbols” and MIDI music data including the “playing style symbols” is “musical data with performance style symbols”. The “playing style symbol” is composed of a chart ID and a chart parameter. The chart ID is an ID indicating a music symbol described in the score, and the chart parameter is a parameter indicating the degree of content of the music symbol indicated by the chart ID. For example, when the chart ID indicates “vibrato”, the speed and depth of the vibrato are given as chart parameters, and when the chart ID indicates “crescendo”, the volume at the start of the crescendo, the end of the crescendo A volume, a length of time during which the volume changes, and the like are given as chart parameters.
[0028]
3.2. Score interpretation unit 101B
The score interpretation unit (player) 101B performs score interpretation processing (step S12). Specifically, the MIDI data included in the song data and the above-mentioned “performance style symbol” (chart ID and chart parameter) are converted into performance style designation information (performance style ID and performance style parameter), and a performance style synthesis unit (articulator) along with time information. ) Output to 101C. In general, even with the same musical symbols, the interpretation of the symbols differs depending on the performer, and the performance may be performed by a different performance method (ie, performance method or articulation) for each performer. Alternatively, the performance may be performed by a different performance method for each performer depending on how the notes are arranged. Therefore, the score interpretation unit 101B is an expert system that has knowledge of interpreting such symbols on a score (music symbols, how to arrange musical notes, etc.).
[0029]
An example of a standard for interpreting symbols on a score in the score interpretation unit 101B is as follows. For example, vibrato can only be applied if it is 8 or more notes. Staccato naturally increases dynamics. The attenuation rate of the note is determined by the tenuto degree. Legato does not decay in one sound. The speed of the eighth note vibrato is almost determined by the note value. The dynamics vary depending on the pitch. Furthermore, dynamics change due to pitch rise or fall within one phrase, attenuation dynamics is db linear, note length change according to tenuto, staccato, etc., bend-up according to attack bend up symbol There are various interpretation criteria such as width and curve. The score interpretation unit 101B converts the score into performance data by performing interpretation on the score according to such a standard. Further, the score interpretation unit 101B performs the above-described score interpretation processing in accordance with the player designation from the user, that is, according to the designation of who is performing (the playing style) by the user. The score interpretation unit 101B interprets the score by changing the score interpretation method according to the player designation. For example, different score interpretation methods corresponding to the plurality of players are stored in the database, and the score interpretation unit 101B interprets the score by selectively changing the score interpretation method according to the player designation from the user.
[0030]
Note that the song data (performance information) may be configured to include data indicating the score interpretation result in advance. Needless to say, when such music data including data obtained as a result of previously interpreting the score is input, it is not necessary to perform the above-described processing. Further, the score interpretation processing in the score interpretation unit 101B (step S12) may be performed fully automatically, or may be performed by appropriately interposing a human input operation by the user.
[0031]
Here, the contents of the performance data created in the score interpretation unit 101B will be described with reference to FIG.
The performance data is composed of a header and a plurality of tracks in the same manner as normal SMF (standard MIDI format). Each track includes program change and event data (note-on, note-off, etc.). In this embodiment, a module designating unit for designating the attack unit, body unit, joint unit, and release unit module. (Playing style designation information including playing style ID and performance style parameters) is included. These module designation units use actually undefined system exclusive messages, meta events, 14-bit control changes, and the like. Further, each track includes time difference data for designating a time difference between the event data or the module designation unit.
[0032]
Here, if a program change that designates a timbre for each track, that is, a program change that designates a new database (performance table + chord book) is included, the score interpretation unit 101B uses the program change as predicted data to generate a waveform. This is supplied to the synthesis unit 101D. This is because the waveform synthesizer 101D predicts vector data to be used next and reads it from the code book, and therefore specifies a program change in order to narrow down the prediction range to some extent (details will be described later). The prediction data includes other various data. Based on the music data, the score interpretation unit 101B supplies “data indicating subsequent performance specification” to the waveform synthesis unit 101D as prediction data. The program change is included as one of the prediction data.
[0033]
3.3. Performance style synthesis unit 101C
The rendition style composition unit (articulator) 101C refers to the rendition style table based on the rendition style designation (performation style ID + rendition style parameters) converted by the score interpretation unit (player) 101B, and a packet corresponding to the rendition style designation (rendition style ID + replay style parameters) Vector parameters relating to the stream (or vector stream) and rendition style parameters corresponding to the stream are generated and supplied to the waveform synthesis unit 101D (step S13). The data supplied to the waveform synthesizer 101D as a packet stream is packet time information, vector ID, representative point value sequence, etc. with respect to the pitch (Pitch) element and amplitude (Amplitude) element, and with respect to the waveform (Timbre) element. Vector ID, time information, etc. (details will be described later).
[0034]
Next, the waveform synthesis unit 101D extracts vector data from the codebook according to the packet stream, deforms the vector data according to the vector parameter, and synthesizes a waveform based on the deformed vector data (step S14). Then, a waveform generation process for other parts is performed (step S15). Here, the other part is a performance part to which a normal musical sound waveform synthesis process is applied that does not perform a performance style synthesis process among a plurality of performance parts. For example, these other parts generate musical sounds using a normal waveform memory tone generator method. This “other-part waveform generation process” may be performed by a dedicated hardware sound source (an external sound source unit or a sound source card that can be attached to a computer). In order to simplify the explanation, in this embodiment, it is assumed that the tone generation according to the performance style (or articulation) is performed for only one part. Of course, it is also possible to reproduce the performance in multiple parts.
[0035]
FIG. 6 is a block diagram for explaining the flow of rendition style synthesis processing in the rendition style synthesis unit 101C described above. Although FIG. 6 shows that the rendition style module and the code book are stored separately, actually both are stored in the database of the hard disk 109.
The rendition style synthesis unit 101C creates various packet streams to be supplied to the waveform synthesis unit 101D based on the rendition style designation (rendition style ID + rendition style parameters) and time information data from the score interpretation unit 101B. The rendition style module used for each tone color in the rendition style synthesis unit 101C is not fixed, and the user newly adds a rendition style module to the rendition style module in use or a part of the rendition style modules in use. You can stop using it. In the rendition style synthesis unit 101C, a process for creating correction information for correcting a deviation between the selected element data and the rendition style parameter value, and a connection for smoothly connecting the waveform characteristics of the previous and next rendition style modules Processing such as smoothing is also performed (details will be described later).
Note that data is normally provided from the score interpretation unit 101B to the performance style synthesis unit 101C, but the present invention is not limited to this, and as described above, performance-designated song data or human beings already interpreted by the score interpretation unit 101B It is also possible to prepare music data with performance style designation to which performance style IDs and performance style parameters are given by interpreting the musical score, and supplying the reproduced data to the performance style synthesis unit 101C.
[0036]
FIG. 7 is a flowchart showing in detail an embodiment of the rendition style synthesis process.
The rendition style synthesis unit 101C selects a rendition style module from the rendition style table according to the rendition style ID and the rendition style parameters (step S21). That is, one performance style module is selected according to the performance style ID (instrument information + module part name) and performance style parameters transmitted from the score interpretation unit 101B. At this time, before interpreting the score, the score interpretation unit 101B checks the database in advance to check what module parts exist in the rendition style table corresponding to the timbre indicated by the musical instrument information. Designation method ID is specified in the range of parts. When a non-existing part is designated, a performance style ID having similar characteristics may be selected instead. Next, a plurality of element data are selected according to the designated performance style ID and performance style parameters (step S22). That is, a rendition style module is identified by referring to the rendition style table by the designated rendition style ID and rendition style parameters, and a plurality of element data corresponding to the rendition style parameters are selected from the module. At this time, if there is no element data that completely matches the rendition style parameter in the rendition style module, element data corresponding to the rendition style parameter close to that value is selected.
[0037]
Next, the time of each position in the element data is calculated according to the time information (step S23). That is, each element data is arranged at an absolute time position based on the time information. Specifically, based on the time information, the corresponding absolute time is calculated from the element data indicating each relative time position. Thus, the timing of each element data is determined (see FIG. 3). And the value of each element data is correct | amended according to a rendition style parameter (step S24). In other words, the deviation between the selected element data and the rendition style parameter value is corrected. For example, the volume (performance parameter) immediately after the attack of the AltoSax [NormalAttack] module transmitted from the score interpretation unit 101B is “95”, and the volume immediately after the attack of the AltoSax [NormalAttack] module in the performance table is “100”. , The rendition style synthesis unit 101C selects element data of the AltoSax [NormalAttack] module whose volume immediately after the attack is “100”. However, since the volume immediately after the attack remains “100” as it is, the volume immediately after the attack is corrected to “95” by correcting the representative point of the selected element data. In this way, correction is performed so that the value of the selected element data is close to the value of the transmitted performance parameter. Further, correction according to the set value of the micro tuning (tuning of the instrument), correction of the volume according to the volume change characteristic of the instrument, and the like are also performed. These corrections are performed by changing the representative point value of each element data, and the representative point value may change greatly. That is, data necessary and sufficient for correction is a representative point, and various corrections are performed by controlling the representative point.
[0038]
In step S23, the time position indicated by the time information may be corrected using correction information such as the performance parameter. For example, when the time position obtained based on the performance data does not match the time position indicated by the time information, the time information indicating the time position close to the time position obtained based on the performance data is selected and acquired there. By correcting the time position information in accordance with the performance data, the time position information intended by the performance data can be obtained. When the performance data includes a variable control factor such as touch or velocity, the time position information can be variably controlled according to the performance data by correcting the time position information according to the variable control factor. it can. The correction information includes information for performing such time position correction.
[0039]
Further, link processing is performed to adjust each element data and smooth the connection portion between adjacent performance style modules (step S25). That is, by connecting the representative points of the connecting portions in the front and rear performance style modules close to each other, the waveform characteristics of the front and rear performance style modules are made smooth. Such connection or link processing is performed for each element such as the waveform (Timbre), amplitude (Amplitude), and pitch (Pitch) of the harmonic component, or for each element of the waveform (Timbre) and amplitude (Amplitude) of the non-harmonic component. Each is done separately.
[0040]
At this time, the adjustment is performed in the range from the “link start point” of the previous performance style module to the “link end point” of the subsequent performance style module. That is, the representative points within the range of “link start point” to “link end point” are adjusted based on “rate from walking”. This “rate from step” is a parameter for controlling how far the connection is made from the previous performance module and the subsequent performance module, and is determined according to the combination of the previous and next performance modules as will be described later. . Also, if the waveform connection is not successful when the front and back performance style modules are connected, the connection is smoothed by thinning out the vector IDs of the waveform characteristics in either of the front and rear performance style modules. In order to realize this decimation, a “performance method module combination table”, a “decimation execution parameter range table” to be referred to from now on, and a “thinning time table” to be referred to from now on are prepared.
[0041]
In addition, the waveform characteristics can be smoothly connected by the link processing in the score interpretation unit 101B as described below. For example, discontinuous portions of performance style parameters (dynamics values, pitch parameter values, etc.) are smoothly connected regardless of the performance style module. Alternatively, when moving from vibrato to release, the vibrato is reduced early, thereby connecting smoothly.
[0042]
Here, the above-described link processing will be described in detail. That is, the adjustment of each element data for smoothing the connection part of the front and rear rendition style modules (see step S25) will be briefly described. First, a link process when the rendition style module corresponds to an amplitude element or a pitch element will be described with reference to FIG.
[0043]
If there is a step at the connection point between the two points due to the discontinuity of the representative point value at the connection between the previous performance module and the subsequent performance module, first the dynamics connection point (in the case of Amplitude) or the pitch connection point (Pitch) In the case of (1), an index “Rate from step” is determined as an index indicating whether the target value is closer to the value on the side of the rendition style module. In this embodiment, it is assumed that “rate from walking” is given by a table as illustrated. For example, when the vector ID of the previous rendition style module is “3” and the vector ID of the subsequent rendition style module is “7”, the “rate from step” is determined as “30” from the table. The envelope shape is gradually deformed toward the target value from the “link start point” of the previous rendition style module to the “end point of the rendition style module” according to the “rate from the step” thus determined. Further, the envelope shape is gradually deformed toward the target value from the “link end point” of the later performance style module to the “performance style module start point”. For example, when the “rate from the step” is determined to be “30”, the target value for the previous rendition style module is “30”, and the previous rendition style module performs the “30”% step toward the subsequent rendition style module ( In the present embodiment, the last representative point in the previous rendition style module is a step of “30”% downward).
[0044]
On the other hand, the subsequent rendition style module performs “70” (100-30)% steps toward the previous rendition style module side (in this embodiment, the first representative point in the later rendition style module is higher than “70”% steps). To do). In addition, the plurality of representative points of the performance module before and after the link start point to the link end point perform the respective steps up and down along with the above steps. In this way, it is performed at a plurality of representative points of the rendition style module that goes back and forth rather than walking. The link start point and link end point may be determined as appropriate, but if the link start point and link end point are set to the same point as the desired representative point, the link start point and link end point as shown in the figure It is desirable because there is no bending of the envelope shape. Of course, even if the link start point and link end point are not set to the same point as the desired representative point, it goes without saying that the step may be performed so that the envelope shape is not bent.
[0045]
The determination of “rate from step” is not limited to the above-described example. For example, it may be determined based on performance style parameters specified before and after the connection point. Or you may determine based on the performance data before becoming performance style ID or a performance style parameter. Or you may determine based on the combination of those data. In the above example, there is only one representative point to be walked based on the “step rate”, and the other representative points are walked by an appropriate amount along with the walk. It is also possible to separately determine the “rate from walking” and to move the representative points according to the “rate from walking” accordingly.
[0046]
Next, the link processing when the rendition style module is a waveform (Timbre) element will be described. 9 to 12 are conceptual diagrams for explaining the link processing when the rendition style module is a waveform (Timbre) element. FIG. 9 is a conceptual diagram for explaining waveform thinning when the attack part waveform and the body part waveform are connected, and FIG. 10 explains the waveform thinning when the body part waveform and the release part waveform are connected. It is a conceptual diagram for doing. In FIG. 9, it is assumed that the body part waveform is composed of five loop waveforms L1 to L5, and loop reproduction is performed in a predetermined time range. Similarly, it is assumed that the body part waveform of FIG. 10 includes six loop waveforms L1 ′ to L6 ′.
[0047]
There are various methods for adjusting the element data related to the waveform (that is, the waveform linking process). For example, the connection between the performance module of the attack part or joint part and the performance module of the body part (or the body part We propose a method for smooth connection by partial thinning of the waveform in the rendition style module and the rendition style module of the release part or joint part). It is well known to perform cross-fade synthesis when connecting waveforms. However, when the time t from the connection point to the start position of the first loop waveform L1 is short as in the example of FIG. 9, it is necessary to perform a rapid crossfade synthesis within the short time t. When such cross-fade waveform synthesis, that is, when the time between connected waveforms is very close, if cross-fade waveform synthesis is performed between the waveforms, large noise is generated accordingly. A waveform is generated, which is not preferable.
[0048]
Therefore, a part of the waveform is thinned out (deleted) so as to widen the time interval between the connected waveform and the waveform, thereby preventing the sudden crossfade waveform synthesis. In this case, the waveform in the attack part, the release part or the joint part is one lump, and the waveform cannot be thinned out. In this case, the loop waveform on the body part side is thinned out. In FIG. 9 and FIG. 10, the loop waveforms L1 and L6 ′ indicated by the solid black rectangles are thinned out. For example, in FIG. 9, the second loop waveform L2 having a relatively long time difference from the connection point and the tail waveform of the attack portion waveform are cross-fade synthesized, and the first loop waveform L1 is not used. Similarly, in FIG. 10, the crossfade synthesis is performed between the loop waveform L5 ′ and the release portion waveform, and the waveform L6 ′ is not used.
In addition, a joint part is a waveform area which connects between sound (or between a sound part and a sound part) by arbitrary performance methods.
[0049]
Also, the connection between the attack style playing module and the release section or joint style playing module is smoothed by waveform thinning. FIG. 11 and FIG. 12 are conceptual diagrams for explaining waveform thinning when an attack part waveform and a release part waveform are connected.
In this case, there may be a case where a rendition style module such as an attack part or a release part can be thinned out and a case where it cannot. An example of an attack module that can perform waveform thinning is a bend attack section (having several loop waveforms in the latter half). Also, waveform thinning can be performed in the case of a release portion having several loop waveforms in the first half. In this way, waveform reciprocation is performed on the performance style module on the side where waveform thinning is possible. For example, when connecting the bent attack portion and the release portion, the loop waveform on the bent attack portion side is thinned as shown in FIG. 11 (in FIG. 11, the loop indicated by the black-painted rectangle on the bent attack portion side). Decimate one waveform). When the normal attack portion and the release portion having the loop waveform are connected, the loop waveform on the release portion side is thinned as shown in FIG. 12 (in FIG. 12, the release portion side is indicated by a black-filled rectangle). Decimate one loop waveform).
The loop waveform to be thinned out is not limited to the loop waveform closest to the connection portion between the rendition style module and the rendition style module (the loop waveform positioned at the beginning or end), but is thinned out from a plurality of loop waveforms according to a predetermined priority order. You may make it identify the loop waveform made into object.
[0050]
In this way, in the combination of a certain rendition style module, the waveform is thinned out when the connection is not successful within a certain rendition style parameter range. In order to realize this, for example, a “rendition style module combination table” is referred to from now on. A “thinning execution parameter range table” and a “thinning time table” to be referred to from now on are prepared. The “performance style module combination table” is a table for determining a predetermined parameter according to a combination of performance style modules before and after connection. The “thinning execution parameter range table” is a table for determining a time range for performing the thinning for each parameter. The “thinning time table” is a table for determining the thinning time. When the time difference (time t shown in FIGS. 9 to 12) between the connection time point and the first (or last) loop waveform L1 (or L6 ′) is shorter than the reference thinning time, the loop waveform is thinned.
[0051]
Further, the waveform connection when the sample length of the performance style module is short and ends before the performance style module following the performance style module is started will be described with reference to FIG. However, in FIG. 13, the waveforms (with four performance modules A.Sax [BendUpAttack], A.Sax [NormalShortBody], A.Sax [VibratoBody], and A.Sax [NormalRelease] are shown in time series from left to right in the figure. A case where a packet stream of (Timbre) element is formed will be described. The sample length (section length) of each rendition style module is represented by the length indicated by “length”. In FIG. 13, “Note On” and “Note Off” described at the top are MIDI data event timings. Further, A.Sax [BendUpAttack] and the like described in the middle are the timings of performance style IDs, and notes, dynamics, depth, and the like indicate the timings of performance style parameters, respectively.
[0052]
The A.Sax [BendUpAttack] module starts at time t0. The time t1 is the note-on timing in the module, and matches the instructed note-on timing. The content of the packet stream of the module is controlled based on performance parameters such as note, dynamics, and depth. The A.Sax [NormalShortBody] module starts at time t2 immediately after the attack module. Time t3 is the timing at which the vibrato performance is started in the middle of the connecting portion. This timing is determined based on, for example, the start timing of the vibrato symbol assigned to the song data. Time t5 is a note-off timing in the A.Sax [NormalRelease] module, and is matched with the instructed note-off timing. The start time t4 of the A.Sax [NormalRelease] module is specified accordingly.
[0053]
That is, since note-on is performed at time t1 and note-off is performed at time t5, the time actually generated according to the waveform generated from the packet stream is the time from time t1 to time t5. In such a packet stream, the time length from time t2 to time t4 and the sum of the sample lengths length of the A.Sax [NormalRelease] module and A.Sax [VibratoBody] module during that time often do not match. Need to be dealt with appropriately. In such a case, by repeating the same rendition style module, the sum of the sample lengths length is adjusted to the time length, the sample length of the rendition style module is changed to match the time length, or the both are used in combination. Adjust the length of time. In this way, the waveform connection is adjusted between the modules. In the above example, the A.Sax [NormalShortBody] module is repeated to connect the waveform to the subsequent A.Sax [VibratoBody] module. Similarly, by repeating the A.Sax [VibratoBody] module, the waveform connection with the subsequent A.Sax [NormalRelease] module is performed.
[0054]
As described above, when the rendition style module is repeatedly connected a plurality of times, the time length of the repetitive style performance module is varied. In this example, the variable control of the time length is performed by moving the representative point in the A.Sax [NormalShortBody] module or the A.Sax [VibratoBody] module. That is, it is realized by an appropriate method such as changing the time of crossfade connection between a plurality of loop waveforms constituting the A.Sax [NormalShortBody] module or the A.Sax [VibratoBody] module. In the case of a loop waveform, the time length of the entire loop reproduction waveform can be variably controlled by changing the number of loops or the loop duration time relatively easily. On the other hand, in the case of a non-loop waveform, it is not so easy to variably control the existence length on the time axis. Therefore, as described above, in a series of sound waveforms composed of a non-loop waveform and a loop waveform, the overall sound generation time length is variably controlled by performing variable control of the time axis of the waveform data in the loop reading section. It is extremely preferable to facilitate time expansion and contraction control. For this purpose, the “Time Stretch & Compress” control (“TSC control” for short) previously proposed by the present applicant in Japanese Patent Laid-Open No. 10-307586 may be used. In particular, the above-described “TSC control” can be preferably applied to vary the length of the time axis in a non-loop waveform corresponding to a special performance style.
[0055]
An example of the packet stream created in this way is conceptually shown in FIG. FIG. 14 shows the packet streams in the harmonic component amplitude (Amplitude) element, pitch (Pitch) element, waveform (Timbre) element, non-harmonic component amplitude (Amplitude) element, and waveform (Timbre) element in order from the top. Also, in the harmonic component amplitude element, the pitch element, and the non-harmonic component amplitude element, the black squares are representative points, and the curve connecting them is the packet in the packet stream. The shape of the vector shown by the contained vector ID is shown. In the waveform (Timbre) element of the harmonic component and the waveform (Timbre) element of the non-harmonic component, the white rectangle L indicates a loop waveform, and the other rectangles NL indicate non-loop waveforms. Of the non-loop waveforms, those with diagonal lines indicate particularly characteristic non-loop waveforms. Furthermore, in this embodiment, the waveform (Timbre) elements of the harmonic component and the non-harmonic component in the NormalAttack module are each composed of two vectors, and the amplitude component, the pitch element, and the non-harmonic component of the harmonic component Each of the Amplitude elements is composed of one vector.
[0056]
In the present embodiment, both the harmonic component and the non-harmonic component are such that the amplitude element and the pitch element do not have a vector in a portion where the waveform (Timbre) element is a non-loop waveform. . However, even when the waveform (Timbre) element is a non-loop waveform, the generated waveform may be controlled by having a vector of an amplitude (Amplitude) element and a pitch (Pitch) element. In the VibratoBody module, the harmonic component waveform (Timbre) element is composed of five vectors, the harmonic component amplitude (Amplitude) element and pitch (Pitch) element, and the non-harmonic component waveform (Timbre) element and amplitude (Amplitude). Each element is composed of one vector. Note that the VibratoBody module is repeated three times, but each vector has a different shape for each iteration. This is because different performance parameters are specified for each repetition. Different element data is selected according to different rendition style parameters, or different level control and time axis control are performed according to different rendition style parameters. In the NormalJoint module, the harmonic component and non-harmonic component waveform (Timbre) elements are each composed of three vectors, the harmonic component amplitude (Amplitude) element, the pitch (Pitch) element, and the non-harmonic component amplitude (Amplitude) element. Are each composed of two vectors. The description of the NormalBody module is omitted.
[0057]
As described above, the rendition style synthesis unit 101C generates a packet stream for each component (harmonic component and non-harmonic component). These packet streams are composed of a plurality of packets, and each packet includes a vector ID and packet time information. In addition, in the case of an amplitude element, a pitch element, and an amplitude element of an out-of-harmonic component, a definite value of each representative point is included. Of course, the present invention is not limited to this, and other information may be included in addition to the vector ID and the packet time information. A packet stream is configured for each component in accordance with the contents of each such packet. Thus, the packet stream includes a plurality of packets and time information (start time) of each packet.
Needless to say, the number of packet streams may differ depending on the type of musical instrument.
[0058]
3.4. Waveform synthesis unit 101D
3.4.1. General operation of waveform synthesizer 101D
The waveform synthesis unit 101D synthesizes a waveform based on the packet stream (a plurality of packet strings including vector ID, time information, correction information, etc.) for each component supplied from the rendition style synthesis unit 101C. FIG. 15 is a conceptual diagram showing the overall configuration for explaining the operation in the waveform synthesis unit 101D. 16 to 19, 22, and 23 are drawings for explaining each operation in the waveform synthesis unit 101 </ b> D in detail. FIG. 16 is a block diagram simply showing the overall flow of waveform synthesis. FIG. 17 is a block diagram for explaining the vector loader. FIG. 18 is a block diagram for explaining a vector operator. FIG. 19 is a block diagram for explaining the vector decoder. FIG. 22 is a diagram showing the timing at which each packet is supplied from the rendition style synthesis unit 101C to the waveform synthesis unit 101D, and FIG. 23 is a block diagram for explaining the cache control unit 40.
[0059]
In FIG. 15, the packet stream for each component element created by the rendition style synthesis unit (articulator) 101C is sequentially applied to predetermined packet queue buffers 21 to 25 provided corresponding to each component element in the waveform synthesis unit 101D. Packet input (that is, input in units of packets). The input packets are accumulated in the packet queue buffers 21 to 25 and sequentially sent to the vector loader 20 in a predetermined order. The vector loader 20 reads (loads) original vector data corresponding to the vector ID from the code book 26 via the cache control unit 40 with reference to the vector ID in the packet. The read vector data is sent to predetermined vector decoders 31 to 35 provided corresponding to each component element, and the vector decoders 31 to 35 generate waveforms for each component element.
[0060]
Further, the vector decoders 31 to 35 generate waveforms for each component (harmonic component and out-of-harmonic component) while synchronizing the generated waveform for each component element between the vector decoders 31 to 35. The waveform for each component generated in this way is sent to the mixer 38. In the rendition style synthesis unit (articulator) 101C, packets are input to the packet queue buffers 21 to 25, stream management (management of generation and deletion of individual vector data or connection between vector data) and playback control (desired) The waveform synthesizer 101D is subjected to various controls such as execution of waveform generation or control of reproduction / stop of the desired waveform generated).
[0061]
As described above, the packet constituting the packet stream stored in the packet queue buffer 21 is sequentially input to the vector loader 20, and the vector loader 20 passes the cache control unit 40 based on the vector ID in each packet. Then, the vector data corresponding to the vector ID is read from the code book 26, and the read vector data is sent to the vector decoder 31 (see FIG. 16). At this time, correction information (for example, correction information related to representative points) may be attached to each read packet. In such a case, the vector loader 20 modifies the read original vector data in accordance with the correction information, and a packet having information of the deformed vector data (referred to as vector information data in order to distinguish it from the original vector data) ( This is called a vector packet in order to distinguish it from the packet input from the rendition style synthesis unit 101C), and is output to the vector decoders 31-35. As described above, the vector loader 20 reads the original vector data from the code book 26 based on the vector ID of the packet input from the rendition style synthesis unit (articulator) 101C, and corrects the vector data with correction information as necessary. After that, the vector packet is transferred to the vector decoders 31 to 35 (see FIG. 17). The correction information related to the representative points of the vector data as described above may include various correction information such as correction information for shifting time information based on random numbers.
[0062]
As shown in FIG. 18, the vector decoders 31 to 35 generate and discard vector operators for processing input vector packets, connect / synchronize management between vector operators, time management, and input from other vector ID streams. Various types of operator operation management such as parameter conversion settings for each vector operator are performed. The vector operators 36 and 37 perform reading of vector information data, vector information data reading position control (Speed input), gain control (Gain input), and the like. Various parameters set in the vector operators 36 and 37 are managed by vector decoders 31-35. Vector decoders 31 to 35 are provided so as to correspond to each component element, and the vector decoders 31 to 35 read out vector information data in the vector packet and generate a desired waveform in time series.
[0063]
For example, as shown in FIG. 19, the vector decoder 31 generates an envelope waveform of the harmonic component Amplitude element, the vector decoder 32 generates the envelope waveform of the harmonic component Pitch element, and the vector decoder 33 Generates a waveform of the harmonic component waveform (Timbre) element, the vector decoder 34 generates an envelope waveform of the amplitude component (Amplitude) of the non-harmonic component, and the vector decoder 35 generates an envelope of the waveform component (Timbre) of the non-harmonic component. Generate a waveform. The vector decoder 33 generates a harmonic component waveform to which the envelope waveform of the harmonic component Amplitude element generated by the vector decoders 31 and 32 and the envelope waveform of the harmonic component pitch element are added, and the mixer 38. Output to. That is, for the vector decoder 33, the envelope waveform of the harmonic component pitch element is used as vector information data as a vector operator for performing gain control (Gain input) on the envelope waveform of the harmonic component Amplitude element. Is input as a vector operator for performing the reading position control (Speed input). Further, the vector decoder 35 generates an out-of-harmonic component waveform to which the envelope waveform of the amplitude component of the out-of-harmonic component generated by the vector decoder 34 is added, and outputs the generated waveform to the mixer 38. That is, the envelope waveform of the amplitude component of the out-of-harmonic component is input to the vector decoder 35 as a control command for performing gain control (Gain input).
[0064]
Furthermore, when generating waveforms in time and in the components and elements, waveform generation is performed while synchronizing the waveforms between the vector decoders 31-35. For example, when a vector packet of a waveform (Timbre) element and a vector packet of an amplitude (Amplitude) element are input, the amplitude (Amplitude) is synchronized with the waveform generation time based on the vector packet of the waveform (Timbre) element as a reference. ) Generate an amplitude waveform based on the vector packet of elements. The amplitude of the waveform generated based on the vector packet of the waveform (Timbre) element is controlled by the amplitude waveform. When a vector packet of a waveform (Timbre) element and a vector packet of a pitch (Pitch) element are input, the time of waveform generation based on the vector packet of the waveform (Timbre) element is used as a reference, and the pitch (Pitch) element A pitch waveform based on a vector packet is synthesized.
[0065]
The pitch of the waveform generated based on the vector packet of the waveform (Timbre) element is controlled by the pitch waveform. When inputting the harmonic component waveform (Timbre) element vector packet and the non-harmonic component waveform (Timbre) element vector packet, based on the harmonic component synthesis time based on the harmonic component waveform (Timbre) element vector packet In synchronization therewith, the out-of-harmonic component based on the vector packet of the waveform (Timbre) element of the out-of-harmonic component is synthesized. A desired musical sound waveform is generated by mixing the synthesized harmonic and non-harmonic waveforms.
In this embodiment, the harmonic component and the non-harmonic component can be selected to be synchronous or asynchronous, and based on the above-described vector packet of the harmonic component waveform (Timbre) element only when synchronization is selected. The waveform of the non-harmonic component generated based on the vector packet of the waveform (Timbre) element of the non-harmonic component may be synthesized in synchronism with the waveform synthesis time of the harmonic component generated .
[0066]
As described above, the packet stream is composed of a plurality of packet sequences. In the case of a vector bucket packet stream, each packet includes vector data. That is, a packet stream is a sequence of vector data arranged in the time direction. The vector structure of the amplitude (Amplitude) element, the vector data of the pitch (Pitch) element, the vector data of the waveform (Timbre) element has the data structure and meaning. Although different, it is basically the same when viewed from the vector operators 36 and 37.
[0067]
3.4.2. Vector data structure
FIG. 20 is a conceptual diagram conceptually showing an embodiment of the data structure of vector data. For example, when the unit of the reading position of the vector data is [SEC] and the reading speed is constant, one sample on the vector data coincides with one sample of the output waveform. The unit of the reading speed is 1/1200 [cent] (= 2 to the power of n). When the index n is 0, it is constant speed, and when it is 1.0, it is double (for example, 1 octave in the case of a waveform (Timbre) element) -1.0 is 0.5 times (for example, in the case of a waveform (Timbre) element, it is lowered by one octave) (see the upper diagram of FIG. 20). The code book 26 stores actual vector data. For example, vector data of an amplitude element or vector data of a pitch element includes an array of VECTORPOINT structures and representative point data.
[0068]
The VECTORPOINT structure array contains the sample positions and values of each point in order. For example, the vector data value of the Amplitude element is in [db] units, and the vector data value of the Pitch element Is 1/1200 [cent] unit when MIDI note number 0 is 0.0. The representative point data is a DWORD type array, and stores the index number of the array of VECTORPOINT structures that are representative points (see the lower diagram of FIG. 20). Of course, it goes without saying that the present invention is not limited to the example described above.
[0069]
3.4.3. Details of the cache control unit 40
(1) Overall configuration of the cache control unit 40
Next, the overall configuration of the cache control unit 40 will be described with reference to FIG. 23. The significance of providing the cache control unit 40 will be described. Since the code book 26 is stored in the hard disk 109, vector data required by the vector decoders 31 to 35 is read from the hard disk 109. However, since a hard disk or the like has a slow access time and is not constant, it is impossible to read the vector data immediately at the timing when the vector decoders 31 to 35 process the vector data. Therefore, in the present embodiment, the cache control unit 40 is provided in the waveform synthesis unit 101D, and vector data to be used in the future (or predicted to be used) is loaded into the cache memory in advance.
[0070]
In FIG. 23, reference numeral 42 denotes a prefetching prefetch unit, which extracts a vector ID from a packet supplied from the rendition style synthesis unit 101C to the waveform synthesis unit 101D, and prefetches (prefetchs) vector data related to the vector ID from the code book 26. Read control to the hard disk 109 is performed. As described above, these packets constitute a packet stream in the packet queue buffers 21 to 25 and are eventually read by the vector loader 20, but in parallel with this, prefetch processing is performed.
[0071]
Reference numeral 41 denotes a prediction control unit, which is highly likely to be used in the future based on prediction data (program change or the like) supplied from the score interpretation unit 101B and prediction conditions supplied from the prefetching prefetch unit 42. And the vector ID related to the predicted vector data is supplied to the prefetching prefetch unit 42. Here, the “prediction condition” is a vector ID or the like determined to be used (that is, supplied from the rendition style synthesis unit 101C). Thus, in the prefetch prefetch unit 42, the vector ID is supplied from both the rendition style synthesis unit 101C and the prediction control unit 41. Then, the prefetching prefetch unit 42 gives priority to the loading of vector data that is determined to be used (that is, the loading of vector data specified from the rendition style synthesis unit 101C), and the vector data related to both vector IDs. Perform prefetch processing. Hereinafter, the load of vector data that is determined to be used is referred to as “designated load”, and the load of vector data that is not determined to be used (simply predicted) is referred to as “predictive load”. Call. A cache memory 44 stores prefetched vector data. When a vector ID is received from the vector loader 20, the read control unit 43 reads vector data corresponding to the vector ID mainly from the cache memory 44 and supplies it to the vector loader 20. A time management unit 45 performs timing control such as prefetch.
[0072]
(2) Operation of prediction control unit 41
Next, the processing content in the prediction control part 41 is demonstrated with reference to the state transition diagram of FIG. The state of the prediction control unit 41 is determined depending on whether or not waveform synthesis is performed in the vector decoders 31 to 35 and to which module the synthesis is performed. In the initial state, since no waveform synthesis is performed in the vector decoders 31 to 35, the prediction control unit 41 performs the process of step S30. Here, the vector data candidates of the attack unit are predicted, and the predicted vector ID is sequentially supplied to the prefetch prefetch unit 42. However, in step S30, unless the “program change” is supplied as prediction data from the score interpretation unit 101B, the prediction of the attack unit is not executed. This is because if the program change is undecided, the vector data of the attack portion that may be specified becomes enormous. Therefore, in the initial state, when a program change is supplied from the score interpretation unit 101B, a predictive load of the attack unit vector data in response to the program change is started immediately.
[0073]
For example, if “Piano” is designated as the program change and there are 100 types of vector data of the attack portion related to “Piano”, predictive loading of 100 types of vector data is started. When the packet related to the attack unit is determined, the waveform loader 20 and the vector decoders 31 to 35 eventually start the attack unit waveform synthesis process. At that time, the state of the prediction control unit 41 transitions to step S31.
[0074]
In step S31, based on the determined vector ID of the attack part, predictive loading is performed on the vector data candidates of the body part. That is, since the pitch of the attack part is known, the candidate vector data is limited to the one corresponding to the same pitch as the attack part. Furthermore, the vector data of the body part that may be linked to the envelope waveform of the attack part that has been determined is further limited. In step S31, candidates narrowed down according to such conditions are predicted loaded. Here, when the packet related to the body part is actually supplied from the rendition style synthesis unit 101C and the packet of the body part is confirmed, the state of the prediction control unit 41 transitions to step S33.
[0075]
In step S33, prediction loading is performed on the next candidate vector data based on the determined vector ID of the body part. As described above, the module connected to the body part is one of the other body part, joint part, or release part. Therefore, the prediction control unit 41 predictively loads these vector data. It should be noted that the vector data candidates to be predicted loaded are narrowed down according to the determined body part pitch, envelope waveform, etc., as in step S31.
[0076]
When a packet is actually supplied from the rendition style synthesis unit 101C during execution of step S33, the state of the prediction control unit 41 transitions according to the packet. First, when the supplied packet is a packet of the body part, the state remains in step S33, and another body part, a joint part or a release part is predicted loaded based on the body part again. . If the supplied packet is a joint packet, the state of the prediction control unit 41 transitions to step S32.
[0077]
In step S32, the vector data candidates of the body part are predictively loaded. Here, the vector data candidates to be predictively loaded are narrowed down to the vector data of the body part that may be connected to the determined joint part. Here, when a packet related to the next body part is supplied from the rendition style synthesis unit 101C, the state of the prediction control unit 41 returns to step S33 again, and the vector data of the other body part, joint part or release part is predicted loaded. Is done. Here, when the packet of the release unit is supplied from the rendition style synthesis unit 101C, the state of the prediction control unit 41 transitions to step S30.
[0078]
In step S30, as described above, the vector data candidates of the attack portion are predicted loaded. However, if the pitch of the release part immediately before is already determined, it is highly possible that the pitch of the next attack part will not deviate so much. Therefore, during the synthesis of the release portion, the vector data of the attack portion that is predicted loaded may be limited to that corresponding to the periphery of the pitch of the release portion (for example, a range of ± 1 octave).
[0079]
(3) Operation of the prefetch prefetch unit 42
(3.1) Load processing (FIG. 25)
Next, the operation of the prefetch prefetch unit 42 will be described. First, in the prefetch prefetch unit 42, a load process shown in FIG. 25 is executed at predetermined intervals. In the figure, when the process proceeds to step S41, it is determined whether a designated load request that has not yet been executed has been received. If "YES" is determined here, the process proceeds to a step S42, and designated loading of the requested vector data is executed. As a result, when a certain read time elapses, the vector data is read from the hard disk 109 and stored in the cache memory 44.
[0080]
On the other hand, if "NO" is determined in the step S41, the process proceeds to a step S43, and a predictive load is executed. That is, of the vector data for which a predicted load request has been made, the data that has been commanded to be read into the cache memory 44 (already loaded in the cache memory 44 and loaded in response to other load requests). That are not scheduled to be read out to the hard disk 109 yet, and the read command is supplied to the hard disk 109 only for the latter. When there is a lot of vector data to be predicted loaded, this routine may be called again during the prediction loading. In such a case, as long as the requested designated load exists, the predicted load is interrupted, and the designated load is executed via step S42. As described above, in the prefetching prefetch unit 42, the designated load is executed more preferentially than the predicted load.
[0081]
(3.2) Packet reception processing (FIG. 26)
Further, in the prefetch prefetch unit 42, every time a packet is supplied from the rendition style synthesis unit 101C, a packet reception process shown in FIG. 25 is executed. In the figure, when the process proceeds to step S51, a vector ID is extracted from the supplied packet, and it is determined whether or not the vector data corresponding to the vector ID is hit. Here, “when hit” means (1) if any of vector data that has been predicted loaded in the cache memory 44 has hit, (2) it has not yet been loaded into the cache memory 44, When the vector data is expected to be loaded, (3) the vector data that has been loaded and used in the past (used state) can be used as it is.
[0082]
In the present embodiment, the used vector data is not immediately released, but is temporarily left in the cache memory 44 as “USED state” vector data. Then, when the storage capacity for storing other vector data becomes insufficient, the vector data area in the USED state is released and new vector data is stored. Details thereof will be described later.
[0083]
If no hit vector data exists, “NO” is determined in step S51, and the process proceeds to step S53. Here, a designated load request is generated for the vector ID included in the packet. Therefore, when the packet reception process (FIG. 26) described above is executed next, the vector data is designated and loaded.
[0084]
On the other hand, if there is hit vector data, it is determined as “YES”, and the process proceeds to step S52. Here, if the prediction load related to the vector data is not completed, the prediction load request is changed to a designated load request. This is because it is preferentially loaded when the packet reception process is subsequently executed. Next, when the process proceeds to step S54, the handle of the vector data requested to be loaded is returned to the rendition style synthesis unit 101C. This handle uniquely corresponds to the vector data. If the vector data requested to be specified is already stored in the cache memory 44, the handle of the vector data is returned. If not, a new handle is generated and returned to the rendition style synthesis unit 101C. .
[0085]
Next, when the process proceeds to step S55, the one out of the predicted load requests that occurred earlier is canceled. The specific content of “cancel” will be described later. Next, when the process proceeds to step S56, the prediction condition in the prediction control unit 41 is changed. That is, according to the packet supplied from the rendition style synthesis unit 101C, prediction load candidates in each state in FIG. 24 are narrowed down, or the state in the prediction control unit 41 is changed.
[0086]
This packet reception process is a “GetVector command” shown in FIG. 28 when viewed from the rendition style synthesis unit 101C side. In other words, the operation in which the rendition style synthesis unit 101C supplies a packet to the waveform synthesis unit 101D is nothing other than sending a GetVector command meaning "get vector data" based on the vector ID included in the packet. . This vector data must be prepared before it is read out later by the vector loader 20, but at that time, a handle is necessary to specify the required vector data from a large number of vector data.
[0087]
(4) Data structure in the cache memory 44
(4.1) Cache page (Fig. 27)
Of the vector data stored in the cache memory 44, those used simultaneously are packed and converted into one file (or a plurality of files equal to or less than the total number of vector data). This conversion is automatically executed prior to performance in accordance with a user instruction or created music data. An example is shown in FIG. In the figure, among the vector data read from the code book 26, the designated load includes time information. Therefore, a plurality of vector data used simultaneously can be extracted. Each vector data read from the code book 26 has a header individually. Vector data used at the same time is collected in, for example, one file, and a common header is given to this file. Thereby, the time for the vector loader 20 to access each vector data can be shortened.
[0088]
The following information is stored in the header of this file.
Data ID: This stores a 4-byte identification character “PACK” for identifying the file type.
Data Size: Indicates the data size of the file
VQ Type: Indicates the type of stored vector data.
Version: Indicates the version of the file format.
A similar header is provided for vector data before packing, but the data ID is not “PACK” but a data ID for identifying the type of each vector data.
[0089]
The waveform generation apparatus according to the present embodiment is realized by an application program on a personal computer, and its cache exists in the system memory. When storing vector data in the cache, cache control is performed in units of cache pages of a predetermined size, rather than being controlled in units of one vector data (size is not uniform). That is, one cache data is divided into a plurality of cache pages, and is stored and managed in the cache in units of cache pages. The system memory stores cache management data (page header) corresponding to each cache page. Since data storage on the hard disk is normally performed in units of fixed-size clusters, the size of the cache page may be the same as the size or an integer multiple thereof. In consideration of the capacity of vector data and the like, it is preferable that the cache page size is 1 k to 10 k bytes.
[0090]
(4.2) Page header data structure
Next, the data structure of the header given to each cache page will be described. Each header is configured by a structure “VDDLCSPAGE”, and the members of the structure are as follows.
dwPage: A page number uniquely assigned to the cache page.
dwID: vector ID of vector data included in this cache page.
dwSize: The data size of this cache page.
dwCount: Indicates the number of prefetches. This member dwCount is incremented by “1” every time it is prefetched by the designated load, and is decremented by “1” every time it is read by the vector loader 20.
dwStatus: Indicates the status of the cache page. The state of the cache page is one of FREE, ALLOCATED, USED, FILLED, and LOCKED.
lpBuf: A pointer that indicates the start address of the entity (other than the header) of the vector data in the cache page.
lpForward / lpBackward: In this embodiment, a bidirectional linked list is formed by a plurality of VDDLCSPAGE structures. The member lpForward is a pointer to another VDDLCSPAGE structure existing in the forward direction of the link, and the member lpBackward: is a pointer to another VDDLCSPAGE structure existing in the backward direction of the link.
lpNext: As described above, when the waveform generation device is realized on dedicated hardware, a plurality of vector data used at the same time is divided into a plurality of cache pages. The plurality of cache pages constitute a “group”, and the member lpNext is a pointer that sequentially indicates other VDDLCSPAGE structures belonging to the same group.
[0091]
Here, the role of the member dwCount will be described. For example, if the same vector data is used twice in a series of packet streams, two designated load requests are generated for the vector data. However, if the cache page is set to the USED state when it is read by the vector loader 20 for the first time, it cannot be read for the second time. Therefore, this problem is prevented by counting how many times the cache page is read.
By the way, when vector data is used a plurality of times, the same vector data is used a plurality of times in the waveform synthesis processing for the same event data, and the same vector data is used a plurality of times in the waveform synthesis processing for a plurality of event data. The case where it is used is considered. In this embodiment, since the remaining number of times of use is determined by the member dwCount in any case, it is possible to handle the cache pages in the cache memory 44 in a unified manner.
[0092]
(4.3) Page header link structure (FIG. 29)
Next, FIG. 29 shows the structure of the bidirectional linked list realized by the pointer lpForward and the pointer lpBackward. In the present embodiment, a list structure as illustrated is employed in order to execute data rearrangement and addition / deletion freely and at high speed.
In the figure, A-1 is a page header located at the head of the bidirectional linked list, the head of which is indicated by a predetermined pointer lpTop, and the end thereof is indicated by a pointer lpTail. A-2 and A-3 are page headers belonging to the same group as the page header A-1. That is, this “group” corresponds to data of individual cache pages formed by dividing one file. The top address of page header A-2 is indexed by member lpNext of page header A-1, and the top address of page header A-3 is indexed by member lpNext of page header A-2.
[0093]
B-1 is a page header linked to the next stage of the page header A-1, and the head address of the page header B-1 is indexed by the member lpForward of the page header A-1. The head address of the page header B-2 belonging to the same group is indicated by the member lpNext of the page header B-1. Further, the start address of the page header C-1 linked to the next stage is indicated by the member lpForward of the page header B-1, and the page header C- is respectively determined by the members lpNext of the page headers C-1 and C-2. 2, the top address of C-3 is indexed. Here, since the cache pages in the FREE state also constitute one group, for example, the groups A and B are set to the FILLED state and the group C is set to the FREE state. When trying to cache new vector data, a cache page is acquired from a group in the FREE state or the USED state, and the cache page is set as a cache page for new vector data.
[0094]
Also, a new cache page and a corresponding page header may be created on the system memory and used as a new vector data cache page. However, in this case, it is preferable to limit the total amount of cache pages to a specified value so that memory resources are not consumed excessively. This designated value may be automatically set according to the amount of system memory, or may be manually set by the user. Further, if control is performed so as to always secure a certain value as the memory amount of the group in the FREE state, the allocation of new vector data to the cache page can be speeded up.
[0095]
According to the bidirectional linked list of FIG. 29, by referring to the member lpForward, the top page headers A-1, B-1, and C-1 of each group constituting the list can be traced in order. it can. Further, the bidirectional linked list can be traced in the reverse direction by referring to the member lpBackward. Accordingly, when investigating whether or not certain vector data is cached, the head page headers constituting the list are sequentially traced, and the member dwID in the page header matches the same vector ID as the vector data. It is good to determine whether or not. If there is a match, the cache page associated with the page header becomes the first cache page of the group caching the vector data. When all vector data used at the same time are always stored in one page, the bidirectional linked list is constituted only by page headers A-1, B-1, and C-1. Null data is stored in the member lpNext of these page headers.
[0096]
When the states indicated by the member dwStatus are arranged in order of importance, the order is “LOCKED ≧ FILLED> ALLOCATED> USED> FREE”. Therefore, if the order of cache pages is set in this order of importance, the allocation of cache pages to new vector data can be speeded up. Furthermore, the value of the member dwCount may be reflected in the importance as it is. In other words, the greater the member dwCount, the higher the importance. In addition, it is preferable to set the level of importance of the cache page that has transitioned to the USED state first between USED state cache pages.
[0097]
(5) Operation in the read control unit 43
Next, the operation of the read control unit 43 will be described again with reference to FIG.
In the vector loader 20, a command is transmitted to the read control unit 43 so as to read the cache memory 44 based on the contents of the packet stream, that is, the vector ID in each packet. This command is called LockVector command. This LockVector command is accompanied by a handle previously returned in response to the GetVector command. In the normal operation state, since the vector data should be stored in the cache memory 44, a pointer to the top address of the cache page related to the vector data is returned to the vector loader 20.
[0098]
As a result, the contents of the cache memory 44 are appropriately read out by the vector loader 20 and the vector decoders 31 to 35, and the waveform synthesis process is executed. As described above, the cache page that can be read by the vector loader 20 or the like is set to the LOCKED state (details will be described later), and is set so that the contents are not altered by other processing.
[0099]
By the way, depending on the situation, necessary vector data may not yet be loaded on the cache memory 44 when the LockVector command is received from the vector loader 20. In particular, when the waveform generation apparatus of this embodiment is realized by an application program of a personal computer, the hard disk 109 may be occupied for a relatively long time due to the convenience of the operating system of the personal computer, and such a situation may often occur. . In this case, different processing is executed depending on the operation mode of the waveform generation device.
[0100]
First, when performing waveform synthesis in non-real time, it is preferable to stop the subsequent processing until the designated vector data is loaded. Therefore, the reading control unit 43 executes synchronous reading with respect to the hard disk 109. This synchronous reading means that no other processing is performed until the desired data is read.
[0101]
On the other hand, when the waveform generation device is operating in real time, executing the synchronous reading may interrupt the musical tone, so that a substitute page pointer is returned to the vector loader 20. In this embodiment, various types of vector data are used to faithfully express various timbre changes. However, in order to perform basic pronunciation without rendition expression etc. for the timbre selected by the program change. If it is limited to the vector, the capacity is not so large. Such vectors are stored in the RAM 103 in advance as default vectors of the timbre, and are used as an alternative to vector data that could not be prepared in the cache memory 44.
[0102]
Even in the case of performing real-time synthesis, when the time delay in the waveform synthesis process S14 (waveform synthesis unit 101D) is sufficiently secured and necessary vector loading and waveform synthesis are possible within the range, Similar to the case of waveform synthesis in non-real time, when it is found that necessary vector data is not loaded, the vector data can be read out urgently to perform waveform synthesis. For cache pages that have been used by the vector loader 20 and the vector decoders 31 to 35, the vector loader 20 supplies a release command with a handle to the read control unit 43. When this Release command is supplied, the LOCKED state of the cache page is canceled and the handle is released.
[0103]
(6) State transition operation for cache pages
Next, an operation for changing the state of each cache page will be described with reference to the state transition diagram of FIG.
First, in the initial state, all cache pages are set to the FREE state (S61). That is, the member dwStatus of the header of the cache page is set to “FREE”. This means that it is unused and the content is not guaranteed. When vector data is loaded on this cache page, the cache page is set to the ALLOCATED state (S62). The ALLOCATED state means that data storage has not yet been completed, but is reserved for reading data from the code book 26. At this time, “1” is stored in the member dwCount.
[0104]
Thereafter, when the vector data is stored in the page, the state of the cache page changes to the FILLED state. In the ALLOCATED state or the FILLED state, when a designated load request occurs again for the same vector data, the member dwCount is incremented by “1” each time. When the predicted load request is canceled in the ALLOCATED state or the FILLED state (step S55 of the load process (FIG. 25)), the member dwCount is decremented by “1”. When the value of the member dwCount becomes “0” in these states, the cache page is set to the USED state (S63).
[0105]
After the cache page transitions to the FILLED state, when the LockVector command is supplied from the vector loader 20, the cache page is set to the LOCKED state (S65). When the use of the cache page by the vector loader 20 and the vector decoders 31 to 35 ends and the Release command is supplied, the LOCKED state is canceled (unlocked), and the cache page is set to the FILLED state (S64) again. Is done. At this time, the member dwCount of the cache page is decremented by “1”. At this time, when the member dwCount becomes “0”, the state of the cache page is immediately set to the USED state (S63).
[0106]
In addition, after a cache page is set to the USED state, when a predicted load request or a designated load request (prefetch) occurs again for the cache page, the cache page is returned to the FILLED state again. When the above processing continues, the cache pages in the USED state increase in the cache memory 44 and the cache pages in the FREE state decrease. When prefetch occurs for new vector data after there are no more cache pages in the FREE state, the cache pages in the USED state are canceled (SwapOut) in order from the oldest USED state, and the FREE state (S61). ). Then, the cache page returned to the FREE state is set to the ALLOCATED state for loading the new vector data.
[0107]
Here, as a method for quickly specifying the oldest cache page in the USED state, the bidirectional linked list described above with reference to FIG. 29 may be used. That is, when any cache page is set to the USED state, the cache page is added to the head of the linked list, and when the cache page in the FREE state is insufficient, the cache page at the end of the linked list is used. You should remove it from the linked list one after another and change it to the FREE state.
[0108]
(7) Time management unit 45
The time management unit 45 controls the timing of the entire waveform synthesis unit 101D. Here, an outline of the timing control in the present embodiment will be described with reference to FIG.
In the figure, it is assumed that the reproduction start is instructed at time t30 (for example, the reproduction button is pressed by the user), and the time when the musical sound output is actually started is t40. The time from time t30 to t40 is called latency β. The latency β is set to about 2000 msec, for example, but need not be set in particular.
[0109]
When the start of playback is instructed, the CPU 101 generates a playback thread every predetermined time. In this playback thread, song data is read, and prefetch processing for the hard disk 109 or the like is executed in accordance with the contents. The time from the time t32 at which certain music data is read to the actual sounding start time t40 is referred to as the advance time γ. For example, the reference value of the advance time γ is preferably set to about 4000 msec, and can be expanded and contracted in a range of about 1000 to 10,000 msec depending on the processing state.
[0110]
In this way, by ensuring a certain amount of the advance time γ, it is possible to intermittently generate playback threads and to read music data intermittently (to some extent). An interval at which the playback thread is generated is called a playback thread generation interval ε. The reference value of the reproduction thread occurrence interval ε is preferably set to 20 msec, for example, and may be expanded and contracted in a range of about 5 to 100 msec depending on the processing status.
[0111]
When the song data is read at time t32, a part of the song data is extracted in step S11 as described above, the score is interpreted in step S12, and then rendition composition is executed in step S13. As a result, vector data is prefetched at time t34. The time from the prefetch time t34 to the sound generation start time t40 is called a prefetch time α.
[0112]
The vector data read from the hard disk 109 is eventually written into the cache memory 44. Thereafter, at time t36, the vector loader 20 reads the vector data from the cache memory 44 via the read control unit 43, and waveform synthesis is started. The time from the waveform synthesis start time t36 to the sound generation start time t40 is called an output latency δ. The reference value of the output latency δ is preferably set to about 300 msec, for example, and may be expanded and contracted in a range of about 10 to 1000 msec depending on the processing state.
[0113]
It should be noted that it is preferable that such a waveform synthesis process is intermittently executed in a certain time range as in the case of the reproduction thread. The reference value of the activation frequency interval of this waveform synthesis process is preferably set to 50 msec, for example, and can be expanded and contracted in a range of about 10 to 500 msec depending on the processing status.
[0114]
As is clear from FIG. 31, the advance time γ, the prefetch time α, and the output latency δ have a relationship of “γ> α> δ”. Here, the time interval “α−δ” from the prefetch time t34 to the waveform synthesis start time t36 needs to be set to such an extent that vector data can be loaded from the hard disk 109. When the peak value of the load amount of vector data is high, generation of noise or the like can be prevented by increasing the time interval “α−δ”.
[0115]
4). Modified example
The present invention is not limited to the above-described embodiment, and various modifications can be made as follows, for example.
(1) When the waveform generating apparatus as described above is used for an electronic musical instrument, the electronic musical instrument is not limited to a keyboard musical instrument, and may be any type of form such as a stringed musical instrument, a wind instrument, or a percussion instrument. In this case, the music data playback unit 101A, the score interpretation unit 101B, the rendition style synthesis unit 101C, the waveform synthesis unit 101D, etc. are not limited to those built in one electronic musical instrument main body, and each is configured separately. Needless to say, the present invention can be similarly applied to a configuration in which each component is connected using communication means such as an interface or various networks. Further, it may be configured as a personal computer and application software. In this case, the processing program may be supplied by being stored in a recording medium such as a magnetic disk, an optical disk or a semiconductor memory, or supplied via a network. . Furthermore, the present invention may be applied to an automatic performance device such as an automatic performance piano.
[0116]
(2) In the above embodiment, a plurality of vector data is stored in one cache page, but it goes without saying that one vector data may be stored in one cache page.
[0117]
(3) In the above-described embodiment, it is determined whether to shift to the USED state by incrementing or decrementing the member dwCount of the header of the cache page. However, with this method, there is a possibility that the cache memory 44 will run out of capacity when the number of unused cache pages increases. In such a case, “priority” may be defined for the cache page in the FILLED state, and the cache page in the FILLED state having a low priority may be sequentially shifted to the USED state and the FREE state. In this case, when the LockVector command is received from the vector loader 20 for the cache page that has been changed to the FREE state, the above-described alternative page is used. As a specific example of “priority”, the value of the member dwCount may be used as it is (assuming that the higher the value, the higher the priority). Also, the number of times the cache page has been used in the past and the maximum value of the member dwCount (maximum value in the past history) may be taken into account.
[0118]
(4) In the above embodiment, when cache pages in the USED state are joined by the bidirectional linked list, and the cache pages in the FREE state are insufficient, the cache page at the end of the linked list (the oldest one) )) We removed sequentially and changed to FREE state. However, the order of transition to the FREE state is not limited to this. For example, for cache pages that have been used many times, cache pages that have a large maximum value in the history of member dwCount, or vector data that is used at the beginning of each module, in other words, avoid transitioning to the FREE state as much as possible. If so, it may be set so as to be preferentially left in the cache memory 44. Further, the used vector data that has been actually used may be left preferentially over vector data that has not been actually used (that is, the prediction has failed).
[0119]
Also, by preferentially leaving the vector data used at the beginning of the module, the margin for the operation of the hard disk 109 is increased, and the situation where an alternative page must be used can be reduced.
Specifically, when a cache page that should remain preferentially is transitioned to the USED state, the cache page is added to the top of the linked list, and when other cache pages are transitioned to the USED state, the cache page is It should be inserted in the middle of the linked list.
[0120]
(5) In the above embodiment, an example using vector data as a specific example of sound data has been shown. However, the sound data is not limited to vector data, and various waveform data defining a musical sound waveform or It goes without saying that the parameters may be used as sound data.
[0121]
(6) In the above embodiment, as described in FIGS. 15 to 23, the packet stream from the rendition style synthesis unit 101C is directly input to the prefetch prefetch unit 42. However, instead of this operation, the prefetch prefetch unit 42 may read the packet stream once written in the packet queue buffers 21 to 25. In that case, the prefetching prefetch unit 42 may read and process the packet from the packet queue buffer at a predetermined time before the timing at which the vector loader 20 reads and processes the packet stored in the packet queue buffer. Is preferred.
[0122]
【The invention's effect】
  As described above, according to the present invention, sound data is used for waveform synthesis.After being used, the sound data is set while setting the release priority based on whether the sound data is sound data used at the head of each section.Since it is held in the high-speed storage device in a state where it can be used in the future, it is not necessary to access a low-speed storage device such as a hard disk when the sound data is actually used later. Thereby, the access frequency with respect to low-speed storage devices, such as a hard disk, can be reduced.
[Brief description of the drawings]
FIG. 1 is a block diagram showing a hardware configuration example of a waveform generation apparatus according to the present invention.
FIG. 2 is a flowchart showing an embodiment of “waveform database creation processing” executed in the waveform generation apparatus.
FIG. 3 is a diagram schematically showing an example of each component and element constituting an actual waveform section corresponding to a rendition style module.
FIG. 4 is a flowchart showing an embodiment of a “musical tone synthesis process based on a database”.
FIG. 5 is a block diagram showing an embodiment when a waveform synthesis process similar to FIG. 4 is configured in the form of dedicated hardware;
FIG. 6 is a block diagram for explaining the flow of rendition style composition processing in the rendition style composition unit described above.
FIG. 7 is a flowchart showing in detail an embodiment of a rendition style synthesis process performed by a rendition style synthesis unit.
FIG. 8 is a conceptual diagram for explaining link processing when a rendition style module corresponds to an amplitude element or a pitch element.
FIG. 9 is a conceptual diagram for explaining waveform thinning when an attack waveform and a body waveform are connected.
FIG. 10 is a conceptual diagram for explaining waveform thinning when a body waveform and a release waveform are connected.
FIG. 11 is a conceptual diagram for explaining waveform thinning when a bent attack waveform and a release waveform are connected.
FIG. 12 is a conceptual diagram for explaining waveform thinning when a normal attack waveform and a release waveform having a loop portion are connected.
FIG. 13 is a conceptual diagram for explaining waveform connection in a case where a performance style module before the start of a subsequent performance style module ends.
FIG. 14 is a conceptual diagram for explaining a packet stream generated by a rendition style synthesis unit.
FIG. 15 is a conceptual diagram showing an embodiment of an overall configuration for explaining an operation in a waveform synthesis unit.
FIG. 16 is a block diagram simply showing the overall flow of waveform synthesis.
FIG. 17 is a block diagram for explaining a vector loader.
FIG. 18 is a block diagram for explaining a vector operator.
FIG. 19 is a block diagram for explaining a vector recorder.
FIG. 20 is a conceptual diagram conceptually showing an embodiment of a data structure of vector data.
FIG. 21 is a view showing the contents of performance data created in the score interpretation unit 101B.
FIG. 22 is a diagram showing timing at which each packet is supplied from the rendition style synthesis unit 101C to the waveform synthesis unit 101D.
23 is a block diagram showing the overall configuration of the cache control unit 40. FIG.
24 is a state transition diagram of the prediction operation of the prediction control unit 41. FIG.
FIG. 25 is a flowchart of a load process executed in the prefetch prefetch unit.
FIG. 26 is a flowchart of packet reception processing executed in the prefetch prefetch unit.
FIG. 27 is an operation explanatory diagram showing a cache page configuration method;
FIG. 28 is a signal flow diagram between the rendition style synthesis unit 101C and the waveform synthesis unit 101D.
FIG. 29 is a diagram showing a link structure of page headers in the cache memory 44;
30 is a state transition diagram of each page in the cache memory 44. FIG.
FIG. 31 is a timing chart showing an outline of timing control of the embodiment.
[Explanation of symbols]
1-12: Data, 20: Vector loader, 21-25: Packet queue buffer, 26: Code book, 31-35 ... Vector decoder, 36, 37 ... Vector operator, 38 ... Mixer, 40 ...... Cache control unit, 41 …… Prediction control unit, 42 …… Prefetching prefetch unit, 43 …… Read control unit, 44 …… Cache memory (high-speed storage device), 45 …… Time management unit, 50 …… Attack unit Rendition style module 101... CPU, 101 A... Song data reproduction unit 101 B... Score interpretation unit 101 C .. rendition style synthesis unit 101 D ... waveform synthesis unit 102 ... ROM 103 103 RAM 104 ... Panel switch, 105... Panel display, 106... Drive, 106 .. said drive, 106 A .. External storage medium, 107. Acquire unit, 108 ...... waveform output section, 108A ...... sound system, 109 ...... hard (low speed storage device), 111 ...... communication interface.

Claims (3)

楽音波形の所定区間毎の波形合成のために用いられる音データを記憶する低速記憶装置と、該音データをキャッシングする高速記憶装置とを用いて、前記低速記憶装置に記憶された音データのうちの一部を波形合成のために前記高速記憶装置に転送する音データ転送方法であって、
発音指示が発生すると、前記高速記憶装置に新たに転送される音データを記憶するための空き領域が不足するか否かを検出する空き領域検出過程と、
前記空き領域検出過程において空き領域が不足すると判定された場合に、前記高速記憶装置に先に保持された音データの記憶領域を解放優先度の高い順に空き領域として解放する解放過程と、
前記空き領域検出過程において検出された空き領域または前記解放過程において得られた空き領域に対して、前記低速記憶装置から新たに転送される音データを転送する転送過程と、
該音データが波形合成のために使用された後、該音データが前記各区間の先頭部分で使用される音データである場合には前記解放優先度が低く、該音データが他の部分で使用される音データである場合には前記解放優先度が高くなるように、前記解放優先度を設定しつつ、該音データを将来も利用可能な状態で前記高速記憶装置に保持する保持過程と
を有することを特徴とする音データ転送方法。Of the sound data stored in the low-speed storage device , using a low-speed storage device that stores sound data used for waveform synthesis for each predetermined section of the musical sound waveform and a high-speed storage device that caches the sound data A sound data transfer method for transferring a part of the data to the high-speed storage device for waveform synthesis,
When a sound generation instruction occurs, a free space detection process for detecting whether or not a free space for storing sound data newly transferred to the high speed storage device is insufficient,
A release process of releasing the storage area of the sound data previously held in the high-speed storage device as a free area in order of high release priority when it is determined that the free area is insufficient in the free area detection process;
A transfer process for transferring sound data newly transferred from the low-speed storage device to a free area detected in the free area detection process or a free area obtained in the release process ;
After the sound data is used for waveform synthesis, the release priority is low when the sound data is sound data used at the head portion of each section, and the sound data is at other portions. A holding process for holding the sound data in the high-speed storage device in a state where it can be used in the future , while setting the release priority so that the release priority becomes higher when the sound data is used. A sound data transfer method comprising: 請求項１記載の方法を実行することを特徴とする音データ転送装置。A sound data transfer apparatus for executing the method according to claim 1 . 請求項１記載の方法を実行することを特徴とするプログラム。A program for executing the method according to claim 1 .
JP2001086163A 2001-03-23 2001-03-23 SOUND DATA TRANSFER METHOD, SOUND DATA TRANSFER DEVICE, AND PROGRAM Expired - Fee Related JP3649141B2 (en)

Priority Applications (9)

Application Number Priority Date Filing Date Title
JP2001086163A JP3649141B2 (en) 2001-03-23 2001-03-23 SOUND DATA TRANSFER METHOD, SOUND DATA TRANSFER DEVICE, AND PROGRAM
TW091104809A TWI228704B (en) 2001-03-23 2002-03-14 Music sound synthesis with waveform caching by prediction
US10/098,670 US6576827B2 (en) 2001-03-23 2002-03-14 Music sound synthesis with waveform caching by prediction
EP09180304A EP2175440A3 (en) 2001-03-23 2002-03-14 Music sound synthesis with waveform changing by prediction
EP02005887.1A EP1260964B1 (en) 2001-03-23 2002-03-14 Music sound synthesis with waveform caching by prediction
SG200201610A SG102667A1 (en) 2001-03-23 2002-03-19 Music sound synthesis with waveform caching by prediction
CN2006100735605A CN1838234B (en) 2001-03-23 2002-03-22 Music tone composing method and device
CNB021080259A CN1258751C (en) 2001-03-23 2002-03-22 Music mixing method by waved high speed fubber with pre-measurement
HK02109273.7A HK1048011B (en) 2001-03-23 2002-12-21 Method and apparatus for synthesizing musical tone

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
JP2001086163A JP3649141B2 (en) 2001-03-23 2001-03-23 SOUND DATA TRANSFER METHOD, SOUND DATA TRANSFER DEVICE, AND PROGRAM

Publications (2)

Publication Number Publication Date
JP2002287754A JP2002287754A (en) 2002-10-04
JP3649141B2 true JP3649141B2 (en) 2005-05-18

Family

ID=18941580

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2001086163A Expired - Fee Related JP3649141B2 (en) 2001-03-23 2001-03-23 SOUND DATA TRANSFER METHOD, SOUND DATA TRANSFER DEVICE, AND PROGRAM

Country Status (1)

Country Link
JP (1) JP3649141B2 (en)

Also Published As

Publication number Publication date
JP2002287754A (en) 2002-10-04

Similar Documents

Publication Publication Date Title
US6576827B2 (en) Music sound synthesis with waveform caching by prediction
US7259315B2 (en) Waveform production method and apparatus
JP3744216B2 (en) Waveform forming apparatus and method
JP2001100760A (en) Method and device for waveform generation
JP2003241757A (en) Device and method for waveform generation
JP3601371B2 (en) Waveform generation method and apparatus
JP3654079B2 (en) Waveform generation method and apparatus
JP3654083B2 (en) Waveform generation method and apparatus
JP3654080B2 (en) Waveform generation method and apparatus
JP3654082B2 (en) Waveform generation method and apparatus
JP3654084B2 (en) Waveform generation method and apparatus
JP3630107B2 (en) SOUND DATA TRANSFER METHOD, SOUND DATA TRANSFER DEVICE, AND PROGRAM
JP3630106B2 (en) SOUND DATA TRANSFER METHOD, SOUND DATA TRANSFER DEVICE, AND PROGRAM
JP3674526B2 (en) Waveform synthesis method, sound data transfer device, and program
JP3649141B2 (en) SOUND DATA TRANSFER METHOD, SOUND DATA TRANSFER DEVICE, AND PROGRAM
JP3933161B2 (en) Waveform generation method and apparatus
JP4007374B2 (en) Waveform generation method and apparatus
JP3674527B2 (en) Waveform generation method and apparatus
JP3933162B2 (en) Waveform generation method and apparatus
JP3829732B2 (en) Waveform generating apparatus and method
JP3829707B2 (en) Waveform generating apparatus and method
JP3778036B2 (en) Waveform generating apparatus and method
JP3613191B2 (en) Waveform generation method and apparatus
JP3744247B2 (en) Waveform compression method and waveform generation method
JP3788096B2 (en) Waveform compression method and waveform generation method

Legal Events

Date Code Title Description
A977 Report on retrieval

Free format text: JAPANESE INTERMEDIATE CODE: A971007

Effective date: 20041001

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20041102

A521 Written amendment

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20041221

TRDD Decision of grant or rejection written
A01 Written decision to grant a patent or to grant a registration (utility model)

Free format text: JAPANESE INTERMEDIATE CODE: A01

Effective date: 20050125

A61 First payment of annual fees (during grant procedure)

Free format text: JAPANESE INTERMEDIATE CODE: A61

Effective date: 20050207

R150 Certificate of patent or registration of utility model

Free format text: JAPANESE INTERMEDIATE CODE: R150

S531 Written request for registration of change of domicile

Free format text: JAPANESE INTERMEDIATE CODE: R313532

R350 Written notification of registration of transfer

Free format text: JAPANESE INTERMEDIATE CODE: R350

FPAY Renewal fee payment (event date is renewal date of database)

Free format text: PAYMENT UNTIL: 20080225

Year of fee payment: 3

FPAY Renewal fee payment (event date is renewal date of database)

Free format text: PAYMENT UNTIL: 20090225

Year of fee payment: 4

FPAY Renewal fee payment (event date is renewal date of database)

Free format text: PAYMENT UNTIL: 20090225

Year of fee payment: 4

FPAY Renewal fee payment (event date is renewal date of database)

Free format text: PAYMENT UNTIL: 20100225

Year of fee payment: 5

FPAY Renewal fee payment (event date is renewal date of database)

Free format text: PAYMENT UNTIL: 20110225

Year of fee payment: 6

FPAY Renewal fee payment (event date is renewal date of database)

Free format text: PAYMENT UNTIL: 20120225

Year of fee payment: 7

FPAY Renewal fee payment (event date is renewal date of database)

Free format text: PAYMENT UNTIL: 20130225

Year of fee payment: 8

FPAY Renewal fee payment (event date is renewal date of database)

Free format text: PAYMENT UNTIL: 20140225

Year of fee payment: 9

LAPS Cancellation because of no payment of annual fees