特開 2024-178957 調判定装置、方法及びプログラム

(19)【発行国】日本国特許庁(JP)

(12)【公報種別】公開特許公報(A)

(11)【公開番号】P2024178957

(43)【公開日】2024-12-26

(54)【発明の名称】調判定装置、方法及びプログラム

(51)【国際特許分類】

   G10H 1/00 20060101AFI20241219BHJP

   G10G 3/04 20060101ALI20241219BHJP

【ＦＩ】

G10H1/00 102Z

G10G3/04

【審査請求】未請求

【請求項の数】9

【出願形態】ＯＬ

(21)【出願番号】P 2023097373

(22)【出願日】2023-06-14

(71)【出願人】

【識別番号】000001443

【氏名又は名称】カシオ計算機株式会社

(74)【代理人】

【識別番号】110004185

【氏名又は名称】インフォート弁理士法人

(74)【代理人】

【識別番号】100121083

【弁理士】

【氏名又は名称】青木 宏義

(74)【代理人】

【識別番号】100138391

【弁理士】

【氏名又は名称】天田 昌行

(74)【代理人】

【識別番号】100074099

【弁理士】

【氏名又は名称】大菅 義之

(74)【代理人】

【識別番号】100182936

【弁理士】

【氏名又は名称】矢野 直樹

(72)【発明者】

【氏名】奥田 広子

(72)【発明者】

【氏名】広浜 雅行

【テーマコード（参考）】

5D182

5D478

【Ｆターム（参考）】

5D182AD01

5D182AD10

5D478EA03

5D478EA05

5D478EA26

(57)【要約】

【課題】調判定装置、方法及びプログラムに関し、メロディ及びコードがリアルタイムに入力される楽音を示す入力データに対して、良好に調判定する。
【解決手段】調判定装置は、入力データに含まれるメロディに基づいて、第１の調と判定するメロディからの調判定処理と、前記入力データに含まれるコードに基づいて、第２の調と判定するコードからの調判定処理と、調関係テーブルを参照し、前記入力データに対する調判定結果として、前記第１の調と前記第２の調のいずれかを出力する調判定結果出力処理と、を実行する。
【選択図】図６

【特許請求の範囲】

【請求項1】

入力データに含まれるメロディに基づいて、第１の調と判定するメロディからの調判定処理と、
前記入力データに含まれるコードに基づいて、第２の調と判定するコードからの調判定処理と、
調関係テーブルを参照し、前記入力データに対する調判定結果として、前記第１の調と前記第２の調のいずれかを出力する調判定結果出力処理と、
を実行する調判定装置。

【請求項2】

前記調関係テーブルは、前記第１の調と前記第２の調が、一致する関係、近親調の関係、又は遠隔調の関係のいずれの関係であるかが規定されている、
請求項１に記載の調判定装置。

【請求項3】

前記調関係テーブルを参照し、前記第１の調と前記第２の調が、近親調の関係にある場合には、前記調判定結果出力処理は、前記第１の調を出力し、
前記調関係テーブルを参照し、前記第１の調と前記第２の調が、遠隔調の関係にある場合には、前記調判定結果出力処理は、前記第２の調を出力する、
請求項１に記載の調判定装置。

【請求項4】

前記コードからの調判定処理の後に、拍数をカウントする拍カウント処理を実行し、
前記拍数が設定された拍数に達するまでは、前記調判定結果出力処理は、前記調関係テーブルを参照し、前記第１の調と前記第２の調のいずれかを出力し、
前記拍数が設定された拍数に達した後は、前記入力データに対する調判定結果として、前記第１の調を出力する、
請求項１乃至３のいずれかに記載の調判定装置。

【請求項5】

前記メロディからの調判定処理は、前記入力データ中のメロディ音の３音列に基づいて前記３音列が属する調を前記第１の調として判定するトリコルド判定処理、又は前記入力データ中のメロディの４音列に基づいて前記４音列が属する調を前記第１の調として判定するテトラコルド判定処理の、少なくとも何れか一方を実行する、
請求項１乃至３のいずれかに記載の調判定装置。

【請求項6】

前記メロディからの調判定処理は、刺繍音を判定対象から除外する刺繍音削除処理を実行する、請求項１乃至３のいずれかに記載の調判定装置。

【請求項7】

前記調関係テーブルは、前記入力データの曲が属する音楽ジャンルごとに複数備えられている、請求項１乃至３のいずれかに記載の調判定装置。

【請求項8】

コンピュータが、
入力データに含まれるメロディに基づいて、第１の調と判定するメロディからの調判定処理と、
前記入力データに含まれるコードに基づいて、第２の調と判定するコードからの調判定処理と、
調関係テーブルを参照し、前記入力データに対する調判定結果として、前記第１の調と前記第２の調のいずれかを出力する調判定結果出力処理と、
を実行する調判定方法。

【請求項9】

コンピュータに、
入力データに含まれるメロディに基づいて、第１の調と判定するメロディからの調判定処理と、
前記入力データに含まれるコードに基づいて、第２の調と判定するコードからの調判定処理と、
調関係テーブルを参照し、前記入力データに対する調判定結果として、前記第１の調と前記第２の調のいずれかを出力する調判定結果出力処理と、
を実行させるプログラム。

【発明の詳細な説明】

【技術分野】

【0001】

本発明は、調判定装置、方法及びプログラムに関する。

【背景技術】

【0002】

従来、演奏者が例えば電子ピアノで演奏する曲に合わせてコンピュータグラフィックスを表示して、曲に合った視覚的効果を演出する製品が開発されている（例えば特許文献１）。このような製品においては、演奏される曲からリアルタイムでその曲の調を決定する技術が必要とされる。

【0003】

従来技術では、リアルタイムで演奏される演奏音が和音を構成するか否かの判定結果に基づいて、コードからの調判定又はメロディからの調判定のどちらか一方のみによる判定処理が実行されている。

【先行技術文献】

【特許文献】

【0004】

【特許文献1】特開２０２０－１４４３４６号公報

【発明の概要】

【発明が解決しようとする課題】

【0005】

しかしながら、上記従来技術では、演奏される曲によっては、コードは単純だがメロディが転調しているケースがあるが、コードからの調判定だけだとそのようなコード進行を拾うことができない。すなわち、コードからの調判定又はメロディからの調判定の一方のみに適した曲以外の曲の場合には、どちらか一方のみによる調判定ではなかなかうまくいかないという課題があった。

【課題を解決するための手段】

【0006】

