JP2007334065A - 演奏装置およびプログラム - Google Patents

Abstract

【課題】同時に複数の楽音を発音させるコードパートのような演奏パートの演奏を、原曲により近く行えるようにする演奏装置を提供する。
【解決手段】ＣＰＵ１は、複数の演奏パートの演奏内容を示す楽曲データをＲＯＭ２から読み込み、コードパートで発音させるべきコードの全構成音数、未発音の構成音数を特定し、ビデオシステム８を介してそれらの情報をテレビ１４に表示させる。未発音の構成音数は、演奏者の鍵盤５への操作（押鍵）により随時、更新する。それにより、発音させるべき数の構成音を正確に発音できるように演奏者を支援する。
【選択図】図１

Description

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

電子鍵盤楽器等の複数の演奏操作子を備えた演奏装置のなかには、演奏者が演奏操作子を操作したタイミングに合わせて、その演奏操作子に割り当てられた音高に係わらず、予め記憶された楽曲データの発音音高順に従って発音させるべき楽音を発音させる機能（任意の演奏操作子の操作により予め記憶された音高順序で楽音を発音させることから以降「エニーキー機能」と呼ぶ）を搭載したものがある。そのエニーキー機能を用いた演奏では、どの演奏操作子を操作しても、予め記憶された楽曲の音高の楽音が順に発音される。このことから、その演奏は主に演奏操作子を操作すべきタイミングの練習用などに利用されている。演奏内容を示す楽曲データは、発音させるべき楽音の特定に用いられる。

発音させるべき楽音の発音をどの演奏操作子を操作しても行える場合、演奏者が同時に発音可能な楽音数は１つに限定される。なぜなら、或る演奏操作子を操作していても、別の演奏操作子への操作によって次に発音させるべき楽音を発音させるからである。このことから、エニーキー機能を搭載した従来の演奏装置のなかには、特許文献１に記載されたように、複数の楽音を同時に発音できるようにしたものがある。演奏操作子については以降、「キー」と表記する。

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

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

候補音高がすべて発音中であっても、前回、押鍵されたキーと今回押鍵のキーの音高を比較する。それにより、前回押鍵されたキーよりも高い音高のキーを演奏者が今回押鍵した場合は、発音中の候補音高のうちの１つを１オクターブ高く変換した音高で楽音をさらに発音させる。

今回、操作されたキーの音高が前回、操作されたキーの音高よりも低いことを確認した場合には、音高の高低を逆にして同様の選択が行われる。
このようにして特許文献１に記載の従来の演奏装置では、楽曲データが示すコードパートの演奏内容の演奏をできるようにしつつ、その演奏内容を演奏者が実際に行った演奏操作に応じて変更、つまり演奏者が実際に行った演奏操作を演奏内容に反映するようにしている。それにより、演奏者にとって自然と感じられる内容の演奏も行えるようになっている。

コードパートで発音すべきコードの構成音は常に同じであるとは限らない。通常、コードの構成音数は３〜４つであるが、コードの種類によってはそれ以上の数となっている。構成音を全て発音させていない場合、行われる演奏は物足りない印象を与えるものとなる。特許文献１に記載の従来の演奏装置では、上述したように、設定した候補音高数を越える押鍵が行われると、候補音高の何れかを１オクターブ上、或いは一オクターブ下にした音高で楽音を発音させる。そのような楽音の発音により、原曲とは異なる印象を与える可能性がある。このようなことから、同時に複数の楽音を発音させるコードパートのような演奏パートでは、原曲により近い演奏を行えるようにするうえで、その楽音数を通知することも重要と考えられる。
特開２００４−１７７８９３号公報

本発明の課題は、同時に複数の楽音を発音させるコードパートのような演奏パートの演奏を、原曲により近く行えるようにする演奏装置を提供することにある。

