JP4267925B2 - 対話型再生によるマルチパートオーディオ演奏を記憶する媒体 - Google Patents

Description

関連出願

本願は、"A Multimedia Data File"という題目の２００１年７月６日に出願された米国特許出願第０９／９００，２８９号と、"A Virtual Music System"という題目の２００１年７月６日に出願された米国特許出願第０９／９００，２８７号と、"A Multimedia Data File"という題目の２００１年４月９日に出願された米国仮出願第６０／２８２，４２０号と、"A Virtual Music System"という題目の２００１年４月９日に出願された米国仮出願第６０／２８２，５４９号と、"A Multimedia Data File"という題目の２００１年５月４日に出願された米国仮出願第６０／２８８，８７６号と、"A Interactive Karaoke System"という題目の２００１年５月４日に出願された米国仮出願第６０／２８８，７３０号とに関する優先権をここに主張するものである。

本願は、１９９３年６月７日に出願され、１９９５年２月２８日に発行され、かつ、"Virtual Music System"という題目の米国特許第５，３９３，９２６号と、１９９５年５月１１日に出願され、１９９７年９月２３日に発行され、かつ、"A Virtual Music Instrument with a Novel Input Device"という題目の米国特許第５，６７０，７２９号と、２０００年２月１７日に出願され、２００１年１月１６日に発行され、かつ、"System and Method for Variable Music Annotation"という題目の米国特許第６，１７５，０７０Ｂ１号とを、この参照により開示に含むものとする。

本発明は、マルチパートデータファイル（multipart data files）に関する。

ムービングピクチャーエキスパートグループ（Moving Picture Experts Group）（ＭＰＥＧまたはＭＰ３）および楽器ディジタルインターフェース（Musical Instrument Digital Interface）（ＭＩＤＩ）は、ディジタルオーディオ記憶および送信のためのプロトコルである。

ＭＩＤＩは、ディジタルオーディオコンテンツをシンセサイザー上で録音かつ再生するために企画された。ＭＩＤＩストリームは、オーディオコンテンツを直接的には示さないが、どのように該コンテンツを合成すべきかについての情報を提供する。ＭＩＤＩストリームはマルチトラックであり、この場合に、各々のトラックを、楽器のような別々のプロファイルにマッピングすることができる。ＭＩＤＩストリームの各トラックは、この楽器により演奏すべき別々のノートを含む。ＭＩＤＩファイルは、（比喩的に述べると、特定のソング自体のサウンド録音とは対照的に）該ソングについての従来的なシートミュージックのコンピュータ等価物であるので、これらのＭＩＤＩファイルは、オーディオコンテンツを直接的かつ連続的に録音するファイルと比較した場合に、小さくかつコンパクトである傾向がある。しかしながら、ＭＩＤＩストリームは、これらのサウンドを生成するために、通常は、ある形式のウェーブテーブル（wave table）シンセサイザーチップまたはＦＭシンセサイザーチップを必要とする。さらに、ＭＩＤＩファイルは、同じ内容を実際にサウンド録音した場合の豊かさおよび力強さを欠く傾向がある。

ＭＩＤＩストリームとは違って、ＭＰ３ストリームは、オーディオコンテンツを実際にサウンド録音したものを含む。通常は、ＭＰ３ストリームは、単一のトラックファイルであり、かつ、録音において利用される特定の音符または楽器に関する情報を含まない。しかしながら、ＭＩＤＩファイルが、通常は、再生されるためにさらなるハードウェアを必要とする一方で、ＭＰ３ファイルについては、特殊化されたハードウェアを最小量のみ備えた最新のマルチメディアパーソナルコンピュータ上において、かなり頻繁に再生することができる。

概略的に、一特徴において、本発明は、対話型再生のためのオーディオ演奏を符号化するデータ構造を、自身に記憶させたコンピュータ読み取り可能な媒体を特徴づける。前記データ構造は、オーディオ演奏の対話型パートを符号化する仮想楽器プールを含む。前記対話型パートのオーディオコンテンツは、少なくとも一連のシンセサイザー制御データに符号化される。前記シンセサイザー制御データ内の各データは、再生すべきオーディオコンテンツのディジタルサンプルを指定する。前記データ構造は、オーディオ演奏の非対話型部分を符号化する全体的伴奏プールをさらに含む。前記全体的伴奏プールは、オーディオ演奏の再生を同期させるためのタイミング情報を含む。

好ましい実施例は、以下の特徴のうちの１つ以上を含む。前記シンセサイザー制御データは、ＭＩＤＩデータである。前記ディジタルサンプルは、ＭＰ３クリップである。前記全体的伴奏プールは、オーディオ演奏のオーディオコンテンツの非対話型パートを符号化する。前記全体的伴奏プールは、サウンドフォントの集合を含み、各々のサウンドフォントは、対話型パートの再生を合成するためのパラメータを供給する。

概略的に、他の特徴において、本発明は、対話型再生のためのオーディオ演奏を符号化するデータ構造を記憶するコンピュータ読み取り可能な媒体を特徴づける。前記データ構造は、オーディオ演奏の非対話型パートを符号化する全体的伴奏プールを含む。前記非対話型パートの一部分はシンセサイザー制御データとして符号化され、該非対話型パートの他の部分はオーディオコンテンツのディジタルサンプルとして符号化される。前記データ構造は、オーディオ演奏の対話型パートを符号化する仮想楽器プールをさらに含む。前記対話型パートは、符号化されたオーディオコンテンツを、少なくともシンセサイザー制御データ内に有する。前記シンセサイザー制御データ内の各データは、合成すべき音符を指定し、または、再生すべきオーディオコンテンツのディジタルサンプルを指定する。

好ましい実施例は、以下の特徴のうちの１つ以上を含む。前記シンセサイザー制御データは、ＭＩＤＩデータである。前記ディジタルサンプルは、ＭＰ３クリップである。前記全体的伴奏プールは、オーディオ演奏のオーディオコンテンツの非対話型パートを符号化する。前記仮想楽器プールは、対話型パートのオーディオコンテンツと調和した催促を指定するキューデータを含む。

概略的に、さらに他の特徴において、本発明は、コンピュータ読み取り可能な媒体上に記憶された符号（code）を特徴づける。前記符号は、娯楽システム内のコンピュータ上で作動し、該娯楽システムは、オーディオ出力サブシステムと、入力装置と、メモリとを含み、該メモリは、音楽演奏データ構造を記憶し、該音楽演奏データ構造は、音楽演奏の対話型部分と、音楽演奏の伴奏的な非対話型部分とを有する。前記符号は、仮想マネージャーオブジェクトを含み、該仮想マネージャーオブジェクトは、コンピュータに、メモリに記憶された音楽演奏データ構造を読み取らせ、かつ、コンピュータに、該音楽演奏データ構造内の識別された仮想楽器を示す仮想オブジェクトを生成させる。前記仮想オブジェクトは、コンピュータに、入力装置からのユーザー入力を、音楽演奏の対話型部分にマッピングさせ、かつ、コンピュータに、該マッピングされた音楽演奏の対話型部分を、オーディオ出力サブシステムを通して演奏させる。前記符号は、全体的伴奏オブジェクトをさらに含み、該全体的伴奏オブジェクトは、コンピュータに、音楽演奏の伴奏的な非対話型部分を、オーディオ出力システムを通して演奏させる。

好ましい実施例は、以下の特徴のうちの１つ以上を含む。前記記憶された音楽演奏データ構造は、別個の楽器を各々が示す複数の別個の仮想楽器を識別する。前記仮想マネージャーオブジェクトは、コンピュータに、複数の仮想オブジェクトを生成させ、該複数の仮想オブジェクトの各々は、識別された複数の楽器のうちの、対応する別個の楽器を示す。前記複数の仮想オブジェクトの各々は、コンピュータに、入力装置からのユーザー入力を、音楽演奏の対話型部分の対応するパートにマッピングさせ、かつ、コンピュータに、該マッピングされた音楽演奏の対話型部分の対応するパートを、オーディオ出力サブシステムを通して演奏させる。

前記全体的伴奏オブジェクトは、コンピュータに、仮想オブジェクトのためのマスタータイミング信号を、コンピュータ上で自身が実行される場合に供給させる論理をさらに含む。

前記娯楽システムが、映像表示サブシステムを含み、かつ、前記記憶された音楽演奏データ構造は、音楽演奏の対話型部分と関連づけられた一連の記憶されたタイミングキューを含むと仮定すると、前記仮想オブジェクトは、ユーザーが仮想楽器を演奏することを補助するために、コンピュータに、タイミングキューの視覚表示を、映像表示システムを通して表示させる論理をさらに含む。さらに、前記記憶された音楽演奏データ構造が、音楽演奏の非対話型部分の別個のパートを各々が示す複数のディジタルクリップと、一連のトリガー時点とを含み、該トリガー時点の各々は、タイミング情報を示し、かつ、前記ディジタルクリップのうちのどの１つを該タイミング情報内の識別された時間に演奏すべきか識別すると仮定すると、この場合に、前記全体的伴奏オブジェクトは、娯楽システムに、複数のディジタルクリップのうちの識別された１つを、記憶された一連のトリガー時点により識別された通りの適切な時間に、オーディオ出力サブシステムを通して演奏させる論理を含む。

前記オーディオ出力サブシステムが、シンセサイザーを含み、かつ、前記記憶された音楽演奏データ構造が、サウンドフォントを含むと仮定すると、前記伴奏オブジェクトは、オーディオ出力サブシステムの記号を制御するために、コンピュータに、記憶された音楽演奏データ構造からサウンドフォントを検索させる論理にして、かつ、コンピュータに、サウンドフォントをシンセサイザー内にロードさせる論理をさらに含む。

本発明に関する１つ以上の実施例についての詳細を、添付図面および以下の説明において示す。本発明に関する他の特徴、目的、および、利点は、説明および図面と、請求項とから明らかとなるだろう。

一実施例において、データファイルは、通常は（ＦＭラジオに匹敵する、または、それ以上の）高品質なディジタル符号化された音楽またはサウンドの標準化演奏（standardized performance）を含む。サウンドをディジタル符号化するための方法は、ＭＩＤＩのようなフォーマットでのシンセサイザーパラメータの他に、ＭＰ３のようなフォーマットでのディジタル録音またはサンプルを含む。標準化演奏は、対話型カラオケシステム（interactive karaoke system）により同期的に再生できる１つ以上のパートに符号化される。例えば、標準化演奏は、音楽家と彼らのボーカルまたは楽器とに割り当てられた様々なパートを備えた歌曲演奏または音楽演奏であり得る。

データファイルは、後述するタイミングキュー、歌詞（lyrics）、および、他の特徴のようなさらなる内容を含む。前記さらなる内容は、同期再生のために、オーディオコンテンツと時間的に相関づけられる（time-correlated）。

１人以上の人間のユーザーが、対話型カラオケシステムを用いることができる。各々のユーザーは、入力装置と、“演奏する”（すなわち、入力装置を経てリアルタイムで対話する）ためのパートとを有する。対話型カラオケシステムは、ユーザーインターフェースを、表示装置を経て、ユーザーに提示する。対話型カラオケシステムは、オーディオコンテンツの同期再生を管理する。再生中に、カラオケシステムは、パート内の符号化されたタイミング情報に従って、該カラオケシステムと対話するように、各々のユーザーに視覚的に催促する。対話型カラオケシステムは、入力装置におけるユーザー入力を、ユーザーのパートに相関させる。次に、対話型カラオケシステムは、パートからのオーディオコンテンツを演奏して、ユーザーがパートを演奏することを奨励する。例えば、オーディオコンテンツが音楽演奏を示す場合に、対話型カラオケシステムは、この音楽演奏の変形を、見かけ上は１人以上のユーザーにより演奏されているものとして再現することができる。

パートを演奏するために、ユーザーは、パートと、入力装置とを選択する。システムは、このパートのためのサウンドプロファイル（または、後述するような“サウンドフォント”）を自動的に選択する。仮想楽器（virtual instruments）は、パートと、入力装置と、サウンドフォントとを用いる。仮想楽器は、カラオケシステムにより生成かつ維持されるソフトウェアオブジェクトとして符号化される。