態様の一例の調判定装置は、入力データに含まれるメロディに基づいて、第１の調と判定するメロディからの調判定処理と、前記入力データに含まれるコードに基づいて、第２の調と判定するコードからの調判定処理と、調関係テーブルを参照し、前記入力データに対する調判定結果として、前記第１の調と前記第２の調のいずれかを出力する調判定結果出力処理と、を実行する。

【発明の効果】

【0007】

本発明によれば、良好に調判定することが可能となる。

【図面の簡単な説明】

【0008】

【図1】調判定装置の実施形態が搭載される電子鍵盤楽器の外観図である。

【図2】調判定装置の実施形態が搭載される電子鍵盤楽器のシステムハードウェアの構成例を示すブロック図である。

【図3】電子鍵盤楽器の全体処理の例を示すメインフローチャートである。

【図4】（ａ）は調関係テーブル、（ｂ）はメジャーキースケールにおけるキー毎のテトラコルドのキースケールノート構成を示すキー毎テトラコルド構成音テーブルの例を示す図である。

【図5】（ａ）はメジャーキースケールにおけるキー毎のトリコルドのキースケールノート構成を示すキー毎トリコルド構成音テーブルの例、（ｂ）はマイナーキースケールにおけるキー毎のトリコルドのキースケールノート構成を示すキー毎トリコルド構成音テーブルの例を示す図である。

【図6】調判定処理の詳細例を示すフローチャートである。

【図7】メロディからの調判定処理の詳細例を示すフローチャートである。

【図8】トリコルド判定処理及びテトラコルド判定処理の詳細例を示すフローチャートである。

【図9】刺繍音削除処理の詳細例を示すフローチャートである。

【図10】実施形態の説明図である。

【発明を実施するための形態】

【0009】

以下、本発明を実施するための形態（以下「本実施形態」）について図面を参照しながら詳細に説明する。

【0010】

本実施形態は、メロディからの調判定処理とコードからの調判定処理を、択一的に実行するのではなく、両方とも並列に実行して夫々第１の調及び第２の調を出力し、図４（ａ）を用いて後述する調関係テーブルを参照することにより第１の調と第２の調の間の調関係を決定し、その決定した調関係に応じて第１の調又は第２の調のいずれかを優先して現在の調判定結果を出力するようにしたものである。このようにメロディからの調判定処理結果である第１の調とコードからの調判定処理結果である第２の調の両方を並列に考慮することにより、演奏形態や演奏の難易度、音楽ジャンルなどを問わず、より精度の高い調判定結果を得ることが可能となる。

【0011】

また、本実施形態では、メロディからの調判定処理において、楽音データ中のメロディ音の３音列に基づいてその３音列が属する調を第１の調として判定するトリコルド判定処理と、楽音データ中のメロディの４音列に基づいてその４音列が属する調を第１の調として判定するテトラコルド判定処理とが実施される。この処理により、楽音データ中のメロディに基づいてより的確な調判定を行うことが可能となる。

【0012】

図１は、調判定装置の実施形態が搭載される電子鍵盤楽器１００の外観図である。電子鍵盤楽器１００は、例えば電子ピアノであり、鍵盤１０１と液晶ディスプレイ１０２とスイッチ１０３のグループを少なくとも備える。また、筐体の裏面部、側面部、又は背面部等にスピーカを備える。この電子鍵盤楽器１００においては、演奏者が鍵盤１０１を使って演奏する曲に合わせて液晶ディスプレイ１０２にコンピュータグラフィックスを表示して、曲に合った視覚的効果を演出することができる。スイッチ１０３のグループは、電子鍵盤楽器１００の電源オン／オフや、音量調整、楽音出力の音色の指定を指示したりする各種スイッチからなる。また、特には図示しないが、演奏効果を付加するスイッチやベンドホイールやペダル等のスイッチが具備されてもよい。

【0013】

図２は、調判定装置の実施形態が搭載される図１の電子鍵盤楽器１００の制御システム２００のハードウェアの構成例を示すブロック図である。制御システム２００において、ＣＰＵ（プロセッサ）２０１、ＲＯＭ（リードオンリーメモリ）２０２、ＲＡＭ（ランダムアクセスメモリ）２０３、音源ＬＳＩ（大規模集積回路）２０４、鍵盤１０１が接続されるキースキャナ２０５、液晶ディスプレイ１０２が接続されるディスプレイコントローラ２０６、スイッチ１０３のグループが接続されるＩ／Ｏ（入出力）コントローラ２０７、及びＭＩＤＩ（Ｍｕｓｉｃａｌ Ｉｎｓｔｒｕｍｅｎｔ Ｄｉｇｉｔａｌ Ｉｎｔｅｒｆａｃｅ）等の楽音フォーマットを有する楽音データや音楽（オーディオ）データを外部機器から例えばＢｌｕｅｔｏｏｔｈ（登録商標）無線通信により取り込むＢｌｕｅｔｏｏｔｈ ＭＩＤＩ＆ＡＵＤＩＯインタフェース２０８が、夫々システムバス２１２に接続されている。更に、音源ＬＳＩ２０４の出力側には、Ｄ／Ａコンバータ２０９、アンプ２１０、及びスピーカ２１１が順次接続される。その他、特には図示しないが、制御システム２００において生成された画像データを外部のテレビモニター等に映し出すための映像インタフェースが具備されてもよい。

【0014】

ＣＰＵ２０１は、ＲＡＭ２０３をワークメモリとして使用しながらＲＯＭ２０２に記憶された制御プログラムを実行することにより、図１の電子鍵盤楽器１００の制御動作を実行する。特に、ＣＰＵ２０１は、図３のフローチャートで示されるメイン処理、及び図６から図９のフローチャートを用いて後述する調判定処理を実行する調判定装置として動作する。また、ＲＯＭ２０２は、上記制御プログラム及び各種固定データのほか、図３、図４、及び図５を用いて後述する各種テーブルデータを記憶する。

【0015】

図３は、電子鍵盤楽器のメイン処理の例を示すメインフローチャートである。この処理は、図２のＣＰＵ２０１がＲＯＭ２０２に記憶されている制御プログラムをＲＡＭ２０３にロードして実行する処理である。なお、特には図示しないが、メイン処理の実行中に、所定の時間間隔で、割込カウンタのカウンタ値をインクリメントするタイマインクリメント処理も実行される。

【0016】

図３に示すように、ＣＰＵ２０１は、電子鍵盤楽器１００の電源が投入されると、ＲＡＭ２０３中のデータや液晶ディスプレイ１０２の画像のクリアを含むイニシャル処理（初期化処理）を実行する（ステップＳ３０１）。

【0017】

その後、ＣＰＵ２０１は、電子鍵盤楽器１００の電源がオフされるまで、ステップＳ３０２からＳ３０７までの一連の処理を、繰り返し実行する。

