JP4525591B2 - 演奏評価装置、及びプログラム - Google Patents

Description

本発明は、楽器に設けられた演奏操作子群を操作していくことで行われた楽曲の演奏を評価するための技術に関する。

演奏は、楽器に設けられた演奏操作子群、例えば鍵盤を操作していくことで行われる。その演奏内容を演奏者が客観的に把握するのは困難なのが実情である。このことから、その演奏を評価し採点する演奏評価装置が製品化されている。現在は、楽器を用いた演奏の評価ではなく、唄った歌を評価し採点する装置も製品化されている（特許文献１）。

従来の演奏評価装置による評価（点数）は基本的に、手本となる演奏内容を示す演奏情報を参照して、演奏操作子群のなかで操作すべき演奏操作子を演奏者が正確に操作したか否か確認して行っていた。その演奏情報は、操作すべき演奏操作子、及びその操作を行っているべき操作期間を操作内容として演奏操作子単位で示す操作データを演奏（楽曲）分、有するものである。ＭＩＤＩでは楽音の発音開始、その終了をそれぞれ別のデータで表すことから、操作データは２つのＭＩＤＩデータに相当する。

演奏の難易度は楽曲によって大きく異なる。例えば単位時間当たりに操作すべき演奏操作子の数が比較的に少ない、その範囲が比較的に狭いといったような演奏内容を満たしている楽曲は演奏の難易度が低いのが普通であり、そのような楽曲を演奏すれば高い点数をとりやすい。これに対し、それらのうちの一つでも満たしていないような楽曲では、難易度が大きく変化する。それにより、前者でしか高い点数をとれない演奏者が生じることになる。演奏する楽曲によって点数が大きく異なる演奏者の割合は大きいと考えられる。

演奏する楽曲によって点数が大きく異なるということは、評価結果である点数が演奏者の演奏技術を適切に表していないことを意味する。このことから、演奏する楽曲に係わらず、演奏技術を適切に表すような評価、言い換えれば演奏する楽曲が異なっても単純に比較できるような評価を行うことが重要であると考えられる。

特許文献１に記載された従来技術では、難易度別に楽曲を分け、唄った歌を評価して求めた点数に、唄った楽曲の難易度に応じた点数を加算することにより、楽曲によって異なる難易度を考慮している。その従来技術を演奏評価装置に採用することが考えられる。しかし、楽曲を演奏するうえでの難易度は全体的に一様であるとは限らない。楽曲のなかには、例えば難易度が比較的に高い演奏区間が局所的に存在しているものもある。そのような楽曲では、難易度が比較的に低い演奏区間のみを正確に演奏できれば或る程度の点数はとれることになる。たとえ楽曲全体にわたって正確に操作できた演奏操作子が存在しなくとも、その楽曲の難易度に応じた点数はとれることになる。このようなことから、演奏技術をより適切に反映させた演奏の評価を行うためには、楽曲全体の難易度は考慮すべきではないと考えられる。
特開２００５−１０７３３４号公報 特開平７−１９９７９１号公報 実用新案登録第２５２７７２１号公報

本発明の課題は、演奏する楽曲に係わらず、演奏技術をより適切に反映させた演奏の評価を行うための技術を提供することにある。

本発明の演奏評価装置は、楽器に設けられた演奏操作子群を操作していくことで行われる楽曲の演奏を評価できるものであり、前記演奏操作子群のなかで演奏の進行に応じて、操作すべき演奏操作子より指定されるピッチ、用いるべき指を表す運指情報及び該演奏操作子の操作開始及び操作終了のタイミングを含む演奏情報を順次取得する演奏情報取得手段と、前記演奏情報取得手段により順次連続して取得される２つの演奏情報を参照し、少なくとも各演奏情報に含まれる運指情報、2つの演奏操作子で指定されるピッチ差、演奏操作子の種類及びピッチ変化方向に基づき、当該演奏操作子を操作する際の難易度を示す難易度データを対応する各演奏情報に付与する難易度データ付与手段と、前記演奏操作子群のいずれかの演奏操作子への操作開始及び操作終了のタイミングを検出するための操作検出手段と、前記操作検出手段により操作の検出された演奏操作子と前記演奏情報取得手段にて取得された演奏情報内の操作すべき演奏操作子とが同一でかつ当該両演奏操作子の操作開始から操作終了までの期間が少なくとも一部で重なり合うか否か判別する判別手段と、前記判別手段により重なり合うと判別される毎に、対応する演奏情報に付与された難易度に基づいて決定される点数を累算することにより採点を行う採点手段と、を具備する。

本発明のプログラムは、上記演奏評価装置が具備する各手段を実現させるための複数の機能を搭載している。

上記取得された演奏情報を参照することにより、演奏操作子による実際の演奏が示す演奏内容に着目した評価を行うことができる。その難易度データを参照することにより、その評価は難易度に応じた、より適切なものに補正することができる。これらのことから、演奏する楽曲に係わらず、演奏技術をより適切に反映させた演奏の評価を行えることとなる。

以下、本発明の実施の形態について、図面を参照しながら詳細に説明する。
＜第１の実施の形態＞
図１は、第１の実施の形態による演奏評価装置の構成を説明する図である。

その演奏評価装置１０は、図１に示すように、装置１０全体の制御を行うＣＰＵ１１と、そのＣＰＵ１１がワークに用いるＲＡＭ１２と、ＣＰＵ１１が実行するプログラムや各種制御用データ、及び波形データ等を格納したＲＯＭ１０３と、例えばキーボードやポインティングデバイス（マウス等）、ＣＤ−ＲＯＭやＤＶＤ等の記録媒体にアクセスする媒体駆動装置、及びそれらのインターフェース等からなる入力部１４と、表示装置に画像を表示させる表示部１５と、外部装置との間でＭＩＤＩデータを送受信するためのＭＩＤＩインターフェース（Ｉ／Ｆ）１６と、発音させる楽音のデジタルデータ（波高値）を外部装置に出力するためのオーディオインターフェース（Ｉ／Ｆ）１７と、を備えた構成となっている。

上記ＭＩＤＩ Ｉ／Ｆ１６には、それとＭＩＤＩデータを送受信可能なＭＩＤＩインターフェース（Ｉ／Ｆ）２１、及びキーボード２２を備えた電子楽器２０が接続され、上記オーディオＩ／Ｆ１７には、波高値を入力して音声に変換できる音源システム３０が接続されている。ＭＩＤＩ Ｉ／Ｆ２１は、キーボード２２に対する操作内容を示すＭＩＤＩデータを生成する機能を備えている。それにより、本実施の形態による演奏評価装置１０は、電子楽器２０のＭＩＤＩ Ｉ／Ｆ２１からＭＩＤＩデータをリアルタイムに入力して、キーボード２２を操作して行ったユーザーの演奏を評価できるものとして実現されている。入力したＭＩＤＩデータにより発音が要求された楽音の発音は、その楽音の波高値を生成し、それを音源システム３０に出力することにより行うようになっている。音源システム３０は、例えばＤ／Ａ変換器、アンプ、及びスピーカを少なくとも備えたものである。表示部１５が画像を表示させる表示装置は、外付けのもの、搭載されたものの何れであっても良い。ここでは便宜的に、表示装置は搭載されたもの、つまり表示部１５を構成しているものと想定する。

その演奏評価装置１０は、例えばパーソナルコンピューター（ＰＣ）に、演奏評価装置１０として動作させるためのアプリケーション・プログラム（以下「アプリケーション」）を搭載させることにより実現させている。そのアプリケーションは、例えば入力部１４を構成する媒体駆動装置がアクセス可能な記録媒体に記録して提供するものである。そのアプリケーションは、インターネット等のネットワークを介して配信するようにしても良い。

アプリケーションを搭載（インストール）できるように、ＲＯＭ１３としては書き込み可能なメモリ（例えばフラッシュメモリ）が採用されている。そのアプリケーションが記録された記録媒体には、楽音の波高値を生成するための各種波形データが多数、記録されている。その波形データには、音色が異なる楽音発音用のものも含まれている。音色が同じ波形データはピッチ毎に用意されている。演奏評価装置１０を実現させるＰＣは、ＲＯＭ１３の他に、或いはその代わりにハードディスク装置等の補助記憶装置を搭載したものであっても良い。そのアプリケーションについては以降「演奏評価アプリケーション」と呼ぶことにする。

各種波形データは、ＲＯＭ１３に保存させることができるようになっている。また、必要に応じて、記録媒体からコピーすることもできるようにしている。ここでは説明上、便宜的にＲＯＭ１３に保存されている場合のみを想定する。

