本発明を、好ましい、また他の実施例に関して、更に詳細に説明する。それは本発明の好ましい実施例の理解を進めるために役立つ。本明細書において記載されているように、さまざまな改良及びさまざまな実施例のさまざまな要素の置換が、ここで開示されている原理及び教示に基づいて可能である。
本発明によれば、多数の典型的な好ましい代替実施例として以下に記載されているように、楽曲を創作することができ(自動作曲によるものを含んでいる)て、相互作用することができ、再生(演奏)することができ、種々の新しい方法で実実現することができる。ここで使用されるトップダウンとは、まず開始点で、概ね良質な音楽のための完全な曲構造がエンドユーザのために創作されることを意味する。これは、システムによって提供される開始点に基づいて、楽曲を変更してそれによって新しい楽曲を創作する能力を有しているユーザについては、そのユーザが直ちに良質な音楽を創作できる状態にする。特定のユーザが楽曲生成プロセスをとる場所は、当該ユーザに依存する。汎用の楽曲生成プロセスはボトムアップの方法を含み、該方法では、各々の楽器と楽曲形式の基本を学び、そして個々の音符(ノート)がいっしょになったりする。この従来の方法は、一般に訓練された人々の小グループのみが楽曲を創作することができ、したがって、実際には、多くの人々が音楽の創作プロセスを行うことを妨げていた。
本発明の実施例を理解することのために役立つ類似は、住宅を建設することと同じである。住宅建設の従来の手段において、ユーザには多くのレンガ、釘、木及び塗料が与えられる。住宅を望むなら、電気的配線、配管、工学、その他と同様に、各々のこれらの機材でどのように建設するかの全ての複合を学ぶか、又は、これらの領域において訓練された人々を探す必要がある。同様に、音楽の作成で、歌曲(気持ちのよい)を望む場合、適宜の量の音楽理論と同様に、様々な形態の楽器(そして、各々のそれらのユニークな特質又は制限)についての全てを学び、特定の技術の熟知及び音楽(例えば、テクノ、ジャズ、ヒップホップ、その他)の所定形式の特性を得ることを必要とする。
誰かが住宅を望むときに、完全な住宅を容易に修正することができる(ボタンを押すことで)ならば、はるかに便利であろう。例えば、彼らは台所の中に入ることができて、直ちにそれを広くしたり、あるいは、異なる色にしたり、窓を追加したりすることができる。そして、彼らは洗面所の中に入ることができ、天井を上げたり、温水浴槽、その他を付け加えたりすることができる。彼らは、リビングルームの中に入ることができ、異なる塗料企画又は異なる家具スタイル、その他を取り入れることもできる。同様に、本発明の実施例によれば、ユーザは、望ましくは第一に完成された曲を提供され、一般から独特のものまでのさまざまなレベルで、ユニークな、そして、ユーザの願望、審美眼及び好みに沿った曲を創作するために、該曲を容易に修正できる。
本発明によれば、一般の人々は、直ちに音楽の作成への簡単なアプローチを提供される。それは完成された曲が得られたことの満足感を与える、その一方で、オリジナル曲を作曲することも可能である。音楽作成へのこのトップダウンアプローチは、楽しい音楽を創作することへの障壁を低減することによって、多くの人々に音楽の創造力の世界を開く。
本発明によれば、ユーザが楽曲を創作することを可能にするさまざまなシステム及び方法が提供される。この種のシステム及び方法は、望ましくは、利用する直観的かつ学習/使用が容易なユーザインターフェースを使用する。該インターフェースの使用により、創作途中の楽曲の創作及び相互作用を容易にし、既に創作された楽曲との相互作用を容易にする。
本発明の好ましい実施例によれば、望ましくは音楽の双方向生成を容易にするようにユーザインターフェース特性が具備される。そのようなインターフェースに関して、以下に提供される議論は、主に『プレーヤ』と呼ばれる携帯型の初心者用の装置の一つの実施例に集中している。しかしながら、この種のプレーヤと関連して議論される新しくて工夫に富む特徴の多くは、制御の視覚的拡張及び楽曲生成プロセスのアーキテクチャに関係する。したがって、それらは、音楽創作及び相互作用を許容する他のタイプの装置、例えば、計算機、ウェブサーバ/ウェブサイト、キオスク、ビデオ又は他の電子ゲーム及びその他娯楽装置に適用でき、このようにして、本発明の態様により効果を上げることができる。他のタイプの装置については、以下に説明される。当業者が理解できるように、プレーヤのユーザインターフェースのさまざまな特徴は、より幅広い範囲に適用できることは言うまでもない。
通常、ユーザインターフェースの目標は、同時に、システムの機能を保つと共に、最小限の数のボタンを有して、さまざまなパラメータを有するシステム及び相互作用の直観的、単純な操作を可能にすることにある。図1は、プレーヤ10のための典型的なシステム構成を例示する。ディスプレイ20は、ユーザに以下に説明するような視覚の情報を提供する。以下に記載されるように、種々のモードキー16は、ユーザがシステムの動作モードを直接アクセスすることや開始することを可能にするボタンを提供する。以下に説明するように、ジョイスティック15は、ユーザがさまざまな音楽の又はシステムパラメータ等を選択又は相互作用させることを可能にするために提供される。ユーザが創作し又はシステムを使って作ることができる曲又はパラメータの変更、その他を保存するために、そして、パラメータ、演奏リスト、サンプル、その他の編集を始めるために、記憶/編集キー17が具備される。出力ボリュームレベルの調整を可能にするため、アップ/ダウン形式のデュアルボタンか、単一のノブ又はダイアルのいずれかの形態のボリュームキー14が具備される。ファンクションキー11は、演奏(ok)、停止(キャンセル)、送り(insert/create)、戻し(削除)及び記録のようなプレーヤ機能を可能にするために具備される。その典型的な使用の詳細は後述する。FXキー12は、ユーザが容易かつ直観的に楽曲(例えば特定のサンプル音)の部分の1又は複数の音響効果(例えばドップラー、残響、ウォブラー、カスタム、その他)を調整することを可能にするために具備される。ユーザによる直観的な音響効果選択を可能にする好ましい方法は、FXキー12をジョイスティック15の左右コントロールと結合して使用することを可能にすることであり、直観的な音響効果調整(例えば、選択された音響効果の効果を増減する)を可能にする対応する好ましい方法は、FXキー12がジョイスティック15のアップダウンコントロールと結合して使用されることを可能にすることである。以下により詳細に記載されているように、ピッチ/テンポの変動(好ましくは、ジョイスティックの動作とともに)ための単一ボタンの活性化を可能とするため、ピッチ/テンポキー13が具備される。オン/オフボタン18は、プレーヤをオン又はオフにするために具備される、そして、好ましくは、瞬時押圧/トグルが、LCDバックライトをターンオン/オフするために用いられる。但し、例えば、他のターンオフモードも、同様に使い得る(プレーヤが再生状態ではなく、所定のタイムアウト期間などで、検出される操作がなかったときの、タイムアウトターンオフ等)。図示したプレーヤ10の実施例におけるこの種のボタン及びキーを典型的な望ましい使い方は、以下の説明により明らかとなるであろう。
好適な実施態様に従って、ホームモードが提供される。ホームモードは、プレーヤ10がオンにされたときに、自動的に開始されるデフォルトモードである。図4の実施例は、ユーザが直接アクセスモードキー16を押圧することによってモードを選ばせ、又は、ジョイスティックを押圧することによってヘルプモードに入る動画の画面を、ホームモードにおいて表示することを示している(図4は、無線アクセスキー操作を促す動画の瞬間を表す)。好ましい実施態様において、ユーザは、例えば、コンパニオンPCソフトウェアプログラム(詳細が後述される)を使用して、ディスプレイ20に表示されるグラフィックスを定めることができ、異なる動作モードの間、デフォルトグラフィックスに代えて、自動的に置き換えられるべき(利用できるならば)グラフィックス(アニメ化又は非アニメ化されたもの)を選ぶことができる。特定の実施例においては、この種のグラフィックスの多数のセットがあってもよく、ホームモードが呼び出されるたびに、システムは異なるセットを選ぶことができる。カスタム画面のこの実施例において、曲及び/又は各動作モードの各楽節のためのカスタマイズされたスクリーングラフィックスに対応するデータファイルが、取り外し可能なメモリ手段(例えばスマートメディアカード(SMC)のフラッシュメモリ)の記憶場所の歌曲データ構造(後述される)の一部として記憶される。好ましい実施態様において、ホームモードで、システム(例えば、モード/直接アクセスキー16(第1図を参照)と関連するモード)で利用できるさまざまなモードによって、画面はスクロールする。さらに、プレーヤ10は好ましくは他のいかなるモード(すなわち、ユーザがストップキーを押圧することで)の主メニューから、ホームモードまで戻るように構成される。ジョイスティックがホームモードで押圧されたときに、好ましくはヘルプ画面が表示され、ユーザにどのキーを押圧してもよいことを示す。ヘルプ画面の一例が図5に示される。この実施例においては、プレーヤ10がこの画面を表示しているときにあるキーが押されると、そのキーに関する有用な文書が表示される。
ホームモードにおいて、I−Wayモード(後で更に詳細に説明する)と称した特に重要な視覚的インターフェースモードに入るために、再生が使われる。図6の実施例に示すように、好ましくはLCD画面が、「e.DJ スタイル」のような他の可能なモードに関して、メッセージをステータス(状態)表示行に示すことができ、楽曲のスタイル/サブスタイル(例えば、テクノミックス、ハウス、ガラージュ、その他)の選択を提案する。この種の画面で、所望のスタイルを選ぶために、ユーザはアップ又はダウンを押圧することができる。この例では、大文字のスタイルは、好ましくは、各曲のためにランダムに選択されるサブスタイルのカテゴリを示し、サブスタイルが各々の大文字のスタイルを生じる小文字のスタイルによって示される。ユーザがスタイルを選ぶと、選択されたスタイルを有するI−Wayモードに入るために、ユーザは再生を押圧することができる。I−Wayモードが始まると、プレーヤ10は自動的に選ばれたスタイルの曲を生成して再生を始める。好ましい実施態様に従って提供される典型的なスタイル/サブスタイルは、クールミックス(サブスタイル バラード、ボサノバ、ニューエイジ)、ヒップポップミックス(サブスタイル ヒップホップ、ラップ、R&B、ダウンビート、ラガ)キッチュ、テクノミックス(サブスタイル ハウス、ガラージュ、トランス、ジャングル)、その他を含む。重要なことは、好ましい実施態様に従って、特定のスタイル/サブスタイル、その他に従う音楽の手早い作成とユーザ変更を可能とするために提供される直観的で使いやすいインターフェースを用いて、個別の楽曲スタイル(少なくともいくつかの楽曲スタイルは異なったサブスタイルを含んでいる)が決定されるということである。そこでは、結果として、特定のスタイル及び/又はサブスタイルの特性が、特定のスタイル/サブスタイルに従って楽曲の自動創作に適用される異なる楽曲ルールになる(楽曲ルール及び他のアルゴリズムの使用及び好ましい楽曲生成処理の詳細は、本願明細書において更に詳細に他の箇所で記述される)。追加の実施例において、音楽の審美性についてのより微細な階調の使用は、マイクロスタイルの形でユーザが利用できる。例えば、特定のサブスタイルにほぼ合致する複数のマイクロスタイルが提供される。その一方で、サブスタイルには一緒に、特定のスタイルにほぼ合致する1又は複数の他のサブスタイルが伴う。音楽の粒状性(granularity)についてのこの第3の結合は、ユーザにアルゴリズム音楽の楽曲出力のより微細な制御を提供する。この種のマイクロスタイルは、おそらく、スタイル/サブスタイルのいくつかの柔軟性を失うが、より一貫した楽曲を提供する。重要であることは、ユーザが楽曲スタイルのカテゴリー化の複数のレベルを提供されるということである。基本的には、レベルが下降すると、ユーザ及び/又は自動作曲アルゴリズムなどによって変化させることができる楽曲のパラメータ範囲は、次第により制限され、選択される特定のスタイル、サブスタイル、スタイル、その他と整合される。
ホームモードの重要な特徴は、迅速且つ容易に楽曲を再生(演奏)を開始できるようにプレーヤ10を構成する能力である。なぜなら、プレーヤ10が対話的に構成され、多くの専門レベルの機能がスタイル及び音声のさまざまな態様を調整するために利用することができるが、ユーザにとって「押圧及び忘れ(press−it−and−forget−it)」モードでプレーヤを使用するために、迅速且つ容易な方法を有することが望ましいからである。このようにして、極めて少ないボタンプッシュだけで、ほとんどあるいは全く音楽の経験のない、若しくはプレーヤ10に接したことがほとんどあるいは全くないユーザであっても、容易に所望のスタイル又はサブスタイルのオリジナル楽曲を作曲し始めることができる。自動再生型の能力を提供する付加的な好ましい方法は、取り外し可能な記憶メモリ媒体(例えば、スマートメディアカード)を使用して、例えば、取り外し可能なメモリに存在する歌曲データ構造のリストを含んでいるファイル等の再生リストを記憶することである。この実施例にしたがって、ユーザが取り外し可能なメモリを挿入したり、すでに取り外し可能なメモリが挿入されているシステムに電源が投入されるとき、システムは取り外し可能なメモリを走査して、再生リストを含むこの種のファイルを探す。そして、システムファイルにリストアップされている歌曲データを演奏し始める。好ましくは、自動再生モードが選択(例えば、システムファイルの構成設定を経て)可能であるように、そして、システムが、異なるモードに入る機会をユーザに与えるために、自動再生を開始する前に短い持続期間を待つように、この装置は構成される。
図7Aに示したように、I−Wayモードのための典型的な好ましい画面は、ハイウェイ又は多車線道路又は通路の視覚表示を運転しているか又は移動しているユーザの正面図を表す。画面の一番上に沿って、進行中のeDJセッション(例えば、パート1、フィルタリングドラム、コーラス、パート2、<<サンプル名>>、その他)の現在部分又は状態を表示するステータスメッセージがある。好ましくは、より傑出してステータスメッセージを示すために、ユーザに表示する他の方法も用いることができる。例えば、システムは、ほぼ全ての画面に対応する大きい視覚インジケータを瞬間的に発光させることができる。演奏されている楽曲に合わせて波動しているスピーカの視覚の表示が、視界の直前にあることが好ましい。I−Wayの各々のレーンは、楽器レーン(ドラム、バス、リフ、リード)や、1又は複数のサンプルレーン(予め格納された声音、音響、その他のサンプルと対話するために)、又は、リアルタイムでマイク入力を管理する1又は複数のマイクレーンのような、楽曲の様々な形の要素を示す。本発明の範囲内のあるレーンのための他のカテゴリも設計することができる。本発明の本態様にとって重要であることは、ユーザに複数のレーンを含むマルチレーン視覚表示が与えられることであり、各々のレーンは、作曲されているか又は演奏されている楽曲の構成要素、効果、その他と一致する。ユーザは、表示の中心を移動するために、ジョイスティック15を使用する(例えば、図1において示したように、一番上、一番下、左及び右の4つの領域において押し下げることができる円形のボタン)。通常、ジョイスティック15の方向選択的な押圧は、対応する方向に表示の中心をシフトさせる。例えば、左のレーン及び右のジョイスティックボタンが押圧されるときに、表示の中心は1レーン以上右へ移動する。
別の実施例において、例えば図7Bに示すように、1節が、例えばリアルタイムで、そのレーンと関連する楽曲の構成要素の相対的な量を表す各レーンのために提供される。別の実施例において、対話用の追加レイヤは、I−Wayの付加水平レイヤによって示される。例えば、ドラムのためのI−Wayのレーンで(小太鼓、バス、フロアトム、ハイハット、クラッシュシンバル、ピングライドシンバル、ロト−トム、その他のような異なった楽器構成要素、ティンパニ、ゴング、トライアングル、その他のような打楽器)、各々のドラム又は構成要素、及び/又はドラム又は楽器音響の異なる態様のためのレーンについては、ドラム又は他の多様な構成要素をもつ楽器用の他のI−Wayに移動するために、ユーザはダウンキー押すことができる。このような多様なI−Wayインターフェースの概念が、ドラム又は他の多様な構成要素からなる楽器(他の楽器は単一I−Wayインターフェース、その他を維持しながら)等の手段から利益を受ける楽器だけのために、選択的に使われる。付加的I−Wayレーンの利用は、本発明の全ての利点を享受するのに必要ではなく、本発明のある使い方、例えば、より専門の用途のために適応させられる製品にとって、また、付加的なユーザインターフェース及び楽器制御の複合性が望ましい楽曲スタイル、例えば、クラシック音楽、又は、ジャズにとって望ましい特徴である。
I−Wayモードにおいては、画面は、好ましくは楽曲拍子に同期した音波又は波動で動画化される。図7Aの実施例において、丸いスピーカの視覚表示は、現在レーンの相対的な量を象徴するために、中央に図示される。この視覚表示は、レーンがミュートされたとき、消えるか又は他の方法で変えられるように構成される。その特定のレーン/楽節の相対的な量が調整されるにつれて(例えば、ジョイスティックアップダウンボタンと組み合わせたファンクションキーを用いて)、より大きく又はより小さくなるように構成することができる。他の単純なバリエーション、例えば、各レーンにおいて同時に見える音量計、各レーンにおいて同時に見えるミュート表示、そのレーン、その他によって示される楽器を視覚的に思い出させる各レーンの画像等もの、本発明の範囲内である。
I−Wayモードのような自動作曲モードにおいて、CD上の又はラジオから実際の歌曲におけるような音を鳴らすようにするのは、歌曲進行を決めるプレーヤ10である。それは、楽器を自動的に加えたり除外することができ、楽曲休止、ドラム進行、コード進行、フィルタリング、変調を行ったり、楽曲と同期してサンプルを再生(演奏)し、ルール及びその他に基づいて演奏するためにサンプルを選択することができる。2、3分後に、何もユーザによってされない場合、プレーヤ10はボリュームの自動フェードアウトで楽曲を停止し、同じスタイル又はあるいは、異なるスタイルの新曲を、自動的に作曲して演奏するように構成される。また、I−Wayモードは、プレーヤ10を使ってユーザが創作/修正し、そして後の再生等のために、プレーヤ10に格納された楽曲等(それは、自動作曲を部分的に用いて創作されたものでもよい)の、自動作曲しない楽曲にも好ましい実施態様で適用できることを理解すべきである。
ある実施例では、新しく生成されたパターンに1〜nまで番号をつける。この番号は、ユーザが彼/彼女が好きである楽曲パターンを記憶しているのを助けて、他の2、3のものを試用した後に元のものに戻るためにステータス線を付けて示すことができる。ある実施例において、この番号は、与えられた歌曲内部で、そして、現在の対話的セッションの間だけ有効である。すなわち、例えば、作曲されている現在の歌曲のためのリフパターン番号5は、他の曲において構成されるリフパターン番号5とは同様に聞こえない。しかしながら、この曲がユーザ歌曲として保存される場合、後に再演奏されるときにリフ楽曲が同じものであっても、それに関連する番号を異ならせる。
一つの典型的な実施例において、プレーヤ10は、現在の対話型セッションの間に予め作曲された最高16のパターンを「記憶している」。例えば、これは、表示される現在のパターン番号が26である場合、ユーザが前に作曲されたパターン(本実施例において、パターン1〜9は上書きされているか又は一方破棄されている)を順次閲覧することによって、番号10〜25のパターンを聞くことができることを意味する。ユーザが現在演奏されている所定の作曲パターンをスキップしたい場合、それが可能であり、そして、パターン番号は増加しない。これは、現在演奏されたパターンが失われることを意味する。この特徴は、ユーザ要求により、前に演奏された複数のパターンの特定のパターンだけを記憶するために用いることができる。重要なことは、ユーザの特定の好み、要求、又はその他に基づいて、ユーザによって決定される楽曲を作曲するために用いる格納されたパターンを用いて、ユーザが楽曲パターンを創作し、選択的に格納する(いくつかの所定数の楽曲パターンまで)ことができるということである。I−Wayモードによって表される画面は、プレーヤ10によって生成/演奏される楽曲をユーザが作成しかつ対話したり、そして変更したりするのを容易にすることが望ましい。
ある好ましい実施例において、必要に応じてユーザによって、I−Wayモードの特定レーンと関連する楽器の付加楽曲パラメータは、ユーザが「見ること」ができかつ対話型である。例えば、Down(ダウン)が押圧される場合(例えばジョイスティック15を経由して)、I−Wayモードの間、画面の中央は、特定のレーン(例えば、図8A参照)の「内部」に対して、「地下」としてとらえられる。このような「地下」モードへの移行は、より好ましくは、床を下方に貫通する観点又はI−Wayレーンの床又は底を貫通して、そのレーンによって示される楽曲の構成要素と一致する特定レーンの下のトンネルの視覚表現であるように見えるものまでの下方の画像ポイントの動きを表している画面動画を構成することによって、視覚的に魅力があるようにされる。ある実施例において、視覚のこの種の移行には、好ましくは音のフィードバック(例えば、トンネルモードの開始/終了という警報をユーザに出す音)が伴う。ある実施例において、例えばユーザ定義可能な構成パラメータに応じて、この種の音のフィードバックが『保存された』音楽作品の一部として記録されないことはが望ましい。このように、ユーザインターフェースは、創作されている歌曲を必ずしも実行せずに強化される。特定レーンの下のトンネル内で、パルス指示(スピーカパルスと同様の)がI−Wayセッションのテンポに合わせて生じる。さらに、トンネルの左右の壁は、左右の音響チャネル出力の波形を示すために用いることができる。あるいは、この種の波形効果の代わりに、ある実施例では、左右の音響チャネル出力に伴う棒グラフを提供することが望ましい。例えば、図8Bはそのような実施例を例示する。さらに、これらの実施例において、ディスプレイが必ずしもオーディオ出力と一致しない場合であっても、この種のグラフィックディスプレイを提供することが望ましい。例えば、利用できる処理資源がリアルタイムで音響を正確かつ詳細にグラフ化/図表化する能力をもつ余裕がない実施例では、音響の近似は、それがより直観的なユーザインターフェース経験をユーザに提供するので、有利である。
ある実施例において、圧力フィードバック機構(図29と関連して後述する)を提供することが好ましい。あるの実施例において、圧力フィードバックイベント(例えば、携帯用装置の振動)を楽曲(例えば、バスドラム)の音波の特性に同期させることが好ましい。ある実施例において、すなわち、ユーザのGUI経験の一部として、視覚の移行を有する圧力フィードバックイベントを視覚の遷移に同期させることが好ましい。例えば、I−Wayモードからの地下モードへの遷移には、圧力フィードバックイベントにより実行することができる。
トンネルの遠端は、その特定レーンの音響に影響を及ぼしている1又は複数のパラメータの値に相関して変動することができる形状(例えば、長方形又は幾何学的なその他)から成る。例えば、ドラムの場合、フィルタパラメータは、ジョイスティック上方又は下方ボタンに加えて、機能又はFxボタン(図1を再び参照)を押し下げることによって、変化させることができる。この時に、トンネルの端を含んでいる形状は、形状を変化するか、視覚的に離れてより遠いかより近くなるように見える。他の例では、ギターのピッチは、左又は右のジョイスティックボタンに加えてピッチキーを押圧することによって調整することができ、同時に、ピッチパラメータ値が増加するか又は減少するとき、形状を多少傾斜させることができ、あるいは、丘を登っていくか又は丘を下って行っているトンネルの視覚の表現が、視覚的にピッチの増加又は減少を示すために提供される。他の実施例において、右/左又はステレオバランス型効果を変化させるために、ジョイスティックボタンの左/右又は上/下操作に加えて、あるモードのシステムのパラメータを変えるよう機能ボタンすなわちFxボタンが押圧される。この種の入力は、例えば、音響バランスを左チャネルよりも右チャネル寄りにする(右へ曲がるトンネルの視覚表示を伴うか、逆に左チャネルへシフトする音響バランスを表すかして)か、又は、より広いかより狭いステレオ効果が要求される場合、その幅において、より広いか狭くなるようなトンネル開口を表すことができる。しかしながら、形状又は他の視覚効果が、ユーザ入力、音響を効果づける1又は複数のパラメータとの相関においてどのように変調され得るかについては、いくつかの例がある。重要であることは、ユーザが特定の楽器レーンに「トンネルを掘る」ときに、楽器と関連するさまざまなパラメータが、ユーザに提供される視覚表現における変化を伴う少なくとも一定のパラメータの変化(例えば、形状、サイズ、色(色表示実施例のために)又は示された視覚表現の動き)を持って、ユーザによって変えられることである。
地下モードでは、ユーザがジョイスティック及びプレーヤ10の他のボタンを使用する特定の要素(例えば、ドラム)と対話し、修正することができる間、プレーヤ10は同じ楽曲のシーケンスによって繰り返し実行され続けるように構成される。また、特定の構成要素に対応するレーンにおける間、好ましくは、ジョイスティックの左右のボタンは、一つの構成要素パラメータから他方に動かすために用いることができる。あるいは、横から横へのジョイスティック移動は、例えば、ユーザが一連の予め設定された特性又はパラメータで進むことを可能にする(すなわち、単純なジョイスティックタイプユーザ入力については、ユーザは、特定の構成要素のさまざまなパラメータを変化させることができ、この種のパラメータ変化と関連する音楽効果を聞くことができ、特定の時等で、ユーザによって要求される特定の楽曲のための望ましい特性を決定することができる。)。さらにもう一つの変形例において、横から横のジョイスティック移動は、例えば、画面に一つのトンネルから隣接したトンネル等までシフトさせることができる。全てのこの種の変形例は、本発明の範囲内である。
他の類似した変形に加えて、ユーザはストップ(停止)キー(図2に示す)を用いて、I−Wayモードの特定レーンを好ましくはミューティングすることができる。これに例において、レーンがミュートされる間、「ミュート状態」がステータスバーにおいて示され、そして、丸いスピーカは消える。この種の実施例によれば、ユーザがストップキーを再び押圧することによって、楽器を非ミュート状態にすることができる。
ユーザインターフェースの望ましいバリエーションは、新しい歌曲部に対応して、好ましくは視覚の外観への変化を動画化することを含む。例えば、図8Aに示される地下モードにおいて、又は図7Aに示されるI−Wayモードにおいて、コーラス部分に対する移動は、解放ドア部を通しての移動により行われる。その歌曲の所定の楽章(例えばコーラス、イントロ、ブリッジ、終章、その他)に対応するグラフィック動画を、その歌曲の間でその楽章が演奏されるたびに使うことができる。遷移の実施例は、以下の通りである。ユーザを1セットの視覚的特性を有するトンネルから出入り口から通過させ、視覚特性の第2の一組を有するトンネルに至らしめる。他の実施例は、ユーザを遷移入り口を通してあるトンネルからより広いトンネル、又は開いた領域へ移動させることである。本発明の本態様の好ましい特徴は、歌曲部分の間で楽曲遷移に密接に結合される動画遷移を調整することによる利用経験を、ユーザに提供することである。
ある別の実施例においては、楽曲の構成要素の特定態様を編集するために、直観的なインターフェースを提供している所定レーンと関連する各レイヤで、図8Cに示されるように、トンネルの多数のレイヤを提供することが好ましい。これらの実施例において、特定のトンネルレイヤを経て編集可能な関連した態様を有する隣接レーンがある場合、図8Cの水平矢印で示されるように、隣接したトンネルの間でユーザが直接移動することを可能にすることが好ましい。
I−Way及び地下概念の変形例を、本発明によって使うことができる。例えば、ユーザインターフェースは、現在の歌曲にある楽器を視覚的に表し、ユーザがその一つを選んで、トンネルすなわち特定の楽器のパラメータが調節されるレベルにはいることを許容する。この例では、楽曲が演奏される間、楽曲に合わせて視覚的なパルスを発している作動中の楽器により、ユーザインターフェースは現在の歌曲における楽器の視覚の表現を提供する。図13Aは、この種のユーザインターフェースの実施例である。この種の実施例によれば、ユーザは楽器(例えば、ジョイスティック15又はファンクションキー11を有する)の特定の視覚の画像を選ぶことができ、その楽器の使用状態に入ることができる。例えば、震動しているドラムセット25を選ぶことによって、ユーザは他のレベル、例えば、それが現在演奏されていることを明らかにしているドラムを有する図8Aに関して上述された地下モードに対応するレベルに入ることができる。そして、音響効果及びドラムトラックと同様に、ドラムの異なる態様をユーザは選びかつ変化させることができる。図13Aに示されるような他の楽器をユーザが選んだ場合、その特定の楽器トラックのパラメータを同様に変えることができる画面にアクセスすることになる。したがって、ユーザインターフェース用の代替テーマの使用は、本発明(特に、実際の楽器があたかもステージ上にあるように表されるテーマ)によって、有利に使用される。
この種の実施例の特定の実施例として、図13Bは3Dステージを表す。この種の実施例においては、初心者の感覚でそのステージ上での試行をユーザに許容することが好ましい。ユーザは、直感的に移動することを許容される。すなわち、3Dディスプレイは、ユーザが移動すると、そのステージ上でユーザの視覚的見方を反映するために更新される。例えば、Quake III Arena(ID Softwareから入手可能な)のような周知のコンピュータビデオゲームで、この第1の効果を達成する技術はがく使用されている。ユーザは、所定の楽器の方へ進むことができて、その楽器によって示される楽曲の構成要素のパラメータを調整することができる。例えば、バスコンポーネントの場合で図13Bの実施例の場合、ユーザはそのステージ(例えば、図13Bに示される3Dのステージ左手に表されるキャビネット)上のバス増幅器及びキャビネットの方へ進むことが可能である。バス増幅器の近くに移動すると、即座に、3Dボタン及び/又はスライダは、ディスプレイに拡大されて、実際のバス増幅器の制御がバスギターの音響に影響を与える方法と同様の方法で、楽曲コンポーネントの音波の制御をすることができる。このように、ユーザは、好ましくは楽曲演奏の視覚的態様を模する直観的なGUIを提供される。その結果、音波特性の制御を、より直観的に行うことができる。
ある実施例において、2つの又は多数のタイプのユーザインターフェースが提供される、そして、ユーザは、図7Aに示されるようなI−Wayタイプのユーザインターフェース、又は、楽器グループ又は他のタイプのインターフェースを選択することができる。重要であることは、楽曲を創作するために用いる楽器を視覚的に理解するために、好ましい実施態様のユーザインターフェースが直観的で使いやすい方法を、楽曲創作経験のほとんどないユーザに提供することができるということであり、そして、特定の楽器と関連するパラメータ及び効果をユーザが変更することができるモードにアクセスする視覚的方法を提供することである。これは、変更されたパラメータ/効果、その他と一致する視覚の変化を伴う。
加えて、ある好ましい実施例においては、外部ビデオディスプレイデバイス(例えば、コンピュータモニタ、テレビ、ビデオプロジェクタ、その他)が、演奏されている楽曲に対してより精巧な視覚的伴奏を表示するために用いられる。そのような場合、I−Wayグラフィック表示は、好ましくは図7A(例えば、カラー階調及び/又はドット/インチに関するより高い解像度イメージ)に示されるI−Wayのより詳細な演出である。アーティスト特定の楽曲(例えば、本明細書の他の箇所で論じられているように)を含むことができる実施例において、ビデオ出力はアーティストによってリリースされる音楽ビデオであってもよい。この種の実施例において、リリースされた形式(例えば、不変の)で、あるいは、本発明の他の特徴(例えば、複合な/単純なデータ構造と関連する特徴、PRNGルーチン、楽曲ルール、声の相互作用、その他)を組み込む形式で、そのアーティスト楽曲を含むことが好ましい。この方法では、好ましくはある程度のユーザ対話性をもって、ユーザは、音楽ビデオを見ることができ、かつそのアーティストの楽曲のミキシングし直し可能なバージョンを聞くことができる。ある実施例において、ユーザインターフェースは、音声/視覚のリモートコントロール入力装置であってもよい。例えば、それは音声構成要素又はテレビを作動するために用いてもよい。このような実施例では、ユーザがアーティストの音楽のミキシングし直し可能なバージョンと対話することができるように、リモートコントロールのボタンを用いることが好ましい。例えば、この開示の全体にわたって論じられるユーザインターフェースの特徴は、リモートコントロールインターフェースとの使用に適合していてもよい。これらの変形の態様は、更に詳細に本明細書の他の箇所で後述される。
ある好ましい実施例において、「Play(演奏又は再生)」を押圧することは、好ましくはレーン楽器に「強制」モードに入らせる。その楽器のレーンがアクティブなときに、再び「Play」を押して「強制」モードが終了されるまで、プレーヤ10にいつまでもこの楽器パターンを演奏することを強制するために、これを具備することができる。この場合、「Force(強制)」モードが選ばれると、楽器が鳴っていない場合、プレーヤ10は自動的に楽器パターンを作曲し、直ちにそれを演奏するように構成され、現在のシーケンス(例えば、2小節)終了後に起動することができる。加えて、比較的長い期間(例えば、1秒以上)「Play」を押圧すると、楽曲を休止することができ、その時、「Paused(ポーズ又は休止)」メッセージをステータスラインにおいて点滅させる。
他の好ましい実施態様で、この種の「強制」モードが必要でない場合(例えば、単純性及び/又はある特定の楽曲のために必要とされないかもしれないという理由で)、「Play」を短時間押し下げすることによって「休止」状態を生じさせても良い。この種の休止は、好ましくは「休止」メッセージをディスプレイ20に現れさせて、楽曲の時間内で歌曲とともに始まりそして終わるように、好ましくはリズミカルに量子化される(例えば、最も近い四分音符(ノート)に対してリズミカルに端数切り上げ又は切り下げ)。
「Sola(独奏)」モードにおいて、他の全ての楽器は音を消され(すでに「独奏」モードにあってもよいそれらを除いて)、この楽器だけが鳴っている。「独奏」のモードは、「Play」ボタンを押し下げことで「独奏」モードに入って楽器がすでに演奏しているなら、特定の楽器用のトンネル又は他のレベルに入ることによって可能にされる(例えば、楽器が「強制」演奏状態にあり、そして、地下モード下の「Play」ボタンの次の押し下げにより、その楽器のための「独奏」モードを始める;典型的な「独奏」モードへの特定のキーエントリ)。対応するトンネルを出て、楽曲I−Wayに戻るときに、楽器は独奏のままである。「独奏」モードから抜けるには、ユーザはまた対応するトンネルに再び入らなければならない。また、ある実施例では、異なるトンネルに入り、「独奏」モードを可能とすることにより、一つずつ又は同時に、あるいは効果的な独奏モードになることによって、いくつかのトラック独奏できるように、「独奏」モードの多数のレベルが可能である。加えて、ある実施例では、長時間(例えば2秒)「Play」ボタンを押すことによって、レーンの期間中、ユーザがI−Wayから「独奏」モードに入ったり/抜け出したりしないようにしたりすることができる。この実施例によれば、「独奏」モードを動作をさせないことにより、手動ですでにミュート状態にある(「独奏」モードが起動される前に)いかなるレーンも、ミュート状態を保持する。
好ましくは、サンプルメニューから、異なるサンプルパラメータを編集することができる。サンプルメニューから、ユーザは、音声、楽曲又は音響サンプルに対する効果を記録することができ、演奏することができ、変更することができる。このメニューも、サンプルリストの作成及び編集を許容する。LCDは、好ましくはステータスラインに「e.Samples」を、そして、そこから選択される記憶媒体(例えば、図32と関連して論じられるスマートメディアカード)中の利用可能なサンプル又はサンプルリストを表示する。
サンプルを再生するときに、LCDは演奏サンプル画面を示す。サンプルの名前は、LCDの中央右部のバナーにおいてスクロールされ、同時に、オーディオ出力レベルがその名前周辺で比較的大きいフレームによって示される。ステータスラインは、好ましくは現在の効果を示す。
ユーザ曲のためにMIDIファイルと同様に、サンプルセット又はリストが好ましくは「e.DJ」によって使われる。MIDIファイルの場合、コンパニオンPCソフトウェアプログラム(例えば、Cakewalkのようなソフトウェアプログラムを編集している標準のMIDI)は、ユーザが自分自身のMDIファイル(必要に応じて)を編集することを可能にし、特定のタイミング位置でサンプルを演奏することを可能とするためにMIDI非登録されたパラメータ番号NRPN(詳細に後述する)を使用することを可能にする。この実施例によれば、コンパニオンPCソフトウェアプログラムは、ユーザがNRPNを用いてサンプルをMIDIデータに挿入することを許容する。新しいe.DJ歌曲が創作されるときに、プレーヤ10は既存のサンプルリスト(好ましくは楽曲の特定のスタイル/サブスタイルを伴うサンプルセット)から1つを選択して、それから歌曲の適当な時間(以下に記載されているように、好ましくは疑似乱数発生に基づいてアルゴリズムで決定される)に、このリストのサンプルを演奏する。ユーザ歌曲を創作するか又は編集するときに、ユーザはこのユーザ歌曲に好ましくはサンプルリストを関連させることができる。その後、このリストのサンプルは、適当な時点で自動的に歌曲に挿入される。各サンプルリストは、e.DJ楽曲スタイル/サブスタイルを伴うことができる。たとえば、テクノスタイルを演奏するときに、テクノスタイルと関連するリストは、テクノユーザ歌曲によって又はe.DJによってのみ使うことができる。変形例おいて、ユーザは、後述するNRPNを介して、特定のサンプルが歌曲において演奏される特定タイミングを特定することができる。特定のサンプルのこのタイミング仕様は、コンパニオンPCソフトウェアプログラム(例えば、Cakewalkのような標準のMIDI編集ソフトウェアプログラム)の使用及び/又はプレーヤ10上のテキストインターフェースメニューによって、ユーザにより示される。
新しいサンプルリストは、デフォルト名称(例えば、サンプルリスト001)で好ましくは創作される。リストは、システム−ファイルメニューで、名称を変ることができる。選択された項目がサンプルであるときに、現在の効果がステータスラインに示される。選択された項目がサンプルリストであるとき、「List(リスト)」がステータスラインに表示される。
圧縮音声、MIDI、カラオケ及びユーザ歌曲(例えば、保存されたe.DJ歌曲)の再生は、「歌曲」モードにおいてアクセス可能である。歌曲は、順番に歌曲のプログラム(連続)を行うために、いわゆる演奏リストにおいて集めることができる。LCDは、好ましくはステータスラインに「e.Songs」を表示し、選択するために、スマートメディアカード上の利用可能な歌曲のリスト又は演奏リストを表示する。
歌曲(例えば、ユーザ歌曲、MIDI又はWMA)のタイプに従い、異なるパラメータが編集される。現在の選択のタイプは、ステータスバーに、例えば、WMA(WMA圧縮音声のために)、MID(MIDI歌曲のために)、KAR(MIDIカラオケ曲のために)、MAD x(ユーザ歌曲{テクノスタイルのためのx=T、ヒップポップのためのx=H、クールのためのx=K、その他}のために)及びList(演奏リストのために)等のように表示される。
歌曲の名称は、LCDの中央右部のバナーにおいて好ましくはスクロールされ、同時に、オーディオ出力レベルがその名称周辺で比較的大きいフレームによって示される。歌曲がカラオケ曲である場合、歌詞はLCDの底で2行(又は他の数)に表示される。動画フレームは示されない。歌曲がユーザ歌曲(すなわち、e.DJによって作曲されて、「保存」/「編集」ボタンを使用して保存された)である場合、楽曲I−Wayモードが演奏歌曲モードの代わりに開始される。
その後、編集スクリーンが示され、左右の2つのカラムが表示される。左カラムは、編集可能なパラメータ又はオブジェクトを項目にリストにし、右カラムは、これらのパラメータの現在値を示す。例えば、演奏リスト編集スクリーンは、左側上にスロット番号及び右面上に歌曲名を表示する。現在の対象が、リバースビデオにおいて強調される。
演奏リストは、歌曲番組を創作するために用いられる。新しい演奏リストは、デフォルト名称(例えば演奏リスト001)で創作され、ユーザによって名称変更することができる。リストが選ばれて、歌曲選択された画面で演奏されるとき、リストに載っている第1の曲の演奏が開始される。歌曲終了後、リストの最後に達するまで、次の歌曲が始まる。リストにおける終了インストラクションが最終リストである場合、プログラムは停止し、そして、プレーヤ10は歌曲選択スクリーンに戻る。終了インストラクションがループリストである場合、第1の曲が好ましくは再び始まり、ユーザが、例えば停止ボタンを押すことによって演奏している曲を中断するまで、プログラムは繰り返し実行される。
本発明の実施例において、従来のラジオの特徴が、本発明のユーザインターフェース(例えば、図32のFM受信機50を参照)に、効果的に組み込まれる。例えば、「ラジオ」モードにおいて演奏するときに、LCDはラジオ画面を示す。LCDは、選択する有効局プリセットのリストと同様にステータスラインの「ラジオ」を表示する。プリセットがされていない場合、現在調整された周波数だけが表示される。ラジオ局の名前(又は、保存されたプリセットでない場合は周波数)は、LCDの中央右部のバナーにおいてスクロールすることができる。電波を示している動画もまた表示してもよい。ステータスラインにおいて、好ましくは調整された周波数を示す。この種の実施例において、プレーヤ10は、従来のラジオ装置として動作することができる。
好ましい実施態様において、異なるスタイルの仮想局については、ラジオ−タイプ機能性は、同タイプのラジオインターフェースの使用を含む。各バーチャル(仮想)局は、特定のスタイル又はサブスタイルの1又は複数の連続的楽曲を生成する。この「V.Radio」モードにおいて、ユーザは局を選局し、そして、実際のラジオを用いずに、連続楽曲を聞くことができる。この種の装置は、可聴広告、その他の負荷なしで、種々の音楽を聞くことを提供することができ、ユーザにより、演奏される楽曲のスタイルを大幅に制御することが可能となる。このような実施例では、ユーザは、「v.Radio」モードにおいて、「v.Radio」局(好ましくは、特定のスタイル又はサブスタイルの楽曲を演奏している)のリストを提出される。ユーザは、該リストから、チャネルを選び、「Play」を押すことにより、好ましくは「v.Radio」チャネルに同調させる。例えば(例えば、図10を参照)、それは、プレーヤ10に特定の「v.Radio」チャネルに従って歌曲を自動作曲しかつ演奏するのを開始させる。ある実施例において、「v.Radio」は、特定のv.Radioチャネルに伴う特定のスタイル又はサブスタイルのユーザ歌曲を演奏するために制御することができる。そして、それはサブスタイルの特定タイプの自動作曲された歌曲と混在することができる。さらに他の実施例において、1又は複数の「v.Radio」チャネルは、複数のスタイル又はサブスタイルのより多くの楽曲を演奏するように提供される。それはまた、さまざまなスタイル又はサブスタイルのユーザ歌曲と混在することができる。この種の実施例において、ユーザは、プレーヤ10が「同調」するv.Radioチャネルの特定のタイプを選ぶオプションが提供される。その上、ある実施例では、「v.Radio」モードは、好ましくは種々の異なる歌曲フォーマット(例えば、MP3、WAV、WMA、eDJ、その他)を演奏するために用いることができる。
ある実施例において、ラジオ機能の変更例が、ラジオの他の態様を有する「v.Radio」のいくつかの態様を有している。一つの例として、ユーザはラジオ局からの放送を聞くことができる。コマーシャル中断が入って来るときに、プレーヤ10は「v.Radio」に切り替わる。それから、その後、実際の楽曲が放送されたときに、装置がラジオへ切り替えられる。他の統合は、選択可能なインターバルで、ラジオからのニュース情報を「v.Radio」音楽の間に入れるということである。例えば、米国において最も公共のラジオ局は、朝及び午後の間に10分ごとにニュース、天気及び交通情報を扱っている。「v.Radio」は、仮想ラジオとして、そして、適切に選択されたインターバルで動作するように構成することができ、ニュースを流すために一般の局へ切り替える。その後、「v.Radio」モードへ切り替えをすることができる。ユーザがラジオでより多くの制御をすることができるが、まだ受動的に聞いているという点で、これらのバリエーションは、新しいリスニング経験の機能を提供する。本明細書で論じられるように、この種の装置には市販アプリケーションの多数の用途があると考えられる。
特殊機能は、システムメニューからアクセスすることができる。これらの機能は、スマートメディアカード(改名称、削除、コピー、リスト、属性変更)(例えば、図32に関連して、この種のスマートメディア又は記憶媒体の他のフラッシュ/メモリ/ハードディスクタイプの使用が論じられる)、プレーヤ構成(自動演奏、パワーオフ、遅延、キーパッドオートリピート、言語、その他)、ファームウェアップグレード、スマートメディアカードフォーマッティング、マイク設定値及びイコライザユーザプリセット上のファイル管理等を含んでいる。プレーヤは、好ましくはスマートメディアカードに記憶されるファイルのさまざまな属性を変更することができる。予防措置として、デフォルトで、全てのシステムファイルは、読出し専用として好ましくはセットすることができる。
ある実施例において、ユーザコンフィギュレーションインターフェースは、ユーザが取り外し可能なメモリ媒体(例えば、SMC)上の歌曲データとともに記憶される名称を入力し、及び/又はユーザがカスタム等化設定及び/又は音響効果を定めることを可能にする。EQ設定値の実施例として、一群の工場プリセットイコライザ設定値(例えば、フラット(例えば、EQ効果なし)、標準(例えば、より低くてより高い周波数のわずかなブースト)、ウーフ(例えば、低音周波数ブースト)及びハイテク(例えば、高周波数ブースト))からユーザが選ぶことを可能にすることが好ましい。この種の予め設定されたEQ設定値に加えて、ユーザがEQ(例示として、ジョイスティックにより各々の4つの帯域を調整する能力を有する4帯域EQ)のための自分自身の所望の設定値を定めることを可能にすることが好ましい。その上、ある実施例では、ユーザが同様に特定のサンプルのために使用される音響効果をカスタマイズすることを可能にする。この実施例によれば、一組の標準の工場プリセット音響効果(例えば、「低音」;ユーザがより低い音声とともに歌うことを可能にするためにより遅い速度及びより低いピッチを有する歌曲を演奏する)、残響、「高音」(例えば、より速い速度及びより高いピッチを有する歌曲を演奏する)、ドップラ(例えば、「高音」から「低音」まで音声を変化させて)及びウォブラー(例えば、効果を有するいくつかの音声をシミュレーションして))に加えて、レベル及び/又はパラメータ値を変化させることで、標準効果のさまざまな組合せを組み込むことをユーザが利用できる、カスタマイズされた機能を生成することが好ましい。さらに、ある実施例において、追加のフィルタ、及び/又は、例えば、AMラジオ局のイコライゼーション(等化)をシミュレーションする「AMラジオ」効果のために、イコライザを使用することが好ましい。
ユーザが「e DJ」モードにおいて演奏されている歌曲を保存するときに、その歌曲はデフォルト名称(例えば、テクノ001)で好ましくは創作される。歌曲は、システム−ファイルメニューで、好ましくは名前を変えることができる。ファイルメニューに入るときに、スマートメディアカード及び自由なメモリサイズに存在するファイルは、編集画面フォーマットでリストアップされる。ステータスラインは、ファイルの数及びメモリの使用量を示す。ファイル管理メニューは、選択されたファイルに実行するために動作の選択、すなわち、削除、名称変更、コピー、属性変更、その他を提供する。現在のファイルの名称は、ステータスラインに示される。加えて、ある実施例においては、システムパラメータファイルの使用を可能にする。それらのファイルは、例えば、ラジオプリセット(例えば、ラジオ局名及び周波数)、WAV、WMA、MP3、MIDI、カラオケなどのような楽曲ファイルと関連するパラメータ(例えば、ピッチ、テンポ、音量、残響、その他)のための設定値を含む。これらの実施例において、パラメータ設定が全ファイルにあてはまることが好ましい。
コンフィギュレーションメニューに入るとき、編集画面はさまざまな可変なパラメータを示して表示される。図14は、可能な値とともに、コンフィギュレーションメニューによってコンフィギュレーション可能であるいくつかのパラメータを記述する。ファイル名の選択された文字を変更するとき、「Forward」が、強調表示された文字の後ろに挿入するために使用され、「Backward」が、強調表示された文字を削除するために使用される。編集を保存して、ファイルメニューに戻るために、「Play」を使うことができる。
図14に関し、ある実施例では、さまざまなメニューオプションを示すための多数の言語(例えばフランス語、英語、スペイン語、その他)をサポートすることが好ましい。これらの実施例において、データ構造(例えば、メモリにある対照表)の使用が採用される。そして、各々のサポート言語に対する対応する語(又は語セット、句、その他)を定める。このような実施例では、ニューオプションのような項を表示する前に、一組の語の中で示された項として、どの語を中で使用すべきかについて決定するために、所望の言語と関連する変数にアクセスすることが好ましい。さらに、ある実施例で、複数の語をユーザ定義可能/編集可能にすることが望ましい。その結果、ユーザは、特定の項に関連して使うために、システムに対する語を入力することができるモードで、システムを作動させることができる。したがって、語「ドラム」が表示される場合には、これらの実施例では、該語を編集することをユーザに提供して、「ファットビート」又は他の所望の語又は句を表示させることができる。明らかなように、ユーザカスタマイズされたメニュー及び条件用の他の実施例は、想定可能である。
コピーを選ぶと、大きなフォントの行き先ファイルの名称を提案する画面が示される。この名称は、ソースファイルのタイプに基づいて自動的に提供される。たとえば、ソースファイルがヒップホップユーザ歌曲である場合、行き先ファイルの提案される名称は、HIPHO001(あるいは、ユーザは好ましくは行き先ファイルの名称を入力するために上記した名称変更手順を使用することができる)である。
ファームウェアップグレードメニューは、スマートメディアカードに記憶されるファイルから、プレーヤファームウェア(ソフトウェアを埋め込んだ)のアップグレードができるようにする。好ましくは、ファームウェアファイルがスマートメディアカードで利用可能でない場合、アップグレードファームウェアメニューに入ることはできない。この場合、警告メッセージが表示され、そして、プレーヤは、好ましくはシステムメニューに戻る。付加的な実施例において、ブートストラッププログラムの使用により、ファームウェアが取り外し可能な記憶場所(例えばSMC)から更新されることを可能にする。この種のブートストラッププログラムは、また、フラッシュ49に存在するDSP42音響バンクをアップグレードするために用いることができる。
第2図に特定されるプレーヤファンクションキーは、好ましくはCDプレーヤ又はVCRに見られる標準のボタンからなり、歌曲(例えば、プレーヤ所有者、MIDI、WMA、MP3、その他)の再生(演奏)を制御するために用いられる。「Record(記録)」キーは、記録を制御する(例えば、サンプル)。編集又は選択メニューで使われるときに、プレーヤキーはまた、以下の動作を有する。すなわち、「Play(演奏)」は好ましくは、サブメニューを選ぶか又は変更を確認するために使われ、「Stop(停止)」は前のメニューに戻るか、動作をキャンセルするか又は変更を破棄するために使われ、「Forward(送り)」は、リストに項目(アイテム)を挿入するために用いられ、「Reverse(戻り)」はリストの項目を削除するために用いられる。これは装置のキーをいかに最小限の使用とするかの一つの実施例であって、その一方で、比較的大きな一組の特性を保持し、ユーザインターフェースを種々のユーザのために比較的直観的に保つものである。
ある実施例において、ユーザインターフェース制御の1又は複数が速度検出可能である(例えば、ユーザが制御を押圧する速度及び/又は圧力の若干の態様を測定することができる)。例えば、プレーヤ機能キーの1又は複数は、情報のこの種の速度−タイプを検出することができて、それを音響に組み込むことができる。これらの典型的な実施例において、「Play(演奏)」ボタンがサンプルを起動させるために用いられる場合、サンプルの実際の音響に、ボタン押圧に由来する速度−タイプ情報を組み込むことが好ましい。ある実施例では、ボタンが急速に及び/又はより強制的に押圧されるときに、サンプルがより大きく聞こえるということである。他の実施例では、変更された音響効果になるであろう。すなわち、どれだけ強く及び/又は強制的に「制御」が押されるかによって、結果の音響が異なる程度に変調され、フィルタがかけられ、ピッチ変更などがなされたりする。更に詳細に後述するように、楽曲イベントの多くは、MIDI−タイプの(又はMIDI類似の)イベント記述子を含み、したがって、ある実施例では、速度及び/又はDSP(例えば、発生アルゴリズム、その他を介した)へのボタンプッシュの圧力特性を挿入するために、MIDI−タイプ記述子の速度部分(及び/又はボリューム、アフタータッチ、その他)を用いることが好ましい。このようにする代わりに、別々の記述子イベントを使うことができる(例えば、システム特ダネ通報又はMIDI NRPN通報)ことは明らかであろう。
リストが歌曲選択画面で選ばれていると、「Play」を押すことによりリストの第1の歌曲の演奏が開始される。サンプルレーンが選ばれている状態では、「Play」の押圧により、選択されたサンプルを演奏し始めるように構成することができる。楽器レーンの場合には、「Play」の押圧により、現在の楽器の「Solo(独奏)」モード又は「Forced(強制)」モードに入るように構成することができる。
歌曲/サンプルリストを創作するために、歌曲又はサンプル選択画面中で「Forward」を使うことができる。
編集画面を終了するために、編集を取り消して退出すべく「Stop」を用いることができる。例えば、サンプル選択画面で、元の画面に戻るために「Stop」を押す。その上、再生の間のいかなる所定の楽器のためにも、「Stop」を楽器の弱音化/非弱音化のトグルとして使うことができる。
サンプルの記録(好ましくは、サンプルを記録することは、プレーヤのほとんどいかなる動作モードにもおいて可能である)を始めるために、「Record(記録)」を一度、押す。「Record」は、記録を終えるために再度押圧される(格納されたサンプルファイルの規模がプログラム可能なサイズ(例えば、500Kbytes)を超える場合、記録は自動的に止められる)。記録ソースは、動作モードに従い、自動的に好ましくは選択される。楽曲が演奏されていない場合、記録ソースは作動中のマイク(例えば、ローカルか、又は、外部ドッキング局に組み込まれるかのいずれかで)である。楽曲が歌曲、e.DJ又はラジオを演奏している場合、ミューティングされていない場合には、記録ソースは好ましくは音楽及びマイク入力の混合である。更に、サイズ/性能オプションの範囲を併せて提供するフォーマットを記録している異なるサンプルを使用することが可能である。例えば、非常に高品質サンプル符号化フォーマットは、より多くのスペースを記憶媒体上に必要とする。その一方で、比較的低品質な符号化フォーマットはより少ないスペースですむ。また、異なるフォーマットは、特定の楽曲のスタイル等により適することができる。
ある実施例においては、サンプル編集モードをサポートすることが好ましい。これらの場合、サンプル編集モードは、選択されたサンプルを編集するために、ユーザによって使用される。選択されたサンプルは表示され(例えば、LCD20上の簡略波形表示として)、ユーザは、サンプルの開始点及び終了点を選ぶことが可能である。好ましくは、この種のグラフィッククリッピング機能は、ユーザに、例えば、不所望の部分等を取り除くために、選択されたサンプルを容易に切り取ることを可能にする。サンプルをクリップ/切り取った後に、ユーザに対して、例えば、新しい名称をつけた、新しく短くなるサンプルファイルを保存するオプションが示される。明らかに、LCD20を使用して、選択されたサンプルの波形のグラフィックバージョンを提供し、かつ、エンドユーザに、選択されたサンプル上で基本操作を実行する単純な方法を提供するために、この種のクリッピングに加えて他の類似した編集型機能をサポートすることができる。
「v−Radio」モードにおいて、選択された局からのものを聞くために、「Play」を使うことができる。ラジオを消すためには、「Play」を押す。プリセット選択画面の局に戻るために、「Stop」を押す。帯域が上の次の局の自動検索をするために、検索が始まるまで、「Forward」を押す。下部帯域の次の局の自動検索をするために、検索が始まるまで、「Return」を押す。50kHzの刻みで上下微調整するために、「Forward」/「Return」を押す。「eDJ」モードにおいて、サンプルレーンの間、「Play」が選択されたサンプルを演奏するよう押される。上記したように、ある実施例において、特定のボタン押圧の速度又は圧力を検出して、結果として生じる音響(例えば、サンプル演奏イベントにおいては、好ましくは、サンプル音響の音量、アフタータッチ、ピッチ、効果、その他を調整して)に、検出情報を伝えることが好ましい。サンプル再生が以前にできなかった場合、最初の「Play」押圧が再生を再度可能にする。次の押圧により、選択されたサンプルを演奏する。サンプルが演奏されている場合、「Stop」がその演奏を止める。サンプルが演奏されていない場合、「Stop」を押すことにより、サンプル(すなわち、I−Wayモードに戻るときに、eDJによってサンプルの自動再生を抑制する)をミューティングする。ミューティング状態のとき、「Muted」がステータスバーに表示され、丸いスピーカがI−Wayサンプルレーンから消える。
「Song(歌曲)」モードにおいて、選択された歌曲又は演奏リストの再生を起動するために、「Play」を押し、LCDが演奏歌曲画面を表示する。「歌曲」モードにおいて、「Stop」により楽曲を止め、歌曲選択画面に戻ることができる。次の歌曲へ行くために「Forward」をわずかの間押圧する(演奏リストのものを演奏する場合、リストの次の歌曲へ行くが、そうでなければ、スマートメディア上の次の歌曲へ行く)。歌曲を早送りするために、「Forward」を連続的に押圧する。歌曲の先頭に戻るために「Backward」をわずかの間押し、2回目の押圧により前の歌曲に戻る(演奏リストのものを演奏する場合、リスト中の前の歌曲へ行き、そうでなければ、スマートメディア上の前の歌曲へ行く)。歌曲において早戻しをするために、「Backward」を連続的に押す。
「Stop」を押圧することにより、楽器/レーンのミューティングを切り換えることができる。例えば、ドラムレーン上で、一時的に「Stop」を押圧することにより、ドラムの音を消すことができる、そして、一時的に再びそれを押圧することによりドラム音を戻すことができる。その上、比較的長い期間(例えば1秒程度)「Stop」を押圧することにより、楽曲演奏を止めてスタイル選択画面に戻るように構成することができる。
「Forward」は、新曲を起動するように構成することができる。「Backward」は、現在の歌曲を再度演奏するために用いることができる。
「Forward」又は「Backward」は、同じパターンを保つために用いることができるが、演奏されている(好ましくは「コンパティブル(互換)」楽器だけが選択されて、プレーヤによって演奏される)楽器を変更することができる。
マイクをミューティングするために、MICレーン又はトンネル内で「Stop」を押す。マイクをミューティング状態から復帰させるために「Play」を押す。
選択されたサンプルの再生を起動するために、好ましくは、「Play」を押す。サンプルの再生を止めて、サンプル選択画面戻るために、「Stop」を押す。
「歌曲」モードにおいて、楽曲を一時停止するために好ましくは「Play」を押す。再生をもう一度再開するために、「Play」を押す。歌曲選択画面で「Foward」キーを押すことにより、新しい「Play」リストを生成する。歌曲選択画面において、元の画面に戻るために、「Stop」を押す。
スタイル選択画面において、元の画面に戻るために、「Stop」を押す。
強調表示されたファイルのためのファイル管理メニューを入力するために、「Play」を押す。
ファイル管理リストを閲覧しながら次のページまでスクロールするために「Foward」を押す。前ページをスクロールするために「Backward」を押す。
ファイル管理メニューにおいて、選択された動作を起動するために「Play」を押す。
「Delete」を選ぶと、確認画面が表示される。
「Rename(名称変更)」を選ぶと、大きいフォントのファイルの名前を示している画面が表示され、最初の文字が選ばれて点滅する。
ファイルをコピーするときに、コピーを確認するために、「Play」を押す。ソースファイルとしての同一タイプのファイルが同じ名称で存在する場合、確認画面はファイルが上書きされなければならないかどうか質問する。YES又はNoを選び、確認するために「Play」を押す。コピーを中止して、ファイルメニューに戻るためには、「Stop」を押す。MP36RAMを用いて一つの取り外し可能なメモリ格納場所(例えばSMC)から別のファイルがコピーされるようにすることは、この実施例の好ましい特徴である。この例では、ひとつのSMCから他に、コンパニオンPCソフトウェアプログラムを使用せずに、個別の歌曲又はシステムファイルをコピーできるようにすることが望ましいが、取り外し可能なメモリ格納量(例えば、特定のSMCの全てのコンテンツ)がすべてコピーされることになっている場合には、より大きいデータ群がPCへのUSB接続によって一時的にバッファ記憶される(PC資源を使用して)ことを許容するために、コンパニオンPCソフトウェアプログラムを使用することが望ましい。SMCターゲット及びソース量を繰り返して交換しているユーザを含むので、この種の特徴はPCシステム(例えば、MP36内蔵のRAMを使用して)の無い実施例においては、可能でない。
図3に示されるeDJ、v−Radio、歌曲、サンプル及びシステムの直接アクセスキーは、ユーザが他の任意のモード内からも直接所望のモードに入ることを許容する。これらのキーは、また、現在のモードを含む任意のモードも停止するために用いられる。これは「Stop」キーよりも高速で行うことができる。その理由は、次の通りである。すなわち、場合によっては、例えば、レーン内部のeDJモードにおいて、「Stop」キーが好ましくはeDJモードを止めるよりむしろ、レーンをミューティングするために使うことができるからである。
オーディオ出力制御は、Vol.Up/Downとして図1に示される。事前に固定されたキーと組み合わせて使われるときに、オーディオ出力コントロールキーはまた、マイク入力を制御するために用いられる。
Up/Down/Left/Rightキーは、以下のために使われ得るジョイスティックからなる。すなわち、メニューナビゲーション、歌曲又は楽曲スタイル選択及び楽曲を演奏することに関するリアルタイム会話である。加えて、Up/Downが直観的な方法で地下及びI−Wayモードのようなモード間で移動するために、使用することができる。
リストを編集するとき、強調表示された対象物の後に対象物を挿入するために「Foward」を押し、対象物を削除するために「Backward」を押す。これにより、挿入又は削除が実行される。
リストを閲覧するか又はパラメータを選ぶために、Up/Downを使用する。強調表示された対象物を編集するために、「Right」を押す。リストの第1番目の項目へ直接行くために、「Left」を押す。
楽器トンネルにおいて(すなわち、ドラム、バス、リフ、及びリード)、「Right」は新しい楽曲パターンを作曲するように構成することができる。同様に、「Left」は、前のパターン(楽曲パターンに関する下記の注を参照)に戻るために用いることができる。新規なパターンは、楽曲に同期して、現在の楽曲シーケンス(例えば、2小節)終了後、演奏し始めることができる。ところで、「Composing(作曲中)」のメッセージは、ステータスラインに現れるようにすることができる。その上、Downキーは、パターン番号を増分することのない新規な楽曲パターンを構成するために用いることができる。パターン番号が増分されない場合を除いて、「Right」(他のパターンを作曲生成して、演奏する)と同じ効果を有する。、
これら構成の特徴の利点は、生演奏の間に、ユーザがパターンを変更することを可能にするということである。明らかなように、この特徴を採用することの他の理由は、ユーザが容易に入れ替えることができる一連のパターンを組み立てることができるということである。新しく作曲されたパターンが他ほど望ましくないことを見出すだけのためにキーを押した後、ユーザは「Down」キーを選択し、そのパターンを廃棄して、別のものを作曲することができる。望ましいパターンを発見すると、即座に、ユーザは、その後に、望ましいパターンの間を行ったり来たりするために、「Right」及び「Left」キーを使用することができる。その上、この特徴によって、システムがパターンを保存するための有効メモリを最適に利用することができる。ユーザがあまり望ましくないパターンを廃棄することができることによって、利用可能な資源を、より望ましいパターンを格納するために用いることができる。
ファイル管理メニューにおいて、所望の動作を選ぶために、Up/Downを使用する。ファイルの名称を変えるとき、ユーザは、変更すべき文字を選択するためにLeft/Rightを用いることができ、選択された文字を変更するためにUp/Downを使用することができる。最後の文字が選ばれたとき、Rightを押すことにより、新しい文字を追加する。ユーザはまた、文字を挿入/削除するために、Forward/Backwardプレーヤ機能キーを使用することができる。
マイクトンネルにおいて、Left/Rightはマイク入力左/右バランスをするように構成することができる。サンプルトンネルにおいて、Left/Rightはサンプルを選ぶために用いることができる。サンプル選択画面で「Foward」を押すことにより、新しいサンプルリストを創作する。
Downは、現在のI−Wayモードレーンに代わって地下モードに入る直観的な方法の例である。このモードにおいて、ユーザは選択された楽器(ドラム、バス、リフ又はリード)によって演奏されるパターンを変更することができ、デジタル効果を加えることができる。同様に、Upにより、地下モードから楽曲I−Wayに戻るように構成することができる。
V−Radioモードにおいて、所望の局をプリセットで選ぶために、Up/Downを使用する。プリセットリスト中の前局/次局へ行くためにUp/Downを用い、局からのものが演奏中に、プリセットリスト中に局を記憶するために、Save/Editを押す。Save/Editキーは、現在の歌曲を後で再生することができるユーザ歌曲として保存するために用いることができる。この種の歌曲は、二次記憶場所(例えば、スマートメディアカード)に保存することができる。あるプレーヤの実施例の場合、eDJ歌曲が演奏する間、その歌曲を生成した「seed(シード)」のみとしていつでも行い得る。その歌曲は、ユーザ歌曲として再生されるときに、同じ歌曲を再生成することができるように格納される。ある実施例においては、自動的に変更されたファイルを新規なファイル(例えば、同じ名称で、しかし、異なる接尾辞を有する)として保存する保存ルーチンを組み込むことが好ましい。この種の特徴は、自動的にファイルの以前のバージョンを保持するために用いることができる。
シードの使用がこの開示の他の箇所で論じられるが、Save/Edit17キーの使用について類推を行うことはこの点で有用であろう。このキーは、非常にコンパクトなやり方で歌曲の基本パラメータを保存するために用いられる。このことは、DNAシーケンスが生体系のパラメータを含む方法と類似している。シードは、完成された歌曲の情報と比較して、ごくわずかなスペースしか占有しない、しかし、それらは最終的な歌曲を定義する。保存されたシードの同じ組が与えられれば、本発明のプレーヤアルゴリズムは、楽曲の正確な同じシーケンスを生成することができる。実際の楽曲がこの例では記憶されないが(Save/Edit 17キーの使用により)楽曲を造っている基本ブロックは非常に効率的に記憶される。この種の方法は、比較的限られた資源を備えるシステム(例えば、比較的低いコスト/低い性能のプロセッサ及び限られたメモリを備えるシステム)において有効である。楽曲を格納する反復性のある、それでいて極めてコンパクトなこの種の方法は、また、他の実施例において採用可能である。それは、例えば、比較的幅が狭い帯域伝送路(例えばインターネットへの56kbpsのモデムリンク又は他の装置へのリンクのiRDA/bluetoothタイプ)を介して他のシステムとの通信を含む。明らかに、この特徴は、システム間の他の比較的低帯域幅接続を同様に使用して、好適に使用することができる。その上、この特徴によって、ユーザが所定格納容量により多くのデータファイル(例えば、歌曲)を格納することができ、他の利点の中でも、この効率は他の好ましい特徴(上記したように、新規ファイルとしての変更されたファイルの自動保存等の特徴)である。
ある実施例において、取り外し可能なメモリボリュームが挿入されない場合、及び/又は、挿入された取り外し可能なメモリボリューム上に利用可能な記憶が充分でない場合、ユーザ歌曲インスタンスを保護するために取り外し可能なメモリインターフェース(例えば、SMC40を伴うSMCインターフェース)が利用できる資源をチェックすることが望ましい。これらの場合、ユーザが歌曲を保存するとき(例えば、Save/Editキー17のボタンを押したとき)に、ユーザが付加取り外し可能なメモリボリュームを挿入することは、有利である。
再生のために、後でこの歌曲(ファイルとして)を選ぶことが可能であるようするために、歌曲の名称は、一時的にステータスラインにおいて表示される。もちろん、ユーザがそうすることを望む場合、歌曲ファイル名は後ほど変更することができる。一旦項目が作成されると、作成された項目を、歌曲又はサンプル選択画面において選び、Save/Editキーを押すことによって編集することができる。Save/Editキーを再び押すことにより、編集された項目を保存する。On/Offキーが2秒以上間押圧されると、プレーヤがオン又はオフされるように構成することができ、この組合せが短く押圧されるときには、On/Offキーは、代わりにLCDバックライトをオン又はオフするように構成することができる。
Pitch/TempoキーがLeft又はRighキーと同時に押圧されると、それが楽曲のテンポを制御するために組合せとして使うことができる。Pitch/TempoキーがUp/Downキーと同時に押圧されるとき、それはマイク入力、楽曲、その他のピッチを制御することができる。
Effects/FiltersキーがLeft/Right又はUp/Downキーと同時に押圧されるとき、所定の楽器、マイク入力、又はサンプルに加えられる効果(例えば、遮断周波数又は共振)及び/又は、音量(ミュートを含んで)を制御できる。
当業者が理解できるように、他の関連した組合せは、装置の作業性を損なうことのない付加機能を提供する線に沿って、そして、本発明の趣旨及び範囲から逸脱することなく、使用することができる。
楽曲を構成するための本発明のさまざまな好ましい実施態様を説明する。新曲のために、唯一必要なユーザ入力は入力スタイルである。スタイル自体を疑似ランダムに選ばせる自動演奏機能が可能にされるときには、入力スタイルさえ必要でない。しかし、ユーザが特定のスタイルを選びたいときには、歌曲生成を開始するためにその入力だけが必要とされる。
実際の生成プロセスそれ自体に移る前に、ユーザのスタイル選択に必要なものがスタイル及びサブスタイルであるということが重要である。すなわち、本発明のある実施例では、スタイルは類似したサブスタイルから成るカテゴリである。これらの場合、ユーザがスタイルを選ぶとき、本実施例はサブスタイルの各種取り合わせから疑似ランダムに選択する。その上、その替わりに、より優れた制御のために、ユーザが特定のサブスタイルを選ぶことも可能である。これらの具体例において、ユーザがスタイル又はサブスタイルを選ぶ場合、その選択結果は、スタイル及びサブスタイルの両方が歌曲生成ルーチンに入力として使うことができるということである。ユーザがサブスタイルを選ぶとき、スタイルは絶対的に利用できる。ユーザがスタイルを選ぶとき、サブスタイルは疑似ランダムに選ばれる。これらの場合、両方のパラメータは、最終的な歌曲の付加的変更を許容すべく、歌曲生成プロセスの間に利用可能である。
図15に示すように、歌曲は一連のパートから成る。各パートは、イントロ、テーマ、コーラス、ブリッジ、エンディング、その他である。そして、異なるパートは、繰り返すことができるか又は歌曲の後に戻ることができる。例えば、一連のパートは、イントロ、テーマ、コーラス、テーマ、コーラス、テーマ、コーラス、エンディングである。あるスタイルスは特別なタイプのパートを有することができる、そして、他のスタイルスは利用可能パートのサブセットだけを使用することができる。これは、特定のスタイル又はサブスタイル用の所望の特性に依存する。例えば、「cool(クール)」スタイルは、ブリッジパートを使用することができない。さらに、通常より速いテンポを有するスタイルスは、各パートを単純に二倍化する(すなわち、イントロ、テーマ、テーマ、コーラス、コーラス、テーマ、テーマ、コーラス、コーラス、その他)ことにより、実質的に2倍にされたパートサイズを使用することができる。
また、ある場合、ユーザは、特定のパートのために更新された表示を有することにより、利益を得ることができる。例えば、歌曲の全長の範囲内の現在の位置の指示は、ユーザに役立つであろう。他の実施例は、エンディングパートの間、歌曲が終了しつつあるという警報をユーザに出すことである。この種の警報は、ディスプレイのある部分でメッセージ(すなわち、「エンディング」)を発光させることを含み、歌曲の保存を望む場合に、それを今保存すべきことをユーザに思い出させる。このレベルの他の最適化は、パート毎で保存されるべき歌曲の対話的生成の間、ユーザによってなされる変更を許容する。これは、ユーザが楽器タイプ、効果、音量又はフィルタ等に対して変更をし、その修正された特性をそのパートが使われる時毎に使うことを許容する。例えば、これは、ユーザがコーラスに若干の変更を与えたならば、コーラスの次の発生がその変更された特性を含むことを意味する。この特定の実施例にしたがって、その歌曲の他のパートはデフォルト特性を含む。あるいは、特性変更態様は、多数のパートに適用することができるか、又は、歌曲の長さ全体にわたってリアルタイムで保存することができる。これについては、後述する。
各パートは、異なる長さであって、一連のサブパートから構成することができる。好ましい実施例の一態様は図15に示されるサブパートレベルを含む。しかし、パート構造がサブパートレベルを介在することなしにシーケンスによって直接構成されることができ、この点で、サブパートレベルの使用は任意である。
ある実施例において、サブパートレイヤーが実行される場合、各サブパートは異なるサイズであってもよい。それがパートにある程度の多様性を与えるので、この種の方法は、結果として生じる作曲の感触を強めることができる。
各サブパートは、一連のシーケンス(SEQ)から成る。一貫したサイジングとルール適用の柔軟性との関係に関する前述のコメントにより、各SEQは、同じ長さ及び拍子記号である。図15の実施例において、各SEQは4/4拍子記号をもつ2楽節の長さである。もちろん、これらは本発明のある変形において調整することができるが、この例のこの装置は良好に動作する。その理由は、測定境界を越えて音符(ノート)をどのように保持できるかを示すことができるからである。楽曲により大きな多様性を許容するためにSEQ(以下に論じられるRPと同様に)のサイズを長くすることは有利である。図15と同様に、この種の変形も本発明の範囲内である。
図15の実施例にしたがえば、各SEQは、平行する多数の「実際のパターン」(RP)のみから成る。通常、楽器の各々のタイプに一つのRPを有することは有用である。この場合、あるタイプの楽器は、I−Wayユーザインターフェース(すなわちドラム、バス、リフ、その他)の単一レーンと一致する。RPデータは、実際の音符(ノート)データである。通常、ユーザ対話を通じて、そして、そのような対話が多数の楽器に適用されない限り、このレベルでの情報は移行(transpose)されない。もちろん、これはユーザインターフェースの決定であって、ここで論じられる実施例への制限ではない。
この場合、多数のRPは、SEQを構成するために一緒に併合される。当業者によって認識されるように、これは、最新技術のMIDIシーケンサがMIDI Type 1情報の多数のセットをMIDI Type 0ファイルに併合する方法に類似している。
これに関する更なる背景詳細は、「一般のMIDIレベル2仕様」(MIDI製造者連合から入手可能)において見出すことができ、本願明細書に引用したものとする。
SEQを定めるために平行に多数のRPを許容することの一つの理由は、ある時間に、I−Way上のあるレーンが多数のRPの使用から利益を得ることができるということである。このことは、歌曲の間、異なる時間に、特定の楽曲の特性を変化させることが望ましい場合があることにある。例えば、リードはコーラス及び独奏の間、異なっていてもよい。この場合、楽器タイプ、グループ、フィルタリング、残響、音量、その他を変化させることが望ましい場合がある。そして、この種の変化は、多数のRPの使用によって実現することができる。その上、この方法は、演奏の間に楽器を加え/排除するために用いることができる。もちろん、これは、この種の変化を取り込む唯一の方法ではなく、多数のRPの唯一の使い方でもない。
図15の実施例にしたがえば、各RPは、2小節から成り、RPx及びRpyに分けられる。この種の2小節構造は、MIDI情報(コード変更、サステイン、その他)の若干の変化を内部小節境界にまたがって許容するので、有用である。この種の変化は、コード変更を小節内におこす複雑さ生じることなく、あるいは、多数のRPの中で持続される音符をもつことなしに、楽曲変化の効果を提供することができる。
通常、多数のRPにわたって音符保持することを許容するのは扱いにくい。これは、音符を保持するために、パターンの終わりで「音符オフ」制御信号のマスキングを必要としたり、そして、次のパターンの始めで「音符オン」制御信号のマスキングを必要とする点で、ある程度MIDI特性によるからである。また、コードを切替えるときに、パターン境界にまたがって同じ音符を保持することは、パターンの終わりがコード進行を通じて循環する機会であるので、重要である。そして、保持されている古い音符が新しいコードと互換性を持つことを確める必要がある。コード進行情報の生成及び併合は、本説明の能動性と平行して生じ、以下に更に詳細に論じられる。通常、複数のパターンにわたって音符を保持することは望ましくないとみなされるが、例外がある。
長いMIDIイベントがいくつかのパターンを通じてフィルターをかけられるとき、多数のパターンにわたる開放音の音符を有する潜在的に有益な拍子の一つの実施例はテクノスタイルにあり、本願明細書において、「pad(パッド)」と呼ばれている。この実施例を扱うひとつの方法は、現在のSEQが、パッドの始めか、中間か、終わりかどうか調べるために、パッドシーケンス表示フラグを使用することである。そして、パッドのためのMIDI音符オフが始めにはなく、次のRPの初めにおいてMIDI音符オンがなく、適切なMIDI音符オフが終わりにくるように、パッドトラックのMIDIイベントを変更することができる。
図15に関して説明を続けると、RPは、それらに適用される楽曲のルールを有したバーチャルパターン(VP)から成る。楽曲のルールは、更に詳細に後述するコード進行情報の生成と併合の一部である。一般の若干のピッチ情報に加えて、VPは対応するRPのリズムであるとして、一般に考えることができる。好ましくは、楽曲のルールはVPに適用され、その結果がRPとなる。楽曲のルールは、更に詳細に以下で論じられる。
VPは、一連のブロックと考えることができる。図15の実施例において、各ブロックは、二次元(ブロックd及びブロックfx)を有するが、これは、一つの可能な例でしかない。この例では、ブロックdはブロックのデータと一致し、そして、ブロックfxはそのデータに適用される効果(すなわち、音量、フィルタリング、その他)と一致する。この例では、ブロックdの情報は、種々のありうる周期的ブロック(この種の周期的ブロックを生成するための望ましい方法、及びVPを創作する際のそれに対応する選択は、図22及び図23に関連して本明細書において後述される)から選択された個々の周期的パターン情報ブロックとして考えることができる。
図15に記載されているブロックfxの次元は、ブロックd情報にある特性を追加するための任意である。例えば、上述した音量又はフィルタリング情報に加えて、ブロックdの次元が音楽の情報予測手段(「バーチャル音符」又は「コントローラ(VNC)」情報として、以下により詳細に論じられる)の割当て又は分布のために使うことができる。しかしながら、ブロックfxの次元は任意であり、そして、卓越した結果を得るために、ブロックdの情報は、この種の音量又はフィルタリング情報とは別個に処理することができる。
拍子記号が4/4で、RPが2小節である上記実施例を仮定すると、パターン中の全てのブロックは期間中に最高8つの四分音符を加えなければならない。この例では、特定のRPのnブロックを仮定すると、対応するVPの各ブロックの四分音符の持続期間は、1と(8−{n−1})の間である。この実施例は、ブロック長の基本単位である四分音符をもつ4/4時間を記述しているが、本実施例の簡単な変形は、代替拍子記号及びブロックの代替基本単位(すなわち、13/16拍子記号及び第32音符のそれぞれ、その他)を含むであろう。
図15の下部を見ると、サブブロック(SB)のオプション実施を理解できるであろう。例えば、大太鼓、シンバル、小太鼓、その他のための別々のSBを有することが望ましい場合には、あるスタイルの間のI−Wayのドラムレーンのために、この種の実施態様を用いることができる。本実施例の実現の更なる最適化は、ドラムレーンのSBレベルにドラムレーンのVP直接構成させることであろう。この種の装置は、効果的にドラムレーンの個々のSBのための別々のブロックfxを有する複雑さを取り除く。本発明を実現する際にこの種の最適化が役立つ実施例は、限られた資源、すなわち、ドラム(小太鼓、大太鼓、その他)の別々のパートのための別々の効果を有することが望ましくない環境における実施例である。
さらに、本発明のあるアプリケーションにおいて、図15のあるレベルがバイパスされるようにすることが望まれることがある。そのような場合、これによって、ユーザが実際の音符情報(例えば、入力としてのMIDI楽器を経た歌曲の間のリアルタイムの情報)の形で、本当のパターンデータを入力することができる。更に、ポケットサイズPCソフトウェアプリケーション(及び、PCへの接続)を用いて、ある実施例では、ブロックデータとしての用途の自身のMIDIパターンを入力することを、ユーザに許容できるようにすることが好ましい。
本発明の歌曲の作成において使用する楽曲ルールの好ましい方法のさまざまな実施例を説明する。
図16Aは、本発明に関連して楽曲を生成する好ましい方法の一般的な概要を表している系統線図である。ステップ1で起動し、楽曲のスタイル及び選択された楽器が定められるか又はロードされる。一旦楽曲のスタイル及び楽器のタイプが既知となると、アルゴリズムは個々のバーチャルパターンサブブロック(例えば、図22に示される)を展開するために、ブロックルールを適用することができる。別の実施例においては、個々のバーチャルパターンサブブロックは、リスト又は他のデータ構造から選ばれる。
好ましい本実施例において、サブブロックデータは、楽曲生成のアルゴリズム処理の間、必要に応じて創作される。図16Bは、図16A(ステップ1)の代替実施を例示する。
図16Bにおいて示したように、ステップ1aにおける、スタイル及び楽器に関連したデータは、互換リズムイベントを創作するアルゴリズムのルーチンへの入力である。一つの例として、「第1の最大%」パラメータが、リズムイベントがどれくらいの頻度で小節/楽節の最初の拍子で起こるかを示すための入力として、使われる。比較的高い最初の最大パーセントは、選択された楽器が、選択されたスタイルの小節又は楽節の始まりで通常音符を鳴らすことを示すことができ、比較的低い最初の最大パーセントは、選択された楽器が、選択されたスタイルの小節又は楽節の始まりで通常音符を鳴らさないことを示すことができる。別の例として、「解像度グリッド」パラメータが、所与の楽器及びスタイルのリズムイベントの典型的位置を示すために、入力として使うことができる。「解像度グリッド」は、小太鼓楽器がロックスタイル用の4拍子の小節の第2と第4拍子目に鳴ることを示すことができる。別の例として、「鼓動最小/最大」パラメータが楽曲の特定のスタイルのために望まれるテンポの範囲を示すための入力として使うことができる。多くの他の入力パラメータが、本発明と整合した方法で使うことができ、ここで論じた実施例では、所与の楽器及びスタイルのための一組のリズムイベントを組み立てることが特徴である。アルゴリズムの実施例では、リズムイベントは、音符イベントが始まる時点である。好ましくは、持続時間、速度等の音符の他の態様は、まだ未決定の状態である。
図16Bに示されるように、ステップ1bでは、リズムイベント(例えば、音符起動イベント)がスタイル及び楽器パラメータ入力に基づいてアルゴリズム的に生成された後、アルゴリズムは持続期間をリズムルールを使用しているリズムイベントに割り当てる。好ましくは、リズムルールは、付加スタイル及び/又は、例として、「無音%」、「コード%」、「コード持続期間感度%」、「コード速度感度%」、「速度アクセント」、「動的速度」、及び/又は、「擬人化」のような楽器パラメータを使用しているステップ1aで生成されるリズムイベントに作用する。「無音%」は、楽器が無音であるときに、ある小節(又は他の楽節)の間の音符長のパーセントを示すために用いることができ、比較的高い数値は、比較的長い音符持続期間を表す等の結果となる。「コード%」は、コード一部として起こる音符のパーセントを示すために用いられる。「コード持続期間感度%」は、あるコードにおけるいくつかの音符が他のものより長い持続期間を有することができるかどうか等の、単一コードの多数の音符の停止時間の結合性の程度を示すために用いられる。「コード速度感度%」は、コードの一部として起こる多数の音符の速度(例えば、音量)の結合性の程度を示すために用いられる。「速度アクセント」を、アルゴリズムにアクセントの位置を示すためにパラメータとして使うことができ、例えば、レゲエスタイルのベースギターがアップビートにアクセントをつけることを示すために用いられる。同様に、「動的速度」は、アクセントが生じる程度を示すために用いられ、アクセントの比較的高い程度は、所定の楽器の他の楽曲イベントと比較するとき、アクセントに起こる楽曲イベントの比較的高速度(例えば、音量)の結果となる。「擬人化」が、リズムイベントのある程度の不ルール性を示すためのパラメータとして使うことができる。これらは、持続期間をリズムイベントに好適に割り当てるために用いられるパラメータの実施例である。本発明の利点を達成しながら、他のパラメータをその実行に応じて置換することができるか又は追加することができる。このステップの結果、図16Aのような図と関連して論じられた方法で処理することができるバーチャルパターンサブブロックデータを生成することになる。
図16Aを参照すると、一旦サブブロックが利用できる(例えば、リストから又は1ブロック支配アルゴリズムから)ようになると、それらはステップ2でバーチャルパターン(VP)に処理される。この例では、この点で、VPは楽曲でない。但し、それはリズム情報、及び、他の組み込み楽曲特性を含む。VPデータ構造の埋め込み楽曲特性を用いるステップ3において、楽曲ルールは、より多くの音楽的才能をパターンに加えるためにVPに適用される、その結果、実際の音楽の情報と同様に、VPのリズム情報を含む。ステップ4において、各々の小節がコード進行をデータ構造に与えるために主音アルゴリズムによって音楽的に移行されるという点で、主音がステップ3から出る出力に適用される。ステップ5において、特定の楽曲モードに設定される楽曲情報を出力するために、微妙な変化を楽曲情報に実行するモードが適用される。それから、ステップ6において、キーの変化を許容し、及び/又は、データ構造及び/又はさまざまな歌曲構成要素の中のキー整合性を許容するように、キーが適用される。最後に、ステップ7で、歌曲演奏の間、リアルタイムのピッチ/テンポシフトを許容するために、他の歌構成要素に加えて、グローバルピッチ調整がデータ構造に適用される。
RPを生成するためにさまざまな楽曲ルールを適用するこの過程は、図15と関連して前述の全体的な歌曲生成プロセスの一部である。更に詳細に図16Aに記載されているステップを行う前での、前述の組み込み特性、同じく主音のいくらかの言及及びキー理論に関する議論は有用である。
MIDI仕様がデジタル的に楽曲を示す簡潔な方法を提供し、そして、今論じられた楽曲ルールからの出力データの一つの重要な行き先が、MIDIデジタル信号処理装置であることを心に留め、本発明者はMIDI言語とのなんらかの類似点があるデータフォーマットを使用することが、ある実施例において有利であることを見出した。後の説明において、各ステップで使うことができるデータの若干の実施例とともに、図16Aのステップの説明を行う。記載されているデータフォーマットがMIDIと類似している一方、差を理解することが重要である。基本的に、本説明は、MIDIに対応するデータストリームにおいて、どのような付加的なコンテキスト仕様の意味を組み込むかを説明する。図16Aにおける各ステップの処理の間、組み込まれた意味要素が抽出され、そして、それに応じて、そのストリームが若干の楽曲進行において変更される。このように、この過程を考慮する手段は、各ステップで、ストリームがMIDI DSP(この態様は、図21に関して、以下で更に詳細に説明される)によって演奏される実際のMIDIストリームに、より近くなる。
本実施例において、楽曲に含まれれるリズム及び楽曲情報を「バーチャル音符」及び/又は「コントローラ」(VNC)に分解することが有利であると考えられる。図17の実施例において、VNCのいくつかの有益な例が提供される。基本的には、これらのVNCは、特定のジャンルの楽曲ルールを、簡素化された機構に分解する方法を示している。該簡素化された機構は、そのジャンルの他のオリジナル曲の特性及びバラエティ(変更)とともに新しい楽曲を生成するために、ランダムな態様に沿ってアルゴリズムによって使用することが可能である。楽曲のスタイルに従い、VNCの異なるタイプを有効に用いることができる。図17のリストは、詳細に後述する2、3の実施例を簡単に提供するものである。
本発明の本態様の重要な特徴は、アルゴリズムによって引き出されるリズムデータの基本ブロックに、楽曲生成アルゴリズムのための制御情報を組み込んだということである。本発明により、アルゴリズム及び最終的楽曲出力の双方において、多様性、アップグレード性及び複雑さを許容する非常に効率的な方法でこれを成し遂げた。これのキーとなる態様は、本発明において、リズムデータの基本ブロックを示すためにMIDI−タイプフォーマットを使用するということであり、このようにして、持続期間、音量、タイミング、その他の制御を可能にする。さらに、本発明においては、どのように楽曲の部分を創作すべきかをアルゴリズムに知らせるVNCデータを組み込むために、これらの基本ブロックのMIDI−タイプフォーマットの異なった模擬部分を使用することができる。例示として、アルゴリズムに、そのMIDI−タイプイベントに関連して、どんなVNCを呼び出すべきかについて指示するために、リズムデータのこれらの基本サブブロックの各MIDI−タイプイベントのピッチを使用することができる。このようにして、このリズムデータがアルゴリズムによってアクセスされるとき、ピッチタイプデータが特定のVNCと認識されて、VNC機能に対応する実際のピッチ情報と置き換えられる。図17は、第1カラムにおいて、この種の組み込み値の例を示し、そして、第2及び第3カラムでは、認識されたVNC命名法の例及びそれに関連する潜在的ピッチ情報を示す。
第17図の実施例において、VNCの基本タイプは、「低音符(Base Note)」である。例えば、これらの音符が一回の実行で、比較的短い音符であるときを除いて、これはメロディの基礎としてある楽曲のスタイルで考慮される。このようなわけで、リズムはVNCに前後関係を提供するためにVPの中に存在する。「低音符」の値の例は、C,E,G又はBである。どの値が最終的に使われるかは、アルゴリズムの一部としての疑似ランダムシードに依存する。本発明においては、これらの実施例において、これらの値が非常に良い楽曲を、これまで研究してきたジャンルに提供することを見出した。マジック音符(マジックノート)は図17(全音階が使われる場合)に示す値を有することができ、これらの値は、先行する「低音符」に対して相対的である。「低音符」と異なって、マジック音符は、メロディに強烈に影響を与えない音符を提供する点で好ましくは有益である。例えば、アルゴリズムは、生成される次の音符がマジック音符1であるということを理解し、そして、可能な値+1, −1, +2, −2の一つを予測された通り選択するために、「擬似ランダム番号シード」を使用することができる。予測通りに選択された値は、先行する「低音符」からの値を数学的に調整して、結果としてある音符値になるように用いられる。この実施例によれば、先行する「低音符」がC2で、アルゴリズムの結果が+1を選択するものである場合、マジック音符値はD2である。マジック音符0及び1の間の唯一の差がマジック音符0が0値を有することができるという点に注意すべきである。このように、マジック音符0の使用は、時として、先行する「低音符」と同一の値である音符に結果としてなる。これは、比較的微妙な方法において特定のスタイルの音響に影響を及ぼす方法の例である。
上記説明において、「予測通り選択された」ことによって、シード値に基づいて結果を擬似ランダムに選ぶ方法を参照する。シード値が同じである場合、結果は好ましくは同じである。これは、再現性を可能にするひとつの方法(唯一の方法ではない)である。これらの疑似ランダム及びシード問題に関する更なる議論は、本願明細書の別の箇所で行われる。
図17を続けて参照して、「高音符」は、単純に1オクターブを先行する低音符に加えて、メロディに大きい変化をつくるするために役立つ。ここで興味深いことは、複数のVNCが前の低音符及び高音符の間に起こり得るということであり、そして、これは、楽曲フレーズの演奏に先の低音符に対応する主音音符を許容するための方法である。明らかに、実際の楽曲構造が実際の楽曲自体が書かれる前に存在することを可能にするので、このVNCは非常に役立つ。アルゴリズムは、最終的なキーかモードがこの点で何であるかはわからないが、オクターブ及び主音を利用できる。
マジック音符と同様に、「倍音音符」VNCは、アルゴリズムが擬似ランダムに一組の可能な高調波から倍音を選ぶことを許可する。あるコードで同時に聞こえている多数の音符があるとき、この能力は役立つ。このVNCが使われるとき、それは結果として、図17に記載されている相対的な高調波のいずれかになる。これらの値は、可能な値の単なる例示であり、われわれが取り組んできたタイプの楽曲に特に有用なものである。
「最終音符」は「低音符」と非常に類似しているVNCである。但し、可能な値のサブセットのみを含む場合は除く。このことは、我々が取り組む楽曲タイプのための楽曲フレーズを理解するように、最終的な音符が特に重要で、一般に最もよく聞こえるので、それがC又はG(この例では、全ての音符がその後追加ステップによって上下に移調することができることを留意して)の相対値を有するときに、一般に最もよく聞こえるからである。全てのVNCと同様に、その値で演奏される正確な音符は、ユーザが利用できる一般のピッチシフトと同様に、後で適用されるモードとキーに依存する。しかしながら、我々が取り組む楽曲において、これが、種々の可能な結果を提供する楽曲に微妙さを付加するための有用な方法であることを我々は見出した。
「最終音符の一つの前の音符」は、「最終音符」の直前に先行するVNCである。このことは、最後のふたつの音符及び倍音的音程が曲の最終効果にとって重要であることを発見したからであり、したがって、「最終音符」C及びGとともに、E、G又はBの「最終音符の一つの前の音符」を使用することが有利であることがわかる。これらの値は、楽曲の他のスタイルに適用でき、VNC構造が有効に利用されることの一例を示している。
図17の最後の例VNCは、ALCコントローラである。これは、ある楽曲の非ピッチ概念がMIDIコントローラを使用して用いられる一例である。この例では、ALCコントローラが直後の音符の意味を変更する接頭辞として考えることができる。ALCコントローラは、例えば、コードを設定するために、次の音符が特別な方法で扱われることになっていることを示すために用いることができる。この例では、付加的倍音音符を有する固定された一連の音符に先行するために、ALCコントローラのための特定の定義済み値を使用することができる。上記で論じられたマジック音符VNCと同様に、ALCコントローラに引き続く「倍音音符」が、アルゴリズムに擬似ランラムに一組の可能な高調波から倍音を選ぶことを許容する。あるコードで同時に聞こえている多数の音符があるとき、この能力は役立つ。このVNCが使われるとき、それは図17に記載されている相対的な高調波のいずれかに結果としてなる。これらの値は、可能な値の単なる例示であり、今日まで取り組まれたタイプの楽曲に特に有用なものである。ALCコントローラの他の実施例は、固定された音符の設定にある。この場合、任意の所望の実際の音符値のための「固定音符」値を有する適当なALCコントローラに追従する。この方法は、所望の楽曲の音符の間の特定の音程が成し遂げられる場合、より慎重に限られた歌曲出力を有するために、多くの例において役立つ。その上、周知のフレーズ又はシーケンスを演奏することは、ALCコントローラのこの使用によって可能である。既存の楽曲にかなり似ている一曲を生成するために、全ての歌曲の部分をこの方法で符号化することができる。この例では、楽曲がまるで既存の曲(例えば、メロディで)のように聞こえることを可能にするように対話的に生成される楽曲のある部分を有することができ、また、他の部分が異なる(例えば、バス又はドラムような)ようにすることもできる。
このようにして、ALC値がVNCの全てを処理し、それに次の音符がコードの基礎になっていることを知らせるソフトウェアルーチンに警告するということ、及び、倍音音符の次の番号がその基礎音符と同時に演奏され、結果としてすぐに演奏されるコードになることから、ユーザは結果コードを設定できる。この実施例は、これが効果的になされる一方法を示す。VNCコントローラの他の値は、類似した楽曲機能を実行するために用いることができる。
特定の楽器タイプの自然音域、又はTessitureを扱う付加的変形を実現することができる点に注意すべきである。ソフトウェアルゴリズムが前述のVNCを採用しかつ真の値を選んでいる場合、真ピッチ値は楽器タイプの真の自然音域と比較することができ、そして、次のVNC結果の値は反転することができる。例えば、与えられたパターンの「低音符」がバス楽器Tessituraのための音域の上部に近い場合、正数を戻すことになる任意の次のマジック音符を、先行する「低音符」の下になるように音符を移行するために反転することができる。これは、特定の楽器タイプの自然音域の制限を組み込むので、微妙さ及び深さを結果に加える独特の最適化である。
Tessituraの簡略実施例として、図18Aは特定の楽器タイプの相対的な最適範囲を表す。これと関連して、楽器のTessituraは、それが最適に聞こえる音域である。MIDI音響バンクのある音響は、特定の音域のために最適化される。ベースギター音響を選んで、非常に高いピッチの音符を演奏する場合、結果はあまり良くはならない。より高いピッチのためには、ギター又はバイオリン音響が、より効果的に作用することができる。したがって、楽曲ルールアルゴリズムがVNCを処理しているとき、選択された楽器タイプのTessituraは、生成された真の音符値の結果で役割を果たすことができる。選択された楽器がそのTessituraの上部エッジに接近していて、楽曲ルールルーティンが「高音符」VNCにわたって現れる場合、アルゴリズムは生成されたピッチを1又は2オクターブ下に落とすように設計される。同様に、他のVNCは、選択された楽器のTessituraに応じて処理される。
ある別の実施例において、状態マシン、表及び「Magcic Function(マジック関数)」ルーティンに部分的に依存することによって、バーチャル音符コントローラ(VNC)及び真の音符の間で変換を実行することが好ましい。このように、新規な楽曲のスタイルは、「Mgic Function」を変更せずに、リリースすることができる。例として、1又は複数の表及び/又は状態マシンを更新するだけで、新しい及び/又は変更されたVNCタイプを含む新規なスタイルを創作することができる。「Magic Function」が転送互換性を犠牲にすることなく最適化された設計(例えば、DSP)において実現されることを可能にするという点で、この種の方法は望ましい。ある実施例において、状態マシンデータは、歌曲の一部として記憶することができる。
図18Bは、転送互換性のために、表及び/又は状態マシンに依存する典型的な「Magic Function」系統線図を例示する。この「Magic Function」は、VNCイベントに基づいて真の音符情報を生成するために、アルゴリズムの楽曲発生器によって呼び出される。この機能が、楽曲の間、多数回呼び出され、したがって、比較的効率的なDSPハードウェア設計のような最適化された設計を使用する利点があることが明白である。
図18Bの左上を起点として、前の真の音符及び処理されるべき現在のバーチャル音符(VNC)を有する「Magic Function」が起動する。この機能の目的は、現在のVNCと一致するために真の音符情報を決定することにある。この例では、本発明の効果の多数を実現するために必要ではないが、「magic Function」の一部として、奇術機能の一部である有限状態マシン(ムーア状態マシン(http://www.nist.gov/dads/HTML/finiteStateMachine.htmlで国立標準技術研究所によって更に詳細に記載されている)のような)の使用を例示する。図18Bに関する説明を続けると、状態マシン(SM)にアクセスして、それによって表からデルタ値の音域を書き込む。また、本願明細書において記述されるように、簡単な更新を与える方法で、表及び/又は状態マシンは記憶される。ここで記載されているデルタ値の音域の例として、図17と関連して本願明細書において記載されているマジック音符1のようなVNCの使用を仮定すると、表から書き込まれるされるデルタ値の音域は、−2, −1, +1, +2である。図18Bにおけるこの点で、「Magic Function」は、前もって決定された真の音符から移動する方向(例えば、増分又は減分)をランダムに選ぶ。説明のために本願明細書において、減分している方向がこの点で選択されると仮定する。それが値(例えば{−2、−1})を減少させるだけであることを含むために、デルタ値の音域が、それが減少値(例えば、−2, −1)のみを含むようにマスキングされる。このマスキングされた音域から、単一のデルタ値は、好ましくはそれから「Magic Function」によって選ばれる。
特定の楽曲構成要素(例えば、図18Aと関連して本願明細書において記載されているように)と関連するTessitureが使われないある実施例において、「Magic Function」のこの点で、デルタ値を、新しい真の音符を創作するために、前もって決定された真の音符に適用することができる。例えば、前の真の音符がG3でデルタ値が−2であると仮定すると、新しい真の音符はE3である。
許容音域ISのTessitureが望まれるある実施例において、個々のデルタ値がマスキングされた音域から選ばれる図18Bに示された「Magic Function」の点で、選択されたデルタ値がtessitura音域値の範囲内であるかどうか調べることが望ましい。それが範囲の中でない場合、その機能は選択されたデルタ値(例えば、−2)を廃棄し、マスキングされたデルタ値の音域から、最大値(例えば、−2)を取り除いて、新規な最大値がtessituraに対応する許容値の音域の中であるかどうか調べる。新規な最大値が音域の中である場合、典型的な機能では、マスキングされた音域の残留する値の中から別のものをランダムに選んで、新しい真の音符を創作し続ける。しかしながら、新規な最大値がtessitura音域によって許容されない場合、「Magic Function」は、デルタ値の現在のマスキングされた音域を廃棄して、方向指示(例えば、減少から増加まで)を変更して、新規な指示によるデルタ値の元の音域をマスキングする。このように、「Magic Function」がtessitura値の許容音域の近い一縁部で作動するとき、端を検出して回転させることができる。したがって、フルート(例えば、比較的高いtessitura音域を有する)のような楽器と関連するVNCが現在処理されていて、その処理のランダム状態が作曲されているメロディにフルート楽器と関連する標準音域の底部端に接近させる場合、現在の典型的な「Magic Function」は減少する方向から+1増加するものまで変更することができて、それによって、フルートと関連する標準ピッチ音域の中にとどまることができる。ここで記載されているような方法において、効率的なアルゴリズム(例えば、DSP)を、バーチャルピッチイベントから真のピッチイベントを創作することに提供することは可能である、その一方で、各々のバーチャルピッチイベント(例えば、特定のVNCに伴う値の表を更新することによって)に伴う個々のデルタ値と同様に、バーチャルピッチイベント(例えば、状態マシン表を更新することによって)のタイプの将来のアップグレードを許容する。さらに、ここで議論される実施例がVNCから真の音符まで移動することに含まれる機能に向けられているが、この種の方法が、この開示の他の箇所で記載されている他の作曲要素(例えば、コード進行の選択、歌曲構造、その他のような)のいずれかに、同じように適用できることも、当業者にとって明らかである。
図19は、楽曲処理の他の態様を記載する。楽曲のキー変化は、オフセットとして符号化することができる。これによって、Xのキーの場合、そのキーは、オフセットを挿入することにより上下にシフトすることができる。この種のオフセットは、(今は異なるキーであるが)前の通りの楽曲フレーズに結果としてなるために、正確な値によってすべてを移調する。図19は、A、C、D及びGのキーを有する例を示している。Cのキーは、0のオフセットを、Aは−3のオフセット、Dは +2のオフセット、Gは+8のオフセットを有する。音楽理論の学生が理解できるように、オフセットは多くの半音と密接に一致する。C及びGの間の音程は、8つの半音である。他のキーも、同じように行うことができる。
上記したように、MIDI言語フォーマットが、増分的に半音ピッチ値と一致している各整数値については、楽曲のピッチを詳細に描写するために整数を使用するので、キーを符号化するための半音の使用は有利である。キーを示すためにオフセット値を提供する他の手段が使用され得る。しかし、経験上、MIDI DSPを使用しているので、半分のステップの活用法は特にこの実施態様に有用である。したがって、楽曲ルールの出力は、少なくとも部分的にMIDIに基づくものである。
図20は、全プロセスの一部である他の楽曲ルールであるモードアプリケーションを示す。楽曲理論の学生によって理解されるように、モードが嬰音(フラットとは反対に)に関して記述されることを仮定すると、嬰音の特定の配置が、各楽曲フレーズにそれ自身のほとんどの独自性を与える。図20において、昇順又は降順バージョンが利用できる「リディアンモード」の例を提供する。他の確立した楽曲モードが存在する(イオニアン、ドーリアン、ハイポドーリアン、フリギアン、ハイポフリギア、ハイポリディアン、ミクロリディアン、アイオリアン、ロクリアン、その他)が、紙面の関係上こここではリディアンのみを使用する。明らかに、図20のそれらの相当値を有する他のモードを、本発明は含むことができる。従来の西洋モードでないモードが要求されるケースにおいては、他の音程が可能であるために、音響バンク(例えば、フラッシュ 49に位置する)をアップグレードするか又は変えることが好ましい。
図20は、我々が扱っている楽曲のジャンルの全ての好ましくは利用できる音符のリストから始まっている。それは、「本位記号モード(Natural Mode)」と称する対応する本位音符値によって追従される。「本位記号モード」の音符の値は、嬰音(再び、本説明では、変音(フラット)ではなく、嬰音の点でモードを定めてめていることを仮定する)なしの音符の全音符列と一致する。「リディアンモード」はリスト記入され、F本位音を許容しない。本位音のFが、F嬰音の次の有効ピッチまで上げられることになっているか、又はEの次の有効ピッチに下げられることになっているかどうかを決めるために、アルゴリズムは昇順性又は降順性移調のいずれかを決定する。降順的に移調されたF本位音はEに変更され、昇順的に移調された本位音FはF嬰音へ移調される。嬰音が「本位音モード」から変化するとすると、昇順「リディアンモード」の使用は、結果として、よりF嬰音の多い楽曲となり、よりアグレッシブな「リディアン」となる。降順移調より典型的によりアグレッシブである昇順移調を行うこの一般の概念は、他のモードでも同様に明らかである。
この点に関して、図21を用いてアルゴリズムの楽曲ルール部分の詳細な例を述べる。本発明の好ましい例がどのようにそれらを組み込むかについて示すために、この説明は、以前の図に関する前述の説明を組み込む。
図21は、各々の番号をつけられた図16Aのステップ2−6の間に存在するように、そのデータを表す。もちろん、バーチャルパターンサブブロックデータがパラメータデータ(例えば、図16Bに示すように)に基づいてアルゴリズム的に生成されるある例では、VPサブブロックは、定義済みセットから書き込まれるよりはむしろ必要に応じて生成され得る。従って、あとに続く説明で、VPサブブロックデータに関する説明が定義済みデータの使用を含むけれども、ある例では、これが、処理の間必要に応じて定めらることに留意すべきである。記譜法は、好ましいフォーマットの簡略実施例を示すために、データがソフトウェアルーチンを取り入れることができるフォーマットの簡略実施例を示すためとともに、全体的な概念を明らかにするために述べられる。
最上列から始まって、楽曲スタイル及び/又は長さによって適宜インデックスを付けることができる一まとまりの定義済みVPサブブロックがある。これらのブロックは、可変サイズであって、ピッチ(ある実施例でVPのピッチ情報が上記のように実際のピッチ特性でなく、しかし、上記したようなVNCデータを示すと認識して)、速度及びMIDIファイル(定義済みVPサブブロックの好ましい集合は、図22及び図23に関して以下で更に詳細に論じられる)の継続期間の記譜法に対応する16進フォーマットで記憶される。図21の最上列に示すように、休止符が有効パターンの集合において利用できる。索引つきサブブロックの集合が、「バーチャルパターン」(VP)を構築するためにソフトウェアルーチンによって使用される。上述したように、ある別の例では、サブブロックのコレクションを生成するためにアルゴリズム的ブロックルールを使用することを含む。この種のアルゴリズムのルールは、楽曲スタイル及び楽器タイプを入力として受け入れ、そのスタイル/楽器の組合せに適するひとまとまりのサブブロックを出力するように構成される。サブブロックが定義済み集合から選ばれるか又はアルゴリズムで活動中に生成されるかは、VPに系統化される。VPは、一貫して大きさを設定されたグループ化に関与するルーチンによって組み立てられた一まとまりのサブブロックである。
図16Aのステップ2が適用されたあと、好ましくはVPを有する。図21(VP)の第2の列は、2小節長の、以下のシーケンスで作曲された実施例VPを表す。すなわち、「低音符」、「マジック音符1」、「マジック音符0」「高音符」、及びその他の「低音符」である。このとき、パートのリズムは適当な位置にあり、各音符の値は概念的に組み込みVNC情報であることに留意すべきである。VPがこの点で演奏されるなら、出力はおそらく気持ちよいものではない。列2の右欄は、このデータが記憶されるフォーマットを表す。本明細書の他の箇所で議論じられているように、このフォーマットが、VNC情報がデータストリームに必ず組み込まれるという点を除き、MIDIフォーマットデータに著しく類似している。
図16Aのステップ3が適用された後の第3の列(NCP)は同じデータを表す。列2からVPに組み込まれるVNCは、可能なVNC値から疑似ランダム選択の助けを借りて、ルーチンによって解釈される。このように、列2の第1の「低音符」に対して、列3のEの真の音符値を有し、そして、減少させた列2のマジック音符のタイプ1に関して、前の「低音符」をふたつの半音分、列3のDまで減少させる。マジック音符のタイプ0については、前の値を0だけ調整して、他のDに結果としてなる。これがVPについて行われ、そして、結果は列3において明白である。この点で、コード及びモード移調が未だなされなっかた場合を除き、最終的に楽曲となる基本的な楽曲情報を有することになる。
図16Aのステップ4が適用された後の図21(PwT)の第4の列は、データストリームを表す。理解できるように、列3のNCPは下へ移調された。これは、特定のパターンが特定の主音音符に適合するように構成されることを許容し、このようにして、楽曲の他の要素に整合させるために適切なコードにそれを配置する。この特徴によって、メロディの異なる部分を異なる主音音符に適合することができる。そして、全ての楽器が同じコード進行に合致することを確実にしつつ、このように、コード進行に沿って処理を行う。
図21(PwTM)の列5は、音符のパターンを示し、特定のモードタイプ(降順的、昇順的、その他のような)と同様にそれを特定のモード(例えば、アイオニアン、ドーリアン、ハイポドーリアン、フリギアン、ハイポフリギアン、リディアン、ハイポリディアン、ミキソリディアン、アイオリアン、ロクリアン、その他)に適合させる。楽曲モード及びモードタイプのより完全なリストは、Manuel Op de Coul(以下のワールドワイドウェブで利用可能:www.xs4all.nl/〜huygensf/doc/modename.html)によって作成されており、本願明細書に組み込まれたものとする。特定のモードに対する音符のパターンの適合は、上述した図20と同様な方法でなされる。図21の例において、C嬰音の差がCに減じられる場合を除いて、結果として生じる楽句は、列4のそれと非常に類似している。このことは、この種のC嬰音がリディアンモードにないことによるもので、したがって、その除去がこのステップで必要である。旋法調整がモードをのぼっているリディアン昇順モードを使用している場合、より多くの嬰音がある故にそれはよりアトラクティブになり、このC嬰音は次のリディアン音符Dに切り上げられる。しかし、この例ではリディアン降順モードをを使用しているので、嬰音CはCに切り下げられる。
図21(RP)の最終列は、楽曲フレーズが音階を包括的に上下移調されるときの位置を示す。これは、包括的ピッチ調整機能が望まれる場合に、ユーザが迅速且つ容易に歌曲のピッチを上下に(例えば、それは、Up/Downキーと結合して使用するピッチ/テンポキーについて先の実施例において論じられたように)移行することを可能にするために有利である。列6の例は、2つの半音の移調を示す。この図の全ての列と同様に、第3の対の番号が行毎に2の値分増加することがある場合、これは、ソフトウェア表記法と同様に記譜法に見てとれる。
楽曲のある要素が、呼び出されるべき上述した楽曲ルールを必要とし例がある。例えば、ドラムトラックは、概してモード又はキーに関係しないので、このように移調される必要はない。その上、ドラム、及びMIDI効果のような多くの楽器タイプは、一連のピッチのMIDI音響バンクに編成されない。しかし、互いに似ているか又は似ていない一連の音響においては編成される。ドラムの実施例において、嬰音Cに対応する音響は小太鼓音であってもよく、大太鼓音であってもよい。これは、ある場合には、図21に関して上述された処理の異なるレベルが、これらの場合に都合よく迂回することができることを意味する。
VPを構築するための上述のサブブロックの集合は、図22及び図23を参照してよりよく理解される。
図22は、1又は2の四分音符の例示的な継続期間に基づいて、可能であるリズム変化の実施例を表す。第1列は、2、3の基本条件(8分音符が最小単位であること、長さは一つの四分音符であること、及び、全ての全休止符は別個に「空の」として示されること)が与えられた場合の4つの可能な変化を示す。図22の第2の列は、類似した変化(8分音符が最小単位であること、第一列のいかなる変化も含まれないということ、及び、長さが2つの四分音符であること)が与えられる場合の、可能な変化の一覧を示す。
図22に示すような一組のリズム変化をつくるひとつの方法は、変化データをMIDIイベントフォーマットに入れることである。この方法は、周期的ブロックを生成するためにMIDIシーケンサソフトウェアツール(CakewalkからのSonar及びスタインバーグからのCubaseのような)を使用することを含む。これは、種々の入力方法(例えば、キーボードコントローラ、MIDI管楽器コントローラ、MIDIギターコントローラ、その他)の使用を可能にして、更に、直観的な複製、ペースト、量子化、及び包括的な特性調整(例えば、多数のイベントを選んで、そして全てのためのピッチを調整すること)を可能にする。MIDIイベントは、MIDIファイル(各楽器グループごとに1ファイルで)として、移出することができる。最後に、ソフトウェアバッチファイルプログラムは、任意の必要とされない特性情報(コントローラ又はパッチ情報のような)と同様に、実質的なヘッダ情報を分析し、そして、ソースコード(例えば、ASCIIテキストテーブル)に含めるのに適しているファイルへ最適化されたデータを出力するために記述することができる。MIDIコントローラ装置の広大なアレイを利用でき、それが特定の楽器タイプの特性を模することができるので、時間配列ツールの使用により、与えられた楽器タイプ毎の種々の適宜のリズムブロックを迅速に生成することを可能にする。例えば、楽器グループのギタータイプのひな型でつま弾くために、MIDIギターコントローラを使用することができる。
図22の例は、概念を伝えるために単純化される。すなわち、2つの四分音符(上述の条件が与えられると仮定すると)までカバーしている全てのリズム変化が、リズム密度によって非常に効率的に編成することができる。図22は、図15に示されるVPを構成するために用いるブロックの一組を効率的に編成する有利な方法を教示する。列全体に整合している上記したような条件が与えられると仮定すると、図22の例がより長い持続期間を有するリズムブロックのための付加列を含むために拡張される場合、各々の次の列は、それより上のそれらより少ない密度のパターンを有するであろう。これは、各列がそれより上の列にあるいかなる変化も含まないという条件によるものであり、パターンの継続期間が各々の次の列のために増加するためでもある。このように、図22に示される例とVPをつくるために使用されるパターンの相対的なリズム密度との間には直接の関係がある。
明らかに、図22に記載されているいずれかの条件が変更される場合、例えば、十六分音符が最小単位であるか、又は全休止符が休止符を含むパターンで示される場合、変化の数は異なるであろう。数が異なるとしても、リズム密度のこの概念に基づく編成パターンの望ましい効果は存続する。
効率に加えて、有効なリズムブロックを編成するこの種の方法は、ソフトウェア(例えば、アルゴリズムの機能)又はハードウェア(例えば、状態表ゲートアレイ)ルーチンに入力としてリズム密度の使用を可能にする。このように、相対的なリズム密度を特定の楽器タイプと関連させることができ、対応するリズムブロックを得るために、所望のブロック長の形で、そのリズム密度を使用することができる。VPが完了する(図15を参照)まで、これは繰り返すことができる。VPは、所望の相対的なリズム密度によって構成することができる。通常、与えられた楽器タイプと一致しているリズム特性を有するほぼ無制限の変化を有するVPの作成を可能にするので、これは特に有用である。
MIDIの当業者にとって明らかであるように、ここで論じられるVP生成にあっては、図22に示されるリズム変化はMIDIイベントの形で示すことができる。この場合、MIDIイベント(ピッチ、速度、アフタータッチ、その他のような)の有効特性の多くは、一般的に設定される。また、この種の特性のための追加機能は、付加的な微妙さを完結した楽曲に与えるために、VPの作成の間にMIDIイベントに適用することができる。この種の機能は、かなり単純であり、効果的である。一つの例として、楽曲(例えば、ロック)の与えられたスタイルのために、拍子(例えば、ダウンビート)の特定の位置にかかるVPいかなるMIDIイベントの速度は、穏やかに増加することができる。同様に、一般にリズム揺動感を有する楽曲スタイルにおいて、拍子のひとつ又はそれ以上の打音がわずかに遅れたり、又は進んだりする場合、VP内の対応するMIDIイベントを、タイミング情報を調整するために変更することができる。明らかに、これらの種類の単純な機能は、与えられた楽器タイプ及び/又は与えられた楽曲スタイルのいずれにも好ましくは適用することができる。
図23は、アルゴリズムで楽曲を創作する際の決定的な特性として相対的なリズム密度を使用する概念と同様に、音符ピッチの相対的な可動性の概念を記述する。図23に示すように、垂直軸はピッチ変化を示し、そして、水平軸は時間を示す。メロディストリームの2つのタイプ例が表される。すなわち、種々のピッチによるストリーミングを有する上部と、より少ない数のピッチの中のむしろ急峻で、不連続な変化を有する下部とである。このように、図23の上のメロディは、音符ピッチのより高い相対的可動性を有する。VNCに関する前の説明理解することができるように、上部のメロディ例は一般に模倣するより多くのマジック音符を必要とし、そして、下部のメロディ例は一般に模倣するより多くの低音符及び高音符を必要とする。
ある楽器が他より高い音符ピッチの相対的可動性を有するという点で、この概念は、与えられた楽曲スタイルの大部分の楽器タイプにもあてはまる。例えば、ロックスタイルのベースギターは、同じスタイルのギターと比較して、音符ピッチの低い相対的可動性を有すると理解することができる。それが各々のリズムパターンのための実際のVNCの決定における手引きとして役立つという点で、音符ピッチ及び関連したVNCタイプの相対的可動性との関係は、上述の通り、定義済みサブブロックの集合を創作するのに非常に有効である。したがって、特定の楽曲スタイル及び/又は楽器タイプで使用するために、一組のリズムビルディングブロックをつくりたいとき、音符ピッチの所望の相対的可動性を考慮して/決定し、VNCタイプを割り当てることは、有利である。
付加的変形として、上記した相対的なリズム密度に関して、与えれられた楽器タイプ及び/又は楽曲スタイルのためにVPを構成するアーキテクチャがソフトウェア(例えば、アルゴリズムの機能)又は、音符ピッチの相対的可動性に関するハードウェア(例えば、状態表ゲートアレイ)ルーチンから非常に利益をもたらすことができる。例えば、特定楽曲スタイル及び/又は楽器タイプに、相対的なリズム密度値を割り当ることができ、そして、この種の値は、VPの生成の間、VNCの割り当て又は配信に影響を与えるために用いることができる。
この状況下での音符ピッチの相対的なリズム密度及び相対的可動性の使用は、実際に人間が生成した楽曲の芸術的微妙さを精巧に模するVPを生成する方法を提供する。これが、この種の真の楽曲の楽曲構成要素のある態様を定量化する方法であるので、本願明細書において開示されるように、それがコンピュータシステムによって模倣することができる。他の変形及びその種の方法の利点は、これらの特性が好ましくはユーザによって変更可能であるパラメータとして容易に定量化されるということである。このように、所与の楽曲スタイル及び/又は楽器タイプが、可変特性として音符ピッチパラメータ(及び/又は相対的なリズム密度パラメータ)の相対的可動性を有することができる。したがって、ユーザは、歌曲再生/生成の間、この種のパラメータを調整することができ、かつ、音楽的結果全体にわたって制御の他のレベルを有することができる。
本発明のブロック作成態様のための好ましい具体化のさまざまな実施例が記述される。また、上記のように、ある実施例で、VPサブブロックデータは、アルゴリズム的にパラメータ入力データ(例えば、第16B図にて図示したように)に基づいて生成することができ、又は、この開示のどこかで論じられた/図解されたように、予め定められたセットから書き込むことができる。
図15に示される例を続けると、RPが2小節で、そして、VPが8つの四分音符(QN)からなる場合、図24のパターン構造作成例は、特定の歌曲生成が8QNのVP長、2小節RP、及び可変サイズ化されたブロックを含むものと仮定する。当業者であれば、相当数のこの好ましい例のアーキテクチャに起因している効果を理解する一方で、さらに、これらの例に対するさまざまな改作変更が本発明の技術思想と範囲から逸脱することなく構成され得ることも理解するであろう。
スタイルのアルゴリズムの生成のためのある好ましい本実施例を、図16Cと関連して述べる。図示するように、楽曲データ(例えば、MIDIファイルのような)を分析するために、次の自動楽曲生成に使用するためにパラメータ及びパラメータ範囲を決定すべく本願明細書において記載されている楽曲生成概念を用いることは有利である。このように、現実の音楽部分をアルゴリズムに入れることができ、分析することができ、特性を決定するために測定されることができる。そして、特性のデータベースに記述され、それから類似した楽曲を生成するために用いてもよい楽曲ルールに、最終的に抜き出される。このように、先に存在する楽曲データに基づいて楽曲スタイルを作成する方法を自動化することができる(ある程度の人間の介入を有するが)。このように、先に存在する楽曲に基づいて自動作曲された楽曲を引き出す能力をもつ余裕がある。これは、アーティスト(例えば、エミネム、イモレーション、ビートルズ又はセロニアスモンク、その他)、ジャンル(例えば、ブラックメタル、バップジャズ又はプログレッシブロック、その他)、及び/又は、時代(例えば、1970年代後期ディスコ)、音楽ラベル(例えば、Motown Records又はBlue Note Music、その他))に基づいて楽曲スタイルを作成する際に有利である。
図16Cに示すように、既存の楽曲データ(例えば、MIDIファイル)が分析アルゴリズムに書き込まれる。所望の結果(例えば、一組のエミネム曲がローディングされ、そして、その結果はエミネムに特有の楽曲スタイルである)に基づいて、1又は複数の楽曲入力の決定は、人間のオペレータによってなされる。一旦楽曲参照データがローディングされると、アルゴリズムはデータのさまざまな特性を測定するためにデータを処理する。図16Bと関連して上記の説明は、アルゴリズム的に楽曲入力データに由来することができるパラメータのタイプの実施例を与える。MIDIデータファイルの例を用いて、さまざまなパラメータは、各楽器について測定することができる(例えば、第1の最大%、解像度グリッド、パルス、無音%、コード%、コード持続期間感度%、コード速度感度%、速度強調、速度動力、擬人化、その他)。その上、この開示のどこかで論じられたように、他の測定が、モード、ピッチ、その他のように引き出される。図16Cに示したように、分析アルゴリズムは、ユーザが派生パラメータを調整することができるように、ある程度のユーザ入力を許容する。例えば、入力ファイルのうちの1つが異例に遅いテンポを有する場合、ユーザは一つの異例に遅い入力曲の効果を除去するために、派生テンポ範囲を微調整することができる。楽曲入力が分析されて測定された後、一組のパラメータ及びパラメータ範囲がデータベースに記憶される。この例では、データベースはプログラミング言語のためのインクルードファイルを公式化するために、コンピュータープログラムによってアクセスすることができる。図16Cの実施例において、この開示の全体にわたって記載されているように、自動作曲を実行するためのファームウェア又は他のソフトウェアを生成するために用いることができるMS Visual C++プログラミング言語インクルードファイルのために、インクルードファイルをフォーマット化することができる。このように、既存の楽曲データ(例えば、1又は複数のMIDIファイルの形で)は、オリジナル楽曲データの特性に密接に似ている楽曲のスタイルを作成するために用いてもよい。
ある実施例において、入力楽曲データは、MIDI以外のフォーマットであってもよい。例えば、ある方法については、記録された楽曲(例えば、PCM、WAV、CD−Audio、その他のフォーマットでの楽曲)を分析するためにすでに記述している。この種のすでに開示された技術は、例えば、図16Cの「分析アルゴリズム」の一部として、本発明に組み込むことができる、「Classifying Recorded Music」、2000年にのエジンバラ大学のためのセスゴーラブによって書かれたMSc論文は、この種の分析のための典型的なソースコードを含む一つの実施例である。キースマーティンによる[Automatic Transcription of Simple Polyphonic Music」は、1996年12月のMITメディアラボPerceptual Computingによってリリースした、本発明と整合した方法で、特性データを引き出すために記録された楽曲をアルゴリズム的に分析する技術の他の例である。エリックシェイラーによって、1998年のアメリカ音響学会によって発行された「Tempo and Beat Analysis of Acoustic Music Signals」は、この種の分析の更なる実施例を提供する。併せて、これらの文献は、パラメータデータをつくるために音響調節的、記録された楽曲の測定及び分析についての典型的なさらなる詳細を提供する。アーティスト、ジャンル、その他に基づいて楽曲ルールを作成するために、自動作曲エンジンのための音楽スタイルを作成するために実行することができる分析の実施例として、この種の技術は本説明に組み込まれれたものとする。
図24に示すように、本発明の好ましい一実施例はパターン構造の作成を含む。このパターン構造は実際のブロックを選ぶために必要な情報から成り、そして、それらはさまざまな方法で歌曲生成の基本単位となる。ある好ましい実施例においては、図16Bと関連して論じられるように、実際のブロックは、特定のスタイル及び/又は楽器のために必要に応じてアルゴリズム的に生成される。あるいは、パターン構造作成のこの実施例は、ブロックが選ばれる楽器の群と同様に、各々のブロックの持続期間(与えられたVPで)を決定することを含む。このステップの後、以下で論じられるように、この情報は、それ自身直接ブロックを生成するために用いられる。
Patt_Infoは、ブロックから特定のVPの作成の一部として、パターン構造情報を生成するために用いることができるルーチンである。
シフトは、さまざまな方法で好ましくは構成されたVPに変化を加えるために用いることができるマルチプライヤであって、例えば、それは、特定のブロックが入るRPにおける2小節のいずれかに基づいて異なるブロックの変化を許容するバイナリ状態であってもよい。シフトマルチプライヤの他の使用形態も容易に適用され、類似した多様性を全体的な歌曲構造に提供する。
Num_Typesは楽器の数であって、Num_Sub_Drumsはドラム楽器を形成する個々のドラムの数である。この後者のポイントは楽器選択の拡張レイヤを許容する好ましい変化であり、そして、それはドラム楽器以外の状況にも適用することができる。逆にいえば、この変化は、全く本発明又は本実施例にさえ必要でない。
Block_Indはブロックインデックスであり、FX_Noは任意の効果番号情報のためのものである。Combi_Noは、Comb_Index_Listと呼ばれている表の場所を示しているインデックスである。この表は、スタイル数に楽器タイプの数が乗じられる大きさであり、各々の入力は、好ましくは以下を含む。すなわち、特定の入力が現在のサブスタイルに適しているかどうか決定するSubstayle_Mask、長さを決定するCombi_Index及びブロックを決定する個々のMIDIパッチ(及び関連した情報)のグループを決定するGroup_Indexである。
Combi_Indexは、ブロックサイズの多数のセットを含むStyle_Type_Combiと呼ばれている表を示している。各々のBlock_Sizeは、合計SEQの長さになる一組のブロックサイズである。実施例SEQ長は、8つのQNである。
Group_Indexは、スタイルグループ毎のMIDI−タイプ情報のセットを含むStyle_Groupと呼ばれている表を示している。そして、好ましくは、MIDIバンクによって構成される。PCは、Patch Change MIDI情報を対象とし、Pは可変に大きさを設定されたMIDIパラメータに与えられたPatchを対象とする。そして、GSはグループの大きさを表す。グループ1のためのGSは、どれくらいの数の楽器がグループ1として定められるかについて示す。
このステップの実行の好ましい最適化は、特定のパッチ構成をGSによって識別されるグループから選択する擬似乱数発生器(PRNG)を組み込むことである。ユーザが特定のサブスタイルの範囲内でかつ特定のレーンの中で楽器の変更を選ぶとき、他のセットのパッチ情報はGSによって識別されるグループから選択される。PRNGのこの使用はまた、異なる時間に、所与の歌曲、パート、サブパート、SEQ、RP、VP、その他に変化又は他の特性を提供するために楽器が変更され得る場合、歌曲の自動生成に取り入れることができる。当業者にとって明らかであるように、PRNG機能の使用から利益を得ることができるこのルーチンプロセスの他の適用分野がある。一旦ブロック持続期間及び楽器パッチ情報が所与のVPのために決定されると、図25に示すように、バーチャルブロック情報はブロックごとに決定され得る。
Block_Listは、ブロックの大きさ及び楽器タイプを使用しているバーチャルブロックを決定することができるルーチンである。図25に示すように、スタイルは好ましくは幅(すなわち1〜8のQN)及びグループ(すなわち楽器グループ)によって構成されるVirtual_Block_Dataポインタの表に対するポインタである。Start_Pointerが決定されると、ブロックデータはVirtual_Block_Data表を得ることができる。ブロックデータがすでに知られている場合(例えば、空のブロック、繰り返しブロック、その他)、特例が存在する。
また、パターン構造生成に関連して上述したように、全体処理の本ステップは付加的な多様性をブロックに提供するために任意のPRNGルーチンを用いることができる。この例の直接の拡張は、結果に充填をおく単純な手段を提供するために、「Stuffing」(すなわち、特定の表の入力を複製する)を使用することである。これによって、さまざまな二重のエントリを挿入することによってVirtual_Block_Data表から選ばれる特定のブロックデータに影響する能力を参照する。「Stuffing」この概念は、本明細書どこかで論じられた他の表に容易に適用することができる。そして、共通に従来技術において周知である各々の表引きのための結果に重きをおく他の手段を、本発明の精神と範囲から逸脱することなく、容易にここで使用することができる。
さらに、当業者が理解するように、好ましい実施態様のこれらの例の多数が表に対する相当な依存を含むけれども、その分野において共通に知られている状態マシンの概念をこれらのステップに適用し、そして状態マシンを組み込むステップにテーブルアーキテクチャを最適化することは、容易である。この種の最適化は、本発明の趣旨及び範囲から逸脱するものではない。例として、図18Bに関する先の説明を参照する。
本発明の擬似乱数発生のためのさまざまな実施例を説明する。
現在の開示において論じられるいくつかの実施例は、好ましくは複雑な楽曲生成/対話装置を得るために、小さい携帯用アーキテクチャの限られた資源を最大にすることを含む。可能な場合、この種の実施例(そして、その他)で、別々のPRNGルーチンの数を最小化することが望ましい。楽曲生成/対話の類のアプリケーションが、同様にスタイル化された楽曲(人間をが作曲した楽曲)に匹敵するリアリズムの感覚を得るために、PRNG技術に相当依存するが、技術を携帯用用とするように、最終製品のコードオーバーヘッドを最小化して、かつ設計及び製造と関連する経費を最小化することが望ましい。従って、最小のPRNGコード/ルーチンとすることと、パート生成に最大限の随時的影響を与えることの競合する目標を持つことになる。
加えて、本技術の他の目標は、ユーザが効率的方法で歌曲を保存することができるようにすることである。オーディオストリームとして歌曲を記憶する(すなわち、MP3、WMA、WAV、その他)よりもむしろ、歌曲を生成するために用いた構成情報を保存することが望ましく、その結果、それは完全にオリジナルと整合した方法で再生することができる。5分のMP3ファイルがほぼ5MBであるとき、この目標の好ましさは容易によく理解され得る、そして、現在のアーキテクチャを使用すると、同一の歌曲のための対応するファイルサイズはほぼ0.5KBであり、したがって、ほぼ10,000倍減少する。
ある好ましい実施例において、保存された歌曲の音質は、従来のコンパクトディスク(このことにより明らかにMP3より良い)と類似している。この比較において、コンパクトディスクに記憶される5分の歌曲は、ほぼ50MBである。このように、本発明を使用している歌曲のファイルサイズは、ほぼ1/100,000にコンパクトディスクファイルから減少する。
オーディオストリームよりむしろ構成情報それ自体を保存することは、前に保存しておいた楽曲こ書き込むことができるという点で、ユーザが中断したところでそれを拾い上げ、そして作業を続けることを可能にする。この種の効果は、単一の、複合オーディオストリームによっては容易に可能ではなく、そして、音声を多数のストリームに分けることは、指数的にファイルサイズを増やして、可搬性及び/又は品質の重要なトレードオフのない現在のアーキテクチャにおいて実現可能ではない。
その上、本発明のこの態様は、ユーザが歌曲のいかなる位置からも歌曲を保存することを可能にする。ユーザは、楽曲作成を行って相互にやり取りをした後に、歌曲終了時に歌曲を保存することを決めることができる。それが楽曲作成プロセスにおいて、ユーザにより大きな柔軟性及び単純性を与えるので、この種の特徴は明らかに有利である。
図26に戻ると、擬似乱数発生(PRNG)の若干の実施例のための好ましいアルゴリズムの状況を示す線図を示している。ドラムシード(DS)は、DS0−DS4を生成するために単純なPRNGルーチンに入力として使われる数である。当業者にとって明らかであるように、出力の数は可変であり得るが、説明の便宜上4をここで使用する。PRNGから出る出力である4つの値は、ドラムパートに若干の疑似ランダム変化を提供するためにドラムパート生成アルゴリズムのさまざまな部分に入れられる。
単純なPRNGルーチンに対する同じシード入力が複数回使われる場合、値の同じリストが毎回出力される点に注意することが重要である。これは、、それらが、もともと、極めて繰返し性で予測可能であるコンピュータシステムの一部であるがゆえに、単純なPRNGルーチンが全くランダムでないことによるものである。たとえ数レベルの複雑性を、クロック等のような表面上無関係なものを利用するPRNGアルゴリズムに与える場合であっても、エンドユーザは楽曲生成の操作に、数レベルの予想を識別することができる。想像できるように、装置の主態様の1つが大量の良好な楽曲を生成することにあるので、これは非常に望ましくない。
単純なPRNGの予測可能な性質の一つの利点は、シード値を保存しておくことによって、後に同じアルゴリズムを使用して同一の結果を生成することができることである。同じアルゴリズム(又は、好ましくは互換もの)であると仮定すると、シードは入力として提供することができて、毎回、好ましくは正確な同じ結果を成し遂げることができる。楽曲生成/相互作用処理におけるシードの使用に関する更なる説明は、本明細書いずれかで論じられる。
繰返し可能なPRNGを組み込むことは本発明の特徴であるが、より「本当」の乱数発生アルゴリズムから利益を得るようにした本発明の態様も存在する。明確にするため、これを「複雑PRNG」と呼ぶ。図26及び図27の実施例を用いて、定期的に、同じシード入力がドラムパート及びバスパートのために使われる場合、それは結果の変動性を制限することになる。他の実施例では、前に保存された歌曲を演奏するとき、A及びA’が常に同じことであることを望むけれども、新しい歌曲を生成しているとき、これらのシード入力がランダムに異なることはたいへん望ましい。一方、歌曲生成は、歌曲再生と同じ繰返し性が欠点である。
本発明に関する、コスト/資源束縛の範囲内で作用する複雑PRNGの一つの実施例は、個々のユーザのボタン−押圧のタイミングを組み込むアルゴリズムを有するものである。例えば、時々楽曲を生成し、その生成処理でユーザ相互作用を提供する進行中に、単純なタイマーを初期化することができて、ユーザのボタン押圧を待つことができる。それから、そのタイマーの値は、ランダム状態を加えるために好ましくはPRNGルーチンに組み込むことができる。例として、システムが33MHz又はその近辺で動作している場合、任意の所与の時点とユーザのボタン押圧との間のクロック数がランダム状態をPRNGに与えるであろうことが理解される。他の実施例では、完了する主ソフトウェアループのための所要時間の情報を得続けるアルゴリズムを有するものである。この種のループは、ユーザボタン押圧、楽曲作曲変化のような外部イベントに基づいて変化するので、それが一つのループを完了するたびに実質的に完了する時間が異なる。外部イベンントのそれぞれは、種々のイベント又は動作、その他のために、他のルーティン及び/又はタイミングループ、又はそれに類したものを呼び出すことができる。シードから値の生成において、この種の複雑PRNGを使用することは、上記した繰り返し性の問題のために望ましくないが、上記で論じられたように、シード、その他の生成においてこの種のPRNGを使用することは望ましい。付加実施例として、装置が時間通りに電源を入れられる瞬間から、「press−it−and−forget−it」モードが起動される瞬間までの時限で、この種の複合PRNGルーチンを使うことができる。このとき、ホームモード(この開示の初期に論じられた)の第1の自動演奏歌曲の選択にある程度のランダム状態及び変動性が提供される。もちろん、この種の複雑PRNGは、本発明の変形であって、本発明を実施する上で必ずしも必要としない。
ある実施例において、一つの望ましい本発明の態様は、選択をエンドユーザに制限することを含む。楽器を演奏することができるさまざまな方法は無制限であり、ある種の構造がない場合、可能な方法の多数は耳に不快である。快い楽曲の一つの特徴は、それがある種の構造にかなうということである。事実、創造力の定義が構造を通じた表現であると論じることができる。楽曲及び/又は楽器の異なるタイプは、異なっている構造を有することができるが、それは聴取者が楽曲を解釈するためにフレームワークを提供するので、構造それ自体は楽曲のアピールに不可欠である。本発明は、楽曲の生成のシード値を使用する好ましいいくつかの態様を含む。シードを組み込むひとつの好まし方法は、楽曲にシードの2つのカテゴリを使用することである。すなわち、1)高レベルの歌曲構造を決定し/効果を与えるシード、及び2)決定し/特定の楽器パート及び特性を決定し/効果を与えるシードである。シードの第1のカテゴリは、ユーザが変えられられないが、スタイルサブスタイル及び楽器タイプ選択によって決定され/効果が与えられる。シードの第2のカテゴリは、ユーザによって変えられ、特定のパターン、メロディ、効果、その他に関する。この例の要点は、ある実施例で、最もユーザから遠ざけられる楽曲生成の観点があるということである。この変化は、ユーザが楽曲生成のために使われるシードの部分集合に直接アクセスすることを許容し、そして、それを通じて表現するためにユーザに構造を提供する。シードに関する本説明のこの好ましい実行で、非音楽的に訓練されたエンドユーザが創造的に楽しく聞こえる音楽を作成することができる。
しかしながら、ある場合には、ユーザにいくつか又はアクセス可能な選択の全てを与えることが望ましいこともある。例えば、楽曲の与えられたスタイルのために、特に適宜範囲に発生アルゴリズムが利用できるいくつかのパラメータ値を制限することが望ましく、ある場合には、ユーザが有効範囲を編集することができ、それによって問題のスタイルに若干の影響を及ぼすことが望ましい。別の例として、特定の楽器又は他の構成要素と関連する値の範囲は、歌曲のその楽器/構成要素の典型的役割と関係していてもよい。ある実施例で、受け入れられるパラメータのこの種の範囲は、ユーザがスタイル及び/又は楽器又は構成要素の制約を変えることができるように、ユーザ(例えば、コンパニオンPCプログラム、その他を経て)によって編集可能である。例えば、あるスタイルにおいて比較的高ピッチ可動性を有する楽器タイプ「リード」があってもよいが、ユーザがピッチ可動性に影響することができる「リード」と関連するパラメータを下げることができることが望ましい。マジック音符の線に沿った他の実施例、その他を、また、これらの具体化において都合よく使わうことができる。
本発明の歌曲を記憶する単純なデータ構造(SDS)の好ましい実施態様のさまざまな例を以下に説明する。
PRNGシードの使用は、歌曲を保存するための単純で極めて効率的な方法を可能にする。本発明の実施例において、歌曲はパラメータの小さい一組とともにシードのオリジナルの一組を使用して、記憶される。パラメータの小さい一組は、リアルタイムイベント及び楽曲ルールアルゴリズムに外付けの外部情報を記憶するために好ましい。上のPRNG説明と整合した方法で、PRNGシード値が、楽曲ルールアルゴリズムのための最初の入力として、好ましくは使われる。
図28は、SDSの情報のタイプの若干の実施例の一覧を示す。
「Application Number(アプリケーション番号)」は、データ構造を生成するために用いるファームウェア/アプリケーションのバージョンを記憶するために用いる。ファームウェアがアップグレード可能である場合に、これは特に有用である。そして、SDSは多数のユーザで共有することができる。ソフトウェア/ファームウェアの多数の生成/変化全体の互換性を組み込むとき、SDSを創作するために用いるソフトウェアのバージョンの情報を取得し続けることが好ましい。
「Style/Substyle(スタイル/サブスタイル)」は、楽曲のサブスタイルを示すために用いる。さまざまな変数及びルーチンを初期化するとき、特定のサブスタイルと関連するルールが歌曲生成処理を支配するシステムに警報を出すために、これは有用である。
「Sound Bank(音響バンク)/Synth Type」は、歌曲において使われる特定の音響を示す。これは、好ましくはMidi DSPのための音響設定を予め書き込む方法である。さらに、ある実施例で、これは音波の互換性について調べるために用いることができる。
「Sample Frequency(サンプル頻度)」は、サンプルがどれくらい演奏されるかについて指し示すために用いることができる設定である。あるいは、これはサンプルがデコードされる率を示すことができる、サンプル再生の周波数を調整することに役立つ技術である。
「Sample Set(サンプルセット)」は、音楽のスタイルを伴う全てのサンプルの一覧を示すためにある。これらのサンプルが歌曲の保存されたSDSバージョンにおいて、全てを使うことはできないが、このリストによって、ユーザが歌曲再生の間、更に選んで、関連したサンプルを演奏することができる。
「Key(キー)」は、その歌曲に使用される第一の調子を示すために用いる。これを示すひとつの方法はピッチオフセットを有することである。
「Tempo(テンプ)」は、歌曲の起動テンポを示すために用いる。これを示す一つの方法は、毎分の拍子(BPM)情報を有することである。
「Instrument(楽器)」は、一群の楽器の特定の楽器を識別するデータである。例えば、一群の全てのギターの中の音響ナイロンストリングギターが鳴る。適切なこのデータは、楽器タイプによってインデックスを付けられる。
「State(状態)」は、特定の楽器の状態を示すデータである。状態の実施例は、弱音、非弱音、標準、強制演奏、独奏、その他である。
「Parameter(パラメータ)」は、さまざまな楽器パラメータ、例えば、音量、pan、音質、その他のための値を示すデータである。
「PRNG Seed Values(PRNGシード値)」は、擬似乱数生成(PRNG)ルーチンを初期化するために用いる一連の数値である。これらの値は、歌曲全体の再現を可能にするために、PRNGの本質的に予測可能な性質を利用することによって歌曲を記憶する特に効率的な方法を表す。本発明のこの態様は、図26及び図27に関して更に詳細に論じられる。
SDSのこれらの実施例パラメータの使用で、ユーザ歌曲は、効率的に記憶され共有される。特定のパラメータタイプが可変であるが、この種のパラメータの使用は、この開示のいずれかで論じられたPRNG Seeds同様に、必要な全ての詳細がゼロから歌曲を繰り返すことを可能にする。楽曲が非常に効率的なデータ構造によって忠実に再生されることができる種々の分野において、この種の装置の使用が有利であると思われる。
図29は、本発明を実施するためにSDSと結合して使うことができる一般的アーキテクチャのための論理フローチャートを表す。このフローチャートは、好ましいソフトウェア/ファームウェア実現のための概念を記述するもので、更に、歌曲がどのようにシード値を使用して、効率的かつ対話的に生成されるかについて詳細に記述する。
図29の開始時に、シード値の最初の一組は、データファイル(例えば、SDS)から書き込まれるか新たに決定される(例えば、複合 PRNG方法を使用することは、この開示のどこかで論じられた)。値のこの一組が効果的に決定されて、この時点で歌曲全体のために書き込まれるが、新しく生成された歌曲にある程度のランダム状態を提供するために、必要に応じて楽節にそれらを決定し書き込むだけであることは有利であると考えられる。更に、上記のように、シード値は、2つのカテゴリ、すなわちユーザが変更可能なもの、及びそうでないもの、に分けることができる。若干のシード値が好ましくは決定されて/書き込まれると、与えられた歌曲パートのための楽曲が生成され始められ、そして、ユーザインターフェース(例えば表示、ビデオ出力、圧力フィードバック、その他)が更新することができる。この過程のいかなる時点でも、楽器又は効果の変更のような、ユーザ入力が検出される(「保存」コマンド以外)場合、ユーザによって現在変更されている歌曲のパートのための関連したシードが更新され、そして、与えられたパートのための楽曲の生成が継続する。ユーザ入力の「保存」コマンドが検出される場合、全てのシード(与えられた歌曲のためのまさに関連したシードではなく)は、非一時的記憶場所(例えば、フラッシュメモリ、ハードディスク又はある程度の遂行能力もつ余裕がある他の書き込み可能な若干のメモリ格納場所)に、保存することができる。ユーザが完全にそれを保存することに決める前に、大部分の歌曲を聞くことができるので、望ましい。ユーザ入力がない限り、歌曲パートの終了が検出されるまで、与えられた歌曲パートのための楽曲の生成が続き、その時、 フローは次の歌曲パート部へ進む。この時、必要に応じて、次の歌曲パートのための関連したシードが決定されて書き込まれる。結局、歌曲の終端状態が検出されると、歌曲は終了する。
本発明の歌曲を記憶する複雑データ構造のための好ましい具体化のさまざまな実施例を、以下に記述する。
本発明に対する他の変形において、歌曲を保存し、再生するために、楽曲ルールアルゴリズム(上記SDSの説明を参照)への入力としてのシードに依存して、複合データ構造(CDS)の使用と交換されてもよい。その効率性のために、進み/戻しの互換性が問題でないときに、上記で論じられたシードに基づくアーキテクチャは望ましい。しかしながら、それはプラットフォーム及び/又はファームウェア改訂全体の互換性が要求される場合、望ましくない若干の態様がある。これらの場合、別の実施例の使用が望ましい。
上記の通り、シードは好ましくは単純なPRNGに対する入力であり、歌曲作成アルゴリズムで使用する一連の値が生成される。歌曲保存及び再生のために、繰返し性は不可欠である。しかしながら、アルゴリズムがファームウェアの次のバージョンにおいて変更される場合、又は、他のアルゴリズムが単純なPRNGの使用から利益を得る場合、それが音列(シリーズ)(例えば、図26のDS0−DS3)を計算する中間にあるとき、又は、付加要素が次の楽曲スタイル、その他のために必要とされる場合であって、それらが付加的シードを含んでいるとき、反復性及び戻しの互換性を逆に挿入することができる。これは、本発明のあるアプリケーションにおいては、将来のアップグレードが重要な余裕を有することができ、かつアップグレードの前に保存される歌曲との戻し互換性を保持するために、歌曲を保存するための他のより複雑なデータ構造(コンプレックスデータ構造)が望ましいことを意味する。さらに、ある実施例では、PRNGアルゴリズムがアップグレード可能/変更可能である場合には、シードの使用は望ましくない。
図30は、この種のCDSに含む若干の実施例パラメータを記載する。一般に、この構造と図28に記載されているSDS実施例との間の差は、これが歌曲を再現するためにシード値に依存しないということである。その代わりに、このCDSは、歌曲の実際のデータの中でより多くを捕獲する。そして、SDS実施例より大きいファイルサイズとしてなる。CDSの利用は、上記したようにシード方法と関連して、オーディオストリームと比較して、歌曲を保存する場合により効率的で望ましい手段である。シード方法が10,000の典型的MP3オーディオストリーム上のサイズ減少を与えるが、CDS方法は1,000の概算サイズ減少を与える可能性がある。すなわち100,000のWAV音声のために、サイズ減少は10,000(又は、コンパクトディスクと比較してサイズ減少がほぼ100,000であるとき)としてなる。シード方法より非常に大きいので、これは、CDS方法が従来技術の楽曲記憶のオーディオストリーム方法に勝る利点である。
ある実施例において、CDSにおける更なる差異は、それがリアルタイムにユーザデータ(例えば弱音化、フィルタリング、楽器変更、その他)を保存するという大きな能力を提供するということである。
両方の実施例はそれらの効果を奏するが、ハイブリッドデータ構造(HDS)に各々の態様を結合することが有効である。例えば、また、CDS実施例の複雑なパラメータ(コンプレックスパラメータ)をより多数を組み込むと共に、データ構造の若干のシード値の使用は、互換性及び効率の間で適当なバランスを提供することができる。アプリケーション及び状況に従い、図28のSDS及び図30のCDSの間にあるハイブリッドデータ構造を用いて、これらの2つの目標間のバランスを調整することができる。
図30の実施例において、「アプリケーション番号」、「スタイル/サブスタイル」、「サウンドバンク/合成タイプ」、「サンプル周波数」、「サンプルリスト」、「キー」、「テンポ」、「楽器」、「状態」及び「パラメータ」は、図28に関して上記した好ましいパラメータである。
しかしながら、ある実施例では、歌曲の間、ユーザによって作動される多くのリアルタイムイベントを捕獲することが望ましい。これらの場合、すなわち「Parameter(パラメータ)」なるパラメータを経て、CDSの一部としてリアルタイムデータを記憶することが好ましい。この例では、特定の楽器パラメータに対するリアルタイム変化は、関連タイムスタンプをつけて、CDSの「パラメータ」部分に記憶される。このような方法で、記憶されたユーザイベントは、歌曲再生においてリアルタイムで実行することができる。この種の実施例は、相当に大きなサイズを有するCDSを含むが、ユーザに対して作曲のニュアンスの大きな制御を提供するので、望ましい。
「Song Structure(歌曲構造)」は、歌曲中のパートの数及びシーケンス、並びに歌曲の楽器タイプの数の一覧を示すデータである。
「Structure (構造)」は、そのパートの範囲内のサブパートの数及びシーケンスを含むことができる、パートごとにインデックスを付けられるデータである。
「Filtered Track(フィルタリングされたトラック)」は、効果の特性を記述するデータを保持するために用いられるパラメータである。例えば、それは矩形波及び特定の初期値を有する効果の変調タイプを示すことができる。効果が特定のパートと典型的に関係があるので、このパラメータはパートによってインデックスを付けることができる。
「Progression(進行)」は、各サブパートのための特性情報である。これは、署名、SEQsの数及びシーケンス、マスキングすることができる楽器タイプのリスト、その他を含む。
「Chord(コード)」は、サブパートの期間での楽曲変更に対応するデータを含む。コードベクトル(例えば+2、−1、その他)、キー音符(例えば、F)及び進行モード(例えば、昇順のドリアン)データがタイムスタンプを伴って保存される。
「Pattern(パターン)」及びサブパラメータの「Combination(組合せ)」、「FX Pattern(FXパターン)」及び「Block(ブロック)」は全て、歌曲において使われる各々の楽器のための実際のブロックデータ及び効果情報を含む。このデータは楽器のタイプによってインデックスを付けられる。
「Improv(即興演奏)」は、歌曲が演奏されるたびに異なって演奏される楽器又はマジック音符を特定するためのものである。このパラメータは、それらの即応の要素を有する曲の作成を許容する。
例えば、特定の歌曲と関連する音響バンクデータが組み込まれることを可能にするために、付加パラメータを含むことができる。この実施例に従い、この種のCDSがアクセスされるときに、音響バンクデータを楽曲出力の生成期間中に使うことができるように、音声バンクデータはDSPにアクセス可能な不揮発性メモリに書き込まれる。
図31は、上記で論じられたCDS方法のための好ましい実施例フローチャートを表す。それは、フローのシードが書き込まれ、決定され、更新され、及び/又は記憶される時点で、CDSパラメータデータを書き込み、決定し、更新し、及び/又は保存する点を除いて、図29と同様である。なお、CDSパラメータデータは、「歌曲構造」、「フィルタリングされたトラック」、「コード」、「パターン」、「楽器」、「状態」、「パラメータ」及び「即興演奏」に対応する。
ある好ましい実施例において、プレーヤ10は、PCシステム上で実行し、データリンク(例えば、USB54、シリアルI/O57及び/又は802.11b、ブルーツース、IRDA、その他のような無線リンク)を介してプレーヤ10と通信するコンパニオンPCソフトウェアシステムを具備する。この種のPCソフトウェアシステムは、ユーザにプレーヤ10及び他の場所(例えば、PCハードディスク、インターネット、他の装置、その他)の間でファイルを複製する簡素で有効方法を提供する。例えば、コンパニオンPCソフトウェアプログラムは、オペレーティングシステムのMS−Windowsファミリの下で動作して、ローカルプレーヤメモリ(例えば、SMC)と同様に、プレーヤ10の全ての機能及びモードのために、ユーザへの完全なアクセスを提供する。この実施例によれば、ユーザは、インターネットに接続して、プレーヤ10上で楽曲スタイル又は歌曲に関連すべきカスタマイズされたユーザ選択可能なグラフィクス等のユーザインターフェース関連のファイルと同様に、プレーヤ10(例えば、MIDI、WMA、MP3、カラオケ、CDS、SDS、その他)で使うために適切な楽曲関連ファイルを、アップロードしたりダウンロードすることができる。この種のコンパニオンPCプログラムは、ハードウェア及び/又はソフトウェア管理機能が容易に管理される(例えば、ファームウェア及び音響バンク更新)ことを可能にするために用いられる。このコンパニオンPCソフトウェアシステムは、ユーザに楽曲構成要素及び/又は完全な歌曲を世界中の他のユーザと(例えば、FTPアクセスを経て、電子メールへの添付物として、ナップスターのようなピアツーピアネットワークソフトウェアを経て、等)共有する簡単な方法を提供するために用いられる。ここで留意すべき重要な事項は、潜在的に使用料免除の性質及びプレーヤ10からの楽曲出力の最大のサイズ効率化が、公開ソースファイルを共有するというインターネット環境に、役立つということである。
PCシステムに結合される携帯用システムを含む上記実施例に加えて、又はそれとの組合せにおいて、ある付加的特徴は、ある実施例において好適に使用される。例えば、コンパニオンPCソフトウェアプリケーションは、例えばPCディスプレイを介して、選択されたサンプルの波形と関連するグラフを表すためにサンプル編集モードを提供する。これらの実施例において、マウスのようなポインティングデバイスを介して、ユーザに、サンプルの始点及び終点を容易に選択する方法が提供される。この種の図形切り落とし機能は、ユーザが、例えば望まれていない部分、その他を取り除くために、選択されたサンプルを容易に切り取る(クリップする)ことを可能にする。サンプルのクリッピング/クロッピングの後に、新しく短くされたサンプルファイルを、例えば、新しい名称をつけて保存するオプション選択がユーザに示される。この種のクリッピングに加えて又はクリッピングなしの他の類似した機能は、ディスプレイ及び/又はPCシステムで利用可能な資源処理を使用し、選択されたサンプルの波形のグラフィックバージョンを提供し、そして、持帰りに単純な方法でエンドユーザに選択されたサンプル上での基本操作実行するための簡単な方法をユーザに提供するために、サポートされる。これらの実施例において、新しく変更されたサンプルファイルは、その後、携帯用システムに、例えば、図32のコネクタ53(例えば、USBバス54及びUSBインタエフェイス39、その他を経て)を経て転送可能である。
リンク(例えば、無線802.11)が複数の装置の間に存在する実施例において、装置は協働モードにおいて動作することができる。該モードでは、第1のユーザ及び/又は装置が、楽曲の少なくとも1つの態様(例えば、1つの楽器又は効果)に関するパラメータを管理しており、第2のユーザ及び/又は装置が、楽曲の第2の態様(例えば、他の楽器、又はマイク、その他)に関するパラメータを管理している。これらの実施例において、複数の装置は、楽曲生成に関するある楽曲イベントと同様に、楽曲スタイルに関する情報を交換する。ある実施例において、例えば共通にアクセス可能なデジタルオーディオストリームを経て、結果として生じる楽曲を共通に聞くことができる。さらに、当業者に明らかであるように、ネットワーク(例えば、LAN及び/又はインターネット)に接続されるとともに、1以上の装置がコンピュータである実施例において、上述した協働モードは都合よく利用され得る。
本発明のハードウェア実現実施例のための好ましい具体化のさまざまな実施例を、以下に説明する。
図32は、本発明の一つの携帯用ハードウェア装置35の実施例のブロックダイヤグラムである。内部RAMを含むマイクロプロセッサ(MP36)は、ローカルアドレス及びデータバス(MPアドレス37及びMPデータ38)を制御する。汎用シリアルバスインターフェース(USB39)、スマートメディアカードインターフェース(SMC40)(すでに論じられたように、スマートメディアの変形例として、フラッシュ又は他のメモリカード、又はハードディスク装置等のような他の記憶媒体が本発明によれば使うことができる)、及びフラッシュ41のようなメモリは、MPデータバス38上に存在する。そして、MIDI/音声DSP(DSP42)は、MPアドレスバス37及びMPデータバス38上に好ましくは存在する。SMCインターフェース40はMPDataバス38の間にバッファ59を有し、そして、キーボードインターフェース42(MPデータラッチ44を有して)及びMPバスとも関連するLCDインターフェース45が存在する。この例では、MP36は、入力データストリームからタイミング情報を得て、MIDI情報(この開示のいずれかで論じたNRPN−タイプデータを含む)をDSP42に送信するためにシーケンサとして働くことができる。DSP42は、ローカルRAM48及びフラッシュ49メモリへのアクセスを提供する専用アドレス及びデータバス(DSPアドレス46及びDSPデータ47)をさらに有する。
MP36、DSP42、FM受信機50及びマイク入力51は全て、DSP42に伴うハードウェアCODEC52への数種類の入力を有する。
図32の左上のコネクタ53は、ドッキング局インターフェースとして又は純粋なUSBインターフェース又は外部電源インターフェースと考えることができ、好ましくはUSB54、電源55、蓄電池充電56、シリアルI/O57及び音声I/O58を備えて完成することができる。本発明のドッキング局(ステーション)70のための実施例のブロックダイヤグラムが、図34に示されている。図34に示されているように、ドッキング局70は、ローカルマイクロプロセッサ(LMP71)を含み、USBインターフェース72、アドレス及びデータバス(LMP ADD73及びLMP Data74)、MIDI I/Oインターフェース75及びメモリ(例えば、フラッシュ76)を備える。その上、ドッキング局70は、音声コーデック77、ビデオI/Oインターフェース78、及び電源79を含む。
任意の類似したマイクロプロセッサを利用することができる(オンボードフラッシュ、より多くのRAM、より速いクロックを有して、より低電圧/より低消費電力、その他を有するバージョン等)が、この例のMP36は、ARM AT91R40807である。このARMコアは、32ビット及び16ビットの2セットの命令を有する。16ビットが組み込みシステム(フラッシュ、USB、SMC、その他)でよく動作し、32ビット命令が大容量データが通過する状況で効率的に働くという点で、多様な幅の命令をもつことは、所与のタイプのアプリケーションにおいて望ましい。
命令ビット長を変更することは、本発明の下で容易に可能である。
32ビット命令のために、本発明のシステムは、MP36の内部RAMに、フラッシュメモリ41からある命令を予め書き込む。これは、フラッシュインターフェースが16ビットであり、32ビット命令を実行することは、少なくとも2サイクルを要するからである。また、フラッシュメモリ41には、通常、読出し動作に関連する遅延がある。一つの実施例において、遅延はほぼ90nsである。この遅延は、典型的な読出し動作における多数の待ち状態(例えば、2)の発生の原因となる。逆にいえば、MP36の内部RAMには、読出し動作と関連する非常に少ない遅延があり、したがって、より少ない待ち状態(例えば、0)となる。もちろん、内部RAMはこの場合32ビット幅であり、したがって、32ビット命令の効率が実現される。
フラッシュメモリ41の待ち状態に関する実施例で先に示されているように、内部MP RAMの使用を最大にすることが望ましい多くの理由がある。図32から判るように、本発明のこの実施例は、SDRAM又はRDRAMを含まない。メモリ手段のこれらのタイプをこの種のシステムに含むことができ、そして、この種の使用が本発明の趣旨及び範囲から逸脱するものではないが、図32に表されるような携帯用アプリケーションでは、比較的不必要なもの(例えば、SDRAMコントローラ及びアドレス論理、その他)の使用は、好ましくない。図32の本実施例は、携帯用機器に適している単純な設計で、本発明の多くの利点を達成する。
複雑性及び携帯性と関連するトレードオフの実施例は、マイクロソフトからの広く利用可能なWMAオーディオデコーダアルゴリズムの使用である。この例では、32MHz/3.0Vで図32のARM MPを作動するときに、44KHzで、かつ、128Kbpsのサンプル率でWMA符号化された歌曲をうまくデコードし演奏するために、アルゴリズムをデコードしているマイクロソフトのWMAを組み込むことができる。しかしながら、本明細書のどこかで論じられたように、オーディオストリーム歌曲の速度を調整することができる好ましい特徴も、また、組み込むことができる。この場合、調速を使用してWMA 44KHz歌曲の速度を上げるとき、図32のシステムを実行状態にすることは可能である。この具体例において、ARM MP36が40MHz/3.0Vで作動されるときに、この種の事態は起こらない。しかしながら、40MHz/3.0VでMP36を作動するときに、バッテリ寿命上の重要な性能ヒットが起き得る。それで、ピッチ速度の特徴と結合する44KHzのWMAの使用が比較的不必要なようであるので、この特定の実施例特徴は、バッテリ寿命を長くするために犠牲にしてもよい。以下のような変形を組み込むことができることが明らかであろう。すなわち、より良い電池システム、プラグ接続されたときに全速で、そして電池を使用するときにより遅い速度で動作する段階速度手法、より効率的なWMAアルゴリズム、その他である。しかしながら、この実施例は、競合する必要性が性能と携帯性とで釣り合うことができることを示している。
図32の実施例において、MP36は136KBの内部RAMを含む。上述の性能/携帯性の釣合いは、136KbのRAMの効率を最大にするために、システムに対してある秘訣をこらさなければならないことを示している。例えば、メモリ値域は、好ましくはバッファリング、プログラム、その他のための異なる領域に分けることができ、そして、リアルタイムモード(例えば、WMA再生)で、コードのために使用するパーセントを最大にすることができ、そして、バッファのために使用するパーセントを最小化することができる。他の別の実施例は、フラッシュメモリ41の使用の減少又は省略を可能にする、内部RAM(例えば、512KB)を有するMP36である。この種のシステムは、総経費を増大させる可能性があるが、上記で論じられたフラッシュメモリ41を使用することに関連する複雑さを減少させる。
他の変形は図33に示される実施例である。該実施例は、付加RAM90がDSPバスにアクセス可能である図32のローカルDSP領域を備えている。この種の付加RAMは、迅速かつ頻繁に演奏される大きいMIDIサウンドループを一時的に記憶するために用いることができる。RAM90は、また、予め書き込まれ、かつ迅速に演奏される1又は複数の音響ストリーム(例えば、PCM)を一時的に記憶するために用いることができる。この特徴なしで、リアルタイムで、それが使われるたびに、各々のサンプルは管理されて、MPによってDSPに送られることを必要とする場合がある。これは本発明のある実施態様の課題ではないが、音響ストリームの広範囲な使用が要求されるとき、図33に示すように、この種の付加RAM90を使用することが有利である。そのような場合、図33のRAM90の典型的容量は、好ましくは512KBである。そして、MPは、局所的に保存されたストリームを演奏するための命令を、DSPに送信することを必要とするだけである。
図32に示されるアーキテクチャに関する説明を続ける。図35は、MPの内部RAMのためのアドレスマップのための一つの実施例を記載する。マップの一番下から始まって、下部2つの区分は、しばしば使われるライブラリ及びルーチンを示し、RAMに常に書き込まれる。「マルチ使用」とラベルをつけられる中間部が、SMCからWMA、MP3及び/又は他の同じように符号化された音声歌曲の再生の間、WMA/MP3に関連したコード用として使われる。しかしながら、eDJモードのような他のモードの間、この中間部が、ブロック、歌曲及びSMC緩バッファのために使われる。この領域上の次の区分は、ストリーミング媒体のためバッファとして使われる。この区分は多くの小区分に分けられ、そして、各小区分は一定の間隔(例えば、5.8ms@44.1kHz、16ビット、1Kbブロック)で、DSP装置に送られる。図35の上端は、変数及び一般のバッファのために使用されるMP RAMの多目的領域である。
この例では、プレーヤがWMA/MP3/その他のモードで動作していないとき、「マルチ使用」中間部は、最低3種類のバッファ用として使うことができる。ブロックバッファが、動作中ブロックデータを記憶するために、eDJブロック作成アルゴリズム(例えば、図24及び図25)によって使われる。ブロック作成が起こったあと、歌曲バッファが歌曲データ(図15を参照)を記憶するために、eDJアルゴリズムによって使われる。この歌曲データは、図32に示されるDSP装置に供給される。SMCバッファは、SMCに書込み動作のために使われる。
SMCは、単一のビットの変更を可許容しないフラッシュメモリ技術である。SMCに書き込みを実行するために、全てのSMCブロックを読出し、SMCブロックの所望の部分を更新し、そして、SMCブロック全体をSMCに書き戻ししなければならない。効率のために、現在使用されているSMCブロックがSMCバッファにおいて保持される。
理解し得るように、上記したシステム構成は、SMCへの書き込みをしながら、同時に大きいWMA/MP3ストリームを再生することはできない。このことは、2つの機能のどちらか一方が同じメモリ領域を使用することによる。これは、限られた資源の創造的な使用である。その理由は、SMCに書き込むと同時にWMA/MP3を読出すことは、比較的珍しい状態であるからである。したがって、コードは同じ場所に記憶される。この種の装置は、図32のような携帯用の環境の限られた資源の使用を最大にすることが可能である。
しかしながら、よりパワフルな環境(付加資源及び/又はより速いクロック数を有した)では、メモリの割り当て領域のこの「マルチ使用」を除去することができ、そして、WMA/MP3及び記録機能の同時使用を容易に実現することができる。携帯用の環境に用いられるこれらの付加拡張は、他の本発明の態様を制限するものではなきことは明らかであろう。
上記のシステムは、携帯用であるが、極めて高品質の音響を有する。基本レベルにおいて、これは、部分的にはPCシステムにおける最高級品の音響カードで典型的に見出される音響チップの使用によるものである。SAM9707チップはその優れた音響性能のゆえに好ましい。しかし、これは、本願明細書において論じられる携帯用実施例で動作するようにするためには、ある種々の適合を必要とした。
SAM9707の一つの特性は、それが音響カードのSDRAMと協調するように構成されるということである。このSDRAMは、通常動作の間、MIDI音響バンクを保持する。この種の音響バンクは、DSP対応システムからの出力である楽曲の最終的な音質の重要な部分である。事実、この特定のチップが好ましい他の理由は、カスタム音響を設計することができることである。
携帯用システムについての上記実施例において、アドレス論理と同様に、SDRAMは必要電源を増大させてしまう。したがって、好ましくはローカルDSP音響バンク記憶装置(図32を参照)としてフラッシュメモリを使用して、構成の変形を行うことが望ましい。ユーザにそれらの携帯用プレーヤシステムの音響バンクをアップグレードすることを許容するために、ローカルDSPフラッシュメモリがアーキテクチャのMP側からアクセスされるようにすることが必要となるので、ローカルDSP記憶装置としてのフラッシュメモリの使用は、ある種の問題を含む。DSPバス及びARM MPバスの双方からのメモリアクセスを備えることにより、この種のアクセスは、デュアルポートフラッシュメモリの使用によって得ることができる。しかし、デュアルポートアーキテクチャは、経費及び複雑さシステムに付加する。
一方で低電力/単純なアーキテクチャを保持し、他方で高品質でアップグレード可能な楽曲音響バンクを提供することの間のバラスを適切にするという課題は、DSPチップのモードを適応させて、アドレス論理を、DSPがMP側からローカルDSPフラッシュメモリまでアクセスを提供することに「トリック」されることができる、というような方法で、カスタマイズすることによって好ましくは解決される。
図36は、DSPローカルRAM及びフラッシュ記憶のアドレス空間の実施例を記載する。マップの一番下から始まって、第1の区分は、ファームウェア用であり、フラッシュメモリ領域にアドレス指定される。次の区分は、好ましくは音響バンクであり、フラッシュ領域にアドレス指定される。第3の区分は、信号A24がアクティブな(この場合、A24はアクティブロウすなわち0である)ときに、フラッシュにアドレス指定される。信号A24については、以下でさらに論じられる。開始アドレス0x1000000での第4の区分は、いかなる記憶場所にもアドレス指定されない32KB32KBブロックである。第5の区分は、32KBであり、ローカルDSP RAM(RAMaとラベルをつけた)にアドレス指定される。この領域を対象にするとき、信号A24が好ましくは高いことに注意すべきである。開始アドレス0x2000000での第7の区分は、RAM(RAMbとラベルをつけた)に分解する32KBの区分である。2つの32KBのRAM領域は、望ましくは64KBのローカルRAMに統合される。
それで、特にPC用の音響カードのその意図された状況において、DSPチップの一般的使用に対する本発明の第一の変形は、RAMaのアドレス位置である。DSP−ローカルRAM及びDSPローカルフラッシュメモリの間に、A24のアサートによりRAMaアドレスの宛て先を切り換えるために、この領域は非常に単純なアドレスデコードロジック装置(好ましくはDSPの外部から)を許容するように選ばれる。この変形は、RAMaの特定の位置が起動時にデフォルトによって適切に設定されることを許容するファームウェア変更態様を含む。初期化の後、この位置を変更する他の方法がある。しかし、それらは、より複雑であって、したがって、本方法ほど望ましくない。
DSPチップアドレスマップの意図された状況に対する他の変形は、音響バンクがDSPチップのローカルフラッシュフラッシュメモリに位置する場合であっても(音響バンクのアプグレードのために典型的にアクセス可能でない位置)、音響バンクがアップグレードされることができるDSP BOOTモードの創造的な実現を含む。
この例では、DSPのBOOTモードによって、内部ROMから実行する内部ブートストラッププログラムが生じる。DSPファームウェアをアップグレードする際、このブートストラッププログラムが用いられる。このように、内部ブートストラップは、16ビットのバースト転送ポートから256語を受け取ることを期待される(それはローカルメモリのアドレス範囲0100H−01FFHでそれを記憶することが期待される)。そしてその後、ブートストラッププログラムは、アドレス0100Hで制御を再開する。この比較的小さいバーストは固定されており、音響バンクを含むには十分な大きさではない。さらに、上記のようにSMCと関連して、それは複合フラッシュメモリ書込み動作を可能にしない。SDRAMの代わりにフラッシュを使用する設計なので、ARM MPバスからRAMまで特別なコードの転送を実行するために、ROMブートストラップを「トリック(取る)」するコードをローディングするために、このブートストラップバーストを使用することがたいへん望ましいことがわかった。そして、この特別なコードは、ARM MPバスからフラッシュメモリまで、音響バンクアップグレードデータの転送を実行するために用いられる。
図37は、DSPブートストラップモードアドレス概念のこの珍しい使用において付加情報を提供する単純な真理値表である。図38は、珍しいDSPアドレス論理の効用を強調する、より詳細な真理値表であり、BOOT信号を用いて、ARM MPによって制御可能なA24信号の好ましい使用を含む。
本実施例では、DSPによって生成されるA24アドレス線は、DSPローカルメモリのロジックをデコードしているアドレスに提示される前に、MPによって制御されるBOOT信号によって変えられる。この手段によって、MPがDSPによるRAM及びBOOTモードのフラッシュ選択を逆にすることができ、そして、RAMがアドレス0x100で利用できるために、RAMがアップグレードコードを受信することができる。
上述されたハードウェア装置に対する付加変形も考慮することができる。例えば、電力レベルが増加し、そして、MPパフォーマンスが増加する場合、DSPはソフトウェアDSPに置換することができる。その場合、音響が低質として可能性があるが、より低いコスト、付加柔軟性等の、それを上回る他の利点を生じる。DSPは、同様に、低質な音響の結果となる可能性があるが、携帯性の利便性等の利点が上回る汎用ハードウェアDSPと取り替えられることができる。MPは、より多くの統合インターフェース(例えば、USB、SMC、LCD、その他)及び/又はより多くのRAM、高速クロック、その他を有するものと置換することができる。いくつかの開示された実施例に対する2、3の変更を加えて、DSP(別個のMPでない)だけ又はデュアルダイDSP/MP又はMP及びソフトウェアだけを有する本発明を実施することができる。加えて、オーディオ出力を保存するために、SMCメモリ記憶装置は、組み込み暗号を有するセキュアディジタル(SD)メモリカード及び/又はハードディスク装置、コンパクトフラッシュ、書き換え可能なCDROM、その他に代用できる。また、LCDは、他のレベルのユーザインターフェースを許容するカラー又はマルチレベルグレーLCD及び/又は接触検知ディスプレイにアップグレードできる。
本説明の更なる変形は、ユーザインターフェースに付加的に望ましい特性を提供するために、Synapticsから入手可能なTouchPadのような、電磁性か容量性のタッチパッドポインティングデバイスの組み込みである。前述のタッチパッド及び接触感応ディスプレイは、ユーザに対して、リズムにあわせてたたくための及び/又は音符/コードをつま弾くための方法を提供するために用いることができる。この種の装置は、特定の楽器グループの操作により近い近似を可能にするために、用いることができる。例えば、タッチパッドは、ユーザが指又は手をタッチパッドの表面を横切って動かす方法から、ユーザの所望のギターパートの速度及びリズムを検出するために、用いることができる。同様に、この種のポインティングデバイスのx及びy座標を通して、ユーザ手の動きは、ピッチ及び/又は楽器の周波数、又は効果又はサンプルの特性と関連して検出することができる。他の例では、タッチパッドポインティングデバイスは、また、従来のDJがターンテーブルによって生成することができるスクラッチ音響に近似しているターンテーブルスクラッチ音の生成/制御を行うために用いることができる。
図32に示すように、本発明において使うことができるDSPの一つの実施例は、Atmel社の子会社、Dream S.A.から入手可能なSAM9707チップである。この特定のチップは、入来するMIDI及びオーディオストリーム情報を扱うことが可能である。
DSPを生成的/対話的な楽曲システムに組み込むとき、MIDI及びオーディオストリームを同期させることが非常に望ましい。毎回、サンプルを正しい時間、正確に演奏しなければならないが、オーディオストリーム構成要素がMIDIイベントとの同期から僅かにずれたとき、結果として生じる楽曲の出力は、通常許容しがたいものである。SMC技術が反応するのが遅くて、複雑な読出し方策が必要であるという点で、生成/相互対話概念において、オーディオストリーム及びMIDIのミキシングのこの微妙な性質は、フラッシュ読出し処理の性質によって悪化する。フラッシュ記憶場所から正確に音声の再生をMIDIイベントに同期させることはむずかしい。サンプル(MIDIイベントと比較して)をデコードして、演奏することの遅れのため、タイミング補償を実行するか、又は比較的大きいデータバンクを予め書き込むかにトレードオフがある。これらの問題のため、DSPチップとともにMIDI及びオーディオストリームを使用する新規な方法を構成することが好ましい。本発明の本態様がDSPアーキテクチャに関して論じられるが、以下の実施例が他の類似したアーキテクチャにあてはまることは、MIDI/オーディオストリーム同期の分野における当業者にとって明らかであろう。
図39は、楽曲生成処理におけるMIDI及びオーディオストリームの簡略化した論理的配列を示す。Synthへの2つの入力は併合され、デジタルオーディオ出力信号に変わる。この出力信号は、それからデジタル−アナログ変換器(DAC)に供給され、ヘッドフォン等で使う適切なアナログ音声信号となる。この実施例では、Synthに対するMIDI入力は、比較的速いメモリ手段(例えば、SRAMバッファ)から供給されるが、Synthに対するオーディオストリーム入力が比較的遅いメモリ手段(例えば、フラッシュメモリ)から供給されることに注意する必要がある。
Synth装置に対する2つの入力は、実際に多重化バスを共有することができる。しかし、論理上、それらは別に識別可能な入力と考えることができる。一つの実施例において、2つの入力は、16ビット幅のバスを共有する。この場合、MIDI入力はあるには好ましくは8ビットを占め、そして、オーディオストリーム入力は他の時間に16ビットを占める。この実施例に従い、一つのストリームは休止することができ、他のストリームがバスを獲得することができる。同じバスのこの種の交互使用は、各々のストリームの比較的小さい中断が常に起こっていることを意味する。この種の休止はごくわずかであり、したがって、ここではその目的のために、2つのストリームは別個であると考えることができる。
図40は、簡略MIDI/オーディオストリームスケジュールを示す。図40がブロックのまさしくその始まりのためのタイミングであると仮定する。この場合、設計者がMIDI音符の演奏を望み、ブロックの始まりから250ms後に開始して500ms続くものとする。音符の継続期間は、演奏されている音符のタイプに関係する。例えば、それが4/4拍子の四分音符で、2秒の拍子持続期間をもつ場合、500msは四分音符持続期間と一致する。また、図40に示すように、短い音声サンプル「yo」のようなオーディオストリームイベントが、MIDIイベントの中間で起こるように同期される。サンプルを楽曲状況に同期させることによって、ユーザ側の小さいタイミングエラーの微妙な修正を含むことができるという意味で、この方法によってサンプルが、楽曲に好ましくは量子化されることができる。
この例では、主に上述したシステムアーキテクチャ実施例の制約のために、従来の技術を一貫して正確に使用する上で、些細なものでない。オーディオストリームイベントが、ARM MPからの1又は複数のアシスト(SMCから音響をとってくること、解凍すること(PCM,その他)、音響効果を加えること(残響、フィルタ、その他))を必要とすることを考慮すると、MIDIイベントが、Synthチップによってほぼ直ちに生成されることは好ましいことである。
この例では、各々のイベント及び専門的な非登録パラメータ多数(NRPN)のためのデルタ拍子情報を含んでいる特別なMIDIファイルを創作することが望ましい。サンプルリスト(上記したような)によって使われるときに、リストの特定サンプルの名前が内在するので、この特徴は特に有利であり、そして、NRPNは、好ましくは特定のサンプル名又はタイプを明示的に必要とすることのない特定のサンプルリストの異なるサンプルを起動させるために、用いることができる。この種の最適化は、名前で特定サンプル又はタイプを取ってくるロードを軽減し、使用するサンプルが予め書き込まれることを許容する。以下の説明において、ある実施例では、MIDIシステム独占(Exclusive)メッセージ(SYSEXs)の使用が、NRPN代わりに(又はそれに加えて)使われる、と理解すべきである。
図41は、音声サンプル及び効果を有するMIDIイベントの効率的な同期を可能とするために本発明に組み込まれるMIDI NRPNの実施例を表す。左欄は、MIDI NRPNストリームを形成している16進値を表す。MIDI仕様書(先に引用組み込みしたものとする)に関し、従事する誰もが理解するように、MIDI NRPNは、MIDIストリームの部分のカスタムメイドの使用を可能にするデータ構造である。したがって、それは、与えられたアーキテクチャのための特定のカスタムイベントを起動させるために用いることができる。
図41において、それが第1の16進値「B0」は、MIDIコントローラコマンドであり、チャネル番号を示す。これは、マルチチャネル装置の経路選択を助けるために用いることができる。本実施例において、単純性のために、チャネル0が設定されているものとする。第2の値「63」は、この特定のストリームが特定のコントローラ(例えば、「A」)のためのNRPN情報を含むことを示す。この例では、NRPNコントローラAは音声サンプルタイプを示すために、ファームウェア/ソフトウェアによって理解される。第3の列値「40」は、コントローラと一致するデータであり、実施例では、このデータはサンプルのタイプを記述する。この装置の効用の例として、タイプが「長音」と設定される場合、ファームウェア/ソフトウェアはかなりの量のサンプルを書き込むよう手配することができる。他の例では、サンプルのこの「タイプ」は、長いサンプルと短いサンプルとを区別するために用いることができるので、アルゴリズムが自動作曲の間、それらを別々に使用することができる。第4の列は、MIDI ticksにおけるデルタ時間を示し、正確に次のイベントを計時するために用いることができる。説明を簡単にするため、この例において、このデルタ時間は「00」に設定されるものとする。第5の列は、この特定のストリームが「B」コントローラのためのNRPN情報を含むことを示す。この例では、NRPNコントローラBは、音声効果タイプを示すために、ファームウェア/ソフトウェアによって理解される。これは、MIDI NRPNを経たタイムリな方法で、効果的に制御されることができる特定の音声効果を含むMIDI DSP構成要素を使用することが有利であるとわかったからである。第6の列は、このNRPN実施例において要求される特定の音声効果タイプの確認を示す。説明を簡単にするために「00」を示すが、MIDIストリームのこの部分の値が特定のアーキテクチャのための有効音声効果の中から特定の効果を選ぶために、ファームウェア/ソフトウェアによって解釈される。第7の列は、遅延とみなされる他のデルタ時間を示す。第8の列は、ファームウェア/ソフトウェアに第9列に示されるNRPNコントローラA値を記憶するレジスタの確認を示すために、用いることできる。例として第9の列は、「03」を使用するものとする。これは、歌曲(図29及び図30の「サンプルリスト」を参照)に対応するリストの第3の音響サンプルを意味するように、解釈される。値「00」は、ファームウェア/ソフトウェアにランダムにサンプルリストからサンプルを選ぶように指示するために用いることができる。図41の第10の列は、他のデルタ時刻値(例えば、「00」は0のMIDI ticskである)である。第11の列は、ファームウェア/ソフトウェアに第12列に示されるNRPNコントローラB値を記憶するレジスタの確認を示すために用いる。例として第12の列は、「07」を使用することにする。これは、MIDI DSPに利用できる音響効果中の特定の音声効果を利用するように指示するために、ファームウェア/ソフトウェアによって解釈される。
図42は、上の実施例の線に沿った特別なMIDIタイプファイル(すなわちARM MPから好ましくはMIDI入力ストリームを経たDSPまで送られているデータの配列の実施例)の簡略描写である。
図の最上部は、このファイルの第1の情報が250msのデルタ時間であることを示す。これは、図40の初めにおける250msの遅延と対応する。図42において表されるファイルの次は、チャネル1、ピッチCのためのイベントの音符を示している一般のMIDI情報である。250msが経過するとき、これは図40の時間と一致する。次に図42において、別の250msのデルタ時間がある。これは、前のMIDIイベントと図40の500msにおける次のオーディオストリームイベントとの間の時間を示す。次に、図42で、さまざまなパラメータP及びさまざまな効果Eとともに、オーディオストリームイベントXを演奏することを必要とすることをSynthチップに知らせるNRPNメッセージを受け取る。これは、図40において表されるオーディオストリームイベント(「yo」)と一致する。次いで、図42において、250msの他のデルタ時間イベントを有し、該時間イベントに続いて、チャネル1、ピッチCのための音符オフイベントを示している一般のMIDI情報を含んでいる。この最終ステップは、図40(例えば、「C」四分音符)のMIDIイベントの終わりに対応している。
前の実施例において、特別なMIDIタイプファイルにおけるデルタ時間は、毎回(そして、しばしば)異なることがありる。簡略例において、四分音符、その他を有するタイミング関係を作りたいという理由において、毎回同じ250msの値を使用したが、より複雑なファイルではデルタ時間が変化することは明らかであろう。
その上、図2のプレーヤ機能キーの実施例に関連して上記したように、ある実施例において、ボタン押圧の速度を検出することが好ましい。これらの実施例の多数において、ボタン押圧が、例えば、サンプルイベントを起動するとき、演奏されるサンプルを起動させるMIDI−タイプイベントに、ボタン押圧イベントの検出速度−タイプ情報を転送することが好ましい。これらの実施例において、速度、アフタータッチ、音量、その他に指定されるイベントの部分で、速度−タイプ情報が、MIDI−タイプイベントにおいて示すことができる。その上、システム独占メッセージ、又はNRPNメッセージのようなMIDI−タイプイベントを択一的に使うことができる。
前述したように、本発明に従って、声音及び他の音声サンプルは符号化することができ、記憶することができ、再生のために処理することができる。ある好ましい実施例において、声サンプルは、PCMフォーマットで、好ましくは適合型(予示型)差動PCM(ADPCM)フォーマットの形で符号化される。他のPCMフォーマット又は他のサンプル符号化フォーマットも本発明において使用可能であり、特定のPCM符号化フォーマット(そして、効果を提供する方法が以下に記載されている)が、さまざまな本発明の態様を実施する上で重要でないが、典型的なADPCMの説明はある効果機能と同様に本発明の好ましい実施例のより完全な理解のために提供される。本発明のこの種の実施例によれば、一種のADPCMは、効果を奏することができる。
本願明細書における開示に基づいて当業者が理解できるように、ADPCMの使用により、データファイルに減少された容量で(それは不揮発性記憶装置(例えば、SMC)において好ましくは記憶される)、サンプルを記憶することを可能にする。このように、より多くのサンプル、歌曲リスト及び歌曲が不揮発性記憶装置の所定の容量に記憶されることを可能にする。好ましくは、符号化は、ADPCMフレーム(例えば、8つのサンプル)のサイズのパケットによって行われる。各パケットのために、コードは最高値を提供し、2つのサンプルの間の最大差が、符号化されてファイルに記憶される。各々のコード(サンプル(delta_max)とパケットのコード(diff_max)の差)は、4ビットを使用する。この実施例に従って、データ/サンプルは、したがって、(8*4+4)/8=4.5ビット/サンプルである。
明らかなように、この種の符号化は、本当に必要であるものだけを符号化することを試みる。8つのサンプルで、2つのサンプル間の最大差は一般に、信号(+32767/−32768)の可能なダイナミックレンジよりもはるかに小さく、そして、サンプルの間の差だけを符号化することが可能である。好ましくは、ADPCMは、比較的変化しない声音に適するように選ばれる。予測フィルタリングによって、新規なサンプル及びその予測の間の差を減少することが可能である。遭遇する平均差を考慮すると、予測がより良くできれば、差は小さくなり、そして選択される符号化(量子化)の量も小さくなる。この方法が予測計算のための付加的な計算能力を必要とすることはいうまでもないが、この方法が、本発明に受け入れられるサンプル符号化品質を有するサンプルのための減少された記憶の重要な効果を提供すると考えられる。従来の又は標準化されたADPCMは、遅延を導入することのない符号化時間を提供することを必要とするが、本発明では、この種の属性が重要でない。
予測型ではなく、生じた差の平均値だけへの考慮をしない単純な符号化は、非定常状態(例えば、語又は音節の各初め)では良好に反応しない。各新語又は音節にとって、以前に生じた平均差よりはるかに大きい新しい差は、最適に符号化することができない。したがって、信号のレベルによっては、インパルス雑音が生じる傾向がある。解決方法は、したがって、生じる差(したがって、8つのサンプルの遅延があり、したがって予測は量子化だけのためになされる)の最大値を、固定数のサンプルのために与え、そして、この最大差(パーセントで)の関数として、サンプルを符号化することである。符号化は、各瞬間でより最適化される傾向である、非常によく非定常状態(語又は音節の各初め)に反応する。好ましくは、符号化は対数的であり(耳は対数符号化に敏感であるが、直線符号化に対してはそうでない)、信号/雑音比率は24dBである。好ましい実施態様において、この機能は、例えば、3倍速で実行される(外部フラッシュメモリ内での各々のインストラクションのための1(3の代わりに)クロックサイクル)ように備えられた内部RAMに、記憶される。
ある種の効果が、本発明の実施例において使用するADPCM符号化に含まれる。例えば、それが最終固定数が256個であるサンプル用として、ADPCMサンプルの可変数を必要とするので、ドップラー効果がADPCM復号化に含まれる。既に知られているように、この種のドップラー効果は、より速く又はより遅くサンプルを演奏することからなり、ピッチの変化とともに速度の変化が付いてくる復号化声音のピッチの変化と対応する。自然で直線的変化を与えるために、他の2つのサンプル間に新規なサンプルを差し込むことが望ましい。それにより、不快な高振動数高調波を耳に加える傾向があるという点で、直線補間方式は不利益があると考えられてきた。
伝統的に使用される方法は、信号(例えば、3又は4の比率の)をオーバサンプリングし、そして、生じた周波数をフィルタリングすることからなる。フィルタリングされた信号は、線形補間される。この方法の不利な点は、それが付加的な計算機能を必要とするということである。ある実施例に従えば、4つの隣接したサンプルを有する信号を補間する技術が利用される。それは、直線補間によってつくられる高調波に対して4.5dBの利得を許容する第2の順序補間と一致する。4.5dBは低いように思われるが、声音信号の弱い高周波においてそれを考慮することが重要である。声音の最初の高周波数はリニア方法の場合の低い周波数の上部高調波によってマスキングされ、そして、この効果は第2の順序補間によって消える。さらに、それは、オーバサンプリング法より3倍速い傾向がある。この機能は、例えば、3倍速で実行される(外部フラッシュメモリ内での各々のインストラクションのための1(3の代わりに)クロックサイクル)ために備えられた内部RAMに記憶される。
また、好ましい実施態様に従えば、基本周波数から演繹するために、分析ウィンドウ内で期間番号(ピッチ)を計数することからなる周波数分析機能が含まれる。この機能は、期間を現すためのサンプル処理に利用することができる。一般に、信号が時間とともに変わる(例えば、必ずしも完全に調和しているというわけではないピアノストリング(弦)1〜3を鳴らすこと)傾向があるので、ウィンドウのピークを計数することは可能でない。さらに、同じ期間で、複数のピークがあることがある。この種の実施例に従えば、分析ウィンドウの始めに考慮される参照と個々の部分ウインドウの間の距離は、一つのサンプルだけシフトした。したがって、2*WINDOW_SIZEサンプルのウィンドウ及びWINDOW_SIZEサンプルの参照ウィンドウに関して、WINDOW_SIZEサンプル上の距離のWINDOW_SIZE計算を行うことができる。距離の計算は、参照サンプル及び分析サンプルの間での差の絶対値の合計によって計算される。この機能は、例えば、3倍速で実行される(外部フラッシュメモリ内での各々のインストラクションのための1(3の代わりに)クロックサイクル)ように備えられた内部RAMに記憶される。
また、この種の実施例に従れば、ウフォブラー、フランジ、エコー及び残響のような特殊効果を、ADPCM符号化とともに提供することができる。この種の特殊効果が、ADPCMデコーダ及びドップラー効果から得られる256個のサンプルを通じて、生成される。この機能は、例えば、3倍速で実行される(外部フラッシュメモリ内での各々のインストラクションのための1(3の代わりに)クロックサイクル)ように備えられた内部RAMに記憶される。好ましくは、サンプルの平均値が計算され、そして、それについてのwobbler機能を実行することを避けるために、平均値(サンプルを通じて存在する)がサンプルから減じられる。wobbler機能は、不快なヒス音を出す傾向がある信号中の変調周波数を増大させる。好ましくは、wobbler効果のための方法は、サンプルにサイン関数を乗じたもの(当業者によってよく理解されるように、適切なwobbler周波数に基づいて)基づく周波数変調である。
また、好ましい実施態様に従えばて、フランジ効果の目的は、複数の人が話しているか又は単一のソース声音によって歌っているという印象をシミュレーションすることである。計算能力を制限するために、2つの声音がシミュレーションされる。この印象を提供するために、ソース声音のピッチが変更され、オリジナルのソース声音に加えられる。最も正確な方法は、ボコーダを用いて声音を分析することであり、また、速度を変えずにピッチを変更することである。いずれの場合においても、男性及び女性が一緒に歌っているという印象を有することができる。但し、この種の方法は、通常、DSP資源を必要とする。速度(声音が同期式ままであることを望むなら重要)を変化させることなくピッチを変更する方法は、サンプルを交互に加速/減速することによって、第2の声音をシミュレーションすることから成る。その後、前述のドップラー効果を発生するが、それは、僅かに異なるピッチ及び同期式声音を有するような方法で、ゼロ周辺で交互に変動するドップラーである。この種の実施例については、例えば、軸上で規則的に回っている直径4メートルの円上に存在し、かつ、静止している別の人のそばに来た人をシミュレーションすることができる。
また、この種の実施例に従えば、エコー効果は、ソースサンプルと遅延性サンプルの合計であり、残響効果は、ソースサンプルと、利得係数に影響を受ける遅延性サンプルの合計である。遅延性サンプルは、好ましくは環状バッファに記憶され、合計から得られるものである。残響効果の式は、以下の通りであってもよい。
Sample(0)=sample(0)+sample(−n)*gain+sample(−2*n)*gain^2 +sample(−3*n)*gain^+ … +sample(−i*n)*gain^i.
好ましくは、利得は発散を避けるために1未満であるように選ばれる。好ましい実施態様に従えば、バッファの大きさ(それは、適宜でありえる)のために、エコー効果は残響効果のそれと同じバッファを使用する。真のエコーを得るために、残響にゼロであるか低い利得効果を与えることが必要である。2つの効果は同時に機能することができる。新しいサンプル及び古いサンプルの間の遅延は、メモリバッファに入れられた最も古いサンプルを読出すことによって生成される。新規なサンプル毎にバッファがシフトすることを避けるために、バッファの読出しポインタを増分させ、バッファの境界の間で、このポインタを制限する。メモリバッファの容量は、したがって、サンプル間で時間に依存する。
また、この種の実施例に従えば、電子チューナ機能が提供される。その狙いは、楽器によって演奏される音符を与えるために到来するサンプル信号の基本波を見つけることにある。すでに記載したことと同様に、好ましい方法は、期間の計算の精度を増やすために、複数の期間からなる所与の時間毎に、その複数の期間の数を計算することを含む。実際には、単一の期間は、この期間がサンプリング用として不十分であり、精度が低い。期間を検出するために、信号の始めの参照と信号との間の距離を計算するルーチンを使用する。理解されるように、期間は、第一及び最後の期間の間に存在する合計数によって分けられる最後の期間の位置である。最後の期間の有効位置は、2つの距離サンプルの間の実際の最大の補間によって計算される。このように計算される期間は、反転(64ビット/32ビットの割算を使用して)によって大きな精度(ノイズのない信号のための1/4000より良好で、そのような場合はしばしばある)を有する基本周波数を与える。
また、この種の実施例に従えば、低域フィルタ(又は他のフィルタ)機能が、ADPCMサンプル符号化によって得られる効果の一部として提供される。低域フィルタを有するこの種の機能によって、前述のルーチンのために距離の計算に使用したサンプル中の高い周波数を除去することができる。これらの高周波数は、該周波数が極度に上昇する場合、計算を妨げる傾向がある。フィルタリングは、距離の計算のために使用するバッファを正規化するために、最も高い値を探すことによって行われる。
また、本発明によれば、多くの望ましい本発明の観点によって用いることができる多数の付加実施態様及び変形がある。大きな効果を奏するように本発明を使用する方法には、他の製品との一般的な統合と伴に、ソフトウェアベースの方法が含まれる。その上、特に媒体内容管理、ビデオとの統合及び他の雑多な変形に関して、本発明に対する有益ないくつかの変形が使われ得る。
多くの本発明の観点は、デジタル/ビデオライトショーと関連して、好適に使用することができる。「Digital lighting Control System」と称する米国特許第4,241,295号、及び「Control System for Variable Parameter Lighting Fixtures」と称する米国特許第4,797,795号(それらの全部において本願明細書に取り込んだものととする)にさらに詳細に記述されているように、ビデオ及び/又はステージ−タイプの照明系統の制御は、デジタル命令(例えばMIDI−タイプ記述子イベント)を使用して実行することができる。したがって、ここで記載されている実施例において、この種の種類のビデオ/光制御システムを有する楽曲生成の態様を組み込むことが好ましい。例えば、音楽的イベント及び視覚的イベントを同期させることができ、一時的に量子化し及び/又はパラメータ(例えば、デルタ時間、速度、NRPN、システム独占、その他)を使用して調整することができる。楽曲(例えば、前奏からコーラスまで行く)の重要な変更が、映像のタイミング及び/又は強度、カラー、パターン、その他と符合するように配置することができる。このような実施例では、音声/映像出力を視聴している人の体験は改良される。
さらに、ある実施例において、可視ディスプレイは、楽曲(好ましくは、ユーザによって作成されてもよい)によって強調される動画のキャラクタ(例えば、音楽家)のみから構成されるか、又はそれらを含む(また、ある場合には、本明細書のどこかで述べた携帯電話の着信音)。この実施例に従えば、可視ディスプレイは、動画背景を含むことができ、それによって、動画キャラクタが背景動画上で演じているように描かれる。
電話を含んでいる実施例において、視覚の動画は、電話の呼出音(そして、ある場合には、電話リングは、この開示の全体にわたって記載されている他の実施例のあるものを使用することができる)で表示を始めることができる。動画のキャラクタは、例えば、送信される発信者番号通知サービス情報に基づいて、呼出し元を示し、識別するために、前もって割り当てられていることができる。この機能によれば、ユーザは、カスタムメイドの動画及び/又は楽曲(好ましくは呼出し元のアイデンティティに基づく)を再生する能力をもつことができる。
多くの本発明の態様は、ソフトウェアベースに組み込んで実現することができる。例えば、上記説明したハードウェアDSPは、信号処理機能(を実行するために、ソフトウェアシンセサイザによって置換することができるハードウェアベースのシンセサイザの使用は、本発明の必要条件でない)。この種の方法は、例えば、現代のパーソナルコンピュータの過剰処理電源を利用して、また、多数のプラットフォーム(例えば、いかなるPCでも演奏することができる楽曲を共有することは容易である)全体のより大きな互換性を提供すると共に、ハードウェアベースの手段で生産される楽曲と同様な品質を提供する。ソフトウェアベースで本発明の実施例を構成することは、付加的な変形を可能とする(例えば、プロの音楽作者又はアマチュア音楽ファンへ適合させる自己内蔵型アプリケーション)。その上、ユーザのコンピュータ上のローカルファイルに記憶されるユーザ選択及び/又はカスタム情報(例えば、クッキー)で、ウェブサイトでの使用のために、本発明のソフトウェアに基づく実施例を構成することが好ましい(例えば、ジャバ言語アプレット)。この種の方法は、ユーザが「stick(刺さる)」し、該サイトへの次の訪問で残存する楽曲伴奏スタイル選択を示すことを可能にする。ソフトウェアベースの方法の変形は、既存の内容生成ソフトウェアプリケーションへの「ソフトウェアプラグイン」方法(Macromedia Flash、Adobe Acrobat、Macromedia Authorware、Microsoft PowerPoint及び/又は Adobe AfterEffectsのような)を含む。この種のプラグインにより、潜在的に使用料無料の楽曲から利益を得ることができ、ある実施例では、対話的に生成された音楽作品をフラッシュプレゼンテーション、PDFファイル、Authorwareプレゼンテーション、AfterEffects映画、その他への算入のために転送することが好ましい。
本発明の実施例は、複数のユーザが、好ましくはリアルタイムで、協力感覚で一緒に対話的に楽曲を生成することを可能にするインターネットに基づく仕組みを提供することができる。カスタマイズされた楽曲を含んでいる本発明の態様は、音楽ゲーム(及び/又は学習補助)、ニュースソース(例えば、インターネットニュースサイト)、言語ゲーム(及び/又は言語学習補助)、その他の一部として組み込まれることができる。その上、本発明の多くの機能及び利点を組み込んでいるソフト/ハードのハイブリッド方法は、個人コンピュータシステムの高速バス(例えば、IEEE1394又はUSB、その他)にアクセスするハイブリッド「DSP」モジュールを含むことができる。この種の方法において、MP36の機能は、個人コンピュータシステムによって実行されることができる。その一方で、DSP42の機能は、周辺バス(例えば、USB)に取着されるハードウェアモジュールに置かれるDSPによって実行することができる。この実施例に従い、ほぼ自動車キーと同様なサイズの小型USBモジュールを、PCシステムのUSBポートに挿入することができ、アルゴリズム楽曲の対話的自動生成と関連するハードウェアDSP機能を実行するために用いることができる。
明らかなように、多くの有利な本発明の態様は、携帯用通信装置(例えば、移動電話、PDA、その他)において実現可能である。例えば、デジタルカメラ(例えば、内蔵イメージキャプチャ装置(2003年にノキアグループから入手可能であると思われる)を有するノキア3650移動電話と同様の)を組み込んでいる携帯用通信装置の場合、好ましい実施例は、携帯用通信装置でアルゴリズム的な楽曲生成/自動作曲機能を使用することを含む。この実施例に従えば、この種の実施例の一部としてのデジタル像キャプチャ装置の使用によって、ユーザが1又は複数の画像(動画又は静止画)を撮ることができ、好ましくはスライドショーとして、それらを楽曲に設定することができる。楽曲(例えば、図28〜31に例示されて、本願明細書において議論されるSDS及びCDS構造及び特徴)を記憶することを必要とするデータ構造が比較的効率的であるため、この種の拡張イメージをシステム間で交換することができ、したがって、携帯用のこの種の通信装置が利用できるバンド幅が比較的制限されていても、このようなスライドショーの配信が可能となる。
明らかなように、本発明の態様は、種々のシステム及びアプリケーションに組み込むことができ、その例示として、PBXか他の電話タイプシステムを上げることができる。典型的なシステムは、例えば、Pang他に対する米国特許第6,289,025号等に開示されている。そして、それは本願明細書に取り込んだものとする(他の典型的なシステムは、アルカテル、エリクソン、ノーテル、アバイアのような会社からのPBXシステムを含む)。典型的なこの種のシステムから理解できるように、複数の電話及び電話インターフェースがシステムとともに提供され、システムが位置する施設でのユーザ、又は、外部からシステム(例えば、POTS電話線又は他の電話線を経て)にアクセスするユーザは、システムが受信した通話(呼出)を受けることができる。この種の通話は、システムによって特定のユーザに向けられるか、あるいは、通話はホールドオン状態に(典型的なこの種のシステムのこの種の態様は、従来通りであり、本願明細書においては詳細に記載されていない)おかれる。一般に、ホールドオン状態の楽曲は、無線局から得られるホールドオン楽曲、又は、オーディオ入力で結合されて、コーダーで処理され、オーディオストリーム(PCMのような)として提供され、ホールドオン状態の呼び出し元の電話に結合されるテープ記録されるか他の記録された楽曲により、ホールドオン状態の呼び出し元に提供される。
本発明の実施例に従えば、1又は複数のモジュールが、ホールドオン状態の呼出し元にホールドオン楽曲を提供する典型的なシステムに具備される。この種のモジュールは、PBX−タイプの環境に適応するユーザインターフェースを備えていないが、例えば、本願明細書のどこかで記載されているように(例えば、図32及び関連した説明を参照)(この説明のために、この種の組成のハードウェア/ソフトウェア構成要素は、「自動作曲エンジン」と称する)、プレーヤに必要なハードウェア/ソフトウェア構成要素を含むことができる。そのような典型的な実施例においては、1又は複数の自動作曲エンジンは提供される。そして、それは、ホールドオン状態にある1又は複数の呼出し元にホールドオン楽曲を提供するのに役立つ。一つの実施例においては、単一の自動作曲エンジンが備えられ、そして、ホールドオン状態の第1の呼出し元は、まず最初に、自動作曲エンジン(又は、典型的なシステムを制御しているプロセッサ)によって定まる特定のスタイルの自動作曲された楽曲を贈られるによって定まる特定のスタイルの自動作曲された楽曲を贈られる(これは、また、典型的なシステムの構成パラメータによって選ばれるホールドオン楽曲スタイルの不履行であってもよい)。好ましくは、典型的なシステムの資源によって提供される音声プロンプトにより、ホールドオン状態の呼出し元は、ホールドオン状態の呼出しに提供されているホールドオン楽曲のスタイルを変更できることを示す音声情報を提供される(この種の音声の迅速生成は、この種の典型的なシステムの概念において従来通りであり、本願明細書においては更に詳細に記載されていない)。好ましくは、ユーザは、電話キーボード上の予め定められた数字(それは、音声プロンプトにおいて好ましくは識別される)を押圧することによって、この種の要求を示すことができる。そして、それは典型的なシステム(この種の数字検出能力は、この種の典型的なシステムの概念において従来通りであり、本願明細書においては更に詳細に記載されていない)の資源によって検出することができ、その後で、ホールドオン楽曲のスタイルを選ぶ(例えば、楽曲の所望のスタイルを選ぶために始まる1又は複数の数字によって追従される楽曲の有効スタイルを提供している音声プロンプトで)ための、複数の楽曲スタイルを備えている。その後で、ユーザは、電話キーパッド上の適当な数字を押し下げることができ、それはシステムの資源によって検出され、そのシステムは、数字をデコードして、自動作曲エンジンのうちの1台に制御情報を送る。これに応答して、自動作曲エンジンがその後、ホールドオン状態の呼び出し元にホールドオン楽曲として向けられる、選択されたスタイルの自動作曲を開始する。
重要なことは、この種の実施例に従えば、ボタン等又は典型的なシステムの資源からの命令で変更される自動作曲エンジンの命令/制御インターフェースを設けることにより、1又は複数の自動作曲エンジンを典型的なシステムに適応させることである(命令は、ホールドオン状態におかれた通話、数字検出などに応答して生成される)。この種の実施例の変形に従えば、複数自動作曲エンジンは提供され、そして、システムの資源が、ホールドオン状態の呼出し元に、該呼出し元によって選ばれたスタイルのホールドオン楽曲を選択的に提供する。一つの変形において、自動作曲エンジンよりも多くの呼出し元が潜在的にホールドオン状態にあってもよい。この種の実施例において、利用されていない少なくとも一つの自動作曲エンジンがある場合、ホールドオン状態の呼出し元は選択的に自動作曲エンジンの出力オーディオストリームの1つと接続される。呼出し元がホールドオン状態におかれたときに自動作曲エンジンの全てが利用されている場合、ホールドオン状態の呼び出し元が、自動作曲エンジン(選択を与えられずに)の1台によって出力されているひとつのオーディオストリームに結合されるか、あるいは、ユーザにその自動作曲エンジンによって現在提供されているホールドオン楽曲のスタイルを知らせる音声プロンプトが提供される(それに応答して、ホールドオン状態のこの呼出し元は、電話キーパッド上の1又は複数数字を押し下げることによって、提供されているスタイルの1つを選ぶことができ、選択されたスタイルの自動作曲された音楽を提供しているオーディオストリームと接続される)。
他のこの種の実施例の変形には、以下が含まれる。(1)典型的なシステムの資源は、例えば、発信者番号通知サービス情報、又は到来する通話のトランクグループを通して、呼び出し者(例えば、地理学的位置)に関する情報を検出し、その後、特定のもののためのホールドオン楽曲が発信者番号通知サービス情報又はトランクグループ情報、その他に対応する予め定められたスタイルであることを指令する。(2)典型的なシステムの資源は、被呼び出し者(特定の被呼び出し者は、例えば、それらのホールドオン楽曲が特定のスタイルの中であることを指令する構成パラメータを設定することができる)の身元に基づいて、選択的にホールドオン楽曲のスタイルを決定する。(3)典型的なシステムの資源は、その年の季節、時刻又は週、その他で、選択的にホールドオン楽曲のスタイルを決定することができる。(4)典型的なシステムは、各スタイルのための自動作曲エンジンを含み、それにより、ホールドオン状態の全ての呼出し元が、提供されるスタイルの1つを選ぶことができることを確実にする。(5)デフォルト又は最初の楽曲スタイル(例えば、上記したように、典型的なシステム又は被呼者、その他の資源によって決定した)に続いて、ホールドオン状態の呼出し元が楽曲スタイルを変更することを可能にする音声プロンプトが生成される。(6)典型的なシステムの資源は、ユーザが特定の楽曲スタイルを変更するパラメータ、及び特定の楽曲スタイルで自動作曲されている楽曲を変更するパラメータを選択することを可能にする音声プロンプトをさらに具備する(本明細書のどこかで説明されいるように、本質的には、音声プロンプト生成及び数字検出は、ホールドオン状態の呼出し元が自動作曲されている楽曲のパラメータを変えることを可能にするために、システムの資源によって提供される)。
一般に本発明の態様を他の製品と統合する新規な方法の他の実施例は、ビデオカメラ(例えば、好ましくはユーザが容易に使用料なしでホームムービーを創作することを可能にするために、コンフィギュレーション可変なサウンドトラック)、従来のステレオ装置、運動装置(速度/強度/プログラム可能な、好ましくはトレーニング強度プログラム可能な能力をもつトレーニング装置(StairMasteシリーズのようなhills)と同様の)、コンピュータスクリーンセーバプログラムに対するコンフィギュレーション可能な音声付属物、及び情報キオスクシステムに対するコンフィギュレーション可能な音声付属物を含む。
本発明の態様は、媒体コンテンツ権管理等を容易にするために、楽曲出力上の音声「指紋」を組み込むことができる音声透かし技術と結合して、好適に使用することができる。Verance又はDigimarc(例えば、米国の特許第6,289,108号及び6,122,392号(本願明細書に取り込んだものとする)のDigimarcによって記載されている音声透かし概念)によって記述されたように、好ましい音声透かし技術の組み込みは、ユーザがそれらの生成された楽曲の次の使用法をモニタする能力をもつことを可能にする。
他の例では、本発明のある実施例は、ゲーム自体のアクション及び/又はその展開に応じて、ユーザによって選択可能なスタイル及び/又はビデオゲームソフトウェアによって選択可能なスタイルと共に、仮想的に決して繰り返さない楽曲を提供するために、ビデオゲーム(例えば、プレイステーション2のビデオゲーム)のソフトウェアの一部として組み込むことができる。
ある実施例は、ビデオゲームプレーヤに楽曲を提供するために、本願明細書において記載されているアルゴリズムの楽曲生成の使用を含む。ある実施例において、図32の選択された部分を参照すると、DSP42(及び、好ましくは、フラッシュ49、RAM48、DSPデータバス47、及びDSPアドレスバス46の1つ以上)を組み込んだモジュール(例えば、マイクロソフト社からのXboxのようなビデオゲームシステムが用途に適している)が使用可能な状態テレビゲーム機(例えば、パーソナルコンピューターシステム、上述したMS Xbox、及び/又は、アメリカのソニーコンピュータエンターテインメントからのPS2)に結合される。この種のモジュールによって、高品質楽曲音を、例えばDSP資源による高品質を経て、生成することができる。好ましくは、楽曲ルール等のアルゴリズムの処理の多くは、テレビゲーム機の処理資源によって実行される。もちろん、本願明細書において他の箇所で記載されているように、ある実施例は、DSP42(そして、関連したサブシステム)によって生じる計算資源を提供するために、ソフトウェアに基づくDSPを使用する。この種の別の実施例において、DSP処理は、同様にテレビゲーム機によって実行される。
ビデオゲーム実施例において、生成されている楽曲は、ゲームのイベントに応答して更新される。例えば、ユーザがゲームの間、さまざまなキャラクタに遭遇するゲームの場合、1又は複数のキャラクタは、それらと関連する楽曲スタイルを有する。これらの実施例において、楽曲が繰り返すことができないにもかかわらず、楽曲スタイルは特定のキャラクタがそばにいることをユーザに知らせる。
ビデオゲーム実施例において、楽曲(例えば、リード楽器又はドラム)の特定の構成要素は、キャラクタと関係している、そして、特定のキャラクタがビデオゲームのユーザにより近接して移動すると、楽曲の対応する構成要素は、それに応じて調整される。例えば、ビデオゲームのユーザが特定の悪者に近づくとき、その悪者(例えば、リード楽器)に対応する音楽構成要素が調整される(例えば、相対的な音量の増加、及び/又は、例えば、図23に示したような、音符ピッチの相対的な可動性の増加のようなその他の変化を示すか、及び/又は、図18等に示したように、相対的な周期的密度を増やす)。
ビデオゲーム実施例において、例えば、本願明細書のどこかで記述したように、音楽作品(例えば、図28、図30及び図59に例示されるパラメータのような情報)に関する情報は、取り外し可能な記憶場所に保存される。例えば、ソニープレイステーション2のような例では、他のビデオゲームデータを保存するために具備されるモジュラフラッシュメモリカードに情報を保持しておくことが好ましい。これらの実施例において、ビデオゲームデータを保存するためにテレビゲーム機によって使用する取り外し可能なフラッシュメモリカートリッジの容量が比較的限られ(そして、高出費)ていることを苦慮すると、音楽作品を再現することを必要とする楽曲の情報が比較的少ない容量であることは、特に有利である。
その上、本発明の多くの利点を組み込んで効果を生成されることができるように、本発明を変形することができる。例えば、図32の携帯用ハードイウェア装置35の、マイク入力51(例えばユーザの声のメロディ)への着信データがハードウェアコーデック52を介してMP36に達し、そのデータがMP36によって分析され、DSP42(MP36の制御下で)によって処理/調整され、微妙にピッチ及び/又はリズム特性を「改良する」ことができる。この実施例は、ユーザのオーディオ入力が付随する楽曲のキー及び/又はリズム特性に合致するように、調整することができる。この実施例を続けると、マイク入力51に対するユーザの入力のピッチは、携帯用ハードウェア装置35によって分析することができ、より密接に楽曲の現在のキー及びモードに整合するように、ピッチを上下に調整することができる。この種の変形により、初心者に音楽的に対する強い興味を満たせ、また、ユーザの入力(例えば、声の)から派生する歌曲を生成する簡単な方法をユーザに提供する。他の実施例変形においては、ここで言及される回路は、ユーザの入力(例えば、声の)を分析して、タイミング及び/又はメロディ情報の若干のタイプを推定するために利用することができる。その情報は、RPに含まれるピッチ値及び/又はリズムデータを定めるのを助けるために、双方向楽曲自動生成おいて使うことができる。この例は、作曲中に、完全に作曲の複雑さを理解することを必要とせずに、ユーザが楽曲出力と相互作用して、それに影響を与えるための方法を示す。
ある実施例において、リアルタイムの声のマイク入力を分析して、生成されている作曲の一部として、リアルタイム方法の入力声の特性に擬態する声音コードモードを可能にすることが好ましい。一つの例として、この特徴は、ユーザの声の入力イベントを1又は複数の人工的に生成された声のイベントと結合する声音コード効果を提供することができる。この方法では、ユーザは一部を歌うことができ、そして、それらの声音に基づいたコードを聞くことができる。この特徴が、本開示の他の箇所で記述されるピッチ矯正特徴によって、用いることができる。
ある実施例においては、リアルタイムでユーザに参照音符を提供することは好ましい。この種の参照音符は、ユーザにとって主音概念を提供する。例えば、その結果、より正しく歌えるようになる。更に、実施例において、この種の参照音符は、参照メロディとして役立ち、ユーザに対して、精密なメロディ/リズム線を提供することができる。これらの機能は、特にカラオケ環境において有利である。これらの実施例の多数において、参照音符をユーザのイヤーピースに制限することが望ましい(例えば、ユーザが、参照音符情報を、任意の記録及び/又はパフォーマンスオーディオ出力から除外することができる)。
歌唱パートの生成と関連する付加的な発明概念に向けられる実施例を、より詳細に説明する。この説明は、また、本願明細書において記述される声音関連特徴のさらなる様相を提供する。
ある水準では、声音の通信は、限定された数の個々の音響のさまざまな組合せであると考えることができる。例えば、言語学者は、全ての英語声音の通信のために使われる一組のほぼ42の唯一の音響を算出した。この組は、「音素」として公知であり、語の範囲内でそれらの対照によって特徴づけることができる音響で最も小さいセグメントである。例えば、長い「E」音声が、「me」、「feet」、「leap」及び「baby」のようなさまざまなつづりで使われる。また、「sh」音が、「ship」、「nation」及び「special」のようなさまざまなつづりで使われる。更なる実施例として、英語音素のリストは、http://www.auburn.edu/〜murraba/spellings.html.でオーバーン大学ウェブサイトから入手可能である。音素は、話し言葉と典型的に関係していて、口頭の音声を分類して、再分割するひとつの方法である。また、本説明は、本願明細書において英語の例だけを参照している。例えば、英語の音素の一組を用いて、聞いて、音声転写を準備することによって、任意の言語のための一組の音声を組み立てることができることが明らかであろう。同様に、上記の説明が口頭の例だけを参照したが、同じテクニックを、詠唱された通信を示す一組の音声を組み立てるために歌唱された例にも適用することができる。組み立てられた音声セグメントのリストは、英語の音素の一組より長いが、この方法は、歌唱された音声セグメントのライブラリを識別するために用いることができる。
楽器デジタルインターフェース(Musical Instrument Digital Interface)標準(MIDI)は、デジタルベースの音楽製品用の通信プロトコルを可能にするために開発された。それ以来、MIDIは、対話するように設計された全てのデジタルベースの音楽関連の製品のデファクト標準になった。例えば、一組のグランドピアノ音響が音響バンクを識別している音響バンク MIDI命令を送信することによって選ぶることができるように、MIDIは、特定の「音響バンク」に音響のバンクを割り当てる能力を組み込む。その後、例えば、「音符オン」命令を使用して、音響バンクの個々の音符を鳴らすことは可能である。その上、個々の音符がどのように鳴るかを示す特性(例えば、音符が始められる速度を示す「速度」等)を利用することができる。MIDIに関する詳細な情報は、カリフォルニアのMIDI製造者連合から受け取ることができる。
本発明の実施例に従って、歌唱パートを含んでいる楽曲を生成するために、MIDIをより大きなシステムに組み込むことができる。先に参照されたような楽曲生成の環境状況を仮定すると、音響(例えば、音素)のライブラリを有し、そして、制御プロトコル(例えば、MIDI)の使用によって、声音トラックがシステムに加えられる。この実施例に従えば、音素のライブラリは、MIDI音響バンク(例えば、声音のための特定のチャネルを経て)を伴うことができる。ライブラリの個々の音素は、所与のMIDIイベントのための「プログラム」値によって識別することができる。音響(例えば、音素)の所与の部分の振幅は、所与のMIDIイベントと関連する速度情報によって示すことができる。音響の各部分のピッチは、所与のMIDIイベントに伴う「音符」値を使用して、同様に識別することができる。加えて、音響の各部分のための所望の持続期間は、ある時間と関連する「音符オン」イベントのシーケンスを使用しているMIDIに好ましくは示される。そして、デルタ時間(例えば、「音符オン」イベントが実行された後のMIDIクロックの数)と関連する「音符オフ」イベントが、その後に続く。もちろん、ゼロの速度を有する他の「音符オン」命令の代替使用法は、MIDI分野でよく知られているように、音符の終了を示すために用いることができる。
楽曲の自動生成のために先に開示された実施例が、本明細書において説明された。先の開示のさまざまな機能及び実現例は、完全な音楽作品を生成するための楽曲ルール(例えば、コンピュータアルゴリズム)の使用を含む。これらの楽曲ルールは、音楽作品の多数の同時パート(例えば、ドラム、バス、その他)のための一連の音楽イベントを自動的に生成する方法を含むことができる。更に、それらが楽曲モード(例えば、降順のリディアン)と互換性を持つために調和修正されるように、効果的に個々のパートを量子化することができる。加えて、各パートの生成されたイベントを、それらが特定の慣習又は楽曲のスタイル(例えば、スウィング、レゲエ、ワルツ、その他)に合わせて時間修正されるよう量子化するために、これらの楽曲ルールは、リズム的構成要素も組み込むことができる。最後に、先に参照された開示も、自動生成された楽曲作曲に対するユーザ相互作用を可能にする実施例を提供する。
先に述べられた楽曲自動生成コンセプトを使用して、例えば、基本有声音のライブラリから一連の有声音を鳴らすために、自動生成されたピッチ、振幅、及び/又は持続期間の特性を組み込んだ一連のMIDIイベントを生成する声音処理機能が同様に使用され得る。例えば、生成されるピッチの連続が、特定の楽曲モードによって調和修正される。そして、リズム持続期間及び/又は相対的な音の大きさは、特定の所望の溝、拍子記号、スタイル、その他によってリズム修正される。さらに、ある実施例では、より詳しくは、テキストに関している付加ルールを課すことが好ましい。例えば、人間の声音通信は、特定の音素(例えば、母音)の期間、ピッチを変動するだけであることが観察される。したがって、ある実施例では、ピッチ値が変更される前に、自動生成処理の間に、音素タイプを点検することが望ましい。他のある具体例では、ピッチ変化がアクセントをつけられた音節又は「長い」音節(例えば、「orange」における「range」音に対する「o」音のように)にのみ発生するようにすることが好ましい。これらの実施例において、特定の音声が、自動生成処理の間、ピッチ変化と互換性を持つことを確認することが望ましい。この種のふるい分け動作は、さまざまな方法で実行することができる。例えば、「声音ライブラリ」が、音響バンクと関連するアドレス指定可能な範囲の一つの領域にいっしょに配置された「ピッチ変更互換可能の」音声とともに、音響バンクとして配置され得る。この実施例に従って、楽曲ルールが実行され、鳴っている声音音符が音符変更イベントに与えられるとき、それがピッチ変更イベントに関連する「受け入れられる」音域にあるかどうか決定するために、現在の音声のMIDIアドレスを点検することが好ましい。当業者に明らかであるように、これは一つの実施例でしかない。
ここまでの説明は、作曲における声音トラックの音声に近けるために、楽曲生成システムでどのように一連の無意味な音声を生成し演奏するかを対象にした。次章は、意味のある一連の声音を可能とするために、テキスト−スピーチアルゴリズムの考えを混合している。
文書情報は、個々の音声構成要素を識別するために、直ちに分析することができる。例えば、言語分析ルーチンは、各々の語の文脈を識別し、共通に誤ってつづられた語のためのミススペルを修正し、共通して使う略語を識別するために使用することができる。多くのテキスト−音素スキームが従来技術に存在している。一つの例は、ハニーエスエロヴィッツ、ロドニージョンソン、アストリートマクヒュー、及びジョンイーショアによって書かれた、「Letter−to−soundrules for automatic translation of English text to phonetics」(Acoustics、Speech and Signal ProcessingのIEEE論文集)と題する1976年の文献である。本開示の図44に示したように、テキスト情報(例えば、ASCIIテキスト)は、生成され又は書き込まれ(ステップ21)、音声記述子(ステップ22)の流れに解析される。この解析処理は、各々の音声記述子と関連する特性情報(例えばピッチ、振幅及び持続期間)の生成/書き込みに関連する。特性情報を含む音声記述子のストリームが組み立てられると、それは処理され、音声ライブラリ識別情報、ピッチ情報、振幅情報及び/又は持続期間/タイミング情報(ステップ23)を含んでいる制御ストリーム(例えば、MIDIに準拠したデータ)に組み立てられる。この種の制御ストリームは、声音ライブラリをアクセスし、一緒に声音のトラック(ステップ24)を構成する一連の音声を組み立てることによって処理される。音声が出力される前に、ピッチ、振幅及び/又は持続期間、その他の単純な調整をする「スムージング」操作のような処理操作を実行することが好ましい。これにより、出力音声はオーディオストリームが流れるように(ステップ25)、より現実的に出力される(鳴る)。
テキストはユーザ定義可能で/書き込み可能であり得るが、それも無意味である。音楽界のある実施例は、ジャズの音楽の「スキャット」のような無意味な音節歌唱、及び「天国又はラスべガス」アルバムのような「The Coteau Twins」からの環境音楽を組み込む。より単純な効果又はアーキテクチャが望ましい実施例においては、音響ライブラリの有効音素の数を減少することが好ましい。
本発明の好ましい実施例の一つの変形は、例えば、キーボード(又は、ある実施例では、オーディオ入力を経て)のようなユーザ入力インターフェースを介し、取り外し可能な記憶場所を介し、及び/又はパーソナルコンピュータ(すなわち、例えば、参照され、組み込まれた特許出願に開示されたような)に対するインターフェースを介し、エンドユーザが、テキスト入力又は書き込み、かつ、入力されたテキストを楽曲作曲に互換性をもつ自動生成声音パートの基礎として使用することを可能とにすることによって、実現される。先に参照され、かつ組み込まれた特許出願の範囲の実施例として、本開示の図45は、映像出力インターフェース32(例えば、液晶ディスプレイ)及びオーディオ出力インターフェース34(例えば、ステレオヘッドホン出力ジャック)を含む携帯用の楽曲生成装置30を表す。図45の簡略実施例に示すように、テキスト入力インターフェース36は、エンドユーザがテキストを入力することを可能にする。この例では、テキスト入力インターフェース36は、ミニチュアQWERTYキーボードであり、そして、ユーザは、始まるテキストが映像出力インターフェース32に表示されるのを見ることになる。携帯用の楽曲生成装置30が楽曲ルール及びアルゴリズムに従って楽曲を生成するとき、テキスト入力インターフェース36を経たエンドユーザによるテキスト入力は、音声記述子ストリームに解析されて、生成された特性データ(例えばピッチ、振幅、持続期間、その他)と結合されて、MIDI互換ストリームのような制御ストリームを生成するために処理される。図44の実施例と関連して本願明細書において述べられるように、制御ストリームは、声音ライブラリにアクセスすることによって処理され、そして、声音トラックを含んでいる一連の音声を組み立てる。この時点で、組み立てられた声音トラックは、任意の最終的な処理(例えば、「スムージング」、その他)を受ける。最後に、声音は、ユーザに対するオーディオ出力インターフェース34を経た他の任意の楽曲パートと一緒の出力である。完結した出力は、テキスト入力インターフェース36を介して、エンドユーザによるテキスト入力とのいくらかの関係を持つものとして、エンドユーザによって認識可能である。
テキスト入力インターフェースの使用に加えて又はその代わりに、他の変形では、例えば、他のコンピュータ/インターネット(例えば、第3のData I/Oインターフェース38)に対するインターフェースを介して、前もって作られたテキストの使用を可能にすることが望ましい。他の変形において、記憶メモリ39のような記憶場所を、声音トラック用として、テキストを記憶し書き込むために用いることができる。記憶メモリ39は、フラッシュ、ハードディスク、その他のような書き換え可能な不揮発性のメモリである。
ある実施例においては、テキスト−声音処理を行う際のMIDIリリック命令の使用をサポートすることが好ましい。例えば、テキスト情報は、一連の1又は複数のMIDIリリック命令(例えば、1又は複数のテキスト音節のための一つの命令)の形で提供される。この一連のMIDIリリック命令の各々は、それから音節に関連する1又は複数のMIDIプログラム変更メッセージを生成し/取り出すために、アルゴリズムによって分析される。この実施例によれば、歌曲と関連する一連のMIDIリリック命令を組み込んでいるMIDIカラオケファイルをサポートすることが好ましい。その上、ある場合には、更に記述子を再分割するために、特定のカラオケファイルのMIDIリリック命令を解析することが好ましい。そして、各々のリリック命令がそれと関連する一つのデルタ時間パラメータを含むように、より大きなリズム制御を提供する。したがって、デルタ時間制御方式をより微細にした方式が可能であるので、より大きなリズム制御が提供される。
さらに別の態様では、映像出力インターフェース32は、タッチスクリーンオーバーレイを有し、そして、映像出力インターフェース32に示されるキーの画像に対応する位置で、タッチスクリーンに接触することによって起動するシミュレーションされたキーボードのキーで、キーボードは映像出力インターフェース32上でシミュレーションされる。この種の実施例において、参照されて組み込まれた特許出願に記載されている実施例と関連して記載されている物理的ボタンを、タッチスクリーンの使用により、全てではないにしても、ほとんど不要にすることができる。
更に、また別の実施例においては、この種のキーエントリの使用は、ユーザが自動楽曲生成システムに名前を入力(例えば、彼(女)の名前又は愛されるものの名前、又は他のいくつかの語)することを可能にする。典型的な別の実施例において、厳密な方法で自動作曲処理に頭文字で署名するためにタイプされた名前が用いられ、それによって、キー入力によって決定された唯一の歌曲が名前のキー入力に基づいて自動的に作曲される。参照されかつ組み込まれた特許出願に開示された実施例に従って、例えば、最初のシード、楽曲データ又は擬似乱数発生処理(PRNG)への入力などを生成するために、名前の文字がアルゴリズムに使用される。それによって、自動作曲処理を開始する最初のデータが、その名前の入力に基づき決定される。一つの例として、各々の入力文字のASCII表現を加え、おそらく若干の数学を数に適用し、そして、その結果生じる数を、PRNG処理等への入力として使用する。別の例として、典型的なテンキー(例えば、文字「abc」は数「2」、「def」が「3」、その他に対応する)に使われるように、各々の文字は数値をもつことができ、それらの数は、PRNGプロセスに適切な入力となるように、数学的に処理される。この後者の実施例は、キーパッドインターフェースがサポートされる携帯電話機又は類似した携帯用製品(PDA又はページャのような)に組み込まれる場合に、特に有利である。
処理が厳密であるので、少なくとも同じリリース又は楽曲生成システムのバージョン用として、名前の全てのエントリは、特定の人のための同じ唯一のすなわち「署名」歌曲を生成する。別の実施例の自動作曲処理は、部分的に、名前の文字の入力の時間又はタイミングに基づくものであり、したがって、名前入力プロセス(この種の人間の相互作用ランダム状態は参照され、組み込まれた特許文献において述べられている)及び個々の名前入力のための固有の歌曲生成に、ユーザ時間−ランダム状態を差し挟むものであるが、好ましい別の実施例では、相当な数のユーザが、かれらの名前又はかれらにとって重要な他のいくつかの語に基づく「かれらの歌曲」として、特定の曲をもつことを好むと思われるので(何らかの形でそのユーザの名前と関係していてもよい多数の曲を提供するため、テンキーインターフェースと関連して本願明細書において記述されるように、一連の文字に対応する数を使用するために、ユーザは、例えば、逆向きに、大文字でない、ニックネーム等のように、異なる形式で彼/彼女の名前/語を入れることができる)、好ましい別の実施例では、厳密な非ランダム方法が使用される。当業者が理解できるように、この概念も、自動作曲される楽曲スタイル選択に適用できる(参照され、取り込まれた特許文献にて説明したように、スタイルは、ユーザ入力に基づくランダムな選択処理の一部であり、又は、スタイルが選択可能であること、等)。例えば、特定の画曲生成システムによってサポートされる楽曲の各々のスタイル又はサブスタイル用として、各々のスタイル又はサブスタイルのための唯一の曲は、ユーザの名前(又は他の語)の入力に基づいて、あるいは、厳密には、例えば、ユーザが、スタイル等を選択するようにして、文字のユーザ入力などのタイミング又は他のランダム性に基づいて、創作することができる。
明らかなように、自動作曲処理を開始するための名前入力が名前に限定されないということは、他の英数字、グラフィック、他のデータ入力(生年月日、語、ランダム入力された文字、その他)まで、広げることができる。タッチスクリーンを使用している実施例に関して、例えば、他の入力(例えば、引出し線、図、ランダムな線、グラフ、点、その他)は、厳密に又はユーザ入力等のタイミングに基づいて、自動作曲処理を始めるために用いることができる。重要であることは、英数字特性のキーボード入力のようなユーザ入力、又はタッチスクリーンを経た図線のような他のデータ入力エントリ(すなわち、例えば、本来は一般に音楽的でないデータ入力)は、独自にデータ入力イベントに関連する楽曲の作曲を始めるために用いることができる。このように、唯一の楽曲作品が非音楽的データ入力に基づて創作できるので、音楽に堪能でない人でも、非音楽的データ入力に基づいて唯一の楽曲を創作することができる。この種の非音楽的データ入力に基づく楽曲生成処理は、シード又は他の楽曲生成開始データを選んで、自動作曲処理を開始する。特に英数字データ入力に関して、この種の文字も記憶され(単独か、又はデータ入力と関連する楽曲生成開始データを伴って)、他の楽曲生成システムに送信される。非音楽的データの伝送は、実際には、楽曲生成システムによって創作される曲を決定する情報を送信するための少ないバイト数のデータだけの送信であって、唯一の曲を他のユーザ/システムに発信するために用いることができる。
さらに他の実施例において、楽曲生成システムは歌詞の作成を援助する。一つの典型的な実施例においては、ユーザが楽曲のスタイル又はサブスタイルを選び、歌詞のカテゴリ(例えば、バラード/ストーリ、ラップ、ギャングスタラップ、韻文、エモーショナル、その他)を選ぶ。楽曲のスタイル/サブスタイル及び歌詞のカテゴリに基づき、語又は句の入力に応答して、システムは、例えば同語源語、韻、同義語、その他の使用により、歌詞をユーザ選択と整合したように作ることを試みる。好まれる語又は句は、歌詞カテゴリ(例えば、ストーリ、エモーション、無意味な、その他)によって特徴づけられる。そして、それは語又は句がよりユーザ選択と整合した方法で選ばれることを可能にする。この種の実施例に従えば、生成されている楽曲に合わせて、歌詞及び句を楽曲生成システムによって生成することができる。そして、ユーザは、選択的に受け入れる(例えば、保存する)か又はシステム生成された歌詞を拒絶することができる(例えば、保存しない)。
上記のように前もって作られたテキスト及びユーザ入力テキストの使用に加えて、ある実施例では、テキスト自体を生成することが好ましい。例えば、A.L.I.C.E AI財団の「Artificial Intelligence Markup Language(AIML)」バージョン1.0.1 ワーキングドラフト2001年10月25日作成(以下のインターネット上の市民が利用できるhttp://alice.sunlitsurf.com/)のような(その全体において本明細書に組み込まれたものとする)一連のsensical text生成に共通に利用可能なアルゴリズム的方法の使用がある。AIMLは、単純な自動テキスト作成アルゴリズムを作成するためのドラフト規格の一つの実施例である。アルゴリズム的なテキスト自動生成、したがって、声音トラックとしての音素ストリームの自動生成をサポートすることは、本発明において有用である。図43において、テキストを創作するアルゴリズムの使用が、ステップ1に示される。同様に、図44のステップ21においても、AIMLのようなアルゴリズムのテキスト作成の使用ができる。AIMLの単純な実施態様でさえ、句の比較的限られた数を使用して大きな効果を得ることができる。ある場合には、図45に示すような電源/処理資源が制約される携帯用音楽装置において、AIMLアルゴリズムの複雑さを軽減して効率化することが特に効果的である。
本願明細書において議論されるさまざまな実施例及び多数の機能との結合において、ある実施例では、人間の音声で一組の音素を記録することによって、声音ライブラリ(例えば、図43の声音ライブラリA)を生成することが好ましい。この例では、エンドユーザは、各々の一組の音素を歌っているそれ自身を記録するオプション選択をすることができる。この特定の場合において、結果として生じる声音ライブラリが、エンドユーザの声に極めて似ている音声を有する音楽の出力を達成するために、声音トラックの自動生成の間、使われる。その上、有名人の音素は、有名人に対応する声音ライブラリを生成するために記録することができる。このようにして、有名人の声に極めて似ている声音トラックが生成される。この実施例に従えば、デビッドボウイ(例えば、各々の音素として、彼の実際の声か物まねタレントの声が記録される)、ジミーヘンドリックス等に対応する声音ライブラリがあってもよい。このように、エンドユーザは、それらの処理でデビッドボウイ及び/又はジミーヘンドリックスの「声」を有することができる。ある実施例においては、多数の声音ライブラリにアクセスして混合することができることは有利であると考えられる。
音声情報の経路選択に伴う付加な実施例を以下に説明する。図46は、本発明のある付加的な実施例を示す。図示されるように、実施例(例えば、図32を参照)として、プレーヤ10は、DSP42、マイクロプロセッサ36、音声コーダー/デコーダ52、オーディオ入力/出力ジャック66、マイクロプロセッサバス37及び38、バスインターフェース39(あるいは、シリアル I/O 57)、マイクロプロセッサRAM(すなわち、内部RAM、又は、それ以外はMP36の制御下で)及びバスポートコネクタ53を組み込む。更に、この一組の実施例において、DSP42とハードウェアコーデック52(デジタル信号62)の間の信号はデジタル信号で、ハードウェアコーデック52は、DSP42との間でデジタル化された信号を送信/受信している。ハードウェアコーデック52及びアナログ音声I/O66の間の信号は、アナログ信号である。
本実施例は、DSP42を使用している音声情報(例えば、楽曲)を生成することができる音声装置である。ある実施例において、音声情報は、私設のフォーマット(すなわち、携帯用楽曲装置のハードウェア詳細に影響を及ぼす効果的なフォーマット)に符号化される。ある他の実施例(例えば、音声装置がデータを記憶することができ及び/又は他のシステムに接続している時)において、音声情報をより容易に共有することができ(例えば、他の異なるシステムを有して)及び/又は種々の他のフォーマット(例えば、CDROM、その他)に変換することができるように、音声情報(例えば、私設のフォーマットに加えて)の所有権の保持されていないフォーマットを生成することが望ましい。例えば、音声情報のための一つの好ましいフォーマットは、MP3(MPEG Audio Layer3)である。明らかであるように、他のフォーマット(例えばWAV、ASF、MPEG、その他)もまた使用可能である。
図46は、どのようにして、この種の音声装置がストリーミングフォーマットの音声情報の共有を容易にするシステムに接続されるかの実施例を示す。図示されるように、プレーヤ10はコネクタ53及びアナログ音声I/O66を介してシステム460に接続されている。当業者に明らかであるように、接続は単独、又はその他との結合のいずれかで行われる。実施例において、システム460は、オーディオ入力プラグ(そして、関連音声処理回路及びソフトウェア)及びUSBポート(ある実施例では、USB39は、PCMCIA、カードバス、シリアル、パラレル、IrDA、ワイヤレスLAN、その他、インターフェース)を有するパーソナルコンピュータである。ある実施例において、システム460は、テープレコーダ、CDレコーダ、MP3プレーヤ、その他であり得る。システム460は、音声能力がある装置(例えば、音声I/O接続及び関連能力を有する)であれば任意のものでよく、任意選択で、プレーヤ10のコネクタ53につながるためのバスポートを含むことができる。
図32及び図46と関連して上記説明を続けると、ある実施例では、プレーヤ10の音声生成動作の間、DSP42から出力されるデジタル信号62は、I2Sフォーマットであり、USB I/F39(あるいは、シリアルI/O57)に信号線を追加することができる。この例では、USB I/F39(あるいは、シリアルI/O57)は、DSP42(例えば、I2Sフォーマット信号)から、入力信号を直接受け入れることができ、コネクタ53上の出力データストリームにそれを従わせているバスマスタである。この例では、USB I/F39(あるいは、シリアルI/O57)として、好適に使うことができる典型的な装置は、バーリントン(マサチューセッツ)のScanLogic社から入手可能なSL11R USBコントローラである。
ある実施例において、プレーヤ10の音声生成操作の間、DSP42から出力されるデジタル信号62は、MPアドレスバス37及びMPデータバス38に付加信号線を経由することができる。この例では、USB I/F39(あるいは、シリアルI/O57)は、これもScanLogic社から利用できるSL811S USB Dual Speed Slave ControllerのようなスレーブUSB装置である。この例では、特定のコスト削減がより単純なUSB I/F39(前述のSL811RのようなマスタUSB装置に対して)を用いて実現することができるが、トレードオフはMP36がデジタル信号62の流れを制御することができることを必要とするということである。これは、主に、この例で、MP36がMPアドレスバス37及びMPデータバス38のマスタであって、このバスを含んでいる転送動作を実行することを必要とするという理由による。MP36がこれらのそれ以上の機能を実行する充分な能力を有する場合において、この実施例は好ましい。前述の実施例においては、前述した様に、価格/パフォーマンスが珍重されるが、より能力があるUSB、I/F39(あるいは、シリアルI/O57)部分が、MPアドレスバス37及びMPデータバス38上の有効資源にほとんど有害な作用をおよぼすことなく使用され得る。
上記した実施例において、デジタルデータの形で、DSP42から出る音声情報出力は、システム460によって受信されるようにコネクタ53を通じて送られる。システム460は、対応するバスポート、その他(例えば、USBポートか、あるいは、又は他のポート(例えば、PCMCIA、カードバス、シリアル、パラレル、IrDA、ワイヤレスLAN(例えば、802.11)の少なくとも1つと互換性を持つポート)を経て、この種のデジタルデータを受信することができなければならない。
この種の構成は、ユーザによりユーザフレンドリな経験を許容するために、制御機構(例えば、音声の演奏と取り込みの間の同期)の使用を必要とする。その一方で、ユーザは、プレーヤ10での楽曲生成/作曲の動作、デジタル信号62からのデジタル音声情報のコネクタ53への経路選択を行う動作、システム460で音声情報を受信して処理を行う動作、そして、システム460上でその音声情報の記録を行う動作を、視聴したり/それに参加したりする。この種の制御機構の一つの実施例は、ユーザ入力に応答するシステム460上のソフトウェア/ファームウェアプリケーションの実行であって、MP36に音声生成処理を開始するように指示する制御信号を使用して、コネクタ53を介してプレーヤ10で処理を始めることである。あるいは、制御機構及び/又はシステム460が行程手順に参加して、デジタル音声情報を受信するために用意された状態にある限り、行程手順を始めるユーザ入力が、プレーヤ10に最初に受け取られる。
前述の説明において、制御情報は、コネクタ53(例えば、デジタル音声情報に加えて)を通してプレーヤ10及びシステム460の間で通信される。この種の制御情報は、本発明の態様を実施するために必要ではなくて、使用する場合にエンドユーザにより直観的体験を与える。例えば、ある実施例において、デジタル音声データが、(例えば、アナログ音声I/O66を通るアナログ音声情報の代わりに)コネクタ53を通じて制御可能に管理されるので、制御可能なデータリンクを組み込むこの種の装置は、アナログ音声I/O66(例えば、8インチステレオフォノプラグを使用しているアナログ音声リンク)上の接続を必要としない。
別の実施例において、例えば、より多い処理資源で、プレーヤ10の音声生成動作の間、DSP42から出力されるデジタル信号62は、プレーヤ10上のローカル記憶場所((例えば、SMC40を経てのような、取り外し可能なメモリ又はマイクロドライブ、RAM、他のフラッシュその他)に送られる。この方法では、デジタルオーディオストリームを、外部システム(例えば、システム460)を用いずに保存することができる。この種の動作において使うことが可能なデジタルフォーマットは、MP3、WAV及び/又はCD音声を含む。
他の実施例では、システム460に(例えば、共有化を可能にすること等のために)音声情報を送ることは、システム460上(例えば、既存のサウンドカード、その他を用いて)の対応するアナログオーディオ入力(例えば、8インチステレオフォノ入力プラグ)に、アナログ音声I/O66でアナログ信号64を送ることによって成し遂げられる。この場合、DSP42から出るデジタル音声情報出力がコネクタ53に送られる必要がないという点で、本願明細書において議論される択一信号の実施例が必要とされない。より能力のあるMP36も、マスタタイプUSBI/F39も必要とせず、したがって、費用のより効果的な解決を提供するので、この種の実施例は、あるアプリケーションにおいて有利である。従って、本実施例は容易かつ能率的に、プレーヤ10に組み込まれ得る。この種の容易性及び効率性にもかかわらず、本方法は、システム460に進んだ音声情報のフォーマットがアナログであり、したがって、信号損失がより大きくそして信号干渉(例えば、電磁気の)に影響されやすいので、前述の実施例よりより望ましくない。いずれにしても、この装置は、コネクタ53を経てシステム460とプレーヤ10の間を伝送されている制御情報を含むことができる。ユーザが処理を始めることができるという点で、この種の装置は、エンドユーザにより直観的な経験(本願明細書において関連するさまざまな方法で)を提供することができ、そして、その処理の同期は、コネクタ53通して装置の間を通過している制御情報により、ユーザに対して透過的に達成することができる。
ここで、特に本実施例の使用にとって有用であるファイル形式の新しい実施例を提言する。しかしながら、ファイル形式に関する本開示の部分が、携帯用音楽装置以外の別の種々の装置において、容易に利用されることは、ファイル形式の分野の当業者によって理解されるであろう。したがって、楽曲装置に関連する実施例が参照される一方で、他の非常に類似した実施例(一般のコンピュータシステムにおいて使用するファイル、CDのような音楽ファイル、他の種類の携帯用機器で使用するファイル、その他のようなものを含む)を直ちに案出することができることは、明らかである。
現在記載されている「溝付き」ファイル形式は、「スロット」と呼ばれている一まとまりの独立装置を含む。スロットが他のスロットに影響を及ぼさずに加えられるか又は取り除かれるので、与えられたタイプのスロットが他のスロットに影響を及ぼさずに大きくされるか又は縮小され、そして、所与のファームウェア/オペレーティングシステム(OS)リリースの範囲内又は現在のそうしたものの範囲内で未知のタイプを有するスロットは、無視されるので、ファイル内のデータ編成に柔軟性を与える。そして、それはバックワード互換性の問題を解消する助ける。
第1のレベル解析(例えば、各個別のスロットをアクセスすること)と同様に、全ての専用ファイルのために同じ一般的なファイルフォーマットを有することは、ファイルデータの検査合計と整合性の確認のために、同じコードの使用を可能とする。
図47をここで参照すると、スロット構造(SLS)は、スロット構造ヘッダとそれに続くN個のスロットとからなり、個々のスロットは好ましくは項目を含む。
図48は、典型的なSLSヘッダ構造を例示する。「Header Length」フィールドはヘッダの長さを含み、それは、非互換性をつくることなくヘッダの将来的拡張を許容するように使用される。「Checksum」フィールドは、スロットファイルの検査合計を含む。「SLS Shade」フィールドは、例えば、ファイルがインポートされ及び/又はアクセスされるときに決定されるべき、スロットファイルの正確なファイルタイプを含む。「SLS Type」フィールドは、これがどの種類のスロットファイルか(例えば、ファイルが曲、演奏リスト、サンプルセット、その他のどれであるか)を示す。「SLS Version」フィールドは、例えば、互換性(例えば、将来、特定の種類のスロットファイルのフォーマットが変わるかどうか)を保持するために用いる。
「Deta Length」フィールドは、各々のスロットのデータ長フィールドが含むバイト数を含む。ある実施例において、このフィールドは、スロットファイルの容量を最適化するために用いる。−その理由は、スロットファイルの他のタイプは非常に大きいデータフィールド(例えば、サンプル)を使用するのに対し、スロットファイルのあるタイプは非常に少ないデータフィールドしか使用しないか、又は全くデータフィールドを使用しない(例えば、リスト)からである。
「Num Slots」フィールドは、スロット構造のスロット(N)の数を保持する。スロット番号が直ちに利用できる場合、ファイルをデコードすることはより容易である。ある実施例において、この冗長な情報は、スロット構造の整合性を検査するために用いられる。
検査合計の目的は、スロットファイルを読出し/書込みエラーから保護することである。多くの実施例において、CRC算出によって最高の保護が与えられることが期待される。しかし、これは、遅くて複雑で、いずれにしろ実際には必要でない。その理由は、次のことにある。すなわち、読出し/書込みエラーがめったにないので、多重誤りからの保護を必要としないからである。したがって、この目的のためには単純な検査合計算出で充分であると思われる。
例えば、32ビットプロセッサを含んでいる実施例において、最も速くて最も効果的な検査合計計算は、ファイルdword byどぉrdの全てのデータを加算することである。残念なことに、dword by dwordによる計算は、word by wordと同様に、整合性の問題が生じる。
このような実施例では、ファイルのバイト数が多数のdword又はwordであってはならない場合は、検査合計計算のためのファイルの終わりに、ゼロを詰めるバイト追加することにより、調整することができる。しかしながら、この種の実施例で、各々のチャンクの容量が、多数のdword又はwordであることを強いられない限り、ファイルがいくつかのチャンクに書かれるときに、より複雑な検査合計の事態となる。
別の実施例は、スロットファイルの全てのフィールドを語整列とすることによって、この問題解決の折衷案を含む。これらの別の実施例において、全てのスロットは、偶数のサイズ(例えば、word(語)の整数)を有する。このように、一語ずつ検査合計を計算することは、比較的容易になる。これはdword毎の計算ほど速くはないが、バイト単位の計算より速い。ファイルが比較的遅い媒体(例えば、フラッシュメモリカード)に記憶される実施例において、この問題の影響はさほど大きくはない。その理由は、明らかに、検査合計計算遅延への最も大きく影響するものは、データ読出しに必要な時間であるからである。
図49において例示される典型的なスロットフォーマット実施例を説明する。異なる種類のスロットが所与のスロットファイルにおいて使われる場合には、「Slot Type」フィールドは、スロットの内容の性質を示す。「Name Length」フィールドは、「Name」フィールドの長さをバイトで保持する。ある実施例において、「Name」フィールドがない場合、「Name Length」は0である。「Name」フィールドは、65535文字までのいかなる文字列も保持することができる(例えば、この例では「Name Length」フィールドが2バイト)。「Data Length」フィールドは、バイト(再び、「Data」フィールドがない場合、「Data Length」は0である)で「Data」フィールドの長さを保持する。「Data」フィールドは、意味がスロット構造のタイプ及び/又は所与のスロット構造のタイプの範囲内のスロットのタイプに依存する情報を保持する。
ある実施例において、スロットの特定タイプは、ファイル参照を保持することができる。この種の「ファイル」スロットにおいて、スロットタイプは、スロットによって参照されるファイルのファイルタイプに関連し、そして、「Name」フィールドは、ファイルの名前を含む。このように、ファイルスロットは、SLS Typeによって与えられるタイプとは別に、ファイルを参照することができる。
スロットファイルのタイプは、特別な方法でファイルを参照するスロットを含むことができる。この場合、スロットタイプは固定値を有し、それはこの種のスロットファイルだけに有効である。この種のスロットの「Name」フィールドはファイルの名前を含み、そして、ファイルタイプはコンテキストによって与えられる。この実施例を続けると、ファイルスロットの「Data」フィールドは、ファイル設定ファイルのファイル設定を好適に記憶するために用いてもよい。
本説明において、「Alien Slot(異種スロット)」(スロットファイルの所与のタイプ)は、現在のファームウェア及び/又はオペレーティングシステムリリースよってタイプが認識されないスロットである。例えば、「異種スロット」は、当初リリースB(リリースBがリリースAより最近のもの)に書かれたリリースAのファイルを読む場合、存在することがある。ある場合において、コンピュータ上で創作されるか変更されたスロットファイルは、それ自身のタイプを加えることができ、そして、ポータブルシステムは、それを「異種スロット」として考える場合がある。たとえどこでそれらが非互換性をつくらずにスロット構造に載置されても、全てのスロットファイルが「異種スロット」を受け入れることを可能にすることは有利である。この方式では、スロットファイル管理に2つの制約を招く。すなわち、「異種スロット」は無視される(例えば、それらは現在のファームウェア公開の効果を有してはならない)場合、そして、スロットファイルが変更されるときに、「異種スロット」は保存される(例えば、削除されなくて)場合である。この方式は、非互換性をつくることのない将来のファームウェア/OSリリースのいかなるスロットファイルにも相補情報が加えられるようにする。好ましくは、以前のリリースは新規なリリースにおいてつくられるスロットファイルを読出すことが可能であり、そして、以前のリリースがこの種のスロットファイルを変更する場合、新規なリリースに関連する情報が保存される。
あるスロットファイルにおいて、全てのスロットが異なったスロットタイプ値を有することは望ましい。これらの場合、それが探しているスロットを見つけるために、ファームウェアが全ファイルを走査して/書き込むので、スロットがスロット構造に配置される順序は重要ではない。スロットファイルの他の若干のタイプにおいては、ファイルがどのように動くかを判定するために純情が用いられるので、スロットが配置される順序は重要である。実施例として、項目(例えば、曲又はサンプル)が、それらがスロット構造に位置する順序で、演奏され/実行され/アクセスされ/その他であり得るので、リストを有する場合、この種の装置は望ましい。したがって、所与の実施態様で、スロットの順序づけは、スロットの種類(例えば、ファイルスロット)のために重要であって、スロットの他の種類のためには重要でない。
ある実施例において、所与のタイプ(例えば、SLSタイプで規定された)のスロット構造に関して、あるスロット(例えば、スロットタイプ値又はスロットタイプ値の範囲で規定された)は、好ましくは完全なスロット構造(例えば、スロットの「Data」フィールドに位置する)を含む。入れ子にされたスロット構造を可能とするので、この方式は有利である。
いかなるスロットファイルも、読出すときに、以下の3点のうちの1又は複数で確認を実行することが有効である。すなわち、スロット構造のタイプは現在のリリースにおける知られたタイプでなければならない、SLSバージョンは現在のリリースにおいてサポートされていなければならない、スロットファイルデータは整合していなければならない、の3つである。データ整合性検査は、ファイル容量がNスロットの容量の合計に対応することを確かめることからなる。ここで、NはSLSヘッダにおいて読出されるスロットの数である。よって、例えば、データ整合性検査は、SLSにおいて特定されるスロットの数におけるエラーを検出する。ある実施例において、これらの確認は、ファイル検査合計の後で実行される。この確認は、ファイル検査合計確認を有するので冗長でない。その理由は、スロット構造の整合性の確認は、スロット構造(例えば、現在のファームウェア/OSリリースにおいてサポートされていない古いフォーマット)のフォーマットの変化のようなものを検出するのに対し、後者はファイルの書き込み又は読出しにおけるエラーを検出するからである。ある場合において、例えば、リアルタイム動作のために時間が長くかかりすぎる場合、検査合計確認はスキップされてもよい。これは、サンプルのような比較的大きなファイルの場合、望ましいことである。そして、それはリアルタイム再生のためにアクセスされる。
ある実施例において、歌曲ファイルは、以下の4つのスロットの1又は複数を有することができる。すなわち、歌曲データスロット、楽器スロット(例えば、別に記憶することができる楽器インデックスを保持)、サンプルセットスロット(例えば、任意の関連するサンプルセットファイルを保持)、及び設定スロット(例えば、歌曲設定(音量、スピード及びピッチ)を保持)の4つである。サンプルがスロットファイルに記憶される場合、任意の適用可能なサンプル設定(例えば、サンプル記述子、正規化係数、効果インデックス及び効果タイプ)も、サンプルデータと同じファイルに記憶することができる。この特徴は、将来の進化のための大きな柔軟性を生じる。ある実施例において、ファイルにサンプルをスロットとして記憶することが望ましい。
「サンプルデータ」は、サンプルを演奏することに関係しているデータ(例えば、PCMデータ)を示す。ある実施例において、サンプルデータの全ては、一つのスロットの「データ」フィールドに記憶することができる。他の実施態様において、サンプルファイルは、付加的な相補情報(例えば、サンプル設定スロットに適合させることができないカスタムメイドの効果の定義)を含む。この相補情報は、例えば、関連するスロットタイプを用いて、異なるスロットに記憶される。他の変形(必ずしも、前のものと相互に排他的でない)として、サンプルを個々に演奏することができるより小さい塊に分割することが考えられる。一つの例として、この種の実施は、その塊の間に時間間隔を有するようにして(例えば、連続的よりむしろ)サンプルを演奏することができるようにする。
ある実施例において、サンプルファイルは、2つのスロットを有する。すなわち、サンプルデータ(例えば、PCMデータ)を保持するサンプルデータスロット、及び、サンプル設定(例えば、サンプル記述子、正規化係数、効果、その他)を保持するサンプル設定スロットである。異種スロットが、サンプルファイル(例えば、ファームウェア/OSによって認識されないで無視されたサンプルファイル)に受け入れられるようにすることが望ましい。例えば、これは、コメント又はサンプルファイルデータに関連する他のデータを含むように用いることができる。
理想的には、スロットがサンプルファイルに格納される順序は重要ではない。しかしながら、上記「サンプルファイルの進化」で述べたように、容量が大きいので、サンプルファイルは特別な制約を受ける。サンプルデータスロットの後にサンプル設定スロットを格納する場合、ある状況(例えば、重く断片的なクラスタ割当てのような状況)で、サンプル設定値情報を書き込むための時間は、不所望に長い。例えば、断片化の場合、設定値が記憶されている(すなわち、サンプル設定スロットの「Data」フィールド)サンプルファイルの終端のアドレスを算出することは、容易ではない。この問題に対処するために、ある実施例において、変更されるべき領域は、常にサンプルファイルの主要なVSB(ダイナミックメモリ割当ての可変サイズブロック)に位置するようにする。これは、このスロットの長さがクラスタ容量と比較すると十分に小さいという事実に基づいて、サンプル設定スロットにサンプルファイルの第1のスロットを作ることによって達成することができる。
リストファイル(例えば、各々のスロットが項目又は動作を識別することができ、スロットの順序が演奏及び/又は実行の順序に影響を及ぼす場合)を含む実施例において、最後のスロットを、最後の項目の実行後何が起こるかを知らせる「命令終了スロット」とすることが有利である。実施例として、この種のスロットは、「演奏中止」又は手動介入があるまで演奏を続ける「開始までの繰り返し」を示す。これらの実施例においては、ファイルスロットがリストファイルに配置される順序により、リスト(例えば、サンプル又は歌曲)の項目が実行及び/又は演奏される(例えば、たとえ命令終了スロットが組み込まれていなくても)順序が決定される。一方、これを使用する場合、命令終了スロットは、Sリストファイルのどこにでも格納することができる。
上記の例に従えば、リストファイルは、もはや利用できない1又は複数のファイルの参照を保持することになる。さほど長く存在しないファイルの各参照(例えば、ファイルスロットによって保持される)は、「失われた項目」と考えることができる。リストファイルが変更されたとき、失われた項目スロット(異種スロットとは異なった)は好ましくは削除される。
無線局プリセットのような項目のリストを含む実施例において、無線局プリセットは、専用のリストファイルに記憶される。例えば、この種の無線リストファイルの各スロットは、プリセットの名称及び周波数を保持する。この例では、例えば、非互換性をつくらずに、「データ」フィールド内で、より多くのフィールドを加えることが可能である。
図形ファイルを含む実施例において、図形を図形処理ファイルに記憶することが望ましい。ここで論じられるスロットファイルフォーマットは、いくつかの画像/図形が、例えば、各々異なる属性をもって記憶されることを可能にする。この装置は、さまざまな静止画像(例えば、携帯用機器上の多様なGUI表示画面用の静止画像)がファイルに格納されることを許容する。ある場合において、この方式はまた、動画を記憶するために用いられる。例えば、動画の連続したコマと関連するデータは、個々のスロットに位置することができ、そして、スロットの順序づけは動画の連続したコマの順序づけを決定するために用いることができる。
設定された拍子記号と同様に、楽曲ルールに従う楽曲を生成する楽曲生成システムは、典型的には完全に特定の楽曲モードを知っている。結果として生じる出力が音楽的に強い興味をそそるように、音声情報を生成する楽曲ルール/アルゴリズムは、特定の楽曲モード及び拍子記号を巡って動くように構成される。このように、創作された音楽作品の生成又は再生の間のいかなる時も、拍子記号(例えば、アクセントの適当な位置、ドラム挿入等を含む、楽曲の教師及び/又はグルーブ)とモード(例えば、いかなる時でも互換性を持つ一組のピッチ)をトラッキングする定義済みの変数がある。
加えて、ユーザ入力に応答して又は楽曲ルールの一部に応答して再生される選択されたサンプルを用いて、最終的な音楽の出力が有利に増やされる。例えば、単純なメロディを歌っている女性の音声の短いサンプルは、ある調整の機会に、特定のヒップホップスタイル曲に加えることができる。この種の実施例は、予め録音してある音響が、楽曲の出力を強化するために、楽曲生成/再生システムかアルゴリズムによってどのように利用されるかについて、示すものである。
所有権の保持されていないサンプルフォーマットの使用はまた非常に望ましい。それは、エンドユーザが、他の手段を用いて容易に他の音響サンプルを共有及び/又は生成することを可能にし、創作された音楽作品にそれらを含めることを可能にするからである。この種の方式は、エンドユーザが音楽的な素養又は経験を有しない場合であっても、エンドユーザ側の高度な創造力及び音楽の参加を可能にする。この種の初心者エンドユーザに、音楽の創造力についての興味を引き起こす経験を効果的に与えることが、本開示の目的のうちの1つである。
その上、楽曲システムの好ましい実施例は、使用するサンプル上での信号処理を可能にする。例えば、この方法は、好ましいタイプのシステムのDSP機能性を用いて、ユーザが容易にサンプルピッチや速度を調整することを可能にする。一つの例として、Atmel社から入手可能なドリームDSPチップ(そのデータシート及びアプリケーション/ユーザマニュアルは、ここに取り込まれたものとする)は、サンプルが、ドップラ、ウオブラー、エコー、その他のようなさまざまな音響効果の適用とともに、ピッチ、速度、その他を含む、さまざまな線に沿って調整することを可能にする。これらの態様及び特徴は、本願明細書において更に詳細に記載されている。
音声コンテンツの創作の一つの問題は、楽節間のサンプルの再生が、ピッチ又はリズムに関してその楽曲との同期からずれて鳴り響くことがあるということである。これは、通常、特定時点でのサンプルと楽曲との間のデフォルト同期がとれていないことによるものである。これに関するひとつの方法は、例えば、ものを言う音声又は音響効果のような、明白なピッチ又はメロディを有しないサンプルを使用することである。しかしながら、特により高いレジスタでは、メロディサンプルの使用が楽曲の多くのスタイルにおいて望ましいので、サンプルにピッチ及び/又はリズム情報を関連付ける(組み込む又はその反対)能力をもたせることが、場合によっては望ましい。この種の情報は、音楽作品の特定のピッチ、メロディ及び/又はリズム特性にサンプルが同期するようにするために、楽曲装置の楽曲ルール及び/又はアルゴリズムによって解釈される。好ましい実施態様に従うこの種の装置を、以下に説明する。
図50は、本発明の好ましい一実施例に従って利用されるサンプルデータ構造540である。図示するように、サンプルデータ構造540は、サンプルデータフィールド535及びオプションのヘッダ部530を含む。図50の説明において、サンプルデータフィールド535は、音響サンプルデータ510を含み、ヘッダ部530はタグID525、リズム情報520及びピッチ情報515を含む。
タグID525は、互換システムに対してオプションのヘッダ530を識別するために用いて、非互換システムの以前製品との互換性を提供するために用いてもよい。例えば、サンプルを読出している受け継がれたシステムが音響サンプルデータ510を読出し、そして、リズム情報520又はピッチ情報515(例として)を無視するというような方法で、音響サンプルデータ510の起動のためのポインタを与えることによって、以前の製品との互換性は達成される。ある実施例において、これは本願明細書において記載されているスロットファイルフォーマットを介して、好ましくは達成することができる。付加的な実施例において、混合モードCDROMがアップル社及びIBM社双方の仕様互換パーソナルコンピュータCDROMドライブ上で動作するように符号化される方法と同様のやり方で、実際には、透過的に各々のシステムをボリュームの正しい部分までスキップさせるために、ボリュームのはじめにポインタを提供することによって、これは成し遂げられる。この種の技術は、レガシーシステムを、ボリューム(又はファイル)が実際にレガシーフォーマット化されたボリュームであると思っているように、騙すことができる。したがって、サンプルデータファイルがヘッダフィールド530の付加情報から利益を受けるシステムのヘッダフィールド530内に、サンプルデータファイルが周期情報520及び/又はピッチ情報515とともに提供されるとき、本発明の利点が利用されるが、同じサンプルデータファイルをまた、ヘッダフィールドにおける付加データから利益を得ることができないシステムにおけるサンプルデータを提供するために使用することができる。後者の場合、そのファイルは、音響サンプルデータ510だけを提供するようにシステムに現れる。
ピッチ情報515は、固有の周期率である、サンプルに伴うピッチを示しているパラメータデータを含む。例えば、このパラメータデータは、サンプルが通常の未調整率で演奏される場合、ピッチ値がC#に対応する値に関連付けられる。これは、関連音響サンプルデータがC#音符とみなされる楽曲生成処理に関係する楽曲ルール及び/又はアルゴリズムに知らせる。すなわち、C#音符が互換性を持つと考えられる場合、音響サンプルは、いかなるピッチ調整なしで好ましくは演奏される。この方式に対する一つの利点は、C#が互換性を持つと考えられない場合、音響サンプルデータが、適当なピッチ値に対するピッチを上又は下に移行することができるということである。アルゴリズム/楽曲ルールが固有の再生速度のためのピッチ情報を知っているので、それらはピッチの調整を算出することができ、再生の間、サンプルの認められたピッチを調整するために、DSP資源及び機能性(ドリームチップに関して本願明細書において論じられるように)を使用することができる。このように、サンプルピッチは、通常、現在のモード(一つの実施例として)に与えられた適当なピッチに合致する。
周期情報520は、期間関連のパラメータデータを含む。このデータは、関連する音響サンプルデータのタイミング特性を識別する。例えば、音響サンプルが最初から75ミリ秒のリズム強調位置を有する場合、このパラメータによりこれを示すことができる。この例では、ヘッダの期間部分は、固有の速度で演奏されるときに、音楽作品を生成する楽曲ルール/アルゴリズムに対して、この特定の音響サンプルが75ミリ秒のリズム強調位置を有することを、知らせる。したがって、それがメモリに書き込まれ、エンドユーザが歌曲中のそのサンプルを演奏するとき、楽曲ルール/アルゴリズムは、そのサンプルのリズム強調位置を知ることができ、かつ、リズム強調位置が楽曲の適切な位置(例えば、ダウンビート)で起こるように、サンプルを時間調整できる。この時間調整は、例えば、ここで述べられたように、DSP資源及び機能性を使用して行われる。例えば、サンプルが定義可能なテンポを有する場合、周期情報520は、分あたりの拍子(BPM)情報の形で伝達することができる。
本発明のこの種の実施例は、エンドユーザの音楽の経験を改良する方法を備える楽曲演奏システムを提供することができることが明らかであろう。この種の装置は、例えば、ハードウェアシステム(例えば、手で持てるサイズの携帯用機器)又はソフトウェアシステム(例えば、パーソナルコンピュータ上で動作するソフトウェア音楽システム)で、使用することができる。ピッチ又は時間非互換性による弊害は比較的小さく、サンプルは、このようにエンドユーザによって歌曲の間、演奏される。
図51は、サンプル音響ファイルと関連する振幅波形の簡略例を示す。図示の例において、T1、T2及びT3で表される、増加するリズム動作(例えば、振幅の急激な一時的な増加)の3つの一般的な位置がある。サンプルデータファイルは、増加する振幅のこの種の領域を識別するために、ソフトウェアを経て処理される。図51において表される波形が、例えば、290msの持続期間であると仮定する。例として、解析ツールが10msのグリッド解像度(垂直グリッド線を有する図に示す)を有する場合、解析ツールは、リズムイベントを検索するために、ファイルを走査する(例えば、比較的高振幅の短い瞬間)。一つの好ましい実施例において、ツールはリズムイベントの直前のグリッド位置を識別して、任意のヘッダフィールド530のデータに包含させるよう、その情報を取り込む。図54に関して、分析プロセスに関する詳細は以下でさらに説明する。
図51に示したように、実施例サンプルは、非等距離となるように間隔をあけられるほぼ3つの重要なリズムイベントを有する。もちろん、この分布例は、10msのグリッド解像度及び290msのサンプル継続期間のいくぶん任意の例に基づく。このグリッド解像度の場合、この例は、4つのリズムサブパート(例えばT0、T1、T2及びT3から始まっている部分)が異なる持続期間である例である。この例では、第1のリズムサブパートは、0 msのタイムスタンプT0及びGのピッチ値P0を有する。第2のリズムサブパートは、50msのタイムスタンプT1及びF#のピッチ値P1を有する。第3のリズムサブパートは、110ms及び不定ピッチ値のタイムスタンプT2を有する。第4のリズムサブパートT3は、200msのタイムスタンプ及びG#のピッチ値を有する。
この例では、明確にするため、楽曲のモードが、サンプルが演奏される歌曲の位置で「リディアン降順」であると仮定する。
したがって、T0:P0と確認される第1のリズムサブパートは、「リディアン降順モード」において許容可能であるピッチ値を有する。したがって、サンプルのこの楽節はピッチを移行しない。同様に、サンプルの起動のリズムイベントがエンドユーザによって始められるので、時間T0は調整されない。
この実施例をさらに説明する。T1:P1として確認される第2のサブパートはF#のピッチ値を有し、「リディアン降順モード」において許容され、したがって、ピッチを移行しない。リズムイベントT1は50msと関係し、したがって、これは、より密接に楽曲のテンポに釣り合うように時間シフトされる(例えば、創作されている楽曲の周期的グリッド/解像度と符合するために、僅かに減速されるか又は速度を上げられるかする)。歌曲の楽節がテンポを有し、例えば、8分音符が60msの継続期間を有する場合、T1:P1の起動が8分音符の始まりに合わせて起こるように調整され、T1:P1の継続期間は、音楽の拍子記号に合わせて、60msを占めるように僅かに長くされる。もちろん、これらの例は、本発明を実施するために必ずしも使うことができない、さまざまなオプションを構成する。
以前のサブパートが通常の速度で演奏されていた場合、第3のサブパートT2:P2は110msから始まるであろう。この例では、前のサブパートが10ms長くされているので、テンポと同期をとるためには、T2:P2サブパートは120msから始まる。したがって、60msの8分音符の例では、サブパートT2:P2の始まりがテンポと同期して起こり、そして、それが90msの継続期間を有するので、それは120ms(69msの8分音符に合わせて)の継続期間に対して50%時間伸張されるか、時間が60msまで減少されるか、又は90msのままであるかである(例えば、演奏されている楽曲のスタイルのために適所にある特定の楽曲ルール/アルゴリズムに依存している)。このサブパートが関連ピッチ値をもたないので、ピッチを調整していない。
図2の最後のサブパート T3:P3は、G#の関連ピッチ値を有する。現在のモードが、楽曲生成フローの間に遭遇したG#音符がGと置き換えられる「リディアン降順」であると仮定すると、サンプルのこの楽節は、Gまで関連ピッチを下げるようにピッチが調整される。楽曲のスタイル及び/又は拍子記号、グルーブ、その他に合わせて、本願明細書において記載されているように、始点及び持続期間を指定することができる。
図50に示したように、サンプルに関連するピッチ及び周期性を識別している情報は、隣接して配置される。第52図にて示したように、この情報は、また、ヘッダフィールド590の交互サブフィールドに配置することもできる。3セットの周期/ピッチ情報を示している図52の例の場合、タグID585は、サンプルデータフィールド595の音響サンプルデータ550の前に続くヘッダサブフィールド/パラメータの数を設定する情報を含むことができる。図52の例において、この方式により、音響サンプルデータ550が3つの関連周期/ピッチサブパート(周期情報 580及びピッチ情報575、周期情報 570及びピッチ情報565、及び、周期情報560及びピッチ情報555として識別される)を有することを、処理の間にシステムに知らせる。
本発明のある好ましい実施例においては、ピッチ及び周期性情報がサンプルファイルのヘッダフィールド部分にある必要はなく、あるいは、別々の記述子ファイル(例えば、多数のサンプルのための一般のサンプルリストファイル又は同じ名称、異なる接尾辞、その他を有する各々のサンプルのための単一の第2のファイル)にあってもよい点に注意すべきである。これの一つの例が図53に示され、この例では、別々の記述子ファイル615が、固有のフォーマットサンプルファイル616(例えば、名称、ピッチ、周期及び他の情報)と関連する情報を含む。この方法の効果は、サンプルファイルが固有のフォーマット(例えば、MP3、WAV、その他)のままであるということであり、よって、本願明細書において論じられたように、それらは、ヘッダ部分に加えられる付加的なピッチ及び/又は周期情報をもたない。この種の方法は、本発明の利点をさらに確実にしつつ、クロスプラットフォーム互換性を改良する。
図54は、サンプルファイルと関連する記述子情報をつくるための方法の典型的な手順フローを例示する。この種の方法は、システムの処理資源が充分であると仮定すると、楽曲生成の間、リアルタイムに実行することができ、あるいは、リアルタイムサンプル特性処理の充分な処理能力を有しないシステム(例えば、携帯用)のためには、図54に例示される処理を前もって実行するようにすることができる。加えて、計算資源が比較的豊富である個人コンピュータシステムにおいて、図54に例示されるステップが実行される。この変形例において、サンプル記述子を、実際に楽曲を演奏するポータブルシステムへ転送することができる。従って、図54に示されている解析特徴は比較的パワフルなコンピュータシステムによって最適に実行されることができるが、この種の分析の利点は、先に参照され取り込まれた特許出願に照らして、ポータブルシステムで実現されることができる。
図54のフローは、サンプル(ステップ650)のアクセス及び/又は書き込みにより開始される。サンプルのメモリ上の位置に応じて、コンピュータシステムは、単純にサンプル(例えば、RAMから)にアクセスすることができ又は書き込む(例えば、フラッシュ又はマイクロドライブ又はスマートメディア、その他から、RAMに)ことができる。ステップ651は、リズム特性を引き出すためのサンプルの分析を含む。リズムタイミング情報に次のピッチ特性を組み合わせることは有用であり、ステップ651はステップ652のピッチ分析の前に実行される。しかしながら、別の実施例においては、この順序は変更することができる。すなわち、当業者が理解できるように、本発明の利点を実現するためには、これらステップをこの特定の順序で遂行しなくてもよい。ステップ653は、データフォーマットへの生成されたピッチ及び/又はリズム特性の準備(例えば、結合)を含む。ステップ654は、ファイル(例えば、先に述べたように、別々の記述子ファイルに又はサンプルデータファイルの例えばヘッダ部分として)に、この種の特性データフォーマットの組み入れ動作を含む。
図55は、本説明の好ましい実施態様に従うサンプルの再生のための典型的な手順フローを例示する。例えば、この再生手順フローを、作曲又は歌曲の作成/再生の間、与えられたサンプルを演奏している携帯用及び/又はソフトウェアベースの楽曲装置によって使うことができる。詳しくこの開示の他の箇所で議論されるように、本実施例では、楽曲装置がパーソナルコンピュータ上の携帯用ハードウェアシステム又はソフトウェアプラグイン形であってもよいが、現在の楽曲モード及び/又はテンポを探し出す楽曲アルゴリズムを有する必要がある。この情報が楽曲演奏の間に探し出されて、使用される方法の実施例は、本願明細書の他の箇所で詳述するので、本説明のために、この音楽モード/テンポ情報がサンプル再生の間、利用できると指摘するのに十分である。
図55は、サンプルファイル(ステップ660)にアクセス及び/又は書き込みを行ったときに、サンプルファイル(ステップ662)のための関連記述子があるかどうかについて決定することを例示する。もし、関連記述子がない場合には、楽曲創作/再生の間、サンプルはそのまま(ステップ670及び672)演奏される。しかしながら、サンプルファイル記述子情報が、与えられたサンプルファイルと関連していると判定した場合(判定のステップ662で「Yes」)、それはアクセスされ(ステップ664)、演奏されている楽曲(ステップ666)(例えば、本願明細書において図51に関する説明に関連する)の現在の包括的なピッチ及び/又はリズム情報に関連して(例えば、比較されて)、処理される。現在の包括的なピッチ及び/又はリズム情報との比較又は相対的処理の後、DSP機能動作の一組が、サンプルの速度及び/又はピッチをより密接に又は望ましくはそれを包括的ピッチ及び/又はリズム情報に従わせるよう制御するために、準備される(ステップ668)。そして、この動作の組は、サンプルが実際に演奏される(ステップ670及び672)ときに使用され、最小限のユーザ動作によって、その後使われるサンプルのピッチ及び/又はリズムが演奏されている楽曲の形に従っているという結果をもたらす。明らかなように、ステップ670において、判定は、サンプルを演奏するために適宜の時間について行われ、そして、ステップ672において、包括的情報に基づいて速度及び/又はピッチを制御するためにDSPを伴って、サンプルは実際に演奏される。
したがって、本願明細書において詳述するように、一連のピッチ及びリズムイベントが検出されたサンプルの場合、この種のイベントは、より密接に生成されている楽曲に釣り合わせるために時間調整されるか及び/又はピッチ調整される。これは、例えば、DSPタイプ動作を実行するDSPインストラクションの実行によって、デジタル信号処理資源又はシステム機能を使用して行われる。明らかなように、連続ではなく、サンプルに単一のピッチ値及び/又はリズムイベントだけを割り当てることによって、本発明は、より単純な方法で適用される。
本願明細書において、先に例えば、図39〜42に関連する説明に関連して、音声サンプル及び効果をMIDIイベントの効果的同期に関して説明し、かつ、この種の同期を達成するためにMIDI NRPNメッセージの使用を含めて、該効果的な同期を達成するためのハードウェアについて説明した。本発明の好ましい実施例は、MIDIイベント及び音声サンプル及び効果のこの種の同期と結合して使われる。
本発明の好ましい実施例は、携帯用の自動楽曲生成装置を提供する。該装置は、本願明細書に開示されているように実現される。本発明によれば、しかしながら、携帯電話機、個人データアシスタント、その他において使用されるような、先に述べた携帯用の自動楽曲生成装置の実施例アーキテクチャに、無線装置を容易に組み込むことができる点に留意する必要がある。一つの例として、先の開示のUSB通信インターフェースは、RF−増幅器ベースのセルラ方式通信モジュールのデータ受信及び/又は放送回路につながっている通信インターフェースで置換することができる。また、本発明の利点を達成しつつ、他のデータインターフェース装置も有効にされ得る。同様に、携帯用機器は、自動車関連のシステム(例えば、ラジオ又は通信システム)の一部、又は在宅音楽システム(例えば、バンド幅の少ない携帯用技術との互換性のために)の一部分であってもよい。全てのこの種の実施実施例は、本発明の範囲内である。
図56は、好ましい実施態様に従った放送装置を例示しており、該装置の送信機710は、大きな放送プログラム(それは、好ましくは楽曲又は他のコンテンツ等の多数のスタイル/カテゴリから成る)の一部として、放送楽曲データファイル715を放送する。図56に示すように、ノード楽曲生成装置720は、放送楽曲データファイル715を受信して、そこから楽曲を生成し始める。この種の実施例に従って、ノード楽曲生成装置720が楽曲データファイル715を受信することができ、受信された楽曲データファイル715に基づいて、自動的に楽曲の作曲を開始することができ、若しくは、楽曲生成を、ユーザ入力、例えばキー、ボタン又はスイッチの押し下げの後に開始し、あるいは、受信された楽曲データファイル715のユーザによる変更後に開始することができる点に留意すべきである。
図56はまた、ノード著作楽曲データファイル725がノード楽曲生成装置720から送信機710に書き込まれる別の実施例を例示する。ノード著作楽曲データファイル725は、例えば、ノード楽曲生成装置720によって自動的に作曲された楽曲データである場合もあるが、この種のノードのユーザによって変更されたものであってもよく、又は、この種のノードで先に受信されていた楽曲データファイルであってもよく、この種のノード、その他のユーザによって、その後変更されたものであってもい。図56の例ではノード著作ファイルが送信機710にアップロード送信されることを記述したが、別の実施例によれば、楽曲データファイル725は、送信機710に関連する他の同様のノードにも送信され、さらに別の実施例では、別のノードに直接送信されることを理解すべきである。例えば、ノード著作楽曲データファイル725は、放送楽曲データファイル715の放送を管理している放送サービスに関連する受信機に送信される。この「アップロード」機能は、ノードの加入者ユニットが楽曲を著作し、それを放送システムに転送することを可能にし、転送された楽曲を放送に組み込むことができる。明らかなように、この方法は、放送されている実際の音楽へのユーザ参加を可能にして、ノードの間で音楽の共有を可能にする。この方法も、ノード間で直接的に(例えば、送信機 710からの一般放送を含まなくて)、音楽内容の簡単な共有を可能にする。
図57は、ノード/加入者ユニットラジオにおけるラジオスタイルの選択を例示する。図示するように、ノード/加入者ユニットは、情報受信/送信のためのアンテナ755を含む。好ましくは、この種のノード/加入者ユニットはまた、スピーカ760、オーディオ入力765、オーディオ出力770、ディスプレイ775、ユーザインターフェース780及びマイク785の1又は複数を具備している。図示するように、ディスプレイ775は、ユーザにラジオスタイル選択表示を提供するために用いることができる。この種の表示は、ユーザが複数のラジオ局及び/又は楽曲スタイルから適宜選択することを可能にする。好ましくは、ラジオ局及び/又は楽曲スタイルを選んだ後に、ユーザにより選択されたラジオ局/受け取られる楽曲データファイルのスタイルに対応するスタイルで、放送/受信動作(例えば、図56と関連して本願明細書において記載されているように)が行われる。
図58は、本発明のノード/加入者ユニットの好ましい実施例に伴う、特定の機能ブロックの実施例を例示する。ノード/加入者ユニット860は、アンテナ800、送信/受信回路805、電話/PDA装置810、通信インターフェース815及びディスプレイ820を含む。その上、該ユニットは、それ自体が楽曲アルゴリズムブロック830を含む楽曲生成器825、DSPブロック83及びメモリ840を含む。この種のノード/加入者ユニットも、オーディオ入力840、マイク845、オーディオ出力850及びスピーカ855の1又は複数を備えている。
本明細書のいずれかの箇所で論じられたように、本発明の特徴を使用すれば、着信音が多くの本発明の態様と整合した方法で、アルゴリズム的に創作され、特に電話手段(例えば、携帯電話機)において好適である。ある程度の多様性を着信音に与えることが好ましい実施例(例えば、それにより、電話が鳴る毎の着信音が異なる)において、着信音のテーマで、ある程度の認知可能性を保持することも好ましい。この特徴は、特にアーティストに特有の着信音等と関連して有利である。その結果、電話が鳴るたびに歌曲が認識されるが、しかし、それはまた、各時点で少々異なる。例えば、楽曲レーン(トラック、楽器、その他)のサブセットが利用できない(例えば、ユーザ、アルゴリズム、その他に対して)所で、技術を用いることができる。この例では、レーンのこのサブセットは、歌曲の種々テーマ(スタイル、その他)を含むことができる。この方法では、着信音が演奏されるたびに、他のレーンは変化することができ、そしてそれであっても、テーマは認識できる状態を維持する。これらの特徴の多数は、その他の、着信音に関係しない実施態様(例えば、携帯用音楽プレーヤ、ビデオゲーム装置、ウェブサイトプラグイン、その他)へも、適用することができる。
電話着信音作曲環境のような携帯用環境において好ましい付加的な特徴は、電話の終わりでアルゴリズム的に作曲を実行することである。この例では、更に詳細に上で述べられたように、それが呼び出される(例えば、入って来る電話を経て)たびに、着信音はある程度変化することができる。ある実施例において、認識できるテーマを一定にすることができる方法で、着信音は限られた範囲で変化することができる。これらのさまざまな実施例では、着信音が次に呼び出される前のある時点で、いくつかの自動作曲アルゴリズムを使用して着信音を生成する必要がある。充分な処理資源がある場合には、到来する電話を着信音処理のきっかけとして、リアルタイムでこの自動作曲を実行することが好ましい。しかしながら、例えば、バッテリ寿命等を最大にするために処理資源を最小化する必要がある携帯用環境で、処理資源がより限られる状況下では、携帯用機器が動作の特に忙しい状態(例えば、相当な処理資源を占める電話又は他の若干のモードに参加している)でないようなときに、より理想的な時間に着信音自動作曲処理を始めることが好ましい。一つの実施例においては、電話が終了した(又は、まもなくその後で)時点を、着信音自動作曲処理のきっかけとすることが有利である。着信音は、電話の終了において自動作曲され、次の着信音イベントで演奏される着信音に結果としてなる。この方法では、処理資源の必要量を最小化する手法で、可変着信音の機能が提供される。
本発明の実施例の新しい態様は、特に効果的な楽曲配信及び生成システムの使用法を含む。従来の方法のさまざまなFMラジオ放送システム、又はインターネットストリーミングシステムと異なって、本発明は、送信機ではなく、ノードによって生成される楽曲を利用する。ノードは、本質的には、生成される歌曲を定めるデータ又は命令を含み、そして、歌曲を生成するために、ノードのハードウェア/ソフトウェアによって利用されるデータファイル(データ又は命令は、しかしながら、従来技術の放送/ストリーミングシステムに類似している歌曲の若干の副構成要素(サンプルのような)を含むことができる)を受信する。この種の情報、データ又は命令の実施例は、図59及び図60に関して後述する。通常、好ましい実施態様によれば、命令は、例えば、テキスト形式又はいくつかの他のフォーマット(すなわち、特に従来のストリーミングオーディオ−タイプ方法と比較して、それが比較的ごくわずかなバンド幅しか消費しない)で送信されるデータを含む。後述する実施例においては、放送楽曲データファイル(ここでは、少しのデータで測定された)の容量は、例えば、3分の歌曲に対して約200キロビットであるように企図される。
図59は、放送楽曲データファイルに組み込まれることができる、さまざまな典型的なパラメータを例示する。
「Application Revision(アプリケーション改訂)」は、データ構造を生成するために用いるファームウェア/アプリケーションバージョンを記憶するために用いる。ファームウェアがアップグレード可能である場合において、これは特に有用である。
「Style/Substyle(スタイル/サブスタイル)」は、音楽のスタイル及び/又はサブスタイルを示すために用いる。特定のスタイル及び/又はサブスタイルと関連するルールによって歌曲生成処理が支配されるというシステムに対して警報を出すために、さまざまな変数及びルーチンを初期化するときに、これは有用である。好ましい実施例において、スタイル及び/又はサブスタイルは、「ハードロック」、「環境」、「イージーリスニング」、その他のような楽曲のラジオ局スタイルに当てはめることができる。特定のケースにおいて、例えば後述するように、ラジオ局スタイルは、楽曲データファイルの受信の前に、ユーザが選択可能でもよい。
「Sound Bank/Synth Type(音響バンク/合成タイプ)」は、歌曲の生成において使われる特定の音響を示す。例えば、これはMIDI DSP資源のための音響設定を予め書き込みする方法である。
「Sample Frequency(サンプル周波数)」は、サンプルが歌曲に組み込まれる場合、サンプルがどれくらいの頻度で演奏されるかについて示すために用いることができる設定である。あるいは、これはサンプルがデコードされる率を示すことができる。そして、それは、サンプル再生の周波数を調整することに役立つ技術を提供する。
「Sample List(サンプルリスト)」は、データ構造に関連するサンプルの全ての一覧を示す。このリストによって、ユーザは、歌曲再生の間に更に選択して、関連したサンプルを演奏することができる。
「Key(キー)」は、歌曲に使用される最初のキーを示すために用いる。ピッチオフセットでこれを示すことができる。
「Tempo(テンポ)」は、歌曲の起動テンポを示すために用いる。分あたりの拍子(BPM)情報でこれを示すことができる。
「Instrument(楽器)」は、一群の楽器の中の特定の楽器を識別するデータである。これは、例えば、一群の全てのギター音響の中から、音響ナイロン弦ギターを識別することができる。このデータは、楽器タイプによってインデックスを付けられる。
「State(状態)」は、特定の楽器の状態を示すデータである。状態の例は、弱音化、非弱音化、標準、強制演奏、独奏、その他である。
「Parameter(パラメータ)」は、さまざまな楽器パラメータ、例えば音量、パン(pan)、音質、その他のための値を示すデータである。
「PRNG Seed Value(PRNGシード値)」は、擬似乱数生成(PRNG)ルーティンを初期化するために用いる一連の数値である(この種のPRNGシード値は、ある幾つかの実施例でのみ使用され、本発明はこの種のPRNGシード値の使用することに限られていない)。これらの値は、歌曲全体の再現を可能とするために、PRNGの本質的に予測可能な性質を利用することによって歌曲を記憶する、特に効率的な方法示す。
「Song Structure(歌曲構造)」は、歌曲内パートの数及びシーケンス、並びに、歌曲の楽器タイプの数の一覧を示すデータである。
「Structure(構造)」は、パート内のサブパートの数及びシーケンスを含むパートによってインデックスを付けられたデータである。
「Filtered Track(フィルタリングされたトラック)」は、効果の特性を記述するデータを保持するために用いることができるパラメータである。例えば、それは、矩形波及び特定の初期値を有する効果の変調タイプを示すことができる。効果が特定のパートに関連するので、このパラメータは、パートによってインデックスを付けられることができる。
「Progression(進行)」は、各々のサブパートのための特性情報である。これは、拍子記号、SEQの数とシーケンス、マスキングされる楽器タイプのリスト、その他を含む。
「Chord(コード)」は、サブパートの期間中の楽曲変更に対応するデータ含む。コードベクトル(例えば+2、−1、その他)、キー音符(例えば、F)及び進行モード(例えば、ドリアン昇順)データが、タイムスタンプによって記憶される。
「Pattern(パターン)」及びサブパラメータ(「Combination(組合せ)」、「FX Pattern(FXパターン)」及び「Brock(ブロック)」)は、全て実際のブロックデータ及び歌曲で使用される楽器の各々に対する効果情報を含む。このデータは、楽器のタイプによってインデックスを付けられる。
例えば、特定の歌曲と関連する音響バンクデータの少なくとも一部が組み込まれるようにするために、他のパラメータが好ましくは含まれる。この例に従って、この種の放送音楽データファイルがアクセスされたときに、楽曲出力の生成の間に音響バンクデータを使うことができるよう、音響バンクデータの少なくとも一部が不揮発性メモリに書き込まれる。
その上、これらのパラメータの多数は、関連タイムスタンプを有するデータを組み込むことができる。このオプションの特徴は、各イベント等のタイミングを示すために用いることができる。
放送歌曲データ構造のこの種の典型的なパラメータの使用で、歌曲が生成されるデータは、能率的に多くのノードの楽曲発生器装置に放送される。特定のパラメータタイプが好ましくは変化するが、この種のパラメータの使用は、必要な全ての詳細がノードにおいてゼロから正確かつ忠実に歌曲を再生させることを可能にする。
図60は、本発明を実施するために、放送歌曲データファイルと結合して各ノードの楽曲発生装置によって使われる、好ましい一般的アーキテクチャのための論理フローチャートを表す。このフローチャートは、好ましいソフトウェア/ファームウェア実現のための全体像を例示し、歌曲生成処理のためのより詳細な典型的な手順フローを提供する。
図60のフローの開始時(開始点862)に、加入者ユニットによって受信された後、パラメータデータは放送歌曲データ構造から好ましくは書き込まれる(ステップ864)。若干のパラメータ値が決定されて/書き込まれると、所与の歌曲パートのための楽曲が生成され始める(ブロック866)。そして、ユーザインターフェース(例えば表示、ビデオ出力、圧力フィードバック、その他)は、それに応じて更新される(ブロック868)。この過程の任意の位置で、楽器又は効果の変更のようなユーザ入力が検出される(「保存する」以外の命令)(決定ブロック872)場合、ユーザによって現在変更されている歌曲のパートのための関連したパラメータデータが更新され(ブロック876)、そして、与えられたパートのための楽曲の生成が続く。ユーザ入力「保存」命令が検出される(決定ブロック874)場合、全てのパラメータデータは非一時的記憶場所(例えばフラッシュメモリ、ハードディスク又はある程度の永続性をもつ余裕がある他の書き換え可能なメモリ記憶場所)に、保存される(ブロック870)。ユーザがその全体を保存することを決める前に歌曲の大部分を聞くことができるので、この方式は望ましい。ユーザ入力がない限り、歌曲パートの終端が検出される(決定ブロック878)まで、与えられた歌曲パートのための楽曲の生成が継続される。終端が検出されると、フローは、次の歌曲パート(ブロック884)へ進む。この時、必要に応じて、次の歌曲パートのための関連したパラメータデータが決定されて/書き込まれる。結局、歌曲の終端条件(決定ブロック880))が検出されると、その歌曲は終了する(ブロック882)。
図61は、本発明の実施例に適用し得る典型的な通信産業協会(TIA)規格を記載する。広範囲なメッセージ及び/又は他のデータサービスオプションが現在のセルラ産業において利用可能であるので、本願明細書において記載されている楽曲配信のコンセプトは、種々の異なる手段を使用して実現可能である。本開示に従って楽曲データファイルを配信するために用いることができる、いくつかの有効なアーキテクチャがある。例えば、時分割多重アクセス(TDMA)、移動通信用グローバルシステム(GSM)及びコード分割多重アクセス(CDMA)である。図61は、セルラ分野でのデータ配信の好ましい実現に関する詳細を含むある規格を参照するものであり、したがって、これらの全体にわたって本明細書に取り込まれたものとする。明らかに、これは、網羅的なリストではなく、むしろ、単に関連する公表規格のいくつかの実例を挙げたものである。
図62は、TIA/EIA IS−637の「Short message Service for Wideband Spread Spectrum Cellular System」である典型的な規格からのある例を示している。図62に示したように、オプションのベアラー(Beareer)データを可能にするSMS放送メッセージが定められる。この例に従って、ベアラーデータは、可変長(例えば、SUBPARAM_LENとの関係にて説明したように)のサブパラメータデータを含むことができる。SMS放送メッセージのこの実施例は、本発明の態様(例えば、図56にて示したように、放送楽曲データファイル File715を送信する手段)を実施するために用いてもよい。その上、図56において例示されるノード著作楽曲データファイル725に関連して使われるIS−637規格において定められるメッセージと同じような他の定義済みメッセージがある。一つの例として、「Data Burst Message」がTIA/EIA IS−95−Aに記載されているのを参照されたい。明らかに、本発明の利点について目的を達成するために、他の規格も場合によっては採用可能である。同様に、上述した電気通信規格において特定されるデータ処理の他のタイプを、本発明の趣旨及び範囲から逸脱することなく、本願明細書において言及される特定の実施例に置き換えることができる。
更に、また別の実施例においては、図57を参照して、本発明の多くの利点を、クロック又はクロックラジオ装置に組み込むことができる。図57に示すように、クロックラジオは、クロックラジオユーザのためのグラフィックインターフェースを示すことができるディスプレイ(例えば、ディスプレイ775)を備えている。一つの実施例において、ディスプレイは、警報設定と同様に、時間を示すためにも用いられる。ユーザ入力インターフェース780は、クロックラジオユーザに、時間及び/又はアラーム情報を入力するための手段を与えるために用いることができる。ある実施例において、スピーカ760は、所望の時間にクロックブザーを鳴らす。ユーザに完全に新しい音楽作品で毎朝を目覚めさせることができるアラームクロックにおいて、本願明細書において論じられる好ましい具体化の多くの態様を使うことができる。ある実施例において、楽曲のスタイルは、ユーザ(例えば、ユーザ入力インターフェース780及びディスプレイ775を介して)によって選ばれる。
ある実施例において、楽曲出力の特性を、アラーム動作の間に、調整することができる。例えば、楽曲のスタイルは、静かなリラックスした環境から、楽曲のよりエネルギッシュで騒々しいスタイルまで、次第に変化してもよい。好ましくは、ユーザがスヌーズボタン(例えば、ユーザ入力インターフェース780を介して)を押すたびに、又は所定の間隔で(それは、更なるユーザ動作なしでもよい)、この進行は起こる。このように、アラームクロックは、最初にリラックスした静かな及び/又は単純な一曲でユーザを起こすことができ、ユーザが長くベッドにいようとすると(例えば、単にアラームを消さずにベッドに残ることによって又はあるいは、スヌーズボタンを押し続けることによって)、次第により活発になる。
あるアラームクロック実施例において、同様に、スムースコード進行からより不協和のものまで、次第に音楽を調整することが好ましい。例として、図19を参照すると、アラームクロック楽曲がメジャーコードから始まり、アラームがより長く鳴り続けるのに伴って、より不協和に(例えばマイナーコード)なる。あるアラームクロック実施例において、音符ピッチの相対的に低い可動性を有する楽曲から始めて(図23を参照)、ユーザがベッドになおとどまる時間が長くなれば、次第に音符ピッチの相対的可動性を増やすことが好ましい。他の例では、リズム密度は、比較的低周期的密度(例えば、図22参照)から、比較的高周期的密度まで推移する。これらの実施例は、ユーザを和らげる音楽作品で起こし、そして、ユーザがベッドにとどまる時間が長くなれば、次第によりエネルギッシュで複雑及び/又は不協和になる。
更に、また別の実施例においては、図57を参照し、ユーザインターフェース780(例えば、ある数字を覆っている文字をもつ、典型的な携帯電話機テンキー)の使用は、ユーザが自動楽曲生成システムに名前(例えば、彼(女)の名前又は愛されるもの又は他のいくつかの語)を入力することを可能にする。典型的な別の実施例において、入力された名前が厳密なやり方で自動作曲処理にイニシャル署名するために使用される。それによって、キー入力によって決定された唯一の歌曲が、その名前のキー入力に基づいて自動的に作曲される。本願明細書において開示された実施例に従えば、例えば、名前の文字が、最初のシードを生成するアルゴリズム、楽曲データ又は疑似乱数発生処理(PRNG)等へのエントリ、その他において使われる。それによって、自動作曲処理を始める最初のデータは、名前のエントリに基づいて決定される。一例として、入力された文字各々のASCII表現を加えて、おそらく若干の数学を数に適用し、そして、その結果生じる値を、PRNG処理等へのエントリとして使用する。この例を続けると、典型的テンキー(例えば、文字「abc」は数「2」、3に対する「def」、その他と一致する)に使われるように、各々の文字が数値を有することができ、そして、その数はPRNG処理に適切な入力に結果となるために数学的に処理される。この、後者の実施例は、ここで開示された実施例のあるものがキーパッドインターフェースがサポートされる携帯電話機機、又は類似した携帯用製品(例えばPDA又はページャ)に組み込まれる場合、特に有利である。
処理が厳密であるので、少なくとも同じリリース又は楽曲生成システムのバージョンのために、名前の全てのエントリにより、特定の人のための同じ唯一のすなわち「署名」歌曲を生成する。別の実施例の自動作曲処理は、部分的に、名前の文字の入力の時間又はタイミングに基づくものである。したがって、名前入力プロセス(この種の人間の相互作用ランダム状態は参照され、組み込まれた特許文献において述べられている)及び個々の名前入力のための本質的に固有の歌曲生成に、ユーザ時間−ランダム状態を差し挟むものであるが、好ましい別の実施例では、複数の数のユーザが、それら名前又はそれらにとって重要な他のいくつかの語に基づく「それらの歌曲」として特定の曲をもつことを好むと思われるので(何らかの形でそのユーザの名前と関係していてもよい多数の曲を提供するため、テンキーインターフェースと関連して本願明細書において記述されるように、一連の文字に対応する数を使用するために、ユーザは、例えば、逆向きに、数字を使って上下逆さまに、大文字でない、ニックネーム、その他のように、異なる形式で彼/彼女の名前/語を入れることができる)、好ましい別の実施例では、厳密な、非ランダムな方法が使用される。当業者が理解できるように、このコンセプトも自動作曲される楽曲スタイル選択に適用できる(参照され、取り込まれた特許文献にて説明したように、スタイルは、ユーザ入力に基づくランダムな選択処理の一部であり、又は、スタイルは選ばれる)。例えば、特定の画曲生成システムによってサポートされる楽曲のスタイル又はサブスタイル毎に、各々のスタイル又はサブスタイルのための唯一の曲は、ユーザの名前(又は他の語)の入力に基づいて、あるいは、厳密には、例えば、ユーザがスタイル、その他を選択するようにして、文字のユーザ入力などのタイミング又は他のランダム性に基づいて、創作することができる。
明らかなように、ノード/加入者ユニットの楽曲生成デバイス720での自動作曲処理を開始するための名前入力が名前に限定されないというコンセプトは、他の英数字、グラフィック、他のデータ入力(生年月日、語、ランダム入力された文字、その他)まで広げることができる。タッチスクリーンを使用している実施例に関して、例えば、他の入力(例えば、引出し線、図、ランダムな線、グラフ、点、その他)は、厳密に又はユーザ入力等のタイミングに基づいて、自動作曲処理を始めるために用いることができる。重要であることは、英数字特性のキーボード入力のようなユーザ入力、又はタッチスクリーンを介した図面線のような他のデータ入力エントリ(すなわち、例えば、本来は一般に音楽的でないデータ入力)は、独自にデータ入力イベントに関連する楽曲の作曲を始めるために用いることができる。このように、唯一の楽曲作品は、非音楽的データ入力に基づて創作できるので、音楽に堪能でない人でも、非音楽的データ入力に基づいて唯一の楽曲を創作することができる。この種の非音楽的データ入力に基づいて、楽曲生成処理は、シード又は他の楽曲生成の開始データを選んで、自動作曲処理を開始する。明らかなように、特に英数字データ入力に関して、この種の文字も記憶され(単独か、又はデータ入力と関連する楽曲生成開始データを伴って)、他の楽曲生成システム(送信機710を介して)に送信される。それによって、非音楽的データの伝送は、実際には、楽曲生成システムによって創作される曲を決定する情報を送信するための少ないバイト数のデータだけの送信で、唯一の曲を他のユーザ/システムに発信するために用いることができる。
その上、多くの本発明の態様は、ファームウェアのアップグレードの新しい概念を可能にするために役立つ。本発明の態様を用いて、ファームウェア更新をーザが利用でき、組み込み広告を完備したようにされることができる。そして、それは、ファームウェア製造者/販売者に、ユーザ以外の収入源を提供する。このコンセプトは、組み込み広告映像(及び/又は音響)を含むファームウェア(又は、音響バンクデータのような他のソフトウェアベースのプログラム)のアップグレードの配信を含む。この種の映像/音響は、音楽製品の動作中に一時的に現れることができ、自由にダウンロードするユーザのためのカスタマイズされたファームウェアの開発に資金を供給することができる。
音声合成の間の補間寄せ集めと関連する好ましい本実施例を、図63〜図68と関連して説明する。
音声合成を実行するための典型的な合成構造が、図63に例示される。オーディオイベント901(例えば、NOTE ON命令のようなMIDIイベント)が音声合成900アルゴリズムに入力される。これは、オーディオイベントに関連する1又は複数のパラメータ(例えば、波形ファイル及びパラメータデータの好ましくは組合せのような、MIDI 製造者協会によって発行されるダウンロード可能な音響仕様(DLS)と互換性を持つ)によって、実行される。パラメータデータ902が、オーディオイベント901入力に対応する1又は複数のサンプル903を出力する音声合成900アルゴリズムによって使われる。音声合成900によって遂行される処理作業の主要部(例えば、約80%)は、小さい処理ループにおいて実行される。この小さい処理ループは、パラメータ902からのソースサンプルデータを含むデータをとって、サンプル903としての出力である新規なサンプルを生成する。ソースサンプルデータからの新しいサンプルデータを生成するこの過程は、図64に例示される3つの動作を含むことができる。
図64は、上で議論された小さい処理ループによって実行される合成手順フローを例示する。第1の動作は(I)補間ブロックであって、異なる速度でパラメータ902(例えば、DLSデータ)からソースサンプルデータを読み込む(例えば、楽曲ピッチGをもつソースサンプルから、Aの楽曲のピッチを有するサンプルを得る)ステップである。ある実施例において、第1の動作(I)はまた、次の動作において使用する波形データをつくるために、例えば、DLSパラメータをもって、アルゴリズム機能を適用することを含む。この種の実施例において、別の処理ループ(例えば、他の動作より処理頻度が少ないループ)を使用して、このアルゴリズム機能を適用することは有効である。第2の動作(II)は、フィルタリングブロックであり、生成されたサンプルをフィルタリング(例えば、共振を有する低域フィルタで)するステップである。ステップ(I)及び(II)では、モノラル信号を含む。第3の動作(III)は、利得調整(ゲイン)ブロックであり、サンプルの振幅を適宜の大きさに増幅するステップである。このステップにおいて、ある実施例では、モノラル信号ができる限り異なるゲイン値を有する2つの信号に分割される(例えば、信号のステレオ配置効果を与えるため)。
図65は、上で述べられた小さい処理ループを実行する音声合成900の主部分の構造を表す。図示されるように、ソースサンプルデータ910(例えば、パラメータ902からの)は、(I)補間ブロックに入力され、そこで、ピッチパラメータ912(例えば、パラメータ902からの)で処理され、(II)フィルタリングブロックに供給され、そこでフィルタパラメータ914(例えば、パラメータ902からの)でフィルタリングされ、(III)利得調整ブロックに供給され、そこで利得(ゲイン)パラメータ916(例えば、パラメータ902からの)で処理される。この点で、ある実施例で、サンプルは、ステレオフィールドをつくるために(III)利得調整処理を経て、ステレオ出力信号の右(R918)及び左(L920)チャネルに対応する二つの信号に複製される。モノラル出力が要求される状況では、R918及びL920への分離は必要でない(例えば単旋律の移動電話)。さらに、2つ以上の出力チャンネルが要求される状況(例えば、いくつかのスピーカを使用し、それぞれが音響の離散的なチャネルを分配する「5.1のマルチチャネルサラウンドサウンド」)では、利得調整ブロックにより、入力サンプルを複数のチャネル(例えば正面の左、中心、正面の右、左後方、右後方及びサブウーハ)に分割するために、利得パラメータ916が使用される。これは、2チャネルに対して図65に示したものと同様なやり方で実行される。
図65において表される構造によって反復実行される小さい処理ループは、音声合成900によって実行される処理の主要部を含むので、これが、大部分の信号処理資源が音声合成動作において消費される領域である。したがって、処理資源が比較的乏しい携帯電話、PDA、携帯用ビデオゲーム、携帯用アラームクロック、その他のような場合には、この小さい処理ループの効率は、この種の携帯用システムによって達成可能な音声合成の品質に大きな影響を及ぼす。
図66は、ソースサンプルデータ910の処理に関連する算出タイミングの従来技術の方法を例示する。図示のように、与えられたパラメータ(例えば、利得)毎に、新規な値が比較的しばしば算出される。例えば、44.1kHzのオーディオ信号の場合、新規な利得値は、ミリ秒当たり44回算出される(例えば、波形セクション940中で44回)。図67は、新規なパラメータ値がより少ない回数算出される(例えば、44kHzの場合、ミリ秒当たり1回、すなわち波形セクション942の中で1回)という顕著な差をもって、同一波形を示し、そして、時間内の位置で新規なサンプルが算出されない(例えば、前の実施例では、1波形セクション942の中にミリ秒当たりの残りの43回)点で、ルーチンは、デルタ値(例えば推定された差値)に応じて、以前の算出値を出力する。この方式では、図66において表される従来の技術方法ほど頻繁には新規なパラメーター値を算出しないので、上で述べた小さい処理ループはより効率的である。図68は、同一の波形を用いた、別の波形計算タイミングを示しており、新規なパラメータ値がめったに算出されない(例えば、44kHzの場合で、波形セクション944及び946によって表されるように、5ミリ秒当たり1回)という大きな差を有し、そして、新規なパラメーター値は、図66及び図67での値(例えば、前記実施例に従えば、隔ミリ秒ごとに1回、又は波形セクション944及び946のそれぞれの中で4回)の場合より低頻度で、デルタ値に応じて出力される。
比較のための例示として、与えられたチャネルに対して、図66に表される従来技術の方法は、1ミリ秒につき44回、新規なパラメーター値を算出し、図67に表される方法は、1ミリ秒につき1回新規なパラメーター値を算出し、そしてミリ秒につき43回を残してデルタ値を新規なパラメータ値に加える。そして、図68に表される方法は、1ミリ秒につき1回より少なく(例えば、5ミリ秒ごとに1回)、新規なパラメータ値を算出し、新規なデルタ値(例えば、図67の方法に関連するデルタを使用して、それに44を掛けることによって選られる)が、1ミリ秒につき一度加算される。図66〜図68に例示される各々の方法を使用している44kHzの音声の一つのチャネルを処理するために典型的に必要なMIPSの数は、それぞれ、10、2.5、1.5である。
図67に表される方法に対して、図68において表される方法による付加の利点は、固定小数点プロセッサを組み込んでいるアーキテクチャにおいて、実現され得るということである。図67と関連する合成算出は、デルタ値が前のサンプル値に毎ミリ秒44回(例えば、44.1kHzの音声の場合)、加算されることを必要とするので、浮動小数点精度を有しないアーキテクチャでは、これらの算出は不所望な精度となり(例えば、不良なオーディオ出力)、また、処理実行のために不所望のMIPS数を必要とすることになる。図68に例示される方法は、図67に例示されるデルタ値の集合を含み、そして、ただひとつの数(例えば、図66の場合のデルタ値の44倍という比較的大きい値)がサンプル値に加えられ、その結果、固定小数点プロセッサの観点で改良された正確で低いMIPSをもたらす。
ある実施例において、付加的な効率を提供するために、別個に又は上記と結合して、図64及び図65に表される(III)利得処理の動作の更なる最適化を使うことができる。ステレオ出力(モノラルに対して)の例において、通常、チャネル毎に、(III)利得処理ブロックが処理され、以下の3つの式が、1ミリ秒につき44回(44.1kHzの音声の場合)実行される。
(1) 入力信号*利得=増幅された信号
(2) 増幅された信号*左修飾子=左チャンネル出力
(3) 増幅された信号*右修飾子=右チャンネル出力
想像されることができるにように、この処理は、特に多数の同時オーディオイベント901が処理されるときに、かなりの資源を占める(第63図及び付随する上記説明を参照)。ある好ましい実施例においては、式の代替集計された一組を使用することが有利であり、そして、このようにして、効率的なステレオ符号化方処理を遂行することが有利である。該代替の組は、2つの方程式の2セットから成る(合計4)。2つの方程式の第1の組は、次の通りである:
(4) 左の修飾子*利得=増幅された左チャネル修飾子
(5) 右の修飾子*利得=増幅された右チャネル修飾子
式(4)及び(5)は、5ミリ秒毎に1回(例えば、44.1kHzの場合)のように、比較的まれにしか実行されない。1ミリ秒につき44回のように、2つの方程式の以下の第2の組は、より頻繁に実行される。
(6) 入力信号*増幅された左チャネル修飾子= 左チャネル出力
(7) 入力信号*増幅された右チャネル修飾子= 右チャネル出力
典型的な例(式(1)〜式(3)に関連して上述)と、好ましい実施例(式(4)〜(7)に関連して上述)とを比較すると、要求されるMIPSでの相当な減少が達成されることは明らかである(例えば、ある場合で約6%)。この減少は、主に、大部分のサイクル(例えば、上の実施例では、5ミリ秒の期間の220サイクルのうちのほぼ219)において、2つの式だけが3の式の代わりに実行されるからである。
したがって、図67及び図68と関連する各々の2つの好ましい実施態様は、図63〜図65に関連して上記した小さい処理ループのための必要資源をかなり減少させることができ、このように、特に携帯用システム(例えば、携帯電話機、PDA、携帯用ビデオゲーム、携帯用キーボード、その他)での使用に有利である。しかしながら、これらの実施例がポータブルシステムと関連して述べられるが、この種の実施例は、他の非携帯用システム(例えばパーソナルコンピュータ、ステレオシステム、電子音楽製品、など)の使用のためにも望ましい。この技術の使用が処理資源を減少させ、ある場合には汎用プロセッサが合成を効果的に実行できるようにすることによって、特別で高価なハードウェア合成回路の必要性をなくすことができ、音声合成を行ういかなるシステムも、このような効率的な音声合成処理を使用することにより、利益を受けることができる。
減少するメモリ領域又は占有スペースを有するMIDI音声バンクに伴う好ましい本実施例を、図69〜図76に関連して説明する。
携帯用環境のような状況において、MIDI音響バンクが比較的少ないメモリ占有面積であることは望ましい。以下の説明において、ローランド社によって開発されて「GM」と呼ばれ、現在、Microsoft Windowsの標準の部品として含まれる従来技術の音声バンクは、ほぼ3,361KBのメモリ占有スペースを有する。この種の大きい容量は、ある状況において十分に動くことができるが、デスクトップパーソナルコンピュータと比べて減少された資源(たとえば、処理、電池寿命、メモリ、その他)が利用可能な携帯用MIDI装置(例えば、移動電話、携帯用ビデオゲーム、携帯用キーボード、PDA、その他)にとっては、大き過ぎる。以下に記述する技術は、したがって、必要資源のかなり減少するレベルで、一緒又は別個に、高質MIDI音声バンク解決策を提供するものである。もちろん、ある状況では、更に詳細に以下に述べられる種々の理由で、非携帯用環境においても1又は複数のこれら技術を使用することが好ましい。
その上、以下の説明は、上記したように(DLS)互換の音響バンクのようなMIDI互換の音響バンクの一部を含む波形の例を参照する。MMAから入手可能なDLS仕様資料に説明されているように、DLS互換の音響なバンクは、波形データと関連するパラメータデータを含む。波形データは識別される「ループ期間」を有する。そして、それは、MIDI音符の継続期間をサポートするために、必要に応じて再生の間、連続的にループする波形の部分を示す。通常、従来の音響バンクは、各々の楽器のための波形を含む。そして、その波形は、通常ループ期間と確認される端の方へ向かうセクションを有する。
図69は、トムドラムのために使用する従来技術の音響を例示する。図示するように、波形は比較的大きく、ほぼ6467のサンプルの長さをもつ。そして、ループ期間は、波形の後半にあって波形の後部25%を占める。波形から理解できるように、ほぼ25%の始端部は比較的無秩序である。この最初の過渡期間は、トムヘッド上のドラムスティックの影響による音響を伴う。この最初の過渡期間の後、波形はより安定することが判る。図69に示したように、波形の比較的安定部分からループ期間を選ぶことは、MIDI音響バンクの典型的特徴である。残念なことに、これは、比較的大きい波形サイズ(例えば、図69の場合では、6000以上のサンプル)の副作用である。図70は、音響を作るために2枚のDLSレイヤを使用した、本発明のトム音響を例示する。図70に示するように、このトム音響は、2つの波形でできており、共同してかなり少ないスペース(例えば、図69に表される従来の技術波形の6467のサンプルと比較すると、合計904のサンプル)をとる。示されるように、レイヤ2の波形は、トムヘッドを打っているドラムスティックの最初の打ち鳴らし音響である。このレイヤは、ループ期間を有しない。レイヤ1の波形は、識別されたループ期間を有する比較的安定な波形である。これらの2つの波形は、同じ位置で鳴り始め、レイヤ1の波形は、MIDI音符持続期間をサポートするため必要とされるように、ループする(この音響と関連するDLSパラメータデータと整合した方法で)。さらに、ある実施例において、レイヤ1の波形が、ベースギター音響のような、音響バンクのどこかで使用されるピッチが整えられた音響であってもよい。図70に表される方法の一つの効果は、この音響が大きさ(サイズ)において、従来の技術よりかなり小さいということである。この方法の他の効果は、ある実施例では、ループ期間がピッチ調整された楽器(例えば、ベースギター)の波形と関係しているので、種々のピッチ全体にわたって、より良い音響が得られるということである。従来技術の場合、種々のピッチを使用して良い結果を得るために、所与のドラムキットのトム音響のために、多様な波形の使用が必要となる場合がある。本発明の方法の付加的な効果は、レイヤ1のために使用するベースギター音響のように多様な音響のためのソース波形を使用する可能性があるため、減少した波形カウントが全体に渡って存在する、ということである。本方法のさらにもう一つの効果は、異なるサンプリング周波数が各々のレイヤのために使われるということである(例えば、知覚される音響品質へ比較的小さな悪影響を及ぼすもののサイズ低減を可能にし、レイヤ2上の「アタック」波形は低減されたサンプリング周波数を有する)。現在の方法の一つの不利な点は、それが同じ楽器音響のために同時に処理されている2つの波形を含むので、多音が減少するということである。この分野の当業者に明らかであるように、トム音響の実施例は、説明を容易にするためであり、図70の本実施例の多くの教示は、本発明に沿うやり方で他の楽器においても適用される。加えて、ある実施例において、組合せ波形(複合波形)とするために多数の波形(例えば、図70に示す)を前処理することが好ましい。この前処理のステップは、複合波形が「演奏される」とき、それは一つの声音を占有するだけであるので、多音を増やす利点を有する。この種の前処理は、例えば、利用できる処理資源等に応じて、再生の前又は再生中に行う。
図71は、フルートのために使用する従来技術の音響を表す。図示するように、波形は比較的大きく、約2029のサンプルの長さで、ループ期間は波形の最後5%を占める後方部分にある。波形から明らかなように、初期部分は比較的無秩序である。この最初の過渡期間は、フルートの最初の呼吸音響特性に関連する。この最初の過渡期間の後、波形はより安定するようになる。また、図71に示したように、波形の比較的安定部分からループ期間を選ぶことは、MIDI音響バンクの典型的特徴である。残念なことに、これは比較的大きな波形サイズとなる(例えば、図71の場合、2000以上のサンプル)。図72は、本発明におけるフルート音響を例示する。図72に示すように、本発明においては、フルートは、かなり少ないスペース(例えば、図71に表される従来技術の波形の2029のサンプルと比較すると、合計591のサンプル)をとる。図示されるように、一部の波形が最初の遷移期間とループ期間の間から取り除かれ、これにより、比較的安定なループ期間を依然として残しながら、比較的短いサンプルサイズとなる。図72において表される方法の主要な効果は、この音響のサイズが従来技術よりかなり小さいということである。本方法の一つの不利な点は、波形が変わるので、音質の低下を伴うということである。しかしながら、このカット/ペースト技術が慎重になされる場合には、結果として生じる音質低下を、より小さいサイズと比較しても大差ないようにすることができる。これは、安定ループ期間のためであり、この楽器音響が使用される大半の時間、鳴らされる。この分野の当業者に明らかであるように、フルート音響の例は、説明を容易にするためであって、図72の本実施例の多くの教示は、本発明に従うやり方で他の楽器にも適用され得る。
図73は、ピアノのために使用する従来技術の音響を表す。図示するように、波形は比較的大きく約7588のサンプル長を有し、そして、ループ期間は波形の後ろ約20%を占める後方部分にある。波形から理解できるように、始端部は比較的無秩序である。この最初の過渡期間は、ピアノ弦へのハンマーの衝撃と関係している。この最初の過渡期間の後、波形はより安定するようになる。また、図73にて示したように、波形の比較的安定部分からループ期間を選ぶことは、MIDI音響バンクの典型的特徴である。残念なことに、これは比較的大きな波形サイズ(例えば、図73の場合では7500以上のサンプル)となってしまう。図74は、本発明におけるピアノ音響を例示する。図74に示されるように、このピアノ波形は、かなりの少ないスペース(例えば、図73に表される従来技術の波形の7588のサンプルと比較すると、合計54のサンプル)をとる。図示されるように、そのサイズは、ループ期間としての用途のために、最初の遷移期間を識別することによって、大幅に減少した。ピアノ音響の音波特性により、最初の遷移期間は好ましくは比較的安定なループ期間を提供することができ、その結果、比較的短いサンプルサイズとすることができる。図74に表される方法の主要な効果は、この音響のサイズが従来技術よりかなり小さいということである。本方法の一つの不利な点は、ループ期間が最初の過渡期間から選定されているので、音質の低下を伴うということである。しかしながら、ループ期間が慎重に選ばれる場合、結果として生じる音質低下は、より小さいサイズの場合と比較して、さほどではないようにすることができる。この方法の他の不利な点は、それがシンバル音響のように非常に特徴的な遷移期間を含む楽器音響には、通常、適していないということである。この分野の当業者に明らかであるように、ピアノ音響の例は、説明を容易にするためであって、図74の本実施例の多くの教示は、本発明に従うやり方で他の楽器にも適用することが可能である。
第75図は、サクソフォン及びオーボエのために使用する従来技術の音響を表す。
図示するように、波形は比較的大きくて、それぞれ1200のサンプル長である。そして、ループ期間は、非常に小さい後方部分である。これらの波形の並置から理解できるように、これらの2つの楽器が音を出す方法の熟知と同様に、ループ期間は比較的類似している。図76に、本発明のサクソフォンとオーボエの音響を例示する。図76に示すように、従来技術よりかなり少ないスペースをとることに加えて、このオーボエ音響は、サクソフォン音響(例えば、「saxf#4a」)と同じ波形の使用を生じさせる。図示されるように、これらの2つの音響間の主要な差は、ループ期間の終端点の位置である。ループ期間を変えることによって、それらが両方とも同一波形を使用するにもかかわらず、オーボエの音響を聴覚的にサクソフォンと異ならせることができる。先に述べた技術でそうであるように、この技術はまた、楽器音響の個性をより際立たせるため、そして、好ましくは結果として生じる音響をよりしっくりと実際の楽器のように仕上げるために、変更されたパラメータ(例えば、フィルタ、エンベロープ、及び/又はLFO効果のパラメータ)の使用を含むことができる。図76に表される方法の主要な効果は、多様な音響のためのソース波形を使用する可能性のゆえに、減少した波形カウントが全体に渡ってあるということである。本方法の一つの不利な点は、付加パラメータを更に音質を改良するために用いる状況で、音響バンクがより複雑になる可能性がある点である。但し、付随する全体的なサイズ減少は、この懸念を上回る。この分野の当業者に明らかであるように、サクソフォン及びオーボエ音響の例は説明を容易にするためのものであって、図76の例の多くの教示は、本発明に従うやり方で他の楽器にも適用され得る。
前述の教示に加えて、ある好ましい実施例においては、比較的大きな音響バンクの使用し、さらに、一曲ごとに所与の使用のために必要な音響の選択だけを行うことが好ましい。この方法では、特定の使用(例えば、演奏されている特定の歌曲のような)のために必要とされる音響だけは、RAMに書き込まれる必要がある。この方法の一つの効果は、より大きい音響バンクによって産出されるより良好な音質を、ある場合にはメモリの最も決定的な部分(例えば、移動電話の場合のように)であるRAMスペースをさほど大きく占有することなく、使用できるということである。音響バンクを記憶するために128KBのROM又はフラッシュメモリが利用でき、シンセサイザ(合成器)が動作しているときに音響バンクに記憶するために32KBのRAMが利用できる実施例についてみると、本技術の効果は、一つのMIDI歌曲が32KB以上のデータ(例えば、ソースサンプル及びパラメータ)を使用しないならば、音響バンクが最高128KBまで増量できるということである。この技術の潜在的に不利な点は、任意のひとつのMIDI歌曲が32KB以上の音響バンクデータを使用しないことを保証しなければならないということである。この潜在的課題に対処する追加の技術は後述する。利用可能な音響バンクの下位部分の一曲毎の使用は、本明細書において記述される典型的なサイズに限られるものでないが、しかしながら、より多くの又はより少ない資源が音響バンクデータに利用できる他の状況においてむしろ好ましい。この技術は、所与のアプリケーション(例えば、歌曲が演奏されること)のためのメモリサイズの占有スペースへの影響を減少させながら、この技術は高品質な音響バンクを提供する。
前述の教示に加えて、付加的な技術を、全てのMIDI歌曲が有効音響バンク(例えば、128KB)の所定のサブセット(例えば、32KB)以上を使用しないことを保証するために用いてもよい。音響が異なる品質及び/又はサイズであり、そして、所定のサブセットサイズが超過する危険がある状況では、より高品質及び/又はより大容量のコンピュータ音響に代えて、より低品質及び/又はより小容量の音響が選択的に用いられる本技術は、利用可能な音響バンクの複数の音響を、所与の楽器と結びつけることを含む。この方法では、与えられた歌曲が、その歌曲に使用された全ての楽器のために高品質及び/又はより大きいサイズの音響を使用することができる場合には、予め定められたメモリサイズ(例えば、32KBのRAM)の範囲内にとどまりながら、それから、歌曲は高質及び/又はより大きい容量の音響を使用して演奏される。しかしながら、所与のMIDI歌曲がそれらの最高品質及び/又は最大容量のバージョンの有効容量(例えば、32KBのRAM)より集合的に大きくなる楽器音響を必要とする状況では、本発明は、所定のメモリ容量(例えば、32KB RAM)の範囲内にとどまるために、どの楽器がそれらのより低い品質おび/又はより小さい容量の音響で鳴らされるのかを決定するために実行されるアルゴリズム判定を必要とする。アルゴリズム判定は、ランダム状態、楽器の重要性、表、その他に基づいて行われ、そして、ある場合には、MMAによって発行されるScalable Polyphony MIDI Specification(SP−MIDI)に基づいてもよく、これは、本願明細書に取り込まれたものとする。
ある実施例において、個々の楽器の定義の書き換えを可能とするために、書き換え手段(例えば、テーブル又は状態マシンのような)を使用することが好ましく、それによって、特定の楽器は他の楽器の定義に書き換えられる。例として、汎用MIDI(GM)楽器#N用の楽器が音響バンクに含まれていない場合(音響バンクの容量を減少させるため)、この書き換え手段は、好ましくは楽器#Nが楽器#Pに関連する楽器定義に再割付けされたことを示す。この例では、楽器#N及び#Pは両方とも、同じ音響(楽器)定義を共有する。
携帯用電子音楽設計の当業者によってよく理解されるように、ここで述べられている実施例は本発明の技術的範囲に含まれるものを代表的に表したものである。付加的な変形(そのいくつかはここに記載されている)は、多くの本発明の態様を組み込む。
本発明が特定の好ましい実施例と関連して記載されたが、多くの置換、代替及び変形が前述の説明を考慮して当業者にとって明らかであることは明白である。したがって、本発明は、添付の請求項の範囲内で、その代替及び変形の全てを受け入れることを目的とする。例えば、本願明細書において記載されているさまざまな別の実施例に従って、それさまざまなシステム、そして、そのシステムに基づく使用及び方法が得られることが理解されなければならない。また、付加的な有利な組合せ及び同類が提供するために、記載されているさまざまな改良及び代替的かつ付加的特徴が本発明にしたがって結合される。また、前述の説明に基づいて当業者に理解されるように、好ましい実施態様のさまざまな態様が種々の下位結合にも用いられ、ここで述べられた少なくともある利点及び属性を達成することができる。この種の下位結合もまた本発明の範囲内である。本発明の全てのこの種の改良、拡張及び更なる使用は、本発明の範囲内である。
以下に、本発明の種々の構成要件の組み合わせからなる例示的な実施態様を示す。
1.放送楽曲を生成する方法において、
楽曲データファイルを生成するステップと、
基地局から、複数ノードの1又は複数のノードに上記楽曲データファイルを放送するステップと、
上記複数ノードの1又は複数のノードにおいて上記楽曲データファイルを受信するステップと、
上記楽曲データファイルから、歌曲データ構造に関する情報と該歌唱曲データ構造に関連する楽曲パラメータを表す情報を提供する楽曲定義データを抽出するステップと、
上記楽曲定義データを処理するステップであって、上記歌曲データ構造及び上記楽曲パラメータに関連する歌曲が、上記複数ノードの1又は複数によって生成されるステップと、
上記複数ノードの1又は複数において、上記生成された歌曲を演奏するステップと
からなることを特徴とする放送楽曲を生成する方法。
2.受信した楽曲データファイルに基づいて音楽作品を生成するシステムにおいて、
上記システムから離間した1又は複数の第二システムとの間で、少なくとも1つの楽曲データファイルを含むデータを送受信する送受信機と、
少なくとも1つの楽曲生成アルゴリズムを実行する楽曲生成装置であって、1又は複数の音楽作品の楽曲出力を生成するために、楽曲ルールを上記楽曲生成アルゴリズムに従って楽譜データに適用するよう構成された楽曲生成装置と、
上記受信された少なくとも1つの楽曲データファイルが記憶されるメモリと
からなり、楽曲データが上記受信された楽曲データファイルからのデータに基づいて生成され、上記楽曲生成装置が上記受信された楽曲データファイルに基づいて音楽作品を生成することを特徴とするシステム。
3.上項2記載のシステムにおいて、該システムはさらにユーザ入力を備え、ユーザによる上記ユーザ入力の動作により上記受信された楽曲データファイル中のデータが変更され、変更された楽曲データファイルが生成され、上記楽曲生成装置が変更されたデータファイルに基づいて変更された音楽作品を生成するよう構成されていることを特徴とするシステム。
4.上項3記載のシステムにおいて、上記変更されたデータファイルが1又は複数の遠隔システムによって受け取られるように上記送受信機によって送信され、上記1又は複数の遠隔システムは、上記変更されたデータファイルに基づいて、上記変更された音楽作品を生成するよう構成されていることを特徴とするシステム。
5.上項2記載のシステムにおいて、上記楽曲データファイルが電話コールの開始の一部として送信されることを特徴とするシステム。
6.上項2記載のシステムにおいて、上記楽曲データファイルが電話コールの一部として送信されることを特徴とするシステム。
7.処理装置でソースサンプルデータを処理して合成されたオーディオサンプルを生成するために、携帯環境で音声合成を実行する方法において、
補間関数を提供して、ソースモノラルサンプルデータに基づいて1又は複数の補間内挿されたモノラルサンプルを生成するように、該ソースモノラルサンプルデータをアクセスしかつ補間内挿するステップと、
フィルタ関数を提供して、フィルタリングされ補間内挿されたモノラルサンプルを生成するように、少なくとも1つの上記補間内挿されたモノラルサンプルをフィルタリングするステップと、
利得関数を提供して、共同してステレオフィールドを生成するための少なくとも左サンプル及び右サンプルを生成するように、上記フィルタリングされ補間内挿されたモノラルサンプルを処理するステップと
とからなる方法。
8.オーディオ出力を生成するために、MIDI合成機能が、減少された占有スペースの音響バンクをアクセスすることにより処理MIDIイベントに呼び出されるようにした、携帯環境でMIDIの基づく合成を実行する方法において、
第1の所望の音響のための第1及び第2のレベルからなるDLS互換性のある音響バンクを供給するステップであって、第1のレベルがインパクトの開始音響からなる第1のサンプルに関連しており、第2のレベルが安定波形のループ期間からなる少なくとも第2のサンプルに関連している、ステップと、
上記第1のサンプルを上記第所望の音響及び複数の付加的音響に関係する上記DLS互換性の音響バンクに関連するパラメータデータを提供するステップであって、上記第1のサンプルが上記複数の付加的音響に関連がない場合、上記DLS互換性の音響バンク及び関連するパラメータデータが、そうでない場合より小さい占有スペースを占有するステップと
からなることを特徴とする方法。