【0018】

上記一連の処理において、ＣＰＵ２０１はまず、スイッチ１０３のグループの夫々のスイッチの操作をＩ／Ｏコントローラ２０７を介して検出し、対応する処理を実行するスイッチ処理を実行する（ステップＳ３０２）。

【0019】

次に、上記一連の処理において、ＣＰＵ２０１は、演奏者による鍵盤１０１に対する押鍵／離鍵の操作をキースキャナ２０５を介して検出する鍵盤処理を実行する（ステップＳ３０３）。ＣＰＵ２０１は、押鍵の処理において、演奏者によって押鍵された鍵盤１０１上の鍵のノートオンタイミング、ノートナンバー（音高）、及びベロシティ（押鍵の強さ）等の押鍵データを検出する。ＣＰＵ２０１は、離鍵の処理において、演奏者によって離鍵された鍵のノートオフタイミング、ノートナンバー等の離鍵データを検出する。

【0020】

次に、上記一連の処理において、ＣＰＵ２０１は、調判定処理を実行する（ステップＳ３０４）。ＣＰＵ２０１は、この調判定処理において、演奏者が鍵盤１０１で演奏したことにより入力する上記押鍵データ又は離鍵データである楽音を示す入力データに対して調判定を行うことにより、上記入力データに対する現在の調判定結果を出力する。この処理において、ＣＰＵ２０１は、調判定装置として動作する。
なお、入力データは、鍵盤１０１から入力する押鍵／離鍵データに限らず、例えば図２のＢｌｕｅｔｏｏｔｈ ＭＩＤＩ＆ＡＵＤＩＯインタフェース２０８を介して、外部の機器（パーソナルコンピュータ等）から入力する再生された楽音データであってもよい。
ステップＳ３０４の調判定処理の詳細については、図６から図９のフローチャートを用いて後述する。

【0021】

次に、上記一連の処理において、ＣＰＵ２０１は、ステップＳ３０４の調判定処理の結果出力された現在の調判定結果に基づいて、例えば演奏者によって演奏されている現在の曲の調性に良く合った画像データを生成し、図２のディスプレイコントローラ２０６を介して図１の液晶ディスプレイ１０２に表示する画像表示処理を実行する（ステップＳ３０５）。これにより、演奏者は、自分の演奏に合わせて変化する画像の表示を楽しむことができる。
なお、生成された画像は、特には図示しない映像インタフェースを介して外部のテレビモニター等に映し出されてもよい。
更には、前述したように、外部機器から例えばＢｌｕｅｔｏｏｔｈ ＭＩＤＩ＆ＡＵＤＩＯインタフェース２０８を介して入力する再生された楽音データに合わせて、その楽音データが例えば図２の音源ＬＳＩ２０４をスルーしてＤ／Ａコンバータ２０９からアンプ２１０を介してスピーカ２１１から放音されると共に、上述のようにして生成された画像データが、外部のテレビモニター等に映し出されてもよい。

【0022】

次に、上記一連の処理において、ＣＰＵ２０１は、音源発音処理を実行する（ステップＳ３０６）。この音源発音処理において、ＣＰＵ２０１は、ステップＳ３０３の鍵盤処理において生成されたノートオンイベントに基づいて、発音すべき楽音の音色、音高、及びベロシティを示すデータを音源ＬＳＩ２０４に与え、或いは、消音すべき楽音の音高を示す発音制御データを音源ＬＳＩ２０４に与える。音源ＬＳＩ２０４は、音色、音高、ベロシティ、音長等を示す発音制御データに従って、ＲＯＭ２０２又は音源ＬＳＩ２０４が内蔵する特には図示しない波形ＲＯＭに記憶されている波形データを読み出して、所定の楽音データを生成する。この楽音データは、Ｄ／Ａコンバータ２０９によってアナログの楽音信号に変換された後に、アンプ２１０で増幅され、スピーカ２１１から放音される。また、ＣＰＵ２０１は、ノートオフイベントに基づいて、音源ＬＳＩ２０４にノートオフイベントが示す音高（ノートナンバー）の消音を指示する。これにより、音源ＬＳＩ２０４は、該当する発音中だった楽音データを消音させる。

【0023】

上記一連の処理において、ＣＰＵ２０１は最後に、その他処理（例えば、音源ＬＳＩ２０４で発音中の楽音データのエンベロープ制御等）を実行し、ステップＳ３０２の処理に戻る。

【0024】

次に、図３のステップＳ３０４の調判定処理の詳細について、以下に説明する。
前述したように、本実施形態は、メロディからの調判定処理とコードからの調判定処理を、択一的に実行するのではなく、両方とも並列に実行して夫々第１の調及び第２の調を出力し、調関係テーブルを参照することにより第１の調と第２の調の間の調関係を決定し、その決定した調関係に応じて第１の調又は第２の調のいずれかを優先して現在の調判定結果を出力するようにしたものである。

【0025】

図４（ａ）は、調関係テーブルの例を示す図である。この調関係テーブルは、複数の調の各主音間の関係である調関係を示している。図４（ａ）において、縦軸は後述するメロディからの調判定結果を示すキー（Ｋｅｙ）Ｍを示しており、アルファベットの大文字で表記されている左端列４２０は調判定結果としてのメジャーキーを示しており、アルファベットの小文字で表記されている上記左端列４２０の右隣り列４２１は調判定結果としてのマイナーキーを示している。例えば図４（ａ）の横方向のグレー色の行４０１は、メロディからの調判定結果を示すキーＭが、Ｃメジャー（表記：Ｃ）又はＡｍ（Ａマイナー、表記：ａ）であった場合に参照されるべき行である。

【0026】

図４（ａ）において、横軸は後述するコードからの調判定結果を示すキー（Ｋｅｙ）Ｃを示しており、アルファベットの小文字で表記されている上端行４２２は調判定結果としてのマイナーキーを、アルファベットの大文字で表記されている上記上端行４２２の下隣り行４２３は調判定結果としてのメジャーキーを示している。例えば図４（ａ）の縦方向のグレー色の列４０２は、コードからの調判定結果を示すキーＣが、Ｃメジャー（表記：Ｃ）又はＡｍ（Ａマイナー、表記：ａ）であった場合に参照されるべき列である。

【0027】

図４（ａ）において、縦軸の任意のキーの位置の横方向の行と、横軸の任意のキーの位置の縦方向の列とが交差するマスには、記号「○」、「Ｍ」、又は「ｃ」に対応するデータが設定されている。

【0028】