ＲＯＭ１３に保存した波形データは、ＲＡＭ１２にコピーして使用している。これは、一般的にＲＡＭ１２はＲＯＭ１３よりもアクセス速度が速いからである。それにより、より高速に、発音させるべき楽音の波高値を生成できるようにしている。

波形データをピッチ毎に用意することにより、それを構成するサンプリングデータ（波高値）は単に順次、読み出せば良いようにしている。それにより、データを読み出す速さ（歩進幅）に応じた補間を行わなくとも良いようにしている。

ユーザーは、電子楽器２０のキーボード２２を操作して演奏を行う。その演奏では、演奏の進行に合わせて、キーボード２２を構成する鍵（演奏操作子）のなかで押鍵（操作）すべき鍵を順次、押鍵していくことが求められる。本実施の形態では、鍵単位でその鍵を押鍵する際の難易度を考慮した評価を行い、その評価を用いて演奏全体の採点を行うようにしている。

鍵単位で難易度を考慮した評価を行うことにより、押鍵すべき鍵への押鍵によって点数を与えられるようになる。特許文献１に記載された従来技術とは異なり、押鍵すべき鍵への押鍵が全く行われなくとも点数を与えるというようなことは確実に回避できる。

押鍵すべき鍵を押鍵したことの評価はその難易度に応じて異ならせることができる。押鍵するのが困難と考えられる鍵ほど、その押鍵には高い演奏技術が必要と言える。このため、難易度が高い鍵ほど、その押鍵を高く評価すれば、採点に演奏技術を適切な形で反映させることとなる。これらのことから、演奏する楽曲に係わらず、演奏技術をより適切に反映させた演奏の評価を行うことができる。

難易度に応じて評価方法を採用することができるが、多くの評価方法を採用するほど、制御が複雑となる。このことから本実施の形態では、高いか否かにより難易度を２段階、つまり難易度を示す値が定めた閾値以上か否かにより分け、難易度がその閾値以上の鍵を押鍵した場合、予め設定の点数を更に加えることで難易度を採点に反映させるようにしている。以降、その点数については「ボーナス点」と呼ぶことにする。

そのような採点を行うために、本実施の形態では図２、図３に示す各種データを管理している。ここで図２、図３を参照して、それらのデータについて具体的に説明する。
図２は、演奏データの構成を説明する図である。その演奏データは、発音させるべき楽音毎に用意されるデータである。楽曲全体の演奏内容を示す楽曲データは、発音させるべき楽音数の演奏データを有している。その演奏データは、例えば入力部１４を構成する媒体駆動装置がアクセス可能な記録媒体、或いはＲＯＭ１３に格納されている。ここでは入力部１４から入力、つまりそれを構成する媒体駆動装置がアクセス可能な記録媒体から読み出すものと想定する。そのＲＯＭ１３には、図４に示すような楽譜を表示するための楽譜データ等も格納されていると想定する。図２に示す演奏データはＲＡＭ１２に書き込まれた場合のものであり、その格納場所は、［］で示す括弧内の数値（インデクス値）で指定される。これは図３に示す発音データも同様である。

この演奏データは、発音させるべき楽音を発音させるための指の運びである運指を示す運指データを含むものである。図２に示すように、データｌＴｉｍｅ、ｌＧａｔｅ、ｌＴｍｓｅｃ、Ｐｉｔｃｈ、ｉＰｏｓＸ、ｃｆｉｇ、ｉＨａｎｄ、ｉｃｏｓｔ、ｃＩｓＨａｒｍ、ｉＡｒｐＳ、ｉＡｒｐＥ、ｐＨＴｏｐ、ｐＨＴａｉｌ、ｃＴｅｎｄｅｎｃｙ、ｃＴｅｎｄＳｔｅｐｓ、ｃＩｓＳＯ、ｐＰＦＴｏｐ、ｐＰＨＴａｉｌ、ｐＮＨＴｏｐ、ｐＮＨＴａｉｌ、ｉＮＰ、ｐｒｅｖ、及びｎｅｘｔを有している。各データは以下のようなものである。

データｌＴｉｍｅは、発音開始時刻を示すものである。その発音開始時刻は例えば演奏開始からのものをＭＩＤＩで扱う単位時間（ステップ）数で表されている。データｌＧａｔｅは発音時間を示すものである。データｌＴｍｓｅｃはデータｌＴｉｍｅが示す発音開始時刻を絶対時間（単位はｍｓｅｃ）で示すものである。データＰｉｔｃｈは楽音のピッチを示すもの（ピッチ番号、或いはノート番号と呼ぶ）である。データｉＰｏｓＸはそのピッチが割り当てられた鍵のキーボード２２上の座標（Ｘ座標）を示すものである。データｃｆｉｇは、その鍵の押鍵に割り当てられた指を示す値である。値の０は親指を示し、同様にして、１は人差し指、２は中指、３は薬指、４は小指をそれぞれ示している。データｉＨａｎｄは鍵を押鍵して発音される楽音が属するパートを示すものである。そのパートは押鍵に使う指がある手で区別されるものであり、その手が右手のパートでは１、左手では２がデータｉＨａｎｄとして格納される。データｉｃｏｓｔは、割り当てられた指で鍵を押鍵する難易度の評価値（難易度データ）である。データｃＩｓＨａｒｍは楽音が和音の構成音か否かを示すものである。その値は構成音でなければ０、構成音であれば−１となる。

データｉＡｒｐＳは、アルペジオを構成する先頭の楽音か否かを示す先頭フラグである。データｉＡｒｐＥは、その末端（最後）の楽音か否かを示す末端フラグである。それらの値は、該当するか否かによって、予め定めた２種類の値のうちの何れかとなる。データｐＨＴｏｐは、和音の先頭音（一番下の音（最低音））の演奏データの格納場所を示すポインタ（インデクス値）である。データｐＨＴａｉｌは、和音の終端音（一番上の音（最高音））の演奏データの格納場所を示すポインタ（インデクス値）である。それらのインデクス値は、楽音が和音の構成音であった場合に格納される。そうでなければ予め定めた固定値が格納される。

データｃＴｅｎｄｅｎｃｙは、楽音近傍の楽音の並び（音列）の高低傾向を示す値（０は極値、正の値は上昇傾向、負の値は下降傾向、１は変化しない踊り場、２はそれ以外（の変化あり））である。データｃＴｅｎｄＳｔｅｐｓは極値となるまでの段階数である。データｃＩｓＳＯは、ポリフォニーとなっているか否かを示すフラグである。その値の絶対値は音数を示している。正の値は前に同時発音中の楽音の存在を示し、負の値は後に同時発音中の楽音の存在を示している。データｐＰＨＴｏｐは前の音列を構成する和音の先頭音の演奏データのポインタである。データｐＰＨＴａｉｌはその和音の終端音の演奏データのポインタである。データｐＮＨＴｏｐ、ｐＮＨＴａｉｌはそれぞれ、次の音列を構成する和音の先頭音、終端音の演奏データのポインタである。データｉＮＰは割り当てた指を押鍵に使うべきでない禁止条件に該当するか否かを示す値である（０は該当しないことを示す）。データｐｒｅｖは前の演奏データのポインタである。データｎｅｘｔは次の演奏データのポインタである。

上記データｌＴｉｍｅ、ｌＧａｔｅ、ｌＴｍｓｅｃ、及びＰｉｔｃｈは発音させるべき楽音、及びそれを発音させるべき期間（タイミング）を示すデータであり、本来の演奏データ（以下、混乱を避けるために「実演奏データ」と呼ぶ）を構成する。それら、並びにデータｃｆｉｇ、及びｉＨａｎｄは運指データを構成するものである。それらのなかで、データｃｆｉｇ、及びｉＨａｎｄは本来の運指データ（以下、混乱を避けるために「実運指データ」と呼ぶ）を構成する。データｐｒｅｖ、及びｎｅｘｔを除く他のデータは、その実運指データ生成用のものである。

その実運指データは、運指がより容易となるように生成される。そのために、運指（押鍵すべき鍵の押鍵に使う指をその鍵に運ぶ動作）の難易度を計算している。本実施の形態では、そのことに着目し、その難易度を演奏評価に用いている。最終的に求められた難易度を示す値は、上記データｉｃｏｓｔとして格納される。その値は以降、コスト値と呼ぶことにする。

