米国特許情報 | 欧州特許情報 | 国際公開(PCT)情報 | Google の米国特許検索
 
     特許分類
A 農業
B 衣類
C 家具
D 医学
E スポ−ツ;娯楽
F 加工処理操作
G 机上付属具
H 装飾
I 車両
J 包装;運搬
L 化学;冶金
M 繊維;紙;印刷
N 固定構造物
O 機械工学
P 武器
Q 照明
R 測定; 光学
S 写真;映画
T 計算機;電気通信
U 核技術
V 電気素子
W 発電
X 楽器;音響


  ホーム -> 楽器;音響 -> カシオ計算機株式会社

発明の名称 楽音発生装置、及びプログラム
発行国 日本国特許庁(JP)
公報種別 公開特許公報(A)
公開番号 特開2007−140067(P2007−140067A)
公開日 平成19年6月7日(2007.6.7)
出願番号 特願2005−333101(P2005−333101)
出願日 平成17年11月17日(2005.11.17)
代理人 【識別番号】100074099
【弁理士】
【氏名又は名称】大菅 義之
発明者 副島 淳一郎
要約 課題
演奏操作子への操作の有無に係わらず、操作期間となった演奏操作子の存在を音によって通知できる楽音発生装置を提供する。

解決手段
楽音発生装置10には、キーボード22を有する電子楽器20が接続されている。ROM13には、演奏の進行に応じて順次、操作していくべき鍵、及びその鍵を操作しているべき操作期間を鍵単位で示す演奏情報が格納されている。CPU11は、演奏情報を参照して、操作期間、その期間となった鍵を特定し、その操作期間全体で楽音を発音させる。ユーザーが行った演奏操作は入力するMIDIデータから認識し、その操作期間内に適切と言える押鍵を行っている間は押鍵された鍵に応じた楽音を発音させる。それ以外では、その楽音とは異なる種類の楽音を発音させる。それにより、操作期間、及び適切と言える押鍵を行っている間を発音させる楽音により認識可能とさせる。
特許請求の範囲
【請求項1】
演奏操作子群のなかで操作された演奏操作子に応じた楽音を発音させる楽音発音装置において、
前記演奏操作子群のなかで演奏の進行に応じて順次、操作していくべき演奏操作子、及び該演奏操作子を操作しているべき操作期間を該演奏操作子単位で示す演奏情報を取得する演奏情報取得手段と、
前記演奏操作子群への操作を検出するための操作検出手段と、
前記演奏情報取得手段が取得した演奏情報が示す操作期間、及び演奏操作子、並びに該演奏操作子に対する操作の前記操作検出手段による検出結果を基に、該操作期間内に発音させる楽音の種類を1つ以上決定し、該決定した1つ以上の種類の楽音を少なくとも該操作期間内にわたって発音させる発音制御手段と、
を具備することを特徴とする楽音発生装置。
【請求項2】
前記発音制御手段は、前記操作期間の演奏操作子に対する操作開始を前記操作検出手段により検出したタイミングが該操作期間の開始タイミングと許容範囲内で一致しているか否かによって異なる種類の楽音を選択し該操作期間内で発音させる、
ことを特徴とする請求項1記載の楽音発生装置。
【請求項3】
前記発音制御手段は、前記操作期間の演奏操作子に対する操作を前記操作検出手段が検出していた検出期間が該操作期間内であった場合、該操作期間内の該検出期間外の期間は操作すべき演奏操作子を操作していないことを通知する種類の楽音を発音させる、
ことを特徴とする請求項1、または2記載の楽音発生装置。
【請求項4】
前記演奏操作子群が鍵盤であった場合、前記操作検出手段は、該鍵盤を構成する鍵の押鍵時の速さを併せて検出し、
前記発音制御手段は、前記操作検出手段が検出した速さを考慮して前記操作期間内で発音させる楽音の操作を行う、
ことを特徴とする請求項1、2、または3記載の楽音発生装置。
【請求項5】
演奏操作子群のなかで操作された演奏操作子に応じた楽音を発音させる楽音発音装置に実行させるプログラムであって、
前記演奏操作子群のなかで演奏の進行に応じて順次、操作していくべき演奏操作子、及び該演奏操作子を操作しているべき操作期間を該演奏操作子単位で示す演奏情報を取得する機能と、
前記演奏操作子群への操作を検出するための機能と、
前記取得する機能により取得した演奏情報が示す操作期間、及び演奏操作子、並びに該演奏操作子に対する操作の前記検出するための機能による検出結果を基に、該操作期間内に発音させる楽音の種類を1つ以上決定し、該決定した1つ以上の種類の楽音を少なくとも該操作期間にわたって発音させる機能と、
を実現させるためのプログラム。
発明の詳細な説明
【技術分野】
【0001】
本発明は、演奏操作子群のなかで操作された演奏操作子に応じた楽音を発音させる楽音発音装置に関する。
【背景技術】
【0002】
鍵盤などの演奏操作子群への操作に応じた楽音を発生させる楽音発生装置は様々な形で実現される。その演奏操作子群を備えた楽音発生装置のなかには、演奏の進行に応じて操作していくべき演奏操作子を視覚的にガイドする演奏ガイド機能を搭載したものがある。その演奏ガイド機能によるガイドは、演奏操作子群のなかで演奏の進行に応じて順次、操作していくべき演奏操作子、及びその演奏操作子を操作しているべき操作期間を演奏操作子単位で示す演奏情報を参照して行われる。その操作期間とは、演奏操作子への操作を開始すべきタイミングからその操作を解除すべきタイミングとなる期間のことである。
【0003】
上記演奏ガイド機能を搭載した楽音発生装置としては、例えば特許文献1、2にそれぞれ記載されたものが挙げられる。視覚的なガイドに用いられる表示装置は、演奏操作子毎に発光素子を配置したもの(特許文献1)と、1箇所(エリア)で操作すべき演奏操作子を示すことができるもの(特許文献1、2)と、に大別できる。
【0004】
特許文献1、2にそれぞれ記載された従来の楽音発生装置では、表示装置によるガイドに従って演奏操作子群への操作を行うことにより、楽曲を正しく演奏できる。演奏操作子群のなかでガイドされた演奏操作子を正しいタイミングで操作したか否かは、その演奏操作子を実際に操作したタイミングと表示装置によるガイドが行われたタイミングとからユーザー(演奏者)は確認することができる。しかし、その確認を行うためには、演奏の進行に合わせてガイド内容を随時、変化させる表示装置をユーザーは常に注意していなければならない。これはユーザーにとっては重い負担となり、演奏に集中できなくさせる可能性もある。このことから、表示装置を見ることなく、正しく演奏操作子を操作したか否か確認できるようにすることも重要であると言える。
【0005】
表示装置を見ることなく、正しく演奏操作子を操作したか否か確認できるようにした従来の楽音発生装置としては、例えば特許文献3に記載されたものがある。その特許文献3に記載された従来の楽音発生装置では、ユーザーが操作した演奏操作子が操作期間内の演奏操作子か否かより異なる音を発音させるようになっている。それにより、ユーザーが操作すべき演奏操作子を操作すべき操作タイミングで操作すればその演奏操作子に応じた楽音(通常音)を発音させ、そうでなければその楽音とは音色の異なる警告音を発音させている。
【0006】
上記のように発音させる音を変化させることにより、操作期間となった演奏操作子を操作したか否かの確認をユーザーは発音される音から迅速に行うことができる。しかし、通常音、或いは警告音の発音は、演奏操作子への操作によって行うため、演奏操作子を操作していない間に操作期間が経過した演奏操作子の存在やその操作期間は発音された音から認識することができない。このことから、正しく演奏操作子を操作したか否かを音によって確認できるようにする場合には、操作期間に演奏操作子をユーザーが操作しなかったときのことも想定すべきと考えられる。
【0007】
特許文献4には、演奏操作子への操作によって発音させる楽音の音量を制御する従来の楽音発生装置が記載されている。音量を制御することにより、演奏操作子への操作が適切に行われたか否かを通知することができる。しかし、特許文献3に記載された従来の楽音発生装置と同様に、演奏操作子を操作していない間に操作期間が経過した演奏操作子の存在やその操作期間は発音させた音からユーザーに認識させることができない。
【特許文献1】特開平10−97181号公報
【特許文献2】特開2004−85821号公報
【特許文献3】実開昭60−150577号公報
【特許文献4】特開2004−205892号公報
【発明の開示】
【発明が解決しようとする課題】
【0008】
本発明の課題は、演奏操作子への操作の有無に係わらず、操作期間となった演奏操作子の存在を音によって通知できる楽音発生装置を提供することにある。
【課題を解決するための手段】
【0009】
本発明の楽音発生装置は、演奏操作子群のなかで操作された演奏操作子に応じた楽音を発音させることを前提とするものであり、演奏操作子群のなかで演奏の進行に応じて順次、操作していくべき演奏操作子、及び該演奏操作子を操作しているべき操作期間を該演奏操作子単位で示す演奏情報を取得する演奏情報取得手段と、演奏操作子群への操作を検出するための操作検出手段と、演奏情報取得手段が取得した演奏情報が示す操作期間、及び演奏操作子、並びに該演奏操作子に対する操作の操作検出手段による検出結果を基に、該操作期間内に発音させる楽音の種類を1つ以上決定し、該決定した1つ以上の種類の楽音を少なくとも該操作期間内にわたって発音させる発音制御手段と、を具備する。
【0010】
なお、上記発音制御手段は、操作期間の演奏操作子に対する操作開始を操作検出手段により検出したタイミングが該操作期間の開始タイミングと許容範囲内で一致しているか否かによって異なる楽音を選択し該操作期間内で発音させる、ことが望ましい。また、操作期間の演奏操作子に対する操作を操作検出手段が検出していた検出期間が該操作期間内であった場合、該操作期間内の該検出期間外の期間は操作すべき演奏操作子を操作していないことを通知する種類の楽音を発音させる、ことが望ましい。上記演奏操作子群が鍵盤であった場合、操作検出手段は、該鍵盤を構成する鍵の押鍵時の速さを併せて検出し、発音制御手段は、操作検出手段が検出した速さを考慮して状況下で発音させる楽音の操作を行う、ことが望ましい。
【0011】
本発明のプログラムは、上記楽音発生装置が具備する各手段を実現させるための複数の機能を搭載している。
【発明の効果】
【0012】
本発明は、演奏操作子群のなかで演奏の進行に応じて順次、操作していくべき演奏操作子、及びその演奏操作子を操作しているべき操作期間を演奏操作子単位で示す演奏情報を参照し、その操作期間を示す演奏操作子が存在する状況下で楽音を発音させる。その楽音の種類は、操作期間となった演奏操作子に対して行われた操作に応じて選択し決定する。
【0013】
具体的には例えば、適切と言えるタイミングで操作が開始された場合、そのことを通知するための楽音を選択し、そうでない場合には、不適切なタイミングで操作が開始したことを通知するための楽音を選択する。このとき、操作期間が到来した後(操作期間が開始するタイミングとなった後)に操作が開始されたのであれば、操作期間の開始から操作が実際に開始されるまでの間は操作が遅れたことを通知するための楽音を発音させる。一方、操作期間が過ぎる前(操作期間が終了するタイミングとなる前)に操作が解除されたのであれば、不適切なタイミングで操作が解除されたことを通知するための楽音をその操作期間が過ぎるまでは少なくとも発音させる。そのように発音させる種類の楽音を1つ以上、選択・決定し、操作期間内にわたって(操作期間の開始から終了まで)発音させる。このため、演奏操作子への操作の有無に係わらず、ユーザーは操作期間となった演奏操作子の存在を音によって容易に認識することができる。また、自身が適切に操作を行った期間も容易に確認することができる。
【発明を実施するための最良の形態】
【0014】
以下、本発明の実施の形態について、図面を参照しながら詳細に説明する。
<第1の実施の形態>
図1は、第1の実施の形態による楽音発生装置の構成を説明する図である。
【0015】
その楽音発生装置10は、図1に示すように、装置10全体の制御を行うCPU11と、そのCPU11がワークに用いるRAM12と、CPU11が実行するプログラムや各種制御用データ、及び波形データ等を格納したROM103と、例えばキーボードやポインティングデバイス(マウス等)、CD−ROMやDVD等の記録媒体にアクセスする媒体駆動装置、及びそれらのインターフェース等からなる入力部14と、表示装置に画像を表示させる表示部15と、外部装置との間でMIDIデータを送受信するためのMIDIインターフェース(I/F)16と、発音させる楽音のデジタルデータ(波高値)を外部装置に出力するためのオーディオインターフェース(I/F)17と、を備えた構成となっている。
【0016】
上記MIDI I/F16には、それとMIDIデータを送受信可能なMIDIインターフェース(I/F)21、及びキーボード22を備えた電子楽器20が接続され、上記オーディオI/F17には、波高値を入力して音声に変換できる音源システム30が接続されている。MIDI I/F21は、キーボード22に対する操作内容を示すMIDIデータを生成する機能を備えている。それにより、本実施の形態による楽音発生装置10は、電子楽器20のMIDI I/F21からMIDIデータを入力して、そのMIDIデータにより発音が要求された楽音の波高値を生成し、それを音源システム30に出力することにより楽音を発音させるようになっている。音源システム30は、例えばD/A変換器、アンプ、及びスピーカを少なくとも備えたものである。
【0017】
その楽音発生装置10は、例えばパーソナルコンピューター(PC)に、楽音発生装置10として動作させるためのアプリケーション・プログラム(以下「アプリケーション」)を搭載させることにより実現させている。そのアプリケーションは、例えば入力部14を構成する媒体駆動装置がアクセス可能な記録媒体に記録して提供するものである。そのアプリケーションは、インターネット等のネットワークを介して配信するようにしても良い。
【0018】
アプリケーションを搭載(インストール)できるように、ROM13としては書き込み可能なメモリ(例えばフラッシュメモリ)が採用されている。そのアプリケーションが記録された記録媒体には、楽音の波高値を生成するための各種波形データが多数、記録されている。その波形データには、音色が異なる楽音発音用のものも含まれている。音色が同じ波形データはピッチ毎に用意されている。楽音発生装置10を実現させるPCは、ROM13の他に、或いはその代わりにハードディスク装置等の補助記憶装置を搭載したものであっても良い。そのアプリケーションについては以降「楽音発生アプリケーション」と呼ぶことにする。
【0019】
各種波形データは、ROM13に保存させることができるようになっている。また、必要に応じて、記録媒体からコピーすることもできるようにしている。ここでは説明上、便宜的にROM13に保存されている場合のみを想定する。
【0020】
ROM13に保存した波形データは、RAM12にコピーして使用している。これは、一般的にRAM12はROM13よりもアクセス速度が速いからである。それにより、より高速に、発音させるべき楽音の波高値を生成できるようにしている。
【0021】
波形データをピッチ毎に用意することにより、それを構成するサンプリングデータ(波高値)は単に順次、読み出せば良いようにしている。それにより、データを読み出す速さ(歩進幅)に応じた補間を行わなくとも良いようにしている。
【0022】
ユーザーは、電子楽器20のキーボード22を操作して演奏を行う。その演奏では、演奏の進行に合わせて、キーボード22を構成する鍵のなかで押鍵(操作)すべき鍵を順次、押鍵していくことが求められる。本実施の形態では、押鍵すべき鍵を適切(正確)に押鍵できたか否かユーザーが認識できるように、楽音の発音制御を行うようにしている。押鍵すべき鍵、その押鍵を行っているべき操作期間(押鍵から離鍵までの期間。以降「押鍵時間」と呼ぶ)は、それらを鍵(楽音)単位で示す演奏情報を参照して特定している。
【0023】
図7は、楽音の発音制御によって発音される楽音を説明する図である。その図7では、演奏情報が示す或る鍵の押鍵時間が到来、つまり押鍵すべきタイミングとなった時点より時間aだけ早くユーザーが押鍵した場合(ケース1)、そのタイミングより時間bだけ遅れてユーザーが押鍵した場合(ケース2)、及び離鍵すべきタイミングとなってもユーザーが離鍵しなかった場合(ケース3)に発音される楽音を示している。
【0024】
ケース1では、ユーザーの押鍵時間は押鍵すべきタイミングの時間a前から離鍵すべきタイミングが到来する前となっている。そのような押鍵時間でユーザーが押鍵を行うと、時間aが押鍵すべきタイミングと一致すると見なせるだけ短ければ、その押鍵時間内はユーザーが押鍵した鍵に割り当てた楽音(以降「設定音」と呼ぶ)を発音させ、それ以降は、演奏情報が示す押鍵時間が終了するまで、その楽音とは異なる音色の楽音(以降「警告音」と呼ぶ)を発音させる。その時間aが押鍵すべきタイミングと一致すると見なせるだけ短くなければ、演奏情報が示す押鍵時間内、全てにわたって警告音を発音させる。
【0025】
ケース2では、ユーザーの押鍵時間は押鍵すべきタイミングの時間b後から離鍵すべきタイミングが到来する前となっている。そのような押鍵時間でユーザーが押鍵を行うと、時間bが押鍵すべきタイミングと一致すると見なせるだけ短ければ、その時間b内、及びユーザーが離鍵してから演奏情報が示す押鍵時間が終了するまでの間は警告音を発音させ、残りの時間、つまりユーザーの押鍵時間内は設定音を発音させる。その時間bが押鍵すべきタイミングと一致すると見なせるだけ短くなければ、演奏情報が示す押鍵時間内、全てにわたって警告音を発音させる。
【0026】
ケース3では、ユーザーの押鍵時間は押鍵すべきタイミングから離鍵すべきタイミングの後となっている。そのような押鍵時間でユーザーが押鍵を行うと、演奏情報が示す押鍵時間内は設定音を発音させ、離鍵すべきタイミングからユーザーが実際に離鍵するまでの間は何れの楽音も発音させない。つまり無音とさせる。
【0027】
このようにして、本実施の形態では、ユーザーが押鍵を行ったタイミングが適切と見なせるか否かにより、その押鍵によって楽音の種類を選択して発音させ、ユーザーが離鍵を行ったタイミングにより、警告音の発音、或いは発音中の設定音の消音を行う。このため、ユーザーは、発音された楽音から、自身が押鍵、及び離鍵のそれぞれを適切なタイミングで行ったか否か容易に認識することができるようになっている。たとえ押鍵を行わなくとも演奏情報が示す押鍵時間内は警告音が発音されるため(ケース2の時間bが短くないと見なしたときと同じとなる)、押鍵すべき鍵の存在、及びその押鍵時間をユーザーは認識することができる。以降、混乱を避けるため、ユーザーによる押鍵時間を「実押鍵時間」、演奏情報が示す押鍵時間を「正押鍵時間」と表記する。
【0028】
図7に示すような発音制御を行うために、本実施の形態では図2〜図6に示す各種データを管理している。ここで図2〜図6を参照して、それらのデータについて具体的に説明する。また、説明上、便宜的に、以降の説明では特に断らない限り、その発音制御を行うことを前提とする。その発音制御によりユーザーに音声で演奏内容を知らせることを「発音ガイド」と呼ぶことにする。
【0029】
図2は、音色データの構成を説明する図である。その音色データは、波形データを音色単位で管理するために音色毎に用意されるデータである。図2に示すように、音色データは、対応するチャンネル番号を示すデータiID、発音中の楽音数を示すデータiNoteOnCnt、対応するピッチデータのなかで先頭ピッチ(例えば最低ピッチ)のピッチデータの格納場所を示すデータpTD、前の音色データの格納場所を示すデータpPrev、及び次の音色データの格納場所を示すデータpNext、を備えている。
【0030】
図3は、ピッチデータの構成を説明する図である。そのピッチデータは、音色毎、ピッチ毎に用意されるデータであり、上記データpTDとしては、対応する音色での先頭ピッチのピッチデータの格納場所を示すデータがそれぞれの音色データに格納される。図3に示すように、ピッチデータは、対応するピッチを示すデータiPitch(ピッチ番号(ノートナンバー))、対応するソースデータの格納場所を示すデータpSD、前のピッチデータの格納場所を示すデータpPrev、及び次のピッチデータの格納場所を示すデータpNext、を備えている。
【0031】
図4は、ソースデータの構成を説明する図である。そのソースデータは、波形データ毎に用意されるデータである。図4に示すように、ソースデータは、対応する波形データのRAM12にコピーされた波形データの先頭アドレスを示すデータpDAta、波形データのファイル名(オリジナルの格納場所)を示すデータfileName、その波形データ全体の長さを示すデータfLength、波形データが対応するベロシティ範囲の下限値を示すデータminVel、その上限値を示すデータmaxVel、前のピッチデータの格納場所を示すデータpPrev、及び次のピッチデータの格納場所を示すデータpNext、を備えている。
【0032】
発音させる楽音の種類の変更は、その発音に用いる波形データを変更することで行うようにしている。そのため、上記データpDAta、fileName、及びfLengthは、発音対象となる楽音の種類毎に格納している。
【0033】
図5は、発音データの構成を説明する図である。その発音データは、演奏情報が示す、演奏中に発音させるべき楽音毎に用意されるデータである。図5に示すように、発音データは、識別情報であるデータiID、対応する音色データ(チャンネル)を示すデータiTone(例えば対応する音色データ中のデータiID)、楽音のピッチを示すデータiPitch、そのベロシティを示すデータiOnVel、そのピッチの楽音の状態を示すデータiStatus(−1の値は消音中、0の値は消音状態、1の値は演奏情報が示す押鍵時間であり、且つユーザーが押鍵中である状態、2の値は演奏情報が示す押鍵時間であり、且つユーザーが押鍵していない状態(押鍵が遅れている状態)、3の値は演奏情報が示す押鍵時間でなく、且つユーザーが押鍵中である状態(押鍵が早く行われたような状態)、をそれぞれ表す)、対応する演奏データの格納場所を示すデータpME、対応するソースデータの格納場所を示すデータpSD、対応する演奏データによる発音開始時刻を示すデータlOnStart、その消音開始時刻を示すデータlOffStart、ユーザーによる押鍵時刻(タイミング)を示すデータlNoteOn、その離鍵時刻(タイミング)を示すデータlNoteOff、消音処理中での減衰率を示すデータfRelease、前の発音データの格納場所を示すデータpPrev、及び次の発音データの格納場所を示すデータpNext、を備えている。上記データiOnVelは電子楽器20から入力するMIDIデータ中から抽出したベロシティ値である。そのベロシティ値は、周知のように、押鍵時の速さ、つまり楽音を発音させる強さを表している。
【0034】
波形データの選択、つまり上記データpDAta、fileName、及びfLengthのなかで対象とすべきものの選択は、データiStatus(の値)に応じて行うようになっている。それにより、データiStatusの値に応じた種類の楽音を発音させている。
【0035】
上記発音データは演奏中に順次、作成され、随時、更新される。それ以外のデータ、つまり音色データ、ピッチデータ、及びソースデータでは、演奏開始前に作成され、演奏中に更新は行われない。
【0036】
演奏情報には、発音させるべき楽音毎にデータが用意されている。そのデータが演奏データである。その演奏データは、図6に示すように、楽音の発音を開始すべきタイミング(発音開始時刻)を示すデータlTime、その発音を持続させるべき発音時間を示すデータlGate,そのピッチを示すデータPitch、そのベロシティを示すデータVel、前の演奏データの格納場所を示すデータpPrev、及び次の演奏データの格納場所を示すデータpNext、を備えている。
【0037】
データlTimeが示す発音開始時刻は、例えば演奏開始を基準に、それから経過した時間である。それは、発音データにデータlOnStartとしてコピーされる。それにより、データlOffStartは、その発音開始時刻からデータlGateが示す発音時間だけ後の時間である。
【0038】
以降は図8〜図13に示す各種フローチャートを参照して、上述のデータを管理して発音制御を行う楽音発生装置10の動作について詳細に説明する。その動作は、CPU13が、上記楽音発生アプリケーションをROM13からRAM12に読み出して実行することで実現される。
【0039】
図8は、全体処理のフローチャートである。これは、上記楽音発生アプリケーションを起動させてから終了させるまでの間に実行される処理を抜粋してその流れを示したものである。始めに図8を参照して、その全体処理について詳細に説明する。
【0040】
先ず、ステップ101では、MIDI I/F16用のドライバをROM13からRAM12にロードして起動させる。続くステップ102では、同様にオーディオI/F17用のドライバをロードして起動させる。以降は、発音させるべき楽音の波高値(オーディオデータ)をオーディオI/F17から出力するためのオーディオデータ出力スレッドを起動させ(ステップ103)、音色定義ファイルとしてROM13に保存されている図2〜図4に示す各種データを読み込んでRAM12に展開し(ステップ104)、ピッチ毎にその波形データ(図中「音色データ」と表記)をROM13から読み出してRAM12にロードする(ステップ105)。そのロードにより初期化が終了し、ステップ106に移行して、入力部14、或いはMIDI I/F16によるデータの入力を待つ。ここでは、入力部14を操作してのデータ入力については、楽音発生アプリケーションの終了指示、発音ガイドの開始、その停止(終了)のみを想定する。
【0041】
電子楽器20のキーボード22を構成するキー(鍵)をユーザーが押鍵、或いは離鍵すると、MIDI I/F21はその演奏操作の内容、及びその操作が行われたキーに応じたMIDIデータを生成して楽音発生装置10のMIDI I/F16に出力する。入力部14を構成するキーボード、或いはポインティングデバイスを操作すると、その操作内容が入力部14からCPU11に通知される。それにより、ステップ106からステップ107に移行し、入力が楽音発生アプリケーションの終了コマンドか否か判定する。そのアプリケーションを終了させるための操作をユーザーが入力部14に対して行った場合、判定はYESとなってステップ114に移行する。そうでない場合には、判定はNOとなってステップ108に移行する。
【0042】
ステップ108では、入力がMIDIデータか否か判定する。MIDI I/F16がMIDIデータを入力した場合、判定はYESとなり、ステップ109に移行して、その入力に対応するためのMIDI IN処理を実行した後、上記ステップ106に戻る。一方、そうでない場合には、判定はNOとなってステップ110に移行する。
【0043】
ステップ110では、上記発音ガイドの開始を指示するための再生開始コマンドを入力したか否か判定する。ユーザーがそのコマンド入力のための操作を入力部14に対して行った場合、判定はYESとなってステップ111に移行し、発音ガイドのための再生処理を起動した後、上記ステップ106に戻る。そうでない場合には、判定はNOとなってステップ112に移行する。
【0044】
ステップ112では、上記発音ガイドの停止を指示するための再生停止コマンドを入力したか否か判定する。ユーザーがそのコマンド入力のための操作を入力部14に対して行った場合、判定はYESとなってステップ113に移行し、再生処理の実行を管理するための変数である再生停止フラグをオン、つまりその実行停止を示す値を代入した後、上記ステップ106に戻る。そうでない場合には、判定はNOとなり、他のステップの処理を実行することなく、そのステップ106に戻る。
【0045】
上記ステップ107の判定がYESとなって移行するステップ114では、オーディオデータ出力スレッドを終了させる。その終了は、例えばそのスレッド終了管理用の変数に、終了を指示する値を代入することで行う。以降は、RAM12に格納されている図2〜図6に示す各種データを消去し(ステップ115)、オーディオI/F17のドライバを終了(開放)させ(ステップ116)、MIDI I/F16のドライバを終了(開放)させる(ステップ117)。そのようにして各種ドライバやデータをRAM12から消去させた後、一連の処理を終了、つまり楽音発生アプリケーションを終了させる。
【0046】
図9は、上記ステップ109として実行されるMIDI IN処理のフローチャートである。次にそのIN処理について、図9に示すそのフローチャートを参照して詳細に説明する。
【0047】
このIN処理は、MIDI I/F17を介して入力したMIDIデータに対応するための処理である。そのMIDIデータの種類は多数、存在するが、ここでは本発明に特に係わるデータ、つまりノートオンメッセージ、ノートオフメッセージの2種類のMIDIデータのみにのみ注目して説明する。
【0048】
上述したように、発音データ中のデータlOnStart(演奏データ中のデータlTime)は演奏開始からの時間を示している。そのような時間で押鍵すべきタイミングを表していることから、再生処理の起動時に時間を計時するためのカウントを0から開始させるようにしている。そのカウント、つまり時間の計時は、例えばCPU11に内蔵のハードタイマを用いて行っている。特に断らない限り、現在時刻はそのようにして計時した時間を指す意味で用いる。
【0049】
先ず、ステップ201では、入力したMIDIデータが楽音の発音開始を指示するノートオンメッセージか否か判定する。そのMIDIデータがノートオンメッセージでなかった場合、判定はNOとなってステップ212に移行する。そうでない場合には、判定はYESとなってステップ202に移行する。
【0050】
ステップ202では、入力したMIDIデータから、チャンネル番号、ノートナンバー(ピッチ)、及びベロシティ値を抽出し、それぞれ変数ich、iPit、及びiVelに代入する。続くステップ203では、変数ndに、発音データのなかで先頭に位置する発音データの格納場所を示すインデクス値を代入する。その代入後に移行するステップ204〜209では、入力したMIDIデータに応じて、対応する発音データを作成、或いは更新するための処理を行う。
【0051】
先ず、ステップ204では、変数ndの値が示す発音データが存在しないか否か判定する。今回、入力したMIDIデータに対応する発音データは、変数ndの値で指定される発音データ中のデータpNextをその変数ndに新たに代入していくことにより、順次、対象とする発音データを変更しながら探すようになっている。最後に位置する発音データにはそれに続く発音データが存在しないため、データpNextの値は初期値のままとなっている。このため、変数ndに新たに代入した値がその初期値であった場合、判定はYESとなってステップ210に移行する。そうでない場合には、判定はNOとなってステップ205に移行する。ここでのYESの判定は、ユーザーが押鍵すべきタイミングとなる前の鍵を押鍵したことを意味する。
【0052】
ステップ205では、変数ndの値で指定される発音データ中のデータiStatus(図中「nd.iStatus」と表記。以降、他のデータでも同じ表記法を用いる)の値が2と一致し、且つnd.iPitchが示すピッチ番号が変数iPitのそれと一致するか否か判定する。それらのうちの少なくとも一つが一致しない場合、判定はNOとなってステップ206に移行し、変数ndにnd.pNextを代入した後、上記ステップ204に戻る。そうでない場合には、つまりそれらが共に一致する場合には、判定はYESとなってステップ207に移行する。
【0053】
ステップ207では、現在時刻(再生処理起動から経過した時間)からnd.lOnStartが示す時間を引いて得られる時間が、許容できるとする最大時間を示す定数DELAY_ALLOWより小さいか否か判定する。ここではその時間は押鍵が遅れた時間bを表している(図7のケース2)。このため、時間bが十分に短いような場合、判定はYESとなり、nd.iStatusの値を1に更新し(ステップ208)、更にnd.iToneを変数iChの値、nd.iNoteOnを現在時刻、nd.iOnVelを変数iVelの値、ne.pSDを設定音のデータiPitchが一致するピッチデータ中のデータpSDにそれぞれ更新してから(ステップ209)、一連の処理を終了する。そうでない場合には、判定はNOとなって上記ステップ206に移行する。
【0054】
このようにして、変数ndの値をインクリメントしながら、その値で指定される発音データが、入力したMIDIデータに対応するものか否か確認し、対応していると確認できた発音データの更新を行うようにしている。その更新により、時間bが許容範囲内であればユーザーは適切なタイミングで押鍵したとして、その押鍵以降、警告音から設定音に切り換えられる(図7のケース2)。一方、その確認ができなかった場合には、ステップ204の判定がYESとなって、ステップ210に移行することになる。
【0055】
そのステップ210では、変数ndに、新たに作成する発音データの格納場所を示すインデクス値を代入する。また、nd.pPrevとしてはそれまで最後に位置していた発音データのインデクス値を格納し、その発音データ中のデータpNextは変数ndの値に更新する。nd.pNextとしては、最後に位置する発音データであることを示す値を格納する。続くステップ211では、nd.iStatusとして3、nd.iPitchとして変数iPitの値をそれぞれ格納する。また、nd.fRelease、nd.pNext、nd.lOnStart、nd.lOffStart、nd.lNoteOffとして例えばそれぞれ所定の初期値を格納する。その後に上記ステップ209に移行する。
【0056】
上述したように、時間bが許容範囲内でなければ、入力したMIDIデータに対応する発音データを既に作成されたもののなかから確認できない。このため、ステップ204の判定がYESとなって新たに発音データが作成されることになる。その結果、ユーザーが押鍵時間内に押鍵を行ったとしても、ユーザーは不適切なタイミングで押鍵したとして、その押鍵以降も警告音の発音が継続することとなる(図7のケース2)。
【0057】
上記ステップ201の判定がNOとなって移行するステップ212では、入力したMIDIデータが楽音の発音終了を指示するノートオフメッセージか否か判定する。そのMIDIデータがノートオフメッセージだった場合、判定はYESとなってステップ213に移行する。そうでない場合には、判定はNOとなり、ここで一連の処理を終了する。
【0058】
ステップ213では、入力したMIDIデータから、チャンネル番号、及びピッチ番号(ノートナンバー)を抽出し、それぞれ変数iCh、及びiPitに代入する。続くステップ214では、変数ndに、先頭に位置する発音データのインデクス値を代入する。その代入後に移行するステップ215では、変数ndの値で指定される発音データが存在しないか否か判定する。その発音データが存在しない場合、判定はYESとなり、ここで一連の処理を終了する。それにより、入力したMIDIデータを無効とする。一方、そうでない場合には、判定はNOとなってステップ216に移行する。
【0059】
ステップ216では、nd.iPitchの値が変数iPitの値と一致するか否か判定する。それらが一致する場合、判定はYESとなってステップ218に移行し、そうでない場合には、判定はNOとなり、ステップ217で変数ndにnd.pNextを代入した後、上記ステップ215に戻る。
【0060】
ステップ218では、nd.iStatusの値が1か否か判定する。その値が1であった場合、判定はYESとなり、ユーザーは離鍵すべきタイミングとなる前の鍵を離鍵したとして(図7のケース1、2)、ステップ219でnd.iStatusの値を2に更新し、更にステップ220でnd.lNoteOffを現在時刻に更新した後、一連の処理を終了する。そうでない場合には、判定はNOとなってステップ221に移行する。
【0061】
ステップ221では、nd.iStatusの値が3か否か判定する。その値が3であった場合、判定はYESとなり、ステップ222でnd.iStatusの値を−1に更新した後、上記ステップ220に移行する。そうでない場合には、判定はNOとなって上記ステップ217に移行する。ここでのYESの判定は、主に離鍵すべきタイミングとなった鍵をユーザーが離鍵していないことを意味する(図7のケース3)。
【0062】
図10は、図8に示す全体処理内のステップ111で起動される再生処理のフローチャートである。次に図10を参照して、その再生処理について詳細に説明する。
先ず、ステップ301では、変数meに、演奏情報のなかで先頭に位置する演奏データの格納場所を示すインデクス値を代入する。続くステップ302では、上記再生停止フラグがオンとなっているか否か判定する。再生停止コマンドの入力によってそのフラグがオンされた場合、判定はYESとなり、ステップ303で発音データ全てのデータiStatusの値を0に更新した後、一連の処理を終了する。そうでない場合には、判定はNOとなってステップ304に移行する。
【0063】
ステップ304では、発音中の楽音の存在を確認するための変数AllOffに、それが存在しないことを示す値の1を代入し、変数ndに、先頭に位置する発音データのインデクス値を代入する。次のステップ305では、変数ndの値で指定される発音データが存在しないか否か判定する。その発音データが存在しない場合、判定はYESとなってステップ314に移行する。そうでない場合には、判定はNOとなってステップ306に移行する。そのステップ306〜313では、演奏データを参照して、ユーザーによる離鍵時刻に着目した発音データの更新を行うための処理が行われる。
【0064】
先ず、ステップ306では、nd.iStatusの値が0以外か否か、つまり変数ndの値で指定される発音データによって楽音を発音させていないか否か判定する。楽音を発音させていない場合、判定はNOとなり、ステップ307で変数ndにnd.pNextを代入した後、上記ステップ305に戻る。そうでない場合には、判定はYESとなってステップ308に移行する。
【0065】
ステップ308では、楽音が発音中であることを示す値の0を変数AllOffに代入する。次のステップ309では、nd.lOffStartが示す消音開始時刻が現在時刻より前か否か判定する。現在、対象としている発音データが既に離鍵しているべき鍵に対応するものであった場合、その関係が成り立つことから、判定はYESとなってステップ310に移行する。そうでない場合には、判定はNOとなって上記ステップ307に移行する。
【0066】
ステップ310では、nd.iStatusの値が1か否か判定する。その値が1であった場合、判定はYESとなり、離鍵すべきタイミングとなった鍵をユーザーが離鍵していないとして(図7のケース3)、ステップ311でnd.iStatusの値を3に更新した後、上記ステップ307に移行する。そうでない場合には、判定はNOとなってステップ312に移行する。
【0067】
ステップ312では、nd.iStatusの値が2か否か判定する。その値が2であった場合、判定はYESとなり、離鍵すべきタイミングとなる前にユーザーが離鍵した鍵がそのタイミングになったとして(図7のケース1、2)、ステップ313でnd.iStatusの値を−1に更新した後、上記ステップ307に移行する。そうでない場合には、判定はNOとなって次にそのステップ307を実行する。
【0068】
上記ステップ305の判定がYESとなって移行するステップ314では、変数AllOffの値が1と一致し、且つ変数meの値で指定される演奏データが存在しない(直前に対象としていた演奏データが最後のもの)か否か判定する。その値が1と一致し、且つその演奏データが存在しない場合、判定はYESとなり、発音ガイドを終了すべきタイミングが到来したとして、ここで一連の処理を終了する。そうでない場合には、判定はNOとなってステップ315に移行する。そのステップ315以降では、演奏データを参照しての発音データの作成、或いはユーザーによる押鍵時刻に着目した発音データの更新のための処理が行われる。
【0069】
先ず、ステップ315では、me.lTimeが示す発音開始時刻が現在時刻(再生開始からの時間)より前か否か判定する。その発音開始時刻(押鍵すべきタイミング)が現在時刻より前であった場合、判定はYESとなってステップ316に移行する。そうでない場合には、判定はNOとなって上記ステップ302に戻る。
【0070】
ステップ316では、変数ndに、先頭に位置する発音データのインデクス値を代入する。その代入後に移行するステップ317では、変数ndの値で指定される発音データが存在しないか否か判定する。その発音データが存在しない場合、判定はYESとなってステップ324に移行し、そうでない場合には、判定はNOとなってステップ318に移行する。
【0071】
ステップ318では、nd.iStatusの値が3と一致し、且つnd.iPitchの値がme.Pitchの値と一致するか否か判定する。それらのうちの少なくとも一つが一致しない場合、判定はNOとなってステップ319に移行し、変数ndにnd.pNextを代入した後、上記ステップ317に戻る。そうでない場合には、つまりそれらが共に一致する場合には、判定はYESとなってステップ320に移行する。そのYESの判定は、対象としている発音データは、押鍵すべきタイミングとなる前の鍵をユーザーが押鍵することで作成されたことを意味する(図7のケース1)。
【0072】
ステップ320では、現在時刻からnd.lNoteOnが示す時刻を引いて得られる時間aが、上記定数DELAY_ALLOWより小さいか否か判定する。時間aが十分に短いような場合、判定はYESとなり、nd.iStatusの値を1に更新し(ステップ321)、nd.iOnStartを現在時刻、ne.lOffStartを現在時刻にme.lGateの値を加算した値、nd.pMEを変数meの値にそれぞれ更新し(ステップ322)、更に変数meにme.nextを代入してから(ステップ323)、上記ステップ302に戻る。そうでない場合には、判定はNOとなって上記ステップ319に移行する。
【0073】
上記ステップ321でnd.iStatusの値を1に更新することにより、時間aが十分に短ければ初めから設定音が発音されることになる。その更新が行われない場合には、設定音の代わりに警告音が発音されることになる。その警告音のピッチは固定とさせても良い。
【0074】
上記ステップ317の判定がYESとなって移行するステップ324では、変数ndに、新たに作成する発音データの格納場所を示すインデクス値を代入する。nd.pPrevとしてそれまで最後に位置していた発音データのインデクス値を格納し、その発音データ中のデータpNextは変数ndの値に更新する。nd.pNextとしては、最後に位置する発音データであることを示す値を格納する。続くステップ325では、nd.iStatusとして2、nd.iPitchとしてme.Pitch、nd.pSDとしてme.Pitchに対応するインデクス値をそれぞれ格納する。また、nd.fRelease、nd.NoteOn、nd.lNoteOff、nd.pNextとして例えばそれぞれ所定の初期値を格納し、そのようなことを行った後に上記ステップ322に移行する。
【0075】
図11は、図8に示す全体処理内のステップ103で起動されるオーディオデータ出力スレッドの実行により実現される処理のフローチャートである。次に図11を参照して、その処理について詳細に説明する。この出力スレッドは、サンプリング周期でオーディオI/F17を介して出力する、発音させるべき楽音の波高値(オーディオデータ)を生成するためのものである。
【0076】
先ず、ステップ401では、各種変数に初期値を代入し、オーディオI/F17を介して出力するオーディオデータ一時格納用の領域(出力バッファ)をRAM12に確保するといった初期化を行う。次のステップ402では、終了が指示されたか否か判定する。上述したように、図8に示す全体処理のステップ114では、オーディオデータ出力スレッドの終了管理用の変数に、終了を指示する値を代入する。このことから、その変数にその値が代入されていた場合、判定はYESとなり、ここで一連の処理を終了する。そうでない場合には、判定はNOとなってステップ403に移行する。
【0077】
ステップ403では、発音させるべき楽音のオーディオデータを作成(生成)して出力バッファに格納するための出力データ作成処理を実行する。次に移行するステップ404では、出力バッファに格納されたオーディオデータをサンプリング周期で順次、出力するための処理を実行する。その実行後は上記ステップ402に戻る。それにより、楽音発生アプリケーションの起動中は、ステップ402〜404で形成される処理ループを繰り返し実行する。
【0078】
次に、上記ステップ403として実行される出力データ作成処理について、図12に示すそのフローチャートを参照して詳細に説明する。その作成処理では、複数のサンプリング周期分のオーディオデータを一度に作成し、出力バッファに保存するようにしている。図中の「lSamples」は一度に作成するオーディオデータ数を示す定数である。
【0079】
先ず、ステップ501では、変数iに0を代入する。続くステップ502では、変数iの値が定数lSamples未満か否か判定する。変数iの値は、1サンプリング周期分のオーディオデータを作成する度にインクリメントするようになっている。このため、一度に作成すべきオーディオデータを全て作成していない場合、変数iの値は定数lSamples未満の関係を満たすから、判定はYESとなってステップ503に移行する。そうでない場合には、つまり作成すべきオーディオデータを全て作成した場合には、判定はNOとなり、ここで一連の処理を終了する。
【0080】
ステップ503では、変数iの値を定数lSRで割った値を変数lTimeの値に加算して得られる値(=lTime+i/lSR)を変数lSTimeに代入する。変数lTimeに代入された値は、次のオーディオデータを出力すべき時刻を示す値であり、定数lSRは、出力バッファに格納したオーディオデータのサンプリングレートを示す値である。それにより、変数iの値を定数lSRで割った値は、変数iの値にサンプリング周期を掛けた値(時間を示す値)である。このことから、変数lSTimeには、対象とするオーディオデータを出力すべき時刻を示す値が代入される。その代入後はステップ504に移行する。
【0081】
ステップ504では、1サンプリング周期分のオーディオデータ作成用の変数iValueに0を代入する。次のステップ505では、変数ndに、発音データ格納用領域の先頭に位置する発音データの格納場所を指定するインデクス値を代入する。その次に移行するステップ506では、変数ndの値で指定される格納場所に発音データが存在するか否か判定する。その発音データが存在しない場合、判定はNOとなってステップ516に移行する。そうでない場合には、判定はYESとなってステップ507に移行する。
【0082】
ステップ507では、nd.iStatusの値が−1、1、及び2のうちの何れかと一致するか否か判定する。その値がそれらのうちの何れとも一致しない場合、判定はNOとなってステップ510に移行する。そうでない場合には、判定はYESとなってステップ508に移行する。nd.iStatusの値が3の発音データを発音対象から除外することにより、正押鍵時間外の楽音の発音は回避される(図7のケース1、3)。
【0083】
ステップ507でのYESの判定は、現在、注目している発音データに対応する楽音は発音すべきものであることを意味する。このことから、ステップ508では、その楽音を発音させるためのサンプリングデータをRAM12から読み出すためのサンプリングデータ読み取り処理を実行する。その実行によって変数iVtmpには、そのサンプリングデータが代入される。サンプリングデータを読み出す波形データは、データpSDによって指定されるソースデータを参照して特定している。このため、データpSDに応じて設定音、或いは警告音を発音させるための波形データが選択される。
【0084】
ステップ508に続くステップ509では、nd.iStatusの値が−1か否か判定する。その値が−1、つまり現在、注目している発音データに対応する楽音が消音処理中であった場合、判定はYESとなってステップ512に移行する。そうでない場合には、判定はNOとなり、変数iValueに、それまでの値に変数iVtmpの値を加算した値(=iValue+iVtmp)を代入し(ステップ510)、変数ndにnd.pNextを代入する(ステップ511)。その代入後は上記ステップ506に戻る。
【0085】
このように、発音対象とする、消音処理中でない楽音では、ステップ508のサンプリングデータ読み取り処理の実行によって変数iVtmpに代入されたサンプリングデータは変数iValueのそれまでの値に加算される。それにより、消音処理を開始するまではサンプリングデータ(波形データ)に従って発音される。
【0086】
上記ステップ509の判定のYESとなって移行するステップ512〜515では、消音したと見なせるまで、発音させる楽音の音量を徐々に小さくさせていくための処理が行われる。波形データを構成するサンプリングデータの値は大きく変化することから、消音したと見なせるか否かの判定は、消音処理中に更新していくデータfReleaseの値により行っている。図中の「RED_OFF」「RELEASE」はそれぞれ、その判定用に設定した定数、データfRelease更新用に設定した定数である。
【0087】
先ず、ステップ512では、変数iVtmpに、nd.fReleaseの値、つまり注目している発音データ中のデータfReleaseの値をそれまでの値に掛けて得られる値(=iVtmp*fRelease)を代入する。続くステップ513では、そのデータfRelease(nd.fRelease)の値が定数RED_OFF未満か否か判定する。その値が定数RED_OFF未満であった場合、判定はYESとなってステップ514に移行し、データiStatusの値を0に、その他のデータをリセットする操作を行った後、上記ステップ510に移行する。そうでない場合には、判定はNOとなり、ステップ515でデータfReleaseをそれまでの値に定数RELEASEを掛けた値に更新した後、上記ステップ510に移行する。
【0088】
そのステップ406でのNOの判定は、1サンプリング周期分のオーディオデータの作成が終了したことを意味する。このことから、その判定がNOとなって移行するステップ516では、変数iValueの値を1サンプリング周期分のオーディオデータとして、変数lStimeの値と共に、出力バッファの変数iの値で指定される格納場所に格納する。その格納後は、ステップ517で変数iの値をインクリメントしてから上記ステップ502に戻る。
【0089】
図13は、上記ステップ508として実行されるサンプリングデータ読み取り処理のフローチャートである。最後に図13を参照して、その読み取り処理について詳細に説明する。
【0090】
先ず、ステップ551では、変数idに、nd.iStatusの値を代入する。次のステップ552では、変数lTに、変数lStimeの値からnd.lOnStartの値を引いた値、つまり変数ndの値で指定される発音データにより発音中の楽音の発音を開始させてから経過した時間を示す値を代入する。その後は、ステップ553でnd.pSDの値を変数sdに代入する。
【0091】
ステップ553に続くステップ554では、変数lPosに、変数lTの値に定数lSRを掛けた乗算結果を、sd.fLengthのなかで変数idの値で指定されるもの(図中「sd.fLength[id]」と表記。以降、その表記法を用いる)の値で割ったときに得られる余り(=(lT*lSR)%sd.fLength[id])を代入する。その後は、ステップ555に移行して、sd.pDataのなかで変数idの値で指定されるもの(図中「sd.pData[id]」と表記。以降、その表記法を用いる)で指定される波形データを例えば配列変数、或いはバッファであるpWに格納する。ここではpWとしてバッファを想定する。バッファpWに波形データを格納した後はステップ556に移行する。
【0092】
ステップ556では、バッファpWに格納した波形データ中の変数lPosの値で指定されるサンプリングデータ(先頭から変数lPosの値番目のデータ)を読み出して変数iVtmpに代入する。その次のステップ557では、変数iVtmpに、nd.iVelの値をsd.MaxVelの値で割った値をそれまでの値に乗算して得られる値を代入する。そのようにして、変数iVtmpに代入したサンプリングデータを、ユーザーが実際に押鍵したときのベロシティ値と波形データのベロシティ範囲の上限値の比に応じて更新した後、一連の処理を終了する。
【0093】
このように、変数id(nd.iStatus)の値に応じた波形データが参照され、その波形データから読み出して操作したサンプリングデータが最終的に変数iVtmpに代入され、上記出力データ作成処理に渡される。このため、データiStatusの値に対応する種類の楽音が発音される。
<第2の実施の形態>
上記第1の実施の形態では、押鍵すべき鍵をユーザーが実際に押鍵したタイミングに応じて設定音、及び警告音の2種類の楽音を発音させるようにしている(図7)。これに対し、第2の実施の形態は、ユーザーが実際に押鍵したタイミングに応じて3種類の楽音を発音させるようにしたものである。
【0094】
第2の実施の形態における楽音発生装置の構成は、基本的に第1の実施の形態におけるそれと同じである。動作も大部分は同じか、或いは基本的に同じである。このことから、第1の実施の形態で付した符号をそのまま用いて、第1の実施の形態から異なる部分についてのみ説明する。
【0095】
図14は、第2の実施の形態における楽音の発音制御によって発音される楽音を説明する図である。その図14では、図7と同様に、ケース1〜3別に発音される楽音を示している。それらケース1〜3の内容は図7におけるそれと同じである。
【0096】
図14のケース1、3に示すように、第2の実施の形態では、正押鍵時間外もユーザーが鍵を押鍵していれば楽音を発音させるようにしている。その正押鍵時間外は、設定音、及び警告音とは異なる種類の楽音(便宜的に「ミスタッチ音」と呼ぶ)を発音させるようにしている。
【0097】
ケース1では、時間aが十分に短いか否かに係わらず、正押鍵時間が到来するまでの間、ミスタッチ音を放音させる。その正押鍵時間が到来した後は、時間aが十分に短ければ設定音の発音に切り換え、それ以降は第1の実施の形態と同じタイミングで警告音の発音に切り換えて正押鍵時間が経過するまでその警告音を発音させる。一方、時間aが十分に短くなければ、ミスタッチ音は実押鍵時間が経過するまで発音させ、それと併せて、正押鍵時間全体で警告音を発音させる。その後、正押鍵時間が経過するまで警告音に切り換えて発音させる。このため、時間aが十分に短いか否かに係わらず、正押鍵時間と実押鍵時間のずれを発音された楽音から容易に認識できるようになっている。
【0098】
ケース2では、時間bが十分に短ければ第1の実施の形態と同じタイミング、順序で警告音、設定音が発音される。時間bが十分に短くない場合には、第1の実施の形態と同じく、正押鍵時間全体で警告音を発音させる。それと併せて、実押鍵時間全体でミスタッチ音を発音させる。このため、時間bが十分に短いか否かに係わらず、このため、時間aが十分に短いか否かに係わらず、正押鍵時間と実押鍵時間のずれを発音された楽音から容易に認識できるようになっている。
【0099】
ケース3では、正押鍵時間内は第1の実施の形態と同じく設定音を発音させる。その正押鍵時間が経過した後は、実押鍵時間が経過するまでミスタッチ音に切り換えて発音を継続させる。このため、離鍵したタイミングと離鍵すべきタイミングのずれを発音された楽音から容易に認識できるようになっている。
【0100】
上述したように、時間a、或いはbが十分に短くない場合、発音データは複数(ここでは2つ)作成される。ケース1、及び2において、正押鍵時間全体で警告音を発音させる発音データは対応する演奏データから作成され、その警告音と併せてミスタッチ音を発音させる発音データはユーザーの操作から作成される。第1の実施の形態では、その一方のみを用いることで図7に示すような発音制御を実現させている。これに対し、第2の実施の形態では、それらを共に用いることにより、図14に示すような発音制御を実現させている。このために第2の実施の形態では、図12に示す出力データ作成処理に第1の実施の形態から異なる部分が存在する。以降、その異なる部分について具体的に説明する。
【0101】
図12に示す出力データ作成処理では、ステップ507でデータiStatus(nd.iStatus)の値が−1、1、及び2の何れかと一致するか否か判定している。第2の実施の形態では、その値が0でないか否か判定するようにしている。それにより、その値が3であればミスタッチ音を発音させるようにしている。
<第3の実施の形態>
上記第1、及び第2の実施の形態では、押鍵すべき鍵をユーザーが実際に押鍵したタイミングに着目して発音させるべき楽音(ここでは発音の回避を含む)の発音制御を行っている。これに対し、第3の実施の形態は、ユーザーが押鍵したときのベロシティに更に着目して発音制御を行うようにしたものである。そのベロシティを更に着目することにより、行った押鍵の速さ(ベロシティ)が適切か否かを発音させる音によりユーザーに容易に認識させることができる。
【0102】
第3の実施の形態における楽音発生装置の構成は、基本的に第1の実施の形態におけるそれと同じである。動作も大部分は同じか、或いは基本的に同じである。このことから、第2の実施の形態と同様に、第1の実施の形態で付した符号をそのまま用いて、第1の実施の形態から異なる部分についてのみ説明する。
【0103】
第3の実施の形態では、図5に示すように、発音データを構成するデータとして、演奏データ中のデータVelが示すベロシティがユーザーの押鍵時のベロシティと許容範囲内で一致するか否かを示すデータiVelAgreeを用意している。その具体的な値としては、許容範囲内で一致すれば1、そうでなければ0としている。初期値は0としている。データiVelAgreeの値に応じて発音させる楽音の音量を制御することにより、行った押鍵の速さが適切か否か認識可能とさせている。本実施の形態では、データiVelAgreeの値が1であれば音量を小さくさせるようにしている。
【0104】
演奏データが示すベロシティが実際の押鍵時のベロシティと許容範囲内で一致するか否かの判定、その判定結果に応じたデータiVelAgreeの更新は、図9に示すMIDI IN処理、及び図10に示す再生処理に図15に示すフローチャートを追加することで実現させている。
【0105】
その図15に示すフローチャートでは、ステップ601において、変数ndの値で指定される発音データ中のデータpMEが示す演奏データに格納のデータVel(図中「nd.pME.Vel」と表記した、対応する演奏データが示すベロシティ)の値から変数iVel(ユーザーが押鍵したベロシティ)の値を引いた減算値の絶対値が、許容範囲として設定の定数ALLOW_VEL未満か否か判定する。その絶対値が定数ALLOW_VEL未満であった場合、判定はYESとなってステップ602に移行し、データiVelAgreeの値を1に更新する。そうでない場合には、判定はNOとなり、許容範囲外としてデータiVelAgreeを更新することなく、ステップ602の処理の実行後に移行する処理を次に実行する。
【0106】
図15に示すフローチャートは、図9に示すMIDI IN処理ではステップ208、209間に追加・挿入され、図10に示す再生処理では、ステップ321,322間に追加・挿入される。発音させる楽音の音量制御は、例えばその後に移行するステップ209、322のそれぞれに、データiVelAgreeの値が1であれば変数iVelの値に1より小さい係数(例えば0.5)を掛けた値をデータiOnVelとして格納させるか、或いは例えば図12に示すステップ508として実行されるサンプリングデータ読み取り処理にデータiVelAgreeの値に応じたデータiOnVelの更新機能を搭載させることで実現できる。
<第4の実施の形態>
上記第1〜第3の実施の形態では、演奏情報は予め用意されたものを用いるようにしている。これに対し、第4の実施の形態は、実際に行われた演奏結果を示す演奏情報を保存して用いることができるようにしたものである。
【0107】
第4の実施の形態における楽音発生装置の構成は、基本的に第1の実施の形態におけるそれと同じである。動作も大部分は同じか、或いは基本的に同じである。このことから、第2、及び第3の実施の形態と同様に、第1の実施の形態で付した符号をそのまま用いて、第1の実施の形態から異なる部分についてのみ説明する。
【0108】
第4の実施の形態では、MIDI I/F16に複数の電子楽器20を接続可能となっている。演奏結果は合奏を行った人別に保存するようにしている。そのために、図2〜図6に示す各種データに加えて、図16〜図18に示す各種データを管理できるようになっている。始めに図16〜図18にそれぞれ示すデータについて詳細に説明する。演奏結果として保存するデータは、録音データと呼ぶことにする。その録音データは、楽音単位で演奏結果を示す保存データを備えている。
【0109】
図16は、録音データ管理データの構成を説明する図である。その録音データ管理データ(以降「管理データ」と略記)は、演奏(録音)毎に用意される管理用のデータである。図16に示すように、録音(演奏)開始日時を示すデータDate、対応する参加ユーザーデータの格納場所(先頭の位置するデータの場所)を示すデータpUserList、対応する録音データの格納場所を示すデータpRecData、前の管理データの格納場所を示すデータprev、及び次の管理データの格納場所を示すデータnext、を備えている。ここでは上述の各実施の形態と同様に、格納場所を示すものとしてインデクス値(ポインタ値)を想定する。
【0110】
図17は、参加ユーザーデータの構成を説明する図である。その参加ユーザーデータ(以降「ユーザーデータ」と略記)は、合奏者毎に用意されるデータである。図17に示すように、対応する合奏者名(参加したユーザー名)を示すデータUserName、演奏したトラックを示すデータiCh、対応する音色データを示すデータpTone、前のユーザーデータの格納場所を示すデータprev、及び次のユーザーデータの格納場所を示すデータnext、を備えている。
【0111】
図18は、保存データの構成を説明する図である。その保存データは、楽音単位に用意されるデータである。データiCh、楽音のピッチを示すデータiPitch、そのベロシティを示すデータiOnVel、その楽音における演奏判断結果を示すデータiResult(0の値は未押鍵、1の値は適切な押鍵、2の値は遅れた押鍵、3の値は早い押鍵、4の値は誤った押鍵(ミスタッチ)、をそれぞれ表す)、対応する演奏データによる発音開始時刻を示すデータlOnStart、その消音開始時刻を示すデータlOffStart、ユーザーによる押鍵時刻(タイミング)を示すデータlNoteOn、その離鍵時刻(タイミング)を示すデータlNoteOff、前の保存データの格納場所を示すデータprev、及び次の補間データの格納場所を示すデータnext、を備えている。図5に示す発音データにもデータiResultは追加されている。
【0112】
以降は、図19〜図24を参照して、本実施の形態で実行する処理について詳細に説明する。
図19は、図8のステップ109として実行されるMIDI IN処理のフローチャートである。そのIN処理は、図9に示すIN処理の代わりに実行されるものである。図9に示すステップの処理内容と同じ、或いは基本的に同じものには同一の符号を付している。それにより、始めに図19を参照して、第1の実施の形態から異なる部分についてのみ説明する。
【0113】
本実施の形態では、先ず、ステップ212の判定処理を実行する。その判定がNOであれば次にステップ201の判定処理を実行し、その判定がYESであればステップ213に移行するようになっている。そのステップ201でNOと判定すればここで一連の処理を終了し、YESと判定すればステップ202に移行する。
【0114】
ステップ219、或いは222の処理を実行した後は、ステップ701に移行する。そのステップ701では、nd.lNoteOffとして現在時刻を格納し、続くステップ702では、nd.iResultの値が2、或いは3か否か判定する。その値が2、及び3の何れかであった場合、判定はYESとなってステップ703に移行し、配列変数iReduceの変数nd、及びデータiChの各値で指定される要素(図中「iReduce[nd.iCh]」と表記)の値を、それまでの値に0.5を加算した値に更新(図中「iReduce[nd.iCh]+=0.5」と表記)した後、一連の処理を終了する。そうでない場合には、つまりその値が2、及び3の何れでもない場合には、判定はNOとなってステップ704に移行する。
【0115】
ステップ704では、nd.iResultの値が4か否か判定する。その値が4であった場合、判定はYESとなってステップ705に移行し、配列変数fReduceの変数nd、及びデータiChの各値で指定される要素(図中「fReduce[nd.iCh]」と表記)の値を、それまでの値に0.5を加算した値に更新(図中「fReduce[nd.iCh]+=0.5」と表記)した後、一連の処理を終了する。そうでない場合には、判定はNOとなり、ここで一連の処理を終了する。
【0116】
本実施の形態では、ステップ205の判定がYESとなると次にステップ706に移行し、変数lDifに、現在時刻(を示す値)からnd.lOnStart(発音開始時刻)の値を引いた値(時間bに対応)を代入する。続くステップ707では、変数lDifの値が定数DELAY_ALLOW未満か否か判定する。押鍵したタイミングの遅れが許容範囲内であった場合、判定はYESとなってステップ708に移行する。そうでない場合には、判定はNOとなってステップ206に移行する。
【0117】
ステップ708では、nd.iStatusとして1、nd.iResultとして2をそれぞれ格納する。その格納後はステップ709に移行して、変数lDifの値が定数DELAY_OK未満か否か判定する。その値が定数DELAY_OK未満であった場合、判定はYESとなり、ステップ710でnd.iResultとして1を格納し、更にステップ711でnd.lNoteOnとして現在時刻(曲頭からの演奏時間)、nd.iOnVelとして変数iVelの値をそれぞれ格納した後、一連の処理を終了する。そうでない場合には、判定はNOとなって次にそのステップ711に移行する。
【0118】
上記定数DELAY_OKは定数DELAY_ALLOWより小さい値である。そのため、ユーザーが押鍵したタイミングが押鍵すべきタイミングにより近ければ、nd.iResultの値を2から1に更新するようにしている。
【0119】
本実施の形態では、ステップ210の処理を実行した後はステップ712に移行する。そのステップ712では、nd.iStatusとして2、nd.pSDとして変数iPitの値に対応したソースデータのインデクス値、nd.iPitchとして変数iPitの値、nd.iResultとして4、nd.iToneとして変数iChの値、等をそれぞれ格納する。その後にステップ711に移行する。
【0120】
図20は、図8に示す再生処理のフローチャートである。その再生処理は、図10に示す再生処理の代わりに実行されるものである。図10に示すステップの処理内容と同じ、或いは基本的に同じものには同一の符号を付している。それにより、図20を参照して、第1の実施の形態から異なる部分についてのみ説明する。
【0121】
本実施の形態では、ステップ311の処理を実行した後、ステップ801に移行して、nd.iResultの値が0か否か判定する。その値が0であった場合、判定はYESとなってステップ802に移行し、要素iReduce[nd.iCh]の値をインクリメントした後、ステップ307に移行する。そうでない場合には、判定はNOとなってそのステップ307に移行する。
【0122】
ステップ324の処理を実行した後は次にステップ803に移行する。そのステップ803では、nd.iStatusとして2、nd.pSDとして変数iPitの値に対応したソースデータのインデクス値、nd.iPitchとしてme.Pitch、nd.iResultとして0、nd.iChとして変数iChの値、等をそれぞれ格納する。その後はステップ804に移行して、nd.lOnStartとしてme.lTime、nd.lOffStartとして現在時刻にme.lGateが示す発音時間を加算した値、nd.pMEとして変数meの値、等をそれぞれ格納する。その次に移行するステップ805では、配列変数iOrgCntの変数nd、及びデータiChの各値で指定される要素(図中「iOrgCnt[nd.iCh]」と表記)の値をインクリメントする。ステップ323にはその後に移行する。
【0123】
本実施の形態では、ステップ318の判定がYESとなった場合、次にステップ806に移行する。そのステップ806では、変数lDifに、現在時刻(を示す値)からnd.lNoteOn(押鍵時刻)の値を引いた値(時間aに対応)を代入する。続くステップ807では、変数lDifの値が定数DELAY_ALLOW未満か否か判定する。押鍵したタイミングの早さが許容範囲内であった場合、判定はYESとなってステップ808に移行する。そうでない場合には、判定はNOとなってステップ319に移行する。
【0124】
ステップ808では、nd.iStatusとして1、nd.iResultとして3をそれぞれ格納する。その格納後はステップ809に移行して、変数lDifの値が定数DELAY_OK未満か否か判定する。その値が定数DELAY_OK未満であった場合、判定はYESとなり、ステップ810でnd.iResultとして1を格納した後、上記ステップ804に移行する。そうでない場合には、判定はNOとなって次にそのステップ804に移行する。
【0125】
図21は、データ保存処理のフローチャートである。その保存処理は、演奏結果を録音データとして保存するための処理であり、図20に示す再生処理を停止(終了)した後に実行される。次に図21を参照して、その保存処理について詳細に説明する。
【0126】
先ず、ステップ901では、演奏結果の保存管理用の変数である録音フラグがセットされているか否か判定する。ユーザーが演奏結果の保存を指示した場合、その録音フラグにはセットされていると見なす値が代入されることから、判定はYESとなってステップ902に移行する。そうでない場合には、判定はNOとなり、ここで一連の処理を終了する。本実施の形態では、その保存が指示された場合、合奏者全員の演奏結果を対象に保存を行うようにしている。
【0127】
ステップ902では、変数recListに新たな管理データを格納できる場所(空き位置)を示すインデクス値、変数usrListに新たなユーザーデータを格納できる場所を示すインデクス値、変数recDatに新たな保存データを格納できる場所のインデクス値、をそれぞれ代入し、recList.pUserListとして変数usrListの値を格納する。次のステップ903では、usrList.iCh、usrList.pToneとして、対象とするユーザー(合奏者)のトラック番号、音色に対応の音色データを示すデータをそれぞれ格納する。その後はステップ904に移行する。
【0128】
ステップ904では、次の接続鍵盤、つまり他に演奏結果を保存すべきユーザーが存在するか否か判定する。そのようなユーザーが存在する場合、判定はYESとなり、ステップ905に移行して、変数pNxtに新たにユーザーデータを格納できる場所を示インデクス値を代入し、usrList.nextとして変数pNxtの値、pNxt.prevとして変数usrListの値、をそれぞれ格納し、その後に変数usrListに変数pNxtの値を代入し、対象とする合奏者は別の人に変更してから上記ステップ903に戻る。それにより、全てのユーザーを対象にして、ユーザーデータの格納を行う。一方、そうでない場合には、判定はNOとなってステップ906に移行する。
【0129】
ステップ906以降では、発音データから保存データを作成して格納するための処理が行われる。
先ず、ステップ906では、変数ndに先頭位置の発音データを指定するインデクス値を代入する。続くステップ907では、recDat.iChとしてnd.iCh、recDat.iPitchとしてnd.iPitch、recDat.iOnVelとしてnd.iOnVel、recDat.iResultとしてnd.iResult、recDat.iOnStartとしてnd.iOnStart、recDat.iOffStartとしてnd.iOffStart、recDat.iNoteOnとしてnd.iNoteOn、recDat.iNoteOffとしてnd.iNoteOff、をそれぞれ格納する。
【0130】
ステップ907に続くステップ908では、変数ndで指定される発音データの次に位置する発音データが存在するか否か判定する。その次に位置する発音データが存在しない場合、つまり保存データの格納が完了した場合、判定はNOとなり、ここで一連の処理を終了する。そうでない場合には、判定はYESとなり、ステップ909に移行して、変数pNxtに次の保存データを格納する場所を示すインデクス値を代入し、recDat.nextとして変数pNxtの値、pNxt.prevとして変数recDatの値、をそれぞれ格納し、その後に変数recDatに変数pNxtの値、変数ndにnd.pNextをそれぞれ代入してから上記ステップ907に戻る。
【0131】
上述したようにして本実施の形態では、演奏結果を保存データ(録音データ)として保存できるようにしている。このことから、その録音データ再生、及びその録音データを用いた発音ガイド等を行えるようにさせている。次に図22、図23を参照して、それらを実現させるために実行される処理について詳細に説明する。前者を実現させるための処理は「録音データ再生処理」、後者を実現させるための処理は「録音データガイド再生処理」とそれぞれ呼ぶことにする。それらの処理は図10に示す再生処理と同様に、図8に示す全体処理の実行時に起動される。その停止が指示された場合、対応する再生停止フラグがオンされる。また、所望のパートを選択できるようにさせている。その選択はトラック番号を指定して行い、指定されたトラック番号は変数iMyChに代入している。
【0132】
図22は、録音データ再生処理のフローチャートである。始めに図22を参照して、その再生処理について詳細に説明する。
先ず、ステップ1001では、変数rdに、録音データのなかで先頭に位置する保存データの格納場所を示すインデクス値を代入する。続くステップ1002では、上記再生停止フラグがオンとなっているか否か判定する。そのフラグがオンされている場合、判定はYESとなり、ステップ1003で発音データ全てのデータiStatusの値を0に更新した後、一連の処理を終了する。そうでない場合には、判定はNOとなってステップ1004に移行する。
【0133】
ステップ1004では、変数AllOffに1を代入し、変数ndに、先頭に位置する発音データのインデクス値を代入する。次のステップ1005では、変数ndの値で指定される発音データが存在しないか否か判定する。その発音データが存在しない場合、判定はYESとなってステップ1014に移行する。そうでない場合には、判定はNOとなってステップ1006に移行する。
【0134】
ステップ1006では、nd.iStatusの値が0以外か否か、つまり変数ndの値で指定される発音データによって楽音を発音させていないか否か判定する。楽音を発音させていない場合、判定はYESとなり、ステップ1008で変数AllOffに0を代入してからステップ1009に移行する。そうでない場合には、判定はNOとなってステップ1007に移行し、変数ndにnd.pNextを代入した後、上記ステップ1005に戻る。
【0135】
ステップ1009では、nd.iChの値が変数iMyChの値と一致するか否か判定する。それらの値が一致する場合、判定はYESとなってステップ1012に移行する。そうでない場合には、判定はNOとなってステップ1010に移行する。
【0136】
ステップ1010では、nd.lNoteOffが示す離鍵時刻が現在時刻より前か否か判定する。その離鍵時刻が現在時刻より前であった場合、判定はYESとなり、対応する楽音を消音させるべきとして、ステップ1011でnd.iStatusとして−1を格納した後、上記ステップ1007に移行する。そうでない場合には、判定はNOとなってそのステップ1007に移行する。
【0137】
ステップ1012では、nd.lOffStartが示す消音開始時刻が現在時刻より前か否か判定する。その開始時刻が現在時刻より前であった場合、判定はYESとなり、対応する楽音を消音させるべきとして、ステップ1013でnd.iStatusとして−1を格納した後、上記ステップ1007に移行する。そうでない場合には、判定はNOとなってそのステップ1007に移行する。
【0138】
上記ステップ1005の判定がYESとなって移行するステップ1014では、変数AllOffの値が1と一致し、且つ変数rdの値で指定される保存データが存在しない(直前に対象としていた保存データが最後のもの)か否か判定する。その値が1と一致し、且つその保存データが存在しない場合、判定はYESとなり、ここで一連の処理を終了する。そうでない場合には、判定はNOとなってステップ1015に移行する。
【0139】
ステップ1015では、変数lTimeに、rd.lNoteOnの値(押鍵時刻)を代入する。続くステップ1016では、変数lTimeの値が示す押鍵時刻が現在時刻(再生開始からの時間)より前か否か判定する。その押鍵時刻(押鍵すべきタイミング)が現在時刻より前であった場合、判定はYESとなってステップ1017に移行する。そうでない場合には、判定はNOとなって上記ステップ1002に戻る。
【0140】
ステップ1017では、変数ndに、先頭に位置する発音データのインデクス値を代入する。nd.pPrevとしてそれまで最後に位置していた発音データのインデクス値を格納し、その発音データ中のデータpNextは変数ndの値に更新する。nd.pNextとしては、最後に位置する発音データであることを示す値を格納する。その格納後に移行するステップ1018では、nd.iStatusとして2、nd.pSDとしてrd.iPitch、rd.iChに対応するデータ、nd.iPitchとしてrd.iPitch、nd.iResultとして0、nd.iChとしてrd.iChをそれぞれ格納する。次のステップ1019では、nd.lOnStartとして現在時刻、nd.lOffStartとして、現在時刻に、rd.lOffStartの値からrd.lOnStartの値を引いた値(発音時間)を加算した値、などをそれぞれ格納する。その後は、ステップ1020で変数rdにrd.nextを代入してから上記ステップ1002に戻る。
【0141】
図23は、上記録音データガイド再生処理のフローチャートである。次に図23を参照して、そのガイド再生処理について詳細に説明する。この図23では、図20に示す再生処理で実行されるステップの処理内容と同じ、或いは基本的に同じステップには同一の符号を付している。それにより、図20に示す再生処理から異なる部分についてのみ詳細に説明する。
【0142】
この録音データガイド再生処理では、先ず、ステップ1101において、変数rdに録音データのなかで先頭に位置する保存データを指定するインデクス値を代入し、変数iMyChにユーザーが指定のチャンネル番号(トラック番号)を代入する。その後はステップ302に移行する。
【0143】
ステップ308で変数AllOffに0を代入した後はステップ1102に移行して、nd.iChの値が変数iMyChの値と一致するか否か判定する。それらの値が一致する場合、判定はYESとなってステップ1105に移行する。そうでない場合には、判定はNOとなってステップ1103に移行する。
【0144】
ステップ1103では、nd.lNoteOffが示す離鍵時刻が現在時刻より前か否か判定する。その離鍵時刻が現在時刻より前であった場合、判定はYESとなり、対応する楽音を消音させるべきとして、ステップ1104でnd.iStatusとして−1を格納した後、上記ステップ309に移行する。そうでない場合には、判定はNOとなってそのステップ309に移行する。
【0145】
ステップ1105では、nd.lOffStartが示す消音開始時刻が現在時刻より前か否か判定する。その開始時刻が現在時刻より前であった場合、判定はYESとなってステップ310に移行する。そうでない場合には、判定はNOとなって上記ステップ309に移行する。
【0146】
ステップ801の判定がYESとなって移行するステップ1106では、要素iReduce[iMyCh]に、それまでの値にnd.pME.fPtiorityの値を加算した値を代入する。その後は上記ステップ307に移行する。配列変数iReduceは例えばトラック(チャンネル)毎に押鍵すべき鍵を押鍵しなかった回数をカウントするために用意したものである。
【0147】
ステップ314の判定がNOとなって移行するステップ1107では、変数lTimeにrd.lOnStartを代入する。続くステップ1108では、rd.iChの値が変数iMyChの値と一致するか否か判定する。それらの値が一致する場合、判定はYESとなってステップ1109に移行し、変数lTimeにrd.lNoteOnを代入してから上記ステップ315に移行する。それにより、押鍵すべきとするタイミングを演奏結果から演奏データのそれに変更する。一方、そうでない場合には、判定はNOとなってそのステップ315に移行する。なお、そのようなタイミングの変更は行わないようにしても良い。その場合、ステップ1108、1109を省き、ステップ1107の処理を実行した後、ステップ305に移行させれば良い。
【0148】
ステップ315の判定がYESとなると、次にステップ1110に移行して、rd.iChの値が変数変数iMyChの値と一致するか否か判定する。それらの値が一致しない場合、判定はNOとなり、ステップ1115で変数ndに先頭に位置する発音データのインデクス値を代入し、更に要素iOrgCnt[iMyCh]の値をインクリメントしてから上記ステップ317に移行する。そうでない場合には、判定はYESとなってステップ324に移行し、その処理を実行した後はステップ1111に移行する。
【0149】
ステップ1111では、nd.iStatusとして2、nd.pSDとしてrd.iPitch対応したソースデータのインデクス値、nd.iPitchとしてrd.iPitch、nd.iResultとして0、nd.iChとしてrd.iCh、等をそれぞれ格納する。その後はステップ1112に移行して、nd.lOnStartとして変数lTimeの値、nd.lOffStartとして、rd.lOffStartの値からrd.lOnStartの値を引いた値を現在時刻に加算して得られる値、等をそれぞれ格納する。その次に移行するステップ1113では、変数rdにrd.nextを代入する。その代入後はステップ1114に移行して、rd.iChの値が変数変数iMyChの値と一致し、且つrd.iResultの値が4と一致するか否か判定する。それらの値が共に一致する場合、判定はYESとなって再度、ステップ1113の処理を実行する。そうでない場合には、つまりそれらのうちの少なくとも一方が一致しない場合には、判定はNOとなって上記ステップ302に戻る。
【0150】
図24は、本実施の形態における出力データ作成処理のフローチャートである。その作成処理は、図11に示すステップ403として、図12に示す作成処理の代わりに実行される。次に図24を参照して、本実施の形態における作成処理について詳細に説明する。ここでも他と同様に、図12に示すステップの処理内容と同じ、或いは基本的に同じステップには同一の符号を付すことにより、第1の実施の形態から異なる部分についてのみ説明する。
【0151】
本実施の形態では、ステップ508でサンプリングデータ読み取り処理を実行した後、ステップ1200に移行して、rd.iChの値が変数変数iMyChの値と一致するか否か判定する。それらの値が一致しない場合、判定はNOとなって上記ステップ509に移行する。そうでない場合には、判定はYESとなってステップ1201に移行し、nd.iStatusの値の判定を行う。その値が2と判定した場合、ステップ1202に移行し、変数iVtmpにそれまでの値の2倍の値を代入した後、上記ステップ509に移行する。その値が3と判定した場合には、ステップ1203に移行し、変数iVtmpにそれまでの値の1/2の値を代入した後、そのステップ509に移行する。それにより、押鍵すべきでないタイミングで押鍵していれば楽音の音量を小さく、押鍵すべきタイミングで押鍵していなければ楽音の音量を大きくさせる音量制御を行う。そのような音量制御は上記第2、或いは第3の実施の形態に適用させても良い。
【0152】
なお、本実施の形態(第1〜第4の実施の形態)は、PC等のデータ処理装置に本発明を適用したものである。その適用は、本実施の形態によるプログラムに相当する楽音発生アプリケーションをデータ処理装置に実行させることで実現させている。そのようなアプリケーションは電子楽器、音源装置等の楽音発生装置用に開発しても良い。開発したアプリケーションは、CD−ROM、DVD、或いは着脱自在なフラッシュメモリ等の記録媒体に記録させて配布しても良い。公衆網等の通信ネットワークを介して、そのプログラムの一部、若しくは全部を配信するようにしても良い。そのようにした場合には、ユーザーはプログラムを取得してデータ処理装置、或いは楽音発生装置にロードすることにより、その装置に本発明を適用させることができる。このことから、記録媒体は、プログラムを配信する装置がアクセスできるものであっても良い。
【図面の簡単な説明】
【0153】
【図1】第1の実施の形態による楽音発生装置の構成を説明する図である。
【図2】音色データの構成を説明する図である。
【図3】ピッチデータの構成を説明する図である。
【図4】ソースデータの構成を説明する図である。
【図5】発音データの構成を説明する図である。
【図6】演奏データの構成を説明する図である。
【図7】楽音の発音制御によって発音される楽音を説明する図である。
【図8】全体処理のフローチャートである。
【図9】MIDI IN処理のフローチャートである。
【図10】再生処理のフローチャートである。
【図11】オーディオデータ出力スレッドの実行によって実現される処理のフローチャートである。
【図12】出力データ作成処理のフローチャートである。
【図13】サンプリングデータ読み取り処理のフローチャートである。
【図14】楽音の発音制御によって発音される楽音を説明する図である(第2の実施の形態)。
【図15】第3の実施の形態でMIDI IN処理、及び再生処理にそれぞれ追加される部分のフローチャートである。
【図16】録音データ管理データの構成を説明する図である。
【図17】参加ユーザーデータの構成を説明する図である。
【図18】保存データの構成を説明する図である。
【図19】MIDI IN処理のフローチャートである(第4の実施の形態)。
【図20】再生処理のフローチャートである(第4の実施の形態)。
【図21】データ保存処理のフローチャートである。
【図22】録音データ再生処理のフローチャートである。
【図23】録音データガイド再生処理のフローチャートである。
【図24】出力データ作成処理のフローチャートである。
【符号の説明】
【0154】
10 楽音発生装置
11 CPU
12 RAM
13 ROM
14 入力部
15 表示部
16、21 MIDIインターフェース(I/F)
17 オーディオインクリメント(I/F)
20 電子楽器
22 キーボード
30 音源システム




 

 


     NEWS
会社検索順位 特許の出願数の順位が発表

URL変更
平成6年
平成7年
平成8年
平成9年
平成10年
平成11年
平成12年
平成13年


 
   お問い合わせ info@patentjp.com patentjp.com   Copyright 2007-2013