(57)【要約】【課題】楽曲データを利用して複数のパートの演奏を行える演奏装置を提供する。【解決手段】ＣＰＵ１は、複数の演奏パートの演奏内容を示す楽曲データをＲＯＭ２から読み込み、それぞれの演奏パートごとに楽曲データによって発音が示されている楽音の音高を候補音高として設定する。演奏者が鍵盤４のキーを押鍵すると、その押鍵に対応して楽音を発音させる演奏パートを選択し、選択した演奏パートで設定した候補音高で楽音を発音させる。選択した演奏パートがコードパートでは、発音させるべきコードの構成音が全て発音中であれば、構成音の１オクターブ上の音高、或いは一オクターブ下の音高で楽音を発音させる。【選択図】図１
2008020875.tif 000002
【特許請求の範囲】
【請求項１】
演奏者が演奏を行うための複数の演奏操作子を備えた演奏装置において、
複数の演奏パートの演奏内容を示す楽曲データを記憶する楽曲データ記憶手段と、
前記楽曲データ記憶手段が記憶する楽曲データを参照して、前記演奏パート毎に、演奏の進行に応じて該楽曲データが表す楽音の音高を候補音高として随時、設定する音高設定手段と、
前記複数の演奏操作子のなかの何れかの演奏操作子が操作された場合に、該演奏操作子への操作により楽音を発音させる演奏パートを選択し、該選択した演奏パートで前記音高設定手段が設定した候補音高により楽音を楽音発生装置により発音させる発音制御手段と、
を具備することを特徴とする演奏装置。
【請求項２】
前記発音制御手段は、前記演奏操作子への操作により楽音を発音させる演奏パートを、前記複数の演奏パート間で定めた優先度、及び該演奏操作子に割り当てられた音高のうちの何れかに着目して選択する、
ことを特徴とする請求項１記載の演奏装置。
【請求項３】
前記複数の演奏パートとして、メロディパート、コードパート、及びベースパートが存在する場合、前記発音制御手段は、前記演奏操作子への操作により楽音を発音させる演奏パートを、該ベースパートは該演奏操作子に割り当てられた音高により選択し、該メロディパート、及び該コードパートは、該ベースパートを該割り当てられた音高により選択しない場合に、それらの間で定めた優先度に従って選択する、
ことを特徴とする請求項２記載の演奏装置。
【請求項４】
前記発音制御手段は、前記複数の演奏操作子を複数のグループに分けると共に、各グループに一つ以上の演奏パートを割り当てることにより、該複数の演奏操作子のなかで操作された演奏操作子の属するグループに基づいて、該操作子への操作により楽音を発音させる演奏パートを選択する、
ことを特徴とする請求項１、または２記載の演奏装置。
【請求項５】
前記発音制御手段は、前記複数のグループを構成する第１のグループに属する演奏操作子への操作により前記演奏を進行させる、
ことを特徴とする請求項４記載の演奏装置。
【請求項６】
前記発音制御手段は、前記第１のグループに属する演奏操作子を、該第１のグループに割り当てた演奏パートにおいて前記音高設定手段が設定する候補音高に応じて動的に変更し、操作すべき演奏操作子への操作により前記演奏を進行させる、
ことを特徴とする請求項５記載の演奏装置。
【請求項７】
演奏装置に備えられている複数の演奏操作子を用いた演奏者による演奏を実現させるための方法であって、
楽曲データが演奏内容を示す複数の演奏パートの演奏を前記演奏者が行う場合に、前記複数の演奏操作子を複数のグループに分けると共に、各グループに一つ以上の演奏パートを割り当て、
前記楽曲データを参照して、前記演奏パート毎に、前記演奏の進行に応じて該楽曲データが表す楽音の音高を候補音高として随時、設定し、
前記複数の演奏操作子のなかの何れかの演奏操作子が操作された場合に、該操作された演奏操作子の属するグループに基づいて、前記複数の演奏パートのなかから該グループに割り当てた演奏パートを選択し、
該選択した演奏パートで設定されている候補音高を基に該演奏パートの楽音を楽音発生装置により発音させることで前記演奏を実現させる、
ことを特徴とする演奏実現方法。
【請求項８】
演奏者が演奏を行うための複数の演奏操作子を備えた演奏装置として用いることが可能なコンピュータに、
楽曲データ記憶手段に記憶されている、複数の演奏パートの演奏内容を示す楽曲データを参照して、前記演奏パート毎に、演奏の進行に応じて該楽曲データが表す楽音の音高を候補音高として随時、設定する音高設定機能と、
前記複数の演奏操作子のなかの何れかの演奏操作子が操作された場合に、該演奏操作子への操作により楽音を発音させる演奏パートを選択し、該選択した演奏パートで前記音高設定機能により設定した候補音高により楽音を楽音発生装置により発音させる発音制御機能と、
を実現させるためのプログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、演奏者が演奏を行うための複数の演奏操作子を備えた演奏装置に関する。
【背景技術】
【０００２】
電子鍵盤楽器等の演奏用の演奏操作子を備えた演奏装置のなかには、演奏者（ユーザー）が操作子を操作したタイミングに合わせて、その操作子の種類に係わらず、楽曲データが示す発音順序に従って楽音を発音させる機能を搭載したものがある。その機能を用いた演奏では、どの演奏操作子を操作しても、楽曲データが示す演奏内容に従って楽曲を演奏することができる。このことから、その演奏は主に操作子を操作すべきタイミングの練習用などに利用されている。発音させる楽音は楽曲データに依存し、操作される演奏操作子に依存しないことから、つまり、どの操作子を操作しても演奏を行えることから、その機能については以降「エニーキー機能」と呼ぶことにする。
【０００３】
上記エニーキー機能を用いた演奏では、楽曲の演奏内容を示す楽曲データは、演奏操作子への操作によって発音させる楽音の設定（選択）に利用される。演奏を進行させる方法は、演奏操作子への操作によって進行させる方法（以降「マニュアル進行方法」と呼ぶ）、楽曲データに沿って自動的に進行させる方法（以降「自動進行方法」と呼ぶ）に大別することができる。演奏操作子への操作によって発音される楽音は、マニュアル進行方法では操作子に対してそれまでに行った操作回数に応じて選択され、自動進行方法では操作子を操作したタイミングに応じて選択される。
【０００４】
エニーキー機能を搭載した演奏装置では、一つの演奏操作子への１回の操作によって発音させる楽音は一つとし、同時に発音中とさせる楽音数は一つのみとしているのが普通である。しかし、エニーキー機能を搭載した従来の演奏装置のなかには、特許文献１に記載されたように、複数の楽音を同時に発音できるようにしたものがある。演奏操作子については以降「キー」と表記する。
【０００５】
特許文献１に記載の従来の演奏装置では、演奏者が演奏すべき演奏パートとしてコードパートを想定し、コード（和音）の構成音の各音高を候補音高として設定する。候補音高の設定は、演奏の進行に応じて随時、更新するものである。演奏者がキーを操作すると、そのキーに割り当てられた音高に応じて、候補音高の中から選択した音高またはそれをオクターブ単位で高く若しくは低く変換（転回）した音高で楽音を発音させる。そのようにして、キーへの操作により、構成音数の楽音を同時に発音させることを可能とさせている。
【０００６】
発音させる楽音の選択は、具体的には以下のように行われる。
キーが操作されると先ず、候補音高の中に未発音のものがあるか否か確認する。その結果、未発音のものが確認できれば、今回、操作されたキーの音高が前回、操作されたキーの音高よりも高いか否か確認し、それによって前回、操作されたキーの音高より高い音高のキーを今回、操作したことが判明すると、前回の操作で発音させた楽音の音高より高い未発音の候補音高を探し、そのような候補音高があれば、その候補音高を選択する。逆になければ、未発音の候補音高を一つ選択し、それを１オクターブ上に変換した音高で楽音を発音させる。
【０００７】
候補音高がすべて発音中であっても、前回操作されたキーと今回操作のキーの音高を比較する。それにより、前回操作されたキーよりも高い音高のキーを演奏者が今回操作した場合は、発音中の候補音高のうちの１つを１オクターブ高く変換した音高で楽音をさらに発音させる。逆に今回操作されたキーの音高が前回操作されたキーの音高よりも低いことを確認した場合には、音高の高低を逆にして同様の選択が行われる。
【０００８】
このようにして特許文献１に記載の従来の演奏装置では、楽曲データが示すコードパートの演奏内容の演奏をできるようにしつつ、その演奏内容を演奏者が実際に行った演奏操作に応じて変更、つまり演奏者が実際に行った演奏操作を演奏内容に反映するようにしている。それにより、演奏者にとって自然と感じられる内容の演奏も行えるようになっている。
【０００９】
演奏者は複数の演奏パートを演奏する場合がある。例えば鍵盤楽器では、メロディパートとコードパートを演奏することも多い。このようなこともあり、楽曲データを利用した演奏でも、複数の演奏パートの演奏を行えることを望む人も少なくないと思われる。それにより、そのような演奏を行える演奏装置を提供することも重要と考えられる。
【特許文献１】特開２００４−１７７８９３号公報
【発明の開示】
【発明が解決しようとする課題】
【００１０】
本発明の課題は、楽曲データを利用して複数の演奏パートの演奏を行える演奏装置を提供することにある。
【課題を解決するための手段】
【００１１】
本発明の演奏装置は、演奏者が演奏を行うための複数の演奏操作子を備えたもの、或いは複数の演奏操作子を備えた装置が接続可能なものであり、複数の演奏パートの演奏内容を示す楽曲データを記憶する楽曲データ記憶手段と、楽曲データ記憶手段が記憶する楽曲データを参照して、演奏パート毎に、演奏の進行に応じて該楽曲データが表す楽音の音高を候補音高として随時、設定する音高設定手段と、複数の演奏操作子のなかの何れかの演奏操作子が操作された場合に、該演奏操作子への操作により楽音を発音させる演奏パートを選択し、該選択した演奏パートで音高設定手段が設定した候補音高により楽音を楽音発生装置により発音させる発音制御手段と、を具備する。
【００１２】
なお、上記発音制御手段は、演奏操作子への操作により楽音を発音させる演奏パートを、複数の演奏パート間で定めた優先度、及び該演奏操作子に割り当てられた音高のうちの何れかに着目して選択する、ことが望ましい。また、複数の演奏パートとして、メロディパート、コードパート、及びベースパートが存在する場合、発音制御手段は、演奏操作子への操作により楽音を発音させる演奏パートを、該ベースパートは該演奏操作子に割り当てられた音高により選択し、該メロディパート、及び該コードパートは、該ベースパートを該割り当てられた音高により選択しない場合に、それらの間で定めた優先度に従って選択する、ことが望ましい。
【００１３】
また、上記発音制御手段は、複数の演奏操作子を複数のグループに分けると共に、各グループに一つ以上の演奏パートを割り当てることにより、該複数の演奏操作子のなかで操作された演奏操作子の属するグループに基づいて、該操作子への操作により楽音を発音させる演奏パートを選択する、ことが望ましい。その場合、複数のグループを構成する第１のグループに属する演奏操作子への操作により演奏を進行させる、ことが望ましい。その第１のグループに属する演奏操作子は、該第１のグループに割り当てた演奏パートで音高設定手段が設定する候補音高に応じて動的に変更し、操作すべき演奏操作子への操作により演奏を進行させる、ことが望ましい。
【００１４】
本発明の演奏実現方法は、演奏装置に備えられている複数の演奏操作子を用いた演奏者による演奏を実現させるための方法であって、楽曲データが演奏内容を示す複数の演奏パートの演奏を演奏者が行う場合に、複数の演奏操作子を複数のグループに分けると共に、各グループに一つ以上の演奏パートを割り当て、楽曲データを参照して、演奏パート毎に、演奏の進行に応じて該楽曲データが表す楽音の音高を候補音高として随時、設定し、複数の演奏操作子のなかの何れかの演奏操作子が操作された場合に、該操作された演奏操作子の属するグループに基づいて、複数の演奏パートのなかから該グループに割り当てた演奏パートを選択し、該選択した演奏パートで設定されている候補音高を基に該演奏パートの楽音を楽音発生装置により発音させることで演奏を実現させる。
【００１５】
本発明のプログラムは、演奏者が演奏を行うための複数の演奏操作子を備えた演奏装置として用いることが可能なコンピュータに、楽曲データ記憶手段に記憶されている、複数の演奏パートの演奏内容を示す楽曲データを参照して、演奏パート毎に、演奏の進行に応じて該楽曲データが表す楽音の音高を候補音高として随時、設定する音高設定機能と、複数の演奏操作子のなかの何れかの演奏操作子が操作された場合に、該演奏操作子への操作により楽音を発音させる演奏パートを選択し、該選択した演奏パートで音高設定機能により設定した候補音高により楽音を楽音発生装置により発音させる発音制御機能と、を実現させる。
【発明の効果】
【００１６】
本発明では、複数の演奏パートの演奏内容を示す楽曲データを参照して、演奏パート毎に、演奏の進行に応じてその楽曲データが表す楽音の音高を候補音高として随時、設定し、複数の演奏操作子のなかの何れかの演奏操作子が操作された場合に、複数の演奏パートのなかで当該演奏操作子への操作により楽音を発音させる演奏パートを選択し、選択した演奏パートで設定した候補音高（或いはその候補音高から特定される音高）により楽音を発音させる。このため、演奏者にとっては、発音させるべき楽音を発音させるための演奏操作子を操作することなく、つまりその演奏操作子以外の演奏操作子を操作して、複数の演奏パートの演奏を行うことができる。
【００１７】
上記複数の演奏パートの演奏は、複数の演奏操作子を複数のグループに分けると共に、各グループに一つ以上の演奏パートを割り当て、楽曲データを参照して演奏パート毎に設定する候補音高のなかで演奏操作子への操作により楽音の発音に用いる候補音高を、その演奏操作子が属するグループに割り当てられている演奏パートに応じて選択することで行えるようにすることができる。その場合、操作する演奏操作子により、楽音を発音させる演奏パートを演奏者は選択することができる。
【発明を実施するための最良の形態】
【００１８】
以下、本発明の実施の形態について、図面を参照しながら詳細に説明する。
＜第１の実施形態＞
図１は、第１の実施形態による演奏装置の構成図である。本実施形態による演奏装置は鍵盤楽器であり、全体を制御するＣＰＵ１と、ＣＰＵ１が実行するプログラム、各種制御用データ、および演奏対象の楽曲データ等を格納したＲＯＭ（Read Only Memory）２と、ＣＰＵ１がワークに用いるＲＡＭ（Random Access Memory）３と、複数のキー（演奏操作子である鍵）を有する鍵盤４と、各種操作子を有するスイッチ群５と、例えばＭＩＤＩ（Musical Instrument Digital Interface）データで発音が指示された楽音の波形データを生成し、その波形データをＤ／Ａ変換して得られるオーディオ信号を出力する音源システム６と、音源システム６から出力されたオーディオ信号を増幅して出力するアンプ回路７と、アンプ回路７から入力したオーディオ信号により楽音を放音するスピーカー８と、ＣＰＵ１、ＲＯＭ２、ＲＡＭ３、鍵盤４、スイッチ群５、音源システム６を互いに接続するバス９と、を備えている。
【００１９】
ＣＰＵ１はＲＯＭ２に記録されているプログラムを実行することにより、演奏者（ユーザー）が鍵盤４やスイッチ群５に対して行った操作に応じた制御を行う。鍵盤４への操作が行われた場合には、操作されたキーに割り当てられている音高の楽音の発音指示を音源システム６に対して行う。その指示に従って音源システム６が波形データを生成してオーディオ信号をアンプ回路７に出力する結果、その楽音がスピーカー８により発音される。それにより、音源システム６は楽音発生装置に相当する。スイッチ群５への操作が行われた場合には、操作が行われた操作子に応じて、楽曲データの指定を含む各種設定を行う。その楽音発生装置は、演奏装置に搭載されていないものであっても良い。
【００２０】
スイッチ群５への操作により設定可能なモードとして、楽曲データから特定される音高の楽音を鍵盤４へのキー操作により発音させるもの（以降「エニーキーモード」）がある。そのエニーキーモードは本発明に係わるモードである。このことから便宜的に以降、特に断らない限り、そのエニーキーモードが設定されていることを前提に説明する。ここでは、そのエニーキーモードで用いられる楽曲データは選択されているものとする。また、以下のことも前提とする。
（１）演奏者が演奏すべき演奏パート（以降「対象演奏パート」）は、メロディパート、コードパート、ベースパートの３つとする。
（２）演奏の進行には楽曲データに沿って自動的に演奏を進行させる自動進行方法が採用されている。
（３）メロディパート、コードパート、及びベースパートの各データは、それぞれ異なるチャンネル（以下ではそれぞれ「メロディチャンネル」、「コードチャンネル」及び「ベースチャンネル」と呼ぶ）のデータとして楽曲データに格納されている。
【００２１】
図５は、上記楽曲データを構成する楽音データの構成を説明する図である。
楽曲データを構成する楽音データは、図５に示すように、演奏上のイベントの内容を示すイベントデータ、及び次に処理すべき楽音データを処理するまでの時間間隔（Δｔ）を示す時間データから構成される。
【００２２】
上記時間間隔Δｔは、テンポによって変更される最小時間間隔を単位として表現されたものである。これは他の時間、或いは時間間隔についても同様である。楽音の発音に係わるイベントデータは、例えばイベントが楽音の発音、及び消音の何れであるかを示すイベント種別、楽音の音高を示す番号（以降「音階番号」）、及びチャンネル番号の各データを有するものである。それにより楽曲データは、イベント（楽音）単位で用意された楽音データをその処理順に並べた形の構成となっている。楽曲を構成する演奏パートにはそれぞれ異なるチャンネルが割り当てられる。その演奏パートの一つであるコード（和音）の演奏用のコードパートでは、コード発音用のイベントデータとして、例えば音階番号の代わりに、コードの種類を示すコード名データ、及びルート（根音）の音高を示す音階番号（ルート音階番号）が挿入されている。楽曲データ、或いは楽音データは、上述したような構成に限定されるものではない。また、楽曲データは、ＲＯＭ２等の不揮発性メモリに用意するのではなく、通信ネットワーク、或いは可搬性の記録媒体を介して取得できるようにすることにより、ＲＡＭ３に格納しても良い。
【００２３】
ＣＰＵ１は、処理すべきタイミングとなったイベントデータから音源システム６に送出すべきコマンド（以降ＭＩＤＩデータを想定する）を生成して送出することで楽音の発音開始、或いは消音を指示する。イベントデータ中にコード名データ、及びルート音階番号が挿入されていた場合には、そのコード名データ、及び音階番号から各コード構成音の音高を特定し、コード構成音毎にＭＩＤＩデータを生成して送出する。処理すべきタイミングは、対象演奏パートでは時間データの他に鍵盤４への操作を考慮して判定し、それ以外の演奏パートでは時間データのみから判定する。それにより、エニーキーモード設定時では、対象演奏パートの楽音はユーザーの演奏に応じて放音させ、それ以外の演奏パートの楽音は自動的に放音させる。
【００２４】
音源システム６は、発音を指示するＭＩＤＩデータをＣＰＵ１から入力した場合、そのＭＩＤＩデータ中の音階番号（ノートナンバー）で指定される音高に応じて、楽音発音用の波形データを生成し、生成した波形データをアナログのオーディオ信号に変換してアンプ回路７に出力する。波形データの生成は、消音を指示するＭＩＤＩデータがＣＰＵ１から送出されて実際に消音させるまでの間、行う。そのような波形データの生成、及び生成した波形データを変換してのオーディオ信号の出力を行うことにより、ＣＰＵ１の指示に従って楽音の放音を可能とさせる。
【００２５】
以降は、図２〜図４、及び図８に示すフローチャートを参照しつつ、エニーキーモード設定時のＣＰＵ１の動作について具体的に説明する。
図２は、メイン処理のフローチャートである。そのメイン処理は、電源の投入後に実行される主な処理を抜粋してその流れを示したものであり、ＲＯＭ２に格納されたプログラムをＣＰＵ１が実行することにより実現される。
【００２６】
先ず、ステップＡ１では、イニシャル処理が行われる。そのイニシャル処理では、各種変数の初期化等が行われる。ステップＡ１の処理の実行後はステップＡ２に移行する。
ステップＡ２〜Ａ５は繰り返しループを形成しており、例えば予め定めた時間間隔で繰り返し実行される。
【００２７】
ステップＡ２では、図３に示す自動演奏処理を実行する。これは、楽曲データを読み込み、演奏者が演奏の対象とする対象演奏パート毎に、その楽曲データが発音を示す楽音の音高を候補音高として設定し、他の演奏パートを自動演奏する処理である。その実行後はステップＡ３に移行する。自動進行方法では、候補音高の設定は、自動演奏の進行に応じて随時、更新する。
【００２８】
ステップＡ３では、図８に示す鍵盤処理を実行する。これは、演奏者の鍵盤４への操作（押鍵や離鍵）に応じて楽音を発音させるための処理である。ここではエニーキーモードが設定された場合に実行される処理を抜粋して図８に示している。その鍵盤処理の実行後、ステップＡ４に移行する。
【００２９】
ステップＡ４では、音源発音処理を実行する。発音、或いは消音させるべき楽音は、ステップＡ２の自動演奏処理、及びステップＡ３の鍵盤処理の実行によって特定され、その特定によって生成されるＭＩＤＩデータはＲＡＭ３に確保された領域に格納される。音源発音処理は、その領域に格納されたＭＩＤＩデータを音源システム６に送出することにより、特定した楽音の発音、或いは消音を音源システム６に対して指示するための処理である。その指示を行い、音源システム６からオーディオ信号がアンプ回路７に出力される結果、楽音がスピーカー８を介して発音される。音源発音処理の実行後、ステップＡ５に移行する。
【００３０】
ステップＡ５では、スイッチ群５への操作に対応することを含むその他の処理を実行し、ステップＡ２に戻る。
設定した候補音高を示す音高データは、それぞれ演奏パート毎にＲＡＭ３上に確保された領域に格納される。図６は、その領域のデータ構成図である。図６（ａ）に示すように、メロディパートで設定した候補音高を示す音高データは候補音高バッファ１に格納される。同様に、コードパートの音高データは図６（ｂ）に示す候補音高バッファ２、ベースパートの音高データは図６（ｃ）に示す候補音高バッファ３にそれぞれ格納される。候補音階バッファ１、３に格納する音高データが一つなのは、メロディパート、ベースパート共に、同時に２音以上、発音させることはないと想定しているためである。候補音階バッファ２に６つの音高データを格納できるようにしたのは、最大で６つの構成音のコードまで対応可能としているためである。
【００３１】
図３は自動演奏処理のフローチャートである。その自動演奏処理は図２のステップＡ２で呼び出される。処理の対象となる楽曲データはＲＯＭ２から読み出してＲＡＭ３に格納したものである。
【００３２】
上述したように楽曲データを構成する楽音データは、イベントの内容を示すイベントデータに、次の楽音データの処理タイミングを示す時間データが付加された構成となっている（図５）。ステップＢ１では、時間データが示す処理タイミングとなったイベントデータの有無を判定し、それにより処理タイミングとなったイベントデータが有ることが判明すると、そのイベントデータの演奏パートが対象演奏パートか否か判定する。そのイベントデータがメロディチャンネル、コードチャンネル、或いはベースチャンネルのものであった場合、判定はＹＥＳとなってステップＢ２に移行し、それらの何れでもない場合には、判定はＮＯとなってステップＢ３に移行する。処理タイミングとなったイベントデータが無いことが判明すると、特には図示していないが、ここで自動演奏処理を終了する。
【００３３】
ステップＢ２では、図４に示す候補音高取り込み処理を実行して自動演奏処理を終了し、図２のメイン処理に戻る。他方のステップＢ３では、演奏対象外の演奏パートの自動演奏を行うための通常再生処理を実行する。それにより、演奏対象でない演奏パートのイベントデータからＭＩＤＩデータを生成し、そのＭＩＤＩデータをＲＡＭ３に確保した領域に格納する。その領域に格納されたデータは、図２のステップＡ４で実際の発音や消音を音源システム６により行わせるために利用される。通常再生処理の実行後は自動演奏処理を終了し、図２のメイン処理に戻る。
【００３４】
図４は候補音高取り込み処理のフローチャートである。候補音高取り込み処理は図３のステップＢ２で呼び出され、図６に示す候補音高バッファ１〜３への音高データの格納を行う処理である。
【００３５】
ステップＢ２−１では、図３のステップＢ１で処理タイミングとなったことを確認したイベントデータがメロディパートのもの（メロディ音として発音される楽音を示すもの）であれば、そのイベントデータが示すイベントの内容（ここでは発音、及び消音の何れか）に応じて、それを構成する音高データの図６（ａ）の候補音高バッファ１への格納、或いは格納された音高データのクリアを行う。そのクリアは「ＮＯＤＡＴＡ」とも表記する。
【００３６】
ステップＢ２−２では、図３のステップＢ１で処理タイミングとなったことを確認したイベントデータがコードパートのものであれば、そのイベントデータ中に挿入されているコード名データ、及びルート音階番号から、コードの各構成音の音高データを特定し、特定した音高データを、イベント種別が示すイベントの内容（ここでは発音、及び消音の何れか）に応じて、図６（ｂ）の候補音高バッファ２に格納するか、或いはそのバッファ２からクリアしてＮＯＤＡＴＡの状態にする。
【００３７】
ステップＢ２−３では、図３のステップＢ１で処理タイミングとなったことを確認したイベントデータがベースパートのもの（ベース音として発音される楽音を示すもの）であれば、そのイベントデータ中のイベント種別が示すイベントの内容（ここでは発音、及び消音の何れか）に応じて、それに挿入された音階番号に対応する音高データの図６（ｃ）の候補音高バッファ３への格納、或いはそのバッファ３からのクリアを行う。その後は候補音高取り込み処理を終了して自動演奏処理に戻る。
【００３８】
図８は鍵盤処理のフローチャートである。鍵盤処理は図２のステップＡ３で呼び出される。上記したように、ここでもエニーキーモード設定時に実行される処理を抜粋して示している。鍵盤４への操作により発音させる楽音は、この鍵盤処理を実行することで決定される。
【００３９】
鍵盤処理では、図６に示す各候補音高バッファ１〜３が参照される。また、図７のＡｎｙＫｅｙバッファおよび前回押鍵バッファを参照し、更新する。ＡｎｙＫｅｙバッファはエニーキーモードでの楽音の発音を管理するためのものであり、図７（ａ）に示すように、実際に演奏者が押鍵しているキーに割り当てられた音高を示す鍵盤番号と、その押鍵に対応して実際に発音している音高と、その発音に使っているチャンネル番号からなる組を１０組分格納できるように、ＲＡＭ３上に確保された領域である。以下では、鍵盤番号を格納するフィールドを鍵盤フィールド、音高（データ）を格納するフィールドを「音高フィールド」、チャンネル番号を格納するフィールドを「チャンネルフィールド」とそれぞれ呼ぶことにする。ＡｎｙＫｅｙバッファでデータが格納されている（ＮＯＤＡＴＡの状態ではない）組の数は、現在押鍵中のキーの数、つまり発音中の楽音の数と一致する。データを１０組分、格納できるようにしたのは、両手の１０本の指で最大１０個のキーを同時に押鍵することが可能なためである。チャンネルフィールドを設けたのは、演奏パート毎に異なる音色で楽音を発音させることもできるようにしたためである。
【００４０】
前回押鍵バッファは、図７（ｂ）に示すように、ＡｎｙＫｅｙバッファと同様の鍵盤フィールドと音高フィールドを備えた、ＲＡＭ３上に確保された領域である。鍵盤フィールドには、前回押鍵されたキーの鍵盤番号、音高フィールドには、その押鍵に対応して発音させた楽音の音高データをそれぞれ格納するようにしている。
【００４１】
先ず、ステップＣ１では、鍵盤４上のキーの状態変化を判定する。演奏者が新たな押鍵、及び離鍵を行っていない場合、状態が変化したキーは存在しないことから、その旨が判定され、鍵盤処理を終了する。演奏者が新たな離鍵を行った場合には、その旨（ＯＦＦ）が判定されてステップＣ２３に移行し、演奏者が新たな押鍵を行った場合には、その旨（ＯＮ）が判定されてステップＣ２に移行する。
【００４２】
ステップＣ２では、ＡｎｙＫｅｙバッファの空き領域を抽出するためのサーチを行う。その後に移行するステップＣ３では、サーチによってＡｎｙＫｅｙバッファの空き領域を抽出できたか否か判定する。その空き領域を抽出できた場合、判定はＹＥＳとなってステップＣ４に移行する。反対に空き領域を抽出できなかった場合には、つまり既に１０個の楽音を発音中の場合には、判定はＮＯとなり、ここで鍵盤処理を終了する。
【００４３】
承知のように、ベースパートは最低音を担当する楽器で演奏される。このことに着目し、本実施形態では、ベースパートの楽音を発音可能な鍵域（ベース鍵域）を設定し、そのベース鍵域への操作に応じてそのベースパートで発音させるべき楽音を発音させるようにしている。ベース鍵域以外は、メロディパート、或いはコードパートの楽音を発音可能な鍵域（メロディ・コード鍵域）としている。このことからステップＣ４では、新たに押鍵されたキーがベース鍵域内のものか否か判定する。演奏者がベース鍵域内のキーを新たに押鍵した場合、判定はＹＥＳとなってステップＣ５に移行し、そうでない場合には、つまりメロディ・コード鍵域内のキーを演奏者が新たに押鍵した場合には、判定はＮＯとなってステップＣ７に移行する。
【００４４】
ステップＣ５では、演奏すべきベース音があるか否か、つまり図６（ｃ）の候補音高バッファ３に音高データが格納されているか否かを判定する。候補音高バッファ３に音高データが格納されている場合、判定はＹＥＳとなってステップＣ６に移行し、そうでない場合には、判定はＮＯとなってステップＣ９に移行する。
【００４５】
ステップＣ６では、候補音高バッファ３に格納されている音高データで楽音が発音中か否か判定する。その音高データが図７（ａ）のＡｎｙＫｅｙバッファのいずれかの音高フィールドに格納されていた場合、その楽音は発音中として、判定はＹＥＳとなってステップＣ９に移行する。それにより、今回の押鍵はコードパートの楽音を発音させるためのものと見なす。そうでない場合には、判定はＮＯとなってステップＣ２１に移行する。
【００４６】
一方ステップＣ７では、発音させるべきメロディパートの楽音があるか否か、つまり図６（ａ）の候補音高バッファ１に音高データが格納されているか否かを判定する。候補音高バッファ１に音高データが格納されている場合、判定はＹＥＳとなってステップＣ８に移行し、その音高データが格納されていない、つまり候補音高バッファ１がＮＯＤＡＴＡの状態であった場合には、判定はＮＯとなってステップＣ９に移行する。
【００４７】
ステップＣ８では、候補音高バッファ１に格納されている音高データで楽音が発音中か否かを判定する。その音高データが図７（ａ）のＡｎｙＫｅｙバッファのいずれかの音高フィールドに格納されていた場合、その楽音は発音中として、判定はＹＥＳとなってステップＣ９に移行する。そうでない場合には、判定はＮＯとなってステップＣ２１に移行する。
【００４８】
ステップＣ９〜Ｃ２０は、今回の押鍵に対してコードパートを対応させて発音する場合の処理である。ステップＣ９への移行は、ベース鍵域内のキーを押鍵してもベースパートに新たに発音させるべき楽音が存在しない場合、或いはメロディ・コード鍵域内のキーを押鍵してもメロディパートに新たに発音させるべき楽音が存在しない場合に行われる。
【００４９】
ステップＣ９では、コードの構成音のうち未発音のものがあるか否かを判定する。候補音高バッファ２に１つ以上の音高データが格納されており、且つそれらのうちで図７（ａ）のＡｎｙＫｅｙバッファの音高フィールドに格納されていないものがある場合、コードの構成音のうち未発音のものがあるとして、判定はＹＥＳとなりステップＣ１０に移行する。候補音高バッファ２に音高データが格納されていない、或いは音高データが１つ以上格納され、且つそのすべてがＡｎｙＫｅｙバッファの音高フィールドに格納されている場合には、未発音の構成音は存在しないとして、判定はＮＯとなりステップＣ１７に移行する。
【００５０】
ステップＣ１０では、今回押鍵されたキーは前回押鍵されたキーより割り当てられた音高が下か否か判定する。前回押鍵したキーより低い音高のキーを演奏者が今回押鍵した場合、つまり前回押鍵バッファの鍵盤フィールドに格納された鍵盤番号より小さい鍵盤番号が割り当てられたキーを演奏者が今回押鍵した場合、判定はＹＥＳとなってステップＣ１４に移行し、そうでない場合には、判定はＮＯとなってステップＣ１１に移行する。
【００５１】
ステップＣ１１では、演奏者が前回の押鍵時よりも高い音高の楽音を発音させようとしたと見なし、候補音高バッファ２に格納された音高データのなかで、ＡｎｙＫｅｙバッファの音高フィールドに対応する音高データが格納されてなく、且つ前回、発音させた構成音の音高データ以上、高音の音高データを探す。次にステップＣ１２では、そのような音高データが有ったか否か判定する。そのような音高データを探し出せた場合、判定はＹＥＳとなってステップＣ２１に移行し、そうでない場合には、判定はＮＯとなってステップＣ１３に移行する。
【００５２】
ステップＣ１３は、コードの構成音に未発音の音が存在するが、その中には前回の押鍵に対応して発音させた構成音の音高データ以上高音の構成音がない場合に実行される。この場合、未発音の構成音をそのまま発音したのでは、前回の押鍵時よりも高音の構成音を発音させようとしている演奏者の意図に応えることはできない。そこで、ステップＣ１３では、未発音の構成音を１オクターブ上げた音高で発音させるよう設定するオクターブＵＰ変換処理を実行する。それにより、演奏者の意図を反映しつつ自然と感じられるようにコードの構成音を発音させる（コードはメロディやベースと異なり、その構成音をオクターブ単位で変換しても（転回しても）演奏の自然さが保たれる）。その後はステップＣ２１に移行する。
【００５３】
ステップＣ１４〜Ｃ１６は、コードの構成音のうち未発音のものがあり、且つ演奏者は前回よりも低音のキーを今回押鍵している場合に実行される。それにより、演奏者が前回の押鍵時よりも低音の構成音を発音させようとしていると見なし、その意図に対応するための処理が行われる。
【００５４】
ステップＣ１４では、候補音高バッファ２に格納された音高データのなかで、ＡｎｙＫｅｙバッファの音高フィールドに音高データが格納されてなく、且つ前回、発音させた構成音の音高データより低音の音高データを探す。次にステップＣ１５では、そのような音高データが有ったか否か判定する。そのような音高データを探し出せた場合、判定はＹＥＳとなってステップＣ２１に移行し、そうでない場合には、判定はＮＯとなってステップＣ１６に移行する。
【００５５】
ステップＣ１６は、コードの構成音に未発音の音が存在するが、その中には前回の押鍵に対応して発音させた構成音の音高データより低音の構成音がない場合に実行される。このことから、ステップＣ１６では、未発音の構成音を１オクターブ下げた音高で発音させるよう設定するオクターブＤＯＷＮ変換処理を実行する。それにより、演奏者の意図を反映しつつ自然と感じられるようにコードの構成音を発音させる。
【００５６】
ステップＣ１７〜Ｃ２０は、演奏すべきコード構成音がすべて発音中の場合に実行される。押鍵操作は、現状よりもさらに多くの楽音を発音させたいという演奏者の意図の表れと見なすことができる。演奏者の意図を実際の楽音の発音に反映させるという観点からは、現在発音されている構成音とは音高が異なる音を押鍵操作に合わせて発音することが好ましいと言える。しかし、ステップＣ１７に移行時には発音すべき構成音は既にすべて発音されているので、演奏の自然さを損なわないような楽音を、現在発音させていない楽音の中から選んで発音する必要がある。
【００５７】
そのような楽音として、本実施形態では、発音中のコードの構成音のうちの任意の１つの音高をオクターブ単位で上または下に変換した楽音を採用している。上か下かの選択は、演奏者の意図を発音に反映させるという観点から、前回と今回で押鍵されたキー間の音高関係により行う。
【００５８】
ステップＣ１７への移行は、発音させるべきコード自体が存在しない場合にも行われる。その場合、特には図示していないが、ステップＣ１７〜Ｃ２０を実行することなく、鍵盤処理を終了するようになっている。
【００５９】
ステップＣ１７では、図６の候補音高バッファ２の音高フィールドに格納された音高データの中から１つの音高データを選択する。その選択後、ステップＣ１８に移行する。
ステップＣ１８では、ステップＣ１０と同様に、今回押鍵されたキーは前回押鍵されたキーより低音のものか否か判定する。前回押鍵したキーより低音のキーを今回、演奏者が押鍵した場合、判定はＹＥＳとなってステップＣ２０に移行し、そうでない場合には、判定はＮＯとなってステップＣ１９に移行する。
【００６０】
ステップＣ１９では、ステップＣ１３と同様に、選択した音高データを対象にオクターブＵＰ変換処理を実行する。その後ステップＣ２１に移行する。他方のステップＣ２０では、ステップＣ１６と同様に、選択した音高データを対象にオクターブＤＯＷＮ変換処理を実行する。その後ステップＣ２１に移行する。
【００６１】
ステップＣ２１に移行時には、発音させる楽音の音高、その楽音の演奏パートが決定している。その音高は、演奏パートがメロディパート、或いはベースパートであれば候補音高であり、コードパートであれば候補音高、それよりも１オクターブ上の音高、或いは１オクターブ下の音高である。ステップＣ２１では、決定した音高、その音高の楽音を発音させる演奏パートから音源システム６に出力すべきコマンド（ここではＭＩＤＩデータ）を生成し、ＲＡＭ３上に確保した領域に格納する。また、ＡｎｙＫｅｙバッファのステップＣ２で探した空き領域の各フィールドに、今回押鍵されたキーの鍵盤番号、候補音高を示す音高データ、及び演奏パートに対応するチャンネル番号をそれぞれ格納する。続くステップＣ２２では、図７（ｂ）の前回押鍵バッファを更新する。つまり、今回押鍵されたキーの鍵盤番号を鍵盤フィールドに格納し、今回の押鍵により実際に発音させた楽音の音高データを音高フィールドに格納する。その後、鍵盤処理を終了する。
【００６２】
演奏者が新たな離鍵を行っていないとステップＣ１で判定した場合に移行するステップＣ２３では、図７（ａ）のＡｎｙＫｅｙバッファをサーチして、鍵盤フィールドの鍵盤番号が今回押鍵されたキーのそれと一致する領域の抽出を行う。次のステップＣ２４では、一致する領域が見つかったか否かを判定する。一致する領域を探し出せた場合、判定はＹＥＳとなってステップＣ２５に移行する。そうでない場合には、判定はＮＯとなり、ここで鍵盤処理を終了する。
【００６３】
ステップＣ２５では、一致する領域が複数あればそのうちの一つを選択し、音高フィールドの音高データ、及びチャンネルフィールドのチャンネル番号を用いて音源システム６に出力するコマンド（ＭＩＤＩデータ）を生成し、ＲＡＭ３上に確保した領域に格納する。また、ＡｎｙＫｅｙバッファのコマンドの生成に用いたデータを格納した領域の各フィールドをクリアしてＮＯＤＡＴＡの状態にする。その後、鍵盤処理を終了する。
【００６４】
このようにして上記ステップＣ２３〜Ｃ２５は、離鍵操作に対応するために実行される。その実行により、鍵の押鍵よって発音を開始させたコードの構成音は、その鍵の離鍵によって消音される。このため、ユーザー（演奏者）はコードの構成音毎に、その発音期間を制御できるようになっている。
【００６５】
図８の鍵盤処理は上記のとおりであるが、その主な特徴と効果は以下のとおりである。
第一に、複数の演奏パートに優先度を設けることにより、演奏者が押鍵したときに優先度の高い対象演奏パートの音から発音することができる。図８では優先度の順に処理を行うことで実現させている。これにより、演奏者がメロディ・コード鍵域を押鍵した際には、より重要なメロディパートがコードパートよりも優先して発音される。
【００６６】
第二に、押鍵された鍵域によって複数の演奏パートの優先度を変更することにより、演奏者の意図が発音に反映される度合いを高めることができる。本実施形態では、ベース鍵域内のキーが押鍵されたか否かによって優先度を変えている。ベース鍵域内のキーが押鍵された場合の優先度はベースパート、コードパートの順であり、メロディパートは無視される。逆に、メロディ・コード鍵域が押鍵された場合の優先度はメロディパート、コードパートの順であり、ベースパートは無視される。
【００６７】
なお、本実施形態では対象演奏パートは３つとなっているが、対象演奏パート数はそれよりも多くとも少なくともよい。例えば、演奏パートがメロディパートとコードパートの２つだけでもよい。その場合、図４のステップＢ２−３、図６（ｃ）の候補音高バッファ３、図８のステップＣ４〜Ｃ６は不要である。
【００６８】
楽曲データについては、データを演奏パート毎に分けて記述されたものを用いているが、パート毎に分けて記述されていないものを用いても良い。その場合、演奏内容を解析して、発音を示す楽音が属する演奏パートを特定すれば良い。また形式も特に限定されるものではない。その楽曲データは、ＲＯＭ２に格納して用意するのではなく、ネットワークや可搬型コンピュータ読み取り可能記憶媒体（メモリカード等）を介して取得するものであっても良い。
【００６９】
演奏パート間の優先度の変更は、ベース鍵域内のキーが押鍵されたか否かにより行っている。その変更は、演奏パート毎に鍵域を設定して行うようにしても良い。その鍵域は固定でも良いが、ユーザーによって変更可能としても良い。
【００７０】
本実施形態では、発音させるべき楽音を全て発音中の状況下で更に押鍵が行われると、その押鍵によって更に楽音を発音させるようにしている。しかし、そのような状況下では、更に楽音を発音させないようにしても良い。つまり押鍵を無視するようにしても良い。
【００７１】
コードを発音させるための全ての押鍵が同時に行われるとは限らない。発音させるコード（の構成音）は常に同じものとは限らない。このことから、前後に押鍵されたキーの音高関係に着目して構成音を選択するのではなく、一定時間の間に押鍵されたキーを全て考慮する形で構成音を選択するようにしても良い。コードによって構成音は異なることから、前のコードの影響を回避するために、前回押鍵バッファは候補音階バッファ２の更新に応じてクリアすることが望ましい。
【００７２】
＜第２の実施形態＞
上記第１の実施形態では、楽曲データに沿って自動的に演奏を進行させる自動進行方法が採用されている。これに対し第２の実施形態は、演奏操作子への操作によって進行させるマニュアル進行方法を採用したものである。それにより、スキルの低い演奏者が自身に合ったペースで演奏を行えるようにしている。
【００７３】
第２の実施形態による演奏装置の構成は基本的に第１の実施形態と同じである。動作も大部分は同じである。このことから、第１の実施形態で付した符号をそのまま用いつつ、第１の実施形態から異なる部分にのみ着目する形で説明を行う。ここでは、対象演奏パートはメロディパート、及びコードパートを想定する。
【００７４】
上記第１の実施形態では、鍵盤４上のキーをベース鍵域、及びメロディ・コード鍵域の２つのグループに分け、ベース鍵域はベースパート、メロディ・コート鍵域はメロディパート、及びコードパートの２つの演奏パートの演奏用に割り当てている。これに対し第２の実施形態では、鍵盤４上のキーをコードパート演奏用のコード鍵域、及びコード鍵域以外をメロディパート演奏用のメロディ鍵域の２つのグループに分けている。それにより、各グループにそれぞれ一つの演奏パートを割り当てている。演奏の進行は、メロディ鍵域への操作に応じて、つまりメロディパートでの楽音の発音に応じて行うようにしている。
【００７５】
上述したような演奏の進行を可能とするために、第２の実施形態では図２に示すメイン処理において、ステップＡ２として実行される自動演奏処理、及びステップＡ３として実行される鍵盤処理が第１の実施形態から異なっている。他のステップでは処理内容は同じか、或いは基本的に同じである。このことから、第２の実施形態で実行される自動演奏処理、及び鍵盤処理について、図９〜図１２を参照して詳細に説明する。
【００７６】
図９は、第２の実施形態で実行される自動演奏処理のフローチャートである。始めに図９を参照して、その自動演奏処理について詳細に説明する。
楽曲データ中で処理対象とする楽音データは、各楽音データを構成する時間データが示す時間間隔Δｔを計時して移行させる。第２の実施形態では、発音すべき楽音が発生した場合に、つまり図６（ａ）の候補音高バッファ１に音高データを新たに格納した場合に、その楽音の発音を指示するメロディ鍵域に対する押鍵が行われるまでの間、時間の計時を一時停止させることにより、メロディパートでの演奏に合わせて、楽曲データ中の楽音データの処理を進行させる。時間の計時は、一定時間間隔（例えば上記最小時間間隔）で発生する割り込み信号により実行されるタイマインタラプト処理、或いはＣＰＵ１に搭載のハードタイマを用いて行うことができる。ここでは、タイマインタラプト処理を用いて時間を計時するものと想定する。そのタイマインタラプト処理は、例えば実行する度に、計時した時間を示す値（以降「タイマ値」と呼ぶ）をインクリメント、或いはデクリメントするものである。そのようなタイマインタラプト処理による時間の計時は、それを実行させる割り込み信号を無効とさせることで停止させることができる。
【００７７】
先ず、ステップＢ１０では、時間を計時中か否か判定する。時間を計時中か否かは、上記タイマインタラプト処理を実行させる割り込み信号が無効となっているか否かの確認、或いは上記タイマ値の更新の有無の確認により判定することができる。そのような確認の結果、時間が計時中であることが判明した場合、判定はＹＥＳとなってステップＢ１１に移行する。そうでない場合には、判定はＮＯとなり、ここで自動演奏処理を終了する。
【００７８】
ステップＢ１１では、直前のイベントデータを処理してから、そのイベントデータに付加された時間データ（図５）が示す時間間隔Δｔが経過したか否か判定する。直前のイベントデータが存在しない（次に処理対象とするイベントデータは先頭に位置する楽音データを構成している）、或いは上記タイマ値がその時間間隔Δｔの経過を示していた場合、判定はＹＥＳとなってステップＢ１２に移行する。それらの何れでもない場合には、判定はＮＯとなり、ここで自動演奏処理を終了し、図２のメイン処理に戻る。
【００７９】
ステップＢ１２では、楽曲データから次の楽音データを読み出し、その楽音データ中の時間データが示す時間間隔Δｔの計時を開始させる。その計時の開始は、上記タイマ値に初期値を設定することで行う。続くステップＢ１３では、読み出した楽音データ中のイベントデータが示すチャンネル（図中「演奏ｃｈ」と表記）の判定を行う。そのチャンネルがメロディパートのもの（メロディチャンネル）であった場合、その旨が判定されてステップＢ１４に移行し、時間の計時を一時停止させた後、自動演奏処理を終了する。
【００８０】
メロディパートの演奏に合わせて演奏全体を進行させることから、図６（ａ）の候補音高バッファ１への音高データの格納は基本的に、後述の鍵盤処理で行うようになっている。その鍵盤処理では、メロディ鍵域への押鍵により、楽曲データ中で処理対象とする楽音データをメロディパートで次の楽音の発音を示す楽音データまで進め、その楽音データから特定される音高データを候補音高バッファ１に格納することにより、次のメロディ鍵域への押鍵への用意を行うようにしている。このため、ステップＢ１４への移行は基本的に、メロディパートで発音タイミングとなった楽音の発音指示をそのタイミング期間内に演奏者が行わなかった場合に生じるようになっている。それにより、メロディパートの楽音の発音指示を演奏者が行うのを待つようにして、演奏者が自身の演奏により、演奏全体の進行を制御できるようにしている。
【００８１】
なお、上記ステップＢ１２で読み出すべき楽音データが無いことが判明すると、特には図示していないが、ここで自動演奏処理を終了するようになっている。そのステップＢ１２、及びステップＢ１１は、図３に示す自動演奏処理ではステップＢ１で行われる。
【００８２】
候補音高バッファ１への音高データの格納は、メロディパートの最初の楽音を発音させるタイミングとなってから行われる。このため、その楽音の発音を示す楽音データはステップＢ１２で読み出される。その楽音データをステップＢ１２で読み出した場合には、ステップＢ１４に移行して、時間の計時を一時停止させると共に、音高データの候補音高バッファ１への格納を併せて行うようになっている。その音高データを格納すべきか否かは、候補音高バッファ１に格納された音高データの有無により判定することができる。
【００８３】
一方、イベントデータが示すチャンネルがコードパートのもの（コードチャンネル）であった場合には、その旨がステップＢ１３で判定されてステップＢ１５に移行する。コードパートのイベントデータには、コードの種類を示すコード名データ、及びルートの音高を示すルート音階番号が挿入されている。このことから、ステップＢ１５では、コード名データ、及びルート音階番号からコードの各構成音の音高データを特定し、特定した音高データを、イベント種別が示すイベントの内容（ここでは発音、及び消音の何れか）に応じて、図６（ｂ）の候補音高バッファ２に格納するか、或いはそのバッファ２からクリアしてＮＯＤＡＴＡの状態にする。自動演奏処理はその後に終了する。
【００８４】
イベントデータが示すチャンネルがメロディパート及びコードパート以外のもの、つまりリズムパートや、リズムパート等のチャンネルであった場合には、その旨がステップＢ１３で判定されてステップＢ１６に移行する。そのステップＢ１６では、イベントデータから音源システム６に送出すべきＭＩＤＩデータを生成しＲＡＭ３に格納する。その後、自動演奏処理を終了する。
【００８５】
図１０は、第２の実施形態で実行される鍵盤処理のフローチャートである。次に図１０を参照して、その鍵盤処理について詳細に説明する。
その鍵盤処理は、第１の実施形態と同様に、エニーキーモード設定時に実行される処理を抜粋して示している。第１の実施形態と同じ、或いは基本的に同じ処理内容のステップには同一の符号を付している（図１２）。それにより、第１の実施形態から異なる部分にのみ着目する形で説明を行う。
【００８６】
先ず、ステップＤ１では、メロディ鍵域で状態が変化したキーがあるか否か判定する。新たな押鍵、或いは離鍵によって状態が変化したキーがメロディ鍵域のものであった場合、判定はＹＥＳとなってステップＤ２に移行し、メロディ鍵域に対する操作に対応するためのメロディ鍵処理を実行した後、鍵盤処理を終了する。状態が変化したキーがコード鍵域のものであった場合には、判定はＮＯとなってステップＤ３に移行し、コード鍵域に対する操作に対応するための伴奏鍵処理を実行した後、鍵盤処理を終了する。新たに押鍵、或いは離鍵されたキーが存在しない場合には、その旨が判定され、ここで鍵盤処理を終了する。
【００８７】
図１１は、上記ステップＤ２として実行されるメロディ鍵処理のフローチャートである。次に図１１を参照して、そのメロディ鍵処理について詳細に説明する。
先ず、ステップＥ１では、状態の変化がキーへの押鍵によるものか否か判定する。演奏者がキーを新たに押鍵した場合、その旨を示す情報が鍵盤４からＣＰＵ１に通知されることから、判定はＹＥＳとなってステップＥ２に移行し、そうでない場合には、判定はＮＯとなってステップＥ６に移行し、離鍵された鍵への押鍵によって発音させている楽音の消音を指示するＭＩＤＩデータを作成しＲＡＭ３に格納した後、メロディ鍵処理を終了する。
【００８８】
ステップＥ２では、図６（ａ）の候補音高バッファ１に格納された音高データを用いて楽音の発音を指示するＭＩＤＩデータを生成しＲＡＭ３に格納する。続くステップＥ３では、楽曲データ中で処理対象とする楽音データを、メロディパートで次の楽音の発音を示す楽音データまで早送りし（進め）、読み出す。次のステップＥ４では、時間の計時が一時停止中であればその計時を再開、つまりタイマインタラプト処理を実行（起動）させる割り込み信号を有効とさせる。その後はステップＥ５に移行し、読み出した楽音データ中のイベントデータから特定される音高データを候補音高バッファ１に格納し、上記タイマ値に初期値を設定してから鍵盤処理を終了する。
【００８９】
このようにして、メロディ鍵域への押鍵により、次にメロディパートで発音させるべき楽音の音高データが候補音高バッファ１に格納され、演奏箇所はその楽音の発音開始タイミングに変更される。それにより、メロディパートでの演奏に合わせて演奏全体の進行が管理される。
【００９０】
図１２は、上記ステップＤ３として実行される伴奏鍵処理のフローチャートである。最後に図１２を参照して、その伴奏鍵処理について詳細に説明する。この伴奏鍵処理では、第１の実施形態（図８）と同じ、或いは基本的に同じ処理内容のステップには同一の符号を付している。それにより、第１の実施形態から異なる部分にのみ着目して説明する。
【００９１】
先ず、ステップＦ１では、状態の変化がキーへの押鍵によるものか否か判定する。演奏者がキーを新たに押鍵した場合、その旨を示す情報が鍵盤４からＣＰＵ１に通知されることから、判定はＹＥＳとなってステップＣ２に移行し、そうでない場合には、判定はＮＯとなってステップＣ２３に移行する。
【００９２】
第２の実施形態では、ステップＣ３の処理の実行後にステップＣ９に移行する。ステップＣ３、或いはＣ２４でのＮＯの判定、ステップ２２、或いはＣ２５の処理の実行により、伴奏鍵処理を終了する。
【００９３】
＜第３の実施形態＞
上記第２の実施形態では、メロディ鍵域の任意のキーを演奏者が押鍵することにより、メロディパートで発音させるべき楽音を発音させるようにしている。これに対し第３の実施形態は、メロディパートで発音させるべき楽音の音高に対応するキーの押鍵によりその楽音を発音させるようにしたものである。それにより、演奏者が自身に合ったペースでの演奏を行えるようにしつつ、正しいキーの押鍵を学習できるようにさせている。
【００９４】
第３の実施形態による演奏装置の構成も第２の実施形態と同様に、基本的に第１の実施形態と同じである。動作も大部分は同じである。このことから、第１の実施形態で付した符号をそのまま用いつつ、第１或いは第２の実施形態から異なる部分にのみ着目する形で説明を行う。ここでも第２の実施形態と同様に、対象演奏パートはメロディパート、及びコードパートを想定する。
【００９５】
上記第２の実施形態では、鍵盤４上のキーをコードパート演奏用のコード鍵域、及びコード鍵域以外をメロディパート演奏用のメロディ鍵域の２つのグループに分け、各グループにそれぞれ一つの演奏パートを割り当てている。これに対し第３の実施形態では、メロディパートの演奏では正しいキーの押鍵を演奏者に要求することから、そのキーのみをメロディ演奏用とし、それ以外をコード演奏用としている。演奏の進行は、メロディ鍵域への正しいキーへの押鍵に応じて行うようにしている。メロディ演奏用のキーを通常の演奏で操作すべきとする正しいキーにのみ限定することから、演奏者にとっては鍵域を考慮した演奏を行う必要性が回避される。演奏の進行の基準となる演奏パート（メロディパート）用に割り当てるキー数は必要最小限となることから、つまり他の演奏パート用に割り当て可能なキー数はより多くなることから、他の演奏パートでの演奏における自由度がより高くなる、キーを割り当て可能な演奏パート数がより多くなる、といった利点もある。
【００９６】
上述したような演奏の進行を可能とするために、第３の実施形態では図２に示すメイン処理において、ステップＡ３として実行される鍵盤処理が第２の実施形態から異なっている。他のステップでは処理内容は同じか、或いは基本的に同じである。このことから、第３の実施形態で実行される鍵盤処理についてのみ、図１３を参照して詳細に説明する。その図１３は、第３の実施形態で実行される鍵盤処理のフローチャートである。その鍵盤処理は、第１及び第２の実施形態と同様に、エニーキーモード設定時に実行される処理を抜粋して示している。第１の実施形態と同じ、或いは基本的に同じ処理内容のステップには同一の符号を付している。
【００９７】
先ず、ステップＧ１では、鍵盤４上のキーの状態変化を判定する。演奏者が新たな押鍵、及び離鍵を行っていない場合、状態が変化したキーは存在しないことから、その旨が判定され、ここで鍵盤処理を終了する。演奏者が新たな離鍵を行った場合には、その旨（ＯＦＦ）が判定されてステップＧ８に移行する。演奏者が新たな押鍵を行った場合には、その旨（ＯＮ）が判定されてステップＧ２に移行する。
【００９８】
ステップＧ２では、押鍵されたキーは図６（ａ）の候補音高バッファ１に格納された音高データに対応するものか否か判定する。メロディパートで次の楽音の発音指示のために押鍵すべきキーを演奏者が正しく押鍵した場合、判定はＹＥＳとなってステップＧ３に移行し、そうでない場合には、判定はＮＯとなってステップＣ２に移行する。それにより、コード演奏用のキーが押鍵されたと見なし、その押鍵に対応するための処理を実行する。一方、ステップＧ３〜Ｇ６の処理内容については、図１１のステップＥ２〜Ｅ５と同じであるため、説明を省略する。
【００９９】
一方、上記ステップＧ８では、離鍵されたキーがメロディパートで発音中の楽音の発音を指示したものか否か判定する。その楽音をそのキーへの押鍵によって発音させていた場合、判定はＹＥＳとなってステップＧ９に移行し、その楽音の消音を指示するＭＩＤＩデータを生成してＲＡＭ３に格納した後、鍵盤処理を終了する。そうでない場合には、判定はＮＯとなってステップＣ２３に移行する。
【０１００】
なお、第３の実施形態では、第２の実施形態と同様に、メロディパートでの楽音の発音指示により、演奏箇所をメロディパートで次に発音させるべき楽音の位置に進め、楽曲データ中で処理対象とする楽音データをその楽音の発音を示す楽音データに移行させるようにしているが、そのように演奏を進行させなくとも良い。例えばメロディパートでの楽音の発音指示により、その楽音の発音を示す楽音データ以降の処理を進めるようにしても良い。
【０１０１】
＜第４の実施形態＞
上記第２及び第３の実施形態では、鍵盤４への操作により演奏を進行させるようにしている。これに対し第４の実施形態は、鍵盤４以外の演奏操作子への操作により演奏を進行させるようにしたものである。
【０１０２】
第４の実施形態による演奏装置の構成も第２及び第３の実施形態と同様に、基本的に第１の実施形態と同じである。動作も大部分は同じである。このことから、第１の実施形態で付した符号をそのまま用いつつ、第１、第２、或いは第３の実施形態から異なる部分にのみ着目する形で説明を行う。ここでは対象演奏パートは、メロディパート、コードパート、ベースパート、及びリズムパートを想定する。
【０１０３】
第４の実施形態では、鍵盤４（上のキー）以外の演奏操作子として、演奏者が足で操作するペダルを想定している。そのために第４の実施形態による演奏装置は、図１に示すように、ペダル２０用のインターフェース１０を備えている。エニーキーモード設定時には、ペダル２０はそれに割り当てた対象演奏パートの音の発音指示用の演奏操作子として機能させるようにしている。その対象演奏パートはリズムパートとし、演奏の進行はペダル２０への操作に応じて行うようにしている。そのペダル２０を演奏操作子として用いるようにしたことにより、演奏者が自身に合ったペースでより多くの演奏パートの演奏を容易に行えるようにしている。
【０１０４】
上述したような演奏の進行を可能とするために、第４の実施形態では図２に示すメイン処理において、ステップＡ２として実行される自動演奏処理、及びステップＡ５として実行されるその他処理が第１の実施形態から異なっている。他のステップでは処理内容は同じか、或いは基本的に同じである。このことから、第４の実施形態で実行される鍵盤処理、及びその他処理についてのみ詳細に説明する。
【０１０５】
図１４は、第４の実施形態で実行される自動演奏処理のフローチャートである。始めに図１４を参照して、その自動演奏処理について詳細に説明する。その図１４では、第２の実施形態（図９）と同じ、或いは処理内容が同じものには同一の符号を付している。
【０１０６】
第４の実施形態では、ステップＢ１２の処理の実行後はステップＨ１に移行する。そのステップＨ１では、読み出した楽音データ中のイベントデータが示すチャンネルの判定を行う。そのチャンネルがリズムパートのもの（リズムチャンネル）であった場合、その旨が判定されてステップＨ２に移行し、時間の計時を一時停止させた後、自動演奏処理を終了する。イベントデータが示すチャンネルがメロディパート、コードパート、或いはベースパートのものであった場合には、その旨がステップＨ１で判定されてステップＢ２に移行し、図４に示す候補音高取り込み処理を実行した後、自動演奏処理を終了する。その候補音高取り込み処理の内容は第１の実施形態と同じであることから、図２に示すメイン処理内でステップＡ３として実行される鍵盤処理の内容も第１の実施形態と同じとなっている。
【０１０７】
リズムパートでリズム音を発音させるためのデータ（以降「リズム音データ」）は、他の対象演奏パートであるメロディパートやコードパート等と同様に、そのリズムパート用にＲＡＭ３に確保した領域である領域（以降「リズムバッファ」と呼ぶ）に格納するようになっている。リズムパートの演奏に合わせて演奏全体を進行させることから、そのリズムバッファへのリズム音データの格納は基本的に、別のサブルーチン処理で行うようになっている。そのサブルーチン処理では、第２の実施形態と同様に、ペダル２０の押下により、楽曲データ中で処理対象とする楽音データをリズムパートで次のリズム音の発音を示す楽音データまで進め、その楽音データから特定されるリズム音データをリズムバッファに格納することにより、次のペダル２０の押下への用意を行うようにしている。このため、ステップＨ３への移行は基本的に、リズムパートで発音タイミングとなったリズム音の発音指示をそのタイミング期間内に演奏者が行わなかった場合に生じるようになっている。それにより、リズムパートの楽音の発音指示を演奏者が行うのを待つようにして、演奏者が自身の演奏により、演奏全体の進行を制御できるようにしている。
【０１０８】
リズムバッファへのリズム音データの格納は、リズムパートの最初のリズム音を発音させるタイミングとなってから行われる。このため、そのリズム音の発音を示す楽音データはステップＢ１２で読み出される。その楽音データをステップＢ１２で読み出した場合には、ステップＨ３に移行して、時間の計時を一時停止させると共に、リズム音データのリズムバッファへの格納を併せて行うようになっている。そのリズム音データを格納すべきか否かは、リズムバッファに格納されたリズム音データの有無により判定することができる。
【０１０９】
第４の実施形態では、インターフェース１０から通知された情報を解析してペダル２０の状態変化を判定し、その判定結果に対応するためのペダル処理をその他処理内で実行するようになっている。それにより、その他処理が第１の実施形態から異なっている。次にそのペダル処理について詳細に説明する。
【０１１０】
そのペダル処理で実行する処理の流れは、図１１に示すメロディ鍵処理と基本的に同じである。このことから図１１を参照し、各ステップで実行される処理の内容について具体的に説明することとする。
【０１１１】
ペダル処理では、ステップＥ１において、インターフェース１０から通知された情報を解析し、ペダル２０に押下による状態の変化が生じたか否か判定する。演奏者がペダル２０を新たに押下した場合、その旨を示す情報がインターフェース１０からＣＰＵ１に通知されることから、判定はＹＥＳとなってステップＥ２に移行し、そうでない場合には、つまり押下の解除による状態の変化が生じた場合には、判定はＮＯとなってステップＥ６に移行し、ペダル２０の押下によって発音させているリズム音の消音を指示するＭＩＤＩデータを作成しＲＡＭ３に格納した後、ペダル処理を終了する。
【０１１２】
ステップＥ２では、上記リズムバッファに格納されたリズム音データを用いてリズム音の発音を指示するＭＩＤＩデータを生成しＲＡＭ３に格納する。続くステップＥ３では、楽曲データ中で処理対象とする楽音データを、リズムパートで次のリズム音の発音を示す楽音データまで早送りし（進め）、読み出す。次のステップＥ４では、時間の計時が一時停止中であればその計時を再開、つまりタイマインタラプト処理を実行（起動）させる割り込み信号を有効とさせる。その後はステップＥ５に移行し、読み出した楽音データ中のイベントデータから特定されるリズム音データをリズムバッファに格納し、上記タイマ値に初期値を設定してから鍵盤処理を終了する。
【０１１３】
このようにして、ペダル処理では第２の実施形態におけるメロディ鍵処理と同様の処理が各ステップで実行される。それにより、ペダル２０を操作して行われるリズムパートでの演奏に合わせて演奏全体の進行が管理される。
【０１１４】
なお、第２〜第４の実施形態では、着目する演奏パートの演奏に合わせて演奏全体（他の演奏パート）の進行を制御するようにしているが、一つ以上の演奏操作子を演奏の進行用とし、その演奏操作子への操作に応じて、予め定めた単位演奏分、進行させるようにしても良い。その単位演奏分は、演奏する楽曲に応じて演奏者に設定させても良いが、楽曲データの内容を解析して自動的に設定させるようにしても良い。着目する演奏パート、及び他の演奏対象とする演奏パートについては限定されるものではなく、任意に設定可能としても良い。
【０１１５】
本実施形態（第１〜第４の実施形態）による演奏装置は、ＣＰＵ１に実行させるプログラムをＲＯＭ２に格納し実行させることで実現させているが、そのようなプログラムは、ＣＤ−ＲＯＭ、ＤＶＤ、或いは着脱自在なフラッシュメモリ等の記録媒体に記録させて配布しても良い。公衆網等の通信ネットワークを介して、そのプログラムの一部、若しくは全部を配信するようにしても良い。そのようにした場合には、ユーザーはプログラムを取得して、演奏装置として用いることが可能なコンピュータにロードすることにより、そのコンピュータに本発明を適用させることができる。このことから、記録媒体は、プログラムを配信する装置がアクセスできるものであっても良い。そのコンピュータは演奏装置を構成するものであっても良いが、鍵盤４のような複数の演奏操作子を備えた装置を接続できるもの、つまり行われた演奏操作の内容を示すデータを受信できるものであっても良い。
【図面の簡単な説明】
【０１１６】
【図１】本実施形態による演奏装置の構成図である。
【図２】メイン処理のフローチャートである。
【図３】自動演奏処理のフローチャートである。
【図４】候補音高取り込み処理のフローチャートである。
【図５】楽曲データを構成する楽音データの構成を説明する図である。
【図６】各種候補音高バッファのデータ構成図である。
【図７】ＡｎｙＫｅｙバッファおよび前回押鍵バッファのデータ構成図である。
【図８】鍵盤処理のフローチャートである。
【図９】第２の実施形態で実行される自動演奏処理のフローチャートである。
【図１０】第２の実施形態で実行される鍵盤処理のフローチャートである。
【図１１】メロディ鍵処理のフローチャートである。
【図１２】伴奏鍵処理のフローチャートである。
【図１３】第３の実施形態で実行される鍵盤処理のフローチャートである。
【図１４】第４の実施形態で実行される自動演奏処理のフローチャートである。
【符号の説明】
【０１１７】
１  ＣＰＵ
２  ＲＯＭ
３  ＲＡＭ
４  鍵盤
５  スイッチ群
６  音源システム
７  アンプ回路
８  スピーカー
９  バス
１０  インターフェース
２０  ペダル
【図１】
2008020875.tif 000003
【図２】
2008020875.tif 000004
【図３】
2008020875.tif 000005
【図４】
2008020875.tif 000006
【図５】
2008020875.tif 000007
【図６】
2008020875.tif 000008
【図７】
2008020875.tif 000009
【図８】
2008020875.tif 000010
【図９】
2008020875.tif 000011
【図１０】
2008020875.tif 000012
【図１１】
2008020875.tif 000013
【図１２】
2008020875.tif 000014
【図１３】
2008020875.tif 000015
【図１４】
2008020875.tif 000016