JP2020030418A

JP2020030418A - 携帯用音声合成のためのシステム及び方法

Info

Publication number: JP2020030418A
Application number: JP2019193982A
Authority: JP
Inventors: ジョルジュ，アラン; Alain Georges; デイムブスキ，ボイト; Voit Damevski; ブレアー，ピーター・エム; Peter M Blair; ラファイエット，クリスティヤン; Christian Laffitte; ヴェンツィンガー，イヴ; Yves Wenzinger
Original assignee: MediaLab Solutions LLC
Current assignee: MediaLab Solutions LLC
Priority date: 2003-01-07
Filing date: 2019-10-25
Publication date: 2020-02-27
Also published as: JP2014238604A; US20100031804A1; JP5624255B2; US9471271B2; JP6645956B2; JP6122404B2; US20150148927A1; US8153878B2; JP2006513448A; JP2017107202A; US20070186752A1; US20080053293A1; JP2011028276A; US20040089141A1; US7169996B2; JP2008501125A; JP4413144B2; WO2004064036A1; US7655855B2; US8247676B2

Abstract

【課題】楽曲を創作し、変更し、相互作用し及び／又は演奏するためのシステム及び方法を提供する。【解決手段】携帯用ハードウェアデバイスにおいて、マイクロプロセッサＭＰ３６は、ローカルアドレス及びデータバスＭＰアドレス及びＭＰデータを制御する。汎用シリアルバスインターフェースＵＳＢ、ＳＭＣ及びフラッシュ４１のようなメモリは、ＭＰデータバス上に存在する。ＭＩＤＩ／音声ＤＳＰは、ＭＰアドレスバス及びＭＰデータバス上に存在する。ＳＭＣは、ＭＰデータバスの間にバッファ、キーボード及びＭＰバスとも関連するＬＣＤインターフェース４５を有する。ＭＰは、入力データストリームからタイミング情報を得て、ＭＩＤＩ情報をＤＳＰに送信するシーケンサとして働く。ＤＳＰは、ローカルＲＡＭ及びフラッシュ４９へのアクセスを提供する専用アドレス及びデータバス（ＤＳＰアドレス及びＤＳＰデータ）をさらに有する。【選択図】図３２

Description

本特許出願は、２００３年１月７日に米国出願されたシリアル番号３３７，７５３号、及び、２００３年８月８日に国際出願されたＰＣＴ／ＵＳ０３／２５８１３の一部継続出願である。

本発明は、携帯用機器において音声合成のためのシステム及び方法に関する。さらに、本発明は、楽曲を創作し、変更し、相互作用を生じさせて、演奏するためのシステム及び方法に関するものであり、より詳細には、トップダウン及び対話式の自動作曲プロセスを使用したシステム及び方法に関する。このようなシステム／方法は、特定のユーザが望む楽曲を創作するために、変更され、相互作用され、演奏され、及び／又は、（後の演奏のために）記憶されることができる音楽作品をユーザに提供する。さらに、本発明は、自動生成された楽曲のためのシステム及び方法に関し、より詳細には、アルゴリズムにより生成された音楽作品の一部として声音トラックを生成するためのシステム及び方法に関する。さらに、本発明は、好ましくは、順方向及び／又は逆方向の互換性を提供するような手法で情報を記憶させるのに好適なファイルフォーマットに関する。さらに、本発明は、演算による楽曲生成のためのシステム及び方法に関し、特に、好ましくは、楽曲構成の現在のピッチ及び／又はリズム特性に音響サンプルのおおよその調和を可能にする、改良されたサンプルフォーマット及びコントロール機能に関する。さらにまた、本発明は、楽曲を放送するためのシステム及び方法に関し、より詳細には、データファイル分配システムを用いたシステム及び方法に関するものであって、楽曲の少なくともいくつかの部分をデータファイルの受信に伴ってノード／加入者ユニットによって生成さすることができるものである。上記のデータファイルは、好ましくは、そのデータファイルに基づいて好ましくは楽曲を作る楽曲生成システムを用いて、処理される。その上、本発明は、楽曲データファイルをノード／加入者ユニットによって生成又は変更することができて、そして、好ましくはセルラ又は他の無線ネットワークを通して、他と共有されるシステム及び方法に関する。

システム及びこの種のスタイルにしたがって創作し、記憶して、楽曲を演奏するシステム及び技術により、多数の異なる楽曲スタイルが長年の間に出現している。特に、楽曲創作は、音楽的訓練を受けたり、１又は複数の楽器を学び、演奏するために必要とされる時間と精力を費やした人々に限られていた。良質の楽曲を創作し記憶するためのシステムは、多数のコンピュータ処理及び／又はデータ記憶を利用する技術に向かっていた。その技術の最近の例は、コンパクトディスク（ＣＤ）を含むオーディオプレーヤ及び圧縮されたファイルのプレーヤ（例えば標準のＭＰＥＧ−レベル３）などを含む。さらに、ＦＭ又はＡＭ受信器のような電磁波を通して無線放送の受信を許容するチューナを組み込んだ機器も存在する。

電子工学及びコンピュータ関連技術は、長年楽器に適用されてきており、その傾向が強まっている。複合度、音楽的洗練性及び優秀性を増大する楽曲合成器及び他の器具が開発され、標準のＭＩＤＩ（ＭｕｓｉｃａｌＩｎｓｔｒｕｍｅｎｔＤｉｇｉｔａｌＩｎｅｔｅｒｆａｃｅ）として知られるそれらの器具相互間の対話のための言語が創作された。ＭＩＤＩ互換の器具及びコンピュータ技術は、楽曲を創作し、演奏し、記憶するための能力に大きなインパクトもたらしたが、それらのシステムは、それでもかなりの音楽訓練又は経験を必要とし、複雑で高価となる傾向にある。

音響生成システムは、対話的に生成された音響との組み合わせで演奏される既存の音響のサンプルを組み込むことができる。ひとつの例として、携帯用楽曲生成製品は、ある楽曲ルールに従う楽曲を対話的に生成するために利用される。ユーザにより確実な音楽的経験をしてもらうために、予め録音されていた音響の利用を可能にすることが好ましい。

録音済の音響サンプルの利用をサポートする際の問題点は、楽曲の楽節中のサンプルの演奏が、ときどきピッチ又はリズムの点で楽曲と同期して鳴り響くことになるということである。これは、ある特定の時点でのサンプルと楽曲との間のデフォルト同期の欠如による。解決策のひとつは、明確なピッチ又はメロディをもたないサンプル、例えば、しゃべり声、音響効果、を利用することである。しかしながら、メロディサンプルの利用は、特に高い音域において楽曲の数多くの楽曲のスタイルにおいて望ましく、ピッチ及び／又は周期的情報（組み込み又は他の方法で）サンプルに入れ込む手段を持たせることが望ましい。

放送音楽配信は、歴史的にＦＭ又はＡＭ放送チャネルを利用する放送電波を通しての、楽曲のリアルタイムのストリーミングを含む。同様に、インターネットも、ほぼリアルタイム方式での楽曲データの音声ストリーミングのために利用されてきた。これらの例のいずれも、比較的大量のデータを着実に送信することができるので、比較的大量の利用可能な帯域幅を必要とする。楽曲のスタイル数とこれらのシステムの効果的な使用に必要な帯域幅は、広範囲の無線コンピューティング資源（例えば、携帯電話機及び／又はパーソナルデジタルアシスタント（ＰＤＡ））を組み込んだ新しい製品へのアプローチを制限していた。さらに、楽曲配信へのこれらのアプローチの制限は、楽曲のラジオタイプ配信の一部としても、あるいは、他のノード／加入者ユニットでダイレクトに、楽曲、特にノード／加入者ユニットのユーザによって創作され、変更された楽曲をそのノード／加入者ユニットで共有することができることを困難にしている。

さらに、ここで論じた発明に関係している情報を記憶するにふさわしいファイルフォーマットは、最適化された特徴を提供しないことが多々ある。一つの例として、順方向及び／又は逆方向の互換性が達成できず、結果として、楽曲ファイルが、それを作ったシステムとは異なるバージョンのシステムによって利用できないことになる。順方向及び／又は逆方向互換性のあるレベルを提供するファイルフォーマットは、しばしばオーバヘッド（例えば、同じデータの複数のバージョン）を含んでいる。それは、携帯可能であり、それ故に比較的限られた資源を有する好ましい実施例において、望ましくない。

本発明の技術分野において、比較的限られた処理資源をもつ環境下で高品質の音声合成を提供するのは困難である。通常、高品質の音声合成は、電力を消費し全体的なシステムのコストを大幅に増加させる専用ＤＳＰチップを伴うことがある。例えば、ＭＩＤＩベースの着信音を提供する携帯電話機では、一般に、専用ＭＩＤＩＤＳＰが組み込まれ、システムの開発及び材料の全体的コストを増加させることがあり、また、一般に、製品の電池寿命へ悪影響を及ぼす。さらに、多くの場合、そのようなシステムは、専用ＤＳＰハードウェアを用いたとしても、高品質の音声合成を提供することができない。

本発明の技術分野において、携帯可能なアプリケーション（例えば、携帯電話機など）に関連付けられる減少されたメモリサイズで高品質なＭＩＤＩ音響バンクを提供するのは困難である。通常、ＭＩＤＩ合成プロセッサを用いて高品質の音響を得るためには、比較的に大きなメモリエリアを持つＭＩＤＩ音響バンクが必要とされる。ある携帯可能なアプリケーションでは、利用可能なＭＩＤＩ器具の数を、またある場合にはＭＩＤＩ音響の品質を著しく低減するので、そのような大きなメモリエリアを利用することは好ましくない。

以上の点に鑑み、本発明の目的の１つは、トップダウンプロセスを用いて楽曲を創作し、変更し、相互作用し、及び／又は演奏するためのシステム及び方法を提供することにある。そのシステム／方法は、変更され、相互作用され、演奏され、及び／又は（後の演奏のために）記憶される音楽作品をユーザに提供して、その特定ユーザが望む楽曲を作る。

本発明の他の目的は、楽曲を創作し、変更し、相互に作用し及び／又は演奏するためのシステム及び方法を提供することであり、リアルタイムパフォーマンスのため及び／又は記憶させ次の演奏のために、ユーザが自動作曲された音楽製品又は前に創作された音楽作品を変更することを含め、ユーザが１又は種々の楽曲スタイルにしたがって、望ましい楽曲の迅速創作を開始することを可能にするものである。

本発明の他の目的は、楽曲を創作し、変更し、相互作用し及び／又は演奏するためのシステム及び方法を提供することであり、該システム及び方法においては、聞こえている楽曲又は変更されている楽曲の態様と一致する方法等に示されるグラフィック情報を有することによって、そのシステムの使用を容易にするため及びユーザの興味を増加させるために、グラフィックインターフェースが備えられる。ユーザによってカスタマイズ可能なこの種のグラフィック情報を作ることも、本発明の目的である。

本発明の他の目的は、楽曲を創作し、変更し、相互作用し及び／又は演奏するためのシステム及び方法を提供することであり、それらにおいては、トンネルとして示される複数の楽曲レーンの表現を示すグラフィックインターフェースが備えられ、ユーザは、好ましくは視覚効果の変化を伴っているこの種の変更態様を有する楽曲のパラメータ、音楽作品のサンプル又は他の属性を変更することができる。

本発明の他の目的は、楽曲を創作し、変更し、相互作用し及び／又は演奏するためのシステム及び方法を提供することであり、簡単に変更できるか又は自動合成アルゴリズムなどにおいて使われる形式で楽曲が表現されることができる。そして、それは従来の音声記録技術と比較して、処理及び／又は記憶が必要な事項を低減することができる。

本発明の他の目的は、楽曲を創作し、変更し、相互作用し及び／又は演奏するためのシステム及び方法を提供することであり、それらにおいては、種々の異なった楽曲スタイルで自動的に作曲することができ、ユーザは、特定の楽曲スタイルの新しい音楽を創作するために、自動作曲された楽曲に対して作用することができる。システムは、どのパラメータがユーザによって変更されることができるかについて制御する。そして、ユーザによってなされてもよいこの種のパラメータの変更範囲は、特定の楽曲スタイルと整合している。

本発明の他の目的は、次の自動合成プロセスの楽曲スタイルの一部として使うことができる楽曲ルールを引き出すためにアルゴリズムへの入力として既存の楽曲を使用するためのシステム及び方法を提供することである。

本発明の他の目的は、効率的な歌曲構造と歌曲表現方法に基づき楽曲を創作し、変更し、相互作用し及び／又は演奏するためのシステム及び方法を提供することであり、それらは、この種の歌曲構造及び歌曲表現方法基づいて音楽作品を創作する際に、疑似ランダム事象又はランダム事象を組み込むことができるか又は利用することができる。

本発明の他の目的は、楽曲を創作し、変更し、相互作用し及び／又は演奏するためのシステム及び方法を提供することであり、歌曲が能率的に創作され、記憶され、処理されることができ、好ましくは、比較的少ないデータ記憶容量を曲を記憶するために必要とするような形式で、歌曲が表現される。

このように、歌曲を比較的小さいデータ記憶容量を使用して記憶することができ、したがって、多数の歌曲を所定のデータ記憶容量に記憶することができる。また、歌曲を、比較的小さいデータ伝送帯域幅を使用してインターネットを介して配信することができる。

本発明の他の目的は、楽曲を創作し、変更し、相互作用し及び／又は演奏するためのシステム及び方法を提供することであり、該システム及び方法において、楽曲の変更されたＭＩＤＩ表現が用いられる。好ましくは、例えば、楽曲ルール情報がＭＩＤＩピッチデータに埋め込まれ、楽曲ルールは相対的リズム密度及び音符（ノート）ピッチの相対的移動性を利用するように適用される。

本発明の他の目的は、楽曲を創作し、変更し、相互作用し及び／又は演奏するためのシステム及び方法を提供することであり、ハードウェア／ソフトウェアシステムが好ましくはラジオチューナを含み、そのチューナからの出力を、例えばそのシステムによって作られた自動合成歌曲にミキシングすることができる。それは、好ましくは仮想ラジオ動作モードを含む。

歌曲、歌曲リスト及びコンフィギュレーション情報を記憶するために不揮発性記憶装置媒体を利用するハードウェアを提供し、音楽作品を創作するために利用される歌曲及び歌曲リスト及び音響バンクなどの更新を保存すること及び共有することを容易にするハードウェアを提供することも、本発明の目的である。

本発明の他の目的は、楽曲を創作し、変更し、相互作用し及び／又は演奏するためのシステム及び方法を提供することであり、該システム及び方法は、コンパニオンＰＣソフトウェアプログラムと連動して、ユーザがコンパニオンＰＣ資源を利用することを可能にし、及び／又は演奏リスト、歌曲の構成要素、歌曲、サンプルなどを容易に更新すること及び／又は共有することを可能にする。

本発明の他の目的は、楽曲を創作し、変更し、相互作用し及び／又は演奏するためのシステム及び方法を提供することであり、それにより、歌曲を生成し変更することができ、あるいは、潜在的に使用料なしで広めることができる。

本発明の他の目的は、楽曲を創作し、変更し、相互作用し及び／又は演奏するためのシステム及び方法を提供することであり、楽曲創作のために利用することができる種々のアプリケーション、システム及びプロセスに適用することができる。

本発明の他の目的は、アルゴリズム的に生成される音楽作品の一部として、人間の声のトラックを自動的に生成するためのシステム及び方法を提供することである。
本発明の他の目的は、好ましくは音楽作品の現在のピッチ及び／又はリズム特性に対する音響サンプルの概ねの一致を可能にするために、改良されたサンプルフォーマット及び制御機能のためのシステム及び方法を提供することである。

本発明の目的は、ノードベースの楽曲生成プロセスを使用し、楽曲を配信して、放送及び／又は共有のためのシステム及び方法を提供することである。該システム／方法は、ユーザが楽曲を作曲することができるデータファイルを受け取る（ノード／加入者ユニットを経て）か、及び／又は、書くか又は修正変更することを可能にするものである。

本発明の目的は、楽曲データが放送されるか、若しくはセルラ又は他の無線ネットワークを通じて配信されることを可能にするものである。
本発明の目的は、効果的な逆方向及び／又は順方向の互換ファイル形式を提供するものである。本明細書において開示される好ましい実施態様に関連して使われるときに、この種のファイル形式は特に効果を奏することができる。

本発明の目的は、品質が求められ、処理資源が制限される携帯用環境（例えば、携帯電話機、ＰＤＡ、携帯用ビデオゲーム、その他）における高品質音声合成を提供することである。

最後に、本発明の目的は、比較的小さいメモリサイズ又は配置空間で高質ＭＩＤＩ音響バンクを提供することである。

本発明は、この種の課題及び限定事項を対象にしており、ハードウェア、ソフトウェア、作曲アルゴリズム及びユーザインターフェースなどを（以下に詳述するように）提供することによって、この種の目的を達成することができるシステム及び方法を提供するもので、ユーザが容易に楽曲を創作することができるか、変更することができるか、相互作用して、演奏することができるものである。好ましい実施例において、システムは、ビデオ又はコンピュータゲームのような携帯用フォームファクタにおいて提供される。ステータス情報、好ましくは音楽のパラメータとしての形状、カラー又は他の視覚の属性などが変動し、マイクロホン入力、サンプル、その他のような特定の楽器又は楽曲の構成要素に関連して変動する、楽曲レーン又は構成要素のグラフィック描写を表示するために、グラフィックディスプレイが具備される。ユーザが所望のスタイルの楽曲を創作することができ、変更することができ、相互作用することができ、演奏することができるように、システムは、好ましくは電子ＤＪ（”ｅ−ＤＪ”）モード、仮想ラジオモード、歌曲／歌曲リスト演奏モード、サンプル生成／演奏モード及びシステムモードを含む、種々のモードにおいて動作する。それぞれについて、以下にさらに詳細に説明する。

好ましい実施例は、トップダウン方式を使用し、システムが、ユーザに、特定のユーザによって要求される楽曲を創作するために変更することができ、対話することができ、演奏することができ、及び／又は記憶することができる（後のプレイのために）、ぼほ完成した音楽作品、主要部として歌曲を提供する。楽曲ルール及び好ましくは疑似乱数発生器（それは、また、ユーザ入力等のタイミングによって導入されるランダム状態を組み込むことができる）を使用する自動合成プロセスを利用して、ユーザは、迅速に、リアルタイムパフォーマンスのため及び次の再生のために格納するために、１又は種々の音楽スタイルに従って望ましい楽曲を創作し始めることができる。そこでは、ユーザは、自動作曲された（又は以前作られた）音楽作品を変更することもできる。

グラフィックインターフェースは、聞こえている音楽曲又は変更されている楽曲の態様と一致する方法等に示されるグラフィック情報を有することによって、システムの使用を容易にしてシステムのユーザ享受を増やすために具備される。液晶ディスプレイは、好ましくはＧＵＩを提供するために用いる。但し、外部ビデオモニタ又は他のディスプレイを付加又は変形例として用いることができる。好ましい実施態様において、例えば、コンパニオンソフトウェアプログラムによって、この種のグラフィック情報はユーザによってカスタマイズ可能である。そして、それは好ましくは、ＰＣ上で働いて、ＵＳＢポートのようなインターフェースを経てシステムと接続される。例えば、コンパニオンソフトウェアプログラムは、ユーザが選ぶことができ及び／又は表示に表示されるグラフィックスをカスタマイズするために変更することができる、テンプレート又はサンプルグラフィックスを提供することができる。そして、それは、特定のユーザのパフォーマンスに合うように選択され変更され、又は、演奏されている音楽のスタイルと一致するように選択される。一実施例において、コンパニオンソフトウェアプログラムは、１又は複数のテンプレート又はサンプルグラフィックスセットを提供する。特定のテンプレート又はサンプルグラフィックセットは、楽曲の特定のスタイルと一致する。この種の実施例については、グラフィックスは、創作されるか又は演奏されている楽曲の特定のスタイル及び／又はユーザ個人の好みに密接に一致させるために、カスタマイズすることができる。

少なくとも一つの動作モードで、グラフィックインターフェースは、好ましくは、特定の楽器、サンプル又はマイク入力、その他のような構成要素に対応すする複数の楽曲レーン又はパス（経路）の視覚的表現を示す。ユーザが音楽作品のさまざまな構成要素を視覚化することができることに加えて、ユーザ入力（例えばジョイスティック連動による）によって、ユーザは特定のレーンに入ることができる。レーンは、好ましくはトンネルの表現によって視覚的に示される。

特定のトンネル内部で、ユーザは音楽作品の楽曲パラメータ、サンプル又は他の属性を変更することができ、この種の変更態様は、好ましくはトンネルを伴う視覚効果の変化を伴っている。好ましい実施態様に従って、楽曲を種々の異なった楽曲のスタイルで自動的に作曲することができる。ユーザは、種々のプリセットされた楽曲スタイルによって楽曲を与えられ、ユーザはそれを選ぶことができる。特定の実施例として、ｅ−ＤＪモードで、ユーザは、一まとまりのスタイル（以下に後述するように、スタイルは“スタイルミックス”として準備され、特定のスタイルミックスの範囲内では、１又は複数の特定のスタイル及び任意に“サブスタイル”又は“マイクロスタイル”として準備される）から、特定のスタイルを選ぶことができる。特定のスタイル又はサブスタイルの選択の後、一回のボタンプッシュ（例えば、”ＰＬＡＹ”）で、システムは特定の選択されたスタイル又はサブスタイルに従って自動的作曲を開始する。その後、ユーザは、特定の楽曲のパラメータを変更するために選択されたスタイル／サブスタイルの自動作曲された楽曲と相互作用することができ（例えば、楽曲の特定の構成要素のためのトンネルに入ることにより）、そして、この種の変更により、楽曲スタイル／サブスタイルの新しい楽曲を創作する。選択されたスタイル／サブスタイルと整合した望ましい品質の楽曲の創作を容易にするために、システムは、どのパラメータがユーザによって変更されることができるかについて制御する。そして、この種のユーザ変更可能なパラメータの範囲は、特定の楽曲スタイル／サブスタイルに応じてユーザによって変更される。システムは、これを、容易に変更可能な形式で示されるか又は自動合成アルゴリズム等において使われることができる楽曲を通して、実行する。楽曲のデータ表現及び楽曲のデータを処理することに付随するルールは、楽曲が自動作成されることを可能にし、従来の音声記憶技術（例えばＣＤ音声、ＭＰ３ファイル、ＷＡＶファイル等）と比較して、軽減された処理及び／又は記憶容量で、相互作用されることを可能にする。

特定の実施例に従えば、次の自動合成プロセスの楽曲スタイルの一部として使用可能な楽曲ルールを引き出すために、既存の楽曲がアルゴリズムへの入力として使われる。この種の実施例に従って、楽曲のスタイルは、アーティストの作品、ジャンル、時限、楽曲ラベル、その他に基づいて生成される。この種のスタイルが、それから派生楽曲を作曲するために自動作曲プロセスの一部として用いられる。

特定の実施例に従えば、システムは、効率的な歌曲構造及び歌曲を再現するための方法に基づいて動作する。そして、それはこの種の歌曲構造及び歌曲を示すための方法に基づいて、音楽作品の創作における疑似ランダム／ランダムなイベントを組み込むことができるか又は利用することができる。楽曲は、能率的に創作され、記憶され及び／又は処理され、そして、好ましくは、比較的少ない記憶容量で楽曲を記憶できるような形式で、楽曲は表現される。楽曲は比較的少ないデータ記憶容量を使用して記憶され、すなわち、多数の楽曲を与えられたデータ記憶容量に記憶させることができる、そして、楽曲は比較的小さいデータ伝送バンド幅を使用してインターネットを経て配信される。好ましい実施態様において、例えば、音楽の変更されたＭＩＤＩ表現が使用される。該表現では、楽曲のルール情報がＭＩＤＩピッチデータに埋め込まれ、そして、音響サンプルが、望ましくてより最適な方法でＭＩＤＩイベントに同期することができる。

好ましい実施態様のシステムアーキテクチャは、全体的な系統運用を制御するためのマイクロプロセッサ又はマイクロコントローラを含む。シンセサイザ／ＤＳＰが、オーディオストリーム（音声流れ）（楽曲及び音声サンプル、その他）を生成するために、特定の実施例に具備される。不揮発性メモリが音響バンクを記憶するために提供される。特定の実施例においては、取り外し可能な非不揮発性記憶装置／メモリが、設定ファイル、歌曲リスト及びサンプルを音響バンク最適化又は音響バンクデータを記憶するために具備されている。コーデックが、好ましくは受信されたマイク入力のため、及び、オーディオ出力を提供するために具備される。ラジオチューナが備えられ、例えば、仮想ラジオ動作モードを含むシステムによって創作される自動合成された楽曲が、ラジオチューナから出る出力とミキシングされる。システムはまた、好ましくはハードウェア及び関連するソフトウェエアを含んでおり、楽曲及び歌曲リストの保存及び共有を容易にし、そして、音楽作品を創作する音響バンク等の更新を容易にする。

別の実施例において、ハードウェア、ソフトウェア、楽曲のデータ構造及び／又はユーザインターフェース属性は、種々のアプリケーション及びこの種の楽曲生成が利用されるシステムやプロセスに適合されて利用される。

ある実施例において、本発明は、楽曲のアルゴリズム生成の間、フォーマット化して、予め録音してあるサンプルの演奏を制御するための改良されたシステム及び方法を含む。本発明のすくなるとも１つの利点は、所定のサンプルと関連するピッチ及び／又はリズム特性情報の使用を通して達成される。好ましくは、この種の情報は、リズムの進行及び／又はサンプルのピッチが楽曲に一致することを可能にするために、楽曲のサンプルの演奏を変えるためにＤＳＰ機能を使用することを含む処理の一部としての楽曲のサンプルの演奏の間に、任意に使用される。

本発明の好ましい実施例によれば、ピッチ又はリズムに関して楽曲に同期して音を出す予め録音してある音響サンプルの問題は、サンプルを、明白なピッチ又はメロディを有しないもの、例えば、しゃべり声又は音響効果に制限せずに、十分に対処することができる。メロディサンプルの使用が、特により高いレジスタにおいて、楽曲の多くのスタイルにおいて望ましいので、アルゴリズム又はその他自動生成楽曲であっても、ピッチ及び／又は周期性情報（埋め込まれているか又はその以外）をサンプルに関連付ける能力を有することは望ましい。そして、この種の情報は、特定のピッチ、メロディ及び／又は音楽作品の周期特性にサンプルの同期を可能にするために、音楽装置の楽曲ルール及び／又はアルゴリズムによって解釈される。

本発明の好ましい実施例によれば、放送音楽と関連する問題は、楽曲を放送するためのシステム及び方法、特に、データファイルに基づく配信を使用するシステム及び方法を提供することによって対処される。該システム及び方法においては、少なくとも楽曲の部分はデータファイルの受信によりノード／加入者ユニットによって生成される。そして、それは楽曲生成システムを使用して処理され、データファイルに基づいて楽曲を作曲する。本発明は、好ましくはノード／ベースの楽曲生成を利用する。ノード／加入者ユニットに楽曲の生成を組み込むことによって、従来技術の帯域幅強調の技術を避けることができる。従って、帯域幅も例えばノード対ノード及びノード対基地の楽曲データ伝送機能等のために使われる。例えば、ノードは、楽曲を生成するための、以前に受信され又は生成されたデータファイルを創作又は変更することができる。そして、生成又は変更されたデータファイルは、当該ノードから他のノードまで、又は当該ノードから基地局まで伝送される。それは、放送であってもよいし、又は１又は複数のノードに伝送されてもよい。本発明は、その後生成される楽曲を描写するか又は定めるのに十分なさまざまなパラメータを含む、比較的小さいデータファイル伝送によって特徴づけられる。さまざまな楽曲生成及び信号処理機能を使用する楽曲を提供するために、この種のファイルが１又は複数のノード／加入者ユニットによって受信され、そして使用される。

本発明の好ましい実施例に従えば、設計要求事項を単純化しコストを最小化する方法で音声合成を実行するためのシステム及び方法を提供する。該単純化及びコスト低減は、ポータブルシステム（例えば、携帯電話機機、ＰＤＡ、携帯用ビデオゲーム等）のために良質な音声合成機能を提供しつつ可能となり、携帯環境の音声合成と関連する課題が対処される。

本発明の好ましい本実施例に従えば、ＭＩＤＩ音声バンクにおける音質とメモリサイズとのトレードオフに関連する課題は、システム及び方法を比較的低いメモリサイズのアプリケーション（例えば、携帯電話機、ＰＤＡ、携帯用ビデオゲーム、その他）のために最適化されるＭＩＤＩ音響バンクを提供するためのシステム及び方法を具備することによって、対処される。

この種の本発明の態様は、以下に続く詳細な説明に基づいて理解される。

本発明の「プレーヤ」の典型的な好ましい実施例を例示する図である。本発明による典型的な好ましい機能及びモードキーを例示する図である。本発明による典型的な好ましい機能及びモードキーを例示する図である。本発明のＧＵＩの典型的な好ましい画面を例示する図である。本発明のＧＵＩの典型的な好ましい画面を例示する図である。本発明のＧＵＩの典型的な好ましい画面を例示する図である。本発明のＧＵＩの典型的な好ましい画面を例示する図である。本発明のＧＵＩの典型的な好ましい画面を例示する図である。本発明のＧＵＩの典型的な好ましい画面を例示する図である。本発明のＧＵＩの典型的な好ましい画面を例示する図である。本発明のＧＵＩの典型的な好ましい画面を例示する図である。本発明のＧＵＩの典型的な好ましい画面を例示する図である。本発明のＧＵＩの典型的な好ましい画面を例示する図である。本発明のＧＵＩの典型的な好ましい画面を例示する図である。本発明のＧＵＩの典型的な好ましい画面を例示する図である。本発明のＧＵＩの典型的な好ましい画面を例示する図である。本発明のＧＵＩの典型的な好ましい画面を例示する図である。本発明のある好ましい実施例に従って使用する典型的な構成パラメータを例示しているテーブルの図である。特定の好ましい実施例において、本発明で使用する歌曲構造を例示する図である。本発明の中で特定の好ましい実施例において、利用される典型的な好ましい音楽の生成フローの図である。本発明の中で特定の好ましい実施例において、利用される典型的な好ましい音楽の生成フローの図である。自動作曲プログラムの部分のためのインクルードファイルを生成するために楽曲の自動分析のための典型的な手順フローを例示する図である。本発明の好ましい実施例において利用される典型的な仮想音符／コントローラを例示しているテーブルの図である。本発明の特定の実施例に従って利用される音域（Ｔｅｓｓｉｔｕｒａ）原理を例示している線図である。本発明の特定の実施例に従って利用される音域（Ｔｅｓｓｉｔｕｒａ）原理を例示している線図である。本発明の好ましい実施例において利用される、オフセットとして楽曲キーの変化の符号化の原理を例示する図である。本発明の好ましい実施例に従う全体プロセスの部分であるモードアプリケーション楽曲ルールを例示する図である。本発明の好ましい実施例において利用される実際のパターンフローに対する典型的な好ましい仮想パターンを例示する図である。本発明のある実施例に従って利用される相対的なリズム密度の原則を例示する図である。本発明のある実施例に従う利用される音符ピッチの相対的な可動性の原則を例示する図である。本発明のある実施例に従うパターン構造作成実施例を例示する図である。本発明のある実施例に従うブロック構造作成実施例を例示する図である。本発明のある好ましい実施例において利用される擬似乱数発生実施例を例示する図である。本発明のある好ましい実施例において利用される擬似乱数発生実施例を例示する図である。本発明のある好ましい実施例に従って利用される単純なデータ構造の属性を例示する図である。図２９は、本発明のある好ましい実施例に従って典型的な単純なデータ構造フローを例示する；本発明のある好ましい実施例に従って利用される複合データ構造の属性を例示する図である。本発明のある好ましい実施例に従う典型的な複合データ構造フローを例示する図である。本発明によるプレーヤ及びドッキング局のある好ましい実施例の典型的なハードウェア構成を例示する図である。本発明によるプレーヤ及びドッキング局のある好ましい実施例の典型的なハードウェア構成を例示する図である。本発明によるプレーヤ及びドッキング局のある好ましい実施例の典型的なハードウェア構成を例示する図である。本発明のある好ましい実施例に従って利用されるマイクロプロセッサのための典型的なアドレスマップを例示する図である。本発明のある好ましい実施例に従って利用されるシンセサイザ／ＤＳＰのための典型的なアドレスマップを例示する図である。本発明のある好ましい実施例に従って利用されるＤＳＰブートストラップ／アドレス指定テクニックの活用法を例示する図である。本発明のある好ましい実施例に従って利用されるＤＳＰブートストラップ／アドレス指定テクニックの活用法を例示する図である。本発明の好ましい実施例を理解するためにＭＩＤＩの簡略論理的配列及び楽曲生成プロセスの音声流れを例示する図である。本発明の好ましい実施例を理解するために簡略ＭＩＤＩ及びオーディオストリームスケジュールを例示する図である。本発明のある好ましい実施例に従って並列ＭＩＤＡイベント及び音声サンプルのために非登録パラメータ番号（ＮＲＰＮ）の使用を例示する図である。本発明のある好ましい実施例に従って並列ＭＩＤＡイベント及び音声サンプルのために非登録パラメータ番号（ＮＲＰＮ）の使用を例示する図である。自動声音の特性を含んでいる本発明のある実施例に従って利用される典型的な好ましい手順フローを例示する図である。自動声音の特性を含んでいる本発明の特定の実施例に従って利用される典型的な好ましい他の手順フローを例示する図である。外部的に見ることができる、自動声音の特性を含んでいる本発明のある実施例に従って利用される典型的な好ましい携帯用楽曲生成装置を例示する図である。プレーヤ装置及び外部システム間の相互接続装置の典型的な好ましい実施例を例示する図である。ファイル形式と関連するある典型的な好ましい実施態様を例示する図である。ファイル形式と関連するある典型的な好ましい実施態様を例示する図である。ファイル形式と関連するある典型的な好ましい実施態様を例示する図である。本発明のある実施例に従って利用される、任意のヘッダ部を組み込んでいる音声サンプルデータファイルの典型的な好ましい実施例を例示する図である。本発明のある実施例に従って利用される、典型的な音声サンプル振幅グラフを好ましい重畳されたタイミンググリッドで例示する図である。本発明のある実施例に従って利用される、任意のヘッダ部を組み込んでいる音声サンプルデータファイルの付加的な典型的な好ましい実施例を例示する図である。本発明のある実施例に従って利用される、１以上の固有のフォーマット音声サンプルファイルと関連する別々の記述子ファイルの典型的な好ましい実施例を例示する図である。本発明のある実施例に従って利用される、音声サンプル分析法のための典型的な好ましい手順フローを例示する図である。本発明のある実施例に従って利用される、音声サンプル再生方法のための典型的な好ましい手順フローを例示する図である。本発明のある実施例に従った典型的な好ましい放送及びデータファイルの伝達を例示する図である。本発明の実施例に従って外部的に表示される、典型的な好ましいノード／加入者ユニットを例示する図である。本発明のある実施例に従ってノード／加入者ユニットにおいて利用される典型的な好ましい機能ブロックを例示する図である。本発明のある実施例に従った典型的な音楽データファイルと関連する典型的なパラメータデータを例示する図である。本発明のある実施例に従った好ましい楽曲生成プロセスの典型的な好ましい手順フローを例示する図である。本発明のある実施例に従って利用されるセルラデータ伝送／受信サービスと関連する典型的な通信規格について例示する図である。本発明の特定の実施例に従って利用される放送フォーマットの態様の好ましい実施例として、ＩＳ−６３７からの典型的な抜粋を例示する図である。本発明のある実施例に従って利用される、典型的な合成構造の第１の図を例示する図である。本発明のある実施例に従って利用される、典型的な合成手順フローを例示する図である。本発明のある実施例に従って利用される、典型的な合成構造の第２の図を例示する図である。従来技術の波形算出タイミングを例示する図である。本発明のある実施例に従って利用される、第１の典型的な波形算出タイミングを例示する図である。本発明のある実施例に従って利用される、第２の典型的な波形算出タイミングを例示する図である。ＭＩＤＩ音響バンクのトムドラム音と関連する従来技術の波形プロセスを例示する図である。ＭＩＤＩ音声バンクのトムドラム音と関連する波形プロセスのある典型的な実施例を例示する図である。ＭＩＤＩ音声バンクのフルート音と関連する従来技術の波形プロセスを例示する図である。ＭＩＤＩ音声バンクのフルート音と関連する波形プロセスのある典型的な実施例を例示する図である。ＭＩＤＩ音声バンクのピアノ音と関連する従来技術の波形プロセスを例示する図である。ＭＩＤＩ音声バンクのピアノ音と関連する波形プロセスのある典型的な実施例を例示する図である。サクソフォン音と関連する従来技術の波形プロセス及びＭＩＤＩ音声バンクのオーボエ音を例示する図である。サクソフォン音と関連する波形プロセス及びＭＩＤＩ音声バンクのオーボエ音のある典型的な実施例を例示する図である。

本発明を、好ましい、また他の実施例に関して、更に詳細に説明する。それは本発明の好ましい実施例の理解を進めるために役立つ。本明細書において記載されているように、さまざまな改良及びさまざまな実施例のさまざまな要素の置換が、ここで開示されている原理及び教示に基づいて可能である。

本発明によれば、多数の典型的な好ましい代替実施例として以下に記載されているように、楽曲を創作することができ（自動作曲によるものを含んでいる）て、相互作用することができ、再生（演奏）することができ、種々の新しい方法で実実現することができる。ここで使用されるトップダウンとは、まず開始点で、概ね良質な音楽のための完全な曲構造がエンドユーザのために創作されることを意味する。これは、システムによって提供される開始点に基づいて、楽曲を変更してそれによって新しい楽曲を創作する能力を有しているユーザについては、そのユーザが直ちに良質な音楽を創作できる状態にする。特定のユーザが楽曲生成プロセスをとる場所は、当該ユーザに依存する。汎用の楽曲生成プロセスはボトムアップの方法を含み、該方法では、各々の楽器と楽曲形式の基本を学び、そして個々の音符（ノート）がいっしょになったりする。この従来の方法は、一般に訓練された人々の小グループのみが楽曲を創作することができ、したがって、実際には、多くの人々が音楽の創作プロセスを行うことを妨げていた。

本発明の実施例を理解することのために役立つ類似は、住宅を建設することと同じである。住宅建設の従来の手段において、ユーザには多くのレンガ、釘、木及び塗料が与えられる。住宅を望むなら、電気的配線、配管、工学、その他と同様に、各々のこれらの機材でどのように建設するかの全ての複合を学ぶか、又は、これらの領域において訓練された人々を探す必要がある。同様に、音楽の作成で、歌曲（気持ちのよい）を望む場合、適宜の量の音楽理論と同様に、様々な形態の楽器（そして、各々のそれらのユニークな特質又は制限）についての全てを学び、特定の技術の熟知及び音楽（例えば、テクノ、ジャズ、ヒップホップ、その他）の所定形式の特性を得ることを必要とする。

誰かが住宅を望むときに、完全な住宅を容易に修正することができる（ボタンを押すことで）ならば、はるかに便利であろう。例えば、彼らは台所の中に入ることができて、直ちにそれを広くしたり、あるいは、異なる色にしたり、窓を追加したりすることができる。そして、彼らは洗面所の中に入ることができ、天井を上げたり、温水浴槽、その他を付け加えたりすることができる。彼らは、リビングルームの中に入ることができ、異なる塗料企画又は異なる家具スタイル、その他を取り入れることもできる。同様に、本発明の実施例によれば、ユーザは、望ましくは第一に完成された曲を提供され、一般から独特のものまでのさまざまなレベルで、ユニークな、そして、ユーザの願望、審美眼及び好みに沿った曲を創作するために、該曲を容易に修正できる。

本発明によれば、一般の人々は、直ちに音楽の作成への簡単なアプローチを提供される。それは完成された曲が得られたことの満足感を与える、その一方で、オリジナル曲を作曲することも可能である。音楽作成へのこのトップダウンアプローチは、楽しい音楽を創作することへの障壁を低減することによって、多くの人々に音楽の創造力の世界を開く。

本発明によれば、ユーザが楽曲を創作することを可能にするさまざまなシステム及び方法が提供される。この種のシステム及び方法は、望ましくは、利用する直観的かつ学習／使用が容易なユーザインターフェースを使用する。該インターフェースの使用により、創作途中の楽曲の創作及び相互作用を容易にし、既に創作された楽曲との相互作用を容易にする。

本発明の好ましい実施例によれば、望ましくは音楽の双方向生成を容易にするようにユーザインターフェース特性が具備される。そのようなインターフェースに関して、以下に提供される議論は、主に『プレーヤ』と呼ばれる携帯型の初心者用の装置の一つの実施例に集中している。しかしながら、この種のプレーヤと関連して議論される新しくて工夫に富む特徴の多くは、制御の視覚的拡張及び楽曲生成プロセスのアーキテクチャに関係する。したがって、それらは、音楽創作及び相互作用を許容する他のタイプの装置、例えば、計算機、ウェブサーバ／ウェブサイト、キオスク、ビデオ又は他の電子ゲーム及びその他娯楽装置に適用でき、このようにして、本発明の態様により効果を上げることができる。他のタイプの装置については、以下に説明される。当業者が理解できるように、プレーヤのユーザインターフェースのさまざまな特徴は、より幅広い範囲に適用できることは言うまでもない。

通常、ユーザインターフェースの目標は、同時に、システムの機能を保つと共に、最小限の数のボタンを有して、さまざまなパラメータを有するシステム及び相互作用の直観的、単純な操作を可能にすることにある。図１は、プレーヤ１０のための典型的なシステム構成を例示する。ディスプレイ２０は、ユーザに以下に説明するような視覚の情報を提供する。以下に記載されるように、種々のモードキー１６は、ユーザがシステムの動作モードを直接アクセスすることや開始することを可能にするボタンを提供する。以下に説明するように、ジョイスティック１５は、ユーザがさまざまな音楽の又はシステムパラメータ等を選択又は相互作用させることを可能にするために提供される。ユーザが創作し又はシステムを使って作ることができる曲又はパラメータの変更、その他を保存するために、そして、パラメータ、演奏リスト、サンプル、その他の編集を始めるために、記憶／編集キー１７が具備される。出力ボリュームレベルの調整を可能にするため、アップ／ダウン形式のデュアルボタンか、単一のノブ又はダイアルのいずれかの形態のボリュームキー１４が具備される。ファンクションキー１１は、演奏（ｏｋ）、停止（キャンセル）、送り（ｉｎｓｅｒｔ／ｃｒｅａｔｅ）、戻し（削除）及び記録のようなプレーヤ機能を可能にするために具備される。その典型的な使用の詳細は後述する。ＦＸキー１２は、ユーザが容易かつ直観的に楽曲（例えば特定のサンプル音）の部分の１又は複数の音響効果（例えばドップラー、残響、ウォブラー、カスタム、その他）を調整することを可能にするために具備される。ユーザによる直観的な音響効果選択を可能にする好ましい方法は、ＦＸキー１２をジョイスティック１５の左右コントロールと結合して使用することを可能にすることであり、直観的な音響効果調整（例えば、選択された音響効果の効果を増減する）を可能にする対応する好ましい方法は、ＦＸキー１２がジョイスティック１５のアップダウンコントロールと結合して使用されることを可能にすることである。以下により詳細に記載されているように、ピッチ／テンポの変動（好ましくは、ジョイスティックの動作とともに）ための単一ボタンの活性化を可能とするため、ピッチ／テンポキー１３が具備される。オン／オフボタン１８は、プレーヤをオン又はオフにするために具備される、そして、好ましくは、瞬時押圧／トグルが、ＬＣＤバックライトをターンオン／オフするために用いられる。但し、例えば、他のターンオフモードも、同様に使い得る（プレーヤが再生状態ではなく、所定のタイムアウト期間などで、検出される操作がなかったときの、タイムアウトターンオフ等）。図示したプレーヤ１０の実施例におけるこの種のボタン及びキーを典型的な望ましい使い方は、以下の説明により明らかとなるであろう。

好適な実施態様に従って、ホームモードが提供される。ホームモードは、プレーヤ１０がオンにされたときに、自動的に開始されるデフォルトモードである。図４の実施例は、ユーザが直接アクセスモードキー１６を押圧することによってモードを選ばせ、又は、ジョイスティックを押圧することによってヘルプモードに入る動画の画面を、ホームモードにおいて表示することを示している（図４は、無線アクセスキー操作を促す動画の瞬間を表す）。好ましい実施態様において、ユーザは、例えば、コンパニオンＰＣソフトウェアプログラム（詳細が後述される）を使用して、ディスプレイ２０に表示されるグラフィックスを定めることができ、異なる動作モードの間、デフォルトグラフィックスに代えて、自動的に置き換えられるべき（利用できるならば）グラフィックス（アニメ化又は非アニメ化されたもの）を選ぶことができる。特定の実施例においては、この種のグラフィックスの多数のセットがあってもよく、ホームモードが呼び出されるたびに、システムは異なるセットを選ぶことができる。カスタム画面のこの実施例において、曲及び／又は各動作モードの各楽節のためのカスタマイズされたスクリーングラフィックスに対応するデータファイルが、取り外し可能なメモリ手段（例えばスマートメディアカード（ＳＭＣ）のフラッシュメモリ）の記憶場所の歌曲データ構造（後述される）の一部として記憶される。好ましい実施態様において、ホームモードで、システム（例えば、モード／直接アクセスキー１６（第１図を参照）と関連するモード）で利用できるさまざまなモードによって、画面はスクロールする。さらに、プレーヤ１０は好ましくは他のいかなるモード（すなわち、ユーザがストップキーを押圧することで）の主メニューから、ホームモードまで戻るように構成される。ジョイスティックがホームモードで押圧されたときに、好ましくはヘルプ画面が表示され、ユーザにどのキーを押圧してもよいことを示す。ヘルプ画面の一例が図５に示される。この実施例においては、プレーヤ１０がこの画面を表示しているときにあるキーが押されると、そのキーに関する有用な文書が表示される。

ホームモードにおいて、Ｉ−Ｗａｙモード（後で更に詳細に説明する）と称した特に重要な視覚的インターフェースモードに入るために、再生が使われる。図６の実施例に示すように、好ましくはＬＣＤ画面が、「ｅ．ＤＪスタイル」のような他の可能なモードに関して、メッセージをステータス（状態）表示行に示すことができ、楽曲のスタイル／サブスタイル（例えば、テクノミックス、ハウス、ガラージュ、その他）の選択を提案する。この種の画面で、所望のスタイルを選ぶために、ユーザはアップ又はダウンを押圧することができる。この例では、大文字のスタイルは、好ましくは、各曲のためにランダムに選択されるサブスタイルのカテゴリを示し、サブスタイルが各々の大文字のスタイルを生じる小文字のスタイルによって示される。ユーザがスタイルを選ぶと、選択されたスタイルを有するＩ−Ｗａｙモードに入るために、ユーザは再生を押圧することができる。Ｉ−Ｗａｙモードが始まると、プレーヤ１０は自動的に選ばれたスタイルの曲を生成して再生を始める。好ましい実施態様に従って提供される典型的なスタイル／サブスタイルは、クールミックス（サブスタイルバラード、ボサノバ、ニューエイジ）、ヒップポップミックス（サブスタイルヒップホップ、ラップ、Ｒ＆Ｂ、ダウンビート、ラガ）キッチュ、テクノミックス（サブスタイルハウス、ガラージュ、トランス、ジャングル）、その他を含む。重要なことは、好ましい実施態様に従って、特定のスタイル／サブスタイル、その他に従う音楽の手早い作成とユーザ変更を可能とするために提供される直観的で使いやすいインターフェースを用いて、個別の楽曲スタイル（少なくともいくつかの楽曲スタイルは異なったサブスタイルを含んでいる）が決定されるということである。そこでは、結果として、特定のスタイル及び／又はサブスタイルの特性が、特定のスタイル／サブスタイルに従って楽曲の自動創作に適用される異なる楽曲ルールになる（楽曲ルール及び他のアルゴリズムの使用及び好ましい楽曲生成処理の詳細は、本願明細書において更に詳細に他の箇所で記述される）。追加の実施例において、音楽の審美性についてのより微細な階調の使用は、マイクロスタイルの形でユーザが利用できる。例えば、特定のサブスタイルにほぼ合致する複数のマイクロスタイルが提供される。その一方で、サブスタイルには一緒に、特定のスタイルにほぼ合致する１又は複数の他のサブスタイルが伴う。音楽の粒状性（ｇｒａｎｕｌａｒｉｔｙ）についてのこの第３の結合は、ユーザにアルゴリズム音楽の楽曲出力のより微細な制御を提供する。この種のマイクロスタイルは、おそらく、スタイル／サブスタイルのいくつかの柔軟性を失うが、より一貫した楽曲を提供する。重要であることは、ユーザが楽曲スタイルのカテゴリー化の複数のレベルを提供されるということである。基本的には、レベルが下降すると、ユーザ及び／又は自動作曲アルゴリズムなどによって変化させることができる楽曲のパラメータ範囲は、次第により制限され、選択される特定のスタイル、サブスタイル、スタイル、その他と整合される。

ホームモードの重要な特徴は、迅速且つ容易に楽曲を再生（演奏）を開始できるようにプレーヤ１０を構成する能力である。なぜなら、プレーヤ１０が対話的に構成され、多くの専門レベルの機能がスタイル及び音声のさまざまな態様を調整するために利用することができるが、ユーザにとって「押圧及び忘れ（ｐｒｅｓｓ−ｉｔ−ａｎｄ−ｆｏｒｇｅｔ−ｉｔ）」モードでプレーヤを使用するために、迅速且つ容易な方法を有することが望ましいからである。このようにして、極めて少ないボタンプッシュだけで、ほとんどあるいは全く音楽の経験のない、若しくはプレーヤ１０に接したことがほとんどあるいは全くないユーザであっても、容易に所望のスタイル又はサブスタイルのオリジナル楽曲を作曲し始めることができる。自動再生型の能力を提供する付加的な好ましい方法は、取り外し可能な記憶メモリ媒体（例えば、スマートメディアカード）を使用して、例えば、取り外し可能なメモリに存在する歌曲データ構造のリストを含んでいるファイル等の再生リストを記憶することである。この実施例にしたがって、ユーザが取り外し可能なメモリを挿入したり、すでに取り外し可能なメモリが挿入されているシステムに電源が投入されるとき、システムは取り外し可能なメモリを走査して、再生リストを含むこの種のファイルを探す。そして、システムファイルにリストアップされている歌曲データを演奏し始める。好ましくは、自動再生モードが選択（例えば、システムファイルの構成設定を経て）可能であるように、そして、システムが、異なるモードに入る機会をユーザに与えるために、自動再生を開始する前に短い持続期間を待つように、この装置は構成される。

図７Ａに示したように、Ｉ−Ｗａｙモードのための典型的な好ましい画面は、ハイウェイ又は多車線道路又は通路の視覚表示を運転しているか又は移動しているユーザの正面図を表す。画面の一番上に沿って、進行中のｅＤＪセッション（例えば、パート１、フィルタリングドラム、コーラス、パート２、＜＜サンプル名＞＞、その他）の現在部分又は状態を表示するステータスメッセージがある。好ましくは、より傑出してステータスメッセージを示すために、ユーザに表示する他の方法も用いることができる。例えば、システムは、ほぼ全ての画面に対応する大きい視覚インジケータを瞬間的に発光させることができる。演奏されている楽曲に合わせて波動しているスピーカの視覚の表示が、視界の直前にあることが好ましい。Ｉ−Ｗａｙの各々のレーンは、楽器レーン（ドラム、バス、リフ、リード）や、１又は複数のサンプルレーン（予め格納された声音、音響、その他のサンプルと対話するために）、又は、リアルタイムでマイク入力を管理する１又は複数のマイクレーンのような、楽曲の様々な形の要素を示す。本発明の範囲内のあるレーンのための他のカテゴリも設計することができる。本発明の本態様にとって重要であることは、ユーザに複数のレーンを含むマルチレーン視覚表示が与えられることであり、各々のレーンは、作曲されているか又は演奏されている楽曲の構成要素、効果、その他と一致する。ユーザは、表示の中心を移動するために、ジョイスティック１５を使用する（例えば、図１において示したように、一番上、一番下、左及び右の４つの領域において押し下げることができる円形のボタン）。通常、ジョイスティック１５の方向選択的な押圧は、対応する方向に表示の中心をシフトさせる。例えば、左のレーン及び右のジョイスティックボタンが押圧されるときに、表示の中心は１レーン以上右へ移動する。

別の実施例において、例えば図７Ｂに示すように、１節が、例えばリアルタイムで、そのレーンと関連する楽曲の構成要素の相対的な量を表す各レーンのために提供される。別の実施例において、対話用の追加レイヤは、Ｉ−Ｗａｙの付加水平レイヤによって示される。例えば、ドラムのためのＩ−Ｗａｙのレーンで（小太鼓、バス、フロアトム、ハイハット、クラッシュシンバル、ピングライドシンバル、ロト−トム、その他のような異なった楽器構成要素、ティンパニ、ゴング、トライアングル、その他のような打楽器）、各々のドラム又は構成要素、及び／又はドラム又は楽器音響の異なる態様のためのレーンについては、ドラム又は他の多様な構成要素をもつ楽器用の他のＩ−Ｗａｙに移動するために、ユーザはダウンキー押すことができる。このような多様なＩ−Ｗａｙインターフェースの概念が、ドラム又は他の多様な構成要素からなる楽器（他の楽器は単一Ｉ−Ｗａｙインターフェース、その他を維持しながら）等の手段から利益を受ける楽器だけのために、選択的に使われる。付加的Ｉ−Ｗａｙレーンの利用は、本発明の全ての利点を享受するのに必要ではなく、本発明のある使い方、例えば、より専門の用途のために適応させられる製品にとって、また、付加的なユーザインターフェース及び楽器制御の複合性が望ましい楽曲スタイル、例えば、クラシック音楽、又は、ジャズにとって望ましい特徴である。

Ｉ−Ｗａｙモードにおいては、画面は、好ましくは楽曲拍子に同期した音波又は波動で動画化される。図７Ａの実施例において、丸いスピーカの視覚表示は、現在レーンの相対的な量を象徴するために、中央に図示される。この視覚表示は、レーンがミュートされたとき、消えるか又は他の方法で変えられるように構成される。その特定のレーン／楽節の相対的な量が調整されるにつれて（例えば、ジョイスティックアップダウンボタンと組み合わせたファンクションキーを用いて）、より大きく又はより小さくなるように構成することができる。他の単純なバリエーション、例えば、各レーンにおいて同時に見える音量計、各レーンにおいて同時に見えるミュート表示、そのレーン、その他によって示される楽器を視覚的に思い出させる各レーンの画像等もの、本発明の範囲内である。

Ｉ−Ｗａｙモードのような自動作曲モードにおいて、ＣＤ上の又はラジオから実際の歌曲におけるような音を鳴らすようにするのは、歌曲進行を決めるプレーヤ１０である。それは、楽器を自動的に加えたり除外することができ、楽曲休止、ドラム進行、コード進行、フィルタリング、変調を行ったり、楽曲と同期してサンプルを再生（演奏）し、ルール及びその他に基づいて演奏するためにサンプルを選択することができる。２、３分後に、何もユーザによってされない場合、プレーヤ１０はボリュームの自動フェードアウトで楽曲を停止し、同じスタイル又はあるいは、異なるスタイルの新曲を、自動的に作曲して演奏するように構成される。また、Ｉ−Ｗａｙモードは、プレーヤ１０を使ってユーザが創作／修正し、そして後の再生等のために、プレーヤ１０に格納された楽曲等（それは、自動作曲を部分的に用いて創作されたものでもよい）の、自動作曲しない楽曲にも好ましい実施態様で適用できることを理解すべきである。

ある実施例では、新しく生成されたパターンに１〜ｎまで番号をつける。この番号は、ユーザが彼／彼女が好きである楽曲パターンを記憶しているのを助けて、他の２、３のものを試用した後に元のものに戻るためにステータス線を付けて示すことができる。ある実施例において、この番号は、与えられた歌曲内部で、そして、現在の対話的セッションの間だけ有効である。すなわち、例えば、作曲されている現在の歌曲のためのリフパターン番号５は、他の曲において構成されるリフパターン番号５とは同様に聞こえない。しかしながら、この曲がユーザ歌曲として保存される場合、後に再演奏されるときにリフ楽曲が同じものであっても、それに関連する番号を異ならせる。

一つの典型的な実施例において、プレーヤ１０は、現在の対話型セッションの間に予め作曲された最高１６のパターンを「記憶している」。例えば、これは、表示される現在のパターン番号が２６である場合、ユーザが前に作曲されたパターン（本実施例において、パターン１〜９は上書きされているか又は一方破棄されている）を順次閲覧することによって、番号１０〜２５のパターンを聞くことができることを意味する。ユーザが現在演奏されている所定の作曲パターンをスキップしたい場合、それが可能であり、そして、パターン番号は増加しない。これは、現在演奏されたパターンが失われることを意味する。この特徴は、ユーザ要求により、前に演奏された複数のパターンの特定のパターンだけを記憶するために用いることができる。重要なことは、ユーザの特定の好み、要求、又はその他に基づいて、ユーザによって決定される楽曲を作曲するために用いる格納されたパターンを用いて、ユーザが楽曲パターンを創作し、選択的に格納する（いくつかの所定数の楽曲パターンまで）ことができるということである。Ｉ−Ｗａｙモードによって表される画面は、プレーヤ１０によって生成／演奏される楽曲をユーザが作成しかつ対話したり、そして変更したりするのを容易にすることが望ましい。

ある好ましい実施例において、必要に応じてユーザによって、Ｉ−Ｗａｙモードの特定レーンと関連する楽器の付加楽曲パラメータは、ユーザが「見ること」ができかつ対話型である。例えば、Ｄｏｗｎ（ダウン）が押圧される場合（例えばジョイスティック１５を経由して）、Ｉ−Ｗａｙモードの間、画面の中央は、特定のレーン（例えば、図８Ａ参照）の「内部」に対して、「地下」としてとらえられる。このような「地下」モードへの移行は、より好ましくは、床を下方に貫通する観点又はＩ−Ｗａｙレーンの床又は底を貫通して、そのレーンによって示される楽曲の構成要素と一致する特定レーンの下のトンネルの視覚表現であるように見えるものまでの下方の画像ポイントの動きを表している画面動画を構成することによって、視覚的に魅力があるようにされる。ある実施例において、視覚のこの種の移行には、好ましくは音のフィードバック（例えば、トンネルモードの開始／終了という警報をユーザに出す音）が伴う。ある実施例において、例えばユーザ定義可能な構成パラメータに応じて、この種の音のフィードバックが『保存された』音楽作品の一部として記録されないことはが望ましい。このように、ユーザインターフェースは、創作されている歌曲を必ずしも実行せずに強化される。特定レーンの下のトンネル内で、パルス指示（スピーカパルスと同様の）がＩ−Ｗａｙセッションのテンポに合わせて生じる。さらに、トンネルの左右の壁は、左右の音響チャネル出力の波形を示すために用いることができる。あるいは、この種の波形効果の代わりに、ある実施例では、左右の音響チャネル出力に伴う棒グラフを提供することが望ましい。例えば、図８Ｂはそのような実施例を例示する。さらに、これらの実施例において、ディスプレイが必ずしもオーディオ出力と一致しない場合であっても、この種のグラフィックディスプレイを提供することが望ましい。例えば、利用できる処理資源がリアルタイムで音響を正確かつ詳細にグラフ化／図表化する能力をもつ余裕がない実施例では、音響の近似は、それがより直観的なユーザインターフェース経験をユーザに提供するので、有利である。

ある実施例において、圧力フィードバック機構（図２９と関連して後述する）を提供することが好ましい。あるの実施例において、圧力フィードバックイベント（例えば、携帯用装置の振動）を楽曲（例えば、バスドラム）の音波の特性に同期させることが好ましい。ある実施例において、すなわち、ユーザのＧＵＩ経験の一部として、視覚の移行を有する圧力フィードバックイベントを視覚の遷移に同期させることが好ましい。例えば、Ｉ−Ｗａｙモードからの地下モードへの遷移には、圧力フィードバックイベントにより実行することができる。

トンネルの遠端は、その特定レーンの音響に影響を及ぼしている１又は複数のパラメータの値に相関して変動することができる形状（例えば、長方形又は幾何学的なその他）から成る。例えば、ドラムの場合、フィルタパラメータは、ジョイスティック上方又は下方ボタンに加えて、機能又はＦｘボタン（図１を再び参照）を押し下げることによって、変化させることができる。この時に、トンネルの端を含んでいる形状は、形状を変化するか、視覚的に離れてより遠いかより近くなるように見える。他の例では、ギターのピッチは、左又は右のジョイスティックボタンに加えてピッチキーを押圧することによって調整することができ、同時に、ピッチパラメータ値が増加するか又は減少するとき、形状を多少傾斜させることができ、あるいは、丘を登っていくか又は丘を下って行っているトンネルの視覚の表現が、視覚的にピッチの増加又は減少を示すために提供される。他の実施例において、右／左又はステレオバランス型効果を変化させるために、ジョイスティックボタンの左／右又は上／下操作に加えて、あるモードのシステムのパラメータを変えるよう機能ボタンすなわちＦｘボタンが押圧される。この種の入力は、例えば、音響バランスを左チャネルよりも右チャネル寄りにする（右へ曲がるトンネルの視覚表示を伴うか、逆に左チャネルへシフトする音響バランスを表すかして）か、又は、より広いかより狭いステレオ効果が要求される場合、その幅において、より広いか狭くなるようなトンネル開口を表すことができる。しかしながら、形状又は他の視覚効果が、ユーザ入力、音響を効果づける１又は複数のパラメータとの相関においてどのように変調され得るかについては、いくつかの例がある。重要であることは、ユーザが特定の楽器レーンに「トンネルを掘る」ときに、楽器と関連するさまざまなパラメータが、ユーザに提供される視覚表現における変化を伴う少なくとも一定のパラメータの変化（例えば、形状、サイズ、色（色表示実施例のために）又は示された視覚表現の動き）を持って、ユーザによって変えられることである。

地下モードでは、ユーザがジョイスティック及びプレーヤ１０の他のボタンを使用する特定の要素（例えば、ドラム）と対話し、修正することができる間、プレーヤ１０は同じ楽曲のシーケンスによって繰り返し実行され続けるように構成される。また、特定の構成要素に対応するレーンにおける間、好ましくは、ジョイスティックの左右のボタンは、一つの構成要素パラメータから他方に動かすために用いることができる。あるいは、横から横へのジョイスティック移動は、例えば、ユーザが一連の予め設定された特性又はパラメータで進むことを可能にする（すなわち、単純なジョイスティックタイプユーザ入力については、ユーザは、特定の構成要素のさまざまなパラメータを変化させることができ、この種のパラメータ変化と関連する音楽効果を聞くことができ、特定の時等で、ユーザによって要求される特定の楽曲のための望ましい特性を決定することができる。）。さらにもう一つの変形例において、横から横のジョイスティック移動は、例えば、画面に一つのトンネルから隣接したトンネル等までシフトさせることができる。全てのこの種の変形例は、本発明の範囲内である。

他の類似した変形に加えて、ユーザはストップ（停止）キー（図２に示す）を用いて、Ｉ−Ｗａｙモードの特定レーンを好ましくはミューティングすることができる。これに例において、レーンがミュートされる間、「ミュート状態」がステータスバーにおいて示され、そして、丸いスピーカは消える。この種の実施例によれば、ユーザがストップキーを再び押圧することによって、楽器を非ミュート状態にすることができる。

ユーザインターフェースの望ましいバリエーションは、新しい歌曲部に対応して、好ましくは視覚の外観への変化を動画化することを含む。例えば、図８Ａに示される地下モードにおいて、又は図７Ａに示されるＩ−Ｗａｙモードにおいて、コーラス部分に対する移動は、解放ドア部を通しての移動により行われる。その歌曲の所定の楽章（例えばコーラス、イントロ、ブリッジ、終章、その他）に対応するグラフィック動画を、その歌曲の間でその楽章が演奏されるたびに使うことができる。遷移の実施例は、以下の通りである。ユーザを１セットの視覚的特性を有するトンネルから出入り口から通過させ、視覚特性の第２の一組を有するトンネルに至らしめる。他の実施例は、ユーザを遷移入り口を通してあるトンネルからより広いトンネル、又は開いた領域へ移動させることである。本発明の本態様の好ましい特徴は、歌曲部分の間で楽曲遷移に密接に結合される動画遷移を調整することによる利用経験を、ユーザに提供することである。

ある別の実施例においては、楽曲の構成要素の特定態様を編集するために、直観的なインターフェースを提供している所定レーンと関連する各レイヤで、図８Ｃに示されるように、トンネルの多数のレイヤを提供することが好ましい。これらの実施例において、特定のトンネルレイヤを経て編集可能な関連した態様を有する隣接レーンがある場合、図８Ｃの水平矢印で示されるように、隣接したトンネルの間でユーザが直接移動することを可能にすることが好ましい。

Ｉ−Ｗａｙ及び地下概念の変形例を、本発明によって使うことができる。例えば、ユーザインターフェースは、現在の歌曲にある楽器を視覚的に表し、ユーザがその一つを選んで、トンネルすなわち特定の楽器のパラメータが調節されるレベルにはいることを許容する。この例では、楽曲が演奏される間、楽曲に合わせて視覚的なパルスを発している作動中の楽器により、ユーザインターフェースは現在の歌曲における楽器の視覚の表現を提供する。図１３Ａは、この種のユーザインターフェースの実施例である。この種の実施例によれば、ユーザは楽器（例えば、ジョイスティック１５又はファンクションキー１１を有する）の特定の視覚の画像を選ぶことができ、その楽器の使用状態に入ることができる。例えば、震動しているドラムセット２５を選ぶことによって、ユーザは他のレベル、例えば、それが現在演奏されていることを明らかにしているドラムを有する図８Ａに関して上述された地下モードに対応するレベルに入ることができる。そして、音響効果及びドラムトラックと同様に、ドラムの異なる態様をユーザは選びかつ変化させることができる。図１３Ａに示されるような他の楽器をユーザが選んだ場合、その特定の楽器トラックのパラメータを同様に変えることができる画面にアクセスすることになる。したがって、ユーザインターフェース用の代替テーマの使用は、本発明（特に、実際の楽器があたかもステージ上にあるように表されるテーマ）によって、有利に使用される。

この種の実施例の特定の実施例として、図１３Ｂは３Ｄステージを表す。この種の実施例においては、初心者の感覚でそのステージ上での試行をユーザに許容することが好ましい。ユーザは、直感的に移動することを許容される。すなわち、３Ｄディスプレイは、ユーザが移動すると、そのステージ上でユーザの視覚的見方を反映するために更新される。例えば、ＱｕａｋｅＩＩＩＡｒｅｎａ（ＩＤＳｏｆｔｗａｒｅから入手可能な）のような周知のコンピュータビデオゲームで、この第１の効果を達成する技術はがく使用されている。ユーザは、所定の楽器の方へ進むことができて、その楽器によって示される楽曲の構成要素のパラメータを調整することができる。例えば、バスコンポーネントの場合で図１３Ｂの実施例の場合、ユーザはそのステージ（例えば、図１３Ｂに示される３Ｄのステージ左手に表されるキャビネット）上のバス増幅器及びキャビネットの方へ進むことが可能である。バス増幅器の近くに移動すると、即座に、３Ｄボタン及び／又はスライダは、ディスプレイに拡大されて、実際のバス増幅器の制御がバスギターの音響に影響を与える方法と同様の方法で、楽曲コンポーネントの音波の制御をすることができる。このように、ユーザは、好ましくは楽曲演奏の視覚的態様を模する直観的なＧＵＩを提供される。その結果、音波特性の制御を、より直観的に行うことができる。

ある実施例において、２つの又は多数のタイプのユーザインターフェースが提供される、そして、ユーザは、図７Ａに示されるようなＩ−Ｗａｙタイプのユーザインターフェース、又は、楽器グループ又は他のタイプのインターフェースを選択することができる。重要であることは、楽曲を創作するために用いる楽器を視覚的に理解するために、好ましい実施態様のユーザインターフェースが直観的で使いやすい方法を、楽曲創作経験のほとんどないユーザに提供することができるということであり、そして、特定の楽器と関連するパラメータ及び効果をユーザが変更することができるモードにアクセスする視覚的方法を提供することである。これは、変更されたパラメータ／効果、その他と一致する視覚の変化を伴う。

加えて、ある好ましい実施例においては、外部ビデオディスプレイデバイス（例えば、コンピュータモニタ、テレビ、ビデオプロジェクタ、その他）が、演奏されている楽曲に対してより精巧な視覚的伴奏を表示するために用いられる。そのような場合、Ｉ−Ｗａｙグラフィック表示は、好ましくは図７Ａ（例えば、カラー階調及び／又はドット／インチに関するより高い解像度イメージ）に示されるＩ−Ｗａｙのより詳細な演出である。アーティスト特定の楽曲（例えば、本明細書の他の箇所で論じられているように）を含むことができる実施例において、ビデオ出力はアーティストによってリリースされる音楽ビデオであってもよい。この種の実施例において、リリースされた形式（例えば、不変の）で、あるいは、本発明の他の特徴（例えば、複合な／単純なデータ構造と関連する特徴、ＰＲＮＧルーチン、楽曲ルール、声の相互作用、その他）を組み込む形式で、そのアーティスト楽曲を含むことが好ましい。この方法では、好ましくはある程度のユーザ対話性をもって、ユーザは、音楽ビデオを見ることができ、かつそのアーティストの楽曲のミキシングし直し可能なバージョンを聞くことができる。ある実施例において、ユーザインターフェースは、音声／視覚のリモートコントロール入力装置であってもよい。例えば、それは音声構成要素又はテレビを作動するために用いてもよい。このような実施例では、ユーザがアーティストの音楽のミキシングし直し可能なバージョンと対話することができるように、リモートコントロールのボタンを用いることが好ましい。例えば、この開示の全体にわたって論じられるユーザインターフェースの特徴は、リモートコントロールインターフェースとの使用に適合していてもよい。これらの変形の態様は、更に詳細に本明細書の他の箇所で後述される。

ある好ましい実施例において、「Ｐｌａｙ（演奏又は再生）」を押圧することは、好ましくはレーン楽器に「強制」モードに入らせる。その楽器のレーンがアクティブなときに、再び「Ｐｌａｙ」を押して「強制」モードが終了されるまで、プレーヤ１０にいつまでもこの楽器パターンを演奏することを強制するために、これを具備することができる。この場合、「Ｆｏｒｃｅ（強制）」モードが選ばれると、楽器が鳴っていない場合、プレーヤ１０は自動的に楽器パターンを作曲し、直ちにそれを演奏するように構成され、現在のシーケンス（例えば、２小節）終了後に起動することができる。加えて、比較的長い期間（例えば、１秒以上）「Ｐｌａｙ」を押圧すると、楽曲を休止することができ、その時、「Ｐａｕｓｅｄ（ポーズ又は休止）」メッセージをステータスラインにおいて点滅させる。

他の好ましい実施態様で、この種の「強制」モードが必要でない場合（例えば、単純性及び／又はある特定の楽曲のために必要とされないかもしれないという理由で）、「Ｐｌａｙ」を短時間押し下げすることによって「休止」状態を生じさせても良い。この種の休止は、好ましくは「休止」メッセージをディスプレイ２０に現れさせて、楽曲の時間内で歌曲とともに始まりそして終わるように、好ましくはリズミカルに量子化される（例えば、最も近い四分音符（ノート）に対してリズミカルに端数切り上げ又は切り下げ）。

「Ｓｏｌａ（独奏）」モードにおいて、他の全ての楽器は音を消され（すでに「独奏」モードにあってもよいそれらを除いて）、この楽器だけが鳴っている。「独奏」のモードは、「Ｐｌａｙ」ボタンを押し下げことで「独奏」モードに入って楽器がすでに演奏しているなら、特定の楽器用のトンネル又は他のレベルに入ることによって可能にされる（例えば、楽器が「強制」演奏状態にあり、そして、地下モード下の「Ｐｌａｙ」ボタンの次の押し下げにより、その楽器のための「独奏」モードを始める；典型的な「独奏」モードへの特定のキーエントリ）。対応するトンネルを出て、楽曲Ｉ−Ｗａｙに戻るときに、楽器は独奏のままである。「独奏」モードから抜けるには、ユーザはまた対応するトンネルに再び入らなければならない。また、ある実施例では、異なるトンネルに入り、「独奏」モードを可能とすることにより、一つずつ又は同時に、あるいは効果的な独奏モードになることによって、いくつかのトラック独奏できるように、「独奏」モードの多数のレベルが可能である。加えて、ある実施例では、長時間（例えば２秒）「Ｐｌａｙ」ボタンを押すことによって、レーンの期間中、ユーザがＩ−Ｗａｙから「独奏」モードに入ったり／抜け出したりしないようにしたりすることができる。この実施例によれば、「独奏」モードを動作をさせないことにより、手動ですでにミュート状態にある（「独奏」モードが起動される前に）いかなるレーンも、ミュート状態を保持する。

好ましくは、サンプルメニューから、異なるサンプルパラメータを編集することができる。サンプルメニューから、ユーザは、音声、楽曲又は音響サンプルに対する効果を記録することができ、演奏することができ、変更することができる。このメニューも、サンプルリストの作成及び編集を許容する。ＬＣＤは、好ましくはステータスラインに「ｅ．Ｓａｍｐｌｅｓ」を、そして、そこから選択される記憶媒体（例えば、図３２と関連して論じられるスマートメディアカード）中の利用可能なサンプル又はサンプルリストを表示する。

サンプルを再生するときに、ＬＣＤは演奏サンプル画面を示す。サンプルの名前は、ＬＣＤの中央右部のバナーにおいてスクロールされ、同時に、オーディオ出力レベルがその名前周辺で比較的大きいフレームによって示される。ステータスラインは、好ましくは現在の効果を示す。

ユーザ曲のためにＭＩＤＩファイルと同様に、サンプルセット又はリストが好ましくは「ｅ．ＤＪ」によって使われる。ＭＩＤＩファイルの場合、コンパニオンＰＣソフトウェアプログラム（例えば、Ｃａｋｅｗａｌｋのようなソフトウェアプログラムを編集している標準のＭＩＤＩ）は、ユーザが自分自身のＭＤＩファイル（必要に応じて）を編集することを可能にし、特定のタイミング位置でサンプルを演奏することを可能とするためにＭＩＤＩ非登録されたパラメータ番号ＮＲＰＮ（詳細に後述する）を使用することを可能にする。この実施例によれば、コンパニオンＰＣソフトウェアプログラムは、ユーザがＮＲＰＮを用いてサンプルをＭＩＤＩデータに挿入することを許容する。新しいｅ．ＤＪ歌曲が創作されるときに、プレーヤ１０は既存のサンプルリスト（好ましくは楽曲の特定のスタイル／サブスタイルを伴うサンプルセット）から１つを選択して、それから歌曲の適当な時間（以下に記載されているように、好ましくは疑似乱数発生に基づいてアルゴリズムで決定される）に、このリストのサンプルを演奏する。ユーザ歌曲を創作するか又は編集するときに、ユーザはこのユーザ歌曲に好ましくはサンプルリストを関連させることができる。その後、このリストのサンプルは、適当な時点で自動的に歌曲に挿入される。各サンプルリストは、ｅ．ＤＪ楽曲スタイル／サブスタイルを伴うことができる。たとえば、テクノスタイルを演奏するときに、テクノスタイルと関連するリストは、テクノユーザ歌曲によって又はｅ．ＤＪによってのみ使うことができる。変形例おいて、ユーザは、後述するＮＲＰＮを介して、特定のサンプルが歌曲において演奏される特定タイミングを特定することができる。特定のサンプルのこのタイミング仕様は、コンパニオンＰＣソフトウェアプログラム（例えば、Ｃａｋｅｗａｌｋのような標準のＭＩＤＩ編集ソフトウェアプログラム）の使用及び／又はプレーヤ１０上のテキストインターフェースメニューによって、ユーザにより示される。

新しいサンプルリストは、デフォルト名称（例えば、サンプルリスト００１）で好ましくは創作される。リストは、システム−ファイルメニューで、名称を変ることができる。選択された項目がサンプルであるときに、現在の効果がステータスラインに示される。選択された項目がサンプルリストであるとき、「Ｌｉｓｔ（リスト）」がステータスラインに表示される。

圧縮音声、ＭＩＤＩ、カラオケ及びユーザ歌曲（例えば、保存されたｅ．ＤＪ歌曲）の再生は、「歌曲」モードにおいてアクセス可能である。歌曲は、順番に歌曲のプログラム（連続）を行うために、いわゆる演奏リストにおいて集めることができる。ＬＣＤは、好ましくはステータスラインに「ｅ．Ｓｏｎｇｓ」を表示し、選択するために、スマートメディアカード上の利用可能な歌曲のリスト又は演奏リストを表示する。

歌曲（例えば、ユーザ歌曲、ＭＩＤＩ又はＷＭＡ）のタイプに従い、異なるパラメータが編集される。現在の選択のタイプは、ステータスバーに、例えば、ＷＭＡ（ＷＭＡ圧縮音声のために）、ＭＩＤ（ＭＩＤＩ歌曲のために）、ＫＡＲ（ＭＩＤＩカラオケ曲のために）、ＭＡＤｘ（ユーザ歌曲｛テクノスタイルのためのｘ＝Ｔ、ヒップポップのためのｘ＝Ｈ、クールのためのｘ＝Ｋ、その他｝のために）及びＬｉｓｔ（演奏リストのために）等のように表示される。

歌曲の名称は、ＬＣＤの中央右部のバナーにおいて好ましくはスクロールされ、同時に、オーディオ出力レベルがその名称周辺で比較的大きいフレームによって示される。歌曲がカラオケ曲である場合、歌詞はＬＣＤの底で２行（又は他の数）に表示される。動画フレームは示されない。歌曲がユーザ歌曲（すなわち、ｅ．ＤＪによって作曲されて、「保存」／「編集」ボタンを使用して保存された）である場合、楽曲Ｉ−Ｗａｙモードが演奏歌曲モードの代わりに開始される。

その後、編集スクリーンが示され、左右の２つのカラムが表示される。左カラムは、編集可能なパラメータ又はオブジェクトを項目にリストにし、右カラムは、これらのパラメータの現在値を示す。例えば、演奏リスト編集スクリーンは、左側上にスロット番号及び右面上に歌曲名を表示する。現在の対象が、リバースビデオにおいて強調される。

演奏リストは、歌曲番組を創作するために用いられる。新しい演奏リストは、デフォルト名称（例えば演奏リスト００１）で創作され、ユーザによって名称変更することができる。リストが選ばれて、歌曲選択された画面で演奏されるとき、リストに載っている第１の曲の演奏が開始される。歌曲終了後、リストの最後に達するまで、次の歌曲が始まる。リストにおける終了インストラクションが最終リストである場合、プログラムは停止し、そして、プレーヤ１０は歌曲選択スクリーンに戻る。終了インストラクションがループリストである場合、第１の曲が好ましくは再び始まり、ユーザが、例えば停止ボタンを押すことによって演奏している曲を中断するまで、プログラムは繰り返し実行される。

本発明の実施例において、従来のラジオの特徴が、本発明のユーザインターフェース（例えば、図３２のＦＭ受信機５０を参照）に、効果的に組み込まれる。例えば、「ラジオ」モードにおいて演奏するときに、ＬＣＤはラジオ画面を示す。ＬＣＤは、選択する有効局プリセットのリストと同様にステータスラインの「ラジオ」を表示する。プリセットがされていない場合、現在調整された周波数だけが表示される。ラジオ局の名前（又は、保存されたプリセットでない場合は周波数）は、ＬＣＤの中央右部のバナーにおいてスクロールすることができる。電波を示している動画もまた表示してもよい。ステータスラインにおいて、好ましくは調整された周波数を示す。この種の実施例において、プレーヤ１０は、従来のラジオ装置として動作することができる。

好ましい実施態様において、異なるスタイルの仮想局については、ラジオ−タイプ機能性は、同タイプのラジオインターフェースの使用を含む。各バーチャル（仮想）局は、特定のスタイル又はサブスタイルの１又は複数の連続的楽曲を生成する。この「Ｖ．Ｒａｄｉｏ」モードにおいて、ユーザは局を選局し、そして、実際のラジオを用いずに、連続楽曲を聞くことができる。この種の装置は、可聴広告、その他の負荷なしで、種々の音楽を聞くことを提供することができ、ユーザにより、演奏される楽曲のスタイルを大幅に制御することが可能となる。このような実施例では、ユーザは、「ｖ．Ｒａｄｉｏ」モードにおいて、「ｖ．Ｒａｄｉｏ」局（好ましくは、特定のスタイル又はサブスタイルの楽曲を演奏している）のリストを提出される。ユーザは、該リストから、チャネルを選び、「Ｐｌａｙ」を押すことにより、好ましくは「ｖ．Ｒａｄｉｏ」チャネルに同調させる。例えば（例えば、図１０を参照）、それは、プレーヤ１０に特定の「ｖ．Ｒａｄｉｏ」チャネルに従って歌曲を自動作曲しかつ演奏するのを開始させる。ある実施例において、「ｖ．Ｒａｄｉｏ」は、特定のｖ．Ｒａｄｉｏチャネルに伴う特定のスタイル又はサブスタイルのユーザ歌曲を演奏するために制御することができる。そして、それはサブスタイルの特定タイプの自動作曲された歌曲と混在することができる。さらに他の実施例において、１又は複数の「ｖ．Ｒａｄｉｏ」チャネルは、複数のスタイル又はサブスタイルのより多くの楽曲を演奏するように提供される。それはまた、さまざまなスタイル又はサブスタイルのユーザ歌曲と混在することができる。この種の実施例において、ユーザは、プレーヤ１０が「同調」するｖ．Ｒａｄｉｏチャネルの特定のタイプを選ぶオプションが提供される。その上、ある実施例では、「ｖ．Ｒａｄｉｏ」モードは、好ましくは種々の異なる歌曲フォーマット（例えば、ＭＰ３、ＷＡＶ、ＷＭＡ、ｅＤＪ、その他）を演奏するために用いることができる。

ある実施例において、ラジオ機能の変更例が、ラジオの他の態様を有する「ｖ．Ｒａｄｉｏ」のいくつかの態様を有している。一つの例として、ユーザはラジオ局からの放送を聞くことができる。コマーシャル中断が入って来るときに、プレーヤ１０は「ｖ．Ｒａｄｉｏ」に切り替わる。それから、その後、実際の楽曲が放送されたときに、装置がラジオへ切り替えられる。他の統合は、選択可能なインターバルで、ラジオからのニュース情報を「ｖ．Ｒａｄｉｏ」音楽の間に入れるということである。例えば、米国において最も公共のラジオ局は、朝及び午後の間に１０分ごとにニュース、天気及び交通情報を扱っている。「ｖ．Ｒａｄｉｏ」は、仮想ラジオとして、そして、適切に選択されたインターバルで動作するように構成することができ、ニュースを流すために一般の局へ切り替える。その後、「ｖ．Ｒａｄｉｏ」モードへ切り替えをすることができる。ユーザがラジオでより多くの制御をすることができるが、まだ受動的に聞いているという点で、これらのバリエーションは、新しいリスニング経験の機能を提供する。本明細書で論じられるように、この種の装置には市販アプリケーションの多数の用途があると考えられる。

特殊機能は、システムメニューからアクセスすることができる。これらの機能は、スマートメディアカード（改名称、削除、コピー、リスト、属性変更）（例えば、図３２に関連して、この種のスマートメディア又は記憶媒体の他のフラッシュ／メモリ／ハードディスクタイプの使用が論じられる）、プレーヤ構成（自動演奏、パワーオフ、遅延、キーパッドオートリピート、言語、その他）、ファームウェアップグレード、スマートメディアカードフォーマッティング、マイク設定値及びイコライザユーザプリセット上のファイル管理等を含んでいる。プレーヤは、好ましくはスマートメディアカードに記憶されるファイルのさまざまな属性を変更することができる。予防措置として、デフォルトで、全てのシステムファイルは、読出し専用として好ましくはセットすることができる。

ある実施例において、ユーザコンフィギュレーションインターフェースは、ユーザが取り外し可能なメモリ媒体（例えば、ＳＭＣ）上の歌曲データとともに記憶される名称を入力し、及び／又はユーザがカスタム等化設定及び／又は音響効果を定めることを可能にする。ＥＱ設定値の実施例として、一群の工場プリセットイコライザ設定値（例えば、フラット（例えば、ＥＱ効果なし）、標準（例えば、より低くてより高い周波数のわずかなブースト）、ウーフ（例えば、低音周波数ブースト）及びハイテク（例えば、高周波数ブースト））からユーザが選ぶことを可能にすることが好ましい。この種の予め設定されたＥＱ設定値に加えて、ユーザがＥＱ（例示として、ジョイスティックにより各々の４つの帯域を調整する能力を有する４帯域ＥＱ）のための自分自身の所望の設定値を定めることを可能にすることが好ましい。その上、ある実施例では、ユーザが同様に特定のサンプルのために使用される音響効果をカスタマイズすることを可能にする。この実施例によれば、一組の標準の工場プリセット音響効果（例えば、「低音」；ユーザがより低い音声とともに歌うことを可能にするためにより遅い速度及びより低いピッチを有する歌曲を演奏する）、残響、「高音」（例えば、より速い速度及びより高いピッチを有する歌曲を演奏する）、ドップラ（例えば、「高音」から「低音」まで音声を変化させて）及びウォブラー（例えば、効果を有するいくつかの音声をシミュレーションして））に加えて、レベル及び／又はパラメータ値を変化させることで、標準効果のさまざまな組合せを組み込むことをユーザが利用できる、カスタマイズされた機能を生成することが好ましい。さらに、ある実施例において、追加のフィルタ、及び／又は、例えば、ＡＭラジオ局のイコライゼーション（等化）をシミュレーションする「ＡＭラジオ」効果のために、イコライザを使用することが好ましい。

ユーザが「ｅＤＪ」モードにおいて演奏されている歌曲を保存するときに、その歌曲はデフォルト名称（例えば、テクノ００１）で好ましくは創作される。歌曲は、システム−ファイルメニューで、好ましくは名前を変えることができる。ファイルメニューに入るときに、スマートメディアカード及び自由なメモリサイズに存在するファイルは、編集画面フォーマットでリストアップされる。ステータスラインは、ファイルの数及びメモリの使用量を示す。ファイル管理メニューは、選択されたファイルに実行するために動作の選択、すなわち、削除、名称変更、コピー、属性変更、その他を提供する。現在のファイルの名称は、ステータスラインに示される。加えて、ある実施例においては、システムパラメータファイルの使用を可能にする。それらのファイルは、例えば、ラジオプリセット（例えば、ラジオ局名及び周波数）、ＷＡＶ、ＷＭＡ、ＭＰ３、ＭＩＤＩ、カラオケなどのような楽曲ファイルと関連するパラメータ（例えば、ピッチ、テンポ、音量、残響、その他）のための設定値を含む。これらの実施例において、パラメータ設定が全ファイルにあてはまることが好ましい。

コンフィギュレーションメニューに入るとき、編集画面はさまざまな可変なパラメータを示して表示される。図１４は、可能な値とともに、コンフィギュレーションメニューによってコンフィギュレーション可能であるいくつかのパラメータを記述する。ファイル名の選択された文字を変更するとき、「Ｆｏｒｗａｒｄ」が、強調表示された文字の後ろに挿入するために使用され、「Ｂａｃｋｗａｒｄ」が、強調表示された文字を削除するために使用される。編集を保存して、ファイルメニューに戻るために、「Ｐｌａｙ」を使うことができる。

図１４に関し、ある実施例では、さまざまなメニューオプションを示すための多数の言語（例えばフランス語、英語、スペイン語、その他）をサポートすることが好ましい。これらの実施例において、データ構造（例えば、メモリにある対照表）の使用が採用される。そして、各々のサポート言語に対する対応する語（又は語セット、句、その他）を定める。このような実施例では、ニューオプションのような項を表示する前に、一組の語の中で示された項として、どの語を中で使用すべきかについて決定するために、所望の言語と関連する変数にアクセスすることが好ましい。さらに、ある実施例で、複数の語をユーザ定義可能／編集可能にすることが望ましい。その結果、ユーザは、特定の項に関連して使うために、システムに対する語を入力することができるモードで、システムを作動させることができる。したがって、語「ドラム」が表示される場合には、これらの実施例では、該語を編集することをユーザに提供して、「ファットビート」又は他の所望の語又は句を表示させることができる。明らかなように、ユーザカスタマイズされたメニュー及び条件用の他の実施例は、想定可能である。

コピーを選ぶと、大きなフォントの行き先ファイルの名称を提案する画面が示される。この名称は、ソースファイルのタイプに基づいて自動的に提供される。たとえば、ソースファイルがヒップホップユーザ歌曲である場合、行き先ファイルの提案される名称は、ＨＩＰＨＯ００１（あるいは、ユーザは好ましくは行き先ファイルの名称を入力するために上記した名称変更手順を使用することができる）である。

ファームウェアップグレードメニューは、スマートメディアカードに記憶されるファイルから、プレーヤファームウェア（ソフトウェアを埋め込んだ）のアップグレードができるようにする。好ましくは、ファームウェアファイルがスマートメディアカードで利用可能でない場合、アップグレードファームウェアメニューに入ることはできない。この場合、警告メッセージが表示され、そして、プレーヤは、好ましくはシステムメニューに戻る。付加的な実施例において、ブートストラッププログラムの使用により、ファームウェアが取り外し可能な記憶場所（例えばＳＭＣ）から更新されることを可能にする。この種のブートストラッププログラムは、また、フラッシュ４９に存在するＤＳＰ４２音響バンクをアップグレードするために用いることができる。

第２図に特定されるプレーヤファンクションキーは、好ましくはＣＤプレーヤ又はＶＣＲに見られる標準のボタンからなり、歌曲（例えば、プレーヤ所有者、ＭＩＤＩ、ＷＭＡ、ＭＰ３、その他）の再生（演奏）を制御するために用いられる。「Ｒｅｃｏｒｄ（記録）」キーは、記録を制御する（例えば、サンプル）。編集又は選択メニューで使われるときに、プレーヤキーはまた、以下の動作を有する。すなわち、「Ｐｌａｙ（演奏）」は好ましくは、サブメニューを選ぶか又は変更を確認するために使われ、「Ｓｔｏｐ（停止）」は前のメニューに戻るか、動作をキャンセルするか又は変更を破棄するために使われ、「Ｆｏｒｗａｒｄ（送り）」は、リストに項目（アイテム）を挿入するために用いられ、「Ｒｅｖｅｒｓｅ（戻り）」はリストの項目を削除するために用いられる。これは装置のキーをいかに最小限の使用とするかの一つの実施例であって、その一方で、比較的大きな一組の特性を保持し、ユーザインターフェースを種々のユーザのために比較的直観的に保つものである。

ある実施例において、ユーザインターフェース制御の１又は複数が速度検出可能である（例えば、ユーザが制御を押圧する速度及び／又は圧力の若干の態様を測定することができる）。例えば、プレーヤ機能キーの１又は複数は、情報のこの種の速度−タイプを検出することができて、それを音響に組み込むことができる。これらの典型的な実施例において、「Ｐｌａｙ（演奏）」ボタンがサンプルを起動させるために用いられる場合、サンプルの実際の音響に、ボタン押圧に由来する速度−タイプ情報を組み込むことが好ましい。ある実施例では、ボタンが急速に及び／又はより強制的に押圧されるときに、サンプルがより大きく聞こえるということである。他の実施例では、変更された音響効果になるであろう。すなわち、どれだけ強く及び／又は強制的に「制御」が押されるかによって、結果の音響が異なる程度に変調され、フィルタがかけられ、ピッチ変更などがなされたりする。更に詳細に後述するように、楽曲イベントの多くは、ＭＩＤＩ−タイプの（又はＭＩＤＩ類似の）イベント記述子を含み、したがって、ある実施例では、速度及び／又はＤＳＰ（例えば、発生アルゴリズム、その他を介した）へのボタンプッシュの圧力特性を挿入するために、ＭＩＤＩ−タイプ記述子の速度部分（及び／又はボリューム、アフタータッチ、その他）を用いることが好ましい。このようにする代わりに、別々の記述子イベントを使うことができる（例えば、システム特ダネ通報又はＭＩＤＩＮＲＰＮ通報）ことは明らかであろう。

リストが歌曲選択画面で選ばれていると、「Ｐｌａｙ」を押すことによりリストの第１の歌曲の演奏が開始される。サンプルレーンが選ばれている状態では、「Ｐｌａｙ」の押圧により、選択されたサンプルを演奏し始めるように構成することができる。楽器レーンの場合には、「Ｐｌａｙ」の押圧により、現在の楽器の「Ｓｏｌｏ（独奏）」モード又は「Ｆｏｒｃｅｄ（強制）」モードに入るように構成することができる。

歌曲／サンプルリストを創作するために、歌曲又はサンプル選択画面中で「Ｆｏｒｗａｒｄ」を使うことができる。
編集画面を終了するために、編集を取り消して退出すべく「Ｓｔｏｐ」を用いることができる。例えば、サンプル選択画面で、元の画面に戻るために「Ｓｔｏｐ」を押す。その上、再生の間のいかなる所定の楽器のためにも、「Ｓｔｏｐ」を楽器の弱音化／非弱音化のトグルとして使うことができる。

サンプルの記録（好ましくは、サンプルを記録することは、プレーヤのほとんどいかなる動作モードにもおいて可能である）を始めるために、「Ｒｅｃｏｒｄ（記録）」を一度、押す。「Ｒｅｃｏｒｄ」は、記録を終えるために再度押圧される（格納されたサンプルファイルの規模がプログラム可能なサイズ（例えば、５００Ｋｂｙｔｅｓ）を超える場合、記録は自動的に止められる）。記録ソースは、動作モードに従い、自動的に好ましくは選択される。楽曲が演奏されていない場合、記録ソースは作動中のマイク（例えば、ローカルか、又は、外部ドッキング局に組み込まれるかのいずれかで）である。楽曲が歌曲、ｅ．ＤＪ又はラジオを演奏している場合、ミューティングされていない場合には、記録ソースは好ましくは音楽及びマイク入力の混合である。更に、サイズ／性能オプションの範囲を併せて提供するフォーマットを記録している異なるサンプルを使用することが可能である。例えば、非常に高品質サンプル符号化フォーマットは、より多くのスペースを記憶媒体上に必要とする。その一方で、比較的低品質な符号化フォーマットはより少ないスペースですむ。また、異なるフォーマットは、特定の楽曲のスタイル等により適することができる。

ある実施例においては、サンプル編集モードをサポートすることが好ましい。これらの場合、サンプル編集モードは、選択されたサンプルを編集するために、ユーザによって使用される。選択されたサンプルは表示され（例えば、ＬＣＤ２０上の簡略波形表示として）、ユーザは、サンプルの開始点及び終了点を選ぶことが可能である。好ましくは、この種のグラフィッククリッピング機能は、ユーザに、例えば、不所望の部分等を取り除くために、選択されたサンプルを容易に切り取ることを可能にする。サンプルをクリップ／切り取った後に、ユーザに対して、例えば、新しい名称をつけた、新しく短くなるサンプルファイルを保存するオプションが示される。明らかに、ＬＣＤ２０を使用して、選択されたサンプルの波形のグラフィックバージョンを提供し、かつ、エンドユーザに、選択されたサンプル上で基本操作を実行する単純な方法を提供するために、この種のクリッピングに加えて他の類似した編集型機能をサポートすることができる。

「ｖ−Ｒａｄｉｏ」モードにおいて、選択された局からのものを聞くために、「Ｐｌａｙ」を使うことができる。ラジオを消すためには、「Ｐｌａｙ」を押す。プリセット選択画面の局に戻るために、「Ｓｔｏｐ」を押す。帯域が上の次の局の自動検索をするために、検索が始まるまで、「Ｆｏｒｗａｒｄ」を押す。下部帯域の次の局の自動検索をするために、検索が始まるまで、「Ｒｅｔｕｒｎ」を押す。５０ｋＨｚの刻みで上下微調整するために、「Ｆｏｒｗａｒｄ」／「Ｒｅｔｕｒｎ」を押す。「ｅＤＪ」モードにおいて、サンプルレーンの間、「Ｐｌａｙ」が選択されたサンプルを演奏するよう押される。上記したように、ある実施例において、特定のボタン押圧の速度又は圧力を検出して、結果として生じる音響（例えば、サンプル演奏イベントにおいては、好ましくは、サンプル音響の音量、アフタータッチ、ピッチ、効果、その他を調整して）に、検出情報を伝えることが好ましい。サンプル再生が以前にできなかった場合、最初の「Ｐｌａｙ」押圧が再生を再度可能にする。次の押圧により、選択されたサンプルを演奏する。サンプルが演奏されている場合、「Ｓｔｏｐ」がその演奏を止める。サンプルが演奏されていない場合、「Ｓｔｏｐ」を押すことにより、サンプル（すなわち、Ｉ−Ｗａｙモードに戻るときに、ｅＤＪによってサンプルの自動再生を抑制する）をミューティングする。ミューティング状態のとき、「Ｍｕｔｅｄ」がステータスバーに表示され、丸いスピーカがＩ−Ｗａｙサンプルレーンから消える。

「Ｓｏｎｇ（歌曲）」モードにおいて、選択された歌曲又は演奏リストの再生を起動するために、「Ｐｌａｙ」を押し、ＬＣＤが演奏歌曲画面を表示する。「歌曲」モードにおいて、「Ｓｔｏｐ」により楽曲を止め、歌曲選択画面に戻ることができる。次の歌曲へ行くために「Ｆｏｒｗａｒｄ」をわずかの間押圧する（演奏リストのものを演奏する場合、リストの次の歌曲へ行くが、そうでなければ、スマートメディア上の次の歌曲へ行く）。歌曲を早送りするために、「Ｆｏｒｗａｒｄ」を連続的に押圧する。歌曲の先頭に戻るために「Ｂａｃｋｗａｒｄ」をわずかの間押し、２回目の押圧により前の歌曲に戻る（演奏リストのものを演奏する場合、リスト中の前の歌曲へ行き、そうでなければ、スマートメディア上の前の歌曲へ行く）。歌曲において早戻しをするために、「Ｂａｃｋｗａｒｄ」を連続的に押す。

「Ｓｔｏｐ」を押圧することにより、楽器／レーンのミューティングを切り換えることができる。例えば、ドラムレーン上で、一時的に「Ｓｔｏｐ」を押圧することにより、ドラムの音を消すことができる、そして、一時的に再びそれを押圧することによりドラム音を戻すことができる。その上、比較的長い期間（例えば１秒程度）「Ｓｔｏｐ」を押圧することにより、楽曲演奏を止めてスタイル選択画面に戻るように構成することができる。

「Ｆｏｒｗａｒｄ」は、新曲を起動するように構成することができる。「Ｂａｃｋｗａｒｄ」は、現在の歌曲を再度演奏するために用いることができる。
「Ｆｏｒｗａｒｄ」又は「Ｂａｃｋｗａｒｄ」は、同じパターンを保つために用いることができるが、演奏されている（好ましくは「コンパティブル（互換）」楽器だけが選択されて、プレーヤによって演奏される）楽器を変更することができる。

マイクをミューティングするために、ＭＩＣレーン又はトンネル内で「Ｓｔｏｐ」を押す。マイクをミューティング状態から復帰させるために「Ｐｌａｙ」を押す。
選択されたサンプルの再生を起動するために、好ましくは、「Ｐｌａｙ」を押す。サンプルの再生を止めて、サンプル選択画面戻るために、「Ｓｔｏｐ」を押す。

「歌曲」モードにおいて、楽曲を一時停止するために好ましくは「Ｐｌａｙ」を押す。再生をもう一度再開するために、「Ｐｌａｙ」を押す。歌曲選択画面で「Ｆｏｗａｒｄ」キーを押すことにより、新しい「Ｐｌａｙ」リストを生成する。歌曲選択画面において、元の画面に戻るために、「Ｓｔｏｐ」を押す。

スタイル選択画面において、元の画面に戻るために、「Ｓｔｏｐ」を押す。
強調表示されたファイルのためのファイル管理メニューを入力するために、「Ｐｌａｙ」を押す。

ファイル管理リストを閲覧しながら次のページまでスクロールするために「Ｆｏｗａｒｄ」を押す。前ページをスクロールするために「Ｂａｃｋｗａｒｄ」を押す。
ファイル管理メニューにおいて、選択された動作を起動するために「Ｐｌａｙ」を押す。

「Ｄｅｌｅｔｅ」を選ぶと、確認画面が表示される。
「Ｒｅｎａｍｅ（名称変更）」を選ぶと、大きいフォントのファイルの名前を示している画面が表示され、最初の文字が選ばれて点滅する。

ファイルをコピーするときに、コピーを確認するために、「Ｐｌａｙ」を押す。ソースファイルとしての同一タイプのファイルが同じ名称で存在する場合、確認画面はファイルが上書きされなければならないかどうか質問する。ＹＥＳ又はＮｏを選び、確認するために「Ｐｌａｙ」を押す。コピーを中止して、ファイルメニューに戻るためには、「Ｓｔｏｐ」を押す。ＭＰ３６ＲＡＭを用いて一つの取り外し可能なメモリ格納場所（例えばＳＭＣ）から別のファイルがコピーされるようにすることは、この実施例の好ましい特徴である。この例では、ひとつのＳＭＣから他に、コンパニオンＰＣソフトウェアプログラムを使用せずに、個別の歌曲又はシステムファイルをコピーできるようにすることが望ましいが、取り外し可能なメモリ格納量（例えば、特定のＳＭＣの全てのコンテンツ）がすべてコピーされることになっている場合には、より大きいデータ群がＰＣへのＵＳＢ接続によって一時的にバッファ記憶される（ＰＣ資源を使用して）ことを許容するために、コンパニオンＰＣソフトウェアプログラムを使用することが望ましい。ＳＭＣターゲット及びソース量を繰り返して交換しているユーザを含むので、この種の特徴はＰＣシステム（例えば、ＭＰ３６内蔵のＲＡＭを使用して）の無い実施例においては、可能でない。

図３に示されるｅＤＪ、ｖ−Ｒａｄｉｏ、歌曲、サンプル及びシステムの直接アクセスキーは、ユーザが他の任意のモード内からも直接所望のモードに入ることを許容する。これらのキーは、また、現在のモードを含む任意のモードも停止するために用いられる。これは「Ｓｔｏｐ」キーよりも高速で行うことができる。その理由は、次の通りである。すなわち、場合によっては、例えば、レーン内部のｅＤＪモードにおいて、「Ｓｔｏｐ」キーが好ましくはｅＤＪモードを止めるよりむしろ、レーンをミューティングするために使うことができるからである。

オーディオ出力制御は、Ｖｏｌ．Ｕｐ／Ｄｏｗｎとして図１に示される。事前に固定されたキーと組み合わせて使われるときに、オーディオ出力コントロールキーはまた、マイク入力を制御するために用いられる。

Ｕｐ／Ｄｏｗｎ／Ｌｅｆｔ／Ｒｉｇｈｔキーは、以下のために使われ得るジョイスティックからなる。すなわち、メニューナビゲーション、歌曲又は楽曲スタイル選択及び楽曲を演奏することに関するリアルタイム会話である。加えて、Ｕｐ／Ｄｏｗｎが直観的な方法で地下及びＩ−Ｗａｙモードのようなモード間で移動するために、使用することができる。

リストを編集するとき、強調表示された対象物の後に対象物を挿入するために「Ｆｏｗａｒｄ」を押し、対象物を削除するために「Ｂａｃｋｗａｒｄ」を押す。これにより、挿入又は削除が実行される。

リストを閲覧するか又はパラメータを選ぶために、Ｕｐ／Ｄｏｗｎを使用する。強調表示された対象物を編集するために、「Ｒｉｇｈｔ」を押す。リストの第１番目の項目へ直接行くために、「Ｌｅｆｔ」を押す。

楽器トンネルにおいて（すなわち、ドラム、バス、リフ、及びリード）、「Ｒｉｇｈｔ」は新しい楽曲パターンを作曲するように構成することができる。同様に、「Ｌｅｆｔ」は、前のパターン（楽曲パターンに関する下記の注を参照）に戻るために用いることができる。新規なパターンは、楽曲に同期して、現在の楽曲シーケンス（例えば、２小節）終了後、演奏し始めることができる。ところで、「Ｃｏｍｐｏｓｉｎｇ（作曲中）」のメッセージは、ステータスラインに現れるようにすることができる。その上、Ｄｏｗｎキーは、パターン番号を増分することのない新規な楽曲パターンを構成するために用いることができる。パターン番号が増分されない場合を除いて、「Ｒｉｇｈｔ」（他のパターンを作曲生成して、演奏する）と同じ効果を有する。、
これら構成の特徴の利点は、生演奏の間に、ユーザがパターンを変更することを可能にするということである。明らかなように、この特徴を採用することの他の理由は、ユーザが容易に入れ替えることができる一連のパターンを組み立てることができるということである。新しく作曲されたパターンが他ほど望ましくないことを見出すだけのためにキーを押した後、ユーザは「Ｄｏｗｎ」キーを選択し、そのパターンを廃棄して、別のものを作曲することができる。望ましいパターンを発見すると、即座に、ユーザは、その後に、望ましいパターンの間を行ったり来たりするために、「Ｒｉｇｈｔ」及び「Ｌｅｆｔ」キーを使用することができる。その上、この特徴によって、システムがパターンを保存するための有効メモリを最適に利用することができる。ユーザがあまり望ましくないパターンを廃棄することができることによって、利用可能な資源を、より望ましいパターンを格納するために用いることができる。

ファイル管理メニューにおいて、所望の動作を選ぶために、Ｕｐ／Ｄｏｗｎを使用する。ファイルの名称を変えるとき、ユーザは、変更すべき文字を選択するためにＬｅｆｔ／Ｒｉｇｈｔを用いることができ、選択された文字を変更するためにＵｐ／Ｄｏｗｎを使用することができる。最後の文字が選ばれたとき、Ｒｉｇｈｔを押すことにより、新しい文字を追加する。ユーザはまた、文字を挿入／削除するために、Ｆｏｒｗａｒｄ／Ｂａｃｋｗａｒｄプレーヤ機能キーを使用することができる。

マイクトンネルにおいて、Ｌｅｆｔ／Ｒｉｇｈｔはマイク入力左／右バランスをするように構成することができる。サンプルトンネルにおいて、Ｌｅｆｔ／Ｒｉｇｈｔはサンプルを選ぶために用いることができる。サンプル選択画面で「Ｆｏｗａｒｄ」を押すことにより、新しいサンプルリストを創作する。

Ｄｏｗｎは、現在のＩ−Ｗａｙモードレーンに代わって地下モードに入る直観的な方法の例である。このモードにおいて、ユーザは選択された楽器（ドラム、バス、リフ又はリード）によって演奏されるパターンを変更することができ、デジタル効果を加えることができる。同様に、Ｕｐにより、地下モードから楽曲Ｉ−Ｗａｙに戻るように構成することができる。

Ｖ−Ｒａｄｉｏモードにおいて、所望の局をプリセットで選ぶために、Ｕｐ／Ｄｏｗｎを使用する。プリセットリスト中の前局／次局へ行くためにＵｐ／Ｄｏｗｎを用い、局からのものが演奏中に、プリセットリスト中に局を記憶するために、Ｓａｖｅ／Ｅｄｉｔを押す。Ｓａｖｅ／Ｅｄｉｔキーは、現在の歌曲を後で再生することができるユーザ歌曲として保存するために用いることができる。この種の歌曲は、二次記憶場所（例えば、スマートメディアカード）に保存することができる。あるプレーヤの実施例の場合、ｅＤＪ歌曲が演奏する間、その歌曲を生成した「ｓｅｅｄ（シード）」のみとしていつでも行い得る。その歌曲は、ユーザ歌曲として再生されるときに、同じ歌曲を再生成することができるように格納される。ある実施例においては、自動的に変更されたファイルを新規なファイル（例えば、同じ名称で、しかし、異なる接尾辞を有する）として保存する保存ルーチンを組み込むことが好ましい。この種の特徴は、自動的にファイルの以前のバージョンを保持するために用いることができる。

シードの使用がこの開示の他の箇所で論じられるが、Ｓａｖｅ／Ｅｄｉｔ１７キーの使用について類推を行うことはこの点で有用であろう。このキーは、非常にコンパクトなやり方で歌曲の基本パラメータを保存するために用いられる。このことは、ＤＮＡシーケンスが生体系のパラメータを含む方法と類似している。シードは、完成された歌曲の情報と比較して、ごくわずかなスペースしか占有しない、しかし、それらは最終的な歌曲を定義する。保存されたシードの同じ組が与えられれば、本発明のプレーヤアルゴリズムは、楽曲の正確な同じシーケンスを生成することができる。実際の楽曲がこの例では記憶されないが（Ｓａｖｅ／Ｅｄｉｔ１７キーの使用により）楽曲を造っている基本ブロックは非常に効率的に記憶される。この種の方法は、比較的限られた資源を備えるシステム（例えば、比較的低いコスト／低い性能のプロセッサ及び限られたメモリを備えるシステム）において有効である。楽曲を格納する反復性のある、それでいて極めてコンパクトなこの種の方法は、また、他の実施例において採用可能である。それは、例えば、比較的幅が狭い帯域伝送路（例えばインターネットへの５６ｋｂｐｓのモデムリンク又は他の装置へのリンクのｉＲＤＡ／ｂｌｕｅｔｏｏｔｈタイプ）を介して他のシステムとの通信を含む。明らかに、この特徴は、システム間の他の比較的低帯域幅接続を同様に使用して、好適に使用することができる。その上、この特徴によって、ユーザが所定格納容量により多くのデータファイル（例えば、歌曲）を格納することができ、他の利点の中でも、この効率は他の好ましい特徴（上記したように、新規ファイルとしての変更されたファイルの自動保存等の特徴）である。

ある実施例において、取り外し可能なメモリボリュームが挿入されない場合、及び／又は、挿入された取り外し可能なメモリボリューム上に利用可能な記憶が充分でない場合、ユーザ歌曲インスタンスを保護するために取り外し可能なメモリインターフェース（例えば、ＳＭＣ４０を伴うＳＭＣインターフェース）が利用できる資源をチェックすることが望ましい。これらの場合、ユーザが歌曲を保存するとき（例えば、Ｓａｖｅ／Ｅｄｉｔキー１７のボタンを押したとき）に、ユーザが付加取り外し可能なメモリボリュームを挿入することは、有利である。

再生のために、後でこの歌曲（ファイルとして）を選ぶことが可能であるようするために、歌曲の名称は、一時的にステータスラインにおいて表示される。もちろん、ユーザがそうすることを望む場合、歌曲ファイル名は後ほど変更することができる。一旦項目が作成されると、作成された項目を、歌曲又はサンプル選択画面において選び、Ｓａｖｅ／Ｅｄｉｔキーを押すことによって編集することができる。Ｓａｖｅ／Ｅｄｉｔキーを再び押すことにより、編集された項目を保存する。Ｏｎ／Ｏｆｆキーが２秒以上間押圧されると、プレーヤがオン又はオフされるように構成することができ、この組合せが短く押圧されるときには、Ｏｎ／Ｏｆｆキーは、代わりにＬＣＤバックライトをオン又はオフするように構成することができる。

Ｐｉｔｃｈ／ＴｅｍｐｏキーがＬｅｆｔ又はＲｉｇｈキーと同時に押圧されると、それが楽曲のテンポを制御するために組合せとして使うことができる。Ｐｉｔｃｈ／ＴｅｍｐｏキーがＵｐ／Ｄｏｗｎキーと同時に押圧されるとき、それはマイク入力、楽曲、その他のピッチを制御することができる。

Ｅｆｆｅｃｔｓ／ＦｉｌｔｅｒｓキーがＬｅｆｔ／Ｒｉｇｈｔ又はＵｐ／Ｄｏｗｎキーと同時に押圧されるとき、所定の楽器、マイク入力、又はサンプルに加えられる効果（例えば、遮断周波数又は共振）及び／又は、音量（ミュートを含んで）を制御できる。

当業者が理解できるように、他の関連した組合せは、装置の作業性を損なうことのない付加機能を提供する線に沿って、そして、本発明の趣旨及び範囲から逸脱することなく、使用することができる。

楽曲を構成するための本発明のさまざまな好ましい実施態様を説明する。新曲のために、唯一必要なユーザ入力は入力スタイルである。スタイル自体を疑似ランダムに選ばせる自動演奏機能が可能にされるときには、入力スタイルさえ必要でない。しかし、ユーザが特定のスタイルを選びたいときには、歌曲生成を開始するためにその入力だけが必要とされる。

実際の生成プロセスそれ自体に移る前に、ユーザのスタイル選択に必要なものがスタイル及びサブスタイルであるということが重要である。すなわち、本発明のある実施例では、スタイルは類似したサブスタイルから成るカテゴリである。これらの場合、ユーザがスタイルを選ぶとき、本実施例はサブスタイルの各種取り合わせから疑似ランダムに選択する。その上、その替わりに、より優れた制御のために、ユーザが特定のサブスタイルを選ぶことも可能である。これらの具体例において、ユーザがスタイル又はサブスタイルを選ぶ場合、その選択結果は、スタイル及びサブスタイルの両方が歌曲生成ルーチンに入力として使うことができるということである。ユーザがサブスタイルを選ぶとき、スタイルは絶対的に利用できる。ユーザがスタイルを選ぶとき、サブスタイルは疑似ランダムに選ばれる。これらの場合、両方のパラメータは、最終的な歌曲の付加的変更を許容すべく、歌曲生成プロセスの間に利用可能である。

図１５に示すように、歌曲は一連のパートから成る。各パートは、イントロ、テーマ、コーラス、ブリッジ、エンディング、その他である。そして、異なるパートは、繰り返すことができるか又は歌曲の後に戻ることができる。例えば、一連のパートは、イントロ、テーマ、コーラス、テーマ、コーラス、テーマ、コーラス、エンディングである。あるスタイルスは特別なタイプのパートを有することができる、そして、他のスタイルスは利用可能パートのサブセットだけを使用することができる。これは、特定のスタイル又はサブスタイル用の所望の特性に依存する。例えば、「ｃｏｏｌ（クール）」スタイルは、ブリッジパートを使用することができない。さらに、通常より速いテンポを有するスタイルスは、各パートを単純に二倍化する（すなわち、イントロ、テーマ、テーマ、コーラス、コーラス、テーマ、テーマ、コーラス、コーラス、その他）ことにより、実質的に２倍にされたパートサイズを使用することができる。

また、ある場合、ユーザは、特定のパートのために更新された表示を有することにより、利益を得ることができる。例えば、歌曲の全長の範囲内の現在の位置の指示は、ユーザに役立つであろう。他の実施例は、エンディングパートの間、歌曲が終了しつつあるという警報をユーザに出すことである。この種の警報は、ディスプレイのある部分でメッセージ（すなわち、「エンディング」）を発光させることを含み、歌曲の保存を望む場合に、それを今保存すべきことをユーザに思い出させる。このレベルの他の最適化は、パート毎で保存されるべき歌曲の対話的生成の間、ユーザによってなされる変更を許容する。これは、ユーザが楽器タイプ、効果、音量又はフィルタ等に対して変更をし、その修正された特性をそのパートが使われる時毎に使うことを許容する。例えば、これは、ユーザがコーラスに若干の変更を与えたならば、コーラスの次の発生がその変更された特性を含むことを意味する。この特定の実施例にしたがって、その歌曲の他のパートはデフォルト特性を含む。あるいは、特性変更態様は、多数のパートに適用することができるか、又は、歌曲の長さ全体にわたってリアルタイムで保存することができる。これについては、後述する。

各パートは、異なる長さであって、一連のサブパートから構成することができる。好ましい実施例の一態様は図１５に示されるサブパートレベルを含む。しかし、パート構造がサブパートレベルを介在することなしにシーケンスによって直接構成されることができ、この点で、サブパートレベルの使用は任意である。

ある実施例において、サブパートレイヤーが実行される場合、各サブパートは異なるサイズであってもよい。それがパートにある程度の多様性を与えるので、この種の方法は、結果として生じる作曲の感触を強めることができる。

各サブパートは、一連のシーケンス（ＳＥＱ）から成る。一貫したサイジングとルール適用の柔軟性との関係に関する前述のコメントにより、各ＳＥＱは、同じ長さ及び拍子記号である。図１５の実施例において、各ＳＥＱは４／４拍子記号をもつ２楽節の長さである。もちろん、これらは本発明のある変形において調整することができるが、この例のこの装置は良好に動作する。その理由は、測定境界を越えて音符（ノート）をどのように保持できるかを示すことができるからである。楽曲により大きな多様性を許容するためにＳＥＱ（以下に論じられるＲＰと同様に）のサイズを長くすることは有利である。図１５と同様に、この種の変形も本発明の範囲内である。

図１５の実施例にしたがえば、各ＳＥＱは、平行する多数の「実際のパターン」（ＲＰ）のみから成る。通常、楽器の各々のタイプに一つのＲＰを有することは有用である。この場合、あるタイプの楽器は、Ｉ−Ｗａｙユーザインターフェース（すなわちドラム、バス、リフ、その他）の単一レーンと一致する。ＲＰデータは、実際の音符（ノート）データである。通常、ユーザ対話を通じて、そして、そのような対話が多数の楽器に適用されない限り、このレベルでの情報は移行（ｔｒａｎｓｐｏｓｅ）されない。もちろん、これはユーザインターフェースの決定であって、ここで論じられる実施例への制限ではない。

この場合、多数のＲＰは、ＳＥＱを構成するために一緒に併合される。当業者によって認識されるように、これは、最新技術のＭＩＤＩシーケンサがＭＩＤＩＴｙｐｅ１情報の多数のセットをＭＩＤＩＴｙｐｅ０ファイルに併合する方法に類似している。
これに関する更なる背景詳細は、「一般のＭＩＤＩレベル２仕様」（ＭＩＤＩ製造者連合から入手可能）において見出すことができ、本願明細書に引用したものとする。

ＳＥＱを定めるために平行に多数のＲＰを許容することの一つの理由は、ある時間に、Ｉ−Ｗａｙ上のあるレーンが多数のＲＰの使用から利益を得ることができるということである。このことは、歌曲の間、異なる時間に、特定の楽曲の特性を変化させることが望ましい場合があることにある。例えば、リードはコーラス及び独奏の間、異なっていてもよい。この場合、楽器タイプ、グループ、フィルタリング、残響、音量、その他を変化させることが望ましい場合がある。そして、この種の変化は、多数のＲＰの使用によって実現することができる。その上、この方法は、演奏の間に楽器を加え／排除するために用いることができる。もちろん、これは、この種の変化を取り込む唯一の方法ではなく、多数のＲＰの唯一の使い方でもない。

図１５の実施例にしたがえば、各ＲＰは、２小節から成り、ＲＰｘ及びＲｐｙに分けられる。この種の２小節構造は、ＭＩＤＩ情報（コード変更、サステイン、その他）の若干の変化を内部小節境界にまたがって許容するので、有用である。この種の変化は、コード変更を小節内におこす複雑さ生じることなく、あるいは、多数のＲＰの中で持続される音符をもつことなしに、楽曲変化の効果を提供することができる。

通常、多数のＲＰにわたって音符保持することを許容するのは扱いにくい。これは、音符を保持するために、パターンの終わりで「音符オフ」制御信号のマスキングを必要としたり、そして、次のパターンの始めで「音符オン」制御信号のマスキングを必要とする点で、ある程度ＭＩＤＩ特性によるからである。また、コードを切替えるときに、パターン境界にまたがって同じ音符を保持することは、パターンの終わりがコード進行を通じて循環する機会であるので、重要である。そして、保持されている古い音符が新しいコードと互換性を持つことを確める必要がある。コード進行情報の生成及び併合は、本説明の能動性と平行して生じ、以下に更に詳細に論じられる。通常、複数のパターンにわたって音符を保持することは望ましくないとみなされるが、例外がある。

長いＭＩＤＩイベントがいくつかのパターンを通じてフィルターをかけられるとき、多数のパターンにわたる開放音の音符を有する潜在的に有益な拍子の一つの実施例はテクノスタイルにあり、本願明細書において、「ｐａｄ（パッド）」と呼ばれている。この実施例を扱うひとつの方法は、現在のＳＥＱが、パッドの始めか、中間か、終わりかどうか調べるために、パッドシーケンス表示フラグを使用することである。そして、パッドのためのＭＩＤＩ音符オフが始めにはなく、次のＲＰの初めにおいてＭＩＤＩ音符オンがなく、適切なＭＩＤＩ音符オフが終わりにくるように、パッドトラックのＭＩＤＩイベントを変更することができる。

図１５に関して説明を続けると、ＲＰは、それらに適用される楽曲のルールを有したバーチャルパターン（ＶＰ）から成る。楽曲のルールは、更に詳細に後述するコード進行情報の生成と併合の一部である。一般の若干のピッチ情報に加えて、ＶＰは対応するＲＰのリズムであるとして、一般に考えることができる。好ましくは、楽曲のルールはＶＰに適用され、その結果がＲＰとなる。楽曲のルールは、更に詳細に以下で論じられる。

ＶＰは、一連のブロックと考えることができる。図１５の実施例において、各ブロックは、二次元（ブロックｄ及びブロックｆｘ）を有するが、これは、一つの可能な例でしかない。この例では、ブロックｄはブロックのデータと一致し、そして、ブロックｆｘはそのデータに適用される効果（すなわち、音量、フィルタリング、その他）と一致する。この例では、ブロックｄの情報は、種々のありうる周期的ブロック（この種の周期的ブロックを生成するための望ましい方法、及びＶＰを創作する際のそれに対応する選択は、図２２及び図２３に関連して本明細書において後述される）から選択された個々の周期的パターン情報ブロックとして考えることができる。

図１５に記載されているブロックｆｘの次元は、ブロックｄ情報にある特性を追加するための任意である。例えば、上述した音量又はフィルタリング情報に加えて、ブロックｄの次元が音楽の情報予測手段（「バーチャル音符」又は「コントローラ（ＶＮＣ）」情報として、以下により詳細に論じられる）の割当て又は分布のために使うことができる。しかしながら、ブロックｆｘの次元は任意であり、そして、卓越した結果を得るために、ブロックｄの情報は、この種の音量又はフィルタリング情報とは別個に処理することができる。

拍子記号が４／４で、ＲＰが２小節である上記実施例を仮定すると、パターン中の全てのブロックは期間中に最高８つの四分音符を加えなければならない。この例では、特定のＲＰのｎブロックを仮定すると、対応するＶＰの各ブロックの四分音符の持続期間は、１と（８−｛ｎ−１｝）の間である。この実施例は、ブロック長の基本単位である四分音符をもつ４／４時間を記述しているが、本実施例の簡単な変形は、代替拍子記号及びブロックの代替基本単位（すなわち、１３／１６拍子記号及び第３２音符のそれぞれ、その他）を含むであろう。

図１５の下部を見ると、サブブロック（ＳＢ）のオプション実施を理解できるであろう。例えば、大太鼓、シンバル、小太鼓、その他のための別々のＳＢを有することが望ましい場合には、あるスタイルの間のＩ−Ｗａｙのドラムレーンのために、この種の実施態様を用いることができる。本実施例の実現の更なる最適化は、ドラムレーンのＳＢレベルにドラムレーンのＶＰ直接構成させることであろう。この種の装置は、効果的にドラムレーンの個々のＳＢのための別々のブロックｆｘを有する複雑さを取り除く。本発明を実現する際にこの種の最適化が役立つ実施例は、限られた資源、すなわち、ドラム（小太鼓、大太鼓、その他）の別々のパートのための別々の効果を有することが望ましくない環境における実施例である。

さらに、本発明のあるアプリケーションにおいて、図１５のあるレベルがバイパスされるようにすることが望まれることがある。そのような場合、これによって、ユーザが実際の音符情報（例えば、入力としてのＭＩＤＩ楽器を経た歌曲の間のリアルタイムの情報）の形で、本当のパターンデータを入力することができる。更に、ポケットサイズＰＣソフトウェアプリケーション（及び、ＰＣへの接続）を用いて、ある実施例では、ブロックデータとしての用途の自身のＭＩＤＩパターンを入力することを、ユーザに許容できるようにすることが好ましい。

本発明の歌曲の作成において使用する楽曲ルールの好ましい方法のさまざまな実施例を説明する。
図１６Ａは、本発明に関連して楽曲を生成する好ましい方法の一般的な概要を表している系統線図である。ステップ１で起動し、楽曲のスタイル及び選択された楽器が定められるか又はロードされる。一旦楽曲のスタイル及び楽器のタイプが既知となると、アルゴリズムは個々のバーチャルパターンサブブロック（例えば、図２２に示される）を展開するために、ブロックルールを適用することができる。別の実施例においては、個々のバーチャルパターンサブブロックは、リスト又は他のデータ構造から選ばれる。

好ましい本実施例において、サブブロックデータは、楽曲生成のアルゴリズム処理の間、必要に応じて創作される。図１６Ｂは、図１６Ａ（ステップ１）の代替実施を例示する。

図１６Ｂにおいて示したように、ステップ１ａにおける、スタイル及び楽器に関連したデータは、互換リズムイベントを創作するアルゴリズムのルーチンへの入力である。一つの例として、「第１の最大％」パラメータが、リズムイベントがどれくらいの頻度で小節／楽節の最初の拍子で起こるかを示すための入力として、使われる。比較的高い最初の最大パーセントは、選択された楽器が、選択されたスタイルの小節又は楽節の始まりで通常音符を鳴らすことを示すことができ、比較的低い最初の最大パーセントは、選択された楽器が、選択されたスタイルの小節又は楽節の始まりで通常音符を鳴らさないことを示すことができる。別の例として、「解像度グリッド」パラメータが、所与の楽器及びスタイルのリズムイベントの典型的位置を示すために、入力として使うことができる。「解像度グリッド」は、小太鼓楽器がロックスタイル用の４拍子の小節の第２と第４拍子目に鳴ることを示すことができる。別の例として、「鼓動最小／最大」パラメータが楽曲の特定のスタイルのために望まれるテンポの範囲を示すための入力として使うことができる。多くの他の入力パラメータが、本発明と整合した方法で使うことができ、ここで論じた実施例では、所与の楽器及びスタイルのための一組のリズムイベントを組み立てることが特徴である。アルゴリズムの実施例では、リズムイベントは、音符イベントが始まる時点である。好ましくは、持続時間、速度等の音符の他の態様は、まだ未決定の状態である。

図１６Ｂに示されるように、ステップ１ｂでは、リズムイベント（例えば、音符起動イベント）がスタイル及び楽器パラメータ入力に基づいてアルゴリズム的に生成された後、アルゴリズムは持続期間をリズムルールを使用しているリズムイベントに割り当てる。好ましくは、リズムルールは、付加スタイル及び／又は、例として、「無音％」、「コード％」、「コード持続期間感度％」、「コード速度感度％」、「速度アクセント」、「動的速度」、及び／又は、「擬人化」のような楽器パラメータを使用しているステップ１ａで生成されるリズムイベントに作用する。「無音％」は、楽器が無音であるときに、ある小節（又は他の楽節）の間の音符長のパーセントを示すために用いることができ、比較的高い数値は、比較的長い音符持続期間を表す等の結果となる。「コード％」は、コード一部として起こる音符のパーセントを示すために用いられる。「コード持続期間感度％」は、あるコードにおけるいくつかの音符が他のものより長い持続期間を有することができるかどうか等の、単一コードの多数の音符の停止時間の結合性の程度を示すために用いられる。「コード速度感度％」は、コードの一部として起こる多数の音符の速度（例えば、音量）の結合性の程度を示すために用いられる。「速度アクセント」を、アルゴリズムにアクセントの位置を示すためにパラメータとして使うことができ、例えば、レゲエスタイルのベースギターがアップビートにアクセントをつけることを示すために用いられる。同様に、「動的速度」は、アクセントが生じる程度を示すために用いられ、アクセントの比較的高い程度は、所定の楽器の他の楽曲イベントと比較するとき、アクセントに起こる楽曲イベントの比較的高速度（例えば、音量）の結果となる。「擬人化」が、リズムイベントのある程度の不ルール性を示すためのパラメータとして使うことができる。これらは、持続期間をリズムイベントに好適に割り当てるために用いられるパラメータの実施例である。本発明の利点を達成しながら、他のパラメータをその実行に応じて置換することができるか又は追加することができる。このステップの結果、図１６Ａのような図と関連して論じられた方法で処理することができるバーチャルパターンサブブロックデータを生成することになる。

図１６Ａを参照すると、一旦サブブロックが利用できる（例えば、リストから又は１ブロック支配アルゴリズムから）ようになると、それらはステップ２でバーチャルパターン（ＶＰ）に処理される。この例では、この点で、ＶＰは楽曲でない。但し、それはリズム情報、及び、他の組み込み楽曲特性を含む。ＶＰデータ構造の埋め込み楽曲特性を用いるステップ３において、楽曲ルールは、より多くの音楽的才能をパターンに加えるためにＶＰに適用される、その結果、実際の音楽の情報と同様に、ＶＰのリズム情報を含む。ステップ４において、各々の小節がコード進行をデータ構造に与えるために主音アルゴリズムによって音楽的に移行されるという点で、主音がステップ３から出る出力に適用される。ステップ５において、特定の楽曲モードに設定される楽曲情報を出力するために、微妙な変化を楽曲情報に実行するモードが適用される。それから、ステップ６において、キーの変化を許容し、及び／又は、データ構造及び／又はさまざまな歌曲構成要素の中のキー整合性を許容するように、キーが適用される。最後に、ステップ７で、歌曲演奏の間、リアルタイムのピッチ／テンポシフトを許容するために、他の歌構成要素に加えて、グローバルピッチ調整がデータ構造に適用される。

ＲＰを生成するためにさまざまな楽曲ルールを適用するこの過程は、図１５と関連して前述の全体的な歌曲生成プロセスの一部である。更に詳細に図１６Ａに記載されているステップを行う前での、前述の組み込み特性、同じく主音のいくらかの言及及びキー理論に関する議論は有用である。

ＭＩＤＩ仕様がデジタル的に楽曲を示す簡潔な方法を提供し、そして、今論じられた楽曲ルールからの出力データの一つの重要な行き先が、ＭＩＤＩデジタル信号処理装置であることを心に留め、本発明者はＭＩＤＩ言語とのなんらかの類似点があるデータフォーマットを使用することが、ある実施例において有利であることを見出した。後の説明において、各ステップで使うことができるデータの若干の実施例とともに、図１６Ａのステップの説明を行う。記載されているデータフォーマットがＭＩＤＩと類似している一方、差を理解することが重要である。基本的に、本説明は、ＭＩＤＩに対応するデータストリームにおいて、どのような付加的なコンテキスト仕様の意味を組み込むかを説明する。図１６Ａにおける各ステップの処理の間、組み込まれた意味要素が抽出され、そして、それに応じて、そのストリームが若干の楽曲進行において変更される。このように、この過程を考慮する手段は、各ステップで、ストリームがＭＩＤＩＤＳＰ（この態様は、図２１に関して、以下で更に詳細に説明される）によって演奏される実際のＭＩＤＩストリームに、より近くなる。

本実施例において、楽曲に含まれれるリズム及び楽曲情報を「バーチャル音符」及び／又は「コントローラ」（ＶＮＣ）に分解することが有利であると考えられる。図１７の実施例において、ＶＮＣのいくつかの有益な例が提供される。基本的には、これらのＶＮＣは、特定のジャンルの楽曲ルールを、簡素化された機構に分解する方法を示している。該簡素化された機構は、そのジャンルの他のオリジナル曲の特性及びバラエティ（変更）とともに新しい楽曲を生成するために、ランダムな態様に沿ってアルゴリズムによって使用することが可能である。楽曲のスタイルに従い、ＶＮＣの異なるタイプを有効に用いることができる。図１７のリストは、詳細に後述する２、３の実施例を簡単に提供するものである。

本発明の本態様の重要な特徴は、アルゴリズムによって引き出されるリズムデータの基本ブロックに、楽曲生成アルゴリズムのための制御情報を組み込んだということである。本発明により、アルゴリズム及び最終的楽曲出力の双方において、多様性、アップグレード性及び複雑さを許容する非常に効率的な方法でこれを成し遂げた。これのキーとなる態様は、本発明において、リズムデータの基本ブロックを示すためにＭＩＤＩ−タイプフォーマットを使用するということであり、このようにして、持続期間、音量、タイミング、その他の制御を可能にする。さらに、本発明においては、どのように楽曲の部分を創作すべきかをアルゴリズムに知らせるＶＮＣデータを組み込むために、これらの基本ブロックのＭＩＤＩ−タイプフォーマットの異なった模擬部分を使用することができる。例示として、アルゴリズムに、そのＭＩＤＩ−タイプイベントに関連して、どんなＶＮＣを呼び出すべきかについて指示するために、リズムデータのこれらの基本サブブロックの各ＭＩＤＩ−タイプイベントのピッチを使用することができる。このようにして、このリズムデータがアルゴリズムによってアクセスされるとき、ピッチタイプデータが特定のＶＮＣと認識されて、ＶＮＣ機能に対応する実際のピッチ情報と置き換えられる。図１７は、第１カラムにおいて、この種の組み込み値の例を示し、そして、第２及び第３カラムでは、認識されたＶＮＣ命名法の例及びそれに関連する潜在的ピッチ情報を示す。

第１７図の実施例において、ＶＮＣの基本タイプは、「低音符（ＢａｓｅＮｏｔｅ）」である。例えば、これらの音符が一回の実行で、比較的短い音符であるときを除いて、これはメロディの基礎としてある楽曲のスタイルで考慮される。このようなわけで、リズムはＶＮＣに前後関係を提供するためにＶＰの中に存在する。「低音符」の値の例は、Ｃ，Ｅ，Ｇ又はＢである。どの値が最終的に使われるかは、アルゴリズムの一部としての疑似ランダムシードに依存する。本発明においては、これらの実施例において、これらの値が非常に良い楽曲を、これまで研究してきたジャンルに提供することを見出した。マジック音符（マジックノート）は図１７（全音階が使われる場合）に示す値を有することができ、これらの値は、先行する「低音符」に対して相対的である。「低音符」と異なって、マジック音符は、メロディに強烈に影響を与えない音符を提供する点で好ましくは有益である。例えば、アルゴリズムは、生成される次の音符がマジック音符１であるということを理解し、そして、可能な値＋１， −１，＋２， −２の一つを予測された通り選択するために、「擬似ランダム番号シード」を使用することができる。予測通りに選択された値は、先行する「低音符」からの値を数学的に調整して、結果としてある音符値になるように用いられる。この実施例によれば、先行する「低音符」がＣ２で、アルゴリズムの結果が＋１を選択するものである場合、マジック音符値はＤ２である。マジック音符０及び１の間の唯一の差がマジック音符０が０値を有することができるという点に注意すべきである。このように、マジック音符０の使用は、時として、先行する「低音符」と同一の値である音符に結果としてなる。これは、比較的微妙な方法において特定のスタイルの音響に影響を及ぼす方法の例である。

上記説明において、「予測通り選択された」ことによって、シード値に基づいて結果を擬似ランダムに選ぶ方法を参照する。シード値が同じである場合、結果は好ましくは同じである。これは、再現性を可能にするひとつの方法（唯一の方法ではない）である。これらの疑似ランダム及びシード問題に関する更なる議論は、本願明細書の別の箇所で行われる。

図１７を続けて参照して、「高音符」は、単純に１オクターブを先行する低音符に加えて、メロディに大きい変化をつくるするために役立つ。ここで興味深いことは、複数のＶＮＣが前の低音符及び高音符の間に起こり得るということであり、そして、これは、楽曲フレーズの演奏に先の低音符に対応する主音音符を許容するための方法である。明らかに、実際の楽曲構造が実際の楽曲自体が書かれる前に存在することを可能にするので、このＶＮＣは非常に役立つ。アルゴリズムは、最終的なキーかモードがこの点で何であるかはわからないが、オクターブ及び主音を利用できる。

マジック音符と同様に、「倍音音符」ＶＮＣは、アルゴリズムが擬似ランダムに一組の可能な高調波から倍音を選ぶことを許可する。あるコードで同時に聞こえている多数の音符があるとき、この能力は役立つ。このＶＮＣが使われるとき、それは結果として、図１７に記載されている相対的な高調波のいずれかになる。これらの値は、可能な値の単なる例示であり、われわれが取り組んできたタイプの楽曲に特に有用なものである。

「最終音符」は「低音符」と非常に類似しているＶＮＣである。但し、可能な値のサブセットのみを含む場合は除く。このことは、我々が取り組む楽曲タイプのための楽曲フレーズを理解するように、最終的な音符が特に重要で、一般に最もよく聞こえるので、それがＣ又はＧ（この例では、全ての音符がその後追加ステップによって上下に移調することができることを留意して）の相対値を有するときに、一般に最もよく聞こえるからである。全てのＶＮＣと同様に、その値で演奏される正確な音符は、ユーザが利用できる一般のピッチシフトと同様に、後で適用されるモードとキーに依存する。しかしながら、我々が取り組む楽曲において、これが、種々の可能な結果を提供する楽曲に微妙さを付加するための有用な方法であることを我々は見出した。

「最終音符の一つの前の音符」は、「最終音符」の直前に先行するＶＮＣである。このことは、最後のふたつの音符及び倍音的音程が曲の最終効果にとって重要であることを発見したからであり、したがって、「最終音符」Ｃ及びＧとともに、Ｅ、Ｇ又はＢの「最終音符の一つの前の音符」を使用することが有利であることがわかる。これらの値は、楽曲の他のスタイルに適用でき、ＶＮＣ構造が有効に利用されることの一例を示している。

図１７の最後の例ＶＮＣは、ＡＬＣコントローラである。これは、ある楽曲の非ピッチ概念がＭＩＤＩコントローラを使用して用いられる一例である。この例では、ＡＬＣコントローラが直後の音符の意味を変更する接頭辞として考えることができる。ＡＬＣコントローラは、例えば、コードを設定するために、次の音符が特別な方法で扱われることになっていることを示すために用いることができる。この例では、付加的倍音音符を有する固定された一連の音符に先行するために、ＡＬＣコントローラのための特定の定義済み値を使用することができる。上記で論じられたマジック音符ＶＮＣと同様に、ＡＬＣコントローラに引き続く「倍音音符」が、アルゴリズムに擬似ランラムに一組の可能な高調波から倍音を選ぶことを許容する。あるコードで同時に聞こえている多数の音符があるとき、この能力は役立つ。このＶＮＣが使われるとき、それは図１７に記載されている相対的な高調波のいずれかに結果としてなる。これらの値は、可能な値の単なる例示であり、今日まで取り組まれたタイプの楽曲に特に有用なものである。ＡＬＣコントローラの他の実施例は、固定された音符の設定にある。この場合、任意の所望の実際の音符値のための「固定音符」値を有する適当なＡＬＣコントローラに追従する。この方法は、所望の楽曲の音符の間の特定の音程が成し遂げられる場合、より慎重に限られた歌曲出力を有するために、多くの例において役立つ。その上、周知のフレーズ又はシーケンスを演奏することは、ＡＬＣコントローラのこの使用によって可能である。既存の楽曲にかなり似ている一曲を生成するために、全ての歌曲の部分をこの方法で符号化することができる。この例では、楽曲がまるで既存の曲（例えば、メロディで）のように聞こえることを可能にするように対話的に生成される楽曲のある部分を有することができ、また、他の部分が異なる（例えば、バス又はドラムような）ようにすることもできる。

このようにして、ＡＬＣ値がＶＮＣの全てを処理し、それに次の音符がコードの基礎になっていることを知らせるソフトウェアルーチンに警告するということ、及び、倍音音符の次の番号がその基礎音符と同時に演奏され、結果としてすぐに演奏されるコードになることから、ユーザは結果コードを設定できる。この実施例は、これが効果的になされる一方法を示す。ＶＮＣコントローラの他の値は、類似した楽曲機能を実行するために用いることができる。

特定の楽器タイプの自然音域、又はＴｅｓｓｉｔｕｒｅを扱う付加的変形を実現することができる点に注意すべきである。ソフトウェアルゴリズムが前述のＶＮＣを採用しかつ真の値を選んでいる場合、真ピッチ値は楽器タイプの真の自然音域と比較することができ、そして、次のＶＮＣ結果の値は反転することができる。例えば、与えられたパターンの「低音符」がバス楽器Ｔｅｓｓｉｔｕｒａのための音域の上部に近い場合、正数を戻すことになる任意の次のマジック音符を、先行する「低音符」の下になるように音符を移行するために反転することができる。これは、特定の楽器タイプの自然音域の制限を組み込むので、微妙さ及び深さを結果に加える独特の最適化である。

Ｔｅｓｓｉｔｕｒａの簡略実施例として、図１８Ａは特定の楽器タイプの相対的な最適範囲を表す。これと関連して、楽器のＴｅｓｓｉｔｕｒａは、それが最適に聞こえる音域である。ＭＩＤＩ音響バンクのある音響は、特定の音域のために最適化される。ベースギター音響を選んで、非常に高いピッチの音符を演奏する場合、結果はあまり良くはならない。より高いピッチのためには、ギター又はバイオリン音響が、より効果的に作用することができる。したがって、楽曲ルールアルゴリズムがＶＮＣを処理しているとき、選択された楽器タイプのＴｅｓｓｉｔｕｒａは、生成された真の音符値の結果で役割を果たすことができる。選択された楽器がそのＴｅｓｓｉｔｕｒａの上部エッジに接近していて、楽曲ルールルーティンが「高音符」ＶＮＣにわたって現れる場合、アルゴリズムは生成されたピッチを１又は２オクターブ下に落とすように設計される。同様に、他のＶＮＣは、選択された楽器のＴｅｓｓｉｔｕｒａに応じて処理される。

ある別の実施例において、状態マシン、表及び「ＭａｇｃｉｃＦｕｎｃｔｉｏｎ（マジック関数）」ルーティンに部分的に依存することによって、バーチャル音符コントローラ（ＶＮＣ）及び真の音符の間で変換を実行することが好ましい。このように、新規な楽曲のスタイルは、「ＭｇｉｃＦｕｎｃｔｉｏｎ」を変更せずに、リリースすることができる。例として、１又は複数の表及び／又は状態マシンを更新するだけで、新しい及び／又は変更されたＶＮＣタイプを含む新規なスタイルを創作することができる。「ＭａｇｉｃＦｕｎｃｔｉｏｎ」が転送互換性を犠牲にすることなく最適化された設計（例えば、ＤＳＰ）において実現されることを可能にするという点で、この種の方法は望ましい。ある実施例において、状態マシンデータは、歌曲の一部として記憶することができる。

図１８Ｂは、転送互換性のために、表及び／又は状態マシンに依存する典型的な「ＭａｇｉｃＦｕｎｃｔｉｏｎ」系統線図を例示する。この「ＭａｇｉｃＦｕｎｃｔｉｏｎ」は、ＶＮＣイベントに基づいて真の音符情報を生成するために、アルゴリズムの楽曲発生器によって呼び出される。この機能が、楽曲の間、多数回呼び出され、したがって、比較的効率的なＤＳＰハードウェア設計のような最適化された設計を使用する利点があることが明白である。

図１８Ｂの左上を起点として、前の真の音符及び処理されるべき現在のバーチャル音符（ＶＮＣ）を有する「ＭａｇｉｃＦｕｎｃｔｉｏｎ」が起動する。この機能の目的は、現在のＶＮＣと一致するために真の音符情報を決定することにある。この例では、本発明の効果の多数を実現するために必要ではないが、「ｍａｇｉｃＦｕｎｃｔｉｏｎ」の一部として、奇術機能の一部である有限状態マシン（ムーア状態マシン（ｈｔｔｐ：／／ｗｗｗ．ｎｉｓｔ．ｇｏｖ／ｄａｄｓ／ＨＴＭＬ／ｆｉｎｉｔｅＳｔａｔｅＭａｃｈｉｎｅ．ｈｔｍｌで国立標準技術研究所によって更に詳細に記載されている）のような）の使用を例示する。図１８Ｂに関する説明を続けると、状態マシン（ＳＭ）にアクセスして、それによって表からデルタ値の音域を書き込む。また、本願明細書において記述されるように、簡単な更新を与える方法で、表及び／又は状態マシンは記憶される。ここで記載されているデルタ値の音域の例として、図１７と関連して本願明細書において記載されているマジック音符１のようなＶＮＣの使用を仮定すると、表から書き込まれるされるデルタ値の音域は、−２， −１，＋１，＋２である。図１８Ｂにおけるこの点で、「ＭａｇｉｃＦｕｎｃｔｉｏｎ」は、前もって決定された真の音符から移動する方向（例えば、増分又は減分）をランダムに選ぶ。説明のために本願明細書において、減分している方向がこの点で選択されると仮定する。それが値（例えば｛−２、−１｝）を減少させるだけであることを含むために、デルタ値の音域が、それが減少値（例えば、−２， −１）のみを含むようにマスキングされる。このマスキングされた音域から、単一のデルタ値は、好ましくはそれから「ＭａｇｉｃＦｕｎｃｔｉｏｎ」によって選ばれる。

特定の楽曲構成要素（例えば、図１８Ａと関連して本願明細書において記載されているように）と関連するＴｅｓｓｉｔｕｒｅが使われないある実施例において、「ＭａｇｉｃＦｕｎｃｔｉｏｎ」のこの点で、デルタ値を、新しい真の音符を創作するために、前もって決定された真の音符に適用することができる。例えば、前の真の音符がＧ３でデルタ値が−２であると仮定すると、新しい真の音符はＥ３である。

許容音域ＩＳのＴｅｓｓｉｔｕｒｅが望まれるある実施例において、個々のデルタ値がマスキングされた音域から選ばれる図１８Ｂに示された「ＭａｇｉｃＦｕｎｃｔｉｏｎ」の点で、選択されたデルタ値がｔｅｓｓｉｔｕｒａ音域値の範囲内であるかどうか調べることが望ましい。それが範囲の中でない場合、その機能は選択されたデルタ値（例えば、−２）を廃棄し、マスキングされたデルタ値の音域から、最大値（例えば、−２）を取り除いて、新規な最大値がｔｅｓｓｉｔｕｒａに対応する許容値の音域の中であるかどうか調べる。新規な最大値が音域の中である場合、典型的な機能では、マスキングされた音域の残留する値の中から別のものをランダムに選んで、新しい真の音符を創作し続ける。しかしながら、新規な最大値がｔｅｓｓｉｔｕｒａ音域によって許容されない場合、「ＭａｇｉｃＦｕｎｃｔｉｏｎ」は、デルタ値の現在のマスキングされた音域を廃棄して、方向指示（例えば、減少から増加まで）を変更して、新規な指示によるデルタ値の元の音域をマスキングする。このように、「ＭａｇｉｃＦｕｎｃｔｉｏｎ」がｔｅｓｓｉｔｕｒａ値の許容音域の近い一縁部で作動するとき、端を検出して回転させることができる。したがって、フルート（例えば、比較的高いｔｅｓｓｉｔｕｒａ音域を有する）のような楽器と関連するＶＮＣが現在処理されていて、その処理のランダム状態が作曲されているメロディにフルート楽器と関連する標準音域の底部端に接近させる場合、現在の典型的な「ＭａｇｉｃＦｕｎｃｔｉｏｎ」は減少する方向から＋１増加するものまで変更することができて、それによって、フルートと関連する標準ピッチ音域の中にとどまることができる。ここで記載されているような方法において、効率的なアルゴリズム（例えば、ＤＳＰ）を、バーチャルピッチイベントから真のピッチイベントを創作することに提供することは可能である、その一方で、各々のバーチャルピッチイベント（例えば、特定のＶＮＣに伴う値の表を更新することによって）に伴う個々のデルタ値と同様に、バーチャルピッチイベント（例えば、状態マシン表を更新することによって）のタイプの将来のアップグレードを許容する。さらに、ここで議論される実施例がＶＮＣから真の音符まで移動することに含まれる機能に向けられているが、この種の方法が、この開示の他の箇所で記載されている他の作曲要素（例えば、コード進行の選択、歌曲構造、その他のような）のいずれかに、同じように適用できることも、当業者にとって明らかである。

図１９は、楽曲処理の他の態様を記載する。楽曲のキー変化は、オフセットとして符号化することができる。これによって、Ｘのキーの場合、そのキーは、オフセットを挿入することにより上下にシフトすることができる。この種のオフセットは、（今は異なるキーであるが）前の通りの楽曲フレーズに結果としてなるために、正確な値によってすべてを移調する。図１９は、Ａ、Ｃ、Ｄ及びＧのキーを有する例を示している。Ｃのキーは、０のオフセットを、Ａは−３のオフセット、Ｄは＋２のオフセット、Ｇは＋８のオフセットを有する。音楽理論の学生が理解できるように、オフセットは多くの半音と密接に一致する。Ｃ及びＧの間の音程は、８つの半音である。他のキーも、同じように行うことができる。

上記したように、ＭＩＤＩ言語フォーマットが、増分的に半音ピッチ値と一致している各整数値については、楽曲のピッチを詳細に描写するために整数を使用するので、キーを符号化するための半音の使用は有利である。キーを示すためにオフセット値を提供する他の手段が使用され得る。しかし、経験上、ＭＩＤＩＤＳＰを使用しているので、半分のステップの活用法は特にこの実施態様に有用である。したがって、楽曲ルールの出力は、少なくとも部分的にＭＩＤＩに基づくものである。

図２０は、全プロセスの一部である他の楽曲ルールであるモードアプリケーションを示す。楽曲理論の学生によって理解されるように、モードが嬰音（フラットとは反対に）に関して記述されることを仮定すると、嬰音の特定の配置が、各楽曲フレーズにそれ自身のほとんどの独自性を与える。図２０において、昇順又は降順バージョンが利用できる「リディアンモード」の例を提供する。他の確立した楽曲モードが存在する（イオニアン、ドーリアン、ハイポドーリアン、フリギアン、ハイポフリギア、ハイポリディアン、ミクロリディアン、アイオリアン、ロクリアン、その他）が、紙面の関係上こここではリディアンのみを使用する。明らかに、図２０のそれらの相当値を有する他のモードを、本発明は含むことができる。従来の西洋モードでないモードが要求されるケースにおいては、他の音程が可能であるために、音響バンク（例えば、フラッシュ４９に位置する）をアップグレードするか又は変えることが好ましい。

図２０は、我々が扱っている楽曲のジャンルの全ての好ましくは利用できる音符のリストから始まっている。それは、「本位記号モード（ＮａｔｕｒａｌＭｏｄｅ）」と称する対応する本位音符値によって追従される。「本位記号モード」の音符の値は、嬰音（再び、本説明では、変音（フラット）ではなく、嬰音の点でモードを定めてめていることを仮定する）なしの音符の全音符列と一致する。「リディアンモード」はリスト記入され、Ｆ本位音を許容しない。本位音のＦが、Ｆ嬰音の次の有効ピッチまで上げられることになっているか、又はＥの次の有効ピッチに下げられることになっているかどうかを決めるために、アルゴリズムは昇順性又は降順性移調のいずれかを決定する。降順的に移調されたＦ本位音はＥに変更され、昇順的に移調された本位音ＦはＦ嬰音へ移調される。嬰音が「本位音モード」から変化するとすると、昇順「リディアンモード」の使用は、結果として、よりＦ嬰音の多い楽曲となり、よりアグレッシブな「リディアン」となる。降順移調より典型的によりアグレッシブである昇順移調を行うこの一般の概念は、他のモードでも同様に明らかである。

この点に関して、図２１を用いてアルゴリズムの楽曲ルール部分の詳細な例を述べる。本発明の好ましい例がどのようにそれらを組み込むかについて示すために、この説明は、以前の図に関する前述の説明を組み込む。

図２１は、各々の番号をつけられた図１６Ａのステップ２−６の間に存在するように、そのデータを表す。もちろん、バーチャルパターンサブブロックデータがパラメータデータ（例えば、図１６Ｂに示すように）に基づいてアルゴリズム的に生成されるある例では、ＶＰサブブロックは、定義済みセットから書き込まれるよりはむしろ必要に応じて生成され得る。従って、あとに続く説明で、ＶＰサブブロックデータに関する説明が定義済みデータの使用を含むけれども、ある例では、これが、処理の間必要に応じて定めらることに留意すべきである。記譜法は、好ましいフォーマットの簡略実施例を示すために、データがソフトウェアルーチンを取り入れることができるフォーマットの簡略実施例を示すためとともに、全体的な概念を明らかにするために述べられる。

最上列から始まって、楽曲スタイル及び／又は長さによって適宜インデックスを付けることができる一まとまりの定義済みＶＰサブブロックがある。これらのブロックは、可変サイズであって、ピッチ（ある実施例でＶＰのピッチ情報が上記のように実際のピッチ特性でなく、しかし、上記したようなＶＮＣデータを示すと認識して）、速度及びＭＩＤＩファイル（定義済みＶＰサブブロックの好ましい集合は、図２２及び図２３に関して以下で更に詳細に論じられる）の継続期間の記譜法に対応する１６進フォーマットで記憶される。図２１の最上列に示すように、休止符が有効パターンの集合において利用できる。索引つきサブブロックの集合が、「バーチャルパターン」（ＶＰ）を構築するためにソフトウェアルーチンによって使用される。上述したように、ある別の例では、サブブロックのコレクションを生成するためにアルゴリズム的ブロックルールを使用することを含む。この種のアルゴリズムのルールは、楽曲スタイル及び楽器タイプを入力として受け入れ、そのスタイル／楽器の組合せに適するひとまとまりのサブブロックを出力するように構成される。サブブロックが定義済み集合から選ばれるか又はアルゴリズムで活動中に生成されるかは、ＶＰに系統化される。ＶＰは、一貫して大きさを設定されたグループ化に関与するルーチンによって組み立てられた一まとまりのサブブロックである。

図１６Ａのステップ２が適用されたあと、好ましくはＶＰを有する。図２１（ＶＰ）の第２の列は、２小節長の、以下のシーケンスで作曲された実施例ＶＰを表す。すなわち、「低音符」、「マジック音符１」、「マジック音符０」「高音符」、及びその他の「低音符」である。このとき、パートのリズムは適当な位置にあり、各音符の値は概念的に組み込みＶＮＣ情報であることに留意すべきである。ＶＰがこの点で演奏されるなら、出力はおそらく気持ちよいものではない。列２の右欄は、このデータが記憶されるフォーマットを表す。本明細書の他の箇所で議論じられているように、このフォーマットが、ＶＮＣ情報がデータストリームに必ず組み込まれるという点を除き、ＭＩＤＩフォーマットデータに著しく類似している。

図１６Ａのステップ３が適用された後の第３の列（ＮＣＰ）は同じデータを表す。列２からＶＰに組み込まれるＶＮＣは、可能なＶＮＣ値から疑似ランダム選択の助けを借りて、ルーチンによって解釈される。このように、列２の第１の「低音符」に対して、列３のＥの真の音符値を有し、そして、減少させた列２のマジック音符のタイプ１に関して、前の「低音符」をふたつの半音分、列３のＤまで減少させる。マジック音符のタイプ０については、前の値を０だけ調整して、他のＤに結果としてなる。これがＶＰについて行われ、そして、結果は列３において明白である。この点で、コード及びモード移調が未だなされなっかた場合を除き、最終的に楽曲となる基本的な楽曲情報を有することになる。

図１６Ａのステップ４が適用された後の図２１（ＰｗＴ）の第４の列は、データストリームを表す。理解できるように、列３のＮＣＰは下へ移調された。これは、特定のパターンが特定の主音音符に適合するように構成されることを許容し、このようにして、楽曲の他の要素に整合させるために適切なコードにそれを配置する。この特徴によって、メロディの異なる部分を異なる主音音符に適合することができる。そして、全ての楽器が同じコード進行に合致することを確実にしつつ、このように、コード進行に沿って処理を行う。

図２１（ＰｗＴＭ）の列５は、音符のパターンを示し、特定のモードタイプ（降順的、昇順的、その他のような）と同様にそれを特定のモード（例えば、アイオニアン、ドーリアン、ハイポドーリアン、フリギアン、ハイポフリギアン、リディアン、ハイポリディアン、ミキソリディアン、アイオリアン、ロクリアン、その他）に適合させる。楽曲モード及びモードタイプのより完全なリストは、ＭａｎｕｅｌＯｐｄｅＣｏｕｌ（以下のワールドワイドウェブで利用可能：ｗｗｗ．ｘｓ４ａｌｌ．ｎｌ／〜ｈｕｙｇｅｎｓｆ／ｄｏｃ／ｍｏｄｅｎａｍｅ．ｈｔｍｌ）によって作成されており、本願明細書に組み込まれたものとする。特定のモードに対する音符のパターンの適合は、上述した図２０と同様な方法でなされる。図２１の例において、Ｃ嬰音の差がＣに減じられる場合を除いて、結果として生じる楽句は、列４のそれと非常に類似している。このことは、この種のＣ嬰音がリディアンモードにないことによるもので、したがって、その除去がこのステップで必要である。旋法調整がモードをのぼっているリディアン昇順モードを使用している場合、より多くの嬰音がある故にそれはよりアトラクティブになり、このＣ嬰音は次のリディアン音符Ｄに切り上げられる。しかし、この例ではリディアン降順モードをを使用しているので、嬰音ＣはＣに切り下げられる。

図２１（ＲＰ）の最終列は、楽曲フレーズが音階を包括的に上下移調されるときの位置を示す。これは、包括的ピッチ調整機能が望まれる場合に、ユーザが迅速且つ容易に歌曲のピッチを上下に（例えば、それは、Ｕｐ／Ｄｏｗｎキーと結合して使用するピッチ／テンポキーについて先の実施例において論じられたように）移行することを可能にするために有利である。列６の例は、２つの半音の移調を示す。この図の全ての列と同様に、第３の対の番号が行毎に２の値分増加することがある場合、これは、ソフトウェア表記法と同様に記譜法に見てとれる。

楽曲のある要素が、呼び出されるべき上述した楽曲ルールを必要とし例がある。例えば、ドラムトラックは、概してモード又はキーに関係しないので、このように移調される必要はない。その上、ドラム、及びＭＩＤＩ効果のような多くの楽器タイプは、一連のピッチのＭＩＤＩ音響バンクに編成されない。しかし、互いに似ているか又は似ていない一連の音響においては編成される。ドラムの実施例において、嬰音Ｃに対応する音響は小太鼓音であってもよく、大太鼓音であってもよい。これは、ある場合には、図２１に関して上述された処理の異なるレベルが、これらの場合に都合よく迂回することができることを意味する。

ＶＰを構築するための上述のサブブロックの集合は、図２２及び図２３を参照してよりよく理解される。
図２２は、１又は２の四分音符の例示的な継続期間に基づいて、可能であるリズム変化の実施例を表す。第１列は、２、３の基本条件（８分音符が最小単位であること、長さは一つの四分音符であること、及び、全ての全休止符は別個に「空の」として示されること）が与えられた場合の４つの可能な変化を示す。図２２の第２の列は、類似した変化（８分音符が最小単位であること、第一列のいかなる変化も含まれないということ、及び、長さが２つの四分音符であること）が与えられる場合の、可能な変化の一覧を示す。

図２２に示すような一組のリズム変化をつくるひとつの方法は、変化データをＭＩＤＩイベントフォーマットに入れることである。この方法は、周期的ブロックを生成するためにＭＩＤＩシーケンサソフトウェアツール（ＣａｋｅｗａｌｋからのＳｏｎａｒ及びスタインバーグからのＣｕｂａｓｅのような）を使用することを含む。これは、種々の入力方法（例えば、キーボードコントローラ、ＭＩＤＩ管楽器コントローラ、ＭＩＤＩギターコントローラ、その他）の使用を可能にして、更に、直観的な複製、ペースト、量子化、及び包括的な特性調整（例えば、多数のイベントを選んで、そして全てのためのピッチを調整すること）を可能にする。ＭＩＤＩイベントは、ＭＩＤＩファイル（各楽器グループごとに１ファイルで）として、移出することができる。最後に、ソフトウェアバッチファイルプログラムは、任意の必要とされない特性情報（コントローラ又はパッチ情報のような）と同様に、実質的なヘッダ情報を分析し、そして、ソースコード（例えば、ＡＳＣＩＩテキストテーブル）に含めるのに適しているファイルへ最適化されたデータを出力するために記述することができる。ＭＩＤＩコントローラ装置の広大なアレイを利用でき、それが特定の楽器タイプの特性を模することができるので、時間配列ツールの使用により、与えられた楽器タイプ毎の種々の適宜のリズムブロックを迅速に生成することを可能にする。例えば、楽器グループのギタータイプのひな型でつま弾くために、ＭＩＤＩギターコントローラを使用することができる。

図２２の例は、概念を伝えるために単純化される。すなわち、２つの四分音符（上述の条件が与えられると仮定すると）までカバーしている全てのリズム変化が、リズム密度によって非常に効率的に編成することができる。図２２は、図１５に示されるＶＰを構成するために用いるブロックの一組を効率的に編成する有利な方法を教示する。列全体に整合している上記したような条件が与えられると仮定すると、図２２の例がより長い持続期間を有するリズムブロックのための付加列を含むために拡張される場合、各々の次の列は、それより上のそれらより少ない密度のパターンを有するであろう。これは、各列がそれより上の列にあるいかなる変化も含まないという条件によるものであり、パターンの継続期間が各々の次の列のために増加するためでもある。このように、図２２に示される例とＶＰをつくるために使用されるパターンの相対的なリズム密度との間には直接の関係がある。

明らかに、図２２に記載されているいずれかの条件が変更される場合、例えば、十六分音符が最小単位であるか、又は全休止符が休止符を含むパターンで示される場合、変化の数は異なるであろう。数が異なるとしても、リズム密度のこの概念に基づく編成パターンの望ましい効果は存続する。

効率に加えて、有効なリズムブロックを編成するこの種の方法は、ソフトウェア（例えば、アルゴリズムの機能）又はハードウェア（例えば、状態表ゲートアレイ）ルーチンに入力としてリズム密度の使用を可能にする。このように、相対的なリズム密度を特定の楽器タイプと関連させることができ、対応するリズムブロックを得るために、所望のブロック長の形で、そのリズム密度を使用することができる。ＶＰが完了する（図１５を参照）まで、これは繰り返すことができる。ＶＰは、所望の相対的なリズム密度によって構成することができる。通常、与えられた楽器タイプと一致しているリズム特性を有するほぼ無制限の変化を有するＶＰの作成を可能にするので、これは特に有用である。

ＭＩＤＩの当業者にとって明らかであるように、ここで論じられるＶＰ生成にあっては、図２２に示されるリズム変化はＭＩＤＩイベントの形で示すことができる。この場合、ＭＩＤＩイベント（ピッチ、速度、アフタータッチ、その他のような）の有効特性の多くは、一般的に設定される。また、この種の特性のための追加機能は、付加的な微妙さを完結した楽曲に与えるために、ＶＰの作成の間にＭＩＤＩイベントに適用することができる。この種の機能は、かなり単純であり、効果的である。一つの例として、楽曲（例えば、ロック）の与えられたスタイルのために、拍子（例えば、ダウンビート）の特定の位置にかかるＶＰいかなるＭＩＤＩイベントの速度は、穏やかに増加することができる。同様に、一般にリズム揺動感を有する楽曲スタイルにおいて、拍子のひとつ又はそれ以上の打音がわずかに遅れたり、又は進んだりする場合、ＶＰ内の対応するＭＩＤＩイベントを、タイミング情報を調整するために変更することができる。明らかに、これらの種類の単純な機能は、与えられた楽器タイプ及び／又は与えられた楽曲スタイルのいずれにも好ましくは適用することができる。

図２３は、アルゴリズムで楽曲を創作する際の決定的な特性として相対的なリズム密度を使用する概念と同様に、音符ピッチの相対的な可動性の概念を記述する。図２３に示すように、垂直軸はピッチ変化を示し、そして、水平軸は時間を示す。メロディストリームの２つのタイプ例が表される。すなわち、種々のピッチによるストリーミングを有する上部と、より少ない数のピッチの中のむしろ急峻で、不連続な変化を有する下部とである。このように、図２３の上のメロディは、音符ピッチのより高い相対的可動性を有する。ＶＮＣに関する前の説明理解することができるように、上部のメロディ例は一般に模倣するより多くのマジック音符を必要とし、そして、下部のメロディ例は一般に模倣するより多くの低音符及び高音符を必要とする。

ある楽器が他より高い音符ピッチの相対的可動性を有するという点で、この概念は、与えられた楽曲スタイルの大部分の楽器タイプにもあてはまる。例えば、ロックスタイルのベースギターは、同じスタイルのギターと比較して、音符ピッチの低い相対的可動性を有すると理解することができる。それが各々のリズムパターンのための実際のＶＮＣの決定における手引きとして役立つという点で、音符ピッチ及び関連したＶＮＣタイプの相対的可動性との関係は、上述の通り、定義済みサブブロックの集合を創作するのに非常に有効である。したがって、特定の楽曲スタイル及び／又は楽器タイプで使用するために、一組のリズムビルディングブロックをつくりたいとき、音符ピッチの所望の相対的可動性を考慮して／決定し、ＶＮＣタイプを割り当てることは、有利である。

付加的変形として、上記した相対的なリズム密度に関して、与えれられた楽器タイプ及び／又は楽曲スタイルのためにＶＰを構成するアーキテクチャがソフトウェア（例えば、アルゴリズムの機能）又は、音符ピッチの相対的可動性に関するハードウェア（例えば、状態表ゲートアレイ）ルーチンから非常に利益をもたらすことができる。例えば、特定楽曲スタイル及び／又は楽器タイプに、相対的なリズム密度値を割り当ることができ、そして、この種の値は、ＶＰの生成の間、ＶＮＣの割り当て又は配信に影響を与えるために用いることができる。

この状況下での音符ピッチの相対的なリズム密度及び相対的可動性の使用は、実際に人間が生成した楽曲の芸術的微妙さを精巧に模するＶＰを生成する方法を提供する。これが、この種の真の楽曲の楽曲構成要素のある態様を定量化する方法であるので、本願明細書において開示されるように、それがコンピュータシステムによって模倣することができる。他の変形及びその種の方法の利点は、これらの特性が好ましくはユーザによって変更可能であるパラメータとして容易に定量化されるということである。このように、所与の楽曲スタイル及び／又は楽器タイプが、可変特性として音符ピッチパラメータ（及び／又は相対的なリズム密度パラメータ）の相対的可動性を有することができる。したがって、ユーザは、歌曲再生／生成の間、この種のパラメータを調整することができ、かつ、音楽的結果全体にわたって制御の他のレベルを有することができる。

本発明のブロック作成態様のための好ましい具体化のさまざまな実施例が記述される。また、上記のように、ある実施例で、ＶＰサブブロックデータは、アルゴリズム的にパラメータ入力データ（例えば、第１６Ｂ図にて図示したように）に基づいて生成することができ、又は、この開示のどこかで論じられた／図解されたように、予め定められたセットから書き込むことができる。

図１５に示される例を続けると、ＲＰが２小節で、そして、ＶＰが８つの四分音符（ＱＮ）からなる場合、図２４のパターン構造作成例は、特定の歌曲生成が８ＱＮのＶＰ長、２小節ＲＰ、及び可変サイズ化されたブロックを含むものと仮定する。当業者であれば、相当数のこの好ましい例のアーキテクチャに起因している効果を理解する一方で、さらに、これらの例に対するさまざまな改作変更が本発明の技術思想と範囲から逸脱することなく構成され得ることも理解するであろう。

スタイルのアルゴリズムの生成のためのある好ましい本実施例を、図１６Ｃと関連して述べる。図示するように、楽曲データ（例えば、ＭＩＤＩファイルのような）を分析するために、次の自動楽曲生成に使用するためにパラメータ及びパラメータ範囲を決定すべく本願明細書において記載されている楽曲生成概念を用いることは有利である。このように、現実の音楽部分をアルゴリズムに入れることができ、分析することができ、特性を決定するために測定されることができる。そして、特性のデータベースに記述され、それから類似した楽曲を生成するために用いてもよい楽曲ルールに、最終的に抜き出される。このように、先に存在する楽曲データに基づいて楽曲スタイルを作成する方法を自動化することができる（ある程度の人間の介入を有するが）。このように、先に存在する楽曲に基づいて自動作曲された楽曲を引き出す能力をもつ余裕がある。これは、アーティスト（例えば、エミネム、イモレーション、ビートルズ又はセロニアスモンク、その他）、ジャンル（例えば、ブラックメタル、バップジャズ又はプログレッシブロック、その他）、及び／又は、時代（例えば、１９７０年代後期ディスコ）、音楽ラベル（例えば、ＭｏｔｏｗｎＲｅｃｏｒｄｓ又はＢｌｕｅＮｏｔｅＭｕｓｉｃ、その他））に基づいて楽曲スタイルを作成する際に有利である。

図１６Ｃに示すように、既存の楽曲データ（例えば、ＭＩＤＩファイル）が分析アルゴリズムに書き込まれる。所望の結果（例えば、一組のエミネム曲がローディングされ、そして、その結果はエミネムに特有の楽曲スタイルである）に基づいて、１又は複数の楽曲入力の決定は、人間のオペレータによってなされる。一旦楽曲参照データがローディングされると、アルゴリズムはデータのさまざまな特性を測定するためにデータを処理する。図１６Ｂと関連して上記の説明は、アルゴリズム的に楽曲入力データに由来することができるパラメータのタイプの実施例を与える。ＭＩＤＩデータファイルの例を用いて、さまざまなパラメータは、各楽器について測定することができる（例えば、第１の最大％、解像度グリッド、パルス、無音％、コード％、コード持続期間感度％、コード速度感度％、速度強調、速度動力、擬人化、その他）。その上、この開示のどこかで論じられたように、他の測定が、モード、ピッチ、その他のように引き出される。図１６Ｃに示したように、分析アルゴリズムは、ユーザが派生パラメータを調整することができるように、ある程度のユーザ入力を許容する。例えば、入力ファイルのうちの１つが異例に遅いテンポを有する場合、ユーザは一つの異例に遅い入力曲の効果を除去するために、派生テンポ範囲を微調整することができる。楽曲入力が分析されて測定された後、一組のパラメータ及びパラメータ範囲がデータベースに記憶される。この例では、データベースはプログラミング言語のためのインクルードファイルを公式化するために、コンピュータープログラムによってアクセスすることができる。図１６Ｃの実施例において、この開示の全体にわたって記載されているように、自動作曲を実行するためのファームウェア又は他のソフトウェアを生成するために用いることができるＭＳＶｉｓｕａｌＣ＋＋プログラミング言語インクルードファイルのために、インクルードファイルをフォーマット化することができる。このように、既存の楽曲データ（例えば、１又は複数のＭＩＤＩファイルの形で）は、オリジナル楽曲データの特性に密接に似ている楽曲のスタイルを作成するために用いてもよい。

ある実施例において、入力楽曲データは、ＭＩＤＩ以外のフォーマットであってもよい。例えば、ある方法については、記録された楽曲（例えば、ＰＣＭ、ＷＡＶ、ＣＤ−Ａｕｄｉｏ、その他のフォーマットでの楽曲）を分析するためにすでに記述している。この種のすでに開示された技術は、例えば、図１６Ｃの「分析アルゴリズム」の一部として、本発明に組み込むことができる、「ＣｌａｓｓｉｆｙｉｎｇＲｅｃｏｒｄｅｄＭｕｓｉｃ」、２０００年にのエジンバラ大学のためのセスゴーラブによって書かれたＭＳｃ論文は、この種の分析のための典型的なソースコードを含む一つの実施例である。キースマーティンによる［ＡｕｔｏｍａｔｉｃＴｒａｎｓｃｒｉｐｔｉｏｎｏｆＳｉｍｐｌｅＰｏｌｙｐｈｏｎｉｃＭｕｓｉｃ」は、１９９６年１２月のＭＩＴメディアラボＰｅｒｃｅｐｔｕａｌＣｏｍｐｕｔｉｎｇによってリリースした、本発明と整合した方法で、特性データを引き出すために記録された楽曲をアルゴリズム的に分析する技術の他の例である。エリックシェイラーによって、１９９８年のアメリカ音響学会によって発行された「ＴｅｍｐｏａｎｄＢｅａｔＡｎａｌｙｓｉｓｏｆＡｃｏｕｓｔｉｃＭｕｓｉｃＳｉｇｎａｌｓ」は、この種の分析の更なる実施例を提供する。併せて、これらの文献は、パラメータデータをつくるために音響調節的、記録された楽曲の測定及び分析についての典型的なさらなる詳細を提供する。アーティスト、ジャンル、その他に基づいて楽曲ルールを作成するために、自動作曲エンジンのための音楽スタイルを作成するために実行することができる分析の実施例として、この種の技術は本説明に組み込まれれたものとする。

図２４に示すように、本発明の好ましい一実施例はパターン構造の作成を含む。このパターン構造は実際のブロックを選ぶために必要な情報から成り、そして、それらはさまざまな方法で歌曲生成の基本単位となる。ある好ましい実施例においては、図１６Ｂと関連して論じられるように、実際のブロックは、特定のスタイル及び／又は楽器のために必要に応じてアルゴリズム的に生成される。あるいは、パターン構造作成のこの実施例は、ブロックが選ばれる楽器の群と同様に、各々のブロックの持続期間（与えられたＶＰで）を決定することを含む。このステップの後、以下で論じられるように、この情報は、それ自身直接ブロックを生成するために用いられる。

Ｐａｔｔ＿Ｉｎｆｏは、ブロックから特定のＶＰの作成の一部として、パターン構造情報を生成するために用いることができるルーチンである。
シフトは、さまざまな方法で好ましくは構成されたＶＰに変化を加えるために用いることができるマルチプライヤであって、例えば、それは、特定のブロックが入るＲＰにおける２小節のいずれかに基づいて異なるブロックの変化を許容するバイナリ状態であってもよい。シフトマルチプライヤの他の使用形態も容易に適用され、類似した多様性を全体的な歌曲構造に提供する。

Ｎｕｍ＿Ｔｙｐｅｓは楽器の数であって、Ｎｕｍ＿Ｓｕｂ＿Ｄｒｕｍｓはドラム楽器を形成する個々のドラムの数である。この後者のポイントは楽器選択の拡張レイヤを許容する好ましい変化であり、そして、それはドラム楽器以外の状況にも適用することができる。逆にいえば、この変化は、全く本発明又は本実施例にさえ必要でない。

Ｂｌｏｃｋ＿Ｉｎｄはブロックインデックスであり、ＦＸ＿Ｎｏは任意の効果番号情報のためのものである。Ｃｏｍｂｉ＿Ｎｏは、Ｃｏｍｂ＿Ｉｎｄｅｘ＿Ｌｉｓｔと呼ばれている表の場所を示しているインデックスである。この表は、スタイル数に楽器タイプの数が乗じられる大きさであり、各々の入力は、好ましくは以下を含む。すなわち、特定の入力が現在のサブスタイルに適しているかどうか決定するＳｕｂｓｔａｙｌｅ＿Ｍａｓｋ、長さを決定するＣｏｍｂｉ＿Ｉｎｄｅｘ及びブロックを決定する個々のＭＩＤＩパッチ（及び関連した情報）のグループを決定するＧｒｏｕｐ＿Ｉｎｄｅｘである。

Ｃｏｍｂｉ＿Ｉｎｄｅｘは、ブロックサイズの多数のセットを含むＳｔｙｌｅ＿Ｔｙｐｅ＿Ｃｏｍｂｉと呼ばれている表を示している。各々のＢｌｏｃｋ＿Ｓｉｚｅは、合計ＳＥＱの長さになる一組のブロックサイズである。実施例ＳＥＱ長は、８つのＱＮである。

Ｇｒｏｕｐ＿Ｉｎｄｅｘは、スタイルグループ毎のＭＩＤＩ−タイプ情報のセットを含むＳｔｙｌｅ＿Ｇｒｏｕｐと呼ばれている表を示している。そして、好ましくは、ＭＩＤＩバンクによって構成される。ＰＣは、ＰａｔｃｈＣｈａｎｇｅＭＩＤＩ情報を対象とし、Ｐは可変に大きさを設定されたＭＩＤＩパラメータに与えられたＰａｔｃｈを対象とする。そして、ＧＳはグループの大きさを表す。グループ１のためのＧＳは、どれくらいの数の楽器がグループ１として定められるかについて示す。

このステップの実行の好ましい最適化は、特定のパッチ構成をＧＳによって識別されるグループから選択する擬似乱数発生器（ＰＲＮＧ）を組み込むことである。ユーザが特定のサブスタイルの範囲内でかつ特定のレーンの中で楽器の変更を選ぶとき、他のセットのパッチ情報はＧＳによって識別されるグループから選択される。ＰＲＮＧのこの使用はまた、異なる時間に、所与の歌曲、パート、サブパート、ＳＥＱ、ＲＰ、ＶＰ、その他に変化又は他の特性を提供するために楽器が変更され得る場合、歌曲の自動生成に取り入れることができる。当業者にとって明らかであるように、ＰＲＮＧ機能の使用から利益を得ることができるこのルーチンプロセスの他の適用分野がある。一旦ブロック持続期間及び楽器パッチ情報が所与のＶＰのために決定されると、図２５に示すように、バーチャルブロック情報はブロックごとに決定され得る。

Ｂｌｏｃｋ＿Ｌｉｓｔは、ブロックの大きさ及び楽器タイプを使用しているバーチャルブロックを決定することができるルーチンである。図２５に示すように、スタイルは好ましくは幅（すなわち１〜８のＱＮ）及びグループ（すなわち楽器グループ）によって構成されるＶｉｒｔｕａｌ＿Ｂｌｏｃｋ＿Ｄａｔａポインタの表に対するポインタである。Ｓｔａｒｔ＿Ｐｏｉｎｔｅｒが決定されると、ブロックデータはＶｉｒｔｕａｌ＿Ｂｌｏｃｋ＿Ｄａｔａ表を得ることができる。ブロックデータがすでに知られている場合（例えば、空のブロック、繰り返しブロック、その他）、特例が存在する。

また、パターン構造生成に関連して上述したように、全体処理の本ステップは付加的な多様性をブロックに提供するために任意のＰＲＮＧルーチンを用いることができる。この例の直接の拡張は、結果に充填をおく単純な手段を提供するために、「Ｓｔｕｆｆｉｎｇ」（すなわち、特定の表の入力を複製する）を使用することである。これによって、さまざまな二重のエントリを挿入することによってＶｉｒｔｕａｌ＿Ｂｌｏｃｋ＿Ｄａｔａ表から選ばれる特定のブロックデータに影響する能力を参照する。「Ｓｔｕｆｆｉｎｇ」この概念は、本明細書どこかで論じられた他の表に容易に適用することができる。そして、共通に従来技術において周知である各々の表引きのための結果に重きをおく他の手段を、本発明の精神と範囲から逸脱することなく、容易にここで使用することができる。

さらに、当業者が理解するように、好ましい実施態様のこれらの例の多数が表に対する相当な依存を含むけれども、その分野において共通に知られている状態マシンの概念をこれらのステップに適用し、そして状態マシンを組み込むステップにテーブルアーキテクチャを最適化することは、容易である。この種の最適化は、本発明の趣旨及び範囲から逸脱するものではない。例として、図１８Ｂに関する先の説明を参照する。

本発明の擬似乱数発生のためのさまざまな実施例を説明する。
現在の開示において論じられるいくつかの実施例は、好ましくは複雑な楽曲生成／対話装置を得るために、小さい携帯用アーキテクチャの限られた資源を最大にすることを含む。可能な場合、この種の実施例（そして、その他）で、別々のＰＲＮＧルーチンの数を最小化することが望ましい。楽曲生成／対話の類のアプリケーションが、同様にスタイル化された楽曲（人間をが作曲した楽曲）に匹敵するリアリズムの感覚を得るために、ＰＲＮＧ技術に相当依存するが、技術を携帯用用とするように、最終製品のコードオーバーヘッドを最小化して、かつ設計及び製造と関連する経費を最小化することが望ましい。従って、最小のＰＲＮＧコード／ルーチンとすることと、パート生成に最大限の随時的影響を与えることの競合する目標を持つことになる。

加えて、本技術の他の目標は、ユーザが効率的方法で歌曲を保存することができるようにすることである。オーディオストリームとして歌曲を記憶する（すなわち、ＭＰ３、ＷＭＡ、ＷＡＶ、その他）よりもむしろ、歌曲を生成するために用いた構成情報を保存することが望ましく、その結果、それは完全にオリジナルと整合した方法で再生することができる。５分のＭＰ３ファイルがほぼ５ＭＢであるとき、この目標の好ましさは容易によく理解され得る、そして、現在のアーキテクチャを使用すると、同一の歌曲のための対応するファイルサイズはほぼ０．５ＫＢであり、したがって、ほぼ１０，０００倍減少する。
ある好ましい実施例において、保存された歌曲の音質は、従来のコンパクトディスク（このことにより明らかにＭＰ３より良い）と類似している。この比較において、コンパクトディスクに記憶される５分の歌曲は、ほぼ５０ＭＢである。このように、本発明を使用している歌曲のファイルサイズは、ほぼ１／１００，０００にコンパクトディスクファイルから減少する。

オーディオストリームよりむしろ構成情報それ自体を保存することは、前に保存しておいた楽曲こ書き込むことができるという点で、ユーザが中断したところでそれを拾い上げ、そして作業を続けることを可能にする。この種の効果は、単一の、複合オーディオストリームによっては容易に可能ではなく、そして、音声を多数のストリームに分けることは、指数的にファイルサイズを増やして、可搬性及び／又は品質の重要なトレードオフのない現在のアーキテクチャにおいて実現可能ではない。

その上、本発明のこの態様は、ユーザが歌曲のいかなる位置からも歌曲を保存することを可能にする。ユーザは、楽曲作成を行って相互にやり取りをした後に、歌曲終了時に歌曲を保存することを決めることができる。それが楽曲作成プロセスにおいて、ユーザにより大きな柔軟性及び単純性を与えるので、この種の特徴は明らかに有利である。

図２６に戻ると、擬似乱数発生（ＰＲＮＧ）の若干の実施例のための好ましいアルゴリズムの状況を示す線図を示している。ドラムシード（ＤＳ）は、ＤＳ０−ＤＳ４を生成するために単純なＰＲＮＧルーチンに入力として使われる数である。当業者にとって明らかであるように、出力の数は可変であり得るが、説明の便宜上４をここで使用する。ＰＲＮＧから出る出力である４つの値は、ドラムパートに若干の疑似ランダム変化を提供するためにドラムパート生成アルゴリズムのさまざまな部分に入れられる。

単純なＰＲＮＧルーチンに対する同じシード入力が複数回使われる場合、値の同じリストが毎回出力される点に注意することが重要である。これは、、それらが、もともと、極めて繰返し性で予測可能であるコンピュータシステムの一部であるがゆえに、単純なＰＲＮＧルーチンが全くランダムでないことによるものである。たとえ数レベルの複雑性を、クロック等のような表面上無関係なものを利用するＰＲＮＧアルゴリズムに与える場合であっても、エンドユーザは楽曲生成の操作に、数レベルの予想を識別することができる。想像できるように、装置の主態様の１つが大量の良好な楽曲を生成することにあるので、これは非常に望ましくない。

単純なＰＲＮＧの予測可能な性質の一つの利点は、シード値を保存しておくことによって、後に同じアルゴリズムを使用して同一の結果を生成することができることである。同じアルゴリズム（又は、好ましくは互換もの）であると仮定すると、シードは入力として提供することができて、毎回、好ましくは正確な同じ結果を成し遂げることができる。楽曲生成／相互作用処理におけるシードの使用に関する更なる説明は、本明細書いずれかで論じられる。

繰返し可能なＰＲＮＧを組み込むことは本発明の特徴であるが、より「本当」の乱数発生アルゴリズムから利益を得るようにした本発明の態様も存在する。明確にするため、これを「複雑ＰＲＮＧ」と呼ぶ。図２６及び図２７の実施例を用いて、定期的に、同じシード入力がドラムパート及びバスパートのために使われる場合、それは結果の変動性を制限することになる。他の実施例では、前に保存された歌曲を演奏するとき、Ａ及びＡ’が常に同じことであることを望むけれども、新しい歌曲を生成しているとき、これらのシード入力がランダムに異なることはたいへん望ましい。一方、歌曲生成は、歌曲再生と同じ繰返し性が欠点である。

本発明に関する、コスト／資源束縛の範囲内で作用する複雑ＰＲＮＧの一つの実施例は、個々のユーザのボタン−押圧のタイミングを組み込むアルゴリズムを有するものである。例えば、時々楽曲を生成し、その生成処理でユーザ相互作用を提供する進行中に、単純なタイマーを初期化することができて、ユーザのボタン押圧を待つことができる。それから、そのタイマーの値は、ランダム状態を加えるために好ましくはＰＲＮＧルーチンに組み込むことができる。例として、システムが３３ＭＨｚ又はその近辺で動作している場合、任意の所与の時点とユーザのボタン押圧との間のクロック数がランダム状態をＰＲＮＧに与えるであろうことが理解される。他の実施例では、完了する主ソフトウェアループのための所要時間の情報を得続けるアルゴリズムを有するものである。この種のループは、ユーザボタン押圧、楽曲作曲変化のような外部イベントに基づいて変化するので、それが一つのループを完了するたびに実質的に完了する時間が異なる。外部イベンントのそれぞれは、種々のイベント又は動作、その他のために、他のルーティン及び／又はタイミングループ、又はそれに類したものを呼び出すことができる。シードから値の生成において、この種の複雑ＰＲＮＧを使用することは、上記した繰り返し性の問題のために望ましくないが、上記で論じられたように、シード、その他の生成においてこの種のＰＲＮＧを使用することは望ましい。付加実施例として、装置が時間通りに電源を入れられる瞬間から、「ｐｒｅｓｓ−ｉｔ−ａｎｄ−ｆｏｒｇｅｔ−ｉｔ」モードが起動される瞬間までの時限で、この種の複合ＰＲＮＧルーチンを使うことができる。このとき、ホームモード（この開示の初期に論じられた）の第１の自動演奏歌曲の選択にある程度のランダム状態及び変動性が提供される。もちろん、この種の複雑ＰＲＮＧは、本発明の変形であって、本発明を実施する上で必ずしも必要としない。

ある実施例において、一つの望ましい本発明の態様は、選択をエンドユーザに制限することを含む。楽器を演奏することができるさまざまな方法は無制限であり、ある種の構造がない場合、可能な方法の多数は耳に不快である。快い楽曲の一つの特徴は、それがある種の構造にかなうということである。事実、創造力の定義が構造を通じた表現であると論じることができる。楽曲及び／又は楽器の異なるタイプは、異なっている構造を有することができるが、それは聴取者が楽曲を解釈するためにフレームワークを提供するので、構造それ自体は楽曲のアピールに不可欠である。本発明は、楽曲の生成のシード値を使用する好ましいいくつかの態様を含む。シードを組み込むひとつの好まし方法は、楽曲にシードの２つのカテゴリを使用することである。すなわち、１）高レベルの歌曲構造を決定し／効果を与えるシード、及び２）決定し／特定の楽器パート及び特性を決定し／効果を与えるシードである。シードの第１のカテゴリは、ユーザが変えられられないが、スタイルサブスタイル及び楽器タイプ選択によって決定され／効果が与えられる。シードの第２のカテゴリは、ユーザによって変えられ、特定のパターン、メロディ、効果、その他に関する。この例の要点は、ある実施例で、最もユーザから遠ざけられる楽曲生成の観点があるということである。この変化は、ユーザが楽曲生成のために使われるシードの部分集合に直接アクセスすることを許容し、そして、それを通じて表現するためにユーザに構造を提供する。シードに関する本説明のこの好ましい実行で、非音楽的に訓練されたエンドユーザが創造的に楽しく聞こえる音楽を作成することができる。

しかしながら、ある場合には、ユーザにいくつか又はアクセス可能な選択の全てを与えることが望ましいこともある。例えば、楽曲の与えられたスタイルのために、特に適宜範囲に発生アルゴリズムが利用できるいくつかのパラメータ値を制限することが望ましく、ある場合には、ユーザが有効範囲を編集することができ、それによって問題のスタイルに若干の影響を及ぼすことが望ましい。別の例として、特定の楽器又は他の構成要素と関連する値の範囲は、歌曲のその楽器／構成要素の典型的役割と関係していてもよい。ある実施例で、受け入れられるパラメータのこの種の範囲は、ユーザがスタイル及び／又は楽器又は構成要素の制約を変えることができるように、ユーザ（例えば、コンパニオンＰＣプログラム、その他を経て）によって編集可能である。例えば、あるスタイルにおいて比較的高ピッチ可動性を有する楽器タイプ「リード」があってもよいが、ユーザがピッチ可動性に影響することができる「リード」と関連するパラメータを下げることができることが望ましい。マジック音符の線に沿った他の実施例、その他を、また、これらの具体化において都合よく使わうことができる。

本発明の歌曲を記憶する単純なデータ構造（ＳＤＳ）の好ましい実施態様のさまざまな例を以下に説明する。
ＰＲＮＧシードの使用は、歌曲を保存するための単純で極めて効率的な方法を可能にする。本発明の実施例において、歌曲はパラメータの小さい一組とともにシードのオリジナルの一組を使用して、記憶される。パラメータの小さい一組は、リアルタイムイベント及び楽曲ルールアルゴリズムに外付けの外部情報を記憶するために好ましい。上のＰＲＮＧ説明と整合した方法で、ＰＲＮＧシード値が、楽曲ルールアルゴリズムのための最初の入力として、好ましくは使われる。

図２８は、ＳＤＳの情報のタイプの若干の実施例の一覧を示す。
「ＡｐｐｌｉｃａｔｉｏｎＮｕｍｂｅｒ（アプリケーション番号）」は、データ構造を生成するために用いるファームウェア／アプリケーションのバージョンを記憶するために用いる。ファームウェアがアップグレード可能である場合に、これは特に有用である。そして、ＳＤＳは多数のユーザで共有することができる。ソフトウェア／ファームウェアの多数の生成／変化全体の互換性を組み込むとき、ＳＤＳを創作するために用いるソフトウェアのバージョンの情報を取得し続けることが好ましい。

「Ｓｔｙｌｅ／Ｓｕｂｓｔｙｌｅ（スタイル／サブスタイル）」は、楽曲のサブスタイルを示すために用いる。さまざまな変数及びルーチンを初期化するとき、特定のサブスタイルと関連するルールが歌曲生成処理を支配するシステムに警報を出すために、これは有用である。

「ＳｏｕｎｄＢａｎｋ（音響バンク）／ＳｙｎｔｈＴｙｐｅ」は、歌曲において使われる特定の音響を示す。これは、好ましくはＭｉｄｉＤＳＰのための音響設定を予め書き込む方法である。さらに、ある実施例で、これは音波の互換性について調べるために用いることができる。

「ＳａｍｐｌｅＦｒｅｑｕｅｎｃｙ（サンプル頻度）」は、サンプルがどれくらい演奏されるかについて指し示すために用いることができる設定である。あるいは、これはサンプルがデコードされる率を示すことができる、サンプル再生の周波数を調整することに役立つ技術である。

「ＳａｍｐｌｅＳｅｔ（サンプルセット）」は、音楽のスタイルを伴う全てのサンプルの一覧を示すためにある。これらのサンプルが歌曲の保存されたＳＤＳバージョンにおいて、全てを使うことはできないが、このリストによって、ユーザが歌曲再生の間、更に選んで、関連したサンプルを演奏することができる。

「Ｋｅｙ（キー）」は、その歌曲に使用される第一の調子を示すために用いる。これを示すひとつの方法はピッチオフセットを有することである。
「Ｔｅｍｐｏ（テンプ）」は、歌曲の起動テンポを示すために用いる。これを示す一つの方法は、毎分の拍子（ＢＰＭ）情報を有することである。

「Ｉｎｓｔｒｕｍｅｎｔ（楽器）」は、一群の楽器の特定の楽器を識別するデータである。例えば、一群の全てのギターの中の音響ナイロンストリングギターが鳴る。適切なこのデータは、楽器タイプによってインデックスを付けられる。

「Ｓｔａｔｅ（状態）」は、特定の楽器の状態を示すデータである。状態の実施例は、弱音、非弱音、標準、強制演奏、独奏、その他である。
「Ｐａｒａｍｅｔｅｒ（パラメータ）」は、さまざまな楽器パラメータ、例えば、音量、ｐａｎ、音質、その他のための値を示すデータである。

「ＰＲＮＧＳｅｅｄＶａｌｕｅｓ（ＰＲＮＧシード値）」は、擬似乱数生成（ＰＲＮＧ）ルーチンを初期化するために用いる一連の数値である。これらの値は、歌曲全体の再現を可能にするために、ＰＲＮＧの本質的に予測可能な性質を利用することによって歌曲を記憶する特に効率的な方法を表す。本発明のこの態様は、図２６及び図２７に関して更に詳細に論じられる。

ＳＤＳのこれらの実施例パラメータの使用で、ユーザ歌曲は、効率的に記憶され共有される。特定のパラメータタイプが可変であるが、この種のパラメータの使用は、この開示のいずれかで論じられたＰＲＮＧＳｅｅｄｓ同様に、必要な全ての詳細がゼロから歌曲を繰り返すことを可能にする。楽曲が非常に効率的なデータ構造によって忠実に再生されることができる種々の分野において、この種の装置の使用が有利であると思われる。

図２９は、本発明を実施するためにＳＤＳと結合して使うことができる一般的アーキテクチャのための論理フローチャートを表す。このフローチャートは、好ましいソフトウェア／ファームウェア実現のための概念を記述するもので、更に、歌曲がどのようにシード値を使用して、効率的かつ対話的に生成されるかについて詳細に記述する。

図２９の開始時に、シード値の最初の一組は、データファイル（例えば、ＳＤＳ）から書き込まれるか新たに決定される（例えば、複合ＰＲＮＧ方法を使用することは、この開示のどこかで論じられた）。値のこの一組が効果的に決定されて、この時点で歌曲全体のために書き込まれるが、新しく生成された歌曲にある程度のランダム状態を提供するために、必要に応じて楽節にそれらを決定し書き込むだけであることは有利であると考えられる。更に、上記のように、シード値は、２つのカテゴリ、すなわちユーザが変更可能なもの、及びそうでないもの、に分けることができる。若干のシード値が好ましくは決定されて／書き込まれると、与えられた歌曲パートのための楽曲が生成され始められ、そして、ユーザインターフェース（例えば表示、ビデオ出力、圧力フィードバック、その他）が更新することができる。この過程のいかなる時点でも、楽器又は効果の変更のような、ユーザ入力が検出される（「保存」コマンド以外）場合、ユーザによって現在変更されている歌曲のパートのための関連したシードが更新され、そして、与えられたパートのための楽曲の生成が継続する。ユーザ入力の「保存」コマンドが検出される場合、全てのシード（与えられた歌曲のためのまさに関連したシードではなく）は、非一時的記憶場所（例えば、フラッシュメモリ、ハードディスク又はある程度の遂行能力もつ余裕がある他の書き込み可能な若干のメモリ格納場所）に、保存することができる。ユーザが完全にそれを保存することに決める前に、大部分の歌曲を聞くことができるので、望ましい。ユーザ入力がない限り、歌曲パートの終了が検出されるまで、与えられた歌曲パートのための楽曲の生成が続き、その時、フローは次の歌曲パート部へ進む。この時、必要に応じて、次の歌曲パートのための関連したシードが決定されて書き込まれる。結局、歌曲の終端状態が検出されると、歌曲は終了する。

本発明の歌曲を記憶する複雑データ構造のための好ましい具体化のさまざまな実施例を、以下に記述する。
本発明に対する他の変形において、歌曲を保存し、再生するために、楽曲ルールアルゴリズム（上記ＳＤＳの説明を参照）への入力としてのシードに依存して、複合データ構造（ＣＤＳ）の使用と交換されてもよい。その効率性のために、進み／戻しの互換性が問題でないときに、上記で論じられたシードに基づくアーキテクチャは望ましい。しかしながら、それはプラットフォーム及び／又はファームウェア改訂全体の互換性が要求される場合、望ましくない若干の態様がある。これらの場合、別の実施例の使用が望ましい。

上記の通り、シードは好ましくは単純なＰＲＮＧに対する入力であり、歌曲作成アルゴリズムで使用する一連の値が生成される。歌曲保存及び再生のために、繰返し性は不可欠である。しかしながら、アルゴリズムがファームウェアの次のバージョンにおいて変更される場合、又は、他のアルゴリズムが単純なＰＲＮＧの使用から利益を得る場合、それが音列（シリーズ）（例えば、図２６のＤＳ０−ＤＳ３）を計算する中間にあるとき、又は、付加要素が次の楽曲スタイル、その他のために必要とされる場合であって、それらが付加的シードを含んでいるとき、反復性及び戻しの互換性を逆に挿入することができる。これは、本発明のあるアプリケーションにおいては、将来のアップグレードが重要な余裕を有することができ、かつアップグレードの前に保存される歌曲との戻し互換性を保持するために、歌曲を保存するための他のより複雑なデータ構造（コンプレックスデータ構造）が望ましいことを意味する。さらに、ある実施例では、ＰＲＮＧアルゴリズムがアップグレード可能／変更可能である場合には、シードの使用は望ましくない。

図３０は、この種のＣＤＳに含む若干の実施例パラメータを記載する。一般に、この構造と図２８に記載されているＳＤＳ実施例との間の差は、これが歌曲を再現するためにシード値に依存しないということである。その代わりに、このＣＤＳは、歌曲の実際のデータの中でより多くを捕獲する。そして、ＳＤＳ実施例より大きいファイルサイズとしてなる。ＣＤＳの利用は、上記したようにシード方法と関連して、オーディオストリームと比較して、歌曲を保存する場合により効率的で望ましい手段である。シード方法が１０，０００の典型的ＭＰ３オーディオストリーム上のサイズ減少を与えるが、ＣＤＳ方法は１，０００の概算サイズ減少を与える可能性がある。すなわち１００，０００のＷＡＶ音声のために、サイズ減少は１０，０００（又は、コンパクトディスクと比較してサイズ減少がほぼ１００，０００であるとき）としてなる。シード方法より非常に大きいので、これは、ＣＤＳ方法が従来技術の楽曲記憶のオーディオストリーム方法に勝る利点である。

ある実施例において、ＣＤＳにおける更なる差異は、それがリアルタイムにユーザデータ（例えば弱音化、フィルタリング、楽器変更、その他）を保存するという大きな能力を提供するということである。

両方の実施例はそれらの効果を奏するが、ハイブリッドデータ構造（ＨＤＳ）に各々の態様を結合することが有効である。例えば、また、ＣＤＳ実施例の複雑なパラメータ（コンプレックスパラメータ）をより多数を組み込むと共に、データ構造の若干のシード値の使用は、互換性及び効率の間で適当なバランスを提供することができる。アプリケーション及び状況に従い、図２８のＳＤＳ及び図３０のＣＤＳの間にあるハイブリッドデータ構造を用いて、これらの２つの目標間のバランスを調整することができる。

図３０の実施例において、「アプリケーション番号」、「スタイル／サブスタイル」、「サウンドバンク／合成タイプ」、「サンプル周波数」、「サンプルリスト」、「キー」、「テンポ」、「楽器」、「状態」及び「パラメータ」は、図２８に関して上記した好ましいパラメータである。

しかしながら、ある実施例では、歌曲の間、ユーザによって作動される多くのリアルタイムイベントを捕獲することが望ましい。これらの場合、すなわち「Ｐａｒａｍｅｔｅｒ（パラメータ）」なるパラメータを経て、ＣＤＳの一部としてリアルタイムデータを記憶することが好ましい。この例では、特定の楽器パラメータに対するリアルタイム変化は、関連タイムスタンプをつけて、ＣＤＳの「パラメータ」部分に記憶される。このような方法で、記憶されたユーザイベントは、歌曲再生においてリアルタイムで実行することができる。この種の実施例は、相当に大きなサイズを有するＣＤＳを含むが、ユーザに対して作曲のニュアンスの大きな制御を提供するので、望ましい。
「ＳｏｎｇＳｔｒｕｃｔｕｒｅ（歌曲構造）」は、歌曲中のパートの数及びシーケンス、並びに歌曲の楽器タイプの数の一覧を示すデータである。

「Ｓｔｒｕｃｔｕｒｅ（構造）」は、そのパートの範囲内のサブパートの数及びシーケンスを含むことができる、パートごとにインデックスを付けられるデータである。
「ＦｉｌｔｅｒｅｄＴｒａｃｋ（フィルタリングされたトラック）」は、効果の特性を記述するデータを保持するために用いられるパラメータである。例えば、それは矩形波及び特定の初期値を有する効果の変調タイプを示すことができる。効果が特定のパートと典型的に関係があるので、このパラメータはパートによってインデックスを付けることができる。

「Ｐｒｏｇｒｅｓｓｉｏｎ（進行）」は、各サブパートのための特性情報である。これは、署名、ＳＥＱｓの数及びシーケンス、マスキングすることができる楽器タイプのリスト、その他を含む。

「Ｃｈｏｒｄ（コード）」は、サブパートの期間での楽曲変更に対応するデータを含む。コードベクトル（例えば＋２、−１、その他）、キー音符（例えば、Ｆ）及び進行モード（例えば、昇順のドリアン）データがタイムスタンプを伴って保存される。

「Ｐａｔｔｅｒｎ（パターン）」及びサブパラメータの「Ｃｏｍｂｉｎａｔｉｏｎ（組合せ）」、「ＦＸＰａｔｔｅｒｎ（ＦＸパターン）」及び「Ｂｌｏｃｋ（ブロック）」は全て、歌曲において使われる各々の楽器のための実際のブロックデータ及び効果情報を含む。このデータは楽器のタイプによってインデックスを付けられる。

「Ｉｍｐｒｏｖ（即興演奏）」は、歌曲が演奏されるたびに異なって演奏される楽器又はマジック音符を特定するためのものである。このパラメータは、それらの即応の要素を有する曲の作成を許容する。

例えば、特定の歌曲と関連する音響バンクデータが組み込まれることを可能にするために、付加パラメータを含むことができる。この実施例に従い、この種のＣＤＳがアクセスされるときに、音響バンクデータを楽曲出力の生成期間中に使うことができるように、音声バンクデータはＤＳＰにアクセス可能な不揮発性メモリに書き込まれる。

図３１は、上記で論じられたＣＤＳ方法のための好ましい実施例フローチャートを表す。それは、フローのシードが書き込まれ、決定され、更新され、及び／又は記憶される時点で、ＣＤＳパラメータデータを書き込み、決定し、更新し、及び／又は保存する点を除いて、図２９と同様である。なお、ＣＤＳパラメータデータは、「歌曲構造」、「フィルタリングされたトラック」、「コード」、「パターン」、「楽器」、「状態」、「パラメータ」及び「即興演奏」に対応する。

ある好ましい実施例において、プレーヤ１０は、ＰＣシステム上で実行し、データリンク（例えば、ＵＳＢ５４、シリアルＩ／Ｏ５７及び／又は８０２．１１ｂ、ブルーツース、ＩＲＤＡ、その他のような無線リンク）を介してプレーヤ１０と通信するコンパニオンＰＣソフトウェアシステムを具備する。この種のＰＣソフトウェアシステムは、ユーザにプレーヤ１０及び他の場所（例えば、ＰＣハードディスク、インターネット、他の装置、その他）の間でファイルを複製する簡素で有効方法を提供する。例えば、コンパニオンＰＣソフトウェアプログラムは、オペレーティングシステムのＭＳ−Ｗｉｎｄｏｗｓファミリの下で動作して、ローカルプレーヤメモリ（例えば、ＳＭＣ）と同様に、プレーヤ１０の全ての機能及びモードのために、ユーザへの完全なアクセスを提供する。この実施例によれば、ユーザは、インターネットに接続して、プレーヤ１０上で楽曲スタイル又は歌曲に関連すべきカスタマイズされたユーザ選択可能なグラフィクス等のユーザインターフェース関連のファイルと同様に、プレーヤ１０（例えば、ＭＩＤＩ、ＷＭＡ、ＭＰ３、カラオケ、ＣＤＳ、ＳＤＳ、その他）で使うために適切な楽曲関連ファイルを、アップロードしたりダウンロードすることができる。この種のコンパニオンＰＣプログラムは、ハードウェア及び／又はソフトウェア管理機能が容易に管理される（例えば、ファームウェア及び音響バンク更新）ことを可能にするために用いられる。このコンパニオンＰＣソフトウェアシステムは、ユーザに楽曲構成要素及び／又は完全な歌曲を世界中の他のユーザと（例えば、ＦＴＰアクセスを経て、電子メールへの添付物として、ナップスターのようなピアツーピアネットワークソフトウェアを経て、等）共有する簡単な方法を提供するために用いられる。ここで留意すべき重要な事項は、潜在的に使用料免除の性質及びプレーヤ１０からの楽曲出力の最大のサイズ効率化が、公開ソースファイルを共有するというインターネット環境に、役立つということである。

ＰＣシステムに結合される携帯用システムを含む上記実施例に加えて、又はそれとの組合せにおいて、ある付加的特徴は、ある実施例において好適に使用される。例えば、コンパニオンＰＣソフトウェアプリケーションは、例えばＰＣディスプレイを介して、選択されたサンプルの波形と関連するグラフを表すためにサンプル編集モードを提供する。これらの実施例において、マウスのようなポインティングデバイスを介して、ユーザに、サンプルの始点及び終点を容易に選択する方法が提供される。この種の図形切り落とし機能は、ユーザが、例えば望まれていない部分、その他を取り除くために、選択されたサンプルを容易に切り取る（クリップする）ことを可能にする。サンプルのクリッピング／クロッピングの後に、新しく短くされたサンプルファイルを、例えば、新しい名称をつけて保存するオプション選択がユーザに示される。この種のクリッピングに加えて又はクリッピングなしの他の類似した機能は、ディスプレイ及び／又はＰＣシステムで利用可能な資源処理を使用し、選択されたサンプルの波形のグラフィックバージョンを提供し、そして、持帰りに単純な方法でエンドユーザに選択されたサンプル上での基本操作実行するための簡単な方法をユーザに提供するために、サポートされる。これらの実施例において、新しく変更されたサンプルファイルは、その後、携帯用システムに、例えば、図３２のコネクタ５３（例えば、ＵＳＢバス５４及びＵＳＢインタエフェイス３９、その他を経て）を経て転送可能である。

リンク（例えば、無線８０２．１１）が複数の装置の間に存在する実施例において、装置は協働モードにおいて動作することができる。該モードでは、第１のユーザ及び／又は装置が、楽曲の少なくとも１つの態様（例えば、１つの楽器又は効果）に関するパラメータを管理しており、第２のユーザ及び／又は装置が、楽曲の第２の態様（例えば、他の楽器、又はマイク、その他）に関するパラメータを管理している。これらの実施例において、複数の装置は、楽曲生成に関するある楽曲イベントと同様に、楽曲スタイルに関する情報を交換する。ある実施例において、例えば共通にアクセス可能なデジタルオーディオストリームを経て、結果として生じる楽曲を共通に聞くことができる。さらに、当業者に明らかであるように、ネットワーク（例えば、ＬＡＮ及び／又はインターネット）に接続されるとともに、１以上の装置がコンピュータである実施例において、上述した協働モードは都合よく利用され得る。

本発明のハードウェア実現実施例のための好ましい具体化のさまざまな実施例を、以下に説明する。
図３２は、本発明の一つの携帯用ハードウェア装置３５の実施例のブロックダイヤグラムである。内部ＲＡＭを含むマイクロプロセッサ（ＭＰ３６）は、ローカルアドレス及びデータバス（ＭＰアドレス３７及びＭＰデータ３８）を制御する。汎用シリアルバスインターフェース（ＵＳＢ３９）、スマートメディアカードインターフェース（ＳＭＣ４０）（すでに論じられたように、スマートメディアの変形例として、フラッシュ又は他のメモリカード、又はハードディスク装置等のような他の記憶媒体が本発明によれば使うことができる）、及びフラッシュ４１のようなメモリは、ＭＰデータバス３８上に存在する。そして、ＭＩＤＩ／音声ＤＳＰ（ＤＳＰ４２）は、ＭＰアドレスバス３７及びＭＰデータバス３８上に好ましくは存在する。ＳＭＣインターフェース４０はＭＰＤａｔａバス３８の間にバッファ５９を有し、そして、キーボードインターフェース４２（ＭＰデータラッチ４４を有して）及びＭＰバスとも関連するＬＣＤインターフェース４５が存在する。この例では、ＭＰ３６は、入力データストリームからタイミング情報を得て、ＭＩＤＩ情報（この開示のいずれかで論じたＮＲＰＮ−タイプデータを含む）をＤＳＰ４２に送信するためにシーケンサとして働くことができる。ＤＳＰ４２は、ローカルＲＡＭ４８及びフラッシュ４９メモリへのアクセスを提供する専用アドレス及びデータバス（ＤＳＰアドレス４６及びＤＳＰデータ４７）をさらに有する。

ＭＰ３６、ＤＳＰ４２、ＦＭ受信機５０及びマイク入力５１は全て、ＤＳＰ４２に伴うハードウェアＣＯＤＥＣ５２への数種類の入力を有する。
図３２の左上のコネクタ５３は、ドッキング局インターフェースとして又は純粋なＵＳＢインターフェース又は外部電源インターフェースと考えることができ、好ましくはＵＳＢ５４、電源５５、蓄電池充電５６、シリアルＩ／Ｏ５７及び音声Ｉ／Ｏ５８を備えて完成することができる。本発明のドッキング局（ステーション）７０のための実施例のブロックダイヤグラムが、図３４に示されている。図３４に示されているように、ドッキング局７０は、ローカルマイクロプロセッサ（ＬＭＰ７１）を含み、ＵＳＢインターフェース７２、アドレス及びデータバス（ＬＭＰＡＤＤ７３及びＬＭＰＤａｔａ７４）、ＭＩＤＩＩ／Ｏインターフェース７５及びメモリ（例えば、フラッシュ７６）を備える。その上、ドッキング局７０は、音声コーデック７７、ビデオＩ／Ｏインターフェース７８、及び電源７９を含む。

任意の類似したマイクロプロセッサを利用することができる（オンボードフラッシュ、より多くのＲＡＭ、より速いクロックを有して、より低電圧／より低消費電力、その他を有するバージョン等）が、この例のＭＰ３６は、ＡＲＭＡＴ９１Ｒ４０８０７である。このＡＲＭコアは、３２ビット及び１６ビットの２セットの命令を有する。１６ビットが組み込みシステム（フラッシュ、ＵＳＢ、ＳＭＣ、その他）でよく動作し、３２ビット命令が大容量データが通過する状況で効率的に働くという点で、多様な幅の命令をもつことは、所与のタイプのアプリケーションにおいて望ましい。
命令ビット長を変更することは、本発明の下で容易に可能である。

３２ビット命令のために、本発明のシステムは、ＭＰ３６の内部ＲＡＭに、フラッシュメモリ４１からある命令を予め書き込む。これは、フラッシュインターフェースが１６ビットであり、３２ビット命令を実行することは、少なくとも２サイクルを要するからである。また、フラッシュメモリ４１には、通常、読出し動作に関連する遅延がある。一つの実施例において、遅延はほぼ９０ｎｓである。この遅延は、典型的な読出し動作における多数の待ち状態（例えば、２）の発生の原因となる。逆にいえば、ＭＰ３６の内部ＲＡＭには、読出し動作と関連する非常に少ない遅延があり、したがって、より少ない待ち状態（例えば、０）となる。もちろん、内部ＲＡＭはこの場合３２ビット幅であり、したがって、３２ビット命令の効率が実現される。

フラッシュメモリ４１の待ち状態に関する実施例で先に示されているように、内部ＭＰＲＡＭの使用を最大にすることが望ましい多くの理由がある。図３２から判るように、本発明のこの実施例は、ＳＤＲＡＭ又はＲＤＲＡＭを含まない。メモリ手段のこれらのタイプをこの種のシステムに含むことができ、そして、この種の使用が本発明の趣旨及び範囲から逸脱するものではないが、図３２に表されるような携帯用アプリケーションでは、比較的不必要なもの（例えば、ＳＤＲＡＭコントローラ及びアドレス論理、その他）の使用は、好ましくない。図３２の本実施例は、携帯用機器に適している単純な設計で、本発明の多くの利点を達成する。

複雑性及び携帯性と関連するトレードオフの実施例は、マイクロソフトからの広く利用可能なＷＭＡオーディオデコーダアルゴリズムの使用である。この例では、３２ＭＨｚ／３．０Ｖで図３２のＡＲＭＭＰを作動するときに、４４ＫＨｚで、かつ、１２８Ｋｂｐｓのサンプル率でＷＭＡ符号化された歌曲をうまくデコードし演奏するために、アルゴリズムをデコードしているマイクロソフトのＷＭＡを組み込むことができる。しかしながら、本明細書のどこかで論じられたように、オーディオストリーム歌曲の速度を調整することができる好ましい特徴も、また、組み込むことができる。この場合、調速を使用してＷＭＡ４４ＫＨｚ歌曲の速度を上げるとき、図３２のシステムを実行状態にすることは可能である。この具体例において、ＡＲＭＭＰ３６が４０ＭＨｚ／３．０Ｖで作動されるときに、この種の事態は起こらない。しかしながら、４０ＭＨｚ／３．０ＶでＭＰ３６を作動するときに、バッテリ寿命上の重要な性能ヒットが起き得る。それで、ピッチ速度の特徴と結合する４４ＫＨｚのＷＭＡの使用が比較的不必要なようであるので、この特定の実施例特徴は、バッテリ寿命を長くするために犠牲にしてもよい。以下のような変形を組み込むことができることが明らかであろう。すなわち、より良い電池システム、プラグ接続されたときに全速で、そして電池を使用するときにより遅い速度で動作する段階速度手法、より効率的なＷＭＡアルゴリズム、その他である。しかしながら、この実施例は、競合する必要性が性能と携帯性とで釣り合うことができることを示している。

図３２の実施例において、ＭＰ３６は１３６ＫＢの内部ＲＡＭを含む。上述の性能／携帯性の釣合いは、１３６ＫｂのＲＡＭの効率を最大にするために、システムに対してある秘訣をこらさなければならないことを示している。例えば、メモリ値域は、好ましくはバッファリング、プログラム、その他のための異なる領域に分けることができ、そして、リアルタイムモード（例えば、ＷＭＡ再生）で、コードのために使用するパーセントを最大にすることができ、そして、バッファのために使用するパーセントを最小化することができる。他の別の実施例は、フラッシュメモリ４１の使用の減少又は省略を可能にする、内部ＲＡＭ（例えば、５１２ＫＢ）を有するＭＰ３６である。この種のシステムは、総経費を増大させる可能性があるが、上記で論じられたフラッシュメモリ４１を使用することに関連する複雑さを減少させる。

他の変形は図３３に示される実施例である。該実施例は、付加ＲＡＭ９０がＤＳＰバスにアクセス可能である図３２のローカルＤＳＰ領域を備えている。この種の付加ＲＡＭは、迅速かつ頻繁に演奏される大きいＭＩＤＩサウンドループを一時的に記憶するために用いることができる。ＲＡＭ９０は、また、予め書き込まれ、かつ迅速に演奏される１又は複数の音響ストリーム（例えば、ＰＣＭ）を一時的に記憶するために用いることができる。この特徴なしで、リアルタイムで、それが使われるたびに、各々のサンプルは管理されて、ＭＰによってＤＳＰに送られることを必要とする場合がある。これは本発明のある実施態様の課題ではないが、音響ストリームの広範囲な使用が要求されるとき、図３３に示すように、この種の付加ＲＡＭ９０を使用することが有利である。そのような場合、図３３のＲＡＭ９０の典型的容量は、好ましくは５１２ＫＢである。そして、ＭＰは、局所的に保存されたストリームを演奏するための命令を、ＤＳＰに送信することを必要とするだけである。

図３２に示されるアーキテクチャに関する説明を続ける。図３５は、ＭＰの内部ＲＡＭのためのアドレスマップのための一つの実施例を記載する。マップの一番下から始まって、下部２つの区分は、しばしば使われるライブラリ及びルーチンを示し、ＲＡＭに常に書き込まれる。「マルチ使用」とラベルをつけられる中間部が、ＳＭＣからＷＭＡ、ＭＰ３及び／又は他の同じように符号化された音声歌曲の再生の間、ＷＭＡ／ＭＰ３に関連したコード用として使われる。しかしながら、ｅＤＪモードのような他のモードの間、この中間部が、ブロック、歌曲及びＳＭＣ緩バッファのために使われる。この領域上の次の区分は、ストリーミング媒体のためバッファとして使われる。この区分は多くの小区分に分けられ、そして、各小区分は一定の間隔（例えば、５．８ｍｓ＠４４．１ｋＨｚ、１６ビット、１Ｋｂブロック）で、ＤＳＰ装置に送られる。図３５の上端は、変数及び一般のバッファのために使用されるＭＰＲＡＭの多目的領域である。

この例では、プレーヤがＷＭＡ／ＭＰ３／その他のモードで動作していないとき、「マルチ使用」中間部は、最低３種類のバッファ用として使うことができる。ブロックバッファが、動作中ブロックデータを記憶するために、ｅＤＪブロック作成アルゴリズム（例えば、図２４及び図２５）によって使われる。ブロック作成が起こったあと、歌曲バッファが歌曲データ（図１５を参照）を記憶するために、ｅＤＪアルゴリズムによって使われる。この歌曲データは、図３２に示されるＤＳＰ装置に供給される。ＳＭＣバッファは、ＳＭＣに書込み動作のために使われる。

ＳＭＣは、単一のビットの変更を可許容しないフラッシュメモリ技術である。ＳＭＣに書き込みを実行するために、全てのＳＭＣブロックを読出し、ＳＭＣブロックの所望の部分を更新し、そして、ＳＭＣブロック全体をＳＭＣに書き戻ししなければならない。効率のために、現在使用されているＳＭＣブロックがＳＭＣバッファにおいて保持される。

理解し得るように、上記したシステム構成は、ＳＭＣへの書き込みをしながら、同時に大きいＷＭＡ／ＭＰ３ストリームを再生することはできない。このことは、２つの機能のどちらか一方が同じメモリ領域を使用することによる。これは、限られた資源の創造的な使用である。その理由は、ＳＭＣに書き込むと同時にＷＭＡ／ＭＰ３を読出すことは、比較的珍しい状態であるからである。したがって、コードは同じ場所に記憶される。この種の装置は、図３２のような携帯用の環境の限られた資源の使用を最大にすることが可能である。

しかしながら、よりパワフルな環境（付加資源及び／又はより速いクロック数を有した）では、メモリの割り当て領域のこの「マルチ使用」を除去することができ、そして、ＷＭＡ／ＭＰ３及び記録機能の同時使用を容易に実現することができる。携帯用の環境に用いられるこれらの付加拡張は、他の本発明の態様を制限するものではなきことは明らかであろう。

上記のシステムは、携帯用であるが、極めて高品質の音響を有する。基本レベルにおいて、これは、部分的にはＰＣシステムにおける最高級品の音響カードで典型的に見出される音響チップの使用によるものである。ＳＡＭ９７０７チップはその優れた音響性能のゆえに好ましい。しかし、これは、本願明細書において論じられる携帯用実施例で動作するようにするためには、ある種々の適合を必要とした。

ＳＡＭ９７０７の一つの特性は、それが音響カードのＳＤＲＡＭと協調するように構成されるということである。このＳＤＲＡＭは、通常動作の間、ＭＩＤＩ音響バンクを保持する。この種の音響バンクは、ＤＳＰ対応システムからの出力である楽曲の最終的な音質の重要な部分である。事実、この特定のチップが好ましい他の理由は、カスタム音響を設計することができることである。

携帯用システムについての上記実施例において、アドレス論理と同様に、ＳＤＲＡＭは必要電源を増大させてしまう。したがって、好ましくはローカルＤＳＰ音響バンク記憶装置（図３２を参照）としてフラッシュメモリを使用して、構成の変形を行うことが望ましい。ユーザにそれらの携帯用プレーヤシステムの音響バンクをアップグレードすることを許容するために、ローカルＤＳＰフラッシュメモリがアーキテクチャのＭＰ側からアクセスされるようにすることが必要となるので、ローカルＤＳＰ記憶装置としてのフラッシュメモリの使用は、ある種の問題を含む。ＤＳＰバス及びＡＲＭＭＰバスの双方からのメモリアクセスを備えることにより、この種のアクセスは、デュアルポートフラッシュメモリの使用によって得ることができる。しかし、デュアルポートアーキテクチャは、経費及び複雑さシステムに付加する。

一方で低電力／単純なアーキテクチャを保持し、他方で高品質でアップグレード可能な楽曲音響バンクを提供することの間のバラスを適切にするという課題は、ＤＳＰチップのモードを適応させて、アドレス論理を、ＤＳＰがＭＰ側からローカルＤＳＰフラッシュメモリまでアクセスを提供することに「トリック」されることができる、というような方法で、カスタマイズすることによって好ましくは解決される。

図３６は、ＤＳＰローカルＲＡＭ及びフラッシュ記憶のアドレス空間の実施例を記載する。マップの一番下から始まって、第１の区分は、ファームウェア用であり、フラッシュメモリ領域にアドレス指定される。次の区分は、好ましくは音響バンクであり、フラッシュ領域にアドレス指定される。第３の区分は、信号Ａ２４がアクティブな（この場合、Ａ２４はアクティブロウすなわち０である）ときに、フラッシュにアドレス指定される。信号Ａ２４については、以下でさらに論じられる。開始アドレス０ｘ１００００００での第４の区分は、いかなる記憶場所にもアドレス指定されない３２ＫＢ３２ＫＢブロックである。第５の区分は、３２ＫＢであり、ローカルＤＳＰＲＡＭ（ＲＡＭａとラベルをつけた）にアドレス指定される。この領域を対象にするとき、信号Ａ２４が好ましくは高いことに注意すべきである。開始アドレス０ｘ２００００００での第７の区分は、ＲＡＭ（ＲＡＭｂとラベルをつけた）に分解する３２ＫＢの区分である。２つの３２ＫＢのＲＡＭ領域は、望ましくは６４ＫＢのローカルＲＡＭに統合される。

それで、特にＰＣ用の音響カードのその意図された状況において、ＤＳＰチップの一般的使用に対する本発明の第一の変形は、ＲＡＭａのアドレス位置である。ＤＳＰ−ローカルＲＡＭ及びＤＳＰローカルフラッシュメモリの間に、Ａ２４のアサートによりＲＡＭａアドレスの宛て先を切り換えるために、この領域は非常に単純なアドレスデコードロジック装置（好ましくはＤＳＰの外部から）を許容するように選ばれる。この変形は、ＲＡＭａの特定の位置が起動時にデフォルトによって適切に設定されることを許容するファームウェア変更態様を含む。初期化の後、この位置を変更する他の方法がある。しかし、それらは、より複雑であって、したがって、本方法ほど望ましくない。

ＤＳＰチップアドレスマップの意図された状況に対する他の変形は、音響バンクがＤＳＰチップのローカルフラッシュフラッシュメモリに位置する場合であっても（音響バンクのアプグレードのために典型的にアクセス可能でない位置）、音響バンクがアップグレードされることができるＤＳＰＢＯＯＴモードの創造的な実現を含む。

この例では、ＤＳＰのＢＯＯＴモードによって、内部ＲＯＭから実行する内部ブートストラッププログラムが生じる。ＤＳＰファームウェアをアップグレードする際、このブートストラッププログラムが用いられる。このように、内部ブートストラップは、１６ビットのバースト転送ポートから２５６語を受け取ることを期待される（それはローカルメモリのアドレス範囲０１００Ｈ−０１ＦＦＨでそれを記憶することが期待される）。そしてその後、ブートストラッププログラムは、アドレス０１００Ｈで制御を再開する。この比較的小さいバーストは固定されており、音響バンクを含むには十分な大きさではない。さらに、上記のようにＳＭＣと関連して、それは複合フラッシュメモリ書込み動作を可能にしない。ＳＤＲＡＭの代わりにフラッシュを使用する設計なので、ＡＲＭＭＰバスからＲＡＭまで特別なコードの転送を実行するために、ＲＯＭブートストラップを「トリック（取る）」するコードをローディングするために、このブートストラップバーストを使用することがたいへん望ましいことがわかった。そして、この特別なコードは、ＡＲＭＭＰバスからフラッシュメモリまで、音響バンクアップグレードデータの転送を実行するために用いられる。

図３７は、ＤＳＰブートストラップモードアドレス概念のこの珍しい使用において付加情報を提供する単純な真理値表である。図３８は、珍しいＤＳＰアドレス論理の効用を強調する、より詳細な真理値表であり、ＢＯＯＴ信号を用いて、ＡＲＭＭＰによって制御可能なＡ２４信号の好ましい使用を含む。

本実施例では、ＤＳＰによって生成されるＡ２４アドレス線は、ＤＳＰローカルメモリのロジックをデコードしているアドレスに提示される前に、ＭＰによって制御されるＢＯＯＴ信号によって変えられる。この手段によって、ＭＰがＤＳＰによるＲＡＭ及びＢＯＯＴモードのフラッシュ選択を逆にすることができ、そして、ＲＡＭがアドレス０ｘ１００で利用できるために、ＲＡＭがアップグレードコードを受信することができる。

上述されたハードウェア装置に対する付加変形も考慮することができる。例えば、電力レベルが増加し、そして、ＭＰパフォーマンスが増加する場合、ＤＳＰはソフトウェアＤＳＰに置換することができる。その場合、音響が低質として可能性があるが、より低いコスト、付加柔軟性等の、それを上回る他の利点を生じる。ＤＳＰは、同様に、低質な音響の結果となる可能性があるが、携帯性の利便性等の利点が上回る汎用ハードウェアＤＳＰと取り替えられることができる。ＭＰは、より多くの統合インターフェース（例えば、ＵＳＢ、ＳＭＣ、ＬＣＤ、その他）及び／又はより多くのＲＡＭ、高速クロック、その他を有するものと置換することができる。いくつかの開示された実施例に対する２、３の変更を加えて、ＤＳＰ（別個のＭＰでない）だけ又はデュアルダイＤＳＰ／ＭＰ又はＭＰ及びソフトウェアだけを有する本発明を実施することができる。加えて、オーディオ出力を保存するために、ＳＭＣメモリ記憶装置は、組み込み暗号を有するセキュアディジタル（ＳＤ）メモリカード及び／又はハードディスク装置、コンパクトフラッシュ、書き換え可能なＣＤＲＯＭ、その他に代用できる。また、ＬＣＤは、他のレベルのユーザインターフェースを許容するカラー又はマルチレベルグレーＬＣＤ及び／又は接触検知ディスプレイにアップグレードできる。

本説明の更なる変形は、ユーザインターフェースに付加的に望ましい特性を提供するために、Ｓｙｎａｐｔｉｃｓから入手可能なＴｏｕｃｈＰａｄのような、電磁性か容量性のタッチパッドポインティングデバイスの組み込みである。前述のタッチパッド及び接触感応ディスプレイは、ユーザに対して、リズムにあわせてたたくための及び／又は音符／コードをつま弾くための方法を提供するために用いることができる。この種の装置は、特定の楽器グループの操作により近い近似を可能にするために、用いることができる。例えば、タッチパッドは、ユーザが指又は手をタッチパッドの表面を横切って動かす方法から、ユーザの所望のギターパートの速度及びリズムを検出するために、用いることができる。同様に、この種のポインティングデバイスのｘ及びｙ座標を通して、ユーザ手の動きは、ピッチ及び／又は楽器の周波数、又は効果又はサンプルの特性と関連して検出することができる。他の例では、タッチパッドポインティングデバイスは、また、従来のＤＪがターンテーブルによって生成することができるスクラッチ音響に近似しているターンテーブルスクラッチ音の生成／制御を行うために用いることができる。

図３２に示すように、本発明において使うことができるＤＳＰの一つの実施例は、Ａｔｍｅｌ社の子会社、ＤｒｅａｍＳ．Ａ．から入手可能なＳＡＭ９７０７チップである。この特定のチップは、入来するＭＩＤＩ及びオーディオストリーム情報を扱うことが可能である。

ＤＳＰを生成的／対話的な楽曲システムに組み込むとき、ＭＩＤＩ及びオーディオストリームを同期させることが非常に望ましい。毎回、サンプルを正しい時間、正確に演奏しなければならないが、オーディオストリーム構成要素がＭＩＤＩイベントとの同期から僅かにずれたとき、結果として生じる楽曲の出力は、通常許容しがたいものである。ＳＭＣ技術が反応するのが遅くて、複雑な読出し方策が必要であるという点で、生成／相互対話概念において、オーディオストリーム及びＭＩＤＩのミキシングのこの微妙な性質は、フラッシュ読出し処理の性質によって悪化する。フラッシュ記憶場所から正確に音声の再生をＭＩＤＩイベントに同期させることはむずかしい。サンプル（ＭＩＤＩイベントと比較して）をデコードして、演奏することの遅れのため、タイミング補償を実行するか、又は比較的大きいデータバンクを予め書き込むかにトレードオフがある。これらの問題のため、ＤＳＰチップとともにＭＩＤＩ及びオーディオストリームを使用する新規な方法を構成することが好ましい。本発明の本態様がＤＳＰアーキテクチャに関して論じられるが、以下の実施例が他の類似したアーキテクチャにあてはまることは、ＭＩＤＩ／オーディオストリーム同期の分野における当業者にとって明らかであろう。

図３９は、楽曲生成処理におけるＭＩＤＩ及びオーディオストリームの簡略化した論理的配列を示す。Ｓｙｎｔｈへの２つの入力は併合され、デジタルオーディオ出力信号に変わる。この出力信号は、それからデジタル−アナログ変換器（ＤＡＣ）に供給され、ヘッドフォン等で使う適切なアナログ音声信号となる。この実施例では、Ｓｙｎｔｈに対するＭＩＤＩ入力は、比較的速いメモリ手段（例えば、ＳＲＡＭバッファ）から供給されるが、Ｓｙｎｔｈに対するオーディオストリーム入力が比較的遅いメモリ手段（例えば、フラッシュメモリ）から供給されることに注意する必要がある。

Ｓｙｎｔｈ装置に対する２つの入力は、実際に多重化バスを共有することができる。しかし、論理上、それらは別に識別可能な入力と考えることができる。一つの実施例において、２つの入力は、１６ビット幅のバスを共有する。この場合、ＭＩＤＩ入力はあるには好ましくは８ビットを占め、そして、オーディオストリーム入力は他の時間に１６ビットを占める。この実施例に従い、一つのストリームは休止することができ、他のストリームがバスを獲得することができる。同じバスのこの種の交互使用は、各々のストリームの比較的小さい中断が常に起こっていることを意味する。この種の休止はごくわずかであり、したがって、ここではその目的のために、２つのストリームは別個であると考えることができる。

図４０は、簡略ＭＩＤＩ／オーディオストリームスケジュールを示す。図４０がブロックのまさしくその始まりのためのタイミングであると仮定する。この場合、設計者がＭＩＤＩ音符の演奏を望み、ブロックの始まりから２５０ｍｓ後に開始して５００ｍｓ続くものとする。音符の継続期間は、演奏されている音符のタイプに関係する。例えば、それが４／４拍子の四分音符で、２秒の拍子持続期間をもつ場合、５００ｍｓは四分音符持続期間と一致する。また、図４０に示すように、短い音声サンプル「ｙｏ」のようなオーディオストリームイベントが、ＭＩＤＩイベントの中間で起こるように同期される。サンプルを楽曲状況に同期させることによって、ユーザ側の小さいタイミングエラーの微妙な修正を含むことができるという意味で、この方法によってサンプルが、楽曲に好ましくは量子化されることができる。

この例では、主に上述したシステムアーキテクチャ実施例の制約のために、従来の技術を一貫して正確に使用する上で、些細なものでない。オーディオストリームイベントが、ＡＲＭＭＰからの１又は複数のアシスト（ＳＭＣから音響をとってくること、解凍すること（ＰＣＭ，その他）、音響効果を加えること（残響、フィルタ、その他））を必要とすることを考慮すると、ＭＩＤＩイベントが、Ｓｙｎｔｈチップによってほぼ直ちに生成されることは好ましいことである。

この例では、各々のイベント及び専門的な非登録パラメータ多数（ＮＲＰＮ）のためのデルタ拍子情報を含んでいる特別なＭＩＤＩファイルを創作することが望ましい。サンプルリスト（上記したような）によって使われるときに、リストの特定サンプルの名前が内在するので、この特徴は特に有利であり、そして、ＮＲＰＮは、好ましくは特定のサンプル名又はタイプを明示的に必要とすることのない特定のサンプルリストの異なるサンプルを起動させるために、用いることができる。この種の最適化は、名前で特定サンプル又はタイプを取ってくるロードを軽減し、使用するサンプルが予め書き込まれることを許容する。以下の説明において、ある実施例では、ＭＩＤＩシステム独占（Ｅｘｃｌｕｓｉｖｅ）メッセージ（ＳＹＳＥＸｓ）の使用が、ＮＲＰＮ代わりに（又はそれに加えて）使われる、と理解すべきである。

図４１は、音声サンプル及び効果を有するＭＩＤＩイベントの効率的な同期を可能とするために本発明に組み込まれるＭＩＤＩＮＲＰＮの実施例を表す。左欄は、ＭＩＤＩＮＲＰＮストリームを形成している１６進値を表す。ＭＩＤＩ仕様書（先に引用組み込みしたものとする）に関し、従事する誰もが理解するように、ＭＩＤＩＮＲＰＮは、ＭＩＤＩストリームの部分のカスタムメイドの使用を可能にするデータ構造である。したがって、それは、与えられたアーキテクチャのための特定のカスタムイベントを起動させるために用いることができる。

図４１において、それが第１の１６進値「Ｂ０」は、ＭＩＤＩコントローラコマンドであり、チャネル番号を示す。これは、マルチチャネル装置の経路選択を助けるために用いることができる。本実施例において、単純性のために、チャネル０が設定されているものとする。第２の値「６３」は、この特定のストリームが特定のコントローラ（例えば、「Ａ」）のためのＮＲＰＮ情報を含むことを示す。この例では、ＮＲＰＮコントローラＡは音声サンプルタイプを示すために、ファームウェア／ソフトウェアによって理解される。第３の列値「４０」は、コントローラと一致するデータであり、実施例では、このデータはサンプルのタイプを記述する。この装置の効用の例として、タイプが「長音」と設定される場合、ファームウェア／ソフトウェアはかなりの量のサンプルを書き込むよう手配することができる。他の例では、サンプルのこの「タイプ」は、長いサンプルと短いサンプルとを区別するために用いることができるので、アルゴリズムが自動作曲の間、それらを別々に使用することができる。第４の列は、ＭＩＤＩｔｉｃｋｓにおけるデルタ時間を示し、正確に次のイベントを計時するために用いることができる。説明を簡単にするため、この例において、このデルタ時間は「００」に設定されるものとする。第５の列は、この特定のストリームが「Ｂ」コントローラのためのＮＲＰＮ情報を含むことを示す。この例では、ＮＲＰＮコントローラＢは、音声効果タイプを示すために、ファームウェア／ソフトウェアによって理解される。これは、ＭＩＤＩＮＲＰＮを経たタイムリな方法で、効果的に制御されることができる特定の音声効果を含むＭＩＤＩＤＳＰ構成要素を使用することが有利であるとわかったからである。第６の列は、このＮＲＰＮ実施例において要求される特定の音声効果タイプの確認を示す。説明を簡単にするために「００」を示すが、ＭＩＤＩストリームのこの部分の値が特定のアーキテクチャのための有効音声効果の中から特定の効果を選ぶために、ファームウェア／ソフトウェアによって解釈される。第７の列は、遅延とみなされる他のデルタ時間を示す。第８の列は、ファームウェア／ソフトウェアに第９列に示されるＮＲＰＮコントローラＡ値を記憶するレジスタの確認を示すために、用いることできる。例として第９の列は、「０３」を使用するものとする。これは、歌曲（図２９及び図３０の「サンプルリスト」を参照）に対応するリストの第３の音響サンプルを意味するように、解釈される。値「００」は、ファームウェア／ソフトウェアにランダムにサンプルリストからサンプルを選ぶように指示するために用いることができる。図４１の第１０の列は、他のデルタ時刻値（例えば、「００」は０のＭＩＤＩｔｉｃｓｋである）である。第１１の列は、ファームウェア／ソフトウェアに第１２列に示されるＮＲＰＮコントローラＢ値を記憶するレジスタの確認を示すために用いる。例として第１２の列は、「０７」を使用することにする。これは、ＭＩＤＩＤＳＰに利用できる音響効果中の特定の音声効果を利用するように指示するために、ファームウェア／ソフトウェアによって解釈される。

図４２は、上の実施例の線に沿った特別なＭＩＤＩタイプファイル（すなわちＡＲＭＭＰから好ましくはＭＩＤＩ入力ストリームを経たＤＳＰまで送られているデータの配列の実施例）の簡略描写である。

図の最上部は、このファイルの第１の情報が２５０ｍｓのデルタ時間であることを示す。これは、図４０の初めにおける２５０ｍｓの遅延と対応する。図４２において表されるファイルの次は、チャネル１、ピッチＣのためのイベントの音符を示している一般のＭＩＤＩ情報である。２５０ｍｓが経過するとき、これは図４０の時間と一致する。次に図４２において、別の２５０ｍｓのデルタ時間がある。これは、前のＭＩＤＩイベントと図４０の５００ｍｓにおける次のオーディオストリームイベントとの間の時間を示す。次に、図４２で、さまざまなパラメータＰ及びさまざまな効果Ｅとともに、オーディオストリームイベントＸを演奏することを必要とすることをＳｙｎｔｈチップに知らせるＮＲＰＮメッセージを受け取る。これは、図４０において表されるオーディオストリームイベント（「ｙｏ」）と一致する。次いで、図４２において、２５０ｍｓの他のデルタ時間イベントを有し、該時間イベントに続いて、チャネル１、ピッチＣのための音符オフイベントを示している一般のＭＩＤＩ情報を含んでいる。この最終ステップは、図４０（例えば、「Ｃ」四分音符）のＭＩＤＩイベントの終わりに対応している。

前の実施例において、特別なＭＩＤＩタイプファイルにおけるデルタ時間は、毎回（そして、しばしば）異なることがありる。簡略例において、四分音符、その他を有するタイミング関係を作りたいという理由において、毎回同じ２５０ｍｓの値を使用したが、より複雑なファイルではデルタ時間が変化することは明らかであろう。

その上、図２のプレーヤ機能キーの実施例に関連して上記したように、ある実施例において、ボタン押圧の速度を検出することが好ましい。これらの実施例の多数において、ボタン押圧が、例えば、サンプルイベントを起動するとき、演奏されるサンプルを起動させるＭＩＤＩ−タイプイベントに、ボタン押圧イベントの検出速度−タイプ情報を転送することが好ましい。これらの実施例において、速度、アフタータッチ、音量、その他に指定されるイベントの部分で、速度−タイプ情報が、ＭＩＤＩ−タイプイベントにおいて示すことができる。その上、システム独占メッセージ、又はＮＲＰＮメッセージのようなＭＩＤＩ−タイプイベントを択一的に使うことができる。

前述したように、本発明に従って、声音及び他の音声サンプルは符号化することができ、記憶することができ、再生のために処理することができる。ある好ましい実施例において、声サンプルは、ＰＣＭフォーマットで、好ましくは適合型（予示型）差動ＰＣＭ（ＡＤＰＣＭ）フォーマットの形で符号化される。他のＰＣＭフォーマット又は他のサンプル符号化フォーマットも本発明において使用可能であり、特定のＰＣＭ符号化フォーマット（そして、効果を提供する方法が以下に記載されている）が、さまざまな本発明の態様を実施する上で重要でないが、典型的なＡＤＰＣＭの説明はある効果機能と同様に本発明の好ましい実施例のより完全な理解のために提供される。本発明のこの種の実施例によれば、一種のＡＤＰＣＭは、効果を奏することができる。

本願明細書における開示に基づいて当業者が理解できるように、ＡＤＰＣＭの使用により、データファイルに減少された容量で（それは不揮発性記憶装置（例えば、ＳＭＣ）において好ましくは記憶される）、サンプルを記憶することを可能にする。このように、より多くのサンプル、歌曲リスト及び歌曲が不揮発性記憶装置の所定の容量に記憶されることを可能にする。好ましくは、符号化は、ＡＤＰＣＭフレーム（例えば、８つのサンプル）のサイズのパケットによって行われる。各パケットのために、コードは最高値を提供し、２つのサンプルの間の最大差が、符号化されてファイルに記憶される。各々のコード（サンプル（ｄｅｌｔａ＿ｍａｘ）とパケットのコード（ｄｉｆｆ＿ｍａｘ）の差）は、４ビットを使用する。この実施例に従って、データ／サンプルは、したがって、（８＊４＋４）／８＝４．５ビット／サンプルである。

明らかなように、この種の符号化は、本当に必要であるものだけを符号化することを試みる。８つのサンプルで、２つのサンプル間の最大差は一般に、信号（＋３２７６７／−３２７６８）の可能なダイナミックレンジよりもはるかに小さく、そして、サンプルの間の差だけを符号化することが可能である。好ましくは、ＡＤＰＣＭは、比較的変化しない声音に適するように選ばれる。予測フィルタリングによって、新規なサンプル及びその予測の間の差を減少することが可能である。遭遇する平均差を考慮すると、予測がより良くできれば、差は小さくなり、そして選択される符号化（量子化）の量も小さくなる。この方法が予測計算のための付加的な計算能力を必要とすることはいうまでもないが、この方法が、本発明に受け入れられるサンプル符号化品質を有するサンプルのための減少された記憶の重要な効果を提供すると考えられる。従来の又は標準化されたＡＤＰＣＭは、遅延を導入することのない符号化時間を提供することを必要とするが、本発明では、この種の属性が重要でない。

予測型ではなく、生じた差の平均値だけへの考慮をしない単純な符号化は、非定常状態（例えば、語又は音節の各初め）では良好に反応しない。各新語又は音節にとって、以前に生じた平均差よりはるかに大きい新しい差は、最適に符号化することができない。したがって、信号のレベルによっては、インパルス雑音が生じる傾向がある。解決方法は、したがって、生じる差（したがって、８つのサンプルの遅延があり、したがって予測は量子化だけのためになされる）の最大値を、固定数のサンプルのために与え、そして、この最大差（パーセントで）の関数として、サンプルを符号化することである。符号化は、各瞬間でより最適化される傾向である、非常によく非定常状態（語又は音節の各初め）に反応する。好ましくは、符号化は対数的であり（耳は対数符号化に敏感であるが、直線符号化に対してはそうでない）、信号／雑音比率は２４ｄＢである。好ましい実施態様において、この機能は、例えば、３倍速で実行される（外部フラッシュメモリ内での各々のインストラクションのための１（３の代わりに）クロックサイクル）ように備えられた内部ＲＡＭに、記憶される。

ある種の効果が、本発明の実施例において使用するＡＤＰＣＭ符号化に含まれる。例えば、それが最終固定数が２５６個であるサンプル用として、ＡＤＰＣＭサンプルの可変数を必要とするので、ドップラー効果がＡＤＰＣＭ復号化に含まれる。既に知られているように、この種のドップラー効果は、より速く又はより遅くサンプルを演奏することからなり、ピッチの変化とともに速度の変化が付いてくる復号化声音のピッチの変化と対応する。自然で直線的変化を与えるために、他の２つのサンプル間に新規なサンプルを差し込むことが望ましい。それにより、不快な高振動数高調波を耳に加える傾向があるという点で、直線補間方式は不利益があると考えられてきた。

伝統的に使用される方法は、信号（例えば、３又は４の比率の）をオーバサンプリングし、そして、生じた周波数をフィルタリングすることからなる。フィルタリングされた信号は、線形補間される。この方法の不利な点は、それが付加的な計算機能を必要とするということである。ある実施例に従えば、４つの隣接したサンプルを有する信号を補間する技術が利用される。それは、直線補間によってつくられる高調波に対して４．５ｄＢの利得を許容する第２の順序補間と一致する。４．５ｄＢは低いように思われるが、声音信号の弱い高周波においてそれを考慮することが重要である。声音の最初の高周波数はリニア方法の場合の低い周波数の上部高調波によってマスキングされ、そして、この効果は第２の順序補間によって消える。さらに、それは、オーバサンプリング法より３倍速い傾向がある。この機能は、例えば、３倍速で実行される（外部フラッシュメモリ内での各々のインストラクションのための１（３の代わりに）クロックサイクル）ために備えられた内部ＲＡＭに記憶される。

また、好ましい実施態様に従えば、基本周波数から演繹するために、分析ウィンドウ内で期間番号（ピッチ）を計数することからなる周波数分析機能が含まれる。この機能は、期間を現すためのサンプル処理に利用することができる。一般に、信号が時間とともに変わる（例えば、必ずしも完全に調和しているというわけではないピアノストリング（弦）１〜３を鳴らすこと）傾向があるので、ウィンドウのピークを計数することは可能でない。さらに、同じ期間で、複数のピークがあることがある。この種の実施例に従えば、分析ウィンドウの始めに考慮される参照と個々の部分ウインドウの間の距離は、一つのサンプルだけシフトした。したがって、２＊ＷＩＮＤＯＷ＿ＳＩＺＥサンプルのウィンドウ及びＷＩＮＤＯＷ＿ＳＩＺＥサンプルの参照ウィンドウに関して、ＷＩＮＤＯＷ＿ＳＩＺＥサンプル上の距離のＷＩＮＤＯＷ＿ＳＩＺＥ計算を行うことができる。距離の計算は、参照サンプル及び分析サンプルの間での差の絶対値の合計によって計算される。この機能は、例えば、３倍速で実行される（外部フラッシュメモリ内での各々のインストラクションのための１（３の代わりに）クロックサイクル）ように備えられた内部ＲＡＭに記憶される。

また、この種の実施例に従れば、ウフォブラー、フランジ、エコー及び残響のような特殊効果を、ＡＤＰＣＭ符号化とともに提供することができる。この種の特殊効果が、ＡＤＰＣＭデコーダ及びドップラー効果から得られる２５６個のサンプルを通じて、生成される。この機能は、例えば、３倍速で実行される（外部フラッシュメモリ内での各々のインストラクションのための１（３の代わりに）クロックサイクル）ように備えられた内部ＲＡＭに記憶される。好ましくは、サンプルの平均値が計算され、そして、それについてのｗｏｂｂｌｅｒ機能を実行することを避けるために、平均値（サンプルを通じて存在する）がサンプルから減じられる。ｗｏｂｂｌｅｒ機能は、不快なヒス音を出す傾向がある信号中の変調周波数を増大させる。好ましくは、ｗｏｂｂｌｅｒ効果のための方法は、サンプルにサイン関数を乗じたもの（当業者によってよく理解されるように、適切なｗｏｂｂｌｅｒ周波数に基づいて）基づく周波数変調である。

また、好ましい実施態様に従えばて、フランジ効果の目的は、複数の人が話しているか又は単一のソース声音によって歌っているという印象をシミュレーションすることである。計算能力を制限するために、２つの声音がシミュレーションされる。この印象を提供するために、ソース声音のピッチが変更され、オリジナルのソース声音に加えられる。最も正確な方法は、ボコーダを用いて声音を分析することであり、また、速度を変えずにピッチを変更することである。いずれの場合においても、男性及び女性が一緒に歌っているという印象を有することができる。但し、この種の方法は、通常、ＤＳＰ資源を必要とする。速度（声音が同期式ままであることを望むなら重要）を変化させることなくピッチを変更する方法は、サンプルを交互に加速／減速することによって、第２の声音をシミュレーションすることから成る。その後、前述のドップラー効果を発生するが、それは、僅かに異なるピッチ及び同期式声音を有するような方法で、ゼロ周辺で交互に変動するドップラーである。この種の実施例については、例えば、軸上で規則的に回っている直径４メートルの円上に存在し、かつ、静止している別の人のそばに来た人をシミュレーションすることができる。

また、この種の実施例に従えば、エコー効果は、ソースサンプルと遅延性サンプルの合計であり、残響効果は、ソースサンプルと、利得係数に影響を受ける遅延性サンプルの合計である。遅延性サンプルは、好ましくは環状バッファに記憶され、合計から得られるものである。残響効果の式は、以下の通りであってもよい。
Ｓａｍｐｌｅ（０）＝ｓａｍｐｌｅ（０）＋ｓａｍｐｌｅ（−ｎ）＊ｇａｉｎ＋ｓａｍｐｌｅ（−２＊ｎ）＊ｇａｉｎ＾２＋ｓａｍｐｌｅ（−３＊ｎ）＊ｇａｉｎ＾＋ … ＋ｓａｍｐｌｅ（−ｉ＊ｎ）＊ｇａｉｎ＾ｉ．

好ましくは、利得は発散を避けるために１未満であるように選ばれる。好ましい実施態様に従えば、バッファの大きさ（それは、適宜でありえる）のために、エコー効果は残響効果のそれと同じバッファを使用する。真のエコーを得るために、残響にゼロであるか低い利得効果を与えることが必要である。２つの効果は同時に機能することができる。新しいサンプル及び古いサンプルの間の遅延は、メモリバッファに入れられた最も古いサンプルを読出すことによって生成される。新規なサンプル毎にバッファがシフトすることを避けるために、バッファの読出しポインタを増分させ、バッファの境界の間で、このポインタを制限する。メモリバッファの容量は、したがって、サンプル間で時間に依存する。

また、この種の実施例に従えば、電子チューナ機能が提供される。その狙いは、楽器によって演奏される音符を与えるために到来するサンプル信号の基本波を見つけることにある。すでに記載したことと同様に、好ましい方法は、期間の計算の精度を増やすために、複数の期間からなる所与の時間毎に、その複数の期間の数を計算することを含む。実際には、単一の期間は、この期間がサンプリング用として不十分であり、精度が低い。期間を検出するために、信号の始めの参照と信号との間の距離を計算するルーチンを使用する。理解されるように、期間は、第一及び最後の期間の間に存在する合計数によって分けられる最後の期間の位置である。最後の期間の有効位置は、２つの距離サンプルの間の実際の最大の補間によって計算される。このように計算される期間は、反転（６４ビット／３２ビットの割算を使用して）によって大きな精度（ノイズのない信号のための１／４０００より良好で、そのような場合はしばしばある）を有する基本周波数を与える。

また、この種の実施例に従えば、低域フィルタ（又は他のフィルタ）機能が、ＡＤＰＣＭサンプル符号化によって得られる効果の一部として提供される。低域フィルタを有するこの種の機能によって、前述のルーチンのために距離の計算に使用したサンプル中の高い周波数を除去することができる。これらの高周波数は、該周波数が極度に上昇する場合、計算を妨げる傾向がある。フィルタリングは、距離の計算のために使用するバッファを正規化するために、最も高い値を探すことによって行われる。

また、本発明によれば、多くの望ましい本発明の観点によって用いることができる多数の付加実施態様及び変形がある。大きな効果を奏するように本発明を使用する方法には、他の製品との一般的な統合と伴に、ソフトウェアベースの方法が含まれる。その上、特に媒体内容管理、ビデオとの統合及び他の雑多な変形に関して、本発明に対する有益ないくつかの変形が使われ得る。

多くの本発明の観点は、デジタル／ビデオライトショーと関連して、好適に使用することができる。「ＤｉｇｉｔａｌｌｉｇｈｔｉｎｇＣｏｎｔｒｏｌＳｙｓｔｅｍ」と称する米国特許第４，２４１，２９５号、及び「ＣｏｎｔｒｏｌＳｙｓｔｅｍｆｏｒＶａｒｉａｂｌｅＰａｒａｍｅｔｅｒＬｉｇｈｔｉｎｇＦｉｘｔｕｒｅｓ」と称する米国特許第４，７９７，７９５号（それらの全部において本願明細書に取り込んだものととする）にさらに詳細に記述されているように、ビデオ及び／又はステージ−タイプの照明系統の制御は、デジタル命令（例えばＭＩＤＩ−タイプ記述子イベント）を使用して実行することができる。したがって、ここで記載されている実施例において、この種の種類のビデオ／光制御システムを有する楽曲生成の態様を組み込むことが好ましい。例えば、音楽的イベント及び視覚的イベントを同期させることができ、一時的に量子化し及び／又はパラメータ（例えば、デルタ時間、速度、ＮＲＰＮ、システム独占、その他）を使用して調整することができる。楽曲（例えば、前奏からコーラスまで行く）の重要な変更が、映像のタイミング及び／又は強度、カラー、パターン、その他と符合するように配置することができる。このような実施例では、音声／映像出力を視聴している人の体験は改良される。

さらに、ある実施例において、可視ディスプレイは、楽曲（好ましくは、ユーザによって作成されてもよい）によって強調される動画のキャラクタ（例えば、音楽家）のみから構成されるか、又はそれらを含む（また、ある場合には、本明細書のどこかで述べた携帯電話の着信音）。この実施例に従えば、可視ディスプレイは、動画背景を含むことができ、それによって、動画キャラクタが背景動画上で演じているように描かれる。

電話を含んでいる実施例において、視覚の動画は、電話の呼出音（そして、ある場合には、電話リングは、この開示の全体にわたって記載されている他の実施例のあるものを使用することができる）で表示を始めることができる。動画のキャラクタは、例えば、送信される発信者番号通知サービス情報に基づいて、呼出し元を示し、識別するために、前もって割り当てられていることができる。この機能によれば、ユーザは、カスタムメイドの動画及び／又は楽曲（好ましくは呼出し元のアイデンティティに基づく）を再生する能力をもつことができる。

多くの本発明の態様は、ソフトウェアベースに組み込んで実現することができる。例えば、上記説明したハードウェアＤＳＰは、信号処理機能（を実行するために、ソフトウェアシンセサイザによって置換することができるハードウェアベースのシンセサイザの使用は、本発明の必要条件でない）。この種の方法は、例えば、現代のパーソナルコンピュータの過剰処理電源を利用して、また、多数のプラットフォーム（例えば、いかなるＰＣでも演奏することができる楽曲を共有することは容易である）全体のより大きな互換性を提供すると共に、ハードウェアベースの手段で生産される楽曲と同様な品質を提供する。ソフトウェアベースで本発明の実施例を構成することは、付加的な変形を可能とする（例えば、プロの音楽作者又はアマチュア音楽ファンへ適合させる自己内蔵型アプリケーション）。その上、ユーザのコンピュータ上のローカルファイルに記憶されるユーザ選択及び／又はカスタム情報（例えば、クッキー）で、ウェブサイトでの使用のために、本発明のソフトウェアに基づく実施例を構成することが好ましい（例えば、ジャバ言語アプレット）。この種の方法は、ユーザが「ｓｔｉｃｋ（刺さる）」し、該サイトへの次の訪問で残存する楽曲伴奏スタイル選択を示すことを可能にする。ソフトウェアベースの方法の変形は、既存の内容生成ソフトウェアプリケーションへの「ソフトウェアプラグイン」方法（ＭａｃｒｏｍｅｄｉａＦｌａｓｈ、ＡｄｏｂｅＡｃｒｏｂａｔ、ＭａｃｒｏｍｅｄｉａＡｕｔｈｏｒｗａｒｅ、ＭｉｃｒｏｓｏｆｔＰｏｗｅｒＰｏｉｎｔ及び／又はＡｄｏｂｅＡｆｔｅｒＥｆｆｅｃｔｓのような）を含む。この種のプラグインにより、潜在的に使用料無料の楽曲から利益を得ることができ、ある実施例では、対話的に生成された音楽作品をフラッシュプレゼンテーション、ＰＤＦファイル、Ａｕｔｈｏｒｗａｒｅプレゼンテーション、ＡｆｔｅｒＥｆｆｅｃｔｓ映画、その他への算入のために転送することが好ましい。

本発明の実施例は、複数のユーザが、好ましくはリアルタイムで、協力感覚で一緒に対話的に楽曲を生成することを可能にするインターネットに基づく仕組みを提供することができる。カスタマイズされた楽曲を含んでいる本発明の態様は、音楽ゲーム（及び／又は学習補助）、ニュースソース（例えば、インターネットニュースサイト）、言語ゲーム（及び／又は言語学習補助）、その他の一部として組み込まれることができる。その上、本発明の多くの機能及び利点を組み込んでいるソフト／ハードのハイブリッド方法は、個人コンピュータシステムの高速バス（例えば、ＩＥＥＥ１３９４又はＵＳＢ、その他）にアクセスするハイブリッド「ＤＳＰ」モジュールを含むことができる。この種の方法において、ＭＰ３６の機能は、個人コンピュータシステムによって実行されることができる。その一方で、ＤＳＰ４２の機能は、周辺バス（例えば、ＵＳＢ）に取着されるハードウェアモジュールに置かれるＤＳＰによって実行することができる。この実施例に従い、ほぼ自動車キーと同様なサイズの小型ＵＳＢモジュールを、ＰＣシステムのＵＳＢポートに挿入することができ、アルゴリズム楽曲の対話的自動生成と関連するハードウェアＤＳＰ機能を実行するために用いることができる。

明らかなように、多くの有利な本発明の態様は、携帯用通信装置（例えば、移動電話、ＰＤＡ、その他）において実現可能である。例えば、デジタルカメラ（例えば、内蔵イメージキャプチャ装置（２００３年にノキアグループから入手可能であると思われる）を有するノキア３６５０移動電話と同様の）を組み込んでいる携帯用通信装置の場合、好ましい実施例は、携帯用通信装置でアルゴリズム的な楽曲生成／自動作曲機能を使用することを含む。この実施例に従えば、この種の実施例の一部としてのデジタル像キャプチャ装置の使用によって、ユーザが１又は複数の画像（動画又は静止画）を撮ることができ、好ましくはスライドショーとして、それらを楽曲に設定することができる。楽曲（例えば、図２８〜３１に例示されて、本願明細書において議論されるＳＤＳ及びＣＤＳ構造及び特徴）を記憶することを必要とするデータ構造が比較的効率的であるため、この種の拡張イメージをシステム間で交換することができ、したがって、携帯用のこの種の通信装置が利用できるバンド幅が比較的制限されていても、このようなスライドショーの配信が可能となる。

明らかなように、本発明の態様は、種々のシステム及びアプリケーションに組み込むことができ、その例示として、ＰＢＸか他の電話タイプシステムを上げることができる。典型的なシステムは、例えば、Ｐａｎｇ他に対する米国特許第６，２８９，０２５号等に開示されている。そして、それは本願明細書に取り込んだものとする（他の典型的なシステムは、アルカテル、エリクソン、ノーテル、アバイアのような会社からのＰＢＸシステムを含む）。典型的なこの種のシステムから理解できるように、複数の電話及び電話インターフェースがシステムとともに提供され、システムが位置する施設でのユーザ、又は、外部からシステム（例えば、ＰＯＴＳ電話線又は他の電話線を経て）にアクセスするユーザは、システムが受信した通話（呼出）を受けることができる。この種の通話は、システムによって特定のユーザに向けられるか、あるいは、通話はホールドオン状態に（典型的なこの種のシステムのこの種の態様は、従来通りであり、本願明細書においては詳細に記載されていない）おかれる。一般に、ホールドオン状態の楽曲は、無線局から得られるホールドオン楽曲、又は、オーディオ入力で結合されて、コーダーで処理され、オーディオストリーム（ＰＣＭのような）として提供され、ホールドオン状態の呼び出し元の電話に結合されるテープ記録されるか他の記録された楽曲により、ホールドオン状態の呼び出し元に提供される。

本発明の実施例に従えば、１又は複数のモジュールが、ホールドオン状態の呼出し元にホールドオン楽曲を提供する典型的なシステムに具備される。この種のモジュールは、ＰＢＸ−タイプの環境に適応するユーザインターフェースを備えていないが、例えば、本願明細書のどこかで記載されているように（例えば、図３２及び関連した説明を参照）（この説明のために、この種の組成のハードウェア／ソフトウェア構成要素は、「自動作曲エンジン」と称する）、プレーヤに必要なハードウェア／ソフトウェア構成要素を含むことができる。そのような典型的な実施例においては、１又は複数の自動作曲エンジンは提供される。そして、それは、ホールドオン状態にある１又は複数の呼出し元にホールドオン楽曲を提供するのに役立つ。一つの実施例においては、単一の自動作曲エンジンが備えられ、そして、ホールドオン状態の第１の呼出し元は、まず最初に、自動作曲エンジン（又は、典型的なシステムを制御しているプロセッサ）によって定まる特定のスタイルの自動作曲された楽曲を贈られるによって定まる特定のスタイルの自動作曲された楽曲を贈られる（これは、また、典型的なシステムの構成パラメータによって選ばれるホールドオン楽曲スタイルの不履行であってもよい）。好ましくは、典型的なシステムの資源によって提供される音声プロンプトにより、ホールドオン状態の呼出し元は、ホールドオン状態の呼出しに提供されているホールドオン楽曲のスタイルを変更できることを示す音声情報を提供される（この種の音声の迅速生成は、この種の典型的なシステムの概念において従来通りであり、本願明細書においては更に詳細に記載されていない）。好ましくは、ユーザは、電話キーボード上の予め定められた数字（それは、音声プロンプトにおいて好ましくは識別される）を押圧することによって、この種の要求を示すことができる。そして、それは典型的なシステム（この種の数字検出能力は、この種の典型的なシステムの概念において従来通りであり、本願明細書においては更に詳細に記載されていない）の資源によって検出することができ、その後で、ホールドオン楽曲のスタイルを選ぶ（例えば、楽曲の所望のスタイルを選ぶために始まる１又は複数の数字によって追従される楽曲の有効スタイルを提供している音声プロンプトで）ための、複数の楽曲スタイルを備えている。その後で、ユーザは、電話キーパッド上の適当な数字を押し下げることができ、それはシステムの資源によって検出され、そのシステムは、数字をデコードして、自動作曲エンジンのうちの１台に制御情報を送る。これに応答して、自動作曲エンジンがその後、ホールドオン状態の呼び出し元にホールドオン楽曲として向けられる、選択されたスタイルの自動作曲を開始する。

重要なことは、この種の実施例に従えば、ボタン等又は典型的なシステムの資源からの命令で変更される自動作曲エンジンの命令／制御インターフェースを設けることにより、１又は複数の自動作曲エンジンを典型的なシステムに適応させることである（命令は、ホールドオン状態におかれた通話、数字検出などに応答して生成される）。この種の実施例の変形に従えば、複数自動作曲エンジンは提供され、そして、システムの資源が、ホールドオン状態の呼出し元に、該呼出し元によって選ばれたスタイルのホールドオン楽曲を選択的に提供する。一つの変形において、自動作曲エンジンよりも多くの呼出し元が潜在的にホールドオン状態にあってもよい。この種の実施例において、利用されていない少なくとも一つの自動作曲エンジンがある場合、ホールドオン状態の呼出し元は選択的に自動作曲エンジンの出力オーディオストリームの１つと接続される。呼出し元がホールドオン状態におかれたときに自動作曲エンジンの全てが利用されている場合、ホールドオン状態の呼び出し元が、自動作曲エンジン（選択を与えられずに）の１台によって出力されているひとつのオーディオストリームに結合されるか、あるいは、ユーザにその自動作曲エンジンによって現在提供されているホールドオン楽曲のスタイルを知らせる音声プロンプトが提供される（それに応答して、ホールドオン状態のこの呼出し元は、電話キーパッド上の１又は複数数字を押し下げることによって、提供されているスタイルの１つを選ぶことができ、選択されたスタイルの自動作曲された音楽を提供しているオーディオストリームと接続される）。

他のこの種の実施例の変形には、以下が含まれる。（１）典型的なシステムの資源は、例えば、発信者番号通知サービス情報、又は到来する通話のトランクグループを通して、呼び出し者（例えば、地理学的位置）に関する情報を検出し、その後、特定のもののためのホールドオン楽曲が発信者番号通知サービス情報又はトランクグループ情報、その他に対応する予め定められたスタイルであることを指令する。（２）典型的なシステムの資源は、被呼び出し者（特定の被呼び出し者は、例えば、それらのホールドオン楽曲が特定のスタイルの中であることを指令する構成パラメータを設定することができる）の身元に基づいて、選択的にホールドオン楽曲のスタイルを決定する。（３）典型的なシステムの資源は、その年の季節、時刻又は週、その他で、選択的にホールドオン楽曲のスタイルを決定することができる。（４）典型的なシステムは、各スタイルのための自動作曲エンジンを含み、それにより、ホールドオン状態の全ての呼出し元が、提供されるスタイルの１つを選ぶことができることを確実にする。（５）デフォルト又は最初の楽曲スタイル（例えば、上記したように、典型的なシステム又は被呼者、その他の資源によって決定した）に続いて、ホールドオン状態の呼出し元が楽曲スタイルを変更することを可能にする音声プロンプトが生成される。（６）典型的なシステムの資源は、ユーザが特定の楽曲スタイルを変更するパラメータ、及び特定の楽曲スタイルで自動作曲されている楽曲を変更するパラメータを選択することを可能にする音声プロンプトをさらに具備する（本明細書のどこかで説明されいるように、本質的には、音声プロンプト生成及び数字検出は、ホールドオン状態の呼出し元が自動作曲されている楽曲のパラメータを変えることを可能にするために、システムの資源によって提供される）。

一般に本発明の態様を他の製品と統合する新規な方法の他の実施例は、ビデオカメラ（例えば、好ましくはユーザが容易に使用料なしでホームムービーを創作することを可能にするために、コンフィギュレーション可変なサウンドトラック）、従来のステレオ装置、運動装置（速度／強度／プログラム可能な、好ましくはトレーニング強度プログラム可能な能力をもつトレーニング装置（ＳｔａｉｒＭａｓｔｅシリーズのようなｈｉｌｌｓ）と同様の）、コンピュータスクリーンセーバプログラムに対するコンフィギュレーション可能な音声付属物、及び情報キオスクシステムに対するコンフィギュレーション可能な音声付属物を含む。

本発明の態様は、媒体コンテンツ権管理等を容易にするために、楽曲出力上の音声「指紋」を組み込むことができる音声透かし技術と結合して、好適に使用することができる。Ｖｅｒａｎｃｅ又はＤｉｇｉｍａｒｃ（例えば、米国の特許第６，２８９，１０８号及び６，１２２，３９２号（本願明細書に取り込んだものとする）のＤｉｇｉｍａｒｃによって記載されている音声透かし概念）によって記述されたように、好ましい音声透かし技術の組み込みは、ユーザがそれらの生成された楽曲の次の使用法をモニタする能力をもつことを可能にする。

他の例では、本発明のある実施例は、ゲーム自体のアクション及び／又はその展開に応じて、ユーザによって選択可能なスタイル及び／又はビデオゲームソフトウェアによって選択可能なスタイルと共に、仮想的に決して繰り返さない楽曲を提供するために、ビデオゲーム（例えば、プレイステーション２のビデオゲーム）のソフトウェアの一部として組み込むことができる。

ある実施例は、ビデオゲームプレーヤに楽曲を提供するために、本願明細書において記載されているアルゴリズムの楽曲生成の使用を含む。ある実施例において、図３２の選択された部分を参照すると、ＤＳＰ４２（及び、好ましくは、フラッシュ４９、ＲＡＭ４８、ＤＳＰデータバス４７、及びＤＳＰアドレスバス４６の１つ以上）を組み込んだモジュール（例えば、マイクロソフト社からのＸｂｏｘのようなビデオゲームシステムが用途に適している）が使用可能な状態テレビゲーム機（例えば、パーソナルコンピューターシステム、上述したＭＳＸｂｏｘ、及び／又は、アメリカのソニーコンピュータエンターテインメントからのＰＳ２）に結合される。この種のモジュールによって、高品質楽曲音を、例えばＤＳＰ資源による高品質を経て、生成することができる。好ましくは、楽曲ルール等のアルゴリズムの処理の多くは、テレビゲーム機の処理資源によって実行される。もちろん、本願明細書において他の箇所で記載されているように、ある実施例は、ＤＳＰ４２（そして、関連したサブシステム）によって生じる計算資源を提供するために、ソフトウェアに基づくＤＳＰを使用する。この種の別の実施例において、ＤＳＰ処理は、同様にテレビゲーム機によって実行される。

ビデオゲーム実施例において、生成されている楽曲は、ゲームのイベントに応答して更新される。例えば、ユーザがゲームの間、さまざまなキャラクタに遭遇するゲームの場合、１又は複数のキャラクタは、それらと関連する楽曲スタイルを有する。これらの実施例において、楽曲が繰り返すことができないにもかかわらず、楽曲スタイルは特定のキャラクタがそばにいることをユーザに知らせる。

ビデオゲーム実施例において、楽曲（例えば、リード楽器又はドラム）の特定の構成要素は、キャラクタと関係している、そして、特定のキャラクタがビデオゲームのユーザにより近接して移動すると、楽曲の対応する構成要素は、それに応じて調整される。例えば、ビデオゲームのユーザが特定の悪者に近づくとき、その悪者（例えば、リード楽器）に対応する音楽構成要素が調整される（例えば、相対的な音量の増加、及び／又は、例えば、図２３に示したような、音符ピッチの相対的な可動性の増加のようなその他の変化を示すか、及び／又は、図１８等に示したように、相対的な周期的密度を増やす）。

ビデオゲーム実施例において、例えば、本願明細書のどこかで記述したように、音楽作品（例えば、図２８、図３０及び図５９に例示されるパラメータのような情報）に関する情報は、取り外し可能な記憶場所に保存される。例えば、ソニープレイステーション２のような例では、他のビデオゲームデータを保存するために具備されるモジュラフラッシュメモリカードに情報を保持しておくことが好ましい。これらの実施例において、ビデオゲームデータを保存するためにテレビゲーム機によって使用する取り外し可能なフラッシュメモリカートリッジの容量が比較的限られ（そして、高出費）ていることを苦慮すると、音楽作品を再現することを必要とする楽曲の情報が比較的少ない容量であることは、特に有利である。

その上、本発明の多くの利点を組み込んで効果を生成されることができるように、本発明を変形することができる。例えば、図３２の携帯用ハードイウェア装置３５の、マイク入力５１（例えばユーザの声のメロディ）への着信データがハードウェアコーデック５２を介してＭＰ３６に達し、そのデータがＭＰ３６によって分析され、ＤＳＰ４２（ＭＰ３６の制御下で）によって処理／調整され、微妙にピッチ及び／又はリズム特性を「改良する」ことができる。この実施例は、ユーザのオーディオ入力が付随する楽曲のキー及び／又はリズム特性に合致するように、調整することができる。この実施例を続けると、マイク入力５１に対するユーザの入力のピッチは、携帯用ハードウェア装置３５によって分析することができ、より密接に楽曲の現在のキー及びモードに整合するように、ピッチを上下に調整することができる。この種の変形により、初心者に音楽的に対する強い興味を満たせ、また、ユーザの入力（例えば、声の）から派生する歌曲を生成する簡単な方法をユーザに提供する。他の実施例変形においては、ここで言及される回路は、ユーザの入力（例えば、声の）を分析して、タイミング及び／又はメロディ情報の若干のタイプを推定するために利用することができる。その情報は、ＲＰに含まれるピッチ値及び／又はリズムデータを定めるのを助けるために、双方向楽曲自動生成おいて使うことができる。この例は、作曲中に、完全に作曲の複雑さを理解することを必要とせずに、ユーザが楽曲出力と相互作用して、それに影響を与えるための方法を示す。

ある実施例において、リアルタイムの声のマイク入力を分析して、生成されている作曲の一部として、リアルタイム方法の入力声の特性に擬態する声音コードモードを可能にすることが好ましい。一つの例として、この特徴は、ユーザの声の入力イベントを１又は複数の人工的に生成された声のイベントと結合する声音コード効果を提供することができる。この方法では、ユーザは一部を歌うことができ、そして、それらの声音に基づいたコードを聞くことができる。この特徴が、本開示の他の箇所で記述されるピッチ矯正特徴によって、用いることができる。

ある実施例においては、リアルタイムでユーザに参照音符を提供することは好ましい。この種の参照音符は、ユーザにとって主音概念を提供する。例えば、その結果、より正しく歌えるようになる。更に、実施例において、この種の参照音符は、参照メロディとして役立ち、ユーザに対して、精密なメロディ／リズム線を提供することができる。これらの機能は、特にカラオケ環境において有利である。これらの実施例の多数において、参照音符をユーザのイヤーピースに制限することが望ましい（例えば、ユーザが、参照音符情報を、任意の記録及び／又はパフォーマンスオーディオ出力から除外することができる）。

歌唱パートの生成と関連する付加的な発明概念に向けられる実施例を、より詳細に説明する。この説明は、また、本願明細書において記述される声音関連特徴のさらなる様相を提供する。

ある水準では、声音の通信は、限定された数の個々の音響のさまざまな組合せであると考えることができる。例えば、言語学者は、全ての英語声音の通信のために使われる一組のほぼ４２の唯一の音響を算出した。この組は、「音素」として公知であり、語の範囲内でそれらの対照によって特徴づけることができる音響で最も小さいセグメントである。例えば、長い「Ｅ」音声が、「ｍｅ」、「ｆｅｅｔ」、「ｌｅａｐ」及び「ｂａｂｙ」のようなさまざまなつづりで使われる。また、「ｓｈ」音が、「ｓｈｉｐ」、「ｎａｔｉｏｎ」及び「ｓｐｅｃｉａｌ」のようなさまざまなつづりで使われる。更なる実施例として、英語音素のリストは、ｈｔｔｐ：／／ｗｗｗ．ａｕｂｕｒｎ．ｅｄｕ／〜ｍｕｒｒａｂａ／ｓｐｅｌｌｉｎｇｓ．ｈｔｍｌ．でオーバーン大学ウェブサイトから入手可能である。音素は、話し言葉と典型的に関係していて、口頭の音声を分類して、再分割するひとつの方法である。また、本説明は、本願明細書において英語の例だけを参照している。例えば、英語の音素の一組を用いて、聞いて、音声転写を準備することによって、任意の言語のための一組の音声を組み立てることができることが明らかであろう。同様に、上記の説明が口頭の例だけを参照したが、同じテクニックを、詠唱された通信を示す一組の音声を組み立てるために歌唱された例にも適用することができる。組み立てられた音声セグメントのリストは、英語の音素の一組より長いが、この方法は、歌唱された音声セグメントのライブラリを識別するために用いることができる。

楽器デジタルインターフェース（ＭｕｓｉｃａｌＩｎｓｔｒｕｍｅｎｔＤｉｇｉｔａｌＩｎｔｅｒｆａｃｅ）標準（ＭＩＤＩ）は、デジタルベースの音楽製品用の通信プロトコルを可能にするために開発された。それ以来、ＭＩＤＩは、対話するように設計された全てのデジタルベースの音楽関連の製品のデファクト標準になった。例えば、一組のグランドピアノ音響が音響バンクを識別している音響バンクＭＩＤＩ命令を送信することによって選ぶることができるように、ＭＩＤＩは、特定の「音響バンク」に音響のバンクを割り当てる能力を組み込む。その後、例えば、「音符オン」命令を使用して、音響バンクの個々の音符を鳴らすことは可能である。その上、個々の音符がどのように鳴るかを示す特性（例えば、音符が始められる速度を示す「速度」等）を利用することができる。ＭＩＤＩに関する詳細な情報は、カリフォルニアのＭＩＤＩ製造者連合から受け取ることができる。

本発明の実施例に従って、歌唱パートを含んでいる楽曲を生成するために、ＭＩＤＩをより大きなシステムに組み込むことができる。先に参照されたような楽曲生成の環境状況を仮定すると、音響（例えば、音素）のライブラリを有し、そして、制御プロトコル（例えば、ＭＩＤＩ）の使用によって、声音トラックがシステムに加えられる。この実施例に従えば、音素のライブラリは、ＭＩＤＩ音響バンク（例えば、声音のための特定のチャネルを経て）を伴うことができる。ライブラリの個々の音素は、所与のＭＩＤＩイベントのための「プログラム」値によって識別することができる。音響（例えば、音素）の所与の部分の振幅は、所与のＭＩＤＩイベントと関連する速度情報によって示すことができる。音響の各部分のピッチは、所与のＭＩＤＩイベントに伴う「音符」値を使用して、同様に識別することができる。加えて、音響の各部分のための所望の持続期間は、ある時間と関連する「音符オン」イベントのシーケンスを使用しているＭＩＤＩに好ましくは示される。そして、デルタ時間（例えば、「音符オン」イベントが実行された後のＭＩＤＩクロックの数）と関連する「音符オフ」イベントが、その後に続く。もちろん、ゼロの速度を有する他の「音符オン」命令の代替使用法は、ＭＩＤＩ分野でよく知られているように、音符の終了を示すために用いることができる。

楽曲の自動生成のために先に開示された実施例が、本明細書において説明された。先の開示のさまざまな機能及び実現例は、完全な音楽作品を生成するための楽曲ルール（例えば、コンピュータアルゴリズム）の使用を含む。これらの楽曲ルールは、音楽作品の多数の同時パート（例えば、ドラム、バス、その他）のための一連の音楽イベントを自動的に生成する方法を含むことができる。更に、それらが楽曲モード（例えば、降順のリディアン）と互換性を持つために調和修正されるように、効果的に個々のパートを量子化することができる。加えて、各パートの生成されたイベントを、それらが特定の慣習又は楽曲のスタイル（例えば、スウィング、レゲエ、ワルツ、その他）に合わせて時間修正されるよう量子化するために、これらの楽曲ルールは、リズム的構成要素も組み込むことができる。最後に、先に参照された開示も、自動生成された楽曲作曲に対するユーザ相互作用を可能にする実施例を提供する。

先に述べられた楽曲自動生成コンセプトを使用して、例えば、基本有声音のライブラリから一連の有声音を鳴らすために、自動生成されたピッチ、振幅、及び／又は持続期間の特性を組み込んだ一連のＭＩＤＩイベントを生成する声音処理機能が同様に使用され得る。例えば、生成されるピッチの連続が、特定の楽曲モードによって調和修正される。そして、リズム持続期間及び／又は相対的な音の大きさは、特定の所望の溝、拍子記号、スタイル、その他によってリズム修正される。さらに、ある実施例では、より詳しくは、テキストに関している付加ルールを課すことが好ましい。例えば、人間の声音通信は、特定の音素（例えば、母音）の期間、ピッチを変動するだけであることが観察される。したがって、ある実施例では、ピッチ値が変更される前に、自動生成処理の間に、音素タイプを点検することが望ましい。他のある具体例では、ピッチ変化がアクセントをつけられた音節又は「長い」音節（例えば、「ｏｒａｎｇｅ」における「ｒａｎｇｅ」音に対する「ｏ」音のように）にのみ発生するようにすることが好ましい。これらの実施例において、特定の音声が、自動生成処理の間、ピッチ変化と互換性を持つことを確認することが望ましい。この種のふるい分け動作は、さまざまな方法で実行することができる。例えば、「声音ライブラリ」が、音響バンクと関連するアドレス指定可能な範囲の一つの領域にいっしょに配置された「ピッチ変更互換可能の」音声とともに、音響バンクとして配置され得る。この実施例に従って、楽曲ルールが実行され、鳴っている声音音符が音符変更イベントに与えられるとき、それがピッチ変更イベントに関連する「受け入れられる」音域にあるかどうか決定するために、現在の音声のＭＩＤＩアドレスを点検することが好ましい。当業者に明らかであるように、これは一つの実施例でしかない。

ここまでの説明は、作曲における声音トラックの音声に近けるために、楽曲生成システムでどのように一連の無意味な音声を生成し演奏するかを対象にした。次章は、意味のある一連の声音を可能とするために、テキスト−スピーチアルゴリズムの考えを混合している。

文書情報は、個々の音声構成要素を識別するために、直ちに分析することができる。例えば、言語分析ルーチンは、各々の語の文脈を識別し、共通に誤ってつづられた語のためのミススペルを修正し、共通して使う略語を識別するために使用することができる。多くのテキスト−音素スキームが従来技術に存在している。一つの例は、ハニーエスエロヴィッツ、ロドニージョンソン、アストリートマクヒュー、及びジョンイーショアによって書かれた、「Ｌｅｔｔｅｒ−ｔｏ−ｓｏｕｎｄｒｕｌｅｓｆｏｒａｕｔｏｍａｔｉｃｔｒａｎｓｌａｔｉｏｎｏｆＥｎｇｌｉｓｈｔｅｘｔｔｏｐｈｏｎｅｔｉｃｓ」（Ａｃｏｕｓｔｉｃｓ、ＳｐｅｅｃｈａｎｄＳｉｇｎａｌＰｒｏｃｅｓｓｉｎｇのＩＥＥＥ論文集）と題する１９７６年の文献である。本開示の図４４に示したように、テキスト情報（例えば、ＡＳＣＩＩテキスト）は、生成され又は書き込まれ（ステップ２１）、音声記述子（ステップ２２）の流れに解析される。この解析処理は、各々の音声記述子と関連する特性情報（例えばピッチ、振幅及び持続期間）の生成／書き込みに関連する。特性情報を含む音声記述子のストリームが組み立てられると、それは処理され、音声ライブラリ識別情報、ピッチ情報、振幅情報及び／又は持続期間／タイミング情報（ステップ２３）を含んでいる制御ストリーム（例えば、ＭＩＤＩに準拠したデータ）に組み立てられる。この種の制御ストリームは、声音ライブラリをアクセスし、一緒に声音のトラック（ステップ２４）を構成する一連の音声を組み立てることによって処理される。音声が出力される前に、ピッチ、振幅及び／又は持続期間、その他の単純な調整をする「スムージング」操作のような処理操作を実行することが好ましい。これにより、出力音声はオーディオストリームが流れるように（ステップ２５）、より現実的に出力される（鳴る）。

テキストはユーザ定義可能で／書き込み可能であり得るが、それも無意味である。音楽界のある実施例は、ジャズの音楽の「スキャット」のような無意味な音節歌唱、及び「天国又はラスべガス」アルバムのような「ＴｈｅＣｏｔｅａｕＴｗｉｎｓ」からの環境音楽を組み込む。より単純な効果又はアーキテクチャが望ましい実施例においては、音響ライブラリの有効音素の数を減少することが好ましい。

本発明の好ましい実施例の一つの変形は、例えば、キーボード（又は、ある実施例では、オーディオ入力を経て）のようなユーザ入力インターフェースを介し、取り外し可能な記憶場所を介し、及び／又はパーソナルコンピュータ（すなわち、例えば、参照され、組み込まれた特許出願に開示されたような）に対するインターフェースを介し、エンドユーザが、テキスト入力又は書き込み、かつ、入力されたテキストを楽曲作曲に互換性をもつ自動生成声音パートの基礎として使用することを可能とにすることによって、実現される。先に参照され、かつ組み込まれた特許出願の範囲の実施例として、本開示の図４５は、映像出力インターフェース３２（例えば、液晶ディスプレイ）及びオーディオ出力インターフェース３４（例えば、ステレオヘッドホン出力ジャック）を含む携帯用の楽曲生成装置３０を表す。図４５の簡略実施例に示すように、テキスト入力インターフェース３６は、エンドユーザがテキストを入力することを可能にする。この例では、テキスト入力インターフェース３６は、ミニチュアＱＷＥＲＴＹキーボードであり、そして、ユーザは、始まるテキストが映像出力インターフェース３２に表示されるのを見ることになる。携帯用の楽曲生成装置３０が楽曲ルール及びアルゴリズムに従って楽曲を生成するとき、テキスト入力インターフェース３６を経たエンドユーザによるテキスト入力は、音声記述子ストリームに解析されて、生成された特性データ（例えばピッチ、振幅、持続期間、その他）と結合されて、ＭＩＤＩ互換ストリームのような制御ストリームを生成するために処理される。図４４の実施例と関連して本願明細書において述べられるように、制御ストリームは、声音ライブラリにアクセスすることによって処理され、そして、声音トラックを含んでいる一連の音声を組み立てる。この時点で、組み立てられた声音トラックは、任意の最終的な処理（例えば、「スムージング」、その他）を受ける。最後に、声音は、ユーザに対するオーディオ出力インターフェース３４を経た他の任意の楽曲パートと一緒の出力である。完結した出力は、テキスト入力インターフェース３６を介して、エンドユーザによるテキスト入力とのいくらかの関係を持つものとして、エンドユーザによって認識可能である。

テキスト入力インターフェースの使用に加えて又はその代わりに、他の変形では、例えば、他のコンピュータ／インターネット（例えば、第３のＤａｔａＩ／Ｏインターフェース３８）に対するインターフェースを介して、前もって作られたテキストの使用を可能にすることが望ましい。他の変形において、記憶メモリ３９のような記憶場所を、声音トラック用として、テキストを記憶し書き込むために用いることができる。記憶メモリ３９は、フラッシュ、ハードディスク、その他のような書き換え可能な不揮発性のメモリである。

ある実施例においては、テキスト−声音処理を行う際のＭＩＤＩリリック命令の使用をサポートすることが好ましい。例えば、テキスト情報は、一連の１又は複数のＭＩＤＩリリック命令（例えば、１又は複数のテキスト音節のための一つの命令）の形で提供される。この一連のＭＩＤＩリリック命令の各々は、それから音節に関連する１又は複数のＭＩＤＩプログラム変更メッセージを生成し／取り出すために、アルゴリズムによって分析される。この実施例によれば、歌曲と関連する一連のＭＩＤＩリリック命令を組み込んでいるＭＩＤＩカラオケファイルをサポートすることが好ましい。その上、ある場合には、更に記述子を再分割するために、特定のカラオケファイルのＭＩＤＩリリック命令を解析することが好ましい。そして、各々のリリック命令がそれと関連する一つのデルタ時間パラメータを含むように、より大きなリズム制御を提供する。したがって、デルタ時間制御方式をより微細にした方式が可能であるので、より大きなリズム制御が提供される。

さらに別の態様では、映像出力インターフェース３２は、タッチスクリーンオーバーレイを有し、そして、映像出力インターフェース３２に示されるキーの画像に対応する位置で、タッチスクリーンに接触することによって起動するシミュレーションされたキーボードのキーで、キーボードは映像出力インターフェース３２上でシミュレーションされる。この種の実施例において、参照されて組み込まれた特許出願に記載されている実施例と関連して記載されている物理的ボタンを、タッチスクリーンの使用により、全てではないにしても、ほとんど不要にすることができる。

更に、また別の実施例においては、この種のキーエントリの使用は、ユーザが自動楽曲生成システムに名前を入力（例えば、彼（女）の名前又は愛されるものの名前、又は他のいくつかの語）することを可能にする。典型的な別の実施例において、厳密な方法で自動作曲処理に頭文字で署名するためにタイプされた名前が用いられ、それによって、キー入力によって決定された唯一の歌曲が名前のキー入力に基づいて自動的に作曲される。参照されかつ組み込まれた特許出願に開示された実施例に従って、例えば、最初のシード、楽曲データ又は擬似乱数発生処理（ＰＲＮＧ）への入力などを生成するために、名前の文字がアルゴリズムに使用される。それによって、自動作曲処理を開始する最初のデータが、その名前の入力に基づき決定される。一つの例として、各々の入力文字のＡＳＣＩＩ表現を加え、おそらく若干の数学を数に適用し、そして、その結果生じる数を、ＰＲＮＧ処理等への入力として使用する。別の例として、典型的なテンキー（例えば、文字「ａｂｃ」は数「２」、「ｄｅｆ」が「３」、その他に対応する）に使われるように、各々の文字は数値をもつことができ、それらの数は、ＰＲＮＧプロセスに適切な入力となるように、数学的に処理される。この後者の実施例は、キーパッドインターフェースがサポートされる携帯電話機又は類似した携帯用製品（ＰＤＡ又はページャのような）に組み込まれる場合に、特に有利である。

処理が厳密であるので、少なくとも同じリリース又は楽曲生成システムのバージョン用として、名前の全てのエントリは、特定の人のための同じ唯一のすなわち「署名」歌曲を生成する。別の実施例の自動作曲処理は、部分的に、名前の文字の入力の時間又はタイミングに基づくものであり、したがって、名前入力プロセス（この種の人間の相互作用ランダム状態は参照され、組み込まれた特許文献において述べられている）及び個々の名前入力のための固有の歌曲生成に、ユーザ時間−ランダム状態を差し挟むものであるが、好ましい別の実施例では、相当な数のユーザが、かれらの名前又はかれらにとって重要な他のいくつかの語に基づく「かれらの歌曲」として、特定の曲をもつことを好むと思われるので（何らかの形でそのユーザの名前と関係していてもよい多数の曲を提供するため、テンキーインターフェースと関連して本願明細書において記述されるように、一連の文字に対応する数を使用するために、ユーザは、例えば、逆向きに、大文字でない、ニックネーム等のように、異なる形式で彼／彼女の名前／語を入れることができる）、好ましい別の実施例では、厳密な非ランダム方法が使用される。当業者が理解できるように、この概念も、自動作曲される楽曲スタイル選択に適用できる（参照され、取り込まれた特許文献にて説明したように、スタイルは、ユーザ入力に基づくランダムな選択処理の一部であり、又は、スタイルが選択可能であること、等）。例えば、特定の画曲生成システムによってサポートされる楽曲の各々のスタイル又はサブスタイル用として、各々のスタイル又はサブスタイルのための唯一の曲は、ユーザの名前（又は他の語）の入力に基づいて、あるいは、厳密には、例えば、ユーザが、スタイル等を選択するようにして、文字のユーザ入力などのタイミング又は他のランダム性に基づいて、創作することができる。

明らかなように、自動作曲処理を開始するための名前入力が名前に限定されないということは、他の英数字、グラフィック、他のデータ入力（生年月日、語、ランダム入力された文字、その他）まで、広げることができる。タッチスクリーンを使用している実施例に関して、例えば、他の入力（例えば、引出し線、図、ランダムな線、グラフ、点、その他）は、厳密に又はユーザ入力等のタイミングに基づいて、自動作曲処理を始めるために用いることができる。重要であることは、英数字特性のキーボード入力のようなユーザ入力、又はタッチスクリーンを経た図線のような他のデータ入力エントリ（すなわち、例えば、本来は一般に音楽的でないデータ入力）は、独自にデータ入力イベントに関連する楽曲の作曲を始めるために用いることができる。このように、唯一の楽曲作品が非音楽的データ入力に基づて創作できるので、音楽に堪能でない人でも、非音楽的データ入力に基づいて唯一の楽曲を創作することができる。この種の非音楽的データ入力に基づく楽曲生成処理は、シード又は他の楽曲生成開始データを選んで、自動作曲処理を開始する。特に英数字データ入力に関して、この種の文字も記憶され（単独か、又はデータ入力と関連する楽曲生成開始データを伴って）、他の楽曲生成システムに送信される。非音楽的データの伝送は、実際には、楽曲生成システムによって創作される曲を決定する情報を送信するための少ないバイト数のデータだけの送信であって、唯一の曲を他のユーザ／システムに発信するために用いることができる。

さらに他の実施例において、楽曲生成システムは歌詞の作成を援助する。一つの典型的な実施例においては、ユーザが楽曲のスタイル又はサブスタイルを選び、歌詞のカテゴリ（例えば、バラード／ストーリ、ラップ、ギャングスタラップ、韻文、エモーショナル、その他）を選ぶ。楽曲のスタイル／サブスタイル及び歌詞のカテゴリに基づき、語又は句の入力に応答して、システムは、例えば同語源語、韻、同義語、その他の使用により、歌詞をユーザ選択と整合したように作ることを試みる。好まれる語又は句は、歌詞カテゴリ（例えば、ストーリ、エモーション、無意味な、その他）によって特徴づけられる。そして、それは語又は句がよりユーザ選択と整合した方法で選ばれることを可能にする。この種の実施例に従えば、生成されている楽曲に合わせて、歌詞及び句を楽曲生成システムによって生成することができる。そして、ユーザは、選択的に受け入れる（例えば、保存する）か又はシステム生成された歌詞を拒絶することができる（例えば、保存しない）。

上記のように前もって作られたテキスト及びユーザ入力テキストの使用に加えて、ある実施例では、テキスト自体を生成することが好ましい。例えば、Ａ．Ｌ．Ｉ．Ｃ．ＥＡＩ財団の「ＡｒｔｉｆｉｃｉａｌＩｎｔｅｌｌｉｇｅｎｃｅＭａｒｋｕｐＬａｎｇｕａｇｅ（ＡＩＭＬ）」バージョン１．０．１ワーキングドラフト２００１年１０月２５日作成（以下のインターネット上の市民が利用できるｈｔｔｐ：／／ａｌｉｃｅ．ｓｕｎｌｉｔｓｕｒｆ．ｃｏｍ／）のような（その全体において本明細書に組み込まれたものとする）一連のｓｅｎｓｉｃａｌｔｅｘｔ生成に共通に利用可能なアルゴリズム的方法の使用がある。ＡＩＭＬは、単純な自動テキスト作成アルゴリズムを作成するためのドラフト規格の一つの実施例である。アルゴリズム的なテキスト自動生成、したがって、声音トラックとしての音素ストリームの自動生成をサポートすることは、本発明において有用である。図４３において、テキストを創作するアルゴリズムの使用が、ステップ１に示される。同様に、図４４のステップ２１においても、ＡＩＭＬのようなアルゴリズムのテキスト作成の使用ができる。ＡＩＭＬの単純な実施態様でさえ、句の比較的限られた数を使用して大きな効果を得ることができる。ある場合には、図４５に示すような電源／処理資源が制約される携帯用音楽装置において、ＡＩＭＬアルゴリズムの複雑さを軽減して効率化することが特に効果的である。

本願明細書において議論されるさまざまな実施例及び多数の機能との結合において、ある実施例では、人間の音声で一組の音素を記録することによって、声音ライブラリ（例えば、図４３の声音ライブラリＡ）を生成することが好ましい。この例では、エンドユーザは、各々の一組の音素を歌っているそれ自身を記録するオプション選択をすることができる。この特定の場合において、結果として生じる声音ライブラリが、エンドユーザの声に極めて似ている音声を有する音楽の出力を達成するために、声音トラックの自動生成の間、使われる。その上、有名人の音素は、有名人に対応する声音ライブラリを生成するために記録することができる。このようにして、有名人の声に極めて似ている声音トラックが生成される。この実施例に従えば、デビッドボウイ（例えば、各々の音素として、彼の実際の声か物まねタレントの声が記録される）、ジミーヘンドリックス等に対応する声音ライブラリがあってもよい。このように、エンドユーザは、それらの処理でデビッドボウイ及び／又はジミーヘンドリックスの「声」を有することができる。ある実施例においては、多数の声音ライブラリにアクセスして混合することができることは有利であると考えられる。

音声情報の経路選択に伴う付加な実施例を以下に説明する。図４６は、本発明のある付加的な実施例を示す。図示されるように、実施例（例えば、図３２を参照）として、プレーヤ１０は、ＤＳＰ４２、マイクロプロセッサ３６、音声コーダー／デコーダ５２、オーディオ入力／出力ジャック６６、マイクロプロセッサバス３７及び３８、バスインターフェース３９（あるいは、シリアルＩ／Ｏ５７）、マイクロプロセッサＲＡＭ（すなわち、内部ＲＡＭ、又は、それ以外はＭＰ３６の制御下で）及びバスポートコネクタ５３を組み込む。更に、この一組の実施例において、ＤＳＰ４２とハードウェアコーデック５２（デジタル信号６２）の間の信号はデジタル信号で、ハードウェアコーデック５２は、ＤＳＰ４２との間でデジタル化された信号を送信／受信している。ハードウェアコーデック５２及びアナログ音声Ｉ／Ｏ６６の間の信号は、アナログ信号である。

本実施例は、ＤＳＰ４２を使用している音声情報（例えば、楽曲）を生成することができる音声装置である。ある実施例において、音声情報は、私設のフォーマット（すなわち、携帯用楽曲装置のハードウェア詳細に影響を及ぼす効果的なフォーマット）に符号化される。ある他の実施例（例えば、音声装置がデータを記憶することができ及び／又は他のシステムに接続している時）において、音声情報をより容易に共有することができ（例えば、他の異なるシステムを有して）及び／又は種々の他のフォーマット（例えば、ＣＤＲＯＭ、その他）に変換することができるように、音声情報（例えば、私設のフォーマットに加えて）の所有権の保持されていないフォーマットを生成することが望ましい。例えば、音声情報のための一つの好ましいフォーマットは、ＭＰ３（ＭＰＥＧＡｕｄｉｏＬａｙｅｒ３）である。明らかであるように、他のフォーマット（例えばＷＡＶ、ＡＳＦ、ＭＰＥＧ、その他）もまた使用可能である。

図４６は、どのようにして、この種の音声装置がストリーミングフォーマットの音声情報の共有を容易にするシステムに接続されるかの実施例を示す。図示されるように、プレーヤ１０はコネクタ５３及びアナログ音声Ｉ／Ｏ６６を介してシステム４６０に接続されている。当業者に明らかであるように、接続は単独、又はその他との結合のいずれかで行われる。実施例において、システム４６０は、オーディオ入力プラグ（そして、関連音声処理回路及びソフトウェア）及びＵＳＢポート（ある実施例では、ＵＳＢ３９は、ＰＣＭＣＩＡ、カードバス、シリアル、パラレル、ＩｒＤＡ、ワイヤレスＬＡＮ、その他、インターフェース）を有するパーソナルコンピュータである。ある実施例において、システム４６０は、テープレコーダ、ＣＤレコーダ、ＭＰ３プレーヤ、その他であり得る。システム４６０は、音声能力がある装置（例えば、音声Ｉ／Ｏ接続及び関連能力を有する）であれば任意のものでよく、任意選択で、プレーヤ１０のコネクタ５３につながるためのバスポートを含むことができる。

図３２及び図４６と関連して上記説明を続けると、ある実施例では、プレーヤ１０の音声生成動作の間、ＤＳＰ４２から出力されるデジタル信号６２は、Ｉ２Ｓフォーマットであり、ＵＳＢＩ／Ｆ３９（あるいは、シリアルＩ／Ｏ５７）に信号線を追加することができる。この例では、ＵＳＢＩ／Ｆ３９（あるいは、シリアルＩ／Ｏ５７）は、ＤＳＰ４２（例えば、Ｉ２Ｓフォーマット信号）から、入力信号を直接受け入れることができ、コネクタ５３上の出力データストリームにそれを従わせているバスマスタである。この例では、ＵＳＢＩ／Ｆ３９（あるいは、シリアルＩ／Ｏ５７）として、好適に使うことができる典型的な装置は、バーリントン（マサチューセッツ）のＳｃａｎＬｏｇｉｃ社から入手可能なＳＬ１１ＲＵＳＢコントローラである。

ある実施例において、プレーヤ１０の音声生成操作の間、ＤＳＰ４２から出力されるデジタル信号６２は、ＭＰアドレスバス３７及びＭＰデータバス３８に付加信号線を経由することができる。この例では、ＵＳＢＩ／Ｆ３９（あるいは、シリアルＩ／Ｏ５７）は、これもＳｃａｎＬｏｇｉｃ社から利用できるＳＬ８１１ＳＵＳＢＤｕａｌＳｐｅｅｄＳｌａｖｅＣｏｎｔｒｏｌｌｅｒのようなスレーブＵＳＢ装置である。この例では、特定のコスト削減がより単純なＵＳＢＩ／Ｆ３９（前述のＳＬ８１１ＲのようなマスタＵＳＢ装置に対して）を用いて実現することができるが、トレードオフはＭＰ３６がデジタル信号６２の流れを制御することができることを必要とするということである。これは、主に、この例で、ＭＰ３６がＭＰアドレスバス３７及びＭＰデータバス３８のマスタであって、このバスを含んでいる転送動作を実行することを必要とするという理由による。ＭＰ３６がこれらのそれ以上の機能を実行する充分な能力を有する場合において、この実施例は好ましい。前述の実施例においては、前述した様に、価格／パフォーマンスが珍重されるが、より能力があるＵＳＢ、Ｉ／Ｆ３９（あるいは、シリアルＩ／Ｏ５７）部分が、ＭＰアドレスバス３７及びＭＰデータバス３８上の有効資源にほとんど有害な作用をおよぼすことなく使用され得る。

上記した実施例において、デジタルデータの形で、ＤＳＰ４２から出る音声情報出力は、システム４６０によって受信されるようにコネクタ５３を通じて送られる。システム４６０は、対応するバスポート、その他（例えば、ＵＳＢポートか、あるいは、又は他のポート（例えば、ＰＣＭＣＩＡ、カードバス、シリアル、パラレル、ＩｒＤＡ、ワイヤレスＬＡＮ（例えば、８０２．１１）の少なくとも１つと互換性を持つポート）を経て、この種のデジタルデータを受信することができなければならない。

この種の構成は、ユーザによりユーザフレンドリな経験を許容するために、制御機構（例えば、音声の演奏と取り込みの間の同期）の使用を必要とする。その一方で、ユーザは、プレーヤ１０での楽曲生成／作曲の動作、デジタル信号６２からのデジタル音声情報のコネクタ５３への経路選択を行う動作、システム４６０で音声情報を受信して処理を行う動作、そして、システム４６０上でその音声情報の記録を行う動作を、視聴したり／それに参加したりする。この種の制御機構の一つの実施例は、ユーザ入力に応答するシステム４６０上のソフトウェア／ファームウェアプリケーションの実行であって、ＭＰ３６に音声生成処理を開始するように指示する制御信号を使用して、コネクタ５３を介してプレーヤ１０で処理を始めることである。あるいは、制御機構及び／又はシステム４６０が行程手順に参加して、デジタル音声情報を受信するために用意された状態にある限り、行程手順を始めるユーザ入力が、プレーヤ１０に最初に受け取られる。

前述の説明において、制御情報は、コネクタ５３（例えば、デジタル音声情報に加えて）を通してプレーヤ１０及びシステム４６０の間で通信される。この種の制御情報は、本発明の態様を実施するために必要ではなくて、使用する場合にエンドユーザにより直観的体験を与える。例えば、ある実施例において、デジタル音声データが、（例えば、アナログ音声Ｉ／Ｏ６６を通るアナログ音声情報の代わりに）コネクタ５３を通じて制御可能に管理されるので、制御可能なデータリンクを組み込むこの種の装置は、アナログ音声Ｉ／Ｏ６６（例えば、８インチステレオフォノプラグを使用しているアナログ音声リンク）上の接続を必要としない。

別の実施例において、例えば、より多い処理資源で、プレーヤ１０の音声生成動作の間、ＤＳＰ４２から出力されるデジタル信号６２は、プレーヤ１０上のローカル記憶場所（（例えば、ＳＭＣ４０を経てのような、取り外し可能なメモリ又はマイクロドライブ、ＲＡＭ、他のフラッシュその他）に送られる。この方法では、デジタルオーディオストリームを、外部システム（例えば、システム４６０）を用いずに保存することができる。この種の動作において使うことが可能なデジタルフォーマットは、ＭＰ３、ＷＡＶ及び／又はＣＤ音声を含む。

他の実施例では、システム４６０に（例えば、共有化を可能にすること等のために）音声情報を送ることは、システム４６０上（例えば、既存のサウンドカード、その他を用いて）の対応するアナログオーディオ入力（例えば、８インチステレオフォノ入力プラグ）に、アナログ音声Ｉ／Ｏ６６でアナログ信号６４を送ることによって成し遂げられる。この場合、ＤＳＰ４２から出るデジタル音声情報出力がコネクタ５３に送られる必要がないという点で、本願明細書において議論される択一信号の実施例が必要とされない。より能力のあるＭＰ３６も、マスタタイプＵＳＢＩ／Ｆ３９も必要とせず、したがって、費用のより効果的な解決を提供するので、この種の実施例は、あるアプリケーションにおいて有利である。従って、本実施例は容易かつ能率的に、プレーヤ１０に組み込まれ得る。この種の容易性及び効率性にもかかわらず、本方法は、システム４６０に進んだ音声情報のフォーマットがアナログであり、したがって、信号損失がより大きくそして信号干渉（例えば、電磁気の）に影響されやすいので、前述の実施例よりより望ましくない。いずれにしても、この装置は、コネクタ５３を経てシステム４６０とプレーヤ１０の間を伝送されている制御情報を含むことができる。ユーザが処理を始めることができるという点で、この種の装置は、エンドユーザにより直観的な経験（本願明細書において関連するさまざまな方法で）を提供することができ、そして、その処理の同期は、コネクタ５３通して装置の間を通過している制御情報により、ユーザに対して透過的に達成することができる。

ここで、特に本実施例の使用にとって有用であるファイル形式の新しい実施例を提言する。しかしながら、ファイル形式に関する本開示の部分が、携帯用音楽装置以外の別の種々の装置において、容易に利用されることは、ファイル形式の分野の当業者によって理解されるであろう。したがって、楽曲装置に関連する実施例が参照される一方で、他の非常に類似した実施例（一般のコンピュータシステムにおいて使用するファイル、ＣＤのような音楽ファイル、他の種類の携帯用機器で使用するファイル、その他のようなものを含む）を直ちに案出することができることは、明らかである。

現在記載されている「溝付き」ファイル形式は、「スロット」と呼ばれている一まとまりの独立装置を含む。スロットが他のスロットに影響を及ぼさずに加えられるか又は取り除かれるので、与えられたタイプのスロットが他のスロットに影響を及ぼさずに大きくされるか又は縮小され、そして、所与のファームウェア／オペレーティングシステム（ＯＳ）リリースの範囲内又は現在のそうしたものの範囲内で未知のタイプを有するスロットは、無視されるので、ファイル内のデータ編成に柔軟性を与える。そして、それはバックワード互換性の問題を解消する助ける。

第１のレベル解析（例えば、各個別のスロットをアクセスすること）と同様に、全ての専用ファイルのために同じ一般的なファイルフォーマットを有することは、ファイルデータの検査合計と整合性の確認のために、同じコードの使用を可能とする。

図４７をここで参照すると、スロット構造（ＳＬＳ）は、スロット構造ヘッダとそれに続くＮ個のスロットとからなり、個々のスロットは好ましくは項目を含む。

図４８は、典型的なＳＬＳヘッダ構造を例示する。「ＨｅａｄｅｒＬｅｎｇｔｈ」フィールドはヘッダの長さを含み、それは、非互換性をつくることなくヘッダの将来的拡張を許容するように使用される。「Ｃｈｅｃｋｓｕｍ」フィールドは、スロットファイルの検査合計を含む。「ＳＬＳＳｈａｄｅ」フィールドは、例えば、ファイルがインポートされ及び／又はアクセスされるときに決定されるべき、スロットファイルの正確なファイルタイプを含む。「ＳＬＳＴｙｐｅ」フィールドは、これがどの種類のスロットファイルか（例えば、ファイルが曲、演奏リスト、サンプルセット、その他のどれであるか）を示す。「ＳＬＳＶｅｒｓｉｏｎ」フィールドは、例えば、互換性（例えば、将来、特定の種類のスロットファイルのフォーマットが変わるかどうか）を保持するために用いる。

「ＤｅｔａＬｅｎｇｔｈ」フィールドは、各々のスロットのデータ長フィールドが含むバイト数を含む。ある実施例において、このフィールドは、スロットファイルの容量を最適化するために用いる。−その理由は、スロットファイルの他のタイプは非常に大きいデータフィールド（例えば、サンプル）を使用するのに対し、スロットファイルのあるタイプは非常に少ないデータフィールドしか使用しないか、又は全くデータフィールドを使用しない（例えば、リスト）からである。

「ＮｕｍＳｌｏｔｓ」フィールドは、スロット構造のスロット（Ｎ）の数を保持する。スロット番号が直ちに利用できる場合、ファイルをデコードすることはより容易である。ある実施例において、この冗長な情報は、スロット構造の整合性を検査するために用いられる。

検査合計の目的は、スロットファイルを読出し／書込みエラーから保護することである。多くの実施例において、ＣＲＣ算出によって最高の保護が与えられることが期待される。しかし、これは、遅くて複雑で、いずれにしろ実際には必要でない。その理由は、次のことにある。すなわち、読出し／書込みエラーがめったにないので、多重誤りからの保護を必要としないからである。したがって、この目的のためには単純な検査合計算出で充分であると思われる。

例えば、３２ビットプロセッサを含んでいる実施例において、最も速くて最も効果的な検査合計計算は、ファイルｄｗｏｒｄｂｙどぉｒｄの全てのデータを加算することである。残念なことに、ｄｗｏｒｄｂｙｄｗｏｒｄによる計算は、ｗｏｒｄｂｙｗｏｒｄと同様に、整合性の問題が生じる。

このような実施例では、ファイルのバイト数が多数のｄｗｏｒｄ又はｗｏｒｄであってはならない場合は、検査合計計算のためのファイルの終わりに、ゼロを詰めるバイト追加することにより、調整することができる。しかしながら、この種の実施例で、各々のチャンクの容量が、多数のｄｗｏｒｄ又はｗｏｒｄであることを強いられない限り、ファイルがいくつかのチャンクに書かれるときに、より複雑な検査合計の事態となる。

別の実施例は、スロットファイルの全てのフィールドを語整列とすることによって、この問題解決の折衷案を含む。これらの別の実施例において、全てのスロットは、偶数のサイズ（例えば、ｗｏｒｄ（語）の整数）を有する。このように、一語ずつ検査合計を計算することは、比較的容易になる。これはｄｗｏｒｄ毎の計算ほど速くはないが、バイト単位の計算より速い。ファイルが比較的遅い媒体（例えば、フラッシュメモリカード）に記憶される実施例において、この問題の影響はさほど大きくはない。その理由は、明らかに、検査合計計算遅延への最も大きく影響するものは、データ読出しに必要な時間であるからである。

図４９において例示される典型的なスロットフォーマット実施例を説明する。異なる種類のスロットが所与のスロットファイルにおいて使われる場合には、「ＳｌｏｔＴｙｐｅ」フィールドは、スロットの内容の性質を示す。「ＮａｍｅＬｅｎｇｔｈ」フィールドは、「Ｎａｍｅ」フィールドの長さをバイトで保持する。ある実施例において、「Ｎａｍｅ」フィールドがない場合、「ＮａｍｅＬｅｎｇｔｈ」は０である。「Ｎａｍｅ」フィールドは、６５５３５文字までのいかなる文字列も保持することができる（例えば、この例では「ＮａｍｅＬｅｎｇｔｈ」フィールドが２バイト）。「ＤａｔａＬｅｎｇｔｈ」フィールドは、バイト（再び、「Ｄａｔａ」フィールドがない場合、「ＤａｔａＬｅｎｇｔｈ」は０である）で「Ｄａｔａ」フィールドの長さを保持する。「Ｄａｔａ」フィールドは、意味がスロット構造のタイプ及び／又は所与のスロット構造のタイプの範囲内のスロットのタイプに依存する情報を保持する。

ある実施例において、スロットの特定タイプは、ファイル参照を保持することができる。この種の「ファイル」スロットにおいて、スロットタイプは、スロットによって参照されるファイルのファイルタイプに関連し、そして、「Ｎａｍｅ」フィールドは、ファイルの名前を含む。このように、ファイルスロットは、ＳＬＳＴｙｐｅによって与えられるタイプとは別に、ファイルを参照することができる。

スロットファイルのタイプは、特別な方法でファイルを参照するスロットを含むことができる。この場合、スロットタイプは固定値を有し、それはこの種のスロットファイルだけに有効である。この種のスロットの「Ｎａｍｅ」フィールドはファイルの名前を含み、そして、ファイルタイプはコンテキストによって与えられる。この実施例を続けると、ファイルスロットの「Ｄａｔａ」フィールドは、ファイル設定ファイルのファイル設定を好適に記憶するために用いてもよい。

本説明において、「ＡｌｉｅｎＳｌｏｔ（異種スロット）」（スロットファイルの所与のタイプ）は、現在のファームウェア及び／又はオペレーティングシステムリリースよってタイプが認識されないスロットである。例えば、「異種スロット」は、当初リリースＢ（リリースＢがリリースＡより最近のもの）に書かれたリリースＡのファイルを読む場合、存在することがある。ある場合において、コンピュータ上で創作されるか変更されたスロットファイルは、それ自身のタイプを加えることができ、そして、ポータブルシステムは、それを「異種スロット」として考える場合がある。たとえどこでそれらが非互換性をつくらずにスロット構造に載置されても、全てのスロットファイルが「異種スロット」を受け入れることを可能にすることは有利である。この方式では、スロットファイル管理に２つの制約を招く。すなわち、「異種スロット」は無視される（例えば、それらは現在のファームウェア公開の効果を有してはならない）場合、そして、スロットファイルが変更されるときに、「異種スロット」は保存される（例えば、削除されなくて）場合である。この方式は、非互換性をつくることのない将来のファームウェア／ＯＳリリースのいかなるスロットファイルにも相補情報が加えられるようにする。好ましくは、以前のリリースは新規なリリースにおいてつくられるスロットファイルを読出すことが可能であり、そして、以前のリリースがこの種のスロットファイルを変更する場合、新規なリリースに関連する情報が保存される。

あるスロットファイルにおいて、全てのスロットが異なったスロットタイプ値を有することは望ましい。これらの場合、それが探しているスロットを見つけるために、ファームウェアが全ファイルを走査して／書き込むので、スロットがスロット構造に配置される順序は重要ではない。スロットファイルの他の若干のタイプにおいては、ファイルがどのように動くかを判定するために純情が用いられるので、スロットが配置される順序は重要である。実施例として、項目（例えば、曲又はサンプル）が、それらがスロット構造に位置する順序で、演奏され／実行され／アクセスされ／その他であり得るので、リストを有する場合、この種の装置は望ましい。したがって、所与の実施態様で、スロットの順序づけは、スロットの種類（例えば、ファイルスロット）のために重要であって、スロットの他の種類のためには重要でない。

ある実施例において、所与のタイプ（例えば、ＳＬＳタイプで規定された）のスロット構造に関して、あるスロット（例えば、スロットタイプ値又はスロットタイプ値の範囲で規定された）は、好ましくは完全なスロット構造（例えば、スロットの「Ｄａｔａ」フィールドに位置する）を含む。入れ子にされたスロット構造を可能とするので、この方式は有利である。

いかなるスロットファイルも、読出すときに、以下の３点のうちの１又は複数で確認を実行することが有効である。すなわち、スロット構造のタイプは現在のリリースにおける知られたタイプでなければならない、ＳＬＳバージョンは現在のリリースにおいてサポートされていなければならない、スロットファイルデータは整合していなければならない、の３つである。データ整合性検査は、ファイル容量がＮスロットの容量の合計に対応することを確かめることからなる。ここで、ＮはＳＬＳヘッダにおいて読出されるスロットの数である。よって、例えば、データ整合性検査は、ＳＬＳにおいて特定されるスロットの数におけるエラーを検出する。ある実施例において、これらの確認は、ファイル検査合計の後で実行される。この確認は、ファイル検査合計確認を有するので冗長でない。その理由は、スロット構造の整合性の確認は、スロット構造（例えば、現在のファームウェア／ＯＳリリースにおいてサポートされていない古いフォーマット）のフォーマットの変化のようなものを検出するのに対し、後者はファイルの書き込み又は読出しにおけるエラーを検出するからである。ある場合において、例えば、リアルタイム動作のために時間が長くかかりすぎる場合、検査合計確認はスキップされてもよい。これは、サンプルのような比較的大きなファイルの場合、望ましいことである。そして、それはリアルタイム再生のためにアクセスされる。

ある実施例において、歌曲ファイルは、以下の４つのスロットの１又は複数を有することができる。すなわち、歌曲データスロット、楽器スロット（例えば、別に記憶することができる楽器インデックスを保持）、サンプルセットスロット（例えば、任意の関連するサンプルセットファイルを保持）、及び設定スロット（例えば、歌曲設定（音量、スピード及びピッチ）を保持）の４つである。サンプルがスロットファイルに記憶される場合、任意の適用可能なサンプル設定（例えば、サンプル記述子、正規化係数、効果インデックス及び効果タイプ）も、サンプルデータと同じファイルに記憶することができる。この特徴は、将来の進化のための大きな柔軟性を生じる。ある実施例において、ファイルにサンプルをスロットとして記憶することが望ましい。

「サンプルデータ」は、サンプルを演奏することに関係しているデータ（例えば、ＰＣＭデータ）を示す。ある実施例において、サンプルデータの全ては、一つのスロットの「データ」フィールドに記憶することができる。他の実施態様において、サンプルファイルは、付加的な相補情報（例えば、サンプル設定スロットに適合させることができないカスタムメイドの効果の定義）を含む。この相補情報は、例えば、関連するスロットタイプを用いて、異なるスロットに記憶される。他の変形（必ずしも、前のものと相互に排他的でない）として、サンプルを個々に演奏することができるより小さい塊に分割することが考えられる。一つの例として、この種の実施は、その塊の間に時間間隔を有するようにして（例えば、連続的よりむしろ）サンプルを演奏することができるようにする。

ある実施例において、サンプルファイルは、２つのスロットを有する。すなわち、サンプルデータ（例えば、ＰＣＭデータ）を保持するサンプルデータスロット、及び、サンプル設定（例えば、サンプル記述子、正規化係数、効果、その他）を保持するサンプル設定スロットである。異種スロットが、サンプルファイル（例えば、ファームウェア／ＯＳによって認識されないで無視されたサンプルファイル）に受け入れられるようにすることが望ましい。例えば、これは、コメント又はサンプルファイルデータに関連する他のデータを含むように用いることができる。

理想的には、スロットがサンプルファイルに格納される順序は重要ではない。しかしながら、上記「サンプルファイルの進化」で述べたように、容量が大きいので、サンプルファイルは特別な制約を受ける。サンプルデータスロットの後にサンプル設定スロットを格納する場合、ある状況（例えば、重く断片的なクラスタ割当てのような状況）で、サンプル設定値情報を書き込むための時間は、不所望に長い。例えば、断片化の場合、設定値が記憶されている（すなわち、サンプル設定スロットの「Ｄａｔａ」フィールド）サンプルファイルの終端のアドレスを算出することは、容易ではない。この問題に対処するために、ある実施例において、変更されるべき領域は、常にサンプルファイルの主要なＶＳＢ（ダイナミックメモリ割当ての可変サイズブロック）に位置するようにする。これは、このスロットの長さがクラスタ容量と比較すると十分に小さいという事実に基づいて、サンプル設定スロットにサンプルファイルの第１のスロットを作ることによって達成することができる。

リストファイル（例えば、各々のスロットが項目又は動作を識別することができ、スロットの順序が演奏及び／又は実行の順序に影響を及ぼす場合）を含む実施例において、最後のスロットを、最後の項目の実行後何が起こるかを知らせる「命令終了スロット」とすることが有利である。実施例として、この種のスロットは、「演奏中止」又は手動介入があるまで演奏を続ける「開始までの繰り返し」を示す。これらの実施例においては、ファイルスロットがリストファイルに配置される順序により、リスト（例えば、サンプル又は歌曲）の項目が実行及び／又は演奏される（例えば、たとえ命令終了スロットが組み込まれていなくても）順序が決定される。一方、これを使用する場合、命令終了スロットは、Ｓリストファイルのどこにでも格納することができる。

上記の例に従えば、リストファイルは、もはや利用できない１又は複数のファイルの参照を保持することになる。さほど長く存在しないファイルの各参照（例えば、ファイルスロットによって保持される）は、「失われた項目」と考えることができる。リストファイルが変更されたとき、失われた項目スロット（異種スロットとは異なった）は好ましくは削除される。

無線局プリセットのような項目のリストを含む実施例において、無線局プリセットは、専用のリストファイルに記憶される。例えば、この種の無線リストファイルの各スロットは、プリセットの名称及び周波数を保持する。この例では、例えば、非互換性をつくらずに、「データ」フィールド内で、より多くのフィールドを加えることが可能である。

図形ファイルを含む実施例において、図形を図形処理ファイルに記憶することが望ましい。ここで論じられるスロットファイルフォーマットは、いくつかの画像／図形が、例えば、各々異なる属性をもって記憶されることを可能にする。この装置は、さまざまな静止画像（例えば、携帯用機器上の多様なＧＵＩ表示画面用の静止画像）がファイルに格納されることを許容する。ある場合において、この方式はまた、動画を記憶するために用いられる。例えば、動画の連続したコマと関連するデータは、個々のスロットに位置することができ、そして、スロットの順序づけは動画の連続したコマの順序づけを決定するために用いることができる。

設定された拍子記号と同様に、楽曲ルールに従う楽曲を生成する楽曲生成システムは、典型的には完全に特定の楽曲モードを知っている。結果として生じる出力が音楽的に強い興味をそそるように、音声情報を生成する楽曲ルール／アルゴリズムは、特定の楽曲モード及び拍子記号を巡って動くように構成される。このように、創作された音楽作品の生成又は再生の間のいかなる時も、拍子記号（例えば、アクセントの適当な位置、ドラム挿入等を含む、楽曲の教師及び／又はグルーブ）とモード（例えば、いかなる時でも互換性を持つ一組のピッチ）をトラッキングする定義済みの変数がある。

加えて、ユーザ入力に応答して又は楽曲ルールの一部に応答して再生される選択されたサンプルを用いて、最終的な音楽の出力が有利に増やされる。例えば、単純なメロディを歌っている女性の音声の短いサンプルは、ある調整の機会に、特定のヒップホップスタイル曲に加えることができる。この種の実施例は、予め録音してある音響が、楽曲の出力を強化するために、楽曲生成／再生システムかアルゴリズムによってどのように利用されるかについて、示すものである。

所有権の保持されていないサンプルフォーマットの使用はまた非常に望ましい。それは、エンドユーザが、他の手段を用いて容易に他の音響サンプルを共有及び／又は生成することを可能にし、創作された音楽作品にそれらを含めることを可能にするからである。この種の方式は、エンドユーザが音楽的な素養又は経験を有しない場合であっても、エンドユーザ側の高度な創造力及び音楽の参加を可能にする。この種の初心者エンドユーザに、音楽の創造力についての興味を引き起こす経験を効果的に与えることが、本開示の目的のうちの１つである。

その上、楽曲システムの好ましい実施例は、使用するサンプル上での信号処理を可能にする。例えば、この方法は、好ましいタイプのシステムのＤＳＰ機能性を用いて、ユーザが容易にサンプルピッチや速度を調整することを可能にする。一つの例として、Ａｔｍｅｌ社から入手可能なドリームＤＳＰチップ（そのデータシート及びアプリケーション／ユーザマニュアルは、ここに取り込まれたものとする）は、サンプルが、ドップラ、ウオブラー、エコー、その他のようなさまざまな音響効果の適用とともに、ピッチ、速度、その他を含む、さまざまな線に沿って調整することを可能にする。これらの態様及び特徴は、本願明細書において更に詳細に記載されている。

音声コンテンツの創作の一つの問題は、楽節間のサンプルの再生が、ピッチ又はリズムに関してその楽曲との同期からずれて鳴り響くことがあるということである。これは、通常、特定時点でのサンプルと楽曲との間のデフォルト同期がとれていないことによるものである。これに関するひとつの方法は、例えば、ものを言う音声又は音響効果のような、明白なピッチ又はメロディを有しないサンプルを使用することである。しかしながら、特により高いレジスタでは、メロディサンプルの使用が楽曲の多くのスタイルにおいて望ましいので、サンプルにピッチ及び／又はリズム情報を関連付ける（組み込む又はその反対）能力をもたせることが、場合によっては望ましい。この種の情報は、音楽作品の特定のピッチ、メロディ及び／又はリズム特性にサンプルが同期するようにするために、楽曲装置の楽曲ルール及び／又はアルゴリズムによって解釈される。好ましい実施態様に従うこの種の装置を、以下に説明する。

図５０は、本発明の好ましい一実施例に従って利用されるサンプルデータ構造５４０である。図示するように、サンプルデータ構造５４０は、サンプルデータフィールド５３５及びオプションのヘッダ部５３０を含む。図５０の説明において、サンプルデータフィールド５３５は、音響サンプルデータ５１０を含み、ヘッダ部５３０はタグＩＤ５２５、リズム情報５２０及びピッチ情報５１５を含む。

タグＩＤ５２５は、互換システムに対してオプションのヘッダ５３０を識別するために用いて、非互換システムの以前製品との互換性を提供するために用いてもよい。例えば、サンプルを読出している受け継がれたシステムが音響サンプルデータ５１０を読出し、そして、リズム情報５２０又はピッチ情報５１５（例として）を無視するというような方法で、音響サンプルデータ５１０の起動のためのポインタを与えることによって、以前の製品との互換性は達成される。ある実施例において、これは本願明細書において記載されているスロットファイルフォーマットを介して、好ましくは達成することができる。付加的な実施例において、混合モードＣＤＲＯＭがアップル社及びＩＢＭ社双方の仕様互換パーソナルコンピュータＣＤＲＯＭドライブ上で動作するように符号化される方法と同様のやり方で、実際には、透過的に各々のシステムをボリュームの正しい部分までスキップさせるために、ボリュームのはじめにポインタを提供することによって、これは成し遂げられる。この種の技術は、レガシーシステムを、ボリューム（又はファイル）が実際にレガシーフォーマット化されたボリュームであると思っているように、騙すことができる。したがって、サンプルデータファイルがヘッダフィールド５３０の付加情報から利益を受けるシステムのヘッダフィールド５３０内に、サンプルデータファイルが周期情報５２０及び／又はピッチ情報５１５とともに提供されるとき、本発明の利点が利用されるが、同じサンプルデータファイルをまた、ヘッダフィールドにおける付加データから利益を得ることができないシステムにおけるサンプルデータを提供するために使用することができる。後者の場合、そのファイルは、音響サンプルデータ５１０だけを提供するようにシステムに現れる。

ピッチ情報５１５は、固有の周期率である、サンプルに伴うピッチを示しているパラメータデータを含む。例えば、このパラメータデータは、サンプルが通常の未調整率で演奏される場合、ピッチ値がＣ＃に対応する値に関連付けられる。これは、関連音響サンプルデータがＣ＃音符とみなされる楽曲生成処理に関係する楽曲ルール及び／又はアルゴリズムに知らせる。すなわち、Ｃ＃音符が互換性を持つと考えられる場合、音響サンプルは、いかなるピッチ調整なしで好ましくは演奏される。この方式に対する一つの利点は、Ｃ＃が互換性を持つと考えられない場合、音響サンプルデータが、適当なピッチ値に対するピッチを上又は下に移行することができるということである。アルゴリズム／楽曲ルールが固有の再生速度のためのピッチ情報を知っているので、それらはピッチの調整を算出することができ、再生の間、サンプルの認められたピッチを調整するために、ＤＳＰ資源及び機能性（ドリームチップに関して本願明細書において論じられるように）を使用することができる。このように、サンプルピッチは、通常、現在のモード（一つの実施例として）に与えられた適当なピッチに合致する。

周期情報５２０は、期間関連のパラメータデータを含む。このデータは、関連する音響サンプルデータのタイミング特性を識別する。例えば、音響サンプルが最初から７５ミリ秒のリズム強調位置を有する場合、このパラメータによりこれを示すことができる。この例では、ヘッダの期間部分は、固有の速度で演奏されるときに、音楽作品を生成する楽曲ルール／アルゴリズムに対して、この特定の音響サンプルが７５ミリ秒のリズム強調位置を有することを、知らせる。したがって、それがメモリに書き込まれ、エンドユーザが歌曲中のそのサンプルを演奏するとき、楽曲ルール／アルゴリズムは、そのサンプルのリズム強調位置を知ることができ、かつ、リズム強調位置が楽曲の適切な位置（例えば、ダウンビート）で起こるように、サンプルを時間調整できる。この時間調整は、例えば、ここで述べられたように、ＤＳＰ資源及び機能性を使用して行われる。例えば、サンプルが定義可能なテンポを有する場合、周期情報５２０は、分あたりの拍子（ＢＰＭ）情報の形で伝達することができる。

本発明のこの種の実施例は、エンドユーザの音楽の経験を改良する方法を備える楽曲演奏システムを提供することができることが明らかであろう。この種の装置は、例えば、ハードウェアシステム（例えば、手で持てるサイズの携帯用機器）又はソフトウェアシステム（例えば、パーソナルコンピュータ上で動作するソフトウェア音楽システム）で、使用することができる。ピッチ又は時間非互換性による弊害は比較的小さく、サンプルは、このようにエンドユーザによって歌曲の間、演奏される。

図５１は、サンプル音響ファイルと関連する振幅波形の簡略例を示す。図示の例において、Ｔ１、Ｔ２及びＴ３で表される、増加するリズム動作（例えば、振幅の急激な一時的な増加）の３つの一般的な位置がある。サンプルデータファイルは、増加する振幅のこの種の領域を識別するために、ソフトウェアを経て処理される。図５１において表される波形が、例えば、２９０ｍｓの持続期間であると仮定する。例として、解析ツールが１０ｍｓのグリッド解像度（垂直グリッド線を有する図に示す）を有する場合、解析ツールは、リズムイベントを検索するために、ファイルを走査する（例えば、比較的高振幅の短い瞬間）。一つの好ましい実施例において、ツールはリズムイベントの直前のグリッド位置を識別して、任意のヘッダフィールド５３０のデータに包含させるよう、その情報を取り込む。図５４に関して、分析プロセスに関する詳細は以下でさらに説明する。

図５１に示したように、実施例サンプルは、非等距離となるように間隔をあけられるほぼ３つの重要なリズムイベントを有する。もちろん、この分布例は、１０ｍｓのグリッド解像度及び２９０ｍｓのサンプル継続期間のいくぶん任意の例に基づく。このグリッド解像度の場合、この例は、４つのリズムサブパート（例えばＴ０、Ｔ１、Ｔ２及びＴ３から始まっている部分）が異なる持続期間である例である。この例では、第１のリズムサブパートは、０ｍｓのタイムスタンプＴ０及びＧのピッチ値Ｐ０を有する。第２のリズムサブパートは、５０ｍｓのタイムスタンプＴ１及びＦ＃のピッチ値Ｐ１を有する。第３のリズムサブパートは、１１０ｍｓ及び不定ピッチ値のタイムスタンプＴ２を有する。第４のリズムサブパートＴ３は、２００ｍｓのタイムスタンプ及びＧ＃のピッチ値を有する。

この例では、明確にするため、楽曲のモードが、サンプルが演奏される歌曲の位置で「リディアン降順」であると仮定する。
したがって、Ｔ０：Ｐ０と確認される第１のリズムサブパートは、「リディアン降順モード」において許容可能であるピッチ値を有する。したがって、サンプルのこの楽節はピッチを移行しない。同様に、サンプルの起動のリズムイベントがエンドユーザによって始められるので、時間Ｔ０は調整されない。

この実施例をさらに説明する。Ｔ１：Ｐ１として確認される第２のサブパートはＦ＃のピッチ値を有し、「リディアン降順モード」において許容され、したがって、ピッチを移行しない。リズムイベントＴ１は５０ｍｓと関係し、したがって、これは、より密接に楽曲のテンポに釣り合うように時間シフトされる（例えば、創作されている楽曲の周期的グリッド／解像度と符合するために、僅かに減速されるか又は速度を上げられるかする）。歌曲の楽節がテンポを有し、例えば、８分音符が６０ｍｓの継続期間を有する場合、Ｔ１：Ｐ１の起動が８分音符の始まりに合わせて起こるように調整され、Ｔ１：Ｐ１の継続期間は、音楽の拍子記号に合わせて、６０ｍｓを占めるように僅かに長くされる。もちろん、これらの例は、本発明を実施するために必ずしも使うことができない、さまざまなオプションを構成する。

以前のサブパートが通常の速度で演奏されていた場合、第３のサブパートＴ２：Ｐ２は１１０ｍｓから始まるであろう。この例では、前のサブパートが１０ｍｓ長くされているので、テンポと同期をとるためには、Ｔ２：Ｐ２サブパートは１２０ｍｓから始まる。したがって、６０ｍｓの８分音符の例では、サブパートＴ２：Ｐ２の始まりがテンポと同期して起こり、そして、それが９０ｍｓの継続期間を有するので、それは１２０ｍｓ（６９ｍｓの８分音符に合わせて）の継続期間に対して５０％時間伸張されるか、時間が６０ｍｓまで減少されるか、又は９０ｍｓのままであるかである（例えば、演奏されている楽曲のスタイルのために適所にある特定の楽曲ルール／アルゴリズムに依存している）。このサブパートが関連ピッチ値をもたないので、ピッチを調整していない。

図２の最後のサブパートＴ３：Ｐ３は、Ｇ＃の関連ピッチ値を有する。現在のモードが、楽曲生成フローの間に遭遇したＧ＃音符がＧと置き換えられる「リディアン降順」であると仮定すると、サンプルのこの楽節は、Ｇまで関連ピッチを下げるようにピッチが調整される。楽曲のスタイル及び／又は拍子記号、グルーブ、その他に合わせて、本願明細書において記載されているように、始点及び持続期間を指定することができる。

図５０に示したように、サンプルに関連するピッチ及び周期性を識別している情報は、隣接して配置される。第５２図にて示したように、この情報は、また、ヘッダフィールド５９０の交互サブフィールドに配置することもできる。３セットの周期／ピッチ情報を示している図５２の例の場合、タグＩＤ５８５は、サンプルデータフィールド５９５の音響サンプルデータ５５０の前に続くヘッダサブフィールド／パラメータの数を設定する情報を含むことができる。図５２の例において、この方式により、音響サンプルデータ５５０が３つの関連周期／ピッチサブパート（周期情報５８０及びピッチ情報５７５、周期情報５７０及びピッチ情報５６５、及び、周期情報５６０及びピッチ情報５５５として識別される）を有することを、処理の間にシステムに知らせる。

本発明のある好ましい実施例においては、ピッチ及び周期性情報がサンプルファイルのヘッダフィールド部分にある必要はなく、あるいは、別々の記述子ファイル（例えば、多数のサンプルのための一般のサンプルリストファイル又は同じ名称、異なる接尾辞、その他を有する各々のサンプルのための単一の第２のファイル）にあってもよい点に注意すべきである。これの一つの例が図５３に示され、この例では、別々の記述子ファイル６１５が、固有のフォーマットサンプルファイル６１６（例えば、名称、ピッチ、周期及び他の情報）と関連する情報を含む。この方法の効果は、サンプルファイルが固有のフォーマット（例えば、ＭＰ３、ＷＡＶ、その他）のままであるということであり、よって、本願明細書において論じられたように、それらは、ヘッダ部分に加えられる付加的なピッチ及び／又は周期情報をもたない。この種の方法は、本発明の利点をさらに確実にしつつ、クロスプラットフォーム互換性を改良する。

図５４は、サンプルファイルと関連する記述子情報をつくるための方法の典型的な手順フローを例示する。この種の方法は、システムの処理資源が充分であると仮定すると、楽曲生成の間、リアルタイムに実行することができ、あるいは、リアルタイムサンプル特性処理の充分な処理能力を有しないシステム（例えば、携帯用）のためには、図５４に例示される処理を前もって実行するようにすることができる。加えて、計算資源が比較的豊富である個人コンピュータシステムにおいて、図５４に例示されるステップが実行される。この変形例において、サンプル記述子を、実際に楽曲を演奏するポータブルシステムへ転送することができる。従って、図５４に示されている解析特徴は比較的パワフルなコンピュータシステムによって最適に実行されることができるが、この種の分析の利点は、先に参照され取り込まれた特許出願に照らして、ポータブルシステムで実現されることができる。

図５４のフローは、サンプル（ステップ６５０）のアクセス及び／又は書き込みにより開始される。サンプルのメモリ上の位置に応じて、コンピュータシステムは、単純にサンプル（例えば、ＲＡＭから）にアクセスすることができ又は書き込む（例えば、フラッシュ又はマイクロドライブ又はスマートメディア、その他から、ＲＡＭに）ことができる。ステップ６５１は、リズム特性を引き出すためのサンプルの分析を含む。リズムタイミング情報に次のピッチ特性を組み合わせることは有用であり、ステップ６５１はステップ６５２のピッチ分析の前に実行される。しかしながら、別の実施例においては、この順序は変更することができる。すなわち、当業者が理解できるように、本発明の利点を実現するためには、これらステップをこの特定の順序で遂行しなくてもよい。ステップ６５３は、データフォーマットへの生成されたピッチ及び／又はリズム特性の準備（例えば、結合）を含む。ステップ６５４は、ファイル（例えば、先に述べたように、別々の記述子ファイルに又はサンプルデータファイルの例えばヘッダ部分として）に、この種の特性データフォーマットの組み入れ動作を含む。

図５５は、本説明の好ましい実施態様に従うサンプルの再生のための典型的な手順フローを例示する。例えば、この再生手順フローを、作曲又は歌曲の作成／再生の間、与えられたサンプルを演奏している携帯用及び／又はソフトウェアベースの楽曲装置によって使うことができる。詳しくこの開示の他の箇所で議論されるように、本実施例では、楽曲装置がパーソナルコンピュータ上の携帯用ハードウェアシステム又はソフトウェアプラグイン形であってもよいが、現在の楽曲モード及び／又はテンポを探し出す楽曲アルゴリズムを有する必要がある。この情報が楽曲演奏の間に探し出されて、使用される方法の実施例は、本願明細書の他の箇所で詳述するので、本説明のために、この音楽モード／テンポ情報がサンプル再生の間、利用できると指摘するのに十分である。

図５５は、サンプルファイル（ステップ６６０）にアクセス及び／又は書き込みを行ったときに、サンプルファイル（ステップ６６２）のための関連記述子があるかどうかについて決定することを例示する。もし、関連記述子がない場合には、楽曲創作／再生の間、サンプルはそのまま（ステップ６７０及び６７２）演奏される。しかしながら、サンプルファイル記述子情報が、与えられたサンプルファイルと関連していると判定した場合（判定のステップ６６２で「Ｙｅｓ」）、それはアクセスされ（ステップ６６４）、演奏されている楽曲（ステップ６６６）（例えば、本願明細書において図５１に関する説明に関連する）の現在の包括的なピッチ及び／又はリズム情報に関連して（例えば、比較されて）、処理される。現在の包括的なピッチ及び／又はリズム情報との比較又は相対的処理の後、ＤＳＰ機能動作の一組が、サンプルの速度及び／又はピッチをより密接に又は望ましくはそれを包括的ピッチ及び／又はリズム情報に従わせるよう制御するために、準備される（ステップ６６８）。そして、この動作の組は、サンプルが実際に演奏される（ステップ６７０及び６７２）ときに使用され、最小限のユーザ動作によって、その後使われるサンプルのピッチ及び／又はリズムが演奏されている楽曲の形に従っているという結果をもたらす。明らかなように、ステップ６７０において、判定は、サンプルを演奏するために適宜の時間について行われ、そして、ステップ６７２において、包括的情報に基づいて速度及び／又はピッチを制御するためにＤＳＰを伴って、サンプルは実際に演奏される。

したがって、本願明細書において詳述するように、一連のピッチ及びリズムイベントが検出されたサンプルの場合、この種のイベントは、より密接に生成されている楽曲に釣り合わせるために時間調整されるか及び／又はピッチ調整される。これは、例えば、ＤＳＰタイプ動作を実行するＤＳＰインストラクションの実行によって、デジタル信号処理資源又はシステム機能を使用して行われる。明らかなように、連続ではなく、サンプルに単一のピッチ値及び／又はリズムイベントだけを割り当てることによって、本発明は、より単純な方法で適用される。

本願明細書において、先に例えば、図３９〜４２に関連する説明に関連して、音声サンプル及び効果をＭＩＤＩイベントの効果的同期に関して説明し、かつ、この種の同期を達成するためにＭＩＤＩＮＲＰＮメッセージの使用を含めて、該効果的な同期を達成するためのハードウェアについて説明した。本発明の好ましい実施例は、ＭＩＤＩイベント及び音声サンプル及び効果のこの種の同期と結合して使われる。

本発明の好ましい実施例は、携帯用の自動楽曲生成装置を提供する。該装置は、本願明細書に開示されているように実現される。本発明によれば、しかしながら、携帯電話機、個人データアシスタント、その他において使用されるような、先に述べた携帯用の自動楽曲生成装置の実施例アーキテクチャに、無線装置を容易に組み込むことができる点に留意する必要がある。一つの例として、先の開示のＵＳＢ通信インターフェースは、ＲＦ−増幅器ベースのセルラ方式通信モジュールのデータ受信及び／又は放送回路につながっている通信インターフェースで置換することができる。また、本発明の利点を達成しつつ、他のデータインターフェース装置も有効にされ得る。同様に、携帯用機器は、自動車関連のシステム（例えば、ラジオ又は通信システム）の一部、又は在宅音楽システム（例えば、バンド幅の少ない携帯用技術との互換性のために）の一部分であってもよい。全てのこの種の実施実施例は、本発明の範囲内である。

図５６は、好ましい実施態様に従った放送装置を例示しており、該装置の送信機７１０は、大きな放送プログラム（それは、好ましくは楽曲又は他のコンテンツ等の多数のスタイル／カテゴリから成る）の一部として、放送楽曲データファイル７１５を放送する。図５６に示すように、ノード楽曲生成装置７２０は、放送楽曲データファイル７１５を受信して、そこから楽曲を生成し始める。この種の実施例に従って、ノード楽曲生成装置７２０が楽曲データファイル７１５を受信することができ、受信された楽曲データファイル７１５に基づいて、自動的に楽曲の作曲を開始することができ、若しくは、楽曲生成を、ユーザ入力、例えばキー、ボタン又はスイッチの押し下げの後に開始し、あるいは、受信された楽曲データファイル７１５のユーザによる変更後に開始することができる点に留意すべきである。

図５６はまた、ノード著作楽曲データファイル７２５がノード楽曲生成装置７２０から送信機７１０に書き込まれる別の実施例を例示する。ノード著作楽曲データファイル７２５は、例えば、ノード楽曲生成装置７２０によって自動的に作曲された楽曲データである場合もあるが、この種のノードのユーザによって変更されたものであってもよく、又は、この種のノードで先に受信されていた楽曲データファイルであってもよく、この種のノード、その他のユーザによって、その後変更されたものであってもい。図５６の例ではノード著作ファイルが送信機７１０にアップロード送信されることを記述したが、別の実施例によれば、楽曲データファイル７２５は、送信機７１０に関連する他の同様のノードにも送信され、さらに別の実施例では、別のノードに直接送信されることを理解すべきである。例えば、ノード著作楽曲データファイル７２５は、放送楽曲データファイル７１５の放送を管理している放送サービスに関連する受信機に送信される。この「アップロード」機能は、ノードの加入者ユニットが楽曲を著作し、それを放送システムに転送することを可能にし、転送された楽曲を放送に組み込むことができる。明らかなように、この方法は、放送されている実際の音楽へのユーザ参加を可能にして、ノードの間で音楽の共有を可能にする。この方法も、ノード間で直接的に（例えば、送信機７１０からの一般放送を含まなくて）、音楽内容の簡単な共有を可能にする。

図５７は、ノード／加入者ユニットラジオにおけるラジオスタイルの選択を例示する。図示するように、ノード／加入者ユニットは、情報受信／送信のためのアンテナ７５５を含む。好ましくは、この種のノード／加入者ユニットはまた、スピーカ７６０、オーディオ入力７６５、オーディオ出力７７０、ディスプレイ７７５、ユーザインターフェース７８０及びマイク７８５の１又は複数を具備している。図示するように、ディスプレイ７７５は、ユーザにラジオスタイル選択表示を提供するために用いることができる。この種の表示は、ユーザが複数のラジオ局及び／又は楽曲スタイルから適宜選択することを可能にする。好ましくは、ラジオ局及び／又は楽曲スタイルを選んだ後に、ユーザにより選択されたラジオ局／受け取られる楽曲データファイルのスタイルに対応するスタイルで、放送／受信動作（例えば、図５６と関連して本願明細書において記載されているように）が行われる。

図５８は、本発明のノード／加入者ユニットの好ましい実施例に伴う、特定の機能ブロックの実施例を例示する。ノード／加入者ユニット８６０は、アンテナ８００、送信／受信回路８０５、電話／ＰＤＡ装置８１０、通信インターフェース８１５及びディスプレイ８２０を含む。その上、該ユニットは、それ自体が楽曲アルゴリズムブロック８３０を含む楽曲生成器８２５、ＤＳＰブロック８３及びメモリ８４０を含む。この種のノード／加入者ユニットも、オーディオ入力８４０、マイク８４５、オーディオ出力８５０及びスピーカ８５５の１又は複数を備えている。

本明細書のいずれかの箇所で論じられたように、本発明の特徴を使用すれば、着信音が多くの本発明の態様と整合した方法で、アルゴリズム的に創作され、特に電話手段（例えば、携帯電話機）において好適である。ある程度の多様性を着信音に与えることが好ましい実施例（例えば、それにより、電話が鳴る毎の着信音が異なる）において、着信音のテーマで、ある程度の認知可能性を保持することも好ましい。この特徴は、特にアーティストに特有の着信音等と関連して有利である。その結果、電話が鳴るたびに歌曲が認識されるが、しかし、それはまた、各時点で少々異なる。例えば、楽曲レーン（トラック、楽器、その他）のサブセットが利用できない（例えば、ユーザ、アルゴリズム、その他に対して）所で、技術を用いることができる。この例では、レーンのこのサブセットは、歌曲の種々テーマ（スタイル、その他）を含むことができる。この方法では、着信音が演奏されるたびに、他のレーンは変化することができ、そしてそれであっても、テーマは認識できる状態を維持する。これらの特徴の多数は、その他の、着信音に関係しない実施態様（例えば、携帯用音楽プレーヤ、ビデオゲーム装置、ウェブサイトプラグイン、その他）へも、適用することができる。

電話着信音作曲環境のような携帯用環境において好ましい付加的な特徴は、電話の終わりでアルゴリズム的に作曲を実行することである。この例では、更に詳細に上で述べられたように、それが呼び出される（例えば、入って来る電話を経て）たびに、着信音はある程度変化することができる。ある実施例において、認識できるテーマを一定にすることができる方法で、着信音は限られた範囲で変化することができる。これらのさまざまな実施例では、着信音が次に呼び出される前のある時点で、いくつかの自動作曲アルゴリズムを使用して着信音を生成する必要がある。充分な処理資源がある場合には、到来する電話を着信音処理のきっかけとして、リアルタイムでこの自動作曲を実行することが好ましい。しかしながら、例えば、バッテリ寿命等を最大にするために処理資源を最小化する必要がある携帯用環境で、処理資源がより限られる状況下では、携帯用機器が動作の特に忙しい状態（例えば、相当な処理資源を占める電話又は他の若干のモードに参加している）でないようなときに、より理想的な時間に着信音自動作曲処理を始めることが好ましい。一つの実施例においては、電話が終了した（又は、まもなくその後で）時点を、着信音自動作曲処理のきっかけとすることが有利である。着信音は、電話の終了において自動作曲され、次の着信音イベントで演奏される着信音に結果としてなる。この方法では、処理資源の必要量を最小化する手法で、可変着信音の機能が提供される。

本発明の実施例の新しい態様は、特に効果的な楽曲配信及び生成システムの使用法を含む。従来の方法のさまざまなＦＭラジオ放送システム、又はインターネットストリーミングシステムと異なって、本発明は、送信機ではなく、ノードによって生成される楽曲を利用する。ノードは、本質的には、生成される歌曲を定めるデータ又は命令を含み、そして、歌曲を生成するために、ノードのハードウェア／ソフトウェアによって利用されるデータファイル（データ又は命令は、しかしながら、従来技術の放送／ストリーミングシステムに類似している歌曲の若干の副構成要素（サンプルのような）を含むことができる）を受信する。この種の情報、データ又は命令の実施例は、図５９及び図６０に関して後述する。通常、好ましい実施態様によれば、命令は、例えば、テキスト形式又はいくつかの他のフォーマット（すなわち、特に従来のストリーミングオーディオ−タイプ方法と比較して、それが比較的ごくわずかなバンド幅しか消費しない）で送信されるデータを含む。後述する実施例においては、放送楽曲データファイル（ここでは、少しのデータで測定された）の容量は、例えば、３分の歌曲に対して約２００キロビットであるように企図される。

図５９は、放送楽曲データファイルに組み込まれることができる、さまざまな典型的なパラメータを例示する。
「ＡｐｐｌｉｃａｔｉｏｎＲｅｖｉｓｉｏｎ（アプリケーション改訂）」は、データ構造を生成するために用いるファームウェア／アプリケーションバージョンを記憶するために用いる。ファームウェアがアップグレード可能である場合において、これは特に有用である。

「Ｓｔｙｌｅ／Ｓｕｂｓｔｙｌｅ（スタイル／サブスタイル）」は、音楽のスタイル及び／又はサブスタイルを示すために用いる。特定のスタイル及び／又はサブスタイルと関連するルールによって歌曲生成処理が支配されるというシステムに対して警報を出すために、さまざまな変数及びルーチンを初期化するときに、これは有用である。好ましい実施例において、スタイル及び／又はサブスタイルは、「ハードロック」、「環境」、「イージーリスニング」、その他のような楽曲のラジオ局スタイルに当てはめることができる。特定のケースにおいて、例えば後述するように、ラジオ局スタイルは、楽曲データファイルの受信の前に、ユーザが選択可能でもよい。

「ＳｏｕｎｄＢａｎｋ／ＳｙｎｔｈＴｙｐｅ（音響バンク／合成タイプ）」は、歌曲の生成において使われる特定の音響を示す。例えば、これはＭＩＤＩＤＳＰ資源のための音響設定を予め書き込みする方法である。

「ＳａｍｐｌｅＦｒｅｑｕｅｎｃｙ（サンプル周波数）」は、サンプルが歌曲に組み込まれる場合、サンプルがどれくらいの頻度で演奏されるかについて示すために用いることができる設定である。あるいは、これはサンプルがデコードされる率を示すことができる。そして、それは、サンプル再生の周波数を調整することに役立つ技術を提供する。

「ＳａｍｐｌｅＬｉｓｔ（サンプルリスト）」は、データ構造に関連するサンプルの全ての一覧を示す。このリストによって、ユーザは、歌曲再生の間に更に選択して、関連したサンプルを演奏することができる。

「Ｋｅｙ（キー）」は、歌曲に使用される最初のキーを示すために用いる。ピッチオフセットでこれを示すことができる。
「Ｔｅｍｐｏ（テンポ）」は、歌曲の起動テンポを示すために用いる。分あたりの拍子（ＢＰＭ）情報でこれを示すことができる。

「Ｉｎｓｔｒｕｍｅｎｔ（楽器）」は、一群の楽器の中の特定の楽器を識別するデータである。これは、例えば、一群の全てのギター音響の中から、音響ナイロン弦ギターを識別することができる。このデータは、楽器タイプによってインデックスを付けられる。

「Ｓｔａｔｅ（状態）」は、特定の楽器の状態を示すデータである。状態の例は、弱音化、非弱音化、標準、強制演奏、独奏、その他である。
「Ｐａｒａｍｅｔｅｒ（パラメータ）」は、さまざまな楽器パラメータ、例えば音量、パン（ｐａｎ）、音質、その他のための値を示すデータである。

「ＰＲＮＧＳｅｅｄＶａｌｕｅ（ＰＲＮＧシード値）」は、擬似乱数生成（ＰＲＮＧ）ルーティンを初期化するために用いる一連の数値である（この種のＰＲＮＧシード値は、ある幾つかの実施例でのみ使用され、本発明はこの種のＰＲＮＧシード値の使用することに限られていない）。これらの値は、歌曲全体の再現を可能とするために、ＰＲＮＧの本質的に予測可能な性質を利用することによって歌曲を記憶する、特に効率的な方法示す。

「ＳｏｎｇＳｔｒｕｃｔｕｒｅ（歌曲構造）」は、歌曲内パートの数及びシーケンス、並びに、歌曲の楽器タイプの数の一覧を示すデータである。
「Ｓｔｒｕｃｔｕｒｅ（構造）」は、パート内のサブパートの数及びシーケンスを含むパートによってインデックスを付けられたデータである。

「ＦｉｌｔｅｒｅｄＴｒａｃｋ（フィルタリングされたトラック）」は、効果の特性を記述するデータを保持するために用いることができるパラメータである。例えば、それは、矩形波及び特定の初期値を有する効果の変調タイプを示すことができる。効果が特定のパートに関連するので、このパラメータは、パートによってインデックスを付けられることができる。

「Ｐｒｏｇｒｅｓｓｉｏｎ（進行）」は、各々のサブパートのための特性情報である。これは、拍子記号、ＳＥＱの数とシーケンス、マスキングされる楽器タイプのリスト、その他を含む。

「Ｃｈｏｒｄ（コード）」は、サブパートの期間中の楽曲変更に対応するデータ含む。コードベクトル（例えば＋２、−１、その他）、キー音符（例えば、Ｆ）及び進行モード（例えば、ドリアン昇順）データが、タイムスタンプによって記憶される。

「Ｐａｔｔｅｒｎ（パターン）」及びサブパラメータ（「Ｃｏｍｂｉｎａｔｉｏｎ（組合せ）」、「ＦＸＰａｔｔｅｒｎ（ＦＸパターン）」及び「Ｂｒｏｃｋ（ブロック）」）は、全て実際のブロックデータ及び歌曲で使用される楽器の各々に対する効果情報を含む。このデータは、楽器のタイプによってインデックスを付けられる。

例えば、特定の歌曲と関連する音響バンクデータの少なくとも一部が組み込まれるようにするために、他のパラメータが好ましくは含まれる。この例に従って、この種の放送音楽データファイルがアクセスされたときに、楽曲出力の生成の間に音響バンクデータを使うことができるよう、音響バンクデータの少なくとも一部が不揮発性メモリに書き込まれる。

その上、これらのパラメータの多数は、関連タイムスタンプを有するデータを組み込むことができる。このオプションの特徴は、各イベント等のタイミングを示すために用いることができる。

放送歌曲データ構造のこの種の典型的なパラメータの使用で、歌曲が生成されるデータは、能率的に多くのノードの楽曲発生器装置に放送される。特定のパラメータタイプが好ましくは変化するが、この種のパラメータの使用は、必要な全ての詳細がノードにおいてゼロから正確かつ忠実に歌曲を再生させることを可能にする。

図６０は、本発明を実施するために、放送歌曲データファイルと結合して各ノードの楽曲発生装置によって使われる、好ましい一般的アーキテクチャのための論理フローチャートを表す。このフローチャートは、好ましいソフトウェア／ファームウェア実現のための全体像を例示し、歌曲生成処理のためのより詳細な典型的な手順フローを提供する。

図６０のフローの開始時（開始点８６２）に、加入者ユニットによって受信された後、パラメータデータは放送歌曲データ構造から好ましくは書き込まれる（ステップ８６４）。若干のパラメータ値が決定されて／書き込まれると、所与の歌曲パートのための楽曲が生成され始める（ブロック８６６）。そして、ユーザインターフェース（例えば表示、ビデオ出力、圧力フィードバック、その他）は、それに応じて更新される（ブロック８６８）。この過程の任意の位置で、楽器又は効果の変更のようなユーザ入力が検出される（「保存する」以外の命令）（決定ブロック８７２）場合、ユーザによって現在変更されている歌曲のパートのための関連したパラメータデータが更新され（ブロック８７６）、そして、与えられたパートのための楽曲の生成が続く。ユーザ入力「保存」命令が検出される（決定ブロック８７４）場合、全てのパラメータデータは非一時的記憶場所（例えばフラッシュメモリ、ハードディスク又はある程度の永続性をもつ余裕がある他の書き換え可能なメモリ記憶場所）に、保存される（ブロック８７０）。ユーザがその全体を保存することを決める前に歌曲の大部分を聞くことができるので、この方式は望ましい。ユーザ入力がない限り、歌曲パートの終端が検出される（決定ブロック８７８）まで、与えられた歌曲パートのための楽曲の生成が継続される。終端が検出されると、フローは、次の歌曲パート（ブロック８８４）へ進む。この時、必要に応じて、次の歌曲パートのための関連したパラメータデータが決定されて／書き込まれる。結局、歌曲の終端条件（決定ブロック８８０））が検出されると、その歌曲は終了する（ブロック８８２）。

図６１は、本発明の実施例に適用し得る典型的な通信産業協会（ＴＩＡ）規格を記載する。広範囲なメッセージ及び／又は他のデータサービスオプションが現在のセルラ産業において利用可能であるので、本願明細書において記載されている楽曲配信のコンセプトは、種々の異なる手段を使用して実現可能である。本開示に従って楽曲データファイルを配信するために用いることができる、いくつかの有効なアーキテクチャがある。例えば、時分割多重アクセス（ＴＤＭＡ）、移動通信用グローバルシステム（ＧＳＭ）及びコード分割多重アクセス（ＣＤＭＡ）である。図６１は、セルラ分野でのデータ配信の好ましい実現に関する詳細を含むある規格を参照するものであり、したがって、これらの全体にわたって本明細書に取り込まれたものとする。明らかに、これは、網羅的なリストではなく、むしろ、単に関連する公表規格のいくつかの実例を挙げたものである。

図６２は、ＴＩＡ／ＥＩＡＩＳ−６３７の「ＳｈｏｒｔｍｅｓｓａｇｅＳｅｒｖｉｃｅｆｏｒＷｉｄｅｂａｎｄＳｐｒｅａｄＳｐｅｃｔｒｕｍＣｅｌｌｕｌａｒＳｙｓｔｅｍ」である典型的な規格からのある例を示している。図６２に示したように、オプションのベアラー（Ｂｅａｒｅｅｒ）データを可能にするＳＭＳ放送メッセージが定められる。この例に従って、ベアラーデータは、可変長（例えば、ＳＵＢＰＡＲＡＭ＿ＬＥＮとの関係にて説明したように）のサブパラメータデータを含むことができる。ＳＭＳ放送メッセージのこの実施例は、本発明の態様（例えば、図５６にて示したように、放送楽曲データファイルＦｉｌｅ７１５を送信する手段）を実施するために用いてもよい。その上、図５６において例示されるノード著作楽曲データファイル７２５に関連して使われるＩＳ−６３７規格において定められるメッセージと同じような他の定義済みメッセージがある。一つの例として、「ＤａｔａＢｕｒｓｔＭｅｓｓａｇｅ」がＴＩＡ／ＥＩＡＩＳ−９５−Ａに記載されているのを参照されたい。明らかに、本発明の利点について目的を達成するために、他の規格も場合によっては採用可能である。同様に、上述した電気通信規格において特定されるデータ処理の他のタイプを、本発明の趣旨及び範囲から逸脱することなく、本願明細書において言及される特定の実施例に置き換えることができる。

更に、また別の実施例においては、図５７を参照して、本発明の多くの利点を、クロック又はクロックラジオ装置に組み込むことができる。図５７に示すように、クロックラジオは、クロックラジオユーザのためのグラフィックインターフェースを示すことができるディスプレイ（例えば、ディスプレイ７７５）を備えている。一つの実施例において、ディスプレイは、警報設定と同様に、時間を示すためにも用いられる。ユーザ入力インターフェース７８０は、クロックラジオユーザに、時間及び／又はアラーム情報を入力するための手段を与えるために用いることができる。ある実施例において、スピーカ７６０は、所望の時間にクロックブザーを鳴らす。ユーザに完全に新しい音楽作品で毎朝を目覚めさせることができるアラームクロックにおいて、本願明細書において論じられる好ましい具体化の多くの態様を使うことができる。ある実施例において、楽曲のスタイルは、ユーザ（例えば、ユーザ入力インターフェース７８０及びディスプレイ７７５を介して）によって選ばれる。

ある実施例において、楽曲出力の特性を、アラーム動作の間に、調整することができる。例えば、楽曲のスタイルは、静かなリラックスした環境から、楽曲のよりエネルギッシュで騒々しいスタイルまで、次第に変化してもよい。好ましくは、ユーザがスヌーズボタン（例えば、ユーザ入力インターフェース７８０を介して）を押すたびに、又は所定の間隔で（それは、更なるユーザ動作なしでもよい）、この進行は起こる。このように、アラームクロックは、最初にリラックスした静かな及び／又は単純な一曲でユーザを起こすことができ、ユーザが長くベッドにいようとすると（例えば、単にアラームを消さずにベッドに残ることによって又はあるいは、スヌーズボタンを押し続けることによって）、次第により活発になる。

あるアラームクロック実施例において、同様に、スムースコード進行からより不協和のものまで、次第に音楽を調整することが好ましい。例として、図１９を参照すると、アラームクロック楽曲がメジャーコードから始まり、アラームがより長く鳴り続けるのに伴って、より不協和に（例えばマイナーコード）なる。あるアラームクロック実施例において、音符ピッチの相対的に低い可動性を有する楽曲から始めて（図２３を参照）、ユーザがベッドになおとどまる時間が長くなれば、次第に音符ピッチの相対的可動性を増やすことが好ましい。他の例では、リズム密度は、比較的低周期的密度（例えば、図２２参照）から、比較的高周期的密度まで推移する。これらの実施例は、ユーザを和らげる音楽作品で起こし、そして、ユーザがベッドにとどまる時間が長くなれば、次第によりエネルギッシュで複雑及び／又は不協和になる。

更に、また別の実施例においては、図５７を参照し、ユーザインターフェース７８０（例えば、ある数字を覆っている文字をもつ、典型的な携帯電話機テンキー）の使用は、ユーザが自動楽曲生成システムに名前（例えば、彼（女）の名前又は愛されるもの又は他のいくつかの語）を入力することを可能にする。典型的な別の実施例において、入力された名前が厳密なやり方で自動作曲処理にイニシャル署名するために使用される。それによって、キー入力によって決定された唯一の歌曲が、その名前のキー入力に基づいて自動的に作曲される。本願明細書において開示された実施例に従えば、例えば、名前の文字が、最初のシードを生成するアルゴリズム、楽曲データ又は疑似乱数発生処理（ＰＲＮＧ）等へのエントリ、その他において使われる。それによって、自動作曲処理を始める最初のデータは、名前のエントリに基づいて決定される。一例として、入力された文字各々のＡＳＣＩＩ表現を加えて、おそらく若干の数学を数に適用し、そして、その結果生じる値を、ＰＲＮＧ処理等へのエントリとして使用する。この例を続けると、典型的テンキー（例えば、文字「ａｂｃ」は数「２」、３に対する「ｄｅｆ」、その他と一致する）に使われるように、各々の文字が数値を有することができ、そして、その数はＰＲＮＧ処理に適切な入力に結果となるために数学的に処理される。この、後者の実施例は、ここで開示された実施例のあるものがキーパッドインターフェースがサポートされる携帯電話機機、又は類似した携帯用製品（例えばＰＤＡ又はページャ）に組み込まれる場合、特に有利である。

処理が厳密であるので、少なくとも同じリリース又は楽曲生成システムのバージョンのために、名前の全てのエントリにより、特定の人のための同じ唯一のすなわち「署名」歌曲を生成する。別の実施例の自動作曲処理は、部分的に、名前の文字の入力の時間又はタイミングに基づくものである。したがって、名前入力プロセス（この種の人間の相互作用ランダム状態は参照され、組み込まれた特許文献において述べられている）及び個々の名前入力のための本質的に固有の歌曲生成に、ユーザ時間−ランダム状態を差し挟むものであるが、好ましい別の実施例では、複数の数のユーザが、それら名前又はそれらにとって重要な他のいくつかの語に基づく「それらの歌曲」として特定の曲をもつことを好むと思われるので（何らかの形でそのユーザの名前と関係していてもよい多数の曲を提供するため、テンキーインターフェースと関連して本願明細書において記述されるように、一連の文字に対応する数を使用するために、ユーザは、例えば、逆向きに、数字を使って上下逆さまに、大文字でない、ニックネーム、その他のように、異なる形式で彼／彼女の名前／語を入れることができる）、好ましい別の実施例では、厳密な、非ランダムな方法が使用される。当業者が理解できるように、このコンセプトも自動作曲される楽曲スタイル選択に適用できる（参照され、取り込まれた特許文献にて説明したように、スタイルは、ユーザ入力に基づくランダムな選択処理の一部であり、又は、スタイルは選ばれる）。例えば、特定の画曲生成システムによってサポートされる楽曲のスタイル又はサブスタイル毎に、各々のスタイル又はサブスタイルのための唯一の曲は、ユーザの名前（又は他の語）の入力に基づいて、あるいは、厳密には、例えば、ユーザがスタイル、その他を選択するようにして、文字のユーザ入力などのタイミング又は他のランダム性に基づいて、創作することができる。

明らかなように、ノード／加入者ユニットの楽曲生成デバイス７２０での自動作曲処理を開始するための名前入力が名前に限定されないというコンセプトは、他の英数字、グラフィック、他のデータ入力（生年月日、語、ランダム入力された文字、その他）まで広げることができる。タッチスクリーンを使用している実施例に関して、例えば、他の入力（例えば、引出し線、図、ランダムな線、グラフ、点、その他）は、厳密に又はユーザ入力等のタイミングに基づいて、自動作曲処理を始めるために用いることができる。重要であることは、英数字特性のキーボード入力のようなユーザ入力、又はタッチスクリーンを介した図面線のような他のデータ入力エントリ（すなわち、例えば、本来は一般に音楽的でないデータ入力）は、独自にデータ入力イベントに関連する楽曲の作曲を始めるために用いることができる。このように、唯一の楽曲作品は、非音楽的データ入力に基づて創作できるので、音楽に堪能でない人でも、非音楽的データ入力に基づいて唯一の楽曲を創作することができる。この種の非音楽的データ入力に基づいて、楽曲生成処理は、シード又は他の楽曲生成の開始データを選んで、自動作曲処理を開始する。明らかなように、特に英数字データ入力に関して、この種の文字も記憶され（単独か、又はデータ入力と関連する楽曲生成開始データを伴って）、他の楽曲生成システム（送信機７１０を介して）に送信される。それによって、非音楽的データの伝送は、実際には、楽曲生成システムによって創作される曲を決定する情報を送信するための少ないバイト数のデータだけの送信で、唯一の曲を他のユーザ／システムに発信するために用いることができる。

その上、多くの本発明の態様は、ファームウェアのアップグレードの新しい概念を可能にするために役立つ。本発明の態様を用いて、ファームウェア更新をーザが利用でき、組み込み広告を完備したようにされることができる。そして、それは、ファームウェア製造者／販売者に、ユーザ以外の収入源を提供する。このコンセプトは、組み込み広告映像（及び／又は音響）を含むファームウェア（又は、音響バンクデータのような他のソフトウェアベースのプログラム）のアップグレードの配信を含む。この種の映像／音響は、音楽製品の動作中に一時的に現れることができ、自由にダウンロードするユーザのためのカスタマイズされたファームウェアの開発に資金を供給することができる。

音声合成の間の補間寄せ集めと関連する好ましい本実施例を、図６３〜図６８と関連して説明する。
音声合成を実行するための典型的な合成構造が、図６３に例示される。オーディオイベント９０１（例えば、ＮＯＴＥＯＮ命令のようなＭＩＤＩイベント）が音声合成９００アルゴリズムに入力される。これは、オーディオイベントに関連する１又は複数のパラメータ（例えば、波形ファイル及びパラメータデータの好ましくは組合せのような、ＭＩＤＩ製造者協会によって発行されるダウンロード可能な音響仕様（ＤＬＳ）と互換性を持つ）によって、実行される。パラメータデータ９０２が、オーディオイベント９０１入力に対応する１又は複数のサンプル９０３を出力する音声合成９００アルゴリズムによって使われる。音声合成９００によって遂行される処理作業の主要部（例えば、約８０％）は、小さい処理ループにおいて実行される。この小さい処理ループは、パラメータ９０２からのソースサンプルデータを含むデータをとって、サンプル９０３としての出力である新規なサンプルを生成する。ソースサンプルデータからの新しいサンプルデータを生成するこの過程は、図６４に例示される３つの動作を含むことができる。

図６４は、上で議論された小さい処理ループによって実行される合成手順フローを例示する。第１の動作は（Ｉ）補間ブロックであって、異なる速度でパラメータ９０２(例えば、ＤＬＳデータ)からソースサンプルデータを読み込む（例えば、楽曲ピッチＧをもつソースサンプルから、Ａの楽曲のピッチを有するサンプルを得る）ステップである。ある実施例において、第１の動作（Ｉ）はまた、次の動作において使用する波形データをつくるために、例えば、ＤＬＳパラメータをもって、アルゴリズム機能を適用することを含む。この種の実施例において、別の処理ループ（例えば、他の動作より処理頻度が少ないループ）を使用して、このアルゴリズム機能を適用することは有効である。第２の動作（ＩＩ）は、フィルタリングブロックであり、生成されたサンプルをフィルタリング（例えば、共振を有する低域フィルタで）するステップである。ステップ（Ｉ）及び（ＩＩ）では、モノラル信号を含む。第３の動作（ＩＩＩ）は、利得調整（ゲイン）ブロックであり、サンプルの振幅を適宜の大きさに増幅するステップである。このステップにおいて、ある実施例では、モノラル信号ができる限り異なるゲイン値を有する２つの信号に分割される（例えば、信号のステレオ配置効果を与えるため）。

図６５は、上で述べられた小さい処理ループを実行する音声合成９００の主部分の構造を表す。図示されるように、ソースサンプルデータ９１０（例えば、パラメータ９０２からの）は、（Ｉ）補間ブロックに入力され、そこで、ピッチパラメータ９１２（例えば、パラメータ９０２からの）で処理され、（ＩＩ）フィルタリングブロックに供給され、そこでフィルタパラメータ９１４（例えば、パラメータ９０２からの）でフィルタリングされ、（ＩＩＩ）利得調整ブロックに供給され、そこで利得（ゲイン）パラメータ９１６（例えば、パラメータ９０２からの）で処理される。この点で、ある実施例で、サンプルは、ステレオフィールドをつくるために（ＩＩＩ）利得調整処理を経て、ステレオ出力信号の右（Ｒ９１８）及び左（Ｌ９２０）チャネルに対応する二つの信号に複製される。モノラル出力が要求される状況では、Ｒ９１８及びＬ９２０への分離は必要でない（例えば単旋律の移動電話）。さらに、２つ以上の出力チャンネルが要求される状況（例えば、いくつかのスピーカを使用し、それぞれが音響の離散的なチャネルを分配する「５．１のマルチチャネルサラウンドサウンド」）では、利得調整ブロックにより、入力サンプルを複数のチャネル（例えば正面の左、中心、正面の右、左後方、右後方及びサブウーハ）に分割するために、利得パラメータ９１６が使用される。これは、２チャネルに対して図６５に示したものと同様なやり方で実行される。

図６５において表される構造によって反復実行される小さい処理ループは、音声合成９００によって実行される処理の主要部を含むので、これが、大部分の信号処理資源が音声合成動作において消費される領域である。したがって、処理資源が比較的乏しい携帯電話、ＰＤＡ、携帯用ビデオゲーム、携帯用アラームクロック、その他のような場合には、この小さい処理ループの効率は、この種の携帯用システムによって達成可能な音声合成の品質に大きな影響を及ぼす。

図６６は、ソースサンプルデータ９１０の処理に関連する算出タイミングの従来技術の方法を例示する。図示のように、与えられたパラメータ（例えば、利得）毎に、新規な値が比較的しばしば算出される。例えば、４４．１ｋＨｚのオーディオ信号の場合、新規な利得値は、ミリ秒当たり４４回算出される（例えば、波形セクション９４０中で４４回）。図６７は、新規なパラメータ値がより少ない回数算出される（例えば、４４ｋＨｚの場合、ミリ秒当たり１回、すなわち波形セクション９４２の中で１回）という顕著な差をもって、同一波形を示し、そして、時間内の位置で新規なサンプルが算出されない（例えば、前の実施例では、１波形セクション９４２の中にミリ秒当たりの残りの４３回）点で、ルーチンは、デルタ値（例えば推定された差値）に応じて、以前の算出値を出力する。この方式では、図６６において表される従来の技術方法ほど頻繁には新規なパラメーター値を算出しないので、上で述べた小さい処理ループはより効率的である。図６８は、同一の波形を用いた、別の波形計算タイミングを示しており、新規なパラメータ値がめったに算出されない（例えば、４４ｋＨｚの場合で、波形セクション９４４及び９４６によって表されるように、５ミリ秒当たり１回）という大きな差を有し、そして、新規なパラメーター値は、図６６及び図６７での値（例えば、前記実施例に従えば、隔ミリ秒ごとに１回、又は波形セクション９４４及び９４６のそれぞれの中で４回）の場合より低頻度で、デルタ値に応じて出力される。

比較のための例示として、与えられたチャネルに対して、図６６に表される従来技術の方法は、１ミリ秒につき４４回、新規なパラメーター値を算出し、図６７に表される方法は、１ミリ秒につき１回新規なパラメーター値を算出し、そしてミリ秒につき４３回を残してデルタ値を新規なパラメータ値に加える。そして、図６８に表される方法は、１ミリ秒につき１回より少なく（例えば、５ミリ秒ごとに１回）、新規なパラメータ値を算出し、新規なデルタ値（例えば、図６７の方法に関連するデルタを使用して、それに４４を掛けることによって選られる）が、１ミリ秒につき一度加算される。図６６〜図６８に例示される各々の方法を使用している４４ｋＨｚの音声の一つのチャネルを処理するために典型的に必要なＭＩＰＳの数は、それぞれ、１０、２．５、１．５である。

図６７に表される方法に対して、図６８において表される方法による付加の利点は、固定小数点プロセッサを組み込んでいるアーキテクチャにおいて、実現され得るということである。図６７と関連する合成算出は、デルタ値が前のサンプル値に毎ミリ秒４４回（例えば、４４．１ｋＨｚの音声の場合）、加算されることを必要とするので、浮動小数点精度を有しないアーキテクチャでは、これらの算出は不所望な精度となり（例えば、不良なオーディオ出力）、また、処理実行のために不所望のＭＩＰＳ数を必要とすることになる。図６８に例示される方法は、図６７に例示されるデルタ値の集合を含み、そして、ただひとつの数（例えば、図６６の場合のデルタ値の４４倍という比較的大きい値）がサンプル値に加えられ、その結果、固定小数点プロセッサの観点で改良された正確で低いＭＩＰＳをもたらす。

ある実施例において、付加的な効率を提供するために、別個に又は上記と結合して、図６４及び図６５に表される（ＩＩＩ）利得処理の動作の更なる最適化を使うことができる。ステレオ出力（モノラルに対して）の例において、通常、チャネル毎に、（ＩＩＩ）利得処理ブロックが処理され、以下の３つの式が、１ミリ秒につき４４回（４４．１ｋＨｚの音声の場合）実行される。

（１）入力信号＊利得＝増幅された信号
（２）増幅された信号＊左修飾子＝左チャンネル出力
（３）増幅された信号＊右修飾子＝右チャンネル出力
想像されることができるにように、この処理は、特に多数の同時オーディオイベント９０１が処理されるときに、かなりの資源を占める（第６３図及び付随する上記説明を参照）。ある好ましい実施例においては、式の代替集計された一組を使用することが有利であり、そして、このようにして、効率的なステレオ符号化方処理を遂行することが有利である。該代替の組は、２つの方程式の２セットから成る（合計４）。２つの方程式の第１の組は、次の通りである：
（４）左の修飾子＊利得＝増幅された左チャネル修飾子
（５）右の修飾子＊利得＝増幅された右チャネル修飾子
式（４）及び（５）は、５ミリ秒毎に１回（例えば、４４．１ｋＨｚの場合）のように、比較的まれにしか実行されない。１ミリ秒につき４４回のように、２つの方程式の以下の第２の組は、より頻繁に実行される。
（６）入力信号＊増幅された左チャネル修飾子＝左チャネル出力
（７）入力信号＊増幅された右チャネル修飾子＝右チャネル出力

典型的な例（式（１）〜式（３）に関連して上述）と、好ましい実施例（式（４）〜（７）に関連して上述）とを比較すると、要求されるＭＩＰＳでの相当な減少が達成されることは明らかである（例えば、ある場合で約６％）。この減少は、主に、大部分のサイクル（例えば、上の実施例では、５ミリ秒の期間の２２０サイクルのうちのほぼ２１９）において、２つの式だけが３の式の代わりに実行されるからである。

したがって、図６７及び図６８と関連する各々の２つの好ましい実施態様は、図６３〜図６５に関連して上記した小さい処理ループのための必要資源をかなり減少させることができ、このように、特に携帯用システム（例えば、携帯電話機、ＰＤＡ、携帯用ビデオゲーム、携帯用キーボード、その他）での使用に有利である。しかしながら、これらの実施例がポータブルシステムと関連して述べられるが、この種の実施例は、他の非携帯用システム（例えばパーソナルコンピュータ、ステレオシステム、電子音楽製品、など）の使用のためにも望ましい。この技術の使用が処理資源を減少させ、ある場合には汎用プロセッサが合成を効果的に実行できるようにすることによって、特別で高価なハードウェア合成回路の必要性をなくすことができ、音声合成を行ういかなるシステムも、このような効率的な音声合成処理を使用することにより、利益を受けることができる。

減少するメモリ領域又は占有スペースを有するＭＩＤＩ音声バンクに伴う好ましい本実施例を、図６９〜図７６に関連して説明する。
携帯用環境のような状況において、ＭＩＤＩ音響バンクが比較的少ないメモリ占有面積であることは望ましい。以下の説明において、ローランド社によって開発されて「ＧＭ」と呼ばれ、現在、ＭｉｃｒｏｓｏｆｔＷｉｎｄｏｗｓの標準の部品として含まれる従来技術の音声バンクは、ほぼ３，３６１ＫＢのメモリ占有スペースを有する。この種の大きい容量は、ある状況において十分に動くことができるが、デスクトップパーソナルコンピュータと比べて減少された資源（たとえば、処理、電池寿命、メモリ、その他）が利用可能な携帯用ＭＩＤＩ装置（例えば、移動電話、携帯用ビデオゲーム、携帯用キーボード、ＰＤＡ、その他）にとっては、大き過ぎる。以下に記述する技術は、したがって、必要資源のかなり減少するレベルで、一緒又は別個に、高質ＭＩＤＩ音声バンク解決策を提供するものである。もちろん、ある状況では、更に詳細に以下に述べられる種々の理由で、非携帯用環境においても１又は複数のこれら技術を使用することが好ましい。

その上、以下の説明は、上記したように（ＤＬＳ）互換の音響バンクのようなＭＩＤＩ互換の音響バンクの一部を含む波形の例を参照する。ＭＭＡから入手可能なＤＬＳ仕様資料に説明されているように、ＤＬＳ互換の音響なバンクは、波形データと関連するパラメータデータを含む。波形データは識別される「ループ期間」を有する。そして、それは、ＭＩＤＩ音符の継続期間をサポートするために、必要に応じて再生の間、連続的にループする波形の部分を示す。通常、従来の音響バンクは、各々の楽器のための波形を含む。そして、その波形は、通常ループ期間と確認される端の方へ向かうセクションを有する。

図６９は、トムドラムのために使用する従来技術の音響を例示する。図示するように、波形は比較的大きく、ほぼ６４６７のサンプルの長さをもつ。そして、ループ期間は、波形の後半にあって波形の後部２５％を占める。波形から理解できるように、ほぼ２５％の始端部は比較的無秩序である。この最初の過渡期間は、トムヘッド上のドラムスティックの影響による音響を伴う。この最初の過渡期間の後、波形はより安定することが判る。図６９に示したように、波形の比較的安定部分からループ期間を選ぶことは、ＭＩＤＩ音響バンクの典型的特徴である。残念なことに、これは、比較的大きい波形サイズ（例えば、図６９の場合では、６０００以上のサンプル）の副作用である。図７０は、音響を作るために２枚のＤＬＳレイヤを使用した、本発明のトム音響を例示する。図７０に示するように、このトム音響は、２つの波形でできており、共同してかなり少ないスペース（例えば、図６９に表される従来の技術波形の６４６７のサンプルと比較すると、合計９０４のサンプル）をとる。示されるように、レイヤ２の波形は、トムヘッドを打っているドラムスティックの最初の打ち鳴らし音響である。このレイヤは、ループ期間を有しない。レイヤ１の波形は、識別されたループ期間を有する比較的安定な波形である。これらの２つの波形は、同じ位置で鳴り始め、レイヤ１の波形は、ＭＩＤＩ音符持続期間をサポートするため必要とされるように、ループする（この音響と関連するＤＬＳパラメータデータと整合した方法で）。さらに、ある実施例において、レイヤ１の波形が、ベースギター音響のような、音響バンクのどこかで使用されるピッチが整えられた音響であってもよい。図７０に表される方法の一つの効果は、この音響が大きさ（サイズ）において、従来の技術よりかなり小さいということである。この方法の他の効果は、ある実施例では、ループ期間がピッチ調整された楽器（例えば、ベースギター）の波形と関係しているので、種々のピッチ全体にわたって、より良い音響が得られるということである。従来技術の場合、種々のピッチを使用して良い結果を得るために、所与のドラムキットのトム音響のために、多様な波形の使用が必要となる場合がある。本発明の方法の付加的な効果は、レイヤ１のために使用するベースギター音響のように多様な音響のためのソース波形を使用する可能性があるため、減少した波形カウントが全体に渡って存在する、ということである。本方法のさらにもう一つの効果は、異なるサンプリング周波数が各々のレイヤのために使われるということである（例えば、知覚される音響品質へ比較的小さな悪影響を及ぼすもののサイズ低減を可能にし、レイヤ２上の「アタック」波形は低減されたサンプリング周波数を有する）。現在の方法の一つの不利な点は、それが同じ楽器音響のために同時に処理されている２つの波形を含むので、多音が減少するということである。この分野の当業者に明らかであるように、トム音響の実施例は、説明を容易にするためであり、図７０の本実施例の多くの教示は、本発明に沿うやり方で他の楽器においても適用される。加えて、ある実施例において、組合せ波形（複合波形）とするために多数の波形（例えば、図７０に示す）を前処理することが好ましい。この前処理のステップは、複合波形が「演奏される」とき、それは一つの声音を占有するだけであるので、多音を増やす利点を有する。この種の前処理は、例えば、利用できる処理資源等に応じて、再生の前又は再生中に行う。

図７１は、フルートのために使用する従来技術の音響を表す。図示するように、波形は比較的大きく、約２０２９のサンプルの長さで、ループ期間は波形の最後５％を占める後方部分にある。波形から明らかなように、初期部分は比較的無秩序である。この最初の過渡期間は、フルートの最初の呼吸音響特性に関連する。この最初の過渡期間の後、波形はより安定するようになる。また、図７１に示したように、波形の比較的安定部分からループ期間を選ぶことは、ＭＩＤＩ音響バンクの典型的特徴である。残念なことに、これは比較的大きな波形サイズとなる（例えば、図７１の場合、２０００以上のサンプル）。図７２は、本発明におけるフルート音響を例示する。図７２に示すように、本発明においては、フルートは、かなり少ないスペース（例えば、図７１に表される従来技術の波形の２０２９のサンプルと比較すると、合計５９１のサンプル）をとる。図示されるように、一部の波形が最初の遷移期間とループ期間の間から取り除かれ、これにより、比較的安定なループ期間を依然として残しながら、比較的短いサンプルサイズとなる。図７２において表される方法の主要な効果は、この音響のサイズが従来技術よりかなり小さいということである。本方法の一つの不利な点は、波形が変わるので、音質の低下を伴うということである。しかしながら、このカット／ペースト技術が慎重になされる場合には、結果として生じる音質低下を、より小さいサイズと比較しても大差ないようにすることができる。これは、安定ループ期間のためであり、この楽器音響が使用される大半の時間、鳴らされる。この分野の当業者に明らかであるように、フルート音響の例は、説明を容易にするためであって、図７２の本実施例の多くの教示は、本発明に従うやり方で他の楽器にも適用され得る。

図７３は、ピアノのために使用する従来技術の音響を表す。図示するように、波形は比較的大きく約７５８８のサンプル長を有し、そして、ループ期間は波形の後ろ約２０％を占める後方部分にある。波形から理解できるように、始端部は比較的無秩序である。この最初の過渡期間は、ピアノ弦へのハンマーの衝撃と関係している。この最初の過渡期間の後、波形はより安定するようになる。また、図７３にて示したように、波形の比較的安定部分からループ期間を選ぶことは、ＭＩＤＩ音響バンクの典型的特徴である。残念なことに、これは比較的大きな波形サイズ（例えば、図７３の場合では７５００以上のサンプル）となってしまう。図７４は、本発明におけるピアノ音響を例示する。図７４に示されるように、このピアノ波形は、かなりの少ないスペース（例えば、図７３に表される従来技術の波形の７５８８のサンプルと比較すると、合計５４のサンプル）をとる。図示されるように、そのサイズは、ループ期間としての用途のために、最初の遷移期間を識別することによって、大幅に減少した。ピアノ音響の音波特性により、最初の遷移期間は好ましくは比較的安定なループ期間を提供することができ、その結果、比較的短いサンプルサイズとすることができる。図７４に表される方法の主要な効果は、この音響のサイズが従来技術よりかなり小さいということである。本方法の一つの不利な点は、ループ期間が最初の過渡期間から選定されているので、音質の低下を伴うということである。しかしながら、ループ期間が慎重に選ばれる場合、結果として生じる音質低下は、より小さいサイズの場合と比較して、さほどではないようにすることができる。この方法の他の不利な点は、それがシンバル音響のように非常に特徴的な遷移期間を含む楽器音響には、通常、適していないということである。この分野の当業者に明らかであるように、ピアノ音響の例は、説明を容易にするためであって、図７４の本実施例の多くの教示は、本発明に従うやり方で他の楽器にも適用することが可能である。

第７５図は、サクソフォン及びオーボエのために使用する従来技術の音響を表す。
図示するように、波形は比較的大きくて、それぞれ１２００のサンプル長である。そして、ループ期間は、非常に小さい後方部分である。これらの波形の並置から理解できるように、これらの２つの楽器が音を出す方法の熟知と同様に、ループ期間は比較的類似している。図７６に、本発明のサクソフォンとオーボエの音響を例示する。図７６に示すように、従来技術よりかなり少ないスペースをとることに加えて、このオーボエ音響は、サクソフォン音響（例えば、「ｓａｘｆ＃４ａ」）と同じ波形の使用を生じさせる。図示されるように、これらの２つの音響間の主要な差は、ループ期間の終端点の位置である。ループ期間を変えることによって、それらが両方とも同一波形を使用するにもかかわらず、オーボエの音響を聴覚的にサクソフォンと異ならせることができる。先に述べた技術でそうであるように、この技術はまた、楽器音響の個性をより際立たせるため、そして、好ましくは結果として生じる音響をよりしっくりと実際の楽器のように仕上げるために、変更されたパラメータ（例えば、フィルタ、エンベロープ、及び／又はＬＦＯ効果のパラメータ）の使用を含むことができる。図７６に表される方法の主要な効果は、多様な音響のためのソース波形を使用する可能性のゆえに、減少した波形カウントが全体に渡ってあるということである。本方法の一つの不利な点は、付加パラメータを更に音質を改良するために用いる状況で、音響バンクがより複雑になる可能性がある点である。但し、付随する全体的なサイズ減少は、この懸念を上回る。この分野の当業者に明らかであるように、サクソフォン及びオーボエ音響の例は説明を容易にするためのものであって、図７６の例の多くの教示は、本発明に従うやり方で他の楽器にも適用され得る。

前述の教示に加えて、ある好ましい実施例においては、比較的大きな音響バンクの使用し、さらに、一曲ごとに所与の使用のために必要な音響の選択だけを行うことが好ましい。この方法では、特定の使用（例えば、演奏されている特定の歌曲のような）のために必要とされる音響だけは、ＲＡＭに書き込まれる必要がある。この方法の一つの効果は、より大きい音響バンクによって産出されるより良好な音質を、ある場合にはメモリの最も決定的な部分（例えば、移動電話の場合のように）であるＲＡＭスペースをさほど大きく占有することなく、使用できるということである。音響バンクを記憶するために１２８ＫＢのＲＯＭ又はフラッシュメモリが利用でき、シンセサイザ（合成器）が動作しているときに音響バンクに記憶するために３２ＫＢのＲＡＭが利用できる実施例についてみると、本技術の効果は、一つのＭＩＤＩ歌曲が３２ＫＢ以上のデータ（例えば、ソースサンプル及びパラメータ）を使用しないならば、音響バンクが最高１２８ＫＢまで増量できるということである。この技術の潜在的に不利な点は、任意のひとつのＭＩＤＩ歌曲が３２ＫＢ以上の音響バンクデータを使用しないことを保証しなければならないということである。この潜在的課題に対処する追加の技術は後述する。利用可能な音響バンクの下位部分の一曲毎の使用は、本明細書において記述される典型的なサイズに限られるものでないが、しかしながら、より多くの又はより少ない資源が音響バンクデータに利用できる他の状況においてむしろ好ましい。この技術は、所与のアプリケーション（例えば、歌曲が演奏されること）のためのメモリサイズの占有スペースへの影響を減少させながら、この技術は高品質な音響バンクを提供する。

前述の教示に加えて、付加的な技術を、全てのＭＩＤＩ歌曲が有効音響バンク（例えば、１２８ＫＢ）の所定のサブセット（例えば、３２ＫＢ）以上を使用しないことを保証するために用いてもよい。音響が異なる品質及び／又はサイズであり、そして、所定のサブセットサイズが超過する危険がある状況では、より高品質及び／又はより大容量のコンピュータ音響に代えて、より低品質及び／又はより小容量の音響が選択的に用いられる本技術は、利用可能な音響バンクの複数の音響を、所与の楽器と結びつけることを含む。この方法では、与えられた歌曲が、その歌曲に使用された全ての楽器のために高品質及び／又はより大きいサイズの音響を使用することができる場合には、予め定められたメモリサイズ（例えば、３２ＫＢのＲＡＭ）の範囲内にとどまりながら、それから、歌曲は高質及び／又はより大きい容量の音響を使用して演奏される。しかしながら、所与のＭＩＤＩ歌曲がそれらの最高品質及び／又は最大容量のバージョンの有効容量（例えば、３２ＫＢのＲＡＭ）より集合的に大きくなる楽器音響を必要とする状況では、本発明は、所定のメモリ容量（例えば、３２ＫＢＲＡＭ）の範囲内にとどまるために、どの楽器がそれらのより低い品質おび／又はより小さい容量の音響で鳴らされるのかを決定するために実行されるアルゴリズム判定を必要とする。アルゴリズム判定は、ランダム状態、楽器の重要性、表、その他に基づいて行われ、そして、ある場合には、ＭＭＡによって発行されるＳｃａｌａｂｌｅＰｏｌｙｐｈｏｎｙＭＩＤＩＳｐｅｃｉｆｉｃａｔｉｏｎ（ＳＰ−ＭＩＤＩ）に基づいてもよく、これは、本願明細書に取り込まれたものとする。

ある実施例において、個々の楽器の定義の書き換えを可能とするために、書き換え手段（例えば、テーブル又は状態マシンのような）を使用することが好ましく、それによって、特定の楽器は他の楽器の定義に書き換えられる。例として、汎用ＭＩＤＩ（ＧＭ）楽器＃Ｎ用の楽器が音響バンクに含まれていない場合（音響バンクの容量を減少させるため）、この書き換え手段は、好ましくは楽器＃Ｎが楽器＃Ｐに関連する楽器定義に再割付けされたことを示す。この例では、楽器＃Ｎ及び＃Ｐは両方とも、同じ音響（楽器）定義を共有する。

携帯用電子音楽設計の当業者によってよく理解されるように、ここで述べられている実施例は本発明の技術的範囲に含まれるものを代表的に表したものである。付加的な変形（そのいくつかはここに記載されている）は、多くの本発明の態様を組み込む。

本発明が特定の好ましい実施例と関連して記載されたが、多くの置換、代替及び変形が前述の説明を考慮して当業者にとって明らかであることは明白である。したがって、本発明は、添付の請求項の範囲内で、その代替及び変形の全てを受け入れることを目的とする。例えば、本願明細書において記載されているさまざまな別の実施例に従って、それさまざまなシステム、そして、そのシステムに基づく使用及び方法が得られることが理解されなければならない。また、付加的な有利な組合せ及び同類が提供するために、記載されているさまざまな改良及び代替的かつ付加的特徴が本発明にしたがって結合される。また、前述の説明に基づいて当業者に理解されるように、好ましい実施態様のさまざまな態様が種々の下位結合にも用いられ、ここで述べられた少なくともある利点及び属性を達成することができる。この種の下位結合もまた本発明の範囲内である。本発明の全てのこの種の改良、拡張及び更なる使用は、本発明の範囲内である。

以下に、本発明の種々の構成要件の組み合わせからなる例示的な実施態様を示す。
１．放送楽曲を生成する方法において、
楽曲データファイルを生成するステップと、
基地局から、複数ノードの１又は複数のノードに上記楽曲データファイルを放送するステップと、
上記複数ノードの１又は複数のノードにおいて上記楽曲データファイルを受信するステップと、
上記楽曲データファイルから、歌曲データ構造に関する情報と該歌唱曲データ構造に関連する楽曲パラメータを表す情報を提供する楽曲定義データを抽出するステップと、
上記楽曲定義データを処理するステップであって、上記歌曲データ構造及び上記楽曲パラメータに関連する歌曲が、上記複数ノードの１又は複数によって生成されるステップと、
上記複数ノードの１又は複数において、上記生成された歌曲を演奏するステップと
からなることを特徴とする放送楽曲を生成する方法。
２．受信した楽曲データファイルに基づいて音楽作品を生成するシステムにおいて、
上記システムから離間した１又は複数の第二システムとの間で、少なくとも１つの楽曲データファイルを含むデータを送受信する送受信機と、
少なくとも１つの楽曲生成アルゴリズムを実行する楽曲生成装置であって、１又は複数の音楽作品の楽曲出力を生成するために、楽曲ルールを上記楽曲生成アルゴリズムに従って楽譜データに適用するよう構成された楽曲生成装置と、
上記受信された少なくとも１つの楽曲データファイルが記憶されるメモリと
からなり、楽曲データが上記受信された楽曲データファイルからのデータに基づいて生成され、上記楽曲生成装置が上記受信された楽曲データファイルに基づいて音楽作品を生成することを特徴とするシステム。
３．上項２記載のシステムにおいて、該システムはさらにユーザ入力を備え、ユーザによる上記ユーザ入力の動作により上記受信された楽曲データファイル中のデータが変更され、変更された楽曲データファイルが生成され、上記楽曲生成装置が変更されたデータファイルに基づいて変更された音楽作品を生成するよう構成されていることを特徴とするシステム。
４．上項３記載のシステムにおいて、上記変更されたデータファイルが１又は複数の遠隔システムによって受け取られるように上記送受信機によって送信され、上記１又は複数の遠隔システムは、上記変更されたデータファイルに基づいて、上記変更された音楽作品を生成するよう構成されていることを特徴とするシステム。
５．上項２記載のシステムにおいて、上記楽曲データファイルが電話コールの開始の一部として送信されることを特徴とするシステム。
６．上項２記載のシステムにおいて、上記楽曲データファイルが電話コールの一部として送信されることを特徴とするシステム。
７．処理装置でソースサンプルデータを処理して合成されたオーディオサンプルを生成するために、携帯環境で音声合成を実行する方法において、
補間関数を提供して、ソースモノラルサンプルデータに基づいて１又は複数の補間内挿されたモノラルサンプルを生成するように、該ソースモノラルサンプルデータをアクセスしかつ補間内挿するステップと、
フィルタ関数を提供して、フィルタリングされ補間内挿されたモノラルサンプルを生成するように、少なくとも１つの上記補間内挿されたモノラルサンプルをフィルタリングするステップと、
利得関数を提供して、共同してステレオフィールドを生成するための少なくとも左サンプル及び右サンプルを生成するように、上記フィルタリングされ補間内挿されたモノラルサンプルを処理するステップと
とからなる方法。
８．オーディオ出力を生成するために、ＭＩＤＩ合成機能が、減少された占有スペースの音響バンクをアクセスすることにより処理ＭＩＤＩイベントに呼び出されるようにした、携帯環境でＭＩＤＩの基づく合成を実行する方法において、
第１の所望の音響のための第１及び第２のレベルからなるＤＬＳ互換性のある音響バンクを供給するステップであって、第１のレベルがインパクトの開始音響からなる第１のサンプルに関連しており、第２のレベルが安定波形のループ期間からなる少なくとも第２のサンプルに関連している、ステップと、
上記第１のサンプルを上記第所望の音響及び複数の付加的音響に関係する上記ＤＬＳ互換性の音響バンクに関連するパラメータデータを提供するステップであって、上記第１のサンプルが上記複数の付加的音響に関連がない場合、上記ＤＬＳ互換性の音響バンク及び関連するパラメータデータが、そうでない場合より小さい占有スペースを占有するステップと
からなることを特徴とする方法。

以下に、本発明の種々の構成要件の組み合わせからなる例示的な実施態様を更に示す。
１．受信した楽曲データファイルに基づいて音楽作品を生成する音楽作品生成システムにおいて、
上記音楽作品生成システムから遠隔している１又は複数のリモートシステムとの間でデータを送信及び受信する送受信機であって、上記音楽作品生成システムが受け取るデータは少なくとも楽曲データファイルを含み、該楽曲データファイルは、楽曲ピースが忠実に再生されるようにするためのシード情報を含んでいる、送受信機と、
少なくとも１つの楽曲生成アルゴリズムを実行する楽曲生成装置であって、上記音楽作品の楽曲出力を生成するために、楽曲ルールを上記楽曲生成アルゴリズムに従って適用するよう構成された楽曲生成装置と、
上記受信された少なくとも１つの楽曲データファイルが記憶されるメモリと
からなり、前記楽曲ピースに対応する楽曲データが、上記受信された楽曲データファイルからのシード情報に基づいて生成され、上記楽曲生成装置が、上記受信された楽曲データファイルに基づいて音楽作品を生成し、前記シード情報の少なくとも一部が擬似乱数発生（ＰＲＮＧ）ルーチンによって処理されることを特徴とするシステム。
２．上記１記載の音楽作品生成システムにおいて、該システムはさらに、上記受信された楽曲データファイルのデータを編集して編曲された楽曲データファイルを生成するユーザ入力手段を備え、該編曲された楽曲データファイルに基づいて、上記楽曲生成装置が編曲された音楽作品を生成するよう構成されていることを特徴とする音楽作品生成システム。
３．上記２記載の音楽作品生成システムにおいて、上記編曲された楽曲データファイルは、上記リモートシステムにおいて受け取られるように、上記送受信機から送信され、上記リモートシステムは、上記編曲された楽曲データファイルに基づいて編曲された音楽作品を生成することができるようにしたことを特徴とする音楽作品生成システム。
４．上記１記載の音楽作品生成システムにおいて、上記楽曲生成装置は、エンターテイメント装置の音響出力を生成するよう構成されていることを特徴とする音楽作品生成システム。
５．上記４記載の音楽作品生成システムにおいて、上記受信された楽曲データファイルは、上記楽曲出力を生成するために上記楽曲生成装置によって使用されるタイミングループ情報を含んでいることを特徴とする音楽作品生成システム。
６．上記４記載の音楽作品生成システムにおいて、上記エンターテイメント装置はビデオゲーム装置であり、上記音響出力は上記ビデオゲーム装置の音響出力であることを特徴とする音楽作品生成システム。
７．上記６記載の音楽作品生成システムにおいて、該システムはさらに、ビデオゲームデータを格納するフラッシュメモリカードを備えており、該ビデオゲームデータは上記シード情報を含んでいることを特徴とする音楽作品生成システム。
８．上記７記載の音楽作品生成システムにおいて、上記音楽作品はビデオゲームの音響成分であり、上記音楽作品は、ビデオゲームの展開に部分的に基づいて変動するよう構成されていることを特徴とする音楽作品生成システム。
９．オーディオを生成するオーディオ生成方法において、
第１のステーションにおいて、楽曲ピースに対応する第１の楽曲データを生成するステップと、
ネットワークを介して、上記第１のステーションから上記第１の楽曲データを第２のステーションに送信するステップと、
上記第２のステーションで上記第１の楽曲データを受信するステップと、
上記第２のステーションにおいて、上記第２のステーションに存在する第１の作曲機能手段に基づいて、上記第１の楽曲データから、第１の楽曲パラメータに関する情報を提供する第１の楽曲規定データを抽出するステップと、
上記第２のステーションにおいて、上記第１の楽曲規定データを処理するステップであって、上記第１の楽曲パラメータに基づいて第１の楽曲部分を生成するステップと、
上記第２のステーションにおいて、上記第１の楽曲部分を再生するステップと、
上記第２のステーションにおいて、上記楽曲ピースに対応する第２の楽曲データを生成するステップと、
上記第２のステーションから上記ネットワークを介して上記第１のステーションへ、上記第２の楽曲データを送信するステップと
からなり、
前記第１の楽曲規定データが１組のピッチ値を含むことを特徴とするオーディオ生成方法。
１０．上記９記載のオーディオ生成方法において、該方法はさらに、
上記第１のステーションにおいて上記第２の楽曲データを受信するステップと、
上記第１のステーションにおいて、上記第２の楽曲データから、上記第１のステーションに存在する第２の作曲機能手段に基づく第２の楽曲パラメータに関する情報を提供する第２の楽曲規定データを抽出するステップと
上記第１のステーションにおいて、上記第２の楽曲規定データを処理するステップであって、上記第２の楽曲パラメータに基づいて第２の楽曲部分を生成するステップと
を含んでいることを特徴とするオーディオ生成方法。
１１．上記９記載のオーディオ生成方法において、上記第１のステーションはビデオゲーム装置であり、上記第１の楽曲データはビデオゲームの実行中に生成されることを特徴とするオーディオ生成方法。
１２．上記１０記載のオーディオ生成方法において、上記第１及び第２のステーションはビデオゲーム装置であり、上記第１の楽曲データは上記第１のステーションにおけるビデオゲームの実行中に生成され、上記第２の楽曲データは上記第２のステーションにおけるビデオゲームの実行中に生成されることを特徴とするオーディオ生成方法。
１３．上記１２記載のオーディオ生成方法において、上記第２の楽曲データは、上記第１のステーションにおいてビデオゲームを実行中に、上記第２の楽曲部分を生成するために使用されるタイミングループ情報を含んでいることを特徴とするオーディオ生成方法。
１４．上記１２記載のオーディオ生成方法において、上記第２の楽曲規定データは、１又は複数のビデオキャラクタに関連する楽曲情報であることを特徴とするオーディオ生成方法。
１５．上記１４記載のオーディオ生成方法において、上記楽曲情報は、上記１又は複数のビデオキャラクタの接近時に部分的に基づいて、第２の作曲機能手段によって処理されることを特徴とするオーディオ生成方法。
１６．別のシステムにおいて組み立てられる楽曲部分に対応する第１の楽曲データであって、第１の楽曲規定パラメータを含んでいる第１の楽曲データを生成する第１の楽曲データ生成機能手段と、
上記第１の楽曲データをリモートステーションにネットワークを介して送信する楽曲データ送信手段と、
上記リモートステーションから上記ネットワークを介して、第２の楽曲規定パラメータを含んでいる第２の楽曲データを受け取る楽曲データ受信手段と、
上記第１及び第２の楽曲規定パラメータに部分的に応じて、第１の楽曲出力を生成する楽曲組立機能手段と
を備える楽曲生成システムであって、
前記第１の楽曲規定パラメータが１組のピッチ値を含むことを特徴とする楽曲生成システム。
１７．上記１６記載の楽曲生成システムにおいて、上記第１及び第２の楽曲規定パラメータは、上記第１の楽曲出力を生成するために上記楽曲組立機能手段によって使用されるループタイミング情報を含んでいることを特徴とする楽曲出力生成システム。
１８．上記１６記載の楽曲生成システムにおいて、上記リモートステーションはビデオゲーム装置であり、上記第１の楽曲出力はビデオゲームの実行中に生成されることを特徴とする楽曲生成システム。
１９．上記１６記載の楽曲生成システムにおいて、上記楽曲組立機能手段は、ビデオゲーム装置に組み入れられていることを特徴とする楽曲生成システム。
２０．上記１９記載の楽曲生成システムにおいて、該システムは更に、ビデゲームデータを格納するモジュラ型のフラッシュメモリカードを備えており、該ビデオゲームデータは、上記第１の楽曲規定パラメータに含まれていることを特徴とする楽曲生成システム。

Claims

別のシステムにおいて生成される楽曲部分に対応し、且つ第１の楽曲規定パラメータを含む第１の楽曲データを生成する第１の楽曲データ生成機能手段と、
上記第１の楽曲データをリモートステーションにネットワークを介して送信する楽曲データ送信手段と、
上記リモートステーションから上記ネットワークを介して、第２の楽曲規定パラメータを含む第２の楽曲データを受け取る楽曲データ受信手段と、
上記第１及び第２の楽曲規定パラメータに応じて、楽曲を生成する楽曲組立機能手段とを備え、
前記第１の楽曲規定パラメータが１組のピッチ値を含むことを特徴とする楽曲生成システム。
請求項１に記載の楽曲生成システムにおいて、上記第１及び第２の楽曲規定パラメータは、上記楽曲を生成するために上記楽曲組立機能手段によって使用されるループタイミング情報を含んでいることを特徴とする楽曲生成システム。
請求項１に記載の楽曲生成システムにおいて、上記リモートステーションはビデオゲーム装置であり、上記楽曲はビデオゲームの実行中に生成されることを特徴とする楽曲生成システム。
請求項１に記載の楽曲生成システムにおいて、上記楽曲組立機能手段は、ビデオゲーム装置に組み入れられていることを特徴とする楽曲生成システム。
請求項４に記載の楽曲生成システムにおいて、該システムは更に、ビデゲームデータを格納するモジュラ型のフラッシュメモリカードを備えており、該ビデオゲームデータは、上記第１の楽曲規定パラメータに含まれていることを特徴とする楽曲生成システム。