(57)【要約】【課題】楽曲の拍子を変えることが可能な新規な情報処理プログラム等を提供し、また、楽曲の小節の途中を再生中であってもリアルタイムに楽曲の拍子を変化させることが可能な情報処理プログラム等を提供すること。【解決手段】情報処理プログラムは、１又は複数のトラックからなる楽曲を再生する情報処理装置のコンピュータを、楽曲を再生する再生手段と、再生手段で楽曲を再生中に拍子を変更する拍子変更手段と、変更された拍子に基づいて、現在再生中の楽曲の小節内で次に再生する拍を再生手段に再生させるか否かを繰り返し判定する判定手段として機能させる。そして、再生手段は、判定手段による判定結果に基づいて楽曲を再生する。【選択図】図３
2013105085.tif 000002
【特許請求の範囲】
【請求項１】
１又は複数のトラックからなる楽曲を再生する情報処理装置のコンピュータにおいて実行される情報処理プログラムであって、
前記コンピュータを、
前記楽曲を再生する再生手段と、
前記再生手段で前記楽曲を再生中に拍子を変更する拍子変更手段と、
前記変更された拍子に基づいて、現在再生中の前記楽曲の小節内で次に再生する拍を前記再生手段に再生させるか否かを繰り返し判定する判定手段として機能させ、
前記再生手段は、前記判定手段による判定結果に基づいて前記楽曲を再生する、情報処理プログラム。
【請求項２】
前記楽曲には、第１の拍子用トラックと第２の拍子用トラックとが含まれ、
前記再生手段は、
前記拍子変更手段によって変更された前記拍子が第１の拍子であるとき、前記第１の拍子用トラックを有音で再生するとともに、前記第２の拍子用トラックを無音で再生し、
前記拍子変更手段によって変更された前記拍子が前記第１の拍子とは異なる第２の拍子であるとき、前記第１の拍子用トラックを無音で再生するとともに、前記第２の拍子用トラックを有音で再生する、請求項１に記載の情報処理プログラム。
【請求項３】
前記第２の拍子用トラックは、前記第１の拍子用トラックと同一の旋律を、前記第２の拍子向けに調整することによって生成されたトラックである、請求項２に記載の情報処理プログラム。
【請求項４】
前記第１の拍子は、前記第２の拍子よりも大きい、請求項２または３に記載の情報処理プログラム。
【請求項５】
前記再生手段は、
前記判定手段による判定結果が否定である場合には、前記次に再生する拍を再生せず、
前記判定手段による判定結果が肯定である場合には、前記次に再生する拍をそのまま再生する、請求項１から４のいずれかに記載の情報処理プログラム。
【請求項６】
前記判定手段は、
小節内での次に再生する拍の順番が、前記拍子変更手段によって変更された拍子の数以下である場合には、当該次に再生する拍を前記再生手段にそのまま再生させる、と判定し、
小節内での次に再生する拍の順番が、前記拍子変更手段によって変更された拍子の数よりも大きい場合には、当該次に再生する拍を前記再生手段に再生させない、と判定する、請求項１から５のいずれかに記載の情報処理プログラム。
【請求項７】
前記再生手段は、前記判定手段による判定結果が否定である場合には、次の小節の第１拍目の再生を開始する、請求項６に記載の情報処理プログラム。
【請求項８】
前記判定手段は、所定の間隔で繰り返し判定する請求項１から７のいずれかに記載の情報処理プログラム。
【請求項９】
前記所定の間隔は、拍の間隔もしくは当該拍の間隔よりも短い間隔である請求項８に記載の情報処理プログラム。
【請求項１０】
前記再生手段は、前記拍子変更手段によって前記拍子が前記第１の拍子と前記第２の拍子との間で切り替えられると、前記第１の拍子用トラックと前記第２の拍子用トラックの有音／無音の切り替えをクロスフェードで切り替える、請求項２から４のいずれかに記載の情報処理プログラム。
【請求項１１】
前記コンピュータを、ユーザからの入力を受け付ける入力受付手段としてさらに機能させ、
前記拍子変更手段は、前記入力受付手段が受け付けたユーザからの入力に基づいて、前記楽曲データを再生させる際の拍子を変更する、請求項１から１０のいずれかに記載の情報処理プログラム。
【請求項１２】
前記入力受付手段が受け付けたユーザからの入力は、前記楽曲データを再生する際の拍子を変更する処理以外の処理に用いられる、請求項１１に記載の情報処理プログラム。
【請求項１３】
１又は複数のトラックからなる楽曲を再生する情報処理装置であって、
前記楽曲を再生する再生手段と、
前記再生手段で前記楽曲を再生中に拍子を変更する拍子変更手段と、
前記変更された拍子に基づいて、現在再生中の前記楽曲の小節内で次に再生する拍を前記再生手段に再生させるか否かを繰り返し判定する判定手段とを備え、
前記再生手段は、前記判定手段による判定結果に基づいて前記楽曲を再生する、情報処理装置。
【請求項１４】
１又は複数のトラックからなる楽曲を再生する情報処理システムであって、
前記楽曲を再生する再生手段と、
前記再生手段で前記楽曲を再生中に拍子を変更する拍子変更手段と、
前記変更された拍子に基づいて、現在再生中の前記楽曲の小節内で次に再生する拍を前記再生手段に再生させるか否かを繰り返し判定する判定手段とを備え、
前記再生手段は、前記判定手段による判定結果に基づいて前記楽曲を再生する、情報処理システム。
【請求項１５】
１又は複数のトラックからなる楽曲を再生する情報処理方法であって、
前記楽曲を再生する再生ステップと、
前記再生ステップで前記楽曲を再生中に拍子を変更する拍子変更ステップと、
前記変更された拍子に基づいて、現在再生中の前記楽曲の小節内で次に再生する拍を前記再生ステップで再生するか否かを繰り返し判定する判定ステップとを備え、
前記再生ステップでは、前記判定ステップでの判定結果に基づいて前記楽曲を再生する、情報処理方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、情報処理プログラム、情報処理装置、情報処理システム及び情報処理方法に関し、より特定的には、楽曲の再生を行う情報処理プログラム、情報処理装置、情報処理システム及び情報処理方法に関する。
【背景技術】
【０００２】
従来、複数のトラックで構成された楽曲データを再生する楽曲演奏装置や、当該楽曲演奏装置における楽曲演奏プログラムがある（例えば、特許文献１）。
【先行技術文献】
【特許文献】
【０００３】
【特許文献１】特開２００９−２１０９１７号公報
【発明の概要】
【発明が解決しようとする課題】
【０００４】
しかし、特許文献１に記載の楽曲演奏プログラムでは、楽曲データを処理（再生）中に再生中の楽曲の拍子を切り替えることはできなかった。
【０００５】
それゆえに、この発明の主たる目的は、楽曲の拍子を変えることが可能な新規な、情報処理プログラム、情報処理装置、情報処理システム及び情報処理方法を提供することである。また、この発明の他の目的は、楽曲の小節の途中を再生中であってもリアルタイムに楽曲の拍子を変化させることが可能な情報処理プログラム、情報処理装置、情報処理システム及び情報処理方法を提供することである。
【課題を解決するための手段】
【０００６】
本発明は、上述の課題を解決するために、以下の構成を採用した。
【０００７】
本発明に係る情報処理プログラムは、１又は複数のトラックからなる楽曲を再生する情報処理装置のコンピュータを、楽曲を再生する再生手段と、再生手段で楽曲を再生中に拍子を変更する拍子変更手段と、変更された拍子に基づいて、現在再生中の楽曲の小節内で次に再生する拍を再生手段に再生させるか否かを繰り返し判定する判定手段として機能させる。そして、再生手段は、判定手段による判定結果に基づいて楽曲を再生する。
【０００８】
本構成によれば、拍子変更手段によって、楽曲が再生される際の拍子が変更され、判定手段によって、この拍子に基づいて小節内で次に再生する予定の拍（直後の拍）が再生されるか否かが判定される。すなわち、変更された拍子に応じて、楽曲は、小節内の拍単位で次に再生されるか否かが決定される。このことにより、楽曲の小節の途中が再生中であっても、リアルタイムに、変更された拍子に応じて、拍単位で楽曲の再生を調整することができる。
【０００９】
楽曲には、第１の拍子用トラックと第２の拍子用トラックとが含まれ、再生手段は、以下のように再生するものとしてもよい。すなわち、再生手段は、拍子変更手段によって変更された拍子が第１の拍子であるとき、第１の拍子用トラックを有音で再生するとともに、第２の拍子用トラックを無音で再生し、拍子変更手段によって変更された拍子が第１の拍子とは異なる第２の拍子であるとき、第１の拍子用トラックを無音で再生するとともに、第２の拍子用トラックを有音で再生する。
【００１０】
本構成によれば、第１の拍子用トラックと第２の拍子用トラックが並行して再生されており、楽曲が再生される際の拍子が第１の拍子である場合には、第２の拍子用トラックは無音で再生され、楽曲が再生される際の拍子が第２の拍子である場合には、第１の拍子用トラックは無音で再生される。このことにより、ユーザには、楽曲が再生される際の拍子に応じたトラックの音だけが聞こえる。また、２つのトラックは並行して再生されているので、小節や拍の順序がずれることがない。このため、拍子を切り替えたタイミングで、再生中のトラックの再生を停止し、停止中のトラックの再生を開始する場合に比べて、切り替えるタイミングのずれによって楽曲が不自然に聞こえてしまうということがなく、また、拍子を切り替えるタイミングを合わせるための調整が必要ない。
【００１１】
第２の拍子用トラックは、第１の拍子用トラックと同一の旋律を、第２の拍子向けに調整することによって生成されたトラックであってもよい。
【００１２】
本構成によれば、第２の拍子用トラックは、第１の拍子用トラックと同一の旋律が調整されたものであるので、楽曲が再生される際の拍子に合わせて、ユーザに違和感のない楽曲を提供することができる。
【００１３】
第１の拍子は、第２の拍子よりも大きくてもよい。
【００１４】
本構成によれば、第２の拍子用トラックは、第１の拍子よりも小さな第２の拍子向けに調整されたトラックである。すなわち、第１の拍子を、変更される可能性がある複数の拍子のうちの最大の拍子とすることで、それよりも小さな第２の拍子向けのトラックは、第１の拍子用トラックに基づいて生成することができる。
【００１５】
再生手段は、判定手段による判定結果が否定である場合には、次に再生する拍を再生せず、判定手段による判定結果が肯定である場合には、次に再生する拍をそのまま再生するものとしてもよい。
【００１６】
本構成によれば、判定結果に応じて、次に再生する予定の拍が再生されるか否かが決定される。このことにより、楽曲の小節の途中が再生中であっても、拍単位で楽曲の再生を調整することができる。
【００１７】
判定手段は、以下のように判定するものとしてもよい。すなわち、判定手段は、小節内での次に再生する拍の順番が、拍子変更手段によって変更された拍子の数以下である場合には、当該次に再生する拍を再生手段にそのまま再生させる、と判定し、小節内での次に再生する拍の順番が、拍子変更手段によって変更された拍子の数よりも大きい場合には、当該次に再生する拍を再生手段に再生させない、と判定する。
【００１８】
本構成によれば、小節内での次に再生する予定の拍の順番と、拍子変更手段によって変更された楽曲が再生される際の拍子の数との大きさを比較した結果に応じて、当該次に再生する予定の拍が再生されるか、再生されないかが決定される。具体的には、例えば、変更された楽曲が再生される際の拍子の数が３拍子である場合には、小節内での次に再生する予定の第３拍目は再生されるが、次に再生する予定の第４拍目は再生されない。このことにより、楽曲の小節の途中が再生中であっても、リアルタイムに、変更された拍子に応じて、拍単位で楽曲の再生を調整することができる。
【００１９】
再生手段は、判定手段による判定結果が否定である場合には、次の小節の第１拍目の再生を開始するものとしてもよい。
【００２０】
本構成によれば、小節内での次に再生する予定の拍が再生されない場合には、次小節の第１拍目が再生される。具体的には、例えば、変更された楽曲が再生される際の拍子の数が３（３拍子）である場合には、小節内での次に再生する予定の第３拍目は再生されるが、次に再生する予定の第４拍目は再生されずに、次の小節の第１拍目の再生が開始される。すなわち、同一の楽曲でありながら、３拍子の楽曲として再生される。このことにより、１小節の拍数（例えば、４拍）を変化の最大値とする１つの楽曲データを準備することで、複数の拍子（４拍子以下の拍子）の楽曲を再生することができる。なお、所定の拍子用に調整されたトラックを準備しておく場合には、これらのトラックは並行して再生され、変更された拍子に合わせて有音、無音が切り替わるので、拍子の切り替えに対して滑らかな切り替えが行われると同時に、楽曲が不自然に聞こえてしまうおそれが無い。
【００２１】
判定手段は、所定の間隔で繰り返し判定するものとしてもよい。
【００２２】
本構成によれば、次に再生する予定の拍（直後の拍）を再生するか否かを適切なタイミングで定期的に判定することができる。
【００２３】
所定の間隔は、拍の間隔もしくは当該拍の間隔よりも短い間隔であるとしてもよい。
【００２４】
本構成によれば、判定処理は、例えば、楽曲が再生される際の拍子が４拍子から３拍子に切り替わる場合には、４拍ごとに、小節内の第４拍を再生する直前に、第４拍目（直後の拍）を再生するか否かの判定処理が行われる。このことにより、切り替わる拍子の数に応じて、適切なタイミングで、直後の拍を次に再生するか否かを判定する効率的な判定処理を行うことができる。
【００２５】
再生手段は、拍子変更手段によって拍子が第１の拍子と第２の拍子との間で切り替えられると、第１の拍子用トラックと第２の拍子用トラックの有音／無音の切り替えをクロスフェードで切り替えてもよい。
【００２６】
本構成によれば、第１の拍子用トラックと、第２の拍子用トラックの有音／無音はクロスフェードで切り替えられる。このことにより、ユーザには、トラックが切り替えられて有音再生されていることに対する違和感を覚えることがより少なくなる。
【００２７】
コンピュータを、ユーザからの入力を受け付ける入力受付手段としてさらに機能させ、
拍子変更手段は、入力受付手段が受け付けたユーザからの入力に基づいて、楽曲データを再生させる際の拍子を変更してもよい。
【００２８】
本構成によれば、楽曲が再生される際の拍子は、ユーザからの入力指示に応じて変更可能となる。
【００２９】
入力受付手段が受け付けたユーザからの入力は、楽曲データを再生する際の拍子を変更する処理以外の処理に用いられてもよい。
【００３０】
本構成によれば、例えば、ユーザ（ゲームプレイヤ）が、ゲームキャラクタを操作する処理（楽曲データの再生の拍子を変更する処理以外の処理）を行うことによって、ゲームの状況や場面を変化させ、これに応じて楽曲の拍子を変更させることができる。
【００３１】
以上では、情報処理プログラムとして本発明を構成する場合について記載した。しかし、本発明は、情報処理装置、情報処理システム、又は情報処理方法として構成されてもよい。更には、本発明は、上記情報処理プログラムを記録したコンピュータで読み取り可能な記録媒体として構成されてもよい。
【発明の効果】
【００３２】
本発明によれば、楽曲の拍子を変えることが可能な新規な、情報処理プログラム等を提供することができる。また、楽曲の小節の途中を再生中であってもリアルタイムに楽曲の拍子を変化させることが可能な情報処理プログラム等を提供することができる。
【図面の簡単な説明】
【００３３】
【図１】情報処理システム１０の構成の一例を示すブロック図
【図２】楽曲データの一例を示す模式図
【図３】拍子が変更される場合の楽曲データの一例を示す模式図
【図４】複数のトラックで構成された楽曲データの一例を示す模式図
【図５】メインメモリ２２のメモリマップの一例
【図６】拍子設定処理のフローチャートの一例
【図７】判定処理のフローチャートの一例
【図８】通常再生用トラックと切り替え再生用トラックが再生されたときの譜例を示す図
【図９】拍子が変更される場合の通常再生用トラックと切り替え再生用トラックの一例を示す模式図
【図１０】拍子設定処理のフローチャートの変形例
【発明を実施するための形態】
【００３４】
（一実施形態）
以下、図面を参照して、本発明の一実施形態について説明する。ここでは、本発明を情報処理システムに適用した例について説明するが、本発明は、このような情報処理システムに限定されるものではなく、このような情報処理システムの機能を実現する情報処理装置であってもよく、このような情報処理装置における情報処理方法であってもよく、このような情報処理装置において実行される情報処理プログラムであってもよい。更には、本発明は、このような情報処理プログラムを記録したコンピュータ読み取り可能な記録媒体であってもよい。
【００３５】
（情報処理システムのハードウェア構成）
図１を参照して、本発明の一実施形態に係る情報処理システム１０について説明する。図１は、情報処理システム１０の構成の一例を示すブロック図である。図１に示すように、情報処理システム１０は、操作装置１２、情報処理装置１４、表示装置１６、スピーカ１７、及び外部記憶装置２４を備えている。
【００３６】
操作装置１２は、自装置に対して行われた操作の内容を示す操作データを情報処理装置１４に与える入力装置である。操作装置１２と情報処理装置１４とは、無線通信の技術が用いられて接続されてもよいし、接続コード等を用いて有線で接続されてもよい。
【００３７】
情報処理装置１４は、プロセッサ１８、内部記憶装置２０、及びメインメモリ２２を備えている。内部記憶装置２０には、プロセッサ１８によって実行されるコンピュータプログラムが格納されている。内部記憶装置２０は、典型的には、ハードディスクやＲＯＭ（Ｒｅａｄ  Ｏｎｌｙ  Ｍｅｍｏｒｙ）である。メインメモリ２２は、コンピュータプログラムやその他のデータを一時的に記憶する。
【００３８】
表示装置１６は、情報処理装置１４によって生成された画像を画面に表示する。なお、表示装置１６は、情報処理装置１４と一体に構成されてもよい。
【００３９】
スピーカ１７は、情報処理装置１４によって生成された音声を出力する。なお、スピーカ１７は、表示装置１６と一体に構成されてもよい。
【００４０】
外部記憶装置２４には、プロセッサ１８によって実行されるコンピュータプログラムが格納されている。外部記憶装置２４は、典型的には、ＣＤ（Ｃｏｍｐａｃｔ  Ｄｉｓｃ）やＤＶＤ（Ｄｉｇｉｔａｌ  Ｖｅｒｓａｔｉｌｅ  Ｄｉｓｃ）や半導体記憶装置である。
【００４１】
なお、上記のようなハードウェア構成は単なる一例に過ぎず、本発明は任意の情報処理システムに適用可能である。
【００４２】
以下では、本発明の一実施形態として、情報処理システム１０がゲームシステムである場合について説明する。本実施形態における情報処理システム１０では、操作装置１２（例えば、ゲームコントローラ）を用いた操作に基づいて、情報処理装置１４（例えば、ゲーム装置）がゲーム処理や楽曲再生処理を実行する。
【００４３】
まず、情報処理システム１０において実行されるゲーム楽曲（楽曲の一例）の楽曲再生処理について説明する。本実施形態では、外部記憶装置２４等からメインメモリ２２にロードされたゲーム楽曲の楽曲再生プログラム（コンピュータプログラムの一例）をプロセッサ１８が実行することによって、ゲームの進行に応じたゲーム楽曲が再生される。
【００４４】
（楽曲再生処理）
本実施形態では、楽曲再生プログラムによって再生されるゲーム楽曲の楽曲データは、ＭＩＤＩ（Musical Instruments Digital Interface）規格に則ったデータ（ここでは単にＭＩＤＩデータと称す）であり、外部記憶装置２４等からメインメモリ２２にロードされる。また、ＭＩＤＩデータでは、楽曲に含まれる複数の音が１以上のトラック（譜面に相当する）で管理されている。つまり、楽曲に含まれる各音は、いずれかのトラックに所属する。
【００４５】
ＭＩＤＩデータは、複数のＭＩＤＩイベントの集合体として表現される。ＭＩＤＩイベントには、音を鳴らすための「ノートイベント」や、トラック単位で音のボリュームや音色を変えたりするための「コントロールチェンジイベント」をはじめ、「ピッチベンドイベント」、「プログラムチェンジイベント」など、種々のＭＩＤＩイベントが存在する。そして、各ＭＩＤＩイベント間の時間間隔を表す時間情報とイベント情報との組がイベントの発生順に格納されて、ＭＩＤＩデータが構成される。
【００４６】
ノートイベントには、「所属トラック」、「再生タイミング」、「ノート長（デュレーション）」、「音高（ノートナンバー）」、「ベロシティ」等の情報が含まれる。「所属トラック」は、そのノートイベントによって鳴らされる音が、どのトラックに含まれる音かを示す情報である。「再生タイミング」は、音を鳴らすタイミングを示す情報であって、ティック（tick）という単位で表される。「ノート長（デュレーション）」は、音の長さを示す情報であり、ティックで表される。「音高（ノートナンバー）」は、音の高さである音高を示す情報である。「ベロシティ」は、音を鳴らす強さを示す情報である。
【００４７】
楽曲再生プログラムは、楽曲のＭＩＤＩデータに基づいて、ノートイベントを含む各種ＭＩＤＩイベントを、先頭から順番に処理することにより、楽曲を小節、拍の順番で順次再生する。より具体的には、情報処理装置１４において楽曲再生プログラムが実行されることにより生成された音声データが、スピーカ１７を通して出力される。なお、楽曲再生プログラムには、ＭＩＤＩプレーヤーとしての機能を有する既存のプログラムライブラリ等を利用すればよい。
【００４８】
なお、拍の順番（第３拍目など）とは、小節内の再生位置を示すものである。また、本明細書において、「拍の再生」と記載することがあるが、これは、特に断りのない限り、当該拍に含まれる音符の再生を意味するものとする。
【００４９】
ところで、ゲーム楽曲は、ゲームの進行に応じてゲームの興趣性や臨場感を高めるためにゲームの音響効果のための演出音として用いられることが多いため、ゲームの場面や状況の変化に合わせてゲーム楽曲の拍子を変化させることで、ゲームの臨場感をより高めたいという要望がある。具体的には、所定の拍子（例えば、４拍子）でゲーム楽曲が再生されているときに、ゲームのプレイヤキャラクタ（主人公）の状況（場面）が変化した場合（例えば、プレイヤキャラクタが休憩所に移動した場合）、ゲーム楽曲の旋律はそのままに拍子を変える（例えば３拍子に変える）ことで、プレイヤキャラクタの状況の変化を、ゲームプレイヤに臨場感をもって体感させたいという要望がある。また、このような状況の変化は、ゲームプレイヤが操作装置１２によってプレイヤキャラクタを操作することによって生ずることであるため、どのようなタイミングであっても（すなわち、ゲーム楽曲の小節の途中が再生中であっても）リアルタイムに変化できることが求められる。本実施形態では、この要望に応えるために、上記したＭＩＤＩイベントが再生処理プログラムによって実行される際に、ＭＩＤＩイベントにより小節中の拍の再生が開始される直前に定期的に判定処理が実行される。以下に、本実施形態におけるこの判定処理について説明する。
【００５０】
（判定処理）
本実施形態における判定処理は、ゲーム楽曲を再生する際の拍子の数と、直後に再生する小節中の拍の順番とを定期的に比較して、比較結果に応じて次の処理を決定する（次に再生処理プログラムによって実行されるＭＩＤＩイベントを指定する）処理である。この判定処理は、内部記憶装置２０等からメインメモリ２２にロードされた判定プログラムをプロセッサ１８が実行することによって実行される。
【００５１】
以下、図２、図３を参照しつつ、この判定処理について具体的に説明する。図２は、４拍子の１トラックからなる楽曲データを説明するための模式図であり、図３の（１）は、４拍子の１トラックからなる楽曲データが３拍子で再生される様子を示す模式図であり、図３の（２）は、４拍子の１トラックからなる楽曲データが２拍子で再生される様子を示す模式図である。
【００５２】
楽曲再生プログラムによってＭＩＤＩデータに含まれる各種ＭＩＤＩイベントが先頭から順番に実行されると、ゲーム楽曲が小節、拍順に順次再生される。具体的には、楽曲データが４拍子の１トラックからなる場合、図２に示すように、第１小節の第１拍、…、第１小節の第４拍、第２小節の第１拍、…第２小節の第４拍、…というように、ゲーム楽曲の小節、拍順に楽曲データが処理（再生）される。ここで、判定処理（判定プログラム）は、楽曲再生プログラムによる楽曲データの処理に対して、定期的に実行される。そして、判定プログラムが実行されることにより、直後に再生される拍（すなわち、これから再生しようとする拍）の順番ｎ（つまり、第ｎ拍）と、ゲーム楽曲が再生される際の拍子の数Ｒとが比較され、この結果に基づいて後続の処理が決定される。詳細には、判定プログラムによって、ｎ≦Ｒであると判定されると、次の処理として、楽曲再生プログラムによって後続のＭＩＤＩイベントがそのまま実行されることが決定される。一方、判定プログラムによって、ｎ＞Ｒであると判定されると、次の処理として、後続のＭＩＤＩイベントではなく（すなわち、現在再生中の小節に含まれている残りのＭＩＤＩイベントの処理が省略されて）、次小節の第１拍目を再生させるＭＩＤＩイベントが楽曲再生プログラムによって実行されることが決定される。
【００５３】
上述した判定プログラムが実行される例について、図２、図３を参照しつつ、具体的に説明する。図２および図３に示すように、４拍子の１トラックの楽曲データを４拍子（Ｒ＝４）または３拍子（Ｒ＝３）または２拍子（Ｒ＝２）で再生するときには、判定プログラムは、第３拍目（ｎ＝３）の再生の直前と、第４拍目（ｎ＝４）の再生の直前に、定期的に実行される。
【００５４】
図２に示すように、４拍子の１トラックの楽曲データを４拍子（Ｒ＝４）で再生する場合には、第３拍目（ｎ＝３）の再生の直前では、直後に再生される拍の順番（すなわち、ｎ＝３）と、ゲーム楽曲の再生の拍子（すなわち、Ｒ＝４）とが比較され、ｎ≦Ｒであると判定されるため、次の処理として、楽曲再生プログラムによって後続のＭＩＤＩイベントがそのまま実行される。そして、第４拍目（ｎ＝４）の再生の直前では、直後に再生される拍の順番（すなわち、ｎ＝４）と、ゲーム楽曲の再生の拍子（すなわち、Ｒ＝４）とが比較され、ｎ≦Ｒであると判定されるため、次の処理として、楽曲再生プログラムによって後続のＭＩＤＩイベントがそのまま実行される。すなわち、ＭＩＤＩイベントは順序どおりに実行され、楽曲データは、そのままの順序で再生される（４拍子の楽曲として再生される）。
【００５５】
一方、図３（１）に示すように、上記４拍子の１トラックの楽曲データを３拍子（Ｒ＝３）で再生する場合には、第３拍目（ｎ＝３）の再生の直前では、直後に再生される拍の順番（すなわち、ｎ＝３）と、ゲーム楽曲の再生の拍子（すなわち、Ｒ＝３）とが比較され、ｎ≦Ｒであると判定されるため、次の処理として、楽曲再生プログラムによって後続のＭＩＤＩイベントがそのまま実行される。そして、第４拍目（ｎ＝４）の再生の直前では、直後に再生される拍の順番（すなわち、ｎ＝４）と、ゲーム楽曲の再生の拍子の数（すなわち、Ｒ＝３）とが比較され、ｎ＞Ｒであると判定されるため、次の処理として、楽曲再生プログラムによって次小節の第１拍目を再生させるＭＩＤＩイベントが実行されることが決定される。このことにより、後続のＭＩＤＩイベントが実行されず（すなわち、第４拍目が再生されず）、次小節の第１拍目が再生される。すなわち、図３の（１）に示すように、４拍子の１トラックの楽曲データの斜線部の拍（第４拍目）が飛ばされて再生されることにより、ゲーム楽曲の旋律はそのままに３拍子の楽曲が再生される。
【００５６】
ところで、上述したように、上記した４拍子の楽曲データを再生する際の拍子は、ゲームプレイヤによるプレイヤキャラクタの操作によって生ずる状況の変化に応じて変化するものであるから、リアルタイムに変更可能であることが求められる。本実施形態では、フレーム毎（１拍の間隔よりもはるかに短い間隔であり、例えば１／６０ｓ）に、楽曲データを何拍子で再生させるかという情報が取得される。そのため、楽曲再生プログラムによって小節の第３拍目を再生させるＭＩＤＩイベントが実行されているとき、楽曲が再生される際の拍子が４拍子から３拍子に切り替わると、当該小節の第４拍目が再生される直前には、Ｒの値が４から３に切り替わっている。したがって、上述した判定プログラムが実行されると、後続の第４拍目を再生させるＭＩＤＩイベントが実行されなくなる（飛ばされる）。このことにより、楽曲データの小節の途中が再生中であっても、リアルタイムにゲーム楽曲の拍子を切り替えることができる。
【００５７】
次に、図３（２）に示すように、上記４拍子の１トラックの楽曲データを２拍子で再生する場合について説明する。この場合、判定プログラムは、第３拍目（ｎ＝３）の再生の直前と、第４拍目（ｎ＝４）の再生の直前に定期的に実行される。したがって、楽曲再生プログラムによって第１拍目又は第２拍目を再生させるＭＩＤＩイベントが実行されているときに、楽曲データの再生の拍子が４拍子から２拍子に切り替わった場合には、判定処理プログラムが実行されることにより、第３拍目の再生の直前に、直後に再生される拍の順番（すなわち、ｎ＝３）と、ゲーム楽曲の再生の拍子の数（すなわち、Ｒ＝２）とが比較される。この結果、ｎ＞Ｒであると判定されるため、次の処理として、楽曲再生プログラムによって次小節の第１拍目を再生させるＭＩＤＩイベントが実行されることが決定される。このことにより、後続のＭＩＤＩイベントが実行されず（すなわち、第３拍目と第４拍目が再生されず）、次小節の第１拍目が再生される。すなわち、図３の（２）に示すように、４拍子の１トラックの楽曲データの斜線部の拍（第３拍目と第４拍目）が飛ばされて再生されることにより、ゲーム楽曲の旋律はそのままに２拍子の楽曲が再生される。
【００５８】
また、楽曲再生プログラムによって第３拍目を再生させるＭＩＤＩイベントが実行されているときに、楽曲データの再生の拍子が２拍子に切り替わった場合には、判定処理プログラムが実行されることにより、第４拍目の再生の直前に、直後に再生される拍の順番（すなわち、ｎ＝４）と、ゲーム楽曲の再生の拍子の数（すなわち、Ｒ＝２）とが比較される。この結果、ｎ＞Ｒであると判定されるため、次の処理として、楽曲再生プログラムによって次小節の第１拍目を再生させるＭＩＤＩイベントが実行されることが決定される。このことにより、後続のＭＩＤＩイベントが実行されず（すなわち、第４拍目が再生されず）、次小節の第１拍目が再生される。このように、楽曲データの再生の拍子を４拍子から２拍子に切り替えるときには、第３拍目と第４拍目の再生の直前に判定プログラムを実行させることで、楽曲データの小節の途中が再生中であっても、リアルタイムに拍子の切り替えを行うことができる。
【００５９】
なお、上記した判定プログラムが実行されるタイミングについては、上記例に限らず、例えば、小節中の各拍の再生の直前に毎回実行されるものとしてもよい。このようにすれば、より柔軟に、拍子の変更にリアルタイムに対応することができる。また、楽曲のデータとしては、小節の拍数が、変更される可能性がある複数の拍子のうちの最大の拍子に対応する拍数であるような楽曲データさえ準備しておけば、変更される可能性がある全ての拍子に対応可能となり、各拍子用の楽曲のデータを個別に準備する必要がない。
【００６０】
また、上記では、楽曲データが１つのトラックで構成されている場合について説明したが、複数のトラックで構成されていてもよい。この場合、上記した判定プログラムは、全てのトラックにおいて同じタイミングで実行される。具体的には、図４に示すように、複数のトラックで構成される４拍子の楽曲データが、３拍子（Ｒ＝３）で再生される際には、それぞれのトラックにおいて、少なくとも第４拍目（ｎ＝４）の再生の直前に判定プログラムが実行される。そして、この結果、各トラックにおいてｎ＞Ｒと判定されるので、トラックごとに、次小節の第１拍目が再生されることが決定され、各トラックの次小節の第１拍目が同じタイミングで再生される。このことにより、楽曲データが複数のトラックで構成されていても１つのトラックで構成されているときと同様に、楽曲データの小節の途中が再生中であっても、リアルタイムに拍子の切り替えを行うことができる。なお、判定プログラムは、上記複数のトラックのいずれか１つのトラックにおいて実行され、この判定結果に基づいて、全てのトラックにおいて、例えば第４拍目が再生されない（飛ばされる）ようにしてもよい。
【００６１】
以上のように、判定処理が、定期的、より具体的には、飛ばすべきか否かの判定対象となる拍の直前に実行されることにより、リアルタイムに楽曲の拍子の切り替えを行うことができる。なお、言うまでもないが、４拍子の楽曲データが３拍子に切り替わり、その後、４拍子に戻る場合には、Ｒの値は、３から４に戻る。この場合、第４拍（ｎ＝４）の直前に判定処理が実行されることにより、ｎ≦Ｒと判定される。したがって、楽曲再生プログラムによって後続のＭＩＤＩイベントが実行されるので、楽曲データはそのままの順序で再生されることにより、元の４拍子の楽曲として再生される。
【００６２】
次に、上述した楽曲再生処理や、判定処理が実行されるために、メインメモリ２２に記憶される各種データ（メモリマップ）について説明する。
【００６３】
（メモリマップ）
図５は、外部記憶装置２４や内部記憶装置２０から読み出されたゲームプログラム等のプログラムや、各種データを記憶するメインメモリ２２のメモリ構成の一例を示す図である。図５に示すように、メインメモリ２２は、ゲームプログラム２２０、拍子設定プログラム２２１、楽曲再生プログラム２２２、判定プログラム２２３、ＭＩＤＩデータ２２４、拍子データ２２５を有している。ゲームプログラム２２０、拍子設定プログラム２２１、楽曲再生プログラム２２２、判定プログラム２２３は、プロセッサ１８が実行するプログラムである。また、ＭＩＤＩデータ２２４、拍子データ２２５は、拍子設定プログラム２２１、楽曲再生プログラム２２２、判定プログラム２２３が実行される際に用いられるデータである。
【００６４】
ゲームプログラム２２０は、ゲームを進行させるためのプログラムであり、ゲームプレイヤ（ユーザ）による操作装置１２からの操作情報を受け付けて、操作情報に応じたゲーム進行を行うプログラムである。
【００６５】
拍子設定プログラム２２１は、後述する楽曲再生プログラム２２２によって再生される楽曲（ゲーム楽曲）の拍子を設定するプログラムである。具体的には、拍子設定プログラム２２１が定期的に実行されることにより、ゲームの進行（状況）に応じて、拍子データ２２５が逐次更新される。
【００６６】
楽曲再生プログラム２２２は、ゲームプログラム２２０が実行するゲームの進行に合わせて、ゲームの音響効果のために用いられる楽曲（ゲーム楽曲）を再生するプログラムである。この際、ゲームの進行に合わせた楽曲データ（ＭＩＤＩデータ２２４）が用いられる。
【００６７】
判定プログラム２２３は、拍子データ２２５を取得して、当該拍子の数と、直後に再生される拍の順番とを定期的に比較して、比較結果に応じて次の処理を決定するプログラムである。
【００６８】
ＭＩＤＩデータ２２４は、楽曲再生プログラムが実行される際に用いられるゲーム楽曲のデータであり、上述したように複数のＭＩＤＩイベントの集合体からなるデータである。
【００６９】
拍子データ２２５は、楽曲再生プログラムによって再生される楽曲の拍子を示すデータである。具体的には、楽曲によって予め初期値が定められており、また、拍子設定プログラムが実行されることによって、ゲームの進行に合わせて更新されるデータである。なお、拍子データ２２５は、ゲームプレイヤの操作情報によって更新されるデータであってもよい。
【００７０】
次に、上述した拍子設定プログラム２２１が実行されることによって行われる拍子設定処理の処理フローについて説明する。
【００７１】
（拍子設定処理の処理フロー）
図６を参照しつつ、情報処理装置１４のプロセッサ１８が実行する拍子設定処理について説明する。図６は、本実施形態において、プロセッサ１８が実行する拍子設定処理のフローチャートである。情報処理装置１４の電源が投入されると、プロセッサ１８は、内部記憶装置２０のいわゆるブートＲＯＭに記憶されている起動プログラムを実行し、メインメモリ２２を初期化する。そして、外部記憶装置２４等から各種プログラムや各種データをメインメモリ２２にロードした後に、拍子設定プログラム２２１を読み込んで図６に示すフローチャートの処理を１フレーム（例えば１／６０ｓ）毎に実行する。
【００７２】
ステップＳ１１において、プロセッサ１８は、楽曲の拍子を変える（すなわち、拍子データ２２５を更新する）必要があるか否かを判定する。具体的には、プロセッサ１８は、ゲームプログラム２２０を実行することにより進行させているゲームの状況に基づいて、拍子データ２２５を更新するか否かを判定する。例えば、ゲームの状況が変化することに伴って、ゲームの音響効果として再生しているゲーム楽曲の拍子を変化させる必要がある場合には、拍子データ２２５を更新する必要があると判定する。この判定の結果がＹＥＳの場合、処理はステップＳ１２に移り、ＮＯの場合、処理は終了し、次のフレームにおいて、再び図６に示すフローチャートの処理が繰り返される。
【００７３】
ステップＳ１２において、プロセッサ１８は、拍子データ２２５を更新する。具体的には、プロセッサ１８は、ゲームの状況に応じて楽曲の拍子を適切な値に更新する。例えば、ゲーム空間において時がゆったりと流れる状況を演出したい場合には、プロセッサ１８は、音響効果のためのゲーム楽曲の拍子データ２２５の値を、それまでの４拍子から３拍子に更新する。そして、処理は終了し、次のフレームにおいて、再び図６に示すフローチャートの処理が繰り返される。
【００７４】
以上のように、プロセッサ１８によって、ゲームの状況に応じて、ゲーム楽曲の拍子が適宜（１フレーム単位で）適切な値に更新される。このことにより、後述する判定プログラムが実行されるタイミングでは、拍子データ２２５は、ゲームの状況にふさわしい最新の値に更新されている。
【００７５】
次に、上述した判定プログラム２２３が実行されることによって行われる判定処理の処理フローについて説明する。
【００７６】
（判定処理の処理フロー）
図７を参照しつつ、情報処理装置１４のプロセッサ１８が実行する判定処理について説明する。図７は、本実施形態において、プロセッサ１８が実行する判定処理のフローチャートである。情報処理装置１４の電源が投入されて、メインメモリ２２が初期化され、外部記憶装置２４等から各種プログラムや各種データがメインメモリ２２にロードされた後に、プロセッサ１８は、判定プログラム２２３を読み込んで図７に示すフローチャートの処理を予め定められた周期（例えば、小節の第４拍目が再生される直前のタイミングで）で実行する。
【００７７】
ステップＳ２１において、プロセッサ１８は、拍子データ２２５を参照して、現在設定されている楽曲が再生される際の拍子を取得する。その後、処理はステップＳ２２に移る。
【００７８】
ステップＳ２２において、プロセッサ１８は、次に再生される楽曲の拍の順番が、設定されている楽曲が再生される際の拍子の数よりも大きいか否かを判定する。具体的には、プロセッサ１８は、楽曲再生プログラム２２２に基づいて次に再生される楽曲データの拍の順番ｎ（つまり第ｎ拍）と、ステップＳ２１で取得した楽曲が再生される際の拍子の数Ｒとを比較して、次に再生される拍の順番が拍子の数よりも大きい（ｎ＞Ｒである）か否かを判定する。この判定の結果がＹＥＳの場合、処理はステップＳ２３に移り、ＮＯの場合は、処理は終了し、所定の周期で、再び図７に示すフローチャートの処理が繰り返される。
【００７９】
ステップＳ２３において、プロセッサ１８は、楽曲再生プログラム２２２に基づいて次に再生されるゲーム楽曲の拍を次小節の第１拍目に決定する。具体的には、プロセッサ１８は、楽曲再生プログラム２２２に基づいて後続のＭＩＤＩイベントを実行するのではなく（飛ばして）、楽曲再生プログラム２２２に基づいて次小節の第１拍目の再生に対応するＭＩＤＩイベントを実行することを決定する。そして、処理は終了し、所定の周期で、再び図７に示すフローチャートの処理が繰り返される。
【００８０】
なお、上記した所定の周期は、例えば４拍子の楽曲データを３拍子でも再生する要望がある場合には、少なくとも第４拍目の再生の直前毎に定期的に繰り返し行うものとすればよい（図３（１）参照）。また、例えば４拍子の楽曲データを２拍子でも再生する要望がある場合には、少なくとも第３拍目の再生の直前と第４拍目の再生の直前毎に定期的に繰り返し行うものとすればよい（図３（２）参照）。さらに、同一の楽曲データを様々な拍子に再生することを可能にする要望がある場合には、毎拍の再生の直前に定期的に繰り返し行うものとしてもよい。
【００８１】
以上のように、プロセッサ１８によって、判定処理プログラムが、所定の周期で（例えば、小節の第４拍目が再生される直前のタイミング毎に）実行されることにより、ゲーム状況にふさわしい最新のゲーム楽曲の拍子の数と、次に再生される拍の順番が比較された結果、次に再生する拍をそのまま再生するか、次小節の第１拍目を再生する（すなわち、現在再生中の小節において、次に再生する拍以降の部分を再生せずに、次小節の第１拍目を再生する）かが決定される。このことにより、楽曲データの小節の途中の拍が再生中であっても、リアルタイムに拍子の切り替えを行うことができる。
【００８２】
以上に説明したように、本実施形態では、判定処理プログラムが適切なタイミングで繰り返し実行されることで、楽曲が再生される際の拍子の変化に応じて、所定の拍が飛ばされて再生されることにより、同一の楽曲データでありながら拍子の異なる楽曲が再生される。
【００８３】
なお、同一の楽曲データの拍子を変える場合に、その拍子が変更される際の楽曲の変化を滑らかにするために、以下のような方法がある。例えば、４拍子の楽曲データを３拍子で再生する場合、小節内の第４拍目が飛ばされて再生されることになるが、この第４拍目が飛ばされて再生される前後において、直前（小節内の第３拍目）の音符の長さを維持して再生する方法や、直前（小節内の第３拍目）の音符の長さは、直後（次小節内の第１拍目）の音符に跨らない長さとし、直後（次小節の第１拍目）の音符を再生する方法や、直後（次小節の第１拍目）の音符は休符でない場合のみ再生する方法などがある。
【００８４】
また、楽曲の拍子が変更される際に、楽曲データの小節間の繋がりをより滑らかにする方法として、上記した方法以外に、各拍子専用に小節間の繋がりが滑らかになるように予め音符が調整された拍子専用トラックを用意しておくという方法がある。以下に、この拍子専用トラックを用意しておく場合の変形例について説明する。
【００８５】
（変形例）
図８、図９を参照しつつ、楽曲が再生される際の拍子が４拍子から３拍子に切り替わる際の拍子専用トラックの一例について説明する。変形例における楽曲データは、後述する通常専用トラックと切り替え再生用トラックからなる。図８は、通常再生用トラックと切り替え再生用トラックが再生されたときの譜例を示す図であり、図９は、拍子が変更される場合の通常再生用トラックと切り替え再生用トラックの一例を示す模式図である。
【００８６】
ここで、通常再生用トラックとは、４拍子の１トラックの楽曲データであり、４拍子用の拍子専用トラックとして機能する。また、切り替え再生用トラックとは、４拍子の１トラックの楽曲データであり、３拍子用の拍子専用トラックとして機能する。これらのトラックの特徴を、図８を参照しつつ説明する。図８の譜例Ａは、通常再生用トラックの楽曲データ（ＭＩＤＩデータ）が実際に再生された場合の譜例を示し、図８の譜例Ｂは、切り替え再生用トラックの楽曲データ（ＭＩＤＩデータ）が実際に再生された場合の譜例を示す。
【００８７】
図８の譜例Ｂからわかるように、切り替え再生用トラックは、１小節が４拍子の楽曲データであり、４拍目の音符が休符となっている。また、切り替え再生用トラックが再生された場合の譜例Ｂは、通常再生用トラックが再生された場合の譜例Ａと比べて、４拍目が再生されない場合の小節間の繋がりが滑らかになるように、通常再生用トラックの音符に基づいて予め音符が調整されている。例えば、図９に示すように、第１小節の第３拍目の音符の長さが、通常再生用トラックでは１．５拍（譜例Ａ参照）であるのに対し、切り替え用再生トラックの第１小節の第３拍目の音符の長さは、１拍（譜例Ｂ参照）に調整されている。すなわち、切り替え再生用トラックは、通常再生用トラックの旋律を維持しながら、３拍子で再生された際に（４拍目が飛ばされて再生された際に）、小節間の繋がりがより滑らかになるように調整されたトラックである。このことにより、第４拍目の音符が再生されない場合には、切り替え再生用トラックは、通常再生用トラックに比べて、小節間のつながりがより滑らかになる。なお、上記では、切り替え再生用トラックにおいて、第４拍目のデータは休符データとしたが、第４拍目のデータは、飛ばされて再生されるので、休符以外の音符データであってもよい。
【００８８】
通常再生用トラックと、切り替え再生用トラックは、楽曲再生プログラムによって、並行して、それぞれのＭＩＤＩデータに含まれる各種ＭＩＤＩイベントが先頭から順番に実行される。このことにより、それぞれのトラックは、同じ小節、拍の順に同期を取って再生される。ただし、楽曲が再生される際の拍子が４拍子に設定されるとき、通常再生用トラックは有音で再生されるが、切り替え再生用トラックは無音で再生される。したがって、拍子が４拍子であるときには、ゲームプレイヤには、通常再生用トラックの音声しか聞こえない。そして、ゲームの状況の変化に応じて４拍子の楽曲データを３拍子で再生させる必要が生じたときには、通常再生用トラックは無音で再生され、切り替え再生用トラックが有音で再生される。
【００８９】
すなわち、通常再生用トラックと、切り替え再生用トラックは、同時に並行して再生されているが、ゲームの状況の変化に応じて、一方のみが有音で再生される。
【００９０】
この場合、上記した判定プログラムは、同じタイミングで通常再生用トラックと、切り替え再生用トラックに対して同時に実行される。より具体的には、前述したように、通常再生用トラックと切り替え再生用トラックは、小節、拍の順に同期が取られて再生されているので、判定プログラムが、各トラックにおいて同一の拍が再生される直前に実行されることにより、判定プログラムも両トラック間で同期を取って実行される。例えば、図９の（１）に示すように、通常再生用トラックと切り替え再生用トラックで構成される４拍子の楽曲データが、３拍子（Ｒ＝３）で再生される際には、それぞれのトラックにおいて、少なくとも第４拍目（ｎ＝４）の再生の直前に判定プログラムが実行される。
【００９１】
そして、判定プログラムが実行された結果、各トラックにおいてｎ＞Ｒと判定されるので、トラックごとに、次小節の第１拍目が再生されることが決定され、各トラックの次小節の第１拍目が同じタイミングで再生される。そして、４拍子の楽曲データが３拍子で再生される際には、通常再生用トラックは無音で再生され、切り替え再生用トラックが有音で再生されている（図９の（２）参照）。このため、ゲームプレイヤには、切り替え再生用トラックの第４拍目が再生されない楽曲が聞こえるので、通常再生用トラックの第４拍目が再生されない楽曲が聞こえるときよりも、小節間の繋がりが滑らかに聞こえる。また、切り替え再生専用トラックも、通常再生用トラックもどちらも、第４拍目が再生されないで（第４拍目が飛ばされて）楽曲が再生されていくので、両方のトラックの小節、拍の順番にずれが生じることがない。このため、３拍子で再生されていた楽曲が再び４拍子に戻された場合には、通常再生用トラックが有音で再生され、切り替え再生用トラックが無音で再生されるが、ずれることなく４拍子の通常再生用トラックの楽曲が聞こえる。
【００９２】
（拍子設定処理の変形例）
次に、図１０を参照しつつ、情報処理装置１４のプロセッサ１８が実行する拍子設定処理の変形例について説明する。図１０において、図６を用いて説明した拍子設定処理のフローチャートの処理と同一の処理には同一の参照番号を付して、その説明は簡略化する。
【００９３】
情報処理装置１４の電源が投入されて、メインメモリ２２が初期化され、外部記憶装置２４等から各種プログラムや各種データがメインメモリ２２にロードされた後に、プロセッサ１８は、拍子設定プログラム２２１を読み込んで図１０に示すフローチャートの処理を１フレーム（例えば１／６０ｓ）毎に実行する。また、同時に、プロセッサ１８は、楽曲再生プログラム２２２を読み込んで、通常再生（例えば、４拍子再生）用のトラックを有音で再生し、切り替え再生（例えば、３拍子再生）用のトラックを無音で再生する。
【００９４】
ステップＳ１１において、プロセッサ１８は、楽曲の拍子を変える必要がないと判定した場合には、処理を終了し、拍子を変える必要があると判定した場合には、処理はステップＳ１２に移り、プロセッサ１８が拍子データ２２５を適切な値に更新した後、処理はステップＳ３３に移る。
【００９５】
ステップＳ３３において、プロセッサ１８は、切り替え再生用のトラックを無音再生から有音再生に切り替える。その後、処理はステップＳ３４に移る。
【００９６】
ステップＳ３４において、プロセッサ１８は、不必要なトラックが有音再生中でないか否かを判定する。具体的には、通常再生用のトラックが有音再生中でないかを判定する。この判定結果がＹＥＳの場合、処理はステップＳ３５に移り、ＮＯの場合、処理は終了する。
【００９７】
ステップＳ３５において、プロセッサ１８は、不必要なトラックを無音再生に切り替える。具体的には、通常再生用のトラックを無音再生に切り替え、処理を終了する。
【００９８】
なお、上記ステップＳ３３〜Ｓ３５において行われる通常再生用トラックと、切り替え再生用トラックの有音／無音の切り替えは、再生音量をクロスフェードで切り替えることにより行われることが好ましい。
【００９９】
（その他の変形例）
なお、上記実施形態では、楽曲再生プログラムと判定プログラムとは、別のプログラムであり、判定プログラムは、楽曲再生プログラムの実行中に定期的に実行されるものとしたが、判定プログラムが楽曲再生プログラムの一部として埋め込まれていてもよい。すなわち、楽曲再生プログラムが、ＭＩＤＩイベントを処理すると共に、ＭＩＤＩイベントの間に所定の間隔で埋め込まれた判定処理（判定コマンド）を実行するものとしてもよい。例えば、ＭＩＤＩデータの各小節の第３拍目の最初のＭＩＤＩイベントの直前に「Ｒが３未満であれば次の小節の先頭のＭＩＤＩイベントへジャンプする」というコマンドを挿入するとともに、各小節の第４拍目の最初のＭＩＤＩイベントの直前に「Ｒが４未満であれば次の小節の先頭のＭＩＤＩイベントへジャンプする」というコマンドを挿入しておき、楽曲再生プログラムが当該コマンドに従ってＭＩＤＩデータを再生するようにしてもよい。
【０１００】
また、上記実施形態では、ゲームの場面や状況の変化に合わせて、ゲーム楽曲が再生される際の拍子を変化させることで、ゲームの臨場感をより高めるものとした。しかし、これに限らず、例えば、ゲームプレイヤ（ユーザ）による操作に基づいて、ゲーム楽曲が再生される際の拍子を変化させてもよい。具体的には、ゲームプレイヤは、操作装置１２を用いて、ゲーム世界におけるプレイヤキャラクタを操作する。このとき、ゲーム世界における複数のエリアに互いに異なる拍子が関連付けられており、ゲームプレイヤの操作に応じてプレイヤキャラクタがエリア間を移動するときに、再生中のゲーム楽曲の拍子が変化するものとしてもよい。
【０１０１】
また、上記実施形態では、ゲームの場面や状況の変化に応じて、ゲーム楽曲が再生される際の拍子が変化するものとしたが、これに加えてゲーム楽曲が再生される際の音色やテンポ等が変化するものとしてもよい。
【０１０２】
また、上記実施形態では、ゲーム楽曲のデータはＭＩＤＩデータであるものとした。しかし、これに代え、あるいはこれとの組み合わせで、ゲーム楽曲のデータとして波形データを用いてもよい。この場合、波形データは、時間と周波数の関係を規定するデータであるので、楽曲の小節、拍の順序は、時間をカウントすることによって算出される。そして、この時間情報を基に、所定のタイミングで（例えば、第４拍目の再生の直前に）判定処理プログラムが実行される。
【０１０３】
また、上記変形例では、楽曲データは、通常再生用トラックと、切り替え再生用トラックとからなり、これらのトラックのいずれか一方が有音で再生されるものとしたが、これに加えて、拍子の変更に限らず常に再生される常時再生用トラックを有していてもよい。この場合、例えば、常時再生用トラックには、拍子の変更に左右されない単調な曲調が選択されることが好ましい。
【０１０４】
また、上記変形例では、楽曲データが、通常再生用トラック（４拍子用の拍子専用トラック）と、当該トラックの音符に基づいて予め音符が調整された切り替え対象トラック（３拍子用の拍子専用トラック）との１組のトラックからなる場合について説明した。しかし、楽曲データは、４拍子用の拍子専用の複数のトラックと、当該複数のそれぞれのトラックの音符に基づいて予め音符が調整された３拍子用の複数の拍子専用トラックとから構成されてもよい。
【０１０５】
また、上記実施形態は、本発明を情報処理システムの一例であるゲームシステムに適用したものであるが、他の情報処理システムや情報処理装置にも適用可能である。例えば、パーソナルコンピュータや、楽曲演奏装置等のように、楽曲データを扱う情報処理装置にも本発明の適用は可能である。
【０１０６】
また、上記実施形態では、１つの情報処理装置１４で上述した処理を実行しているが、有線又は無線で通信可能な複数の装置で上記処理を分担してもよい。
【０１０７】
また、上記実施形態において、情報処理装置１４の形状や、その構成要素等は、単なる一例に過ぎず他の形状、構成要素を有していても、本発明を実現できることは言うまでもない。また、上述した情報処理で用いられる処理順序、設定値、判定に用いられる値等は、単なる一例に過ぎず、本発明の範囲を逸脱しなければ他の順序や値であっても、本発明を実現できることは言うまでもない。
【０１０８】
また、上記実施形態の情報処理装置１４において実行される各種情報処理プログラムは、メインメモリ２２等の記憶媒体を通じて情報処理装置１４に供給されるだけでなく、有線又は無線の通信回線を通じて情報処理装置１４に供給されてもよい。また、上記プログラムは、情報処理装置１４内部の不揮発性の記憶装置に予め記録されていてもよい。なお、上記プログラムを記憶する情報記憶媒体としては、不揮発性メモリの他に、ＣＤ−ＲＯＭ、ＤＶＤ、或いはそれらに類する光学式ディスク状記憶媒体、フレキシブルディスク、ハードディスク、光磁気ディスク、磁気テープ等であってもよい。また、上記プログラムを記憶する情報記憶媒体としては、上記プログラムを一時的に記憶する揮発性メモリでもよい。
【０１０９】
以上、本発明を詳細に説明してきたが、上述の説明はあらゆる点において本発明の例示に過ぎず、その範囲を限定しようとするものではない。本発明の範囲を逸脱することなく種々の改良や変形を行うことができることは言うまでもない。
【符号の説明】
【０１１０】
１０    ゲームシステム
１２    操作装置
１４    情報処理装置
１６    表示装置
１７    スピーカ
１８    プロセッサ
２０    内部記憶装置
２２    メインメモリ
２４    外部記憶装置
【図１】
2013105085.tif 000003
【図２】
2013105085.tif 000004
【図３】
2013105085.tif 000005
【図４】
2013105085.tif 000006
【図５】
2013105085.tif 000007
【図６】
2013105085.tif 000008
【図７】
2013105085.tif 000009
【図８】
2013105085.tif 000010
【図９】
2013105085.tif 000011
【図１０】
2013105085.tif 000012