本発明の第１、及び第２の態様の演奏装置は共に、演奏者が演奏を行うための複数の演奏操作子を備えていることを前提とし、それぞれ以下の手段を具備する。
第１の態様の演奏装置は、演奏パートとしてコードパートの演奏内容を少なくとも示す楽曲データを取得する楽曲データ取得手段と、楽曲データ取得手段が取得した楽曲データを参照し、コードパートで発音させるべきコードの構成音毎に該構成音の音高を候補音高として、演奏の進行に応じて随時、設定する音高設定手段と、複数の演奏操作子のなかのいずれかの演奏操作子が操作された場合に、音高設定手段が設定した候補音高のなかの一つを選択し、該選択した候補音高で楽音を発音させる発音制御手段と、表示装置を介して、音高設定手段が設定した候補音高の数を通知する表示制御手段と、を具備する。

なお、上記表示制御手段は、表示装置を介して、音高設定手段が設定した候補音高のなかで発音制御手段が楽音の発音用に未選択となっている候補音高の数を併せて通知する、ことが望ましい。

第２の態様の演奏装置は、演奏パートとしてコードパートの演奏内容を少なくとも示す楽曲データを取得する楽曲データ取得手段と、楽曲データ取得手段が取得した楽曲データを参照し、コードパートで発音させるべきコードの構成音毎に該構成音の音高を候補音高として、演奏の進行に応じて随時、設定する音高設定手段と、複数の演奏操作子のなかのいずれかの演奏操作子が操作された場合に、音高設定手段が設定した候補音高のなかの一つを選択し、該選択した候補音高で楽音を発音させる発音制御手段と、表示装置を介して、音高設定手段が設定した候補音高のなかで発音制御手段が楽音の発音用に未選択となっている候補音高の数を通知する表示制御手段と、を具備する。

本発明の第１、及び第２の態様のプログラムはそれぞれ、上記第１、及び第２の態様の演奏装置が具備する各手段を実現させるための機能を搭載している。

本発明では、演奏パートとしてコードパートの演奏内容を少なくとも示す楽曲データを参照し、コードパートで発音させるべきコードの構成音毎に該構成音の音高を候補音高として、演奏の進行に応じて随時、設定し、複数の演奏操作子のなかのいずれかの演奏操作子が操作された場合に、設定した候補音高のなかの一つを選択し、選択した候補音高で楽音を発音させ、表示装置を介して、設定した候補音高の数を通知する。このため、演奏者は発音させるべき数の構成音（楽音）を正確に発音させることができる。

設定した候補音高の数の代わりに、そのなかで楽音の発音用に未選択となっている候補音高の数、つまり未発音の構成音の数を通知した場合も、演奏者は発音させるべき数の構成音（楽音）を正確に発音させることができる。

何れにおいても、発音させるべき数の楽音を正確に発音させるように演奏者を支援（ガイド）することから、原曲により近い内容の演奏をより容易に行えるようになる。

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

ＣＰＵ１はＲＯＭ２に記録されているプログラムを実行することにより、演奏者（ユーザー）が鍵盤５やスイッチ群６に対して行った操作に応じた制御を行う。鍵盤５への操作が行われた場合には、操作されたキーに割り当てた音高の楽音の発音指示を音源システム４に対して行うことにより、その楽音がスピーカー１２により発音される。スイッチ群６への操作が行われた場合には、操作が行われた操作子に応じて、各種設定を行う。

スイッチ群６への操作により設定可能なモードとして、楽曲データから特定される音高の楽音を鍵盤４へのキー操作により発音させるもの（以降「エニーキーモード」）がある。そのエニーキーモードは本発明に係わるモードである。このことから便宜的に以降、特に断らない限り、そのエニーキーモードが設定されていることを前提に説明する。それにより、そのエニーキーモードで用いられる楽曲データは選択されているものとする。

図２は、ＲＯＭ２に格納された楽曲データの構成とコードパートで行われる画面表示例を説明する図である。図２において、横軸は時間を示し、縦線は小節の区切りを表している。また、メロディパート、リズムパートで横軸方向に延びた形の矩形は、各パートで発音される楽音の発音期間を示している。それにより、例えばメロディパートの先頭に位置する小節では、計五個の楽音を発音させるべきであること、つまりその小節分として、計５個の楽音の発音させるためのデータを楽曲データは有する構成であることを表している。

