以下、図面を用いてこの発明の実施の形態を説明する。
図1は、この発明の実施の形態に係るディジタル・ミキサの構成例を示す。101はコンソール、102はエンジン、103は各ユニットを示す。コンソール101は、ユーザが操作する多数の操作子やディスプレイを備えた部分であり、ユーザによる操作指示を受け付け、エンジン102に指示を出す。エンジン102は、コンソール101からの指示に応じて、入力ユニットから入力したマイク信号やライン信号などを適宜ミキシングし、効果の付与などを行なって、出力ユニットに出力する。ユニット103としては、アナログ入力(AIN)ユニット、アナログ出力(AOUT)ユニット、およびディジタル入出力(DI/O)ユニットが接続される。AINユニットは、1ユニットに複数枚のアナログ/ディジタル(A/D)変換ボードをマウントできるボックスであり、これによりマイク信号やライン信号を複数チャンネル(ch)分入力することができる。AOUTユニットは、1ユニットに複数枚のディジタル/アナログ(D/A)変換ボードをマウントできるボックスであり、複数ch分の出力を行なうことができる。DI/Oユニットは、1ユニットに複数枚のディジタル入出力(I/O)ボードをマウントできるボックスであり、複数ch分のディジタル入力およびディジタル出力を行なうことができる。
1台のエンジン102には、入力側に10台のユニット(AINユニットまたはDI/Oユニット)を接続でき、出力側に6台のユニット(AOUTユニットまたはDI/Oユニット)を接続できる。1台のコンソール101、1台のエンジン102、および当該エンジン102に接続された複数のユニット103の組み合わせが、ミキサとしての1システムの最小構成となる。これにより、任意の入力chの入力信号を任意のミキシングchに流し込んでミキシングし、任意に効果付与して、任意の出力chに出力する処理を、集中的に制御できる。
図1の(1)(なお、図面中の丸数字は明細書中では括弧付きの数字で表すものとする)は、コンソール101にもう1台のコンソール111を接続し、デュアルコンソールとした例である。これにより、操作子の数を増やし多数のchについての直接的な制御環境を構築したり、1台のコンソールが故障した場合に他の1台のコンソールで操作を続行できるようなフェイルセーフシステムを構築できる。デュアルコンソールとした場合、初めからあるシステムのコンソール101はマスタコンソール、後から接続したコンソール111はスレーブコンソールと呼ぶ。コンソール101内のMMの記載は、マスタシステムのマスタコンソールであることを示す。コンソール111内のMSの記載は、マスタシステムのスレーブコンソールであることを示す。
図1の(2)は、エンジンのミラーリングの例である。ミラーリングでは、マスタシステムのコンソール101とユニット103に、もう1台のエンジン121を接続する。ミラーリングでは、コンソール101からの制御により、エンジン102と121は同じ動作を行なう。通常は選択されているエンジン(例えば102)が使われるが、当該エンジンに故障があったとき、もう一方のエンジンに切り換えて処理を継続できる。
図1の(3)は、システムのカスケード接続の例である。コンソール131、エンジン132、およびユニット133を別システムとして用意し、マスタシステムのエンジン102とエンジン132とをカスケード接続する。コンソール131、エンジン132、およびユニット133でスレーブシステムを構成する。これにより、2台のエンジン102,132のそれぞれのミキシングバスが連結され、全体として入力ch数が倍のミキサシステムが構築できる。なお、コンソール131内のSMの記載は、スレーブシステムのマスタコンソールであることを示す。エンジン132内のSの記載は、スレーブシステムのエンジンであることを示す。
図2は、1台のコンソールの外部パネルの例を示す。外部パネルは、201〜210の各セクションに分かれている。そのうち、セクション201〜205,207〜209は、スイッチ、フェーダ、およびロータリーエンコーダなどの複数の操作子を備えた部分である。
201,202,203,204は、それぞれが1つの入力chセクション(IN A〜D)である。入力chセクションは、複数入力chについての各種制御を行なう部分である。205はセレクテッド入力chセクション(IN SEL)であり、入力chセクション201〜204で選択した1つの入力chについて各種の制御を行なう部分である。表示器(LCD)206は、各種の情報を表示する液晶表示装置とマウス操作子のインターフェースを備えた部分である。出力chセクション(OUT)207は、複数の出力chについての各種制御を行なう部分である。セレクテッド出力chセクション(OUT SEL)208は、出力chセクション207で選択した1つの出力chについて各種の制御を行なう部分である。シーンセクション(SCN)209は、シーンに関する各種の制御を行なう部分である。シーンとは、ある場面での設定状態を示す。例えば、各場面毎の設定をシーンとして記憶させておき、それを呼び出すことにより設定した状態を簡単に再現できる。メーター(MTR)210は、各chのレベルを示すメーターなどを備えた部分である。
図3に、1台のコンソールの内部構成例を示す。コンソール300は、CPU301、フラッシュメモリ(CMAIN)302、ランダムアクセスメモリ(RAM)303、通信制御部(O COM)304、コントロール部(CTL)305、表示器(LCD)306、パネル制御部A(PNL A)307、パネル制御部B(PNL B)308、波形通信制御部(W COM)309、通信制御部(COM)310、セレクテッド入力chセクション(IN SEL)321、セレクテッド出力chセクション(OUT SEL)322、シーンセクション(SCN)323、出力chセクション(OUT)324、入力chセクション(IN A〜D)325〜328、メーター(MTR)329、および接続バス311を備えている。なお、接続バス311は、1つのバスラインで図示したが、実際には各部が相互に情報をやり取りするための複数の方式を適用している。また、図2の各セクションと図3の各ブロックとで、対応する部分は同じ記号で図示している。例えば、図3のIN A325は図2のセクション201に対応している。
図3において、太枠で図示したブロックは、それぞれが、その内部にCPUおよびフラッシュメモリを備えた機能ブロックである。また、図3のコンソール300自体も、太枠のブロックの部分以外は、CPU301およびフラッシュメモリ(CMAIN)302を備えた機能ブロックである。これらの各ブロック内のフラッシュメモリには、当該ブロックの動作を制御する制御プログラムが格納されており、当該ブロック内のCPUがその制御プログラムを実行することにより、当該ブロックが所定の機能を果たすべく動作する。必要に応じて、各ブロック間で各種の情報がやり取りされる。各ブロックの制御プログラムは、バージョン管理されており、バージョンアッププログラムによりバージョンアップすることができる。なお、「バージョン」とは、厳密には各ブロック内に設けられているフラッシュメモリに格納されている制御プログラムのバージョンを意味するが、説明の簡単化のため、ブロックのバージョンという呼び方を使う。例えば、「CTL305のバージョン」とは、CTL305内に設けられているフラッシュメモリに格納されている制御プログラムのバージョンのことである。
図3の各部について説明する。CPU301は、CMAIN302に格納されている制御プログラムを実行することにより、このコンソール300全体の動作を制御する。CTL305は、CPU301に対して各種の指示を与えてこのコンソール300の動作を制御する。本実施形態では、CTL305のバージョンを基準として、他の各ブロックのバージョンの整合性をチェックするものとする。LCD306は、CTL305の指示に応じて各種の情報を表示する。RAM303は、CPU301が実行するプログラムや使用する各種のデータを記憶するワーキング用メモリである。O COM304は、外部のコンピュータやMIDI機器と接続するインターフェースである。O COM304にPCを接続し、当該PCからコンソールやエンジンやユニットの各ブロックの制御プログラムをバージョンアップすることができる。
PNL A307は、図2で説明したセクション205,208,209,207に対応するセクション321〜324を制御するためのパネル制御用ボードである。同様にPNL B308は、図2で説明したセクション201〜204,210に対応するセクション325〜329を制御するためのパネル制御用ボードである。W COM309は、各種波形信号に関する通信制御を行なう部分である。例えば、モニタ用マイクやモニタ用スピーカなどの各種の入出力端子はW COM309に接続される。点線の矢印は波形信号の入出力を示す。COM310は、エンジン等との間で制御信号を授受する通信制御部である。デュアルコンソール時の2台目のコンソールとの通信も、エンジンとの通信と同様にW COM309およびCOM310を介して行なわれる。
図4に、1台のエンジンの内部構成例を示す。エンジン400は、CPU401、フラッシュメモリ(EMAIN)402、RAM403、O COM404、表示器405、信号処理部406、通信制御部(B COM)407、通信制御部(COM)408、および接続バス411を備えている。信号処理部406は、複数のDSP421〜425を備えている。接続バ411は、1つのバスラインで図示したが、実際には各部が相互に情報をやり取りするための複数の方式を適用している。
図3と同様に図4でも、太枠で図示したブロックは、それぞれがその内部にCPUおよびフラッシュメモリを備えた機能ブロックである。エンジン400自体も、太枠のブロックの部分以外は、CPU401およびフラッシュメモリ(EMAIN)402を備えた機能ブロックである。これらの各ブロック内のフラッシュメモリには、当該ブロックの動作を制御する制御プログラムが格納され、それらはバージョンアッププログラムによりバージョンアップすることができることも同じである。エンジン400の各ブロックのバージョン(EMAIN402内の制御プログラムも含む)は、CTL305のバージョンを基準として、バージョンチェックされる。
図4の各部について説明する。CPU401は、EMAIN402に格納されている制御プログラムを実行することにより、このエンジン400全体の動作を制御する。特にCPU401は、COM408を介してコンソール300から送られる制御信号や、O COM404を介して送られる制御信号に基づいて、エンジン400の動作を制御する。RAM403は、CPU401が実行するプログラムや使用する各種のデータを記憶するワーキング用メモリである。O COM404は、外部のコンピュータやMIDI機器と接続するインターフェースである。O COM404にPCを接続し、当該PCからコンソールやエンジンやユニットの各ブロックの制御プログラムをバージョンアップすることができる。表示器405は、エンジンの状態などを表示するLCDである。B COM407は、コンソール300との間およびユニットとの間で波形信号や制御信号を授受する通信制御部である。COM408は、コンソール300との間で制御信号を授受する通信制御部である。信号処理部406内のDSP421〜425は、CPU401の指示に応じて、各種信号処理(ユニットから入力した波形のミキシングや効果付与処理など)を行なう。
図5は、図1で説明したユニット103(133)の例である。上述したように、アナログ入力(AIN)ユニット501、アナログ出力(AOUT)ユニット502、およびディジタル入出力(DI/O)ユニット503がある。これらのユニットは、それぞれ、CPUおよびそのCPUが実行する制御プログラムを記憶したフラッシュメモリを備えた機能ブロックである。その制御プログラムは、上述したコンソール300やエンジン400に接続したPCからバージョンアップできる。また、制御プログラムのバージョンは、CTL305のバージョンを基準として、バージョンチェックされる。
図6は、この実施形態のミキサにおける信号の流れを示すブロック図である。601は、図1のユニット103,133のうち、信号入力用のユニット(図5の501,503)を示す。入力側および出力側のどちらにも複数のユニットを接続可能だが、図6では、まとめて1つの点線の矩形で示した。MADin621は、マイク信号のアナログ/ディジタル変換入力ボードによる入力を示す。ADin622は、ライン信号のアナログ/ディジタル変換入力ボードによる入力を示す。Din623は、ディジタル入出力ボードによる入力を示す。以上の3種類のボードは、エンジンの入力側に接続されたAINユニット501またはDI/Oユニット503に差し込むことによってボード単位で増設できる。602はコンソールからの入力を示す。トークバック入力631は、コンソールのオペレータが舞台側との指示連絡用に用いる入力である。パネル入力632は、コンソールから直接入力される効果音などの波形入力である。
入力パッチ603から出力パッチ611までの処理はエンジンが行なう。入力パッチ603は、上述した入力系統から、入力チャンネル(48ch)への任意結線を行なう。その設定は、ユーザがコンソールで所定の画面を見ながら任意に行なうことができる。入力ch604の任意の信号を、48本のMIXバス605あるいはステレオバス(Stereo_L/R)606の任意のchへ、選択的に出力できる。
MIXバス605は、入力ch604から入力する信号をミキシングする。ミキシングされた信号は、対応するMIX出力ch609に出力される。ステレオバス606は、入力ch604から入力する信号をミキシングする。ミキシングされたステレオ信号は、ステレオ出力ch608へ出力される。ステレオ出力ch608およびMIX出力ch609の出力は、それぞれ出力パッチ611およびマトリックス出力ch610へ出力される。マトリックス出力ch610は、ステレオ出力ch608とMIX出力ch609から任意の数の信号を選択的に入力することができ、選択入力されたこれらの信号をさらにミキシングすることができる。マトリックス出力ch610の出力は、出力パッチ611へ出力される。出力パッチ611は、上述した3種類の出力ch608〜610から、出力系統(DAout、Dout)への任意の結線を行なう。
616は、図1のユニット103,133のうち、信号出力用のユニット(図5の502,503)を示す。DAout641は、ディジタル/アナログ変換出力ボードへの出力を示す。Dout642は、ディジタル出力ボードへの出力を示す。以上の2種類のボードは、エンジンの出力側に接続されたAOUTユニット502またはDI/Oユニット503に差し込むことによってボード単位で増設できる。
カスケード接続部607は、図1の(3)で説明したようにエンジンをカスケード接続する場合のインターフェースを示す。カスケード接続部607を介して別のエンジンと接続することにより、バス605,606を2つのエンジンで共有できる。モニタ用セレクタ612とモニタ用ミキサ613およびコンソール614のモニタ用DAout615は、各chの信号モニタ用の機構である。
図7は、コンソールの表示器(LCD)206に表示されるバージョンチェックダイアログボックスの表示例を示す。バージョンチェックダイアログボックスは、ミキサの立上げ時に自動的に各部のバージョンチェックを行なった結果何らかの不整合が検出された場合、あるいはユーザがバージョンチェックスイッチを押した場合に表示される。ミキサ立上げ時にバージョンの不整合が検出されなかったときはこのダイアログボックスは表示されない。またブロックの新規接続や接続断あるいは故障などの異常が検出されたときにも、バージョンチェックを行ない、その結果がバージョンチェックダイアログボックスとして表示される。
バージョンチェックダイアログボックス700において、701は、図3に示したコンソール300のCTL305のバージョンおよびその他のブロック全体のバージョンを示す。「CTL 2.44 OK」は、CTL305のバージョンが2.44で、他のブロックと整合性が取れていることを示す。「CS 2.44 OK」は、CTL305以外のコンソール(CS)300全体のバージョンが2.44で、CTL305と整合性が取れていることを示す。702は、701で「CS 2.44 OK」とまとめて表示したブロック、すなわちCTL305以外の各ブロックの詳細なバージョンと整合状態を示す。例えば、「CMAIN 2.43 OK」は、図3のCMAIN302に格納されている制御プログラムのバージョンが2.43で、CTL305と整合性が取れていることを示す。「MTR 2.11 OK」は、図3のMTR329のバージョンが2.11で、CTL305と整合性が取れていることを示す。以下同様にして、図3の太枠で示した各ブロックについて、CTL305とのバージョンの整合状態が表示される。なお、整合が取れていないときは、OKでなくNGと表示される。702で表示する各ブロックのうち、1つでもNGのブロックがあった場合は、表示701のCSの整合状態もNGとなる。
703は、図4に示したエンジン(EG)400の全体としてのバージョンと整合状態を示す。704は、エンジン400内部の各ブロックの個別のバージョンとその整合状態を示す。704で表示する各ブロックのうち、1つでもNGのブロックがあった場合は、表示703のEGの整合状態もNGとなる。705と706は、エンジン400に接続されたユニット(図5)のバージョンと整合状態を示す。表示705の中で1〜10とあるのは、エンジンの入力側のユニット接続用端子を示す。ここでは2番目の接続用端子にAINユニット501が接続され、3番目の接続用端子にDI/Oユニット503が接続されている。表示706の中で1〜6とあるのは、エンジンの出力側のユニット接続用端子を示す。ここでは3番目の接続用端子にDI/Oユニット503が接続され、5番目の接続用端子にAOUTユニット502が接続されている。バージョンや整合状態の表示の仕方は、表示701〜704と同じである。なお、−はその接続用端子にユニットが接続されていないことを示す。
707は、図1の(1)で説明したデュアルコンソールの場合の、メインコンソールA101でのスレーブコンソールB111についての表示である。デュアルコンソールの場合のみ表示されるので点線で図示した(後述する708〜710も同様)。表示707のうち「CTL 2.44 OK」はスレーブコンソールB111内のCTL305のバージョンと整合状態を示す。「CS 2.44 OK」は、スレーブコンソールB111内のCTL305以外のブロックのバージョンと整合状態を示す。これらの整合状態は、マスタコンソールA101内のCTL305のバージョンを基準とするものである。なお、スレーブ側の各ブロックの個別のバージョンと整合状態(マスタコンソールの702の表示と同様の表示)は、マスタ側には表示されず、スレーブコンソールB111の表示器に表示される。
708,709は、図1の(2)で説明したエンジンのミラーリングを行なった場合の表示である。追加したエンジンB121について、703,704と同様の表示がなされる。なお、追加したエンジンB121についての表示708,709における整合状態は、マスタコンソールA101内のCTL305のバージョンを基準とするものである。
710は、図1の(3)で説明したシステムのカスケード接続を行なった場合の表示である。スレーブシステムのエンジンC132について、703の表示と同様の表示710がなされる。カスケード接続したエンジンC132の整合状態は、マスタコンソールA101内のCTL305のバージョンを基準とするものである。スレーブ側のコンソールC131やユニット133については、スレーブシステムのマスタコンソールC131の表示器に表示される。
721は、メッセージ表示領域である。ここではバージョンチェックの結果が正常であった場合のメッセージ表示例を図示した。722は、動作を続行する際に押下するOKボタンの表示である。
図7ではバージョンチェック結果が正常の場合の表示例を示したが、1つでも整合しないバージョンのブロックが検出された場合にはその旨が表示される。整合しないブロックが検出された場合、それがミキサ全体の動作を継続する上で致命的となる場合と致命的とならない場合がある。図8の801と802は、致命的でない場合のメッセージ表示領域721の表示例である。801は当該ブロックから応答が無い場合、802は当該ブロックから応答はあったがそのバージョンが(基準のブロックのバージョンに対して)整合しない場合のメッセージ例である。801と802の場合は、OKボタン722が表示され、オペレータがこれを押下すると、当該ブロックとの通信を切り離して動作を継続する。強制的に動作停止するためのボタンを用意してもよい。図8の803と804は、致命的である場合のメッセージ表示領域721の表示例である。これらの場合は、OKボタンは表示されず以後の動作を停止する。
図9は、本ミキサにおける状態遷移を示す。電源オン時に全ブロックが正常でバージョンの不整合もない場合は通常動作状態901となる。電源オン時に上記致命的なブロックの異常またはバージョン不整合が検出された場合は動作停止状態903となる。電源オン時に上記致命的でないブロックの異常またはバージョン不整合が検出された場合は一部動作状態902となる。これらの状態は、ミキサ動作中も相互に遷移する。例えば、通常動作状態901で正常動作している途中で、あるブロックに異常が発生したり、あるブロックが新規追加されたりしたときは、必要に応じて電源オン時と同様にバージョンチェックを行ない、その結果を表示して、一部動作状態902や動作停止状態903に遷移する。同様に、一部動作状態902や動作停止状態903のとき、異常またはバージョン不整合のブロックのボードを交換するなどして正常化することにより、通常動作状態901に遷移する。
以下、各ブロックのバージョンチェックについての具体例を説明する。
まず、メインシステムのコンソール300(図3)の各ブロックのバージョンチェックの具体例について説明する。メインコンソール300においては、基準となるCTL305のバージョンに対して、CMAIN302、MTR329、PNL A307、PNL B308、およびLCD306の何れかのブロック(致命的なブロック)のバージョンが不整合(または異常)である場合、動作停止状態903となる。メインコンソール300のこれら以外のブロック(致命的でないブロック)にバージョン不整合(または異常)が検出されたときは、一部動作状態902となる。
なお、マスタコンソール300のCTL305のバージョンを基準として判断される各ブロックのバージョンの整合性の判断基準は、所定の記憶領域(例えば、CMAIN302でよい)に記憶されているものとする。例えば、図7の表示701,702では、CTLのバージョン2.44に対し、MTRのバージョンが2.11であるが、上記判断基準にCTLのバージョン2.44に整合するMTRのバージョンが記載されており、これを参照してMTRのバージョン2.11が整合していると判断している。また、致命的なブロックか否かを判断する基準についても、同様に所定の記憶領域(CMAIN302でよい)に記憶されているものとする。
次に、ユニット(図5)のバージョンチェックの具体例について説明する。電源がオンされたとき、およびエンジンでユニットの新規接続を検出したとき、当該ユニットのバージョンチェックを行なう。エンジンのユニット接続用端子には、ユニットを接続してもしなくてもよいので、ユニットが接続されていないからといってNGにはならない。接続されたユニットのバージョンが不整合のとき、その部分をNGとしてダイアログボックス(図7)を表示し、当該ユニットとの通信を切り離して一部動作状態902となる。
デュアルコンソールの場合のバージョンチェックの具体例について説明する。デュアルコンソールが設定されている場合、電源がオンされたとき、および第2(スレーブ)コンソールの接続が検出されたときに、相手コンソールのバージョンチェックを行なう。相手コンソールが接続されていない場合は、NGとはせずにシングルコンソール動作(当該コンソールのみで動作続行)を行なう。相手コンソールが接続されており、かつバージョンが不整合のときは、NGとしてダイアログボックスを表示し、動作停止状態903となる。その後に相手コンソールが非接続になったら、ダイアログボックスを消去し、シングルコンソール動作を再開する。相手コンソールが接続されており、かつバージョンが整合するときは、OKであるので、直ちに通常動作状態901となりデュアルコンソール動作を開始する。デュアルコンソール動作では、まず、自分と相手のマスタスレーブ関係を確認し、問題がなければデュアルコンソール接続を確立する。マスタとマスタないしスレーブとスレーブに設定されている場合は、デュアルコンソール接続を行なわない。デュアルコンソール接続が確立された場合、第1コンソールと第2コンソールの両方で、接続されたエンジンのミキシング処理を制御することができる。
ミラーリングの場合のバージョンチェックの具体例について説明する。ミラーリングが設定されている場合、電源がオンされたとき、および第2エンジンの接続検出時に、第2エンジンのバージョンチェックを行なう。バージョンチェック動作は、基本的に上記デュアルコンソールの場合と同じであり、整合しないエンジンが接続されている間は動作停止状態903になる。ミラー動作では、2つのエンジンにマスタスレーブ関係は無いので、バージョンさえ整合すれば直ちに通常動作状態901となりミラー接続が確立される。ミラー接続が確立された場合、2つのエンジンは、コンソールからの制御により、相互に同じ動作を行なう。選択されているエンジンが故障したとき、自動ないし手動で他方のエンジンに切り換えられる。
カスケードの場合のバージョンチェックの具体例について説明する。カスケードが設定されている場合、電源がオンされたとき、および第2エンジンの接続検出時に、第2エンジンのバージョンチェックを行なう。バージョンチェック動作は、基本的に上記デュアルコンソールの場合と同じである。カスケード動作では、まず、自分と相手のマスタスレーブ関係を確認し、問題がなければ通常動作状態901となりカスケード接続を確立する。マスタとマスタないしスレーブとスレーブに設定されている場合は、カスケード接続を行なわない。カスケード接続が確立された場合、2つのミキサシステムのミキシングバスが連結され、全体としてch数が倍のミキサシステムとなる。
なお、上記ではバージョンチェックの例を説明したが、各ブロックで異常が検出された場合(例えば、何れかのブロックが接続断の状態になったり故障が検出された場合など)、そのブロックはNGになるので、バージョンチェックダイアログボックスの表示データは書き換えられる。例えば、IN Cで異常が検出されたら(これは致命的でない異常である)、コンソール300のメインCPU301は、IN C327に対して動作停止を指示するとともに、PNL_B308に対してIN C327との通信停止を指示する。また、図7の表示データ中、IN Cの状態をOKからNGに書き換える。別の例として、例えば、CTL305で異常が検出されたら(これは致命的な異常である)、コンソール300のメインCPU301は(接続されているコンソール、エンジン、ユニットを含めて)全ブロックに対して動作停止を指示する。
図10は、図3に示したコンソール300のメインCPU301のパワーオン時の処理を示す。ステップ1001で、初期設定をし、ステップ1002で自コンソールと接続されている第1エンジンの各ブロックのバージョンのチェックを行なう。なお、任意のブロックのバージョンは、そのブロックに問合せを発行することで得ることができる。ステップ1003でデュアルコンソールになっているか否か判定し、デュアルコンソールの場合は、ステップ1004で第2(スレーブ)コンソールの各ブロックのバージョンのチェックを行なう。ステップ1005でミラーがオンされているか否か判定し、ミラーオンの場合は、ステップ1006で第2エンジンの各ブロックのバージョンをチェックする。次に、ステップ1007でカスケードがオンされているか否か判定し、カスケードオンの場合は、ステップ1008で第2(スレーブ)システムの各ブロックのバージョンチェックを行なう。ステップ1009では、以上の各バージョンチェックで不整合(または異常)があるか否か判定する。不整合(または異常)が無いときは通常動作状態に移行し動作を継続する。不整合(または異常)があったときは、ステップ1010で致命的であるか否か判定し、致命的な場合は、ステップ1011で、接続されている各ブロックの動作停止を指示し、ステップ1012で、図7で説明したダイアログボックスを表示し、動作停止状態に移行する。致命的でないときは、ステップ1013で、問題があるブロックの停止と通信の切り離しを指示し、ステップ1014で、ダイアログボックスを表示し、一部動作状態に移行する。
図11は、図10のステップ1002,1004,1006,1008(および後述のステップ1201,1211)で実行するバージョンチェックの処理の詳細を示す。ステップ1101で、チェック対象のブロックのバージョン情報を収集する。ステップ1102で収集が完了したか否か判定し、完了していたらステップ1105に進む。バージョン情報の収集が完了していないときは、ステップ1103でタイムアウトするまでステップ1101からの処理を繰り返す。タイムアウトのときは、ステップ1104で、収集できなかった不足分の情報は取得不能と判定し、ステップ1105に進む。ステップ1105では、収集したバージョン情報が、基準となるCTLのバージョンに整合しているか否か判定する。
図12(a)は、コンソールがエンジンないし2台目のコンソールの新規接続を検出したときの処理を示す。ステップ1201で、新規に接続された機器の各ブロックのバージョンをチェックする。ステップ1202で、それらのバージョンが整合しているか否か判定する。整合しているときは通常動作状態に移行する。整合していないときは、ステップ1203で、接続されている各ブロックの動作停止を指示し、ステップ1204で、バージョンチェックダイアログボックスを表示し、新規に接続されたエンジンないしコンソールに関する表示を行なう。すなわち、エンジンが接続された場合は、それが1台目であればバージョンの整合状態を表示703および704に表示する。2台目のエンジンの接続はミラーオンに設定されている場合のみ検出され、その整合状態が表示708および709に表示される。また、2台目のコンソールの接続はデュアルコンソールオンの場合のみ検出され、その整合状態が表示707に表示される。ステップ1204の後、動作停止状態に移行する。すなわち、本実施形態では、コンソールとコンソール、ないしコンソールとエンジンで、バージョンの不整合が発生した場合は、それを致命的であると判断し、動作停止状態903に入るのである。この場合でも、不整合の発生したコンソールないしエンジンを切り離すことにより、通常動作状態901に復帰できる。
図12(b)は、ユニットの新規接続を検出したときの処理を示す。ステップ1211で、接続されたユニットのバージョンチェックを行なう。バージョンが整合していたときは、ステップ1212から通常動作状態に移行する。整合していないときは、ステップ1213で、該ユニットとの通信の切り離しを指示し、ステップ1214で、バージョンチェックダイアログボックスを表示し、新規に接続されたユニットに関する表示を行なう。すなわち、入力側のユニットが接続された場合には、表示705のそのユニットを接続した端子位置にバージョンの整合状態が表示され、出力側のユニットが接続された場合には、表示706の接続端子位置に表示される。ステップ1214の後、一部動作状態に移行する。すなわち、エンジンとユニットとの間のバージョンの不整合が発生した場合、それは致命的でないと判断され、不整合の発生したユニットが切り離されて一部動作状態に入る。
図12(c)は、各機器との接続断を検出したときの処理を示す。ステップ1221では、画面表示等により、接続が切れたことをユーザに通知する。ステップ1222では、接続の切れた機器が何であるかに応じてシステムの状態を更新する。例えば、2台のコンソールが接続されデュアルコンソールの動作をしている状態でコンソールBとの接続が切れた場合、コンソールAのみのシングルコンソールの状態に移行する。また、バージョンが不整合のユニットが物理的にエンジンから切り離された場合には、そのユニットに関する不整合が解消される。さらにまた、通常動作状態にあるコンソールとエンジンの間が切断された場合には、コンソールとしての通常動作は可能だがシステムとしてのミキシング動作は不能な状態に移行する。
次に、ステップ1223では、接続断が検出された時にバージョンチェックダイアログボックスを表示中であった場合、ないし、ステップ1222の更新後も何らかの不整合が残っている場合にはステップ1224に進み、それ以外の場合には通常動作状態へ移行する。
ステップ1224では、バージョンチェックダイアログボックスを表示し、接続の切れた機器に関する表示部分を更新する。例えば、デュアルコンソールのコンソールBとの接続が切れた場合には、相手側のコンソールに関する表示707を消去する。また、エンジンからユニットが切り離された場合は、表示705ないし706におけるそのユニットの表示部分を−に変更する。また、コンソールとエンジンが切り離された場合は、接続断となったエンジンの表示703をNGとする。ステップ1225では、バージョンチェックの結果に応じて、不整合が全くなければ通常動作状態に、一部不整合でも動作可能であれば一部動作状態に、不整合が致命的であれば動作停止状態に移行する。
このように、図7のダイアログボックスは、バージョンチェックが行なわれ、その結果バージョンの不整合が検出されたときに自動的に開かれる。また、ユーザがマウスによりバージョンチェックダイアログを呼び出す操作を行なうことも可能である。
なお、本実施形態は、コンソール、エンジン、およびユニットが分離されたミキサで説明したが、全てが一体のミキサや、コンソールとエンジン分離型のミキサに適用しても良い。また、バージョンチェックの基準はCTLにしたが、どのブロックを基準にしてもよい。
本実施形態では、制御プログラムのバージョンをその機能ブロックのバージョンとして説明したが、機能ブロックのボード自体にバージョンが付与されている場合でも本発明は適用可能である。例えば、機能ブロックとなるボードがCPU無しのハードウェアで構成されている場合、CPUを含むハードウェアとファームウェアの組み合わせで構成されている場合などは、ボード自体にバージョンが付けられているので、そのバージョンの整合性をチェックするようにしてもよい。
本実施形態のデュアルコンソール動作では、スレーブコンソールのバージョンが不整合であった場合、ミキサシステム(マスタコンソール+エンジン)が動作停止状態903に入るようになっていたが、シングルコンソールとして動作を継続する(一部動作状態902)ようにしてもよい。同様に、ミラーリング動作でも、接続された2台のエンジンのうちの一方が不整合であった場合に、動作停止状態903に入らずに、バージョンが整合する方のエンジンとコンソールで動作を継続する(一部動作状態902)ようにしてもよい。