(57)【特許請求の範囲】
【請求項１】
異なる楽音の音高が各々割り当てられた鍵を有する鍵盤と、
この鍵盤を所定周期でスキャンすることにより、鍵盤の押鍵状態を検出する押鍵状態検出手段と、
前記押鍵情報検出手段によるスキャン結果から新たな押鍵の有無を検出する押鍵検出手段と、
ダンパペダルと、
前記ダンパペダルが操作されているか否かを判定する判定手段と、
前記押鍵検出手段により新たな押鍵が検出され、かつ前記判定手段により前記ダンパペダルが操作されていないことを検出している場合に、前記押鍵状態検出手段により押鍵状態にあると検出された鍵に対応する音高に基づいてコードを判別するコード判別手段と、
を具備したことを特徴とするコード判別装置。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、演奏操作子群の複数の異なる演奏操作子に対する操作によって指定されるコードを判別するための技術に関する。
【背景技術】
【０００２】
近年、電子楽器においては、自動伴奏機能が標準的に搭載されている。この自動伴奏機能によってユーザは、伴奏音に合わせてメロディを弾くことで、一人でもアンサンブル演奏のような楽しさを味わうことができる。
【０００３】
通常、伴奏音は、ベース（リズム）パートとコード伴奏パートとからなり、コードは、例えば鍵盤（演奏操作子群）上の複数の鍵を、所望するコードの構成音に対応させて押鍵することで任意に指定することができるようになっている。普通、伴奏音は、スタートボタン等の操作によりリズムパートが先ずスタートし、その後、コードが指定されてからコード伴奏パートがスタートする。一旦自動伴奏をスタートさせると、コードは途中で変更することも可能となっている。
【０００４】
上記のような電子楽器に搭載されているコード判別装置は、鍵盤上の押鍵された鍵からコードを判別する。従って、自動伴奏では、コード判別装置が判別したコードで伴奏音が発音される。
【０００５】
自動伴奏機能では、これまでは鍵盤を伴奏鍵域、メロディ鍵域に分け、それぞれの鍵域毎に異なる機能を割り当てるスプリット仕様が多く採用されていた。伴奏鍵域は伴奏音のコード指定用であり、メロディ鍵域はメロディとして発音させる楽音の指定用である。このスプリット仕様では、一般的に、伴奏鍵域内の現在押鍵されている鍵の組み合わせからコードが判別される。
【０００６】
最近では、鍵盤の全てが伴奏音の指定鍵として割り当てるとともに、押鍵された鍵の音もそれに設定されている音高で発音される全鍵伴奏域仕様という自動伴奏仕様の電子楽器が製品化されている。このような仕様では、鍵盤の全ての押鍵から指定されたコードを判別しなければならない。このため、音高の低いほうから押鍵されている所定の複数の鍵がコード指定のための押鍵と判断し、これらの鍵の組み合わせからコードを判別していた。例えば、異なる３鍵で指定されるコードであれば音高の低いほうから押鍵されている３鍵であり、異なる４鍵で指定されるコードであれば音高の低いほうから押鍵されている４鍵である。
【０００７】
全鍵伴奏域仕様では、このように鍵盤全てがコード指定に使用できることから、たとえメロディとして演奏したつもりであっても、コードを指定する複数の鍵を同時に押鍵した状態となり、ユーザの意図しないコードが設定されてしまうという問題点が発生していた。この問題点により、音高、音長、強弱等を生かしたメロディの演奏が制限されていた。当然のことではあるが、上記の問題点は、伴奏鍵域の押鍵によりコードの指定とともに楽音を発音させるスプリット仕様においても同様に発生する。
【発明の開示】
【発明が解決しようとする課題】
【０００８】
本発明の課題は、ユーザが意識して指定したコードだけを判別し、ユーザの意図に沿ったコード進行が得られるようにすることにある。
【課題を解決するための手段】
【０００９】
本発明のコード判別装置は、異なる楽音の音高が各々割り当てられた鍵を有する鍵盤と、この鍵盤を所定周期でスキャンすることにより、鍵盤の押鍵状態を検出する押鍵状態検出手段と、前記押鍵情報検出手段によるスキャン結果から新たな押鍵の有無を検出する押鍵検出手段と、ダンパペダルと、前記ダンパペダルが操作されているか否かを判定する判定手段と、前記押鍵検出手段により新たな押鍵が検出され、かつ前記判定手段により前記ダンパペダルが操作されていないことを検出している場合に、前記押鍵状態検出手段により押鍵状態にあると検出された鍵に対応する音高に基づいてコードを判別するコード判別手段と、を具備することを特徴とする。
【発明の効果】
【００１８】
以上、説明したように本発明は、ダンパーといった楽音の発音期間を制御する入力手段が操作されている状態のときにはコードの判別を中止するため、コード指定を意識していない期間のコード判別が回避され、ユーザは意図に沿ったコード進行を得ることができる。
【００２１】
上記したこれらの発明は各々異なる点に着目したものであることから、これらを組み合わせることで、より大きな効果を得ることができる。
【発明を実施するための最良の形態】
【００２２】
本発明のコード判別装置は、ダンパーといった楽音の発音期間を制御する入力手段の操作状態に応じて、操作されている演奏操作子からコードの判別を行う。
【００２５】
コードは、高さが異なる２つ以上の音が同時に響く場合に合成される音であり、音程差が３度の３つの音を積み重ねてなるトライアド（三和音）が基礎的・典型的である。また、上記したように、常識的にユーザは、コードの構成音に対応する複数の演奏操作子を同時に操作することで（少なくとも操作するつもりで）コードを指定する。これらのことから、上記のように操作されている演奏操作子間の音高差を調べ、その結果に応じてコードの判別を行うことで、たとえコード指定に該当する演奏操作子が意識せずに操作されている状態となってもコードの判別が行われず、所望しないコード進行が回避される。
【００２７】
ダンパーが操作されていた場合、発音中の楽音は演奏操作子への操作が終了すると直ちに消音されることから、ダンパーの操作とともにコードを指定することは普通では考えられない。このことから明らかなように、ユーザが意図しないコードを判別することが回避される。
【００２９】
以下、本発明の実施例について、図面を参照しながら詳細に説明する。図１は、第１の実施例によるコード判別装置を搭載した電子楽器１００の構成を示すブロック図である。
【００３０】
図１において、演奏情報入力装置１０１はユーザが所望の楽音を発音させるために操作されるものであり、タッチレスポンス機能を備えた鍵盤１０１ａと、右（ダンパー）ペダル、及び左（弱音）ペダルの各種ペダル１０１ｂとからなる。タッチレスポンス機能には、大別して、鍵を弾いた強さを検出するイニシャルタッチレスポンスと、押鍵後の鍵を押す強さを検出するアフタタッチレスポンスとがある。第１の実施例では、タッチレスポンス機能としてイニシャルタッチレスポンス機能を備えている。鍵を弾いた強さは、例えば鍵の押鍵を開始してから押鍵が完了するまでの時間を計測し、その計測した時間から求めた速度により判断する。以降、押鍵時の強さを押鍵速度と記載する。
【００３１】
制御部１０２は、上記演奏情報入力装置１０１のスキャンを行うとともに、特には図示しないコンソール上の各種スイッチ等の操作状態をスキャンにより検出し、スイッチの操作状態に応じた楽器１００全体の制御を実行する。楽音発生部１０３は、制御部１０２が演奏情報入力装置１０１をスキャンした後の信号を演奏情報として入力し、該演奏情報に応じて楽音を発生する。従って、この楽音発生部１０３は、ユーザが演奏情報入力装置１０１に対して何らかの操作を行った場合、その操作内容、及び押鍵タイミングに応じた楽音をメロディとして発音する。
【００３２】
演奏情報入力装置１０１から出力された現在の操作状態を表す演奏情報は、演奏情報記憶部１０４に入力される。この演奏情報記憶部１０４は、制御部１０２からの制御信号に従い、演奏情報入力装置１０１から出力された演奏情報を記憶する。
【００３３】
押鍵タイミング判別部１０５は、演奏情報記憶部１０４に記憶されている演奏情報を読み出して操作された鍵の押鍵速度（押鍵されたときの強さ）を求め、これら求めた各鍵毎の押鍵速度を予め定めた速度（設定速度）と比較することにより、各鍵に対する操作が強拍、弱拍の何方に属するかを判別（検出）する。この判別結果は、コード判別を行うべきタイミングを表すタイミング情報として、後述する音高比較部１０８に送出される。
【００３４】
上記押鍵速度は、鍵の操作を検出したときに１度求められる。それが強拍に属すると判別した場合、その旨を示すタイミング情報が所定期間だけ押鍵タイミング判別部１０５から音高比較部１０８に送られる。これにより、強拍に属する鍵の操作が検出されていない状態である鍵が強く操作された場合、その鍵が操作されてから上記所定期間が経過するまではコード判別を行う期間となる。
【００３５】
コード検出部１０６は、演奏情報記憶部１０４に記憶されている演奏情報を読み出し、現在押鍵中の鍵に割り当てられた音高からコード種を判別する。コード確定部１０７は、コード検出部１０６が判別したコード種（コードデータ）を、音高比較部１０８から入力した制御信号に応じてこれを保持するか否か決定する。このコード確定部１０７に保持されたコードデータで表されるコード種が現在確定しているコードである。
【００３６】
音高比較部１０８は、詳細は後述する図２の全体処理のフローチャートを用いて説明するが、押鍵タイミング判別部１０５から入力したタイミング情報（強拍に属する押鍵の有無）、コード検出部１０６から入力した現在押鍵中の鍵の音高データ、最新押鍵データ記憶バッファ１０９に記憶されている音高データの各データに基づいて、ユーザが意図しないコードの指定が行われているか否かを判断し、その判断結果に従って制御信号をコード検出部１０６、コード確定部１０７に出力する。この制御信号を出力した後、音高比較部１０８は、コード検出部１０６から入力した音高データを新たに最新押鍵データ記憶バッファ１０９に格納する。これにより、最新押鍵データ記憶バッファ１０９には、演奏情報入力装置１０１をスキャンした際の最新の結果が、スキャンが行われる度に随時格納され、更新される。
【００３７】
上記コード検出部１０６は、現在押鍵中の鍵からコード種を判別し、上記制御信号に従って、該判別したコード種を表すコードデータをコード確定部１０７に出力する。一方のコード確定部１０７は、音高比較部１０８から入力した制御信号に従って、当該音高比較部１０８がユーザが意図しないコードの指定が行われていないと判断された場合にコード検出部１０６が出力したコードデータを格納する。
【００３８】
自動伴奏発生部１１０は、コード確定部１０７に格納されているコードデータで伴奏音を発生する。このとき伴奏音は、特には図示しないコンソールに設けられたスイッチの操作により指定された内容（リズム、音色、テンポ等）で発生する。
【００３９】
以上が電子楽器１００の構成、及び概略動作である。次に図２に示す全体処理のフローチャートを参照して、制御部１０２による全体動作を説明する。電源がオンされると、先ず、制御部１０２はその内部に備えているＲＡＭ（図示せず）の内容の初期設定（イニシャライズ）等を行い（ステップ２０１）、次に演奏情報入力装置１０１のスキャン処理、該スキャン処理の結果に応じてメロディ、及び伴奏音を発音させる発音イベント処理（詳細は後述する）等の各種イベント処理を実行する（ステップ２０２）。
【００４０】
ステップ２０２の各種イベント処理が終了すると、次にコンソール上のスイッチ群のスキャンを行い、そのスキャン結果に応じたモードの設定／切り換え、特には図示しない表示器類の表示等を行うコンソールスイッチ処理を実行する（ステップ２０３）。このコンソールスイッチ処理が終了した後、例えば所定の時間内になんの操作も行われなければ電源をオフするといったその他の制御処理を実行し（ステップ２０４）、ステップ２０２の処理に戻る。
【００４１】
ステップ２０２〜２０４の処理の繰り返しにより、電子楽器１００は、ユーザの操作に応じてメロディ、伴奏音の発生、モードの設定、及び切り換えを行うことになる。
【００４２】
次に、上記ステップ２０２の各種イベント処理について詳細に説明する。上述したように、このステップ２０２の処理内容は、演奏情報入力装置１０１のスキャンを行う処理と、該スキャンに応じた発音イベント処理とに大別され、この順序で各処理は実行される。スキャンは一般的に広く知られている方法を用いていることから、ここでは発音イベント処理についてのみ説明する。
【００４３】
図３は、第１の実施例による発音イベント処理のフローチャートである。この発音イベント処理は、制御部１０２が、コード検出部１０６、音高比較部１０８等の各部が行う動作を制御することで進行するものである。
【００４４】
発音イベント処理では、先ず、演奏情報入力装置１０１、即ち鍵盤１０１ａ、及び各種ペダル１０１ｂに対する操作イベントの有無を判断する（ステップ３０１）。この操作イベントの有無は、演奏情報記憶部１０４に記憶された内容から判断される。演奏操作イベント無しと判断すると（ステップ３０１、ＮＯ）、ここで一連の処理を終了し、反対に演奏操作イベント有りと判断すると（ステップ３０１、ＹＥＳ）、ステップ３０２の処理に移行する。
【００４５】
ステップ３０２では、押鍵イベントの有無を判断する。押鍵イベント無しと判断すると（ステップ３０２、ＮＯ）、各種ペダル１０１ｂの操作に応じて発音させる音の音量、その長さを設定する等のその他のイベント処理を実行し（ステップ３０３）、その処理を終了した後、一連の処理が終了する。
【００４６】
ステップ３０２において、押鍵イベント有りと判断すると、次に押鍵イベントを検出した鍵に割り当てられた音高で楽音を発音させる発音処理を実行し（ステップ３０４）、その後、ステップ３０５の処理に移行する。ステップ３０４の発音処理は、演奏情報入力装置１０１から出力されたスキャン結果に応じて楽音発生部１０３に楽音を発音させることで実現される。
【００４７】
ステップ３０５では、現在伴奏モードが設定されているか否か判断する。伴奏モードが設定されていないと判断すると（ステップ３０５、ＮＯ）、ここで一連の処理を終了し、反対に伴奏モードが設定されていると判断すると（ステップ３０５、ＹＥＳ）、ステップ３０６の処理に移行する。ここで、電子楽器１００は、伴奏音のコードは鍵盤１０１ａ上の全ての鍵で指定できる全鍵伴奏域仕様である。このため、コードは、音高の低いほうから押鍵されている鍵をその構成音の数だけ参照することで判別される。
【００４８】
ステップ３０６では、現在コードが確定しているか否か判断する。コードが確定していないと判断すると（ステップ３０６、ＮＯ）、現在押鍵されている鍵からコード種を判別する処理を実行する（ステップ３０７）。このコード判別処理は、コード検出部１０６に、演奏情報記憶部１０４に記憶されている演奏情報からコードを判別させることで実現される。演奏情報からコードを新たに判別できなかった場合、それまで確定していたコードから変更されず、コード確定部１０７はそれまで保持していたコードデータを継続して保持する。
【００４９】
コードの判別が終了すると、次にコードが確定したか否か判断する（ステップ３０８）。コードが確定したと判断すると（ステップ３０８、ＹＥＳ）、確定したコードで伴奏音を自動伴奏発生部１１０に発音させるコード発音処理を実行する（ステップ３０９）。コード発音処理が終了すると、最新押鍵の音高データを更新して（ステップ３１０）、一連の処理を終了する。
【００５０】
上記ステップ３０９のコード発音処理は、コード確定部１０９に保持されているコードデータで自動伴奏発生部１１０に伴奏音を発音させる制御信号を出力することで実現される。また、最新押鍵の音高データを更新するステップ３１０の処理は、音高比較部１０８に、コード検出部１０６から受け取った現時点で押鍵されている最新の鍵の音高データを、最新押鍵データ記憶バッファ１０９に書き込ませることで実現される。
【００５１】
一方、ステップ３０６において、現在コードが確定していると判断すると、次にステップ３１１において、現在確定しているコードの構成音の鍵が押鍵されているか否か、即ちコードを確定させた押鍵が継続しているか否か判断する。この判断処理は、音高比較部１０８に、前の処理ループによってコード確定部１０７に保持されたコードデータからその構成音を求め、該求めた構成音とコード検出部１０６から入力した音高データとを比較させることで実現される。コードの構成音の鍵が押鍵されていると判断すると（ステップ３１１、ＹＥＳ）、ステップ３０９の処理に移行し、反対にコードの構成音の鍵が押鍵されていないと判断すると（ステップ３１１、ＮＯ）、ステップ３１２の処理に移行する。
【００５２】
ステップ３１２では、ステップ３０１、３０２にて検出された押鍵イベントの検出タイミングである演奏押鍵タイミングは弱拍か否か判断する。押鍵タイミングが弱拍ではないと判断すると（ステップ３１２、ＮＯ）、ステップ３０７のコード判別処理に移行し、反対にそれが弱拍と判断すると（ステップ３１２、ＹＥＳ）、ステップ３１３の処理に移行する。
【００５３】
押鍵された強さが弱拍か否かは、上記したように、押鍵タイミング判別部１０５が、設定速度と操作を検出した鍵の押鍵速度とを比較することで判断される。この設定速度は、ＭＩＤＩ（Musical Instrument Digital Interface）を例にすると、例えば鍵を弾いたときの強弱を伝えるパラメータであるベロシティの値（１〜１２７段階の精度を有する）が"４０"程度に対応する値である。音高比較部１０８は、押鍵タイミング判別部１０５から強拍に属する押鍵を検出した旨を示すタイミング情報が送られていない場合、押鍵タイミングが弱拍と判断し、そうでない場合、押鍵タイミングは強拍と判断する。
【００５４】
コードチェンジ等は、曲の進行にタイミングを合わせて行われるので、コード指定を意図した押鍵は強くなるのが普通である。また、一般的に、伴奏音は指定された音量で発音されることから、コードを指定するために意識して弱く鍵を弾かなければならない理由は特にない。これらのことから、押鍵タイミングが弱拍であった場合、コードを指定する複数の鍵が押鍵されていても、ユーザはそのコードの指定を所望していない可能性が高いと言える。この場合はコードの判別を中止するので、ユーザの意図しないコードチェンジを回避することができる。
【００５５】
図４（ａ）〜（ｃ）は、演奏における強拍、弱拍の押鍵例を示す図である。楽曲は、図４に示すように、１小節内において、小節の先頭を強拍とし、その他を弱拍とするように演奏されることが多い。小節は、楽曲の定められた拍子に合うようになっており、演奏におけるリズムの単位である。このため、普通、コードチェンジは、小節の先頭のタイミング、即ち押鍵タイミング（押鍵速度）が強拍のときに行われ、押鍵速度が弱拍であった場合、ユーザはコード指定を意図していないことが多い。
【００５６】
第１の実施例では、ユーザが実際に鍵を押鍵したときの強さからコード判別を行うタイミングを判断することで、ユーザが意図しないコードチェンジを回避している。しかし、図４（ａ）〜（ｃ）に示すように、強拍、弱拍の押鍵が規則的に行われる場合も多い。このことから、ある楽曲において強拍で演奏（押鍵）されるタイミングをコード判別するタイミングとして予め定めても、ユーザが意図しないコードチェンジを回避することができる。
【００５７】
自動伴奏機能を搭載した電子楽器は、自動伴奏を行うために演奏データを有し、この演奏データには発音する個々の楽音を管理するための時間データが含まれる。このため、小節の先頭であるか否かを含め、現在の演奏位置は演奏データか知ることができ、その実現は容易である。
【００５８】
なお、第１の実施例では、押鍵速度が強拍に属する押鍵を１つでも検出すればコードの判別を行うことになるが、コードは複数の鍵を押鍵することで指定することから、例えば、それらの鍵が弾かれた際の平均の押鍵速度が設定速度よりも遅い（弱い）場合や、その設定速度よりも遅く（弱く）弾かれた鍵が１つでもあった場合、押鍵タイミングは弱拍であると判断（即ち、コード判別を中止）するようにしても良い。また、押鍵速度、即ち鍵が弾かれた際の強さの他に、小節の先頭であるか否かといった押鍵されたタイミングを含めてコード判別を行うようにしてもよい。
【００５９】
上記平均の強さを採用する場合、例えば第１、及び第２の設定速度（第１の設定速度＞第２の設定速度である）を用意し、平均の強さが第１の設定速度よりも速く、且つ各鍵毎の強さが全て第２の設定速度よりも速い場合にコード判別を行うようにしても良い。例えば１つの鍵が非常に強く押鍵されたような場合、１つの設定速度では意図しないコードを判別することも考えられる。しかし、２つの設定速度を設けることで、このような不具合は確実に回避することができる。
【００６０】
更には、例えばコードの指定は３鍵の押鍵により指定すると想定した場合、弱く弾かれた鍵は無視し、音高の低いほうから強く弾かれた３鍵を抽出してコード判別を行うようにしても良い。これは、技量レベルが低いユーザにとってはコード指定が容易になるという効果が期待できる。
【００６１】
ステップ３１３では、新たに押鍵された鍵の音高が、１つ前に押鍵された鍵、即ちその押鍵の直前に離鍵された鍵の音高と２度の範囲内で隣接しているか否か判断する。この判断処理は、音高比較部１０８に、コード検出部１０６から入力した音高データと、最新押鍵データ記憶バッファ１０９に記憶されている音高データとを参照させ、該当する２つの音高データを特定させて行われる処理である。例えば前回のスキャンした状態から新たに１つの鍵が押鍵された場合、コード検出部１０６から出力された音高データの数は、最新押鍵データ記憶バッファ１０９に記憶されている音高データの数より１つだけ多いことから、これらの音高データを比較することで新たに押鍵された鍵が特定される。前回のスキャンから新たな押鍵がなかった場合、最新押鍵データ記憶バッファ１０９にはコード検出部１０６から出力される音高データが全て記憶されていることになる。この場合にはコード判別を行う必要がないと判断され、ステップ３１３からステップ３０９に移行する。
【００６２】
ステップ３１３において、２度の範囲で隣接していると判断すると（ＹＥＳ）、ステップ３０９の処理に移行してコード確定部１０７に保持されたコードで伴奏音を発音させる。反対に２度の範囲で隣接していないと判断すると（ＮＯ）、ステップ３１４の処理に移行する。
【００６３】
ステップ３１４では、今回押鍵された鍵の音高は既に押鍵されている他の鍵の音高と２度の範囲内で隣接しているか否か判断する。これらの音程差が２度の範囲内であった場合、その判定はＹＥＳとなり、ステップ３０９の処理に移行する。音程差が２度の範囲外であった場合、その判定はＮＯとなり、ステップ３０７のコード判別処理に移行する。このステップ３１４の判断処理も、音高比較部１０８に、コード検出部１０６から入力した音高データと、最新押鍵データ記憶バッファ１０９に記憶されている音高データとを参照させることで行われる処理である。
【００６４】
図５は、音程差として短２度、長２度の例を示す図であり、同図（ａ）は短２度、同図（ｂ）は長２度の音程差を各々示す。
基本的なコードは、音程が３度の音を３つ積み重ねてなり、電子楽器１００（自動伴奏発生部１１０）が伴奏音として発音するために用意したコードの構成音は３度以上の音程差がある。また、コード指定時の操作としては、複数の鍵を順次押鍵することはなく、スキャンによって押鍵を検出した時期は異なっても、少なくとも複数の鍵は狭い時間内に押鍵されるのが普通である。これらのことから、新たに押鍵された鍵と既に押鍵されている鍵の間の音程差が３度以下となっている場合、ユーザはコード指定を意図していない可能性が高いと言える。この場合、上述したように、ステップ３１３、或いは３１４でコード判別を行う状況ではないと判断される。このため、ユーザの所望しないコード判別が回避され、ユーザの意図に沿ったコード進行が得られることになる。
【００６５】
ステップ３１３では、押鍵された時期が前後する２つの音高データの音程差だけが比較される。このため、他の音高データとも比較するステップ３１４と比較すると、ユーザの所望しないコードを判別する危険性は高いが、その処理は高速に行うことができるという利点がある。このことから、これはステップ３１２を含めたことであるが、コード判別を行うか否かの判断の基準となる演奏状態を複数選択し、これらを組み合わせることで、よりユーザの意図した通りのコードチェンジが可能となり、また、その処理に要する時間を全体的に短縮させることが可能となる。
【００６６】
上述した発音イベント処理において、ステップ３１２〜３１４は、新たに押鍵された鍵に着目し、新たに押鍵された鍵はメロディとして押鍵されたのか、或いはコード指定を意識して押鍵されたのかを分析する処理である。既に押鍵されている他の音高データの間の関係等は基本的には考慮せず、新たな押鍵の機能を随時分析しながらコード判別を行うか否か判断していくので、個々のステップにおける処理内容は簡易であるにも係わらず、意図しないコードの指定の回避において高い効果が得られる。
【００６９】
なお、第１の実施例では音程差、押鍵時の強弱等のコード判別を行う条件は固定であるが、ユーザが設定できるようにしてもよい。このようにした場合、例えばコード判別を行わない音程差を少なくとも一つを任意に設定することで、用意されているコード種のなかから指定できるコード種を限定させることも可能である。
【００７０】
次に、第２の実施例について説明する。この第２の実施例は、上記第１の実施例と同様に、電子楽器１００に適用されたものであり、その基本的な構成は第１の実施例と同じである。このため、同じ符号を用いて第１の実施例から異なる部分だけ説明する。
【００７１】
図６は、第２の実施例による発音イベント処理のフローチャートである。図６を参照して、その発音イベント処理について説明する。第２の実施例では、先ず、演奏情報入力装置１０１、即ち鍵盤１０１ａ、及び各種ペダル１０１ｂに対する操作イベントの有無を判断する（ステップ６０１）。この操作イベントの有無は、演奏情報記憶部１０４に記憶された内容から判断される。演奏操作イベント無しと判断すると（ステップ６０１、ＮＯ）、ここで一連の処理を終了し、反対に演奏操作イベント有りと判断すると（ステップ６０１、ＹＥＳ）、ステップ６０２の処理に移行する。
【００７２】
ステップ６０２では、押鍵イベントの有無を判断する。押鍵イベント無しと判断すると（ステップ６０２、ＮＯ）、各種ペダル１０１ｂの操作に応じて発音させる音の音量、その長さを設定する等のその他のイベント処理を実行し（ステップ６０３）、その処理を終了した後、一連の処理を終了する。
【００７３】
ステップ６０２において、押鍵イベント有りと判断すると、次に押鍵イベントを検出した鍵に割り当てられた音高で楽音を発音させる発音処理を実行し（ステップ６０４）、その後、ステップ６０５の処理に移行する。ステップ６０４の発音処理は、演奏情報入力装置１０１から出力されたスキャン結果に応じて楽音発生部１０３に楽音を発音させることで実現される。
【００７４】
ステップ６０５では、現在伴奏モードが設定されているか否か判断する。伴奏モードが設定されていないと判断すると（ステップ６０５、ＮＯ）、ここで一連の処理を終了し、反対に伴奏モード（全鍵伴奏域仕様）が設定されていると判断すると（ステップ６０５、ＹＥＳ）、ステップ６０６の処理に移行する。
【００７５】
ステップ６０６では、現在コードが確定しているか否か判断する。コードが確定していないと判断すると（ステップ６０６、ＮＯ）、現在押鍵されている鍵からコード種を判別する処理を実行する（ステップ６０７）。このコード判別処理は、コード検出部１０６に、演奏情報記憶部１０４に記憶されている演奏情報からコードを判別させることで実現される。演奏情報からコードを新たに判別できなかった場合、それまで確定していたコードから変更されず、コード確定部１０７はそれまで保持していたコードデータを継続して保持する。
【００７６】
コードの判別が終了すると、次にコードが確定したか否か判断する（ステップ６０８）。コードが確定したと判断すると（ステップ６０８、ＹＥＳ）、確定したコードで伴奏音を自動伴奏発生部１１０に発音させるコード発音処理を実行する（ステップ６０９）。コード発音処理が終了すると、最新押鍵の音高データを更新して（ステップ６１０）、一連の処理を終了する。
【００７７】
上記ステップ６０９のコード発音処理は、コード確定部１０９に保持されているコードデータで自動伴奏発生部１１０に伴奏音を発音させることで実現される。また、最新押鍵の音高データを更新するステップ６１０の処理は、音高比較部１０８に、コード検出部１０６から受け取った現時点で押鍵されている最新の鍵の音高データを、最新押鍵データ記憶バッファ１０９に書き込ませることで実現される。
【００７８】
一方、ステップ６０６において、現在コードが確定していると判断すると、次にステップ６１１において、現在確定しているコードの構成音の鍵が押鍵されているか否か、即ちコードを確定させた押鍵が継続しているか否か判断する。この判断処理は、音高比較部１０８に、コード確定部１０７に保持されているコードデータからその構成音を求め、該求めた構成音とコード検出部１０６から入力した音高データとを比較させることで実現される。コードの構成音の鍵が押鍵されていると判断すると（ステップ６１１、ＹＥＳ）、ステップ６０９の処理に移行し、反対にコードの構成音の鍵が押鍵されていないと判断すると（ステップ６１１、ＮＯ）、ステップ６１２の処理に移行する。
【００７９】
ステップ６１２では、ダンパーペダルはオン（ＯＮ）されているか否か判断する。ダンパーペダルはオンされていないと判断すると（ステップ６１２、ＮＯ）、ステップ６０７のコード判別処理に移行し、反対にオンされていると判断すると（ステップ６１２、ＹＥＳ）、ステップ６０９の処理に移行する。
【００８１】
なお、第２の実施例は、ダンパーペダルの操作状態に応じてコード判別を行うようにしたものであるが、この第２の実施例を第１の実施例に組み込んだ実施例としても良い。この場合、図６のステップ６１２の処理は、例えば図６のステップ３１１と３１２の処理の間に挿入すれば良い。
【００８２】
また、第１、及び第２の実施例は、全鍵伴奏域仕様の場合を例にして説明しているが、自動伴奏機能の仕様としてはこれだけに限定されるものではない。誤った押鍵による意図しないコードの指定を回避できることから、伴奏鍵域とメロディ鍵域とに機能を分割するスプリット仕様の電子楽器にも本発明は適用することができる。また、伴奏音のコード判別だけに限定されるものではなく、ユーザが指定したコードに応じて何らかの楽音を発音させる機能を電子楽器が備えていれば本発明は容易に適用することができる。本発明から得られる効果としては、上述した効果の他に、コードを指定する各鍵が押鍵されたタイミング、各鍵毎の強さ等の演奏状態に応じてコード判別を行うことから、演奏内容のチェックが行えるという効果も期待できる。
【図面の簡単な説明】
【００８３】
【図１】第１の実施例（及び第２の実施例）が適用された電子楽器の構成を示すブロック図である。
【図２】全体処理のフローチャートである。
【図３】第１の実施例による発音イベント処理のフローチャートである。
【図４】強拍、弱拍の押鍵例を示す図である。
【図５】強拍、弱拍の押鍵例を示す図である。
【図６】第２の実施例による発音イベント処理のフローチャートである。
【符号の説明】
【００８４】
１００ 電子楽器
１０１ 演奏情報入力装置
１０１ａ 鍵盤
１０１ｂ 各種ペダル
１０２ 制御部
１０４ 演奏情報記憶部
１０５ 押鍵タイミング判別部
１０６ コード検出部
１０７ コード確定部
１０８ 音高比較部
１０９ 最新押鍵データ記憶バッファ
【図１】
0003728626.tif 000002
【図２】
0003728626.tif 000003
【図３】
0003728626.tif 000004
【図４】
0003728626.tif 000005
【図５】
0003728626.tif 000006
【図６】
0003728626.tif 000007