コードパートでは、矩形の代わりに「Ａｍ」「Ｇ７」が表記されている。それらは発音すべきコードの種類、その構成音を示すコード名である。例えば「Ａｍ」では、「Ａ」はコードのルート（根音）を示し、「ｍ」はコードの種類（ここではマイナー）を示している。それにより、コード名がＡｍのときの構成音はＡ、Ｃ、Ｅの３つである。そのコード名から構成音の音高として、例えばＡ３、Ｃ４、Ｅ４が決定され、それらが候補音高として設定される。コード名がＧ７のときも同様に、例えばＧ３、Ｂ３、Ｄ４、Ｆ４という４つが構成音の音高として決定され、それらが候補音高として設定される。

コード名Ａｍの構成音は３つである。このことから、その発音期間中は、３つの丸を縦に並べてＬＣＤ表示部７、或いはテレビ１４に表示させる。その丸の数は構成音数を表しており、その横に表記の「３」は、構成音のなかで未発音の構成音数を表している。それにより演奏者が、コードの発音のために押鍵すべき押鍵（キー）数、及び押鍵数となるまでの残り分を把握できるようにさせている。その残り分は、丸内の表示色を発音させた構成音の数だけ変更することにより、その表示色からも把握できるようにさせている。これは、他のコードでも同様である。

このようにして本実施形態では、発音させるべき全構成音数、その構成音を全て発音させるために必要な残りの押鍵数を情報として演奏者に視覚的に通知するようにしている。このため、演奏者にとっては、押鍵すべき数だけ正確に押鍵できるようになる。そのような押鍵を行えることにより、発音させるべき楽音のみを正確に発音できるようになることから、原曲に近いコードパートの演奏を演奏者は確実に行えるようになる。なお、以降は、それらの情報は外部のテレビ１４に表示させることを想定する。そのテレビ１４への情報の表示は、例えば１画面分の画像データを作成し、それをビデオシステム８に出力して、その画像データを映像信号に変換させることで行われる。

上記楽曲データは例えばＳＭＦ（Standard MIDI File）形式でＲＯＭ２に格納されている。メロディパート、リズムパートの各データはそれぞれ異なるチャンネルのデータとして楽曲データに格納されている。コードパートでは、上記コード名を示すコード名データをシステムエクスクルーシブメッセージの形で楽曲データに格納されている。ここでは便宜的に、各コード名データ（システムエクスクルーシブメッセージ）はそれを処理すべき箇所に挿入されていることにする。

図形（本実施形態では丸）や表示色による表現と、シンボル（数字）による表現はいずれも視覚的表現の例である。全構成音数や未発音の構成音数の通知は、別の方法を採用しても良い。例えば図形の形状を変更して未発音の構成音数を通知するようにしても良い。或いは全構成音数を数字で表し、発音させた構成音数をその数の図形で表すようにしても良い。このように、様々な変形を行うことができる。

図３は、メイン処理のフローチャートである。そのメイン処理はＲＯＭ２に格納されたプログラムをＣＰＵ１が実行することにより実現される。
ステップＡ１では、イニシャル処理が行われる。具体的には各種変数の初期化等の処理である。ステップＡ１の実行後、ステップＡ２に移行する。

ステップＡ２〜Ａ６は繰り返しループを形成しており、例えば予め定めた時間間隔で繰り返し実行される。
ステップＡ２では、図４に示す自動演奏処理を実行する。これは、楽曲データを読み込み、演奏者が演奏の対象とするコードパートで発音させるべきコードの各構成音の音高を候補音高として設定し、他の演奏パートを自動演奏する処理である。自動演奏処理の実行後、ステップＡ３に移行する。候補音高の設定は、演奏の進行に応じて随時、更新する。

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

ステップＡ４では、音源発音処理を実行する。発音、或いは消音させるべき楽音は、ステップＡ２の自動演奏処理、及びステップＡ３の鍵盤処理の実行によって特定される。音源発音処理は、特定された楽音の発音、或いは消音を音源システム４に対して指示するための処理である。その指示を行うことにより、楽音がスピーカー１２を介して発音される。音源発音処理の実行後、ステップＡ５に移行する。

ステップＡ５では、図９に示す表示処理を実行する。その表示処理を実行することにより、テレビ１４に図２のような画面表示を行わせることが実現される。表示処理の実行後は、ステップＡ６に移行し、スイッチ群６への操作に対応することを含むその他の処理を実行する。その後はステップＡ２に戻る。

