(57)【特許請求の範囲】
【請求項１】
複数のコマンドで構成された演奏情報に基づいて演奏を行う楽曲演奏装置であって、
前記コマンドに規定されている送信タイミングに基づいて、ソフトウェア音源で構成された演奏手段に前記コマンドを送信する送信処理と、
前記演奏情報中、前記送信タイミングが同時または略同時である関係を有する複数の前記コマンドからなるコマンド群を検出し、検出した前記コマンド群の内、先頭に位置する前記コマンド以外の少なくとも１つの前記コマンドについて、当該コマンドに規定されている前記送信タイミングに遅延量を付与したタイミングで、前記演奏手段に送信する遅延処理と、を実行することを特徴とする
楽曲演奏装置。
【請求項２】
前記コマンドは、ＭＩＤＩ規格に従って形成されていることを特徴とする
請求項１に記載の楽曲演奏装置。
【請求項３】
前記送信処理で付与する遅延量は、前記コマンド群中、先に位置する前記コマンドのデータ量に基づいて決定されることを特徴とする
請求項１または請求項２に記載の楽曲演奏装置。
【請求項４】
前記遅延処理を実行する第１演奏処理と、前記遅延処理を実行しない第２演奏処理とを、実行可能とし、
前記演奏情報の種別に従い、前記第１演奏処理もしくは前記第２演奏処理を実行することを特徴とする
請求項１から請求項３の何れか１項に記載の楽曲演奏装置。
【請求項５】
複数のコマンドで構成された演奏情報に基づいて演奏を行う楽曲演奏用プログラムであって、
前記コマンドに規定されている送信タイミングに基づいて、ソフトウェア音源で構成された演奏手段に前記コマンドを送信する送信処理と、
前記演奏情報中、前記送信タイミングが同時または略同時である関係を有する複数の前記コマンドからなるコマンド群を検出し、前記検出したコマンド群の内、先頭に位置する前記コマンド以外の少なくとも１つの前記コマンドについて、当該コマンドに規定されている前記送信タイミングに遅延量を付与したタイミングで、前記演奏手段に送信する遅延処理と、をコンピュータに実行させることを特徴とする
楽曲演奏用プログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、演奏情報を再生することで楽曲の演奏を行う楽曲演奏装置及び楽曲演奏用プログラムに関する。
【背景技術】
【０００２】
近年パーソナルコンピュータは、ＣＰＵやメモリの性能が向上するとともに価格が下がり広く普及している。これに伴ってパーソナルコンピュータで使用される各種ソフトウェアが多数開発され、機能および性能が向上している。ソフトウェア音源もその一つであり、ＣＰＵにより楽音を合成する技術およびその合成された楽音に効果を付与する技術が改良され、良質な楽音を形成できるようになっている。
【０００３】
特許文献１には、ソフトウェア音源の処理負荷が大きかったことを課題として、ＣＰＵにかかる負荷が所定の値より大きい場合、ＣＰＵに代え代替音源で楽音を合成する楽音合成装置が開示されている。このような楽音合成装置を使用することで、ＣＰＵにかかる負荷が大きい場合であっても、代替音源を使用することで、楽音の発生開始の遅れや、楽音の合成の途切れといった不具合を解消することが可能となっている。
【先行技術文献】
【特許文献】
【０００４】
【特許文献１】特開２００５−２８３７７４号公報
【発明の概要】
【発明が解決しようとする課題】
【０００５】
現在、ＣＰＵの処理能力の向上、メモリの大容量化に伴い、パーソナルコンピュータなどの各種情報処理装置の能力は、ソフトウェア音源を十分に扱うことのできるまでになっている。従来、カラオケ装置では、ハードウェア音源を使用することが主流であったが、このような処理能力の向上により、ソフトウェア音源を搭載することが検討されている。ソフトウェア音源は、良質な楽音を提供できるため、顧客誘引の要素として音質が求められるカラオケ装置には好適な機能である。また、ソフトウェア音源は、ソフトウェアのバージョンを上げることで、バグの修正、機能の追加などに対応可能であるため、各種メンテナンスの面においても好適な機能といえる。
【０００６】
ところで、カラオケ装置では、これまでに作成した楽曲情報を活用することが必要となる。楽曲情報は、ＭＩＤＩ規格を基本に作成されているため、ハードウェア音源用に作成した楽曲情報であってもソフトウェア音源で再生することが可能である。カラオケ装置において、ソフトウェア音源の搭載開発を進めるにあたり、従前にハードウェア音源用に作成した楽曲情報を、ソフトウェア音源で再生させた場合、聴取時に違和感が発生することが分かった。この違和感は、従前に作成したハードウェア音源用の楽曲情報を、ソフトウェア音源用に調整することで対応可能であるが、カラオケ装置で扱っている楽曲情報は数十万曲にも達するため、１曲ずつ調整することは不可能に近い。
【課題を解決するための手段】
【０００７】
本発明は、このような課題を解決することを目的とし、楽曲再生装置において良好な音質の楽曲を再生するため、以下の構成を採用するものである。
複数のコマンドで構成された演奏情報に基づいて演奏を行う楽曲演奏装置であって、
前記コマンドに規定されている送信タイミングに基づいて、ソフトウェア音源で構成された演奏手段に前記コマンドを送信する送信処理と、
前記演奏情報中、前記送信タイミングが同時または略同時である関係を有する複数の前記コマンドからなるコマンド群を検出し、検出した前記コマンド群の内、先頭に位置する前記コマンド以外の少なくとも１つの前記コマンドについて、当該コマンドに規定されている前記送信タイミングに遅延量を付与したタイミングで、前記演奏手段に送信する遅延処理と、を実行することを特徴とする。
【０００８】
さらに本発明に係る楽曲演奏装置において、
前記コマンドは、ＭＩＤＩ規格に従って形成されていることを特徴とする。
【０００９】
さらに本発明に係る楽曲演奏装置において、
前記送信処理で付与する遅延量は、前記コマンド群中、先に位置する前記コマンドのデータ量に基づいて決定されることを特徴とする。
【００１１】
さらに本発明に係る楽曲演奏装置は、
前記遅延処理を実行する第１演奏処理と、前記遅延処理を実行しない第２演奏処理とを、実行可能とし、
前記演奏情報の種別に従い、前記第１演奏処理もしくは前記第２演奏処理を実行することを特徴とする。
【００１２】
さらに本発明に係る楽曲演奏用プログラムは、
複数のコマンドで構成された演奏情報に基づいて演奏を行う楽曲演奏用プログラムであって、
前記コマンドに規定されている送信タイミングに基づいて、ソフトウェア音源で構成された演奏手段に前記コマンドを送信する送信処理と、
前記演奏情報中、前記送信タイミングが同時または略同時である関係を有する複数の前記コマンドからなるコマンド群を検出し、前記検出したコマンド群の内、先頭に位置する前記コマンド以外の少なくとも１つの前記コマンドについて、当該コマンドに規定されている前記送信タイミングに遅延量を付与したタイミングで、前記演奏手段に送信する遅延処理と、をコンピュータに実行させることを特徴とする。
【発明の効果】
【００１３】
本発明に係る楽曲再生装置、または、楽曲再生用プログラムによれば、例えば、ハードウェア音源のように、コマンドをシリアル転送する環境で作成された演奏情報を、ソフトウェア音源のように、複数のコマンドを同時、あるいは、短い時間で処理できる環境を使用して演奏する場合、聴取時の違和感を抑制することが可能となる。したがって、従前にハードウェア音源のために作成した演奏情報を、違和感なくソフトウェア音源で演奏することが可能となる。よって、ソフトウェア音源のために演奏情報を調整、あるいは、再度作成し直す必要がなく、既存の資産を活用することが可能となる。特に、膨大な数の演奏情報を扱うカラオケ装置において、ハードウェア音源からソフトウェア音源に変更する際、大きな効果を発揮する。
【００１４】
さらに本発明に係る楽曲再生装置、または、楽曲再生用プログラムによれば、演奏情報の種別に応じて、既存の演奏情報には第１演奏処理を使用し、ソフトウェア音源用に作成した演奏情報には第２演奏処理を使用することで、新旧、どちらの演奏情報に対しても、聴取時の違和感の抑制された演奏を楽しむことが可能となる。
【図面の簡単な説明】
【００１５】
【図１】本実施形態のカラオケシステムの構成を示す図
【図２】本実施形態の楽曲情報のデータ構成を示す図
【図３】ＭＩＤＩコマンドを使用した演奏情報の演奏を説明するための図
【図４】ハードウェア音源を使用した場合の波形生成を説明するための図
【図５】本実施形態のソフトウェア音源を使用した場合の波形生成を説明するための図
【図６】本実施形態の楽曲再生処理を示すフロー図
【図７】本実施形態のソフトウェア音源構成を示すブロック図
【図８】本実施形態の（第１、第２）演奏処理を示すフロー図
【図９】本実施形態の要求サンプルと単位サンプル（１ｍｓ時間）の関係を示す図
【図１０】本実施形態の第１演奏処理（遅延処理あり）を説明するための図
【図１１】本実施形態の第２演奏処理（遅延処理なし）を説明するための図
【発明を実施するための形態】
【００１６】
本実施形態の楽曲演奏装置について、カラオケ装置２を例にとって説明する。図１は、本発明の実施形態に係るカラオケシステムの構成を示す図である。本実施形態におけるカラオケシステムは、カラオケ装置２（コマンダ）と、リモコン装置１を含んで構成されている。なお、図１に示す例では、１台のカラオケ装置２に対して、リモコン装置１ａとリモコン装置１ｂ、２台のリモコン装置１が使用されている例である。これらリモコン装置１ａ、１ｂの構成は同一であるため、リモコン装置１として説明を行う。カラオケ装置２とリモコン装置１は、ＬＡＮ１００及びアクセスポイント１１０を利用してネットワークを形成するように接続されている。
【００１７】
カラオケボックスなどの店舗に設置されるカラオケ装置２は、楽曲情報を再生することで歌唱の伴奏を行う装置である。カラオケ装置２は、各構成を統括して制御するためのＣＰＵ３０、各種プログラムを実行するにあたって必要となる情報を一時記憶するためのメモリ２７を備えている。本実施形態のカラオケ装置２は、ハードウェア音源ではなく、ＣＰＵ３０上で動作するソフトウェア音源を使用して楽曲の演奏を行う形態となっている。ＣＰＵ３０は、ハードディスク３２等の記憶手段に記憶されている波形を読み出して、ＰＣＭ情報を合成し、音響制御部２５に出力する。音響制御部２５では、合成されたＰＣＭ情報と、マイクロホン４４ａ、４４ｂから入力される歌唱音声情報とを加算してスピーカ４２に出力する。
【００１８】
カラオケ装置２は、ユーザからの各種入力を受け付ける操作部２１を備える。カラオケ装置２は、操作部２１からの入力を解釈してＣＰＵ３０に伝達する操作処理部２２を備える。また、カラオケ装置２は、各種情報を記憶する記憶部としてのハードディスク３２を備える。カラオケ装置２は、ＬＡＮ１００に接続してネットワークに加入する通信手段としてのＬＡＮ通信部２４を備えている。
【００１９】
また、カラオケ装置２は、モニタ４１に対して歌詞映像、背景映像を表示させる映像再生手段を備える。この映像再生手段は、映像情報に基づいて映像を再生する映像再生部２９、再生する映像を一時的に蓄積するビデオＲＡＭ２８、再生された映像に対する歌詞テロップの重畳、映像効果を付与する映像制御部３１を備えて構成される。
【００２０】
さらに、このカラオケ装置２では、外部に接続されるモニタ４１以外に、タッチパネルモニタ３３に対して各種情報を表示することを可能としている。タッチパネルモニタ３３は映像制御部３１から入力された映像情報を表示する表示部３５と、タッチ入力された位置を操作処理部２２に出力するタッチパネル３４が重畳されて構成されている。このタッチパネルモニタ３３は、カラオケ装置２の操作部、あるいは、リモコン装置１のタッチパネルモニタ１１などと同様、入力部として機能する。ユーザは、タッチパネルモニタ３３にて楽曲を選択することで、直接カラオケ装置２に予約をさせるなど、カラオケ装置２に対する各種操作を行うことが可能である。
【００２１】
このような構成にてカラオケ装置２は、各種処理を実行することとなるが、カラオケ装置２の主な機能として、楽曲予約処理、楽曲再生処理などを実行可能としている。楽曲予約処理は、ユーザからの指定に基づいて楽曲を指定、予約するための処理であってリモコン装置１と連携して実行される。ユーザの操作により、リモコン装置１などの入力部で指定された予約情報をメモリ２７中の予約テーブルに登録する。楽曲再生処理は、予約された楽曲を再生させる処理であって、演奏処理と歌詞再生処理とが同期して実行される処理である。
【００２２】
演奏処理は、楽曲情報に含まれる演奏情報に基づいて演奏を行う処理である。本実施形態では、ＣＰＵ３０、メモリ２７等の制御手段を使用して演奏を行うソフトウェア音源の形態を採用している。なお、ソフトウェア音源に対し、波形合成の専用チップを使用するような形態の音源は、ハードウェア音源と呼ばれる。ソフトウェア音源としての制御手段で合成されたＰＣＭ情報は、音響制御部２５で合成され、マイクロホン４４ａ、４４ｂから入力される歌唱音声と一緒にスピーカ４２から放音される。歌詞再生処理は、楽曲情報に含まれる歌詞情報をモニタ４１に表示させることで歌唱補助を行う処理である。この歌詞再生処理で表示される歌詞に、背景映像を重畳させて表示させる背景映像表示処理を実行することとしてもよい。
【００２３】
一方、リモコン装置１は、歌唱する楽曲を選択する選曲処理を実行可能とし、予約情報などカラオケ装置２に対して各種指示を送信可能としている。また、リモコン装置１は、カラオケ装置２あるいはインターネット上に接続されたサーバ装置５から各種情報を受信し、ユーザに対して各種情報を提供することも可能である。本実施形態では、ユーザから各種指示を受け付けるユーザインターフェイスとして、操作部１７と、タッチパネルモニタ１１を備えている。タッチパネルモニタ１１は、表示部１１ａとタッチパネル１１ｂを有して構成され、表示部１１ａに各種インターフェイスを表示するとともに、ユーザからのタッチ入力を受付可能としている。
【００２４】
さらにリモコン装置１は、楽曲検索に必要とされるデータベース、各種プログラム、並びに、プログラム実行に伴って発生する各種情報を記憶する記憶部として、メモリ１４、そして、これら構成を統括して制御するためのリモコン側制御部を備えて構成される。リモコン側制御部には、ＣＰＵ１５、タッチパネルモニタ１１に対して表示する映像を形成する映像制御部１３、表示する映像情報を一時的に蓄えるビデオＲＡＭ１２、タッチパネルモニタ１１あるいは操作部１７からの入力を解釈してＣＰＵ１５に伝える操作処理部１８が含まれている。
【００２５】
また、リモコン装置１は、無線ＬＡＮ通信部１６によって、アクセスポイント１１０と無線接続されることで、ＬＡＮ１００によって構成されるネットワークに接続される。なお、各リモコン装置１は、特定のカラオケ装置２に対して事前に対応付けされている。リモコン装置１から出力される各種命令は、対応付けされたカラオケ装置２にて受信される。
【００２６】
このようなリモコン装置１の構成により、ユーザからの各種入力をタッチパネルモニタ１１、あるいは、操作部１７から受付けるとともに、映像情報をタッチパネルモニタ１１に表示することで、カラオケ装置２に対して楽曲予約などの各種指示を行うことが可能とされている。
【００２７】
図２は、カラオケ装置２で使用する楽曲情報のデータ構成を示す図である。楽曲情報は、楽曲情報に関連する各種情報であるメタ情報と、演奏等、各種処理を実行する実情報を含んで構成される。メタ情報には、楽曲情報を識別するための楽曲識別情報（楽曲ＩＤ）、楽曲名、歌手名などの楽曲関連情報が含まれている。
【００２８】
メタ情報中、ソフトウェア音源での使用を前提として作成された楽曲情報には、ソフトウェア音源フラグが含まれている。本実施形態のカラオケ装置２では、ハードウェア音源での使用を前提として作成された楽曲情報と、ハードウェア音源での使用を前提として作成された楽曲情報が再生され、特に、演奏情報の演奏処理については、両種別の楽曲情報で異なる形態の演奏処理が行われる。このソフトウェア音源フラグは、両種別の楽曲情報を判別するために設けられた識別子である。
【００２９】
カラオケ装置２では、従来、ハードウェア音源が使用されており、既存のカラオケ装置２で再生可能な楽曲は数十万曲にも上る数である。今回、新たにカラオケ装置２にソフトウェア音源を採用することで、新たな楽曲情報の作成はソフトウェア音源での使用を前提として行われる。本実施形態では、ソフトウェア音源での使用を前提として新たに作成された楽曲情報に対し、ソフトウェア音源フラグを付すことで、ハードウェア音源での使用を前提として作成された既存の楽曲情報を変更することなく、判別することが可能となっている。なお、ソフトウェア音源での使用を前提として作成された楽曲情報と、ハードウェア音源での使用を前提として作成された楽曲情報との判別は、このようなソフトウェア音源フラグを使用する形態に代え、楽曲情報のデータベースを使用して判別することや、楽曲情報の作成日によって判別するなど、各種形態を採用することが可能である。
【００３０】
楽曲情報の実情報には、演奏情報、歌詞情報が含まれている。演奏情報は、ＭＩＤＩ規格に基づいて音源を制御する制御情報を含んで構成された、カラオケの伴奏音を演奏するための情報である。歌詞情報は、歌唱補助のため、演奏情報に同期して表示される情報であり、演奏に同期して表示された歌詞の色替えを行うように構成することも可能である。
【００３１】
図３は、ＭＩＤＩコマンドを使用した演奏情報の演奏を説明するための図である。図３（Ａ）は、演奏情報の構成形態を示した図である。演奏情報は、複数のＭＩＤＩコマンドの列で構成されている。ＭＩＤＩコマンドを読み出すシーケンス処理は、図に示すように、上から下方向にＭＩＤＩコマンドを順次読み出して音源に引き渡す。各ＭＩＤＩコマンドは、デルタタイムＤＴとイベントデータＥＶの組み合わせで構成されている。デルタタイムＤＴは、前に位置するＭＩＤＩコマンドとの時間間隔を規定する情報であって、音符長に対応する数値である。例えば、全音符の分解能を４８０とした場合、デルタタイムＤＴ＝１２０は、前のＭＩＤＩコマンドから四分音符の長さを空けて、イベントデータＥＶを実行することを意味する。また、デルタタイムＤＴ＝０は、前のＭＩＤＩコマンドと間隔を空けることなく（同時に）、イベントデータＥＶを実行することを意味する。
【００３２】
図３（Ｂ）は、図３（Ａ）のＭＩＤＩコマンドに含まれるイベントデータＥＶの実行タイミングが示されている。演奏情報中に記述されるイベント１は、その前に記述されたＭＩＤＩコマンドから、デルタタイムＤＴ＝１２０の間隔を有する時間Ｔ１のタイミングで実行される。イベント１に続いて記述されたイベント２は、時間Ｔ１からデルタタイムＤＴ＝１２０の間隔を有する時間Ｔ２のタイミングで実行される。全部音符の分解能が４８０の場合、時間Ｔ１と時間Ｔ２の間隔は四分音符の時間長となる。イベント２に続いて記述されたイベント３は、時間Ｔ２からデルタタイムＤＴ＝０、すなわち、イベント２と同じ時間Ｔ２のタイミングで実行される。イベント３に続いて記述されたイベント４は、時間Ｔ２からデルタタイムＤＴ＝１８０の間隔を有する時間Ｔ３のタイミングで実行される。全部音符の分解能が４８０の場合、時間Ｔ１と時間Ｔ２の間隔は付点四分音符の時間長となる。
【００３３】
イベントデータＥＶは、音源を制御する各種命令を規定したデータである。このイベントデータＥＶには、発音開始を指示するノートオンデータ、発音終了を指示するノートオフデータ、音源に対し各種制御を指示するコントロールチェンジデータ、独自に定めた各種制御を指示するエクスクルーシブデータ等が含まれる。このように、イベントデータＥＶとその実行タイミングを規定したデルタタイムＤＴの組み合わせからなるＭＩＤＩコマンドを使用して、楽曲の演奏が実行される。
【００３４】
図４は、本実施形態のハードウェア音源を使用した場合の波形生成を説明するための図である。ここでは、２つの音を同時に発音させる場合を例にとって説明する。図４（Ａ）に示す様に、ノートオンＡとノートオンＢは、ノートオンＢに対応して記述されているイベントデータＥＶ＝０により、２つの音を同時に発音させることが規定されている。ハードウェア音源では、情報を伝送する際、シリアル転送が用いられる。したがって、演奏情報の伝送は、演奏情報に記述された順序で行われることになり、図４（Ａ）の場合、ノートオンＡ、ノートオンＢの順で転送され、実際には、ノートオンＢは、ノートオンＡよりも遅れて実行されることになる。
【００３５】
図４（Ｂ−１）には、２つのイベントデータＥＶの実際の伝送の様子を模式的に示している。ノートオンＡがハードウェア音源に伝送された後、ノートオンＡのデータ量の伝送部に対応する遅延時間ｄｔの後、ノートオンＢがハードウェア音源に伝送されることになる。図４（Ｂ−２）には、ハードウェア音源において、２つのイベントデータの伝送に従って発生する音声波形について、上半分のエンベロープ（包絡線）を示したものである。理解を容易にするため、ノートオンＡとノートオンＢは同じ波形を発生するイベントデータＥＶとしている。ノートオンＡとノートオンＢの実行タイミングは、遅延時間ｄｔを伴うため、ノートオンＡによって発生する音声波形Ｗａ（実線）とノートオンＢによって発生する音声波形Ｗｂ（破線）の間にも遅延時間が発生することになる。図４（Ｂ−３）に示されるように、実際に聴取する合成波形は、音声波形Ｗａと遅延時間ｄｔを伴って発生した音声波形Ｗｂの和となる。
【００３６】
次に、ソフトウェア音源を使用した場合の波形生成について説明を行う。図５は、本実施形態のソフトウェア音源を使用した場合の波形生成を説明するための図である。ソフトウェア音源では、情報の伝送にシリアル転送を使用していない。そのため、図４で説明したようなシリアル転送に伴う遅延時間が発生しない。ここでは、図４と同じデータ構成の２つのＭＩＤＩコマンドを、ソフトウェア音源を使用して発音させた場合について説明を行う。
【００３７】
ソフトウェア音源では、シリアル転送を使用しないため、情報伝送に伴う遅延が発生しない。図４（Ａ）と同じ図５（Ａ）に示されるノートオンＡとノートオンＢを発音させる場合を考えてみる。これら２つのイベントデータＥＶは、図５（Ｂ−１）に示されているように、ソフトウェア音源では、時間Ｔａにおいて同時に実行される。図５（Ｂ−２）には、図４（Ｂ−２）には、ハードウェア音源において、２つのイベントデータの伝送に従って発生する音声波形について、上半分のエンベロープ（包絡線）を示したものである。ノートオンＡとノートオンＢは同じ波形を発生するイベントデータＥＶを想定しているため、両波形は同一となる。分かりやすくするため図５（Ｂ−２）では、ノートオンＡによって発生する音声波形Ｗａ（実線）とノートオンＢによって発生する音声波形Ｗｂ（破線）を僅かにずらして記載している。実際には、音声波形Ｗａと音声波形Ｗｂの間には、遅延は発生しない。
【００３８】
実際に聴取する合成波形は、図５（Ｂ−３）に示されるように、音声波形Ｗａと音声波形Ｗｂの和となる。ここでは、各音声波形の最大値をＡとした場合、加算した音声波形の最大値は２Ａとなることが想定できる。図５（Ｂ−３）には、図４（Ｂ−３）の振幅Ｂで示した音声波形のエンベロープ（破線）を同時に示している。ハードウェア音源を使用した場合の合成波形の振幅Ｂは、ソフトウェア音源を使用した場合の合成波形の振幅２Ａよりも小さいことが分かる。これは、ハードウェア音源におけるシリアル転送に基づき発生する遅延時間によるものである。
【００３９】
カラオケ装置２では、従来、ハードウェア音源を使用して演奏情報の作成が行われていた。したがって、演奏情報に対するチューンアップは、実際に演奏されるカラオケ装置２、あるいは、それに搭載されたハードウェア音源で聴取することで行われている。したがって、従来のハードウェア音源を使用した環境化で作成された演奏情報は、いわば、ハードウェア音源に適化されたものであって、シリアル転送を使用しないソフトウェア音源での使用を想定していないものであった。今回、新たに、カラオケ装置２において、ソフトウェア音源を採用するにあたり、既存の演奏情報（ハードウェア音源の環境下で作成された演奏情報）を再生させた場合、シリアル転送を使用しないことを理由とした聴取上の違和感が発生することが分かった。例えば、図５（Ｂ−２）で説明した様に、ハードウェア音源の環境下では振幅Ｂの音量で再生されていたところ、ソフトウェア音源の環境下では、振幅２Ａ（２Ａ＞Ｂ）の音量で再生されてしまうこと等である。
【００４０】
本実施形態では、このような事情を鑑みなされたものであって、ハードウェア音源の環境下で作成された演奏情報をソフトウェア音源で演奏させる場合の違和感を抑制することを目的とするものである。
【００４１】
図６は、本実施形態の楽曲再生処理を示すフロー図である。図１のカラオケシステムにおいて、リモコン装置１から送信された予約情報は、カラオケ装置２のメモリ２７で管理する予約テーブルに順次記憶される。カラオケ装置２は、予約テーブルのチェックを行い（Ｓ１０１）、次に再生すべき再生の楽曲があると判定された場合（Ｓ１０２：Ｙｅｓ）、予約情報中に規定された楽曲情報をハードディスク３２から読み出す（Ｓ１０３）。そして、楽曲情報のメタ情報中にソフトウェア音源フラグが記述されているか否かを確認する（Ｓ１０４）。本実施形態では、既存の楽曲情報のように、ハードウェア音源の環境下で作成された演奏情報と、ソフトウェア音源の環境下で作成された演奏情報との間で異なる演奏処理を行うこととしている。このような形態により、ハードウェア音源の環境下、あるいは、ソフトウェア音源の環境下で作成された演奏情報のどちらについても違和感なく演奏を行うことを可能としている。
【００４２】
ソフトウェア音源フラグが無い楽曲情報は、第１演奏処理（Ｓ２００）を使用して演奏情報の演奏が実行される。一方、ソフトウェア音源フラグが付された楽曲情報は、第２演奏処理（Ｓ２００’）を使用して演奏情報の演奏が実行される。なお、このフロー図には記載していないが、カラオケ装置２では、楽曲情報に含まれる歌詞情報に基づいて歌詞再生処理も併せて実行される。
【００４３】
では、本実施形態のカラオケ装置２で使用するソフトウェア音源について、その構成、及び、演奏処理について説明する。図７は、本実施形態のソフトウェア音源構成を示すブロック図である。ソフトウェア音源は、図１で説明したカラオケ装置２中のＣＰＵ３００、メモリ２７等の制御手段、そして、ソフトウェア音源を実現するためのプログラムを使用して実現される。図７は、ソフトウェア音源の機能を、ブロック図で説明したものである。
【００４４】
ＣＰＵ３００は、シーケンサ３０１、ＭＩＤＩコマンド受信手段３０２、シンセサイザ３０４といった機能を受け持つ。シーケンサ３０１は、演奏情報を構成するＭＩＤＩコマンドをハードディスク３２から読み出し、合成波形としてのＰＣＭ情報を音響制御部２５に出力する機能を有する。ＭＩＤＩコマンドに応じて生成されたＰＣＭ情報は、音響制御部２５からスピーカ４２へ出力することで演奏情報は演奏音となって楽曲情報が再生されることとなる。このシーケンサ３０１は、ＭＩＤＩコマンドの入力を管理するＭＩＤＩ管理手段３０１ａと、ＰＣＭ情報の出力を管理するＰＣＭ管理手段３０１ｂ、ＰＣＭ情報を蓄積するバッファ２７ｃを有して構成される。なお、紙面の都合上、バッファ２７ｃはＣＰＵ３００内に位置しているが、メモリ２７など、ＣＰＵ３００の外部に設けられた記憶手段を使用することが一般的である。バッファ２７ｃは、蓄積しているＰＣＭ情報を、所定のサンプリングレートに従って、音響制御部２５に出力する。ＰＣＭ管理手段３０１ｂは、バッファ２７ｃ内のＰＣＭ情報の蓄積量を監視し、ＰＣＭ情報が必要になった場合、シンセサイザ３０４にＰＣＭ生成指示を出力する（丸４）。
【００４５】
ＭＩＤＩコマンド受信手段３０２は、シーケンサ３０１から送信（丸１）されたＭＩＤＩコマンドを受信し、受信したＭＩＤＩコマンドをメモリ２７内の一部領域を使用して形成されたリングバッファ２７ａに格納する（丸２）。なお、ＭＩＤＩコマンド受信手段３０２は、ＭＩＤＩコマンドを受信した場合、確認の意を有する応答信号をＭＩＤＩ管理手段３０１ａに返信する（丸３）。シンセサイザ３０４（本発明に係る「演奏手段」に相当）は、リングバッファ２７ａに記憶されたＭＩＤＩコマンドに記述されたイベントデータＥＶをデルタタイムＤＴに基づいて取り出し（丸５）、キャッシュ２７ｂに蓄積した音声波形を読み出してＰＣＭ情報を合成し（丸６）、ＰＣＭ情報を出力する（丸８）機能を有する。また、シンセサイザ３０４は、ＤＳＰ機能を有しており、音声波形に対して各種音響効果を付与する（丸７）ことが可能である。
【００４６】
図８は、本実施形態の（第１、第２）演奏処理を示すフロー図である。図６の楽曲再生処理で説明したように、ハードウェア音源の環境下で作成された演奏情報は第１演奏処理（Ｓ２００）を、ソフト音源の環境下で作成された演奏情報は第２演奏処理（Ｓ２００’）を使用して楽曲の演奏が行われるが、両演奏処理（Ｓ２００とＳ２００’）は、遅延処理の有無において異なるため、ここでは１のフロー図を使用して説明する。
【００４７】
演奏処理が開始されると、メモリ２７上において、リングバッファ２７ａ、キャッシュ２７ｂ、バッファ２７ｃの確保、シンセサイザ３０４の初期値設定等、初期化処理が実行される（Ｓ２０１）。ソフトウェア音源中、ＭＩＤＩ管理手段３０１ａは、楽曲の再生状況などに応じて、ハードディスク３２からＭＩＤＩデータを読み出して、ＭＩＤＩコマンド受信手段３０２へ出力する。ＭＩＤＩコマンド受信手段３０２は、ＭＩＤＩコマンドが入力される（Ｓ２０２：Ｙｅｓ）と、受信したＭＩＤＩデータをリングバッファ２７ａに書き込む（Ｓ２０３）。シンセサイザ３０４は、ＰＣＭ管理手段３０１ｂからＰＣＭ生成指示を待つ（Ｓ２０４）。ＰＣＭ生成指示は、バッファ２７ｃの蓄積状況に応じてＰＣＭ管理手段３０１ｂから出力される指示である。このＰＣＭ生成指示には、必要なＰＣＭ情報の情報量を示す要求サンプル数が含まれている。ＰＣＭ生成指示を受信した場合（Ｓ２０４：Ｙｅｓ）、シンセサイザ３０４は、受信した要求サンプル数分のＰＣＭ情報の生成が完了するまで、Ｓ２０６〜Ｓ２０９繰り返し、単位サンプル分（この例では、１ｍｓ時間分）分毎にＰＣＭ情報を生成する。
【００４８】
図９には、本実施形態の要求サンプルと単位サンプル（１ｍｓ時間）の関係を示した図である。要求サンプルは、バッファ２７ｃの蓄積量等に基づいて可変する値である。図９の場合、要求サンプルは、１５の単位サンプルを必要とした場合となっており、この要求サンプルを受信したシンセサイザ３０４は、Ｓ２０４〜Ｓ２０７を１５回繰り返し実行して、１５ｍｓ時間分のＰＣＭ情報を生成する。ＰＣＭ情報の生成は、まず、今回生成する単位サンプル内に、反映させるイベントデータＥＶがあるか否かを確認する（Ｓ２０６）。これはＭＩＤＩコマンド中に規定されているデルタタイムＤＴに基づいて行われる。反映すべきイベントデータＥＶがある場合（Ｓ２０６：Ｙｅｓ）、当該イベントデータＥＶをリングバッファ２７ａから読み出して（Ｓ２０７）、当該イベントデータＥＶに基づく処理を実行する。例えば、イベントデータＥＶがノートオンの場合、キャッシュ２７ｂに蓄積した音声波形を読み出して、合成波形の生成を開始する。なお、本実施形態では、リングバッファ２７ａに蓄積されたＭＩＤＩコマンドを先読みし、必要となる音声波形を予めハードディスク３２からキャッシュ２７ｂに読み出すこととしており、シンセサイザ３０４の波形合成において、迅速な音声波形の読み出しを可能としている。
【００４９】
シンセサイザ３０４では、新たに読み出したイベントデータと先に読み出したイベントデータに基づいて、単位サンプル（１ｍｓ時間）分のＰＣＭ情報を生成する（Ｓ２０８）。そして、生成したＰＣＭ情報に各種音響効果を付与するＤＳＰ処理を施し、シーケンサ３０１内のバッファ２７ｃに出力する。単位サンプル分毎に繰り返し、Ｓ２０６〜Ｓ２０９の処理を実行することで、要求サンプル数分のＰＣＭ情報の生成が完了する（Ｓ２０５：Ｙｅｓ）と、演奏終了の確認を行う（Ｓ２１０）。演奏終了で無い場合（Ｓ２１０：Ｎｏ）、ＭＩＤＩコマンドの入力（Ｓ２０２）、もしくは、ＰＣＭ生成指示の受信を待つ。一方、演奏が終了した場合（Ｓ２１０：Ｙｅｓ）、メモリ２７上に確保したリングバッファ２７ａ、キャッシュ２７ｂ、バッファ２７ｃ等、リソース開放を行う等の終了処理（Ｓ２１１）を実行し、一連の演奏処理を終了する。
【００５０】
以上、本実施形態のソフトウェア音源では、シリアル転送を行うハードウェア音源と異なり、演奏情報中、同時に行うことが規定されたイベントデータＥＶは、遅延なく同時に実行することが可能である。そのため、音響的に優れた演奏を行うできる反面、図４、図５で説明した様に、ハードウェア音源での使用を前提として作成された演奏情報は、鳥瞰的な違和感を伴うことがある。そのため、本実施形態の第１演奏処理では、ハードウェア音源での使用を前提として作成された演奏情報の演奏において、遅延処理を施すことで、従来のハードウェア音源と同様の演奏を行い、演奏上の違和感の抑制を図ることとしている。
【００５１】
図１０は、本実施形態の第１演奏処理（遅延処理あり）を説明するための図である。この第１演奏処理は、ソフトウェア音源フラグが付されていない楽曲情報に含まれる演奏情報、すなわち、ハードウェア音源での使用を前提として作成された演奏情報に対して行われる処理であり、特に、演奏情報中、同時に実行することが規定されたイベントデータＥＶに対し、遅延処理を行うことを特徴としている。
【００５２】
図１０（Ａ）は、演奏情報中、同時に実行することが規定された３つのイベントデータＥＶを含む部分を記載したものである。イベントＢに付されたデルタタイムＤＴ、イベントＣに付されたデルタタイムＤＴは、共に「０」であり、３つのイベントデータＥＶは、同時に実行されることが規定されている。
【００５３】
このような演奏情報をソフトウェア音源で演奏させた場合、各イベントデータＥＶは忠実に同タイミングで実行されることになる。本実施形態では、ハードウェア音源での実行を模擬するため遅延処理を施すこととしている。遅延処理は、同時に実行する複数のイベントデータＥＶ中、先頭に記述されたイベントデータＥＶ以外に対して行われる。図１０の例では、イベントＢ、イベントＣに対して遅延が施される。遅延量は、前に位置するイベントデータＥＶのデータ量に基づいて決定される。
【００５４】
イベントＡの実行タイミングが、時間Ｔ１の場合、イベントＢの実行タイミングは、時間Ｔ１に遅延時間Ｄ１を付与した時間Ｔ２のタイミングで実行される。図７のブロック図では、このタイミングでリングバッファ２７ａから読み出されることになる。この遅延時間Ｄ１は、前に位置するイベントＡのデータ量Ｌａにシリアル転送速度Ｖｔを乗算（Ｄ１＝Ｌａ*Ｖｔ）して算出される。同様に、イベントＣの実行タイミングは、時間Ｔ２に遅延時間Ｄ２を付与した時間Ｔ３のタイミングで実行される。遅延時間Ｄ２は、前に位置するイベントＢのデータ量Ｌｂに、ハードウェア音源で使用するシリアル転送速度Ｖｔを乗算（Ｄ２＝Ｌｂ*Ｖｔ）して算出される。イベントＣの実行タイミングである時間Ｔ３は、時間Ｔ１から遅延時間Ｄ３を付与したタイミングでもある。この遅延時間Ｄ３は、前に位置するイベントＡとイベントＢのデータ量（Ｌａ＋Ｌｂ）にシリアル転送速度Ｖｔを乗算（Ｄ３＝（Ｌａ＋Ｌｂ）*Ｖｔ）して算出される。なお、遅延時間Ｄ１〜Ｄ３の値は、このように、前に位置するイベントデータＥＶのデータ量のみならず、他の要素を含んで算出されることとしてもよい。このように本実施形態では、ハードウェア音源での使用を前提として作成された演奏情報をソフトウェア音源で演奏する際、遅延処理を伴う演奏処理（第１演奏処理）を行うことで、ハードウェア音源での演奏を模擬し、聴取上の違和感を抑制することが可能となる。
【００５５】
図１１には、本実施形態の第２演奏処理（遅延処理なし）を説明するための図が示されている。一方、新たに形成した楽曲情報など、ソフトウェア音源での使用を前提として作成された演奏情報は、遅延処理を伴わない第２演奏処理を使用した演奏が行われる。この第２演奏処理では、ＭＩＤＩコマンドに規定されているタイミングでイベントデータＥＶが実行される。図１１（Ａ）は、図１０（Ａ）と同様、演奏情報中、同時に実行することが規定された３つのイベントデータＥＶを含む部分を記載したものである。第２演奏処理では、ソフトウェア音源での使用を前提として形成された演奏情報を対象とするため、図１０のような遅延時間は設けない。すなわち、同時に実行することが規定されたＭＩＤＩコマンドは、図１１（Ｂ）に示す様に、時間Ｔ１で同時に実行されることになる。ソフトウェア音源での使用を前提として形成された演奏情報は、ソフトウェア音源での聴取テストなどが行われ、ソフトウェア音源上での演奏が最適化されているため、図４、図５で説明した様な問題も発生しない。また、シリアル転送を必要としないため、コマンド実行のレスポンスが高く、良好な演奏を行うことも可能である。
【００５６】
以上、カラオケ装置２を例に取って、本実施形態の楽曲演奏装置を説明したが、楽曲演奏装置では、同時に実行することが規定されたコマンド（ＭＩＤＩコマンド）について、少なくとも１つのコマンドに遅延を施すことで、ハードウェア音源の様な他の形態で作成された演奏情報であっても違和感を抑えた演奏を行うことが可能である。なお、明細書中では、同時に実行することが規定されたコマンド（ＭＩＤＩコマンド）をコマンド群として特定し、遅延処理の対象としているが、コマンド群の特定は、このような形態以外に、実行間隔が短い複数のコマンドをコマンド群の対象として規定するなど各種形態を採用することが可能である。また、本実施形態の楽曲演奏装置は、カラオケ装置２のみならず、電子楽器など他の装置に適用することが可能である。あるいは、パソコン、スマートホンなどの携帯端末、ゲーム機などの各種コンピュータで実行可能な楽曲演奏用プログラムとして提供することも可能である。
【符号の説明】
【００５７】
１（１ａ、１ｂ）：リモコン装置         ２７ｃ：バッファ
２：カラオケ装置                       ２８：ビデオＲＡＭ
５：サーバ装置                         ２９：映像再生部
１１：タッチパネルモニタ               ３０：ＣＰＵ
１１ａ：表示部                         ３１：映像制御部
１１ｂ：タッチパネル                   ３２：ハードディスク
１２：ビデオＲＡＭ                     ３３：タッチパネルモニタ
１３：映像制御部                       ３４：タッチパネル
１４：メモリ                           ３５：表示部
１５：ＣＰＵ                           ４１：モニタ
１６：無線ＬＡＮ通信部                 ４２：スピーカ
１７：操作部                           ４４ａ、４４ｂ：マイクロホン
１８：操作処理部                       １１０：アクセスポイント
２１：操作部                           ３００：ＣＰＵ
２２：操作処理部                       ３０１：シーケンサ
２４：ＬＡＮ通信部                     ３０１ａ：ＭＩＤＩ管理手段
２５：音響制御部                       ３０１ｂ：ＰＣＭ管理手段
２７：メモリ                           ３０２：ＭＩＤＩコマンド受信手段
２７ａ：リングバッファ                 ３０４：シンセサイザ
２７ｂ：キャッシュ
【図１】
0006464824.tif 000002
【図２】
0006464824.tif 000003
【図３】
0006464824.tif 000004
【図４】
0006464824.tif 000005
【図５】
0006464824.tif 000006
【図６】
0006464824.tif 000007
【図７】
0006464824.tif 000008
【図８】
0006464824.tif 000009
【図９】
0006464824.tif 000010
【図１０】
0006464824.tif 000011
【図１１】
0006464824.tif 000012