概略的に、この説明は、実況的演奏（live performance）と、データファイル内の符号化された標準化演奏とを区別している。実況的演奏は、リアルタイムのユーザー入力とユーザーの好みとについて調整した後の標準化演奏を、カラオケシステムにより表したものである。これらの調整の結果として、実況的演奏は、通常は、標準化演奏から逸脱したものとなる。例えば、ユーザー入力がパート内の符号化されたタイミング情報からあまりにも逸脱すれば、カラオケシステムは、このパートについてのオーディオ出力の全てまたは一部を抑制する。他の逸脱は、タイミングに起因するものであり得る。カラオケシステムは、リアルタイムのユーザー入力のタイミングに従って、標準化演奏からのサンプルを演奏する。ユーザーが標準化演奏のタイミングからあまりにも逸脱すれば、実況的演奏も同様に逸脱する。さらに他の逸脱は、ユーザーが選択するシステム設定に起因するものであり得る。例えば、ユーザーは、カラオケシステムに標準化演奏の１つ以上のパートを省略させることを選択し得る。実況的演奏と標準化演奏との間における変化は、カラオケシステムの娯楽的価値に寄与する。

前記システムおよびマルチパートファイルの内容の対話型の特徴は、音楽教育にも同様に適している。マルチパートファイルのさらに他の用途は、ディスクジョッキー（deejay）ソフトウェアに適用される。

〈システム〉
以下、図１Ａを参照すると、対話型カラオケシステム１０は、マルチパートデータファイル１４を演奏し、該マルチパートデータファイル１４の各々は、ソング１５ａまたはオーディオコンテンツ１５ｂのような標準化演奏１５に対応する。各々の標準化演奏１５は、１つ以上のパート１５ｃを含み、該パート１５ｃは、通常は、特定の楽器または人間の演奏者に割り当てられた標準化演奏１５のオーディオコンテンツである。データファイル１４は、後述するように、標準化演奏１５の各パート１５ｃのためのパートチャンク４２またはトラックチャンク３８ａのいずれかを含む。マルチパートデータファイル１４は、システムが標準化演奏１５とパート１５ｃとを再生するために十分な情報を含む。

カラオケシステム１０は、対話型の特徴および視聴覚的な特徴を含む。例えば、ユーザー１６は、入力装置２８（音楽的入力装置２８”であり得る）を経て、システム１０と対話する。ユーザー１６は、視覚表示装置２６を閲覧し、該視覚表示装置２６を通して、システム１０は、情報をユーザー１６に表示する。オーディオ出力サブシステム２７は、ユーザー１６にとって可聴なサウンドにして、実況的演奏を含むサウンドを生じさせる。

システム論理（system logic）１８は、後述するように、処理装置により実行できる命令として符号化された手続き（procedures）を含む。換言すれば、システム論理１８はソフトウェアである。システム論理１８は、後で説明するように、プレイヤーアプリケーション２０と、エンジンライブラリー２２とを含む。

〈パート符号化プロセス〉
概略的に、システム１０は、標準化演奏１５の“対話型（interactive）”パート１５ｃと“非対話型（non-interactive）”パート１５ｃとを区別する。システム１０は、対話型パート１５ｃを、実況的演奏中にユーザー１６により演奏されるように利用可能にする。システム１０は、自動的に（実演またはガイドモードで）、または、対話によって（後述するように、ユーザーによる入力刺激（input stimuli）の影響を受けて）、対話型パート１５ｃを表すことができる。対照的に、システム１０は、非対話型パート１５ｃを、実況的演奏中に、自動的に表す。非対話型パート１５ｃは、対話型パート１５ｃに対するバックグラウンドまたは伴奏（accompaniment）である。

対話型パート１５ｃと非対話型パート１５ｃとの間の相違点は、データファイル１４に符号化される。概略的に、対話型パート１５ｃは（図２に示される）ＶＩプール４０内のパートチャンク４２に対応する一方で、非対話型パート１５ｃは伴奏プール３８内のトラックチャンク３８ａに対応する。

以下、図１Ｂを参照すると、パート符号化プロセス１９は、概略的には、パート１５ｃを、データファイル１４の一部にマッピングする。パート符号化プロセス１９は、対話型または非対話型に指定された各々のパート１５ｃを備えた標準化演奏１５を受信する（プロセス１９ａ）。例えば、人間の管理者が、このような指定を与えることができる。

パート符号化プロセス１９は、データファイル１４に符号化すべきパート１５ｃを、標準化演奏１５から選択する（プロセス１９ｂ）。パート符号化プロセス１９は、パート１５ｃが対話型であるか否かを検査する（プロセス１９ｃ）。検査が肯定的であれば、パート符号化プロセス１９は、パート１５ｃを、仮想楽器として符号化する（プロセス１９ｄ）。例えば、パート１５ｃは、データファイル１４内のＶＩプール４０内のパートチャンク４２にマッピングされる。テストが肯定的でなければ、パート符号化プロセス１９は、パート１５ｃを、全体的伴奏（global accompaniment）の一部分として符号化する（プロセス１９ｅ）。例えば、パート１５ｃは、データファイル１４内の伴奏プール３８内のトラックチャンク３８ａにマッピングされる。

パート符号化プロセス１９は、入力における各々のパート１５ｃのために、プロセス１９ｂに戻る（プロセス１９ｆ）。

〈ファイル構造〉
以下、図２を参照すると、マルチパートデータファイル１４は、ヘッダー３２と、本体（body）３４とを含む。データファイル１４において、ヘッダー３２は、通常は、本体３４に優先する。ヘッダー３２は、本体３４が暗号化されているか否かを示す暗号化フラグ３２ａと、ソング識別子３２ｂとを含む。ソング識別子３２ｂは、ソング１５ａを他のソング１５ａに対して独自に識別する値である。例えば、ソング識別子３２ｂは、発行者のカタログにおいて、ソング１５ａの製品番号としての機能を果たすことができる。

本体３４は、ソング情報３６と、伴奏プール３８と、仮想楽器（または、“ＶＩ”）プール４０とを含む。ソング情報３６は、マルチパートデータファイル１４と関連づけられた標準化演奏１５を指定する。ソング情報３６は、タイトル３６ａ、アーティスト３６ｂ、説明３６ｃ、長さ３６ｄ、ジャンル３６ｅ、サブジャンル３６ｆ、発行者３６ｇ、著作権３６ｈ、作曲者３６ｉ、バージョン３６ｋ、フォーマット３６ｍ、および、難易度等級３６ｎ、のようなフィールドを含む。タイトル３６ａは、標準化演奏１５をユーザー１６に対して識別する名前である。説明３６ｃ、ジャンル３６ｅ、および、サブジャンル３６ｆは、標準化演奏１５を、ユーザー１６に対してさらに説明する。アーティスト３６ｂは、標準化演奏１５内に示される１人以上のアーティストを示す。長さ３６ｄは、標準化演奏１５の継続時間を示す。発行者３６ｇ、著作権３６ｈ、および、作曲者３６ｉは、標準化演奏１５における知的財産権を識別する一方で、バージョン３６ｋおよびフォーマット３６ｍは、データファイル１４を符号化した時刻における朱筆（rubrics）を、（例えば、将来的な改訂のための）様々なバージョンのシステム１０が適切に認識することを補助するメタデータである。難易度等級３６ｎは、標準化演奏１５内のパート１５ｃの全体的な難易度の基準である。

伴奏プール３８およびＶＩプール４０は、チャンク５０としてフォーマットされたデータを含む。さらに、伴奏プール３８およびＶＩプール４０自体が、チャンク５０のフォーマットを用いる。チャンク５０については、図３Ａを参照して説明する。

〈伴奏プール〉
概略的に、伴奏プール３８は、実況的演奏を管理するために、かつ、非対話型パート１５ｃを表すために対話型カラオケシステム１０が解釈する情報を含む。さらに、伴奏プール３８は、後述するように、標準化演奏１５に特有のサウンドフォント３９を供給する。伴奏プール３８は、トラックチャンク３８ａと、サウンドバンクチャンク３８ｂと、ＤＡ（“ディジタルオーディオ”）トリガーチャンク３８ｃと、ＤＡチャンク３８ｄとを含む。

トラックチャンク３８ａは、全体的伴奏コンテンツを符号化する。トラックチャンク３８ａは、対応する標準化演奏１５がシステム１０により表されるテンポおよび長さを定義するためのタイミングを含む。トラックチャンク３８ａは、通常は（しかし、常にとは限らない）、実際のオーディオコンテンツをも符号化する。例えば、トラックチャンク３８ａは、非伴奏（unaccompanied）パート１５ｃ（例えば、ソロボーカル演奏）を含む標準化演奏１５のパートであり得る。この場合に、標準化演奏１５は、少なくともマスタータイミング信号を供給するために、全体的伴奏トラック３８ａによって、なおも符号化される。

〈サウンドバンクおよびサウンドフォント〉
サウンドバンクチャンク３８ｂは、ファイル１４に対応する標準化演奏１５に特有のサウンドフォント３９を供給する。

サウンドフォント３９は、仮想楽器のためのサンプルと音響的特徴とを含む。音響的特徴は、包絡線（envelope）、または、時間とともに動くサンプル音量（volume）を含む。包絡線は、通常は、アタック（attack）（時間とともに急速に立ち上がる最初の音量）と、アタックからの最初の減衰（decay）と、（ノートが保持される必要がある間保持される）サステイン（sustain）と、リリース（release）（楽器がノートの演奏を終了させられた時にサウンドに発生するもの）とを含む。

例えば、サウンドフォント３９がオーバードライブギター（overdriven guitar）のためのものであれば、サンプルは、定義されたノートまたは周波数を演奏するオーバードライブギターを実際に録音したものとなる。サンプルと同じ周波数を有するノートに（図３Ｂに示される演奏トラック４８ａに応じて）対応する入力刺激がユーザー１６により供給されれば、サンプルは変更されずに演奏される。しかしながら、この入力刺激が、サンプルの周波数とは別個の周波数のノートに対応すれば、対話型カラオケシステム１０は、サンプルの周波数を、必要なノートの周波数へシフトする。（図５に示される）シンセサイザー６６ａは、周波数シフトを実行することができる。

説明する実施例において、サウンドフォント３９は、クリエイティブ・ラボ社（Creative Labs, Inc.）による技術および製品と互換性がある。

〈ＤＡトリガーおよびＤＡチャンク〉
ＤＡトリガーチャンク３８ｃは、ＭＰ３サンプルのようなディジタルオーディオクリップの演奏を許容する１組の制御メッセージを与える。これらのクリップ自体は、ＤＡチャンク３８ｄに記憶される。

ＤＡトリガーチャンク３８ｃはクリップにインデックスを付け、かつ、ＤＡトリガーチャンク３８ｃは、ＭＩＤＩノートイベント値をＭＰ３サンプルに、例えば、該ＭＩＤＩノートイベント値とクリップとを関連づける組からなる表においてマッピングする情報を含む。パート１５ｃと関連づけられたＤＡガイドトラック４８ｇは、これらのインデックスを、クリップに参照符号を付ける（referencing）場合の空間効率的（space-efficient）略記として用いることができる。

〈ＶＩプール〉
ＶＩプール４０は、パートチャンク４２の集合を含む。マルチパートデータファイル１４は、対応する標準化演奏１５内の演奏可能な各仮想楽器のためのパートチャンク４２を含む。パートチャンク４２のフォーマットについては、図３Ｂを参照して説明する。概略的に、パートチャンク４２は、対話型パート１５ｃを符号化するデータを保持する。後述するように、ＶＩマネージャーは、開始中にＶＩプール４０を探し、かつ、各々のパートチャンク４２のための仮想楽器オブジェクト８０を生成する。

〈チャンク〉
以下、図３Ａを参照すると、チャンク５０は、ディジタル情報を記憶するためのフォーマットである。チャンク５０のフォーマットは、広い範囲のデータを記憶することができる。チャンク５０は、メタデータ部分５２と、データ部分５４とを含む。メタデータフィールドは、データ部分５４に記憶されたデータの性質について説明する。メタデータ５２は、名前５２ａと、型５２ｂと、サイズ５２ｃと、暗号化インジケータ５２ｄと、圧縮インジケータ５２ｅとを含む。暗号化インジケータ５２ｄは、データ部分５４が暗号化されているか否かを示す。圧縮インジケータ５２ｅは、データ部分５４において用いられる圧縮スキームを示す。通常は、メタデータ５２がプレーンテキストとして記憶される一方で、データ部分５４は、暗号化と圧縮とによって記憶される。

データ部分５４に記憶されるデータの例は、ディジタルオーディオ録音と、ＭＩＤＩと、テキストとを含む。データ部分は、さらなるチャンク５０を記憶することもできる（すなわち、チャンク５０の構造は再帰的（recursive）である）。サイズ５２ｃは、いつ所定のチャンク５０が終了するのかを示す。

