JP3322209B2

JP3322209B2 - コンピュータソフトウェアを用いた音源システムおよび記憶媒体

Info

Publication number: JP3322209B2
Application number: JP10394698A
Authority: JP
Inventors: 英之増田
Original assignee: Yamaha Corp
Current assignee: Yamaha Corp
Priority date: 1998-03-31
Filing date: 1998-03-31
Publication date: 2002-09-09
Anticipated expiration: 2018-03-31
Also published as: JPH11288290A; US6040516A

Description

【発明の詳細な説明】

【０００１】

【発明の属する技術分野】本発明は、コンピュータソフ
トウェアを用いて楽音を合成する音源システムおよび該
コンピュータソフトウェアを記憶した記憶媒体に関す
る。

【０００２】

【従来の技術】従来、コンピュータソフトウェアを用い
て楽音を合成する音源システムの一つとして、自然楽器
の発音メカニズム（物理現象）をシミュレートし、当該
自然楽器の音色の楽音を合成する物理モデル音源と呼ば
れるものが知られている（たとえば特開平２−２９３８
９８号公報参照）。

【０００３】物理モデル音源は、具体的には、自然楽器
の発音メカニズムを次のようにしてシミュレートする。

【０００４】すなわち、シミュレートすべき自然楽器
が、たとえば管楽器の場合には、演奏者の息圧に相当す
る信号（励振信号）を発生させ、この息圧が管内を通っ
て楽音信号になるまでの物理現象を、少なくとも励振信
号の遅延およびループによりシミュレートする。

【０００５】また、シミュレートすべき自然楽器が弦楽
器の場合には、演奏者の弓速度および弓圧によって弦に
発生する初期振動に相当する信号（励振信号）を発生さ
せ、この初期振動によって発生した弦振動が弦を振動さ
せて楽音信号になるまでの物理現象を、少なくとも励振
信号の遅延およびループによりシミュレートする。

【０００６】このように、物理モデル音源は、少なくと
も励振信号を遅延しループさせることによって、自然楽
器の発音メカニズムをシミュレートしているので、コン
ピュータソフトウェアによって容易に物理モデル音源を
実現することができ、実際に製品化されている。

【０００７】

【発明が解決しようとする課題】しかし、上記従来の物
理モデル音源、すなわちコンピュータソフトウェアによ
って実現した物理モデル音源では、ほぼ演算のみによっ
て楽音を発生させるためにその演算量は多く、また、同
時発音数を多くすればするほど演算量は増大するため、
ＣＰＵの能力が向上した現在においても、この演算量は
ＣＰＵにとって多大な負荷となっている。この事情は、
物理モデル音源が楽音出力を行っていないとき、すなわ
ち無音のときでもほとんど変化なく、ＣＰＵにはある一
定以上の演算負荷が常時かかっている。したがって、物
理モデル音源の起動時、実行時には、無音状態であるに
も拘わらず、他のアプリケーションプログラムを同時に
起動、実行させることができない場合があった。

【０００８】また、ＣＰＵに対する演算負荷について
は、物理モデル音源以外のソフト音源（コンピュータソ
フトウェアを用いて楽音を合成する音源）であっても、
程度の差はあるものの問題になっており、たとえばＦＭ
音源方式のソフト音源に対して、本願出願人は、特願平
８−２４６９４２において、ＣＰＵの演算負荷を減少さ
せる手法を開示した。具体的には、楽音の出力波形を監
視し、その振幅レベルが所定の閾値より小さくなったと
きに、所定の波形生成ブロック（ソフトウェアによって
記述されるブロック）における演算を停止して、ＣＰＵ
の演算量を減少させている。

【０００９】この手法を単純に物理モデル音源に適用し
て、楽音の出力状態を監視し、無音状態になったとき
に、物理モデル音源処理を停止することにより、ＣＰＵ
の演算負荷を低減させることも考えられる。

【００１０】しかし、物理モデル音源では、上述のよう
に、少なくとも励振信号の遅延およびループによって楽
音を発生させるため、楽音の出力状態のみを監視して物
理モデル音源処理を停止すると、発音指示から楽音信号
出力までの遅延時間により、出力状態は無音の状態であ
っても、発音指示はなされているという場合があり、こ
の場合には、当該楽音信号の合成演算の途中で演算が停
止され、演奏者の意図した楽音が発音されない虞があっ
た。

【００１１】本発明は、この点に着目してなされたもの
であり、ソフト音源として、たとえば物理モデル音源を
採用したときに、真に無音な状態を検出して、物理モデ
ル音源処理を停止することにより、ＣＰＵに対する演算
負荷を低減化することが可能な音源システムおよび記憶
媒体を提供することを目的とする。

【００１２】

【課題を解決するための手段】上記目的を達成するた
め、本発明の音源システムは、楽音信号の発生要求に応
じて励振信号を発生するとともに、該発生した励振信号
を少なくとも遅延およびループさせることにより楽音信
号を生成する楽音生成モジュールと、前記楽音信号の発
生要求の有無を監視する第１の監視モジュールと、前記
楽音生成モジュールによって生成された楽音信号の有無
を監視する第２の監視モジュールと、前記第１の監視モ
ジュールによって楽音信号の発生要求がなされていない
ことが検出され、かつ、前記第２の監視モジュールによ
って楽音信号が生成されていないことが検出されたとき
に、前記楽音生成モジュールの実行を停止する停止モジ
ュールとを有するコンピュータソフトウェアを用いた音
源システムであって、前記第１の監視モジュールによる
監視のタイミングと前記第２の監視モジュールによる監
視のタイミングとの間に、前記楽音生成モジュール内の
遅延量に応じた時間差を設けることを特徴とする。

