JP4978177B2 - 演奏装置、演奏実現方法およびプログラム - Google Patents

Description

本発明は、演奏者が演奏を行うための複数の演奏操作子を備えた演奏装置に関する。

電子鍵盤楽器等の演奏用の演奏操作子を備えた演奏装置のなかには、演奏者（ユーザー）が操作子を操作したタイミングに合わせて、その操作子の種類に係わらず、楽曲データが示す発音順序に従って楽音を発音させる機能を搭載したものがある。その機能を用いた演奏では、どの演奏操作子を操作しても、楽曲データが示す演奏内容に従って楽曲を演奏することができる。このことから、その演奏は主に操作子を操作すべきタイミングの練習用などに利用されている。発音させる楽音は楽曲データに依存し、操作される演奏操作子に依存しないことから、つまり、どの操作子を操作しても演奏を行えることから、その機能については以降「エニーキー機能」と呼ぶことにする。

上記エニーキー機能を用いた演奏では、楽曲の演奏内容を示す楽曲データは、演奏操作子への操作によって発音させる楽音の設定（選択）に利用される。演奏を進行させる方法は、演奏操作子への操作によって進行させる方法（以降「マニュアル進行方法」と呼ぶ）、楽曲データに沿って自動的に進行させる方法（以降「自動進行方法」と呼ぶ）に大別することができる。演奏操作子への操作によって発音される楽音は、マニュアル進行方法では操作子に対してそれまでに行った操作回数に応じて選択され、自動進行方法では操作子を操作したタイミングに応じて選択される。

エニーキー機能を搭載した演奏装置では、一つの演奏操作子への１回の操作によって発音させる楽音は一つとし、同時に発音中とさせる楽音数は一つのみとしているのが普通である。しかし、エニーキー機能を搭載した従来の演奏装置のなかには、特許文献１に記載されたように、複数の楽音を同時に発音できるようにしたものがある。演奏操作子については以降「キー」と表記する。

特許文献１に記載の従来の演奏装置では、演奏者が演奏すべき演奏パートとしてコードパートを想定し、コード（和音）の構成音の各音高を候補音高として設定する。候補音高の設定は、演奏の進行に応じて随時、更新するものである。演奏者がキーを操作すると、そのキーに割り当てられた音高に応じて、候補音高の中から選択した音高またはそれをオクターブ単位で高く若しくは低く変換（転回）した音高で楽音を発音させる。そのようにして、キーへの操作により、構成音数の楽音を同時に発音させることを可能とさせている。

発音させる楽音の選択は、具体的には以下のように行われる。
キーが操作されると先ず、候補音高の中に未発音のものがあるか否か確認する。その結果、未発音のものが確認できれば、今回、操作されたキーの音高が前回、操作されたキーの音高よりも高いか否か確認し、それによって前回、操作されたキーの音高より高い音高のキーを今回、操作したことが判明すると、前回の操作で発音させた楽音の音高より高い未発音の候補音高を探し、そのような候補音高があれば、その候補音高を選択する。逆になければ、未発音の候補音高を一つ選択し、それを１オクターブ上に変換した音高で楽音を発音させる。

候補音高がすべて発音中であっても、前回操作されたキーと今回操作のキーの音高を比較する。それにより、前回操作されたキーよりも高い音高のキーを演奏者が今回操作した場合は、発音中の候補音高のうちの１つを１オクターブ高く変換した音高で楽音をさらに発音させる。逆に今回操作されたキーの音高が前回操作されたキーの音高よりも低いことを確認した場合には、音高の高低を逆にして同様の選択が行われる。

このようにして特許文献１に記載の従来の演奏装置では、楽曲データが示すコードパートの演奏内容の演奏をできるようにしつつ、その演奏内容を演奏者が実際に行った演奏操作に応じて変更、つまり演奏者が実際に行った演奏操作を演奏内容に反映するようにしている。それにより、演奏者にとって自然と感じられる内容の演奏も行えるようになっている。

演奏者は複数の演奏パートを演奏する場合がある。例えば鍵盤楽器では、メロディパートとコードパートを演奏することも多い。このようなこともあり、楽曲データを利用した演奏でも、複数のパートの演奏を行えることを望む人も少なくないと思われる。それにより、そのような演奏を行える演奏装置を提供することも重要と考えられる。

周知のようにコードは、協和音と不協和音とに大別される。協和音は、協和音程のみから成るコード、不協和音は、協和しない状態の構成音が２つ以上、存在するコードである。「協和」とは、２音以上の楽音が快く調和して響く状態にあることを指す用語であり、その状態が実現される音程が「協和音程」と呼ばれる。協和音程は、調和の度合い（協和度）によって、更に「完全協和音程」と「不完全協和音程」とに分けられる。「不協和」は、「協和」しない状態にあることを指す用語であり、その状態が実現される音程は「不協和音程」と呼ばれる。

協和度は、音程を構成する２音の振動数の整数で表す比が簡単なほど強いとされる。それにより、完全１、８、５及び４度は完全協和音程とされ、長短３及び６度は不完全協和音程とされている。それら以外の音程は何れも不協和音程とされる。従って、短七度、或いは長七度の不協和音程を持つ七の和音（セブンス）は何れの種類も不協和和音である。

不協和は協和度の漸減によって到達する状態である。それにより、「協和」と「不協和」は対概念ではあるが、その間には相対的関連性が存在し、その境界を明確に規定するのは困難なのが実情である。

協和音程の響きは安定であるが、不協和音程の響きは不安定である。不安定であるために、その響きは聞く人に緊張感を与える。それにより不協和音では、他の構成音と不協和音程の関係を持つ構成音（緊張感を与える楽音であることから以降、便宜的に「テンションノート」と呼ぶ）を発音させる順序（タイミング）により、人に与える印象（演奏内容）を大きく変化させる可能性がある。そのように不協和音では構成音の発音順序が演奏内容に大きく影響する可能性があることから、より所望の演奏内容を実現できるようにするためには、不協和音ではテンションノートを含む構成音の発音順序を演奏者（ユーザー）が制御できるようにすることも重要と考えられる。
特開２００４−１７７８９３号公報

本発明の課題は、不協和音における構成音の発音順序を演奏者が制御できる演奏装置を提供することにある。

本発明の演奏装置は、演奏者が演奏を行うための複数の演奏操作子を備えた演奏装置において、コードを発音させるコードパートを少なくとも示す楽曲データを記憶する楽曲データ記憶手段と、前記演奏の進行に応じて随時、前記楽曲データ記憶手段が記憶した楽曲データが示すコードパートにおいて、コードの各構成音の音高をそれぞれ、該コードを不協和音とさせる第１の候補音高、及び該第１の候補音高以外の第２の候補音高のうちの何れかに分類、設定する音高設定手段と、前記複数の演奏操作子を第１及び第２のグループの２つのグループに分け、該複数の演奏操作子のなかで前記第１のグループに属する演奏操作子への操作によって前記第１の候補音高を選択するとともに前記第２のグループに属する演奏操作子への操作によって前記第２の候補音高を選択し、該選択した候補音高により楽音を楽音発生装置により発音させる発音制御手段と、を具備する。

なお、前記複数の演奏操作子が鍵盤を構成する複数の鍵であった場合、前記第１、及び第２のグループに属する演奏操作子はそれぞれ黒鍵、及び白鍵である、ことが望ましい。

