以下、図面を用いてこの発明の実施の形態を説明する。
図1は、この発明の一実施形態であるディジタルミキサのエンジンの構成を示す。このエンジン100は、中央処理装置(CPU)101、フラッシュメモリ102、RAM(ランダム・アクセス・メモリ)103、PC入出力インターフェース(I/O)104、MIDI I/O105、その他I/O106、表示器107、操作子108、波形I/O109、信号処理部(DSP群)110、カスケードI/O111、およびシステムバス120を備える。
中央処理装置(CPU)101は、このミキサ全体の動作を制御する処理装置である。フラッシュメモリ102は、CPU101や信号処理部110のDSPなどが使用する各種のプログラムやデータを格納した不揮発性メモリである。RAM103は、CPU101が実行するプログラムのロード領域やワーク領域に使用する揮発性メモリである。PC I/O104は、外部のパーソナルコンピュータ(以下、PCと言う)130を接続するインターフェース(例えば、LAN、USB、シリアルI/Oなど)である。MIDI I/O105は、各種MIDI機器を接続するインターフェースである。その他I/O106は、その他の機器を接続するためのインタフェースである。表示器107は、このミキサの外部パネル上に設けられた各種の情報を表示するためのディスプレイである。操作子108は、外部パネル上に設けられたユーザが操作するための各種の操作子である。波形I/O109は、外部機器との間で音響信号をやり取りするためのインターフェースであり、例えば、アナログの音響信号を入力してディジタル信号に変換して信号処理部110に渡すA/D(アナログ・ディジタル)変換機能、ディジタルの音響信号を入力して信号処理部110に渡すディジタル信号入力機能、および信号処理部110から出力されたディジタルの音響信号をアナログの音響信号に変換してサウンドシステムに出力するD/A(ディジタル・アナログ)変換機能などを実現する。信号処理部110は、幾つかのDSP(ディジタル・シグナル・プロセッサ)などからなる。これらのDSPは、CPU101の指示に基づいて各種のマイクロプログラムを実行することにより、波形I/O109経由で入力した波形信号のミキシング処理、効果付与処理、および音量レベル制御処理などを行ない、処理後の波形信号を波形I/O109経由で出力する。カスケードI/O111は、他のディジタルミキサとカスケード接続するためのインターフェースである。カスケード接続することにより、入出力チャンネル数やDSP処理力を増やすことができる。
本ディジタルミキサのエンジン100では、信号処理部110で実現するミキサ構成をカスタムメイドすることができる。そのミキサ構成は、PC130上で動作する所定のミキサ制御プログラム131によりPC130の画面上で作成編集することができる。作成したミキサ構成をコンフィグレーション(PC上での実体はCFデータである)と呼ぶ。ミキサ制御プログラム131は、ユーザの画面上での操作指示に応じて、コンフィグレーションをメモリ上にコンフィグ(CF)データ132として生成する。CFデータ132は、PC130から書き込み可能な任意の記憶装置にファイルとして保存できる。また、PC130側のメモリまたは記憶装置上のCFデータは(コンパイル(後述)した後)エンジン100に転送できる。エンジン100は、PC130から転送されたCFデータをフラッシュメモリ102に格納して保存しておくことができる。所定の操作によりフラッシュメモリ102に格納されたCFデータをRAM103上のカレントメモリ(後述する)に読み出し、あるいはPC130から転送されたCFデータを直接カレントメモリに展開し、カレントメモリ上のCFデータに基づいてエンジン100を動作させることにより、当該CFデータで定義されるミキサ構成のミキサが実現する。
なお、PC130によりCFデータを作成編集するユーザは、エンドユーザに限らず、業者の場合もある。例えば、ある会場にミキサが設置された場合、その会場に業者が出向いて、そのミキサにPC130を接続し、当該PC130からその会場に合わせたミキサ構成のCFデータを作成編集し、そのCFデータをフラッシュメモリ102に格納する。この場合、ミキサはノンプログラマブル(エンドユーザに対してミキサ構成の作成編集を許可せず、エンドユーザは業者が作り込んだミキサ構成を呼び出して利用するだけ)でもよい。エンドユーザは、パネル上の操作子108を用いてフラッシュメモリ102に格納されたCFデータを読み出し、そのCFデータで定義されたミキサ構成のミキサとして動作させることができるので、動作時にPC130を接続する必要はない。もちろん、PC130を接続し、そのPC130からの操作でミキサを制御することは可能である(後述する実行モード)。
図2(a)は、ミキサ制御プログラム131によりPC130上でCFデータ132を作成編集しているときの画面(コンフィグレーション画面と呼ぶ)例200を示す。211は入力コンポーネント、212はCコンポーネントUser All Mix、213はPコンポーネントMatrix #1、214は出力コンポーネントを示す。Pコンポーネントは、コンフィグレーションを構成する基本単位部品ブロックであり、例えば、ミキサ、コンプレッサ、エフェクト、クロスオーバなどのオーディオプロセッサや、フェーダ、スイッチ、パン、メータなどの個々のパーツのコンポーネントが用意されている。C(カスタム)コンポーネントは、ユーザが作成編集したコンポーネントであり、複数のPコンポーネントあるいはCコンポーネントから構成される。ユーザは、所定の操作で、選択可能な複数のPコンポーネントまたはCコンポーネントから任意にコンポーネントを選択し、図2(a)のように画面上に配置することができる。またユーザは、所定の操作により、各コンポーネントの端子間に結線(例えば221)を引くことができる。結線を引くことは、コンポーネント間の信号の入出力関係を定義することに相当する。このようにして完成したCFデータ132は、ハードディスクなどに保存することができ、またコンパイル(CFデータをエンジン100が解釈できる情報に変換すること)した後、PC130からPC I/O104を介してエンジン100側に転送することができる。メモリカードなどの着脱可能な記憶媒体によりエンジン100側に読み取らせてもよい。
ミキサ制御プログラム131は、操作モードとして編集モードと実行モードを有する。所定の操作により、編集モードと実行モードとを切り換えることができる。編集モードは、CFデータを作成編集するモードである。実行モードは、PC130のミキサ制御プログラム131からエンジン100をリアルタイムに制御するモードである。例えば、コンフィグレーション画面上に表示されたミキサ構成中にフェーダを備えたコンポーネントが存在する場合、実行モードでは、そのフェーダをマウスを用いて操作するとその操作はリアルタイムにエンジン100に反映される。実行モードでは、コンポーネントの構成と結線は変更できない。実行モードは、PC130側でカレントメモリに呼び出されているコンフィグレーション(コンフィグレーション画面に表示されている)とエンジン100側でカレントメモリに呼び出されているコンフィグレーションとが一致しているときのみ選択できる。
図2(b)は、Pコンポーネントのパラメータ設定画面の例を示す。図2(a)のコンフィグレーション画面で任意のPコンポーネントをダブルクリックすることにより当該Pコンポーネントのパラメータ設定画面が開く。パラメータ設定画面により、そのPコンポーネントの各種のパラメータ項目の値(数値だけでなくオン/オフなども含む)を設定できる。図2(b)では一例として、HPF(ハイパスフィルタ)のPコンポーネントのパラメータ設定画面を図示した。Pコンポーネントの種類が異なれば、そのコンポーネントで設定可能なパラメータ項目も異なるので、パラメータ設定画面はPコンポーネントの種類毎にある。パラメータ設定画面でPコンポーネントのパラメータ値を変更すると、実行モードのときは、その変更がリアルタイムにエンジン100に反映され、編集モードのときは、オフライン編集(エンジン100には反映されず、PC130内のデータのみ変更される)となる。各パラメータ項目の現在設定値をカレント値と呼ぶ。新たにPコンポーネントを選択してコンフィグレーション画面に配置したときには、そのコンポーネントのカレント値としてデフォルト値が設定されるものとする。
図2(a)のコンフィグレーション画面でCコンポーネントをダブルクリックすることにより当該Cコンポーネントの作成編集画面が開く。図3に、図2(a)のCコンポーネント212をダブルクリックしたときに表示されるCコンポーネント作成編集画面の例300を示す。ユーザは、この画面300で、図2(a)でミキサ構成を作成編集するのと同様にして、Cコンポーネントを作成編集することができる。作成編集したCコンポーネントは、任意に名前をつけて、Cコンポーネント(PC上での実体は後述するCCデータである)として保存することができる。保存したCコンポーネントは、図2(a)のコンフィグレーション画面や図3のCコンポーネント作成編集画面で呼び出して利用できる。Cコンポーネントの構成要素として、自分自身以外の他のCコンポーネントを利用することもできる。図3中、311はCコンポーネントの構成要素として利用している別のCコンポーネントの例である。これ以降の図は省略するが、Cコンポーネント311をダブルクリックすることにより、このCコンポーネントの作成編集画面が表示され任意にカスタマイズすることができる。
図4(a)は、PC130のミキサ制御プログラム131が使用するPコンポーネントデータ(PCデータ)の構成を示す。PCデータは、Pコンポーネントを規定する定義データであり、ミキサ制御プログラム131がアクセスできる任意の記憶手段に予め格納されている。PCデータは、Pコンポーネントの種類毎に用意される。ここでは種類がNpc個あるものとする。1つのPCデータは、PCヘッダ、PC構成情報、PC処理ルーチン、表示・編集処理ルーチン、およびライブラリからなる。PCヘッダは、PコンポーネントID(PC_ID)およびPコンポーネントバージョン(PC_Ver)などからなる。PC_IDとPC_Verにより、PCデータを特定することができる。
PC構成情報は、そのPコンポーネントがどのようなエレメントから構成されているかを示す情報であり、そのPコンポーネントのパラメータ設定画面などの表示データを含む。エレメントは、Pコンポーネントを構成する部品(例えば、パラメータ設定画面の構成要素)に相当する。具体的には、PC構成情報は、エレメントの順番(エレメントの有無も含む)や、当該エレメントのパラメータが、単一の値、1次元配列、2次元配列のどのデータ形式であるかの情報を含む。ただし、エレメントのデータ形式が1次元配列や2次元配列である場合、その要素数は含まない。要素数は、CFデータの構成要素としてPコンポーネントが利用される際に、そのPCデータのプロパティで決定されるものである。PC処理ルーチンは、PC構成情報に関する各種の処理を行なうためのプログラムである。ミキサ制御プログラム131がCFデータを処理する際には、コンポーネント毎のPC処理ルーチンを利用する。表示・編集処理ルーチンは、CFデータを作成編集する際に用いるプログラム群である。ライブラリについては、後述する。
図4(b)は、PC130のミキサ制御プログラム131が使用するCコンポーネントデータ(CCデータ)の構成を示す。CCデータは、Cコンポーネントを規定する定義データである。1つのCCデータは、CCヘッダ、PC用CADデータ、およびライブラリからなる。CCヘッダは、CコンポーネントID(CC_ID)、Cコンポーネントバージョン(CC_Ver)、およびシステムバージョン(SYS_Ver)などからなる。CC_IDとCC_Verにより、CCデータを特定することができる。
PC用CADデータは、当該Cコンポーネントがどのようなコンポーネントをどのように結線して構成したものかを定義するデータである。PC用CADデータは、当該Cコンポーネントの構成要素として使用するPコンポーネントやCコンポーネントを指定するデータであるCデータ、およびそれらのコンポーネント間を結ぶ結線データからなる。Cコンポーネントの構成要素として自分以外の他のCコンポーネントを利用することができるので、CCデータ中のPC用CADデータの中に、他のCCデータを指定するCデータを含めることができる。例えば図4(b)のCCデータ2のPC用CADデータにおいて、CデータDAとCデータDBはそれぞれPCデータDAとPCデータDBを指定するCデータであるが、CデータDCはCCデータDCを指定するCデータであるものとする。なお、PC用CADデータの構成は、図4(c)で後述するCFデータのPC用CADデータと同様であるので、これ以上の説明は省略する。特に、Cデータがどのようなデータから構成されるかについては、後述のCFデータの説明で代替する。
このようなCコンポーネントデータは、所定の権限を持つユーザが任意に図3のような画面で作成編集できる。従って、図4(b)に示す各CCデータは、それぞれファイルとして所定の記憶装置に記憶することができる。また、図3に示したようなCコンポーネント作成編集画面を表示して作成編集する場合、作成編集対象のCCデータはカレントメモリ上に展開されるものである。Cコンポーネントのカレントメモリ上のデータ構成は、図4(c)や図5(c)で後述するCFデータのカレントメモリ上の構成と同様であり、CCヘッダおよびPC用CADデータなどがカレントメモリ上に展開されて編集されるものである。従って、CCデータのPC用CADデータは、Cコンポーネント作成編集画面を表示するための表示データを含む。また、Cコンポーネントのカレントメモリ上には、作成編集対象のCCデータのパラメータ現在値であるカレントのコンポーネントシーンデータを格納する領域が設けられている。カレントコンポーネントシーンデータの構成は、図5(a)で後述するCCシーンと同様であり、作成編集対象のCCデータに対応するCCシーンがPCシーンに展開されているものである。
図4(c)は、PC130において、ミキサ制御プログラム131によって作成され保存されたCFデータの構成を示す。各CFデータ1〜Ncfは、それぞれ、1つのミキサ構成を規定するCFデータである。各CFデータは、それぞれ1ファイルとして任意の記憶装置(例えば、PC内のハードディスクなど)に格納できる。ここでは、CFファイル1、CFファイル2、…と並べて図示したが、各ファイルは、PC130上のファイルシステムで独立してコピーや移動ができる単位である。「CFファイル」というときは、ハードディスクなどに保存されたCFデータを指すものとする。単に、「CFデータ」と言うときは、どのような形態で記憶されているかを問わず、図示した内容のデータからなる1つのミキサ構成を定義するデータを指すものとする。
図4(c)に示すように、1つのCFデータは、CFヘッダ、PC用CADデータ、およびNs個のシーンデータからなる。CFヘッダは、コンフィグID(CF_ID)、コンフィグバージョン(CF_Ver)、およびシステムバージョン(SYS_Ver)などからなる。PC用CADデータは、当該CFデータのミキサ構成がどのようなコンポーネントをどのように結線して構成したものかを定義するデータであり、図2(a)で説明したコンフィグレーション画面を表示するための表示データを含む。PC用CADデータは、そのコンフィグレーションの構成要素として使用するPコンポーネントやCコンポーネントを指定するデータであるCデータ、およびそれらのコンポーネント間を結ぶ結線データからなる。
Cデータは、PコンポーネントまたはCコンポーネントを指定するIDとバージョン、ユニークID(U_ID)、およびその他のデータ(例えば、プロパティなど)などからなる。IDとバージョンは、Pコンポーネントを指定する場合はPコンポーネントID(PC_ID)とPコンポーネントバージョン(PC_Ver)であり、Cコンポーネントを指定する場合はCコンポーネントID(CC_ID)とCコンポーネントバージョン(CC_Ver)である。なお、これらのIDは、それがPC_IDがCC_IDかを区別できるように(例えば、PC_IDとして使用する範囲とCC_IDとして使用する範囲を分ける)構成されているものとする。以下、図4(c)のCFデータ2のPC用CADデータでは、CデータA〜Cの3つはそれぞれPCデータA〜Cを指定し、CデータDはCCデータDを指定しているものとして説明する。従って、このCFデータのミキサ構成は3つのPコンポーネント、1つのCコンポーネント、および結線データから構成されている。なお、上述のCデータの構成は、図4(b)で説明したCCデータ中のCADデータのCデータでも同様である。図4(b)のCCデータのCコンポーネント構成は、2つのPコンポーネント、1つのCコンポーネント、および結線データから構成されている。
図4(c)のCFデータ中のシーンデータ(図のシーン1、シーン2、…、シーンNsの1つ1つがシーンデータである)について説明する。シーンとは、1つのコンフィグレーションを構成するすべてのコンポーネントのパラメータ(図2(b)で説明したパラメータ設定画面でその値を設定する)の組であり、そのデータ構成は、PC用CADデータの各CデータのID(PC_IDまたはCC_ID)とバージョン(PC_VerまたはCC_Ver)で指定された図4(a)のPCデータまたは図4(b)のCCデータ、および、同Cデータ中のプロパティに基づいて決められている。シーンデータは、1つのシーンを定義するデータ、すなわち当該コンフィグレーションの各コンポーネントが動作する際に使用する具体的なパラメータ値のデータセットである。PC130側で、現在(PC130内の)カレントメモリ上にあるパラメータ設定画面等の各種画面での編集対象となるシーンデータをカレントシーンと呼ぶ。エンジン100側も同様に、現在(エンジン100内の)カレントメモリ上にある信号処理部100における処理で使用中のシーンデータをカレントシーンと呼ぶ。同じミキサ構成でも、場面に応じてそのミキサ構成におけるパラメータを変更したい場合があるので、1つのCFデータ中に複数シーン分のシーンデータを含めることができるようになっている。シーンはシーン番号nで特定してシーンnと呼ぶものとし、図中のシーン1、シーン2、…、シーンNsのn=1,2,…,Nsがシーン番号である。シーンnへのストア(保存)が指示されたとき、カレントシーンがその指定されたシーンnのシーンデータ記憶領域へ保存され、シーンnからのリコール(呼出)が指示されたとき、シーンnのシーンデータ記憶領域から読み出されたシーンデータがカレントシーンへ呼び出される(書き込まれる)。
シーンデータは、各コンポーネントのパラメータ値を示すコンポーネントシーン(Pコンポーネントに対応するコンポーネントシーンをPCシーンと呼び、Cコンポーネントに対応するコンポーネントシーンをCCシーンと呼ぶ)の並びからなる。この並びの順序は、PC用CADデータ中のCデータの並びと対応している。図では、CデータAで指定されるPコンポーネントであるPCデータAのパラメータがPCシーン3A、CデータBで指定されるPコンポーネントであるPCデータBのパラメータがPCシーン3B、…、CデータDで指定されるCコンポーネントであるCCデータDのパラメータがCCシーン3Dである。カレントメモリに記憶されているカレントシーンや各シーンのシーンデータは、上述したようなPC用CADデータで規定されるデータ構成を有している。
図5(a)は、図4(c)のシーンデータの詳細な構成を示す。図5(a)のコンポーネントシーンは図4(c)のコンポーネントシーンに対応する。1つのPCシーンは、それに対応する1つのPコンポーネントを構成する各エレメントに設定するパラメータの並び(エレメントシーン)からなる。エレメントシーンの並びは、そのPコンポーネントのPC構成情報(図4(a))が示すエレメントの並びに対応するものとなっている。例えば図5(a)のエレメントシーンE3B1は、PCシーン3BのPコンポーネントを構成する第1番目のエレメントのパラメータを示す。ここではPCシーン3Bのコンポーネントは4つのエレメントからなるので、エレメントシーンも4つある。各エレメントシーンは、単一の値、1次元配列、または2次元配列の何れかのデータ形式を取る。例えば、エレメントシーンE3B1やE3B4は単一のパラメータ値からなるエレメントシーンである。E3B2は、要素数が8の1次元配列からなる。E3B3は、2次元配列のデータ形式を持つエレメントシーンである。
1つのエレメントシーンは、そのデータ形式に応じた幾つかのパラメータ値(パラメータシーン)からなる。同種のPコンポーネントであれば、それらのPコンポーネントのエレメント構成(順序も含める)は常に同じであり、従って、それらPコンポーネントに対応するPCシーン内のエレメントシーンの並びの順序も同じである。ただし、同種のPコンポーネントでも設定されたパラメータに応じてエレメントシーンの1次元配列または2次元配列の要素数は変化するので、エレメントシーンのデータ長が変わることはある。エレメントシーンが1次元配列または2次元配列である場合の要素数は、そのエレメントを含むコンポーネントを指定するCデータのプロパティ(図4(c))に格納されている。
1つのCCシーンは、それに対応するCコンポーネントを構成する各コンポーネントのコンポーネントシーンの並びからなる。その並びは、そのCコンポーネントのPC用CADデータ(図4(b))が示すコンポーネントの並びに対応するものとなっている。例えば図5(a)のCCシーン3Dは、図4(c)のCデータDで指定するCコンポーネントである図4(b)のCCデータ2のコンポーネントシーンデータであるが、そのCCデータ2はCデータDAで指定するPCデータDA、CデータDBで指定するPCデータDB、およびCデータDCで指定するCCデータDCの並びから構成されている(図4(b))ので、CCシーン3Dは、それらに対応してPCシーン3DA、PCシーン3DB、およびCCシーン3DCから構成されていることになる。CCシーン3DCについても同様にして、対応するCCデータのPC用CADデータで定義されているコンポーネントデータに対応するコンポーネントシーンの並びから構成されている。
結果として、図5(a)で示されるコンポーネントシーンの並び(すなわち1つのシーンデータ)は、実際は図5(b)に示すように個別のPCシーンの並びである。要するに、この並びの順番は、(1)一番上位のCFデータのPC用CADデータのCデータの並びからPコンポーネントおよびCコンポーネントの並び順を取得し、(2)その中のCコンポーネントの部分については、そのCデータで指定されるCCデータのPC用CADデータを参照して同様にPコンポーネントおよびCコンポーネントの並び順を取得し、(3)さらにその中にCコンポーネントがある場合は(2)の処理を繰り返す、という処理により決定されるものである。
また、上述したようなCCシーンのデータ構成は、対応するCコンポーネントを規定するCCデータのCADデータ中の各CデータのID(PC_IDまたはCC_ID)とバージョン(PC_VerまたはCC_Ver)で指定されたPCデータまたはCCデータ、および、同Cデータ中のプロパティに基づいて決められている。Cコンポーネントがネストする場合、ネストした下位のCCシーンの部分のデータ構成は、同様にして決められる。
図5(c)は、PC130のミキサ制御プログラム131により処理される対象のCFデータのRAM上での構成を示す。PC130のRAM上に設けられたカレントメモリには、CFデータの全体(すなわち、CFヘッダとPC用CADデータと複数のシーンデータ)を格納する領域、現在設定中のシーンデータであるカレントシーンを格納する領域、およびエンジン用CADデータ形成バッファが設けられている。カレントメモリ上のPC用CADデータに基づいて、図2(a)のようなコンフィグレーション画面が表示される。コンフィグレーション画面上で行なわれた編集は、カレントメモリ上のPC用CADデータに反映される。カレントシーンは、表示されているコンフィグレーションの各コンポーネントのパラメータ現在値(カレント値)を表す。パラメータ設定画面によりコンポーネントのパラメータに対して行なわれた編集はカレントシーンに反映される。カレントシーンの構成は、図5(a)および(b)で説明したのと同様であり、最下位のPCシーンの並びに展開されている。ただし、ミキサ制御プログラム131は、401〜403に示すような階層構造は認識しているものである。エンジン用CADデータ形成バッファは、CFデータをコンパイルしたとき、PC用CADデータからエンジン用CADデータを生成するバッファである。図3の画面で作成編集されるCCデータのRAM上の構成も同様である。CFヘッダをCCヘッダとし、シーン1,2,…とエンジン用CADデータ形成バッファを無くせばよい。
次に、ライブラリについて説明する。ライブラリとは、各コンポーネントのパラメータ設定を予め幾つかのパターンで格納したものである。例えば図4(a)のPCデータ2では、ライブラリとして設定データ1,2,…が格納されている。Pコンポーネントをコンフィグレーション画面(図2(a))やCコンポーネント作成編集画面(図3)に呼び出して構成要素として使用するとき、そのPコンポーネントのPCデータのライブラリ中の任意の設定データを読み出して、一括してパラメータ設定することができる。
ライブラリ中の1つの設定データは、そのコンポーネントのパラメータ値のデータセットである点はコンポーネントシーンと同様であるので、その構成も図5(a)で説明したコンポーネントシーンと同様のものである。ただし、コンポーネントシーンは1次元または2次元配列のエレメントシーンを含む場合の要素数が既に決定されている(図4(c)のPC用CADデータのCデータのプロパティに要素数が記載されている)ので各パラメータの値そのものだけで構成されているが、ライブラリの各設定データは各パラメータの値に加えて上記要素数のデータを含む。図4(a)のPCデータのPC構成情報は要素数を含まず、該PCデータがコンフィグレーション画面(図2(a))やCコンポーネント作成編集画面(図3)で構成要素として呼び出されたときに要素数が決まるものである(初期値は例えば設定データ1で規定する要素数とすればよい)。
Cコンポーネントについても同様のライブラリが持てる。ただし、Cコンポーネントのライブラリの各設定データは、そのCコンポーネントの構成要素であるPCデータやCCデータのそれぞれの設定データの並びである。CCデータがネストする場合は、ネストした部分が個別のPコンポーネントの設定データに展開される。例えば、図4(b)のCCデータ2のライブラリの各設定データは、CデータDAで指定されるPCデータDAに対応するパラメータセット、CデータDBで指定されるPCデータDBに対応するパラメータセット、およびCデータDCで指定されるCCデータDCに対応するパラメータセットからなり、そのCCデータDCに対応するパラメータセットの部分は、それに対応するCコンポーネントを構成する構成要素毎のパラメータセットに展開されている。結果として、Cコンポーネントのライブラリの各設定データは、個別のPコンポーネント対応のパラメータセット(上述したように各パラメータの値と要素数のデータを含む)の並びとなる。このようなCコンポーネントのライブラリの各設定データのデータ構成は、対応するCコンポーネントシーンのデータ構成の決定方法と同様の方法で決定される。すなわち、(1)当該CCデータのCADデータのCデータの並びからPコンポーネントおよびCコンポーネントの並び順を取得し、(2)その中のCコンポーネントの部分については、そのCデータで指定されるCCデータのCADデータを参照して同様にPコンポーネントおよびCコンポーネントの並び順を取得し、(3)さらにその中にCコンポーネントがある場合は(2)の処理を繰り返す、という処理により、各コンポーネントの設定データの並び順が決定される。さらに、各コンポーネントの設定データ内部のデータ構成については、例えば図5(a)で説明したようにエレメントシーンの1次元配列または2次元配列の要素数が区々であるので、同じコンポーネントでも設定データの構成が異なる場合がある。そこで、各コンポーネントの設定データ内部のデータ構成を決定するために、対応するコンポーネントを規定するCデータのプロパティを参照するものとする。
以上のように、PC130のミキサ制御プログラム131により、図2(a)のような画面上の操作で、図4(a)および(b)のコンポーネントデータを使用して、図5(c)のカレントメモリ上にCFデータを作成編集し、図4(c)のような構成でCFファイルとして保存できる。また図3のような画面上の操作で、図4(a)および(b)のコンポーネントデータを使用して、図5(c)と同様の構成のCコンポーネント作成編集用のカレントメモリ上に、図4(b)の構成のCCデータを作成編集し、ファイルとして保存することができる。
図2(a)および図3の何れの画面でも、表示されているPコンポーネントについては、ダブルクリックすることにより図2(b)に示すようなパラメータ設定画面が表示され個々のパラメータ設定を行なうことができる。また、PコンポーネントおよびCコンポーネントの何れに対しても、ライブラリから設定データを読み出して一括してパラメータ設定(カレントシーンへのパラメータの書き込みと、PC用CADデータ内のPCデータやCCデータのプロパティへの書き込み)を行なうこともできる。操作上は、例えば図2(a)や図3の画面でPまたはCコンポーネントを1つ選択し、所定の操作でそのコンポーネントのライブラリの中から1つの設定データを読み出したり、いったん図2(b)のようなパラメータ設定画面を表示させこの画面上でライブラリから1つの設定データを読み出して、一括してパラメータ設定を行なうなどの方式を採ればよい。ライブラリから設定データを読み出して一括してパラメータ設定を行なうことを、設定データのライブラリからの「ロード」と呼ぶ。逆にカレントメモリ上のパラメータ設定を、ライブラリの設定データとして一括して保存することもできる。これを、設定データのライブラリへの「セーブ」と呼ぶ。
既に説明したように、PC130側で保存したCFファイルは、コンパイルした後、エンジン100に転送してフラッシュメモリ102に格納できる。エンジン100では、表示器107に表示された画面を見ながらパネル上の操作子108を操作することにより、フラッシュメモリ102に格納されたCFファイルを指定してRAM103内のカレントメモリにロードできる。エンジン100は、カレントメモリ上のCFデータで定義されるミキサ構成のミキサとして動作する。
図6(a)は、エンジン100内のフラッシュメモリ102に格納されるCFデータの一部を示す。フラッシュメモリ102に格納されるCFデータは、図4(c)に示したPC内のCFデータの構成とほとんど同じであるので、図6(a)は異なる部分のみを示した。すなわち、エンジン100側では、図4(c)のPC用CADデータの部分が、図6(a)のエンジン用CADデータに置き換わる。エンジン用CADデータは、コンフィグレーション画面で示されるようなミキサ構成を表すデータである点はPC用CADデータと同じだが、エンジン内では図2(a)の画面におけるコンポーネントや配線の表示位置などのデータは不要であるため、またデータ量を少なくするため、表示データを含まずバイナリ形式で表現されている。さらに、エンジン側ではCコンポーネントの概念はないので、エンジン用CADデータは最下層のPCデータをそれぞれ指定するCデータに展開されている。言い替えると、エンジン用CADデータは、CCデータを指定するCデータを含まず、そのようなCデータはPCデータを指定するCデータまで展開されると言うことである。この展開は、コンパイルにより行なわれる。例えば、図4(c)のCFデータ2をコンパイルすると、そのPC用CADデータ中のCデータDは、それが指定する図4(b)のCCデータ2が参照されて、CデータDA、CデータDB、およびCデータDCに展開される。さらにこの中のCデータDCはCCデータを指定しているので、そのCCデータについても同様に展開する。これによりCFデータ中のPC用CADデータはすべてPCデータを指定するCデータに置き換わる。なお、コンパイル後のエンジン用CADデータ中の各Cデータは、エンジン100内のフラッシュメモリ102に格納されているPコンポーネントデータを指定するデータとなる。以上のような処理をコンパイル時に行ない、図5(c)のエンジン用CADデータ形成バッファにエンジン用CADデータを生成する。PC130側では、図4(c)の形式でCFファイルを任意の記憶装置に保存しているが、コンパイル後は、図6(a)の形式でやはり任意の記憶装置に保存できる。その図6(a)の形式のCFファイルをPC130からエンジン100に転送してフラッシュメモリ102に格納する。なお、フラッシュメモリ102上には、所定のファイルシステム(PC上のファイルシステムに準拠するものである必要はない)が構築されており、CFデータはCFファイルの形で複数格納されている。
図6(b)は、エンジン100上のCFデータのRAM103上での構成を示す。RAM103上のカレントメモリには、CFデータのうち、CFヘッダとエンジン用CADデータを格納する領域、現在設定されているシーンデータであるカレントシーンを格納する領域、およびマイクロプログラム形成バッファが設けられている。カレントメモリにエンジン用CADデータが読み込まれたときには、自動的に、当該CADデータのミキサ構成を実現するマイクロプログラムがマイクロプログラム形成バッファ上に展開され、そのマイクロプログラムが信号処理部110に転送される。これにより、信号処理部110のDSP群はカレントメモリ上のCADデータのミキサ構成の動作を実現する。ここで、フラッシュメモリからの読み出しはPCの記憶装置(ハードディスクなど)からに比べて高速なので、複数のシーンデータについてはカレントメモリに読み込まなくてもシーンリコールの速度は遅くならない。また、エンジン用CADデータについても必ずしもカレントメモリに読み込まなくても良く、フラッシュメモリ上のデータを直接利用しても良い。
カレントシーンは、カレントメモリに展開されているエンジン用CADデータのミキサ構成の各コンポーネントのパラメータのカレント値である。カレントメモリにカレントシーンが読み込まれたとき、あるいはそのカレントシーンが変更されたときには、自動的に、当該カレントシーンが信号処理部110に転送される。信号処理部110は、転送されたカレントシーンをDSP群の係数メモリに展開する。信号処理部110のDSP群は当該係数メモリの係数を使用して上記転送されたマイクロプログラムを実行し、これにより信号処理部110は、カレントメモリ上のCADデータのミキサ構成で、かつカレントシーンのパラメータ値での動作を実現する。エンジン100上のカレントシーンの構成は、図4や図5で説明したのと同様である。
図6(c)は、フラッシュメモリ102に予め格納されているPコンポーネントデータの構成の一部を示す。このPコンポーネントデータは、図5(c)に示したPC内でのPコンポーネントデータの構成とほとんど同じであるので、図6(c)は異なる部分のみを示した。すなわち、エンジン100側では、図5(c)の表示・編集処理ルーチンとライブラリの部分が、図6(c)のPCマイクロプログラムに置き換わる。エンジン100では、図2(a)、(b)に示されるコンフィグレーション画面における各コンポーネントの表示や複数操作子を有するパラメータ設定画面の表示はできないので、その表示・編集のための表示・編集ルーチンは不要である。また、エンジン側ではライブラリを使用しないのでライブラリもない。その代わり、エンジン100では、エンジン用CADデータのミキサ構成に応じたマイクロプログラム(マイクロプログラム形成バッファ上に生成)をDSP群に送る必要があるため、図6(c)のような各コンポーネント対応のPCマイクロプログラムが必要である。また図示しないが、PC処理ルーチンは、エンジン中で各構成情報を処理するための各種のプログラムであるものとする。なお、各コンポーネントの入出力数はパラメータの設定によって変化するが、コンポーネントデータ中のPCマイクロプログラムにはそれらの入出力数のバリエーションが全て格納されているものとする。エンジン側にはCコンポーネントの概念はないので、フラッシュメモリ102には、図4(b)のようなCコンポーネントデータが格納されていない。
本実施形態のシステムの特徴は、ミキサ制御プログラム131でCコンポーネントを利用する場合に、異なるCコンポーネント間でコンポーネントシーンやライブラリの設定データを相互利用可能としたことにある。具体的には、所定の条件下で、異なるCCデータ間でコンポーネントシーンをやり取りしたり、同様に異なるCCデータ間でライブラリの設定データをやり取りすることができる。まずCCシーンのやり取りに着目すると、図4および図5から、Cコンポーネントに対応するCCシーンが存在する場所としては、(a)PC130の記憶手段に格納された複数のCFファイルの中の複数のシーンデータ、(b)PC130のカレントメモリのカレントシーンおよび複数のシーンデータ、の2つあるから、原理的にはCCシーンのやり取りは(a)および(b)のうちの任意の2つ(同じもの同士を含む)の間で行なわれることになる。ただし、PC130の記憶装置に格納されたCFファイルは、そのままではデータのやり取りを行うのに時間がかかるので、データのやり取りを行うのに先立って、やり取りを行うCFファイルをPC130のRAM上のコピー用メモリにCFデータとして読み出し、そのRAM上のCFデータによってデータのやり取りを行い、やり取りが終了したら再び元の記憶装置ないしフラッシュメモリに書き戻す。本実施形態では、それをCFファイルのデータのやり取りと表現する。さらに別のPC上でミキサ制御プログラムが動作している場合、一方のPCの支配下にあるCFデータのCCシーンを、他方のPCに移すケースもある。このようなCCシーンをやり取りするどのような場面でも、上述の本実施形態の特徴が有効である。Cコンポーネントのライブラリの設定データのやり取りについても同様である。Cコンポーネントのライブラリの設定データは図4(b)のCコンポーネントデータ中に存在し、その設定データをカレントメモリに読み出してCコンポーネントのパラメータ設定を行なったり、逆にカレントメモリのパラメータ設定をCコンポーネントのライブラリの設定データに書き込むことができるが、この際、異なるCコンポーネント間でも所定の条件下でそのような設定データのやり取りが可能である。
上記CCシーンのやり取りの典型的な例としては、以下のようなケースがある。
(1)PC130において、1つのCFファイル中の1つのシーンデータの1つのCCシーンと、カレントシーンの1つのCCシーンとを指定して、指定されたCFファイル中のCCシーンを、指定されたカレントシーンのCCシーンに読み込むとき。これはCCシーンのリコールである。
(2)PC130において、カレントシーンの1つのCCシーンと、1つのCFファイルの1つのシーンデータの1つのCCシーンを指定して、指定されたカレントシーンのCCシーンを、指定されたCFファイル中のCCシーンに書き出すとき。これはCCシーンのストアである。
(3)読み出し元の1つのCFファイルないしCFデータの1つのシーンの1つのCCシーンと、書き込み先の1つのCFファイルないしCFデータの1つのシーンの1つのCCシーンとを指定し、読み出し元として指定されたCCシーンの記憶領域から書き込み先として指定されたCCシーンの記憶領域へCCシーンのコピーを行なうとき。
また、上記Cコンポーネントのライブラリの設定データのやり取りの典型的な例としては、以下のようなケースがある。
(1)PC130において、図4(b)の1つのCCデータ中のライブラリの1つの設定データと、カレントメモリの1つのCコンポーネントとを指定して、指定されたライブラリの設定データを、指定されたカレントメモリのCコンポーネントの設定として読み込むとき。これはライブラリの設定データのロードである。
(2)PC130において、カレントメモリの1つのCコンポーネントと、図4(b)の1つのCCデータ中のライブラリの1つの設定データとを指定して、指定されたカレントメモリのCコンポーネントの設定を、指定されたCCデータ中のライブラリの設定データに書き出すとき。これはライブラリの設定データのセーブである。
(3)読み出し元の1つのCCデータ中のライブラリの1つの設定データと、書き込み先の1つのCCデータ中のライブラリの1つの設定データとを指定し、読み出し元として指定されたライブラリの設定データの記憶領域から書き込み先として指定されたライブラリの設定データの記憶領域へ設定データのコピーを行なうとき。
なお、リコール、ストア、およびコピーという言葉は一般的にはデータの内容の変更を伴わずにデータをやり取りするものであるが、本実施形態においてCCシーンのリコール、ストア、およびコピーというときは、一般的には当該シーンデータの内容が変更されるものである。シーンデータはCコンポーネントに付随するデータであるので、読み出し元のCCシーンに対応するCコンポーネントの構成と書き込み先のCCシーンに対応するCコンポーネントの構成とが異なる場合、CCシーンの構造も異なることになるからである。ライブラリの設定データに対するロードやセーブの言葉についても同様である。
上述したように、本実施形態においては異なるCコンポーネント間でコンポーネントシーンやライブラリの設定データをやり取りできるが、これは各CコンポーネントにCC_IDが付与されていることによる。すなわち、本発明では、各Cコンポーネントに対してそのデータ互換性を示すCC_IDが付与されており、そのCC_IDによってCCシーン間のデータ互換性がチェックされる。すなわち、CC_IDが同じであるということは、そのコンポーネントシーン間にデータ互換性があるということを意味する。また、Cコンポーネントのライブラリについても、そのライブラリに対応するCCデータにはCC_IDが付与されているので、そのCC_IDによってライブラリの設定データをやり取りする際の互換性がチェックできる。
同じCC_IDのCコンポーネントの間でCCシーンがデータ互換できるようにするため、また、同じCC_IDのCコンポーネントの間でライブラリの設定データがデータ互換できるようにするため、本実施形態では、Cコンポーネントの構成要素にU_ID(ユニークID)を付与するようにした。以下、このことについて説明する。
CC_IDは、CC(カスタムコンポーネント)データを特定するIDである(ファイル形態かカレントメモリ上かを問わない)。CC_Verは、初期値が例えば1.00で、その後CCデータを編集したときにカウントアップされていくバージョンを示す。任意のCCデータをカレントメモリ上に開いて編集した後、保存(別ファイル名または上書き保存のどちらでもよい)すると、CC_IDは同じでCC_VerがカウントアップされたCCヘッダが付く。PC130上でCCデータを新規作成した場合、当該新規作成したCCデータには新たなCC_IDおよび初期値のCC_Verが付けられる。PC130では、次に付ける最新のCC_IDの値を管理しているものとする。なお、CC_IDは、CCデータを作成したPCなどの機器のIDを含ませることにより、偶然に一致したCC_IDが付与されることを防止する。また、業者が作成編集するCCデータに付けるCC_IDと、エンドユーザが作成編集するCCデータに付けるCC_IDとで、重ならないように範囲を分けるものとし、業者の管理下にあるCCデータの範囲内、あるいは各エンドユーザの管理下にあるCCデータの範囲内では、それぞれ上記の方式でCC_IDとCC_Verを付けていくものとする。以上のようにIDとバージョンを付けることにより、同じCC_IDを持つ別々のCCデータは、そのCCデータに至る編集の経過をさかのぼれば同じCC_IDでCC_Verが初期値のCCデータに行き着くはずである。同じCC_IDを持つCCデータは、同じ「系列」に属すると言うものとする。
PC_ID(PコンポーネントID)は、図4(a)で説明した各PCデータを特定するIDである。PC_Ver(Pコンポーネントバージョン)は、そのPCデータのバージョンを示す。CCデータ中のCADデータの各Cデータでは、PC_IDとPC_VerでPコンポーネントを指定し、CC_IDとCC_VerでCコンポーネントを指定する。
U_ID(ユニークID)は、CCデータの構成を順次編集していく際に、その系列内においてそのCCデータの構成要素であるPまたはCコンポーネントを特定するためのIDである。例えば、Cコンポーネント作成編集画面上でCCデータを新規作成する場合、PまたはCコンポーネントを画面上に読み出して結線していくが、その際、追加したコンポーネントを指定するCデータをCADデータに新規追加する毎に新たなU_IDの値がそのCデータに付けられる。Cデータを削除したときは、そのCデータのU_IDの値は空きとなり、当該CCデータの系列内ではU_IDとして使われることはない。空きのU_IDの値があったとしても、それ以後新規に追加されるCデータに対しては新たなU_IDの値が付けられる。これにより、CCデータが編集されていきCデータの追加や削除がなされ、その編集の途中の任意の段階でCCデータが保存されたとしても、その系列内において、U_IDの値が一致するCデータは同じCデータであると判別できる。なお、ここで「同じCデータ」というのは「全く同じデータ」を意味しない。U_IDの値が一致したとしても、別々のCCデータ内の2つのCデータということであるから、各CCデータ内でそれぞれパラメータ編集されれば、データとしては異なることがある。ただし、同じ種類のCデータであって、対応するコンポーネントシーンの構造が同じ(エレメントシーンの配列要素数を除く)であることは保証される。
図7は、CCデータを編集していくときのIDやバージョンの付け方およびCCシーンデータの構成の例を示す図である。701は図3のようなCコンポーネント作成編集画面で初めに新規作成したCコンポーネントのPC用CADデータを示す。新規作成なので、新たなCC_ID=XXが付けられ、CC_Ver=1.00(初期値)になっている。このCADデータは、イコライザEQ711およびダイナミックスDYN712の2つのPコンポーネントから成る。各Pコンポーネントを示すブロック内に記載された括弧内の3つの数値は、先頭からPC_ID、PC_Ver、およびU_IDを示す。EQ711はU_ID=1、DYN712はU_ID=2である。
702は、CCデータ701を元にして新たなPコンポーネントであるクロスオーバーX_OVER723を追加し、結線し、その後、別名のCCデータとして保存したものである。CCデータ702の保存時には、CCデータ701と同じCC_ID=XXが付けられ、バージョンはカウントアップされてCC_Ver=1.01になっている。追加されたX_OVER723はU_ID=3となる。ここまでで本系列内ではU_ID=2まで使用しているからである。703は、CCデータ702を元にしてEQ721を削除し、その後、別名のCCデータとして保存したものである。CCデータ703の保存時には、CCデータ701,702と同じCC_ID=XXが付けられ、バージョンはカウントアップされてCC_Ver=1.02になっている。もしCCデータ703の状態からコンポーネントを追加するとU_ID=4となる。ここまでで本系列内ではU_ID=3まで使用しているからである。削除されたU_ID=1は空きとなるが、以後のこの系列のCCデータの編集においてU_ID=1が使われることはない。
741は、CCデータ701のCコンポーネントに対して作成された1つのCCシーン(既に、あるCFデータのシーンデータに含まれるCCシーンとして保存されているものとする)を示す。CCデータ701の2つのPコンポーネントの並びに応じて、EQ711に対応するPCシーン751とDYN712に対応するPCシーン752が並べられている。
742は、CCデータ702に対応するCCシーンを示す。CCシーン742の編集において、CCデータ701のCCシーン741を指定してリコールを指示したとき、CCシーン741のPCシーン751,752が、それぞれ、CCシーン742のPCシーン761,762にコピーされる。このリコールは、CCデータ701とCCデータ702との間であるので、異Cコンポーネント間リコールである。異Cコンポーネント間リコールの場合、一般的にはCコンポーネントの構成が異なるので、その相違に基づきCCシーンの構造も異なることになる。従って、例えばPCシーン751を読み出してきても、そのPCシーンを、CCシーン742のどこに書き込めばよいかは一般的には分からない。しかし、本実施形態のミキサのシステムでは、CADデータが編集され別名で保存されてもCC_IDは同じものが付され、また同じ系列内のCCデータであればU_IDによりその構成要素の各コンポーネントの対応が取れる。従って、リコール元とリコール先のCCデータのCC_IDが一致していることを確認した後、例えばCCシーン741から読み出してきたPCシーン751については、当該PCシーン751に対応するPコンポーネントであるEQ711のU_IDが1であることを求め、CCデータ702からU_IDが1であるPコンポーネントがEQ721であることを求め、当該EQ721に対応するPCシーンの格納位置が761であることを求め、その位置761にPCシーン751をコピーする。CCシーン741をCCシーン742にリコールしたとき、CCシーン742のPCシーン763については、リコール元に対応するPCシーンが無いのでそのままとする。
CCデータ703のCCシーン743の編集において、CCデータ702のCCシーン742を指定してリコールを指示したときも上記と同様である。CCシーン742のPCシーン762,763が、それぞれ、CCシーン743のPCシーン772,773にコピーされる。リコールの処理シーケンスは、CCシーン742のPCシーン761についてもコピーしようとするが、このPCシーンに対応するPコンポーネントのU_IDは1であり、一方リコール先のCCデータ703にはU_ID=1のコンポーネントは無いので、PCシーン761はコピーされない。以上のようにして、異Cコンポーネント間リコールが実現される。
図7では、Cコンポーネントの構成要素がすべてPコンポーネントである場合を例としたが、Cコンポーネントの構成要素として他のCコンポーネントを利用する場合(Cコンポーネントをネストする場合)も同様である。例えば、EQ711をCコンポーネントに置き換えた場合は、対応するシーンデータをCCシーンとすればよい。Cコンポーネントに対しても上述のU_IDが(そのCコンポーネントを指定するCデータに)付与されて管理されるので、系列内で同じCコンポーネントであることが確認でき、当該CコンポーネントのCCシーンについて同じ考え方で処理できる。
また、図7では、CCシーンのやり取りを例としたが、ライブラリの設定データのやり取りについても同様である。Cコンポーネントのライブラリの設定データのやり取りの典型的な例として、上述の(1)〜(3)のようなケースがあるが、何れのケースでも、異Cコンポーネント間でCC_IDの一致が確認された場合には、ライブラリの設定データがやり取りできる。例えば、741がCCデータ701のライブラリの1つの設定データであるとすると、PCシーン751,752はそれぞれそれぞれ各Pコンポーネント711,712に対応する設定データと読み替える。742をカレントメモリ上のCCデータ702のCコンポーネントのカレントシーンとすると、Cコンポーネントのライブラリの設定データ741をカレントのCコンポーネント702のカレントコンポーネントシーンとしてロードするとき、上記コンポーネントシーンデータのリコールと同様にして、各Pコンポーネントの設定データ751,752とカレントのコンポーネントシーンとの対応が分かるので、ロードすることができる。742をCCデータ702のCコンポーネントのライブラリの1つの設定データとしたときも同様である。
図8は、エレメントシーンの書き込み処理の例を示す。図7で説明したように、本実施形態のミキサのシステムでは、異Cコンポーネント間でも、CC_IDが一致する場合には、それらのCコンポーネントを構成する各コンポーネントのU_IDによりPCシーンやCCシーンの対応がとれる。同じU_IDのPまたはCコンポーネントは同じPC_IDまたはCC_IDが付与されているので基本的には相互にパラメータの互換性があるのであるが、その2つのコンポーネントでPC_VerやCC_Verが異なっていたり、端子数等のコンポーネント規模を示すプロパティ情報が異なっている場合がある。そのため、例えば図7のCCデータ701のPCシーン751をCCデータ702のPCシーン761にコピーする場合、その2つのPCシーン751とPCシーン761では、その構造、すなわちエレメントシーンの並びの順序と形式(単一値か一次元配列か二次元配列か)については一致するが、その一部のエレメントシーンについて、何れかの一方にだけ存在していたり、配列要素数が異なっている可能性がある。PCシーンの各エレメントの有無は各PコンポーネントのPC構成情報により制御され、PCシーンの各エレメントの要素数はCADデータの対応するCデータのプロパティ情報により制御される。要素数が変更されている場合、パラメータシーンの書き込みのルールを決めておく必要がある。
図8(a)は、エレメントシーンが単一の値から成る場合である。801は書き込むデータEx、802は書き込み先のデータEoを示す。エレメントシーンの書き込み処理により、803に示すように、書き込み先のデータがExに書き替わる。
図8(b)は、エレメントシーンのデータ形式が一次元配列の場合である。811は書き込むエレメントシーンのデータを示す。このデータの要素数は4である。書き込み先のエレメントシーン812の要素数が6のとき、書き込み処理により、813に示すように書き込み先のエレメントシーンの先頭から4番目の要素までが書き込むデータE[1]xからE[4]xに書き替わる。元からあるE[5]oとE[6]oは変化しない。一方、書き込み先のエレメントシーン814の要素数が2のときは、815に示すように2つの要素が書き替わり、E[3]xとE[4]xは無視される。
図8(c)は、エレメントシーンのデータ形式が二次元配列の場合である。書き込むエレメントシーンのデータ821は、行要素数が4、列要素数が3の形式である。書き込み先のエレメントシーン822は、行要素数が6、列要素数が2である。書き込み処理により、823に示すように、重なる部分のみが書き替えられ、その他は無視される。
以上のように、エレメントシーンが配列であるときは、書き込み元と書き込み先とで、要素の添字が一致する要素は書き替え、書き込み元のみに存在する添字の要素は無視し、書き込み先のみに存在する添字の要素はそのままとされる。
以上をまとめると、まずCコンポーネントに対応するCCシーンのやり取り(リコール、ストア、コピー)の際の処理の基本は以下のようなものである。
(1)呼び出し元のCCシーンに対応するCCデータを取得し、そのCCデータのCADデータのCデータの並び順を取得する。その並び順が、呼び出し元のCCシーンを構成するコンポーネントシーンの並び順となる。
(2)各コンポーネントシーンのデータ構造は、そのコンポーネントがPコンポーネントである場合は、そのPコンポーネントのPCデータのPC構成情報、およびそのコンポーネントシーンに対応するPコンポーネントを指定するCデータのプロパティを参照して決定する。
(3)CCデータがネストしている場合は、当該CCデータについて同様にして、対応するCCシーンのデータ構造を決定する。
以上により、読み出し元のCCシーンのデータ構造が取得できる。書き込み先のCCシーンについても同様にしてデータ構造を取得する。その後は、図7および図8で説明したように、CC_IDが一致していることを確認し、U_IDが一致するコンポーネントを確認して、対応するコンポーネント同士でコンポーネントシーンをやり取りする。以上のような処理の基本は、Cコンポーネントのライブラリの設定データのやり取りでも同様である。本実施形態のミキサ制御プログラムでは、上記処理時(あるいは処理に先立って)には、カレントアクセスルーチン、シーンアクセスルーチン、およびライブラリアクセスルーチンを構築し、これにより上記処理の基本を実現する。各ルーチンについては、図10〜図12で詳しく説明する。
図9(a)は、コンパイル時の処理の概要を示す。901は、コンパイル前のCADデータを示し、これはカレントメモリ上のCFデータのPC用CADデータに相当する。コンパイル処理では、ステップ902で、CADデータ901を入力し、当該CADデータにCCデータが含まれるときには、Cコンポーネントデータ903(図4(b))を参照してそのCCデータ部分をPCデータに展開する。CCデータがネストしているときはさらにそのネスト部分も展開する。次にステップ904で、不要データ(例えば表示用データなど)を除去しエンジンに転送できる形式とするためパッキングする。以上によりコンパイル済みのCADデータ905が生成される。
図9(b)は、図9(a)で説明したコンパイル処理の詳細を示す。ステップ911で、コンパイル対象のCADデータを読み込むなどの準備処理を行なう。次に、CADデータに含まれるコンポーネントのコンパイル処理を行なう。まずステップ912で、CADデータの最初のコンポーネントを準備する。ステップ913で、準備したコンポーネントがCコンポーネントか否か判定する。Pコンポーネントの場合は、ステップ914で、該Pコンポーネントの不要データを除去しパッキングし、ステップ917に進む。Cコンポーネントの場合は、ステップ915で、該CコンポーネントのCADデータを準備する。これは、該Cコンポーネントを特定するCC_IDによりCコンポーネントのデータを探索する処理である。見つからないときは警告表示を行なう。ステップ916では、ステップ915で読み出したCADデータに含まれるコンポーネントのコンパイル処理を行なう。これは図9(b)の処理を再帰的に行なうものである。次にステップ917で、次のコンポーネントを準備し、ステップ918で次のコンポーネントがないときはステップ919に進み、結線の不要データを除去しパッキングして処理を終了する。次のコンポーネントがあるときは、ステップ918から913に戻って処理を継続する。
図10(a)は、ミキサ制御プログラム131においてカレントシーンメモリまたはシーンメモリ(ファイルの形式で保存されているシーンデータでもよいし、RAM上のワーク領域に読み出したシーンデータでもよい)上のシーンデータをアクセスするための準備処理を示す。この処理は、例えば、Cコンポーネントを構成要素として含むミキサ構成が何らかの処理の対象として選択されたときなどに実行される。1001は、選択されたミキサ構成(CFデータ)のコンパイル前のCADデータを示す。ステップ1002で、そのCADデータ1001を読み込み、Cコンポーネントが含まれていたら、CCデータのCADデータ(図4(b))1003を参照して当該Cコンポーネントの部分を展開する。展開とは、Cコンポーネントをその構成要素のPコンポーネントに展開するということであり、Cコンポーネントがネストしている場合は展開を繰り返し、最終的に最下位のPコンポーネントの構成を取得する処理である。次にステップ1004で、PCデータ1005(図4(a))を参照して、カレントアクセスルーチン、シーンアクセスルーチン、およびライブラリアクセスルーチンなどの制御ルーチンを構築する。
シーンデータのデータ構造は、そのシーンデータに対応するミキサ構成を上述したように展開し、各PCデータの構成情報やミキサ構成に含まれるプロパティ情報を参照して決定する。そのように決定したデータ構造に応じたアクセス機能を提供するため、上述の各種ルーチンを構築するものである。構築後は、これらのルーチンを用いて、処理対象のミキサ構成に付随するシーンデータをアクセスできる。シーンデータは、最大の単位は1つのシーンを規定するシーンデータ(すなわち図4(c)のCFデータに含まれる1つのシーンデータ)であり、その単位でのシーンデータをアクセスするルーチンが構築されることはもちろん、その下位階層のコンポーネントシーン単位、エレメントシーン単位、およびパラメータ単位の各アクセス機能も提供される。特に、処理対象がCCシーンであっても、当該CコンポーネントのCCシーンのデータ構造を把握し、そのデータ構造に沿ったアクセスルーチンが構築されるので、当該アクセスルーチンを用いることによりCCシーンのリコール、ストア、およびコピーを容易に行なうことができる。
図10(b)は、ミキサエンジンでのカレントシーンメモリまたはシーンメモリの準備処理を示す。1011は、処理対象のミキサ構成のコンパイル後のCADデータを示す。ステップ1012で、当該CADデータ1011を読み込み、Pコンポーネントデータ(図6(c))1013を参照して、カレントアクセスルーチンやシーンアクセスルーチンなどの制御ルーチンを構築する。エンジン側にはCコンポーネントの概念がないので、Cコンポーネントの展開は不要である。
図11は、シーンメモリのストア/リコールの概念図である。図の左側のミキサ制御プログラム側では、ストアやリコールの対象となるカレントメモリ上のシーンデータ1112をアクセスする機能を提供するカレントアクセスルーチン1111、および同様にストアやリコールの対象となるシーンメモリ1115上のシーンデータ1114にアクセスする機能を提供するシーンアクセスルーチン1113が、上記図10(a)の処理により構築されている。これらのルーチン1111,1113は、CFデータのCADデータ1121、CCデータのCADデータ1122、およびPCデータ1123に基づいて決定されたデータ構造のシーンデータをアクセスする機能を提供する。発行されたストア命令やリコール命令の指示に応じて、これらのアクセスルーチンを利用してシーンデータをやり取りできる。ここではシーンデータ単位で図示したが、シーンデータ1112,1114がCCシーンであっても同様であり、上述の処理の基本を遵守し図7や図8で説明したデータの読み出しと書き込みが実現できる。
図11の右側のエンジン側では、ストアやリコールの対象となるカレントメモリ上のシーンデータ1132をアクセスする機能を提供するカレントアクセスルーチン1131、および同様にストアやリコールの対象となるシーンメモリ1135上のシーンデータ1134にアクセスする機能を提供するシーンアクセスルーチン1133が、上記図10(b)の処理により構築されている。これらのルーチン1131,1133は、CFデータのCADデータ1141、およびPCデータ1143に基づいて決定されたデータ構造のシーンデータをアクセスする機能を提供する。発行されたストア命令やリコール命令の指示に応じて、これらのアクセスルーチンを利用してシーンデータをやり取りできる。
図12は、Cコンポーネントの設定データのライブラリへのセーブ/ライブラリからのロードの概念図である。図の左側のミキサ制御プログラム側では、図11で説明したのと同様のカレントアクセスルーチン1211、およびロードやセーブの対象となるライブラリ1216上の設定データ1214にアクセスする機能を提供するライブラリアクセスルーチン1213が、上記図10(a)の処理により構築されている。カレントアクセスルーチン1211は、CFデータのCADデータ1221、CCデータのCADデータ1222、およびPCデータ1223に基づいて決定されたデータ構造のカレントメモリ1215上のCCシーン1212をアクセスする機能を提供する。ライブラリアクセスルーチン1213は、CCデータのCADデータ1222およびPCデータ1223に基づいて決定されたデータ構造の設定データ1214をアクセスする機能を提供する。発行されたロード命令やセーブ命令の指示に応じて、これらのアクセスルーチンを利用して、Cコンポーネント単位で設定データをやり取りできる。これにより、上述の処理の基本を遵守し、図7や図8で説明したデータの読み出しと書き込みが実現できる。
図12の右側のエンジン側では、カレントメモリ1232をアクセスする機能を提供するカレントアクセスルーチン1231が準備されている。カレントアクセスルーチン1231は、CFデータのCADデータ1241やPCデータ1243に基づいて決定されたデータ構造のカレントメモリ上のPCシーンをアクセスする機能を提供する。エンジン側にはライブラリの概念がない。実行モードの場合、ミキサ制御プログラム側でCコンポーネントの設定データのロードが実行されると、そのCコンポーネントを構成するPコンポーネントのそれぞれに対応する設定データのロード命令がエンジン側に送られ、エンジン側ではそれぞれのPコンポーネントに対応する設定データのカレントメモリへのロードを行なう。1251,1252,1253はそれぞれがPコンポーネントに対応する設定データであり、カレントアクセスルーチン1231により、Pコンポーネント単位でカレントメモリ1232上の対応するPCシーン1261,1262,1263の位置に設定される。
100…エンジン、101…CPU、102…フラッシュメモリ、103…RAM、104…PC I/O、105…MIDI I/O、106…その他I/O、107…表示器、108…操作子、109…波形I/O、110…信号処理部(DSP群)、111…カスケードI/O、120…システムバス、130…パーソナルコンピュータ(PC)、131…ミキサ制御プログラム、132…コンフィグ(CF)データ。