JPH09258737A - コンピュータソフトウェアを用いた音源システム - Google Patents

Abstract

(57)【要約】 【課題】 ＯＳを介してＭＩＤＩ演奏情報を受け、これ
に基づきアプリケーションレベルのソフト音源を駆動
し、ソフト音源のＯＳレベルでの簡易な応用範囲を広げ
る。 【解決手段】 擬似的ドライバ（ＦＭＤ）をＯＳにイン
ストールし、アプリケーションソフト（ＡＰＳ１）から
出力された演奏情報をＯＳを介して該擬似的ドライバで
受け取り、該演奏情報をアプリケーションレベルのソフ
ト音源（ＳＳＭ）に与えるようにする。別の例として
は、該ソフト音源（ＳＳＭ）をＯＳにドライバとしてイ
ンストールし、アプリケーションソフト（ＡＰＳ１）か
ら出力された演奏情報をＯＳを介して該ソフト音源が受
け取れるようにする。

Description

【発明の詳細な説明】

【０００１】

【発明の属する技術分野】この発明は、ＣＰＵのような
汎用の演算処理手段すなわちコンピュータを使用して、
ソフトウェアとして記述された音波形データ生成処理プ
ログラムを実行することに基づき音波形データを生成す
る音源システムに関する。

【０００２】

【従来の技術】電子楽器では、楽音生成処理（楽音生成
処理によって生成した楽音波形データにエフェクトを付
加する処理を含む場合もある）を、マイクロプロセッサ
に実行させることが広く行なわれている。そのようなマ
イクロプロセッサとしては、楽音生成方式（例えば波形
メモリ方式やＦＭ合成方式等）に応じた回路構成を採用
して成る専用のハードウェア（例えば音源ＬＳＩやＤＳ
Ｐ（ディジタルシグナルプロセッサ）等）を設計するこ
とが一般的であった。

【０００３】しかし近年、ＣＰＵの演算能力の向上に伴
って、汎用コンピュータや専用の楽音発生装置に搭載し
たＣＰＵにおいて、所定の楽音生成処理手順を記述した
プログラムを実行させることにより、楽音波形データを
生成させるようにしたものが登場している。ここでは、
そのような楽音生成処理プログラムを基礎としている楽
音生成装置や楽音生成方法のことをＣＰＵ音源またはソ
フトウェア音源（必要に応じてソフト音源と略称する）
と呼び、これに対し、専用のハードウェアを使用する従
来からの楽音生成装置や楽音生成方法をハード音源と呼
ぶことにする。

【０００４】従来のソフト音源は、アプリケーションレ
ベルのソフトウェアとして構成されている。図２２は、
アプリケーションレベルのソフト音源を具備する従来技
術のソフトウェア構造の一例を示す図である。このソフ
トウェア構造は、プログラミングの複雑さの低減化を目
的として、独立にプログラミングできる最小単位（モジ
ュール）の複合体として階層的に構成されている。最上
位の階層のプログラムは、ＭＩＤＩメッセージを作成す
るためのモジュールであり、具体的には、シーケンサソ
フトやゲームソフトやカラオケソフト等の形態をとるア
プリケーションソフトウェアからなっている。

【０００５】図２２では、アプリケーションソフトウェ
アの形態例として２つの形態が並列的に示されている。
１つは、カラオケプレイヤーに搭載されたカラオケソフ
ト等の形態をとっており、もう１つは、ＭＩＤＩプレイ
ヤーに搭載されたＭＩＤＩ再生ソフトの形態をとってい
る。カラオケプレイヤーでは、多数のカラオケ曲につい
てのファイルをＭＩＤＩ形式で記憶しており、選択され
たカラオケ曲のファイルを読み出し、その演奏情報をＭ
ＩＤＩメッセージのフォームで出力する。カラオケソフ
トの下位の階層に、ソフト音源モジュールが設けられ
る。このソフト音源モジュールの入力側には、所定のソ
フト音源用ＡＰＩ（アプリケーションプログラミングイ
ンターフェース）が設けられている（図中“ＳＧＭ Ｍ
ＩＤＩ ｏｕｔ ＡＰＩ”と記されたものがソフト音源
用ＡＰＩである）。

【０００６】ソフト音源モジュールは、図中の“ＳＧＭ
ＭＩＤＩ ｏｕｔ ＡＰＩ”のような専用のソフト音
源用ＡＰＩ経由で供給されるＭＩＤＩメッセージに基づ
いて楽音波形データを生成するためのプログラムからな
っている。このソフト音源モジュールは、図２３に示す
ように、「ＭＩＤＩ出力ドライバ部」と「音源部（エン
ジン部）」との２つのモジュールで構成されている。
「ＭＩＤＩ出力ドライバ部」は、「音源部」を駆動する
ためのモジュールであり、ＭＩＤＩメッセージに応じ
て、ボイスデータを「音源部」制御用の制御パラメータ
に変換する。この制御パラメータは、モジュール間の所
定のインターフェース経由で「音源部」に送られる。ま
た、「ＭＩＤＩ出力ドライバ部」が初期化されるとき、
必要な波形データ群がファイルからロードされて「波形
データ記憶部」に蓄えられる。「音源部」は、この制御
パラメータに従い、「波形データ記憶部」に蓄えられた
波形データ群を利用して（例えば所要のピッチで読み出
して）、所要のピッチや音色等の楽音特徴を具備する楽
音波形データ（順次サンプル点の楽音波形データ）を生
成する。

【０００７】コンピュータにおいて採用される所定のオ
ペレーティングシステム（例えばマイクロソフト社製の
Ｗｉｎｄｏｗｓ３．１（商標）やＷｉｎｄｏｗｓ９５
（商標）など）においては、生成済みの波形データ（波
形サンプルデータ）を授受するためのインターフェース
（例えばＷｉｎｄｏｗｓ３．１（商標）では“ＷＡＶＥ
ｏｕｔ ＡＰＩ”）が用意されている。「出力デバイ
ス」は、オペレーティングシステム（以下必要に応じて
ＯＳと略称する）にインストールされたドライバモジュ
ールであり、アプリケーションソフトとしての上記ソフ
ト音源モジュールで生成された波形データを、上記“Ｗ
ＡＶＥ ｏｕｔ ＡＰＩ”のような所定のインターフェ
ースを介して受け取り、これを外部のハードウェアに対
して出力する処理を行う。「出力デバイス」は、例え
ば、ソフト音源モジュールの処理によって生成されてハ
ードディスクのような記憶装置にバッファ記憶された波
形データをダイレクトメモリアクセス（ＤＭＡ）コント
ローラを介して読み出して、例えばディジタル／アナロ
グコンバータ（ＤＡＣ）からなる上記外部ハードウェア
に対して出力する処理を行うソフトウェアからなってい
る。

【０００８】図２２において示されたＭＩＤＩプレイヤ
ーは、ＭＩＤＩ再生モジュールとソフト音源モジュール
を予め内蔵しているタイプである。ＭＩＤＩ再生モジュ
ールでは、スタンダードＭＩＤＩファイル（ＳＭＦ）を
読み出してＭＩＤＩメッセージを再生する。再生された
ＭＩＤＩメッセージがソフト音源モジュールで処理され
て、上記と同様に、該ＭＩＤＩメッセージに対応する楽
音波形データが生成される。このＭＩＤＩプレイヤー内
のソフト音源モジュールで生成された楽音波形データ
は、上記と同様に、上記“ＷＡＶＥ ｏｕｔ ＡＰＩ”
のような所定のインターフェースを介して「出力デバイ
ス」によって処理され、外部のハードウェア（例えばＤ
ＡＣ）に対して出力される。

【０００９】一方、コンピュータのオペレーティングシ
ステムにおいては、波形データを生成する基となる演奏
情報（典型的にはＭＩＤＩメッセージ）を授受するため
のインターフェース（例えばＷｉｎｄｏｗｓ３．１（商
標）では“ＭＩＤＩ ＡＰＩ”）も用意されている。こ
のようなインターフェースの存在によって、ＭＩＤＩメ
ッセージを出力するソフトウェアをアプリケーションソ
フトとして利用することもできる。図２４は、その一例
を示したもので、ゲームソフトやシーケンサソフトある
いはマルチメディアソフト等から、様々なゲーム効果音
や背景音（ＢＧＭ）のＭＩＤＩデータあるいは自動シー
ケンス演奏音の演奏情報がＭＩＤＩメッセージのフォー
ムで出力される。これが上記“ＭＩＤＩ ＡＰＩ”のよ
うな所定のインターフェースを介してＯＳで受け取ら
れ、ＭＩＤＩドライバに与えられる。ＭＩＤＩドライバ
では、与えられたＭＩＤＩメッセージに基づく音生成用
データを外部のハードウェア音源に与える。外部のハー
ドウェア音源では、与えられたデータに基づき所定の楽
音生成用ハードウェア装置を用いて音波形データを生成
する。

【００１０】

【発明が解決しようとする課題】上述のように、従来の
アプリケーションレベルのソフト音源においては、ＯＳ
の所定のインターフェース（例えばＷＡＶＥ ｏｕｔ
ＡＰＩ）に生成済みの波形データを出力することができ
るが、波形データを生成する基となる演奏情報を授受す
るためのインターフェース（例えばＭＩＤＩ ＡＰＩ）
からのデータを受け取ってこれに基づく波形データ生成
処理を行うことができない。そのため、ゲームソフトや
シーケンサソフトあるいはマルチメディアソフト等の演
奏情報（ＭＩＤＩメッセージ）を発生する各種のソフト
ウェアと、アプリケーションレベルのソフト音源とを、
コンピュータのＯＳを介して、簡便に組み合わせること
ができなかった。また、それ故に、ゲームソフトやシー
ケンサソフトあるいはマルチメディアソフト等の演奏情
報（ＭＩＤＩメッセージ）を発生する各種のソフトウェ
アをコンピュータのＯＳに適用して簡便に使用できるよ
うにするためには、どうしてもハードウェア音源が必要
とされ、コストがかかるものとなっていた。

【００１１】ところで、ＭＩＤＩメッセージ等の演奏情
報に基づいて楽音発生処理を行おうとする場合、コンピ
ュータが楽音発生処理のみを実行することは希であり、
他のソフトウェアのプログラムを同じＯＳ上で並行して
処理することが多い。例えば、ゲームソフトを実行する
ときは、音声発生処理に並行して動画像の発生処理等を
行う必要があるし、カラオケソフトを実行する場合でも
歌詞画像及び背景画像の発生処理を同時並行的に行う必
要がある。そのような場合、ソフトウェア音源を使用す
る場合、コンピュータはそのソフトウェア音源のプログ
ラムと他の必要なソフトウェアのプログラムを同じＯＳ
上で並行して処理することになる。その場合には、他の
処理に影響されることなくソフトウェア音源による楽音
波形データ生成処理の実行が確保されるようにするため
に、マルチタスク機能を有するＯＳ（例えばＷｉｎｄｏ
ｗｓ９５（商標）等）上で楽音生成処理を実行させるこ
とが望ましい。しかし、完全なマルチタスク機能を有し
ないＯＳ（例えばＷｉｎｄｏｗｓ３．１（商標）等）も
広く普及しており、そうしたＯＳ上でも楽音生成処理を
実行させたいというニーズが存在している。しかるに、
そうしたＯＳ上では、他のソフトウェアの処理の影響に
よって楽音生成処理の実行が遅れ、その結果、発音に支
障が生じることがあり得るし、逆に、楽音生成処理に長
い時間を費やすことに影響されて他の処理の実行が遅れ
るという問題も起こり得る。特に、従来は、ハードウェ
ア音源を用いていたので、そのような並行処理の問題が
起こらなかったアプリケーションソフトにおいて、本発
明に従ってソフトウェア音源を使用するようにすると、
そのような並行処理の問題が起こるおそれが出てくるの
で、予め解決策を講ずることが望まれる。

【００１２】この発明は上述の点に鑑みてなされたもの
で、オペレーションシステムを介してＭＩＤＩメッセー
ジのような演奏情報を受けて、これに基づきアプリケー
ションレベルのソフトウェア音源を駆動することができ
るようにすることにより、ソフトウェア音源の応用範囲
を広げることができるようにしたコンピュータソフトウ
ェアを用いた音源システムを提供しようとするものであ
る。また、完全なマルチタスク機能を有しないＯＳ上で
ソフトウェア音源による音波形データ生成処理と他のソ
フトウェアの処理を並行して実行させる場合でも、楽音
生成処理や他の処理に支障が生じないようにしたコンピ
ュータソフトウェアを用いた音源システムを提供しよう
とするものである。

【００１３】

【課題を解決するための手段】第１の観点によれば、こ
の発明は、所定のオペレーティングシステムとソフトウ
ェア音源のプログラムとを搭載したコンピュータを用い
て音波形データを生成するための音源システムにおい
て、前記オペレーティングシステムは、波形データを生
成する基となる演奏情報を授受するための第１のインタ
ーフェースと、生成済みの波形データを授受するための
第２のインターフェースとを有しており、また、前記ソ
フトウェア音源は、演奏情報を受け取り、これに基づき
波形データを生成する処理を行い、生成した波形データ
を前記第２のインターフェースを介して出力するアプリ
ケーションレベルのソフトウェアであり、そこにおい
て、前記オペレーティングシステムにドライバとしてイ
ンストールされ、前記第１のインターフェースを介して
与えられる前記演奏情報を受け取り、受け取った該演奏
情報を前記ソフトウェア音源に与えるようにプログラム
された擬似的ドライバを更に具備することを特徴とする
ものである。

【００１４】上記第１の観点によれば、擬似的ドライバ
を設けたことにより、適宜のアプリケーションソフトを
介して第１のインターフェースを介して与えられる演奏
情報（例えばＭＩＤＩメッセージ）を該擬似的ドライバ
によって受け取り、この受け取った演奏情報をソフトウ
ェア音源に与えることができる。従って、自らがアプリ
ケーションソフトでもあるソフトウェア音源が、上記別
のアプリケーションソフトから与えられる演奏情報を入
力し、これに基づき音波形データ生成処理を行うことが
できる。従って、アプリケーションソフトであるソフト
ウェア音源と別のアプリケーションソフトとをＯＳレベ
ルで簡単に組み合わせることができ、該別のアプリケー
ションソフトから第１のインターフェースを介して与え
られる演奏情報（例えばＭＩＤＩメッセージ）をソフト
ウェア音源に入力して、それに対応する音波形データを
生成することができる。これにより、アプリケーション
ソフトであるソフトウェア音源の応用範囲を広げること
ができると共に、ゲームソフトやシーケンサソフトある
いはマルチメディアソフト等の演奏情報（ＭＩＤＩメッ
セージ）を発生する各種のアプリケーションソフトウェ
アをコンピュータのＯＳに適用して簡便に使用できるよ
うにする場合に、ハードウェア音源を不要にすることが
できるので、これらの簡便な応用性を確保しながら、コ
ストの面でも有利になる、という優れた効果を奏する。

【００１５】前記第１のインターフェースに演奏情報を
与える第１の手段（すなわち、ＭＩＤＩメッセージのよ
うな演奏情報を発生する上記別のアプリケーションソフ
ト）と、前記ソフトウェア音源に演奏情報を与える第２
の手段（すなわち、ＯＳを経由せずに、従来知られたよ
うに、ソフトウェア音源に専用に組み込まれたカラオケ
ソフト等の適宜のソフトウェア）とを具備し、前記ソフ
トウェア音源は、前記第１のインターフェースを経由し
て前記第１の手段から与えられる演奏情報に基づく波形
データ生成処理と前記第２の手段から直接与えられる演
奏情報に基づく波形データ生成処理とを実行するように
してもよい。これによって、従来知られたようなソフト
ウェア音源に専用に組み込まれたソフトウェア（つまり
第２の手段）と、ＯＳを介して該ソフトウェア音源と組
み合わされる別のソフトウェア（つまり第１の手段）と
によって、並行して、該ソフトウェア音源を利用するこ
とができるようになる。

【００１６】第２の観点によれば、この発明は、所定の
オペレーティングシステムとソフトウェア音源のプログ
ラムとを搭載したコンピュータを用いて音波形データを
生成するための音源システムにおいて、前記オペレーテ
ィングシステムは、波形データを生成する基となる演奏
情報を授受するための第１のインターフェースと、生成
済みの波形データを授受するための第２のインターフェ
ースとを有しており、また、前記ソフトウェア音源は、
演奏情報を受け取り、これに基づき波形データを生成す
る処理を行い、生成した波形データを前記第２のインタ
ーフェースを介して出力するアプリケーションレベルの
ソフトウェアであり、そこにおいて、前記ソフトウェア
音源のプログラムを前記オペレーティングシステムにド
ライバとしてインストールすると共に、該ソフトウェア
音源が前記第１のインターフェースを介して与えられる
前記演奏情報を受け取るようにプログラムし、前記第１
のインターフェースを介して受け取った演奏情報に基づ
く波形データ生成処理を前記ソフトウェア音源によって
実行するようにしたことを特徴とする。

【００１７】上記第２の観点によれば、アプリケーショ
ンソフトである前記ソフトウェア音源のプログラムを前
記オペレーティングシステムにドライバとしてインスト
ールすると共に、該ソフトウェア音源が前記第１のイン
ターフェースを介して与えられる前記演奏情報を受け取
るようにプログラムしたことにより、適宜のアプリケー
ションソフトを介して第１のインターフェースを介して
与えられる演奏情報（例えばＭＩＤＩメッセージ）をＯ
Ｓを介してソフトウェア音源に与えることができる。従
って、この場合も、自らがアプリケーションソフトでも
あるソフトウェア音源が、上記別のアプリケーションソ
フトから与えられる演奏情報を入力し、これに基づき音
波形データ生成処理を行うことができ、前記と同様の効
果を奏する。