【００１３】ここで、楽音合成モジュールとしては、物
理モデル音源が典型例であるが、これに限る必要はな
い。励振信号の発生要求から楽音信号の生成までに時間
遅れが生ずる楽音合成モジュールに対して、本発明は有
効である。第１の監視モジュールによる励振信号の発生
要求の監視方法は、たとえば、発生要求に関連する情報
をバッファに記憶し、その値が“０”か否かを監視する
方法が挙げられる。もちろん、これに限らず、発生要求
の有無を監視できる方法であればどのような方法でもよ
い。第２の監視モジュールによる楽音信号の監視方法
も、第１の監視モジュールでの監視方法と同様に各種方
法が考えられる。停止モジュールは、楽音合成モジュー
ル内に位置するように構成してもよいし、楽音合成モジ
ュール外に位置するように構成してもよい（以下、請求
項が変わっても同様）。

【００１４】また、上記目的を達成するために、本発明
の記憶媒体は、楽音信号の発生要求に応じて励振信号を
発生するとともに、該発生した励振信号を少なくとも遅
延およびループさせることにより楽音信号を生成する楽
音生成モジュールと、前記励振信号の有無を監視する第
１の監視モジュールと、前記楽音生成モジュールによっ
て生成された楽音信号の有無を監視する第２の監視モジ
ュールと、前記第１の監視モジュールによって励振信号
が発生されていないことが検出され、かつ、前記第２の
監視モジュールによって楽音信号が生成されていないこ
とが検出されたときに、前記楽音生成モジュールの実行
を停止する停止モジュールとを含むことを特徴とする。

【００１５】また、上記目的を達成するため、本発明の
音源システムは、楽音信号の発生要求に応じて励振信号
を発生するとともに、該発生した励振信号を少なくとも
遅延およびループさせることにより楽音信号を生成する
楽音生成モジュールと、前記励振信号の有無を監視する
第１の監視モジュールと、前記楽音生成モジュールによ
って生成された楽音信号の有無を監視する第２の監視モ
ジュールと、前記第１の監視モジュールによって励振信
号が発生されていないことが検出され、かつ、前記第２
の監視モジュールによって楽音信号が生成されていない
ことが検出されたときに、前記楽音生成モジュールの実
行を停止する停止モジュールとを有することを特徴とす
る。

【００１６】さらに、好ましくは、前記楽音生成モジュ
ールによって生成される楽音信号の特性に応じて前記第
１および第２の監視モジュールにおける監視の条件を変
更することを特徴とする。

【００１７】ここで、楽音信号の特性の例としては、当
該楽音信号の音高、音高周期、音色等が挙げられる。監
視の条件とは、たとえば、バッファを用いて監視してい
る場合には、そのバッファ長や、バッファ内の監視範囲
等である。

【００１８】

【発明の実施の形態】以下、本発明の実施の形態を図面
に基づいて詳細に説明する。

【００１９】図１は、本発明の一実施の形態に係る音源
システムを実現するハードウェアの概略構成を示す図で
ある。本システムは、最も典型的な一例として汎用のパ
ーソナルコンピュータにより実現され、そのメイン制御
部としてはＣＰＵ３が使用され、該ＣＰＵ３の制御の下
で、ＯＳ（Operating System）、演奏制御アプリケーシ
ョンプログラム、楽音合成アプリケーションプログラム
および該楽音合成アプリケーションプログラム以外のそ
の他のプログラムが並行して実行される。

【００２０】同図において、ＣＰＵ３には、外部からの
ＭＩＤＩ（Musical Instrument Digital Interface）メ
ッセージを入力したり、ＭＩＤＩメッセージを外部に出
力したりするＭＩＤＩインターフェースＭＩＤＩＩ／Ｆ
１、タイマ割込み時間や各種時間を計時するタイマ２、
各種制御プログラムやテーブルデータ（音色データライ
ブラリを含む）等を記憶するＲＯＭ（リードオンリメモ
リ）４、前記選択されたＭＩＤＩファイルや各種入力情
報および演算結果等を一時的に記憶するＲＡＭ（ランダ
ムアクセスメモリ）５、たとえば鍵盤やホイール、ジョ
イスティック等の演奏操作子７、たとえばキーボードや
マウス等の設定操作子８、たとえば大型ＬＣＤやＣＲＴ
等の各種情報等を表示するディスプレイ９、ＣＰＵ３が
実行する各種制御プログラムを含む各種アプリケーショ
ンプログラムや各種データ等を記憶する、たとえばフロ
ッピディスクドライブ、ハードディスクドライブ、ＣＤ
−ＲＯＭ（Compact Disc Read-Only Memory）ドライ
ブ、ＭＯ（Magneto Optical）ドライブ等の外部記憶装
置１０、および、通信ネットワーク１０１を介して、た
とえばサーバコンピュータ１０２とデータの送受信を行
う通信インターフェース（Ｉ／Ｆ）１４が、データおよ
びアドレスバス６を介して接続されている。

【００２１】また、データおよびアドレスバス６には、
拡張インターフェース（Ｉ／Ｆ）＆拡張バス１５を介し
て、デジタル楽音信号をアナログ楽音信号に変換するＤ
ＡＣ（Digital-to-Analog Converter）１２が接続され
ている。そして、ＤＡＣ１２は、その楽音信号出力を音
響に変換するための、たとえばアンプやスピーカ等から
なるサウンドシステム１３に接続されている。

【００２２】ＤＡＣ１２は、ＣＯＤＥＣ（COder-DECode
r）と呼ばれるハードウェアの一部の機能に相当する。
ＣＯＤＥＣは、出力すべき楽音信号（アナログ信号）の
基になるデジタル楽音信号を記憶するバッファを備え、
ＣＰＵ３は、ソフト音源プログラム（少なくとも物理モ
デル音源プログラムを含む）に従って合成した楽音信号
を、このバッファに順次送出する。そして、ＣＯＤＥＣ
は、この記憶されたデジタル楽音信号を所定のタイミン
グで順次読み出し、Ｄ／Ａ変換を施した後に、サウンド
システム１３に送出する。すなわち、本実施の形態で
は、楽音信号をすべてＣＰＵ３で合成するようにしてい
るため、音源部１１は必要ない。しかし、これに限ら
ず、音源部１１を設けて、楽音信号の合成の一部を音源
部１１に分担させるようにしてもよい。