本実施の形態では、上記演奏データが実演奏データ分のみで構成されている場合に対応するために、運指データを生成する機能を搭載させている。それにより、実演奏データ分のみで構成されている演奏データによる評価を行う場合には、演奏データ毎に運指データを生成し、難易度を考慮した評価を行えるようにしている。

図３は、発音データの構成を説明する図である。その発音データは、発音させる楽音毎に用意されるデータである。図３に示すように、発音データは、演奏パートを示すトラック番号であるデータｉＣｈ、対応する音色データを示すデータｉＴｏｎｅ、楽音のピッチを示すデータｉＰｉｔｃｈ、そのベロシティを示すデータｉＯｎＶｅｌ、そのピッチの楽音の状態を示すデータｉＳｔａｔｕｓ（−１の値は消音中、０の値は消音、１の値は演奏データが示す押鍵時間（押鍵開始から離鍵するまでの期間）であり、且つユーザーが押鍵中である状態、２の値は演奏データが示す押鍵時間であり、且つユーザーが押鍵していない状態（押鍵が遅れている状態）、３の値は演奏情報が示す押鍵時間でなく、且つユーザーが押鍵中である状態（押鍵が早く行われた状態）、をそれぞれ表す）、その楽音における演奏判断結果を示すデータｉＲｅｓｕｌｔ（０の値は未押鍵、１の値は適切な押鍵、２の値は遅れた押鍵、３の値は早い押鍵、４の値は誤った押鍵（ミスタッチ）、をそれぞれ表す）、対応する演奏データの格納場所を示すデータｐＭＥ、対応する演奏データによる発音開始時刻を示すデータｌＯｎＳｔａｒｔ、その消音開始時刻を示すデータｌＯｆｆＳｔａｒｔ、ユーザーによる押鍵時刻（タイミング）を示すデータｌＮｏｔｅＯｎ、その離鍵時刻（タイミング）を示すデータｌＮｏｔｅＯｆｆ、前の発音データの格納場所を示すデータｐＰｒｅｖ、及び次の発音データの格納場所を示すデータｐＮｅｘｔ、を備えている。この発音データは演奏中に順次、作成され、随時、更新される。

以降は図５〜図１２に示す各種フローチャートを参照して、上述のデータを管理して楽音の発音、及び演奏評価を行う演奏評価装置１０の動作について詳細に説明する。その動作は、ＣＰＵ１３が、上記演奏評価アプリケーションをＲＯＭ１３からＲＡＭ１２に読み出して実行することで実現される。

図５は、全体処理のフローチャートである。これは、上記演奏評価アプリケーションを起動させてから終了させるまでの間に実行される処理を抜粋してその流れを示したものである。始めに図５を参照して、その全体処理について詳細に説明する。

先ず、ステップ１０１では、各種変数に初期値を代入するといった初期化を行う。次のステップ１０２では、ユーザーが指定の楽曲に対応する楽曲データをＲＯＭ１３から読み出してＲＡＭ１２に格納する。その後に移行するステップ１０３では、楽曲データを構成する演奏データで示される運指を評価するための運指評価処理を実行する。その実行後はステップ１０４に移行する。

その演奏データが運指データを含むものであるとは限らない。このことから、その運指データが演奏データに含まれていない場合、運指評価処理では運指データの生成を併せて行う。運指の評価は、運指データに不適切な部分が存在すればそれをより適切なものに更新するために実行される。その実行により、各演奏データのデータｉｃｏｓｔは必要に応じて更新され、最終的には最も適切と考えられるものとなる。

ステップ１０４では、入力部１４、或いはＭＩＤＩ Ｉ／Ｆ１６によるデータの入力を待つ。ここでは、入力部１４を操作してのデータ入力については、演奏評価アプリケーションの終了指示、演奏評価の開始（楽曲データの再生開始）、その停止（終了）のみを想定する。

電子楽器２０のキーボード２２を構成するキー（鍵）をユーザーが押鍵、或いは離鍵すると、ＭＩＤＩ Ｉ／Ｆ２１はその演奏操作の内容、及びその操作が行われたキーに応じたＭＩＤＩデータを生成して演奏評価装置１０のＭＩＤＩ Ｉ／Ｆ１６に出力する。入力部１４を構成するキーボード、或いはポインティングデバイスを操作すると、その操作内容が入力部１４からＣＰＵ１１に通知される。それにより、ステップ１０４からステップ１０５に移行し、入力が演奏評価アプリケーションの終了コマンドか否か判定する。そのアプリケーションを終了させるための操作をユーザーが入力部１４に対して行った場合、判定はＹＥＳとなり、ここで一連の処理を終了する。そうでない場合には、判定はＮＯとなってステップ１０６に移行する。

ステップ１０６では、入力がＭＩＤＩデータか否か判定する。ＭＩＤＩ Ｉ／Ｆ１６がＭＩＤＩデータを入力した場合、判定はＹＥＳとなり、ステップ１０７に移行して、その入力に対応するためのＭＩＤＩ ＩＮ処理を実行した後、上記ステップ１０４に戻る。一方、そうでない場合には、判定はＮＯとなってステップ１０８に移行する。

ステップ１０８では、上記演奏評価の開始を指示するための再生開始コマンドを入力したか否か判定する。ユーザーがそのコマンド入力のための操作を入力部１４に対して行った場合、判定はＹＥＳとなってステップ１０９に移行し、演奏評価のための再生処理を起動した後、上記ステップ１０４に戻る。そうでない場合には、判定はＮＯとなってステップ１１０に移行する。

ステップ１１０では、上記演奏評価の停止を指示するための再生停止コマンドをユーザーが入力したか否か判定する。ユーザーがそのコマンド入力のための操作を入力部１４に対して行った場合、判定はＹＥＳとなってステップ１１１に移行し、再生処理の実行を管理するための変数である再生停止フラグをオン、つまりその実行停止を示す値を代入した後、上記ステップ１０４に戻る。そうでない場合には、判定はＮＯとなり、他のステップの処理を実行することなく、そのステップ１０４に戻る。

図６は、上記ステップ１０３として実行される運指評価処理のフローチャートである。次にその評価処理について、図６に示すそのフローチャートを参照して詳細に説明する。
先ず、ステップ２０１では、運指評価に用いる各種変数の初期化等を行う。続くステップ２０２では、運指データを演奏データ中に有する楽曲データを取得するためのデータ取得処理を実行する。入力部１４を介して入力した楽曲データを構成する演奏データに運指データが含まれていない場合、その運指データを演奏データ毎に生成する処理を行う。その生成は周知の技術を用いて行う。

ステップ２０２に続くステップ２０３では、変数ｍｅに、楽曲データ中で先頭に位置する演奏データを指定するインデクス値（ポインタ）を代入する。次のステップ２０４では、運指評価が終了したか否か判定する。その評価は、変数ｍｅの値で指定される演奏データを先頭のものから最後のものまで順次、変更しながら行われる。このため、変数ｍｅの値で指定される演奏データが存在しない場合、判定はＹＥＳとなってステップ２１３に移行し、全演奏データのデータｉｃｏｓｔの値の平均値を算出して変数ＣｏｓｔＡｖｅに代入（ストア）してから一連の処理を終了する。そうでない場合には、判定はＮＯとなってステップ２０５に移行する。

ステップ２０５では、変数ｍｅの値で指定される演奏データが示す楽音（指定音）とその次に発音すべき楽音間のコストを算出する２音間コスト算出処理を実行する。次に移行するステップ２０６では、現在、注目している運指（指定音を発音させるための運指）が禁止条件とする事項の何れかに該当しているか否か確認するための禁止事項検索処理を実行する。その後はステップ２０７に移行する。

ステップ２０７では、ｍｅ．ｉＮＰの値が０でないか否か判定する。上記禁止事項検索処理では、該当する事項（禁止条件）に該当していることが判明した場合、その値として０以外の値を格納する。このことから、その場合、判定はＹＥＳとなり、ステップ２１２でｍｅ．ｉｃｏｓｔとして、想定範囲内におけるコストの最大値を格納した後、ステップ２０９に移行する。そうでない場合には、判定はＮＯとなってステップ２０８に移行し、運指に従って指定音を発音させるためのコストをより適切なものに更新するためのコスト補正処理を実行する。ステップ２０９にはその後に移行する。