本発明の演奏実現方法は、コードを発音させるコードパートを少なくとも示す楽曲データを記憶する楽曲データ記憶手段、及び演奏者が演奏を行うための複数の演奏操作子を備えた演奏装置を用いることによる演奏を実現させるための方法であって、前記演奏の進行に応じて随時、前記楽曲データ記憶手段が記憶した楽曲データが示すコードパートにおいて、コードの各構成音の音高をそれぞれ、該コードを不協和音とさせる第１の候補音高、及び該第１の候補音高以外の第２の候補音高のうちの何れかに分類、設定し、前記複数の演奏操作子を第１及び第２のグループの２つのグループに分け、該複数の演奏操作子のなかで前記第１のグループに属する演奏操作子への操作によって前記第１の候補音高を選択するとともに前記第２のグループに属する演奏操作子への操作によって前記第２の候補音高を選択し、該選択した候補音高により楽音を楽音発生装置により発音させることで前記演奏を実現させる。

本発明のプログラムは、コードを発音させるコードパートを少なくとも示す楽曲データを記憶する楽曲データ記憶手段、及び演奏者が演奏を行うための複数の演奏操作子を備えた演奏装置として用いられるコンピュータに、前記演奏の進行に応じて随時、前記楽曲データ記憶手段が記憶した楽曲データが示すコードパートにおいて、コードの各構成音の音高をそれぞれ、該コードを不協和音とさせる第１の候補音高、及び該第１の候補音高以外の第２の候補音高のうちの何れかに分類、設定する音高設定機能と、前記複数の演奏操作子を第１及び第２のグループの２つのグループに分け、該複数の演奏操作子のなかで前記第１のグループに属する演奏操作子への操作によって前記第１の候補音高を選択するとともに前記第２のグループに属する演奏操作子への操作によって前記第２の候補音高を実現させる。

本発明では、楽曲データが演奏内容を示す演奏パートの演奏を演奏者が行う場合に、複数の演奏操作子を複数のグループに分け、演奏パートで楽曲データが表す楽音の音高を候補音高として、演奏の進行に応じて随時、設定する。その設定は、複数の演奏操作子に対するグループ分けに合わせた分類をしつつ行う。つまりグループとの対応関係を合わせて設定しながら行う。それにより、候補音高を一つ以上、設定している状況下で複数の演奏操作子のうちの何れかが操作された場合に、その操作された演奏操作子の属するグループに基づいて、その候補音高のなかから候補音高を選択し、選択した候補音高により楽音を楽音発生装置により発音させる。

複数の演奏操作子のグループ分けに合わせて候補音高を分類することから、演奏者にとっては、操作する演奏操作子を通して、候補音高の分類間での選択を任意に行えるようになる。演奏パートがコードを発音させるコードパートであった場合には、コードの構成音を不協和音とさせる構成音であるテンションノートか否かにより分類すれば、テンションノート、及びそれ以外の構成音とに分けての選択を演奏者は任意に行えるようになる。それにより、不協和音における構成音の発音順序を演奏者が制御できることとなる。

以下、本発明の実施の形態について、図面を参照しながら詳細に説明する。
＜第１の実施形態＞
図１は、第１の実施形態による演奏装置の構成図である。本実施形態による演奏装置は鍵盤楽器であり、全体を制御するＣＰＵ１と、ＣＰＵ１が実行するプログラム、各種制御用データ、および演奏対象の楽曲データ等を格納したＲＯＭ（Read Only Memory）２と、ＣＰＵ１がワークに用いるＲＡＭ（Random Access Memory）３と、複数のキー（演奏操作子である鍵）を有する鍵盤４と、各種操作子を有するスイッチ群５と、例えばＭＩＤＩ（Musical Instrument Digital Interface）データで発音が指示された楽音の波形データを生成し、その波形データをＤ／Ａ変換して得られるオーディオ信号を出力する音源システム６と、音源システム６から出力されたオーディオ信号を増幅して出力するアンプ回路７と、アンプ回路７から入力したオーディオ信号により楽音を放音するスピーカー８と、ＣＰＵ１、ＲＯＭ２、ＲＡＭ３、鍵盤４、スイッチ群５、音源システム６を互いに接続するバス９と、を備えている。

ＣＰＵ１はＲＯＭ２に記録されているプログラムを実行することにより、演奏者（ユーザー）が鍵盤４やスイッチ群５に対して行った操作に応じた制御を行う。鍵盤４への操作が行われた場合には、操作されたキーに割り当てられている音高の楽音の発音指示を音源システム６に対して行う。その指示に従って音源システム６が波形データを生成してオーディオ信号をアンプ回路７に出力する結果、その楽音がスピーカー８により発音される。それにより、音源システム６は楽音発生装置に相当する。スイッチ群５への操作が行われた場合には、操作が行われた操作子に応じて、楽曲データの指定を含む各種設定を行う。その楽音発生装置は、演奏装置に搭載されていないものであっても良い。

スイッチ群５への操作により設定可能なモードとして、楽曲データから特定される音高の楽音を鍵盤４へのキー操作により発音させるもの（以降「エニーキーモード」）がある。そのエニーキーモードは本発明に係わるモードである。このことから便宜的に以降、特に断らない限り、そのエニーキーモードが設定されていることを前提に説明する。ここでは、そのエニーキーモードで用いられる楽曲データは選択されているものとする。また、以下のことも前提とする。
（１）演奏者が演奏すべき演奏パート（以降「対象演奏パート」）は、メロディパート、コードパート、ベースパートの３つとする。
（２）演奏の進行には楽曲データに沿って自動的に演奏を進行させる自動進行方法が採用されている。
（３）メロディパート、コードパート、及びベースパートの各データは、それぞれ異なるチャンネル（以下ではそれぞれ「メロディチャンネル」、「コードチャンネル」及び「ベースチャンネル」と呼ぶ）のデータとして楽曲データに格納されている。

図５は、上記楽曲データを構成する楽音データの構成を説明する図である。
楽曲データを構成する楽音データは、図５に示すように、演奏上のイベントの内容を示すイベントデータ、及び次に処理すべき楽音データを処理するまでの時間間隔（Δｔ）を示す時間データから構成される。

上記時間間隔Δｔは、テンポによって変更される最小時間間隔を単位として表現されたものである。これは他の時間、或いは時間間隔についても同様である。楽音の発音に係わるイベントデータは、例えばイベントが楽音の発音、及び消音の何れであるかを示すイベント種別、楽音の音高を示す番号（以降「音階番号」）、及びチャンネル番号の各データを有するものである。それにより楽曲データは、イベント（楽音）単位で用意された楽音データをその処理順に並べた形の構成となっている。楽曲を構成する演奏パートにはそれぞれ異なるチャンネルが割り当てられる。その演奏パートの一つであるコード（和音）の演奏用のコードパートでは、コード発音用のイベントデータとして、例えば音階番号の代わりに、コードの種類を示すコード名データ、及びルート（根音）の音高を示す音階番号（ルート音階番号）が挿入されている。楽曲データ、或いは楽音データは、上述したような構成に限定されるものではない。また、楽曲データは、ＲＯＭ２等の不揮発性メモリに用意するのではなく、通信ネットワーク、或いは可搬性の記録媒体を介して取得できるようにすることにより、ＲＡＭ３に格納しても良い。