【００２３】外部記憶装置１０内の、たとえばハードデ
ィスクには、前記ＯＳやユーティリティソフト等のソフ
トウェアの他に、ソフト音源を実現するためのソフトウ
ェアと、その他のアプリケーションソフトが記憶されて
いる。

【００２４】通信Ｉ／Ｆ１４は、ＬＡＮ（ローカルエリ
アネットワーク）やインターネット、電話回線等の通信
ネットワーク１０１に接続されており、該通信ネットワ
ーク１０１を介して、サーバコンピュータ１０２と接続
される。外部記憶装置１０内のハードディスクに上記各
プログラムや各種パラメータが記憶されていない場合に
は、通信Ｉ／Ｆ１４は、サーバコンピュータ１０２から
プログラムやパラメータをダウンロードするために用い
られる。クライアントとなるコンピュータ（本実施の形
態の音源システム）は、通信Ｉ／Ｆ１４及び通信ネット
ワーク１０１を介してサーバコンピュータ１０２へとプ
ログラムやパラメータのダウンロードを要求するコマン
ドを送信する。サーバコンピュータ１０２は、このコマ
ンドを受け、要求されたプログラムやパラメータを、通
信ネットワーク１０１を介してコンピュータへと配信
し、コンピュータが通信Ｉ／Ｆ１０１を介して、これら
プログラムやパラメータを受信して外部記憶装置１０内
のハードディスクに蓄積することにより、ダウンロード
が完了する。

【００２５】この他、外部コンピュータ等との間で直接
データのやりとりを行うためのインターフェースを備え
てもよい。

【００２６】図２は、本実施の形態の音源システムの機
能を視覚的に表した図であり、物理モデル音源に関連す
るもののみが図示されている。

【００２７】本実施の形態の音源システムは、複数種類
の音源方式（たとえば、物理モデル音源、ＦＭ（Freque
ncy Modulation）音源、ＰＣＭ（Pulse Code Modulatio
n）音源等）によって複数種類の楽音を発生し、合成す
ることができるように構成されている。そして、本発明
の特徴は、物理モデル音源が選択されているときの音源
制御にあるため、図２には、物理モデル音源に関連する
機能のみが図示されている。以下、図２に基づいて、本
実施の形態の音源システムの機能を説明する。

【００２８】本実施の形態の音源システムは、操作子情
報、演奏曲データおよびＭＩＤＩメッセージ等を入力す
る入力部２１と、入力部２１から入力された各種情報に
基づいて演奏制御情報を発生する演奏制御アプリケーシ
ョンと、該発生した演奏制御情報に基づいて楽音信号を
合成する楽音合成アプリケーションと、ＯＳと、このＯ
Ｓのシステム管理部にその一部機能が任されている楽音
合成管理部とによって、主として構成されている。

【００２９】入力部２１は、入力するデータ（情報）の
種類に応じて前記ＭＩＤＩＩ／Ｆ１、ＣＰＵ３、演奏操
作子７および設定操作子８等のいずれかに相当する。す
なわち、入力部２１は、操作子情報を入力するときには
演奏操作子７に相当し、演奏曲データを入力するときに
はＣＰＵ３に相当し、ＭＩＤＩメッセージを入力すると
きにはＭＩＤＩＩ／Ｆ１に相当する。

【００３０】演奏制御アプリケーションは、楽音合成の
基礎になる各種パラーメータを設定して供給するパラメ
ータ設定供給部２２と、楽音合成を開始する契機を与え
るとともにその楽音合成の基礎になる演奏操作情報を供
給する演奏操作情報供給部２３とにより構成されてい
る。パラメータ設定供給部２２は、入力部２１からの入
力データに基づいて各種パラメータを設定し、演奏操作
情報供給部２３に供給するとともに、楽音合成アプリケ
ーションおよび楽音合成管理部に供給する。演奏操作情
報供給部２３は、入力部２１からの入力データおよびパ
ラメータ設定供給部２２からの供給パラメータに基づい
て演奏操作情報を生成し、楽音合成アプリケーションお
よび楽音合成管理部に供給する。演奏操作情報は、具体
的には、シミュレートすべき自然楽器として管楽器が選
択されたときには、音高情報、息圧情報、アンブシュア
情報（吹奏時の唇などの動きの情報）、管内で起こる乱
気流（呼気ノイズ）量等であり、シミュレートすべき自
然楽器として弦楽器が選択されたときには、音高情報、
弦に対する弓の位置、弓圧、弓速度等である。

【００３１】なお、図中、白抜きの矢印は、パラメータ
が伝達されることを意味し、黒塗りの矢印は、演奏操作
情報が伝達されることを意味し、網掛けの矢印は、デジ
タル楽音信号が伝送されることを意味している。

【００３２】楽音合成アプリケーションは、励振信号を
発生させる励振部２４および励振信号を含む各種信号の
遅延およびループを行うことによって共鳴振動体（たと
えば、自然楽器の弦楽器や管楽器）をシミュレートする
共鳴振動体シミュレート部２５からなる物理モデル音源
部と、該物理モデル音源部によって生成された楽音信号
に必要に応じてエンベロープや各種効果を付与して出力
すべき楽音信号を合成する出力合成部２６とによって構
成されている。出力合成部２６は、合成された楽音信号
を記憶するための出力バッファを備えている。

【００３３】パラメータ設定供給部２２からの供給パラ
メータは、励振部２４、共鳴振動体シミュレート部２５
および出力合成部２６に供給される。励振部２４には、
演奏操作情報供給部２３からの演奏操作子情報も供給さ
れ、励振部２４は、これらの情報に基づいて励振信号を
生成し、共鳴振動体シミュレート部２５および出力合成
部２６に供給する。