〈パートチャンク〉
以下、図３Ｂを参照すると、パートチャンク４２は、情報チャンク４４と、データチャンク４６とを含む。情報チャンク４４は、名前４４ａと、型４４ｂと、難易度等級４４ｃと、説明４４ｄとを含む。パート１５ｃのための名前４４ａは、該パート１５ｃをユーザー１６に対して識別する。難易度等級４４ｃおよび説明４４ｄは、標準化演奏１５を、ユーザー１６に対してさらに説明する。型４４ｂは、パート１５ｃを、適切な仮想楽器に（例えば、ドラムパート１５ｃを、ドラム楽器に）マッチングさせることを許容する。

データチャンク４６は、ＭＩＤＩデータを含む。ＭＩＤＩデータは、ＭＩＤＩトラックの形にフォーマットされる。トラックの型は、ガイドトラック４８ｂと、演奏トラック４８ａと、キュートラック４８ｃと、楽譜（score）トラック４８ｄと、ローカル伴奏トラック４８ｅと、映像トラック４８ｆと、ＤＡガイドトラック４８ｇとを含む。

〈ガイドトラック〉
ガイドトラック４８ｂは、対話型パート１５ｃに対する非対話型の補集合である。ガイドトラック４８ｂは、パート１５ｃに対応する標準化演奏１５の一部分を符号化する。ユーザーは、ガイドトラック４８ｂの再生を、手動でオン／オフに切り替えることができる。さらに、システムは、ガイドトラック４８ｂを自動的に演奏することができる。

ユーザー１６は、実況的演奏が１人のユーザーも所定の対話型パートに割り当てさせないように、システム１０を構成設定することができる。このパートのオーディオコンテンツが実況的演奏のために必要とされる場合に、システム１０は、例えば、演奏トラック４８ａを対話的に表す代わりに、ガイドトラック４８ｂのオーディオコンテンツを非対話的に表す。

ガイドトラック４８ｂについては、幾つかのフォーマットで記憶することができる。ガイドトラック４８ｂは、ＭＩＤＩストリームのようなシンセサイザー制御ストリーム、または、ＭＰ３ファイルのようなサウンド録音ファイル９４を含むことができる。

ユーザーが仮想楽器を演奏しないことを選択した場合にオーディオ“フィル（fill）”を供給することの他に、１つ以上のガイドトラック４８ｂを、ガイド情報をユーザー１６に提供するために、選択的に演奏することができる。このガイド情報は、特定の仮想楽器の演奏のピッチ、リズム、音色（timbre）に関する見識を、ユーザーに提供する。例えば、ユーザー１６が不慣れなソング１５ａを歌っていれば、該ユーザー１６が歌う演奏の他に、ガイドトラック４８ｂを演奏することができる。ユーザー１６は、通常は、ボーカルよりも低い音量レベルで、このガイドトラック４８ｂを演奏する。（あるいは、ユーザー１６は、ヘッドフォンを通して、ガイドトラック４８ｂを聞くことができる。）ユーザー１６により表されるボーカル演奏の後方で穏やかに演奏されるこのガイドトラック４８ｂは、ユーザーがこのボーカル仮想楽器のための正確な演奏を提供することを補助する。ガイドトラック４８ｂについては、非ボーカル仮想楽器のためのガイド情報を提供するためにも同様に用いることができる。

〈演奏トラック〉
演奏トラック４８ａは、受理可能な入力がユーザーにより供給される場合に、パート１５ｃの実況的演奏のための基礎であるオーディオコンテンツを符号化する。演奏トラック４８ａは、ＭＩＤＩストリームを含む。ＭＩＤＩストリームのノートイベント値は、シンセサイザーの入力を符号化する。

仮想楽器は、演奏トラック４８ａを有する必要はない。弦の入力装置２８または打楽器の入力装置２８のためのパートは、通常は、演奏トラック４８ａを有している。このようなパートのために、対話型カラオケシステム１０は、受信された各々の入力刺激のために、（演奏トラック４８ａにより指定されるような）適切なピッチを有するノートを生成する必要がある。しかしながら、ボーカルパートのためのユーザー入力は、ノートを生成することをシステム１０に要求しない。代わりに、ユーザー１６は、（図５に示される）マイクロフォン２８ｂを経て、ボーカルパート入力を供給する。

〈キュートラック〉
概略的には、キュートラック４８ｃは、実況的演奏中において、どのように／いつシステム１０がユーザーに入力を催促すべきかを示す。これらの催促は、演奏トラック４８ａに１対１で対応する必要はない。代わりに、これらの催促は、通常は、演奏トラック４８ａを要約する。この要約は、ユーザー１６が演奏トラック４８ａ内の全てのノートを演奏する必要がないように、システム１０がパートを簡略化するのに役立つ。キュートラック４８ｃ内のキューは、演奏トラック４８ａから、多くのノートまたはフレーズを収集することができる。個々の刺激を多くのノートにマッピングすることは、刺激が厳密に示すよりも完全な演奏であるという錯覚（illusion）を、システム１０により生じさせることができる１つの方法である。

キュートラック４８ｃは、タイミング間隔を指定し、該タイミング間隔の間に、ユーザーは、入力刺激を催促される。一般的に、キュー間隔は重複しない。

キュー間隔のタイミング（開始および終了の両方）は、幾つかの機能を有する。これにより、いつ催促をユーザーに表示すべきかが示される。前記間隔は、受理可能なユーザー入力がこのウィンドウの間に発生すれば演奏されることになる演奏トラック４８ａの区分（sections）をさらに示す。

〈楽譜トラック４８ｄ〉
楽譜トラック４８ｄは、実況的演奏中に表示するために演奏トラック４８ａと同期する音楽的表記（musical notations）を符号化する。これらの表記は、幾つかの形式を取ることができる。１つの形式は、“Ｆ＃５”または“Ｃ５”のような、和音（chords）のテキスト記述である。これらの表記は、従来的な表記（例えば、譜表（staff）またはタブラチュア（tablature））をさらに示すことができる。

表示される表記の例については、図１２Ａおよび図１２Ｂを参照して論考する。

〈ローカル伴奏トラック〉
仮想楽器パート１５ｃ内のローカル伴奏トラック４８ｅは、全体的伴奏とは別個のものである。ローカル伴奏トラック４８ｅは、仮想楽器パートのためのさらなるオーディオ“フィル”を、必要に応じて供給する。ローカル伴奏トラック４８ｅを用いて、システム１０は、実際には入力刺激が標準化演奏１５の一部分にのみ対応している場合であっても、ユーザーが楽器パート全体を演奏しているというオーディオ的錯覚を生じさせる。標準化演奏１５は、演奏トラック４８ａおよびローカル伴奏トラック４８ｅの組み合わせであり得る。

一例として、ドラムキットについて考慮する。物理的装置として、ドラムキットは、幾つかの打楽器を伴って、かなり複雑であり得る。熟練したドラマーは、２つの手と２つの足とを別々かつ同時に用いて演奏することができる。これ以上簡素な入力装置２８であれば、プロフェッショナルのドラマーが完全なドラムキットによってリアルタイムで作成し得る多くの相互作用を、単独の入力装置によって正確に再現することはユーザーにとって困難または不可能であるという程度まで、システム１０のユーザーが操作する入力装置２８は、遙かに簡素なものであり得る。ローカル伴奏トラック４８ｅは、パート内の全ノートの部分集合または近似値を演奏することを、かつ、残りのノートを何としても供給させることを、ユーザー１６に許容する。例えば、ドラムの例において、１つの選択肢は、ユーザー１６がスネアドラムのみを演奏する一方で、ＶＩトラック内の伴奏トラックがキックドラム、タムタム、ハイハットなどを供給するというものである。

演奏において、演奏トラック４８ａと同様に、受理可能な入力がユーザーにより供給されていない期間中に、システム１０は、ローカル伴奏トラック４８ｅのオーディオコンテンツを表さない。

〈映像トラック〉
映像トラック４８ｆは、実況的演奏と同期した対話型の可視要素を提供する。映像トラック４８ｆは、ユーザーによる対話に応答してシステム１０がユーザー１６に提示するための時間符号化された（time-encoded）一連の可視フレームを含む。例えば、自動化された音楽的訓練は、映像による応答から利益を得ることができる。映像トラック４８ｆは、標準化演奏１５内のある時点に対して調和（coordinate）させた一連の貯蔵ピクチャーまたはムービーを含むことができる。例えば、映像トラック４８ｆは、ディスクジョッキーの用途のためにターンテーブルを描写することができる。この場合に、所定の標準化演奏１５のために、映像トラック４８ｆは、様々な、カスタマイズされた形のターンテーブルを提供することができる。

〈ＤＡガイドトラック〉
概念上、ＤＡガイドトラック４８ｇは、ガイドトラック４８ｂと類似したものであるが、ディジタルオーディオクリップによって特有の形で動作する。ＤＡガイドトラック４８ｇは、ＤＡトリガーチャンク３８ｃ内でインデックスを付けられかつＤＡチャンク３８ｄに記憶されたディジタルオーディオクリップを指すために、ＭＩＤＩ制御メッセージを用いる。ＤＡガイドトラック４８ｇは、時間符号化された一連のトリガー間隔を含む。これらのトリガー間隔は、いつ所定のクリップを演奏すべきかを示す。ノート番号は、どのクリップを演奏すべきかを示し、ノートの時間的配置は、いつノートを演奏すべきかを示し、かつ、ノートの継続時間は、どのくらいの間ノートを演奏すべきかを示す。ＤＡガイドトラック４８ｇは、例えば、特定のボーカル演奏と満足に合成できないオーディオコンテンツ、または、概略的には、異常なまたは独特の音質を備えたあらゆる演奏と満足に合成できないオーディオコンテンツを標準化演奏１５が含む場合に、少なくとも有用である。

サウンド録音またはディジタルオーディオクリップの効率的な使用法の１つは、多くの標準化演奏１５が冗長性（redundancy）を含むという事実を活用する。例えば、バックグラウンドトラックは、反復的な楽節（musical passage）、または、広範囲の無音（silence）部分、または、これらの両方をしばしば含む。従って、これらのバックグラウンドトラックについては、別個のクリップの形に分割することができ、各々のクリップは、各々の反復部分の最初の例を示し、その後に反復される例をもう使用しないものにする。従って、冗長的な楽節を除いては、記憶空間および帯域幅は浪費されない。再生中に、適切な時間に各々の適切なクリップに参照符号を付けることにより、これらのクリップを反復的に表すことができる。例えば、標準化演奏１５が１５秒の同じバックグラウンドコーラスを５つ有しており、かつ、これら５つのコーラスが４５秒の無音によりそれぞれ分離されれば、標準化演奏１５内に録音されたこのバックグラウンドコーラスは、全体で４分１５秒の長さとなる。しかしながら、このトラック内には１５秒の独自のデータが存在するのみであるが、その理由は、このデータチャンクが５回反復されるためである。従って、データのうちの独自の部分のみを録音することにより、４分１５秒のバックグラウンドトラックを、僅か１５秒にまで縮小することができ、９４％のファイルサイズの縮小という結果となる。（５分の間に１分につき１回）この１５秒のデータトラックの時限式（timed）かつ反復的再生を開始するためにＭＩＤＩトリガーファイルを利用することにより、ＭＩＤＩファイルの空間節約特性の他にＭＰＥＧファイルの力強いサウンド特性をさらに有するバックグラウンドトラックを作成することができる。

〈装置〉
以下、図４を参照すると、クライアント装置１２は、カラオケシステム１０のシステム論理１８を実行する。この実施例において、クライアント装置１２は、パーソナルコンピュータである。クライアント装置１２は、バス１２ｄにより相互接続されたメインメモリ１２ａ、記憶装置１２ｂ、および、プロセッサ１２ｃを含む。記憶装置１２ｂは、ディスクドライブのような非揮発性記憶媒体である。プロセッサ１２ｃは、オペレーティングシステム１８ａに従って、メインメモリ１２ａまたは記憶装置１２ｂに、あるいは、これらの両方に記憶された機械読み取り可能な命令を実行する。バス１２ｄは、クライアント装置１２の構成要素間の連絡を伝える。

この実施例において、オペレーティングシステム１８ａは、ウィンドウズ（登録商標）９８、ウィンドウズ（登録商標）９８ＳＥ、ウィンドウズ（登録商標）ＭＥ、ウィンドウズ（登録商標）２０００、ウィンドウズ（登録商標）ＸＰのようなマイクロソフトウィンドウズ（登録商標）オペレーティングシステム、または、他の互換性オペレーティングシステムである。