ＣＰＵ１は、処理すべきタイミングとなったイベントデータから音源システム６に送出すべきコマンド（以降ＭＩＤＩデータを想定する）を生成して送出することで楽音の発音開始、或いは消音を指示する。イベントデータ中にコード名データ、及びルート音階番号が挿入されていた場合には、そのコード名データ、及び音階番号から各コード構成音の音高を特定し、コード構成音毎にＭＩＤＩデータを生成して送出する。処理すべきタイミングは、対象演奏パートでは時間データの他に鍵盤４への操作を考慮して判定し、それ以外の演奏パートでは時間データのみから判定する。それにより、エニーキーモード設定時では、対象演奏パートの楽音はユーザーの演奏に応じて放音させ、それ以外の演奏パートの楽音は自動的に放音させる。

音源システム６は、発音を指示するＭＩＤＩデータをＣＰＵ１から入力した場合、そのＭＩＤＩデータ中の音階番号（ノートナンバー）で指定される音高に応じて、楽音発音用の波形データを生成し、生成した波形データをアナログのオーディオ信号に変換してアンプ回路７に出力する。波形データの生成は、消音を指示するＭＩＤＩデータがＣＰＵ１から送出されて実際に消音させるまでの間、行う。そのような波形データの生成、及び生成した波形データを変換してのオーディオ信号の出力を行うことにより、ＣＰＵ１の指示に従って楽音の放音を可能とさせる。

以降は、図２〜図４、及び図８に示すフローチャートを参照しつつ、エニーキーモード設定時のＣＰＵ１の動作について具体的に説明する。
図２は、メイン処理のフローチャートである。そのメイン処理は、電源の投入後に実行される主な処理を抜粋してその流れを示したものであり、ＲＯＭ２に格納されたプログラムをＣＰＵ１が実行することにより実現される。

先ず、ステップＡ１では、イニシャル処理が行われる。そのイニシャル処理では、各種変数の初期化等が行われる。ステップＡ１の処理の実行後はステップＡ２に移行する。
ステップＡ２〜Ａ５は繰り返しループを形成しており、例えば予め定めた時間間隔で繰り返し実行される。

ステップＡ２では、図３に示す自動演奏処理を実行する。これは、楽曲データを読み込み、演奏者が演奏の対象とする対象演奏パート毎に、その楽曲データが発音を示す楽音の音高を候補音高として設定し、他の演奏パートを自動演奏する処理である。その実行後はステップＡ３に移行する。自動進行方法では、候補音高の設定は、自動演奏の進行に応じて随時、更新する。

ステップＡ３では、図８に示す鍵盤処理を実行する。これは、演奏者の鍵盤４への操作（押鍵や離鍵）に応じて楽音を発音させるための処理である。ここではエニーキーモードが設定された場合に実行される処理を抜粋して図８に示している。その鍵盤処理の実行後、ステップＡ４に移行する。

ステップＡ４では、音源発音処理を実行する。発音、或いは消音させるべき楽音は、ステップＡ２の自動演奏処理、及びステップＡ３の鍵盤処理の実行によって特定され、その特定によって生成されるＭＩＤＩデータはＲＡＭ３に確保された領域に格納される。音源発音処理は、その領域に格納されたＭＩＤＩデータを音源システム６に送出することにより、特定した楽音の発音、或いは消音を音源システム６に対して指示するための処理である。その指示を行い、音源システム６からオーディオ信号がアンプ回路７に出力される結果、楽音がスピーカー８を介して発音される。音源発音処理の実行後、ステップＡ５に移行する。

ステップＡ５では、スイッチ群５への操作に対応することを含むその他の処理を実行し、ステップＡ２に戻る。
設定した候補音高を示す音高データは、それぞれ演奏パート毎にＲＡＭ３上に確保された領域に格納される。図６は、その領域のデータ構成図である。図６（ａ）に示すように、メロディパートで設定した候補音高を示す音高データは候補音高バッファ１に格納される。同様に、コードパートの音高データは図６（ｂ）に示す候補音高バッファ２、ベースパートの音高データは図６（ｃ）に示す候補音高バッファ３にそれぞれ格納される。候補音階バッファ１、３に格納する音高データが一つなのは、メロディパート、ベースパート共に、同時に２音以上、発音させることはないと想定しているためである。候補音階バッファ２に６つの音高データを格納できるようにしたのは、最大で６つの構成音のコードまで対応可能としているためである。

図３は自動演奏処理のフローチャートである。その自動演奏処理は図２のステップＡ２で呼び出される。処理の対象となる楽曲データはＲＯＭ２から読み出してＲＡＭ３に格納したものである。

上述したように楽曲データを構成する楽音データは、イベントの内容を示すイベントデータに、次の楽音データの処理タイミングを示す時間データが付加された構成となっている（図５）。ステップＢ１では、時間データが示す処理タイミングとなったイベントデータの有無を判定し、それにより処理タイミングとなったイベントデータが有ることが判明すると、そのイベントデータの演奏パートが対象演奏パートか否か判定する。そのイベントデータがメロディチャンネル、コードチャンネル、或いはベースチャンネルのものであった場合、判定はＹＥＳとなってステップＢ２に移行し、それらの何れでもない場合には、判定はＮＯとなってステップＢ３に移行する。処理タイミングとなったイベントデータが無いことが判明すると、特には図示していないが、ここで自動演奏処理を終了する。

ステップＢ２では、図４に示す候補音高取り込み処理を実行して自動演奏処理を終了し、図２のメイン処理に戻る。他方のステップＢ３では、演奏対象外の演奏パートの自動演奏を行うための通常再生処理を実行する。それにより、演奏対象でない演奏パートのイベントデータからＭＩＤＩデータを生成し、そのＭＩＤＩデータをＲＡＭ３に確保した領域に格納する。その領域に格納されたデータは、図２のステップＡ４で実際の発音や消音を音源システム６により行わせるために利用される。通常再生処理の実行後は自動演奏処理を終了し、図２のメイン処理に戻る。

図４は候補音高取り込み処理のフローチャートである。候補音高取り込み処理は図３のステップＢ２で呼び出され、図６に示す候補音高バッファ１〜３への音高データの格納を行う処理である。

ステップＢ２−１では、図３のステップＢ１で処理タイミングとなったことを確認したイベントデータがメロディパートのもの（メロディ音として発音される楽音を示すもの）であれば、そのイベントデータが示すイベントの内容（ここでは発音、及び消音の何れか）に応じて、それを構成する音高データの図６（ａ）の候補音高バッファ１への格納、或いは格納された音高データのクリアを行う。そのクリアは「ＮＯＤＡＴＡ」とも表記する。

ステップＢ２−２では、図３のステップＢ１で処理タイミングとなったことを確認したイベントデータがコードパートのものであれば、そのイベントデータ中に挿入されているコード名データ、及びルート音階番号から、コードの各構成音の音高データを特定し、特定した音高データを、イベント種別が示すイベントの内容（ここでは発音、及び消音の何れか）に応じて、図６（ｂ）の候補音高バッファ２に格納するか、或いはそのバッファ２からクリアしてＮＯＤＡＴＡの状態にする。

ステップＢ２−３では、図３のステップＢ１で処理タイミングとなったことを確認したイベントデータがベースパートのもの（ベース音として発音される楽音を示すもの）であれば、そのイベントデータ中のイベント種別が示すイベントの内容（ここでは発音、及び消音の何れか）に応じて、それに挿入された音階番号に対応する音高データの図６（ｃ）の候補音高バッファ３への格納、或いはそのバッファ３からのクリアを行う。その後は候補音高取り込み処理を終了して自動演奏処理に戻る。