【００１８】第３の観点によれば、上記の各音源システ
ムにおいて、前記コンピュータは、前記ソフトウェア音
源のプログラムとその他のプログラムを並行して実行す
る制御を行うメイン制御部を有しており、このメイン制
御部は、所定時間内の複数回の起動機会のうち、前記ソ
フトウェア音源のプログラムを実際に実行してよい機会
に起動命令を発生する起動命令発生手段を具備してお
り、また、前記ソフトウェア音源において、前記起動命
令に応じて波形データ生成処理を実際に起動した機会だ
けで、通算として前記所定時間内に所定サンプル数分の
波形データを生成させるように、波形データ生成処理を
調整する調整処理手段を具備していることを特徴とす
る。

【００１９】これによれば、コンピュータのメイン制御
部において起動命令発生手段を設け、波形データ生成処
理を起動する機会を所定時間内に複数回設定し、この複
数回の機会のうち、前記ソフトウェア音源のプログラム
を実際に実行してよい機会にだけ起動命令を発生する。
これにより、メイン制御部は、他のプログラムの実行状
況との兼ね合いで、ソフトウェア音源のプログラムを実
際に実行してよい機会にだけ起動命令を発生することが
でき、ソフトウェア音源のプログラムとその他のプログ
ラムとを適切に時分割制御して並行して実行させること
ができる。

【００２０】一方、ソフトウェア音源において、前記起
動命令に応じて波形データ生成処理を実際に起動した機
会だけで、通算として前記所定時間内に所定サンプル数
分の波形データを生成させるように、波形データ生成処
理を調整する調整処理手段を具備している。従って、所
定時間内に設定された複数回の起動機会のうち何回かの
機会で起動命令が発生されなかったとしても、起動命令
に応じて波形データ生成処理を実際に起動した機会だけ
を使用して、通算して上記所定時間内に所定サンプル数
分の音波形データを生成が完了するように制御される。
すなわち、ソフトウェア音源における１回の起動命令に
基づく波形データ生成処理量がフレキシブルに可変制御
され、所定時間内における実際の起動命令発生回数がメ
イン制御部の状況に依存する可変数であっても、通算し
て上記所定時間内に所定サンプル数分の音波形データを
生成が完了するように制御することができる。

【００２１】従って、完全なマルチタスク機能を有しな
いＯＳ上でソフトウェア音源による音波形データ生成処
理と他のソフトウェアの処理を並行して実行させる場合
でも、音波形データ生成処理及び他のソフトウェアの処
理に支障が生じないようにすることができる、という優
れた効果を奏する。すなわち、他のソフトウェアの処理
の影響によって音波形データ生成処理の起動命令発生回
数が相対的に減ったとしても、通算して上記所定時間内
に所定サンプル数分の音波形データを生成が完了するよ
うに制御されるので、発音遅れ等の支障が生じることが
なくなる。逆に、音波形データ生成処理を固定の時分割
的処理時間で行わないことにより、他のソフトウェアの
処理の実行が音波形データ生成処理によって阻害されて
その処理が遅れるという問題が起こらないようにするこ
とができる。

【００２２】一実施態様として、前記調整処理手段は、
各起動命令に対応する時点において、その時点までに生
成処理すべき波形データの未処理量の関数として、該時
点の１起動命令に応じて生成すべき波形データ量を決定
するものであってよく、その場合、前記ソフトウェア音
源は、該決定された波形データ量分の波形データを生成
する処理を、該１起動命令に応じて実行する。これによ
って、上記関数を適切に定めることにより、生成処理す
べき波形データの未処理量との兼ね合いで、１起動命令
に応じて生成すべき波形データ量を適切に決定すること
ができ、１起動命令に対応するソフトウェア音源の処理
によってメイン制御部の作業が占有されることによって
他の処理の実行が阻害されることが起こる確率をできる
だけ低くするように制御することができるようになる。

【００２３】次に、第４の観点によれば、この発明は、
所定のオペレーティングシステムで動作するサウンドプ
ログラムを実行することによって音波形データを生成す
るための音源システムにおいて、前記オペレーティング
システムは、生成済みの波形データを授受するための第
１のインターフェースと、波形データを生成する基とな
る演奏情報を授受するための第２のインターフェース
と、生成済みの波形データを授受するための第３のイン
ターフェースとを有しており、前記サウンドプログラム
は、前記オペレーティングシステムにドライバとしてイ
ンストールされており、前記第２のインターフェースか
ら入力された演奏情報に基づき、楽音生成処理を実行し
て波形データを生成する生成ステップと、前記第３のイ
ンターフェースから入力された波形データと前記生成ス
テップで生成された波形データとを同期をとって混合す
る混合ステップと、前記混合ステップで混合した波形デ
ータを前記第１のインターフェースに出力する出力ステ
ップとを実行することを特徴とする。

【００２４】前述の第２の観点に係る音源システムで
は、ソフトウェア音源がスタートすると、生成済みの波
形データを授受するための第１のインターフェースがソ
フトウェア音源によって占有されてしまい、その他のア
プリケーションソフトから発生した波形データを当該イ
ンターフェースに出力することができなかった。これに
対し、この第４の観点によれば、オペレーティングシス
テムが、生成済みの波形データを授受するためのインタ
ーフェースとして、第１のインターフェースとは別に第
３のインターフェースを有している。従って、第１のイ
ンターフェースがソフトウェア音源によって占有されて
いても、他の適宜のアプリケーションソフトから発生し
た波形データを第３のインターフェースに出力すること
ができる。

【００２５】ところで、従来の課題として述べたよう
に、完全なマルチタスク機能を有しないＯＳ上では、演
奏情報に基づく楽音生成処理に、並行して実行しなけれ
ばならない他のソフトウェアの処理の影響によって遅れ
が生じる。そのため、他のアプリケーションソフトから
第２のインターフェースを介して入力された演奏情報に
基づいてソフトウェア音源において波形データの生成が
完了するタイミングは、当該演奏情報の発生タイミング
と同じタイミングで他のアプリケーションソフトから発
生した波形データが第３のインターフェースに出力され
るタイミングよりも遅れることになるので、これらの波
形データをそのタイミングのままＯＳに与えると、再生
タイミングがずれてしまい演奏上不都合である。

【００２６】そこで、この第４の観点によれば、オペレ
ーティングシステムにドライバとしてインストールされ
たアプリケーションソフトであるサウンドプログラム
が、第２のインターフェースを介して入力された演奏情
報に基づいて波形データを生成し、その波形データを第
３のインターフェースを介して入力された波形データと
同期をとって混合し、混合した波形データを第１のイン
ターフェースに出力する。このように、演奏情報に基づ
いて生成した波形データを、第３のインターフェースを
介して入力された波形データと同期をとって混合した
後、第１のインターフェースを介してＯＳに与えること
により、波形データの生成の時間遅れが調整され、再生
タイミングを揃えられるようになる。

【００２７】尚、この第４の観点の一実施態様として、
前記混合ステップでは、第３のインターフェースを介し
て入力された波形データを初期値として、前記生成ステ
ップで生成された波形データを該初期値に累算すること
によって波形データを混合することが望ましい。なぜな
ら、演奏情報に基づく波形データの生成タイミングは、
並行して実行中の他のソフトウェア如何によって変動す
るので、第３のインターフェースを介して入力された波
形データを、この演奏情報に基づく波形データの生成時
に混合することは困難である。そこで、第３のインター
フェースを介して入力された波形データをこのように波
形データの生成時よりも前に初期値として供給しておく
ことにより、演奏情報に基づく波形データの生成タイミ
ングに左右されずに、波形データを同期をとって混合す
ることができるようになるので、タイミングを揃えた波
形データの再生を安定して行なうことができるようにな
る。

【００２８】

【発明の実施の形態】以下、添付図面を参照してこの発
明の実施の形態を詳細に説明しよう。図１は、この発明
の第１の観点に従う実施形態のソフトウェアシステム構
成例を概念的に示す図である。オペレーティングシステ
ム（ＯＳ）としては、例えば、Ｗｉｎｄｏｗｓ３．１又
はＷｉｎｄｏｗｓ９５（共にマイクロソフト社の商標）
を使用する。このＯＳは、ＭＩＤＩメッセージ（すなわ
ち波形データを生成する基となる演奏情報）を授受する
ための第１のインターフェースＩＦ１として前述の“Ｍ
ＩＤＩ ＡＰＩ”を有しており、生成済みの波形データ
を授受するための第２のインターフェースＩＦ２として
前述の“ＷＡＶＥ ｏｕｔ ＡＰＩ”を有している。

【００２９】ＭＩＤＩメッセージ（すなわち波形データ
を生成する基となる演奏情報）を発生するアプリケーシ
ョンソフトＡＰＳ１として、例えば“Ｄｉｒｅｃｔｏ
ｒ”ソフトが適用されている。この“Ｄｉｒｅｃｔｏ
ｒ”ソフトは、“Ｄｉｒｅｃｔｏｒ ｆｉｌｅｓ”を具
備しており、背景音楽（ＢＧＭ）の演奏情報をＭＩＤＩ
メッセージのフォームでリアルタイムに出力する。勿
論、アプリケーションソフトはこれに限らず、ＭＩＤＩ
メッセージ（すなわち波形データを生成する基となる演
奏情報）を発生するものであれば何でもよい。ソフトウ
ェア音源モジュールＳＳＭは、ＭＩＤＩメッセージ（す
なわち波形データを生成する基となる演奏情報）を受け
取るための専用のインターフェース（例えば前述の“Ｓ
ＧＭ ＭＩＤＩ ｏｕｔ ＡＰＩ”）を有しており、受
け取ったＭＩＤＩメッセージに基づき波形データを生成
する処理を行い、生成した波形データをＯＳレベルの前
記第２のインターフェースＩＦ２（すなわち“ＷＡＶＥ
ｏｕｔ ＡＰＩ”）を介して出力するアプリケーション
レベルのソフトウェアである。このソフトウェア音源モ
ジュールの構成例は例えば図２３に示したようであって
よい。

【００３０】図１では、ＯＳの前記第１のインターフェ
ースＩＦ１（すなわち“ＭＩＤＩＡＰＩ”）を介して与
えられるＭＩＤＩメッセージ（すなわち波形データを生
成する基となる演奏情報）を受け取り、受け取った該Ｍ
ＩＤＩメッセージを前記ソフトウェア音源モジュールＳ
ＳＭに与えるようにプログラムされた擬似的ドライバと
して、フェイクＭＩＤＩドライバＦＭＤが設けられる。
このフェイクＭＩＤＩドライバＦＭＤは、オペレーティ
ングシステムにドライバとしてインストールされる。従
って、アプリケーションソフトＡＰＳ１から第１のイン
ターフェースＩＦ１（“ＭＩＤＩ ＡＰＩ”）を介して
与えられるＭＩＤＩメッセージが、フェイクＭＩＤＩド
ライバＦＭＤによって受け取られ、この受け取られたＭ
ＩＤＩメッセージがソフトウェア音源モジュールＳＳＭ
に与えられる。

【００３１】ソフトウェア音源モジュールＳＳＭでは、
フェイクＭＩＤＩドライバＦＭＤから与えられるＭＩＤ
Ｉメッセージを自己のインターフェース（例えば“ＳＧ
ＭＭＩＤＩ ｏｕｔ ＡＰＩ”）を介して受け取り、前
述の通り、受け取ったＭＩＤＩメッセージに基づき波形
データを生成する処理を行い、生成した波形データを第
２のインターフェースＩＦ２（“ＷＡＶＥ ｏｕｔ Ａ
ＰＩ”）を介してＯＳに与える。こうして、自らがアプ
リケーションソフトでもあるソフトウェア音源モジュー
ルＳＳＭが、別のアプリケーションソフトＡＰＳ１から
ＯＳの“ＭＩＤＩ ＡＰＩ”を介して与えられたＭＩＤ
Ｉメッセージを入力し、これに基づき音波形データ生成
処理を行うことができる。従って、アプリケーションソ
フトであるソフトウェア音源モジュールＳＳＭと別のア
プリケーションソフトＡＰＳ１とをＯＳレベルで簡単に
組み合わせることができる。

【００３２】ソフトウェア音源モジュールＳＳＭには、
従来と同様に、ＭＩＤＩメッセージを出力する適宜のソ
フトウェアが専用に組み込まれていてもよい。例えば、
図１のアプリケーションソフト（例えばカラオケソフ
ト）ＡＰＳ２はそのような専用のＭＩＤＩメッセージ供
給ソフトの一例を示している。ソフトウェア音源モジュ
ールＳＳＭでは、専属のアプリケーションソフトＡＰＳ
２から供給されるＭＩＤＩメッセージも自己のインター
フェース（例えば“ＳＧＭ ＭＩＤＩ ｏｕｔＡＰ
Ｉ”）を介して受け取り、前述の通り、受け取ったＭＩ
ＤＩメッセージに基づき波形データを生成する処理を行
い、生成した波形データを第２のインターフェースＩＦ
２（“ＷＡＶＥ ｏｕｔ ＡＰＩ”）を介してＯＳに与
える。これによって、従来知られたようなソフトウェア
音源モジュールＳＳＭに専用に組み込まれたソフトウェ
アＡＰＳ２と、ＯＳを介して該ソフトウェア音源モジュ
ールＳＳＭと組み合わされる別のソフトウェアＡＰＳ１
とによって、並行して、該ソフトウェア音源モジュール
ＳＳＭを利用することができるようになる。第２のイン
ターフェースＩＦ２（“ＷＡＶＥ ｏｕｔ ＡＰＩ”）
を介してＯＳレベルで受け取られる生成済み波形データ
は、図２２の従来例と同様に、出力デバイスＯＵＤを介
して外部の装置例えばｃｏｄｅｃハードウェア（すなわ
ちディジタル／アナログ変換器ＤＡＣ）に出力される。

【００３３】図２は、この発明の第２の観点に従う実施
形態のソフトウェアシステム構成例を概念的に示す図で
ある。ここでは、アプリケーションソフトであるソフト
ウェア音源モジュールＳＳＭがオペレーティングシステ
ムにドライバとしてインストールされ、該ソフトウェア
音源モジュールＳＳＭがＯＳの第１のインターフェース
ＩＦ１（“ＭＩＤＩＡＰＩ”）を介して与えられるＭＩ
ＤＩメッセージを受け取るようにプログラムされる。従
って、アプリケーションソフトＡＰＳ１から第１のイン
ターフェースＩＦ１（“ＭＩＤＩ ＡＰＩ”）を介して
ＭＩＤＩメッセージを、ＯＳを介してソフトウェア音源
モジュールＳＳＭに与えることができる。ソフトウェア
音源モジュールＳＳＭでは、受け取ったＭＩＤＩメッセ
ージに基づく波形データ生成処理を実行し、生成した波
形データを第２のインターフェースＩＦ２（“ＷＡＶＥ
ｏｕｔ ＡＰＩ”）を介してＯＳに与える。従って、こ
の場合も、自らがアプリケーションソフトでもあるソフ
トウェア音源モジュールＳＳＭが、別のアプリケーショ
ンソフトＡＰＳ１からＯＳレベルで与えられるＭＩＤＩ
メッセージを入力し、これに基づき音波形データ生成処
理を行うことができ、生成した波形データを第２のイン
ターフェースＩＦ２（“ＷＡＶＥ ｏｕｔ ＡＰＩ”）
を介してＯＳレベルで出力することができる。

【００３４】図２５は、上記第４の観点に従う実施形態
のソフトウェアシステム構成例を概念的に示す図であ
る。このシステムでは、アプリケーションソフトＡＰＳ
１として、ＭＩＤＩメッセージ以外に波形データをＭＩ
ＤＩメッセージと同期して発生するＭｕｌｔｉｍｅｄｉ
ａソフトが適用されている。そして、ＯＳは、“ＷＡＶ
Ｅ ｏｕｔ ＡＰＩ”として、図２に示したインターフ
ェースＩＦ２（“ＷＡＶＥ ｏｕｔ ＡＰＩ”）とは別
に、ＯＳにドライバとしてインストールされたアプリケ
ーションソフトであるサウンドモジュールＳＧＭが用意
したインターフェースＩＦ３（図の左側の“ＷＡＶＥ
ｏｕｔ ＡＰＩ”）を有している。アプリケーションソ
フトＡＰＳ１から発生した波形データは、このサウンド
モジュールＳＧＭが用意したインターフェースＩＦ３で
授受される。

【００３５】サウンドモジュールＳＧＭはソフトウェア
音源モジュールＳＳＭを内蔵しており、該ソフトウェア
音源モジュールＳＳＭは、図２に示したシステムにおけ
るソフトウェア音源モジュールＳＳＭと同様に、インタ
ーフェースＩＦ１（“ＭＩＤＩ ＡＰＩ”）を介して与
えられるＭＩＤＩメッセージを受け取るようにプログラ
ムされている。ソフトウェア音源モジュールＳＳＭで
は、受け取ったＭＩＤＩメッセージに基づく波形データ
生成処理を実行する。