例えば、メロディからの調判定結果がキーＣ又はＡｍである行４０１と、コードからの調判定結果もキーＣ又はＡｍである列４０２とが交差するマスに対応する記憶位置には、記号「○」に対応するデータが設定されている。この記号「○」に対応するデータは、メロディからの調判定結果のキーとコードからの調判定結果のキーとが一致している場合に設定される。

【0029】

次に例えば、メロディからの調判定結果がキーＣ又はＡｍである行４０１と、コードからの調判定結果がキーＣ又はＡｍである列４０２の左右両隣りの、キーＦメジャー（表記：Ｆ）若しくはＤｍ（Ｄマイナー、表記：ｄ）の列４０３、又はキーＧメジャー（表記：Ｇ）若しくはＥｍ（Ｅマイナー、表記：ｅ）の列４０４とが交差するマスに対応する記憶位置には、記号「Ｍ」に対応するデータが設定される。この記号「Ｍ」に対応するデータは、メロディからの調判定結果のキーとコードからの調判定結果のキーとが音楽理論の五度圏でいうところの近親調（属調）になっている場合に設定される。近親調とは、ある調（主調）に対して関係の深い調である。記号「Ｍ」に対応するデータは、メロディからの調判定結果を採用することを示す。なお、後述する記号「ｃ」に対応するデータは、コードからの調判定結果を採用することを示す。

【0030】

また例えば、メロディからの調判定結果がキーＣ又はＡｍである行４０１と、コードからの調判定結果がキーＣ又はＡｍである列４０２の各左右２つ隣りの、キーＢ♭メジャー（表記：Ｂ♭）若しくはＧｍ（Ｇマイナー、表記：ｇ）の列４０５、又はキーＤメジャー（表記：Ｄ）若しくはＢｍ（Ｂマイナー、表記：ｂ）の列４０６とが交差するマスに対応する記憶位置にも、記号「Ｍ」に対応するデータが設定されている。Ｂ♭メジャー若しくはＧｍはＣメジャー若しくはＡｍからみると下属調の下属調、Ｄメジャー若しくはＢｍはＣメジャー若しくはＡｍからみると属調の属調となる。本実施形態では、これらの下属調の下属調又は属調の属調の各データも、メロディからの調判定結果のキーとコードからの調判定結果のキーとが音楽理論の五度圏でいうところの近親調であると捉える。

【0031】

このように、図４（ａ）の調関係テーブルにおいて、五度圏において、五度ずつ移動する属調又は属調の属調という関係で近親調が示されている。

【0032】

縦軸と横軸の関係が逆になっても同様である。例えば、コードからの調判定結果がキーＣ又はＡｍである列４０２と、メロディからの調判定結果がキーＣ又はＡｍである行４０１の上下両隣りの、キーＦメジャー（表記：Ｆ）若しくはＤｍ（Ｄマイナー、表記：ｄ）の行４０７、又はキーＧメジャー（表記：Ｇ）若しくはＥｍ（Ｅマイナー、表記：ｅ）の行４０８とが交差するマスに対応する記憶位置には、記号「Ｍ」に対応するデータが設定されており、メロディからの調判定結果のキーとコードからの調判定結果のキーとが近親調（属調または下属調）の関係になっている。

【0033】

また例えば、コードらの調判定結果がキーＣ又はＡｍである列４０２と、メロディからの調判定結果がキーＣ又はＡｍである行４０１の各上下２つ隣りの、キーＢ♭メジャー（表記：Ｂ♭）若しくはＧｍ（Ｇマイナー、表記：ｇ）の行４０９、又はキーＤメジャー（表記：Ｄ）若しくはＢｍ（Ｂマイナー、表記：ｂ）の行４１０とが交差するマスに対応する記憶位置にも、記号「Ｍ」に対応するデータが設定されており、これらのマス位置においても、メロディからの調判定結果のキーとコードからの調判定結果のキーとが近親調（下属調の下属調、属調の属調）の関係になっている。

【0034】

このように、図４（ａ）の調関係テーブルにおいて、五度圏において、五度ずつ移動する属調又は属調の属調、或いは、下属調又は下属調の下属調という関係で近親調が示されている。

【0035】

上記以外で、メロディからの調判定結果のキーとコードからの調判定結果のキーとが遠い位置関係にある各マスに対応する記憶位置には、記号「ｃ」に対応するデータが設定されている。この記号「ｃ」に対応するデータは、メロディからの調判定結果のキーとコードからの調判定結果のキーとが音楽理論の五度圏でいうところの遠隔調になっている場合に設定される。

【0036】

本実施形態においては、図４（ａ）の調関係テーブルにおいて、メロディからの調判定結果である第１の調とコードからの調判定結果である第２の調とが一致する関係にある記号「○」に対応するデータが設定された組合せとなった場合には、第１の調＝第２の調が現在の調判定結果として出力される。

【0037】

また、図４（ａ）の調関係テーブルにおいて、第１の調と第２の調とが近親調の関係にある記号「Ｍ」に対応するデータが設定された組合せとなった場合には、メロディからの調判定結果である第１の調が優先されて現在の調判定結果として出力される。

【0038】

更に、図４（ａ）の調関係テーブルにおいて、第１の調と第２の調とが遠隔調の関係にある記号「ｃ」に対応するデータが設定された組合せとなった場合には、コードからの調判定結果である第２の調が優先されて現在の調判定結果として出力される。

【0039】

本実施形態においてこのようなアルゴリズムを採用した理由は次の通りである。転調の仕方として、コードは変化しないが、メロディの演奏において、属調になったり、属調の属調になったり、下属調になったり、下属調の下属調になったりするように、近親調に変化することは、よくある。従って、この場合にはメロディからの調判定結果を優先するとよい。

【0040】

例えば、コードからの調判定結果はＣで固定されているが、メロディがＣからＢ♭に変化した場合にはメロディからの調判定結果がＣからその下属調であるＦに変化し得る。このような場合には、全体としてメロディからの調判定結果Ｆを優先するのがよい。
一方、歌謡曲ポップスなどで、例えばずっとＣ調できたが最後に半音転調して上がって盛り上げるような演奏がされる場合がよくある。この例のように、曲調がＣ調からＣ＃調になったときには、全然遠い調なのでそのような場合はコードが必ず変わっているはずなので、本実施形態ではコードからの調判定結果が優先されるとよい。

【0041】

ただ、図４（ａ）に示される例では、近親調の範囲が２つである（図４（ａ）において記号「Ｍ」に対応するデータが設定されたマス位置が２つ続いている）が、例えばジャズ系などでは、近親調の範囲をもう少し広げてもよい。すなわち、図４（ａ）に例示される調関係テーブルを入力データの曲が属する音楽ジャンルごとに切り替えることにより、様々なジャンルの曲の調判定に良好に対応することが可能である。