設定した候補音高を示す音高データ（以降「鍵盤番号」とも表記する）は、ＲＡＭ３上に確保された領域である候補音高バッファに格納される。図６は、候補音高バッファのデータ構成図である。図６に示すように、そのバッファには、コードの構成音毎に、その音高を示す音高データ、及びその構成音が発音中か否か示すデータである発音済みフラグが格納される。以降、音高データが格納されるフィールドは音高フィールド、発音済みフラグが格納されるフィールドは発音済みフラグフィールドとそれぞれ呼ぶことにする。候補音階バッファに６つの音高データを格納できるようにしたのは、最大で６つの構成音のコードまで想定しているためである。図６中、「音高」「発音済みフラグ」に付した「（０）」等は音高データと発音済みフラグの対応関係を示している。

図４は自動演奏処理のフローチャートである。自動演奏処理は図３のステップＡ２で呼び出される。処理の対象となる楽曲データはＲＯＭ２から読み出してＲＡＭ３に格納したものである。ＳＭＦでは、イベントの内容を示すイベントデータ（ここでは上記コード名データを含む）に、その処理タイミングを示す時間データが付加されている。

ステップＢ１では、次に処理すべきデータが演奏の対象となる演奏パート（ここではコードパート）か否か判定する。そのデータがコードパートのものであった場合、判定はＹＥＳとなってステップＢ２に移行し、そうでない場合には、判定はＮＯとなってステップＢ３に移行する。

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

図５は候補音高取り込み処理のフローチャートである。候補音高取り込み処理は図４のステップＢ２で呼び出され、図６に示す候補音高バッファの設定を行う処理である。
ステップＢ２−１では、時間データが示す処理タイミングとなったイベントデータが有るか否か判定する。そのようなイベントデータ（ここではコード名データ）が存在する場合、判定はＹＥＳとなってステップＢ２−２に移行し、そうでない場合には、判定はＮＯとなり、ここで候補音高取り込み処理を終了する。

ステップＢ２−２では、そのコード名データが発音開始を指示するものか否か判定する。その発音開始を指示するものであった場合、判定はＹＥＳとなってステップＢ２−３に移行し、そうでない場合には、判定はＮＯとなってステップＢ２−４に移行する。

ステップＢ２−３では、コード名データが示すコードの各構成音の音高データを、図６の候補音高バッファの音高フィールドにそれぞれ格納し、発音済みフラグフィールドにはそれぞれ、未発音を示す発音済みフラグを格納する。また、音高データをそれが示す音高によってソートする。そのソートを行った後、この取り込み処理を終了する。

他方のステップＢ２−４では、コード名データが示すコードの各構成音の音高データを、図６の候補音高バッファの音高フィールドからそれぞれクリアし、その音高データに対応する発音済みフラグを発音済みフラグフィールドからそれぞれクリアする。残った音高データが存在すれば、それが示す音高によりソートを行う。そのソートを行った後、この取り込み処理を終了する。ここでは、データをクリアすることをＮＯＤＡＴＡにする、或いはＮＯＤＡＴＡ状態にする、といった表現も用いることにする。

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

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

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

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

ステップＣ４では、候補音高のなかで未発音のものを特定するために候補音高バッファのサーチを行う。その後に移行するステップＣ５では、サーチによって未発音の候補音高が見つかったか否か判定する。候補音高バッファに、発音済みフラグフィールドに未発音を示す発音済みフラグが格納されていた場合、判定はＹＥＳとなってステップＣ６に移行し、そうでない場合には、判定はＮＯとなってステップＣ１３に移行する。

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

ステップＣ７では、演奏者が前回の押鍵時よりも高い音高の楽音を発音させようとしたと見なし、候補音高バッファに格納された音高データのなかで、対応する発音済みフラグが未発音を示し、且つ前回、発音させた構成音の音高データ以上高音の音高データを探す。次にステップＣ８では、そのような音高データが有ったか否か判定する。そのような音高データを探し出せた場合、判定はＹＥＳとなってステップＣ１７に移行し、そうでない場合には、判定はＮＯとなってステップＣ９に移行する。

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

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