図８は鍵盤処理のフローチャートである。鍵盤処理は図２のステップＡ３で呼び出される。上記したように、ここでもエニーキーモード設定時に実行される処理を抜粋して示している。鍵盤４への操作により発音させる楽音は、この鍵盤処理を実行することで決定される。

鍵盤処理では、図６に示す各候補音高バッファ１〜３が参照される。また、図７のＡｎｙＫｅｙバッファおよび前回押鍵バッファを参照し、更新する。ＡｎｙＫｅｙバッファはエニーキーモードでの楽音の発音を管理するためのものであり、図７（ａ）に示すように、実際に演奏者が押鍵しているキーに割り当てられた音高を示す鍵盤番号と、その押鍵に対応して実際に発音している音高と、その発音に使っているチャンネル番号からなる組を１０組分格納できるように、ＲＡＭ３上に確保された領域である。以下では、鍵盤番号を格納するフィールドを鍵盤フィールド、音高（データ）を格納するフィールドを「音高フィールド」、チャンネル番号を格納するフィールドを「チャンネルフィールド」とそれぞれ呼ぶことにする。ＡｎｙＫｅｙバッファでデータが格納されている（ＮＯＤＡＴＡの状態ではない）組の数は、現在押鍵中のキーの数、つまり発音中の楽音の数と一致する。データを１０組分、格納できるようにしたのは、両手の１０本の指で最大１０個のキーを同時に押鍵することが可能なためである。チャンネルフィールドを設けたのは、演奏パート毎に異なる音色で楽音を発音させることもできるようにしたためである。

前回押鍵バッファは、図７（ｂ）に示すように、ＡｎｙＫｅｙバッファと同様の鍵盤フィールドと音高フィールドを備えた、ＲＡＭ３上に確保された領域である。鍵盤フィールドには、前回押鍵されたキーの鍵盤番号、音高フィールドには、その押鍵に対応して発音させた楽音の音高データをそれぞれ格納するようにしている。

先ず、ステップＣ１では、鍵盤４上のキーの状態変化を判定する。演奏者が新たな押鍵、或いは離鍵を行っていない場合、状態が変化したキーは存在しないことから、その旨が判定され、鍵盤処理を終了する。演奏者が新たな離鍵を行った場合には、その旨（ＯＦＦ）が判定されてステップＣ２３に移行し、演奏者が新たな押鍵を行った場合には、その旨（ＯＮ）が判定されてステップＣ２に移行する。

ステップＣ２では、ＡｎｙＫｅｙバッファの空き領域を抽出するためのサーチを行う。その後に移行するステップＣ３では、サーチによってＡｎｙＫｅｙバッファの空き領域を抽出できたか否か判定する。その空き領域を抽出できた場合、判定はＹＥＳとなってステップＣ４に移行する。反対に空き領域を抽出できなかった場合には、つまり既に１０個の楽音を発音中の場合には、判定はＮＯとなり、ここで鍵盤処理を終了する。

承知のように、ベースパートは最低音を担当する楽器で演奏される。このことに着目し、本実施形態では、ベースパートの楽音を発音可能な鍵域（ベース鍵域）を設定し、そのベース鍵域への操作に応じてそのベースパートで発音させるべき楽音を発音させるようにしている。ベース鍵域以外は、メロディパート、或いはコードパートの楽音を発音可能な鍵域（メロディ・コード鍵域）としている。このことからステップＣ４では、新たに押鍵されたキーがベース鍵域内のものか否か判定する。演奏者がベース鍵域内のキーを新たに押鍵した場合、判定はＹＥＳとなってステップＣ５に移行し、そうでない場合には、つまりメロディ・コード鍵域内のキーを演奏者が新たに押鍵した場合には、判定はＮＯとなってステップＣ７に移行する。

ステップＣ５では、演奏すべきベース音があるか否か、つまり図６（ｃ）の候補音高バッファ３に音高データが格納されているか否かを判定する。候補音高バッファ３に音高データが格納されている場合、判定はＹＥＳとなってステップＣ６に移行し、そうでない場合には、判定はＮＯとなってステップＣ９に移行する。

ステップＣ６では、候補音高バッファ３に格納されている音高データで楽音が発音中か否か判定する。その音高データが図７（ａ）のＡｎｙＫｅｙバッファのいずれかの音高フィールドに格納されていた場合、その楽音は発音中として、判定はＹＥＳとなってステップＣ９に移行する。それにより、今回の押鍵はコードパートの楽音を発音させるためのものと見なす。そうでない場合には、判定はＮＯとなってステップＣ２１に移行する。

一方ステップＣ７では、発音させるべきメロディパートの楽音があるか否か、つまり図６（ａ）の候補音高バッファ１に音高データが格納されているか否かを判定する。候補音高バッファ１に音高データが格納されている場合、判定はＹＥＳとなってステップＣ８に移行し、その音高データが格納されていない、つまり候補音高バッファ１がＮＯＤＡＴＡの状態であった場合には、判定はＮＯとなってステップＣ９に移行する。

ステップＣ８では、候補音高バッファ１に格納されている音高データで楽音が発音中か否かを判定する。その音高データが図７（ａ）のＡｎｙＫｅｙバッファのいずれかの音高フィールドに格納されていた場合、その楽音は発音中として、判定はＹＥＳとなってステップＣ９に移行する。そうでない場合には、判定はＮＯとなってステップＣ２１に移行する。

ステップＣ９〜Ｃ２０は、今回の押鍵に対してコードパートを対応させて発音する場合の処理である。ステップＣ９への移行は、ベース鍵域内のキーを押鍵してもベースパートに新たに発音させるべき楽音が存在しない場合、或いはメロディ・コード鍵域内のキーを押鍵してもメロディパートに新たに発音させるべき楽音が存在しない場合に行われる。

ステップＣ９では、コードの構成音のうち未発音のものがあるか否かを判定する。候補音高バッファ２に１つ以上の音高データが格納されており、且つそれらのうちで図７（ａ）のＡｎｙＫｅｙバッファの音高フィールドに格納されていないものがある場合、コードの構成音のうち未発音のものがあるとして、判定はＹＥＳとなりステップＣ１０に移行する。候補音高バッファ２に音高データが格納されていない、或いは音高データが１つ以上格納され、且つそのすべてがＡｎｙＫｅｙバッファの音高フィールドに格納されている場合には、未発音の構成音は存在しないとして、判定はＮＯとなりステップＣ１７に移行する。

ステップＣ１０では、今回押鍵されたキーは前回押鍵されたキーより割り当てられた音高が下か否か判定する。前回押鍵したキーより低い音高のキーを演奏者が今回押鍵した場合、つまり前回押鍵バッファの鍵盤フィールドに格納された鍵盤番号より小さい鍵盤番号が割り当てられたキーを演奏者が今回押鍵した場合、判定はＹＥＳとなってステップＣ１４に移行し、そうでない場合には、判定はＮＯとなってステップＣ１１に移行する。

ステップＣ１１では、演奏者が前回の押鍵時よりも高い音高の楽音を発音させようとしたと見なし、候補音高バッファ２に格納された音高データのなかで、ＡｎｙＫｅｙバッファの音高フィールドに対応する音高データが格納されてなく、且つ前回、発音させた構成音の音高データ以上、高音の音高データを探す。次にステップＣ１２では、そのような音高データが有ったか否か判定する。そのような音高データを探し出せた場合、判定はＹＥＳとなってステップＣ２１に移行し、そうでない場合には、判定はＮＯとなってステップＣ１３に移行する。