ステップ２０９では、ｍｅ．ｉｃｏｓｔの値、つまり指定音のコストの値が、閾値として定めた定数ＴＨＲＣＯＳＴ（＜コストの最大値）より大きいか否か判定する。その値が定数ＴＨＲＣＯＳＴより大きい場合、判定はＹＥＳとなり、運指を修正するための運指修正処理を実行し（ステップ２１０）、その実行後に変数ｍｅにｍｅ．ｎｅｘｔの値（次の演奏データを指定するインデクス値）を代入してから（ステップ２１１）、上記ステップ２０４に戻る。一方、そうでない場合には、判定はＹＥＳとなり、次にそのステップ２１１に移行する。

上記運指修正処理での運指の修正は、特に詳細な説明は省略するが、例えば指定音の前後の部分を考慮して処理対象とする区間を決定し、決定した区間内の演奏を行ううえで可能性のある全ての運指の組み合わせのなかからコストが最小となる組み合わせを抽出することで行っている。それにより、指定音に対して最適な運指を修正時には確実に設定させている。この結果、評価に用いる運指データは全て、それが示す運指が可能、且つそのコストが異常に大きくないものとなる。

ここで、上記ステップ２０５、２０６、及び２０８で実行されるサブルーチン処理について、図７〜図１０を参照して詳細に説明する。
図７は、上記ステップ２０５として実行される２音間コスト算出処理のフローチャートである。始めに図７を参照して、そのコスト算出処理について詳細に説明する。

このコスト算出処理では、連続する２音にのみ着目する形でその２音を発音させるための運指のコストを算出するようになっている。そのコストの算出は、図８に示す運指コストテーブルを参照し、対応する値を抽出することで行っている。コスト算出処理について説明する前に、そのコストテーブルについて具体的に説明する。

図８中、「ｂｗ」は鍵盤種類（０は白鍵、１は黒鍵）、「ｐｍ」はピッチ変化方向（０は増加方向、１は減少方向）、「ｆ１」は変数ｅｖ１の値で指定される音符の指番号（その値で指定される演奏データ中のデータｃｆｉｇの値）、「ｆ２」は変数ｅｖ２の値で指定される音符の指番号、「ｉｎｔｖ」はそれら２つの音符間のピッチ差、をそれぞれ表している。それにより、テーブルは、それらのデータの各値の組み合わせで示される状況別に、その状況下での運指のコスト（の値）を格納したものとなっている。このことから、２音間コスト算出処理では、それらのデータの各値を求め、各値の組み合わせで指定される欄に格納されたコスト（値）を抽出し、それを指定音の運指のコストとして更新するようになっている。運指コストテーブルは、５個の値によって示される状況別にコストの値を格納したものであることから、図７中では５次元の配列変数ＣＴとして「ＣＴ［ｂｗ］［ｐｍ］［ｆ１］［ｆ２］［ｉｎｔｖ］」と表記している。以降、その図７に示すコスト算出処理について詳細に説明する。

先ず、ステップ３０１では、変数ｅｖ１、及びｅｖ２にそれぞれ、変数ｍｅの値、及びｍｅ．ｎｅｘｔの値を代入する。続くステップ３０２では、変数ｆ１にｅｖ１．ｃｆｉｇの値、変数ｐ１にｅｖ１．ｉＰｏｓＸの値、変数ｂｗに変数ｐ１の値を２で割った余り（図中「ｐ１％２」と表記）、変数ｆ２にｅｖ２．ｃｆｉｇの値、変数ｐ２にｅｖ２．ｉＰｏｓＸの値、をそれぞれ代入する。その代入後に移行するステップ３０３では、変数ｐ１の値が変数ｐ２の値以下か否か判定する。後者が前者より大きい場合、判定はＹＥＳとなり、ステップ３０４で０を変数ｐｍに、変数ｐ２の値から変数ｐ１の値を引いた値を変数ｉｎｔｖにそれぞれ代入してからステップ３０６に移行する。そうでない場合には、判定はＮＯとなり、ステップ３０５で１を変数ｐｍに、変数ｐ１の値から変数ｐ２の値を引いた値を変数ｉｎｔｖにそれぞれ代入してからステップ３０６に移行する。

ステップ３０６５では、変数ｉｎｔｖの値が定数ＭＡＸＩＮＴＶ以下か否か判定する。その定数ＭＡＸＩＮＴＶは、運指により押鍵を行う難易度が極めて高いと考えられる鍵間（ピッチ差）を判定するために用意したものである。このことから、着目する２つの音符の間にそのようなピッチ差が存在していない場合、判定はＹＥＳとなり、ステップ３０７でｅｖ１．ｉｃｏｓｔとして、変数ｂｗ、ｐｍ、ｆ１、ｆ２、及びｉｎｔｖの各値によって運指コストテーブル（図８）から抽出される値（図中「ＣＴ［ｂｗ］［ｐｍ］［ｆ１］［ｆ２］［ｉｎｔｖ］」と表記）を代入した後、一連の処理を終了する。そうでない場合には、判定はＮＯとなり、ステップ３０８でｅｖ１．ｉｃｏｓｔとして定数ＭＡＸＣＯＳＴを代入した後、一連の処理を終了する。

上記定数ＭＡＸＣＯＳＴは、例えばコストとして想定する範囲内で最大値として定めたものである。図６中のステップ２１２では最大値としてこの定数ＭＡＸＣＯＳＴにｍｅ．ｉｃｏｓｔを更新するようになっている。

上述したような構成の運指コストテーブルでは、２音間の発音開始時刻の時間間隔が考慮されていない。その時間間隔が短くなるほど、運指は困難となるのが普通である。このことから、上記ステップ３０７では、特には図示していないが、ｅｖ１．ｉｃｏｓｔとして、変数ｂｗ、ｐｍ、ｆ１、ｆ２、及びｉｎｔｖの各値によって運指コストテーブルから値を抽出した後、抽出値に時間間隔に応じた係数を乗算し、その乗算結果をｅｖ１．ｉｃｏｓｔとして格納している。

図９は、図６に示す運指評価処理内でステップ２０６として実行される禁止事項検索処理のフローチャートである。次に図９を参照して、その検索処理について詳細に説明する。

例えば親指や小指はその長さ、手における位置などの理由により、鍵盤上の黒鍵の押鍵はそれ以外の指よりも困難である。同じ指を使った連続する押鍵は、離鍵から押鍵までの時間間隔、押鍵する鍵間の距離（音高（ピッチ）差）などに応じて難易度（コスト）が変化する。時間間隔が短く、且つ鍵間の距離が大きいような場合、その押鍵は不可能か、或いは極めて困難となる。他にも不可能、或いは極めて困難な運指は存在する。このようなことから、検索処理では、指定音に割り当てられた運指が不可能、或いは極めて困難と考えられる条件（禁止事項）毎に、それを満たしているか否か検索により確認するようになっている。

先ず、ステップ４０１では、親指や小指といった比較的に短い指で演奏者から見て離れた場所にある黒鍵を押鍵するような運指を禁止条件に該当しているとして検出するための黒鍵の指使い検出処理を実行する。次のステップ４０２では、和音を発音させる場合に、或る指で押鍵する鍵より高音の鍵をその指より低音側に位置する指で押鍵する、或いはその逆に押鍵するといったことを禁止事項として検出するための和音での指の逆転検出処理を実行する。その後はステップ４０３に移行する。

ステップ４０３では、複数の鍵を押鍵する状況下で、同時に押鍵していることが不可能と考えられる指の割り当てを禁止条件として検出するための指の開き幅の限界検出処理を実行する。続くステップ４０４では、同時に押鍵していることが不可能な数の押鍵を禁止条件として検出するための多声条件検出処理を実行する。その実行後、一連の処理を終了する。

上記ステップ４０１〜４の各検出処理では、禁止条件を満たしていることが確認された場合、ｍｅ．ｉＮＰとして０以外の値を格納（更新）する。それにより、図６に示す運指評価処理では、ステップ２０７の判定がＹＥＳとなって、その指定音のコストは最大値に更新されることとなる。

図１０は、図６に示す運指評価処理内でステップ２０８として実行されるコスト補正処理のフローチャートである。その運指評価処理内で実行されるサブルーチン処理では、最後に図１０を参照してその補正処理について詳細に説明する。

先ず、ステップ５０１では、運指に従って指定音を発音させる際の状況を示す各種値を対応する変数に代入するための処理を実行する。次のステップ５０２では、変数ｍｅの値で指定される演奏データが示す楽音（指定音）の発音開始時刻に発音中の他の楽音、或いはその発音終了時刻前に発音を開始する他の楽音に着目してコストを補正するための多声音の補正処理を実行する。続くステップ５０３では、指定音の押鍵に必要な、指越え、或いは指くぐりという比較的に高度な演奏方法に着目してコストを補正するための指越え／指くぐりでの補正処理を実行する。その次のステップ５０４では、分散和音とそれに続く分散和音間の相互関係に着目してコストを補正するための分散和音での補正処理を実行する。その後はステップ５０５に移行する。