ステップＣ１０では、候補音高バッファに格納された音高データのなかで、対応する発音済みフラグが未発音を示し、且つ前回、発音させた構成音の音高データより低音の音高データを探す。次にステップＣ１１では、そのような音高データが有ったか否か判定する。そのような音高データを探し出せた場合、判定はＹＥＳとなってステップＣ１７に移行し、そうでない場合には、判定はＮＯとなってステップＣ１２に移行する。

ステップＣ１２は、コードの構成音に未発音の音が存在するが、その中には前回の押鍵に対応して発音させた構成音の音高データより低音の構成音がない場合に実行される。この場合、未発音の構成音をそのまま発音したのでは、前回の押鍵時よりも高音の構成音を発音させようとしている演奏者の意図には合わない。そこで、ステップＣ１２では、候補音高バッファから、未発音の構成音のなかで最高音の構成音の音高データをサーチにより抽出し、その構成音を１オクターブ下げた音高で発音させるよう設定する（オクターブＤＯＷＮ変換を実行する）。それにより、演奏者の意図を反映しつつ自然と感じられるようにコードの構成音を発音させる。その後はステップＣ１７に移行する。

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

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

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

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

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

ステップＣ１７に移行時には、発音させる楽音の音高が決定している。その音高は、候補音高、それよりも１オクターブ上の音高、或いは１オクターブ下の音高である。ステップＣ１７では、決定した音高の楽音を発音させるために音源システム４に出力するコマンド（例えばＭＩＤＩデータ）を生成し、ＲＡＭ３上に確保した領域に格納する。また、ＡｎｙＫｅｙバッファのステップＣ２で探した空き領域の各フィールドに、今回押鍵されたキーの鍵盤番号、候補音高を示す音高データをそれぞれ格納する。続くステップＣ１８では、図８（ｂ）の前回押鍵バッファを更新する。つまり、今回押鍵されたキーの鍵盤番号を鍵盤フィールドに格納し、今回の押鍵により実際に発音させた構成音の音高データを音高フィールドに格納する。次のステップＣ１９では、その音高データに対応する発音済みフラグを発音中のものに更新する。その後、鍵盤処理を終了する。

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

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

ステップＣ２３では、ＡｎｙＫｅｙバッファに、クリアした音高データと同じ音名の音高データを音高フィールドに格納した領域が存在しないか否か判定する。クリアした音高データと同じ音名の音高データで他に発音中のものが有る場合、その音高データが一つ以上ＡｎｙＫｅｙバッファに残っている。このことから、判定はＮＯとなり、ここで鍵盤処理を終了する。そうでない場合には、判定はＹＥＳとなってステップＣ２４に移行し、候補音高バッファでその音高データに対応する発音済みフラグを未発音のものに更新する。その更新を行った後、鍵盤処理を終了する。

なお、コードを発音させるための押鍵を開始する前は、前回押鍵バッファはＮＯＤＡＴＡ状態である。その場合、例えば構成音のなかで最低音の構成音といったように、予め定めた規則に従って構成音（候補音高）が選択される。

複数の押鍵を同時に行うべき状況下で、全ての押鍵が同時に行われるとは限らない。このことから、前後に押鍵されたキーの音高関係に着目して構成音を選択するのではなく、一定時間の間に押鍵されたキーを全て考慮する形で構成音を選択するようにしても良い。コードによって構成音は異なり、発音させるコード（の構成音）は常に同じものとは限らない。それにより、前のコードの影響を回避するためには、前回押鍵バッファは候補音階バッファ２の更新に応じてクリアすることが望ましい。

図９は表示処理のフローチャートである。表示処理は図３のステップＡ５で呼び出される。表示処理を実行することにより、発音させるべきコードの全構成音数、構成音のなかで未発音の構成音数が情報としてテレビ１４に表示される。

ステップＤ１では、発音すべきコードが存在していれば、その全構成音数分の丸を、発音中か否かで変更する表示色とすることにより、候補音高バッファの内容を表示する。次のステップＤ２では、未発音の構成音数、つまり未発音を示す発音済みフラグの数をカウントし、そのカウント結果を表示する。その後、表示処理を終了する。

ステップＤ１、Ｄ２の処理を実行することにより、図２に示すような画像を表示させるための画像データが作成され、ビデオシステム８に出力される。それにより、図２に示すような画像がテレビ１４に表示される。