ステップＣ１３は、コードの構成音に未発音の音が存在するが、その中には前回の押鍵に対応して発音させた構成音の音高データ以上高音の構成音がない場合に実行される。この場合、未発音の構成音をそのまま発音したのでは、前回の押鍵時よりも高音の構成音を発音させようとしている演奏者の意図に応えることはできない。そこで、ステップＣ１３では、未発音の構成音を１オクターブ上げた音高で発音させるよう設定するオクターブＵＰ変換処理を実行する。それにより、演奏者の意図を反映しつつ自然と感じられるようにコードの構成音を発音させる（コードはメロディやベースと異なり、その構成音をオクターブ単位で変換しても（転回しても）演奏の自然さが保たれる）。その後はステップＣ２１に移行する。

ステップＣ１４〜Ｃ１６は、コードの構成音のうち未発音のものがあり、且つ演奏者は前回よりも低音のキーを今回押鍵している場合に実行される。それにより、演奏者が前回の押鍵時よりも低音の構成音を発音させようとしていると見なし、その意図に対応するための処理が行われる。

ステップＣ１４では、候補音高バッファ２に格納された音高データのなかで、ＡｎｙＫｅｙバッファの音高フィールドに音高データが格納されてなく、且つ前回、発音させた構成音の音高データより低音の音高データを探す。次にステップＣ１５では、そのような音高データが有ったか否か判定する。そのような音高データを探し出せた場合、判定はＹＥＳとなってステップＣ２１に移行し、そうでない場合には、判定はＮＯとなってステップＣ１６に移行する。

ステップＣ１６は、コードの構成音に未発音の音が存在するが、その中には前回の押鍵に対応して発音させた構成音の音高データより低音の構成音がない場合に実行される。このことから、ステップＣ１６では、未発音の構成音を１オクターブ下げた音高で発音させるよう設定するオクターブＤＯＷＮ変換処理を実行する。それにより、演奏者の意図を反映しつつ自然と感じられるようにコードの構成音を発音させる。

ステップＣ１７〜Ｃ２０は、演奏すべきコード構成音がすべて発音中の場合に実行される。押鍵操作は、現状よりもさらに多くの楽音を発音させたいという演奏者の意図の表れと見なすことができる。演奏者の意図を実際の楽音の発音に反映させるという観点からは、現在発音されている構成音とは音高が異なる音を押鍵操作に合わせて発音することが好ましいと言える。しかし、ステップＣ１７に移行時には発音すべき構成音は既にすべて発音されているので、演奏の自然さを損なわないような楽音を、現在発音させていない楽音の中から選んで発音する必要がある。

そのような楽音として、本実施形態では、発音中のコードの構成音のうちの任意の１つの音高をオクターブ単位で上または下に変換した楽音を採用している。上か下かの選択は、演奏者の意図を発音に反映させるという観点から、前回と今回で押鍵されたキー間の音高関係により行う。

ステップＣ１７への移行は、発音させるべきコード自体が存在しない場合にも行われる。その場合、特には図示していないが、ステップＣ１７〜Ｃ２０を実行することなく、鍵盤処理を終了するようになっている。

ステップＣ１７では、図６の候補音高バッファ２の音高フィールドに格納された音高データの中から１つの音高データを選択する。その選択後、ステップＣ１８に移行する。
ステップＣ１８では、ステップＣ１０と同様に、今回押鍵されたキーは前回押鍵されたキーより低音のものか否か判定する。前回押鍵したキーより低音のキーを今回、演奏者が押鍵した場合、判定はＹＥＳとなってステップＣ２０に移行し、そうでない場合には、判定はＮＯとなってステップＣ１９に移行する。

ステップＣ１９では、ステップＣ１３と同様に、選択した音高データを対象にオクターブＵＰ変換処理を実行する。その後ステップＣ２１に移行する。他方のステップＣ２０では、ステップＣ１６と同様に、選択した音高データを対象にオクターブＤＯＷＮ変換処理を実行する。その後ステップＣ２１に移行する。

ステップＣ２１に移行時には、発音させる楽音の音高、その楽音の演奏パートが決定している。その音高は、演奏パートがメロディパート、或いはベースパートであれば候補音高であり、コードパートであれば候補音高、それよりも１オクターブ上の音高、或いは１オクターブ下の音高である。ステップＣ２１では、決定した音高、その音高の楽音を発音させる演奏パートから音源システム６に出力すべきコマンド（ここではＭＩＤＩデータ）を生成し、ＲＡＭ３上に確保した領域に格納する。また、ＡｎｙＫｅｙバッファのステップＣ２で探した空き領域の各フィールドに、今回押鍵されたキーの鍵盤番号、候補音高を示す音高データ、及び演奏パートに対応するチャンネル番号をそれぞれ格納する。続くステップＣ２２では、図７（ｂ）の前回押鍵バッファを更新する。つまり、今回押鍵されたキーの鍵盤番号を鍵盤フィールドに格納し、今回の押鍵により実際に発音させた楽音の音高データを音高フィールドに格納する。その後、鍵盤処理を終了する。

演奏者が新たな離鍵を行っていないとステップＣ１で判定した場合に移行するステップＣ２３では、図７（ａ）のＡｎｙＫｅｙバッファをサーチして、鍵盤フィールドの鍵盤番号が今回押鍵されたキーのそれと一致する領域の抽出を行う。次のステップＣ２４では、一致する領域が見つかったか否かを判定する。一致する領域を探し出せた場合、判定はＹＥＳとなってステップＣ２５に移行する。そうでない場合には、判定はＮＯとなり、ここで鍵盤処理を終了する。

ステップＣ２５では、一致する領域が複数あればそのうちの一つを選択し、音高フィールドの音高データ、及びチャンネルフィールドのチャンネル番号を用いて音源システム６に出力するコマンド（ＭＩＤＩデータ）を生成し、ＲＡＭ３上に確保した領域に格納する。また、ＡｎｙＫｅｙバッファのコマンドの生成に用いたデータを格納した領域の各フィールドをクリアしてＮＯＤＡＴＡの状態にする。その後、鍵盤処理を終了する。

このようにして上記ステップＣ２３〜Ｃ２５は、離鍵操作に対応するために実行される。その実行により、鍵の押鍵よって発音を開始させたコードの構成音は、その鍵の離鍵によって消音される。このため、ユーザー（演奏者）はコードの構成音毎に、その発音期間を制御できるようになっている。

図８の鍵盤処理は上記のとおりであるが、その主な特徴と効果は以下のとおりである。
第一に、複数の演奏パートに優先度を設けることにより、演奏者が押鍵したときに優先度の高い対象演奏パートの音から発音することができる。図８では優先度の順に処理を行うことで実現させている。これにより、演奏者がメロディ・コード鍵域を押鍵した際には、より重要なメロディパートがコードパートよりも優先して発音される。

第二に、押鍵された鍵域によって複数の演奏パートの優先度を変更することにより、演奏者の意図が発音に反映される度合いを高めることができる。本実施形態では、ベース鍵域内のキーが押鍵されたか否かによって優先度を変えている。ベース鍵域内のキーが押鍵された場合の優先度はベースパート、コードパートの順であり、メロディパートは無視される。逆に、メロディ・コード鍵域が押鍵された場合の優先度はメロディパート、コードパートの順であり、ベースパートは無視される。