【００３６】またサウンドモジュールＳＧＭは、アプリ
ケーションソフトＡＰＳ１からインターフェースＩＦ３
を介して与えられる波形データと、ソフトウェア音源モ
ジュールＳＳＭが生成した波形データとの両者を受け取
り、受け取った波形データを累算した後、インターフェ
ースＩＦ２に出力するようにプログラムされている。従
って、この場合も、自らがアプリケーションソフトでも
あるサウンドモジュールＳＧＭが、別のアプリケーショ
ンソフトＡＰＳ１からＯＳレベルで与えられるＭＩＤＩ
メッセージを入力して波形データ生成処理を行うととも
に、生成した波形データとアプリケーションソフトＡＰ
Ｓ１からインターフェースＩＦ３を介して与えられる波
形データとを累算した波形データを、インターフェース
ＩＦ２を介してＯＳレベルで出力することができる。

【００３７】次に、この発明の第１の観点に従う実施形
態の詳細例を第３の観点に従う実施形態とあわせて説明
し、その後に、第２の観点に従う実施形態と、第４の観
点に従う実施形態とを説明することにする。図３は、こ
の発明に係るコンピュータソフトウェアを用いた音源シ
ステムの実施に使用するハードウェア構成例を示す全体
ブロック図である。この音源システムでは、メイン制御
部としてパーソナルコンピュータのＣＰＵ（中央処理
部）３を使用し、このＣＰＵ３の制御の下でソフトウェ
ア音源プログラムによる波形データ生成処理とその他の
プログラムの処理を並行して実行する。なお、以下では
「楽音生成処理」という用語も使用するが、これは「波
形データ生成処理」と実質的に同義であり、さらには
「波形データ生成処理」のみならずエフェクト等の各種
楽音処理を含んでいてよい。

【００３８】ＣＰＵ３には、ＭＩＤＩのインターフェー
ス１，タイマ２，ＲＯＭ（リードオンリーメモリ）４，
ＲＡＭ（ランダムアクセスメモリ）５，マウス７，キー
ボード８，ディスプレイ９，ハードディスク装置１０，
及びＤＭＡ（ダイレクトメモリアクセス）コントローラ
１１が、データ及びアドレスバス６を介して接続されて
いる。ＤＭＡコントローラ１１は、楽音生成処理の実行
によって生成されてＲＡＭ５内の出力バッファに書き込
まれた楽音データを、ＤＡＣ（ディジタル／アナログ変
換器）１２からの再生サンプリングクロックに同期して
１サンプルずつダイレクトメモリアクセス方式で出力バ
ッファから読み出してＤＡＣ１２に送る処理（再生処
理）を実行するためのものである。ＤＡＣ１２でアナロ
グ変換された楽音データは、サウンドシステム１３に送
られて、該システム１３から音響的に発音される。

【００３９】ハードディスク装置１０内のハードディス
クには、ＯＳ（ここでは、マイクロソフト社製のＷｉｎ
ｄｏｗｓ３．１（商標）を使用するものとする）やユー
ティリティソフトといったソフトウェアの他に、ソフト
音源を実現するためのソフトウェア（すなわち図１又は
図２のソフトウェア音源モジュールＳＳＭ）と、その他
のアプリケーションソフト（すなわち図１又は図２のＡ
ＰＳ１とＡＰＳ２）が記録されており、更に、複数種類
の音色についての１または複数周期分の波形データ群を
予め記憶した波形データメモリの領域を含んでいる。フ
ェイクＭＩＤＩドライバＦＭＤ等の各種プログラムをハ
ードディスク装置１０に記憶してもよいし、あるいはＲ
ＡＭ５又はＲＯＭ４に記憶してもよい。なお、以下の説
明では、ハードディスク装置１０内の波形データメモリ
に予め記憶されている「波形データ」群と、ソフトウェ
ア音源モジュールＳＳＭの処理によってＭＩＤＩメッセ
ージに対応してこの記憶波形データを利用して（読み出
して）生成する「波形データ」とを区別するために、ソ
フトウェア音源モジュールＳＳＭの処理によって生成す
る順次サンプル点「波形データ」を「楽音データ」とい
うこともある。

【００４０】ソフトウェア音源モジュールＳＳＭの概略
構成は、図２３と同様であってよい。すなわち、図２３
において、「ＭＩＤＩ出力ドライバ部」は、「音源部」
を駆動するためのモジュールであり、ＭＩＤＩメッセー
ジに応じて、ボイスデータを「音源部」制御用の制御パ
ラメータに変換する。この制御パラメータは、モジュー
ル間の所定のインターフェース（例えば“ＳＧＭ ｅｎ
ｇｉｎｅ ＡＰＩ”）経由で「音源部」に送られる。ま
た、「ＭＩＤＩ出力ドライバ部」が初期化されるとき、
上記波形データメモリの所要のファイルから波形データ
群がロードされて適宜の「波形データ記憶部」に蓄えら
れる。「音源部」は、この制御パラメータに従い、「波
形データ記憶部」に蓄えられた波形データ群を利用して
（例えば所要のピッチで読み出して）、ＭＩＤＩメッセ
ージに対応する所要のピッチや音色等の楽音特徴を具備
する楽音データを生成する。

【００４１】図１及び図２に示された「出力デバイス」
は、ＯＳレベルの前記第２のインターフェース（“ＷＡ
ＶＥ ｏｕｔ ＡＰＩ”）経由でソフトウェア音源モジュ
ールＳＳＭから供給される楽音データをＤＡＣ１２に送
るためのモジュールに相当する。前述のように、ＤＭＡ
コントローラ１１がダイレクトメモリアクセス方式で楽
音データをＤＡＣ１２に送るようになっている。したが
って、「出力デバイス」は、ＣＰＵ３の制御のもとで、
ＤＭＡコントローラ１１による割込み処理として実行さ
れる。

【００４２】次に、以下で詳細に説明しようとするＣＰ
Ｕ３による起動制御に基づく、ソフトウェア音源モジュ
ールＳＳＭによる楽音生成処理の一例の概要を、図４を
参照して説明する。アプリケーションソフトＡＰＳ１又
はＡＰＳ２のプログラムが起動すると、ソフトウェア音
源モジュールＳＳＭにＭＩＤＩメッセージが供給されは
じめる。この供給は、前述の通り、図１のシステム構成
では、アプリケーションソフトＡＰＳ１の出力について
は第１のインターフェースＩＦ１（“ＭＩＤＩ ＡＰ
Ｉ”）とフェイクＭＩＤＩドライバＦＭＤを経由して、
アプリケーションソフトＡＰＳ２の出力については直接
的に、ソフトウェア音源モジュールＳＳＭの入力インタ
ーフェース（“ＳＧＭ ＭＩＤＩ ｏｕｔ ＡＰＩ”）
に対してなされる。ソフトウェア音源モジュールＳＳＭ
の入力インターフェース（“ＳＧＭ ＭＩＤＩｏｕｔ
ＡＰＩ”）に対してＭＩＤＩメッセージが供給される
と、ソフトウェア音源モジュールＳＳＭの「ＭＩＤＩ出
力ドライバ部」（図２３）が起動され、各ＭＩＤＩメッ
セージに応じてボイスデータを制御パラメータに変換
し、その制御パラメータ等を、当該ＭＩＤＩメッセージ
に基づく発音を割り当てた発音チャンネル用の音源レジ
スタに格納する。換言すれば、これらの音源レジスタが
ソフトウェア音源モジュールＳＳＭの入力インターフェ
ース（例えば“ＳＧＭ ＭＩＤＩ ｏｕｔ ＡＰＩ”）
の一構成要素をなしている。

【００４３】ソフトウェア音源モジュールＳＳＭの「音
源部」（図２３）は、ＣＰＵ３の制御の下で、基本的に
は、所定の時間長の区間（フレームと呼ぶ）毎に設定さ
れる起動機会に応じて起動されて、それぞれその直前の
フレーム内に供給されたＭＩＤＩメッセージに基づく楽
音生成処理を、各制御パラメータに従って実行する（例
えば、図４に示すように、時刻Ｔ１からＴ２までのフレ
ーム内に供給されたＭＩＤＩメッセージに基づく楽音生
成処理を、時刻Ｔ２からＴ３までのフレームで実行す
る）。楽音生成処理の一例として、波形メモリ方式の楽
音生成処理では、まず、発音を割り当てられている各発
音チャンネル毎に、当該発音チャンネル用の音源レジス
タに格納された制御パラメータに従うピッチでＲＡＭ５
から波形データを読み出し、その波形データに、音色制
御（フィルタ演算）と、音量制御（音量エンベロープデ
ータの乗算）と、ピッチ，音色または音量等の変調制御
とを制御パラメータに従って施すことにより、当該発音
チャンネルについての所定数サンプル分の楽音データを
生成する。そして、各発音チャンネルについての楽音デ
ータを累算し、累算した楽音データを（あるいは、累算
した楽音データにエフェクトを付加し、その楽音データ
を）、ＲＡＭ５内の出力バッファに書き込む。そして、
その出力バッファの再生を「出力デバイス」に予約す
る。この出力バッファの再生を「出力デバイス」に予約
することが、生成した楽音データをソフト音源ＳＳＭか
らＯＳレベルの第２のインターフェース（“ＷＡＶＥ
ｏｕｔ ＡＰＩ”）に出力することに相当する。

【００４４】「出力デバイス」は、各フレーム毎に、そ
れぞれその直前のフレームで「音源部」によって再生予
約された出力バッファから１サンプルずつ楽音データを
読み出してＤＡＣ１２に送る（例えば、図４に示すよう
に、時刻Ｔ２からＴ３までのフレームで生成された楽音
データを書き込まれて再生予約された出力バッファか
ら、時刻Ｔ３からＴ４までのフレームで楽音データを読
み出す）。

【００４５】こうしたソフトウェアのうち、アプリケー
ションソフトＡＰＳ１及び／又はＡＰＳ２のプログラム
の起動と、ＭＩＤＩメッセージの供給に基づく「ＭＩＤ
Ｉ出力ドライバ部」の起動とは、リアルタイムに行なわ
れる。また、「出力デバイス」は、ＤＭＡコントローラ
１１による割込み処理として強制的に起動されるので、
時間的な遅れが生じることはない。これに対し、「音源
部」の起動は、ＣＰＵ３自身の内部割込みによる起動命
令によって行なわれるので、完全なマルチタスク機能を
有しないＯＳ上でこのソフトウェアを走らせた場合に
は、他の処理の影響によって「音源部」の起動が遅れる
ことにより、発音に支障が生じることがある。そこで、
この音源システムでは、次のような対策を講じることに
より、発音に支障が生じる事態を防止している。

【００４６】〔対策１〕「音源部」を起動させる内部割
込み信号（すなわち起動命令）を発生するための機会
を、各フレーム内でそれぞれ複数回設定し（例えばタイ
マによって定期的に設定する）、ソフト音源で楽音生成
処理を実行してよい機会に対応して内部割込み信号（す
なわち起動命令）を実際に発生する。内部割込み信号
（すなわち起動命令）に基づく各起動毎に、それぞれ上
記所定数サンプル分（１出力バッファ分）の楽音データ
のうちの一部の楽音データを生成することにより、通算
として当該フレーム内に１出力バッファ分の楽音データ
が生成されるように調整を行なう。そして、いずれかの
機会で、内部割込み信号（すなわち起動命令）が発生し
なかったために「音源部」が起動せず、その結果楽音デ
ータが生成されなかった場合には、その未生成の楽音デ
ータを、当該フレーム内のその後の内部割込み信号が発
生した機会で併せて生成することにより、当該フレーム
内での１出力バッファ分の楽音データの生成が確保され
るように調整を行なう。

【００４７】このように、「音源部」を起動させる内部
割込み信号（起動命令）を発生する機会を各フレーム毎
に複数回設け、この複数回の機会のうち何回か内部割込
み信号（起動命令）が発生しなくても、内部割込み信号
（起動命令）が発生した機会だけで、当該フレーム内に
１出力バッファ分の楽音データの生成を完了するように
したので、発音に支障が生じる事態が防止される。図５
及び図６は、それぞれこの〔対策１〕の一例を示す図で
ある。これらの例では、１００ミリ秒の長さのフレーム
内に、「音源部」を起動する内部割込み信号を１０ミリ
秒毎のタイミングで（したがって、１フレーム内に合計
１０回）発生し、各起動毎に、それぞれ１出力バッファ
分の楽音データの１０分の１の量の楽音データを生成す
るようにしている。

【００４８】そして、図５の例では、内部割込み信号が
発生しなかったタイミングでの未生成の楽音データを、
その直後に内部割込み信号が発生した機会で全て生成す
るようにしている。すなわち、内部割込み信号が発生し
なかった２回目の機会（図の１０ミリ秒目）で未生成と
なった楽音データを、その直後に内部割込み信号が発生
した３回目の機会（図の２０ミリ秒目）での処理で、当
該機会での楽音データと併せて全て生成し（図では２，
３として示している）、内部割込み信号が発生しなかっ
た６，７回目の機会（図の５０及び６０ミリ秒目）で未
生成となった楽音データを、その直後に内部割込み信号
が発生した８回目の機会（図の７０ミリ秒目）での処理
で、当該機会での楽音データと併せて全て生成している
（図では６〜８として示している）。この図５のような
処理方式は、未生成分がこれを直ちに一括して生成する
ので、楽音生成遅れが起こりにくい、という利点を持
つ。

【００４９】これに対し、図６の例では、内部割込み信
号が発生しなかった機会での未生成の楽音データを、そ
の後に内部割込み信号が発生した複数の機会で分散して
生成するようにしている。すなわち、内部割込み信号が
発生しなかった２，３回目の機会（図の１０，２０ミリ
秒目）で未生成となった楽音データを、その後に内部割
込み信号が発生した４，５回目の機会（図の３０及び４
０ミリ秒目）での処理で、それらの機会での楽音データ
と併せてそれぞれ分散して生成している（図ではそれぞ
れ２，３と４，５として示している）。但し、最後の１
０回目の機会（図の９０ミリ秒目）では、当該フレーム
内での１出力バッファ分の楽音データの生成を確保する
ために、内部割込み信号が発生しなかった７，８，９回
目の機会（図の６０，７０，８０ミリ秒目）で未生成と
なった楽音データを全て生成している。この図６のよう
な処理方式は、未生成量が多い場合に、これを適切に分
散した回数で処理するので、１回分の処理時間が多すぎ
ないように制御でき、ＣＰＵの有効活用に有利である。

【００５０】図６では、未生成の楽音データを、１回の
起動の機会で生成する量の楽音データに分散してその後
に内部割込み信号が発生した機会で生成しているが、こ
れに限らず、未生成の楽音データを、適宜の量の楽音デ
ータ（例えば、１回の起動の機会で生成する量の楽音デ
ータや、１回の起動の機会で生成する量の１．５倍の楽
音データや、１回の起動の機会で生成する量の半分の楽
音データ）に分散してその後の機会で生成するようにし
てもよい。また、更に別の例として、内部割込み信号が
発生しなかった機会での未生成の楽音データを、当該フ
レーム内の最後の機会（図５及び図６では１０回目の機
会）までに徐々に生成するようにしてもよい。

【００５１】図１６は、上記と同様に、〔対策１〕の一
例を示す図であるが、１回の内部割込み信号（起動命
令）に対応して生成される楽音データの量が、図５や図
６に示したように１出力バッファ分の楽音データの１０
分の１の量の整数倍になるとは限らず、該単位に対する
端数を持った量になることがありうる例を示すものであ
る。この図１６の例では、各内部割込み信号（起動命
令）に対応する時点において、その時点までに生成処理
すべき楽音データの未処理量の関数として、該時点の１
回の内部割込み信号（起動命令）に応じて生成すべき楽
音データ量を決定するようにしており、図１６は、その
ようにして決定される楽音データの量の一例を内部割込
み信号の発生との関係で示す図である。同図では、或る
フレームにおいて内部割込み信号が発生した１回目の機
会（図の０ミリ秒目）に、当該フレームにおける１出力
バッファ分の楽音データの１０分の１の量の楽音データ
を生成している。そして、内部割込み信号が発生しなか
った２及び３回目の機会（図の１０及び２０ミリ秒目）
の後、内部割込み信号が発生した４回目の機会（図の３
０ミリ秒目）に、未生成の楽音データのうち、１出力バ
ッファ分の楽音データの１０分の１．６の量の楽音デー
タを生成している（したがってこの機会までに通算とし
て当該フレームにおける１出力バッファ分の楽音データ
の１０分の２．６の量の楽音データを生成したことにな
り、図ではこのことを２．６と示している）。

【００５２】続いて、内部割込み信号が発生した５回目
の機会（図の４０ミリ秒目）に、１出力バッファ分の楽
音データの１０分の１．５の量の楽音データを生成し
（したがってこの機会までに通算として１出力バッファ
分の楽音データの１０分の４．１の量の楽音データを生
成したことになり、図ではこのことを４．１と示してい
る）、内部割込み信号が発生した６回目の機会（図の５
０ミリ秒目）に、１出力バッファ分の楽音データの１０
分の１．４の量の楽音データを生成している（したがっ
てこの機会までに通算として１出力バッファ分の楽音デ
ータの１０分の５．５の量の楽音データを生成したこと
になり、図ではこのことを５．５と示している）。そし
て、内部割込み信号が発生しなかった７及び８回目の機
会（図の６０，７０ミリ秒目）の後、内部割込み信号が
発生した９回目の機会（図の８０ミリ秒目）に、１出力
バッファ分の楽音データの１０分の１．７の量の楽音デ
ータを生成している（したがってこの機会までに通算と
して１出力バッファ分の楽音データの１０分の７．２の
量の楽音データを生成したことになり、図ではこのこと
を７．２と示している）。続いて、内部割込み信号が発
生した１０回目の機会（図の９０ミリ秒目）に、１出力
バッファ分の楽音データの１０分の１．６の量の楽音デ
ータを生成している（したがって１フレーム内に通算と
して当該フレームにおける１出力バッファ分の楽音デー
タの１０分の８．８の量の楽音データを生成したことに
なり、図ではこのことを８．８と示している）。

