(57)【特許請求の範囲】
【請求項１】
演奏操作子群のなかで操作された演奏操作子に応じた楽音を発音させる楽音発音装置において、
前記演奏操作子群のなかで演奏の進行に応じて順次、操作していくべき演奏操作子、及び該演奏操作子の操作開始及び操作終了のタイミングを該演奏操作子単位で示す演奏情報を取得する演奏情報取得手段と、
前記演奏操作子群への操作開始及び操作終了のタイミングを検出するための操作検出手段と、
前記操作検出手段によりいずれかの演奏操作子の操作開始が検出された際、当該検出された操作開始のタイミングを発音開始タイミングとする第１発音データを生成して記憶手段に記憶するとともに、前記演奏情報取得手段により操作された演奏操作子に対応する操作開始のタイミングを示す演奏情報が取得された際、当該取得された操作開始のタイミングを発音開始タイミングとする第２発音データを生成して前記記憶手段に記憶する発音データ生成手段と、
前記操作検出手段によりいずれかの演奏操作子の操作開始タイミングが検出された際に、前記記憶手段に記憶された第２発音データの中から、当該操作された演奏操作子に対応しかつその発音開始タイミングと前記操作開始タイミングとの差が所定時間内である第２発音データを検索して、検索された第２発音データを第３発音データに変更するとともに、その発音開始タイミングを前記操作開始タイミングとする第１変更手段と、
前記演奏情報取得手段により取得された演奏情報においていずれかの操作子の操作開始タイミングが検出された際に、前記記憶手段に記憶された第１発音データのうち、当該操作された演奏操作子に対応しかつその発音開始タイミングと前記操作開始タイミングとの差が所定時間内である第１発音データを検索して、検索された第１発音データを第３発音データに変更するとともに、その発音開始タイミングを前記操作開始タイミングとする第２変更手段と、
前記操作検出手段によりいずれかの演奏操作子の操作終了が検出された際、前記記憶手段から当該演奏操作子に対応する発音データを検索し、検索された発音データが第３発音データである場合は当該第３発音データを第２発音データに変更して前記記憶手段に記憶するとともに、検索された発音データが第１発音データである場合は当該第１発音データを前記記憶手段から消去する第１発音データ消去手段と、
前記演奏情報取得手段により取得された演奏情報においていずれかの操作子の操作終了タイミングが検出された際、前記記憶手段から当該演奏操作子に対応する発音データを検索し、検索された発音データが第３発音データである場合は当該第３発音データを第１発音データに変更して前記記憶手段に記憶するとともに、検索された発音データが第２発音データである場合は当該第２発音データを前記記憶手段から消去する第２発音データ消去手段と、
前記記憶手段に前記第２発音データが記憶されている場合は、当該第２発音データに対応する発音開始タイミング又は前記第１発音データ消去手段により前記第３発音データを第２発音データに変更したタイミングにて当該第２発音データに基づいた楽音の発音を開始するとともに前記第２発音データ消去手段にて当該第２発音データが前記記憶手段から消去されたタイミングで当該楽音を消音し、前記記憶手段に前記第３発音データが記憶されている場合は、前記第３発音データに対応する発音開始タイミングにて当該第３発音データに基づく楽音の発音を開始するとともに前記第１発音データ消去手段又は第２発音データ消去手段にて前記第３発音データが前記第１又は第２発音データに変更されたタイミングで当該楽音を消音し、かつ前記第２発音データに基づいた楽音及び第３発音データに基づいた楽音を夫々異なる形態で発音させる楽音データ生成手段と、
を具備することを特徴とする楽音発生装置。
【請求項２】
前記楽音データ生成手段はさらに、第１発音データに基づいた楽音を、前記第２及び第３発音データに基づく楽音夫々とは異なる形態で生成する請求項１記載の楽音発生装置。
【請求項３】
前記楽音データ生成手段は、前記第３発音データに基づいた楽音の音量と比較して、前記第１発音データに基づいた楽音の音量を小さく、前記第２発音データに基づいた楽音の音量を大きくする請求項２記載の楽音発生装置。
【請求項４】
演奏操作子群のなかで操作された演奏操作子に応じた楽音を発音させる楽音発音装置として用いられるコンピュータに、
前記演奏操作子群のなかで演奏の進行に応じて順次、操作していくべき演奏操作子、及び該演奏操作子の操作開始及び操作終了のタイミングを該演奏操作子単位で示す演奏情報を取得する演奏情報取得機能と、
前記演奏操作子群への操作開始及び操作終了のタイミングを検出するための操作検出機能と、
前記操作検出機能によりいずれかの演奏操作子の操作開始が検出された際、当該検出された操作開始のタイミングを発音開始タイミングとする第１発音データを生成して記憶手段に記憶するとともに、前記演奏情報取得機能により操作された演奏操作子に対応する操作開始のタイミングを示す演奏情報が取得された際、当該取得された操作開始のタイミングを発音開始タイミングとする第２発音データを生成して前記記憶手段に記憶する発音データ生成機能と、
前記操作検出機能によりいずれかの演奏操作子の操作開始タイミングが検出された際に、前記記憶手段に記憶された第２発音データの中から、当該操作された演奏操作子に対応しかつその発音開始タイミングと前記操作開始タイミングとの差が所定時間内である第２発音データを検索して、検索された第２発音データを第３発音データに変更するとともに、その発音開始タイミングを前記操作開始タイミングとする第１変更機能と、
前記演奏情報取得機能により取得された演奏情報においていずれかの操作子の操作開始タイミングが検出された際に、前記記憶手段に記憶された第１発音データのうち、当該操作された演奏操作子に対応しかつその発音開始タイミングと前記操作開始タイミングとの差が所定時間内である第１発音データを検索して、検索された第１発音データを第３発音データに変更するとともに、その発音開始タイミングを前記操作開始タイミングとする第２変更機能と、
前記操作検出機能によりいずれかの演奏操作子の操作終了が検出された際、前記記憶手段から当該演奏操作子に対応する発音データを検索し、検索された発音データが第３発音データである場合は当該第３発音データを第２発音データに変更して前記記憶手段に記憶するとともに、検索された発音データが第１発音データである場合は当該第１発音データを前記記憶手段から消去する第１発音データ消去機能と、
前記演奏情報取得機能により取得された演奏情報においていずれかの操作子の操作終了タイミングが検出された際、前記記憶手段から当該演奏操作子に対応する発音データを検索し、検索された発音データが第３発音データである場合は当該第３発音データを第１発音データに変更して前記記憶手段に記憶するとともに、検索された発音データが第２発音データである場合は当該第２発音データを前記記憶手段から消去する第２発音データ消去機能と、
前記記憶手段に前記第２発音データが記憶されている場合は、当該第２発音データに対応する発音開始タイミング又は前記第１発音データ消去機能により前記第３発音データを第２発音データに変更したタイミングにて当該第２発音データに基づいた楽音の発音を開始するとともに前記第２発音データ消去機能にて当該第２発音データが前記記憶手段から消去されたタイミングで当該楽音を消音し、前記記憶手段に前記第３発音データが記憶されている場合は、前記第３発音データに対応する発音開始タイミングにて当該第３発音データに基づく楽音の発音を開始するとともに前記第１発音データ消去機能又は第２発音データ消去機能にて前記第３発音データが前記第１又は第２発音データに変更されたタイミングで当該楽音を消音し、かつ前記第２発音データに基づいた楽音及び第３発音データに基づいた楽音を夫々異なる形態で発音させる楽音データ生成機能と、
を実現させるためのプログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、演奏操作子群のなかで操作された演奏操作子に応じた楽音を発音させる楽音発音装置に関する。
【背景技術】
【０００２】
鍵盤などの演奏操作子群への操作に応じた楽音を発生させる楽音発生装置は様々な形で実現される。その演奏操作子群を備えた楽音発生装置のなかには、演奏の進行に応じて操作していくべき演奏操作子を視覚的にガイドする演奏ガイド機能を搭載したものがある。その演奏ガイド機能によるガイドは、演奏操作子群のなかで演奏の進行に応じて順次、操作していくべき演奏操作子、及びその演奏操作子を操作しているべき操作期間を演奏操作子単位で示す演奏情報を参照して行われる。その操作期間とは、演奏操作子への操作を開始すべきタイミングからその操作を解除すべきタイミングとなる期間のことである。
【０００３】
上記演奏ガイド機能を搭載した楽音発生装置としては、例えば特許文献１、２にそれぞれ記載されたものが挙げられる。視覚的なガイドに用いられる表示装置は、演奏操作子毎に発光素子を配置したもの（特許文献１）と、１箇所（エリア）で操作すべき演奏操作子を示すことができるもの（特許文献１、２）と、に大別できる。
【０００４】
特許文献１、２にそれぞれ記載された従来の楽音発生装置では、表示装置によるガイドに従って演奏操作子群への操作を行うことにより、楽曲を正しく演奏できる。演奏操作子群のなかでガイドされた演奏操作子を正しいタイミングで操作したか否かは、その演奏操作子を実際に操作したタイミングと表示装置によるガイドが行われたタイミングとからユーザー（演奏者）は確認することができる。しかし、その確認を行うためには、演奏の進行に合わせてガイド内容を随時、変化させる表示装置をユーザーは常に注意していなければならない。これはユーザーにとっては重い負担となり、演奏に集中できなくさせる可能性もある。このことから、表示装置を見ることなく、正しく演奏操作子を操作したか否か確認できるようにすることも重要であると言える。
【０００５】
表示装置を見ることなく、正しく演奏操作子を操作したか否か確認できるようにした従来の楽音発生装置としては、例えば特許文献３に記載されたものがある。その特許文献３に記載された従来の楽音発生装置では、ユーザーが操作した演奏操作子が操作期間内の演奏操作子か否かより異なる音を発音させるようになっている。それにより、ユーザーが操作すべき演奏操作子を操作すべき操作タイミングで操作すればその演奏操作子に応じた楽音（通常音）を発音させ、そうでなければその楽音とは音色の異なる警告音を発音させている。
【０００６】
上記のように発音させる音を変化させることにより、操作期間となった演奏操作子を操作したか否かの確認をユーザーは発音される音から迅速に行うことができる。しかし、通常音、或いは警告音の発音は、演奏操作子への操作によって行うため、演奏操作子を操作していない間に操作期間が経過した演奏操作子の存在やその操作期間は発音された音から認識することができない。このことから、正しく演奏操作子を操作したか否かを音によって確認できるようにする場合には、操作期間に演奏操作子をユーザーが操作しなかったときのことも想定すべきと考えられる。
【０００７】
特許文献４には、演奏操作子への操作によって発音させる楽音の音量を制御する従来の楽音発生装置が記載されている。音量を制御することにより、演奏操作子への操作が適切に行われたか否かを通知することができる。しかし、特許文献３に記載された従来の楽音発生装置と同様に、演奏操作子を操作していない間に操作期間が経過した演奏操作子の存在やその操作期間は発音させた音からユーザーに認識させることができない。
【特許文献１】特開平１０−９７１８１号公報
【特許文献２】特開２００４−８５８２１号公報
【特許文献３】実開昭６０−１５０５７７号公報
【特許文献４】特開２００４−２０５８９２号公報
【発明の開示】
【発明が解決しようとする課題】
【０００８】
本発明の課題は、演奏操作子への操作の有無に係わらず、操作期間となった演奏操作子の存在を音によって通知できる楽音発生装置を提供することにある。
【課題を解決するための手段】
【０００９】
本発明の楽音発生装置は、演奏操作子群のなかで操作された演奏操作子に応じた楽音を発音させることを前提とするものであり、前記演奏操作子群のなかで演奏の進行に応じて順次、操作していくべき演奏操作子、及び該演奏操作子の操作開始及び操作終了のタイミングを該演奏操作子単位で示す演奏情報を取得する演奏情報取得手段と、前記演奏操作子群への操作開始及び操作終了のタイミングを検出するための操作検出手段と、前記操作検出手段によりいずれかの演奏操作子の操作開始が検出された際、当該検出された操作開始のタイミングを発音開始タイミングとする第１発音データを生成して記憶手段に記憶するとともに、前記演奏情報取得手段により操作された演奏操作子に対応する操作開始のタイミングを示す演奏情報が取得された際、当該取得された操作開始のタイミングを発音開始タイミングとする第２発音データを生成して前記記憶手段に記憶する発音データ生成手段と、前記操作検出手段によりいずれかの演奏操作子の操作開始タイミングが検出された際に、前記記憶手段に記憶された第２発音データの中から、当該操作された演奏操作子に対応しかつその発音開始タイミングと前記操作開始タイミングとの差が所定時間内である第２発音データを検索して、検索された第２発音データを第３発音データに変更するとともに、その発音開始タイミングを前記操作開始タイミングとする第１変更手段と、前記演奏情報取得手段により取得された演奏情報においていずれかの操作子の操作開始タイミングが検出された際に、前記記憶手段に記憶された第１発音データのうち、当該操作された演奏操作子に対応しかつその発音開始タイミングと前記操作開始タイミングとの差が所定時間内である第１発音データを検索して、検索された第１発音データを第３発音データに変更するとともに、その発音開始タイミングを前記操作開始タイミングとする第２変更手段と、前記操作検出手段によりいずれかの演奏操作子の操作終了が検出された際、前記記憶手段から当該演奏操作子に対応する発音データを検索し、検索された発音データが第３発音データである場合は当該第３発音データを第２発音データに変更して前記記憶手段に記憶するとともに、検索された発音データが第１発音データである場合は当該第１発音データを前記記憶手段から消去する第１発音データ消去手段と、前記演奏情報取得手段により取得された演奏情報においていずれかの操作子の操作終了タイミングが検出された際、前記記憶手段から当該演奏操作子に対応する発音データを検索し、検索された発音データが第３発音データである場合は当該第３発音データを第１発音データに変更して前記記憶手段に記憶するとともに、検索された発音データが第２発音データである場合は当該第２発音データを前記記憶手段から消去する第２発音データ消去手段と、前記記憶手段に前記第２発音データが記憶されている場合は、当該第２発音データに対応する発音開始タイミング又は前記第１発音データ消去手段により前記第３発音データを第２発音データに変更したタイミングにて当該第２発音データに基づいた楽音の発音を開始するとともに前記第２発音データ消去手段にて当該第２発音データが前記記憶手段から消去されたタイミングで当該楽音を消音し、前記記憶手段に前記第３発音データが記憶されている場合は、前記第３発音データに対応する発音開始タイミングにて当該第３発音データに基づく楽音の発音を開始するとともに前記第１発音データ消去手段又は第２発音データ消去手段にて前記第３発音データが前記第１又は第２発音データに変更されたタイミングで当該楽音を消音し、かつ前記第２発音データに基づいた楽音及び第３発音データに基づいた楽音を夫々異なる形態で発音させる楽音データ生成手段と、を具備する。
【００１０】
なお、前記楽音データ生成手段はさらに、第１発音データに基づいた楽音を、前記第２及び第３発音データに基づく楽音夫々とは異なる形態で生成することが望ましい。また、前記楽音データ生成手段は、前記第３発音データに基づいた楽音の音量と比較して、前記第１発音データに基づいた楽音の音量を小さく、前記第２発音データに基づいた楽音の音量を大きくすることが望ましい。
【００１１】
本発明のプログラムは、上記楽音発生装置が具備する各手段を実現させるための複数の機能を搭載している。
【発明の効果】
【００１２】
本発明は、演奏操作子群のなかで演奏の進行に応じて順次、操作していくべき演奏操作子、及びその演奏操作子を操作しているべき操作期間を演奏操作子単位で示す演奏情報を参照し、その操作期間を示す演奏操作子が存在する状況下で楽音を発音させる。その楽音の種類は、操作期間となった演奏操作子に対して行われた操作に応じて選択し決定する。
【００１３】
具体的には例えば、適切と言えるタイミングで操作が開始された場合、そのことを通知するための楽音を選択し、そうでない場合には、不適切なタイミングで操作が開始したことを通知するための楽音を選択する。このとき、操作期間が到来した後（操作期間が開始するタイミングとなった後）に操作が開始されたのであれば、操作期間の開始から操作が実際に開始されるまでの間は操作が遅れたことを通知するための楽音を発音させる。一方、操作期間が過ぎる前（操作期間が終了するタイミングとなる前）に操作が解除されたのであれば、不適切なタイミングで操作が解除されたことを通知するための楽音をその操作期間が過ぎるまでは少なくとも発音させる。そのように発音させる種類の楽音を１つ以上、選択・決定し、操作期間内にわたって（操作期間の開始から終了まで）発音させる。このため、演奏操作子への操作の有無に係わらず、ユーザーは操作期間となった演奏操作子の存在を音によって容易に認識することができる。また、自身が適切に操作を行った期間も容易に確認することができる。
【発明を実施するための最良の形態】
【００１４】
以下、本発明の実施の形態について、図面を参照しながら詳細に説明する。
＜第１の実施の形態＞
図１は、第１の実施の形態による楽音発生装置の構成を説明する図である。
【００１５】
その楽音発生装置１０は、図１に示すように、装置１０全体の制御を行うＣＰＵ１１と、そのＣＰＵ１１がワークに用いるＲＡＭ１２と、ＣＰＵ１１が実行するプログラムや各種制御用データ、及び波形データ等を格納したＲＯＭ１０３と、例えばキーボードやポインティングデバイス（マウス等）、ＣＤ−ＲＯＭやＤＶＤ等の記録媒体にアクセスする媒体駆動装置、及びそれらのインターフェース等からなる入力部１４と、表示装置に画像を表示させる表示部１５と、外部装置との間でＭＩＤＩデータを送受信するためのＭＩＤＩインターフェース（Ｉ／Ｆ）１６と、発音させる楽音のデジタルデータ（波高値）を外部装置に出力するためのオーディオインターフェース（Ｉ／Ｆ）１７と、を備えた構成となっている。
【００１６】
上記ＭＩＤＩ  Ｉ／Ｆ１６には、それとＭＩＤＩデータを送受信可能なＭＩＤＩインターフェース（Ｉ／Ｆ）２１、及びキーボード２２を備えた電子楽器２０が接続され、上記オーディオＩ／Ｆ１７には、波高値を入力して音声に変換できる音源システム３０が接続されている。ＭＩＤＩ  Ｉ／Ｆ２１は、キーボード２２に対する操作内容を示すＭＩＤＩデータを生成する機能を備えている。それにより、本実施の形態による楽音発生装置１０は、電子楽器２０のＭＩＤＩ  Ｉ／Ｆ２１からＭＩＤＩデータを入力して、そのＭＩＤＩデータにより発音が要求された楽音の波高値を生成し、それを音源システム３０に出力することにより楽音を発音させるようになっている。音源システム３０は、例えばＤ／Ａ変換器、アンプ、及びスピーカを少なくとも備えたものである。
【００１７】
その楽音発生装置１０は、例えばパーソナルコンピューター（ＰＣ）に、楽音発生装置１０として動作させるためのアプリケーション・プログラム（以下「アプリケーション」）を搭載させることにより実現させている。そのアプリケーションは、例えば入力部１４を構成する媒体駆動装置がアクセス可能な記録媒体に記録して提供するものである。そのアプリケーションは、インターネット等のネットワークを介して配信するようにしても良い。
【００１８】
アプリケーションを搭載（インストール）できるように、ＲＯＭ１３としては書き込み可能なメモリ（例えばフラッシュメモリ）が採用されている。そのアプリケーションが記録された記録媒体には、楽音の波高値を生成するための各種波形データが多数、記録されている。その波形データには、音色が異なる楽音発音用のものも含まれている。音色が同じ波形データはピッチ毎に用意されている。楽音発生装置１０を実現させるＰＣは、ＲＯＭ１３の他に、或いはその代わりにハードディスク装置等の補助記憶装置を搭載したものであっても良い。そのアプリケーションについては以降「楽音発生アプリケーション」と呼ぶことにする。
【００１９】
各種波形データは、ＲＯＭ１３に保存させることができるようになっている。また、必要に応じて、記録媒体からコピーすることもできるようにしている。ここでは説明上、便宜的にＲＯＭ１３に保存されている場合のみを想定する。
【００２０】
ＲＯＭ１３に保存した波形データは、ＲＡＭ１２にコピーして使用している。これは、一般的にＲＡＭ１２はＲＯＭ１３よりもアクセス速度が速いからである。それにより、より高速に、発音させるべき楽音の波高値を生成できるようにしている。
【００２１】
波形データをピッチ毎に用意することにより、それを構成するサンプリングデータ（波高値）は単に順次、読み出せば良いようにしている。それにより、データを読み出す速さ（歩進幅）に応じた補間を行わなくとも良いようにしている。
【００２２】
ユーザーは、電子楽器２０のキーボード２２を操作して演奏を行う。その演奏では、演奏の進行に合わせて、キーボード２２を構成する鍵のなかで押鍵（操作）すべき鍵を順次、押鍵していくことが求められる。本実施の形態では、押鍵すべき鍵を適切（正確）に押鍵できたか否かユーザーが認識できるように、楽音の発音制御を行うようにしている。押鍵すべき鍵、その押鍵を行っているべき操作期間（押鍵から離鍵までの期間。以降「押鍵時間」と呼ぶ）は、それらを鍵（楽音）単位で示す演奏情報を参照して特定している。
【００２３】
図７は、楽音の発音制御によって発音される楽音を説明する図である。その図７では、演奏情報が示す或る鍵の押鍵時間が到来、つまり押鍵すべきタイミングとなった時点より時間ａだけ早くユーザーが押鍵した場合（ケース１）、そのタイミングより時間ｂだけ遅れてユーザーが押鍵した場合（ケース２）、及び離鍵すべきタイミングとなってもユーザーが離鍵しなかった場合（ケース３）に発音される楽音を示している。
【００２４】
ケース１では、ユーザーの押鍵時間は押鍵すべきタイミングの時間ａ前から離鍵すべきタイミングが到来する前となっている。そのような押鍵時間でユーザーが押鍵を行うと、時間ａが押鍵すべきタイミングと一致すると見なせるだけ短ければ、その押鍵時間内はユーザーが押鍵した鍵に割り当てた楽音（以降「設定音」と呼ぶ）を発音させ、それ以降は、演奏情報が示す押鍵時間が終了するまで、その楽音とは異なる音色の楽音（以降「警告音」と呼ぶ）を発音させる。その時間ａが押鍵すべきタイミングと一致すると見なせるだけ短くなければ、演奏情報が示す押鍵時間内、全てにわたって警告音を発音させる。
【００２５】
ケース２では、ユーザーの押鍵時間は押鍵すべきタイミングの時間ｂ後から離鍵すべきタイミングが到来する前となっている。そのような押鍵時間でユーザーが押鍵を行うと、時間ｂが押鍵すべきタイミングと一致すると見なせるだけ短ければ、その時間ｂ内、及びユーザーが離鍵してから演奏情報が示す押鍵時間が終了するまでの間は警告音を発音させ、残りの時間、つまりユーザーの押鍵時間内は設定音を発音させる。その時間ｂが押鍵すべきタイミングと一致すると見なせるだけ短くなければ、演奏情報が示す押鍵時間内、全てにわたって警告音を発音させる。
【００２６】
ケース３では、ユーザーの押鍵時間は押鍵すべきタイミングから離鍵すべきタイミングの後となっている。そのような押鍵時間でユーザーが押鍵を行うと、演奏情報が示す押鍵時間内は設定音を発音させ、離鍵すべきタイミングからユーザーが実際に離鍵するまでの間は何れの楽音も発音させない。つまり無音とさせる。
【００２７】
このようにして、本実施の形態では、ユーザーが押鍵を行ったタイミングが適切と見なせるか否かにより、その押鍵によって楽音の種類を選択して発音させ、ユーザーが離鍵を行ったタイミングにより、警告音の発音、或いは発音中の設定音の消音を行う。このため、ユーザーは、発音された楽音から、自身が押鍵、及び離鍵のそれぞれを適切なタイミングで行ったか否か容易に認識することができるようになっている。たとえ押鍵を行わなくとも演奏情報が示す押鍵時間内は警告音が発音されるため（ケース２の時間ｂが短くないと見なしたときと同じとなる）、押鍵すべき鍵の存在、及びその押鍵時間をユーザーは認識することができる。以降、混乱を避けるため、ユーザーによる押鍵時間を「実押鍵時間」、演奏情報が示す押鍵時間を「正押鍵時間」と表記する。
【００２８】
図７に示すような発音制御を行うために、本実施の形態では図２〜図６に示す各種データを管理している。ここで図２〜図６を参照して、それらのデータについて具体的に説明する。また、説明上、便宜的に、以降の説明では特に断らない限り、その発音制御を行うことを前提とする。その発音制御によりユーザーに音声で演奏内容を知らせることを「発音ガイド」と呼ぶことにする。
【００２９】
図２は、音色データの構成を説明する図である。その音色データは、波形データを音色単位で管理するために音色毎に用意されるデータである。図２に示すように、音色データは、対応するチャンネル番号を示すデータｉＩＤ、発音中の楽音数を示すデータｉＮｏｔｅＯｎＣｎｔ、対応するピッチデータのなかで先頭ピッチ（例えば最低ピッチ）のピッチデータの格納場所を示すデータｐＴＤ、前の音色データの格納場所を示すデータｐＰｒｅｖ、及び次の音色データの格納場所を示すデータｐＮｅｘｔ、を備えている。
【００３０】
図３は、ピッチデータの構成を説明する図である。そのピッチデータは、音色毎、ピッチ毎に用意されるデータであり、上記データｐＴＤとしては、対応する音色での先頭ピッチのピッチデータの格納場所を示すデータがそれぞれの音色データに格納される。図３に示すように、ピッチデータは、対応するピッチを示すデータｉＰｉｔｃｈ（ピッチ番号（ノートナンバー））、対応するソースデータの格納場所を示すデータｐＳＤ、前のピッチデータの格納場所を示すデータｐＰｒｅｖ、及び次のピッチデータの格納場所を示すデータｐＮｅｘｔ、を備えている。
【００３１】
図４は、ソースデータの構成を説明する図である。そのソースデータは、波形データ毎に用意されるデータである。図４に示すように、ソースデータは、対応する波形データのＲＡＭ１２にコピーされた波形データの先頭アドレスを示すデータｐＤＡｔａ、波形データのファイル名（オリジナルの格納場所）を示すデータｆｉｌｅＮａｍｅ、その波形データ全体の長さを示すデータｆＬｅｎｇｔｈ、波形データが対応するベロシティ範囲の下限値を示すデータｍｉｎＶｅｌ、その上限値を示すデータｍａｘＶｅｌ、前のピッチデータの格納場所を示すデータｐＰｒｅｖ、及び次のピッチデータの格納場所を示すデータｐＮｅｘｔ、を備えている。
【００３２】
発音させる楽音の種類の変更は、その発音に用いる波形データを変更することで行うようにしている。そのため、上記データｐＤＡｔａ、ｆｉｌｅＮａｍｅ、及びｆＬｅｎｇｔｈは、発音対象となる楽音の種類毎に格納している。
【００３３】
図５は、発音データの構成を説明する図である。その発音データは、演奏情報が示す、演奏中に発音させるべき楽音毎に用意されるデータである。図５に示すように、発音データは、識別情報であるデータｉＩＤ、対応する音色データ（チャンネル）を示すデータｉＴｏｎｅ（例えば対応する音色データ中のデータｉＩＤ）、楽音のピッチを示すデータｉＰｉｔｃｈ、そのベロシティを示すデータｉＯｎＶｅｌ、そのピッチの楽音の状態を示すデータｉＳｔａｔｕｓ（−１の値は消音中、０の値は消音状態、１の値は演奏情報が示す押鍵時間であり、且つユーザーが押鍵中である状態、２の値は演奏情報が示す押鍵時間であり、且つユーザーが押鍵していない状態（押鍵が遅れている状態）、３の値は演奏情報が示す押鍵時間でなく、且つユーザーが押鍵中である状態（押鍵が早く行われたような状態）、をそれぞれ表す）、対応する演奏データの格納場所を示すデータｐＭＥ、対応するソースデータの格納場所を示すデータｐＳＤ、対応する演奏データによる発音開始時刻を示すデータｌＯｎＳｔａｒｔ、その消音開始時刻を示すデータｌＯｆｆＳｔａｒｔ、ユーザーによる押鍵時刻（タイミング）を示すデータｌＮｏｔｅＯｎ、その離鍵時刻（タイミング）を示すデータｌＮｏｔｅＯｆｆ、消音処理中での減衰率を示すデータｆＲｅｌｅａｓｅ、前の発音データの格納場所を示すデータｐＰｒｅｖ、及び次の発音データの格納場所を示すデータｐＮｅｘｔ、を備えている。上記データｉＯｎＶｅｌは電子楽器２０から入力するＭＩＤＩデータ中から抽出したベロシティ値である。そのベロシティ値は、周知のように、押鍵時の速さ、つまり楽音を発音させる強さを表している。
【００３４】
波形データの選択、つまり上記データｐＤＡｔａ、ｆｉｌｅＮａｍｅ、及びｆＬｅｎｇｔｈのなかで対象とすべきものの選択は、データｉＳｔａｔｕｓ（の値）に応じて行うようになっている。それにより、データｉＳｔａｔｕｓの値に応じた種類の楽音を発音させている。
【００３５】
上記発音データは演奏中に順次、作成され、随時、更新される。それ以外のデータ、つまり音色データ、ピッチデータ、及びソースデータでは、演奏開始前に作成され、演奏中に更新は行われない。
【００３６】
演奏情報には、発音させるべき楽音毎にデータが用意されている。そのデータが演奏データである。その演奏データは、図６に示すように、楽音の発音を開始すべきタイミング（発音開始時刻）を示すデータｌＴｉｍｅ、その発音を持続させるべき発音時間を示すデータｌＧａｔｅ，そのピッチを示すデータＰｉｔｃｈ、そのベロシティを示すデータＶｅｌ、前の演奏データの格納場所を示すデータｐＰｒｅｖ、及び次の演奏データの格納場所を示すデータｐＮｅｘｔ、を備えている。
【００３７】
データｌＴｉｍｅが示す発音開始時刻は、例えば演奏開始を基準に、それから経過した時間である。それは、発音データにデータｌＯｎＳｔａｒｔとしてコピーされる。それにより、データｌＯｆｆＳｔａｒｔは、その発音開始時刻からデータｌＧａｔｅが示す発音時間だけ後の時間である。
【００３８】
以降は図８〜図１３に示す各種フローチャートを参照して、上述のデータを管理して発音制御を行う楽音発生装置１０の動作について詳細に説明する。その動作は、ＣＰＵ１３が、上記楽音発生アプリケーションをＲＯＭ１３からＲＡＭ１２に読み出して実行することで実現される。
【００３９】
図８は、全体処理のフローチャートである。これは、上記楽音発生アプリケーションを起動させてから終了させるまでの間に実行される処理を抜粋してその流れを示したものである。始めに図８を参照して、その全体処理について詳細に説明する。
【００４０】
先ず、ステップ１０１では、ＭＩＤＩ  Ｉ／Ｆ１６用のドライバをＲＯＭ１３からＲＡＭ１２にロードして起動させる。続くステップ１０２では、同様にオーディオＩ／Ｆ１７用のドライバをロードして起動させる。以降は、発音させるべき楽音の波高値（オーディオデータ）をオーディオＩ／Ｆ１７から出力するためのオーディオデータ出力スレッドを起動させ（ステップ１０３）、音色定義ファイルとしてＲＯＭ１３に保存されている図２〜図４に示す各種データを読み込んでＲＡＭ１２に展開し（ステップ１０４）、ピッチ毎にその波形データ（図中「音色データ」と表記）をＲＯＭ１３から読み出してＲＡＭ１２にロードする（ステップ１０５）。そのロードにより初期化が終了し、ステップ１０６に移行して、入力部１４、或いはＭＩＤＩ  Ｉ／Ｆ１６によるデータの入力を待つ。ここでは、入力部１４を操作してのデータ入力については、楽音発生アプリケーションの終了指示、発音ガイドの開始、その停止（終了）のみを想定する。
【００４１】
電子楽器２０のキーボード２２を構成するキー（鍵）をユーザーが押鍵、或いは離鍵すると、ＭＩＤＩ  Ｉ／Ｆ２１はその演奏操作の内容、及びその操作が行われたキーに応じたＭＩＤＩデータを生成して楽音発生装置１０のＭＩＤＩ  Ｉ／Ｆ１６に出力する。入力部１４を構成するキーボード、或いはポインティングデバイスを操作すると、その操作内容が入力部１４からＣＰＵ１１に通知される。それにより、ステップ１０６からステップ１０７に移行し、入力が楽音発生アプリケーションの終了コマンドか否か判定する。そのアプリケーションを終了させるための操作をユーザーが入力部１４に対して行った場合、判定はＹＥＳとなってステップ１１４に移行する。そうでない場合には、判定はＮＯとなってステップ１０８に移行する。
【００４２】
ステップ１０８では、入力がＭＩＤＩデータか否か判定する。ＭＩＤＩ  Ｉ／Ｆ１６がＭＩＤＩデータを入力した場合、判定はＹＥＳとなり、ステップ１０９に移行して、その入力に対応するためのＭＩＤＩ  ＩＮ処理を実行した後、上記ステップ１０６に戻る。一方、そうでない場合には、判定はＮＯとなってステップ１１０に移行する。
【００４３】
ステップ１１０では、上記発音ガイドの開始を指示するための再生開始コマンドを入力したか否か判定する。ユーザーがそのコマンド入力のための操作を入力部１４に対して行った場合、判定はＹＥＳとなってステップ１１１に移行し、発音ガイドのための再生処理を起動した後、上記ステップ１０６に戻る。そうでない場合には、判定はＮＯとなってステップ１１２に移行する。
【００４４】
ステップ１１２では、上記発音ガイドの停止を指示するための再生停止コマンドを入力したか否か判定する。ユーザーがそのコマンド入力のための操作を入力部１４に対して行った場合、判定はＹＥＳとなってステップ１１３に移行し、再生処理の実行を管理するための変数である再生停止フラグをオン、つまりその実行停止を示す値を代入した後、上記ステップ１０６に戻る。そうでない場合には、判定はＮＯとなり、他のステップの処理を実行することなく、そのステップ１０６に戻る。
【００４５】
上記ステップ１０７の判定がＹＥＳとなって移行するステップ１１４では、オーディオデータ出力スレッドを終了させる。その終了は、例えばそのスレッド終了管理用の変数に、終了を指示する値を代入することで行う。以降は、ＲＡＭ１２に格納されている図２〜図６に示す各種データを消去し（ステップ１１５）、オーディオＩ／Ｆ１７のドライバを終了（開放）させ（ステップ１１６）、ＭＩＤＩ  Ｉ／Ｆ１６のドライバを終了（開放）させる（ステップ１１７）。そのようにして各種ドライバやデータをＲＡＭ１２から消去させた後、一連の処理を終了、つまり楽音発生アプリケーションを終了させる。
【００４６】
図９は、上記ステップ１０９として実行されるＭＩＤＩ  ＩＮ処理のフローチャートである。次にそのＩＮ処理について、図９に示すそのフローチャートを参照して詳細に説明する。
【００４７】
このＩＮ処理は、ＭＩＤＩ  Ｉ／Ｆ１７を介して入力したＭＩＤＩデータに対応するための処理である。そのＭＩＤＩデータの種類は多数、存在するが、ここでは本発明に特に係わるデータ、つまりノートオンメッセージ、ノートオフメッセージの２種類のＭＩＤＩデータのみにのみ注目して説明する。
【００４８】
上述したように、発音データ中のデータｌＯｎＳｔａｒｔ（演奏データ中のデータｌＴｉｍｅ）は演奏開始からの時間を示している。そのような時間で押鍵すべきタイミングを表していることから、再生処理の起動時に時間を計時するためのカウントを０から開始させるようにしている。そのカウント、つまり時間の計時は、例えばＣＰＵ１１に内蔵のハードタイマを用いて行っている。特に断らない限り、現在時刻はそのようにして計時した時間を指す意味で用いる。
【００４９】
先ず、ステップ２０１では、入力したＭＩＤＩデータが楽音の発音開始を指示するノートオンメッセージか否か判定する。そのＭＩＤＩデータがノートオンメッセージでなかった場合、判定はＮＯとなってステップ２１２に移行する。そうでない場合には、判定はＹＥＳとなってステップ２０２に移行する。
【００５０】
ステップ２０２では、入力したＭＩＤＩデータから、チャンネル番号、ノートナンバー（ピッチ）、及びベロシティ値を抽出し、それぞれ変数ｉｃｈ、ｉＰｉｔ、及びｉＶｅｌに代入する。続くステップ２０３では、変数ｎｄに、発音データのなかで先頭に位置する発音データの格納場所を示すインデクス値を代入する。その代入後に移行するステップ２０４〜２０９では、入力したＭＩＤＩデータに応じて、対応する発音データを作成、或いは更新するための処理を行う。
【００５１】
先ず、ステップ２０４では、変数ｎｄの値が示す発音データが存在しないか否か判定する。今回、入力したＭＩＤＩデータに対応する発音データは、変数ｎｄの値で指定される発音データ中のデータｐＮｅｘｔをその変数ｎｄに新たに代入していくことにより、順次、対象とする発音データを変更しながら探すようになっている。最後に位置する発音データにはそれに続く発音データが存在しないため、データｐＮｅｘｔの値は初期値のままとなっている。このため、変数ｎｄに新たに代入した値がその初期値であった場合、判定はＹＥＳとなってステップ２１０に移行する。そうでない場合には、判定はＮＯとなってステップ２０５に移行する。ここでのＹＥＳの判定は、ユーザーが押鍵すべきタイミングとなる前の鍵を押鍵したことを意味する。
【００５２】
ステップ２０５では、変数ｎｄの値で指定される発音データ中のデータｉＳｔａｔｕｓ（図中「ｎｄ．ｉＳｔａｔｕｓ」と表記。以降、他のデータでも同じ表記法を用いる）の値が２と一致し、且つｎｄ．ｉＰｉｔｃｈが示すピッチ番号が変数ｉＰｉｔのそれと一致するか否か判定する。それらのうちの少なくとも一つが一致しない場合、判定はＮＯとなってステップ２０６に移行し、変数ｎｄにｎｄ．ｐＮｅｘｔを代入した後、上記ステップ２０４に戻る。そうでない場合には、つまりそれらが共に一致する場合には、判定はＹＥＳとなってステップ２０７に移行する。
【００５３】
ステップ２０７では、現在時刻（再生処理起動から経過した時間）からｎｄ．ｌＯｎＳｔａｒｔが示す時間を引いて得られる時間が、許容できるとする最大時間を示す定数ＤＥＬＡＹ＿ＡＬＬＯＷより小さいか否か判定する。ここではその時間は押鍵が遅れた時間ｂを表している（図７のケース２）。このため、時間ｂが十分に短いような場合、判定はＹＥＳとなり、ｎｄ．ｉＳｔａｔｕｓの値を１に更新し（ステップ２０８）、更にｎｄ．ｉＴｏｎｅを変数ｉＣｈの値、ｎｄ．ｉＮｏｔｅＯｎを現在時刻、ｎｄ．ｉＯｎＶｅｌを変数ｉＶｅｌの値、ｎｅ．ｐＳＤを設定音のデータｉＰｉｔｃｈが一致するピッチデータ中のデータｐＳＤにそれぞれ更新してから（ステップ２０９）、一連の処理を終了する。そうでない場合には、判定はＮＯとなって上記ステップ２０６に移行する。
【００５４】
このようにして、変数ｎｄの値をインクリメントしながら、その値で指定される発音データが、入力したＭＩＤＩデータに対応するものか否か確認し、対応していると確認できた発音データの更新を行うようにしている。その更新により、時間ｂが許容範囲内であればユーザーは適切なタイミングで押鍵したとして、その押鍵以降、警告音から設定音に切り換えられる（図７のケース２）。一方、その確認ができなかった場合には、ステップ２０４の判定がＹＥＳとなって、ステップ２１０に移行することになる。
【００５５】
そのステップ２１０では、変数ｎｄに、新たに作成する発音データの格納場所を示すインデクス値を代入する。また、ｎｄ．ｐＰｒｅｖとしてはそれまで最後に位置していた発音データのインデクス値を格納し、その発音データ中のデータｐＮｅｘｔは変数ｎｄの値に更新する。ｎｄ．ｐＮｅｘｔとしては、最後に位置する発音データであることを示す値を格納する。続くステップ２１１では、ｎｄ．ｉＳｔａｔｕｓとして３、ｎｄ．ｉＰｉｔｃｈとして変数ｉＰｉｔの値をそれぞれ格納する。また、ｎｄ．ｆＲｅｌｅａｓｅ、ｎｄ．ｐＮｅｘｔ、ｎｄ．ｌＯｎＳｔａｒｔ、ｎｄ．ｌＯｆｆＳｔａｒｔ、ｎｄ．ｌＮｏｔｅＯｆｆとして例えばそれぞれ所定の初期値を格納する。その後に上記ステップ２０９に移行する。
【００５６】
上述したように、時間ｂが許容範囲内でなければ、入力したＭＩＤＩデータに対応する発音データを既に作成されたもののなかから確認できない。このため、ステップ２０４の判定がＹＥＳとなって新たに発音データが作成されることになる。その結果、ユーザーが押鍵時間内に押鍵を行ったとしても、ユーザーは不適切なタイミングで押鍵したとして、その押鍵以降も警告音の発音が継続することとなる（図７のケース２）。
【００５７】
上記ステップ２０１の判定がＮＯとなって移行するステップ２１２では、入力したＭＩＤＩデータが楽音の発音終了を指示するノートオフメッセージか否か判定する。そのＭＩＤＩデータがノートオフメッセージだった場合、判定はＹＥＳとなってステップ２１３に移行する。そうでない場合には、判定はＮＯとなり、ここで一連の処理を終了する。
【００５８】
ステップ２１３では、入力したＭＩＤＩデータから、チャンネル番号、及びピッチ番号（ノートナンバー）を抽出し、それぞれ変数ｉＣｈ、及びｉＰｉｔに代入する。続くステップ２１４では、変数ｎｄに、先頭に位置する発音データのインデクス値を代入する。その代入後に移行するステップ２１５では、変数ｎｄの値で指定される発音データが存在しないか否か判定する。その発音データが存在しない場合、判定はＹＥＳとなり、ここで一連の処理を終了する。それにより、入力したＭＩＤＩデータを無効とする。一方、そうでない場合には、判定はＮＯとなってステップ２１６に移行する。
【００５９】
ステップ２１６では、ｎｄ．ｉＰｉｔｃｈの値が変数ｉＰｉｔの値と一致するか否か判定する。それらが一致する場合、判定はＹＥＳとなってステップ２１８に移行し、そうでない場合には、判定はＮＯとなり、ステップ２１７で変数ｎｄにｎｄ．ｐＮｅｘｔを代入した後、上記ステップ２１５に戻る。
【００６０】
ステップ２１８では、ｎｄ．ｉＳｔａｔｕｓの値が１か否か判定する。その値が１であった場合、判定はＹＥＳとなり、ユーザーは離鍵すべきタイミングとなる前の鍵を離鍵したとして（図７のケース１、２）、ステップ２１９でｎｄ．ｉＳｔａｔｕｓの値を２に更新し、更にステップ２２０でｎｄ．ｌＮｏｔｅＯｆｆを現在時刻に更新した後、一連の処理を終了する。そうでない場合には、判定はＮＯとなってステップ２２１に移行する。
【００６１】
ステップ２２１では、ｎｄ．ｉＳｔａｔｕｓの値が３か否か判定する。その値が３であった場合、判定はＹＥＳとなり、ステップ２２２でｎｄ．ｉＳｔａｔｕｓの値を−１に更新した後、上記ステップ２２０に移行する。そうでない場合には、判定はＮＯとなって上記ステップ２１７に移行する。ここでのＹＥＳの判定は、主に離鍵すべきタイミングとなった鍵をユーザーが離鍵していないことを意味する（図７のケース３）。
【００６２】
図１０は、図８に示す全体処理内のステップ１１１で起動される再生処理のフローチャートである。次に図１０を参照して、その再生処理について詳細に説明する。
先ず、ステップ３０１では、変数ｍｅに、演奏情報のなかで先頭に位置する演奏データの格納場所を示すインデクス値を代入する。続くステップ３０２では、上記再生停止フラグがオンとなっているか否か判定する。再生停止コマンドの入力によってそのフラグがオンされた場合、判定はＹＥＳとなり、ステップ３０３で発音データ全てのデータｉＳｔａｔｕｓの値を０に更新した後、一連の処理を終了する。そうでない場合には、判定はＮＯとなってステップ３０４に移行する。
【００６３】
ステップ３０４では、発音中の楽音の存在を確認するための変数ＡｌｌＯｆｆに、それが存在しないことを示す値の１を代入し、変数ｎｄに、先頭に位置する発音データのインデクス値を代入する。次のステップ３０５では、変数ｎｄの値で指定される発音データが存在しないか否か判定する。その発音データが存在しない場合、判定はＹＥＳとなってステップ３１４に移行する。そうでない場合には、判定はＮＯとなってステップ３０６に移行する。そのステップ３０６〜３１３では、演奏データを参照して、ユーザーによる離鍵時刻に着目した発音データの更新を行うための処理が行われる。
【００６４】
先ず、ステップ３０６では、ｎｄ．ｉＳｔａｔｕｓの値が０以外か否か、つまり変数ｎｄの値で指定される発音データによって楽音を発音させていないか否か判定する。楽音を発音させていない場合、判定はＮＯとなり、ステップ３０７で変数ｎｄにｎｄ．ｐＮｅｘｔを代入した後、上記ステップ３０５に戻る。そうでない場合には、判定はＹＥＳとなってステップ３０８に移行する。
【００６５】
ステップ３０８では、楽音が発音中であることを示す値の０を変数ＡｌｌＯｆｆに代入する。次のステップ３０９では、ｎｄ．ｌＯｆｆＳｔａｒｔが示す消音開始時刻が現在時刻より前か否か判定する。現在、対象としている発音データが既に離鍵しているべき鍵に対応するものであった場合、その関係が成り立つことから、判定はＹＥＳとなってステップ３１０に移行する。そうでない場合には、判定はＮＯとなって上記ステップ３０７に移行する。
【００６６】
ステップ３１０では、ｎｄ．ｉＳｔａｔｕｓの値が１か否か判定する。その値が１であった場合、判定はＹＥＳとなり、離鍵すべきタイミングとなった鍵をユーザーが離鍵していないとして（図７のケース３）、ステップ３１１でｎｄ．ｉＳｔａｔｕｓの値を３に更新した後、上記ステップ３０７に移行する。そうでない場合には、判定はＮＯとなってステップ３１２に移行する。
【００６７】
ステップ３１２では、ｎｄ．ｉＳｔａｔｕｓの値が２か否か判定する。その値が２であった場合、判定はＹＥＳとなり、離鍵すべきタイミングとなる前にユーザーが離鍵した鍵がそのタイミングになったとして（図７のケース１、２）、ステップ３１３でｎｄ．ｉＳｔａｔｕｓの値を−１に更新した後、上記ステップ３０７に移行する。そうでない場合には、判定はＮＯとなって次にそのステップ３０７を実行する。
【００６８】
上記ステップ３０５の判定がＹＥＳとなって移行するステップ３１４では、変数ＡｌｌＯｆｆの値が１と一致し、且つ変数ｍｅの値で指定される演奏データが存在しない（直前に対象としていた演奏データが最後のもの）か否か判定する。その値が１と一致し、且つその演奏データが存在しない場合、判定はＹＥＳとなり、発音ガイドを終了すべきタイミングが到来したとして、ここで一連の処理を終了する。そうでない場合には、判定はＮＯとなってステップ３１５に移行する。そのステップ３１５以降では、演奏データを参照しての発音データの作成、或いはユーザーによる押鍵時刻に着目した発音データの更新のための処理が行われる。
【００６９】
先ず、ステップ３１５では、ｍｅ．ｌＴｉｍｅが示す発音開始時刻が現在時刻（再生開始からの時間）より前か否か判定する。その発音開始時刻（押鍵すべきタイミング）が現在時刻より前であった場合、判定はＹＥＳとなってステップ３１６に移行する。そうでない場合には、判定はＮＯとなって上記ステップ３０２に戻る。
【００７０】
ステップ３１６では、変数ｎｄに、先頭に位置する発音データのインデクス値を代入する。その代入後に移行するステップ３１７では、変数ｎｄの値で指定される発音データが存在しないか否か判定する。その発音データが存在しない場合、判定はＹＥＳとなってステップ３２４に移行し、そうでない場合には、判定はＮＯとなってステップ３１８に移行する。
【００７１】
ステップ３１８では、ｎｄ．ｉＳｔａｔｕｓの値が３と一致し、且つｎｄ．ｉＰｉｔｃｈの値がｍｅ．Ｐｉｔｃｈの値と一致するか否か判定する。それらのうちの少なくとも一つが一致しない場合、判定はＮＯとなってステップ３１９に移行し、変数ｎｄにｎｄ．ｐＮｅｘｔを代入した後、上記ステップ３１７に戻る。そうでない場合には、つまりそれらが共に一致する場合には、判定はＹＥＳとなってステップ３２０に移行する。そのＹＥＳの判定は、対象としている発音データは、押鍵すべきタイミングとなる前の鍵をユーザーが押鍵することで作成されたことを意味する（図７のケース１）。
【００７２】
ステップ３２０では、現在時刻からｎｄ．ｌＮｏｔｅＯｎが示す時刻を引いて得られる時間ａが、上記定数ＤＥＬＡＹ＿ＡＬＬＯＷより小さいか否か判定する。時間ａが十分に短いような場合、判定はＹＥＳとなり、ｎｄ．ｉＳｔａｔｕｓの値を１に更新し（ステップ３２１）、ｎｄ．ｉＯｎＳｔａｒｔを現在時刻、ｎｅ．ｌＯｆｆＳｔａｒｔを現在時刻にｍｅ．ｌＧａｔｅの値を加算した値、ｎｄ．ｐＭＥを変数ｍｅの値にそれぞれ更新し（ステップ３２２）、更に変数ｍｅにｍｅ．ｎｅｘｔを代入してから（ステップ３２３）、上記ステップ３０２に戻る。そうでない場合には、判定はＮＯとなって上記ステップ３１９に移行する。
【００７３】
上記ステップ３２１でｎｄ．ｉＳｔａｔｕｓの値を１に更新することにより、時間ａが十分に短ければ初めから設定音が発音されることになる。その更新が行われない場合には、設定音の代わりに警告音が発音されることになる。その警告音のピッチは固定とさせても良い。
【００７４】
上記ステップ３１７の判定がＹＥＳとなって移行するステップ３２４では、変数ｎｄに、新たに作成する発音データの格納場所を示すインデクス値を代入する。ｎｄ．ｐＰｒｅｖとしてそれまで最後に位置していた発音データのインデクス値を格納し、その発音データ中のデータｐＮｅｘｔは変数ｎｄの値に更新する。ｎｄ．ｐＮｅｘｔとしては、最後に位置する発音データであることを示す値を格納する。続くステップ３２５では、ｎｄ．ｉＳｔａｔｕｓとして２、ｎｄ．ｉＰｉｔｃｈとしてｍｅ．Ｐｉｔｃｈ、ｎｄ．ｐＳＤとしてｍｅ．Ｐｉｔｃｈに対応するインデクス値をそれぞれ格納する。また、ｎｄ．ｆＲｅｌｅａｓｅ、ｎｄ．ＮｏｔｅＯｎ、ｎｄ．ｌＮｏｔｅＯｆｆ、ｎｄ．ｐＮｅｘｔとして例えばそれぞれ所定の初期値を格納し、そのようなことを行った後に上記ステップ３２２に移行する。
【００７５】
図１１は、図８に示す全体処理内のステップ１０３で起動されるオーディオデータ出力スレッドの実行により実現される処理のフローチャートである。次に図１１を参照して、その処理について詳細に説明する。この出力スレッドは、サンプリング周期でオーディオＩ／Ｆ１７を介して出力する、発音させるべき楽音の波高値（オーディオデータ）を生成するためのものである。
【００７６】
先ず、ステップ４０１では、各種変数に初期値を代入し、オーディオＩ／Ｆ１７を介して出力するオーディオデータ一時格納用の領域（出力バッファ）をＲＡＭ１２に確保するといった初期化を行う。次のステップ４０２では、終了が指示されたか否か判定する。上述したように、図８に示す全体処理のステップ１１４では、オーディオデータ出力スレッドの終了管理用の変数に、終了を指示する値を代入する。このことから、その変数にその値が代入されていた場合、判定はＹＥＳとなり、ここで一連の処理を終了する。そうでない場合には、判定はＮＯとなってステップ４０３に移行する。
【００７７】
ステップ４０３では、発音させるべき楽音のオーディオデータを作成（生成）して出力バッファに格納するための出力データ作成処理を実行する。次に移行するステップ４０４では、出力バッファに格納されたオーディオデータをサンプリング周期で順次、出力するための処理を実行する。その実行後は上記ステップ４０２に戻る。それにより、楽音発生アプリケーションの起動中は、ステップ４０２〜４０４で形成される処理ループを繰り返し実行する。
【００７８】
次に、上記ステップ４０３として実行される出力データ作成処理について、図１２に示すそのフローチャートを参照して詳細に説明する。その作成処理では、複数のサンプリング周期分のオーディオデータを一度に作成し、出力バッファに保存するようにしている。図中の「ｌＳａｍｐｌｅｓ」は一度に作成するオーディオデータ数を示す定数である。
【００７９】
先ず、ステップ５０１では、変数ｉに０を代入する。続くステップ５０２では、変数ｉの値が定数ｌＳａｍｐｌｅｓ未満か否か判定する。変数ｉの値は、１サンプリング周期分のオーディオデータを作成する度にインクリメントするようになっている。このため、一度に作成すべきオーディオデータを全て作成していない場合、変数ｉの値は定数ｌＳａｍｐｌｅｓ未満の関係を満たすから、判定はＹＥＳとなってステップ５０３に移行する。そうでない場合には、つまり作成すべきオーディオデータを全て作成した場合には、判定はＮＯとなり、ここで一連の処理を終了する。
【００８０】
ステップ５０３では、変数ｉの値を定数ｌＳＲで割った値を変数ｌＴｉｍｅの値に加算して得られる値（＝ｌＴｉｍｅ＋ｉ／ｌＳＲ）を変数ｌＳＴｉｍｅに代入する。変数ｌＴｉｍｅに代入された値は、次のオーディオデータを出力すべき時刻を示す値であり、定数ｌＳＲは、出力バッファに格納したオーディオデータのサンプリングレートを示す値である。それにより、変数ｉの値を定数ｌＳＲで割った値は、変数ｉの値にサンプリング周期を掛けた値（時間を示す値）である。このことから、変数ｌＳＴｉｍｅには、対象とするオーディオデータを出力すべき時刻を示す値が代入される。その代入後はステップ５０４に移行する。
【００８１】
ステップ５０４では、１サンプリング周期分のオーディオデータ作成用の変数ｉＶａｌｕｅに０を代入する。次のステップ５０５では、変数ｎｄに、発音データ格納用領域の先頭に位置する発音データの格納場所を指定するインデクス値を代入する。その次に移行するステップ５０６では、変数ｎｄの値で指定される格納場所に発音データが存在するか否か判定する。その発音データが存在しない場合、判定はＮＯとなってステップ５１６に移行する。そうでない場合には、判定はＹＥＳとなってステップ５０７に移行する。
【００８２】
ステップ５０７では、ｎｄ．ｉＳｔａｔｕｓの値が−１、１、及び２のうちの何れかと一致するか否か判定する。その値がそれらのうちの何れとも一致しない場合、判定はＮＯとなってステップ５１０に移行する。そうでない場合には、判定はＹＥＳとなってステップ５０８に移行する。ｎｄ．ｉＳｔａｔｕｓの値が３の発音データを発音対象から除外することにより、正押鍵時間外の楽音の発音は回避される（図７のケース１、３）。
【００８３】
ステップ５０７でのＹＥＳの判定は、現在、注目している発音データに対応する楽音は発音すべきものであることを意味する。このことから、ステップ５０８では、その楽音を発音させるためのサンプリングデータをＲＡＭ１２から読み出すためのサンプリングデータ読み取り処理を実行する。その実行によって変数ｉＶｔｍｐには、そのサンプリングデータが代入される。サンプリングデータを読み出す波形データは、データｐＳＤによって指定されるソースデータを参照して特定している。このため、データｐＳＤに応じて設定音、或いは警告音を発音させるための波形データが選択される。
【００８４】
ステップ５０８に続くステップ５０９では、ｎｄ．ｉＳｔａｔｕｓの値が−１か否か判定する。その値が−１、つまり現在、注目している発音データに対応する楽音が消音処理中であった場合、判定はＹＥＳとなってステップ５１２に移行する。そうでない場合には、判定はＮＯとなり、変数ｉＶａｌｕｅに、それまでの値に変数ｉＶｔｍｐの値を加算した値（＝ｉＶａｌｕｅ＋ｉＶｔｍｐ）を代入し（ステップ５１０）、変数ｎｄにｎｄ．ｐＮｅｘｔを代入する（ステップ５１１）。その代入後は上記ステップ５０６に戻る。
【００８５】
このように、発音対象とする、消音処理中でない楽音では、ステップ５０８のサンプリングデータ読み取り処理の実行によって変数ｉＶｔｍｐに代入されたサンプリングデータは変数ｉＶａｌｕｅのそれまでの値に加算される。それにより、消音処理を開始するまではサンプリングデータ（波形データ）に従って発音される。
【００８６】
上記ステップ５０９の判定のＹＥＳとなって移行するステップ５１２〜５１５では、消音したと見なせるまで、発音させる楽音の音量を徐々に小さくさせていくための処理が行われる。波形データを構成するサンプリングデータの値は大きく変化することから、消音したと見なせるか否かの判定は、消音処理中に更新していくデータｆＲｅｌｅａｓｅの値により行っている。図中の「ＲＥＤ＿ＯＦＦ」「ＲＥＬＥＡＳＥ」はそれぞれ、その判定用に設定した定数、データｆＲｅｌｅａｓｅ更新用に設定した定数である。
【００８７】
先ず、ステップ５１２では、変数ｉＶｔｍｐに、ｎｄ．ｆＲｅｌｅａｓｅの値、つまり注目している発音データ中のデータｆＲｅｌｅａｓｅの値をそれまでの値に掛けて得られる値（＝ｉＶｔｍｐ＊ｆＲｅｌｅａｓｅ）を代入する。続くステップ５１３では、そのデータｆＲｅｌｅａｓｅ（ｎｄ．ｆＲｅｌｅａｓｅ）の値が定数ＲＥＤ＿ＯＦＦ未満か否か判定する。その値が定数ＲＥＤ＿ＯＦＦ未満であった場合、判定はＹＥＳとなってステップ５１４に移行し、データｉＳｔａｔｕｓの値を０に、その他のデータをリセットする操作を行った後、上記ステップ５１０に移行する。そうでない場合には、判定はＮＯとなり、ステップ５１５でデータｆＲｅｌｅａｓｅをそれまでの値に定数ＲＥＬＥＡＳＥを掛けた値に更新した後、上記ステップ５１０に移行する。
【００８８】
そのステップ４０６でのＮＯの判定は、１サンプリング周期分のオーディオデータの作成が終了したことを意味する。このことから、その判定がＮＯとなって移行するステップ５１６では、変数ｉＶａｌｕｅの値を１サンプリング周期分のオーディオデータとして、変数ｌＳｔｉｍｅの値と共に、出力バッファの変数ｉの値で指定される格納場所に格納する。その格納後は、ステップ５１７で変数ｉの値をインクリメントしてから上記ステップ５０２に戻る。
【００８９】
図１３は、上記ステップ５０８として実行されるサンプリングデータ読み取り処理のフローチャートである。最後に図１３を参照して、その読み取り処理について詳細に説明する。
【００９０】
先ず、ステップ５５１では、変数ｉｄに、ｎｄ．ｉＳｔａｔｕｓの値を代入する。次のステップ５５２では、変数ｌＴに、変数ｌＳｔｉｍｅの値からｎｄ．ｌＯｎＳｔａｒｔの値を引いた値、つまり変数ｎｄの値で指定される発音データにより発音中の楽音の発音を開始させてから経過した時間を示す値を代入する。その後は、ステップ５５３でｎｄ．ｐＳＤの値を変数ｓｄに代入する。
【００９１】
ステップ５５３に続くステップ５５４では、変数ｌＰｏｓに、変数ｌＴの値に定数ｌＳＲを掛けた乗算結果を、ｓｄ．ｆＬｅｎｇｔｈのなかで変数ｉｄの値で指定されるもの（図中「ｓｄ．ｆＬｅｎｇｔｈ［ｉｄ］」と表記。以降、その表記法を用いる）の値で割ったときに得られる余り（＝（ｌＴ＊ｌＳＲ）％ｓｄ．ｆＬｅｎｇｔｈ［ｉｄ］）を代入する。その後は、ステップ５５５に移行して、ｓｄ．ｐＤａｔａのなかで変数ｉｄの値で指定されるもの（図中「ｓｄ．ｐＤａｔａ［ｉｄ］」と表記。以降、その表記法を用いる）で指定される波形データを例えば配列変数、或いはバッファであるｐＷに格納する。ここではｐＷとしてバッファを想定する。バッファｐＷに波形データを格納した後はステップ５５６に移行する。
【００９２】
ステップ５５６では、バッファｐＷに格納した波形データ中の変数ｌＰｏｓの値で指定されるサンプリングデータ（先頭から変数ｌＰｏｓの値番目のデータ）を読み出して変数ｉＶｔｍｐに代入する。その次のステップ５５７では、変数ｉＶｔｍｐに、ｎｄ．ｉＶｅｌの値をｓｄ．ＭａｘＶｅｌの値で割った値をそれまでの値に乗算して得られる値を代入する。そのようにして、変数ｉＶｔｍｐに代入したサンプリングデータを、ユーザーが実際に押鍵したときのベロシティ値と波形データのベロシティ範囲の上限値の比に応じて更新した後、一連の処理を終了する。
【００９３】
このように、変数ｉｄ（ｎｄ．ｉＳｔａｔｕｓ）の値に応じた波形データが参照され、その波形データから読み出して操作したサンプリングデータが最終的に変数ｉＶｔｍｐに代入され、上記出力データ作成処理に渡される。このため、データｉＳｔａｔｕｓの値に対応する種類の楽音が発音される。
＜第２の実施の形態＞
上記第１の実施の形態では、押鍵すべき鍵をユーザーが実際に押鍵したタイミングに応じて設定音、及び警告音の２種類の楽音を発音させるようにしている（図７）。これに対し、第２の実施の形態は、ユーザーが実際に押鍵したタイミングに応じて３種類の楽音を発音させるようにしたものである。
【００９４】
第２の実施の形態における楽音発生装置の構成は、基本的に第１の実施の形態におけるそれと同じである。動作も大部分は同じか、或いは基本的に同じである。このことから、第１の実施の形態で付した符号をそのまま用いて、第１の実施の形態から異なる部分についてのみ説明する。
【００９５】
図１４は、第２の実施の形態における楽音の発音制御によって発音される楽音を説明する図である。その図１４では、図７と同様に、ケース１〜３別に発音される楽音を示している。それらケース１〜３の内容は図７におけるそれと同じである。
【００９６】
図１４のケース１、３に示すように、第２の実施の形態では、正押鍵時間外もユーザーが鍵を押鍵していれば楽音を発音させるようにしている。その正押鍵時間外は、設定音、及び警告音とは異なる種類の楽音（便宜的に「ミスタッチ音」と呼ぶ）を発音させるようにしている。
【００９７】
ケース１では、時間ａが十分に短いか否かに係わらず、正押鍵時間が到来するまでの間、ミスタッチ音を放音させる。その正押鍵時間が到来した後は、時間ａが十分に短ければ設定音の発音に切り換え、それ以降は第１の実施の形態と同じタイミングで警告音の発音に切り換えて正押鍵時間が経過するまでその警告音を発音させる。一方、時間ａが十分に短くなければ、ミスタッチ音は実押鍵時間が経過するまで発音させ、それと併せて、正押鍵時間全体で警告音を発音させる。その後、正押鍵時間が経過するまで警告音に切り換えて発音させる。このため、時間ａが十分に短いか否かに係わらず、正押鍵時間と実押鍵時間のずれを発音された楽音から容易に認識できるようになっている。
【００９８】
ケース２では、時間ｂが十分に短ければ第１の実施の形態と同じタイミング、順序で警告音、設定音が発音される。時間ｂが十分に短くない場合には、第１の実施の形態と同じく、正押鍵時間全体で警告音を発音させる。それと併せて、実押鍵時間全体でミスタッチ音を発音させる。このため、時間ｂが十分に短いか否かに係わらず、このため、時間ａが十分に短いか否かに係わらず、正押鍵時間と実押鍵時間のずれを発音された楽音から容易に認識できるようになっている。
【００９９】
ケース３では、正押鍵時間内は第１の実施の形態と同じく設定音を発音させる。その正押鍵時間が経過した後は、実押鍵時間が経過するまでミスタッチ音に切り換えて発音を継続させる。このため、離鍵したタイミングと離鍵すべきタイミングのずれを発音された楽音から容易に認識できるようになっている。
【０１００】
上述したように、時間ａ、或いはｂが十分に短くない場合、発音データは複数（ここでは２つ）作成される。ケース１、及び２において、正押鍵時間全体で警告音を発音させる発音データは対応する演奏データから作成され、その警告音と併せてミスタッチ音を発音させる発音データはユーザーの操作から作成される。第１の実施の形態では、その一方のみを用いることで図７に示すような発音制御を実現させている。これに対し、第２の実施の形態では、それらを共に用いることにより、図１４に示すような発音制御を実現させている。このために第２の実施の形態では、図１２に示す出力データ作成処理に第１の実施の形態から異なる部分が存在する。以降、その異なる部分について具体的に説明する。
【０１０１】
図１２に示す出力データ作成処理では、ステップ５０７でデータｉＳｔａｔｕｓ（ｎｄ．ｉＳｔａｔｕｓ）の値が−１、１、及び２の何れかと一致するか否か判定している。第２の実施の形態では、その値が０でないか否か判定するようにしている。それにより、その値が３であればミスタッチ音を発音させるようにしている。
＜第３の実施の形態＞
上記第１、及び第２の実施の形態では、押鍵すべき鍵をユーザーが実際に押鍵したタイミングに着目して発音させるべき楽音（ここでは発音の回避を含む）の発音制御を行っている。これに対し、第３の実施の形態は、ユーザーが押鍵したときのベロシティに更に着目して発音制御を行うようにしたものである。そのベロシティを更に着目することにより、行った押鍵の速さ（ベロシティ）が適切か否かを発音させる音によりユーザーに容易に認識させることができる。
【０１０２】
第３の実施の形態における楽音発生装置の構成は、基本的に第１の実施の形態におけるそれと同じである。動作も大部分は同じか、或いは基本的に同じである。このことから、第２の実施の形態と同様に、第１の実施の形態で付した符号をそのまま用いて、第１の実施の形態から異なる部分についてのみ説明する。
【０１０３】
第３の実施の形態では、図５に示すように、発音データを構成するデータとして、演奏データ中のデータＶｅｌが示すベロシティがユーザーの押鍵時のベロシティと許容範囲内で一致するか否かを示すデータｉＶｅｌＡｇｒｅｅを用意している。その具体的な値としては、許容範囲内で一致すれば１、そうでなければ０としている。初期値は０としている。データｉＶｅｌＡｇｒｅｅの値に応じて発音させる楽音の音量を制御することにより、行った押鍵の速さが適切か否か認識可能とさせている。本実施の形態では、データｉＶｅｌＡｇｒｅｅの値が１であれば音量を小さくさせるようにしている。
【０１０４】
演奏データが示すベロシティが実際の押鍵時のベロシティと許容範囲内で一致するか否かの判定、その判定結果に応じたデータｉＶｅｌＡｇｒｅｅの更新は、図９に示すＭＩＤＩ  ＩＮ処理、及び図１０に示す再生処理に図１５に示すフローチャートを追加することで実現させている。
【０１０５】
その図１５に示すフローチャートでは、ステップ６０１において、変数ｎｄの値で指定される発音データ中のデータｐＭＥが示す演奏データに格納のデータＶｅｌ（図中「ｎｄ．ｐＭＥ．Ｖｅｌ」と表記した、対応する演奏データが示すベロシティ）の値から変数ｉＶｅｌ（ユーザーが押鍵したベロシティ）の値を引いた減算値の絶対値が、許容範囲として設定の定数ＡＬＬＯＷ＿ＶＥＬ未満か否か判定する。その絶対値が定数ＡＬＬＯＷ＿ＶＥＬ未満であった場合、判定はＹＥＳとなってステップ６０２に移行し、データｉＶｅｌＡｇｒｅｅの値を１に更新する。そうでない場合には、判定はＮＯとなり、許容範囲外としてデータｉＶｅｌＡｇｒｅｅを更新することなく、ステップ６０２の処理の実行後に移行する処理を次に実行する。
【０１０６】
図１５に示すフローチャートは、図９に示すＭＩＤＩ  ＩＮ処理ではステップ２０８、２０９間に追加・挿入され、図１０に示す再生処理では、ステップ３２１，３２２間に追加・挿入される。発音させる楽音の音量制御は、例えばその後に移行するステップ２０９、３２２のそれぞれに、データｉＶｅｌＡｇｒｅｅの値が１であれば変数ｉＶｅｌの値に１より小さい係数（例えば０．５）を掛けた値をデータｉＯｎＶｅｌとして格納させるか、或いは例えば図１２に示すステップ５０８として実行されるサンプリングデータ読み取り処理にデータｉＶｅｌＡｇｒｅｅの値に応じたデータｉＯｎＶｅｌの更新機能を搭載させることで実現できる。
＜第４の実施の形態＞
上記第１〜第３の実施の形態では、演奏情報は予め用意されたものを用いるようにしている。これに対し、第４の実施の形態は、実際に行われた演奏結果を示す演奏情報を保存して用いることができるようにしたものである。
【０１０７】
第４の実施の形態における楽音発生装置の構成は、基本的に第１の実施の形態におけるそれと同じである。動作も大部分は同じか、或いは基本的に同じである。このことから、第２、及び第３の実施の形態と同様に、第１の実施の形態で付した符号をそのまま用いて、第１の実施の形態から異なる部分についてのみ説明する。
【０１０８】
第４の実施の形態では、ＭＩＤＩ  Ｉ／Ｆ１６に複数の電子楽器２０を接続可能となっている。演奏結果は合奏を行った人別に保存するようにしている。そのために、図２〜図６に示す各種データに加えて、図１６〜図１８に示す各種データを管理できるようになっている。始めに図１６〜図１８にそれぞれ示すデータについて詳細に説明する。演奏結果として保存するデータは、録音データと呼ぶことにする。その録音データは、楽音単位で演奏結果を示す保存データを備えている。
【０１０９】
図１６は、録音データ管理データの構成を説明する図である。その録音データ管理データ（以降「管理データ」と略記）は、演奏（録音）毎に用意される管理用のデータである。図１６に示すように、録音（演奏）開始日時を示すデータＤａｔｅ、対応する参加ユーザーデータの格納場所（先頭の位置するデータの場所）を示すデータｐＵｓｅｒＬｉｓｔ、対応する録音データの格納場所を示すデータｐＲｅｃＤａｔａ、前の管理データの格納場所を示すデータｐｒｅｖ、及び次の管理データの格納場所を示すデータｎｅｘｔ、を備えている。ここでは上述の各実施の形態と同様に、格納場所を示すものとしてインデクス値（ポインタ値）を想定する。
【０１１０】
図１７は、参加ユーザーデータの構成を説明する図である。その参加ユーザーデータ（以降「ユーザーデータ」と略記）は、合奏者毎に用意されるデータである。図１７に示すように、対応する合奏者名（参加したユーザー名）を示すデータＵｓｅｒＮａｍｅ、演奏したトラックを示すデータｉＣｈ、対応する音色データを示すデータｐＴｏｎｅ、前のユーザーデータの格納場所を示すデータｐｒｅｖ、及び次のユーザーデータの格納場所を示すデータｎｅｘｔ、を備えている。
【０１１１】
図１８は、保存データの構成を説明する図である。その保存データは、楽音単位に用意されるデータである。データｉＣｈ、楽音のピッチを示すデータｉＰｉｔｃｈ、そのベロシティを示すデータｉＯｎＶｅｌ、その楽音における演奏判断結果を示すデータｉＲｅｓｕｌｔ（０の値は未押鍵、１の値は適切な押鍵、２の値は遅れた押鍵、３の値は早い押鍵、４の値は誤った押鍵（ミスタッチ）、をそれぞれ表す）、対応する演奏データによる発音開始時刻を示すデータｌＯｎＳｔａｒｔ、その消音開始時刻を示すデータｌＯｆｆＳｔａｒｔ、ユーザーによる押鍵時刻（タイミング）を示すデータｌＮｏｔｅＯｎ、その離鍵時刻（タイミング）を示すデータｌＮｏｔｅＯｆｆ、前の保存データの格納場所を示すデータｐｒｅｖ、及び次の補間データの格納場所を示すデータｎｅｘｔ、を備えている。図５に示す発音データにもデータｉＲｅｓｕｌｔは追加されている。
【０１１２】
以降は、図１９〜図２４を参照して、本実施の形態で実行する処理について詳細に説明する。
図１９は、図８のステップ１０９として実行されるＭＩＤＩ  ＩＮ処理のフローチャートである。そのＩＮ処理は、図９に示すＩＮ処理の代わりに実行されるものである。図９に示すステップの処理内容と同じ、或いは基本的に同じものには同一の符号を付している。それにより、始めに図１９を参照して、第１の実施の形態から異なる部分についてのみ説明する。
【０１１３】
本実施の形態では、先ず、ステップ２１２の判定処理を実行する。その判定がＮＯであれば次にステップ２０１の判定処理を実行し、その判定がＹＥＳであればステップ２１３に移行するようになっている。そのステップ２０１でＮＯと判定すればここで一連の処理を終了し、ＹＥＳと判定すればステップ２０２に移行する。
【０１１４】
ステップ２１９、或いは２２２の処理を実行した後は、ステップ７０１に移行する。そのステップ７０１では、ｎｄ．ｌＮｏｔｅＯｆｆとして現在時刻を格納し、続くステップ７０２では、ｎｄ．ｉＲｅｓｕｌｔの値が２、或いは３か否か判定する。その値が２、及び３の何れかであった場合、判定はＹＥＳとなってステップ７０３に移行し、配列変数ｉＲｅｄｕｃｅの変数ｎｄ、及びデータｉＣｈの各値で指定される要素（図中「ｉＲｅｄｕｃｅ［ｎｄ．ｉＣｈ］」と表記）の値を、それまでの値に０．５を加算した値に更新（図中「ｉＲｅｄｕｃｅ［ｎｄ．ｉＣｈ］＋＝０．５」と表記）した後、一連の処理を終了する。そうでない場合には、つまりその値が２、及び３の何れでもない場合には、判定はＮＯとなってステップ７０４に移行する。
【０１１５】
ステップ７０４では、ｎｄ．ｉＲｅｓｕｌｔの値が４か否か判定する。その値が４であった場合、判定はＹＥＳとなってステップ７０５に移行し、配列変数ｆＲｅｄｕｃｅの変数ｎｄ、及びデータｉＣｈの各値で指定される要素（図中「ｆＲｅｄｕｃｅ［ｎｄ．ｉＣｈ］」と表記）の値を、それまでの値に０．５を加算した値に更新（図中「ｆＲｅｄｕｃｅ［ｎｄ．ｉＣｈ］＋＝０．５」と表記）した後、一連の処理を終了する。そうでない場合には、判定はＮＯとなり、ここで一連の処理を終了する。
【０１１６】
本実施の形態では、ステップ２０５の判定がＹＥＳとなると次にステップ７０６に移行し、変数ｌＤｉｆに、現在時刻（を示す値）からｎｄ．ｌＯｎＳｔａｒｔ（発音開始時刻）の値を引いた値（時間ｂに対応）を代入する。続くステップ７０７では、変数ｌＤｉｆの値が定数ＤＥＬＡＹ＿ＡＬＬＯＷ未満か否か判定する。押鍵したタイミングの遅れが許容範囲内であった場合、判定はＹＥＳとなってステップ７０８に移行する。そうでない場合には、判定はＮＯとなってステップ２０６に移行する。
【０１１７】
ステップ７０８では、ｎｄ．ｉＳｔａｔｕｓとして１、ｎｄ．ｉＲｅｓｕｌｔとして２をそれぞれ格納する。その格納後はステップ７０９に移行して、変数ｌＤｉｆの値が定数ＤＥＬＡＹ＿ＯＫ未満か否か判定する。その値が定数ＤＥＬＡＹ＿ＯＫ未満であった場合、判定はＹＥＳとなり、ステップ７１０でｎｄ．ｉＲｅｓｕｌｔとして１を格納し、更にステップ７１１でｎｄ．ｌＮｏｔｅＯｎとして現在時刻（曲頭からの演奏時間）、ｎｄ．ｉＯｎＶｅｌとして変数ｉＶｅｌの値をそれぞれ格納した後、一連の処理を終了する。そうでない場合には、判定はＮＯとなって次にそのステップ７１１に移行する。
【０１１８】
上記定数ＤＥＬＡＹ＿ＯＫは定数ＤＥＬＡＹ＿ＡＬＬＯＷより小さい値である。そのため、ユーザーが押鍵したタイミングが押鍵すべきタイミングにより近ければ、ｎｄ．ｉＲｅｓｕｌｔの値を２から１に更新するようにしている。
【０１１９】
本実施の形態では、ステップ２１０の処理を実行した後はステップ７１２に移行する。そのステップ７１２では、ｎｄ．ｉＳｔａｔｕｓとして２、ｎｄ．ｐＳＤとして変数ｉＰｉｔの値に対応したソースデータのインデクス値、ｎｄ．ｉＰｉｔｃｈとして変数ｉＰｉｔの値、ｎｄ．ｉＲｅｓｕｌｔとして４、ｎｄ．ｉＴｏｎｅとして変数ｉＣｈの値、等をそれぞれ格納する。その後にステップ７１１に移行する。
【０１２０】
図２０は、図８に示す再生処理のフローチャートである。その再生処理は、図１０に示す再生処理の代わりに実行されるものである。図１０に示すステップの処理内容と同じ、或いは基本的に同じものには同一の符号を付している。それにより、図２０を参照して、第１の実施の形態から異なる部分についてのみ説明する。
【０１２１】
本実施の形態では、ステップ３１１の処理を実行した後、ステップ８０１に移行して、ｎｄ．ｉＲｅｓｕｌｔの値が０か否か判定する。その値が０であった場合、判定はＹＥＳとなってステップ８０２に移行し、要素ｉＲｅｄｕｃｅ［ｎｄ．ｉＣｈ］の値をインクリメントした後、ステップ３０７に移行する。そうでない場合には、判定はＮＯとなってそのステップ３０７に移行する。
【０１２２】
ステップ３２４の処理を実行した後は次にステップ８０３に移行する。そのステップ８０３では、ｎｄ．ｉＳｔａｔｕｓとして２、ｎｄ．ｐＳＤとして変数ｉＰｉｔの値に対応したソースデータのインデクス値、ｎｄ．ｉＰｉｔｃｈとしてｍｅ．Ｐｉｔｃｈ、ｎｄ．ｉＲｅｓｕｌｔとして０、ｎｄ．ｉＣｈとして変数ｉＣｈの値、等をそれぞれ格納する。その後はステップ８０４に移行して、ｎｄ．ｌＯｎＳｔａｒｔとしてｍｅ．ｌＴｉｍｅ、ｎｄ．ｌＯｆｆＳｔａｒｔとして現在時刻にｍｅ．ｌＧａｔｅが示す発音時間を加算した値、ｎｄ．ｐＭＥとして変数ｍｅの値、等をそれぞれ格納する。その次に移行するステップ８０５では、配列変数ｉＯｒｇＣｎｔの変数ｎｄ、及びデータｉＣｈの各値で指定される要素（図中「ｉＯｒｇＣｎｔ［ｎｄ．ｉＣｈ］」と表記）の値をインクリメントする。ステップ３２３にはその後に移行する。
【０１２３】
本実施の形態では、ステップ３１８の判定がＹＥＳとなった場合、次にステップ８０６に移行する。そのステップ８０６では、変数ｌＤｉｆに、現在時刻（を示す値）からｎｄ．ｌＮｏｔｅＯｎ（押鍵時刻）の値を引いた値（時間ａに対応）を代入する。続くステップ８０７では、変数ｌＤｉｆの値が定数ＤＥＬＡＹ＿ＡＬＬＯＷ未満か否か判定する。押鍵したタイミングの早さが許容範囲内であった場合、判定はＹＥＳとなってステップ８０８に移行する。そうでない場合には、判定はＮＯとなってステップ３１９に移行する。
【０１２４】
ステップ８０８では、ｎｄ．ｉＳｔａｔｕｓとして１、ｎｄ．ｉＲｅｓｕｌｔとして３をそれぞれ格納する。その格納後はステップ８０９に移行して、変数ｌＤｉｆの値が定数ＤＥＬＡＹ＿ＯＫ未満か否か判定する。その値が定数ＤＥＬＡＹ＿ＯＫ未満であった場合、判定はＹＥＳとなり、ステップ８１０でｎｄ．ｉＲｅｓｕｌｔとして１を格納した後、上記ステップ８０４に移行する。そうでない場合には、判定はＮＯとなって次にそのステップ８０４に移行する。
【０１２５】
図２１は、データ保存処理のフローチャートである。その保存処理は、演奏結果を録音データとして保存するための処理であり、図２０に示す再生処理を停止（終了）した後に実行される。次に図２１を参照して、その保存処理について詳細に説明する。
【０１２６】
先ず、ステップ９０１では、演奏結果の保存管理用の変数である録音フラグがセットされているか否か判定する。ユーザーが演奏結果の保存を指示した場合、その録音フラグにはセットされていると見なす値が代入されることから、判定はＹＥＳとなってステップ９０２に移行する。そうでない場合には、判定はＮＯとなり、ここで一連の処理を終了する。本実施の形態では、その保存が指示された場合、合奏者全員の演奏結果を対象に保存を行うようにしている。
【０１２７】
ステップ９０２では、変数ｒｅｃＬｉｓｔに新たな管理データを格納できる場所（空き位置）を示すインデクス値、変数ｕｓｒＬｉｓｔに新たなユーザーデータを格納できる場所を示すインデクス値、変数ｒｅｃＤａｔに新たな保存データを格納できる場所のインデクス値、をそれぞれ代入し、ｒｅｃＬｉｓｔ．ｐＵｓｅｒＬｉｓｔとして変数ｕｓｒＬｉｓｔの値を格納する。次のステップ９０３では、ｕｓｒＬｉｓｔ．ｉＣｈ、ｕｓｒＬｉｓｔ．ｐＴｏｎｅとして、対象とするユーザー（合奏者）のトラック番号、音色に対応の音色データを示すデータをそれぞれ格納する。その後はステップ９０４に移行する。
【０１２８】
ステップ９０４では、次の接続鍵盤、つまり他に演奏結果を保存すべきユーザーが存在するか否か判定する。そのようなユーザーが存在する場合、判定はＹＥＳとなり、ステップ９０５に移行して、変数ｐＮｘｔに新たにユーザーデータを格納できる場所を示インデクス値を代入し、ｕｓｒＬｉｓｔ．ｎｅｘｔとして変数ｐＮｘｔの値、ｐＮｘｔ．ｐｒｅｖとして変数ｕｓｒＬｉｓｔの値、をそれぞれ格納し、その後に変数ｕｓｒＬｉｓｔに変数ｐＮｘｔの値を代入し、対象とする合奏者は別の人に変更してから上記ステップ９０３に戻る。それにより、全てのユーザーを対象にして、ユーザーデータの格納を行う。一方、そうでない場合には、判定はＮＯとなってステップ９０６に移行する。
【０１２９】
ステップ９０６以降では、発音データから保存データを作成して格納するための処理が行われる。
先ず、ステップ９０６では、変数ｎｄに先頭位置の発音データを指定するインデクス値を代入する。続くステップ９０７では、ｒｅｃＤａｔ．ｉＣｈとしてｎｄ．ｉＣｈ、ｒｅｃＤａｔ．ｉＰｉｔｃｈとしてｎｄ．ｉＰｉｔｃｈ、ｒｅｃＤａｔ．ｉＯｎＶｅｌとしてｎｄ．ｉＯｎＶｅｌ、ｒｅｃＤａｔ．ｉＲｅｓｕｌｔとしてｎｄ．ｉＲｅｓｕｌｔ、ｒｅｃＤａｔ．ｉＯｎＳｔａｒｔとしてｎｄ．ｉＯｎＳｔａｒｔ、ｒｅｃＤａｔ．ｉＯｆｆＳｔａｒｔとしてｎｄ．ｉＯｆｆＳｔａｒｔ、ｒｅｃＤａｔ．ｉＮｏｔｅＯｎとしてｎｄ．ｉＮｏｔｅＯｎ、ｒｅｃＤａｔ．ｉＮｏｔｅＯｆｆとしてｎｄ．ｉＮｏｔｅＯｆｆ、をそれぞれ格納する。
【０１３０】
ステップ９０７に続くステップ９０８では、変数ｎｄで指定される発音データの次に位置する発音データが存在するか否か判定する。その次に位置する発音データが存在しない場合、つまり保存データの格納が完了した場合、判定はＮＯとなり、ここで一連の処理を終了する。そうでない場合には、判定はＹＥＳとなり、ステップ９０９に移行して、変数ｐＮｘｔに次の保存データを格納する場所を示すインデクス値を代入し、ｒｅｃＤａｔ．ｎｅｘｔとして変数ｐＮｘｔの値、ｐＮｘｔ．ｐｒｅｖとして変数ｒｅｃＤａｔの値、をそれぞれ格納し、その後に変数ｒｅｃＤａｔに変数ｐＮｘｔの値、変数ｎｄにｎｄ．ｐＮｅｘｔをそれぞれ代入してから上記ステップ９０７に戻る。
【０１３１】
上述したようにして本実施の形態では、演奏結果を保存データ（録音データ）として保存できるようにしている。このことから、その録音データ再生、及びその録音データを用いた発音ガイド等を行えるようにさせている。次に図２２、図２３を参照して、それらを実現させるために実行される処理について詳細に説明する。前者を実現させるための処理は「録音データ再生処理」、後者を実現させるための処理は「録音データガイド再生処理」とそれぞれ呼ぶことにする。それらの処理は図１０に示す再生処理と同様に、図８に示す全体処理の実行時に起動される。その停止が指示された場合、対応する再生停止フラグがオンされる。また、所望のパートを選択できるようにさせている。その選択はトラック番号を指定して行い、指定されたトラック番号は変数ｉＭｙＣｈに代入している。
【０１３２】
図２２は、録音データ再生処理のフローチャートである。始めに図２２を参照して、その再生処理について詳細に説明する。
先ず、ステップ１００１では、変数ｒｄに、録音データのなかで先頭に位置する保存データの格納場所を示すインデクス値を代入する。続くステップ１００２では、上記再生停止フラグがオンとなっているか否か判定する。そのフラグがオンされている場合、判定はＹＥＳとなり、ステップ１００３で発音データ全てのデータｉＳｔａｔｕｓの値を０に更新した後、一連の処理を終了する。そうでない場合には、判定はＮＯとなってステップ１００４に移行する。
【０１３３】
ステップ１００４では、変数ＡｌｌＯｆｆに１を代入し、変数ｎｄに、先頭に位置する発音データのインデクス値を代入する。次のステップ１００５では、変数ｎｄの値で指定される発音データが存在しないか否か判定する。その発音データが存在しない場合、判定はＹＥＳとなってステップ１０１４に移行する。そうでない場合には、判定はＮＯとなってステップ１００６に移行する。
【０１３４】
ステップ１００６では、ｎｄ．ｉＳｔａｔｕｓの値が０以外か否か、つまり変数ｎｄの値で指定される発音データによって楽音を発音させていないか否か判定する。楽音を発音させていない場合、判定はＹＥＳとなり、ステップ１００８で変数ＡｌｌＯｆｆに０を代入してからステップ１００９に移行する。そうでない場合には、判定はＮＯとなってステップ１００７に移行し、変数ｎｄにｎｄ．ｐＮｅｘｔを代入した後、上記ステップ１００５に戻る。
【０１３５】
ステップ１００９では、ｎｄ．ｉＣｈの値が変数ｉＭｙＣｈの値と一致するか否か判定する。それらの値が一致する場合、判定はＹＥＳとなってステップ１０１２に移行する。そうでない場合には、判定はＮＯとなってステップ１０１０に移行する。
【０１３６】
ステップ１０１０では、ｎｄ．ｌＮｏｔｅＯｆｆが示す離鍵時刻が現在時刻より前か否か判定する。その離鍵時刻が現在時刻より前であった場合、判定はＹＥＳとなり、対応する楽音を消音させるべきとして、ステップ１０１１でｎｄ．ｉＳｔａｔｕｓとして−１を格納した後、上記ステップ１００７に移行する。そうでない場合には、判定はＮＯとなってそのステップ１００７に移行する。
【０１３７】
ステップ１０１２では、ｎｄ．ｌＯｆｆＳｔａｒｔが示す消音開始時刻が現在時刻より前か否か判定する。その開始時刻が現在時刻より前であった場合、判定はＹＥＳとなり、対応する楽音を消音させるべきとして、ステップ１０１３でｎｄ．ｉＳｔａｔｕｓとして−１を格納した後、上記ステップ１００７に移行する。そうでない場合には、判定はＮＯとなってそのステップ１００７に移行する。
【０１３８】
上記ステップ１００５の判定がＹＥＳとなって移行するステップ１０１４では、変数ＡｌｌＯｆｆの値が１と一致し、且つ変数ｒｄの値で指定される保存データが存在しない（直前に対象としていた保存データが最後のもの）か否か判定する。その値が１と一致し、且つその保存データが存在しない場合、判定はＹＥＳとなり、ここで一連の処理を終了する。そうでない場合には、判定はＮＯとなってステップ１０１５に移行する。
【０１３９】
ステップ１０１５では、変数ｌＴｉｍｅに、ｒｄ．ｌＮｏｔｅＯｎの値（押鍵時刻）を代入する。続くステップ１０１６では、変数ｌＴｉｍｅの値が示す押鍵時刻が現在時刻（再生開始からの時間）より前か否か判定する。その押鍵時刻（押鍵すべきタイミング）が現在時刻より前であった場合、判定はＹＥＳとなってステップ１０１７に移行する。そうでない場合には、判定はＮＯとなって上記ステップ１００２に戻る。
【０１４０】
ステップ１０１７では、変数ｎｄに、先頭に位置する発音データのインデクス値を代入する。ｎｄ．ｐＰｒｅｖとしてそれまで最後に位置していた発音データのインデクス値を格納し、その発音データ中のデータｐＮｅｘｔは変数ｎｄの値に更新する。ｎｄ．ｐＮｅｘｔとしては、最後に位置する発音データであることを示す値を格納する。その格納後に移行するステップ１０１８では、ｎｄ．ｉＳｔａｔｕｓとして２、ｎｄ．ｐＳＤとしてｒｄ．ｉＰｉｔｃｈ、ｒｄ．ｉＣｈに対応するデータ、ｎｄ．ｉＰｉｔｃｈとしてｒｄ．ｉＰｉｔｃｈ、ｎｄ．ｉＲｅｓｕｌｔとして０、ｎｄ．ｉＣｈとしてｒｄ．ｉＣｈをそれぞれ格納する。次のステップ１０１９では、ｎｄ．ｌＯｎＳｔａｒｔとして現在時刻、ｎｄ．ｌＯｆｆＳｔａｒｔとして、現在時刻に、ｒｄ．ｌＯｆｆＳｔａｒｔの値からｒｄ．ｌＯｎＳｔａｒｔの値を引いた値（発音時間）を加算した値、などをそれぞれ格納する。その後は、ステップ１０２０で変数ｒｄにｒｄ．ｎｅｘｔを代入してから上記ステップ１００２に戻る。
【０１４１】
図２３は、上記録音データガイド再生処理のフローチャートである。次に図２３を参照して、そのガイド再生処理について詳細に説明する。この図２３では、図２０に示す再生処理で実行されるステップの処理内容と同じ、或いは基本的に同じステップには同一の符号を付している。それにより、図２０に示す再生処理から異なる部分についてのみ詳細に説明する。
【０１４２】
この録音データガイド再生処理では、先ず、ステップ１１０１において、変数ｒｄに録音データのなかで先頭に位置する保存データを指定するインデクス値を代入し、変数ｉＭｙＣｈにユーザーが指定のチャンネル番号（トラック番号）を代入する。その後はステップ３０２に移行する。
【０１４３】
ステップ３０８で変数ＡｌｌＯｆｆに０を代入した後はステップ１１０２に移行して、ｎｄ．ｉＣｈの値が変数ｉＭｙＣｈの値と一致するか否か判定する。それらの値が一致する場合、判定はＹＥＳとなってステップ１１０５に移行する。そうでない場合には、判定はＮＯとなってステップ１１０３に移行する。
【０１４４】
ステップ１１０３では、ｎｄ．ｌＮｏｔｅＯｆｆが示す離鍵時刻が現在時刻より前か否か判定する。その離鍵時刻が現在時刻より前であった場合、判定はＹＥＳとなり、対応する楽音を消音させるべきとして、ステップ１１０４でｎｄ．ｉＳｔａｔｕｓとして−１を格納した後、上記ステップ３０９に移行する。そうでない場合には、判定はＮＯとなってそのステップ３０９に移行する。
【０１４５】
ステップ１１０５では、ｎｄ．ｌＯｆｆＳｔａｒｔが示す消音開始時刻が現在時刻より前か否か判定する。その開始時刻が現在時刻より前であった場合、判定はＹＥＳとなってステップ３１０に移行する。そうでない場合には、判定はＮＯとなって上記ステップ３０９に移行する。
【０１４６】
ステップ８０１の判定がＹＥＳとなって移行するステップ１１０６では、要素ｉＲｅｄｕｃｅ［ｉＭｙＣｈ］に、それまでの値にｎｄ．ｐＭＥ．ｆＰｔｉｏｒｉｔｙの値を加算した値を代入する。その後は上記ステップ３０７に移行する。配列変数ｉＲｅｄｕｃｅは例えばトラック（チャンネル）毎に押鍵すべき鍵を押鍵しなかった回数をカウントするために用意したものである。
【０１４７】
ステップ３１４の判定がＮＯとなって移行するステップ１１０７では、変数ｌＴｉｍｅにｒｄ．ｌＯｎＳｔａｒｔを代入する。続くステップ１１０８では、ｒｄ．ｉＣｈの値が変数ｉＭｙＣｈの値と一致するか否か判定する。それらの値が一致する場合、判定はＹＥＳとなってステップ１１０９に移行し、変数ｌＴｉｍｅにｒｄ．ｌＮｏｔｅＯｎを代入してから上記ステップ３１５に移行する。それにより、押鍵すべきとするタイミングを演奏結果から演奏データのそれに変更する。一方、そうでない場合には、判定はＮＯとなってそのステップ３１５に移行する。なお、そのようなタイミングの変更は行わないようにしても良い。その場合、ステップ１１０８、１１０９を省き、ステップ１１０７の処理を実行した後、ステップ３０５に移行させれば良い。
【０１４８】
ステップ３１５の判定がＹＥＳとなると、次にステップ１１１０に移行して、ｒｄ．ｉＣｈの値が変数変数ｉＭｙＣｈの値と一致するか否か判定する。それらの値が一致しない場合、判定はＮＯとなり、ステップ１１１５で変数ｎｄに先頭に位置する発音データのインデクス値を代入し、更に要素ｉＯｒｇＣｎｔ［ｉＭｙＣｈ］の値をインクリメントしてから上記ステップ３１７に移行する。そうでない場合には、判定はＹＥＳとなってステップ３２４に移行し、その処理を実行した後はステップ１１１１に移行する。
【０１４９】
ステップ１１１１では、ｎｄ．ｉＳｔａｔｕｓとして２、ｎｄ．ｐＳＤとしてｒｄ．ｉＰｉｔｃｈ対応したソースデータのインデクス値、ｎｄ．ｉＰｉｔｃｈとしてｒｄ．ｉＰｉｔｃｈ、ｎｄ．ｉＲｅｓｕｌｔとして０、ｎｄ．ｉＣｈとしてｒｄ．ｉＣｈ、等をそれぞれ格納する。その後はステップ１１１２に移行して、ｎｄ．ｌＯｎＳｔａｒｔとして変数ｌＴｉｍｅの値、ｎｄ．ｌＯｆｆＳｔａｒｔとして、ｒｄ．ｌＯｆｆＳｔａｒｔの値からｒｄ．ｌＯｎＳｔａｒｔの値を引いた値を現在時刻に加算して得られる値、等をそれぞれ格納する。その次に移行するステップ１１１３では、変数ｒｄにｒｄ．ｎｅｘｔを代入する。その代入後はステップ１１１４に移行して、ｒｄ．ｉＣｈの値が変数変数ｉＭｙＣｈの値と一致し、且つｒｄ．ｉＲｅｓｕｌｔの値が４と一致するか否か判定する。それらの値が共に一致する場合、判定はＹＥＳとなって再度、ステップ１１１３の処理を実行する。そうでない場合には、つまりそれらのうちの少なくとも一方が一致しない場合には、判定はＮＯとなって上記ステップ３０２に戻る。
【０１５０】
図２４は、本実施の形態における出力データ作成処理のフローチャートである。その作成処理は、図１１に示すステップ４０３として、図１２に示す作成処理の代わりに実行される。次に図２４を参照して、本実施の形態における作成処理について詳細に説明する。ここでも他と同様に、図１２に示すステップの処理内容と同じ、或いは基本的に同じステップには同一の符号を付すことにより、第１の実施の形態から異なる部分についてのみ説明する。
【０１５１】
本実施の形態では、ステップ５０８でサンプリングデータ読み取り処理を実行した後、ステップ１２００に移行して、ｒｄ．ｉＣｈの値が変数変数ｉＭｙＣｈの値と一致するか否か判定する。それらの値が一致しない場合、判定はＮＯとなって上記ステップ５０９に移行する。そうでない場合には、判定はＹＥＳとなってステップ１２０１に移行し、ｎｄ．ｉＳｔａｔｕｓの値の判定を行う。その値が２と判定した場合、ステップ１２０２に移行し、変数ｉＶｔｍｐにそれまでの値の２倍の値を代入した後、上記ステップ５０９に移行する。その値が３と判定した場合には、ステップ１２０３に移行し、変数ｉＶｔｍｐにそれまでの値の１／２の値を代入した後、そのステップ５０９に移行する。それにより、押鍵すべきでないタイミングで押鍵していれば楽音の音量を小さく、押鍵すべきタイミングで押鍵していなければ楽音の音量を大きくさせる音量制御を行う。そのような音量制御は上記第２、或いは第３の実施の形態に適用させても良い。
【０１５２】
なお、本実施の形態（第１〜第４の実施の形態）は、ＰＣ等のデータ処理装置に本発明を適用したものである。その適用は、本実施の形態によるプログラムに相当する楽音発生アプリケーションをデータ処理装置に実行させることで実現させている。そのようなアプリケーションは電子楽器、音源装置等の楽音発生装置用に開発しても良い。開発したアプリケーションは、ＣＤ−ＲＯＭ、ＤＶＤ、或いは着脱自在なフラッシュメモリ等の記録媒体に記録させて配布しても良い。公衆網等の通信ネットワークを介して、そのプログラムの一部、若しくは全部を配信するようにしても良い。そのようにした場合には、ユーザーはプログラムを取得してデータ処理装置、或いは楽音発生装置にロードすることにより、その装置に本発明を適用させることができる。このことから、記録媒体は、プログラムを配信する装置がアクセスできるものであっても良い。
【図面の簡単な説明】
【０１５３】
【図１】第１の実施の形態による楽音発生装置の構成を説明する図である。
【図２】音色データの構成を説明する図である。
【図３】ピッチデータの構成を説明する図である。
【図４】ソースデータの構成を説明する図である。
【図５】発音データの構成を説明する図である。
【図６】演奏データの構成を説明する図である。
【図７】楽音の発音制御によって発音される楽音を説明する図である。
【図８】全体処理のフローチャートである。
【図９】ＭＩＤＩ  ＩＮ処理のフローチャートである。
【図１０】再生処理のフローチャートである。
【図１１】オーディオデータ出力スレッドの実行によって実現される処理のフローチャートである。
【図１２】出力データ作成処理のフローチャートである。
【図１３】サンプリングデータ読み取り処理のフローチャートである。
【図１４】楽音の発音制御によって発音される楽音を説明する図である（第２の実施の形態）。
【図１５】第３の実施の形態でＭＩＤＩ  ＩＮ処理、及び再生処理にそれぞれ追加される部分のフローチャートである。
【図１６】録音データ管理データの構成を説明する図である。
【図１７】参加ユーザーデータの構成を説明する図である。
【図１８】保存データの構成を説明する図である。
【図１９】ＭＩＤＩ  ＩＮ処理のフローチャートである（第４の実施の形態）。
【図２０】再生処理のフローチャートである（第４の実施の形態）。
【図２１】データ保存処理のフローチャートである。
【図２２】録音データ再生処理のフローチャートである。
【図２３】録音データガイド再生処理のフローチャートである。
【図２４】出力データ作成処理のフローチャートである。
【符号の説明】
【０１５４】
１０    楽音発生装置
１１    ＣＰＵ
１２    ＲＡＭ
１３    ＲＯＭ
１４    入力部
１５    表示部
１６、２１    ＭＩＤＩインターフェース（Ｉ／Ｆ）
１７    オーディオインクリメント（Ｉ／Ｆ）
２０    電子楽器
２２    キーボード
３０    音源システム
【図１】
0004770419.tif 000002
【図２】
0004770419.tif 000003
【図３】
0004770419.tif 000004
【図４】
0004770419.tif 000005
【図５】
0004770419.tif 000006
【図６】
0004770419.tif 000007
【図８】
0004770419.tif 000008
【図９】
0004770419.tif 000009
【図１０】
0004770419.tif 000010
【図１１】
0004770419.tif 000011
【図１２】
0004770419.tif 000012
【図１３】
0004770419.tif 000013
【図１５】
0004770419.tif 000014
【図１６】
0004770419.tif 000015
【図１７】
0004770419.tif 000016
【図１８】
0004770419.tif 000017
【図１９】
0004770419.tif 000018
【図２０】
0004770419.tif 000019
【図２１】
0004770419.tif 000020
【図２２】
0004770419.tif 000021
【図２３】
0004770419.tif 000022
【図２４】
0004770419.tif 000023
【図７】
0004770419.tif 000024
【図１４】
0004770419.tif 000025