【0042】

このように、本実施形態では、コードからの調判定結果とメロディからの調判定結果について、図４（ａ）に例示されるような調関係テーブルを複数用意（ＲＯＭ２０２に記憶）しておくことにより、クラシック、ポップス、ジャズ等の主要な音楽ジャンルに対して調判定を行うことが可能となる。

【0043】

図４（ａ）に例示される調関係テーブルは、図２のＲＯＭ２０２に、テーブルデータとして記憶されている。そのデータ構成は、メロディからの調判定結果である第１の調によって図４（ａ）の縦軸の何れかのキーにアクセスでき、コードからの調判定結果である第２の調によって図４（ａ）の横軸の何れかのキーにアクセスでき、それらが交差するマスに対応する記憶位置から夫々に設定されている記号に対応するデータが読み出される形式であれば、どのようなデータ構成が採用されてもよい。

【0044】

このように、本実施形態において、メロディからの調判定処理結果である第１の調とコードからの調判定処理結果である第２の調の両方を並列に考慮することにより、演奏形態や演奏の難易度、音楽ジャンルなどを問わず、より精度の高い調判定結果を得ることが可能となる。

【0045】

次に、メロディからの調判定処理について説明する。メロディの音列を判定する場合に、３つの音列がきたときに、例えば日本の童謡などでは、ドレミソラの音程しかないいわゆるヨナ抜き音階の童謡が多い。
ヨナ抜き音階とは、西洋音階において、主音（ド）から四つ目のファと、七つ目のシがない音階（ドレミソラ）のことをいう。雅楽の呂旋法がこれに当たり、西洋音楽関係者が日本音階の特徴として名づけたものである。鍵盤楽器における黒鍵部分の５音にも相当する。
このようなケースにおいて、メロディとしてドレミと発音された場合に、それがハ長調なのかヘ長調なのかト長調なのかわからないが、特に童謡などのジャンルにおいては、とりあえずドレミという３音列が来たときにはハ長調の可能性が高いと判定してキー（Ｋｅｙ）を確定して判定を進めると、割と早く調を確定させることができる。

【0046】

その後にファとかシとかがでてくると、実は、ハ長調ではなくてト長調だったなどと判定される場合もあり、図３のステップＳ３０２からＳ３０７のループ処理におけるステップＳ３０４の調判定処理として示されるように、メロディからの調判定処理はリアルタイムで繰り返し実行されるので、最初はハ長調だったがやはりト長調だったという変化は簡単に修正できる。

【0047】

上述のようなメロディの３音列は、トリコルドと呼ばれる。図５（ａ）はメジャーキースケールにおけるキー毎のトリコルドのキースケールノート構成を示すキー毎トリコルド構成音テーブルの例、図５（ｂ）はマイナーキースケールにおけるキー毎のトリコルドのキースケールノート構成を示すキー毎トリコルド構成音テーブルの例を示す図である。夫々ダイアトニックスケールに対応している。図５（ａ）及び（ｂ）において、各縦軸の左端列５０１及び５０２は夫々メジャーキー（Ｋｅｙ）及びマイナーキー（Ｋｅｙ）を示している。
本実施形態におけるメロディからの調判定処理におけるトリコルド判定において、図５（ａ）のメジャースケール又は図５（ｂ）のマイナースケールの各行のグレー色の部分の行方向の３音列の何れかが検出された場合には、図５（ａ）又は（ｂ）の左端列５０１又は５０２における、その検出された３音列に対応する位置の記号で示されるメジャーキー又はマイナーキーが、その時点におけるメロディからの調判定結果としての第１の調の候補となる。

【0048】

例えば、童謡「メリーさんの羊」において、「ミレドレミミミ レレレ ミソソ ミレドレミミミ レレミレド」というメロディでは、ドレミソという音階しかないのでハ長調という判定が確定する。しかしながら、左手の伴奏がない限りは、それがト長調でもヘ長調でも良い。そのようなケースを早く見つけるために、本実施形態におけるメロディからの調判定処理においては、メロディ中のトリコルドを判定することに着目した。最初にトリコルドで早く判定をすれば、童謡「メリーさんの羊」のようなケースを救うことができる。
もちろん、これが恒久的に正しい訳ではなく、後に詳述するように本実施形態では、後で新しい判定がされれば、きちんと修正することが可能である。

【0049】

以上の本実施形態における考え方は、ヨナ抜き音階以外の例えばいわゆるニロ抜き音階などのメロディに対しても同様に適用することができる。

【0050】

以上の考え方は、メロディにおいて３音列が連続した場合であるが、４音列が連続した場合についても同様に考えることができる。メロディおける４音列はテトラコルドと呼ばれている。図４（ｂ）はダイアトニックのメジャーキースケールにおけるキー毎のテトラコルドのキースケールノート構成を示すキー毎テトラコルド構成音テーブルの例を示す図である。図４（ｂ）において、縦軸の左端列４３０はメジャーキー（Ｋｅｙ）を示している。
テトラコルドには、３全音からなる音の組合せが含まれる。１つの音階で３全音がくる組合せは決まっている。例えば、ハ長調であれば、ファソラシの４音中に３個の全音（３全音）が含まれる。従って、このような組合せが現れた場合には、ハ長調であると判定することができる。このように、テトラコルドの組合せは各調で決まっているので、図４（ｂ）に例示されるようなキー毎テトラコルド構成音テーブルを参照することにより、メロディからの調判定処理を行うことが可能である。
即ち、本実施形態におけるメロディからの調判定処理におけるテトラコルド判定において、図４（ｂ）のスケールの各行のグレー色の部分の行方向の３全音を含む４音列の何れかが検出された場合には、図４（ｂ）の左端列４３０における、その検出された４音列の行に対応する位置の記号で示される例えばメジャーキーが、その時点におけるメロディからの調判定結果としての第１の調の候補となる。

【0051】

図５（ａ）、（ｂ）に例示されるキー毎トリコルド構成音テーブル、又は図４（ｂ）に例示されるキー毎テトラコルド構成音テーブルは、図４（ａ）の調関係テーブルの場合と同様に、図２のＲＯＭ２０２に、テーブルデータとして記憶されている。そのデータ構成は、入力データである楽音データの３音列又は４音列が、テーブル上の何れかの行方向のグレー色部分の３音列又は４音列と一致するか否かを判定し、一致した行のキーを特定するデータベース機能を備える形式であれば、どのようなデータ構成が採用されてもよい。

【0052】