【００５３】そして次のフレームにおいて、内部割込み
信号が発生した１回目の機会（図の１００ミリ秒目）
に、直前のフレームにおける残りの未生成の楽音データ
である１出力バッファ分の楽音データの１０分の１．２
の量の楽音データと、今回のフレームにおける１出力バ
ッファ分の楽音データの１０分の０．３の量の楽音デー
タとを生成している（図ではこのことを１０．３と示し
ている）。この段階で、１出力バッファ分を超える楽音
データが生成されることになるので、そのうち１出力バ
ッファ分の楽音データ量に相当する１０分の１０の量の
楽音データについては、生成済みの楽音データ群から取
り出して「出力デバイス」に供給して再生予約するもの
とする。従って、生成中の楽音データとして、１出力バ
ッファ分の楽音データの１０分の０．３の量の楽音デー
タが残されることになる。

【００５４】続いて、内部割込み信号が発生した２回目
の機会（図の１１０ミリ秒目）に、今回のフレームにお
ける１出力バッファ分の楽音データの１０分の１．４の
量の楽音データを生成し（したがってこの機会までに通
算として今回のフレームにおける１出力バッファ分の楽
音データの１０分の１．７の量の楽音データを生成した
ことになり、図ではこのことを１．７と示している）、
以下同様にして、内部割込み信号が発生した機会毎に、
楽音データを生成していく。なお、追って詳しく説明す
る通り、決定された生成すべき楽音データ量が所定の上
限値ＳＲｍａｘを超える場合は、該上限値ＳＲｍａｘの
範囲内に収まるように制御される。

【００５５】このように、図１６の例では、ソフトタイ
マによる内部割込み信号が発生する毎に、それまでに未
生成となっている楽音データの量の関数として、楽音生
成処理に要する時間があまり長くならないような一定範
囲内で楽音データの生成量を決定し、その量だけ楽音デ
ータを生成する処理を実行する。内部割込み信号が発生
する毎にこうした処理が実行されることにより、未生成
の楽音データが徐々に生成されていくことになる。すな
わち、この方式は、内部割込み信号の発生を起動要因と
して楽音生成処理を実行する点では、図５，図６の例と
同じであるから、これらの例と同様の効果を期待するこ
とができる。他方、未生成の楽音データを一度に全て生
成せずに所定の関数に従って徐々に生成していく点で、
それらとは異なっており、その点で特有の効果を有す
る。すなわち、ＣＰＵ３がソフトウェア音源モジュール
ＳＳＭによる楽音生成処理のために長時間連続して独占
されることはないので、ＣＰＵ３において他のソフトウ
ェアのプログラムを並行して実行する場合や、ソフトウ
ェア音源モジュールＳＳＭにおける優先度の低い他の処
理を行なう要求が生じた場合に、それらの処理に比較的
速やかに移行させることができるので、資源の効率的な
利用が図れる。

【００５６】すなわち、例えば図５のような方式では、
未生成の楽音データの生成を最も早期に行なうことがで
きるという点では優れているが、内部割込み信号が何回
も連続して発生しなかったような場合には、その直後に
内部割込み信号が発生した機会での楽音データの生成量
が大きくなってしまう。このように生成量が大きくなる
と、一回の起動でソフトウェア音源モジュールＳＳＭに
よる楽音生成処理を行なうためにＣＰＵ３が費やさなけ
ればならない時間が長くなり、したがってＣＰＵ３がソ
フトウェア音源モジュールＳＳＭによる楽音生成処理の
実行のために長時間連続して独占されるようになるの
で、その実行中にソフトウェア音源モジュールＳＳＭに
よる楽音生成処理よりも優先順位の低い処理の起動要因
が発生しても、ＣＰＵ３がそれらの処理をなかなか実行
できなくなってしまうことがある。また、そのように１
回分の楽音データ生成量が大きくなると、演算可能時間
が残り少ない場合には、楽音データを生成可能な発音チ
ャンネル数が極端に減少してしまうことがある。これに
対して、図１６のような方式を採用すれば、それらの問
題点を解決することができる。従って、以下で詳細に説
明する実施例では、図１６のような方式に従って処理す
る例について説明することにする。

【００５７】ところで、内部割込み信号が発生しなかっ
た機会が多くなると、その後の内部割込み信号が発生し
た機会で、楽音生成処理を割り当てられている全ての発
音チャンネルについて楽音データを生成しきれなくなる
場合がある。そこで、上記〔対策１〕において、そのよ
うな機会では、楽音データを生成する発音チャンネル数
を減少させることにより、楽音データの生成を確保する
ようにすることが望ましい。楽音データを生成する発音
チャンネル数を減少させなければならない頻度は、図５
の例の場合が最も高く、図６の例の場合や、未生成の楽
音データを当該フレーム内の最後の機会までに徐々に生
成する場合、あるいは図１６の例の場合には、図５の例
の場合よりも低くなる（但し、未生成の楽音データの生
成を早期に行なうという観点からは、図５の例が最も望
ましい）。

【００５８】〔対策２〕各発音チャンネル用の音源レジ
スタとして、発音チャンネルが未使用である際に割り当
てた楽音生成処理を制御するパラメータを格納するため
の第１の音源レジスタ（表の音源レジスタ）と、当該発
音チャンネル使用中となった際に割り当てた新たな楽音
生成処理を制御するパラメータを格納するための第２の
音源レジスタ（裏の音源レジスタ）とを設ける。そし
て、当該発音チャンネルで用いるべき音源レジスタとし
て、新たな楽音生成処理を開始すべきタイミングまで
は、表の音源レジスタを選択し、該タイミング以降は、
表の音源レジスタに替えて裏の音源レジスタを選択す
る。

【００５９】これにより、現在使用中の発音チャンネル
に新たな楽音生成処理を割り当てた場合でも、表の音源
レジスタを用いて当該発音チャンネルでの現在の楽音生
成処理の実行を確保しつつ、当該発音チャンネルでの新
たな楽音生成処理を直ちに裏の音源レジスタに用意する
ことができる。したがって、楽音生成処理の用意の遅れ
を原因とする楽音データの生成の遅れを防止することが
できる。

【００６０】〔対策３〕ＲＡＭ５内に複数の出力バッフ
ァの領域を設けておき、「音源部」の起動に先行して、
そのうちの一部の出力バッファの再生を「出力デバイ
ス」に予約しておく。これにより、他の処理の影響によ
り、各フレームで起動すべき「音源部」が当該フレーム
内に起動しなくても、先行して再生予約した出力バッフ
ァの再生処理が全て完了するまでに「音源部」が起動し
て出力バッファの再生が予約されれば、楽音の再生に音
切れが生じなくなる。したがって、音切れを生じさせな
いための楽音生成処理の起動時間の遅れの許容範囲が拡
がる。

【００６１】図７は、この〔対策３〕の一例を示す図で
ある。この例では、「音源部」の起動に先行して、４つ
の出力バッファの再生を「出力デバイス」に予約してい
る。そして、フレームＦ１の開始時には、それより前の
フレームで１出力バッファ分の再生処理が完了したこと
によって予約数が３になっているが、フレームＦ１の途
中に、１出力バッファ分の楽音データの生成が完了して
その出力バッファが再生予約されたために、予約数が４
に増えている。そして、フレームＦ１の終了時に、次の
１出力バッファ分の再生処理が完了したことによって予
約数が３に減るが、フレームＦ２の途中に、次の１出力
バッファ分の楽音データの生成が完了してその出力バッ
ファが再生予約されたために、予約数が４に増えてい
る。

【００６２】そしてその後、「音源部」の起動の遅れに
より楽音データが生成されないために、フレームＦ４の
終了時には予約数が１に減っている。そして、フレーム
Ｆ５で、再生予約済の最後の出力バッファ（フレームＦ
２の途中に再生予約した出力バッファ）が読み出されて
いる（図では、この再生予約と読み出しとの関係を明ら
かにするために、フレームＦ２の途中に再生予約の発生
を太い矢印で示し、フレームＦ５を斜線で網かけしてい
る）が、フレームＦ５の途中に、１出力バッファ分の楽
音データの生成が完了してその出力バッファが再生予約
されたために、予約数が２に増えている。そしてその後
も、再生処理の完了と再生予約の発生とに応じて予約数
が増減している。

【００６３】このように、各フレームで起動すべき「音
源部」が当該フレーム内に起動しなくても、先行して再
生予約した４つの出力バッファの再生処理が全て完了す
るまでに「音源部」が起動して出力バッファの再生が予
約されれば、楽音の再生に遅れが生じなくなる。尚、予
約数が４であるときにフレームの途中で次の１出力バッ
ファ分の楽音データの生成が完了した場合には、当該フ
レームでの再生処理の完了を待って出力バッファの再生
予約を行なうことにより、予約数が４を越えないように
するものとする。

【００６４】この〔対策３〕を実施するためにＲＡＭ５
内に設けておくべき出力バッファの数は、「音源部」の
起動に先行して再生予約する出力バッファの数と、「音
源部」で生成を完了した楽音データを書き込むための１
つの出力バッファと、「音源部」で生成した楽音データ
の量が１出力バッファ分を越えた場合のための予備の出
力バッファとの合計（図７の例では、６つ）になる。尤
も、「音源部」において、生成した楽音データの量が１
出力バッファ分を越える場合には生成をストップするよ
うにすれば、予備の出力バッファは不要になる（したが
って、図７の例では、５つで足りるようになる）。

【００６５】〔対策４〕所定時間内に「出力デバイス」
に出力バッファが再生予約されていない場合、そのタイ
ミングで生成完了しているはずの楽音データの生成を打
ち切り、そのタイミングで生成開始する楽音データから
生成動作を新たに開始する。これにより、再生予約が間
に合わず、一時的に楽音が乱れた場合でも、すぐに安定
した楽音生成動作に復帰し、ノイズを最小限に抑えるこ
とができる。例えば、前述の〔対策３〕の図７の例で
は、先行して「出力デバイス」に再生予約した出力バッ
ファの再生処理が全て完了するまでに、「音源部」で生
成を完了した楽音データを書き込んだ出力バッファが再
生予約されている。しかし、他の処理の影響により「音
源部」の起動が大幅に遅れた場合には、先行して再生予
約した出力バッファの再生処理が全て完了した区間内に
おいても、「音源部」で生成を完了した楽音データを書
き込んだ出力バッファがまだ再生予約されていないこと
（予約数が０になること）も起こりうる。そのような場
合でも、〔対策３〕及び〔対策４〕を併せて実施すれ
ば、予約数が０になった場合、そのタイミングで生成完
了しているはずの楽音データの生成が打ち切られ、「出
力デバイス」に出力バッファの再生の先行予約を再び行
なった後、そのタイミングで生成開始する楽音データか
ら生成動作が新たに開始する。

【００６６】次に、以上のような対策の実施を含んだこ
のコンピュータソフトウェアを用いた音源システムの実
施例を、図８以下を参照して説明する。まず、始めに、
図１のシステム構成に対応する実施例（すなわち、フェ
イクＭＩＤＩドライバＦＭＤを使用する例）について説
明する。図８は、ＣＰＵ３によって実行されるソフトウ
ェア音源モジュールＳＳＭのプログラムのメインルーチ
ンを示すフローチャートである。最初に、「初期設定」
（ステップＳ１）を実行する。「初期設定」では、図９
に示すように、最初に、各発音チャンネル用の音源レジ
スタ（〔対策２〕として説明したように、表の音源レジ
スタと裏の音源レジスタとが設けられている）内のデー
タと、ＲＡＭ５のワークエリア（このワークエリア内に
は、〔対策３〕として説明したように、複数の出力バッ
ファの領域が含まれている）内のデータとを全てクリア
する（ステップＳ２１）。続いて、ハードディスク装置
１０内のハードディスクに記録されている波形データを
ＲＡＭ５にロードする（ステップＳ２２）。続いて、
「出力デバイス」を初期設定し（ステップＳ２３）、
〔対策３〕として説明したように、「音源部」の起動に
先行して、データをクリアされた幾つか（ここでは、図
７の例と同じく４つとする）の出力バッファの再生を
「出力デバイス」に予約する（ステップＳ２４）。続い
て、ＤＡＣ１２から再生サンプリングクロックを発生さ
せてＤＭＡコントローラ１１に与えることにより「出力
デバイス」を起動するとともに、「音源部」を起動する
内部割込み信号（起動命令）を発生するためのソフトタ
イマ（例えば、ハード的に構成したタイマをＣＰＵ３が
参照することによって内部割込み信号を発生するように
したもの）をスタートさせる（ステップＳ２５）。

【００６７】ソフトタイマは、この内部割込み信号（起
動命令）を、前記〔対策１〕として説明したように各フ
レーム毎にそれぞれ複数の機会で発生可能である（ここ
では、図５，図６，図１６の例と同じく、１００ミリ秒
の長さのフレーム内に、１０ミリ秒毎に合計１０回の機
会において発生することが可能であるものとする）。な
お、前述の通り、ソフトタイマによる内部割込み信号
（起動命令）は、各起動機会で（つまり１０ミリ秒毎
に）必ず発生できるとは限らず、起動機会が到来して
も、ＣＰＵ３がＯＳの処理や他のソフトウェアの処理に
占有されているときは、ソフトウェア音源モジュールＳ
ＳＭに対する内部割込み信号（起動命令）をかけること
ができない。そのための起動命令発生手段の構成として
は、例えば、タイマ２で１回の起動機会に対応する所定
時間（例えば１０ミリ秒）を計時する毎にフラグを立て
るようにし、ＣＰＵ３がソフト音源の処理を実行しても
よい状態のとき、このフラグの有無をチェックするよう
にし、未処理のフラグが立っていれば内部割込み信号
（起動命令）を発生するようにすると共にそのフラグを
消去するようにする。従って、１回の起動機会に対応す
る所定時間（例えば１０ミリ秒）の間に、ＣＰＵ３がソ
フト音源の処理をする余裕がある場合は、１回の内部割
込み信号（起動命令）が発生される。しかし、１回の起
動機会に対応する所定時間（例えば１０ミリ秒）の間
に、ＣＰＵ３がソフト音源の処理をする余裕がない場合
は、フラグチェックに行かないので、内部割込み信号
（起動命令）が発生されることなく、所定時間が経過し
てしまい、次のフラグが立ってしまう。つまり、前のフ
ラグに対応して内部割込み信号（起動命令）が発生され
ることがない。こうして、内部割込み信号（起動命令）
は、図５，図６，図１６に例示されるように、各起動機
会毎に必ず発生できるとは限らないものとなる。また、
上記から理解できるように、内部割込み信号（起動命
令）がいくつかの各起動機会で連続して発生される場合
でも、その発生時間間隔は正確な上記所定時間（例えば
１０ミリ秒）とはならず、１０ミリ秒の前後で適宜の変
動がある。すなわち、内部割込み信号（起動命令）の微
視的な発生タイミングはＣＰＵ３の処理状態（いつタイ
マフラグを見に行くか）に依存しているからである。

【００６８】図８に戻り、初期設定を終えると、ディス
プレイ９に、処理の進行に応じた情報を表示したり、マ
ウス７を用いて各種の制御データを入力したりするため
のパネル（図示せず）を表示する（ステップＳ２）。
尚、「音源部」の起動に先行して「初期設定」（図９）
で出力バッファを「出力デバイス」に再生予約している
ので、「出力デバイス」では、この先行予約しした４つ
の出力バッファについての再生処理が完了してから、
「音源部」でその後に再生予約した出力バッファについ
ての再生処理を実行する。したがって、ＭＩＤＩメッセ
ージが供給されてから楽音が再生されるまでの時間が、
この先行予約した出力バッファの数に等しい数のフレー
ム分（図７の例では４フレーム分）だけ長くなる（遅れ
る）ことになる。そこで、ディスプレイ９のパネルにＭ
ＩＤＩメッセージの供給に基づく表示を行なう際には、
表示のタイミングをこのフレーム分だけ後にずらすよう
にすることが望ましい。

【００６９】ステップＳ２に続くステップＳ３では、下
記の各起動要因の発生をチェックする。 起動要因：「ソフトウェア音源モジュールのＡＰＩ」
（例えば“ＳＧＭ ＭＩＤＩ ｏｕｔ ＡＰＩ”、以下
これを「ソフト音源ＡＰＩ」という）を介してＭＩＤＩ
メッセージが供給されたこと（すなわち、アプリケーシ
ョンソフトＡＰＳ１又はＡＰＳ２（図１参照）からＭＩ
ＤＩメッセージが供給されたこと）。 起動要因：ソフトタイマにより、「音源部」を起動す
る内部割込み信号（起動命令）が発生したこと。（この
発生タイミングは、上記のように、所定時間すなわち１
０ミリ秒毎に割り込みを入れることを目標としてはいる
が、必ずしもその通りに正確に発生されるものではな
い。） 起動要因：「出力デバイス」からの処理要求が検出さ
れたこと。 起動要因：その他の要求（パネルの入力イベントや、
キーボード８のコマンド入力イベント（メインルーチン
終了コマンドを除く）が検出されたこと。 起動要因：キーボード８のメインルーチン終了コマン
ドの入力イベントが検出されたこと。