オーディオ出力サブシステム２７は、プロセッサ１２ｃの制御の下でサウンドを再生するための構成要素を含む。クライアント装置１２において、通常は、サウンドカード、ラウドスピーカーまたはヘッドフォン、および、増幅器が、オペレーティングシステム１８ａによってサウンドカードを動作させるためのソフトウェアドライバーとともに含まれる。

クライアント装置１２はネットワークインターフェース１２ｅを任意的に含み、該ネットワークインターフェース１２ｅは、クライアント装置１２により、リンク５８ａを経て、ネットワーク５８を横断して通信することを可能にする。例示的なネットワークインターフェース１２ｅは、イーサネット（登録商標）送受信器またはモデムを含む。ネットワークインターフェース１２ｅは、通常は、少なくともクライアント装置１２がサーバー３０と通信できるように存在しており、該サーバー３０は、クライアント装置１２とは別個のコンピューティング装置であり、かつ、ネットワーク５８を経て通信するためにリンク５８ｂを用いる。クライアント装置１２は、サーバー３０からファイル１４をダウンロードすることができる。

クライアント装置１２は、視覚表示装置２６と、１つ以上の入力装置２８とをさらに含む。視覚表示装置２６は、コンピュータスクリーンである。（図１Ａに示される）幾つかの入力装置２８は、ＱＷＥＲＴＹキーボード２８ｅ、マウス２８ｆ、または、タッチセンシティブ・スクリーン（図示せず）のような、通常のパーソナルコンピュータ周辺入力装置２８’を含んで存在し得る。他の型の入力装置２８は、弦の入力装置２８ａ（例えば、仮想ギター用または仮想ベースギター用のエレキギターピック）、マイクロフォン入力装置２８ｂ、打楽器入力装置２８ｄ（仮想ドラム用の電子ドラムパッド）、または、ＭＩＤＩイネーブル式（MIDI-enabled）楽器入力装置２８ｃ（電子ピアノ、ギター、など）のような音楽的入力装置２８”を含む。音楽的装置および非音楽的装置の両方を、システム１０への入力装置２８として用いることができる。例えば、ユーザー１６は、ＱＷＥＲＴＹキーボード２８ｅのスペースバーを叩くことにより、入力刺激をパートに供給することができる。

クライアント装置１２は、様々な仮想楽器入力装置２８のための入力ポート（図示せず）を含む。これらの仮想楽器装置は、１９９３年６月７日に出願され、１９９５年２月２８日に発行され、かつ、この参照により開示に含まれる"Virtual Music System"という題目の米国特許第５，３９３，９２６号の主題である。さらに、これらの仮想楽器入力装置２８および仮想楽器は、１９９５年５月１１日に出願され、１９９７年９月２３日に発行され、かつ、この参照により開示に含まれる"A Virtual Music Instrument with a Novel Input Device"という題目の米国特許第５，６７０，７２９号の主題である。

本発明において、仮想ピック装置２８ａはＵＳＢ装置である。

〈ソフトウェアアーキテクチャー〉
以下、図５を参照すると、システム１０のソフトウェア構成要素は、層状アーキテクチャーを有する。概略的に、これらの層は、機能に応じて、ソフトウェア構成要素を収集する。

サーバー層６０ｄは、クライアント／サーバーというサービス分割に起因するものである。サーバー層６０ｄは、共有記憶装置３０ａのような、クライアント装置１２に対して遠隔にあるサーバー３０のサービスを含む。システム１０は、ネットワーク５８を横断して、サーバー層６０ｄと通信する。

クライアント装置１２にとってローカルな層は、実行可能層６０ａと、ライブラリー層６０ｂと、オペレーティングシステム（“ＯＳ”）サービス層６０ｃとを含む。実行可能層６０ａは、プレイヤー２０と、ソングエディター２０ａとを含む。マイクロソフトウィンドウズ（登録商標）オペレーティングシステム１８ａを用いるこの実施例において、プレイヤー２０は、“．ＥＸＥ”ファイルである。換言すれば、プレイヤー２０は、オペレーティングシステム１８ａにより実行可能なアプリケーションである。プレイヤー２０は、ファイル１４の再生に関与して実行可能である最重要なものである。

ライブラリー層６０ｂは、エンジンライブラリー２２を含む。マイクロソフトウィンドウズ（登録商標）オペレーティングシステム１８ａを用いるこの実施例において、エンジンライブラリー２２は、ダイナミックリンクライブラリ、すなわち、“ＤＬＬ”である。エンジンライブラリー２２は、プレイヤー２０のコンピューティング命令を補足する命令およびデータを含む。プレイヤー２０は、エンジンライブラリー２２を自動的にロードする。

ライブラリー層６０ｂは、楽器バンク２４のような補助的ファイルをさらに含む。楽器バンク２４は、データファイル１４に記憶されたサウンドフォント３９とは無関係のサウンドフォント３９を含む。例えば、楽器バンク２４は、利用可能なサウンドフォント３９のライブラリーにして、プレイヤー２０とともに予めインストールされるライブラリーとしての機能を果たすことができる。

エンジンライブラリー２２および楽器バンク２４の両方は“ライブラリー”と称されるが、これらは、エンジンライブラリー２２が実行可能な命令を含みかつ楽器バンク２４が該命令を含まないという点で、少なくとも概念上は別個のものである。楽器バンク２４は、システム論理１８により用いられるデータファイルまたは文書である。概略的に、システム論理１８の層状アーキテクチャーは、オペレーティングシステム１８ａとアクティブ状態のソフトウェアとについての標準的慣例（すなわち、実行可能な命令）を反映する。

概略的には、ＯＳサービス層６０ｃは、オペレーティングシステム１８ａ上で作動するアプリケーションにより使用または共有できるサービスを含み、該サービスには、オペレーティングシステム１８ａの一部であるサービスが含まれる。詳細には、ＯＳサービス層６０ｃは、ＯＳサービス６２と、サードパーティーサービス６６とを含む。ＯＳサービス６２は、（図４に示される）オペレーティングシステム１８ａの一部である。ＯＳサービス６２は、デバイスドライバー６２ａと、グラフィックス・アプリケーションプログラミングインターフェース（ＡＰＩ）６２ｂと、オーディオミキサーＡＰＩ６２ｃと、ファイルシステム６２ｄとを含む。グラフィックスＡＰＩ６２ｂは、例えば、視覚表示装置２６を用いることを、システム１０に可能にさせる。オーディオミキサーＡＰＩ６２ｃは、オーディオ出力サブシステム２７を用いることを、システム１０に可能にさせる。ファイルシステム６２ｄは、記憶装置１２ｂを用いることを、システム１０に可能にさせる。デバイスドライバー６２ａは、入力装置２８とのローレベル通信を処理し、通常は、システム１０の構成要素がこのようなローレベル通信を管理する必要がないようにし、その一方で、該デバイスドライバー６２ａは、ハイレベル通信のためのゲートウェイとしての機能を果たす。

サードパーティーサービス６６は、オーディオシンセサイザー６６ａを含む。オーディオシンセサイザー６６ａは、ＭＩＤＩストリームを読み取ることができ、かつ、該ＭＩＤＩストリームを、オーディオ出力サブシステム２７を経て、オーディオとして表すことができる。

〈クラスおよびインターフェース〉
以下、図６Ａを参照すると、システム論理１８は、ソフトウェアオブジェクトを定義するクラスを含む。システム論理１８は、クラス内で実施されるインターフェースをさらに含む。概略的に、これらのクラスは、動き（behaviors）および特性（properties）を指定する。クラス定義は、システム論理１８のようなオブジェクト指向ランタイムプロセスがオブジェクトを生成するために十分な情報を提供する。生成されたオブジェクトは、クラスの一例であり、かつ、このクラスに属するものとされる。クラスに属するオブジェクトは、このクラスの動きおよび特性を実施する。インターフェースは、動きの集合を指定する。クラスは、インターフェースの実施を定義する。通常は、クラス、および、このようなクラスからのオブジェクトの両方が、インターフェースを実施するものとされる。

インターフェースの使用法の１つは、共通の動き一式を標準化することである。様々な型のオブジェクトは、各々が、同じインターフェースを実施することができる。このことは、このような異種のオブジェクトの操作を簡略化するが、その理由は、共通のインターフェースが一貫性を義務づけるためである。さらに、Ｊａｖａ（登録商標）のような幾つかのオブジェクト指向言語において、インターフェースを実施するオブジェクトについては、そのインターフェースの実施を経て、全体としてのオブジェクトへの参照符号（reference）とは別個のものとして参照符号を付けることができる。

この説明およびこれらの図面は、オブジェクトに焦点を当てている。このようなオブジェクトのクラス定義は、システム論理１８にとって利用可能であるものとして理解される。

システム論理１８は、トップレベルオブジェクト７０ａと、動的オブジェクト７０ｂと、インターフェース７０ｃとを含む。トップレベルオブジェクト７０ａは、演奏オブジェクト７２と、ＶＩマネージャーオブジェクト７４と、全体的伴奏オブジェクト７６と、演奏プールオブジェクト７８と、周辺マネージャーオブジェクト７９とを含む。概略的に、トップレベルオブジェクト７０ａは、システム１０が初期化される場合に生成されるオブジェクトを定義する。動的オブジェクト７０ｂは、仮想楽器オブジェクト８０を含む。インターフェース７０ｃは、演奏タイマーインターフェース８４と、トランスポートインターフェース８６とを含む。

〈システムの動き〉
以下、図６Ｂを参照すると、システム論理１８は、システムの動き（system behavior）９０を含む。概略的に、システムの動き９０は、ユーザー入力に応答して、マルチパートファイル１４を選択するための、かつ、関連づけられた実況的演奏を再生するための手続きを含む。

システムの動き９０は、システム１０のオブジェクトおよび設定を初期化する（プロセス９２）。いったん、ユーザー１６が標準化演奏を選択すると（プロセス９０ａ）、システムの動き９０は、後述するように、対応するマルチパートデータファイル１４を選択し、かつ、関連づけられたオブジェクトを準備する（プロセス９４）。いったん、ユーザー１６が対話すべきパートを選択すると（プロセス９０ｂ）、システムの動き９０は、対応する仮想楽器オブジェクト８０を構成設定する。次に、ユーザーは再生を開始し（プロセス９０ｃ）、かつ、システムの動き９０は、実況的対話型再生（live interactive playback）プロセス９８を開始する。

〈システムの初期化〉
以下、図６Ｃを参照すると、システムの初期化９２は、例えば、プロセッサ１２ｃにより実行するためのプレイヤー２０をオペレーティングシステム１８ａがロードする場合にプレイヤー２０を開始すること（プロセス９２ａ）を含む。例えば、プレイヤー２０は、ユーザー１６がマウス入力装置２８と、プレイヤー２０のためのアイコンをダブルクリックするために視覚表示装置２６に示されるグラフィカルユーザーインターフェース（ＧＵＩ）とを用いる場合に開始することができる。

次に、システムの初期化９２は、演奏オブジェクト７２を作成する（プロセス９２ｂ）。後述するように、ＶＩマネージャーオブジェクト７４が周辺マネージャーオブジェクト７９を作成して仮想楽器オブジェクト８０の作成および動作を調和させるように役立てることを除いては、演奏オブジェクト７２が、他のトップレベルオブジェクト７０ａを作成かつ初期化する。

システムの初期化９２は、アプリケーションウィンドウ１００を立ち上げる（launch）（プロセス９２ｃ）。

〈演奏〉
概略的に、演奏オブジェクト７２は、標準化演奏１５の実況的演奏を示し、かつ、実況的演奏を管理するための特性および動きを含む。演奏オブジェクト７２は、第１の例示すべきトップレベルオブジェクト７０ａである。演奏オブジェクト７２は、他のトップレベルオブジェクト７０ａを立ち上げる。

以下、図７Ａを参照すると、演奏オブジェクト７２は、子オブジェクトの作成（child object creation）７２ｃのためのプロセスを含む。演奏オブジェクト７２は、演奏すべき標準化演奏１５を指定するソング参照符号７２ｇのような特性をさらに含む。