図４及び図５を用いて上述した調判定処理の考え方に基づく本実施形態の具体的な調判定処理について、以下に詳細に説明する。図６は、図３のステップＳ３０４で繰り返し実行される調判定処理の詳細例を示すフローチャートである。

【0053】

図６において、図２のＣＰＵ２０１はまず、メロディからの調判定処理（ステップＳ６０１）と、コードからの調判定処理（ステップＳ６０２）を並列して実行し、夫々の判定結果を例えばＲＡＭ２０３上の変数Ｍｋｅｙに第１の調として（ステップＳ６０３）、及び同じくＲＡＭ２０３上の変数Ｃｋｅｙに第２の調として（ステップＳ６０４）、格納する。

【0054】

メロディからの調判定処理については、図７から図９のフローチャートを用いて後述する。

【0055】

また、ＣＰＵ２０１は、ステップＳ６０２でコードからの調判定処理を実行した後は、入力データに対して拍カウントを開始する（ステップＳ６０５）。ＣＰＵ２０１は、拍カウントが１増える毎に、例えばＲＡＭ２０３の拍カウント変数の値を更新する。

【0056】

次に、ＣＰＵ２０１は、入力データにおいて、ＲＡＭ２０３上の拍カウント変数の値が１６拍に達していないか否かを判定する（ステップＳ６０６）。

【0057】

ステップＳ６０６の判定は、例えば、或る曲の入力データにおいて、コードからの調判定が行われないまま所定の拍数（例えば、１６拍）に達していない間は（ステップＳ６０６の判定がＹＥＳの間は）、ＣＰＵ２０１は、調関係テーブルを参照し（ステップＳ６０７）、調を確定する（ステップＳ６０９）。

【0058】

一方、コードからの調判定が行われないまま所定の拍数に達した場合は（ステップＳ６０６の判定がＮＯ）、ＣＰＵ２０１は、変数Ｍｋｅｙに格納されている第１の調を採用し（ステップＳ６０８）、調を確定する（ステップＳ６０９）。

【0059】

図７は、図６のステップＳ６０１のメロディからの調判定処理の詳細例を示すフローチャートである。
まず、ＣＰＵ２０１は、現時点においてコードからの調判定処理等によって調が確定しているか否かを判定する（ステップＳ７０１）。

【0060】

調が確定していてステップＳ７０１の判定がＹＥＳの場合には、ＣＰＵ２０１は、以下に説明するトリコルド判定処理及びテトラコルド判定処理は実行せずに、ステップＳ７０８の刺繍音削除処理に進む。

【0061】

調が確定しておらずステップＳ７０１の判定がＮＯの場合には、ＣＰＵ２０１はまず、トリコルド判定処理を実行する（ステップＳ７０２）。
図８（ａ）は、図７のステップＳ７０２のトリコルド判定処理の詳細例を示すフローチャートである。

【0062】

トリコルドというのは３音列という意味であるが、本実施形態では音程間隔が全音であるつながった３音列という意味で使用する。鍵盤１０１（図１）上の白鍵のドレミ、ファソラ、ソラシなどが条件にあてはまる。童謡などでよく使われるヨナ抜き音階のような場合ではファとシは出てこない場合が多いので、そのような曲の場合はトリコルドの条件を満たせばドレミのトリコルドである比率が高いので、白鍵のドレミが出てきた場合は第１の調ＭｋｅｙをＣメジャーとする目的で判定している。

【0063】

図８（ａ）において、ＣＰＵ２０１は、入力データとして得られている４音を音高が低い方から並びかえる（ステップＳ８０１）。
例えば、入力データにおいてソドレミが入力されたときに、ドレミソと並べておく。この場合、音域は関係なく音名だけで並び替えて音種に着目する。

【0064】

次に、ＣＰＵ２０１は、上記並びかえた後の４音の各音間の音程間隔に、全音が二つ続くものがあるか否かを判定する（ステップＳ８０２）。上述の並びの中で次の音との音程間隔に全音が続くものがある、例えばドレミソという音列ではドレミがこれにマッチする。

【0065】

ステップＳ８０２の判定がＹＥＳならば、ＣＰＵ２０１は、全音音程二つに該当する３音のうち一番下の音を主音とする長調を、第１の調Ｍｋｅｙとして出力する（ステップＳ８０３）。例えば、ドレミソという４音が入ってきた場合にはドレミがトリコルドに当たり、この場合にはドを主音とする長調となるので、ハ長調が第１の調Ｍｋｅｙということになる。
その後、ＣＰＵ２０１は、図８（ａ）で示される図７のステップＳ７０２のトリコルド判定処理を終了する。

【0066】

ステップＳ８０２の判定がＮＯならば、ＣＰＵ２０１は、音程間隔に全音と半音が続くものがあるか否かを判定する（ステップＳ８０４）。

【0067】

ステップＳ８０４の判定がＹＥＳならば、音程二つに該当する３音のうち一番下の音を主音とする短調を、第１の調Ｍｋｅｙとして出力する（ステップＳ８０５）。例えば、ドレミ♭のドを主音とするハ短調として、第１の調Ｍｋｅｙを決定する。短調のトリコルドの場合はドレミ♭なので、全音と半音の間隔の音列を探している。
その後、ＣＰＵ２０１は、図８（ａ）で示される図７のステップＳ７０２のトリコルド判定処理を終了する。

【0068】

ステップＳ８０４の判定がＮＯならば、ＣＰＵ２０１は、第１の調Ｍｋｅｙは設定せずに、図８（ａ）で示される図７のステップＳ７０２のトリコルド判定処理を終了する。

【0069】

図７の処理の説明に戻り、ＣＰＵ２０１は、ステップＳ７０２のトリコルド判定処理の後に、前述した図５（ａ）又は（ｂ）のキー毎トリコルド構成音テーブルを参照し、前述した動作により、第１の調Ｍｋｅｙが何れかのトリコルドとマッチするか否かを判定する（ステップＳ７０３）。

【0070】

ステップＳ７０３の判定がＹＥＳになれば、第１の調Ｍｋｅｙを確定させる（ステップＳ７０４）。その後、ＣＰＵ２０１は、図７のフローチャートで示される図６のステップＳ６０１のメロディからの調判定処理を終了する。

【0071】

ステップＳ７０３の判定がＮＯならば、テトラコルド判定処理を実行する（ステップＳ７０５）。
図８（ｂ）は、図７のステップＳ７０５のテトラコルド判定処理の詳細例を示すフローチャートである。

【0072】