なお、本実施形態では対象演奏パートは３つとなっているが、対象演奏パート数はそれよりも多くとも少なくともよい。例えば、演奏パートがメロディパートとコードパートの２つだけでもよい。その場合、図４のステップＢ２−３、図６の候補音高バッファ３、図８のステップＣ４〜Ｃ６は不要である。

楽曲データについては、データを演奏パート毎に分けて記述されたものを用いているが、パート毎に分けて記述されていないものを用いても良い。その場合、演奏内容を解析して、発音を示す楽音が属する演奏パートを特定すれば良い。また形式も特に限定されるものではない。その楽曲データは、ＲＯＭ２に格納して用意するのではなく、ネットワークや可搬型コンピュータ読み取り可能記憶媒体（メモリカード等）を介して取得するものであっても良い。

演奏パート間の優先度の変更は、ベース鍵域内のキーが押鍵されたか否かにより行っている。その変更は、演奏パート毎に鍵域を設定して行うようにしても良い。その鍵域は固定でも良いが、ユーザーによって変更可能としても良い。

本実施形態では、発音させるべき楽音を全て発音中の状況下で更に押鍵が行われると、その押鍵によって更に楽音を発音させるようにしている。しかし、そのような状況下では、更に楽音を発音させないようにしても良い。つまり押鍵を無視するようにしても良い。

コードを発音させるための全ての押鍵が同時に行われるとは限らない。発音させるコード（の構成音）は常に同じものとは限らない。このことから、前後に押鍵されたキーの音高関係に着目して構成音を選択するのではなく、一定時間の間に押鍵されたキーを全て考慮する形で構成音を選択するようにしても良い。コードによって構成音は異なることから、前のコードの影響を回避するために、前回押鍵バッファは候補音階バッファ２の更新に応じてクリアすることが望ましい。
＜第２の実施形態＞
上記第１の実施形態では、コードで押鍵により発音させる構成音の選択は、今回押鍵されたキーが前回押鍵されたキーより割り当てられた音高が上か否かに応じて、未発音の構成音のなかから発音させる構成音を選択することで行っている。それにより、演奏者が押鍵したキーを考慮して、音高に着目しての構成音の選択を行うようにしている。

上述したようにコードは、協和音と不協和音とに大別される。不協和音では、コードを不協和音とする構成音（テンションノート）によって緊張感を生じさせる。このため、テンションノートを発音させるタイミング（発音順序）は演奏者が制御できるようにすることが望ましい。しかし、音高に着目しての構成音の選択では、その制御が不可能か、たとえ可能であっても制御には、発音させるコードの種類、構成音間の音程等を把握しての適切な操作を行わなければならない。そのような操作は、エニーキーモードでの演奏を行う演奏者にとっては非常に困難なのが実情である。このようなことから第２の実施形態は、テンションノートの発音を所望のタイミングで行えるように、構成音の発音順序を演奏者が制御できるようにして、より意図した音楽表現を行えるようにしたものである。

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

第２の実施形態では、コードパートを対象演奏パートとした場合、対象演奏パートはコードパートのみとしている。鍵盤４に設けられたキーの種類には、白鍵、及び黒鍵がある。このことから、鍵盤４上のキーをその種類によってグループ分けすると共に、コードの構成音をテンションキーか否かにより分類し、操作されたキーが属するグループに応じて、そのグループに対応する分類の構成音を選択して発音させるようにしている。それにより、操作するキーの種類の選択を通して、演奏者が構成音の発音順序を制御できるようにしている。

ここでは、黒鍵が操作されたときにはテンションノート、白鍵が操作されたときにはテンションノート以外の構成音を選択・発音させるようにしている。黒鍵をテンションノート発音用のグループとしたのは、構成音のなかでテンションノートが占める割合は比較的に小さい、実際の演奏ではテンションノートの発音に黒鍵を押鍵する頻度は白鍵を押鍵する頻度に比べて高い、といった理由からである。つまり、押鍵動作が白鍵と比較的して大きくなる黒鍵を押鍵する必要性を低く抑えて操作を容易にする、演奏者にとってより違和感が小さくなる、といった利点があるためである。

上述したような構成音の発音順序の制御を可能とするために、第２の実施形態では図２に示すメイン処理において、ステップＡ２として実行される自動演奏処理、及びステップＡ３として実行される鍵盤処理が第１の実施形態から異なっている。他のステップでは処理内容は同じか、或いは基本的に同じである。このことから、第２の実施形態で実行される自動演奏処理、及び鍵盤処理について、図９〜図１１を参照して詳細に説明する。

図９は、第２の実施形態で実行される自動演奏処理のフローチャートである。始めに図９を参照して、その自動演奏処理について詳細に説明する。
先ず、ステップＢ１１では、直前のイベントデータを処理してから、そのイベントデータに付加された時間データ（図５）が示す時間間隔Δｔが経過したか否か判定する。直前のイベントデータが存在しない（次に処理対象とするイベントデータは先頭に位置する楽音データを構成している）、或いはその時間間隔Δｔが経過した場合、判定はＹＥＳとなってステップＢ１２に移行する。それらの何れでもない場合には、判定はＮＯとなり、ここで自動演奏処理を終了し、図２のメイン処理に戻る。

ステップＢ１２では、楽曲データから次の楽音データを読み出し、その楽音データ中の時間データが示す時間間隔Δｔの計時を開始させる。その計時は、一定時間間隔（例えば上記最小時間間隔）で発生する割り込み信号により実行されるタイマインタラプト処理、或いはＣＰＵ１に搭載のハードタイマを用いて行う。次のステップＢ１３では、読み出した楽音データ中のイベントデータが示すチャンネル（図中「演奏ｃｈ」と表記）の判定を行う。そのチャンネルがコードパート以外のもの、つまりメロディパート、リズムパート等のチャンネルであった場合、その旨が判定されてステップＢ１７に移行し、イベントデータから音源システム６に送出すべきＭＩＤＩデータを生成しＲＡＭ３に格納する。一方、そのチャンネルがコードパートのもの（コードチャンネル）であった場合には、その旨が判定されてステップＢ１４に移行する。

上記ステップＢ１２で読み出すべき楽音データが無いことが判明すると、特には図示していないが、ここで自動演奏処理を終了するようになっている。そのステップＢ１２、及びステップＢ１１は、図３に示す自動演奏処理ではステップＢ１で行われる。

コードパートのイベントデータには、コードの種類を示すコード名データ、及びルートの音高を示すルート音階番号が挿入されている。ステップＢ１４では、コード名データ、及びルート音階番号からコードの各構成音の音高データを特定し、特定した音高データを、イベント種別が示すイベントの内容（ここでは発音、及び消音の何れか）に応じて、図６（ｂ）の候補音高バッファ２に格納するか、或いはそのバッファ２からクリアしてＮＯＤＡＴＡの状態にする。その後はステップＢ１５に移行する。

第２の実施形態では、図６（ｂ）に示す音階候補バッファ２として、音高データを格納するフィールドの他に、テンションノートか否かを示す値（フラグ）を格納するフィールドを設けたものを採用している。それにより、構成音がテンションノートか否か区別するようにしている。ここでは、テンションノートを示す値を格納することを「フラグを設定する」と表現し、その値を格納しないことを「フラグを設定しない」或いは「フラグの設定を解除する」等と表現する。