子オブジェクトの作成７２ｃは、演奏オブジェクト７２が作成される場合に呼び出される。子オブジェクトの作成７２ｃは、ＶＩマネージャーの立ち上げ（launch）７２ｄ、伴奏の立ち上げ７２ｅ、および、演奏プールの立ち上げ７２ｆのようなプロセスを含む。ＶＩマネージャーの立ち上げ７２ｄは、ＶＩマネージャーオブジェクト７４を作成する。伴奏の開始７２ｅは、全体的伴奏オブジェクト７６を作成する。演奏プールの立ち上げ７２ｆは、演奏プールオブジェクト７８を作成する。演奏オブジェクト７２により作成されるこれらのオブジェクト（ＶＩマネージャーオブジェクト７４、全体的伴奏オブジェクト７６、および、演奏プールオブジェクト７８）の各々は、該演奏オブジェクト７２にとって個別のものである。

演奏オブジェクト７２は、図１５Ａおよび図１５Ｂをそれぞれ参照して説明するトランスポートインターフェース８６をさらに実施する。

〈アプリケーションウィンドウ〉
以下、図８Ａを参照すると、プレイヤー２０は、オペレーティングシステム１８ａにより管理されるＧＵＩ内に、アプリケーションウィンドウ１００を有する。アプリケーションウィンドウ１００は、制御エリア１００ａを含む。ユーザー１６は、制御エリア１００ａと対話して、システム１０上で演奏可能な標準化演奏１５のリスト１００ｄから、標準化演奏１５を選択する。リスト１００ｄは、各々の利用可能な標準化演奏１５のために、対応するデータファイル１４の（図２に示される）ソング情報３６に記憶された情報を表示する。ユーザー１６は、ＧＵＩを経て、リスト１００ｄにアクセスし、かつ、該リスト１００ｄをナビゲートする。リスト１００ｄは、遠隔の音楽サーバー３０から既にダウンロードされたデータファイル１４のための標準化演奏１５を示すことができる。さらに、リスト１００ｄは、遠隔の音楽サーバー３０から利用可能なデータファイル１４のための標準化演奏１５を含むことができる。

アプリケーションウィンドウ１００は、ソング情報表示１００ｂと、ユーザーエリア領域１００ｃとをさらに含む。ソング情報表示１００ｂは、現在選択されている標準化演奏１５についてのソング情報３６に記憶された情報を表示する。ユーザーエリア領域１００ｃは１つ以上のユーザーエリア１０２を含み、該ユーザーエリア１０２の各々は、ユーザー１６により演奏可能なパートに対応する。実況的演奏中に、カラオケシステム１０と対話する各々のユーザーがパート１５ｃと一対にされる場合に、このようなユーザー１６の各々は、自分のパートにとって適切な視覚的フィードバックを、自分専用のユーザーエリア１０２において受信する。

〈周辺マネージャー〉
以下、図８Ｂを参照すると、周辺マネージャーオブジェクト７９は、装置の発見７９ａ、装置カタログサービス７９ｂ、および、ドライバー管理７９ｅのようなプロセスを含む。周辺マネージャーオブジェクト７９は、入力装置カタログ７９ｃのような特性をさらに含み、該入力装置カタログ７９ｃは、入力装置の説明７９ｄを含む。

装置の発見７９ａは、クライアント装置１２に結びつけられた入力装置２８を発見するために、ランタイムにおいて呼び出される。装置の発見７９ａは、このような入力装置２８についての情報を、入力装置の説明７９ｄに記憶する。装置カタログサービス７９ｂは、入力装置カタログ７９ｃの内容を、仮想楽器オブジェクト８０のような他のオブジェクトにとって利用可能にする。ドライバー管理７９ｅは、（図５に示される）デバイスドライバー６２ａと対話して、入力装置２８と通信する。

〈ＶＩマネージャーオブジェクト〉
概略的に、ＶＩマネージャーオブジェクト７４は、仮想楽器オブジェクト８０の集合を管理する。通常は、このような仮想楽器オブジェクト８０の各々は、標準化演奏１５のオーディオコンテンツの別個のパートを示す。

以下、図９Ａを参照すると、ＶＩマネージャーオブジェクト７４は、仮想楽器の作成７４ａおよび子オブジェクトの作成７４ｂのようなプロセスと、ロードプロセス１０４とを含む。ＶＩマネージャーオブジェクト７４は、仮想楽器オブジェクトの集合７４ｄのような特性をさらに含み、該仮想楽器オブジェクトの集合７４ｄは、ＶＩマネージャーオブジェクト７４により作成された各々の仮想楽器オブジェクト８０のための参照符号７４ｅを含む。

ＶＩマネージャーオブジェクト７４は、システムの初期化９２中に例示される。自動的に例示されると、ＶＩマネージャーオブジェクト７４は、子オブジェクトの作成７４ｂを実行する。子オブジェクトの作成７４ｂは、周辺マネージャーオブジェクト７９を例示する（プロセス７４ｃ）。後述するように、ロードプロセス１０４は、ユーザー１６がソング１５ａをファイル選択９４の一部として選択する場合に発生する。

以下、図９Ｂを参照すると、ロードプロセス１０４は、ファイル１４内のＶＩプール４０を探す（プロセス１０４ａ）。次に、ロードプロセス１０４は、ＶＩプール４０内のパートチャンク４２を探す（プロセス１０４ｂ）。ロードプロセス１０４は、マルチパートデータファイル１４を検査して、どの仮想楽器を生成する必要があるのかを判断する。詳細には、ロードプロセス１０４は、各々のパートチャンク４２の（図３に示される）情報チャンク４４を走査する（プロセス１０４ｃ）。ロードプロセス１０４は、現在のパートチャンク４２を指定する参照符号を発見し（プロセス１０４ｄ）、かつ、このパートチャンク４２に対応するための仮想楽器オブジェクト８０がこの参照符号により例示される場合に、この参照符号を伝える（プロセス７４ａ）。ロードプロセス１０４は、新たな仮想楽器オブジェクト８０に対する参照符号を、集合７４ｄにさらに加える（プロセス１０４ｅ）。ロードプロセス１０４は、ＶＩプール４０内の各々のパートチャンク４２について（プロセス１０４ｂ）をループし、その後に終了する。

〈ファイル選択〉
以下、図１０Ａを参照すると、ユーザーは、標準化演奏１５を選択する（図６Ｂに示されるプロセス９０ａ）。ファイル選択９４は、対応するデータファイル１４を突き止める（手続き９４ａ）。ファイル選択９４は、データファイル１４を指定するファイル参照符号を、演奏オブジェクト７２へ伝える（手続き９４ｂ）。例えば、ファイル参照符号は、（図５に示される）ファイルシステム６２ｄ内のファイル名であり得る。ファイル参照符号を用いて、演奏オブジェクト７２は、演奏プールオブジェクト７８に、データファイル１４をロードさせる（手続き９４ｃ）。演奏オブジェクト７２は、ロードプロセス１０４を用いて、ロードすべき自身の子オブジェクトを指示する（手続き９４ｄ）。

遠隔の音楽サーバー３０のデータベース上で利用可能な標準化演奏１５を実行することをユーザー１６が希望する場合に、または、標準化演奏１５をリスト１００ｄに加えることを管理者が希望する場合に、対話型カラオケシステム１０は、サーバー３０から適切なマルチパートデータファイル１４をダウンロードする。

〈パート選択〉
以下、図１０Ｂを参照すると、利用可能な仮想楽器が、アプリケーションウィンドウ１００に表示されるリストの形式で、ユーザー１６に提示される。パート選択９６は、アプリケーションウィンドウ１００内のこのリストおよび関連づけられたＧＵＩ制御によって、ユーザーによる対話に応答する。概略的に、パート選択９６は、演奏すべきパートを選択することを、０人以上のユーザー１６に許容する。パートと一対にされるユーザー１６が存在しなければ、システム１０は、標準化演奏１５を表すために、ガイドトラック４８ｂを用いることができる。多くのユーザー１６がパートと一対にされれば、仮想バンドが作成される。

ユーザーがパートの演奏を希望していることを示せば（プロセス９６ａ）、パート選択９６は、対応する仮想楽器オブジェクト８０を対話型にする（プロセス９６ｂ）。次に、パート選択９６は、ＧＵＩを用いて、入力装置２８を選択するように（プロセス９６ｃ）、かつ、サウンドフォント３９を選択するように（プロセス９６ｄ）、ユーザーに催促する。パートチャンク４２は、型４４ｂから推論できるデフォルトの入力装置２８とサウンドフォント３９とを有しているので、プロセス９６ｃ，９６ｄは任意的なものであることに留意されたい。プロセス９６ｄは、デフォルトのサウンドフォント３９に上書きすることを、ユーザーに許容する。プロセス９６ｃの例は、ユーザー１６がドラムパートを演奏するためにギターピック２８ａを選択することである。

ユーザーがパートの演奏を希望しないことを示せば（プロセス９６ａ）、パート選択９６は、対応する仮想楽器オブジェクト８０を非対話型にする（プロセス９６ｅ）。パート選択９６は、利用可能な入力装置２８の数に従って、パートの演奏を選択するユーザー１６の数だけ、これらの選択を反復する（プロセス９６ｆ）。

〈再生〉
以下、図７Ｂを参照すると、ユーザー１６は、実況的対話型再生プロセス９８を開始するように、システムに命令する（プロセス９０ｃ）。実況的対話型再生プロセス９８は、再生処理７２ａを開始するように、演奏オブジェクト７２に命令する（プロセス９８ａ）。次に、再生処理７２ａは、ユーザー入力処理８０ａを開始するように、各々の仮想楽器オブジェクト８０に命令する（プロセス９８ｂ）。さらに、再生処理７２ａは、非対話型再生７６ａを開始するように、全体的伴奏オブジェクト７６に命令する（プロセス９８ｃ）。仮想楽器オブジェクト８０および全体的伴奏オブジェクト７６は、標準化演奏１５が終了するかまたはユーザー１６により中断されるまでは、実況的演奏（プロセス９８ｄ）中において、別々に動作する。

〈仮想楽器オブジェクト〉
以下、図１１Ａを参照すると、仮想楽器オブジェクト８０は、ユーザー入力処理８０ａ、パートプレイヤー８０ｂ、および、キュー表示８０ｋのようなプロセスを含む。仮想楽器オブジェクト８０は、マッチングタグ８０ｆ、周辺マネージャー参照符号８０ｇ、演奏プール参照符号８０ｈ、および、演奏プールオフセット８０ｉのような特性をさらに含む。

仮想楽器オブジェクト８０は、全体的伴奏オブジェクト７６上の演奏タイマーインターフェース８４に対する参照符号を有する。仮想楽器オブジェクト８０は、図１４Ａおよび図１４Ｂをそれぞれ参照して説明するトランスポートインターフェース８６をさらに実施する。

仮想楽器オブジェクト８０は、対話型である（すなわち、実況的演奏中に、ユーザーによる入力刺激に応答する）。ユーザー入力処理８０ａは、これらの対話を、これらの刺激とキュートラック４８ｃ内の符号化されたデータの催促とを相関させながら処理する。周辺マネージャー参照符号８０ｇは、入力装置２８との通信を可能にする周辺マネージャーオブジェクト７９を指定する。

仮想楽器オブジェクト８０は、キュー表示８０ｋを経て、視覚的フィードバックをユーザー１６に提示する。

マッチングタグ８０ｆは、仮想楽器オブジェクト８０とともに用いるために推奨される音楽的入力装置２８”の型を指定する。入力装置２８は、（図８Ｂに示される）入力装置カタログ７９ｃ内に示される。

仮想楽器オブジェクト８０は、演奏プールオブジェクト７８を経て、（図１５Ｃに示される）演奏トラック４８ａと、他のトラックとを読み取る。演奏プール参照符号８０ｈおよび演奏プールオフセット８０ｉは、関連演奏トラック４８ａの位置を指定する。

パートプレイヤー８０ｂは、対話型再生プロセス８０ｃと、充填プロセス８０ｄとを含む。対話型再生プロセス８０ｃは、演奏トラック４８ａのオーディオコンテンツを表し、かつ、（このようなコンテンツが存在する場合には）ローカル伴奏トラック４８ｅと、映像トラック４８ｆとを表す。充填プロセス８０ｄは、ガイドトラック４８ｂと、ＤＡガイドトラック４８ｇとを表す。ユーザーが演奏するために選択するパート１５ｃとは無関係に、対話型カラオケシステム１０は、非演奏（un-played）パート１５ｃを持たない実況的演奏を表すことができるが、その理由は、充填プロセス８０ｄが、欠落している演奏を充填するためである。