ステップ５０５では、単音が続く音符群とそれに続く和音間の相互関係に着目してコストを補正するための短音→和音遷移での補正処理を実行する。続くステップ５０６では、和音とそれに続く単音の音符群間の相互関係に着目してコストを補正するための和音→短音遷移での補正処理を実行する。その次のステップ５０７では、和音とそれに続く和音間の相互関係に着目してコストを補正するための和音→和音遷移での補正処理を実行する。その次に移行するステップ５０８では、和音とその直前に位置する和音間の相互関係に着目してコストを補正するための前方和音補正処理を実行する。一連の処理はその後に終了する。

このようにして、コスト補正処理では、互いに異なる内容毎に、その内容に着目してコストを必要に応じて補正するための処理を実行するようになっている。それにより、コスト補正処理を実行する前の指定音のコスト（ｍｅ．ｉｃｏｓｔ）の値は、該当する内容の有無、その数に応じて補正される（以上のようなコストの算出についての参考技術文献としては、本出願人が出願した特願２００４−２６１０２０号が挙げられる）。

図５に示す全体処理内で実行されるサブルーチン処理の説明に戻る。
図１１は、図５に示す全体処理内でステップ１０７として実行されるＭＩＤＩ ＩＮ処理のフローチャートである。次にそのＩＮ処理について、図１１に示すそのフローチャートを参照して詳細に説明する。

このＩＮ処理は、ＭＩＤＩ Ｉ／Ｆ１７を介して入力したＭＩＤＩデータに対応するための処理である。ここでは本発明に特に係わるデータ、つまりノートオンメッセージ、ノートオフメッセージの２種類のＭＩＤＩデータのみにのみ注目する。理解を容易とするために、図５に示す全体処理内のステップ１０９で再生処理が起動された場合に実行される処理を抜粋してその流れを示している。

上述したように、発音データ中のデータｌＯｎＳｔａｒｔ（演奏データ中のデータｌＴｉｍｅ）は演奏開始からの時間を示している。そのような時間で押鍵すべきタイミングを表していることから、再生処理の起動時に時間を計時するためのカウントを０から開始させるようにしている。そのカウント、つまり時間の計時は、例えばＣＰＵ１１に内蔵のハードタイマを用いて行っている。特に断らない限り、現在時刻はそのようにして計時した時間を指す意味で用いる。

先ず、ステップ６０１では、入力したＭＩＤＩデータが楽音の発音終了を指示するノートオフメッセージか否か判定する。そのＭＩＤＩデータがノートオフメッセージだった場合、判定はＹＥＳとなってステップ６０２に移行する。そうでない場合には、判定はＮＯとなってステップ６１２に移行する。

ステップ６０２では、入力したＭＩＤＩデータから、チャンネル番号、及びピッチ番号（ノートナンバー）を抽出し、それぞれ変数ｉＣｈ、及びｉＰｉｔに代入する。続くステップ６０３では、変数ｎｄに、先頭に位置する発音データのインデクス値を代入する。その代入後に移行するステップ６０４では、変数ｎｄの値で指定される発音データが存在しないか否か判定する。その発音データが存在しない場合、判定はＹＥＳとなってステップ６２５に移行し、表示部１５の表示内容を必要に応じて更新した後、一連の処理を終了する。そうでない場合には、判定はＮＯとなってステップ６０５に移行する。

図４は、再生処理の実行中に表示される画面を説明する図である。本実施の形態では、演奏する楽曲の楽譜と併せて、現在までの採点結果を表示するようにしている。「ＬｅｆｔＴｒａｃｋ」、「ＲｉｇｈｔＴｒａｃｋ」「ＳＣＯＲＥ」がそれぞれ配置されたエリアに表示された数値は、左手パートでの採点結果、右手パートでの採点結果、全体での採点結果（＝左手パートでの採点結果＋右手パートでの採点結果）を表している。楽譜、それらのうちの何れかの採点結果を更新する必要があった場合に、ステップ６２５では表示の更新を行う。

ステップ６０５では、ｎｄ．ｉＰｉｔｃｈの値が変数ｉＰｉｔの値と一致するか否か判定する。それらが一致する場合、判定はＹＥＳとなってステップ６０７に移行し、そうでない場合には、判定はＮＯとなり、ステップ６０６で変数ｎｄにｎｄ．ｐＮｅｘｔを代入した後、上記ステップ６０４に戻る。

ステップ６０７では、ｎｄ．ｉＳｔａｔｕｓの値が１か否か判定する。その値が１であった場合、判定はＹＥＳとなり、ユーザーは離鍵すべきタイミングとなる前の鍵を離鍵したとして、ステップ６０８でｎｄ．ｉＳｔａｔｕｓの値を２に更新し、更にステップ６０９でｎｄ．ｌＮｏｔｅＯｆｆを現在時刻に更新した後、上記ステップ６２５に移行する。そうでない場合には、判定はＮＯとなってステップ６１０に移行する。

ステップ６１０では、ｎｄ．ｉＳｔａｔｕｓの値が３か否か判定する。その値が３であった場合、判定はＹＥＳとなり、ステップ６１１でｎｄ．ｉＳｔａｔｕｓの値を−１に更新した後、上記ステップ６０９に移行する。そうでない場合には、判定はＮＯとなって上記ステップ６０６に移行する。ここでのＹＥＳの判定は、主に離鍵すべきタイミングとなった鍵をユーザーが離鍵していないことを意味する。

上記ステップ６０１の判定がＮＯとなって移行するステップ６１２では、入力したＭＩＤＩデータが楽音の発音開始を指示するノートオンメッセージか否か判定する。そのＭＩＤＩデータがノートオンメッセージでなかった場合、判定はＮＯとなり、ここで一連の処理を終了する。そうでない場合には、判定はＹＥＳとなってステップ６１３に移行する。

ステップ６１３では、入力したＭＩＤＩデータから、チャンネル番号、ノートナンバー（ピッチ）、及びベロシティ値を抽出し、それぞれ変数ｉｃｈ、ｉＰｉｔ、及びｉＶｅｌに代入する。続くステップ６１４では、変数ｎｄに、発音データのなかで先頭に位置する発音データの格納場所を示すインデクス値を代入する。その代入後に移行するステップ６１５〜６２４では、入力したＭＩＤＩデータに応じて、対応する発音データを作成、或いは更新するための処理を行う。

先ず、ステップ６１５では、変数ｎｄの値が示す発音データが存在しないか否か判定する。今回、入力したＭＩＤＩデータに対応する発音データは、変数ｎｄの値で指定される発音データ中のデータｐＮｅｘｔをその変数ｎｄに新たに代入していくことにより、順次、対象とする発音データを変更しながら探すようになっている。最後に位置する発音データにはそれに続く発音データが存在しないため、データｐＮｅｘｔの値は初期値のままとなっている。このため、変数ｎｄに新たに代入した値がその初期値であった場合、判定はＹＥＳとなってステップ６２６に移行する。そうでない場合には、判定はＮＯとなってステップ６１６に移行する。ここでのＹＥＳの判定は、ユーザーが押鍵すべきタイミングとなる前の鍵を押鍵したことを意味する。

ステップ６１６では、変数ｎｄの値で指定される発音データ中のデータｉＳｔａｔｕｓ（図中「ｎｄ．ｉＳｔａｔｕｓ」と表記）の値が２と一致し、且つｎｄ．ｉＰｉｔｃｈが示すピッチ番号が変数ｉＰｉｔのそれと一致するか否か判定する。それらのうちの少なくとも一つが一致しない場合、判定はＮＯとなってステップ６１７に移行し、変数ｎｄにｎｄ．ｐＮｅｘｔを代入した後、上記ステップ６１５に戻る。そうでない場合には、つまりそれらが共に一致する場合には、判定はＹＥＳとなってステップ６１８に移行する。