図８（ｂ）において、ＣＰＵ２０１は、入力データとして得られている１６音を音程が低い方から並びかえる（ステップＳ８１０）。テトラコルドは４音列という意味であるが、本実施形態では、図４（ｂ）にある、調固有の４音列のことを意味している。
例えばハ長調ではファソラシ、音程間隔で言うと全音－全音－全音となっており、この３全音が続くのはハ長調だけである。同様にドレミファ＃の３全音をもつのはト長調、シ♭ドレミの３全音のテトラコルドを持つのはヘ長調だけである。このように、３全音のテトラコルドを最初の４音で見つけたら調が決定されるので、これを４音から１６音の間で探す。

【0073】

次に、ＣＰＵ２０１は、上記並びかえた後の１６音の各音間の音程間隔が、全音－全音－全音の４音があるか否かを判定する（ステップＳ８１１）。

【0074】

ステップＳ８１１の判定がＹＥＳならば、ＣＰＵ２０１は、上位４音の一番上の音の半音上の音を主音とする長調を、第１の調Ｍｋｅｙとして出力する（ステップＳ８１２）。その後、ＣＰＵ２０１は、図８（ｂ）で示される図７のステップＳ７０５のテトラコルド判定処理を終了する。

【0075】

ステップＳ８１１の判定がＮＯならば、ＣＰＵ２０１は、第１の調Ｍｋｅｙは設定せずに、図８（ｂ）で示される図７のステップＳ７０５のテトラコルド判定処理を終了する。

【0076】

図７の処理の説明に戻り、ＣＰＵ２０１は、ステップＳ７０５のテトラコルド判定処理の後に、前述した図４（ｂ）のキー毎テトラコルド構成音テーブルを参照し、前述した動作により、第１の調Ｍｋｅｙが何れかのテトラコルドとマッチするか否かを判定する（ステップＳ７０６）。

【0077】

ステップＳ７０６の判定がＹＥＳになれば、第１の調Ｍｋｅｙを確定させる（ステップＳ７０７）。その後、ＣＰＵ２０１は、図７のフローチャートで示される図６のステップＳ６０１のメロディからの調判定処理を終了する。

【0078】

前述したステップＳ７０１の判定がＹＥＳの場合又はステップＳ７０６の判定がＮＯの場合には、ＣＰＵ２０１は、刺繍音削除処理を実行する（ステップＳ７０８）。

【0079】

図９は、図７のステップＳ７０８の刺繍音削除処理の詳細例を示すフローチャートである。刺繍音というのは装飾音の中でもとりわけメロディを修飾するものであり、頻繁にでてくるもので、メロディの半音若しくは全音下、又は上に行ってまた戻ってくるものである。
図１０（ａ）に、楽曲「エリーゼのために」の冒頭の楽譜を示す。最初の右手のメロディ、ミレ＃ミレ＃ミのレ＃が刺繍音にあたる。ミからレ＃に行ってまたミに戻ってくるので、さながら刺繍しているような印象のため刺繍音と呼ばれている。全音の場合はスケールノートに当たる場合が多いが、半音の場合はスケールノートではない音（非和声音）が使われるので、このような刺繍音を調判定に使うと、正確な調判定とならない。例えば、本当はＡｍの調であるがＥｍと判定されてしまうようなことが起こる。このため、刺繍音の条件に合う場合は調判定音として使用しないようにすることが望ましい。

【0080】

図９において、ＣＰＵ２０１は予め、夫々ＲＡＭ２０３上の変数ＣＴに現在の音、変数ＰＴに一つ前の音、変数ＰＰＴに更にもう一つ前の音を格納する。
その上で、ＣＰＵ２０１はまず、一つ前の音ＰＴと現在の音ＣＴが半音音程であるか否かを判定する（ステップＳ９０１）。
例えば、ミレ＃ミと演奏されたときに、ＣＴにミ、ＰＴにレ＃、ＰＰＴにミが入っている。ＣＴとＰＰＴは、音名が同じというだけではなく、音高も同じである必要がある。

【0081】

ステップＳ９０１の判定がＮＯならば、刺繍音の条件は満たさないので、ＣＰＵ２０１は、刺繍音削除は実行せずに、図９のフローチャートで示される図７のステップＳ７０８の刺繍音削除処理を終了する。

【0082】

ステップＳ９０１の判定がＹＥＳならば、現時点で調が確定しているか否かを判定する（ステップＳ９０２）。

【0083】

ステップＳ９０２の判定がＹＥＳならば、ＣＰＵ２０１は、ＰＴがスケールノートであるか否かを判定する（ステップＳ９０３）。

【0084】

ステップＳ９０３の判定がＹＥＳの場合は、刺繍音ではないので、ＣＰＵ２０１は、刺繍音削除は実行せずに、図９のフローチャートで示される図７のステップＳ７０８の刺繍音削除処理を終了する。

【0085】

ステップＳ９０２又はＳ９０３の判定がＮＯの場合には、ＣＰＵ２０１は、ＰＰＴより１オクターブ下の音は刺繍音判定に入れないで無視する（ステップＳ９０４）。これは演奏者が鍵盤１０１（図１）を両手で演奏している場合に、どれが刺繍音かわからないので、半音が判定された部分から１オクターブ下以降の音（伴奏音）は無視する必要があるからである。図１０（ａ）の楽譜の例でいうと、最初のミの音から１オクターブ下以下の音は刺繍音判定が実行されない。

【0086】

ステップＳ９０４の処理の後、ＣＰＵ２０１は、ＣＴとＰＰＴが同一音高であるか否かを判定する（ステップＳ９０５）。

【0087】

ステップＳ９０５の判定がＮＯならば、刺繍音ではないので、ＣＰＵ２０１は、刺繍音削除は実行せずに、図９のフローチャートで示される図７のステップＳ７０８の刺繍音削除処理を終了する。

【0088】

ステップＳ９０５の判定がＹＥＳならば、ＣＰＵ２０１は、ＣＴとＰＰＴは２拍以内か否かを判定する（ステップＳ９０６）。刺繍音は装飾音のため、あまりに長いものは該当しないからである。

【0089】

ステップＳ９０６の判定がＮＯの場合は、刺繍音ではないとみなし、ＣＰＵ２０１は、刺繍音削除は実行せずに、図９のフローチャートで示される図７のステップＳ７０８の刺繍音削除処理を終了する。

【0090】

ステップＳ９０６の判定がＹＥＳの場合は、ＣＰＵ２０１は、刺繍音であるとみなして、ＰＴを刺繍音を示すＲＡＭ２０３上の変数ＰＴＳに格納する（ステップＳ９０７）。

【0091】

最後に、変数ＰＴＳの音を調判定に使用する音から外す処理を行う（ステップＳ９０８）。その後、ＣＰＵ２０１は、図９のフローチャートで示される図７のステップＳ７０８の刺繍音削除処理を終了する。