実況的演奏中に、ユーザー１６は、入力刺激を、これらの仮想楽器入力装置２８の１つ以上に供給する。これらの入力刺激は、１つ以上の入力信号を生成し、該入力信号の各々は、仮想楽器入力装置２８の１つに対応する。ユーザー１６により供給される入力刺激の形式は、入力装置２８およびユーザー１６が演奏している仮想楽器の型によって変動する。（図４に示される）エレキギターピック２８ａを利用するパートについて、ユーザー１６は、通常は、仮想ギターピック２８ａを固い表面に強打することにより、入力刺激を供給する。電子ドラムパッド２８ｄを用いる打楽器パートについて、ユーザー１６は、通常は、固い物体によってドラムパッドを打つことにより、入力刺激を供給する。ボーカルパートについて、ユーザー１６は、マイクロフォン２８ｂに対して歌う。

パートプレイヤー８０ｂは、演奏トラック４８ａ内で符号化されたオーディオコンテンツに従って、特定の仮想楽器オブジェクト８０により受信された入力信号を、オーディオ出力のためのノートにマッピングする。しかしながら、ユーザー１６は、これらの入力刺激を、タイミングインデックスよりも時間的に前に、または、後に供給することができる。あるいは、ユーザー１６は、オーディオコンテンツが指定する様々な数の入力刺激を供給することができる。従って、各々のピッチ制御インデックス９６のために、パートプレイヤー８０ｂは時間ウィンドウを決定し、該時間ウィンドウ中において、対応する仮想楽器から受信されたあらゆる入力刺激は、その期間にわたって、演奏トラック４８ａのオーディオコンテンツにマッピングされる。例えば、ユーザー１６が仮想ギターピック２８ａを時間ウィンドウ中に３回鳴らせば（各々の鳴りが入力刺激である）、パートプレイヤー８０ｂは、対応するオーディオコンテンツの３つのサンプルを、サステインをかけられた連続的なサウンドが該オーディオコンテンツによりこの時間中に指定される場合であっても、演奏する。このことは、即興演奏すること、および、自分たちの演奏をカスタマイズすることを、ユーザー１６に許容する。

ユーザーにより演奏される特定のノートのピッチを制御することの他に、パートプレイヤー８０ｂは、各々の仮想楽器の音響的特徴を、特定の仮想楽器のためのサウンドフォント３９に従って設定する。

ボーカルが対話型カラオケシステム１０による処理も何も必要とせずに簡単に再生される一方で、非ボーカル（non-vocal）仮想楽器オブジェクト８０（例えば、ギター、ベース、または、ドラムを示すもの）に供給される入力刺激は、これらの入力刺激の各々のために、特定のピッチとタイミングと音色とを各々が有する１つ以上のノートを演奏できるように処理される。演奏トラック４８ａは、これらの入力刺激の各々を特定のノートまたはノート一式にマッピングするために必要な情報を提供する。

〈ＶＩツリー〉
以下、図１１Ｂを参照すると、仮想楽器オブジェクト８０は、オブジェクトの引き継ぎ（inheritance）を支援する。仮想楽器オブジェクト８０についてのクラスにおいて表現されるような仮想楽器の概略的な特徴については、サブクラスにより引き継ぐことができ、これらのサブクラスは、これらの特徴を自身の必要に応じて純化かつカスタマイズし、かつ、。例えば、ＶＩボーカルクラス１１１がマイクロフォンインターフェースプロセス１１１ａを含み得る一方で、ＶＩドラマーオブジェクト１１２はスティックインターフェースプロセス１１２ａを含み、かつ、ＶＩストラマー（strummer）オブジェクト１１４はピックインターフェースプロセス１１４ａを含む。これらのインターフェースプロセス１１０ａ，１１２ａ，１１４ａの各々は、そのクラスにとって独自のものである。

仮想楽器クラス１１０のサブクラスは、独自のサブクラスを有し得る。例えば、ＶＩベース１１６およびＶＩギター１１８は、各々が、ＶＩストラマーからの引き継きを行う。

〈キュー表示〉
以下、図１２Ａを参照すると、キュー表示８２は、実況的演奏中に、入力刺激をユーザー１６に催促する。キュー表示８２は、キュートラック４８ｃ内のタイミングインデックスに従って、催促をユーザーエリア１０２に表す。これらのタイミングインデックスは、仮想楽器入力装置２８および演奏されている仮想楽器の型に応じて、形式的に変動する。例えば、仮想楽器入力装置２８が弦の入力装置２８または打楽器の入力装置２８であれば、タイミングインデックスはスパイク１２２として表される。各々のスパイク１２２は、ユーザー１６が入力刺激を仮想楽器入力装置２８に供給すべき時点を、図式的に表示する。この時間は、キューイング領域１０２ｂ内における、軸１０２ｃに沿ったスパイク１２２の位置により視覚的に示される。このキュートラック４８ｃは、２０００年２月１７日に出願され、２００１年１月１６日に発行され、かつ、この参照により開示に含まれる"System and Method for Variable Music Annotation"という題目の米国特許第６，１７５，０７０Ｂ１号の主題である。

ユーザー１６が入力刺激を供給すべき時点を示すのみであるスパイク１２２の他に、または、該スパイク１２２の代わりに、キュー表示８２は、演奏されているノートのピッチに関する情報を、楽譜トラック４８ｄにより提供されるような譜表（図示せず）またはノートベースの（note-based）音楽的注釈の形式で表示することができる。例えば、キュー表示８２は、和音表記１０２ｅまたは（図１２Ｂに示される）タブラチュア１０２ｆ（または、１０２ｇ）を表すことができる。

キュー表示８２は、スパイク１２２を、時間軸１０２ｃと整列されるダブルスパイク１２２ａとして、キューイング領域１０２ｂの両側に表すことができる。あるいは、キュー表示８２は、スパイク１２２を、シングルスパイク１２２ｂとして、キューイング領域１０２ｂの一側に表すことができる。

他の代替案は、キューイング領域１０２ｂにおいて対向する側にそれぞれ存在するシングルスパイク１２２ｂからなる２つのグループである。この場合に、最初のグループのシングルスパイク１２２ｂはキューを提供する一方で、他方のグループのシングルスパイク１２２ｂは、実況的演奏中にユーザー１６により供給される実際の入力刺激のタイミングを示す。従って、キューイングスパイク１２２ｂおよび刺激スパイク１２２ｂの相対的位置は、キュータイミングに対するユーザー入力の精度に関して、図式的フィードバックを供給する。

以下、図１２Ｂを参照すると、スパイク１２２はキューイング領域１０２ｂ上の固定位置にある一方で、スイーパー（sweeper）１０２ｈは、キューイング領域１０２ｂを左から右へ横断して通る。あるいは、図１２Ａを参照すると、キューイング領域１０２ｂおよびその内容は、左へスクロールすることもできる。後者のスキームにおいて、各々の催促のタイミングは、固定のタイミングインジケータ１０２ｉの下を通過する対応スパイク１２２により示される。

ボーカルパートの実況的演奏について、キュー表示８２は、歌詞によって、ユーザー１６に催促を行うことができる。ボーカルパートについて、キュートラック４８ｃにより提供されるタイミングインデックスは、このような歌詞を、各々の言葉または語句が歌われるべき特定の時点を示すタイミング情報とともに含む。キュー表示８２は、スイーパー１０２ｈまたはタイミングインジケータ１０２ｉと調和して、各々の言葉または語句を、各々の言葉が歌われるべき特定の時点において、強調表示される歌詞１０２ｋとして、順次的に表すことができる。

キュー表示８２は、名前１０２ａをキューイング領域１０２ｂに表す。名前１０２ａは、通常は、（図３Ｂに示される）情報チャンク４４内に提供された情報に対応して、パートについて説明するテキストを含む。

〈全体的伴奏〉
実況的演奏は、全体的伴奏からの音楽的命令からなる少なくとも１つのトラックを必要とする。全てのパートが対話型である（すなわち、可聴的には伴奏されない）場合であっても、演奏は、マスタータイミング制御を必要とする。

以下、図１３Ａを参照すると、全体的伴奏オブジェクト７６は、伴奏ロードプロセス１２０および非対話型再生プロセス７６ａのようなプロセスをさらに含む。全体的伴奏オブジェクト７６は、伴奏プール参照符号７６ｂおよびマッチングタグ７６ｃのような特性をさらに含み、該伴奏プール参照符号７６ｂは、演奏プールオブジェクト７８を経て、データファイル１４内の伴奏プール３８を突き止め、かつ、該マッチングタグ７６ｃは、サウンドフォント３９を指定し、仮想楽器オブジェクト８０のマッチングタグ８０ｆと類似したものである。しかしながら、仮想楽器オブジェクト８０のマッチングタグ８０ｆは互換性の入力装置２８を指定する一方で、マッチングタグ７６ｃはこれを行わない。（全体的伴奏オブジェクト７６は、非対話型パートを演奏するので、入力装置２８についての情報を必要としない。）

非対話型再生プロセス７６ａは、トラックチャンク３８ａの内容を表し、かつ、実況的演奏のためのマスタータイミングパルスを供給する。

全体的伴奏オブジェクト７６は、図１４Ａおよび図１４Ｂをそれぞれ参照して説明する演奏タイマーインターフェース８４およびトランスポートインターフェース８６をさらに実施する。

以下、図１３Ｂを参照すると、伴奏ロードプロセス１２０は、トラックチャンク３８ａから、音楽的内容をロードする（プロセス１２０ａ）。次に、伴奏ロードプロセス１２０は、ソフトウェアシンセサイザー６６ａと対話して、サウンドフォント３９によってソフトウェアシンセサイザー６６ａの準備を行う（プロセス１２０ｂ）。次に、伴奏ロードプロセス１２０は、ＤＡトリガーチャンク３８ｃのうちの少なくとも最初の部分を読み取る（プロセス１２０ｃ）。次に、伴奏ロードプロセス１２０は、オーディオ出力サブシステム２７のオーディオバッファを、ＤＡチャンク３８ｄからのＭＰ３ファイルの最初のサンプルが存在すれば該最初のサンプルによって充填する（プロセス１２０ｄ）。この充填は、実況的演奏を開始するためのユーザー１６からの信号に先立って行われる。バッファの充填は、信号が発生する場合の応答を向上させる。

〈演奏タイマーインターフェースおよびトランスポートインターフェース〉
概略的に、マルチパートデータファイル１４のマルチパートの同期再生は、タイミングを調和させる概念を必要とする。

以下、図１４Ａを参照すると、演奏タイマーインターフェース８４は、タイミング信号の交換を許容する。詳細には、演奏タイマーインターフェース８４は、演奏タイマーインターフェース８４を実施するオブジェクト間におけるクロックパルスの伝達（dissemination）を許容する。

演奏タイマーインターフェース８４は、パルス伝達プロセス８４ａと、パルス受信プロセス８４ｂとを含む。パルス受信プロセス８４ｂは、準拠的な（compliant）オブジェクトに、時限式イベントの通知を、マスタータイマーと同期して受信させる。全体的伴奏オブジェクト７６は、マスタータイマーとしての機能を果たす。全体的伴奏オブジェクト７６は、トラックチャンク３８ａ内のタイミング情報に基づいてクロックパルスを生じさせ、かつ、マスタータイミング信号を用いる他のオブジェクト（演奏オブジェクト７２および仮想楽器オブジェクト８０を含む）へ信号を送るためにパルス伝達プロセス８４ａを用いる。

時限式であり、かつ、パルス伝達プロセス８４ａにより伝達されるイベントは、実況的演奏の開始および停止、小節（measures）の境界および拍子（beats）のような、パルスイベントおよび音楽的イベントの両方を含む。

以下、図１４Ｂを参照すると、トランスポートインターフェース８６は、マルチパートデータファイル１４の再生速度を制御するためのプロセスについて説明する。トランスポートインターフェース８６は、再生８６ａと、停止８６ｂと、早送り８６ｃと、巻き戻し８６ｄとのためのプロセスを含む。トランスポートインターフェース８６は、パートの同期再生を調和させることを、オブジェクトに許容する。詳細には、演奏オブジェクト７２および全体的伴奏オブジェクト７６は、仮想楽器オブジェクト８０による同期再生の速度を制御することができる。

〈演奏プール〉
以下、図１４Ｃを参照すると、演奏プールオブジェクト７８は、説明７８ａ、復元７８ｂ、および、ディレクトリサービス７８ｃのようなプロセスを含む。ディレクトリサービス７８ｃは、発見プロセス７８ｄと、ナビゲーションプロセス７８ｅと、検査プロセス７８ｆとを含む。演奏プールオブジェクト７８は、ディレクトリ構造７８ｇおよび理論的（abstract）アクセスポイント７８ｈのような特性をさらに含む。