【００３４】共鳴振動体シミュレート部２５は、励振部
２４からの励振信号を、供給パラメータに応じた遅延量
で遅延させるとともに、供給パラメータに応じた態様で
ループさせることにより、目的の自然楽器の発音メカニ
ズムをシミュレートして楽音信号を生成する。このよう
にして生成した楽音信号のうち、所定位置から検出した
楽音信号を励振部２４にフィードバックし、他の所定位
置から検出した楽音信号を出力合成部２６に供給する。

【００３５】出力合成部２６は、上述のようにして生成
された楽音信号に、前記供給されたパラメータ等に応じ
てエンベロープや各種効果を施して出力すべき楽音信号
を合成し、出力バッファに記憶する。出力バッファに記
憶された楽音信号は、所定のタイミングで読み出され
て、前記拡張Ｉ／Ｆ＆拡張バス１５を介してＤＡＣ１２
に送出され、前記ＣＯＤＥＣのバッファに記憶される。

【００３６】出力合成部２６から出力された楽音信号
は、楽音合成管理部にも供給される。楽音合成管理部
は、合成された楽音信号を管理するためのもので、楽音
信号を格納する出力バッファ２７と演奏操作情報供給部
２３からの演奏操作情報を格納する入力バッファ２８と
を備えている。本実施の形態では、この出力バッファ２
７および入力バッファ２８に格納されたデータを監視
し、該データが所定の条件を満たしたときに、楽音合成
アプリケーションのタスクを制御する。より具体的に
は、物理モデル音源部での楽音生成処理を停止する。

【００３７】なお、出力バッファ２７および入力バッフ
ァ２８は、前記ＲＡＭ５上に確保され、いわゆるリング
バッファとして動作するように構成されている。出力バ
ッファ２７および入力バッファ２８としての領域の確保
は、図５を用いて後述するメインルーチンを起動したと
きの初期化処理で行うようにすればよい。もちろん、こ
れに限らず、音源関連ソフトウェアを起動するときや、
演奏を開始するときなど、出力バッファ２７および入力
バッファ２８を必要とするときに領域の確保を行うよう
にしてもよい。

【００３８】また、本実施の形態では、楽音合成管理部
によってソフトウェアアプリケーション（楽音合成アプ
リケーション）のタスク制御を行うため、楽音合成管理
部は、ＯＳ内のシステム管理部の機能の一部を使用する
ようにしている。すなわち、楽音合成管理部は、アプリ
ケーションプログラムというよりは、ドライバに近いプ
ログラムである。もちろん、これに限らず、アプリケー
ションプログラムとして構成してもよいし、ＯＳが提供
する機能のみを用いて構成するようにしてもよい。

【００３９】図３は、入力（監視）バッファ２８および
出力（監視）バッファ２７を監視する方法を説明するた
めの図である。

【００４０】同図に示すように、入力バッファ２８およ
び出力バッファ２７はともに、複数個のバッファからな
り、図示例では、最新のデータがバッファの左端に位置
している。すなわち、バッファの右に位置するほど、デ
ータはより古いことになる。

【００４１】入力バッファ２８（たとえばｎ個ある）の
うちの１つのバッファで、領域ａ１が設けられているバ
ッファは、シミュレートすべき自然楽器としてリコーダ
（縦笛）が選択されたときに、前記演奏情報供給部２３
が供給した息圧情報が格納されたバッファである。出力
バッファ２７（たとえば２個ある）の１つのバッファ
で、領域Ａ１が設けられたバッファは、前記楽音合成部
２６が合成した楽音信号出力が格納されたバッファであ
る。そして、領域ａ１および領域Ａ１は、この領域の範
囲内のデータを監視することを示している。すなわち、
入力バッファ２８に対しては、その一部についてデータ
の監視を行い、出力バッファ２７に対しては、その全体
についてデータの監視を行う。このように、入力バッフ
ァ２８の一部に対してデータの監視を行うようにしたの
は、無音状態を判断するにはそれで十分だからである。
また、１点でなくある領域に対してデータの監視を行う
ようにしたのは、息圧情報が供給されてから、対応する
楽音信号が出力バッファ２７に格納されるまでに時間遅
れがあるからである。さらに、出力バッファ２７の全体
に対してデータの監視を行うようにしたのは、合成され
る楽音信号の周期を考慮していないために、どの範囲の
領域を監視すればよいかが分からないからである。した
がって、合成される楽音信号の周期の最大値が分かれ
ば、その周期分の領域を監視すればよい。以上のよう
に、合成する楽音の音色、音高（周期）に応じて、バッ
ファの数や長さ、監視領域などを制御する場合は楽音の
発生状態の監視精度の向上が期待できる。

【００４２】図４は、出力バッファ２７に対しても、デ
ータを監視する領域を設けるようにした例を示す図であ
り、（ａ）は、その監視領域を設けた１つの出力バッフ
ァを示し、（ｂ）は、（ａ）の出力バッファに格納され
る各種波形を示している。

【００４３】（ｂ）において、斜線領域は、合成される
楽音信号がこの領域内にすべて含まれることを示してい
る。このため、（ａ）に示すように、この領域に相当す
る周期Ｔｐ分の領域Ａ１に対して、出力バッファ２７を
監視するだけで、無音状態を正確に判定することができ
る。

【００４４】なお、図４の例では、発音の可能性のある
楽音の周期の最大値に応じてバッファの領域を決定する
ようにしたが、これに限らず、発音の可能性のある楽音
のうち特定のもの、または、条件（「低い音３つまでの
平均値」、「最低音と最高音の和」等）に基づいて選択
されたものに応じてバッファ領域を決定するようにして
もよい。また、簡単化のためにバッファ長、監視領域等
を所定のものに固定してもよい。