【００７０】続いて、上記起動要因のいずれかが発生し
たか否かを判断する（ステップＳ４）。ノーであれば、
ステップＳ３に戻り、いずれかの起動要因が発生するま
でステップＳ３及びＳ４の処理を繰り返す。そしていず
れかの起動要因が発生すると、ステップＳ４でイエスと
なってステップＳ５に進む。ステップＳ５では、どの起
動要因が発生したのかを判定する。以後、発生した起動
要因に応じた処理を行なう。

【００７１】ここで、起動要因を起こさせる他のソフ
トウェアのプログラム例について図１７及び図１８を参
照して説明する。図１７は、フェイクＭＩＤＩドライバ
ＦＭＤ（図１）のプログラム例を示す。このフェイクＭ
ＩＤＩドライバＦＭＤ（図１）のプログラムは、アプリ
ケーションソフトＡＰＳ１（図１）からＯＳの第１のイ
ンターフェースＩＦ１（すなわち“ＭＩＤＩ ＡＰ
Ｉ”）にＭＩＤＩメッセージが与えられたとき起動され
る。ここで、アプリケーションソフトＡＰＳ１（図１）
から出力されるＭＩＤＩメッセージは１乃至１６チャン
ネルのＭＩＤＩチャンネル番号情報を含んでいるものと
する。ステップＳ２２０では、上記第１のインターフェ
ースＩＦ１（すなわち“ＭＩＤＩ ＡＰＩ”）に入力さ
れたＭＩＤＩメッセージのＭＩＤＩチャンネル番号情報
を１７乃至３６チャンネルに変換する処理を行なう。こ
れは、この例では、ソフトウェア音源を１乃至３６チャ
ンネル構成（３２パート構成）とし、そのうち１乃至１
６チャンネルを該ソフトウェア音源に専用のアプリケー
ションソフトＡＰＳ２（図１）に割当て、残りの１７乃
至３６チャンネルをフェイクＭＩＤＩドライバＦＭＤを
介在させた別のアプリケーションソフトＡＰＳ１に割り
当てるようにしたためである。従って、ソフトウェア音
源をフェイクＭＩＤＩドライバＦＭＤを介在させたアプ
リケーションソフトＡＰＳ１のみで利用する場合は、ス
テップＳ２２０の処理は不要である。ステップＳ２２１
では、上記第１のインターフェースＩＦ１（すなわち
“ＭＩＤＩ ＡＰＩ”）を介して受け取った、ステップ
Ｓ２２０でチャンネル番号変換処理済の、ＭＩＤＩメッ
セージを「ソフト音源ＡＰＩ」（ソフトウェア音源モジ
ュールＳＳＭのＡＰＩ）に転送する処理を行なう。この
転送に応じて、ソフトウェア音源モジュールＳＳＭで
は、上記起動要因が発生したと判断する。

【００７２】図１８は、ソフトウェア音源に専用のアプ
リケーションソフトＡＰＳ２（図１）におけるＭＩＤＩ
イベント処理のプログラム例を示す。このＭＩＤＩイベ
ント処理は、該アプリケーションソフトＡＰＳ２の実行
中に、ＭＩＤＩイベントが発生したとき実行される。す
なわち、ステップＳ２３０では、発生したＭＩＤＩイベ
ントに関するＭＩＤＩメッセージを、「ソフト音源ＡＰ
Ｉ」（ソフトウェア音源モジュールＳＳＭのＡＰＩ）に
入力する処理を行なう。この入力に応じて、ソフトウェ
ア音源モジュールＳＳＭでは、上記起動要因が発生し
たと判断する。このように、ソフトウェア音源に専属の
アプリケーションソフトＡＰＳ２と、ＯＳレベルで該ソ
フトウェア音源に組み合わされるアプリケーションソフ
トＡＰＳ１、の２つのアプリケーションソフトからのＭ
ＩＤＩメッセージの供給に応じて、上記起動要因が発
生される。ソフトウェア音源では、１乃至３６チャンネ
ルを上記のように使い分けて、２つのアプリケーション
ソフトに基づく楽音生成処理を並行して行なう。なお、
ＭＩＤＩチャンネル番号の変換形態は、上記例に限ら
ず、他の形態でもよい。例えば、ソフトウェア音源の１
乃至３６チャンネルのうち１乃至１６チャンネルをフェ
イクＭＩＤＩドライバＦＭＤを介在させた別のアプリケ
ーションソフトＡＰＳ１に割り当て、残りの１７乃至３
６チャンネルを該ソフトウェア音源に専用のアプリケー
ションソフトＡＰＳ２（図１）に割り当てるようにして
もよく、その場合は、図１７のステツプＳ２２０に示さ
れたようなチャンネル番号変換処理を図１８のプログラ
ムで行うようにする。

【００７３】図８に戻り、ステップＳ５において、起動
要因が発生したことが判定されると、ステップＳ６に
行き、ＭＩＤＩ処理を実行する。それから、ステップＳ
７に行き、所定の受信表示（例えば、どのＭＩＤＩチャ
ンネルについてのＭＩＤＩメッセージが供給されたかの
表示等）を、パネル上に行なう。そして、ステップＳ３
に戻り、ステップＳ３以下の処理を繰り返す。

【００７４】ステップＳ６で実行するＭＩＤＩ処理に
は、例えば、ノートオンに基づくノートオンイベント処
理や、ノートオフに基づくノートオフイベント処理等が
含まれる。図１０は、ノートオンイベント処理の一例を
示すフローチャートである。最初に、ノートナンバ，ベ
ロシティ，ノートオンを入力したＭＩＤＩチャンネルを
受信するパートのパート番号，ＭＩＤＩメッセージの入
力時刻を示す時間軸上でノートオンイベントが発生した
時刻を示すデータを、それぞれ所定のレジスタＮＮ，Ｖ
ＥＬ，ｐ，ＴＭに格納する（ステップＳ３１）。続い
て、当該ノートオンに基づく発音の割当て処理を行な
い、割り当てた発音チャンネルのチャンネル番号をレジ
スタｉに格納する（ステップＳ３２）。続いて、レジス
タｐ内のパート番号に対応して選択されている音色のボ
イスデータをＲＡＭ５から読み出し、そのボイスデータ
を、レジスタＮＮ，ＶＥＬ内のノートナンバ，ベロシテ
ィに応じて「音源部」制御用の制御パラメータ（ピッチ
を指定する周波数ナンバＦＮを含む）に変換する（図２
参照）（ステップＳ３３）。

【００７５】続いて、この制御パラメータを、ノートオ
ン及びレジスタＴＭ内の発生時刻のデータとともに、レ
ジスタｉ内のチャンネル番号の発音チャンネル用の音源
レジスタに格納することにより、当該発生時刻に応じた
タイミングでのノートオンの予約を行なう（ステップＳ
３４）。レジスタＴＭ内の発生時刻のデータを音源レジ
スタに格納するのは、次のような理由による。ノートオ
ンイベントの発生時刻と、当該ノートオンイベントに基
づく楽音が再生される時刻とには、前述のように約４フ
レーム分の時間差がある（楽音の再生がそれだけ遅れ
る）。楽音生成処理（後述する「音源処理１」）は、そ
の時間差の範囲内の任意のタイミングで、対応する楽音
データを生成すればよい（つまり、その範囲内での処理
の遅れが許容されている）。したがって、ノートオンイ
ベントの発生時刻と異なる任意のタイミングで実行され
る楽音生成処理では、ノートオンイベントの発生時刻が
わかっていないと、対応する楽音データが生成できない
からである。

【００７６】尚、ステップＳ３４において、当該発音チ
ャンネルが使用中であれば、〔対策２〕として説明した
ように、当該発音チャンネル用の表の音源レジスタと裏
の音源レジスタとのうち、裏の音源レジスタに制御パラ
メータ等を格納する。これにより、表の音源レジスタを
用いて当該発音チャンネルでの現在の楽音生成処理の実
行を確保しつつ、当該発音チャンネルでの新たな楽音生
成処理を直ちに裏の音源レジスタに用意することができ
る。またこのように裏の音源レジスタに格納を行なった
場合には、表の音源レジスタ内の予約領域にも、レジス
タＴＭ内の発生時刻に応じたタイミングでのダンプ（音
量エンベロープを急激に減少させる処理）の予約を行な
う。ステップＳ３４に続くステップＳ３５では、ノート
オンの発生時刻が遅い発音チャンネルの順に楽音生成演
算が行なわれるように、発音の割当て処理を行なった各
発音チャンネルの間での演算順序を決定する。（すなわ
ち、後着のノートオンに対応した発音チャンネルが、楽
音の生成において優先的に処理されるようになる）。そ
してリターンする。

【００７７】図１１は、ノートオフイベント処理の一例
を示すフローチャートである。最初に、ノートナンバ，
ノートオフを入力したＭＩＤＩチャンネルを受信するパ
ートに対応して選択されている音色，ＭＩＤＩメッセー
ジの入力時刻を示す時間軸上でノートオフイベントが発
生した時刻を示すデータを、それぞれ所定のレジスタＮ
Ｎ，ｔ，ＴＭに格納する（ステップＳ４１）。続いて、
レジスタｔ内の音色での発音を割り当てた発音チャンネ
ルを捜し、その発音チャンネルのチャンネル番号をレジ
スタｉに格納する（ステップＳ４２）。続いて、レジス
タｉ内のチャンネル番号の発音チャンネル用の表の音源
レジスタと裏の音源レジスタのうち、レジスタｔ内の音
色に対応するほうの音源レジスタ内の予約領域に、レジ
スタＴＭ内の発生時刻に応じたタイミングでのノートオ
フの予約を行なう（ステップＳ４３）。そしてリターン
する。

【００７８】図８の説明に戻り、ステップＳ５において
起動要因が発生していることが判定されると、「音源
処理１」を実行し（ステップＳ８）、それから、所定の
状態表示（例えば、ＣＰＵ３の演算能力や、生成した楽
音の音量レベル等の表示）を、パネル上に行なう（ステ
ップＳ９）。そしてステップＳ３に戻り、ステップＳ３
以下の処理を繰り返す。

【００７９】「音源処理１」は、前述の「音源部」の一
部を成すものである。この「音源処理１」の詳細例は図
１２に示されている。図１２において、最初のステップ
Ｓ５０では、ＭＩＤＩメッセージの入力時刻を示す時間
軸上での現在の時刻ＧＴから、その時間軸上でのＭＩＤ
Ｉメッセージの入力時刻のうち当該ＭＩＤＩメッセージ
に基づく楽音生成処理が終了しているものの最終の入力
時刻ＳＴを減じた時間を、遅れ量ＯＲ（現時点までに生
成すべき楽音データでありながら未生成である楽音デー
タの量を時間の長さで表わしたもの）として設定する。
続くステップＳ５１では、生成量ＳＲ（今回の１起動で
生成すべき楽音データの目標サンプル数を時間の長さで
表現したもの）を、遅れ量ＯＲの関数として決定する。

【００８０】図１９は、この関数の特性の一例を示す図
である。この例では、遅れ量ＯＲが一定未満である場合
には、生成量ＳＲは１０ミリ秒（１出力バッファ分の楽
音データの１０分の１に対応した時間）であるが、遅れ
量ＯＲが一定以上になると、遅れ量ＯＲが増加するにつ
れて、生成量ＳＲが連続的に増加していく。そして、生
成量ＳＲが、楽音生成処理に要する時間があまり長くな
らないような範囲内の一定の上限値ＳＲｍａｘに達する
と、遅れ量ＯＲがそれ以上増加しても、生成量ＳＲは上
限値ＳＲｍａｘを維持する。上限値ＳＲｍａｘは、例え
ば２０ミリ秒であってもよく、あるいはそれ以外の値で
あってもよい。図２０は、この関数の特性の別の一例を
示す図である。この例では、遅れ量ＯＲが一定未満であ
る場合には、生成量ＳＲは１０ミリ秒であるが、遅れ量
ＯＲが一定以上になると、遅れ量ＯＲが増加するにつれ
て、生成量ＳＲが不連続に増加していく。そして、生成
量ＳＲが、楽音生成処理に要する時間があまり長くなら
ないような範囲内の一定の上限値ＳＲｍａｘに達する
と、遅れ量ＯＲがそれ以上増加しても、生成量ＳＲは上
限値ＳＲｍａｘを維持する。

【００８１】尚、このようにして決定される生成量ＳＲ
は、１０ミリ秒を単位としてその整数倍の値のみをとる
のではなく、該単位に対する端数を持った値をとりう
る。したがって、一回の「音源処理１」の実行によって
生成される楽音データの量は、１出力バッファ分の楽音
データの１０分の１の量の整数倍になるとは限らず、図
１６に示したように、該単位に対する端数を持った量に
なることがありうる。すなわち、この図１２の「音源処
理１」は、図１６に示したような態様で、楽音生成処理
を行なうものである。従って、前述の通り、１フレーム
内の所定の起動機会において何回か内部割込み信号（起
動命令）が発生しなかったとしても、実際に内部割込み
信号（起動命令）が発生した機会だけで、当該フレーム
内で生成すべき１出力バッファ分の楽音データの生成を
効率的に行なうことができ、発音に支障が生じる事態を
防止することができると共に、他の処理を阻害するおそ
れが少なくなる。

【００８２】ステップＳ５１に続くステップＳ５２で
は、「初期設定」で再生予約した出力バッファ以外の残
りの出力バッファのうちの１つの出力バッファ上に、時
刻ＳＴを先頭とした生成量ＳＲ分の楽音生成領域を設定
する。続くステップＳ５３では、生成量ＳＲの楽音デー
タを生成する発音チャンネル数を決定する。ここで、こ
の発音チャンネル数は、一例として、遅れ量ＯＲの関数
として決定するようにしてよい。図２１は、そのような
関数の特性の一例を示す図である。この例では、遅れ量
ＯＲが一定未満である場合には、ノートオンイベント処
理（図１０）で発音割当てを行なった発音チャンネル数
ＣＨｍａｘが、そのまま楽音データを生成する発音チャ
ンネル数となるが、遅れ量ＯＲが一定以上になると、遅
れ量ＯＲが増加するにつれて、楽音データを生成する発
音チャンネル数がＣＨｍａｘよりも減少していく。この
ように、遅れ量ＯＲが一定以上である場合には、発音チ
ャンネル数が減少することにより、楽音生成処理に要す
る時間が短縮されるようになる。

【００８３】ステップＳ５３に続くステップＳ５４で
は、演算順序（ノートオンイベント処理のステップＳ３
５で決定したもの）が１位である発音チャンネルのチャ
ンネル番号をレジスタｉに格納し、スタートポインタｓ
ｐで時刻ＳＴを指す。続いて、レジスタｉ内のチャンネ
ル番号の発音チャンネル用の表の音源レジスタの予約領
域を参照して、スタートポインタｓｐ以降の生成量ＳＲ
分の楽音生成領域で、最初の予約（ピッチベンドの予
約，ノートオフの予約，ダンプの予約等）を検出する
（ステップＳ５５）。続いて、予約が検出されたか否か
を判断する（ステップＳ５６）。

【００８４】イエスであれば、当該発音チャンネルにつ
いて、当該予約の時刻までの楽音生成処理を実行し、ス
タートポインタｓｐを当該予約の時刻にまで進める（ス
テップＳ５７）。この楽音生成処理では、前述のよう
に、音源レジスタに格納された制御パラメータに従うピ
ッチでＲＡＭ５から波形データを読み出し、その波形デ
ータに、音色制御（フィルタ演算）と、音量制御（音量
エンベロープデータの乗算）と、ピッチ，音色または音
量等の変調制御と、エフェクトの付加とを制御パラメー
タに従って施すことによって楽音データを生成する。そ
して、生成した楽音データを、それまでの出力バッファ
内のデータに累算する。

【００８５】ステップＳ５７に続くステップＳ５８で
は、当該予約の内容を当該音源レジスタに格納すること
により、その予約内容を実行する。ここで、ノートオフ
の予約が検出された場合には、当該発音チャンネルの表
の音源レジスタにノートオフを書き込み、音量エンベロ
ープのリリーススラートを開始する。また、ダンプの予
約が検出された場合には、ダンプの実行の完了後（すな
わち、音量エンベロープのレベルが一定以下の低い値に
なった後）、〔対策２〕として示したように、当該発音
チャンネルで用いるべき音源レジスタとして、表の音源
レジスタに替えて裏の音源レジスタを選択する（尤も、
先に表の音源レジスタから裏の音源レジスタへの入替え
を行なった後で、表の音源レジスタについてダンプを実
行してもよい）。尚、図１０のステップＳ３４で説明し
たように、裏の音源レジスタに制御パラメータ，ノート
オン及びレジスタＴＭ内のノートオンの発生時刻のデー
タを格納する場合には、表の音源レジスタの予約領域
に、レジスタＴＭ内の発生時刻に応じたタイミングでの
ダンプの予約がされる。したがって、楽音生成処理にお
いて、このレジスタＴＭ内の発生時刻に応じたタイミン
グが来ると、ダンプが実行された後、表の音源レジスタ
に替えて裏の音源レジスタを用いた楽音生成処理が開始
されることになる。