演奏プールオブジェクト７８は、ディレクトリサービス７８ｃを、データファイル１４内に提供する。換言すれば、演奏プールは、システム論理１８のオブジェクトと、記憶装置１２ｂまたはサーバー３０内のデータファイル１４のオブジェクトとの間の調停を行う。演奏プールオブジェクト７８は、理論的アクセスポイント７８ｈをデータに提供し、こうして、例えば、仮想楽器オブジェクト８０がデータファイル１４のファイル構造を検査する必要がないように、または、データファイル１４の位置を認識する必要がないようにする。演奏プールオブジェクト７８は、様々な理論的アクセスポイント７８ｈを、様々なクライアントオブジェクトに提供することができる。

概略的に、ディレクトリサービス７８ｃは、他のオブジェクトが用いるために公表されるプロセスである。発見プロセス７８ｄは、チャンク５０のような再帰的データ構造７８ｇを発見する。ナビゲーションプロセス７８ｅは、このようなデータ構造７８ｇ間をナビゲートすることを、オブジェクトに許容する。検査プロセス７８ｆは、データ構造７８ｇを閲覧しかつこれらの内容にアクセスすることを、オブジェクトに許容する。

説明７８ａおよび復元７８ｂは、データファイル１４の記憶フォーマットを、システム論理１８内で用いるために利用可能なフォーマットの形に転換する。概略的に、演奏プールオブジェクト７８は、暗号化と、データファイル１４の配信機構と、データファイル１４の位置と、データファイル１４の内部ファイル構造とについての情報から、他のオブジェクトを保護する。

〈代替的なＭＩＤＩマッピング〉
ＭＩＤＩプロトコルは、ノートイベントデータを配信できる時間符号化されたストリームを、制御ストリームのような他の特徴とともに定義する。ノートデータは、０〜１２７までの範囲の整数と仮定する。従来的に、この範囲内における各々のノートは、西洋音楽の音階（scale）における別個の音符を示し、従来的なピアノキーボードの演奏および殆どの音楽演奏の範囲をほぼ包含する。この慣例によれば、ノートイベントストリーム内のデータ値は、シンセサイザー６６ａにより表すためのノートを示す。さらに、この慣例によれば、この範囲の全体にわたって、ノートイベント値１はノートイベント値０よりも高いピッチであり、値２は値１よりも高いピッチである、などである。さらなる慣例は、歌詞のような非ノート（non-note）情報または制御情報を、ＭＩＤＩを経て、制御ストリーム内で伝えることができるという点である。

ＤＡトリガーチャンク３８ｃのアーキテクチャーは、ＭＩＤＩを、時間符号化された通信プロトコルとして、より一般的に用いる。ノートイベントストリーム内の値は、意味的に（semantically）、非ノート的な意味にマッピングされる。換言すれば、ＤＡトリガーのアーキテクチャーは、非ノートデータを伝えるために、ＭＩＤＩノートイベント値を用いる。詳細には、ノートイベントストリーム内の値は、ディジタルオーディオクリップに対するインデックスである。ノートイベント値についての慣例的な順番づけ（すなわち、ノートイベント値の上昇がピッチの上昇に対応するという概念）は、この取り組みの下では任意的なものである。例えば、このＭＩＤＩノートイベントストリームの代替的な使用法において、対応するディジタルオーディオクリップがファイル１４のＤＡチャンク３８ｄ内に現れる順番をインデックスが示すように、値を選択することができる。他の順番づけも可能であり、または、ノートイベント値を、これらの相対的な順番に何の意味も割り当てずに用いることもできる。

以下、図１５Ａを参照すると、マッピングプロセス１３０は、名目上の（nominal）ＭＩＤＩノートイベント値を、ディジタルオーディオクリップのような非ノート値にマッピングする。明瞭さのために、この説明は、“ＭＩＤＩノートイベント値”という用語を用いるが、その理由は、これが、ＭＩＤＩストリームのこの部分に対する従来的な用語であるためである。しかしながら、この文脈における“ノートイベント値”という用語については、必ずしも音符情報を伝達するとは限らないものとして理解すべきである。この説明は、ＭＩＤＩノートイベント値が名目上においてのみ言及される旨を強調するために、“名目上”という語を付与している。実際に、マッピングプロセス１３０の利点の１つは、ＭＩＤＩノートイベント値を音符とする慣例的な解釈により制約されないという点である。

マッピングプロセス１３０は、ＭＩＤＩストリームとともに用いるための、オーディオクリップに対する、名目上のノートイベント値のマッピングを受信する（プロセス１３０ａ）。このマッピングにおける名目上のノートイベント値の各々は、別個のオーディオクリップに対応する。マッピングプロセス１３０は、ＭＩＤＩストリームから、名目上のノートイベント値を読み取る（プロセス１３０ｂ）。マッピングプロセス１３０は、ＤＡトリガーチャンク３８ｃに従って、この値を、オーディオクリップのインデックスのような非ノート値にマッピングする（プロセス１３０ｃ）。マッピングプロセス１３０は、ストリームの終わりまで、ストリームから後続の値を読み取るために戻る（プロセス１３０ｄ）。次に、マッピングプロセス１３０は、名目上のＭＩＤＩノートイベント値を、対応するクリップ参照符号に置き換えて、ＭＩＤＩストリームを出力する（プロセス１３０ｅ）。

以下、図１５Ｂを参照すると、リアルタイムマッピングプロセス１３２は、出力タイミングを除いては、前述のマッピングプロセス１３０と類似したものである。リアルタイムマッピングプロセス１３２は、マッピングプロセス１３０の出力段階（１３０ｅ）を省略している。読み取られた値をオーディオクリップ参照符号にマッピングした後に、かつ、次の読み取りを反復する前に、リアルタイムマッピングプロセス１３２は、現在の名目上のＭＩＤＩノートイベント値を、対応する現在のクリップ参照符号に置き換えて、ＭＩＤＩデータを出力する（プロセス１３２ａ）。

以下、図１６を参照すると、ＭＩＤＩマッピング再生プロセス１３４は、名目上のＭＩＤＩノートイベント値のストリーム内におけるオーディオクリップ参照符号を再生するためのＭＩＤＩマッピングプロセスを含む。ＭＩＤＩマッピング再生プロセス１３４は、ＭＩＤＩストリームと、オーディオクリップに対するノート値のマッピングとを受信する（プロセス１３４ａ）。説明する実施例において、ＤＡトリガーチャンク３８ｃは、オーディオクリップに対する、名目上のノートイベント値の適切なマッピングを与える。次に、ＭＩＤＩマッピング再生プロセス１３４は、リアルタイムマッピングプロセス１３２をＭＩＤＩストリーム上で用いて、オーディオクリップに対する参照符号のストリームを生じさせる（プロセス１３４ｂ）。次に、ＭＩＤＩマッピング再生プロセス１３４は、参照符号により指定されたオーディオクリップを表す（プロセス１３４ｃ）。

〈代替的な実施例〉
マルチパートデータファイル１４については、統一的な様式で転送されるものとして説明してきたが、これは例示的な目的のために過ぎない。各々のマルチパートデータファイル１４は、単に、様々な構成要素（例えば、仮想楽器オブジェクト８０および全体的伴奏オブジェクト７６）からなる集合であり、該構成要素の各々は、様々な下位構成要素およびトラックを含む。従って、前述した統一的な様式の他に、これらの構成要素および／または下位構成要素についても、個々に、または、様々なグループの状態で、転送することができる。

さらに、説明した実施例において、データファイル１４は、記憶媒体１２ｂ上の、または、共有記憶装置３０ａ上のファイルである。しかしながら、データファイル１４のフォーマットは、任意のディジタル記憶媒体に適用される。代替的な実施例において、データファイル１４のフォーマットは、ネットワーク通信フローのようなストリーム内のディジタル情報を、または、クライアント装置１２またはサーバー３０のメインメモリ内のディジタル情報を組織化する。

パート符号化プロセス１９は、対話型または非対話型に指定された各々のパート１５ｃを備えた標準化演奏１５を受信する（プロセス１９ａ）。例えば、人間の管理者が、このような指定を与えることができる。

この実施例において、オペレーティングシステム１８ａは、ウィンドウズ（登録商標）９５、ウィンドウズ（登録商標）ＮＴ４．０、または、他の互換性オペレーティングシステムである。

エンジンライブラリー２２については、ＤＬＬとして説明してきたが、エンジンライブラリー２２は、他の基準に従うソフトウェア構成要素であり得る。さらに、エンジンライブラリー２２を、プレイヤー２０から分離する必要はなく、統合することができる。

システム論理１８については、システム論理を実行するクライアント装置１２上に存在するものとして説明してきた。または、システム論理１８については、多くの装置１２にわたって分散させることができる。

ヘッダー３２については、本体３４に優先するものとして説明してきた。物理的レベルまたは論理レベルのいずれか、または、両方のレベルにおいて、データファイル１４の構成要素の順番づけを他の状態に並べ替えることも可能である。

説明した実施例において、データファイル１４は、１つの標準化演奏１５を含む。または、データファイル１４は、１つよりも多い標準化演奏１５を含むことができる。他の代替案として、データファイル１４は、標準化演奏１５の断片（fractional）部分を含むことができる。例えば、第１データファイル１４はソング１５ａを含むことができる一方で、第２データファイル１４は補足的または代替的なパート１５ｃを含むことができる。

説明した実施例において、データファイル１４は、チャンク５０を用いるフォーマットを有し、伴奏プール３８とＶＩプール４０とを含む本体３４を有し、該伴奏プール３８とＶＩプール４０とは、さらなるチャンク５０を含む。代替的な実施例において、データファイル１４は、別のフォーマットにおける同じ論理実在物（logical entities）を有し得る。

説明した実施例において、クライアント装置１２はパーソナルコンピュータである。他の装置１２も可能である。

説明した実施例において、クライアント装置１２は記憶装置１２ｂを含む。または、記憶装置１２ｂは、クライアント装置１２に対して遠隔に存在し得る。

視覚表示装置２６は、投影器または他の表示装置であり得る。

説明した実施例において、パートを演奏するために、ユーザーはパートを選択し、次に、システムは、サウンドフォントと入力装置とを自動的に選択する。代替的な実施例において、ユーザーは、パートのためのサウンドを様々な型の中から選択することができる。

説明した実施例において、シンセサイザー制御データは、０〜１２７という範囲の１２８個の別個の整数値のいずれかを取り得る名目上のＭＩＤＩノートイベント値である。代替的な実施例において、シンセサイザー制御データは非ＭＩＤＩデータであり得る。他の代替的な実施例において、シンセサイザー制御データは、名目上のノートイベント値以外のＭＩＤＩ値であり得るか、または、他の範囲の値を取り得る。概略的に、シンセサイザー制御データは、１２８個よりも多い（または、１２８個よりも少ない）別個の値を取ることが可能である。

説明した実施例において、ディジタルオーディオクリップは、常に始めから演奏される。代替的な実施例において、システム１０は、ディジタルオーディオクリップのランダムアクセス再生を行うことができる。

説明した実施例において、マッピングプロセス１３０およびリアルタイムマッピングプロセス１３２は、名目上のノートイベント値を、オーディオクリップにマッピングする。しかしながら、概略的に、マッピングプロセス１３０およびリアルタイムマッピングプロセス１３２は、適切なマップを与えられた場合に、名目上のノートイベント値を、非ノートデータに転換する。換言すれば、マッピングプロセス１３０およびリアルタイムマッピングプロセス１３２は、各々が、ＭＩＤＩを、汎用時間符号化通信プロトコル（general-purpose time-coded protocol）として用いることを可能にする。前記マップは、名目上のＭＩＤＩノートイベント値の従来的な音楽的意味を、非ノート的な意味に置き換える。

説明した実施例において、ＭＩＤＩマッピング再生プロセス１３４は、リアルタイムマッピングプロセス１３２をＭＩＤＩストリーム上で用いる。代替的な実施例において、ＭＩＤＩマッピング再生プロセス１３４は、リアルタイムマッピングプロセス１３２の代わりに、マッピングプロセス１３０を用いることができる。

説明した実施例は、システム論理１８のアーキテクチャーにおいてオブジェクトを利用する。しかしながら、代替的な実施例において、説明したオブジェクトのデータおよびプロセスは、オブジェクト自体を用いずに類似的データの類似的処理を実行する符号または論理に含まれ得る。

本発明に関する多くの実施例について説明してきた。それでもなお、本発明の真意および範囲から逸脱することなく様々な修正を行うことができる旨が理解されるだろう。従って、他の実施例もまた冒頭の請求項の範囲内にある。