【００４５】図３に戻り、入力バッファ２８の２つのバ
ッファのうち、領域ｂ１が設けられているバッファは、
シミュレートすべき自然楽器としてバイオリンが選択さ
れたときに、演奏情報供給部２３が供給した弓速度が格
納されたバッファであり、領域ｂ２が設けられているバ
ッファは、演奏情報供給部２３が供給した弓圧力が格納
されたバッファである。そして、出力バッファ２７の２
つのバッファのうち、領域Ｂ１が設けられたバッファ
は、前記楽音合成部２６が合成した２つの楽音信号出力
のうちの一方が格納されたバッファであり、領域Ｂ２が
設けられたバッファは、他方の楽音信号出力が格納され
たバッファである。

【００４６】ここで、領域ｂ１および領域ｂ２がとも
に、入力バッファ２８の中間の一部に設けられているの
は、バイオリンの場合には、楽音の合成までに、前記リ
コーダの場合よりも長い時間遅れが生じるために、最新
の入力データまで監視する必要がないからである。ま
た、領域ｂ２が領域ｂ１を含むように設けられているの
は、バイオリン演奏において多くの場合は、弓圧が発生
した後に弓速度が発生するからである。また、出力バッ
ファ２７の全体に対してデータの監視を行うようにした
のは、リコーダの場合と同様の理由からであり、図４で
説明したように、出力バッファ２７に対してもその一部
を監視するようにしてもよい。

【００４７】本実施の形態では、データの監視は、入力
バッファ２８および出力バッファ２７ともに、真にデー
タが入力されていない状態（データ値が“０”）か否か
を判断することによって行っている。

【００４８】もちろん、監視方法はこれに限らず、バッ
ファ内またはバッファ内所定領域内で、データ値が
“０”でないデータがあるか否かを監視し、１つでも
“０”でないデータが検出されたときに、有音状態と判
定するようにしてもよいし、データ値が“０”でない個
数を検出し、この個数が所定値より多いときに、有音状
態と判定するようにしてもよい。また、各データのレベ
ルを検出し、所定の閾値を超えるデータがあったとき
に、有音状態と判定するようにしてもよい。さらに、各
データの平均値（実効値）、その絶対値の累算値（積分
値）等を算出し、所定の閾値を超えるときに、有音状態
と判定するようにしてもよい。また、対象となる波形の
所定の周波数成分に対してのみ上記判定を行うようにし
てもよい。特定の周波数成分を決定する手法としては、
たとえば、ＦＦＴ（Fast Fourier Transformation）に
よる分析を行い、その分析結果であるスペクトルやその
パワーで決定するようにすればよい。さらに別の手法と
しては、楽音のピッチを検出して、基本波や倍音の含有
量を算出し、その算出結果に基づいて決定するようにし
てもよい。

【００４９】なお、本実施の形態では、楽音合成管理部
内の出力バッファ２７を監視するようにしたが、これに
限らず、前記出力合成部２６内の出力バッファを監視す
るようにしてもよいし、前記ＣＯＤＥＣ内のバッファを
監視するようにしてもよい。また、物理モデル音源で
は、必ず遅延演算処理がなされるため、この遅延後の信
号を直接監視して、出力バッファを省略するようにして
もよい。

【００５０】また、励振部２４や共鳴振動体シミュレー
ト部２５内の（楽音）信号を監視するようにしてもよ
い。さらに、複数箇所の信号を監視し、所定の判断基準
で楽音信号（発生）の有無を判断するようにしてもよ
い。

【００５１】図５は、本実施の形態の音源システム、特
に前記ＣＰＵ３が実行するメインルーチンの手順を示す
フローチャートである。

【００５２】同図において、本メインルーチンは、たと
えば電源スイッチ（図示せず）が押されたとき（システ
ムスタート時）に起動され、まず、ＲＯＭ４等に格納さ
れている初期化プログラムを実行し、この初期化プログ
ラムによって指定されるＯＳ等を、たとえば前記外部記
憶装置１０から読み出す等の初期化処理を実行する（ス
テップＳ１）。

【００５３】次に、前記読み出されたＯＳを起動する起
動処理を実行する（ステップＳ２）。この起動処理に
は、各種ドライバの起動処理、たとえば音源ドライバの
ロードおよび起動を行う起動処理が含まれる。

【００５４】続くステップＳ３では、各種タスクのうち
いずれかのタスクの指示等のタスク管理を行うタスク管
理処理（システムモニタ）を実行し、ステップＳ４で
は、このタスク管理処理で指示されたタスクに対応する
処理に処理を移行させるタスクセレクト処理を実行す
る。

【００５５】タスク管理処理では、次の３種類のタスク
のうちいずれかのタスクが指示され、タスクセレクト処
理では、該指示されたタスクに対応する処理が選択され
て移行される。

【００５６】１）ユーザインタフェースに関連するタス
ク２）アプリケーションに関連するタスク３）ドライバに関連するタスクここで、１）のユーザインタフェースに関連するタスク
とは、ユーザ（演奏者）が、たとえばディスプレイ９上
に表示されたアイコンを選択して、対応するアプリケー
ションソフトウェアを起動するタスク等をいう。

【００５７】前記ステップＳ４のタスクセレクト処理
で、１）の範疇のタスクが指示されたときには、そのタ
スクに対応する新規タスクを起動する起動操作処理を実
行した（ステップＳ５）後に、前記ステップＳ３に戻
る。

【００５８】また、ステップＳ４のタスクセレクト処理
で、２）の範疇のタスクが指示されたときには、そのタ
スクに対応するアプリケーションプログラムに処理を移
行させる。図示例では、２個のアプリケーションプログ
ラムが起動されており、指定されたタスクに応じていず
れかのアプリケーションプログラムが選択される。すな
わち、アプリケーション１が指定されたときには、自動
演奏プログラムに処理が移行し、該自動演奏プログラム
の手順に従って演奏情報が発生する（ステップＳ６）。
そして、アプリケーション２が指定されたときには、操
作演奏インターフェースプログラムに処理が移行し、こ
のとき、演奏者が演奏操作子を操作したときには、当該
操作子に対応する情報が入力される（ステップＳ７）。