ステップ６１８では、現在時刻（再生処理起動から経過した時間）からｎｄ．ｌＯｎＳｔａｒｔが示す時間を引いて得られる時間を示す値を変数ｌＤｉｆに代入する。次のステップ６１９では、変数ｌＤｉｆの値が、許容できるとする最大時間を示す定数ＤＥＬＡＹ＿ＡＬＬＯＷより小さいか否か判定する。ここではその変数ｌＤｉｆの値は押鍵が早かった時間を示している。このため、十分に短い時間だけ早く押鍵した場合、判定はＹＥＳとなり、ｎｄ．ｉＳｔａｔｕｓの値を１、ｎｄ．ｉＲｅｓｕｌｔの値を２にそれぞれ更新してから（ステップ６２０）、ステップ６２１に移行する。そうでない場合には、判定はＮＯとなって上記ステップ６１７に移行する。

ステップ６２１では、変数ｌＤｉｆの値が定数ＤＥＬＡＹ＿ＯＫ未満か否か判定する。その値が定数ＤＥＬＡＹ＿ＯＫ未満であった場合、判定はＹＥＳとなり、ステップ６２２でｎｄ．ｉＲｅｓｕｌｔとして１を格納し、次にステップ６２３で採点のための採点処理を実行した後、ステップ６２４に移行する。そのステップ６２４では、ｎｄ．ｌＮｏｔｅＯｎとして現在時刻（曲頭からの演奏時間）、ｎｄ．ｉＯｎＶｅｌとして変数ｉＶｅｌの値をそれぞれ格納し、その後は上記ステップ６２５に移行する。

このようにして、変数ｎｄの値をインクリメントしながら、その値で指定される発音データが、入力したＭＩＤＩデータに対応するものか否か確認し、対応していると確認できた発音データの更新、及び採点を行うようにしている。

上記ステップ６１５の判定がＹＥＳとなって移行するステップ６２６では、変数ｎｄに、新たに作成する発音データの格納場所を示すインデクス値を代入する。また、ｎｄ．ｐＰｒｅｖとしてはそれまで最後に位置していた発音データのインデクス値を格納し、その発音データ中のデータｐＮｅｘｔは変数ｎｄの値に更新する。ｎｄ．ｐＮｅｘｔとしては、最後に位置する発音データであることを示す値を格納する。続くステップ６２７では、ｎｄ．ｉＳｔａｔｕｓとして３、ｎｄ．ｉＰｉｔｃｈとして変数ｉＰｉｔの値、ｎｄ．ｉＲｅｓｕｌｔとして４をそれぞれ格納する。また、ｎｄ．ｆＲｅｌｅａｓｅ、ｎｄ．ｐＮｅｘｔ、ｎｄ．ｌＯｎＳｔａｒｔ、ｎｄ．ｌＯｆｆＳｔａｒｔ、ｎｄ．ｌＮｏｔｅＯｆｆとして例えばそれぞれ所定の初期値を格納する。その後に上記ステップ６２４に移行する。

図１２は、図５に示す全体処理内のステップ１０９で起動される再生処理のフローチャートである。次に図１２を参照して、その再生処理について詳細に説明する。
先ず、ステップ７０１では、変数ｍｅに、演奏情報のなかで先頭に位置する演奏データの格納場所を示すインデクス値を代入する。続くステップ７０２では、上記再生停止フラグがオンとなっているか否か判定する。再生停止コマンドの入力によってそのフラグがオンされた場合、判定はＹＥＳとなり、ステップ７０３で発音データ全てのデータｉＳｔａｔｕｓの値を０に更新した後、一連の処理を終了する。そうでない場合には、判定はＮＯとなってステップ７０４に移行する。

ステップ７０４では、発音中の楽音の存在を確認するための変数ＡｌｌＯｆｆに、それが存在しないことを示す値の１を代入し、変数ｎｄに、先頭に位置する発音データのインデクス値を代入する。次のステップ７０５では、変数ｎｄの値で指定される発音データが存在しないか否か判定する。その発音データが存在しない場合、判定はＹＥＳとなってステップ７１４に移行する。そうでない場合には、判定はＮＯとなってステップ７０６に移行する。そのステップ７０６〜７１３では、演奏データを参照して、ユーザーによる離鍵時刻に着目した発音データの更新を行うための処理が行われる。

先ず、ステップ７０６では、ｎｄ．ｉＳｔａｔｕｓの値が０以外か否か、つまり変数ｎｄの値で指定される発音データによって楽音を発音させていないか否か判定する。楽音を発音させていない場合、判定はＮＯとなり、ステップ７０７で変数ｎｄにｎｄ．ｐＮｅｘｔを代入した後、上記ステップ７０５に戻る。そうでない場合には、判定はＹＥＳとなってステップ７０８に移行する。

ステップ７０８では、楽音が発音中であることを示す値の０を変数ＡｌｌＯｆｆに代入する。次のステップ７０９では、ｎｄ．ｌＯｆｆＳｔａｒｔが示す消音開始時刻が現在時刻より前か否か判定する。現在、対象としている発音データが既に離鍵しているべき鍵に対応するものであった場合、その関係が成り立つことから、判定はＹＥＳとなってステップ７１０に移行する。そうでない場合には、判定はＮＯとなって上記ステップ７０７に移行する。

ステップ７１０では、ｎｄ．ｉＳｔａｔｕｓの値が２か否か判定する。その値が２であった場合、判定はＹＥＳとなり、離鍵すべきタイミングとなる前にユーザーが離鍵した鍵がそのタイミングになったとして、ステップ７１１でｎｄ．ｉＳｔａｔｕｓの値を−１に更新した後、上記ステップ７０７に移行する。そうでない場合には、判定はＮＯとなってステップ７１２に移行する。

ステップ７１２では、ｎｄ．ｉＳｔａｔｕｓの値が１か否か判定する。その値が１であった場合、判定はＹＥＳとなり、離鍵すべきタイミングとなった鍵をユーザーが離鍵していないとして、ステップ７１３でｎｄ．ｉＳｔａｔｕｓの値を３に更新した後、上記ステップ７０７に移行する。そうでない場合には、判定はＮＯとなって次にそのステップ７０７に移行する。

上記ステップ７０５の判定がＹＥＳとなって移行するステップ７１４では、変数ＡｌｌＯｆｆの値が１と一致し、且つ変数ｍｅの値で指定される演奏データが存在しない（直前に対象としていた演奏データが最後のもの）か否か判定する。その値が１と一致し、且つその演奏データが存在しない場合、判定はＹＥＳとなり、発音ガイドを終了すべきタイミングが到来したとして、ステップ７３０でそれに対応するための表示の更新を行ってから一連の処理を終了する。そうでない場合には、判定はＮＯとなってステップ７１５に移行する。そのステップ７１５以降では、演奏データを参照しての発音データの作成、或いはユーザーによる押鍵時刻に着目した発音データの更新のための処理が行われる。

先ず、ステップ７１５では、ｍｅ．ｌＴｉｍｅが示す発音開始時刻が現在時刻（再生開始からの時間）より前か否か判定する。その発音開始時刻（押鍵すべきタイミング）が現在時刻より前であった場合、判定はＹＥＳとなってステップ７１６に移行する。そうでない場合には、判定はＮＯとなって上記ステップ７０２に戻る。

ステップ７１６では、変数ｎｄに、先頭に位置する発音データのインデクス値を代入する。その代入後に移行するステップ７１７では、変数ｎｄの値で指定される発音データが存在しないか否か判定する。その発音データが存在しない場合、判定はＹＥＳとなってステップ７２８に移行し、そうでない場合には、判定はＮＯとなってステップ７１８に移行する。

ステップ７１８では、ｎｄ．ｉＳｔａｔｕｓの値が３と一致し、且つｎｄ．ｉＰｉｔｃｈの値がｍｅ．Ｐｉｔｃｈの値と一致するか否か判定する。それらのうちの少なくとも一つが一致しない場合、判定はＮＯとなってステップ７１９に移行し、変数ｎｄにｎｄ．ｐＮｅｘｔを代入した後、上記ステップ７１７に戻る。そうでない場合には、つまりそれらが共に一致する場合には、判定はＹＥＳとなってステップ７２０に移行する。そのＹＥＳの判定は、対象としている発音データは、押鍵すべきタイミングとなる前の鍵をユーザーが押鍵することで作成されたことを意味する。

ステップ７２０では、現在時刻（再生処理起動から経過した時間）からｎｄ．ｌＮｏｔｅＯｎが示す時間を引いて得られる時間を示す値を変数ｌＤｉｆに代入する。次のステップ７２１では、変数ｌＤｉｆの値が定数ＤＥＬＡＹ＿ＡＬＬＯＷより小さいか否か判定する。その値が示す時間が十分に短いような場合、判定はＹＥＳとなり、ｎｄ．ｉＳｔａｔｕｓの値を１、ｎｄ．ｉＲｅｓｕｌｔの値を３にそれぞれ更新してから（ステップ７２２）、ステップ７２３に移行する。そうでない場合には、判定はＮＯとなって上記ステップ７１９に移行する。