【００８６】ステップＳ５８を終了すると、ステップＳ
５５に戻り、ステップＳ５５以下の処理を繰り返す。他
方、ステップＳ５６でノーと判断されれば（あるいは、
最初はイエスと判断されたがその後ステップＳ５７及び
Ｓ５８を経由することによりノーと判断されるようにな
れば）、当該発音チャンネルについて、スタートポイン
タｓｐ以降の生成量ＳＲ分の楽音生成領域の楽音生成処
理を全て実行する（ステップＳ５９）。これにより、ス
テップＳ５２で出力バッファ上に設定した生成量ＳＲ分
の楽音生成領域への当該発音チャンネルの楽音データの
書き込みが完了する。

【００８７】続いて、ステップＳ５３で決定した数の発
音チャンネルについての楽音生成処理が全て実行された
か否かを判断する（ステップＳ６０）。ノーであれば、
演算順序が次順位である発音チャンネルのチャンネル番
号をレジスタｉに格納し、スタートポインタｓｐを時刻
ＳＴに設定する（ステップＳ６１）。そしてステップＳ
５５に戻り、ステップＳ５５以下の処理を繰り返す。こ
れにより、発音チャンネル毎に生成された楽音データ
が、順次出力バッファ上の生成量ＳＲ分の楽音生成領域
に累算されていく。他方、ステップＳ６０でイエスと判
断されれば（あるいは、最初はノーと判断されたが、そ
の後ステップＳ５５以下を繰り返すことによりイエスと
判断されるようになれば）、楽音生成処理を終了する。
これにより、ステップＳ６２に示すように、各発音チャ
ンネルについての楽音データを累算した楽音データ（あ
るいはその楽音データに適宜のエフェクトを付加したも
の）が、出力バッファ上の生成量ＳＲ分の楽音生成領域
に書き込まれたことになる。またこのようにして、生成
可能な発音チャンネル数が発音の割当て処理を行なった
発音チャンネル数未満である場合には、演算順序の遅い
発音チャンネルについての楽音生成処理が省略されると
いう形で、同時発音チャンネル数が減少することにな
る。

【００８８】ステップＳ６２に続くステップＳ６３で
は、時刻ＳＴに生成量ＳＲの長さを加えた時刻を、新た
な時刻ＳＴとして設定する。この新たな時刻ＳＴは、次
に「音源処理１」を実行する際の演算スタート位置にな
る。続くステップＳ２６４では、今回ノートオフのあっ
た発音チャンネルについての音量エンベロープの大きさ
を、徐々にゼロに向けて下げる。続いて、１出力バッフ
ァ分の楽音データが完成したか否かを判断する（ステッ
プＳ６５）。ノーであればリターンする。他方イエスに
なると、その出力バッファを、後述の「音源処理２」に
よって当該出力バッファに連結されている他の出力バッ
ファから切り離して、「出力デバイス」に再生予約する
（ステップＳ６６）。そしてリターンする。図１，図２
との対応を示すと、このステツプＳ６６の処理は、ソフ
ト音源ＳＳＭで生成した楽音データを、ＯＳの第２のイ
ンターフェースＩＦ２（“ＷＡＶＥ ｏｕｔ ＡＰ
Ｉ”）に対して出力することに相当している。

【００８９】なお、ステップＳ５０及びＳ５１の別の例
として、「ＧＴ−ＳＴ」の結果をそのままＳＲとして設
定することも可能である。その場合は、前記〔対策１〕
における図５の例のように、いずれかの機会で内部割込
み信号が発生しなかったために「音源部」が起動しなか
った場合に、その機会での未生成の楽音データを、その
直後に内部割込み信号が発生した機会で全て生成するよ
うになる。これによっても、１フレーム内に何回か内部
割込み信号が発生しなくても、内部割込み信号が発生し
た機会だけで、当該フレーム内に１出力バッファ分の楽
音データの生成が完了するので、発音に支障が生じる事
態が防止される。また、内部割込み信号が発生しなかっ
た機会での未生成の楽音データを、図６の例のようにそ
の後に内部割込み信号が発生した複数の機会で分散して
生成するようにしたり、あるいは当該フレーム内の最後
の機会までに徐々に生成するようにしてもよいことは、
前記〔対策１〕において述べたとおりである。

【００９０】また、ステップＳ５３における発音チャン
ネル数の決定法の別の例として、次のようにしてもよ
い。まず、１つの発音チャンネルで生成量ＳＲ分の楽音
データを生成するのに要する演算時間と、今回の演算可
能時間ＥＪ（次に内部割込み信号が発生する予定の時刻
である演算終了時刻ＳＪから、今回内部割込み信号が実
際に発生した時刻である演算開始時刻ＫＪを減じた時
間）とに基づき、時間ＥＪ内に幾つの発音チャンネルで
生成量ＳＲ分の楽音データの生成が可能かを算出する。
そして、算出した生成可能な発音チャンネル数が、ノー
トオンイベント処理（図１０）で発音割当てを行なった
発音チャンネル数以上であれば、当該発音割当てを行な
った発音チャンネル数を、そのまま楽音データを生成す
る発音チャンネル数として決定する。他方、算出した生
成可能な発音チャンネル数が、発音割当てを行なった発
音チャンネル数未満であれば、当該生成可能な発音チャ
ンネル数を、楽音データを生成する発音チャンネル数と
して決定する（すなわち、〔対策１〕として説明したよ
うに、楽音データを生成する発音チャンネル数を減少さ
せることにより、１フレーム内に１出力バッファ分の楽
音データの生成を確保する）。

【００９１】図８の説明に戻り、ステップＳ５において
起動要因が発生していることが判定されると、「音源
処理２」を実行し（ステップＳ１０）、所定の状態表示
をパネル上に行なう（ステップＳ１１）。そしてステッ
プＳ３に戻り、ステップＳ３以下の処理を繰り返す。
「音源処理２」も、「音源部」の一部を成すものであ
る。この「音源処理２」は、「出力デバイス」（すなわ
ちＤＭＡコントローラ１１による外部割込み処理）の実
行によって発生する要求に基づいて実行される。図１，
図２との対応を示すと、この「音源処理２」は、ソフト
音源ＳＳＭから第２のインターフェースＩＦ２（“ＷＡ
ＶＥ ｏｕｔ ＡＰＩ”）への楽音データの授受に関連
する処理に対応している。

【００９２】図１３は、ＤＭＡコントローラ１１による
外部割込み処理の一例を示すフローチャートである。こ
の外部割込み処理は、ＤＡＣ１２に楽音データを１サン
プル分ずつ送るタイミング（ＤＡＣ１２の再生サンプリ
ング周期）で、ＤＭＡコントローラ１１が実行するもの
であり、この処理によって、出力バッファに記憶された
１フレーム分の楽音データが、再生サンプリング周期毎
に１サンプル分ずつ読み出されてＤＡＣ１２に供給され
る。これは、図１，図２における「出力デバイス」の処
理に相当する。すなわち、ＯＳのドライバである「出力
デバイス」によって、第２のインターフェースＩＦ２
（“ＷＡＶＥ ｏｕｔ ＡＰＩ”）に対してソフト音源
ＳＳＭから与えられた楽音データを受け取り、これを外
部のハードウェアつまりＤＡＣ１２に出力する処理に対
応している。最初に、「初期処理」（図９）または「音
源処理１」（図１２）によって「出力デバイス」に再生
予約された出力バッファのうちの現在読出し中の出力バ
ッファ（ポインタＰＢで指した出力バッファ）内の現在
読出し中の１サンプル分の楽音データ（ポインタｐｐで
指した楽音データ）を、ＤＡＣ１２に送る（ステップＳ
７１）。続いて、ポインタｐｐを１サンプル分進め（ス
テップＳ７２）、当該出力バッファ内の全ての楽音デー
タをＤＡＣ１２に送り終えたか（すなわち当該出力バッ
ファについての再生処理を完了したか）否かを判断する
（ステップＳ７３）。ノーであればリターンする。

【００９３】他方、ステップＳ７３でイエスと判断され
れば、次の出力バッファの再生予約があるか否かを判断
する（ステップＳ７４）。これは、第２のインターフェ
ースＩＦ２（“ＷＡＶＥ ｏｕｔ ＡＰＩ”）に対して
ＯＳを介して「出力デバイス」からアクセスする処理、
つまりＯＳを介在させた処理に相当する。他の何らかの
処理の影響により「音源部」の起動が遅れているため
に、「音源部」で生成を完了した楽音データを書き込ん
だ出力バッファが未だ再生予約されていない場合であっ
ても、既に再生予約されている出力バッファ（「初期設
定」（図９）で先行して再生予約した出力バッファや、
音源処理１で既に再生予約している出力バッファ）があ
れば、その再生処理が全て完了するまでは、ステップＳ
７４でイエスと判断されてステップＳ７５に進み、その
出力バッファにポインタＰＢを進める。これにより、
〔対策３〕として説明したように、楽音生成処理の遅れ
による音切れを防ぐための楽音生成処理の起動時間の許
容範囲が拡がることになる。ステップＳ７５に続くステ
ップＳ７６では、再生処理を完了した出力バッファを、
「音源処理２」のルーチンに返却する要求を発生する。
そしてリターンする。

【００９４】他方、「音源部」の起動が大幅に遅れてい
るために、既に再生予約している出力バッファの再生処
理を全て完了した区間内においても、「音源部」で生成
を完了した楽音データを書き込んだ出力バッファがまだ
再生予約されていない場合には、ステップＳ７４でノー
と判断されてステップＳ７７に進む。ステップＳ７７で
は、ノイズ音の発生を防止するためにＤＡＣ１２の出力
をミュートする。続いてステップＳ７８では、「音源処
理２」に対してリセット要求（楽音生成処理のリセット
を要求するもの）を発生する。そしてリターンする。

【００９５】図１４は、「出力デバイス」からの返却要
求（図１３のステップＳ７６）に基づく「音源処理２」
の一例を示すフローチャートである。最初に、「出力デ
バイス」から返却された出力バッファを受け取る（ステ
ップＳ８１）。続いて、その出力バッファをクリアし
て、「音源部」が既に保有している出力バッファの後に
その出力バッファを連結する（ステップＳ８２）。尚、
この連結とは、出力バッファ同士を仮想的に順番につな
げて大きな１つのバッファとして扱うことである。した
がって、ＲＡＭ５内で物理的に相互に隣接した領域にそ
れらの出力バッファを存在させることは必要ではない。
ステップＳ８２に続くステップＳ８３では、「音源部」
と「出力デバイス」との間での時刻のずれの有無を確認
して「音源部」の動作を補正するために、「出力デバイ
ス」からの返却要求のタイミングを示すデータを作成す
る。そしてリターンする。

【００９６】図１５は、「出力デバイス」からのリセッ
ト要求（図１３のステップＳ７８）に基づく「音源処理
２」の一例を示すフローチャートである。最初に、各発
音チャンネル用の音源レジスタ内のデータと、ＲＡＭ５
の出力バッファ内のデータとを全てクリアする（ステッ
プＳ９１）。続いて、「初期設定」（図９）のステップ
Ｓ２３乃至Ｓ２５と同じく、「出力デバイス」を初期設
定し（ステップＳ９２）、データをクリアされた４つの
出力バッファの再生を再び「出力デバイス」に予約し
（ステップＳ９３）、「出力デバイス」を起動するとと
もに、ソフトタイマをスタートさせる（ステップＳ９
４）。そしてリターンする。

【００９７】このように、リセット要求に基づく「音源
処理２」では、「出力デバイス」に出力バッファが再生
予約されていない場合には、〔対策４〕として説明した
ように、それまでに「音源部」で実行していた楽音生成
処理を打ち切り、クリアされた出力バッファの再生の先
行予約を「出力デバイス」に再び行なった後、それ以降
に供給されるＭＩＤＩメッセージに基づいて「音源部」
を起動することにより、楽音生成処理を新たに開始して
いる。これにより、再生予約が間に合わず、一時的に楽
音が乱れた場合でも、すぐに安定した楽音生成動作に復
帰するので、ノイズを最小限に抑えることができる。

【００９８】図８のステップＳ５に戻って、起動要因
が発生していると判定されると、その要求に応じた処理
（例えば、ディスプレイ９上のパネルの入力イベント処
理や、キーボード８からのコマンド入力イベント処理
等）を実行し（ステップＳ１２）、それに応じた表示を
パネル上に行なう（ステップＳ１３）。そしてステップ
Ｓ３に戻り、ステップＳ３以下の処理を繰り返す。他
方、起動要因が発生していると判定されると、メイン
ルーチンを終了させるための所定の処理を実行し（ステ
ップＳ１４）、ディスプレイ９からパネルを消去する
（ステップＳ１５）。そしてリターンする。

【００９９】尚、ステップＳ５において、起動要因乃
至のうちの２以上の起動要因が同時的に発生している
と判断された場合には、起動要因が最優先，起動要因
とがその次の優先順位，起動要因が更にその次の
優先順位，起動要因が最下位の優先順位、で該優先順
位に従って処理されるものとする。起動要因との間
には特段の優先順位を付けず、対等とする。また、ステ
ップＳ３乃至ステップＳ５は、擬似マルチタスク処理に
おけるタスク管理を仮想的に示したものであり、実際に
は、いずれかの起動要因の発生に基づいて処理を実行し
ている途中で、それよりも優先順位の高い起動要因が発
生したことにより、割込みで別の処理を実行すること
（例えば、起動要因の発生に基づいて「音源処理１」
を実行している途中で、起動要因が発生したことによ
り、割込みで「ＭＩＤＩ処理」を実行すること等）があ
る。ところで、例えば、起動要因の発生に基づいて
「音源処理１」を実行している途中で、それよりも優先
順位の低い起動要因又はが発生された場合、これら
の起動要因又はについての起動は、起動要因の発
生に基づく１回の「音源処理１」が終了するまで待たな
ければならない。しかし、図１９又は図２０に示すよう
な適切な関数に従って１回の起動に対応する生成量ＳＲ
を遅れ量ＯＲの関数として適切に決定するようにしたこ
とにより、遅れ量ＯＲが多い場合でも、起動要因の発
生に基づく１回の「音源処理１」が過度に処理時間を占
有することかなくなるので、優先順位の低い起動要因に
対応する処理を阻害する確率が低くなり、有効である。

【０１００】次に、図２のシステム構成に対応する実施
形態について説明する。図２のシステム構成を採用する
場合でも、ソフトウェア音源モジュールＳＳＭにおける
プログラムは、図８〜図１５と同様の内容からなってい
てよい。また、図１６，図１９〜図２１に従う説明も、
同様に適用可能である。勿論、図１７と図１８は適用さ
れない。ただし、図２のシステム構成を採用する場合に
は、図８のステップＳ３における起動要因のチェックの
仕方が上述例とは異なる。すなわち、図２のシステム構
成を採用する場合には、図８のステップＳ３において、
下記の各起動要因の発生をチェックする。 起動要因：「ＭＩＤＩ ＡＰＩ」を介してＭＩＤＩメ
ッセージが供給されたこと（すなわち、アプリケーショ
ンソフトＡＰＳ１（図２参照）からＭＩＤＩメッセージ
が供給されたこと） 起動要因：ソフトタイマにより、「音源部」を起動す
る内部割込み信号が発生したこと 起動要因：「出力デバイス」からの処理要求が検出さ
れたこと 起動要因：その他の要求（パネルの入力イベントや、
キーボード８のコマンド入力イベント（メインルーチン
終了コマンドを除く）が検出されたこと 起動要因：キーボード８のメインルーチン終了コマン
ドの入力イベントが検出されたこと 上記起動要因のうち、起動要因が、図１のシステム構
成を採用する場合の前述した起動要因と相違してお
り、他の起動要因〜は同じである。

【０１０１】前述の通り、図２のシステム構成を採用す
る場合においては、ソフトウェア音源モジュールＳＳＭ
はＯＳにインストールされる。そして、図８のステップ
Ｓ３でチェックする起動要因として、「ＯＳの第１の
インターフェースＩＦ１（つまり“ＭＩＤＩ ＡＰ
Ｉ”）を介してＭＩＤＩメッセージが供給されたこと」
をチェックするようにプログラムされる。これによっ
て、アプリケーションソフトであるソフトウェア音源モ
ジュールＳＳＭがＯＳ上でドライバとしてふるまい、他
のアプリケーションソフトＡＰＳ１から第１のインター
フェースＩＦ１（つまり“ＭＩＤＩ ＡＰＩ”）を介し
て与えられるＭＩＤＩメッセージを受け取る。ソフトウ
ェア音源モジュールＳＳＭでは、前述と同様に、内部割
込み信号（起動命令）の発生に基づいて楽音生成処理が
起動されるこに応じて、この受け取ったＭＩＤＩメッセ
ージに基づく楽音データの生成処理を行なう。そして、
生成された楽音データは、前述の通り、フレーム単位で
ＯＳの前記第２のインターフェースＩＦ２（つまり“Ｗ
ＡＶＥ ｏｕｔ ＡＰＩ”）を介して出力される。