【００５９】なお、アプリケーションプログラムの個数
は、“２”に限る必要はなく、ＯＳやＲＡＭ５の容量に
応じた個数のアプリケーションプログラムを起動でき
る。

【００６０】さらに、ステップＳ４のタスクセレクト処
理で、３）の範疇のタスクが指示されたときには、その
タスクに対応するドライバプログラムに処理を移行させ
る。図示例では、２個のドライバプログラムが起動され
ており、指定されたタスクに応じていずれかのドライバ
プログラムが選択される。すなわち、ドライバ１が指定
されたときには、物理モデル音源処理に処理が移行し、
該物理モデル音源プログラムの手順に従ってメロディ音
が生成される（ステップＳ８）。そして、ドライバ２が
指定されたときには、楽音波形合成処理に処理が移行
し、該楽音波形合成処理プログラム（この楽音波形合成
処理は、本実施の形態では、伴奏音を生成するための、
物理モデル音源以外のその他の音源処理、および該生成
された伴奏音にエフェクトを施すとともに、複数個の伴
奏音をミキシングするエフェクト付与＆ミキシング処理
から構成されている）の手順に従って伴奏音が生成され
る（ステップＳ９）。

【００６１】なお、ドライバプログラムの個数も、
“２”に限る必要はなく、ＯＳに応じた個数のアプリケ
ーションプログラムを起動できる。

【００６２】図６は、前記ステップＳ３のタスク管理処
理の詳細な手順を示すフローチャートである。

【００６３】同図において、まず、これから切り換える
べきタスクの指定および該タスクへ処理を移行させるタ
イミングを判定する（ステップＳ１１）。

【００６４】次に、物理モデル音源が音源ドライバとし
てロードされているか否かを判別し（ステップＳ１
２）、ロードされているときには、物理モデル音源処理
の実行タイミングであるか否かを判別する（ステップＳ
１３）。

【００６５】ステップＳ１３で、物理モデル音源処理の
実行タイミングのときには、選択されている音色に対応
する入力バッファ（群）内の信号状態をチェックし（ス
テップＳ１４）、次いで、出力バッファ（群）内の信号
状態をチェックする（ステップＳ１５）。このステップ
Ｓ１５において、信号状態のチェックは、出力バッファ
が少数個のみである場合にはすべての出力バッファに対
して行うようにし、出力バッファが多数個ある場合に
は、選択されている音色に対応する出力バッファのみに
対して行うようにすればよい。

【００６６】図７は、バッファ内の信号状態をチェック
する処理の詳細な手順を示すフローチャートであり、前
記ステップＳ１４およびＳ１５では、この処理がそれぞ
れ個別に実行される。

【００６７】図７において、監視対象バッファ（ステッ
プＳ１４では入力バッファであり、ステップＳ１５では
出力バッファである）内の信号のレベル値が所定値以下
であるか否かを判別し、信号レベル値が所定値以下のと
きには、「無信号」状態と判定し（ステップＳ２２）、
一方、信号レベル値が所定値より大きいときには、「信
号有り」状態と判定する（ステップＳ２３）。

【００６８】なお、監視対象バッファが複数個あるとき
には、監視対象バッファを切り換えながら、その個数分
上記処理を繰り返す。

【００６９】図６に戻り、ステップＳ１６では、チェッ
クした各バッファすべてが「無信号」状態であるか否か
を判別し、すべてが「無信号」状態のときには、物理モ
デル音源処理の実行を不許可に設定し（ステップＳ１
７）、一方、いずれかのバッファが「無信号」状態でな
いときには、物理モデル音源処理の実行を許可に設定す
る（ステップＳ１７）。これにより、「不許可」が設定
されたときには、前記ステップＳ１１で物理モデル音源
処理が指定されず、一方、「許可」が設定されたときに
は、ステップＳ１１で物理モデル音源処理が指定される
ようになる。

【００７０】一方、前記ステップＳ１２で、物理モデル
音源がロードされていないとき、または、前記ステップ
Ｓ１３で、物理モデル音源処理の実行タイミングでない
ときには、他のタスク管理処理を実行した（ステップＳ
１９）後に、本タスク管理処理を終了する。

【００７１】図８は、バッファ更新処理の手順を示すフ
ローチャートである。本処理は、前記タイマ２が所定時
間（たとえば、５ｍｓｅｃ）毎に発生するタイマ割込信
号に応じて起動され、実行される。

【００７２】同図において、まず、入力バッファを更新
すべきタイミングであるか否かを判別し（ステップＳ３
１）、更新すべきタイミングのときには、入力バッファ
の内容を更新する（ステップＳ３２）一方、更新すべき
タイミングでないときには、ステップＳ３２をスキップ
する。

【００７３】次に、出力バッファを更新すべきタイミン
グであるか否かを判別し（ステップＳ３３）、更新すべ
きタイミングのときには、出力バッファの内容を更新す
る（ステップＳ３４）一方、更新すべきタイミングでな
いときには、ステップＳ３４をスキップして、本バッフ
ァ更新処理を終了する。

【００７４】ステップＳ３２，Ｓ３４で、各入力／出力
バッファの更新は、更新すべき時点の信号（演奏操作情
報供給部２３からの演奏操作情報および出力合成部２６
からの楽音信号）をそのまま最新データとして格納する
ようにしてもよいし、この信号を加工した後最新データ
として格納するようにしてもよい。加工の方法は、たと
えば、絶対値や平均値をとったり、フィルタ演算を施し
たりする方法が考えられる。