ステップ７２３では、変数ｌＤｉｆの値が定数ＤＥＬＡＹ＿ＯＫ未満か否か判定する。その値が定数ＤＥＬＡＹ＿ＯＫ未満であった場合、判定はＹＥＳとなり、ステップ７２４でｎｄ．ｉＲｅｓｕｌｔとして１を格納し、次にステップ７２５で採点処理を実行した後、ステップ７２６に移行する。

ステップ７２６では、ｎｄ．ｌＯｎＳｔａｒｔとしてｍｅ．ｌＴｉｍｅ、ｎｄ．ｌＯｆｆＳｔａｒｔとして現在時刻（曲頭からの演奏時間）にｍｅ．ｌＧａｔｅの値を加算した値、ｎｄ．ｐＭＥとして変数ｍｅの値をそれぞれ格納する。次のステップ７２７では、変数ｍｅに、ｍｅ．ｎｅｘｔの値を代入する。その後は上記ステップ７０２に戻る。

上記ステップ７１７の判定がＹＥＳとなって移行するステップ７２８では、変数ｎｄに、新たに作成する発音データの格納場所を示すインデクス値を代入する。ｎｄ．ｐＰｒｅｖとしてそれまで最後に位置していた発音データのインデクス値を格納し、その発音データ中のデータｐＮｅｘｔは変数ｎｄの値に更新する。ｎｄ．ｐＮｅｘｔとしては、最後に位置する発音データであることを示す値を格納する。続くステップ７２９では、ｎｄ．ｉＳｔａｔｕｓとして２、ｎｄ．ｉＰｉｔｃｈとしてｍｅ．Ｐｉｔｃｈ、ｎｄ．ｉＲｅｓｕｌｔとして０、をそれぞれ格納する。また、ｎｄ．ｆＲｅｌｅａｓｅ、ｎｄ．ＮｏｔｅＯｎ、ｎｄ．ｌＮｏｔｅＯｆｆ、ｎｄ．ｐＮｅｘｔとして例えばそれぞれ所定の初期値を格納し、そのようなことを行った後に上記ステップ７２６に移行する。

このようにして、変数ｎｄの値をインクリメントしながら、その値で指定される発音データが、入力したＭＩＤＩデータに対応するものか否か確認し、対応していると確認できた発音データの更新、及び採点を行うようにしている。

図１３は、上記ステップ７２５、或いは図１１に示すＭＩＤＩ ＩＮ処理内のステップ６２３として実行される採点処理のフローチャートである。最後に図１３を参照して、その採点処理について詳細に説明する。

先ず、ステップ８０１では、変数ｉＳｃｏｒｅに基準点として設定の５０を代入する。続くステップ８０２では、対象の演奏データを指定するインデクス値を変数ｍｅに代入する。その変数ｍｅはローカル変数であり、それに代入するインデクス値は、図１１に示すＭＩＤＩ ＩＮ処理、及び図１２に示す再生処理それぞれのローカル変数である変数ｍｅの値である。

ステップ８０２に続くステップ８０３では、ｍｅ．ｉｃｏｓｔの値が変数ＣｏｓｔＡｖｅに代入されている、全演奏データのデータｉｃｏｓｔの値の平均値より大きいか否か判定する。ｍｅ．ｉｃｏｓｔの値がその平均値以下であった場合、判定はＮＯとなり、ボーナス点を加える必要はないとしてステップ８０５に移行する。そうでない場合には、判定はＹＥＳとなり、ステップ８０４で変数ｉＳｃｏｒｅの値を、ボーナス点として定めた５０を加えた値に更新した後、そのステップ８０５に移行する。なお、ｍｅ．ｉｃｏｓｔの値と比較する値（コスト）は、様々な楽曲を考慮して決定した固定的な値としても良い。そのような値を採用した場合には、評価結果を正規化することができる。それにより、演奏する楽曲に係わらず、評価結果から自身の演奏技術を適切に把握できるようになる。

ステップ８０５では、図１１に示すＭＩＤＩ ＩＮ処理、或いは図１２に示す再生処理から渡された変数ｌＤｉｆの値の絶対値が、定数ＤＥＬＡＹ＿ＯＫ未満か否か判定する。ユーザーによる押鍵が高い精度で押鍵すべきタイミングと一致していた場合、判定はＹＥＳとなり、ステップ８０６で変数ｉＳｃｏｒｅの値をそれまでの２倍に更新する形でボーナス点を加えた後、ステップ８０７に移行する。そうでない場合には、判定はＮＯとなってそのステップ８０７に移行する。

ステップ８０７では、ｐＭＥ．ｉＨａｎｄの値が１、つまりユーザーが操作（ここでは押鍵）した鍵は右手パートの楽音を発音させるためのものか否か判定する。その楽音が右手パートに属するものであった場合、判定はＹＥＳとなり、ステップ８０８で変数ｒＴｏｔａｌにそれまでの値に変数ｉＳｃｏｒｅの値を加算した値を新たに代入した後、一連の処理を終了する。そうでない場合には、判定はＮＯとなり、ステップ８０９で変数ｌＴｏｔａｌにそれまでの値に変数ｉＳｃｏｒｅの値を加算した値を新たに代入した後、一連の処理を終了する。

上記変数ｉＳｃｏｒｅ、ｌＳｃｏｒｅはそれぞれ、右手パート、左手パート別に点数の累算値を保持させるために用意している。それらの値は、そのときの時点でのパート別の総得点を表している。このことから、それらのうちの一方を更新した場合、その更新後の値、及び全パートでの総得点を更新するようにしている（図４）。それにより、ユーザーに演奏評価の途中経過をリアルタイムで通知するようにしている。

なお、本実施の形態では、電子楽器２０からＭＩＤＩデータを入力することにより、ユーザーが行った演奏操作をリアルタイムに検出し、その評価を行う形となっている。しかし、その評価は、通常の楽曲データが示す演奏操作を対象に行っても良い。つまり、ユーザーが行う演奏操作をリアルタイムで評価しなくとも良い。

また、本実施の形態では、ミスタッチ、つまり押鍵すべきでない鍵への押鍵は無視している。しかし、そのようなミスタッチをユーザーに知らせるようにしても良い。その実現は、例えば図１１に示すＭＩＤＩ ＩＮ処理を例えば図１４に示すように変更することで行うようにしても良い。図１１に示すステップの処理内容と同じ、或いは基本的に同じステップには同一の符号を付して説明を省略する。これは他の図でも同様とする。

その図１４に示すＭＩＤＩ ＩＮ処理では、ステップ６０９の処理を実行した後、ステップ９０１に移行し、ｎｄ．ｉＲｅｓｕｌｔの値がミスタッチを示す４か否か判定する。その値が４であった場合、判定はＹＥＳとなり、ステップ９０２で変数ｉＰｏｉｎｔに−５０を代入し、その次に移行するステップ６２５でその変数ｉＰｏｉｎｔの値を表示部１５に図４に示すように表示させた後、一連の処理を終了する。そうでない場合には、判定はＮＯとなってそのステップ６２５に移行する。このときには例えば表示させている楽譜のみを必要に応じて更新する。

本実施の形態では、押鍵されたタイミングに着目して評価を行っている。しかし、離鍵されたタイミングに着目した評価を行うようにしても良い。その実現は、例えば図１４に示すＭＩＤＩ ＩＮ処理を例えば図１５に示すように変更することで行うようにしても良い。

その図１５に示すＭＩＤＩ ＩＮ処理では、ステップ９０１でＮＯと判定した場合、次にステップ１０００に移行して、変数ｌＤｉｆに、現在時刻からｎｄ．ｌＯｆｆＳｔａｒｔの値、つまりユーザーが離鍵したタイミングが離鍵すべきタイミングから遅れた時間を示す値を代入する。続くステップ１００１では、ｎｄ．ｉＲｅｓｕｌｔの値が１、２、或いは３と一致するか否か判定する。その値がそれらのうちの何れかと一致する場合、判定はＹＥＳとなり、ステップ１００２で採点処理を実行した後、上記ステップ６２５に移行する。そうでない場合には、判定はＮＯとなり、そのステップ６２５に移行する。それにより、演奏データが示す鍵をその鍵を押鍵しているべき期間内にユーザーがその鍵を押鍵すれば、離鍵したタイミングに応じた加点を行うようになっている。
＜第２の実施の形態＞
上記第１の実施の形態では、ボーナス点の加算は押鍵タイミング、或いは離鍵タイミングに着目して行っている。これに対し、第２の実施の形態は、適切と見なせる押鍵が連続して行われた回数に着目してそのボーナス点を加算するようにしたものである。