【0092】

図７の説明に戻り、ＣＰＵ２０１は、ステップＳ７０８の刺繍音削除処理の後、メロディシーケンスによる調判定を実行し（ステップＳ７０９）、メロディからの調判定結果である第１の調Ｍｋｅｙを確定する（ステップＳ７１０）。その後、ＣＰＵ２０１は、図７のフローチャートで示される図６のステップＳ６０１のメロディからの調判定処理を終了する。
メロディシーケンスによる調判定処理は、従来から色々な方法があるが、入力データの音を一定間隔でどの調のスケールに一番近いかを見ていく方法が、今回のトリコルドやテトラコルド判定、刺繍音判定になじみが良いと思われる。

【0093】

図１０（ｂ）は、コードのみからでは調を適切に判断できない楽譜の例である。コードからの調判定Ｃｋｅｙは、１小節目から３小節目まで、全てＣメジャー（ＣＭ）と判定される。一方、メロディからの調判定Ｍｋｅｙは、１小節目から２小節の１拍目まではＣＭと判定され、２小節の２拍目からはＣＭには含まれないＢ♭の音高が指定されているので、３小節目までにはＦメジャー（ＦＭ）に転調していると判定される。図１０（ｂ）の３小節目において、ＣＰＵ２０１は、図４（ａ）の表を参照することにより、行４０７（Ｍｋｅｙ＝ＦＭ）と列４０２（Ｃｋｅｙ＝ＣＭ）との交点のマスに対応する記憶位置から記号「Ｍ」に対応するデータを取得し、その結果データ「Ｍ」に対応する第１の調Ｍｋｅｙを採用し、調をＦＭと決定する。本願発明を適用すれば、メロディから判定された調（Ｍｋｅｙ）及びコードから判定された調（Ｃｋｅｙ）を用いて、図１０（ｂ）の楽譜の場合の３小節目において、Ｍｋｅｙに基づいて調を決定するので、良好に調を決定できる。
図１０（ｃ）はポップスでよくある、最後に盛り上げるために半音上に転調するような場合の楽譜の例である。調性は基本的には調合が増えていくように、例えば＃が増えていく方向だとＣＭ→ＧＭ→ＤＭ→ＡＭというように、五度圏で広がってゆくものである。そのため、五度上の属調、そのまた五度上の属調の属調を、近親調と捉えている。逆に、五度下の下属調、そのまた五度下の下属調の下属調も、近親調と捉えている。更に、半音違う場合は、元の調と共通する音がほとんどなく、この場合は調性的には遠隔調という扱いになる。図１０（ｃ）の楽譜例において、１小節目から２小節目までＣＭとなり、３小節目で遠隔調であるＤ♭Ｍに転調している。実際のところ、メロディから判定される調と、コードから判定される調と、が遠隔調の関係になっている場合はほとんど無いと思われるが、そのような場合があった場合でも、本願発明を適用すれば、図４（ａ）の表を参照することにより、メロディから判定された調（Ｍｋｅｙ）及びコードから判定された調（Ｃｋｅｙ）を用いて、図１０（ｃ）の楽譜の場合は、Ｃｋｅｙに基づいて調を決定するので、良好に調を決定できる。

【0094】

以上説明したようにして、リアルタイムに何か弾かれたときに、メロディだけの入力であっても、コードだけの入力であっても、両手で弾くものであっても、また童謡などのメロディであっても、ジャズのような複雑な曲であっても、コードからとメロディからのバランス良い調判定が可能となる。
また、トリコルド判定やテトラコルド判定を設けたので、ヨナ抜き音階の曲でも、早く判定できるようになる。
更に、刺繍音判定を入れたので、装飾しているだけでスケールノートにない音を調判定から除くことができるようになったので、より正確な判定結果を得られるようになる。
本実施形態では、メロディからの調判定アルゴリズムとコードからの調判定アルゴリズムを備え、それぞれの判定結果の優先表を設けることにより、両方の判定結果を出したうえで、どちらを優先するかを決定できることを特徴としているので、以下のような効果がある。
（１）コードを押さえられずメロディしか弾けない初心者でも、メロディから判定される調を用いて、早期に正しい調判定結果が得られる。
（２）メロディからとコードからの調判定を同時に行う仕組みなので、曲のジャンルにとらわれず、どのような曲に対しても正解に近い調判定が可能である。
（３）初心者から上級者まで演奏形態を問わず、最適な調判定結果が得られる。
（４）メロディからの調判定結果とコードからの調判定結果のどちらを採用したかがわかるので、これらを画像生成処理などの映像表現パラメータとして連動させて、新しい映像表現を追加することが可能となる。
更に、本実施形態は、以下のような特徴を備える。
（１）メロディからの調判定に対してはトリコルド判定、テトラコルド判定を設けたので、童謡などヨナ抜き音階の曲であっても、早期に調判定できるようになった。
（２）トリコルド判定とテトラコルド判定は調が不確定な場合のみ動作するので、たとえ間違っていたとしても、その後の入力音により正しい調に戻るような仕組みになっている。
（３）メロディからの調判定に対しては、スケールノート以外の音を含む刺繍音を判定し、調判定時には排除して判定するようにしたので、更に精度の高い判定が可能となった。

【0095】

その他、本発明は上述した実施形態に限定されるものではなく、実施段階ではその要旨を逸脱しない範囲で種々に変形することが可能である。また、上述した実施形態で実行される機能は可能な限り適宜組み合わせて実施しても良い。上述した実施形態には種々の段階が含まれており、開示される複数の構成要件による適宜の組み合せにより種々の発明が抽出され得る。例えば、実施形態に示される全構成要件からいくつかの構成要件が削除されても、効果が得られるのであれば、この構成要件が削除された構成が発明として抽出され得る。

【符号の説明】

【0096】

１００ 電子鍵盤楽器
１０１ 鍵盤
１０２ 液晶ディスプレイ
１０３ スイッチ
２０１ ＣＰＵ
２０２ ＲＯＭ
２０３ ＲＡＭ
２０４ 音源ＬＳＩ
２０５ キースキャナ
２０６ ディスプレイコントローラ
２０７ Ｉ／Ｏコントローラ
２０８ Ｂｌｕｅｔｏｏｔｈ ＭＩＤＩ＆ＡＵＤＩＯインタフェース
２０９ Ｄ／Ａコンバータ
２１０ アンプ
２１１ スピーカ

【図1】

【図2】

【図3】

【図4】

【図5】

【図6】

【図7】

【図8】

【図9】

【図10】