ステップＢ１５では、上記コード名データが示すコードの種類が不協和音に大別されるものか否か判定する。その種類が不協和音に大別されるものであった場合、判定はＹＥＳとなってステップＢ１６に移行し、そのコードの種類、及びルート音階番号からテンションノートに相当する構成音を特定して、その全てにフラグを設定した後、自動演奏処理を終了する。そうでない場合には、つまりコードの種類が協和音に大別されるものである場合には、判定はＮＯとなり、ここで自動演奏処理を終了する。

構成音間の音程はコードの種類によって異なる固有のものである。それにより、コードの各構成音の音高は、コードの種類毎に、例えば各構成音のルートからの音程を示す音程データを用意することで特定させることができる。構成音がテンションノートか否かの特定は、例えば音程データと合わせて、その構成音がテンションノートか否かを示すノート種別データを用意することで特定させることができる。セブンスでは何れの種類もルートから短七度、或いは長七度の不協和音程を持つ構成音がテンションノートに相当する。

図１０及び図１１は、第２の実施形態で実行される鍵盤処理のフローチャートである。次に図１０及び図１１を参照して、その鍵盤処理について詳細に説明する。その鍵盤処理は、第１の実施形態と同様に、エニーキーモード設定時に実行される処理を抜粋して示している。第１の実施形態と同じ、或いは基本的に同じ処理内容のステップには同一の符号を付している。それにより、第１の実施形態から異なる部分にのみ着目する形で説明を行う。

第２の実施形態では、対象演奏パートがコードパートのみであるため、図６に示す各候補音高バッファ１〜３のなかで図６（ｂ）に示す候補音高バッファ２のみが参照される。図７のＡｎｙＫｅｙバッファおよび前回押鍵バッファは第１の実子の形態と同様に参照し、更新する。

第２の実施形態では、ステップＣ３でのＹＥＳの判定によってステップＤ２に移行し、押鍵されたキーが白鍵か否か判定する。そのキーが黒鍵であった場合、判定はＮＯとなり、演奏者はテンションノートの発音を所望していると見なし、図１１のステップＤ７に移行する。そうでない場合には、判定はＹＥＳとなってステップＤ３に移行する。

ステップＤ３では、図６（ｂ）の候補音高バッファ２に、フラグが未設定で未発音の構成音の音高データが格納されているか否か判定する。候補音高バッファ２に１つ以上の音高データが格納されており、且つそれらのうちで図７（ａ）のＡｎｙＫｅｙバッファの音高フィールドに格納されていないフラグが未設定のものがある場合、コードの構成音のうちテンションノート以外で未発音のものがあるとして、判定はＹＥＳとなりステップＣ１０に移行する。候補音高バッファ２に音高データが格納されていない、或いは音高データが１つ以上格納され、且つフラグが未設定のもの全てがＡｎｙＫｅｙバッファの音高フィールドに格納されている場合には、テンションノート以外で未発音の構成音は存在しないとして、判定はＮＯとなりステップＤ６に移行する。

ステップＤ６では、図６（ｂ）の候補音高バッファ２の音高フィールドに格納された、フラグが未設定の音高データの中から１つの音高データを選択する。その選択後はステップＣ１８に移行する。ステップＣ１８〜Ｃ２２については処理内容は第１の実施形態と基本的に同じであるため、説明は省略する。

ステップＤ６への移行は、発音させるべきコード自体が存在しない場合にも行われる。その場合、特には図示していないが、音高データの選択を行うことなく、鍵盤処理を終了するようになっている。

一方、ステップＣ１０では、今回押鍵されたキーは前回押鍵されたキーより割り当てられた音高が下か否か判定する。前回押鍵したキーより低い音高のキーを演奏者が今回押鍵した場合、つまり前回押鍵バッファの鍵盤フィールドに格納された鍵盤番号より小さい鍵盤番号が割り当てられたキーを演奏者が今回押鍵した場合、判定はＹＥＳとなってステップＤ５に移行し、そうでない場合には、判定はＮＯとなってステップＤ４に移行する。

ステップＤ４では、演奏者が前回の押鍵時よりも高い音高の楽音を発音させようとしたと見なし、候補音高バッファ２に格納されたフラグが未設定の音高データのなかで、ＡｎｙＫｅｙバッファの音高フィールドに対応する音高データが格納されてなく、且つ前回、発音させた構成音の音高データ以上、高音の音高データを探す。その後はステップＣ１２に移行する。ステップＣ１２及びＣ１３についての説明は省略する。

ステップＤ５では、演奏者が前回の押鍵時よりも低音の構成音を発音させようとしていると見なし、候補音高バッファ２に格納されたフラグが未設定の音高データのなかで、ＡｎｙＫｅｙバッファの音高フィールドに音高データが格納されてなく、且つ前回、発音させた構成音の音高データより低音の音高データを探す。その後はステップＣ１５に移行する。ステップＣ１５及びＣ１６についての説明は省略する。

このようにして、演奏者が白鍵を押鍵した場合、発音タイミングとなったコードが存在していれば、フラグが未設定の構成音に限定し、その構成音を音高データに従って、或いはその音高データが示す音高から１オクターブ高く、若しくは下げた音高で発音させる。それにより、演奏者の意図を反映しつつ自然と感じられるようにコードのテンションノート以外の構成音を発音させる。

上記ステップＤ２の判定がＮＯ、つまり黒鍵が押鍵されたと判定した場合に移行する図１１のステップＤ７〜Ｄ１８では、その黒鍵の押鍵に対応するための処理が行われる。
上述したように黒鍵に対する押鍵は、テンションノートを発音させるための操作と見なすようにしている。このことから、ステップＤ７では、図６（ｂ）の候補音高バッファ２に、フラグが設定された音高データの中で未発音の構成音（テンションノート）のものが格納されているか否か判定する。候補音高バッファ２に１つ以上の音高データが格納されており、且つそれらのうちで図７（ａ）のＡｎｙＫｅｙバッファの音高フィールドに格納されていないフラグが設定のものがある場合、テンションノートで未発音のものがあるとして、判定はＹＥＳとなりステップＤ８に移行する。候補音高バッファ２に音高データが格納されていない、或いは音高データが１つ以上格納され、且つフラグが設定のもの全てがＡｎｙＫｅｙバッファの音高フィールドに格納されている場合には、テンションノートで未発音のものは存在しないとして、判定はＮＯとなりステップＤ１５に移行する。

ステップＤ１５では、図６の候補音高バッファ２の音高フィールドに格納された、フラグが設定の音高データの中から１つの音高データを選択する。その選択後はステップＤ１６に移行する。ステップＤ１６〜Ｄ１８については、上記ステップＣ１８〜Ｃ２０と処理内容が基本的に同じであるため、説明は省略する。ステップＤ１７或いはＤ１８の処理の実行後は図１０のステップＣ２１に移行する。

ステップＤ１５への移行は、発音させるべきコード自体が存在しない場合にも行われる。その場合、特には図示していないが、音高データの選択を行うことなく、鍵盤処理を終了するようになっている。

一方、ステップＤ８では、今回押鍵されたキーは前回押鍵されたキーより割り当てられた音高が下か否か判定する。前回押鍵したキーより低い音高のキー（ここでは黒鍵）を演奏者が今回押鍵した場合、つまり前回押鍵バッファの鍵盤フィールドに格納された鍵盤番号より小さい鍵盤番号が割り当てられた黒鍵を演奏者が今回押鍵した場合、判定はＹＥＳとなってステップＤ９に移行し、そうでない場合には、判定はＮＯとなってステップＤ１２に移行する。