【００７５】このように、本実施の形態では、合成され
た楽音信号の有無に加え、該楽音信号を合成する要求の
有無を監視し、両者が無いときに限って、すなわち真に
無音の状態であるときに限って、物理モデル音源処理の
実行を停止するようにしたので、演奏者の意図と異なら
ない範囲内で、ＣＰＵに対する演算負荷を低減化するこ
とができる。

【００７６】次に、他の実施の形態の音源システムを説
明する。

【００７７】本実施の形態の音源システムは、上述した
音源システムに対して、物理モデル音源処理の実行を停
止するか否かの判別を行う位置が異なるのみであるの
で、その相違点についてのみ説明する。

【００７８】すなわち、本実施の形態の音源システムと
前記実施の形態の音源システムとは、前記図５のメイン
ルーチン中、ステップＳ３のタスク管理処理およびステ
ップＳ８の物理モデル音源処理の一部が異なっている。
以下、まず物理モデル音源処理、次にタスク管理処理の
順序で、その相違点を説明する。

【００７９】図９は、本実施の形態の音源システムが実
行する物理モデル音源処理の詳細な手順を示すフローチ
ャートである。

【００８０】同図において、まず、物理モデル音源で合
成すべき音色が指定されているか否かを判別し（ステッ
プＳ４１）、当該音色が指定されていないときには、直
ちに本物理モデル音源処理を終了する一方、当該音色が
指定されているときには、ステップＳ４２に進む。

【００８１】ステップＳ４２〜Ｓ４４の各処理は、それ
ぞれ、前記図６で説明したステップＳ１４〜Ｓ１６と同
様であるので、その説明を省略する。

【００８２】ステップＳ４４で、チェックしたバッファ
のうちいずれかのバッファが「無信号」状態でないとき
には、物理モデル音源による楽音合成演算処理、すなわ
ち物理モデル音源アルゴリズム本体を実行する（ステッ
プＳ４５）一方、チェックした各バッファすべてが「無
信号」状態のときには、ステップＳ４５をスキップし
て、本物理モデル音源処理を終了する。

【００８３】このように、真に無音の状態の監視を、物
理モデル音源処理内で行うようにしたので、タスク管理
処理では、この監視を行う必要がない。したがって、本
実施の形態のタスク管理処理は、図６のタスク管理処理
からこの監視処理を省略したものを使用すればよい。具
体的には、図６のステップＳ１４〜Ｓ１７を省略する。

【００８４】本実施の形態においても、前記実施の形態
と同様に、合成された楽音信号の有無に加え、該楽音信
号を合成する要求の有無を監視し、両者が無いときに限
って、物理モデル音源処理の実行を停止するようにした
ので、演奏者の意図と異ならない範囲内で、ＣＰＵに対
する演算負荷を低減化することができる。

【００８５】なお、両実施の形態では、物理モデル音源
を例に挙げて説明したが、本発明は、合成要求に対して
楽音信号の合成が遅延するすべての音源に対して有効で
あるため、この種の音源であれば、物理モデル音源に限
る必要はない。現時点では、本発明は、特に物理モデル
音源に有効であるというに過ぎない。このように、本発
明を適用可能な音源が複数個起動されて楽音が合成され
ている場合には、各音源毎に、前述した無音状態の監視
を行うようにすればよい。

【００８６】また、無音状態の監視は、両実施の形態で
は、入力信号（演奏操作情報）と出力信号（楽音信号）
とを個別に監視するようにしたが、これに限らず、各信
号を何らかの演算等によって結合した結果を監視するよ
うにしてもよい。さらに、本発明を適用可能な音源が複
数個起動されて楽音が合成されている場合には、発音チ
ャンネルまたはそのグループ毎に監視したり、各チャン
ネルに対する入出力信号を結合した結果を監視するよう
にしてもよい。

【００８７】なお、監視するバッファ長や範囲は、両実
施の形態では、固定（出力バッファのバッファ長を変更
する例は、図４に示されている）にしたが、これに限ら
ず、音色、音色グループ（楽器の種類）、音高周期Ｔｐ
等に応じて変更するようにしてもよい。

【００８８】また、発音音高に応じてバッファ内の監視
範囲を加減制御するようにしてもよい。たとえば、音高
の高い、すなわち周期が短くなるに従って監視範囲を短
くなるようにする。これにより、無音状態の判定精度を
向上させることができるとともに、監視処理に対するＣ
ＰＵの負荷を軽減させることができる。

【００８９】さらに、監視バッファの位置と監視する信
号の種類との対応、各バッファの容量、監視範囲等を設
定できるようにしたり、その設定値を音色パラメータと
して記憶できるようにしたりしてもよい。

【００９０】また、両実施の形態では、汎用コンピュー
タによって本発明を実現した例を説明したが、その実現
態様は、これに限らず、たとえば、電子楽器、アミュー
ズメント機器（ゲームやカラオケが典型例）、各種家電
機器等、ソフト音源を実行可能なものであれば、どのよ
うなものであってもよい。

【００９１】なお、上述した両実施の形態の機能を実現
するソフトウェアのプログラムを記録した記憶媒体を、
システムまたは装置に供給し、そのシステムまたは装置
のコンピュータ（またはＣＰＵ３やＭＰＵ）が記憶媒体
に格納されたプログラムを読出し実行することによって
も、本発明の目的が達成されることは云うまでもない。

【００９２】この場合、記憶媒体から読出されたプログ
ラム自体が本発明の新規な機能を実現することになり、
そのプログラムを記憶した記憶媒体は本発明を構成する
ことになる。

【００９３】プログラムを供給するための記憶媒体とし
ては、たとえば、ハードディスク、ＣＤ−ＲＯＭ，Ｍ
Ｏ，ＭＤ，フロッピーディスク、ＣＤ−Ｒ（CD- Record
able）、磁気テープ、不揮発性のメモリカード、ＲＯＭ
などを用いることができる。また、他のＭＩＤＩ機器１
００や通信ネットワーク１０１を介してサーバコンピュ
ータ１０２からプログラムが供給されるようにしてもよ
い。

