(57)【要約】      （修正有）【課題】演奏者に対しコール＆レスポンスに関する充実した練習環境を与え得る、或いは、演奏者が擬似的なコール＆レスポンスを楽しむことのできる演奏システムを提供する。【解決手段】演奏システムは、演奏内容に対応付けて演奏データを記憶する記憶手段と、前記記憶された演奏データの中から第１の演奏データを決定する第１決定手段と、前記決定された第１の演奏データに対応する第１の演奏を再生する再生手段と、前記記憶された演奏データの中から前記第１の演奏又は前記第１の演奏に呼応するユーザの演奏に基づいて第２の演奏データを決定する第２決定手段とを具備し、前記再生手段は、前記ユーザの演奏の終了後に、前記決定された第２の演奏データに対応する第２の演奏を再生する。【選択図】図９
2015055649.tif 000002
【特許請求の範囲】
【請求項１】
時間軸上で離散的に演奏を再生する演奏システムであって、
演奏内容に対応付けて演奏データを記憶する記憶手段と、
前記記憶された演奏データの中から第１の演奏データを決定する第１決定手段と、
前記決定された第１の演奏データに対応する第１の演奏を再生する再生手段と、
前記記憶された演奏データの中から前記第１の演奏又は前記第１の演奏に呼応するユーザの演奏に基づいて第２の演奏データを決定する第２決定手段と
を具備し、
前記再生手段は、前記ユーザの演奏の終了後に、前記決定された第２の演奏データに対応する第２の演奏を再生する
ことを特徴とする演奏システム。
【請求項２】
前記第１決定手段は、前記第１の演奏データの初期値を前記ユーザの意思に基づいて決定する
ことを特徴とする請求項１に記載の演奏システム。
【請求項３】
前記第２決定手段は、前記記憶された演奏データの中から、前記第１の演奏の演奏内容と類似又は関連する演奏内容が対応付けられた演奏データを前記第２の演奏データとして決定する
ことを特徴とする請求項１又は２に記載の演奏システム。
【請求項４】
前記ユーザの演奏の演奏内容を解析する解析手段を具備し、
前記第２決定手段は、前記記憶された演奏データの中から、前記解析されたユーザの演奏の演奏内容と類似又は関連する演奏内容が対応付けられた演奏データを前記第２の演奏データとして決定する
ことを特徴とする請求項１から３のいずれか一項に記載の演奏システム。
【請求項５】
前記ユーザの演奏の演奏内容を解析する解析手段と、
前記ユーザの演奏に係る演奏データを前記解析された演奏内容に対応付けて前記記憶手段に記憶させる記憶制御手段と
を具備する
ことを特徴とする請求項１から４のいずれか一項に記載の演奏システム。
【請求項６】
前記演奏内容は、メロディ、リズム、コード及びスケールのうち少なくとも一つを含む
ことを特徴とする請求項１から５のいずれか一項に記載の演奏システム。
【請求項７】
前記演奏内容は複数種類設定されており、
前記第２決定手段は、前記複数種類設定された演奏内容の各々について前記第２の演奏データの候補を選択し、該選択された候補の中から前記第２の演奏データを決定する
ことを特徴とする請求項１から６のいずれか一項に記載の演奏システム。
【請求項８】
演奏内容に対応付けて演奏データを記憶する記憶手段を具備する演奏システムにおいて、時間軸上で離散的に演奏を再生する演奏再生方法であって、
前記記憶された演奏データの中から第１の演奏データを決定する第１決定工程と、
前記決定された第１の演奏データに対応する第１の演奏を再生する第１再生工程と、
前記記憶された演奏データの中から前記第１の演奏又は前記第１の演奏に呼応するユーザの演奏に基づいて第２の演奏データを決定する第２決定工程と、
前記ユーザの演奏の終了後に、前記決定された第２の演奏データに対応する第２の演奏を再生する第２再生工程と
を具備することを特徴とする演奏再生方法。
【請求項９】
ネットワークに収容され、演奏内容に対応付けて演奏データを記憶する記憶手段と、前記記憶された演奏データの中から第１の演奏データを決定する第１決定手段と、前記記憶された演奏データの中から前記第１の演奏又は前記第１の演奏に呼応するユーザの演奏に基づいて第２の演奏データを決定する第２決定手段と、前記ネットワークを介して前記決定された第１及び第２の演奏データを配信する配信手段と共に時間軸上で離散的に演奏を再生する演奏システムを構成する端末装置であって、
前記配信された第１の演奏データに対応する第１の演奏を再生すると共に、前記ユーザの演奏の終了後に、前記配信された第２の演奏データに対応する第２の演奏を再生する再生手段を具備する
ことを特徴とする端末装置。
【請求項１０】
ネットワークに収容され、演奏内容に対応付けて演奏データを記憶する記憶手段と、第１の演奏データに対応する第１の演奏を再生し、且つ前記第１の演奏に呼応するユーザの演奏の終了後に第２の演奏データに対応する第２の演奏を再生する再生手段を備えた端末装置と共に、時間軸上で離散的に演奏を再生する演奏システムを構成するサーバ装置であって、
前記記憶された演奏データの中から前記第１の演奏データを決定する第１決定手段と、
前記記憶された演奏データの中から前記第１の演奏又は前記ユーザの演奏に基づいて第２の演奏データを決定する第２決定手段と、
前記端末装置に対し、前記ネットワークを介して前記決定された第１及び第２の演奏データを配信する配信手段と
を具備することを特徴とするサーバ装置。
【請求項１１】
コンピュータ装置を、請求項１乃至７のいずれか一項に記載の演奏システムにおける第１決定手段及び第２決定手段として機能させることを特徴とするコンピュータプログラム。
【請求項１２】
請求項１１に記載のコンピュータプログラムが記録されることを特徴とする記録媒体。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、演奏を再生する演奏システムの技術分野に関する。
【背景技術】
【０００２】
この種の演奏システムに関連するものとして、例えば特許文献１に開示された電子楽器がある。
【０００３】
特許文献１に開示された電子楽器によれば、伴奏情報を記憶しておき、演奏者がソロ演奏又は即興演奏を行うときに、この記憶された伴奏情報により伴奏演奏が再生される。このため、演奏者がソロ演奏又は即興演奏に集中することができるとされている。また、必要に応じてこの伴奏演奏を繰り返すこともできるため、予めシーケンサに伴奏部分を録音しておく場合と異なり、曲の構成が自由に変更できるとされている。
【０００４】
尚、即興演奏に関連するものとして、アドリブ演奏に対する採点を可能にして自由度のある演奏を楽しむことのできるゲーム機も提案されている（例えば、特許文献２参照）。
【先行技術文献】
【特許文献】
【０００５】
【特許文献１】特開２００１−０９２４４９号公報
【特許文献２】特開２００２−０１８１２３号公報
【発明の概要】
【発明が解決しようとする課題】
【０００６】
近年、ストリーミング再生中の演奏に同期して行われる演奏を録音し、ネットワークを介してその演奏データをサーバにアップロードすることのできる演奏システムが提案されている。この演奏システムによれば、当該サーバにアクセス可能な不特定多数の利用者が、サーバにアップロードされた演奏データを自由に利用することができるため、この不特定多数の利用者は、ストリーミング再生される特定の演奏パートに同期して演奏を行うことにより、擬似的なセッションを楽しむことができる。
【０００７】
ところで、人間同士で行われる実際の演奏セッションにおいては、コール＆レスポンス（以下、適宜「Ｃ／Ｒ」と略表現する）と称される一種の即興的演奏コミュニケーションが行われることがある。これは、一方の演奏者の呼び掛け演奏（コール）に対して、他方の演奏者が応答演奏（レスポンス）を返すことにより成立する。
【０００８】
このＣ／Ｒは、演奏者が複数存在することが前提であり、上述した擬似的な演奏セッションを実現し得る演奏システムを利用しても、演奏者がＣ／Ｒに関する演奏技量を磨くことは困難である。例えば、上記特許文献１に開示される技術を適用すれば、予め定められたスケジュールに従ってコールを再生したり、単一のコールを繰り返し再生したりすることは可能である。しかしながら、このように演奏者が予めコールの内容を把握できる、又は、単一のコールが繰り返されるシステム構成は、Ｃ／Ｒに関する演奏者の技量向上には殆ど寄与しない。
【０００９】
ここで、コールに対するレスポンス及びレスポンスに対するコールには、細かい決まり事はない。しかしながら、即興的になされる演奏者同士のコミュニケーションである以上、現実的にはコールとレスポンスとの間には音楽的な繋がりが必要である。従って、例えば予め定められたコールが繰り返されることを嫌って、音楽的に全く関連性の無い演奏をその都度コールとしてランダムに再生したところで、やはりＣ／Ｒに関する演奏者の技量向上には寄与しない。
【００１０】
即ち、従来の演奏システムには、演奏者に対しＣ／Ｒに関する十分な練習環境を与えることも、演奏者が充実感あるＣ／Ｒを擬似的に楽しむことも困難であるという技術的な問題点がある。
【００１１】
本発明は、係る事情に鑑みてなされたものであり、演奏者に対しコール＆レスポンスに関する充実した練習環境を与え得る、或いは、演奏者が擬似的なコール＆レスポンスを楽しむことのできる演奏システムを提供することを少なくとも一つの課題とする。
【課題を解決するための手段】
【００１２】
上述した課題を解決するため、請求項１に記載の演奏システムは、時間軸上で離散的に演奏を再生する演奏システムであって、演奏内容に対応付けて演奏データを記憶する記憶手段と、前記記憶された演奏データの中から第１の演奏データを決定する第１決定手段と、前記決定された第１の演奏データに対応する第１の演奏を再生する再生手段と、前記記憶された演奏データの中から前記第１の演奏又は前記第１の演奏に呼応するユーザの演奏に基づいて第２の演奏データを決定する第２決定手段とを具備し、前記再生手段は、前記ユーザの演奏の終了後に、前記決定された第２の演奏データに対応する第２の演奏を再生することを特徴とする。
【００１３】
上述した課題を解決するため、請求項８に記載の演奏再生方法は、演奏内容に対応付けて演奏データを記憶する記憶手段を具備する演奏システムにおいて、時間軸上で離散的に演奏を再生する演奏再生方法であって、前記記憶された演奏データの中から第１の演奏データを決定する第１決定工程と、前記決定された第１の演奏データに対応する第１の演奏を再生する第１再生工程と、前記記憶された演奏データの中から前記第１の演奏又は前記第１の演奏に呼応するユーザの演奏に基づいて第２の演奏データを決定する第２決定工程と、前記ユーザの演奏の終了後に、前記決定された第２の演奏データに対応する第２の演奏を再生する第２再生工程とを具備することを特徴とする。
【００１４】
上述した課題を解決するため、請求項９に記載の端末装置は、ネットワークに収容され、演奏内容に対応付けて演奏データを記憶する記憶手段と、前記記憶された演奏データの中から第１の演奏データを決定する第１決定手段と、前記記憶された演奏データの中から前記第１の演奏又は前記第１の演奏に呼応するユーザの演奏に基づいて第２の演奏データを決定する第２決定手段と、前記ネットワークを介して前記決定された第１及び第２の演奏データを配信する配信手段と共に時間軸上で離散的に演奏を再生する演奏システムを構成する端末装置であって、前記配信された第１の演奏データに対応する第１の演奏を再生すると共に、前記ユーザの演奏の終了後に、前記配信された第２の演奏データに対応する第２の演奏を再生する再生手段を具備することを特徴とする。
【００１５】
上述した課題を解決するため、請求項１０に記載のサーバ装置は、ネットワークに収容され、演奏内容に対応付けて演奏データを記憶する記憶手段と、第１の演奏データに対応する第１の演奏を再生し、且つ前記第１の演奏に呼応するユーザの演奏の終了後に第２の演奏データに対応する第２の演奏を再生する再生手段を備えた端末装置と共に、時間軸上で離散的に演奏を再生する演奏システムを構成するサーバ装置であって、前記記憶された演奏データの中から前記第１の演奏データを決定する第１決定手段と、前記記憶された演奏データの中から前記第１の演奏又は前記ユーザの演奏に基づいて第２の演奏データを決定する第２決定手段と、前記端末装置に対し、前記ネットワークを介して前記決定された第１及び第２の演奏データを配信する配信手段とを具備することを特徴とする。
【００１６】
上述した課題を解決するため、請求項１１に記載のコンピュータプログラムは、コンピュータ装置を、請求項１乃至７のいずれか一項に記載の演奏システムにおける第１決定手段及び第２決定手段として機能させることを特徴とする。
【００１７】
上述した課題を解決するため、請求項１２に記載の記録媒体は、請求項１１に記載のコンピュータプログラムが記録されることを特徴とする。
【図面の簡単な説明】
【００１８】
【図１】第１実施例に係る演奏システムの概念を説明する図である。
【図２】図１の演奏システムにおけるサーバ装置のブロック図である。
【図３】図１の演奏システムにおける端末装置のブロック図である。
【図４】図１のサーバ装置において演奏データを管理するデータベースの概念図である。
【図５】図１の演奏システムにおける演奏セッションの概念図である。
【図６】図５の演奏セッションの進行の様子を説明するタイミングチャートである。
【図７】図１のサーバ装置においてコールデータを管理するデータベースの概念図である。
【図８】Ｃ／Ｒモードにおけるウェブサイトの画面を例示する図である。
【図９】Ｃ／Ｒモードの進行の様子を説明する図である。
【図１０】Ｃ／Ｒモードの動作フローである。
【図１１】第２実施例に係るＣ／Ｒモードの動作フローである。
【図１２】第２実施例に係るＣ／Ｒモードの進行の様子を説明する図である。
【図１３】第２応用例に係るサーバ側遅延補償制御のフローチャートである。
【図１４】第２応用例に係る端末側遅延補償制御のフローチャートである。
【発明を実施するための形態】
【００１９】
＜演奏システムの実施形態＞
【００２０】
本発明の演奏システムに係る実施形態は、時間軸上で離散的に演奏を再生する演奏システムであって、演奏内容に対応付けて演奏データを記憶する記憶手段と、前記記憶された演奏データの中から第１の演奏データを決定する第１決定手段と、前記決定された第１の演奏データに対応する第１の演奏を再生する再生手段と、前記記憶された演奏データの中から前記第１の演奏又は前記第１の演奏に呼応するユーザの演奏に基づいて第２の演奏データを決定する第２決定手段とを具備し、前記再生手段は、前記ユーザの演奏の終了後に、前記決定された第２の演奏データに対応する第２の演奏を再生する（請求項１）。
【００２１】
演奏システムに係る実施形態によれば、あるタイミングで再生される、コールとしての第１の演奏に対し、ユーザがレスポンスとしての演奏を行った後に、コールとしての第２の演奏が再生される。尚、この第１の演奏及び第２の演奏は、一つのレスポンスを挟んで時間軸上で隣接する二つのコールを区別するものであって、ある特定のコールを意味しない。
【００２２】
ここで、演奏システムに係る実施形態によれば、第２の演奏に係る演奏データが、第１の演奏又は第１の演奏に呼応するユーザの演奏（即ち、レスポンス）に基づいて決定される。第１及び第２の演奏データを含む演奏データは、予め演奏内容に対応付けられており、第２決定手段は、直前のコール（第１の演奏）又はレスポンスと音楽的な繋がりを有するコール（第２の演奏）をユーザに提示することができる。
【００２３】
Ｃ／Ｒは、即興的演奏コミュニケーションであるところ厳密な規則はないが、一般的には、例えば、全く同じ演奏をレスポンスとして返す、コールのリズムを真似る、コールとスケールを合わせる、或いは、コールの音程と音楽的なしり取りを行う等、コールとレスポンスとの間には音楽的な繋がりが必要である。演奏システムに係る実施形態によれば、時間軸上で離散的に再生されるコール相互間に音楽的繋がりを持たせることができる。従って、演奏システムに係る実施形態により提供される擬似的なＣ／Ｒ環境を、実際に人間同士が行うＣ／Ｒに近付けることができ、ユーザに対しＣ／Ｒに関する充実した練習環境を与えることができる。また、ユーザは擬似的なＣ／Ｒを楽しむことができる。
【００２４】
尚、実施形態に係る演奏システムは、例えばサーバ装置及び端末装置により構築される、例えば商業的サービスを提供するシステムであってもよい。また、このように実施形態に係る演奏システムが複数のノードにより構成される場合においては、これら複数のノードは、例えばインターネット等の広域ネットワークとしてのネットワークに収容されていてもよい。
【００２５】
また、この場合、サーバ装置は、所定のサービスを提供する事業者が所有するサーバであってもよく、例えば利用者と然るべき契約を締結した上で、当該利用者に限定して保有する演奏データを配信する構成とされていてもよい。このような演奏データの配信は、より具体的には、ネットワーク上に、サーバ装置とユーザとのインターフェイスとして構築されるウェブサイトやホームページ等を通じてなされてもよい。
【００２６】
本発明の演奏システムに係る実施形態の一の態様では、前記第１決定手段は、前記第１の演奏データの初期値を前記ユーザの意思に基づいて決定する（請求項２）。
【００２７】
この態様によれば、第１の演奏データの初期値（即ち、最初のコール）が、ユーザの意思に基づいて決定される。従って、ユーザの演奏技量、演奏パート、所望する楽曲等に応じた適切なＣ／Ｒを実現することができる。
【００２８】
尚、このユーザの意思に基づいた初期コールの提示は、ユーザの意思を直接的に汲み取る形でなされてもよいし、間接的に汲み取る形でなされてもよい。前者は、例えば、コールに係る演奏者、楽曲、テンポ、演奏パート等をユーザが指定するものを含み、後者は、例えば、ユーザがＣ／Ｒの伴奏として指定した楽曲、テンポ、演奏パート等を参照して適切なコールを選択するものを含む。
【００２９】
本発明の演奏システムに係る実施形態の他の態様では、前記第２決定手段は、前記記憶された演奏データの中から、前記第１の演奏の演奏内容と類似又は関連する演奏内容が対応付けられた演奏データを前記第２の演奏データとして決定する（請求項３）。
【００３０】
この態様によれば、第１の演奏と演奏内容が類似又は関連する演奏が第２の演奏として提示されるため、ユーザに対して一貫したＣ／Ｒ環境を提供することができる。また、記憶される演奏データの数が多い場合、演奏内容が類似又は関連する演奏の数量も増えるため、ある程度絞られた候補の中からランダムに第２の演奏データを選択することも可能である。この場合、音楽的な繋がりが担保された一貫したＣ／Ｒを提供しつつ、変化に富んだＣ／Ｒを実現することができる。
【００３１】
本発明の演奏システムに係る実施形態の他の態様では、前記ユーザの演奏の演奏内容を解析する解析手段を具備し、前記第２決定手段は、前記記憶された演奏データの中から、前記解析されたユーザの演奏の演奏内容と類似又は関連する演奏内容が対応付けられた演奏データを前記第２の演奏データとして決定する（請求項４）。
【００３２】
この態様によれば、解析手段によりユーザの演奏（即ち、レスポンス）の内容が解析され、解析されたユーザの演奏の演奏内容と演奏内容が類似又は関連する演奏データが第２の演奏データとして決定される。このため、レスポンスに対する適切な第２の演奏（コール）を提供することができ、高品質なＣ／Ｒを実現することができる。
【００３３】
解析手段による演奏内容の解析は、好適な一形態として、例えば、演奏の物理的な解析と音楽理論的な解析とを含み得る。前者は、メロディやリズム、音量、或いはアクセントの位置等、物理的特性を解析するものであり、後者は、コードの進行パターンやスケール等を解析するものである。このような解析手法としては、公知のものを適用することができる。
【００３４】
本発明の演奏システムに係る実施形態の他の態様では、前記ユーザの演奏の演奏内容を解析する解析手段と、前記ユーザの演奏に係る演奏データを前記解析された演奏内容に対応付けて前記記憶手段に記憶させる記憶制御手段とを具備する（請求項５）。
【００３５】
この態様によれば、レスポンスとしてユーザの演奏に係る演奏データが、解析された演奏内容と対応付けられ、記憶手段に記憶される。即ち、レスポンスの演奏データを、コールの演奏データの候補として利用することができる。従って、演奏システムにより提供されるＣ／Ｒ環境をより充実させることができる。
【００３６】
本発明の演奏システムに係る実施形態の態様では、前記演奏内容は、メロディ、リズム、コード及びスケールのうち少なくとも一つを含む（請求項６）。
【００３７】
この態様によれば、メロディ、リズム、コード及びスケールの複数の項目のうち少なくとも一つ、望ましくは複数の項目が演奏データに対応付けられる。或いは、解析手段による解析項目として利用される。従って、第２決定手段により決定される第２の演奏データ（コールの演奏データ）を適切に決定することができる。
【００３８】
尚、演奏内容としての「コード」とは、頻出コードやコードの進行パターン等、コードに関連する各種の情報を含む。
【００３９】
本発明の演奏システムに係る実施形態の他の態様では、前記演奏内容は複数種類設定されており、前記第２決定手段は、前記複数種類設定された演奏内容の各々について前記第２の演奏データの候補を選択し、該選択された候補の中から前記第２の演奏データを決定する（請求項７）。
【００４０】
この態様によれば、複数種類の演奏内容について、第２の演奏データの候補が選択され、この複数の候補の中から第２の演奏データが決定される。従って、提示されるコールに対し、音楽的一貫性と共にランダム性を付与することができ、高品質なＣ／Ｒ環境が実現される。
【００４１】
＜演奏再生方法の実施形態＞
【００４２】
本発明の演奏再生方法に係る実施形態は、演奏内容に対応付けて演奏データを記憶する記憶手段を具備する演奏システムにおいて、時間軸上で離散的に演奏を再生する演奏再生方法であって、前記記憶された演奏データの中から第１の演奏データを決定する第１決定工程と、前記決定された第１の演奏データに対応する第１の演奏を再生する第１再生工程と、前記記憶された演奏データの中から前記第１の演奏又は前記第１の演奏に呼応するユーザの演奏に基づいて第２の演奏データを決定する第２決定工程と、前記ユーザの演奏の終了後に、前記決定された第２の演奏データに対応する第２の演奏を再生する第２再生工程とを具備する。
【００４３】
本発明の演奏再生方法に係る実施形態によれば、上述した本発明の演奏システムに係る実施形態の各手段と同等な作用を呈する各工程により、本発明の演奏システムに係る実施形態と同様、ユーザに対しＣ／Ｒに関する充実した練習環境を与えることができる。また、ユーザは擬似的なＣ／Ｒを楽しむことができる。
【００４４】
＜端末装置の実施形態＞
【００４５】
本発明の端末装置に係る実施形態は、ネットワークに収容され、演奏内容に対応付けて演奏データを記憶する記憶手段と、前記記憶された演奏データの中から第１の演奏データを決定する第１決定手段と、前記記憶された演奏データの中から前記第１の演奏又は前記第１の演奏に呼応するユーザの演奏に基づいて第２の演奏データを決定する第２決定手段と、前記ネットワークを介して前記決定された第１及び第２の演奏データを配信する配信手段と共に時間軸上で離散的に演奏を再生する演奏システムを構成する端末装置であって、前記配信された第１の演奏データに対応する第１の演奏を再生すると共に、前記ユーザの演奏の終了後に、前記配信された第２の演奏データに対応する第２の演奏を再生する再生手段を具備する（請求項９）。
【００４６】
本発明の端末装置に係る実施形態によれば、上述した本発明の演奏システムに係る実施形態における再生手段の作用により、ユーザに対しＣ／Ｒに関する充実した練習環境を与えることができる。また、ユーザは擬似的なＣ／Ｒを楽しむことができる。
【００４７】
＜サーバ装置の実施形態＞
【００４８】
本発明のサーバ装置に係る実施形態は、ネットワークに収容され、演奏内容に対応付けて演奏データを記憶する記憶手段と、第１の演奏データに対応する第１の演奏を再生し、且つ前記第１の演奏に呼応するユーザの演奏の終了後に第２の演奏データに対応する第２の演奏を再生する再生手段を備えた端末装置と共に、時間軸上で離散的に演奏を再生する演奏システムを構成するサーバ装置であって、前記記憶された演奏データの中から前記第１の演奏データを決定する第１決定手段と、前記記憶された演奏データの中から前記第１の演奏又は前記ユーザの演奏に基づいて第２の演奏データを決定する第２決定手段と、前記端末装置に対し、前記ネットワークを介して前記決定された第１及び第２の演奏データを配信する配信手段とを具備する（請求項１０）。
【００４９】
本発明のサーバ装置に係る実施形態によれば、上述した本発明の演奏システムに係る実施形態における第１決定手段及び第２決定手段の作用により、ユーザに対しＣ／Ｒに関する充実した練習環境を与えることができる。また、ユーザは擬似的なＣ／Ｒを楽しむことができる。
【００５０】
尚、本発明のサーバ装置に係る実施形態は、第１及び第２決定手段に加えて、記憶手段を更に備えていてもよい。
【００５１】
＜コンピュータプログラムの実施形態＞
【００５２】
本発明のコンピュータプログラムに係る実施形態は、コンピュータ装置を、本発明の演奏システムに係る実施形態における第１決定手段及び第２決定手段として機能させる（請求項１１）。
【００５３】
本発明のコンピュータプログラムに係る実施形態によれば、当該コンピュータプログラムを格納するＲＯＭ、ＣＤ−ＲＯＭ、ＤＶＤ−ＲＯＭ、ハードディスク等の記録媒体或いはＵＳＢ（Universal Serial Bus）メモリ等コンピュータシステムに着脱可能な固体型記憶装置から、当該コンピュータプログラムをコンピュータシステムに読み込んで実行させれば、或いは、当該コンピュータプログラムを、例えば、通信手段等を介してコンピュータシステムにダウンロードさせた後に実行させれば、上述した本発明の演奏システムに係る実施形態における第１決定手段及び第２決定手段を比較的簡単に実現できる。
【００５４】
尚、上述した本発明の演奏システムに係る実施形態における各種態様に対応して、本発明のコンピュータプログラムに係る実施形態も各種態様を採ることが可能である。
【００５５】
＜記録媒体の実施形態＞
【００５６】
本発明の記録媒体に係る実施形態は、本発明のコンピュータプログラムに係る実施形態が記録される（請求項１３）。
【００５７】
本発明の記録媒体に係る実施形態によれば、コンピュータシステムに装着又は接続することによって、或いはコンピュータシステムに備わる又は接続された然るべき読取装置に挿入することによって、記録している本発明のコンピュータプログラムに係る実施形態を、コンピュータシステムに読み込ませて実行させることができ、上述した本発明の演奏システムに係る実施形態における第１決定手段及び第２決定手段を比較的簡単に実現できる。
【００５８】
本発明のこのような作用及び他の利得は次に説明する実施例から明らかにされる。
【実施例】
【００５９】
以下、適宜図面を参照し、本発明の実施例について説明する。
【００６０】
＜第１実施例＞
先ず、第１実施例として演奏システム１０について説明する。
【００６１】
＜実施例の構成＞
始めに、図１を参照し、演奏システム１０の構成について説明する。ここに、図１は、演奏システム１０の概念を説明する図である。
【００６２】
図１において、演奏システム１０は、サーバ１００及び端末２００が、共にネットワーク１１に収容されてなるシステムである。ネットワーク１１は、インターネット等の広域ネットワーク及び当該広域ネットワークにアクセスするための、ＬＡＮ（Local Area Network）等の狭域ネットワークから構成される。
【００６３】
演奏システム１０は、演奏コミュニケーションサービスを提供するシステムであり、例えばサーバ１００を保有する不図示の事業者との間に所定の利用契約を締結したユーザが利用可能な構成となっている。尚、図１では、三名のユーザＵ１、Ｕ２及びＵ３が例示されるが、これは単なる一例である。また、図１では、ユーザＵ２及びＵ３が保有する端末２００の図示は省略されている。
【００６４】
演奏システム１０では、例えば、サーバ１００に登録されている演奏データの中からユーザに要求された演奏データが配信され、端末２００により再生される。或いは、サーバ１００に登録されている演奏データの中から、特定のユーザにとって適切であると推定される演奏データが配信され、端末２００により再生される。
【００６５】
演奏システム１０では、ユーザが、例えば自身が保有する端末２００を介して演奏を録音することによって得られた演奏データを、ユーザの要求に応じて適宜サーバ１００にアップロードすることも出来る。アップロードされた演奏データは、この演奏データをアップロードしたユーザ以外のユーザ（即ち、他のユーザ）も自由に利用することができる。従って、ユーザは、例えば、自身が所望する楽曲について、自身が所望する演奏パートで、自身が所望する演奏セッションを擬似的に構築し、当該演奏セッションに一演奏者として参加することができる。
【００６６】
演奏システム１０では、ネットワーク１１上に構築されたウェブサイトＷＳを介して、上記を含む各種のサービスが提供される。このウェブサイトＷＳにより、ユーザは、所望する楽曲、演奏パート或いはセッションの検索やその配信要求を簡便に行うことができる。また、これら配信された楽曲、演奏パート或いはセッションに同期して行われた演奏を録音し、サーバ１００にアップロードすることができる。
【００６７】
図１において、サーバ１００は、例えば演奏システム１０を運営する事業者が保有する、本発明に係る「サーバ装置」の一例たるコンピュータ装置である。サーバ１００は、上述したウェブサイトＷＳを管理している。ウェブサイトＷＳは、ユーザとサーバ１００とのインターフェイスとなるウェブサイトであり、ユーザが端末２００（本発明に係る「端末装置」の一例）を介して自由にアクセスすることができる。
【００６８】
次に、図２を参照し、サーバ１００の構成について説明する。ここに、図２は、サーバ１００のブロック図である。尚、同図において、図１と重複する箇所には同一の符号を付してその説明を適宜省略することとする。
【００６９】
図２において、サーバ１００は、制御装置１１０、記憶装置１２０、送信バッファ１３０及び通信インターフェイス（Ｉ／Ｆ）１４０を備える。
【００７０】
制御装置１１０は、サーバ１００の動作を制御する装置であり、制御部１１１、ＷＥＢ管理部１１２、解析部１１３及びコール選択部１１４を備える。
【００７１】
制御部１１１は、ＣＰＵ（Central Processing Unit）、ＲＯＭ（Read Only Memory）及びＲＡＭ（Random Access Memory）等を含む演算処理装置であり、サーバ１００の動作を全体的に制御する。ＷＥＢ管理部１１２、解析部１１３及びコール選択部１１４は、制御部１１１がＲＯＭに格納された制御プログラムを実行することにより機能する構成となっている。この制御プログラムは、本発明に係る「コンピュータプログラム」の一例である。従って、このＲＯＭは本発明に係る「記録媒体」の一例である。
【００７２】
ＷＥＢ管理部１１２は、上述したウェブサイトＷＳを管理する。具体的には、ＷＥＢ管理部１１２は、ウェブサイトＷＳの更新処理やメンテナンス処理を実行することができる。また、ＷＥＢ管理部１１２は、ユーザがウェブサイトＷＳを介して行った要求に応じた処理を実行する。具体的には、ＷＥＢ管理部１１２は、ユーザからウェブサイトＷＳを通じてなされる、アクセス要求、演奏のダウンロード要求、演奏のアップロード要求等各種の要求に対し、これら要求に応じた処理（例えば、認証処理、ダウンロード処理及びアップロード処理等）を実行することができる。
【００７３】
解析部１１３は、ユーザがアップロードした演奏に関する演奏内容を解析する。本実施例において、この演奏内容には、メロディ、リズム、テンポ、コード、スケール等の情報が含まれる。これらのうちメロディ、リズム及びテンポは演奏の物理的特性に属し、コードやスケールは演奏の音楽理論的特性に属する。このような演奏内容の解析には、公知の手法を適用可能である。解析部１１３は、本発明に係る「解析手段」の一例である。
【００７４】
尚、演奏の物理的特性としては、上記メロディやリズムの他に、音量やアクセントの位置等が含まれていてもよい。
【００７５】
コール選択部１１４は、ウェブサイトＷＳを通じて後述するコール＆レスポンスモード（以下、適宜「Ｃ／Ｒモード」とする）が選択された場合において、ユーザに提示すべきコールに相当する演奏を決定する。コール選択部１１４は、本発明に係る「第１決定手段」及び「第２決定手段」の一例である。
【００７６】
記憶装置１２０は、例えばＨＤ（Hard Disk）等の比較的大容量の記録媒体を備えた記憶装置である。記憶装置１２０には、ユーザがアップロードした演奏に関する演奏データを格納及び管理するデータベース１２１及び１２２が構築されている。データベース１２１及び１２２については後述する。
【００７７】
送信バッファ１３０は、演奏データを配信する際のバッファとして機能する揮発性記憶装置である。送信バッファ１３０のバッファ容量は、演奏データのデータサイズに対して十分に大きいものとなっている。
【００７８】
通信Ｉ／Ｆ１４０は、サーバ１００と端末２００との間のデータ通信を実現するための、所定の通信規格に準じたインターフェイスである。
【００７９】
次に、図３を参照し、端末２００の構成について説明する。ここに、図３は、端末２００のブロック図である。尚、同図において、図１と重複する箇所には同一の符号を付してその説明を適宜省略することとする。
【００８０】
図３において、端末２００は、制御装置２１０、受信バッファ２２０、通信インターフェイス（Ｉ／Ｆ）２３０及び表示部２４０を備える。
【００８１】
制御装置２１０は、端末２００の動作を制御する装置であり、制御部２１１、再生制御部２１２、録音処理部２１３、解析部２１４及び表示制御部２１５を備える。
【００８２】
制御部２１１は、ＣＰＵ、ＲＯＭ及びＲＡＭ等を含む演算処理装置であり、端末２００の動作を全体的に制御する。再生制御部２１２、録音処理部２１３、解析部２１４及び表示制御部２１５は、制御部２１１がＲＯＭに格納された制御プログラムを実行することにより機能する構成となっている。この制御プログラムは、本発明に係る「コンピュータプログラム」の他の一例である。従って、このＲＯＭは本発明に係る「記録媒体」の他の一例である。
【００８３】
また、制御部２１１は、ユーザが図示せぬ操作装置（例えば、キーボードやタッチパネル装置）を介してコマンドを入力した場合、この入力されたコマンドに対応する処理を実行する。具体的には、制御部２１１は、ユーザにより録音操作がなされた場合には演奏の録音が開始されるように録音処理部２１３を制御し、ユーザにより再生操作がなされた場合には配信された演奏データに基づいた演奏の再生が開始されるように再生制御部２１２及び表示制御部２１５を制御する。
【００８４】
再生制御部２１２は、サーバ１００から送信される演奏データに基づいて演奏をストリーミング再生する。再生制御部２１２は、受信バッファ２２０に所定量の演奏データが蓄積された段階で、順次この蓄積された演奏データを読み出して再生する。この再生された演奏は、端末２００に外付けされるスピーカ３００から音声として出力される。
【００８５】
尚、本実施例に係る端末２００は、パーソナルコンピュータ等のコンピュータ装置であり、スピーカ３００が外付けされる構成としているが、端末２００が、このような用途に特化した装置である場合等には、端末２００がスピーカを内蔵していてもよい。
【００８６】
録音処理部２１３は、再生される演奏に同期してユーザが行った演奏を、マイクロフォン４００を介して音声信号として取り込むと共に演奏データに変換することによって録音する。録音処理部２１３は、演奏者の演奏を、上述した演奏データと同等のデータ形式で録音し、演奏データを生成する。
【００８７】
解析部２１４は、ユーザがアップロードした演奏に関する演奏内容を解析する。本実施例において、この演奏内容には、メロディ、リズム、テンポ、コード、スケール等の情報が含まれる。これらのうちメロディ、リズム及びテンポは演奏の物理的特性に属し、コードやスケールは演奏の音楽理論的特性に属する。このような演奏内容の解析には、公知の手法を適用可能である。解析部２１４は、上述したサーバ１００の解析部１１３と共に、本発明に係る「解析手段」の一例である。
【００８８】
尚、演奏の物理的特性としては、上記メロディやリズムの他に、音量やアクセントの位置等が含まれていてもよい。
【００８９】
表示制御部２１５は、表示部２４０の表示状態を制御する。
【００９０】
受信バッファ２２０は、配信された演奏データを一時的に蓄積するバッファとして機能する揮発性記憶装置である。受信バッファ２２０のバッファ容量は、演奏データのデータサイズに対して十分に大きいものとなっている。
【００９１】
通信Ｉ／Ｆ２３０は、端末２００とサーバ１００との間のデータ通信を実現するための、所定の通信規格に準じたインターフェイスである。
【００９２】
表示部２４０は、ユーザに対して視覚情報を表示するためのディスプレイ装置である。表示部２４０は、上述したウェブサイトＷＳを表示可能に構成される。
【００９３】
＜実施例の動作＞
次に、実施例の動作について説明する。
【００９４】
＜データベース１２１の説明＞
始めに、図４を参照し、データベース１２１について説明する。ここに、図４は、データベース１２１の概念図である。尚、データベース１２１は、厳密には、記憶装置１２０に記憶された演奏データを管理するために制御部１１１により実行される一種の制御プログラムであるが、ここでは、この制御プログラムにより具現化される擬似的な記憶領域を併せて意味するものとする。
【００９５】
図４（ａ）において、データベース１２１には、演奏データＰＤｘ（ｘは０００００１〜９９９９９９までのデータ識別番号）が格納されている。演奏データＰＤｘは、サーバ１００にアップロードされた演奏データであり、ユーザ（ここでは、便宜上、ユーザ＝演奏者であるとする）、演奏曲目、演奏テンポ及び演奏パート（即ち、楽器）等が夫々異なる多種多様な演奏データの集合体である。演奏データＰＤｘは、その演奏内容を規定するメタデータｍｅｔａ１と共にデータベース１２１に格納される。メタデータｍｅｔａ１は、例えば、アーティスト名、演奏者名、曲目、テンポ、演奏パート等の情報を含んでいる。データベース１２１では、このメタデータｍｅｔａ１を、演奏データＰＤｘの検索に利用することができる。
【００９６】
図４（ｂ）には、演奏データＰＤｘを検索条件Ａに従って検索した場合の検索結果が例示される。検索条件Ａは、アーティスト名、曲名及びテンポであるとする。
【００９７】
ここで、このような検索条件の設定に対し、演奏データに何らの情報も付帯されていなければ、検索条件に合致する演奏データを数多の演奏データの中から検索することは殆ど不可能である。これに対して、上述したように演奏データＰＤｘにはメタデータｍｅｔａ１が付帯されているため、検索条件Ａが設定された場合、この検索条件に合致する演奏データＰＤｘを、例えば演奏パートＰＰｘ（ｘは演奏パートを識別する識別番号）毎に分類することが容易にして可能となる。本実施例において、演奏パートＰＰは、ＰＰ１がリードギター、ＰＰ２がリズムギター、ＰＰ３がドラム、ＰＰ４がベース、ＰＰ５がキーボードであるとする。
【００９８】
図４（ｂ）において、演奏パートＰＰ１（ここでは、リードギター）においてこの検索条件Ａに合致する演奏データが、ＰＤ１０００００、ＰＤ２０００００、・・・、ＰＤ９０００００であると検索される。このような、データベース１２１における演奏データＰＤｘの検索機能は、ウェブサイトＷＳ上でユーザに提供される。従って、ユーザは、自由な検索条件を設定して、自身が所望する演奏データを見付けることができる。
【００９９】
＜演奏セッションモードの説明＞
次に、演奏システム１０が有する動作モードの一つである演奏セッションモードについて説明する。演奏セッションとは、複数の演奏パートにより構成される演奏を意味する。演奏セッションモードでは、ユーザが一演奏者として演奏セッションに参加することができる。
【０１００】
図５を参照し、演奏セッションモードについて詳細に説明する。ここに、図５は、演奏セッションモードの概念図である。尚、同図において、図４と重複する箇所には同一の符号を付してその説明を適宜省略することとする。
【０１０１】
図５において、演奏セッションモードにおけるウェブサイトＷＳの一表示状態が例示される。演奏セッションモードが選択されると、ウェブサイトＷＳには、演奏トラックＴＲ１〜ＴＲ５に演奏データを割り当てるダイアログボックスと、操作キーＯＰとが示される。尚、ここでは、演奏パートＰＰ４（即ち、ベース）を演奏するユーザＵ１が演奏セッションに参加するものとする。
【０１０２】
ここで、例えば、検索条件として上述の検索条件Ａが設定された場合において、検索条件Ａによる演奏データＰＤｘの検索結果から、演奏パート毎にユーザＵ１が所望する演奏データが演奏トラックに割り当てられたとする。図５では、演奏トラックＴＲ１に演奏パートＰＰ１（リードギター）の演奏データＰＤ１０００００が、演奏トラックＴＲ２に演奏パートＰＰ２（リズムギター）の演奏データＰＤ０２００００が、演奏トラックＴＲ３に演奏パートＰＰ３（ドラム）の演奏データＰＤ００１０００が、演奏トラックＴＲ５に演奏パートＰＰ５（キーボード）の演奏データＰＤ００００９０が、夫々割り当てられた様子が示される（図示ハッチング表示参照）。演奏トラックＴＲ５は選択されていない。
【０１０３】
この状態で操作キーＯＰから再生用のキーが操作されると、各演奏トラックに割り当てられた演奏データに基づいて演奏がミキシング再生される。即ち、検索条件Ａに合致する演奏が、演奏パートＰＰ４（ベース）抜きで再生される。ユーザＵ１は、この演奏パートＰＰ４抜きで再生される演奏セッションにおいて、自身が演奏パートＰＰ４を担うことによって、演奏セッションを完成させる。その結果、擬似的な演奏セッションが実現される。
【０１０４】
図６は、演奏セッションモードにより実現された演奏セッションの進行の様子を例示するタイミングチャートである。
【０１０５】
図６において、上から順に、演奏トラックＴＲ１、ＴＲ２、ＴＲ３及びＴＲ４の各演奏トラックの演奏並びにユーザＵ１による演奏の各時間推移が例示されている。演奏を所定の長さ（例えば、４小節、８小節等）毎に区分して、演奏区分Ｂ１、Ｂ２、・・・と表すと、演奏データに基づいて再生される各演奏トラックの演奏は、各演奏トラックについてＴＲｘＢ１、ＴＲｘＢ２、・・・となる。演奏者たるユーザＵ１は、この再生演奏による擬似的演奏セッションに自身の演奏を同期させ、演奏区分Ｂ１、Ｂ２、・・・に対応するユーザ演奏ＵＰＢ１、ＵＰＢ２、・・・を行うことにより、演奏セッションを進行させることができる。
【０１０６】
＜データベース１２２の説明＞
次に、図７を参照し、データベース１２２について説明する。ここに、図７は、データベース１２２の概念図である。尚、データベース１２２は、厳密には、記憶装置１２０に記憶された演奏データを管理するために制御部１１１により実行される一種の制御プログラムであるが、ここでは、この制御プログラムにより具現化される擬似的な記憶領域を併せて意味するものとする。
【０１０７】
図７において、データベース１２２には、コールデータＣＤｘ（ｘは０００００１〜９９９９９９までのデータ識別番号）が格納されている。コールデータＣＤｘは、サーバ１００にアップロードされた演奏データである。但し、コールデータＣＤｘは、先述した演奏データＰＤｘと異なり、Ｃ／Ｒ（コール＆レスポンス）モードにおけるコールとして利用可能な、比較的短い時間の演奏（例えば、上述した演奏区分Ｂｘ（ｘは識別番号）と同様、所定数の小節を単位とする演奏）に関する演奏データである。
【０１０８】
コールデータＣＤｘは、その演奏内容を規定するメタデータｍｅｔａ２と共にデータベース１２２に格納される。データベース１２２におけるメタデータｍｅｔａ２は、先述したデータベース１２１におけるメタデータｍｅｔａ１と若干異なる演奏情報を含んでいる。即ち、コールデータＣＤｘに付帯されるメタデータｍｅｔａ２は、演奏パート、メロディ、リズム、テンポ、コード、スケール等の情報を含んでいる。データベース１２２では、このメタデータｍｅｔａ２を、コールデータＣＤｘの検索に利用することができる。
【０１０９】
尚、演奏情報を規定するメタデータｍｅｔａ２には、上記の他に更に音量やアクセントの位置（演奏の物理的特性の一例）が含まれていてもよい。メタデータｍｅｔａ２に音量やアクセントの位置或いはそのパターンのデータが含まれる場合、当然ながらコールデータＣＤｘの検索に音量やアクセントの位置或いはそのパターンを利用することもできる。
【０１１０】
＜Ｃ／Ｒモードの概要＞
次に、演奏システム１０が有する動作モードの一つであるＣ／Ｒモードについて説明する。Ｃ／Ｒとは、演奏セッションにおいて、呼び掛け演奏（コール）と応答演奏（レスポンス）との繰り返しにより構成される、即興的な演奏コミュニケーションである。Ｃ／Ｒは、一般的に複数の演奏者の参加を前提とする。このため、自身以外の演奏パートを全て事前に指定して行われる上述した演奏セッションモードではＣ／Ｒを実現することは難しい。Ｃ／Ｒモードは、このような事情に鑑みて設定された、擬似的なＣ／Ｒを実現するための動作モードである。
【０１１１】
ここで、図８を参照し、Ｃ／Ｒモードの詳細について説明する。ここに、図８は、Ｃ／ＲモードにおけるウェブサイトＷＳの表示状態を例示する図である。尚、同図において、図７と重複する箇所には同一の符号を付してその説明を適宜省略することとする。
【０１１２】
図８において、Ｃ／ＲモードにおけるウェブサイトＷＳの一表示状態が例示される。Ｃ／Ｒモードが選択されると、ウェブサイトＷＳには、先述した演奏トラックＴＲｘ（ｘは識別番号）に演奏データを割り当てるためのダイアログボックスと、コール条件ＣＲｘ（ｘは識別番号）を指定するためのダイアログボックスとが表示される。
【０１１３】
Ｃ／Ｒモードにおいて、演奏トラックＴＲ１〜ＴＲ３には、Ｃ／Ｒの伴奏となる演奏データが割り当てられる。伴奏とは、全体のリズムを規定する演奏パートであり、臨場感のあるＣ／Ｒを実現するため、或いは、ユーザがレスポンスのタイミングを掴み易いように、望ましくは少なくとも一つ設定される。伴奏に対応する演奏トラックには、演奏セッションモードの場合と同様に、データベース１２１に蓄積された演奏データＰＤｘを割り当てることができる。図８には、演奏トラックＴＲ１に、演奏パートＰＰ３（ドラム）に対応する演奏データＰＤ００１０００が、演奏トラックＴＲ２に演奏パートＰＰ２（リズムギター）に対応する演奏データＰＤ０２００００が夫々割り当てられた様子が示される（ハッチング表示参照）。
【０１１４】
一方、演奏トラックＴＲ４は、コールに割り当てられる。コールは、後述するようにサーバ１００のコール選択部１１４により選択されるため、ユーザＵ１は単に演奏トラックＴＲ４にコールを割り当てるだけでよい。
【０１１５】
他方、ユーザＵ１は、演奏トラックＴＲ４に割り当てられたコールの条件を規定するコール条件ＣＲｘを定義することができる。コール条件ＣＲｘは、コールデータＣＤｘに対応付けられた演奏内容、即ち、メタデータｍｅｔａ２に規定される情報の範囲で自由に設定することができる。図８には、コール条件ＣＲ１として、演奏パート「エレキギター」が指定された様子が示される。この場合、サーバ１００のコール選択部１１４により選択されるコールデータは、エレキギターの演奏パートとなる。
【０１１６】
この状態で、例えば不図示の操作キーＯＰから再生用のキーが操作されると、伴奏に対応する演奏トラックに割り当てられた演奏データに基づいて、上述した演奏セッションモードと同様に伴奏（リズム）がミキシング再生される。そして、この伴奏の演奏期間中に、演奏トラックＴＲ４に割り当てられたコールデータの再生が時間軸上で離散的に行われる。
【０１１７】
図９は、Ｃ／Ｒモードにより実現されたＣ／Ｒの進行の様子を例示するタイミングチャートである。尚、同図において、図６と重複する箇所には同一の符号を付してその説明を適宜省略することとする。
【０１１８】
図９において、上から順に、伴奏に対応する演奏トラックＴＲ１及びＴＲ２、コールに対応する演奏トラックＴＲ４並びにユーザＵ１による演奏（即ち、レスポンス）の各時間推移が例示されている。演奏を所定の長さ（例えば、４小節、８小節等）毎に区分して、演奏区分Ｂ１、Ｂ２、・・・と表すと、演奏データに基づいて再生される伴奏は、各演奏トラックについてＴＲｘＢ１、ＴＲｘＢ２、・・・となる。
【０１１９】
これに対し、演奏トラックＴＲ４に割り当てられたコールデータは、演奏区分Ｂ１、Ｂ３、Ｂ５・・・と離散的な演奏区分において、ＣＬＢ１、ＣＬＢ３、ＣＬＢ５・・・と離散的に再生される。
【０１２０】
演奏者たるユーザＵ１は、この時間軸上で離散的に再生されるコールに対し、自身の演奏によりレスポンスを行う。即ち、演奏区分Ｂ１において再生されるコールＣＬＢ１には演奏区分Ｂ２におけるレスポンスＲＰＢ２が、演奏区分Ｂ２において再生されるコールＣＬＢ３には演奏区分Ｂ４におけるコールＲＰＢ４が、演奏区分Ｂ５において再生されるコールＣＬＢ５には、不図示の演奏区分Ｂ６におけるレスポンスＲＰＢ６が、夫々対応する。
【０１２１】
尚、図９において、コールＣＬＢ１とコールＣＬＢ３との関係で見た場合、コールＣＬＢ１に対応するコールデータは、本発明に係る「第１演奏データ」の一例であり、コールＣＬＢ３に対応するコールデータは、本発明に係る「第２演奏データ」の一例である。また、コールＣＬＢ３とコールＣＬＢ５との関係で見た場合、コールＣＬＢ３に対応するコールデータは、本発明に係る「第１演奏データ」の一例であり、コールＣＬＢ５に対応するコールデータは、本発明に係る「第２演奏データ」の一例である。このように、本発明に係る第１及び第２演奏データとは、二つのコールデータ相互間の時間軸上の関係を表すものであって、特定のコールデータを表すものではない。
【０１２２】
このように、Ｃ／Ｒモードによればユーザが一人であってもＣ／Ｒ環境を実現することができる。従って、ユーザＵ１は、Ｃ／Ｒの技量向上に演奏システム１０を利用することができる。或いは、純粋にＣ／Ｒを楽しむことができる。
【０１２３】
＜Ｃ／Ｒモードの詳細＞
次に、図１０を参照し、Ｃ／Ｒモードの詳細について説明する。ここに、図１０は、Ｃ／Ｒモードの制御フローである。尚、同図において、図２及び図３と重複する箇所には同一の符号を付してその説明を適宜省略することとする。尚、図１０は一種の制御フローを示す図であるが、図中のステップ番号（Ｓ〜）は、時系列的な処理の順序を規定するものではない。
【０１２４】
図１０において、サーバ１００及び端末２００における、Ｃ／Ｒモードの実行に寄与する部分が示される。尚、先述したように、サーバ１００の制御部１１１は、制御プログラムを実行することによりＷＥＢ管理部１１２、解析部１１３及びコール選択部１１４を上位に制御しており、図示は省略されている。
【０１２５】
図１０において、ＷＥＢ管理部１１２は、コールデータＣＤｘが格納されたデータベース１２２へアクセスし、端末２００に送信すべきコールデータを準備する（ステップＳ１０１）。この送信すべきコールデータは、後述するコール選択部１１４のコール決定処理により決定される。
【０１２６】
準備されたコールデータは、不図示の送信バッファ１３０を経由して端末２００へ送信される（ステップＳ１０２）。尚、ＷＥＢ管理部１１２を介したコールデータの送信は、端末２００の制御部２１１から見た場合、コールデータのダウンロードと等価である（図示破矢線「Ｄ／Ｌ」参照）。
【０１２７】
尚、図面の煩雑化を防ぐ目的から図示は省略されているが、Ｃ／Ｒモードの実行期間においては、上述したように伴奏に相当する演奏データがデータベース１２１から取得され、コールデータと同様に端末２００にダウンロードされている。
【０１２８】
端末２００の制御部２１１では、再生すべきコールに関するコールデータが受信され（ステップＳ２０１）、再生制御部２１２へ受け渡される。再生制御部２１２では、この受け取ったコールデータに基づいてコール再生処理が行われる（ステップＳ２０５）。また、演奏データに基づいた伴奏再生処理も行われる（ステップＳ２０４）。
【０１２９】
一方、端末２００において一つのコールの再生が終了すると、再生されたコールに呼応した、ユーザによるレスポンスが行われる。このレスポンスは、録音制御部２１３におけるレスポンス録音処理により演奏データ化され録音される（ステップＳ２０６）。ここでは、レスポンスの演奏データを、便宜的にレスポンスデータと表現する。
【０１３０】
レスポンスデータは、制御部２１１に受け渡され、サーバ１００へのアップロード準備に供される（ステップＳ２０３）。尚、アップロード準備とは、アップロードすべきレスポンスデータに対応する、ユーザＩＤや日付情報等の付加を意味する。アップロード準備が整ったレスポンスデータは、制御部２１１によりサーバ１００に送信される（ステップＳ２０２）。広義においては、この段階でレスポンスデータのアップロードが終了する（図示破矢線「Ｕ／Ｌ」参照）。
【０１３１】
サーバ１００において、この送信されたレスポンスデータが受信されると（ステップＳ１０３）、この受信されたレスポンスデータが解析部１１３に受け渡され、演奏内容の解析が行われる（ステップＳ１０６）。解析部１１３により解析される演奏内容には、メロディ、リズム、テンポ、コード及びスケール等が含まれる。解析部１１３による解析は、例えば、一般化調和解析等、公知の信号処理や統計処理を用いた解析手法により行われる。
【０１３２】
尚、演奏情報を規定するメタデータｍｅｔａ２に音量やアクセントの位置或いはそのパターンが含まれる場合には、当然ながらレスポンスの解析内容に音量やアクセントの位置或いはそのパターンが含まれてもよい。音量やアクセントの位置の解析は、例えば、音圧信号レベルの比較により容易に実現され得る。
【０１３３】
演奏内容の解析が終了すると、演奏内容の解析結果を表すレスポンス解析データＡＲｒｐがＷＥＢ管理部１１２に送信される。ＷＥＢ管理部１１２では、このレスポンス解析データＡＲｒｐがメタデータの形式に変換され、端末２００から送信されたレスポンスデータに付帯される。メタデータが付帯されたレスポンスデータは、新たにコールデータとしてデータベース１２２に格納される。狭義には、この段階でレスポンスのアップロードが終了する。
【０１３４】
尚、データベース１２２に格納されるコールデータＣＤｘは、予め事業者側でＣ／Ｒモードのために用意されたサンプルコールデータと、ユーザにより適宜Ｃ／Ｒモードのために録音されたコールデータと、このコールデータ化されたレスポンスデータとを含む。これらはいずれもコールデータとして使用可能である。ここで、これらコールデータＣＤｘに付帯されるメタデータｍｅｔａ２は、必ずしも解析部１１３等による解析処理の結果得られたものでなくてよい。例えば、事業者やユーザにより人為的に与えられたものであってもよい。また、コールデータＣＤｘを構成する個々のコールデータ間で、メタデータｍｅｔａ２に含まれる情報は必ずしも共通化されておらずともよい。
【０１３５】
＜コール決定処理の詳細＞
次に、コール選択部１１４により行われるコール決定処理（ステップＳ１０８）について説明する。コール決定処理は、データベース１２２に格納されたコールデータＣＤｘの中から端末２００に送信すべき、即ち、次のコール再生タイミングにおいてコールとして再生されるべき一のコールデータＣＤを決定する処理である。
【０１３６】
コール決定処理においては、解析部１１３によるコールの演奏内容の解析結果が利用される。コールの演奏内容の解析とは、先述したレスポンスの演奏内容の解析と同様、メロディ、リズム、テンポ、コード及びスケール等の項目に関する解析を指す。或いは更に、メタデータｍｅｔａ２に音量やアクセントの位置或いはそのパターンが含まれる場合には、音量やアクセントの位置或いはそのパターンの解析が含まれてもよい。解析部１１３は、端末２００で再生されたコールのうち最も新しいコール（以下、適宜「最新のコール」と表現する）について、演奏内容を解析する（ステップＳ１０５）。
【０１３７】
ここで、端末２００に送信されるコールデータには、データベース１２２に格納されている時点で、既にメタデータｍｅｔａ２が付帯されている。即ち、本実施例に係るコールの演奏内容の解析とは、コールデータに付帯されたメタデータｍｅｔａ２の取得と等価である。演奏内容の解析結果は、レスポンスデータの場合と同様に、コール解析データＡＲｃｌとしてコール選択部１１４に送られる。
【０１３８】
最新のコールデータに関するコール解析データＡＲｃｌが得られると、コール選択部１１４は、候補選択処理を実行する（ステップＳ１０７）。候補選択処理では、下記の基準に基づいて複数のコール候補が選択される。
【０１３９】
（１）メロディ又はリズムの類似性
この基準では、メロディ又はリズムの類似性に基づいて複数のコール候補が選択される。
【０１４０】
最新のコールとメロディ又はリズム或いはその両方が類似するコールは、コール相互間の音楽的繋がりが確保された、次のコールの候補となり得る。例えば、メロディが類似するか否かは、最新のコールと比較対象のコールとの音階の相関を推定することにより判定することができる。また、リズムが類似するか否かは、時間軸における発音位置について比較対象との相関を推定することにより判定することができる。実践的には、これらの相関の度合いを数値化した相関係数が閾値以上となった比較対象がコールの候補となる。
【０１４１】
尚、演奏内容の物理的特性として、これらメロディ又はリズムの他に音量が採用される場合、例えば、音量の類似性が基準とされてもよい。音量の類似性とは、音量（音圧信号レベル）の差が所定以内であること等を指す。即ち、原演奏の録音状況が異なると、録音された演奏の音量も異なり得る。複数のコール相互間で音量の差異が大きいと、Ｃ／Ｒのリアル感が失われたり、レスポンスの演奏を円滑に行えなくなったりする可能性がある。そのような意味において、音量の解析もまた、演奏内容の解析として重要な一面を持つ。
【０１４２】
また、この他、演奏内容の物理的特性としては、アクセントの位置の類似性が基準とされてもよい。アクセント、即ち、音の相対的強弱や相対的高低の生じる位置或いはそのパターンが類似する演奏は、物理的特性において近しい演奏と判断することができる。アクセントの位置の判定は、音量（例えば、音圧信号レベル）の解析や、音階の解析により容易に実現され得る。
【０１４３】
（２）コード進行パターン
この基準では、コード進行パターンの妥当性に基づいて複数のコール候補が選択される。
【０１４４】
コード進行には、統計的に幾つかの典型的なパターンがある。また、これら典型的なパターンの出現頻度にも統計的に高低がある。ここで、解析部１１３は、Ｃ／Ｒモードの進行とは別に、コード進行パターンの学習処理を行っている。この学習処理は、演奏セッションモードにおいてサーバ１００にアップロードされる数多の演奏データについて演奏内容を解析し、当該演奏データにおける頻出コードの進行パターンを特定し、統計的解析に付する処理である。
【０１４５】
例えば、この学習処理によれば、「Ｃ△７」のコードに対し、「Ｅｍ７」へのコード進行が５０％、「Ｆ△７」へのコード進行が３０％、「Ｆ７」へのコード進行が５％、等といった学習結果を得ることができる。このコード進行パターンの学習結果を利用すれば、上記最新のコールのコードに対して、統計的に最も違和感の無いと判断されるコードを、次のコールのコードとして決定することができる。上述の例で言えば、最新のコールのコードが「Ｃ△７」であれば、次のコールのコードは、例えば最も頻度の高い「Ｅｍ７」が妥当であるとして、Ｅｍ７に決定される。
【０１４６】
尚、コード進行パターンの学習は、アップロードされる演奏データに基づいたものでなくてもよい。例えば、ジャズスタンダードのコード進行に基づいた学習が行われてもよい。尚、コードには、キーを排して機能和声としてみたコードが利用されてもよい。例えば、機能和声として見たコードを利用する場合、「ＩＩｍ７」のコードに対し、「Ｖ７」へのコード進行が５０％、「ＩＶ△７」へのコード進行が３０％、「ＩＩ７」へのコード進行が１０％、等といった学習結果を得ることができる。
【０１４７】
（３）スケールの類似性又は関連性
この基準では、スケールの類似性又は関連性に基づいて複数のコール候補が選択される。
【０１４８】
スケールの類似性は、メロディの解析結果に基づいて判定される。即ち、メロディに含まれる音階から、該当する又は類似するスケールを選定することができる。該当する又は類似するスケールとして選定されたスケールを有するコールを候補とすることができる。
【０１４９】
スケールの関連性は、コードの解析結果に基づいて判定される。即ち、音楽理論的見地から、解析されたコードと関連性の高いスケールを確定させることができる。例えば、「Ｃ△７」のコードに対しては、ＣメジャーやＣリディアン等を関連性の高いスケールとすることができる。
【０１５０】
また、スケールの関連性については、上記関連性の高いスケールの関連スケールを対象に加えてもよい。例えば、利用音階が同じスケールや、代理和音に対応するスケールが対象に加えられてもよい。
【０１５１】
尚、本実施例では、上記（１）乃至（３）の基準を、最新のコールの解析結果に対してのみ適用したが、最新のコールの元となる前回のコール或いはそれより以前のコール等の解析結果を加えてもよい。このように過去一定数のコールを次のコールの選択に反映させることによって、Ｃ／Ｒモードにおける一連のコールに音楽的な繋がり或いは膨らみを持たせることができる。
【０１５２】
ここで、コール選択部１１４は、上記（１）乃至（３）の基準の各々に基づいて、データベース１２２から複数のコールの候補を選択する。例えば、候補選択処理により選択されるコールデータの数をＮとし、上記（１）、（２）及び（３）の基準に、夫々重み付け係数α、β及びγを定義して、上記（１）、（２）及び（３）の基準に基づいたコールデータが、夫々α×Ｎ個、β×Ｎ個、γ×Ｎ個選択される。尚、重み付け係数の和は１である（α＋β＋γ＝１）。
【０１５３】
尚、上記（１）、（２）及び（３）の各基準に基づいたコールデータの選択には、例えば、下記（ａ）、（ｂ）及び／又は（ｃ）の法則が適用される。
【０１５４】
（ａ）類似性、関連性又は妥当性の度合いが高い順に選択する
（ｂ）サーバ１００のアップロード日時が新しいものから選択する
（ｃ）条件を設けずにランダムに選択する
法則（ａ）が適用される場合、例えば、類似性、関連性又は妥当性が高いものから順に所定個数のデータが選択される。法則（ｂ）が適用される場合、例えば、サーバ１００へのアップロード日時が新しいものから順に所定個数のデータが選択される。法則（ｃ）が適用される場合、例えば、ランダムに所定個数のデータが選択される。
【０１５５】
また、当然ながら、法則（ａ）、（ｂ）、（ｃ）を適宜組み合わせ、複合的な法則を設定することもできる。例えば、法則（ａ）と（ｃ）とを組み合わせ、類似性、関連性又は妥当性の度合いが所定以上となるものの中からランダムに所定個数のデータが選択されてもよい。或いは、法則（ａ）と（ｂ）とを組み合わせ、類似性、関連性又は妥当性の度合いが所定以上となるもののうち、アップロードされた日時が新しいものから所定個数のデータが選択されてもよい。
【０１５６】
尚、類似性、関連性又は妥当性の度合いとは、例えば、類似性について言えば、完全に一致する場合を１００、全く一致しない場合を０として規格化した数値であってもよい。また、妥当性について言えば、例えば、コード進行パターンの学習結果から得られるコードの遷移確率であってもよい。また、関連性について言えば、例えば、音楽理論的見地からスケールの関連性の度合いを数値化したものであってもよい。但し、関連性に関しては、関連性があるか否かの二値的な度合いであってもよい。このような度合いは、適宜設定することができる。
【０１５７】
コール選択部１１４は、候補選択処理により複数（ここでは、Ｎ個）のコール候補が選択されると、これらの中から最終的にランダムに一つのコール（実際にはコールデータ）を選択し、次のコールとして決定する。コール決定処理は以上のように行われる。決定された次のコールの情報は、ＷＥＢ管理部１１２に伝達される。ＷＥＢ管理部１１２は、既に述べたようにデータベース１２２から、該当するコールデータを取得して端末２００に送信する。
【０１５８】
以上説明したように、本実施例に係る演奏システム１０によれば、Ｃ／Ｒモードにおいて、ユーザに対し、時間軸上で離散的にコールを提供することができる。従って、ユーザは、一のコールに対し、自身の感性や技量に応じたレスポンスを返すことができ、あたかも実際にＣ／Ｒによる即興的演奏コミュニケーションに身を投じているかの如き達成感を味わうことができる。ここで特に、この時間軸で離散的に提示されるコールは、過去のコールの演奏内容を反映しつつ、ランダムに決定される。従って、Ｃ／Ｒモードにより擬似的に実現されるＣ／Ｒは、コール相互間に音楽的な繋がりを有するクオリティの高いものとなる。また、コールはこのような音楽的繋がりが確保された上で最終的にはランダムに決定されるため、ユーザは、常に臨場感や緊張感を伴う即興的演奏を求められる。即ち、Ｃ／Ｒを純粋に楽しむことも、Ｃ／Ｒに関する自身の技量を磨くことも可能となる。
【０１５９】
尚、本実施例では、最新の（或いは、更に過去の）コールデータ（第１の演奏データ）に基づいて次のコールデータ（第２の演奏データ）が決定される。しかしながら、次のコールデータを決定するにあたっては、データベース１２２に格納されたコールデータＣＤｘが参照される。このコールデータＣＤｘの中には、過去のレスポンスの演奏データが含まれている。従って、コールの決定にはユーザの過去の演奏も反映される形となり、演奏コミュニケーションとしてのＣ／Ｒの品質が十分に確保される。
【０１６０】
尚、本実施例では、Ｃ／Ｒモードにおける伴奏として、データベース１２１に格納された演奏データに基づいた再生演奏が利用される構成を示したが、伴奏はより簡便なものであってもよい。即ち、Ｃ／Ｒの実現に有益なリズムが再生される限りにおいて、Ｃ／Ｒモードにおける伴奏に係る演奏データは、例えば、予め用意されたサンプルのリズムデータであってもよい。
【０１６１】
＜第２実施例＞
第１実施例では、最新のコールに基づいて次のコールが決定される態様を説明したが、Ｃ／Ｒは、コールとレスポンスとが交互に行われるコミュニケーションである。即ち、ユーザのレスポンスが最新のコールに呼応したものであるのと同様に、次のコールは最新のレスポンスに呼応したものとすることは自然である。第２実施例では、次のコールをレスポンスに基づいて決定する態様について説明する。
【０１６２】
図１１は、第２実施例に係るＣ／Ｒモードの制御フローである。尚、同図において、図１０と重複する箇所には同一の符号を付してその説明を適宜省略することとする。
【０１６３】
図１１において、第２実施例に係る制御フローが第１実施例に係る制御フローと大きく異なる点は、端末２００の解析部２１４でレスポンスの演奏内容が解析される点である。尚、演奏内容の解析そのものは、第１実施例と同様であるとする。
【０１６４】
ここで、一旦図９に戻ると、第１実施例に係るコール決定処理では、演奏区分Ｂ３において再生されるコールＣＬＢ３は、演奏区分Ｂ１に再生されるコールＣＬＢ１の演奏内容の解析結果に基づいて決定される。第１実施例においては、コールＣＬＢ１に呼応して演奏区分Ｂ２においてユーザが行うレスポンスＲＰＢ２の演奏内容が解析されるタイミングは、レスポンスＲＰＢ２の演奏終了後である。従って、直前のレスポンス（例えば、ＲＰＢ２）の演奏内容に基づいて次のコール（例えば、ＣＬＢ３）を決定することはできない。何故なら、レスポンスＲＰＢ２の解析が開始される時点で、既にコールＣＬＢ１に引き続くコール（ここでは、コールＣＬＢ３）は決定されていなければならないからである。
【０１６５】
一方、端末２００でレスポンスの演奏内容が解析される場合、その解析はレスポンスの演奏期間において進行する。従って、その解析結果であるレスポンス解析データＡＲｒｐをサーバ１００に提供する（即ち、送信する）ことにより、最新のレスポンス（ここでは、ＲＰＢ２）を次のコール（ここでは、ＣＬＢ３）の決定に利用することができる。
【０１６６】
即ち、解析部２１４においてレスポンスの演奏内容が解析される（ステップＳ２１１）と、その解析内容を表すレスポンス解析データＡＲｒｐが、サーバ１００側のコール選択部１１４及びＷＥＢ管理部１１２に提供される（矢線参照）。コール選択部１１４は、このレスポンス解析データＡＲｒｐを、第１実施例に係るコール解析データＡＲｃｌと同様に扱って、例えば、上記（１）乃至（３）の基準及び上記（ａ）乃至（ｃ）の法則に基づいてレスポンスと音楽的繋がりを有するコールの候補を選択し、最終的に次のコールを決定する。
【０１６７】
本実施例によれば、このようにコールがレスポンスに基づいて決定される。従って、ユーザは、自身の演奏に呼応したコールを体感することができる。その結果、コールとレスポンスとの繰り返しにより成立する演奏コミュニケーションとしてのＣ／Ｒを、高い臨場感を伴って満喫することができる。
【０１６８】
ところで、このように端末２００側でレスポンスの演奏内容が解析される場合、レスポンスの全てを演奏内容の解析対象とすると、サーバ１００側でのコールの決定が間に合わなくなる。レスポンスが終了すれば、引き続いてコールが再生されなければならないからである。
【０１６９】
そこで、第２実施例に係る演奏システム１０は、端末２００の解析部２１４がレスポンスの演奏途中でレスポンス解析データＡＲｒｐをサーバ１００に送信する構成となっている。このことを、図１２を参照して説明する。ここに、図１２は、第２実施例に係るＣ／Ｒモードの進行の様子を説明する図である。尚、同図において、図９と重複する箇所には同一の符号を付してその説明を適宜省略することとする。
【０１７０】
図１２において、図９における演奏区分Ｂ１、Ｂ２及びＢ３が拡大されている。これ以降、演奏区分Ｂ１におけるコールＣＬＢ１に呼応する、演奏区分Ｂ２におけるレスポンスＲＰＢ２を例にとって説明する。
【０１７１】
上述したように、レスポンスＲＰＢ２の演奏内容の解析に係るレスポンス解析データＡＲｒｐの送信が、レスポンスＲＰＢ２の演奏が終了後に行われると、次の演奏区分Ｂ３におけるコールＣＬＢ３の決定が間に合わなくなる。
【０１７２】
そこで、端末２００の解析部２１４は、時刻ｔ２以前に、その時点までで得られた解析結果を暫定的なレスポンス解析データＡＲｒｐｔとしてサーバ１００に送信する。尚、この暫定的なレスポンス解析データＡＲｒｐｔの送信とは別に、解析部２１４におけるレスポンスＲＰＢ２の演奏内容の解析は継続される。即ち、レスポンスＲＰＢ２の演奏内容の正規の解析結果は、正規のレスポンス解析データＡＲｒｐとして、レスポンスＲＰＢ２の終了後にサーバ１００に送信される。
【０１７３】
ここで、レスポンスの演奏内容を次回のコールに反映させるためには、ある程度の時間的猶予が必要となる。そのため、本実施例では、この時間的猶予を規定する余裕時間ｔｎが定義される。余裕時間ｔｎは、レスポンスの解析時間と、解析結果のアップロード時間と、コールの決定に要する時間と、コールのストリーミング再生に最低限必要な時間とを加算した値である。レスポンスの解析時間とは、演奏内容の解析に最低限必要とされる時間である。この余裕時間ｔｎは、予め実験的に、経験的に又は理論的に定めておくことができる。
【０１７４】
第２実施例において、端末２００でのレスポンスの解析は、少なくともそのレスポンスの演奏が終了する時刻（ここでは、ｔ２）から、当該余裕時間ｔｎを差し引いた時刻ｔ１’よりも前に開始される。従って、レスポンスと音楽的な繋がりを有するコールを演奏者に返すことが可能となる。
【０１７５】
尚、Ｃ／Ｒモードにおける演奏区分の時間的長さは、演奏区分を構成する小節数により決まる。例えば、一のコール及びレスポンスは、概ね１〜８小節程度の演奏区分で行われる。例えば、この演奏区分の時間的長さが、上記余裕時間ｔｎに対して不十分な場合、演奏内容の有効な解析が難しい場合がある。このような場合には、第１実施例と同様に、サーバ１００で決定されるコールが利用される。また、演奏内容の有効な解析が可能であるか否かは、演奏内容の解析に必要なデータ量（例えば、小節数又は音符数等）を事前に定めておくことにより、このデータ量と、演奏区分の時間的長さと、余裕時間ｔｎとの相対関係から判定可能である。
【０１７６】
尚、ここでは、レスポンスＲＰＢ２の演奏内容の解析が全て端末１００で行われる構成を示したが、端末１００側の負荷を考慮すれば、次のコールの決定に必要となる暫定的なレスポンス解析データＡＲｒｐ’が得られた時点で解析部２１４による演奏内容の解析を終了してもよい。この場合、第１実施例と同様に、レスポンスデータの送信後にサーバ１００の解析部１１３で再度レスポンスの演奏内容の解析が行われる。この際サーバ１００で得られたレスポンスの演奏内容の解析結果と端末２００で行われたレスポンスの演奏内容の暫定的な解析結果とは、必ずしも一致しておらずともよい。
【０１７７】
尚、第２実施例では、このように解析部２１４により端末２００側でレスポンスの演奏内容が解析される。逆に言えば、第１実施例のようにサーバ１００側でレスポンスの演奏内容が解析される場合、端末２００に解析部２１４は必ずしも必要はない。
【０１７８】
＜第１応用例＞
次に、上記第１及び第２実施例に係る演奏システム１０の第１応用例について説明する。
【０１７９】
Ｃ／Ｒモードにおいては、コールとして使用された演奏データ（コールデータ）も、レスポンスの演奏データ（レスポンスデータ）も、最終的には演奏データ（実施例では、上述したようにコールデータ）としてデータベース１２２に格納される。一方、これら単一の演奏データのみならず、伴奏、コール及びレスポンスからなる一連のＣ／Ｒもまた、一種の演奏セッションとして演奏データ化され、サーバ１００の記憶装置１２０に記憶される。
【０１８０】
ここで、ユーザの立場から、自身のレスポンスの客観的評価を所望することは至極自然な成り行きである。第１応用例に係る演奏システム１０では、その点に鑑み、Ｃ／Ｒの客観的評価が得られる構成となっている。Ｃ／Ｒの客観的評価は、サーバ１００の解析部１１３により行われる。概略的には、解析部１１３は、第１実施例においてなされた、レスポンスの演奏内容の解析結果（即ち、レスポンス解析データＡＲｒｐ）を利用する。
【０１８１】
具体的には、解析部１１３は、Ｃ／Ｒモードにおいて行なわれた、あるＣ／Ｒにおける一又は複数のレスポンスに係るレスポンス解析データＡＲｒｐを、下記（４）乃至（７）の評価基準に基づいて評価する。この評価基準は、上記第１実施例に係る（１）乃至（３）の基準と、一部において類似する又は同等である。
【０１８２】
（４）メロディ又はリズムの類似性
これは、一のコールとそれに対するレスポンスとからなる一の評価対象組について、メロディ又はリズムの類似性を評価基準とするものである。この評価基準は、演奏の物理的特性の評価である。
【０１８３】
尚、レスポンスの客観的評価においては、演奏内容としての音量やアクセントの位置は、先述したコール決定の場合と較べれば大きく考慮されずともよい。
【０１８４】
メロディの類似性は、上記評価対象組を構成する一のコールに対して、五線譜上に描かれるレスポンスの音符の位置が合致する割合に基づいて判定される。また、当該五線譜上の位置が合致した音符については、更にその長さが合致する割合等が判定要素に加えられる。このようなメロディの類似性は、上記割合の大小が夫々値の大小に対応するメロディ類似度指標値として数値化される。例えば、このメロディ類似度指標値は０〜１００の間で変化する。
【０１８５】
一方、リズムの類似性は、上記評価対象組を構成する一のコールに対して、時間軸上でレスポンスの拍が合致する割合に基づいて判定される。具体的には、コールの拍の各々に対して時間軸上で許容範囲を設定しておき、当該許容範囲内にレスポンスの拍が存在する場合には、当該拍が合致すると判定される。このようなリズムの類似性は、上記割合の大小が夫々値の大小に対応するリズム類似度指標値として数値化される。例えば、このリズム類似度指標値は０〜１００の間で変化する。
【０１８６】
尚、この許容範囲は、例えば、コールのＢＰＭ（Beet Per Minute）と拍から、例えば「４分音符一つ分の長さ／４分音符一つ分に含まれる最小の拍の個数」等の算出基準に従って算出される。この場合、例えば、１００ＢＰＭ、１６ビートの曲であれば、（６０／１００）／（１６／４）＝０．１５（ｓｅｃ）が当該許容範囲に設定される。
【０１８７】
（５）コード進行パターンの妥当性
これは、一のコールとそれに対するレスポンスとからなる一の評価対象組について、或いは、コールとレスポンスの繰り返しにより成立する一連のＣ／Ｒについて、コード進行パターンを評価基準とするものである。この評価基準は、演奏の音楽理論的特性の評価である。
【０１８８】
コード進行には、統計的に幾つかの頻出パターンがある。また、これら頻出パターン相互間にも、統計的に頻度の高低がある。ここで、解析部１１３は、Ｃ／Ｒモードの進行とは別に、コード進行パターンの学習処理を行っている。この学習処理は、演奏セッションモードにおいてサーバ１００にアップロードされる数多の演奏データの演奏内容の解析を通じて、頻出コード進行パターンを特定する処理である。例えば、この学習処理によれば、「Ｃ△７」のコードに対し、「Ｅｍ７」へのコード進行が５０％、「Ｆ△７」へのコード進行が３０％、「Ｆ７」へのコード進行が５％、等といった学習結果を得ることができる。この頻出コード進行パターンの学習結果を利用すれば、上記評価対象組について、一のコードに対するレスポンスが音楽理論的に妥当であるか否かを判定することができる。或いは、この一の評価対象組に関するコード進行パターンの妥当性の判定を、一連のＣ／Ｒに含まれる全ての評価対象組について行い、Ｃ／Ｒ全体としてのコード進行パターンの妥当性を判定することができる。
【０１８９】
尚、頻出コード進行パターンの学習は、アップロードされる演奏データに基づいたものでなくてもよい。例えば、ジャズスタンダードのコード進行に基づいた学習が行われてもよい。尚、コードには、キーを排して機能和声としてみたコードが利用されてもよい。例えば、機能和声として見たコードを利用する場合、「ＩＩｍ７」のコードに対し、「Ｖ７」へのコード進行が５０％、「ＩＶ△７」へのコード進行が３０％、「ＩＩ７」へのコード進行が１０％、等といった学習結果を得ることができる。
【０１９０】
尚、コード進行パターンの妥当性についても、上記（４）の場合と同様に、妥当性の高低が値の大小に夫々対応するコード進行パターン妥当性指標値として数値化される。例えば、このコード進行パターン妥当性指標値は０〜１００の間で変化する。
【０１９１】
（６）スケールの類似性
これは、一のコールとそれに対するレスポンスとからなる一の評価対象組について、スケールの類似性を評価基準とするものである。この評価基準は、演奏の音楽理論的特性の評価である。
【０１９２】
この場合、メロディに含まれる音階から、コール及びレスポンスの各々について、スケールが推定され、両者が合致するか否かが両者の類似性の一つの判断基準となる。また、両者が異なる場合であっても、両者の関連スケールの合致の度合いが類似性の一つの判断基準となる。尚、関連スケールとは、例えば、利用音階が同じスケールや、代理和音に対応するスケール等を含み得る。
【０１９３】
尚、メロディに基づいたスケールの推定に替えて又は加えて、コードの解析結果に基づいたスケールの推定が行われてもよい。即ち、コール及びレスポンスの各々について、音楽理論的見地から、解析されたコードと関連性の高いスケールを確定させることができる。例えば、「Ｃ△７」のコードに対しては、ＣメジャーやＣリディアン等を関連性の高いスケールとすることができる。コール及びレスポンスについての関連性の高いスケールの合致の度合いは、類似性の一つの判断基準となる。或いは、コール及びレスポンスの各々と最も関連性の高いスケールを先ず確定させ、この最も関連性の高いスケールの各々とのスケールの関連度に基づいて類似性が判断されてもよい。
【０１９４】
（７）客観的な評価
演奏システム１０はネットワーク１１に収容されており、サーバ１００（実践的にはウェブサイトＷＳ）へのアクセスを介して、多数のユーザがサーバ１００にアップロードされている演奏データを実際に利用することができる。従って、不特定多数のユーザにおいて、過去に行われたＣ／Ｒが主観的に評価され得る。このユーザ個々の主観的評価をデータとして汲み上げることによって、上記物理的特性の評価や音楽理論的特性の評価とは異なる、人間の六感に基づいた評価が可能となる。
【０１９５】
このような客観的評価は、例えば、ＷＥＢ管理部１１２により実現される。例えば、ＷＥＢ管理部１１２は、Ｃ／Ｒモードに関連する表示画面の一つとして、Ｃ／Ｒ評価画面を作成して、ウェブサイトＷＳに表示させる。
【０１９６】
このＣ／Ｒ評価画面では、サーバ１００にアップロードされたＣ／Ｒの中からＷＥＢ管理部１１２が評価対象として指定した一のＣ／Ｒについて、或いは、ユーザが選択した一のＣ／Ｒについて、ユーザによる視聴の後に、評価入力画面が現れる。この評価入力画面では、「メロディ評価」、「ハーモニー評価」、「リズム評価」、「全体的評価」等の入力項目があり、例えば予め用意された選択肢や評価数値の範囲で、ユーザは主観的な評価を入力することができる。
【０１９７】
個々の入力項目に関する入力結果（例えば、個々の選択肢を選んだユーザの数や、入力された評価数値の最大値、最小値及び平均値等）は、Ｃ／Ｒ評価結果として、ウェブサイトＷＳ上で表示される。このウェブサイトＷＳ上での評価結果の表示方法は、公知の各種多様を利用可能である。また、ＷＥＢ管理部１１２は、より視覚的な効果を高めるために、レーダーチャート等の表示方法を採用してもよい。
【０１９８】
以上説明したように、第１の応用例によれば、演奏システム１０においてＣ／Ｒモードを利用して行なわれた擬似的なＣ／Ｒについて、レスポンスが、物理的特性及び音楽理論的特性に基づいて評価される。また、客観的に評価される。従って、このレスポンスを演奏したユーザは、自身のレスポンスが適切であったのかの示唆を得ることができ、演奏技量の向上や、感性の向上に演奏システム１０を有効に利用することができる。
【０１９９】
＜第２応用例＞
次に、上記第１及び第２実施例に係る演奏システム１０の第２応用例について説明する。
【０２００】
Ｃ／Ｒモードにおいて、サーバ１００から送信されるコールデータは、端末２００において受信バッファ２２０に蓄積された後、然るべき再生タイミングでストリーミング再生される。
【０２０１】
ここで、ネットワーク１１を介してなされる演奏データのストリーミング再生では、ネットワーク１１の伝送遅延やネットワーク障害等により、予定通りにデータの送信が進行しないことがある。特に、演奏システム１０のようにストリーミング再生を前提としたシステムでは、データの伝送遅延が再生不良に直結する。Ｃ／Ｒモードにおいて、このような理由によりコールの再生が遅れると、当然ながらレスポンスの演奏もリズミカルに行うことができず、全体的なＣ／Ｒの品質低下を引き起こす。また、演奏再生システム１０におけるＣ／Ｒモードのように、送信すべきコールデータの決定に演奏内容の解析が必要となる場合、上述したネットワーク１１の伝送遅延やネットワーク障害に加えて、システムビジー等の理由によりコールデータの決定自体が遅延する場合もある。第２応用例では、このような場合においてＣ／Ｒモードの円滑な進行を継続させ得る遅延補償制御について説明する。遅延補償制御には、サーバ１００において実行されるサーバ側遅延補償制御と、端末２００において実行される端末側遅延補償制御とがある。
【０２０２】
＜サーバ側遅延補償制御の詳細＞
始めに、図１３を参照し、サーバ側遅延補償制御の詳細について説明する。ここに、図１３はサーバ側遅延制御のフローチャートである。尚、図１３に例示されるサーバ側遅延補償制御は、制御部１１１により実行される制御プログラムの下、ＷＥＢ管理部１１２、解析部１１３、コール選択部１１４等により協調的に実現される制御である。しかしながら、フローチャート上でこのような複数の実行主体を区別することは煩雑化を招くだけでありメリットがない。従って、図１３では、サーバ側遅延補償制御を、サーバ１００においてなされる制御として一括りに表現することとする。
【０２０３】
図１３において、ある演奏区分に再生すべきコールに係るコールデータＣＤ（ｉ）が決定される（ステップＳ１００）。尚、（ｉ）は時系列上の順序を規定する便宜的に設定された識別子である。
【０２０４】
コールデータＣＤ（ｉ）が決定されると、コールデータの送信に先立って参照データＣＤｒｅｆが端末２００に送信される。
【０２０５】
ここで、参照データＣＤｒｅｆは、コールデータＣＤ（ｉ）の演奏内容に関する情報と、コールデータＣＤ（ｉ）以外のコール候補に関する情報とを含むデータである。尚、参照データＣＤｒｅｆには演奏データは含まれない。
【０２０６】
参照データＣＤｒｅｆによって規定される、コールデータＣＤ（ｉ）の演奏内容に関する情報とは、端的には、上述したメロディ、リズム、コード、スケール、音量、アクセントの位置等といった情報である。尚、このような情報としては、データベース１２２に格納される各コールデータに付帯するメタデータｍｅｔａ２を利用することができる。
【０２０７】
また、上述したように、コールデータＣＤ（ｉ）は、複数のコール候補の中から最終的にランダムに決定される。参照データＣＤｒｅｆによって規定される、コールデータＣＤ（ｉ）以外のコール候補に関する情報とは、この複数のコール候補のうち、コールデータＣＤ（ｉ）に対応するコール以外のコールを特定する、例えばコールデータの識別番号等を記述したリスト等の情報である。
【０２０８】
参照データＣＤｒｅｆの送信が完了すると、コールデータＣＤ（ｉ）が端末装置２００に送信される（ステップＳ１１０）。
【０２０９】
コールデータＣＤ（ｉ）の送信が開始されると、コールデータＣＤ（ｉ）の伝送遅延が発生するか否かが判定される（ステップＳ１３０）。
【０２１０】
ここで、ステップＳ１３０においてその発生の有無が判定される「伝送遅延」とは、端末装置２００においてコールデータＣＤ（ｉ）に基づいたコールの再生が間に合わないことと等価な意味を持つ。即ち、コールの再生に間に合う限りにおいて、ネットワーク障害やネットワーク１１の伝送遅延が生じていても無視される。コールの再生が間に合うか否かは、コールのストリーミング再生に必要な、受信バッファ２２０におけるコールデータの最低限の蓄積量と、現在のネットワーク１１を介したデータ伝送速度と、現在時刻からコールの再生開始時刻までの時間猶予とに基づいてサーバ１００側で判定される。
【０２１１】
尚、この判定が端末２００側でなされ、サーバ１００へ伝達される構成とされてもよい。尚、先述したように、このような伝送遅延が発生する理由は、ネットワーク１１に由来するものであっても、サーバ１００での演奏内容の解析を含むコールデータＣＤ（ｉ）の決定に由来するものであってもよい。サーバ側での解析遅延が要因であっても、伝送遅延の発生の有無は、最終的には、端末側で時間猶予内に必要量のコールデータを蓄積できるか否かに帰結する。
【０２１２】
伝送遅延が発生しないと判定された場合（ステップＳ１３０：ＮＯ）、コールデータＣＤ（ｉ）の送信が完了したか否かが判定される（ステップＳ１５０）。送信が完了していない場合（ステップＳ１５０：ＮＯ）、処理はステップＳ１３０に戻される。送信が完了した場合（ステップＳ１５０：ＹＥＳ）、処理はステップＳ１００に戻される。
【０２１３】
一方、伝送遅延が発生すると判定された場合（ステップＳ１３０：ＹＥＳ）、端末２００に対して伝送遅延の発生が通知される（ステップＳ１４０）。尚、端末２００において伝送遅延の発生の有無が判定される場合には、伝送遅延が発生するとの判定がなされた時点で、伝送遅延が発生する旨のフラグがオン設定される。
【０２１４】
伝送遅延の発生が通知されると、処理は上記のステップＳ１５０に移行される。サーバ側遅延補償制御は以上のように実行される。尚、伝送遅延が発生するか否かにかかわらず、コールデータＣＤ（ｉ）の送信は継続される。このコールデータＣＤ（ｉ）は、本来の再生タイミングの次のタイミング（即ち、コールデータＣＤ（ｉ＋１）の再生タイミング）で再生される。
【０２１５】
＜端末側遅延補償制御の詳細＞
次に、図１４を参照し、端末側遅延補償制御について説明する。ここに、図１４は、端末側遅延補償制御のフローチャートである。尚、図１４に例示される端末側遅延補償制御は、制御部２１１により実行される制御プログラムの下、再生制御部２１２、解析部２１４、表示制御部２１５等により協調的に実現される制御である。しかしながら、フローチャート上でこのような複数の実行主体を区別することは煩雑化を招くだけでありメリットがない。従って、図１４では、端末側遅延補償制御を、端末２００においてなされる制御として一括りに表現することとする。
【０２１６】
図１４において、コールデータＣＤ（ｉ）の伝送遅延の発生が通知されたか否かが判定される（ステップＳ２００）。伝送遅延の発生が通知されていない場合（ステップＳ２００：ＮＯ）、ステップＳ２００が繰り返される。
【０２１７】
一方、伝送遅延の発生が通知された場合（ステップＳ２００：ＹＥＳ）、コールデータＣＤ（ｉ）の送信に先立って送信された、先述の参照データＣＤｒｅｆに基づいて、キャッシュリストの中から参照データＣＤｒｅｆに適合する演奏データが検索される（ステップＳ２１０）。検索が開始されると、キャッシュリストの中に参照データＣＤｒｅｆに適合する演奏データが有るか否かが判定される（ステップＳ２２０）。
【０２１８】
演奏システム１０において、端末２００の受信バッファ２２０には、キャッシュエリアが設けられており、過去にダウンロードされた演奏データやコールデータが一定量キャッシュデータとして蓄積されている。これらのキャッシュデータには、夫々サーバ１００側で付帯されるメタデータｍｅｔａ２も含まれている。
【０２１９】
ここで、参照データＣＤｒｅｆに適合する演奏データとは、参照データＣＤｒｅｆに含まれる情報によって、下記二種類の演奏データに大別される。一方は複数のコール候補のいずれかに該当する演奏データであり、他方はコールデータＣＤ（ｉ）と演奏内容が類似又は関連する演奏データである。
【０２２０】
前者は、キャッシュデータに含まれるデータ名と、コール候補のデータ名とを照合することにより検索される。後者は、上述したように、例えば、メロディやリズムが類似すること、コード遷移が統計的に妥当であること、関連するスケールを有すること等を意味する。後者は、より具体的には、上述した基準（１）乃至（３）に基づいた判定処理等を経て検索される。
【０２２１】
参照データＣＤｒｅｆに適合する演奏データが検索された結果、キャッシュデータの中に適合する演奏データが有る場合（ステップＳ２２０：ＹＥＳ）、更に、適合する演奏データが複数あるか否かが判定される（ステップＳ２３０）。適合する演奏データが単数であれば（ステップＳ２３０：ＮＯ）、この唯一の演奏データがコールデータＣＤ（ｉ）に代替されるべきコールデータとして決定される。
【０２２２】
一方、適合する演奏データが複数有る場合（ステップＳ２３０：ＹＥＳ）、この複数の演奏データの中からコールデータとして使用される一の演奏データがランダムに決定される（ステップＳ２５０）。また、適合する演奏データが相当数存在する場合には、上述した法則（ａ）、（ｂ）及び／又は（ｃ）に基づいた選択処理が行われてもよい。
【０２２３】
また、ステップＳ２２０においてキャッシュデータの中に参照データに該当する演奏データが無い場合（ステップＳ２２０：ＮＯ）、キャッシュデータの中からランダムに一の演奏データが選択され（ステップＳ２４０）、コールデータとして決定される。
【０２２４】
ステップＳ２３０、Ｓ２４０又はＳ２５０において決定された演奏データは、本来再生されるべきコールに関するコールデータＣＤ（ｉ）に代替される代替コールデータである。代替コールデータが決定されると、当該代替コールデータに基づいたコールの再生が行われる（ステップＳ２６０）。端末側遅延補償制御は以上のように実行される。
【０２２５】
このように、第２応用例によれば、ネットワーク１１を介したコールデータの伝送が、コールの再生タイミングに間に合わない場合には、端末１００で一定量保管されるキャッシュデータの中から代替のコールとして適当な演奏データが選択され、コールを滞りなく再生することができる。従って、Ｃ／Ｒモードの円滑な進行が担保される。
【０２２６】
尚、上述したように、伝送遅延が生じた場合にも、コールデータＣＤ（ｉ）の送信は継続される。従って、このキャッシュデータにより代替的になされるコールの次のコールに、このコールデータＣＤ（ｉ）に基づいたコールを再生することができる。
【０２２７】
本発明は、上述した実施例又は応用例に限られるものではなく、請求の範囲及び明細書全体から読み取れる発明の要旨或いは思想に反しない範囲で適宜変更可能であり、そのような変更を伴う演奏システムもまた本発明の技術的範囲に含まれるものである。
【符号の説明】
【０２２８】
１０…演奏システム、１１…ネットワーク、１００…サーバ、１１０…制御装置、１１１…制御部、１１２…ＷＥＢ管理部、１１３…解析部、１１４…コール選択部、１２０…記憶装置、１２１、１２２…データベース、１３０…送信バッファ、１４０…通信Ｉ／Ｆ、２００…端末、２１０…制御装置、２１１…制御部、２１２…再生制御部、２１３…録音処理部、２１４…解析部、２１５…表示制御部、２２０…受信バッファ、２３０…通信Ｉ／Ｆ、２４０…表示部。
【図１】
2015055649.tif 000003
【図２】
2015055649.tif 000004
【図３】
2015055649.tif 000005
【図４】
2015055649.tif 000006
【図６】
2015055649.tif 000007
【図７】
2015055649.tif 000008
【図１０】
2015055649.tif 000009
【図１１】
2015055649.tif 000010
【図１３】
2015055649.tif 000011
【図１４】
2015055649.tif 000012
【図５】
2015055649.tif 000013
【図８】
2015055649.tif 000014
【図９】
2015055649.tif 000015
【図１２】
2015055649.tif 000016