【０１０２】次に、図２５のシステム構成に対応する実
施形態について説明する。図２６は、図２５のシステム
構成を採用する場合にＣＰＵ３によって実行されるサウ
ンドモジュールＳＧＭ−ＭＭのプログラムのメインルー
チンを示すフローチャートである。このメインルーチン
では、図８のステップＳ１及びＳ２と同様の処理内容の
ステップＳ３０１及びＳ３０２を実行した後、続くステ
ップＳ３０３において、下記の各起動要因の発生をチェ
ックする。 起動要因：アプリケーションソフトＡＰＳ１（図２
５）から発生したＭＩＤＩメッセージをインターフェー
ス１Ｆ１（“ＭＩＤＩ ＡＰＩ”）（図２５）を介して
受信したこと 起動要因：ソフトタイマにより、「音源部」を起動す
る内部割込み信号が発生したこと 起動要因：「出力デバイス」からの処理要求が検出さ
れたこと 起動要因：アプリケーションソフトＡＰＳ１から発生
した波形データをインターフェース１Ｆ３（図２５）を
介して受信したこと 起動要因：その他の要求（パネルの入力イベントや、
キーボード８のコマンド入力イベント（メインルーチン
終了コマンドを除く）が検出されたこと 起動要因：キーボード８のメインルーチン終了コマン
ドの入力イベントが検出されたこと 上記起動要因のうち、起動要因が、図２５のシステム
構成を採用する場合に新たに加わった起動要因であり、
他の起動要因，，，，は、図２のシステム構
成を採用する場合に図８のステップＳ３でチェックする
起動要因，，，，とそれぞれ同じである。

【０１０３】ここで、起動要因を起こさせるアプリケ
ーションソフトＡＰＳ１のプログラムの一例を図２７に
示す。このプログラムは、再生中のマルチメディアデー
タのイベントタイミングで起動し、最初のステップＳ４
０１で、そのイベントが、波形データの発生イベントで
あるか、ＭＩＤＩメッセージの発生イベントであるか、
その他の種類の情報の発生イベントであるかを判断す
る。波形データの発生イベントであれば、ステップＳ４
０１に進み、発生した波形データをインターフェース１
Ｆ３（図２５）に出力する。これにより、起動要因が
発生することになる。他方、ＭＩＤＩメッセージの発生
イベントであれば、ステップＳ４０２に進み、発生した
波形データをインターフェース１Ｆ１（“ＭＩＤＩ Ａ
ＰＩ”）（図２５）に出力する。他方、その他の種類の
情報（例えば画像データ等）の発生イベントであれば、
ステップＳ４０３に進み、当該種類に対応してＯＳが有
するＡＰＩに、その情報を出力する。

【０１０４】図２６に戻り、ステップＳ３０４以下で
は、起動要因の発生に基づくステップＳ３１２の「Ｗ
ＡＶＥ処理」及びそれに基づくＳ３１３の状態表示が追
加されている点が図８と異なっており、またステップＳ
３１０の「音源２処理」の一部の内容と図８のステップ
Ｓ１０と異なっているが、その他は図８のステップＳ４
以下と同じである。尚、ステップＳ３０５において、起
動要因乃至のうちの２以上の起動要因が同時的に発
生していると判断された場合には、起動要因が最優先
であり、起動要因乃至の間では、起動要因，，
，，の順に優先順位が高くなっている。

【０１０５】図２８は、起動要因の発生に基づく「Ｗ
ＡＶＥ処理」の一例を示す図である。この処理では、最
初のステップＳ５０１で、アプリケーションソフトＡＰ
Ｓ１からインターフェース１Ｆ１（“ＭＩＤＩ ＡＰ
Ｉ”）（図２５）を介してノートオンを受信してから、
当該ノートオンに基づいて「音源１処理」で生成された
楽音データが再生されるまでの時間Δｔ（この時間Δｔ
内で「音源１処理」での楽音生成の遅れが許容されてお
り、図７の例ではこの遅れ許容時間は約４フレーム分の
時間である）を、現在の時刻に加算してＲＡＭ５内の所
定のレジスタＷＴに書き込む。

【０１０６】続くステップＳ５０２では、アプリケーシ
ョンソフトＡＰＳ１からインターフェース１Ｆ３（図２
５）を介して与えられた波形データを、レジスタＷＴ内
の時刻データとともにＲＡＭ５内の所定のウェーブバッ
ファＷＢに書き込む。続くステップＳ５０３では、ＲＡ
Ｍ５内の所定のフラグＷＰＦ（出力バッファへの波形デ
ータの書込み中は１とし、書込み中でないときは０とす
るるフラグ）の値が１であるか否かを判断する。イエス
であれば、そのままリターンする。他方ノーであれば、
ステップＳ５０４に進み、現在保有している出力バッフ
ァが再生されることになる時刻範囲の中に、レジスタＷ
Ｔ内の時刻が含まれているか否かを判断する。イエスで
あれば、ステップＳ５０５に進み、現在保有している出
力バッファの、レジスタＷＴ内の時刻以降の再生時刻に
対応する領域に、ウェーブバッファＷＢ内の波形データ
を書き込む。尚、一度の波形データ受信イベントに基づ
いて「ＷＡＶＥ処理」でウェーブバッファＷＢに書き込
まれる波形データ量は１出力バッファ分のデータ量より
もかなり多い（一例として再生時間にして約５秒分の量
である）ので、このステップＳ５０５では、ウェーブバ
ッファＷＢ内の波形データのうちの先頭部分の一部の波
形データが出力バッファに書き込まれる。そしてステッ
プＳ５０６に進んでフラグＷＰＦの値を１に切り換えた
後、リターンする。他方、ステップＳ５０４でノーと判
断されれば、そのままリターンする。

【０１０７】図２９は、「出力デバイス」からの返却要
求（図１３のステップＳ７６）に基づく「音源処理２」
の一例を示すフローチャートである。この処理では、図
１４のステップＳ８１乃至Ｓ８３と同様の処理内容のス
テップＳ６０１乃至Ｓ６０３を実行した後、続くステッ
プＳ６０４で、フラグＷＰＦの値が１であるか否かを判
断する。

【０１０８】ノーであれば（すなわち出力バッファへの
波形データへの書込み中でなければ）、ステップＳ６０
５に進み、ステップＳ６０１で受け取った出力バッファ
が次に再生されることになる時刻範囲をチェックする。
続くステップＳ６０６では、当該再生時刻の範囲内に、
「ＷＡＶＥ処理」でレジスタＷＴに書き込んだ時刻が含
まれているか否かを判断する。ノーであれば、ステップ
Ｓ６０７に進んで当該出力バッファに書き込まれている
波形データを全てクリアした後、リターンする。他方イ
エスであれば、ステップＳ６０８に進み、当該出力バッ
ファに書き込まれている波形データのうち、レジスタＷ
Ｔ内の時刻に対応する領域までの波形データをクリアす
る。続くステップＳ６０９では、当該出力バッファの、
レジスタＷＴ内の時刻以降の再生時刻に対応する領域
に、ウェーブバッファＷＢ内の波形データのうちの先頭
部分の一部の波形データを書き込む。そしてステップＳ
６１０に進んでフラグＷＰＦの値を１に切り換えた後、
リターンする。

【０１０９】これに対し、ステップＳ６０４でイエスと
判断された場合（すなわち出力バッファへの波形データ
の書込み中の場合）には、ステップＳ６１１に進み、ス
テップＳ６０１で受け取った出力バッファの再生時刻に
対応するウェーブバッファＷＢ内の波形データ（それま
でに出力バッファに書き込んだ波形データに続く一部の
波形データ）を、当該出力バッファに書き込む。続くス
テップＳ６１２では、当該出力バッファの記憶領域の途
中で書込みが終了したか否かを判断する。ノーであれ
ば、そのままリターンする。他方イエスであれば、ステ
ップＳ６１３に進み、その次の波形データ受信イベント
に基づく波形データがウェーブバッファＷＢに書き込ま
れているか否かを判断する。

【０１１０】ノーであれば、ステップＳ６１４に進み、
当該出力バッファに書き込まれている波形データのう
ち、ステップＳ６１１で書き込みを終了した領域以降の
領域の波形データをクリアする。そしてステップＳ６１
５に進んでフラグＷＰＦの値を０に切り換えた後、リタ
ーンする。他方ステップＳ６１３でイエスと判断された
場合には、ステップＳ６１６に進み、上記次の波形デー
タ受信イベントに基づいて波形データと共にウェーブバ
ッファＷＢに書き込まれたレジスタＷＴ内の時刻が、当
該出力バッファの再生時刻よりもまだ先の時刻なのか、
その再生時刻の範囲内に含まれているのか、あるいはそ
の再生時刻よりも前の時刻（すなわち既に経過してしま
っている時刻）なのかを判断する。

【０１１１】まだ先の時刻であれば、前述のステップＳ
６１４に進み、ステップＳ６１４及びＳ６１５の処理を
実行する。他方、当該出力バッファの再生時刻の範囲内
であれば、ステップＳ６１７に進み、当該出力バッファ
に書き込まれている波形データのうち、レジスタＷＴ内
の時刻に対応する領域までの波形データをクリアする。
続くステップＳ６１８では、当該出力バッファの、レジ
スタＷＴ内の時刻以降の再生時刻に対応する領域に、上
記次の波形データ受信イベントに基づいてウェーブバッ
ファＷＢに書き込まれた波形データのうちの先頭部分の
一部の波形データを書き込む。そしてリターンする。他
方、既に経過してしまっている時刻であれば、ステップ
Ｓ６１９に進み、ステップＳ６１１で書き込みを終了し
た領域に続く領域に、上記次の波形データ受信イベント
に基づいてウェーブバッファＷＢに書き込まれた波形デ
ータのうちの先頭部分の一部の波形データを書き込む。
そしてリターンする。

【０１１２】こうした「音源処理２」を実行することに
より、「音源１処理」において生成した波形データが出
力バッファに書き込まれる前に、アプリケーションソフ
トＡＰＳ１から供給された波形データが、「音源１処
理」における波形生成処理の許容遅れ時間を考慮した出
力バッファ中の領域に初期値として書き込まれる。そし
て、その後図１２に示したのと同じ「音源１処理」にお
いて、各チャンネル毎に生成された波形データがこの初
期値に順次累算されていく。これにより、「音源１処
理」における波形データの生成タイミングに左右されず
に、波形データが同期をとって混合されるようになる。

【０１１３】図３０は、「出力デバイス」からのリセッ
ト要求（図１３のステップＳ７８）に基づく「音源処理
２」の一例を示すフローチャートである。この処理で
は、最初のステップＳ７０１において、音源レジスタ及
び出力バッファ内のデータを全てクリアすると共に、ウ
ェーブバッファＷＢ内のデータも全てクリアする。すな
わち、それまでの波形データ受信イベントに基づいて
「ＷＡＶＥ処理」でウェーブバッファＷＢに書き込んだ
波形データ及び時刻データを全てキャンセルして、新た
に受信する波形データから再生を開始するようにする。
そして、続くステップＳ７０２乃至７０４で、図１５の
ステップＳ９２乃至Ｓ９４と同じ処理内容を実行した
後、リターンする。

【０１１４】尚、アプリケーションソフトＡＰＳ１から
供給された波形データを出力バッファ中の領域に初期値
として書き込む処理は、必ずしも図２９の例のように
「出力デバイス」からの返却要求に基づく「音源処理
２」の一部として実行しなければならないものではな
く、「音源１処理」で波形データが生成されるまでに実
行すれば足りるものである。したがって、別の例とし
て、図１２の「音源１処理」のステップＳ５２でＳＲ分
の楽音生成領域を設定する際に、この初期値の書き込み
処理を併せて行なうようにしてもよい。

【０１１５】また、アプリケーションソフトＡＰＳ１か
ら発生する波形データは、サンプリング周波数がまちま
ちであり、したがって「音源１処理」で生成した波形デ
ータとはサンプリング周波数が一致しない場合がある。
そこで、ウェーブバッファＷＢ内の波形データを出力バ
ッファに書き込む処理の前段階として、所定の補間処理
またはオーバーサンプリング処理を該波形データに施す
ことにより、サンプリング周波数を一致させておくよう
にしてもよい。

【０１１６】また、アプリケーションソフトＡＰＳ１か
ら発生する画像データ等のその他の情報についても、
「音源１処理」における波形生成処理の許容遅れ時間を
考慮した再生タイミングの調整処理を同様にして行なう
ようにしてもよい。

【０１１７】このように、図２５のシステム構成では、
アプリケーションソフトＡＰＳ１から発生してインター
フェース１Ｆ３に出力された波形データは、アプリケー
ションソフトＡＰＳ１からインターフェース１Ｆ１
（“ＭＩＤＩ ＡＰＩ”）を介して受信したノートオン
に基づいてソフトウェア音源モジュールＳＳＭで生成さ
れた波形データと同期をとって混合した後、インターフ
ェース１Ｆ２を介してＯＳに与えられるようになる。こ
れにより、ソフトウェア音源モジュールＳＳＭにおける
波形データの生成の時間遅れが調整され、波形データの
再生タイミングが揃えられるようになる。

【０１１８】尚、以上の実施の形態では、〔対策１〕に
おいて、通算として１フレーム内に所定サンプル数の楽
音データを生成するようにしている。しかし、ここで
「通算として」というのは、必ずしも１つのフレーム内
で該所定サンプル数の楽音データの生成が完了すること
を要求するものではない。特に、これらの実施の形態で
は、図７に示すように、楽音データを書き込んだ出力バ
ッファを複数再生予約できるようになっているので、１
つのフレーム内で楽音データの生成演算が完了しなくて
も、その後のフレームでその分を補う演算を行なうこと
が可能である。図６を例にとってこのことを説明すれ
ば、図６では、内部割込み信号の発生しなかった機会で
の未生成の楽音データを、１つのフレーム内の最後の機
会までに間に合うように生成するようにしているが、該
最後の機会までに生成できなくても、その次のフレーム
にその生成を持ち越すようにしてよい（例えば、未生成
の４回分の楽音データを図６のように１０回目の機会
（１００ミリ秒目）で全て生成するかわりに、１０回目
の機会で７，８回目の２回分の楽音データだけを生成
し、それ以降のフレームで内部割込み信号が発生した機
会で、残りの９，１０回目の２回分の楽音データを生成
するようにしてよい）。尚、図１６に例示しているよう
に、或るフレームにおける未生成の楽音データの生成
を、その次のフレームに持ち越すことがありうる。

【０１１９】また、以上の実施の形態では、ノートオン
イベント処理やノートオフイベント処理といったＭＩＤ
Ｉ処理において、「音源部」制御用の制御パラメータ，
ノートオン及びイベントの発生時刻を示すデータを、各
発音チャンネル毎に設けた音源レジスタに格納してい
る。しかし、このようにこれら制御パラメータ等を各発
音チャンネル毎に別の音源レジスタに格納するかわり
に、１つの記憶エリアに、制御パラメータ等を発音チャ
ンネルのチャンネル番号を示すデータと組にして順次書
き込むようにしてもよい。その場合には、ＭＩＤＩメッ
セージの供給に基づいて、一旦シーケンスデータを作成
し、このシーケンスデータに基づいて楽音データの生成
を行なうことになる。

【０１２０】また、以上の実施の形態では、「音源処理
２」において、「出力デバイス」から返却された出力バ
ッファを、「音源部」が既に保有している出力バッファ
の後に連結しており、したがって「音源処理１」におい
ては、このように連結された出力バッファに、１出力バ
ッファ分ずつ楽音データを生成している。しかし、この
ように出力バッファを連結するかわりに、個々の出力バ
ッファを単位として楽音データを生成するようにしても
よい。

【０１２１】また、以上の実施の形態では、「音源部」
の起動に先行して、４つの出力バッファの再生を「出力
デバイス」に予約している。しかし、「音源部」の起動
に先行して「出力デバイス」に再生予約する出力バッフ
ァの数は、もちろん４以外であってよい。また、また、
ＲＡＭ５内に設ける出力バッファの数も、「音源部」の
起動に先行して「出力デバイス」に再生予約する出力バ
ッファの数よりも１以上多い適宜の数であってよい。

【０１２２】また、以上の実施の形態では、〔対策
１〕，〔対策２〕，〔対策３〕及び〔対策４〕を全て実
施している。しかし、これらの対策は、それぞれ相互に
独立して実施しても、「音源部」の起動の遅れを原因と
して発音に支障が生じる事態を防止できるものである。
したがって、これらの対策のうちのいずれか１つのみを
実施したり、２つまたは３つを適宜組み合わせて実施し
たりしてもよい。また、上記の実施形態においては、ソ
フト音源においては、生成した楽音波形データを出力バ
ッファに最大で４００ｍｓ分貯めてから、これを出力す
るようにしている。そのため、他のソフトウェアによっ
て処理される該再生音楽情報に関連する他の情報（例え
ばカラオケの背景画像や歌詞画像情報）の再生タイミン
グと同期がとれなくなると不都合が生じるので、適宜の
同期化対策を講ずるようにすかるのがよい。例えば、Ｍ
ＩＤＩメッセージを出力するタイミングを、該ＭＩＤＩ
メッセージに対応する再生音楽情報に同期されるべき他
の情報（例えばカラオケの背景画像や歌詞画像情報）の
出力タイミングよりも早めてやり、ソフト音源における
楽音生成処理が他の処理よりも幾分先行して行なわれる
ようにしてやれば、最終的に必要な全情報を同期して出
力することができる。