図１０は、演奏者の演奏によって更新される表示内容、及び各バッファの内容の変化を説明する図である。図１０の（Ａ）〜（Ｄ）はそれぞれ、コードを発音開始すべき時点、演奏者がその後、１回目の操作（押鍵）を行った時点、２回目の操作（押鍵）を行った時点、及び３回目の操作（押鍵）を行った時点を示している。

（Ａ）の時点では、構成音の音高データ（音名）が降順に候補音高バッファに格納されている。全ての発音済みフラグは未発音を示すもの（図中「ＯＦＦ」と表記。発音中を示すものは「ＯＮ」と表記する）となっている。このとき、ＡｎｙＫｅｙバッファは格納されたデータが存在しない状態となっている。画面表示は、未発音の表示色で３つの丸が表示され、その隣に「３」が表示されている。

（Ｂ）の時点では、音高データ（音名）として「Ａ３」を表記した列の発音済みフラグがＯＮとなっている。ＡｎｙＫｅｙバッファの１列には、演奏者が操作したキーの鍵盤番号（図中「鍵１」と表記）、及び音高データとして「Ａ３」が格納されている。画面表示は、未発音の表示色で２つの丸、発音中の表示色で１つの丸が表示され、その隣に「２」が表示されている。

（Ｃ）の時点では、音高データ（音名）として「Ｃ４」を表記した列の発音済みフラグが更にＯＮとなっている。ＡｎｙＫｅｙバッファには、演奏者が操作したキーの鍵盤番号（図中「鍵２」と表記）、及び音高データとして「Ｃ４」が格納されている列が追加されている。画面表示は、未発音の表示色で１つの丸、発音中の表示色で２つの丸が表示され、その隣に「１」が表示されている。ここでは、音高関係は鍵１＜鍵２を想定している。

（Ｄ）の時点では、音高データ（音名）として「Ｅ４」を表記した列の発音済みフラグが更にＯＮとなっている。それにより、候補音高バッファの内容は、全ての構成音が発音中であることを示すものとなっている。ＡｎｙＫｅｙバッファには、演奏者が操作したキーの鍵盤番号（図中「鍵３」と表記）、及び音高データとして「Ｅ３」が格納されている列が追加されている。画面表示は、発音中の表示色で３つの丸が表示され、その隣に「０」が表示されている。

この時点では、音高関係は鍵２＞鍵３を想定している。このため、構成音は本来のＥ４では発音されず、１オクターブ下のＥ３で発音されている。それにより、ＡｎｙＫｅｙバッファでの鍵盤番号の並びは、下から鍵３、鍵１、鍵２の順となっている。

このように、画面表示内容、及び各バッファの内容は、演奏者が行った操作により随時、更新される。それにより、演奏者が常に、発音させるべきコードの全構成音数、そのなかで未発音の構成音数を確認できるようにさせている。このため、演奏者は発音させるべき数の楽音を確実に発音できるようになる。それにより、原曲に近い演奏も容易に行うことができる。

なお、本実施形態では、発音させるべきコードを示すコード名データを楽曲データ中に有するものを想定しているが、その楽曲データは、コードの構成音の発音期間を個別に示すものであっても良い。そのような楽曲データでは、例えば以下のように画面表示、及び各バッファの更新を行うようにすれば良い。図１１を参照して具体的に説明する。

図１１は、楽音の発音期間を個別に示す楽曲データの場合に、演奏者の演奏によって更新される表示内容、及び各バッファの内容の変化を説明する図である。図２と同様に、横軸は時間、縦線は小節の区切り、細長い形状の３つの矩形は対応する楽音（構成音）の発音期間をそれぞれ示している。その３つの矩形は、楽音の発音期間を個別に管理しているために、発音開始、及び発音終了のタイミングが３つの構成音でそれぞれ異なっていることを表している。

図１１の（Ａ）〜（Ｅ）はそれぞれ、コードを発音開始すべき時点、つまり１つめの構成音を発音開始すべき時点、２つめの構成音の発音開始すべき時点、コードの演奏者が１回目の操作（押鍵）を行った時点、３つめの構成音を発音開始すべき時点、及び２回目の操作（押鍵）を行った時点、を示している。

