(57)【要約】【課題】複数の機能ブロックを備え、各機能ブロック毎にＣＰＵとそのＣＰＵが実行する制御プログラムを備えているようなディジタル・ミキサにおいて、それら各機能ブロック毎のＣＰＵで動作する制御プログラムのバージョンを、適正にかつ容易に管理できるようにすることを目的とする。【解決手段】電源立ち上げ時に、システムの全ブロックのバージョンの整合性をチェックし、不整合がなければ動作を継続し、不整合があった場合はユーザに警告する。その警告において、不整合がシステムの動作にとって致命的である場合は動作を停止し、致命的でない場合はユーザに「バージョンの不整合を無視して動作を継続する」という内容の通知をした後、不整合と判定されたブロックを切り離して動作を継続する。【選択図】　図１０
2004056401.tif 000002
【特許請求の範囲】
【請求項１】
複数の機能ブロックが共働して動作することによりミキサとして動作するディジタル・ミキサであって、
電源立ち上げ時に、前記複数の機能ブロックのバージョンを取得する手段と、
前記取得した各機能ブロックのバージョンの整合性をチェックする手段と、
不整合がなければ動作を継続し、不整合があればユーザに警告する手段と
を備えたことを特徴とするディジタル・ミキサ。
【請求項２】
複数の機能ブロック毎にＣＰＵと該ＣＰＵが実行する制御プログラムを記憶した記憶手段を備え、該複数の機能ブロックが共働して動作することによりミキサとして動作するディジタル・ミキサであって、
電源立ち上げ時に、前記複数の機能ブロックの制御プログラムのバージョンを取得する手段と、
前記取得した各制御プログラムのバージョンの整合性をチェックする手段と、
不整合がなければ動作を継続し、不整合があればユーザに警告する手段と
を備えたことを特徴とするディジタル・ミキサ。
【請求項３】
請求項１または２に記載のディジタル・ミキサにおいて、
前記バージョンの不整合があった場合、その不整合が全体の動作にとって致命的であるか否か判定する手段と、
致命的であるときは動作を停止し、致命的でないときは、バージョンの不整合を無視して動作を継続する旨の通知を行なうとともに、不整合と判定された機能ブロックを切り離して動作を継続する手段とを
さらに備えたことを特徴とするディジタル・ミキサ。
【請求項４】
請求項１または２に記載のディジタル・ミキサにおいて、
新たな機器が接続された場合に、該機器の各機能ブロックのバージョンを取得してその整合性をチェックする手段と、
バージョンの不整合があった場合、その不整合が全体の動作にとって致命的であるか否か判定する手段と、
致命的であるときは動作を停止し、致命的でないときは、前記バージョンの不整合を無視して動作を継続する旨の通知を行なうとともに、不整合と判定された機能ブロックを切り離して動作を継続する手段とを
さらに備えたことを特徴とするディジタル・ミキサ。
【請求項５】
請求項１または２に記載のディジタル・ミキサにおいて、
前記各機能ブロックの異常を検出する手段と、
異常が検出された場合、その異常が全体の動作にとって致命的であるか否か判定する手段と、
致命的であるときは動作を停止し、致命的でないときは、前記異常を無視して動作を継続する旨の通知を行なうとともに、異常と判定された機能ブロックを切り離して動作を継続する手段とを
さらに備えたことを特徴とするディジタル・ミキサ。
【発明の詳細な説明】
【０００１】
【発明の属する技術分野】
この発明は、音響設備の集中的な制御を行なうディジタル・ミキサにおけるバージョン管理技術に関する。
【０００２】
【従来の技術】
従来より、コンサートや演劇などを行なう会場において音響設備を制御するためのディジタル・ミキサが知られている。そのような音響設備では、多数のマイクロフォンおよび多数のスピーカが使用され、効果音なども多種多様に使用される。ディジタル・ミキサは、多数の入力をどのようにミキシングして、どのように効果を付与し、どの出力系統に出力するか、などを集中的に制御する。
【０００３】
このようなディジタル・ミキサとして、コンソールとエンジンとを分離し、コンソールをオペレータ側に配置し、エンジンを演奏者側に配置し、それらの間をケーブルで接続するものが知られている（例えば、特開２０００−２９３１８０）。このようなミキサでは処理量が多いため、複数の機能ブロックに分けて、それぞれを１つあるいは複数のＣＰＵで制御するようになっている。複数の機能ブロックが共働してミキサとしての全体の動作を実現する。各機能ブロックのＣＰＵで実行するそれぞれの制御プログラム（いわゆるファームウェア）は、各機能ブロックごとに設けられた所定の記憶領域上に記憶されている。それらの各機能ブロック毎の複数のプログラムは、それぞれがバージョンを管理されており、それぞれバージョンアップすることができるようになっている。
【０００４】
また、特願２０００−３９６１０５では、コンソールとエンジン分離型のミキサにおいて、コンソールあるいはエンジンのいずれかにＰＣ（パーソナルコンピュータ）を接続し、そのＰＣでバージョンアッププログラムを実行し、コンソールがマスタとなって各機器のバージョンをチェックするシステムが記載されている。
【０００５】
【発明が解決しようとする課題】
上述のコンソールとエンジン分離型のミキサにおけるバージョンアップ方式では、一度のバージョンアップ操作で、そのとき接続されている機器の全機能ブロックの制御プログラムを同時にバージョンアップできる。
【０００６】
しかし、この方式を用いたとしても、ミキサの一部の機能ブロックのバージョンが他のブロックのバージョンと整合しない場合がある。例えば、バージョンアップ操作時に接続されていなかった機器内のブロックについてはバージョンアップされない。あるいはその機器を後から接続した場合、当該機器内のブロックだけバージョンが合わないことがある。また、一部のブロックの故障が検出され、そのブロックのボードを新しいものに交換した場合も、そのボードの制御プログラムのバージョンが他の部分と整合しない場合がある。制御プログラムのバージョンに不整合がある状態で動作させると、誤動作をしたり、場合によっては機器を壊してしまう可能性がある。
【０００７】
さらに、制御系統の機能ブロックについては、その中の一部が故障したとしても、全システムが動作停止してしまうという問題があった。すなわち、制御系統については、全ブロックが正常に動作していないと全体として正常動作できなかった。
【０００８】
この発明は、複数の機能ブロックを備え、各機能ブロック毎にＣＰＵとそのＣＰＵが実行する制御プログラムを備えているようなディジタル・ミキサにおいて、それら各機能ブロック毎のＣＰＵで動作する制御プログラムのバージョンを、適正にかつ容易に管理できるようにすることを目的とする。
【０００９】
【課題を解決するための手段】
上記目的を達成するため、この発明では、電源立ち上げ時に、システムの全ブロックのバージョンの整合性をチェックし、不整合がなければ動作を継続し、不整合があった場合はユーザに警告する。その警告において、不整合がシステムの動作にとって致命的である場合は動作を停止し、致命的でない場合はユーザに「バージョンの不整合を無視して動作を継続する」という内容の通知をした後、不整合と判定されたブロックを切り離して動作を継続する。
【００１０】
新たな機器が接続された場合にも、その接続された機器の各ブロックについてのバージョンチェックを行なう。動作上不可欠な機器が接続された場合、新たに接続された機器のバージョンの整合性をチェックし、不整合がなければ動作を継続し、不整合があった場合は動作を停止するとともにユーザに警告する。動作上不可欠でない機器が接続された場合、新たに接続された機器のバージョンの整合性をチェックし、不整合がなければ動作を継続し、不整合があった場合は該機器との連結動作を中止し動作を継続するとともにユーザに警告する。
【００１１】
また、この発明では、各ブロックについて故障を検出し、その故障がシステム動作にとって致命的である場合は動作を停止し、致命的でない場合はユーザに「故障を無視して動作を継続する」という内容の通知をした後、故障したブロックを切り離して動作を継続する。
【００１２】
【発明の実施の形態】
以下、図面を用いてこの発明の実施の形態を説明する。
【００１３】
図１は、この発明の実施の形態に係るディジタル・ミキサの構成例を示す。１０１はコンソール、１０２はエンジン、１０３は各ユニットを示す。コンソール１０１は、ユーザが操作する多数の操作子やディスプレイを備えた部分であり、ユーザによる操作指示を受け付け、エンジン１０２に指示を出す。エンジン１０２は、コンソール１０１からの指示に応じて、入力ユニットから入力したマイク信号やライン信号などを適宜ミキシングし、効果の付与などを行なって、出力ユニットに出力する。ユニット１０３としては、アナログ入力（ＡＩＮ）ユニット、アナログ出力（ＡＯＵＴ）ユニット、およびディジタル入出力（ＤＩ／Ｏ）ユニットが接続される。ＡＩＮユニットは、１ユニットに複数枚のアナログ／ディジタル（Ａ／Ｄ）変換ボードをマウントできるボックスであり、これによりマイク信号やライン信号を複数チャンネル（ｃｈ）分入力することができる。ＡＯＵＴユニットは、１ユニットに複数枚のディジタル／アナログ（Ｄ／Ａ）変換ボードをマウントできるボックスであり、複数ｃｈ分の出力を行なうことができる。ＤＩ／Ｏユニットは、１ユニットに複数枚のディジタル入出力（Ｉ／Ｏ）ボードをマウントできるボックスであり、複数ｃｈ分のディジタル入力およびディジタル出力を行なうことができる。
【００１４】
１台のエンジン１０２には、入力側に１０台のユニット（ＡＩＮユニットまたはＤＩ／Ｏユニット）を接続でき、出力側に６台のユニット（ＡＯＵＴユニットまたはＤＩ／Ｏユニット）を接続できる。１台のコンソール１０１、１台のエンジン１０２、および当該エンジン１０２に接続された複数のユニット１０３の組み合わせが、ミキサとしての１システムの最小構成となる。これにより、任意の入力ｃｈの入力信号を任意のミキシングｃｈに流し込んでミキシングし、任意に効果付与して、任意の出力ｃｈに出力する処理を、集中的に制御できる。
【００１５】
図１の▲１▼は、コンソール１０１にもう１台のコンソール１１１を接続し、デュアルコンソールとした例である。これにより、操作子の数を増やし多数のｃｈについての直接的な制御環境を構築したり、１台のコンソールが故障した場合に他の１台のコンソールで操作を続行できるようなフェイルセーフシステムを構築できる。デュアルコンソールとした場合、初めからあるシステムのコンソール１０１はマスタコンソール、後から接続したコンソール１１１はスレーブコンソールと呼ぶ。コンソール１０１内のＭＭの記載は、マスタシステムのマスタコンソールであることを示す。コンソール１１１内のＭＳの記載は、マスタシステムのスレーブコンソールであることを示す。
【００１６】
図１の▲２▼は、エンジンのミラーリングの例である。ミラーリングでは、マスタシステムのコンソール１０１とユニット１０３に、もう１台のエンジン１２１を接続する。ミラーリングでは、コンソール１０１からの制御により、エンジン１０２と１２１は同じ動作を行なう。通常は選択されているエンジン（例えば１０２）が使われるが、当該エンジンに故障があったとき、もう一方のエンジンに切り換えて処理を継続できる。
【００１７】
図１の▲３▼は、システムのカスケード接続の例である。コンソール１３１、エンジン１３２、およびユニット１３３を別システムとして用意し、マスタシステムのエンジン１０２とエンジン１３２とをカスケード接続する。コンソール１３１、エンジン１３２、およびユニット１３３でスレーブシステムを構成する。これにより、２台のエンジン１０２，１３２のそれぞれのミキシングバスが連結され、全体として入力ｃｈ数が倍のミキサシステムが構築できる。なお、コンソール１３１内のＳＭの記載は、スレーブシステムのマスタコンソールであることを示す。エンジン１３２内のＳの記載は、スレーブシステムのエンジンであることを示す。
【００１８】
図２は、１台のコンソールの外部パネルの例を示す。外部パネルは、２０１〜２１０の各セクションに分かれている。そのうち、セクション２０１〜２０５，２０７〜２０９は、スイッチ、フェーダ、およびロータリーエンコーダなどの複数の操作子を備えた部分である。
【００１９】
２０１，２０２，２０３，２０４は、それぞれが１つの入力ｃｈセクション（ＩＮ　Ａ〜Ｄ）である。入力ｃｈセクションは、複数入力ｃｈについての各種制御を行なう部分である。２０５はセレクテッド入力ｃｈセクション（ＩＮ　ＳＥＬ）であり、入力ｃｈセクション２０１〜２０４で選択した１つの入力ｃｈについて各種の制御を行なう部分である。表示器（ＬＣＤ）２０６は、各種の情報を表示する液晶表示装置とマウス操作子のインターフェースを備えた部分である。出力ｃｈセクション（ＯＵＴ）２０７は、複数の出力ｃｈについての各種制御を行なう部分である。セレクテッド出力ｃｈセクション（ＯＵＴ　ＳＥＬ）２０８は、出力ｃｈセクション２０７で選択した１つの出力ｃｈについて各種の制御を行なう部分である。シーンセクション（ＳＣＮ）２０９は、シーンに関する各種の制御を行なう部分である。シーンとは、ある場面での設定状態を示す。例えば、各場合毎の設定をシーンとして記憶させておき、それを呼び出すことにより設定した状態を簡単に再現できる。メーター（ＭＴＲ）２１０は、各ｃｈのレベルを示すメーターなどを備えた部分である。
【００２０】
図３に、１台のコンソールの内部構成例を示す。コンソール３００は、ＣＰＵ３０１、フラッシュメモリ（ＣＭＡＩＮ）３０２、ランダムアクセスメモリ（ＲＡＭ）３０３、通信制御部（Ｏ　ＣＯＭ）３０４、コントロール部（ＣＴＬ）３０５、表示器（ＬＣＤ）３０６、パネル制御部Ａ（ＰＮＬ　Ａ）３０７、パネル制御部Ｂ（ＰＮＬ　Ｂ）３０８、波形通信制御部（Ｗ　ＣＯＭ）３０９、通信制御部（ＣＯＭ）３１０、セレクテッド入力ｃｈセクション（ＩＮ　ＳＥＬ）３２１、セレクテッド出力ｃｈセクション（ＯＵＴ　ＳＥＬ）３２２、シーンセクション（ＳＣＮ）３２３、出力ｃｈセクション（ＯＵＴ）３２４、入力ｃｈセクション（ＩＮ　Ａ〜Ｄ）３２５〜３２８、メーター（ＭＴＲ）３２９、および接続バス３１１を備えている。なお、接続バス３１１は、１つのバスラインで図示したが、実際には各部が相互に情報をやり取りするための複数の方式を適用している。また、図２の各セクションと図３の各ブロックとで、対応する部分は同じ記号で図示している。例えば、図３のＩＮ　Ａ３２５は図２のセクション２０１に対応している。
【００２１】
図３において、太枠で図示したブロックは、それぞれが、その内部にＣＰＵおよびフラッシュメモリを備えた機能ブロックである。また、図３のコンソール３００自体も、太枠のブロックの部分以外は、ＣＰＵ３０１およびフラッシュメモリ（ＣＭＡＩＮ）３０２を備えた機能ブロックである。これらの各ブロック内のフラッシュメモリには、当該ブロックの動作を制御する制御プログラムが格納されており、当該ブロック内のＣＰＵがその制御プログラムを実行することにより、当該ブロックが所定の機能を果たすべく動作する。必要に応じて、各ブロック間で各種の情報がやり取りされる。各ブロックの制御プログラムは、バージョン管理されており、バージョンアッププログラムによりバージョンアップすることができる。なお、「バージョン」とは、厳密には各ブロック内に設けられているフラッシュメモリに格納されている制御プログラムのバージョンを意味するが、説明の簡単化のため、ブロックのバージョンという呼び方を使う。例えば、「ＣＴＬ３０５のバージョン」とは、ＣＴＬ３０５内に設けられているフラッシュメモリに格納されている制御プログラムのバージョンのことである。
【００２２】
図３の各部について説明する。ＣＰＵ３０１は、ＣＭＡＩＮ３０２に格納されている制御プログラムを実行することにより、このコンソール３００全体の動作を制御する。ＣＴＬ３０５は、ＣＰＵ３０１に対して各種の指示を与えてこのコンソール３００の動作を制御する。本実施形態では、ＣＴＬ３０５のバージョンを基準として、他の各ブロックのバージョンの整合性をチェックするものとする。ＬＣＤ３０６は、ＣＴＬ３０５の指示に応じて各種の情報を表示する。ＲＡＭ３０３は、ＣＰＵ３０１が実行するプログラムや使用する各種のデータを記憶するワーキング用メモリである。Ｏ　ＣＯＭ３０４は、外部のコンピュータやＭＩＤＩ機器と接続するインターフェースである。Ｏ　ＣＯＭ３０４にＰＣを接続し、当該ＰＣからコンソールやエンジンやユニットの各ブロックの制御プログラムをバージョンアップすることができる。
【００２３】
ＰＮＬ　Ａ３０７は、図２で説明したセクション２０５，２０８，２０９，２０７に対応するセクション３２１〜３２４を制御するためのパネル制御用ボードである。同様にＰＮＬ　Ｂ３０８は、図２で説明したセクション２０１〜２０４，２１０に対応するセクション３２５〜３２９を制御するためのパネル制御用ボードである。Ｗ　ＣＯＭ３０９は、各種波形信号に関する通信制御を行なう部分である。例えば、モニタ用マイクやモニタ用スピーカなどの各種の入出力端子はＷ　ＣＯＭ３０９に接続される。点線の矢印は波形信号の入出力を示す。ＣＯＭ３１０は、エンジン等との間で制御信号を授受する通信制御部である。デュアルコンソール時の２台目のコンソールとの通信も、エンジンとの通信と同様にＷ　ＣＯＭ３０９およびＣＯＭ３１０を介して行なわれる。
【００２４】
図４に、１台のエンジンの内部構成例を示す。エンジン４００は、ＣＰＵ４０１、フラッシュメモリ（ＥＭＡＩＮ）４０２、ＲＡＭ４０３、Ｏ　ＣＯＭ４０４、表示器４０５、信号処理部４０６、通信制御部（Ｂ　ＣＯＭ）４０７、通信制御部（ＣＯＭ）４０８、および接続バス４１１を備えている。信号処理部４０６は、複数のＤＳＰ４２１〜４２５を備えている。接続バ４１１は、１つのバスラインで図示したが、実際には各部が相互に情報をやり取りするための複数の方式を適用している。
【００２５】
図３と同様に図４でも、太枠で図示したブロックは、それぞれがその内部にＣＰＵおよびフラッシュメモリを備えた機能ブロックである。エンジン４００自体も、太枠のブロックの部分以外は、ＣＰＵ４０１およびフラッシュメモリ（ＥＭＡＩＮ）４０２を備えた機能ブロックである。これらの各ブロック内のフラッシュメモリには、当該ブロックの動作を制御する制御プログラムが格納され、それらはバージョンアッププログラムによりバージョンアップすることができることも同じである。エンジン４００の各ブロックのバージョン（ＥＭＡＩＮ４０２内の制御プログラムも含む）は、ＣＴＬ３０５のバージョンを基準として、バージョンチェックされる。
【００２６】
図４の各部について説明する。ＣＰＵ４０１は、ＥＭＡＩＮ４０２に格納されている制御プログラムを実行することにより、このエンジン４００全体の動作を制御する。特にＣＰＵ４０１は、ＣＯＭ４０８を介してコンソール３００から送られる制御信号や、Ｏ　ＣＯＭ４０４を介して送られる制御信号に基づいて、エンジン４００の動作を制御する。ＲＡＭ４０３は、ＣＰＵ４０１が実行するプログラムや使用する各種のデータを記憶するワーキング用メモリである。Ｏ　ＣＯＭ４０４は、外部のコンピュータやＭＩＤＩ機器と接続するインターフェースである。Ｏ　ＣＯＭ４０４にＰＣを接続し、当該ＰＣからコンソールやエンジンやユニットの各ブロックの制御プログラムをバージョンアップすることができる。表示器４０５は、エンジンの状態などを表示するＬＣＤである。Ｂ　ＣＯＭ４０７は、コンソール３００との間およびユニットとの間で波形信号や制御信号を授受する通信制御部である。ＣＯＭ４０８は、コンソール３００との間で制御信号を授受する通信制御部である。信号処理部４０６内のＤＳＰ４２１〜４２５は、ＣＰＵ４０１の指示に応じて、各種信号処理（ユニットから入力した波形のミキシングや効果付与処理など）を行なう。
【００２７】
図５は、図１で説明したユニット１０３（１３３）の例である。上述したように、アナログ入力（ＡＩＮ）ユニット５０１、アナログ出力（ＡＯＵＴ）ユニット５０２、およびディジタル入出力（ＤＩ／Ｏ）ユニット５０３がある。これらのユニットは、それぞれ、ＣＰＵおよびそのＣＰＵが実行する制御プログラムを記憶したフラッシュメモリを備えた機能ブロックである。その制御プログラムは、上述したコンソール３００やエンジン４００に接続したＰＣからバージョンアップできる。また、制御プログラムのバージョンは、ＣＴＬ３０５のバージョンを基準として、バージョンチェックされる。
【００２８】
図６は、この実施形態のミキサにおける信号の流れを示すブロック図である。６０１は、図１のユニット１０３，１３３のうち、信号入力用のユニット（図５の５０１，５０３）を示す。入力側および出力側のどちらにも複数のユニットを接続可能だが、図６では、まとめて１つの点線の矩形で示した。ＭＡＤｉｎ６２１は、マイク信号のアナログ／ディジタル変換入力ボードによる入力を示す。ＡＤｉｎ６２２は、ライン信号のアナログ／ディジタル変換入力ボードによる入力を示す。Ｄｉｎ６２３は、ディジタル入出力ボードによる入力を示す。以上の３種類のボードは、エンジンの入力側に接続されたＡＩＮユニット５０１またはＤＩ／Ｏユニット５０３に差し込むことによってボード単位で増設できる。６０２はコンソールからの入力を示す。トークバック入力６３１は、コンソールのオペレータが舞台側との指示連絡用に用いる入力である。パネル入力６３２は、コンソールから直接入力される効果音などの波形入力である。
【００２９】
入力パッチ６０３から出力パッチ６１１までの処理はエンジンが行なう。入力パッチ６０３は、上述した入力系統から、入力チャンネル（４８ｃｈ）への任意結線を行なう。その設定は、ユーザがコンソールで所定の画面を見ながら任意に行なうことができる。入力ｃｈ６０４の任意の信号を、４８本のＭＩＸバス６０５あるいはステレオバス（Ｓｔｅｒｅｏ＿Ｌ／Ｒ）６０６の任意のｃｈへ、選択的に出力できる。
【００３０】
ＭＩＸバス６０５は、入力ｃｈ６０４から入力する信号をミキシングする。ミキシングされた信号は、対応するＭＩＸ出力ｃｈ６０９に出力される。ステレオバス６０６は、入力ｃｈ６０４から入力する信号をミキシングする。ミキシングされたステレオ信号は、ステレオ出力ｃｈ６０８へ出力される。ステレオ出力ｃｈ６０８およびＭＩＸ出力ｃｈ６０９の出力は、それぞれ出力パッチ６１１およびマトリックス出力ｃｈ６１０へ出力される。マトリックス出力ｃｈ６１０は、ステレオ出力ｃｈ６０８とＭＩＸ出力ｃｈ６０９から任意の数の信号を選択的に入力することができ、選択入力されたこれらの信号をさらにミキシングすることができる。マトリックス出力ｃｈ６１０の出力は、出力パッチ６１１へ出力される。出力パッチ６１１は、上述した３種類の出力ｃｈ６０８〜６１０から、出力系統（ＤＡｏｕｔ、Ｄｏｕｔ）への任意の結線を行なう。
【００３１】
６１６は、図１のユニット１０３，１３３のうち、信号出力用のユニット（図５の５０２，５０３）を示す。ＤＡｏｕｔ６４１は、ディジタル／アナログ変換出力ボードへの出力を示す。Ｄｏｕｔ６４２は、ディジタル出力ボードへの出力を示す。以上の２種類のボードは、エンジンの出力側に接続されたＡＯＵＴユニット５０２またはＤＩ／Ｏユニット５０３に差し込むことによってボード単位で増設できる。
【００３２】
カスケード接続部６０７は、図１の▲３▼で説明したようにエンジンをカスケード接続する場合のインターフェースを示す。カスケード接続部６０７を介して別のエンジンと接続することにより、バス６０５，６０６を２つのエンジンで共有できる。モニタ用セレクタ６１２とモニタ用ミキサ６１３およびコンソール６１４のモニタ用ＤＡｏｕｔ６１５は、各ｃｈの信号モニタ用の機構である。
【００３３】
図７は、コンソールの表示器（ＬＣＤ）２０６に表示されるバージョンチェックダイアログボックスの表示例を示す。バージョンチェックダイアログボックスは、ミキサの立上げ時に自動的に各部のバージョンチェックを行なった結果何らかの不整合が検出された場合、あるいはユーザがバージョンチェックスイッチを押した場合に表示される。ミキサ立上げ時にバージョンの不整合が検出されなかったときはこのダイアログボックスは表示されない。またブロックの新規接続や接続断あるいは故障などの異常が検出されたときにも、バージョンチェックを行ない、その結果がバージョンチェックダイアログボックスとして表示される。
【００３４】
バージョンチェックダイアログボックス７００において、７０１は、図３に示したコンソール３００のＣＴＬ３０５のバージョンおよびその他のブロック全体のバージョンを示す。「ＣＴＬ　２．４４　ＯＫ」は、ＣＴＬ３０５のバージョンが２．４４で、他のブロックと整合性が取れていることを示す。「ＣＳ　２．４４　ＯＫ」は、ＣＴＬ３０５以外のコンソール（ＣＳ）３００全体のバージョンが２．４４で、ＣＴＬ３０５と整合性が取れていることを示す。７０２は、７０１で「ＣＳ　２．４４　ＯＫ」とまとめて表示したブロック、すなわちＣＴＬ３０５以外の各ブロックの詳細なバージョンと整合状態を示す。例えば、「ＣＭＡＩＮ　２．４３　ＯＫ」は、図３のＣＭＡＩＮ３０２に格納されている制御プログラムのバージョンが２．４３で、ＣＴＬ３０５と整合性が取れていることを示す。「ＭＴＲ　２．１１　ＯＫ」は、図３のＭＴＲ３２９のバージョンが２．１１で、ＣＴＬ３０５と整合性が取れていることを示す。以下同様にして、図３の太枠で示した各ブロックについて、ＣＴＬ３０５とのバージョンの整合状態が表示される。なお、整合が取れていないときは、ＯＫでなくＮＧと表示される。７０２で表示する各ブロックのうち、１つでもＮＧのブロックがあった場合は、表示７０１のＣＳの整合状態もＮＧとなる。
【００３５】
７０３は、図４に示したエンジン（ＥＧ）４００の全体としてのバージョンと整合状態を示す。７０４は、エンジン４００内部の各ブロックの個別のバージョンとその整合状態を示す。７０４で表示する各ブロックのうち、１つでもＮＧのブロックがあった場合は、表示７０３のＥＧの整合状態もＮＧとなる。７０５と７０６は、エンジン４００に接続されたユニット（図５）のバージョンと整合状態を示す。表示７０５の中で１〜１０とあるのは、エンジンの入力側のユニット接続用端子を示す。ここでは２番目の接続用端子にＡＩＮユニット５０１が接続され、３番目の接続用端子にＤＩ／Ｏユニット５０３が接続されている。表示７０６の中で１〜６とあるのは、エンジンの出力側のユニット接続用端子を示す。ここでは３番目の接続用端子にＤＩ／Ｏユニット５０３が接続され、５番目の接続用端子にＡＯＵＴユニット５０２が接続されている。バージョンや整合状態の表示の仕方は、表示７０１〜７０４と同じである。なお、−はその接続用端子にユニットが接続されていないことを示す。
【００３６】
７０７は、図１の▲１▼で説明したデュアルコンソールの場合の、メインコンソールＡ１０１でのスレーブコンソールＢ１１１についての表示である。デュアルコンソールの場合のみ表示されるので点線で図示した（後述する７０８〜７１０も同様）。表示７０７のうち「ＣＴＬ　２．４４　ＯＫ」はスレーブコンソールＢ１１１内のＣＴＬ３０５のバージョンと整合状態を示す。「ＣＳ　２．４４　ＯＫ」は、スレーブコンソールＢ１１１内のＣＴＬ３０５以外のブロックのバージョンと整合状態を示す。これらの整合状態は、マスタコンソールＡ１０１内のＣＴＬ３０５のバージョンを基準とするものである。なお、スレーブ側の各ブロックの個別のバージョンと整合状態（マスタコンソールの７０２の表示と同様の表示）は、マスタ側には表示されず、スレーブコンソールＢ１１１の表示器に表示される。
【００３７】
７０８，７０９は、図１の▲２▼で説明したエンジンのミラーリングを行なった場合の表示である。追加したエンジンＢ１２１について、７０３，７０４と同様の表示がなされる。なお、追加したエンジンＢ１２１についての表示７０８，７０９における整合状態は、マスタコンソールＡ１０１内のＣＴＬ３０５のバージョンを基準とするものである。
【００３８】
７１０は、図１の▲３▼で説明したシステムのカスケード接続を行なった場合の表示である。スレーブシステムのエンジンＣ１３２について、７０３の表示と同様の表示７１０がなされる。カスケード接続したエンジンＣ１３２の整合状態は、マスタコンソールＡ１０１内のＣＴＬ３０５のバージョンを基準とするものである。スレーブ側のコンソールＣ１３１やユニット１３３については、スレーブシステムのマスタコンソールＣ１３１の表示器に表示される。
【００３９】
７２１は、メッセージ表示領域である。ここではバージョンチェックの結果が正常であった場合のメッセージ表示例を図示した。７２２は、動作を続行する際に押下するＯＫボタンの表示である。
【００４０】
図７ではバージョンチェック結果が正常の場合の表示例を示したが、１つでも整合しないバージョンのブロックが検出された場合にはその旨が表示される。整合しないブロックが検出された場合、それがミキサ全体の動作を継続する上で致命的となる場合と致命的とならない場合がある。図８の８０１と８０２は、致命的でない場合のメッセージ表示領域７２１の表示例である。８０１は当該ブロックから応答が無い場合、８０２は当該ブロックから応答はあったがそのバージョンが（基準のブロックのバージョンに対して）整合しない場合のメッセージ例である。８０１と８０２の場合は、ＯＫボタン７２２が表示され、オペレータがこれを押下すると、当該ブロックとの通信を切り離して動作を継続する。強制的に動作停止するためのボタンを用意してもよい。図８の８０３と８０４は、致命的である場合のメッセージ表示領域７２１の表示例である。これらの場合は、ＯＫボタンは表示されず以後の動作を停止する。
【００４１】
図９は、本ミキサにおける状態遷移を示す。電源オン時に全ブロックが正常でバージョンの不整合もない場合は通常動作状態９０１となる。電源オン時に上記致命的なブロックの異常またはバージョン不整合が検出された場合は動作停止状態９０３となる。電源オン時に上記致命的でないブロックの異常またはバージョン不整合が検出された場合は一部動作状態９０２となる。これらの状態は、ミキサ動作中も相互に遷移する。例えば、通常動作状態９０１で正常動作している途中で、あるブロックに異常が発生したり、あるブロックが新規追加されたりしたときは、必要に応じて電源オン時と同様にバージョンチェックを行ない、その結果を表示して、一部動作状態９０２や動作停止状態９０３に遷移する。同様に、一部動作状態９０２や動作停止状態９０３のとき、異常またはバージョン不整合のブロックのボードを交換するなどして正常化することにより、通常動作状態９０１に遷移する。
【００４２】
以下、各ブロックのバージョンチェックについての具体例を説明する。
【００４３】
まず、メインシステムのコンソール３００（図３）の各ブロックのバージョンチェックの具体例について説明する。メインコンソール３００においては、基準となるＣＴＬ３０５のバージョンに対して、ＣＭＡＩＮ３０２、ＭＴＲ３２９、ＰＮＬ　Ａ３０７、ＰＮＬ　Ｂ３０８、およびＬＣＤ３０６の何れかのブロック（致命的なブロック）のバージョンが不整合（または異常）である場合、動作停止状態９０３となる。メインコンソール３００のこれら以外のブロック（致命的でないブロック）にバージョン不整合（または異常）が検出されたときは、一部動作状態９０２となる。
【００４４】
なお、マスタコンソール３００のＣＴＬ３０５のバージョンを基準として判断される各ブロックのバージョンの整合性の判断基準は、所定の記憶領域（例えば、ＣＭＡＩＮ３０２でよい）に記憶されているものとする。例えば、図７の表示７０１，７０２では、ＣＴＬのバージョン２．４４に対し、ＭＴＲのバージョンが２．１１であるが、上記判断基準にＣＴＬのバージョン２．４４に整合するＭＴＲのバージョンが記載されており、これを参照してＭＴＲのバージョン２．１１が整合していると判断している。また、致命的なブロックか否かを判断する基準についても、同様に所定の記憶領域（ＣＭＡＩＮ３０２でよい）に記憶されているものとする。
【００４５】
次に、ユニット（図５）のバージョンチェックの具体例について説明する。電源がオンされたとき、およびエンジンでユニットの新規接続を検出したとき、当該ユニットのバージョンチェックを行なう。エンジンのユニット接続用端子には、ユニットを接続してもしなくてもよいので、ユニットが接続されていないからといってＮＧにはならない。接続されたユニットのバージョンが不整合のとき、その部分をＮＧとしてダイアログボックス（図７）を表示し、当該ユニットとの通信を切り離して一部動作状態９０２となる。
【００４６】
デュアルコンソールの場合のバージョンチェックの具体例について説明する。デュアルコンソールが設定されている場合、電源がオンされたとき、および第２（スレーブ）コンソールの接続が検出されたときに、相手コンソールのバージョンチェックを行なう。相手コンソールが接続されていない場合は、ＮＧとはせずにシングルコンソール動作（当該コンソールのみで動作続行）を行なう。相手コンソールが接続されており、かつバージョンが不整合のときは、ＮＧとしてダイアログボックスを表示し、動作停止状態９０３となる。その後に相手コンソールが非接続になったら、ダイアログボックスを消去し、シングルコンソール動作を再開する。相手コンソールが接続されており、かつバージョンが整合するときは、ＯＫであるので、直ちに通常動作状態９０１となりデュアルコンソール動作を開始する。デュアルコンソール動作では、まず、自分と相手のマスタスレーブ関係を確認し、問題がなければデュアルコンソール接続を確立する。マスタとマスタないしスレーブとスレーブに設定されている場合は、デュアルコンソール接続を行なわない。デュアルコンソール接続が確立された場合、第１コンソールと第２コンソールの両方で、接続されたエンジンのミキシング処理を制御することができる。
【００４７】
ミラーリングの場合のバージョンチェックの具体例について説明する。ミラーリングが設定されている場合、電源がオンされたとき、および第２エンジンの接続検出時に、第２エンジンのバージョンチェックを行なう。バージョンチェック動作は、基本的に上記デュアルコンソールの場合と同じであり、整合しないエンジンが接続されている間は動作停止状態９０３になる。ミラー動作では、２つのエンジンにマスタスレーブ関係は無いので、バージョンさえ整合すれば直ちに通常動作状態９０１となりミラー接続が確立される。ミラー接続が確立された場合、２つのエンジンは、コンソールからの制御により、相互に同じ動作を行なう。選択されているエンジンが故障したとき、自動ないし手動で他方のエンジンに切り換えられる。
【００４８】
カスケードの場合のバージョンチェックの具体例について説明する。カスケードが設定されている場合、電源がオンされたとき、および第２エンジンの接続検出時に、第２エンジンのバージョンチェックを行なう。バージョンチェック動作は、基本的に上記デュアルコンソールの場合と同じである。カスケード動作では、まず、自分と相手のマスタスレーブ関係を確認し、問題がなければ通常動作状態９０１となりカスケード接続を確立する。マスタとマスタないしスレーブとスレーブに設定されている場合は、カスケード接続を行なわない。カスケード接続が確立された場合、２つのミキサシステムのミキシングバスが連結され、全体としてｃｈ数が倍のミキサシステムとなる。
【００４９】
なお、上記ではバージョンチェックの例を説明したが、各ブロックで異常が検出された場合（例えば、何れかのブロックが接続断の状態になったり故障が検出された場合など）、そのブロックはＮＧになるので、バージョンチェックダイアログボックスの表示データは書き換えられる。例えば、ＩＮ　Ｃで異常が検出されたら（これは致命的でない異常である）、コンソール３００のメインＣＰＵ３０１は、ＩＮ　Ｃ３２７に対して動作停止を指示するとともに、ＰＮＬ＿Ｂ３０８に対してＩＮ　Ｃ３２７との通信停止を指示する。また、図７の表示データ中、ＩＮ　Ｃの状態をＯＫからＮＧに書き換える。別の例として、例えば、ＣＴＬ３０５で異常が検出されたら（これは致命的な異常である）、コンソール３００のメインＣＰＵ３０１は（接続されているコンソール、エンジン、ユニットを含めて）全ブロックに対して動作停止を指示する。
【００５０】
図１０は、図３に示したコンソール３００のメインＣＰＵ３０１のパワーオン時の処理を示す。ステップ１００１で、初期設定をし、ステップ１００２で自コンソールと接続されている第１エンジンの各ブロックのバージョンのチェックを行なう。なお、任意のブロックのバージョンは、そのブロックに問合せを発行することで得ることができる。ステップ１００３でデュアルコンソールになっているか否か判定し、デュアルコンソールの場合は、ステップ１００４で第２（スレーブ）コンソールの各ブロックのバージョンのチェックを行なう。ステップ１００５でミラーがオンされているか否か判定し、ミラーオンの場合は、ステップ１００６で第２エンジンの各ブロックのバージョンをチェックする。次に、ステップ１００７でカスケードがオンされているか否か判定し、カスケードオンの場合は、ステップ１００８で第２（スレーブ）システムの各ブロックのバージョンチェックを行なう。ステップ１００９では、以上の各バージョンチェックで不整合（または異常）があるか否か判定する。不整合（または異常）が無いときは通常動作状態に移行し動作を継続する。不整合（または異常）があったときは、ステップ１０１０で致命的であるか否か判定し、致命的な場合は、ステップ１０１１で、接続されている各ブロックの動作停止を指示し、ステップ１０１２で、図７で説明したダイアログボックスを表示し、動作停止状態に移行する。致命的でないときは、ステップ１０１３で、問題があるブロックの停止と通信の切り離しを指示し、ステップ１０１４で、ダイアログボックスを表示し、一部動作状態に移行する。
【００５１】
図１１は、図１０のステップ１００２，１００４，１００６，１００８（および後述のステップ１２０１，１２１１）で実行するバージョンチェックの処理の詳細を示す。ステップ１１０１で、チェック対象のブロックのバージョン情報を収集する。ステップ１１０２で収集が完了したか否か判定し、完了していたらステップ１１０５に進む。バージョン情報の収集が完了していないときは、ステップ１１０３でタイムアウトするまでステップ１１０１からの処理を繰り返す。タイムアウトのときは、ステップ１１０４で、収集できなかった不足分の情報は取得不能と判定し、ステップ１１０５に進む。ステップ１１０５では、収集したバージョン情報が、基準となるＣＴＬのバージョンに整合しているか否か判定する。
【００５２】
図１２（ａ）は、コンソールがエンジンないし２台目のコンソールの新規接続を検出したときの処理を示す。ステップ１２０１で、新規に接続された機器の各ブロックのバージョンをチェックする。ステップ１２０２で、それらのバージョンが整合しているか否か判定する。整合しているときは通常動作状態に移行する。整合していないときは、ステップ１２０３で、接続されている各ブロックの動作停止を指示し、ステップ１２０４で、バージョンチェックダイアログボックスを表示し、新規に接続されたエンジンないしコンソールに関する表示を行なう。すなわち、エンジンが接続された場合は、それが１台目であればバージョンの整合状態を表示７０３および７０４に表示する。２台目のエンジンの接続はミラーオンに設定されている場合のみ検出され、その整合状態が表示７０８および７０９に表示される。また、２台目のコンソールの接続はデュアルコンソールオンの場合のみ検出され、その整合状態が表示７０７に表示される。ステップ１２０４の後、動作停止状態に移行する。すなわち、本実施形態では、コンソールとコンソール、ないしコンソールとエンジンで、バージョンの不整合が発生した場合は、それを致命的であると判断し、動作停止状態９０３に入るのである。この場合でも、不整合の発生したコンソールないしエンジンを切り離すことにより、通常動作状態９０１に復帰できる。
【００５３】
図１２（ｂ）は、ユニットの新規接続を検出したときの処理を示す。ステップ１２１１で、接続されたユニットのバージョンチェックを行なう。バージョンが整合していたときは、ステップ１２１２から通常動作状態に移行する。整合していないときは、ステップ１２１３で、該ユニットとの通信の切り離しを指示し、ステップ１２１４で、バージョンチェックダイアログボックスを表示し、新規に接続されたユニットに関する表示を行なう。すなわち、入力側のユニットが接続された場合には、表示７０５のそのユニットを接続した端子位置にバージョンの整合状態が表示され、出力側のユニットが接続された場合には、表示７０６の接続端子位置に表示される。ステップ１２１４の後、一部動作状態に移行する。すなわち、エンジンとユニットとの間のバージョンの不整合が発生した場合、それは致命的でないと判断され、不整合の発生したユニットが切り離されて一部動作状態に入る。
【００５４】
図１２（ｃ）は、各機器との接続断を検出したときの処理を示す。ステップ１２２１では、画面表示等により、接続が切れたことをユーザに通知する。ステップ１２２２では、接続の切れた機器が何であるかに応じてシステムの状態を更新する。例えば、２台のコンソールが接続されデュアルコンソールの動作をしている状態でコンソールＢとの接続が切れた場合、コンソールＡのみのシングルコンソールの状態に移行する。また、バージョンが不整合のユニットが物理的にエンジンから切り離された場合には、そのユニットに関する不整合が解消される。さらにまた、通常動作状態にあるコンソールとエンジンの間が切断された場合には、コンソールとしての通常動作は可能だがシステムとしてのミキシング動作は不能な状態に移行する。
【００５５】
次に、ステップ１２２３では、接続断が検出された時にバージョンチェックダイアログボックスを表示中であった場合、ないし、ステップ１２２２の更新後も何らかの不整合が残っている場合にはステップ１２２４に進み、それ以外の場合には通常動作状態へ移行する。
【００５６】
ステップ１２２４では、バージョンチェックダイアログボックスを表示し、接続の切れた機器に関する表示部分を更新する。例えば、デュアルコンソールのコンソールＢとの接続が切れた場合には、相手側のコンソールに関する表示７０７を消去する。また、エンジンからユニットが切り離された場合は、表示７０５ないし７０６におけるそのユニットの表示部分を−に変更する。また、コンソールとエンジンが切り離された場合は、接続断となったエンジンの表示７０３をＮＧとする。ステップ１２２５では、バージョンチェックの結果に応じて、不整合が全くなければ通常動作状態に、一部不整合でも動作可能であれば一部動作状態に、不整合が致命的であれば動作停止状態に移行する。
【００５７】
このように、図７のダイアログボックスは、バージョンチェックが行なわれ、その結果バージョンの不整合が検出されたときに自動的に開かれる。また、ユーザがマウスによりバージョンチェックダイアログを呼び出す操作を行なうことも可能である。
【００５８】
なお、本実施形態は、コンソール、エンジン、およびユニットが分離されたミキサで説明したが、全てが一体のミキサや、コンソールとエンジン分離型のミキサに適用しても良い。また、バージョンチェックの基準はＣＴＬにしたが、どのブロックを基準にしてもよい。
【００５９】
本実施形態では、制御プログラムのバージョンをその機能ブロックのバージョンとして説明したが、機能ブロックのボード自体にバージョンが付与されている場合でも本発明は適用可能である。例えば、機能ブロックとなるボードがＣＰＵ無しのハードウェアで構成されている場合、ＣＰＵを含むハードウェアとファームウェアの組み合わせで構成されている場合などは、ボード自体にバージョンが付けられているので、そのバージョンの整合性をチェックするようにしてもよい。
【００６０】
本実施形態のデュアルコンソール動作では、スレーブコンソールのバージョンが不整合であった場合、ミキサシステム（マスタコンソール＋エンジン）が動作停止状態９０３に入るようになっていたが、シングルコンソールとして動作を継続する（一部動作状態９０２）ようにしてもよい。同様に、ミラーリング動作でも、接続された２台のエンジンのうちの一方が不整合であった場合に、動作停止状態９０３に入らずに、バージョンが整合する方のエンジンとコンソールで動作を継続する（一部動作状態９０２）ようにしてもよい。
【００６１】
【発明の効果】
以上説明したように、この発明によれば、電源立ち上げ時に、システムの全ブロックのバージョンの整合性をチェックし、不整合がなければ動作を継続し、不整合があった場合はユーザに警告するようにしているので、バージョンの不整合を電源立ち上げ時に即時に確認できる。また、不整合が致命的である場合は動作を停止し、致命的でない場合はその不整合を無視して動作を継続する旨の通知をした後、不整合と判定されたブロックを切り離して動作を継続するので、最低限動作を継続できる場合は継続することができる。新規に機器を接続した場合や故障などの異常が発生した場合も、致命的な不整合が起きていなければ、一部動作状態で継続動作するので、制限があっても動作継続したい場合には便宜である。
【図面の簡単な説明】
【図１】この発明の実施の形態に係るディジタル・ミキサの構成例を示すブロック図
【図２】１台のコンソールの外部パネルの例を示す図
【図３】１台のコンソールの内部構成例を示すブロック図
【図４】１台のエンジンの内部構成例を示すブロック図
【図５】ユニットの例を示す図
【図６】ミキサにおける信号の流れを示すブロック図
【図７】バージョンチェックダイアログボックスの表示例を示す図
【図８】メッセージ表示領域の表示例を示す図
【図９】本ミキサにおける状態遷移を示す図
【図１０】パワーオン時の処理を示すフローチャート図
【図１１】バージョンチェックの処理のフローチャート図
【図１２】新規接続や接続断を検出したときの処理のフローチャート図
【符号の説明】
１０１…コンソール、１０２…エンジン、１０３…各ユニット。
【図１】
2004056401.tif 000003
【図２】
2004056401.tif 000004
【図３】
2004056401.tif 000005
【図４】
2004056401.tif 000006
【図５】
2004056401.tif 000007
【図６】
2004056401.tif 000008
【図７】
2004056401.tif 000009
【図８】
2004056401.tif 000010
【図９】
2004056401.tif 000011
【図１０】
2004056401.tif 000012
【図１１】
2004056401.tif 000013
【図１２】
2004056401.tif 000014