ステップＤ９では、演奏者が前回の押鍵時よりも高い音高の楽音を発音させようとしたと見なし、候補音高バッファ２に格納されたフラグが設定の音高データのなかで、ＡｎｙＫｅｙバッファの音高フィールドに対応する音高データが格納されてなく、且つ前回、発音させた構成音の音高データ以上、高音の音高データを探す。その後はステップＤ１０に移行する。ステップＤ１０及びＤ１１については、上記ステップＣ１２及びＣ１３と処理内容が基本的に同じであるため、説明は省略する。ステップＤ１０でのＹＥＳの判定、或いはステップＤ１１の処理の実行により図１０のステップＣ２１に移行する。

ステップＤ１２では、演奏者が前回の押鍵時よりも低音の構成音を発音させようとしていると見なし、候補音高バッファ２に格納されたフラグが設定の音高データのなかで、ＡｎｙＫｅｙバッファの音高フィールドに音高データが格納されてなく、且つ前回、発音させた構成音の音高データより低音の音高データを探す。その後はステップＤ１３に移行する。ステップＤ１３及びＤ１４については、上記ステップＣ１５及びＣ１６と処理内容が基本的に同じであるため、説明は省略する。ステップＤ１３でのＹＥＳの判定、或いはステップＤ１４の処理の実行により図１０のステップＣ２１に移行する。

このようにして、演奏者が黒鍵を押鍵した場合には、発音タイミングとなったコードが存在していれば、フラグが設定の構成音であるテンションノートに限定し、そのテンションノートを音高データに従って、或いはその音高データが示す音高から１オクターブ高く、若しくは下げた音高で発音させる。それにより、演奏者の意図を反映しつつ自然と感じられるようにテンションノートを発音させる。

なお、第２の実施形態では、鍵盤４上のキーを白鍵、黒鍵でグループ分けし、そのグループ分けに合わせてコードの構成音（候補音高）をテンションノート、及びそれ以外の構成音に分類することにより、テンションノート、及びそれ以外の構成音を演奏者が選択して発音させることができるようにしているが、グループ分けは白鍵、黒鍵のキーの種類ではなく、割り当てられた音高の範囲（鍵域）により行っても良い。そのようなグループ分けを採用した場合には、コードパート以外の対象演奏パートの演奏用の鍵域を別に設けることにより、複数の演奏パートの演奏を演奏者が行えるようにしても良い。候補音高を分類する対象演奏パートとしては、楽音間でそれが持つ機能、或いは役割に違いがある演奏パートであれば幅広く採用することができる。

本実施形態（第１及び第２の実施形態）による演奏装置は、ＣＰＵ１に実行させるプログラムをＲＯＭ２に格納し実行させることで実現させているが、そのようなプログラムは、ＣＤ−ＲＯＭ、ＤＶＤ、或いは着脱自在なフラッシュメモリ等の記録媒体に記録させて配布しても良い。公衆網等の通信ネットワークを介して、そのプログラムの一部、若しくは全部を配信するようにしても良い。そのようにした場合には、ユーザーはプログラムを取得して、演奏装置として用いることが可能なコンピュータにロードすることにより、そのコンピュータに本発明を適用させることができる。このことから、記録媒体は、プログラムを配信する装置がアクセスできるものであっても良い。そのコンピュータは演奏装置を構成するものであっても良いが、鍵盤４のような複数の演奏操作子を備えた装置を接続できるもの、つまり行われた演奏操作の内容を示すデータを受信できるものであっても良い。

本実施形態による演奏装置の構成図である。 メイン処理のフローチャートである。 自動演奏処理のフローチャートである。 候補音高取り込み処理のフローチャートである。 楽曲データを構成する楽音データの構成を説明する図である。 各種候補音高バッファのデータ構成図である。 ＡｎｙＫｅｙバッファおよび前回押鍵バッファのデータ構成図である。 鍵盤処理のフローチャートである。 第２の実施形態で実行される自動演奏処理のフローチャートである。 第２の実施形態で実行される鍵盤処理のフローチャートである。 第２の実施形態で実行される鍵盤処理のフローチャートである（続き）。

符号の説明

１ ＣＰＵ
２ ＲＯＭ
３ ＲＡＭ
４ 鍵盤
５ スイッチ群
６ 音源システム
７ アンプ回路
８ スピーカー
９ バス

Claims (4)

1. 演奏者が演奏を行うための複数の演奏操作子を備えた演奏装置において、
   コードを発音させるコードパートを少なくとも示す楽曲データを記憶する楽曲データ記憶手段と、
   前記演奏の進行に応じて随時、前記楽曲データ記憶手段が記憶した楽曲データが示すコードパートにおいて、コードの各構成音の音高をそれぞれ、該コードを不協和音とさせる第１の候補音高、及び該第１の候補音高以外の第２の候補音高のうちの何れかに分類、設定する音高設定手段と、
   前記複数の演奏操作子を第１及び第２のグループの２つのグループに分け、該複数の演奏操作子のなかで前記第１のグループに属する演奏操作子への操作によって前記第１の候補音高を選択するとともに前記第２のグループに属する演奏操作子への操作によって前記第２の候補音高を選択し、該選択した候補音高により楽音を楽音発生装置により発音させる発音制御手段と、
   を具備することを特徴とする演奏装置。
2. 前記複数の演奏操作子が鍵盤を構成する複数の鍵であった場合、前記第１、及び第２のグループに属する演奏操作子はそれぞれ黒鍵、及び白鍵である、
   ことを特徴とする請求項１記載の演奏装置。
3. コードを発音させるコードパートを少なくとも示す楽曲データを記憶する楽曲データ記憶手段、及び演奏者が演奏を行うための複数の演奏操作子を備えた演奏装置を用いることによる演奏を実現させるための方法であって、
   前記演奏の進行に応じて随時、前記楽曲データ記憶手段が記憶した楽曲データが示すコードパートにおいて、コードの各構成音の音高をそれぞれ、該コードを不協和音とさせる第１の候補音高、及び該第１の候補音高以外の第２の候補音高のうちの何れかに分類、設定し、
   前記複数の演奏操作子を第１及び第２のグループの２つのグループに分け、
   該複数の演奏操作子のなかで前記第１のグループに属する演奏操作子への操作によって前記第１の候補音高を選択するとともに前記第２のグループに属する演奏操作子への操作によって前記第２の候補音高を選択し、該選択した候補音高により楽音を楽音発生装置により発音させることで前記演奏を実現させる、
   ことを特徴とする演奏実現方法。
4. コードを発音させるコードパートを少なくとも示す楽曲データを記憶する楽曲データ記憶手段、及び演奏者が演奏を行うための複数の演奏操作子を備えた演奏装置として用いられるコンピュータに、
   前記演奏の進行に応じて随時、前記楽曲データ記憶手段が記憶した楽曲データが示すコードパートにおいて、コードの各構成音の音高をそれぞれ、該コードを不協和音とさせる第１の候補音高、及び該第１の候補音高以外の第２の候補音高のうちの何れかに分類、設定する音高設定機能と、
   前記複数の演奏操作子を第１及び第２のグループの２つのグループに分け、該複数の演奏操作子のなかで前記第１のグループに属する演奏操作子への操作によって前記第１の候補音高を選択するとともに前記第２のグループに属する演奏操作子への操作によって前記第２の候補音高を選択し、該選択した候補音高により楽音を楽音発生装置により発音させる発音制御機能と、
   を実現させるためのプログラム。

Images