対話型カラオケシステムのブロック図である。 パート符号化プロセスのフローチャートである。 マルチパートデータファイルのブロック図である。 チャンクのブロック図である。 パートチャンクのブロック図である。 クライアント装置およびこれに接続された装置のブロック図である。 ソフトウェア層のブロック図である。 オブジェクトクラスおよびインターフェースのブロック図である。 システムの動きのフローチャートである。 システム初期化のフローチャートである。 演奏オブジェクトのブロック図である。 実況的対話型再生プロセスのブロック図である。 アプリケーションウィンドウの図である。 周辺マネージャーオブジェクトのブロック図である。 仮想楽器マネージャーのブロック図である。 ＶＩマネージャーのロードプロセスのフローチャートである。 ファイル選択プロセスのフローチャートである。 パート選択プロセスのフローチャートである。 仮想楽器オブジェクトのブロック図である。 仮想楽器の引き継ぎの図である。 ユーザーエリアの第１図である。 ユーザーエリアの第２図である。 全体的伴奏のブロック図である。 全体的伴奏のロードプロセスのフローチャートである。 演奏タイマーインターフェースの図である。 トランスポートインターフェースの図である。 演奏プールインターフェースの図である。 マッピングプロセスのフローチャートである。 リアルタイムマッピングプロセスのフローチャートである。 ＭＩＤＩマッピング再生プロセスのフローチャートである。

符号の説明

１０ 対話型カラオケシステム
１２ クライアント装置
１４ マルチパートデータファイル
１５ 標準化演奏
１５ａ ソング
１５ｂ オーディオコンテンツ
１５ｃ パート
１６ ユーザー
１８ システム論理
２０ プレイヤー
２２ エンジンライブラリー
２６ 視覚表示装置
２７ オーディオ出力サブシステム
２８’ 入力装置
２８”音楽的入力装置
３０ サーバー
３０ａ 共有記憶装置

Claims (14)

1. 対話型再生のためのオーディオ演奏を符号化したデータ構造が、娯楽システム内のコンピュータによって読み取り可能に記録されている媒体であって、
   前記データ構造は、
   オーディオ演奏の対話型パートを前記娯楽システムがオーディオ演奏できるように符号化したデータの集合である仮想楽器プールと、
   オーディオ演奏の非対話型部分を前記娯楽システムが伴奏的にオーディオ演奏できるように符号化したデータの集合である全体的伴奏プールと
   を具備し、
   前記仮想楽器プールは、少なくとも一連のシンセサイザー制御データに符号化され、該シンセサイザー制御データ内の各データは、再生すべきオーディオコンテンツのディジタルサンプルを前記娯楽システムのオーディオ演奏中での該娯楽システムへの所定の入力に対応して指定されるものであり、
   前記全体的伴奏プールは、前記コンピュータに、前記対話型パートおよび前記非対話型部分が実行されるタイミングの基準となる信号を生成させるためのタイミング情報を含み、
   前記仮想楽器プールは、前記娯楽システムのオーディオ演奏中での該娯楽システムへの所定タイミングでの入力に対応して該娯楽システムに前記入力に応じた音を出力させるデータを有し、
   前記全体的伴奏プールは、前記娯楽システムのオーディオ演奏前に予め設定されている伴奏的な音を、該娯楽システムに出力させるデータを有し、
   前記データ構造は、
   前記仮想楽器プールのデータが前記娯楽システムによってオーディオ演奏されるときの再生速度を可変制御するデータを更に具備し、
   前記娯楽システムは、映像表示サブシステムを含み、かつ、前記データ構造は、前記対話型パートと関連づけられた一連の記憶されたタイミングキューを含み、
   前記仮想楽器プールは、ユーザーが仮想楽器を演奏することを補助するために、コンピュータに、前記タイミングキューの視覚表示を、映像表示システムを通して表示させる論理をさらに具備し、
   前記仮想楽器プールは、前記タイミングキューの視覚表示と、前記入力装置に実際に入力されたユーザー入力のタイミング表示とを、時間軸を示す所定方向に時間的または位置的に関連付けて前記映像表示システムを通して表示させる論理を有することを特徴とする媒体。
2. 前記シンセサイザー制御データは、ＭＩＤＩデータであることを特徴とする請求項１に記載の媒体。
3. 前記ディジタルサンプルは、ＭＰ３クリップであることを特徴とする請求項１に記載の媒体。
4. 前記全体的伴奏プールは、オーディオ演奏のオーディオコンテンツの非対話型パートを符号化することを特徴とする請求項１に記載の媒体。
5. 前記仮想楽器プールは、サウンドフォントの集合を含み、各々のサウンドフォントは、前記娯楽システムへの入力に応じた演奏音を出力するためのパラメータを供給することを特徴とする請求項１に記載の媒体。
6. 対話型再生のためのオーディオ演奏を符号化したデータ構造が、娯楽システム内のコンピュータによって読み取り可能に記録されている媒体であって、
   前記データ構造は、
   オーディオ演奏の非対話型パートを前記娯楽システムがオーディオ演奏できるように符号化したデータの集合である全体的伴奏プールと、
   オーディオ演奏の対話型パートを前記娯楽システムがオーディオ演奏できるように符号化したデータの集合である仮想楽器プールと
   を具備し、
   前記非対話型パートの一部分はシンセサイザー制御データとして符号化され、該非対話型パートの他の部分はオーディオコンテンツのディジタルサンプルとして符号化され、
   前記対話型パートは、符号化されたオーディオコンテンツを、少なくともシンセサイザー制御データ内に有し、該シンセサイザー制御データ内の各データは、合成すべき１つ以上の音符を指定し、または、再生すべきオーディオコンテンツのディジタルサンプルを指定し、
   前記仮想楽器プールは、前記娯楽システムのオーディオ演奏中での該娯楽システムへの所定タイミングでの入力に対応して該娯楽システムに前記入力に応じた音を出力させるデータを有し、
   前記全体的伴奏プールは、前記娯楽システムのオーディオ演奏前に予め設定されている伴奏的な音を、該娯楽システムに出力させるデータを有し、
   前記データ構造は、
   前記仮想楽器プールのデータが前記娯楽システムによってオーディオ演奏されるときの再生速度を可変制御するデータを更に具備し、
   前記娯楽システムは、映像表示サブシステムを含み、かつ、前記データ構造は、前記対話型パートと関連づけられた一連の記憶されたタイミングキューを含み、
   前記仮想楽器プールは、ユーザーが仮想楽器を演奏することを補助するために、コンピュータに、前記タイミングキューの視覚表示を、映像表示システムを通して表示させる論理をさらに具備し、
   前記仮想楽器プールは、前記タイミングキューの視覚表示と、前記入力装置に実際に入力されたユーザー入力のタイミング表示とを、時間軸を示す所定方向に時間的または位置的に関連付けて前記映像表示システムを通して表示させる論理を有することを特徴とする媒体。
7. 前記シンセサイザー制御データは、ＭＩＤＩデータであることを特徴とする請求項６に記載の媒体。
8. 前記ディジタルサンプルは、ＭＰ３クリップであることを特徴とする請求項６に記載の媒体。
9. 前記仮想楽器プールは、対話型パートのオーディオコンテンツと調和した入力が行われるように、表示装置上に催促を提示させるキューデータを含むことを特徴とする請求項６に記載の媒体。
10. コンピュータ読み取り可能な媒体上に記憶されたプログラムであって、
    前記プログラムは、娯楽システム内のコンピュータ上で作動するためのものであり、
    前記娯楽システムは、オーディオ出力サブシステムと、入力装置と、メモリとを含み、
    前記メモリは、音楽演奏データ構造を記憶し、
    前記音楽演奏データ構造は、音楽演奏の対話型部分と、音楽演奏の伴奏的な非対話型部分とを有し、
    前記プログラムは、
    仮想マネージャーオブジェクトと、
    全体的伴奏オブジェクトと
    を具備し、
    前記仮想マネージャーオブジェクトは、コンピュータに、メモリに記憶された音楽演奏データ構造を読み取らせ、かつ、コンピュータに、特定の仮想楽器の音を示すデータを前記音楽演奏データ構造内に識別可能に配置させる仮想オブジェクトを生成させ、
    前記仮想オブジェクトは、コンピュータに、入力装置に入力されたユーザー入力のタイミングに従って、前記特定に仮想楽器の音を示すデータを、前記音楽演奏の対話型部分に配置させ、かつ、コンピュータに、該配置された音楽演奏の対話型部分を、オーディオ出力サブシステムを通して演奏させ、
    前記全体的伴奏オブジェクトは、コンピュータに、音楽演奏の伴奏的な非対話型部分を、オーディオ出力システムを通して演奏させ、
    前記仮想オブジェクトは、前記娯楽システムのオーディオ演奏中における前記入力装置への所定タイミングでの入力に対応して該娯楽システムに前記入力に応じた音を出力させるプログラムであり、
    前記非対話型部分は、前記娯楽システムのオーディオ演奏前に予め設定されている伴奏的な音を、該娯楽システムに出力させるプログラムであり、
    前記仮想マネージャーオブジェクトおよび前記全体的伴奏オブジェクトは、前記仮想オブジェクトによる前記音楽演奏の再生速度を可変制御することを、コンピュータに実行させるプログラムを有し、
    前記娯楽システムは、映像表示サブシステムを含み、かつ、前記記憶された音楽演奏データ構造は、音楽演奏の対話型部分と関連づけられた一連の記憶されたタイミングキューを含み、
    前記仮想オブジェクトは、ユーザーが仮想楽器を演奏することを補助するために、コンピュータに、前記タイミングキューの視覚表示を、映像表示システムを通して表示させる論理をさらに具備し、
    前記仮想オブジェクトは、前記タイミングキューの視覚表示と、前記入力装置に実際に入力されたユーザー入力のタイミング表示とを、時間軸を示す所定方向に時間的または位置的に関連付けて前記映像表示システムを通して表示させる論理を有することを特徴とするプログラム。
11. 前記全体的伴奏オブジェクトは、コンピュータ上で前記非対話型部分および前記対話型部分が実行されるタイミングの基準となる信号であるマスタータイミング信号を、コンピュータに生成させるプログラムをさらに具備することを特徴とする請求項１０に記載のプログラム。
12. 前記娯楽システムは、複数の入力装置を含み、該複数の入力装置の１つは前記ユーザー入力が入力される入力装置であり、
    前記記憶された音楽演奏データ構造は、別個の楽器を各々が示す複数の別個の仮想楽器を識別し、
    前記仮想マネージャーオブジェクトは、コンピュータに、複数の前記仮想オブジェクトを生成させ、該複数の前記仮想オブジェクトの各々は、識別された複数の前記仮想楽器のうちの、対応する別個の仮想楽器の音を示すデータを使用して前記オーディオ出力サブシステムが演奏するように、コンピュータに実行させるプログラムであり、
    前記複数の仮想オブジェクトの各々は、前記コンピュータに、入力装置のうちの対応する１つからのユーザー入力タイミングに従って、前記特定に仮想楽器の音を示すデータを、音楽演奏の対話型部分の対応するパートに配置させ、かつ、前記コンピュータに、該配置された音楽演奏の対話型部分の対応するパートを、オーディオ出力サブシステムを通して演奏させることを特徴とする請求項１０に記載のプログラム。
13. 前記記憶された音楽演奏データ構造は、音楽演奏の非対話型部分の別個のパートを各々が示す複数のディジタルクリップと、一連のトリガー時点とを含み、該トリガー時点の各々は、タイミング情報を示し、かつ、前記ディジタルクリップのうちのどの１つを該タイミング情報内の識別された時間に演奏すべきか識別し、
    前記全体的伴奏オブジェクトは、娯楽システムに、複数のディジタルクリップのうちの識別された１つを、記憶された一連のトリガー時点により識別された通りの適切な時間に、オーディオ出力サブシステムを通して演奏させる論理を具備することを特徴とする請求項１０に記載のプログラム。
14. 前記オーディオ出力サブシステムは、シンセサイザーを含み、かつ、前記記憶された音楽演奏データ構造は、サウンドフォントを含み、
    前記伴奏オブジェクトは、オーディオ出力サブシステムの出力特性を制御するために、コンピュータに、記憶された音楽演奏データ構造からサウンドフォントを検索させる論理にして、かつ、コンピュータに、サウンドフォントをシンセサイザー内にロードさせる論理をさらに具備することを特徴とする請求項１０に記載のプログラム。

Images