【０１２３】また、以上の実施の形態では、波形メモリ
方式の楽音生成処理をＣＰＵに実行させるタイプのソフ
トウェア音源にこの発明を適用しているが、他の適宜の
楽音生成方式（例えばＦＭ合成方式等）をＣＰＵに実行
させるタイプのソフトウェア音源においてこの発明を適
用してもよい。また、この発明は、パーソナルコンピュ
ータ（つまり汎用コンピュータ）のＣＰＵによって楽音
生成処理を実行させるようにしたソフトウェア音源にお
いて適用することができるのみならず、専用の楽音発生
装置やその他の特機化された適宜の装置内に搭載された
コンピュータのＣＰＵによって楽音生成処理を実行させ
るソフトウェア音源を具備するシステムにおいて適用す
ることができる。また、波形データ生成の基となる演奏
情報は、必ずしもＭＩＤＩフォームの情報に限定される
ものではなく、その他の形式であってもよい。

【０１２４】

【発明の効果】以上の通り、この発明の第１の観点によ
れば、擬似的ドライバ（ＦＭＤ）を設けたことにより、
適宜のアプリケーションソフト（ＡＰＳ１）を介してＯ
Ｓ上の第１のインターフェース（ＭＩＤＩ ＡＰＩ）を
介して与えられる演奏情報（例えばＭＩＤＩメッセー
ジ）を該擬似的ドライバによって受け取り、この受け取
った演奏情報をアプリケーションレベルのソフトウェア
音源（ＳＳＭ）に与えることができる。従って、自らが
アプリケーションソフトでもあるソフトウェア音源（Ｓ
ＳＭ）が、上記別のアプリケーションソフト（ＡＰＳ
１）から与えられる演奏情報を入力し、これに基づき音
波形データ生成処理を行うことができるようになり、ア
プリケーションソフトであるソフトウェア音源と別のア
プリケーションソフトとをＯＳレベルで簡単に組み合わ
せることができ、該別のアプリケーションソフトから第
１のインターフェースを介して与えられる演奏情報（例
えばＭＩＤＩメッセージ）をソフトウェア音源に入力し
て、それに対応する音波形データを生成することができ
るものである。これにより、アプリケーションソフトで
あるソフトウェア音源の応用範囲を広げることができる
と共に、ゲームソフトやシーケンサソフトあるいはマル
チメディアソフト等の演奏情報（ＭＩＤＩメッセージ）
を発生する各種のアプリケーションソフトウェアをコン
ピュータのＯＳに適用して簡便に使用できるようにする
場合に、ハードウェア音源を不要にすることができるの
で、これらの簡便な応用性を確保しながら、コストの面
でも有利になる、という優れた効果を奏する。

【０１２５】また、第１のインターフェース（ＭＩＤＩ
ＡＰＩ）に演奏情報を与える第１の手段（アプリケー
ションソフトＡＰＳ１）と、ソフトウェア音源（ＳＳ
Ｍ）に演奏情報を与える第２の手段（ソフトウェア音源
に専用に組み込まれたソフトウェアＡＰＳ２）とを具備
し、ソフトウェア音源（ＳＳＭ）が両方の演奏情報に基
づく楽音波形データ生成処理を実行するようにすること
により、従来知られたようなソフトウェア音源に専用に
組み込まれたソフトウェア（ＡＰＳ２）と、ＯＳを介し
て該ソフトウェア音源と組み合わされる別のソフトウェ
ア（ＡＰＳ１）とによって、並行して、該ソフトウェア
音源を利用することができるようになる、という優れた
効果を奏する。

【０１２６】また、この発明の第２の観点によれば、ア
プリケーションソフトであるソフトウェア音源（ＳＳ
Ｍ）のプログラムをＯＳにドライバとしてインストール
して、該ソフトウェア音源が第１のインターフェース
（ＭＩＤＩ ＡＰＩ）を介して与えられる演奏情報をＯ
Ｓ経由で受け取るようにしたことにより、適宜のアプリ
ケーションソフト（ＡＰＳ１）を介して第１のインター
フェースを介して与えられる演奏情報（例えばＭＩＤＩ
メッセージ）をＯＳを介してソフトウェア音源に与える
ことができる。従って、この場合も、自らがアプリケー
ションソフトでもあるソフトウェア音源が、上記別のア
プリケーションソフトから与えられる演奏情報を入力
し、これに基づき音波形データ生成処理を行うことがで
き、前記と同様の効果を奏する。

【０１２７】更に、この発明の第３の観点によれば、コ
ンピュータのメイン制御部（ＣＰＵ３）において起動命
令発生手段を設け、波形データ生成処理を起動する機会
を所定時間内に複数回設定し、この複数回の機会のう
ち、前記ソフトウェア音源のプログラムを実際に実行し
てよい機会にだけ起動命令を発生し、これにより、メイ
ン制御部は、他のプログラムの実行状況との兼ね合い
で、ソフトウェア音源のプログラムを実際に実行してよ
い機会にだけ起動命令を発生することができ、ソフトウ
ェア音源のプログラムとその他のプログラムとを適切に
時分割制御して並行して実行させることができる一方
で、ソフトウェア音源（ＳＳＭ）において、前記起動命
令に応じて波形データ生成処理を実際に起動した機会だ
けで、通算として前記所定時間内に所定サンプル数分の
波形データを生成させるように、波形データ生成処理を
調整する調整処理手段を具備したので、所定時間内に設
定された複数回の起動機会のうち何回かの機会で起動命
令が発生されなかったとしても、起動命令に応じて波形
データ生成処理を実際に起動した機会だけを使用して、
通算して上記所定時間内に所定サンプル数分の音波形デ
ータを生成が完了するように制御することができ、発音
遅れの問題を解決することができる。従って、完全なマ
ルチタスク機能を有しないＯＳ上でソフトウェア音源に
よる音波形データ生成処理と他のソフトウェアの処理を
並行して実行させる場合でも、音波形データ生成処理及
び他のソフトウェアの処理に支障が生じないようにする
ことができる、という優れた効果を奏する。すなわち、
他のソフトウェアの処理の影響によって音波形データ生
成処理の起動命令発生回数が相対的に減ったとしても、
通算して上記所定時間内に所定サンプル数分の音波形デ
ータを生成が完了するように制御されるので、発音遅れ
等の支障が生じることがなくなる。逆に、音波形データ
生成処理を固定の時分割的処理時間で行わないことによ
り、他のソフトウェアの処理の実行が音波形データ生成
処理によって阻害されてその処理が遅れるという問題が
起こらないようにすることができる。

【０１２８】その場合、各起動命令に対応する時点にお
いて、その時点までに生成処理すべき波形データの未処
理量の関数として、該時点の１起動命令に応じて生成す
べき波形データ量を決定し、該決定された波形データ量
分の波形データを生成する処理を、該１起動命令に応じ
て実行するようにしたことにより、上記関数を適切に定
めることにより、生成処理すべき波形データの未処理量
との兼ね合いで、１起動命令に応じて生成すべき波形デ
ータ量を適切に決定することができ、１起動命令に対応
するソフトウェア音源の処理によってメイン制御部の作
業が占有されることによって他の処理の実行が阻害され
ることが起こる確率をできるだけ低くするように制御す
ることができるようになる。

【０１２９】更に、この発明の第４の観点によれば、Ｏ
Ｓオペレーティングシステムが、生成済みの波形データ
を授受するためのインターフェースとして、第１のイン
ターフェースとは別に第３のインターフェースを有して
おり、且つ、オペレーティングシステムにドライバとし
てインストールされたアプリケーションソフトであるサ
ウンドプログラムが、第２のインターフェースを介して
入力された演奏情報に基づいて波形データを生成し、そ
の波形データを第３のインターフェースを介して入力さ
れた波形データと同期をとって混合し、混合した波形デ
ータを第１のインターフェースを介してＯＳに与える。
従って、適宜の別のアプリケーションソフトから発生し
た波形データを第３のインターフェースから入力し、こ
の波形データと、適宜の別のアプリケーションソフトか
ら第２のインターフェースを介して入力された演奏情報
に基づいて生成した波形データとをタイミングを揃えて
再生することができるようになる。

【０１３０】また、第３のインターフェースを介して入
力された波形データを初期値として、演奏情報に基づい
て生成した波形データを該初期値に累算することによっ
て波形データを混合するようにすれば、演奏情報に基づ
く波形データの生成タイミングに左右されずに、波形デ
ータを同期をとって混合することができるようになるの
で、タイミングを揃えた波形データの再生を安定して行
なうことができるようになる。

【図面の簡単な説明】

【図１】 この発明の第１の観点に従う実施形態のソフ
トウェアシステム構成を略示する図。

【図２】 この発明の第２の観点に従う実施形態のソフ
トウェアシステム構成を略示する図。

【図３】 この発明の一実施形態に係る音源システムの
ハードウェア構成例を示す全体ブロック図。

【図４】 この発明の一例として採用するソフトウェア
による楽音生成処理の概略を説明する図。

【図５】 この発明の一実施形態において採用可能な
〔対策１〕の一例を示す説明図。

【図６】 この発明の一実施形態において採用可能な
〔対策１〕の別の例を示す説明図。

【図７】 この発明の一実施形態において採用可能な
〔対策３〕の一例を示す説明図。

【図８】 図３のＣＰＵによって実行されるソフトウェ
ア音源プログラムのメインルーチンの一例を示すフロー
チャート。

【図９】 図８における初期設定処理の一例を示すフロ
ーチャート。

【図１０】 図８におけるＭＩＤＩ処理において実行さ
れるノートオンイベント処理の一例を示すフローチャー
ト。

【図１１】 図８におけるＭＩＤＩ処理において実行さ
れるノートオフイベント処理の一例を示すフローチャー
ト。

【図１２】 図８における音源処理１の一例を示すフロ
ーチャート。

【図１３】 図３のＤＭＡコントローラによる割込み処
理の一例を示すフローチャート。

【図１４】 図３のＤＭＡコントローラからの返却要求
に基づいて実行される図８の音源処理２の一例を示すフ
ローチャート。

【図１５】 図３のＤＭＡコントローラからのリセット
要求に基づいて実行される図８の音源処理２の一例を示
すフローチャート。

【図１６】 この発明の一実施形態において採用可能な
〔対策１〕の更に別の例を示すものであって、内部割込
み信号の発生と楽音データの生成量との関係の一例を示
す説明図。

【図１７】 図１のフェイクＭＩＤＩドライバにおける
プログラム例を示すフローチャート。

【図１８】 図１のソフトウェア音源モジュールに専属
のアプリケーションソフトに含まれるＭＩＤＩイベント
処理のプログラム例を示すフローチャート。

【図１９】 生成量ＳＲを遅れ量ＯＲの関数として決定
する際の関数の特性の一例を示す図。

【図２０】 生成量ＳＲを遅れ量ＯＲの関数として決定
する際の関数の特性の別の一例を示す図。

【図２１】 発音チャンネル数を遅れ量ＯＲの関数とし
て決定する際の関数の特性の一例を示す図。

【図２２】 アプリケーションレベルのソフトウェア音
源を実施するソフトウェアシステム構成の従来例を示す
図。

【図２３】 従来知られたソフトウェア音源モジュール
の概念的構成例を示す図。

【図２４】 ＭＩＤＩメッセージを出力するアプリケー
ションソフトを実施するシステム構成の従来例を示す
図。

【図２５】 この発明の第４の観点に従う実施形態のソ
フトウェアシステム構成を略示する図。

【図２６】 図２５のシステムにおいて図３のＣＰＵに
よって実行されるサウンドモジュールのプログラムのメ
インルーチンの一例を示すフローチャート。

【図２７】 図２５のシステムにおいてアプリケーショ
ンソフトＡＰＳ１が再生中のデータのイベントタイミン
グで実行する処理の一例を示すフローチャート。

【図２８】 図２６におけるＷＡＶＥ処理の一例を示す
フローチャート。

【図２９】 図３のＤＭＡコントローラからの返却要求
に基づいて実行される図２６の音源処理２の一例を示す
フローチャート。

【図３０】 図３のＤＭＡコントローラからのリセット
要求に基づいて実行される図２６の音源処理２の一例を
示すフローチャート。

【符号の説明】

ＳＳＭ ソフトウェア音源モジュール ＡＰＳ１，ＡＰＳ２ アプリケーションソフト ＩＦ１，ＩＦ２ 第１及び第２のインターフェース ＦＭＤ フェイクＭＩＤＩドライバ １ ＭＩＤＩ ２ タイマ ３ ＣＰＵ ４ ＲＯＭ ５ ＲＡＭ ６ データ及びアドレスバス ７ マウス ８ キーボード ９ ディスプレイ １０ ハードディスク装置 １１ ＤＭＡコントローラ １２ ＤＡＣ １３ サウンドシステム

Claims (7)

【特許請求の範囲】
1. 【請求項１】 所定のオペレーティングシステムとソフ
   トウェア音源のプログラムとを搭載したコンピュータを
   用いて音波形データを生成するための音源システムにお
   いて、 前記オペレーティングシステムは、波形データを生成す
   る基となる演奏情報を授受するための第１のインターフ
   ェースと、生成済みの波形データを授受するための第２
   のインターフェースとを有しており、 前記ソフトウェア音源は、演奏情報を受け取り、これに
   基づき波形データを生成する処理を行い、生成した波形
   データを前記第２のインターフェースを介して出力する
   アプリケーションレベルのソフトウェアであり、 前記オペレーティングシステムにドライバとしてインス
   トールされ、前記第１のインターフェースを介して与え
   られる前記演奏情報を受け取り、受け取った該演奏情報
   を前記ソフトウェア音源に与えるようにプログラムされ
   た擬似的ドライバを更に具備することを特徴とする音源
   システム。
2. 【請求項２】 前記第１のインターフェースに演奏情報
   を与える第１の手段と、前記ソフトウェア音源に演奏情
   報を与える第２の手段とを更に具備し、前記ソフトウェ
   ア音源は、前記第１のインターフェースを経由して前記
   第１の手段から与えられる演奏情報に基づく波形データ
   生成処理と前記第２の手段から直接与えられる演奏情報
   に基づく波形データ生成処理とを実行するものである請
   求項１に記載の音源システム。
3. 【請求項３】 所定のオペレーティングシステムとソフ
   トウェア音源のプログラムとを搭載したコンピュータを
   用いて音波形データを生成するための音源システムにお
   いて、 前記オペレーティングシステムは、波形データを生成す
   る基となる演奏情報を授受するための第１のインターフ
   ェースと、生成済みの波形データを授受するための第２
   のインターフェースとを有しており、 前記ソフトウェア音源は、演奏情報を受け取り、これに
   基づき波形データを生成する処理を行い、生成した波形
   データを前記第２のインターフェースを介して出力する
   アプリケーションレベルのソフトウェアであり、 前記ソフトウェア音源のプログラムを前記オペレーティ
   ングシステムにドライバとしてインストールすると共
   に、該ソフトウェア音源が前記第１のインターフェース
   を介して与えられる前記演奏情報を受け取るようにプロ
   グラムし、前記第１のインターフェースを介して受け取
   った演奏情報に基づく波形データ生成処理を前記ソフト
   ウェア音源によって実行するようにしたことを特徴とす
   る音源システム。
4. 【請求項４】 前記コンピュータは、前記ソフトウェア
   音源のプログラムとその他のプログラムを並行して実行
   する制御を行うメイン制御部を有しており、このメイン
   制御部は、所定時間内の複数回の起動機会のうち、前記
   ソフトウェア音源のプログラムを実際に実行してよい機
   会に起動命令を発生する起動命令発生手段を具備してお
   り、 前記ソフトウェア音源において、前記起動命令に応じて
   波形データ生成処理を実際に起動した機会だけで、通算
   として前記所定時間内に所定サンプル数分の波形データ
   を生成させるように、波形データ生成処理を調整する調
   整処理手段を具備していることを特徴とする請求項１又
   は３に記載の音源システム。
5. 【請求項５】 前記調整処理手段は、各起動命令に対応
   する時点において、その時点までに生成処理すべき波形
   データの未処理量の関数として、該時点の１起動命令に
   応じて生成すべき波形データ量を決定するものであり、
   前記ソフトウェア音源において、該決定された波形デー
   タ量分の波形データを生成する処理を、該１起動命令に
   応じて実行するようにした請求項４に記載の音源システ
   ム。
6. 【請求項６】 所定のオペレーティングシステムで動作
   するサウンドプログラムを実行することによって音波形
   データを生成するための音源システムにおいて、 前記オペレーティングシステムは、生成済みの波形デー
   タを授受するための第１のインターフェースと、波形デ
   ータを生成する基となる演奏情報を授受するための第２
   のインターフェースと、生成済みの波形データを授受す
   るための第３のインターフェースとを有しており、 前記サウンドプログラムは、前記オペレーティングシス
   テムにドライバとしてインストールされており、前記第
   ２のインターフェースから入力された演奏情報に基づ
   き、楽音生成処理を実行して波形データを生成する生成
   ステップと、前記第３のインターフェースから入力され
   た波形データと前記生成ステップで生成された波形デー
   タとを同期をとって混合する混合ステップと、前記混合
   ステップで混合した波形データを前記第１のインターフ
   ェースに出力する出力ステップとを実行することを特徴
   とする音源システム。
7. 【請求項７】 前記混合ステップでは、前記第３のイン
   ターフェースから入力された波形データを初期値とし
   て、前記生成ステップで生成された波形データを該初期
   値に累算することによって波形データを混合する請求項
   ７に記載の音源システム。