第２の実施の形態における演奏評価装置の構成は、基本的に第１の実施の形態におけるそれと同じである。動作も大部分は同じか、或いは基本的に同じである。このことから、第１の実施の形態で付した符号をそのまま用いて、第１の実施の形態から異なる部分についてのみ説明する。

第２の実施の形態では、ＭＩＤＩ ＩＮ処理、及び採点処理に第１の実施の形態から異なる部分が存在する。このことから、それら２つの処理における相違に着目して説明を行う。

図１６は、第２の実施の形態におけるＭＩＤＩ ＩＮ処理のフローチャートである。ここでは、図１５に示すＩＮ処理から異なる部分についてのみ説明する。
図１６に示すＩＮ処理では、ステップ６０９の処理を実行した後、ステップ１１０１に移行する。そのステップ１１０１では、ｎｄ．ｉＲｅｓｕｌｔの値が０か否か判定する。ユーザーが押鍵すべき鍵を押鍵しなかった場合、その値は０となることから、判定はＹＥＳとなり、ステップ１１０２で変数ｉＳｕｃｃｅｓｓに０を代入した後、上記ステップ６２５に移行する。そうでない場合には、判定はＮＯとなってステップ９０１に移行する。その変数ｉＳｕｃｃｅｓｓは、適切と見なせる押鍵が連続して行われた回数をカウントするために用意したものである。

そのステップ９０１の判定がＹＥＳとなると、ステップ９０２に移行して、変数ｉＰｏｉｎｔに−５０を代入する。続くステップ１１０３では、ミスタッチを行ったとして、変数ｉＳｕｃｃｅｓｓに０を代入する。その後は上記ステップ６２５に移行する。

図１７は、第２の実施の形態における採点処理のフローチャートである。
図１７に示す採点処理では、ステップ８０５の判定がＮＯとなるか、或いはステップ８０６の処理を実行することでステップ１２０１に移行し、変数ｉＳｕｃｃｅｓｓの値をインクリメントする。その次に移行するステップ１２０２では、変数ｉＳｕｃｃｅｓｓの値を定数ｂＴｉｍｅで割ったときの余り（図中「ｉＳｕｃｃｅｓｓ％ｂＴｉｍｅ」と表記）が０と一致するか否か判定する。その余りは、変数ｉＳｕｃｃｅｓｓの値が定数ｂＴｉｍｅの倍数となった場合に０となる。このことから、その値が定数ｂＴｉｍｅの倍数であった場合、判定はＹＥＳとなってステップ１２０３に移行し、変数ｉＳｃｏｒｅに、変数ｉＳｕｃｃｅｓｓの値を定数ｂＴｉｍｅで割って得られる値の小数点以下を切り捨てて整数化した値に１０を乗算し、その乗算結果をそれまでの値に加算して得られる値（図中「ｉＳｃｏｒｅ＋Ｉｎｔ（ｉＳｕｃｃｅｓｓ／ｂＴｉｍｅ」と表記）を代入することでボーナス点を加算する。その後はステップ８０７に移行する。一方、そうでない場合には、判定はＮＯとなってそのステップ８０７に移行する。

なお、本実施の形態（第１、第２の実施の形態）は、ＰＣ等のデータ処理装置に本発明を適用したものである。その適用は、本実施の形態によるプログラムに相当する演奏評価アプリケーションをデータ処理装置に実行させることで実現させている。そのようなアプリケーションは電子楽器、音源装置等に搭載させる演奏評価装置用に開発しても良い。開発したアプリケーションは、ＣＤ−ＲＯＭ、ＤＶＤ、或いは着脱自在なフラッシュメモリ等の記録媒体に記録させて配布しても良い。公衆網等の通信ネットワークを介して、そのプログラムの一部、若しくは全部を配信するようにしても良い。そのようにした場合には、ユーザーはプログラムを取得してデータ処理装置、或いは演奏評価装置（それを搭載した装置）にロードすることにより、その装置に本発明を適用させることができる。このことから、記録媒体は、プログラムを配信する装置がアクセスできるものであっても良い。

第１の実施の形態による演奏評価装置の構成を説明する図である。 演奏データの構成を説明する図である。 発音データの構成を説明する図である。 再生処理の実行中に表示される画面を説明する図である。 全体処理のフローチャートである。 運指評価処理のフローチャートである。 ２音間コスト算出処理のフローチャートである。 運指コストテーブルの構成を説明する図である。 禁止事項検索処理のフローチャートである。 コスト補正処理のフローチャートである。 ＭＩＤＩ ＩＮ処理のフローチャートである。 再生処理のフローチャートである。 採点処理のフローチャートである。 ＭＩＤＩ ＩＮ処理のフローチャートである（変形例１）。 ＭＩＤＩ ＩＮ処理のフローチャートである（変形例２）。 ＭＩＤＩ ＩＮ処理のフローチャートである（第２の実施の形態）。 採点処理のフローチャートである（第２の実施の形態）。

符号の説明

１０ 演奏評価装置
１１ ＣＰＵ
１２ ＲＡＭ
１３ ＲＯＭ
１４ 入力部
１５ 表示部
１６、２１ ＭＩＤＩインターフェース（Ｉ／Ｆ）
１７ オーディオインターフェース（Ｉ／Ｆ）
２０ 電子楽器
２２ キーボード
３０ 音源システム

Claims (2)

1. 楽器に設けられた演奏操作子群を操作していくことで行われる楽曲の演奏を評価できる演奏評価装置において、
   前記演奏操作子群のなかで演奏の進行に応じて、操作すべき演奏操作子より指定されるピッチ、用いるべき指を表す運指情報及び該演奏操作子の操作開始及び操作終了のタイミングを含む演奏情報を順次取得する演奏情報取得手段と、
   前記演奏情報取得手段により順次連続して取得される２つの演奏情報を参照し、少なくとも各演奏情報に含まれる運指情報、2つの演奏操作子で指定されるピッチ差、演奏操作子の種類及びピッチ変化方向に基づき、当該演奏操作子を操作する際の難易度を示す難易度データを対応する各演奏情報に付与する難易度データ付与手段と、
   前記演奏操作子群のいずれかの演奏操作子への操作開始及び操作終了のタイミングを検出するための操作検出手段と、
   前記操作検出手段により操作の検出された演奏操作子と前記演奏情報取得手段にて取得された演奏情報内の操作すべき演奏操作子とが同一でかつ当該両演奏操作子の操作開始から操作終了までの期間が少なくとも一部で重なり合うか否か判別する判別手段と、
   前記判別手段により重なり合うと判別される毎に、対応する演奏情報に付与された難易度に基づいて決定される点数を累算することにより採点を行う採点手段と、
   を具備することを特徴とする演奏評価装置。
2. 楽器に設けられた演奏操作子群を操作していくことで行われる楽曲の演奏を評価できる演奏評価装置として用いられるコンピュータに、
   前記演奏操作子群のなかで演奏の進行に応じて、操作すべき演奏操作子より指定されるピッチ、用いるべき指を表す運指情報及び該演奏操作子の操作開始及び操作終了のタイミングを含む演奏情報を順次取得する演奏情報取得機能と、
   前記演奏情報取得機能により順次連続して取得される２つの演奏情報を参照し、少なくとも各演奏情報に含まれる運指情報、2つの演奏操作子で指定されるピッチ差、演奏操作子の種類及びピッチ変化方向に基づき、当該演奏操作子を操作する際の難易度を示す難易度データを対応する各演奏情報に付与する難易度データ付与機能と、
   前記演奏操作子群のいずれかの演奏操作子への操作開始及び操作終了のタイミングを検出するための操作検出機能と、
   前記操作検出機能により操作の検出された演奏操作子と前記演奏情報取得機能にて取得された演奏情報内の操作すべき演奏操作子とが同一でかつ当該両演奏操作子の操作開始から操作終了までの期間が少なくとも一部で重なり合うか否か判別する判別機能と、
   前記判別手段により重なり合うと判別される毎に、対応する演奏情報に付与された難易度に基づいて決定される点数を累算することにより採点を行う採点機能と、
   を実現させるためのプログラム。