（Ａ）の時点では、１構成音の音高データ（音名）が候補音高バッファに格納されている。発音済みフラグはＯＦＦとなっている。このとき、ＡｎｙＫｅｙバッファは格納されたデータが存在しない状態となっている。画面表示は、未発音の表示色で１つの丸が表示され、その隣に「１」が表示されている。

（Ｂ）の時点では、候補音高バッファに、音高データ（音名）として「Ｃ４」、ＯＦＦの発音済みフラグを格納した列が追加されている。このときもＡｎｙＫｅｙバッファは格納されたデータが存在しない状態となっている。画面表示は、未発音の表示色の丸が１つ追加されて表示され、その隣に「２」が表示されている。

（Ｃ）の時点では、音高データ（音名）として「Ａ３」を表記した列の発音済みフラグがＯＮとなっている。ＡｎｙＫｅｙバッファには、演奏者が操作したキーの鍵盤番号（図中「鍵１」と表記）、及び音高データとして「Ａ３」が格納されている列が追加されている。画面表示は、未発音の表示色で１つの丸、発音中の表示色で１つの丸が表示され、その隣に「１」が表示されている。候補音高バッファで「Ａ３」が格納されている列の発音済みフラグがＯＮなので、２つの丸のうち下に位置する丸が発音中の表示色となっている。

（Ｄ）の時点では、候補音高バッファに、音高データ（音名）として「Ｅ４」、ＯＦＦの発音済みフラグを格納した列が更に追加されている。ＡｎｙＫｅｙバッファは（Ｃ）の時点から変化していない。画面表示は、未発音の表示色の丸が１つ上に追加されて表示され、その隣に「２」が表示されている。

（Ｅ）の時点では、音高データ（音名）として「Ｅ４」を表記した列の発音済みフラグが更にＯＮとなっている。ＡｎｙＫｅｙバッファには、演奏者が操作したキーの鍵盤番号（図中「鍵２」と表記）、及び音高データとして「Ｅ３」が格納されている列が追加されている。画面表示は、未発音の表示色の丸が中央の一つ、その上下の丸が発音中の表示色となっている。その隣に「１」が表示されている。

この時点では、音高関係は鍵１＞鍵２を想定している。このため、構成音は本来のＥ４では発音されず、１オクターブ下のＥ３で発音されている。それにより、ＡｎｙＫｅｙバッファでの鍵盤番号の並びは、下から鍵２、鍵１の順となっている。

楽音の発音期間を個別に管理する場合、楽曲データ中のデータを時間データに従って順次処理していくと、コードの全構成音数は最後の構成音のデータを処理するまで特定することはできない。このため、データの処理に応じて画面表示内容、及び各バッファの内容を更新するようにしている。或る一定時間分、先のデータまで読み出し、コードの全構成音を確認するようにした場合には、コード名データを用いる場合と同様な制御を行うこともできる。また、今回、発音させるべきコードのみでなく、それ以降に発音させるべきコードの情報（発音の対象ではないので、全構成音数のみとなる）を事前に表示させることもできるようになる。情報の表示としては、コードの全構成音数、及び未発音の構成音数のうちの何れか一方のみを表示するようにしても良い。一方のみの情報を表示させたとしても、発音させるべき数の楽音を正確に発音できるように演奏者を支援することができる。

本実施形態では、演奏対象をコードパートとしているが、複数の楽音を同時に発音させる状況がありうるパートであれば、そのパートを演奏対象としても良い。また、複数の演奏パートを対象にするようにしても良い。

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

本実施形態による演奏装置の構成図である。 楽曲データの構成とコードパートで行われる画面表示例を説明する図である。 メイン処理のフローチャートである。 自動演奏処理のフローチャートである。 候補音高取り込み処理のフローチャートである。 候補音高バッファのデータ構成図である。 鍵盤処理のフローチャートである。 ＡｎｙＫｅｙバッファおよび前回押鍵バッファのデータ構成図である。 表示処理のフローチャートである。 演奏者の演奏によって更新される表示内容、及び各バッファの内容の変化を説明する図である。 楽音の発音期間を個別に示す楽曲データの場合に、演奏者の演奏によって更新される表示内容、及び各バッファの内容の変化を説明する図である。