【００９４】また、コンピュータが読出したプログラム
を実行することにより、上述した各実施の形態の機能が
実現されるだけでなく、そのプログラムの指示に基づ
き、コンピュータ上で稼働しているＯＳなどが実際の処
理の一部または全部を行い、その処理によって上述した
実施の形態の機能が実現される場合も含まれることは云
うまでもない。

【００９５】さらに、記憶媒体から読出されたプログラ
ムが、コンピュータに挿入された機能拡張ボードやコン
ピュータに接続された機能拡張ユニットに備わるメモリ
に書込まれた後、そのプログラムの指示に基づき、その
機能拡張ボードや機能拡張ユニットに備わるＣＰＵ３な
どが実際の処理の一部または全部を行い、その処理によ
って上述した各実施の形態の機能が実現される場合も含
まれることは云うまでもない。

【００９６】

【発明の効果】以上説明したように、本発明によれば、
第１の監視モジュールによって楽音信号の発生要求がな
されていないことが検出され、かつ、第２の監視モジュ
ールによって楽音信号が生成されていないことが検出さ
れたときに、楽音生成モジュールの実行が停止するの
で、真に無音の状態が検出されたときにのみ、楽音生成
モジュールの実行が停止し、これにより、演奏者の意図
と異ならない範囲内で、ＣＰＵに対する演算負荷を低減
化することが可能となる効果を奏する。

【００９７】また、好ましくは、前記第１の監視モジュ
ールによる監視のタイミングと前記第２の監視モジュー
ルによる監視のタイミングとの間に、前記楽音合成モジ
ュール内の遅延量に応じた時間差を設けるようにしたの
で、無音の状態の検出精度をより向上させることができ
る。

【００９８】さらに、好ましくは、前記楽音生成モジュ
ールによって生成される楽音信号の特性に応じて前記第
１および第２の監視モジュールにおける監視の条件を変
更するようにしたので、無音の状態の検出精度をさらに
向上させることができる。

【図面の簡単な説明】

【図１】本発明の一実施の形態に係る音源システムを実
現するハードウェアの概略構成を示す図である。

【図２】図１の音源システムの機能を視覚的に表した図
である。

【図３】図２の入力（監視）バッファおよび出力（監
視）バッファを監視する方法を説明するための図であ
る。

【図４】図３の出力バッファに対しても、データを監視
する領域を設けるようにした例を示す図である。

【図５】図１の音源システムが実行するメインルーチン
の手順を示すフローチャートである。

【図６】図５のタスク管理処理の詳細な手順を示すフロ
ーチャートである。

【図７】バッファ内の信号状態をチェックする処理の詳
細な手順を示すフローチャートである。

【図８】バッファ更新処理の手順を示すフローチャート
である。

【図９】他の実施の形態の音源システムが実行する物理
モデル音源処理の詳細な手順を示すフローチャートであ
る。

【符号の説明】

２タイマ３ＣＰＵ４ＲＯＭ５ＲＡＭ７演奏操作子８設定操作子１０外部記憶装置

───────────────────────────────────────────────────── フロントページの続き (58)調査した分野(Int.Cl.⁷，ＤＢ名) G10H 1/02 G10H 1/18 101 G10H 7/08

Claims

(57)【特許請求の範囲】

【請求項１】楽音信号の発生要求に応じて励振信号を
発生するとともに、該発生した励振信号を少なくとも遅
延およびループさせることにより楽音信号を生成する楽
音生成モジュールと、前記楽音信号の発生要求の有無を監視する第１の監視モ
ジュールと、前記楽音生成モジュールによって生成された楽音信号の
有無を監視する第２の監視モジュールと、前記第１の監視モジュールによって楽音信号の発生要求
がなされていないことが検出され、かつ、前記第２の監
視モジュールによって楽音信号が生成されていないこと
が検出されたときに、前記楽音生成モジュールの実行を
停止する停止モジュールとを有するコンピュータソフト
ウェアを用いた音源システムであって、前記第１の監視モジュールによる監視のタイミングと前
記第２の監視モジュールによる監視のタイミングとの間
に、前記楽音生成モジュール内の遅延量に応じた時間差
を設けることを特徴とするコンピュータソフトウェアを
用いた音源システム。
【請求項２】楽音信号の発生要求に応じて励振信号を
発生するとともに、該発生した励振信号を少なくとも遅
延およびループさせることにより楽音信号を生成する楽
音生成モジュールと、前記励振信号の有無を監視する第１の監視モジュール
と、前記楽音生成モジュールによって生成された楽音信号の
有無を監視する第２の監視モジュールと、前記第１の監視モジュールによって励振信号が発生され
ていないことが検出され、かつ、前記第２の監視モジュ
ールによって楽音信号が生成されていないことが検出さ
れたときに、前記楽音生成モジュールの実行を停止する
停止モジュールとを有することを特徴とするコンピュー
タソフトウェアを用いた音源システム。
【請求項３】前記楽音生成モジュールによって生成さ
れる楽音信号の特性に応じて前記第１および第２の監視
モジュールにおける監視の条件を変更することを特徴と
する請求項１または２のいずれかに記載のコンピュータ
ソフトウェアを用いた音源システム。
【請求項４】楽音信号の発生要求に応じて励振信号を
発生するとともに、該発生した励振信号を少なくとも遅
延およびループさせることにより楽音信号を生成する楽
音生成モジュールと、前記励振信号の有無を監視する第１の監視モジュール
と、前記楽音生成モジュールによって生成された楽音信号の
有無を監視する第２の監視モジュールと、前記第１の監視モジュールによって励振信号が発生され
ていないことが検出され、かつ、前記第２の監視モジュ
ールによって楽音信号が生成されていないことが検出さ
れたときに、前記楽音生成モジュールの実行を停止する
停止モジュールとを含む、コンピュータが実現できるプ
ログラムを格納した記憶媒体。