符号の説明

２０ 演奏装置
１ ＣＰＵ
２ ＲＯＭ
３ ＲＡＭ
４ 音源システム
５ 鍵盤
６ スイッチ群
７ ＬＣＤ表示部
８ ビデオシステム
９ バス
１０ ミキサー回路
１１ マイク
１２ スピーカー
１３ ビデオ端子
１４ テレビ

Claims (5)

1. 演奏者が演奏を行うための複数の演奏操作子を備えた演奏装置において、
   演奏パートとしてコードパートの演奏内容を少なくとも示す楽曲データを取得する楽曲データ取得手段と、
   前記楽曲データ取得手段が取得した楽曲データを参照し、前記コードパートで発音させるべきコードの構成音毎に該構成音の音高を候補音高として、演奏の進行に応じて随時、設定する音高設定手段と、
   前記複数の演奏操作子のなかのいずれかの演奏操作子が操作された場合に、前記音高設定手段が設定した候補音高のなかの一つを選択し、該選択した候補音高で楽音を発音させる発音制御手段と、
   表示装置を介して、前記音高設定手段が設定した候補音高の数を通知する表示制御手段と、
   を具備することを特徴とする演奏装置。
2. 前記表示制御手段は、前記表示装置を介して、前記音高設定手段が設定した候補音高のなかで前記発音制御手段が楽音の発音用に未選択となっている候補音高の数を併せて通知する、
   ことを特徴とする請求項１に記載の演奏装置。
3. 演奏者が演奏を行うための複数の演奏操作子を備えた演奏装置において、
   演奏パートとしてコードパートの演奏内容を少なくとも示す楽曲データを取得する楽曲データ取得手段と、
   前記楽曲データ取得手段が取得した楽曲データを参照し、前記コードパートで発音させるべきコードの構成音毎に該構成音の音高を候補音高として、演奏の進行に応じて随時、設定する音高設定手段と、
   前記複数の演奏操作子のなかのいずれかの演奏操作子が操作された場合に、前記音高設定手段が設定した候補音高のなかの一つを選択し、該選択した候補音高で楽音を発音させる発音制御手段と、
   表示装置を介して、前記音高設定手段が設定した候補音高のなかで前記発音制御手段が楽音の発音用に未選択となっている候補音高の数を通知する表示制御手段と、
   を具備することを特徴とする演奏装置。
4. 演奏者が演奏を行うための複数の演奏操作子を備えた演奏装置として用いることが可能なコンピュータに実行させるプログラムであって、
   演奏パートとしてコードパートの演奏内容を少なくとも示す楽曲データを取得する楽曲データ取得機能と、
   前記楽曲データ取得機能により取得した楽曲データを参照し、前記コードパートで発音させるべきコードの構成音毎に該構成音の音高を候補音高として、演奏の進行に応じて随時、設定する音高設定機能と、
   前記複数の演奏操作子のなかのいずれかの演奏操作子が操作された場合に、前記音高設定機能により設定した候補音高のなかの一つを選択し、該選択した候補音高で楽音を発音させる発音制御機能と、
   表示装置を介して、前記音高設定機能により設定した候補音高の数を通知する表示制御機能と、
   を実現させるためのプログラム。
5. 演奏者が演奏を行うための複数の演奏操作子を備えた演奏装置として用いることが可能なコンピュータに実行させるプログラムであって、
   演奏パートとしてコードパートの演奏内容を少なくとも示す楽曲データを取得する楽曲データ取得機能と、
   前記楽曲データ取得機能により取得した楽曲データを参照し、前記コードパートで発音させるべきコードの構成音毎に該構成音の音高を候補音高として、演奏の進行に応じて随時、設定する音高設定機能と、
   前記複数の演奏操作子のなかのいずれかの演奏操作子が操作された場合に、前記音高設定機能により設定した候補音高のなかの一つを選択し、該選択した候補音高で楽音を発音させる発音制御機能と、
   表示装置を介して、前記音高設定機能により設定した候補音高のなかで前記発音制御機能による楽音の発音用に未選択となっている候補音高の数を通知する表示制御機能と、
   を実現させるためのプログラム。

Images