以下、この発明の一実施例について図面を参照して詳細に説明する。この実施例では、この発明を、パワーアンプ装置と、該パワーアンプ装置をリモート制御するためのパーソナルコンピュータとを含んで構成される音響システムに適用した例について説明する。なお、音響システムは、PAシステム、あるいは、SRシステムなどと一般的に呼称され、例えば、音楽演奏会場、劇場、あるいは各種ホールなどの大面積建造物等に設備される大規模な音響システムを想定している。
図1は、この発明の一実施例に係る音響システムのモジュール構成例を示すブロック図である。図1に示す音響システムは、複数台のパワーアンプ装置(以下単に「アンプ」)1と複数台のパーソナルコンピュータ(PC)2を含んで構成される。複数のアンプ1と複数のPC2とは、例えばイーサネット(登録商標)ケーブルなど汎用のネットワークケーブルを用いて物理的に接続され、ローカルエリアネットワーク(LAN)を形成している。ネットワーク上の各装置の間では、TCP/IPプロトコルに従う通常のデータ通信が可能であるが、更に、同じネットワークを用いてオーディオ信号をリアルタイム伝送できるようにしてもよい。その場合、そのデータ伝送フォーマットは、例えばCobraNet(登録商標)など、従来から知られる適宜のデータ伝送フォーマットを適用してよい。
アンプ1は、外部から入力された音響信号に電力増幅を含む音響信号処理を施し、該処理した音響信号を、図示外のスピーカへ出力する音響機器である。本実施例にかかる音響システムでは、アンプ1として、ネットワーク接続可能であり、該ネットワークを介して接続された制御装置(PC2)による制御を受けることができる機種が適用される。この実施例では、アンプ1の筐体は、専用の棚(ラック)に登載可能な、いわゆるラックマウント式の形態を想定している。複数台のアンプ1をラックに登載することは、アンプ1群の運搬や設置等に際して有利である。このため、例えば、音響機器賃貸業者が複数台のラックマウント式のパワーアンプ装置を借り手に貸すときには、複数のアンプをラックに登載した状態で貸し出すことが多い。
PC2は、例えば「Windows(商標)」等のオペレーティングシステムを登載した汎用のパーソナルコンピュータであって、ネットワークを介して接続されたアンプ1をリモート制御するための専用のソフトウェアプログラム(以下、これをリモート制御ソフトと呼ぶ)を実装している。リモート制御ソフトは、PC2のオペレーティングシステム上で動作するアプリケーションプログラムである。リモート制御ソフトを実行することにより、PC2はネットワークを介して接続されたアンプ1を制御する制御装置として機能する。すなわち、PC2を操作するユーザは、リモート制御ソフトが提供する機能を用いて、ネットワーク上の複数のアンプ1の動作を制御したり、該複数のアンプ1の動作状況をモニタしたりすることができる。図1では、複数台のPC2がネットワーク上に存在しており、複数のPC2のそれぞれでリモート制御ソフトが起動される。
リモート制御ソフトによるアンプ1のリモート制御は、詳しくは後述する通り、「エリア」単位で行われる。「エリア」には1又は複数のアンプ1を登録することができ、エリアに登録された1又は複数のアンプ1が、そのエリアにおける制御対象となる。図1において、「エリア」に該当する範囲を点線で囲んでいる。符号3Aで示す「エリア1」は、2台のアンプ1と1台のPC2が含まれている。符号3Bで示す「エリア2」は、2台のアンプ1と2台のPC2が含まれている。また、ネットワーク上には、エリアに登録されないアンプ1も存在しうる。エリアに登録されないアンプ1は、後述するマッチング処理によりPC2のリモート制御ソフトがその存在を認識(検出)しても、該ソフトによる制御を受けることはできない。
なお、図1に示す音響システムには、アンプ1およびPC2のほかにも、ネットワークI/Oを有さないタイプのアンプ1をネットワークに接続するための専用のインターフェース装置(ACD)など、図示外の機器が含まれうるが、ここでは、便宜上、それらの図示及び説明を省略した。なお、専用のインターフェース装置を介してパワーアンプ装置をリモート制御用のネットワークに接続することは、従来から知られている技術である。なお、ネットワークに、アンプ以外の音響機器、例えばディジタルミキサ、レコーダ、エフェクタ、A/D変換装置、D/A変換装置、あるいはシンセサイザなどを接続詞、PC2のリモート制御ソフトで、アンプとともにそれらの音響機器も一括制御するようにしてもよい。
図2は図1に示すアンプ1のハードウェア構成の概要を説明するブロック図である。アンプ1は、CPU10と、ROM及びRAMからなるメモリ11とを含む制御部と、DA変換器及びAD変換器を含むオーディオI/O(D/A、A/D)12と、信号処理部(DSP)13と、電力増幅部(AMP)14と、操作子や表示器等のユーザインターフェース(UI)15とネットワーク通信インターフェース(通信I/F)16とを含み、各部がデータ及び通信バス10Bを介して接続される。通信I/F16は、イーサネット(登録商標)規格に準拠するネットワークインターフェースである。アンプ1は通信I/F16を介してネットワークに接続し、同ネットワークを介して接続されたPC2との間で各種データの通信を行う。また、アンプ1には、ユーザインターフェース15として、音量レベル調整ツマミ等の物理操作子、アンプ1のメモリ11に後述するエリア内IDと、エリアIDを設定するための操作子、あるいはアンプ1の動作状態を示す各種表示器等を含む操作パネルが備わる。なお、図2においては、外部ソースや外部シンクとオーディオI/O12との接続ライン、および、電力増幅部14と外部スピーカとの接続ラインが省略されている。
CPU10は、メモリ(ROM又はRAM)11に記憶された制御プログラムを実行し、アンプ1の動作を制御する。メモリ11には、CPU10が実行する各種制御プログラムや、アンプ1が行う音響信号処理(DSP13及び電力増幅部14の動作)に使用する動作データ等の各種データ(後述の図6を参照)が格納される。
オーディオI/O12には所定の複数系統の音響信号入力端子が含まれる。アンプ1にはオーディオI/O12を介して外部ソース(図示せず)から該所定の複数系統のアナログ波形信号またはディジタル波形データが入力される。このときアナログ波形信号はAD変換器によりディジタル波形データに変換される。該外部から入力された複数系統の音響信号はDSP13に供給される。
DSP13は、前記所定の複数系統の音響信号入力端子のそれぞれに対応する音響信号処理チャンネルを備え、各チャンネルに入力されたディジタル波形データに対して、CPU10の指示に基づく音響信号処理を、チャンネル毎に行う。DSP13が行う音響信号処理は、例えば、クロスオーバ処理、ディレイ処理、イコライザ処理、リミッタ処理或いはハウリング抑制処理などである。これら音響信号処理は、音響信号の特性調整や、電力増幅部14やスピーカの保護を行うための処理であって、その内容はメモリ11に格納された動作データにより制御される。
DSP13の出力信号は、電力増幅部14内の入力部のDA変換器(図示せず)でチャンネル別にアナログ波形信号に変換され、電力増幅部14内の電力増幅回路(図示せず)に供給される。電力増幅回路は、前記アナログ波形信号に変換されたDSP13の出力信号をチャンエル別に電力増幅する。該増幅されたアナログ波形信号は、電力増幅部14のの備える所定の複数系統の音響信号出力端子を介して外部スピーカ(図示せず)へ出力され、該出力されたアナログ波形信号によりスピーカが駆動される。なお、基本的には、1系統の音響信号出力端子は1つのスピーカに接続される。また、電力増幅部14は、電力増幅部14の動作状態を示すデータ(例えば、出力段の温度、入力や出力の信号レベル、電源電圧、出力電圧、出力電流、負荷インピーダンス、あるいはプロテクションの状態など)をDSP13に供給する。該動作状態を示すデータは、DSP13において、電力増幅部14やスピーカの保護のための信号処理に利用される。
なお、図2においてDSP13を備えるアンプ1の構成例を示したが、アンプ1は、オーディオI/O12やDSP13を備えない機種(電力増幅部14がアナログ信号を直接入出力する機種)であっても、ネットワークを介して制御装置(PC2)と接続され、該制御装置からリモート制御を受けることができる機種であれば、この発明の音響システムに適用可能である。
図3はPC2のハードウェア構成例を示すブロック図である。PC2は、既に述べたとおり汎用のパーソナルコンピュータであって、CPU20、ROM及びRAMを含むメモリ21と、ハードディスクドライブ(HDD)22と、ネットワーク通信インターフェース(通信I/F)23と、ディスプレイ、マウス操作子及びキーボード等を含むユーザインターフェース24とを含んで構成される。アンプ1をリモート制御するためのリモート制御ソフトは、HDD22に記憶されてよい。リモート制御ソフトは、当該リモート制御ソフトを実行すべきときにHDD22からメモリ21に読み込まれる。CPU20が前記メモリ21に読み込んだリモート制御ソフトを実行することで、PC2はネットワーク上のアンプ1群をリモート制御する制御装置として機能する。
図4は、リモート制御ソフトがPC2のメモリ21及びHDD22に用意するデータの構成例を示す図である。図4に示す通り、データは階層構造で管理されており、この階層構造はリモート制御ソフトによる音響システムの管理構造に対応する。
符号30で示す階層には、コントローラID、プロジェクトライブラリ及びカレントプロジェクトのデータがある。コントローラIDは、例えば当該PC2のMACアドレス(Media Access Control address)、当該PC2のIPアドレス、又は、PC2に登載されたリモート制御ソフトを特定するID情報、若しくは、それらを組み合わせた情報など、ネットワーク上で、このPC2又は当該PC2に登載されたリモート制御ソフトを特定するためのID情報である。このコントローラIDは例えばメモリ(RAM)21に記憶される。
プロジェクトライブラリには、符号31で示すとおり、複数のプロジェクトファイル(図において「プロジェクトファイル1」「プロジェクトファイル2」…)が格納されている。プロジェクトライブラリの記憶領域は、例えばHDD22に設けられていてよい。1つのプロジェクトファイルには、ネットワークに接続されたアンプ1群を制御するために必要な各種データが格納される。1つのプロジェクトファイルに格納されたデータ群が、1つのプロジェクトを構成する。また、カレントプロジェクトは、現在リモート制御ソフトに立ち上げている1つのプロジェクトファイルのデータ群を格納する記憶領域であって、例えばメモリ(RAM)21に用意される。リモート制御ソフトの実行時には、プロジェクトライブラリからカレントプロジェクトに、1つのプロジェクトファイルがロードされる。カレントプロジェクトにロードされたプロジェクトファイルに格納されたプロジェクトが、リモート制御ソフトの制御対象のプロジェクト(カレントプロジェクト)である。
1つのプロジェクトファイルには、符号32に示すように、プロジェクトID、ユーザ情報、プロジェクト名、および複数のエリア情報33が含まれている。プロジェクトIDは、プロジェクトライブリ中の複数のプロジェクトファイルの中から1つのプロジェクトを特定するためのID情報である。プロジェクトライブリ中の各プロジェクトファイルはそれぞれ異なるプロジェクトIDを持つ。また、プロジェクト名のデータは、このプロジェクトに与えられた名称のデータであって、例えば後述する基本画面において当該プロジェクト名を表示するとき等に利用される。プロジェクトライブリ中の各プロジェクトファイルはそれぞれ異なるプロジェクト名を持つ。プロジェクトファイルの名称は、リモート制御ソフトが自動的に作成してもよいし、ユーザが任意の名称を設定してもよい。
1つのプロジェクトファイルのユーザ情報には、当該プロジェクトにログインするためのアカウントを作成したユーザの各々に対応する1又は複数のアカウント情報34が格納される。すなわち、アカウント情報34はプロジェクトファイル毎に作成される。プロジェクトファイルにアカウント情報34を持つユーザだけが、そのプロジェクトファイルを開き、それを使用することができる。1つのアカウント情報34は、ユーザIDと認証情報を含んで構成される。ユーザIDは、複数のユーザのうちから1人のユーザを特定するためのID情報である。認証情報は、例えばユーザIDに対応付けられたパスワードである。
1つのプロジェクトファイルには、当該プロジェクトに作成された「エリア」のそれぞれに対応するエリア情報33(図4において「エリア情報1」、「エリア情報2」…)が記憶されている。「エリア」は、前述の通り、1つのプロジェクト内におけるリモート制御の単位である。各エリア情報には、それぞれのエリアのリモート制御に使用する各種データが格納されている。
1つのエリア情報33には、エリアID46、エリア名、「RackTree」情報、「Feed Structure Tree」情報、および「User Defined Tree」情報のグループ情報36、ユーザロール情報35、当該エリアの「OnLine」のステータスを示す情報、および、当該エリアに登録された1又は複数のアンプのそれぞれに対応する装置情報(図において「装置情報1」、「装置情報2」…)37が含まれる。なお、当該エリア内に、アンプをネットワークに接続するインターフェース装置が含まれる場合には、そのインターフェース装置に対応する装置情報も、エリア情報33に含まれてよい。
エリアID46は、1つのプロジェクトに作成された複数のエリアの中から1つのエリアを特定するためのID情報である。1つのプロジェクト中の各エリアはそれぞれ異なるエリアID46を持つ。また、エリア名は、このエリアに与えられた名称であって、例えば後述する基本画面において当該エリアのエリア名を表示するとき等に利用される。1つのプロジェクト中の各エリアは夫々異なるエリア名を持つ。エリアの名称は、リモート制御ソフトが自動的に作成してもよいし、ユーザが任意のエリア名を設定してもよい。
ユーザロール情報35は、プロジェクトにアカウント情報34を持つ各ユーザに対して当該エリア内で与えられた権限(ユーザロール)を規定する情報である。「ユーザロール」は、当該エリアにアカウントを持つ各ユーザに対して与えられた権限を表す情報である。ユーザロールの種類は、上位の権限から順に列挙すると、「アドミン」、「パワーユーザ」、「ユーザ」、「ゲスト」、および「部外者」の5種類ある。「アドミン」は、プロジェクトの編集権限、エリアの編集権限、エリア内のアンプの制御権限及び閲覧権限を持つ。「パワーユーザ」は、エリアの編集権限、エリア内のアンプの制御権限、およびエリア内のアンプの閲覧権限を持つ。「ユーザ」は、エリア内のアンプの制御権限、およびエリア内のアンプの閲覧権限を持つ。「ゲスト」は、エリア内のアンプの閲覧権限を持つ。「部外者」は、当該エリアに何ら権限を持たない、つまりエリアにアカウントがない(ユーザロール情報35が当該エリアに無い)ことに等しい。
図5は、1つのエリア情報33に格納されたユーザロール情報35の内容を詳細に示す図である。1つのエリア情報33に格納されたユーザロール情報35には、当該プロジェクトにアカウント情報34を持つ全てのユーザの1人ずつに対応する複数のユーザロール情報35がある。1ユーザ分のユーザロール情報35は、そのユーザを特定するユーザIDと、該ユーザIDに対応するユーザに当該エリアで与えられたユーザロール(前記5種類のユーザロールの値のいずれか1つ)とから構成される。ここに含まれるユーザIDは、前記アカウント情報34に含まれるユーザIDである。従って、或るエリアにおける或るユーザの権限は、該ユーザのアカウント情報34(ユーザID)と、該ユーザIDに対応するユーザロール情報35を参照すれば、特定することができる。ユーザロール情報35はエリア毎に設定されているので、ユーザロール情報35に基づくユーザの権限はエリア毎に規定される。例えば、プロジェクトにアカウント情報34を持つユーザであっても、或るエリアのユーザロール情報35で権限が不足していれば、そのエリア内のアンプは制御乃至モニタすることはできない。
図4に戻ると、「RackTree」、「Feed Structure Tree」及び「User Defined Tree」の各情報36は、当該エリアに登録された各アンプをグループに分けて管理するための情報である。「RackTree」はラック(棚)毎にアンプをまとめたグループ(ラックツリー)の構成を記述した情報、「Feed Structure Tree」はアンプの信号出力先のスピーカ毎にアンプのチャンネルをまとめたグループ(フィードストラクチャーグループ)の構成を記述した情報、また、「User Defined Tree」はユーザが任意に定義したグループ(User Definedグツリー)の構成を記述した情報である。本明細書では、これらグループ分けのための情報36をまとめて「グループ情報」と称する。グループ情報36は、例えば、後述する基本画面において、プロジェクトの各エリアに登録されたアンプをグループごとのツリー形状に表示するときに利用される。前記3つのグループ情報36には、それぞれのグループに与えられた名前や、各グループの構成を特定する情報(グループに登録されたアンプ群を特定する情報と、グループ内での各アンプの位置を特定する情報)等を含んで構成される。
装置情報37は、1つずつが1つのアンプ1に対応しており、PC2のリモート制御ソフトから1つのアンプ1をリモート制御するために必要な情報が格納されている。リモート制御ソフトは、各エリア情報33内に、そのエリアに登録された1又は複数のアンプのそれぞれに対応する1又は複数の装置情報37を作成する。
1つの装置情報37には、装置ID38、機種情報、IPアドレス、機器名の情報、アンプの動作データ、当該装置情報37の「OnLine」のステータスを示す情報39、及び、コントローラID40の情報が含まれる。
装置ID38は、当該装置情報37に対応する実際のアンプ1が持つMACアドレスと、当該装置情報37をエリア内で特定するためのエリア内IDとから構成される。エリア内IDは、当該装置情報37がエリアに登録されたときに(該装置情報37の作成のときに)、リモート制御ソフトが自動生成したデータか、又は、当該装置情報37に対応するアンプ1側のユーザインターフェース15を使ってユーザが手動で設定したデータである。一方、MACアドレスはアンプ1が固定的に持つデータであり、リモート制御ソフト又はユーザが設定することはできない。装置ID38は、例えば、装置情報37と、実際のアンプ1とを対応付ける(マッチングする)とき等にリモート制御ソエリア内IDとフトが利用するデータである。
機種情報は、当該装置情報37に対応するアンプ1の機種を特定する情報であって、例えば、該アンプ1のモデル名やモデルID(メーカにより各機種ごとに付与されたID))などである。IPアドレスは、ネットワーク上で当該装置情報37に対応するアンプ1に与えられたIPアドレスである。機器名の情報は、リモート制御ソフトにおいてユーザにより当該装置情報37に対応するアンプ1に与えられた名称(アンプ名)であって、後述する基本画面において該アンプ1の名称を表示するとき等に利用される。
動作データは、当該装置情報37に対応するアンプ1の動作をリモート制御するために必要な各種パラメータの設定値の情報であって、例えば、アンプのチャンネル毎の音量レベルのパラメータの設定値などが含まれる。この動作データは、当該装置情報37に対応するアンプ1のメモリ11に記憶された動作データと同様の形式のデータである。各機種の動作データを定義し編集するための機種定義情報が、リモート制御ソフトの備える機種ライブラリ(図示せず)に記憶されている。ここで、各機種の機種定義情報には、その機種のモデル名、モデルID、動作データの形式を示す情報、および動作データを編集するための編集プログラムなどが含まれる。また、動作データには、例えば、チャンネル毎のゲインパラメータの値、チャンネル毎のアッテネータのパラメータの値、位相切替パラメータの値、遅延時間パラメータの値、イコライザパラメータの値など、各種パラメータとその設定値が含まれる。
OnLineステータス情報39には、「ONLINE」、「MONITOR」、および「OFFLINE」のいずれか1つの値が格納されている。OnLineステータス情報39により、当該装置情報37が、これに対応する実際のアンプ1に対して、上記3つの状態のいずれの状態にあるかを表す。
また、装置情報37に格納されたコントローラID40は、当該装置情報37に対応するアンプ1を制御しているPC2(制御主)を特定する情報であって、当該PC2自身が当該装置情報37に対応するアンプ1の制御主であれば、自身のメモリ21に格納されたコントローラID(符号30で示す階層に格納されたコントローラID)の値が、ここに書き込まれる。自身以外の他のPC2が当該装置情報37に対応するアンプ1の制御主であれば、該他のPC2のコントローラIDがここに書き込まれる。制御装置37内のコントローラID40は、当該プロジェクトがカレントプロジェクトにロードされたときにのみ用意されるデータであって、詳しくは、後述する同期化処理のときにアンプ1から受け取るものである。すなわち、プロジェクトがプロジェクトライブラリ(HDD22)に保存されている状態では、コントローラID40のデータは空である。
図6は、アンプ1のメモリ11に用意されるデータの構成例を説明する図である。図6に示す通り、1つのアンプ1のメモリ11には、機種情報と、装置ID41と、IPアドレスと、動作データと、コントローラID42と、エリアID43と、「RackTree」内でのアンプ位置情報、「Feed Structure Tree」内でのアンプ位置情報、および「User Defined Tree」内でのアンプ位置情報のグループ情報44と、「User Info」情報45とが含まれる。音響システム上の各アンプ1は、自身のメモリ11内に、それぞれ自機分だけ、これらの情報を記憶している。アンプ1の記憶内容のうち、コントローラID42、エリアID43、グループ情報44、およびUser Info情報45は、アンプ1をPC2から制御又はモニタするために必要なデータであって、アンプ1の本来の動作には必要ない。本発明は、User Info情報45や、グループ情報44など、PC2からアンプ1を制御又はモニタするためのデータをアンプ1のメモリ11に記憶していることが主要な特徴の1つである。
機種情報は、当該アンプ1の機種を特定する情報であって、例えば、該アンプ1のモデル名やモデルIDなどである。装置ID41は、MACアドレスとエリア内IDとから構成される。MACアドレスは当該アンプ1が固定的に持つデータであり、ユーザが設定することはできない。エリア内IDは、このアンプ1が登録されたエリア(詳しくは、PC2側で、このアンプ1に対応する装置情報37が登録されたエリア)内で当該アンプ1を特定する情報であって、当該アンプ1に対応する装置情報37がエリアに登録されるときにリモート制御ソフトが自動生成したデータか、又は、当該アンプ1のユーザインターフェース(操作パネル)15を使ってユーザが手動で設定したデータである。装置ID41は、例えば、アンプ1と装置情報37とを対応付ける(マッチングする)とき等に、リモート制御ソフトが利用するデータである。また、IPアドレスは、ネットワーク上で当該アンプ1に与えられたIPアドレスである。
動作データは、アンプ1の動作をリモート制御するために必要な各種パラメータの設定値の情報であって、例えば、例えば、チャンネル毎のゲインパラメータの値、チャンネル毎のアッテネータのパラメータの値、位相切替パラメータの値、遅延時間パラメータの値、イコライザパラメータの値など、各種パラメータとその設定値が含まれる。アンプ1のCPU10は、この動作データに基づいてDSP13に命令を与え、該DSP13が実行する音響信号処理の内容を制御する。アンプ1側の動作データは、PC2側からリモート制御されるか、若しくは、当該アンプ1のユーザインターフェース15を用いて制御される。
アンプ1に格納されたコントローラID42は、当該アンプ1の制御主のPC2のメモリ21に記憶されたコントローラIDに対応するデータであって、これは後述する同期化処理のときに該制御主のPC2から受け取る。コントローラID42は、当該アンプ1が現在PC2による制御を受けているか否かの状態を判断すること等に利用される。コントローラID42に値が入っていれば、当該アンプ1はPC2から制御を受けている状態にあり、コントローラID42に値が入っていなければ、当該アンプ1はPC2から制御を受けていない状態にある。エリアID43は、当該アンプ1が登録されたエリアに付与されたエリアIDである。アンプ1のメモリ11にエリアIDを持つことにより、当該アンプ1がカレントプロジェクトにおいて、どのエリアに登録されているのかをPC2に知らせることができる。エリアID43は、後述する同期化処理のときに、当該アンプ1の制御主のPC2から受け取るデータである。また、エリアID43はアンプ1のユーザインターフェース(操作パネル)15を使ってユーザが手動で設定できる。
また、「RackTree」、「Feed Structure Tree」、および「User Defined Tree」の各アンプ位置情報44は、「RackTree」、「Feed Structure Tree」、および「User Defined Tree」の各グループ内での当該アンプの位置を特定するグループ情報である。個々のアンプ1が持つグループ情報44は、前記PC2側に記憶されるグループ情報36に基づくデータである。PC2側に記憶されるグループ情報36が、1つのエリア内に作成された各グループの構成(各グループに登録されたアンプ群を特定する情報)と、各グループ内での各アンプの位置情報を特定する情報とから構成されるのに対して、アンプ1側に記憶されるグループ情報44は、自機が登録されたグループと各グループにおける自機の位置とを特定できさえすればよい。アンプ1に記憶されるグループ情報44は、後述する同期化処理のときに、該アンプ1の制御主のPC2から受け取るPC2側のグループ情報36(当該アンプ1が登録されたエリア情報33中のグループ情報36)に基づき設定されるデータである。
また、「User info」情報45は、1又は複数のユーザのそれぞれに対応する1又は複数の「User info」情報39である。1ユーザ分の「User info」情報45は、そのユーザのユーザIDと、該ユーザIDに対応する認証情報からなるアカウント情報と、アカウントを持つユーザの該アンプ1に対する権限(ユーザロール)を規定する情報とから構成される。「User info」情報45は、後述する同期化処理のときに、当該アンプ1の制御主のPC2から受け取るカレントプロジェクト中のユーザ情報(アカウント情報34)と、当該アンプ1が登録されたエリア情報33中のユーザロール情報35とに基づき作成されるデータである。つまり、「User info」情報45は、1ユーザ毎に、アカウント情報34と、当該アンプ1が登録されたエリア内での各ユーザのユーロール情報35とを対応付けたデータである。
図7は、リモート制御ソフトが提供する操作画面を説明するための図であって、リモート制御ソフトが提供する機能の全体的な操作を行う「基本画面」の構成例を示す。PC2においてリモート制御ソフトが起動さて、制御対象となる1つのプロジェクトが選択されると、PC2のディスプレイ(ユーザインターフェース24)には、該制御対象に選択されたプロジェクト(カレントプロジェクト)を制御及びモニタするための「基本画面」が表示される。
図7に示す基本画面において、ツリー表示部50は、制御対象のプロジェクト(カレントプロジェクト)の構成を、カレントプロジェクト内のデータに基づき、ツリー形式に表示する領域である。すなわち、ツリー表示部50には、1つのプロジェクトファイルのデータ構成に対応して、最上位層にエリアに対応する表示物群があり、各エリアに対応する表示物の下位に、それぞれのエリアに属するグループ、アンプ、あるいはアンプのチャンネルのそれぞれを表す表示物群が枝分かれした状態で配置される。各表示物には、対応する構成要素の名前(エリア名、グループ名、あるいはアンプ名など)が、カレントプロジェクト内のデータに基づき、表示される。また、ある構成要素の下位に要素が存在する場合には、そのツリー構成要素に対応する表示物の左端に、該下位要素を表示するか又は隠すかの指示をするためのGUI部品51が表示される。下位要素を表示している状態ではGUI部品51上に「−」印が表示され、下位要素を隠している状態ではGUI部品51上に「+」印が表示される。
ところで、ツリー表示部50に表示される制御対象のプロジェクトの構成は、前述の通り、PC2に記憶されたカレントプロジェクトのデータに基づく。従って、ツリー表示部50においてアンプを表す表示物は、制御対象のプロジェクトファイル内に作成された装置情報37に対応する仮想的アンプを表す。この明細書では、プロジェクトファイル内に作成された仮想的アンプ(つまり、PC2に記憶された装置情報37)のことを必要に応じて「バーチャル機器」と称し、これに対して、現実に音響システムに接続されたアンプ1の実体のことを必要に応じて「リアル機器」と称する。
ユーザは、ツリー表示部50に表示された該表示物群のいずれか1つを選択することで、該指定した表示物群に対応するエリア、グループ、アンプ(バーチャル機器)、又はアンプのチャンネルの各種パラメータの値を、レベル表示部52、状態表示部53、およびアッテネータ操作部54に展開することができる。これら符号52〜54で示す領域が、アンプをリモート制御するための主要な操作を行う領域である。ユーザは、符号52〜54で示す領域の詳細な構成の一例は、後述する。
また、図7に示す基本画面には、上記の他に、現在制御対象のエリア(ツリー表示部50で選択されたエリア、又は、同選択されたグループが属するエリア、又は、同選択されたアンプが属するエリア、又は、同選択されたアンプのチャンネルが属するエリア)のエリア名を表示するエリア名表示部55、現在リモート制御ソフトにログインしているユーザ名(例えばそのユーザのユーザIDなど)を表示するユーザ名表示部56、バーチャル機器とリアル機器の同期化処理ダイアログ機能を起動するための「On−Line」ボタン画像57、現在制御対象のエリアのミュートオン・オフ切替指示ボタン画像58、あるいは、当該基本画面全体に共通する操作を行う共通操作パネル59が含まれる。共通操作パネル59には、例えば、プロジェクトファイルをカレントプロジェクトに読み出す(ロードする)指示や、同ファイルを保存する(ストアする)指示や、同ファイルを新規に作成する指示等を行うためのGUI部品が含まれていてよい。また、基本画面には、上記の他にも、例えば、ログイン中のユーザに与えられた現在制御対象のエリアにおける権限(「アドミン」、「パワーユーザ」、「ユーザ」、「ゲスト」)や、カレントプロジェクトのプロジェクト名など、その他の情報を表示するための表示部(図において「その他情報表示部」と表記したもの)が含まれてよい。
図8(a)〜(c)は、ツリー表示部50の構成を詳細に説明するための図である。ツリー表示部50には、その上端分に、「Device」タブ60、「Rack」タブ61、「Feed Structure」タブ62、および「User Defined」タブ63の4つのタブ画像が設けられている。ユーザは、これら4つのタブ画像60〜63を択一的に選択することで、該選択されたタブ画像60〜63のいずれか1つに応じて、ツリー表示部50に表示されるツリーの表示形態を切り替えることができる。
「Device」タブ60が選択されているときには、(a)に示す「デバイスツリー」の表示形態でツリー表示部50にプロジェクトの構成が表示される。「デバイスツリー」は、エリア毎に、そのエリアに登録されたバーチャル機器を表示する表示形態である。「デバイスツリー」において、ネットワークに直接接続されている機器は、いずれかつのエリアの直下、又は「Unknown Device」カテゴリーの直下に表示され、グループを形成することはない。図8(a)では「Area(1)」の直下に、「Amp3」と、アンプをネットワークに接続するためのインターフェース装置「ACD(1)」並びに「ACD(2)」が配置された例を示している。図の例からは、「Amp1」及び「Amp2」が「ACD(1)」に接続されていることが見て取れる。このように、デバイスツリーにはアンプ1以外のエリア内の機器(グループ化されない機器)も表示されうる。なお、1台のインターフェース装置(ACD)には、最大32台のアンプを接続可能である。
また、「デバイスツリー」には、各バーチャル機器の表示物に対応して、該バーチャル機器に対応するリアル機器を確認するための「Identelify」ボタン画像64が表示される。ユーザは、「Identelify」ボタン画像64を操作することで、そのバーチャル機器に対応付けられたリアル機器を確認することができる。確認方法の一例として、「Identelify」ボタン画像64の操作に応じて、そのバーチャル機器に対応付けられたリアル機器に備わるLED表示器が点灯するよう構成することができる。また、「デバイスツリー」には、各バーチャル機器の表示物に対応して、各バーチャル機器のエリア内IDを表示するID表示欄65が設けられている。図8(a)では、「Area(1)」に登録された6つのバーチャル機器(「Amp1」、「Amp2」、「Amp3」、「Amp4」、「ACD(1)」および「ACD(2)」)には、それぞれ、当該エリア内で連続する通し番号「1」〜「6」がエリア内IDとして付与されている。
また、「Rack」タブ61が選択されているときには、図8(b)に示す「ラックグループツリー」の表示形態でツリー表示部50にプロジェクトの構成が表示される。「ラックグループツリー」は、各エリアのエリア情報33に含まれる「Rack tree」の情報に基づき、エリアに登録されたアンプを「ラックグループ」に分けたツリーの表示形態(グループツリー)である。ラックグループは、アンプが登載されたラック(棚)ごとにアンプをまとめたグループである。1つのラックグループの下位に更に入れ子状にラックグループを作ること、つまり、1つのグループ内のアンプ群を更に小グループに分けることもできる。図8(b)の例では、「Area(1)」に作成された1つのラックグループ「Rack−1」の下位に、2つのグループ「Rack−1A」と「Rack−1B」が作成されており、更に「Rack−1B」の下位に2つのグループ「Rack−1B/1」と「Rack−1B/2」が設けられている。或るエリア内のバーチャル機器であって、ラックグループに分類されないものは、「Ungrouped Device」のカテゴリーに分類される。図8(b)では、「AmpX1」と「AmpX2」が「Ungrouped Device」のカテゴリーに分類されている。「ラックグループツリー」にも、各バーチャル機器の表示物に対応して、各バーチャル機器のエリア内IDを表示するID表示欄65が設けられている。
また、「Feed Structure」タブ62が選択されているときには、図8(c)に示す「フィードストラクチャーグループツリー」の表示形態でツリー表示部50にプロジェクトの構成が表示される。「フィードストラクチャーグループツリー」は、各エリアのエリア情報33に含まれる「Feed Structure Tree」の情報に基づき、エリアに登録されたアンプの各チャンネルを「フィードストラクチャーグループ」毎に分けたツリーの表示形態(グループツリー)である。フィードストラクチャーグループは、アンプの各チャンネルの信号出力先となるスピーカ毎に、アンプのチャンネルをまとめたグループである。このグループ分けでは、例えば、ステレオスピーカのLチャンネルに接続された高音域、中音域、および低音域の各帯域毎のアンプのチャンネルをまとめた第1のグループ(図8(c)において「Group−1」)、ステレオスピーカのRチャンネルに接続された高音域、中音域、および低音域の各帯域毎のアンプのチャンネルをまとめた第2のグループ(図8(c)において「Group−2」)…などのようなグループ分けが可能である。従って、「フィードストラクチャーグループツリー」では、各グループ内には、アンプのチャンネルに対応する表示物(図8(c)において、「Amp1:ch1」など)が表示される。また、「フィードストラクチャーグループツリー」では、エリア内のバーチャル機器のチャンネルであって、「フィードグループ」に分類されないものは、「Ungrouped Channels」のカテゴリーに分類される。
また、「User Defined」タブ63が選択されたときには、「User Definedツリー」の表示形態でツリー表示部50にプロジェクトの構成が表示される。このグループは、ユーザが定義したグループ分けに従いエリア内のアンプのチャンネルをまとめたグループであって、各エリアのエリア情報33に含まれる「User Defined Tree」の情報に基づき、エリアに登録されたアンプを「User Definedツリー」毎に分けたツリーの表示形態である。その表示形態は、参照するグループ情報36の違いを除けば、図8(c)のフィードストラクチャーグループツリーと概ね同様であるため、User Definedツリーの表示例の図示は割愛した。
ツリー表示部50において、1つのプロジェクト内に複数のエリアを設定し、エリア毎に1又は複数のグループにまとめることで、(1)ツリー表示部50におけるツリー構成の表示形態を、異なる観点でのグループ分け(グループ定義)に応じて選択することができるので、個々のアンプを制御するときに、ツリー表示部50から目的のアンプ又はアンプのチャンネルに辿り着くのが容易になる、という利点がある。また、(2)制御対象にグループを選択することにより、複数のアンプをグループ単位でまとめて制御できる、という利点がある。
また、ツリー表示部50のデバイスツリー及びグループツリーにおいて表示されるバーチャル機器に対応する表示物の表示形態には、(1)対応するリアル機器がネットワーク上に存在する「実体有り」を表す表示形態と、(2)対応するリアル機器がネットワーク上に存在しない「実体無し」を表す表示形態との2通りの表示形態がある。この実施例では、「実体有り」の場合にはバーチャル機器に対応する表示物を「実線」で表示し、「実体無し」の場合にはバーチャル機器に対応する表示物を「点線」で表示する。
ツリー表示部50において、プロジェクトファイルでエリアに登録されているバーチャル機器ないしそのバーチャル機器のチャンネルは、デバイスツリー、およびグループツリーの両方に、「エリア内のバーチャル機器」として表示される。後述するバーチャル機器とリアル機器とのマッチング処理によりバーチャル機器とリアル機器との対応付けがとれたエリア内のバーチャル機器に対応する表示物は、「実体有り」を表す表示形態、すなわち実線で表示される。例えば、図8(a)において、「Amp1」は、「実体有り」の表示形態で表示されたエリア内のバーチャル機器を表す表示物の一例である。また、マッチング処理によりバーチャル機器とリアル機器との対応付けがとれなかったエリア内のバーチャル機器、すなわち、リアル機器が検出されなかったエリア内のバーチャル機器に対応する表示物は、「実体無し」を表す表示形態、すなわち点線で表示される。例えば、図8(a)において、「Amp4」は、「実体無し」の表示形態で表示されたエリア内のバーチャル機器を表す表示物の一例である。
これに対して、マッチング処理により音響システム上でリアル機器が検出されたものの、プロジェクトファイルの何れのエリアのバーチャル機器とも対応付けできなかったリアル機器があった場合には、リモート制御ソフトは、デバイスツリーの「UnknownDevice」というカテゴリーに、その機器に対応する表示物を自動作成する。本明細書では、これを「エリア外のバーチャル機器」と呼ぶ。例えば、図8(a)において、「AmpX」は、エリア外のバーチャル機器に対応する表示物の一例である。ここでは、「AmpX」を表す表示物が点線(つまり実体無しを表す表示形態)で表示されている。これは、「AmpX」がエリア外のバーチャル機器として作成された後に、対応するリアル機器がネットワークから切断されたことを意味する。なお、エリア外のバーチャル機器に対応する表示物は、グループツリーには表示されない。また、対応するリアル機器が切断されたバーチャル機器を点線で表示する代わりに、そのバーチャル機器の表示をツリーから消去してしまうようにしてもよい。
また、図8(a)〜(c)において、バーチャル機器に対応する表示物の右隣に表示された両方向矢印画像66は、対応するバーチャル機器のOnLineステータスがオンライン状態(「ONLINE」)であることを示すマークである。また、バーチャル機器に対応する表示物の右隣に表示された一方向矢印画像67は、対応するバーチャル機器のOnLineステータスがモニタ状態(「MONITOR」)であることを示すマークである。また、バーチャル機器のOnLineステータスがオフライン状態(「OFFLINE」)のバーチャル機器については、対応する表示物の右隣に何らマークが表示されていない。各バーチャル機器のOnLineステータスは、対応する装置情報37に格納されたOnLineステータス情報39に基づく。
オンライン状態(ONLINE)とは、エリア内のアンプの制御権限を持つ「ユーザ」が、PC2から、対応するリアル機器をリモートで制御可能な状態である。また、モニタ状態(MONITOR)とは、エリア内のアンプの閲覧権限を持つ「ゲスト」が、PC2から、対応するリアル機器の動作状態をリモートでモニタ可能な状態である。また、「オフライン(OFFLINE)」は、バーチャル機器とリアル機器の間でリモート通信が行われない状態である。オフライン状態で、リモート制御ソフトにおいてバーチャル機器の動作データの編集が行われると、該編集操作内容に応じてカレントプロジェクトのデータが更新される。しかし、その操作はリアル機器には反映されない。
図9(a),(b)は、前記図7の基本画面において符号52〜54で示す領域の画面構成例を示す図である。(a)は、ツリー表示部50でアンプが個別に指定された場合の画面の構成例であり、(b)は、ツリー表示部50でエリア又はグループが指定された場合、つまり複数のアンプをまとめて制御する画面の構成例である。
図9(a)又は(b)において、レベル表示部52には、ツリー表示部50で指定された1つのエリア、グループ、アンプ、又はアンプのチャンネルにおける入力信号の音量レベル、出力信号の音量レベル、出力端子に接続された負荷インピーダンスのレベル、及び出力電力レベルについて、それぞれチャンネル毎(図9では「CH A」と「CH B」の2つのチャンネル)に表示するレベルメータ群や、同チャンネル毎の入力信号乃至出力信号のミュートオン・オフ切替指示ボタン画像、出力の極性を切り替えスイッチ画像などが含まれる。また、状態表示部53には、ツリー表示部50で指定された1つのエリア、グループ、アンプ、又はアンプの動作状態等を表示する。また、アッテネータ操作部54には、アッテネータのパラメータ(音量レベル減衰量)を調整する操作子画像がもうけられており、ツリー表示部50で選択された1つのエリア、グループ又はアンプ1のアッテネータのパラメータが該操作子画像の制御対象に割り当てられる。図9に示す通り、(a)と(b)の画面構成は概ね共通している。両者の違いは、図9に示す例では、アッテネータ操作部43の構成の違い、(b)の画面には出力の極性を切り替えスイッチ画像がない点、および(b)の画面の状態表示部53には「Output Mode」の設定状態が表示されない点の3点である。
上記の構成からなる音響システムにおいてPC2及びアンプ1のそれぞれが実行する各種動作の手順を、フローチャートを参照して説明する。
図10は、PC2のCPU20が実行するリモート制御ソフトの動作手順の流れの大枠を示すフローチャートである。PC2のOS上で、リモート制御ソフトが起動されると、ディスプレイ(ユーザインターフェース24)に基本画面を立ち上げることを含む所定の初期化処理をCPU20は行う(ステップS1)。初期化処理が終了した後、CPU20はユーザから操作イベントが入力されることを待機する(ステップS2)。該ユーザが入力した何らかの操作イベントが検出されると、CPU20は該操作イベントに応じた処理を実行する(ステップS3)。そして、ユーザがリモート制御ソフトの終了を指示するまで(ステップS4のNO)、CPU20は前記ステップS2及びS3の処理を繰り返す。リモート制御ソフトの終了が指示されたら(ステップS4のYES)、CPU20は所定の終了処理を行い(ステップS5)、リモート制御ソフトを終了する。
前記ステップS2でCPU20が待機する操作イベントは、ディスプレイ(ユーザインターフェース24)に表示された基本画面等の操作画面からユーザが入力する操作イベントであって、例えば、プロジェクトファイルのロード指示、カレントプロジェクトとのストア指示、プロジェクト内のデータの各種編集操作、あるいはバーチャル機器とリアル機器のオンライン化指示又はオフライン化指示などである。以下に、ユーザによる種々の操作イベントに応じて、CPU20が前記ステップS3で実行する処理の動作手順の一例をフローチャートを参照して説明する。
なお、以下に説明する各種編集操作には、それぞれの操作を実行可能なユーザの権限が定義されており、それによりデータの編集操作の実施主体を制限している。ユーザの権限は、既に述べたとおり、プロジェクトの全権限を持つ「アドミン」、エリアの編集権限までを持つ「パワーユーザ」、エリア内のアンプの制御権限までを持つ「ユーザ」、エリア内のアンプの閲覧権限のみを持つ「ゲスト」、および当該エリアに何ら権限を持たない「部外者」の5種類ある。なお、ここでは、各ユーザに、予め定義された5種類の権限の1つを適用するようになっていたが、各権限をユーザが定義できるようにしたり、更に、ユーザが内容を定義できる「カスタム」という権限を設けてもよい。
図11は、操作イベントとしてプロジェクトファイルのロード指示がユーザにより入力されたときに、CPU20が実行する処理の動作手順の一例を示すフローチャートである。ユーザは、図7の基本画面の共通操作パネル59から、プロジェクトファイルライブラリ31を開き、該ライブラリ中の1つのプロジェクトファイル32を選択し、該選択したプロジェクトファイル32のロード指示を行うことができる。スッテプS6において、CPU20は、前記ユーザが選択したプロジェクトファイル32を開く処理を行い、該選択されたプロジェクトファイル32に含まれるデータ群を、カレントプロジェクトにロードする。
ステップS7において、CPU20は前記ステップS6でカレントプロジェクトにロードしたプロジェクトに、ユーザをログイン(ユーザ認証)させる処理を行う。具体的には、CPU20は、ディスプレイ24に、ユーザIDと認証情報の入力を求めるログイン画面(図示せず)を表示して、ユーザにユーザIDと認証情報を入力させて、該ログイン画面で入力されたユーザIDと認証情報を、当該カレントプロジェクトに含まれるユーザ情報中のアカウント情報34(ユーザIDと認証情報)と照合する。ユーザによって入力されたユーザID及び認証情報に一致するアカウント情報34があれば、CPU20はユーザ認証が成立したものと判断し、当該ユーザがカレントプロジェクトにログインすることを許可する。一方、当該ユーザがこのプロジェクトにアカウントを持たない場合や、入力されたユーザID及び認証情報の少なくともいずれか一方に誤りがあった場合には、CPU20は、ログイン失敗と判断して、プロジェクトファイルのロードの動作は終了する。
前記ステップS7のログイン処理が終了したら、CPU20は、ステップS8におい「マッチング処理」を行う。マッチング処理は、ネットワーク上に接続された各リアル機器を検出し、該検出した各リアル機器から装置ID41とエリアID43を取得して、該取得した装置ID41とエリアID43を用いて、カレントプロジェクトの各エリアのエリアID46と、該各エリアに登録されたバーチャル機器の装置ID38とを照合し、音響システムに接続されたリアル機器と各エリアに登録されたバーチャル機器の対応付けを行う処理である。なお、マッチング処理の動作手順の詳細な説明は図23を参照して後述する。
そして、ステップS9において、CPU20は、前記ステップS8の「マッチング処理」の結果に基づき、ツリー表示部50の初期表示を行う等、画面初期化処理を行う。すなわち、前記ステップS8のマッチング処理の結果、(1)エリア内のバーチャル機器のうちでリアル機器との対応付けがとれたものは、「実体(リアル機器)有り」を表す表示形態の表示物がツリー表示部50のデバイスツリー及びグループツリーに表示され、また、(2)エリア内のバーチャル機器のうちでリアル機器との対応付けがとれなかったものは、「実体(リアル機器)無し」を表す表示形態の表示物がツリー表示部50のデバイスツリー及びグループツリーに表示される。また、ネットワーク上にリアル機器が検出されたものの、いずれのエリアのバーチャル機器とも対応付けが取れなかったものは、デバイスツリーの「UnknownDevice」のカテゴリーに、エリア外のバーチャル機器を表す表示物が、「実体(リアル機器)有り」を表す表示形態で自動生成される。
上記図11の処理により、PC2のディスプレイには、ユーザが制御対象に選択したプロジェクトが基本画面に表示され、PC2から該制御対象に選択したプロジェクトを制御ないしモニタすることが可能な状態となる。
図12は、操作イベントとしてプロジェクトファイルの保存(ストア)指示がユーザにより入力されたときに、CPU20が実行するプロジェクトファイルの保存の動作手順の一例を示すフローチャートである。ユーザによりプロジェクトファイルの保存指示が行われると、ステップS10において、CPU20は、メモリ(RAM)21上のカレントプロジェクトの内容をHDD22に設けられたプロジェクトファイルライブラリ31中の1つのプロジェクトファイル32としてストアする処理を行う。これにより、リモート制御ソフトに現在立ち上げているカレントプロジェクトの内容が、1つのプロジェクトファイル32としてプロジェクトファイルライブラリ31に保存される。
図13は、ユーザが操作イベントとしてツリー表示部50の編集操作を行ったときに、CPU20が実行する処理の動作手順の一例を示すフローチャートである。ツリー表示部50の編集操作は、エリアの編集権限(「パワーユーザ」以上の権限)を持つユーザによって行われる操作であり、且つ、編集対象のエリアに含まれる全てのバーチャル機器がオフライン状態のときにのみ実行可能である。ツリー表示部50の編集操作には、エリアを新規に作成する操作、既存のエリアを削除する操作、或るエリアにグループを新規に作成する操作、既存のグループ削除する操作、或るエリア中のグループを別のエリアに移動する操作、バーチャル機器を新規に作成する操作、或るエリア内にバーチャル機器を新規に作成する操作、既存のバーチャル機器を削除する操作、あるいはエリア間若しくはグループ間でバーチャル機器を移動する操作等が含まれる。ユーザは、これらの編集操作を、例えば、各要素に対応する表示物のドラッグ&ドロップ操作など、PC2のユーザインターフェース24を用いた操作により、グラフィカルに行うことができる。
ユーザが入力したツリー表示部50の編集操作が、新規デバイス(バーチャル機器)の追加であれば(ステップS11のYES)、CPU20は、追加先に指定されたエリアのエリア情報33に、該新規に追加されたバーチャル機器に対応する装置情報37を作成する。新規デバイス追加操作は、例えば基本画面の共通操作パネル59で機種ライブラリのメニューを開く操作を行い、開かれたメニューに表示された複数のモデル名のうちの所望のモデル名を選択することにより、モデル名に対応するバーチャル機器を追加するようにすればよい。ここで、新規に作成されるバーチャル機器を定義するためのデータとして最低限指定されなければならないデータは、新規に追加するバーチャル機器の機種情報とエリア内ID(装置ID38の一部)である。この実施例では、バーチャル機器新規作成時に、CPU20は、追加先に指定されたエリアでの通し番号(当該エリアに既存の他のエリア内ID群に連続する番号)を、新規に作成されるバーチャル機器のエリア内IDとして、自動的に付与する処理を行うものとする。
新規にデバイス(バーチャル機器)が追加されたら(ステップS11のYES)、CPU20は、該追加されたバーチャル機器と、音響システムに接続されたリアル機器とのマッチング処理を行い(ステップS12)、新規デバイス追加に応じてカレントプロジェクトの記憶内容を更新する(ステップS13)。そして、CPU20は、ステップS14において基本画面(ツリー表示部50)の表示を更新することで、該新規デバイス追加の操作を画面に反映する。また、新規デバイス(バーチャル機器)追加以外の、ツリー表示部50の編集操作が行われた場合には(ステップS11のNO)、CPU20は、編集対象に選択されたツリーの構成を、当該編集操作の内容に応じて編集する処理を行う(ステップS15)。そして、CPU20は、前記編集操作の内容に応じてカレントプロジェクトの記憶内容を更新し(ステップS13)、基本画面(ツリー表示部50)の表示を更新する(ステップS14)。この処理により、ツリー表示部50に表示されたツリー構成がユーザの編集操作に応じて変更される。
また、エリア内のアンプの制御権限(「ユーザ」以上の権限)を持つユーザは、アンプのデータを編集することができる。エリア内のアンプの制御権限を持つユーザは、編集対象のアンプをツリー表示部50で選択することで、該選択したバーチャル機器のデータを、図7の基本画面において符号52〜54で示す領域に展開し、該領域41〜43のGUI部品(前記図9(a)又は(b)を参照)を使って、そこに展開された各種パラメータの値を変更することができる。なお、ここで編集対象のアンプ(バーチャル機器)は、アンプ単体、1つのグループ、又は1つのエリアのいずれかである。すなわち、1つのグループ、又は1つのエリアが編集対象であれば実質的には複数のアンプ(バーチャル機器)が編集対象となる。編集対象のバーチャル機器又はバーチャル機器群がオンライン状態のときには、図14のフローチャートに示す通り、CPU20は、編集対象のリアル機器に対して、ユーザが基本画面で行ったアンプ(バーチャル機器)の編集操作の内容を通知する操作要求を送信する(ステップS16)。前記操作要求を受信したリアル機器では、該操作要求を行ったユーザに権限があるならば、編集操作の内容に応じて自機の動作データを更新し、該更新結果をPC2へ返信する(詳しくは後述の図28を参照)。PC2側では、CPU20は、前記リアル機器からの応答内容に応じてカレントプロジェクトの記憶内容を更新し(ステップS17)、必要に応じて画面の表示も更新する。
また、編集対象のバーチャル機器がオフライン状態のときには、図15のフローチャートに示す通り、CPU20は、ユーザが基本画面で行ったアンプ(バーチャル機器)の編集操作に応じてカレントプロジェクトの記憶内容を更新し(ステップS18)、必要に応じて画面の表示も更新する。この場合は、ユーザがPC2側で行った編集操作の内容はリアル機器に反映しない。
図16は、ユーザが、制御対象のプロジェクトに登録されたアカウントの編集操作を行ったときに、CPU20が実行する処理の動作手順の一例を示すフローチャートである。ユーザのアカウントは、プロジェクトファイル31毎に設定されるもので、プロジェクトファイル31に記憶されたユーザ毎のアカウント情報34により管理されている。アカウントの編集操作は、プロジェクトの全権限(「アドミン」の権限)を持つユーザのみが実行可能であり、且つ、プロジェクト内の全てのバーチャル機器がオフライン状態のときにのみ実行される。
ユーザは、例えば、基本画面の共通操作パネル59などからアカウントの編集要求を行うことができてよい。ユーザによってアカウントの編集要求が入力されると、CPU20は、アカウントの編集を行うためのユーザ管理ダイアログ画面(図示せず)をディスプレイに表示する(ステップS19)。そして、CPU20は、ユーザ管理ダイアログ画面におけるアカウントの編集操作をユーザから受け付けて(ステップS20)、入力された編集操作に応じてカレントプロジェクトに格納されたユーザ情報(アカウント情報34)を更新する(ステップS21〜S24)。すなわち、既存のアカウントの削除の操作が行われた場合には、ステップS21において、CPU20は、指定されたアカウント情報34と、エリア毎の該アカウント情報34に対応するユーザロール情報35を、カレントプロジェクトから削除する。また、既存のアカウントの変更の操作が行われた場合には、ステップS21において、CPU20は、ユーザが行った変更操作の内容に応じて、指定されたアカウント情報34のユーザID及び認証情報の少なくともいずれか一方、あるいは、指定されたエリアにおけるそのアカウント情報34に対応するユーザロール情報35を変更する処理を行う。
また、新規にアカウントが追加された場合には、CPU20は、ステップS23において、新規のアカウントを作成する。すなわち、CPU20は、ユーザIDと認証情報をユーザに設定させることでアカウント情報34をカレントプロジェクトに新規に作成すると共に、該新規アカウントのユーザに権限を与えるべきエリア毎の権限をユーザに設定させることで該エリア毎に該新規アカウント情報34に対応するユーザロール情報35を新規に作成する。そして、ステップS24において、前記ステップS23で作成された規のアカウントをカレントプロジェクトに登録する。つまりカレントプロジェクトに格納されたユーザ情報(アカウント情報34)とエリア毎のユーザロール情報35を更新する。
次に、バーチャル機器とリアル機器の同期化処理について説明する。ユーザが、図7に示す基本画面の「Online」ボタン画像57を操作すると、CPU20は、図17に示す「シンクロナイズドダイアログ」画面をディスプレイに表示させる。「シンクロナイズドダイアログ」画面は、基本画面のツリー表示部50で現在制御対象に選択されているエリアに登録されたアンプ群について、オンライン化指示(同期化指示)又はオフライン化指示を行うためのダイアログ画面であって、オンライン化指示(「Go−Online」)ボタン画像68と、オフライン化指示(「Go−Offline」)ボタン画像69とを含む。ユーザが、「シンクロナイズドダイアログ」画面のオンライン化指示ボタン画像68を操作すると、CPU20は現在制御対象に選択されているエリア内のバーチャル機器群をオンライン状態にするための同期化処理を実行する。すなわち、同期化処理は1つのエリアを対象に行われる。また、画面中の「Get Editable」ボタン画像78は、ユーザがオンライン状態化とモニタ状態化のいずれを選択するかを指示するボタンである。このボタン画像78のオン状態は、オンライ状態化を選択したことを示し、オフ状態は、モニタ状態化を選択したことを示す。画面中の機器情報表示部76には、当該エリア内のバーチャル機器のうち、リアル機器と対応付けがされているバーチャル機器(同期化候補のバーチャル機器)のアンプ名と、デバイスIDと、対応するリアル危機のIPアドレスと、OnLineステータスとが表示される。
図18は、ユーザがオンライン化指示ボタン画像68を操作したときに、CPU20が実行する処理の動作手順の一例を示すフローチャートである。ステップS25において、CPU20は、エリア内のバーチャル機器のうち、リアル機器との対応付けができており、且つ、OnlineステータスがONLINEでないものを、「同期化すべきバーチャル機器」として特定するとともに、そのうちの1台目のバーーチャル機器及びその対応するリアル機器を「同期化処理対象」として指定する。ここで同期化すべきバーチャル機器として特定された機器の1ずつに対して、順番に、ステップS26以下の処理を実行する。従って、同期化処理の対象になる機器は、或るエリアに登録されたバーチャル機器であって、リアル機器とのマッチングが取れたもの(実体有りのエリア内のバーチャル機器)である。
ステップS26において、同期化対象のリアル機器からUserInfo情報45を取得して、該取得したUserInfo情報45に含まれる複数組のユーザIDと認証情報と、アカウント情報34中のログインユーザのユーザIDと認証情報の組との整合を確認する。ログインユーザのユーザIDと認証情報の組が、該取得したUserInfo情報45にそのまま含まれていれば(ステップS27の「一致」)、処理をステップS30に進める。
ステップS27において不一致と判断されるのは、取得したUserInfo情報45に、ログインユーザのユーザIDが含まれていない場合、又は、取得したUserInfo情報45に、ログインユーザのユーザIDが含まれているが、それと組になる認証情報がログインユーザの認証情報と一致しない場合、又は、リアル機器側のUserInfo情報45がクリアされている場合の3通りのケースである。
取得したUserInfo情報45、ログインユーザのユーザIDは含まれているが、それと組になる認証情報が不一致であったった認証に失敗した場合(ステップS27の不一致)には、ステップS28において、CP20は、パスワード(認証情報)の入力を求めるパスワード入力画面を表示し、ユーザにパスワード(認証情報)を入力させる再認証処理を行う。この再認証処理により入力されたパスワードが正しければ、認証が成功したものと判断する(ステップS29の「OK」)。
また、リアル機器側にUserInfo情報45がクリアされている場合には、前記ステップS28において、CPU20は、当該バーチャル機器が属するエリア情報33中のユーザロール情報35に基づき当該ログイン中のユーザの権限(ユーザロール)を調べ、該ユーザが当該エリアの編集権限以上の権限(「パワーユーザ」以上の権限)を持っていれば、認証が成功したものと判断する(ステップS29の「OK」)。
また、取得したUserInfo情報45に、ログインユーザのユーザIDが含まれていない場合、又は、リアル機器のUserInfo情報45がクリアされており且つログインユーザが当該エリアの編集権限以上の権限を持たない場合には、CPU20は認証が失敗したものと判断し(ステップS29の「NG」)、当該バーチャル機器の同期化処理は終了する。
ステップS30において、CPU20は、ログイン中のユーザのユーザロール情報35を調べる。ユーザロール情報35に設定された権限が「ユーザ」以上、すなわち、エリア内のアンプの制御権限以上の権限であるならば、該ログイン中のユーザは、同期化対象のバーチャル機器に対応するリアル機器を制御する権限を持っている。従って、その場合には、ステップS30の判断は「エディット可能」に分岐する。なお、ステップS30では、ユーザロール情報35に基づいて分岐を行っていたが、その分岐を、ログイン中のユーザのユーザロール情報35と、取得したUserInfo情報45中の同ユーザのユーザロール情報のうち、示す権限が低いほうのユーザロール情報に基づいて行うようにしてもよい。その場合、UserInfo情報45に基づく権限チェックが、PC2側とアンプ側とで二重化され、セキュリティがより強化される。また、後述するアンプ側での権限判定(ステップS61)を省略することができるようにもなる。
一方、ログイン中のユーザのユーザロール情報35に設定された権限が「ユーザ」以下、すなわち、エリア内のアンプの制御権限がない場合(エリア内のアンプの閲覧権限を有する場合)は、ステップS30の判断は「エディット不可」に分岐する。ここでエディット不可に分岐することは、つまり、モニタ許可するということである。なお、この実施例では、エリア内で最初に同期化処理を行ったバーチャル機器が、その同期化処理の結果、モニタ状態になった場合(権限不足の場合、当該アンプが既に他のユーザによる制御を受けている場合、或いは、「Get Editable」ボタン78がオフ状態にある、すなわち、ユーザが自らモニタ状態になることを選択した場合)には、当該エリア内のバーチャル機器について、全て「エディット不可」に分岐するようテップS30の判断処理が構成される。この動作は、「エリアの機器の制御は、1台のPCが行う」という設計ポリシーに従うものである。
ステップS30の判断を「エディット可能」に分岐した場合、CPU20は、ステップS31において、現在同期化処理の対象のバーチャル機器に対応するリアル機器に対して、当該ログイン中のユーザにより該リアル機器を制御する許可を求める「制御要求」のコマンドを送信する。このとき、リアル機器には、制御要求とともに、ログインユーザのユーザIDと認証情報も送信される。該「制御要求」のコマンドを受信したリアル機器は、後述する図25に示す処理により、該ログイン中ユーザによる自機の制御を許可するか否かの判断を行い、その判断結果をPC2に返信する。
なお、PC2のCPU20は、前記ステップS31において制御要求を送った後、ステップS31でレスポンスを受けるまでの間の適宜のタイミングで、カレントプロジェクトに格納された当該エリアのエリアID46、当該PC2のコントローラID40、同期化処理対象のバーチャル機器が属するエリア情報33中のグループ情報36、およびカレントプロジェクト中のユーザ情報(アカウント情報34群)と、同期化処理対象のバーチャル機器が属するエリア情報33中のユーザロール情報35とを、リアル機器に対して送信する。ここで送信された情報群は、リアル機器側で制御を受け入れた場合に、該リアル機器側のコントローラID42、エリアID43、グループ情報44及びUserInfo情報45に上書きされる。
ステップS32において、CPU20は、前記「制御要求」に対する前記リアル機器からのレスポンス(返信内容)を判断する。前記リアル機器からのレスポンスには、「制御可」、「モニタ可」、および「拒絶」の3通りの種類がある。ユーザがリアル機器の制御権限を持ち、且つ、当該リアル機器が他のユーザから制御を受けていない場合には、リアル機器からのレスポンス(返信内容)は「制御可」である。ユーザがリアル機器の閲覧権限を持つ場合、又は、ユーザがエリア内のアンプの制御権限を持つが、当該リアル機器が他のPC2(他の制御主)から制御を受けている場合には、リアル機器からのレスポンス(返信内容)は「モニタ可」である。それ以外の場合、例えばユーザがリアル機器に何の権限も持たない「部外者」である場合や、リアル機器に当該ユーザのアカウント(ユーザIDと認証情報)がない場合には、この制御要求が不正であると判断して、リアル機器からPC2へ「拒絶」のレスポンスが送信される。
前記「制御要求」に対する前記リアル機器からのレスポンス(返信内容)が「制御可」であれば(ステップS32の「制御可」)、ステップS33において、CPU20は、カレントプロジェクトに格納された当該同期化対象のアンプに対応する装置情報37のOnLineステータス情報39の値に、「ONLINE」をセットする。なお、リアル機器は「制御可」のレスポンスとともに、該リアル機器に記憶されたコントローラID42(当該リアル機器の制御主のコントローラID)のデータも一緒に、PC2へ送信する。PC2のCPU20は、「制御可」のレスポンスとともに受信したコントローラID42の値を、カレントプロジェクトの当該同期化処理対象のバーチャル機器に対応する装置情報37のコントローラID40に上書きする。レスポンスが「制御可」の場合には、リアル機器のコントローラID42の値は、PC2自身のコントローラIDである。
また、前記ステップS33によりOnLineステータス情報39の値に「ONLINE」をセットしたときに、バーチャル機器の装置ID38とリアル機器の装置ID41が部分的にのみ一致している状態(つまり、両者の装置ID中のMACアドレス又はエリア内IDのいずれか一方のみが一致している状態)であれば、両者の装置IDを一致させる処理も併せて行う。装置IDのうちMACアドレスのみが一致している場合には、バーチャル機器の装置ID38でリアル機器の装置ID41を上書きする。また、装置IDのうちエリア内IDのみが一致している場合には、リアル機器の装置ID41でバーチャル機器の装置ID38を上書きする。また、このとき、リアル機器のIPアドレス、および機種情報を、バーチャル機器のIPアドレス、および機種情報(図4)に上書きする。
ステップS34において、CPU20は、バーチャル機器の装置情報37中の動作データと、リアル機器のメモリ11に記憶された動作データとの整合性、つまり両者の一致不一致の確認を行う。両者が一致していれば、CPU20は、バーチャル機器とリアル機器とのデータの同期化(シンクロ)処理は行う必要はないものと判断し(ステップイS35の「OK」)、このバーチャル機器に対する同期化処理を終える。
一方、バーチャル機器とリアル機器の動作データが不一致であった場合(ステップイS35の「NG」)、CPU20は、図19に示す「シンクロ方向選択画面」をディスプレイ24に表示する処理を行う。「シンクロ方向選択画面」には、同期化(シンクロ)の方向として、「シンクロ」(「Application→Device」)又は「逆シンクロ」(「Device→Application」)をユーザに選択させるラジオボタン69が設けられている。図19の例ではラジオボタン69は「シンクロ」方向を選択した状態になっている。また、ラジオボタン69の下部には、前記ステップS35でデータの不整合が検出されたアンプ名を表示する表示欄70が設けられている。図19の例では、表示欄60に「Amp3」というアンプ名が表示されている。ユーザは、ラジオボタン69を使って同期化処理の方向として「シンクロ」又は「逆シンクロ」のいずれか一方を選択し、「OK」ボタン画像71の操作により前記ラジオボタン69による方向の選択を確定する。つまり、アンプ(バーチャル機器)をオンライン状態にするときのオンライン化指示には、同期化方向の選択指示も含まれる。
CPU20は、ステップS36において、前記シンクロ方向選択画面でユーザにより選択された同期化処理の方向(シンクロ又は逆シンクロ)に従い、バーチャル機器とリアル機器のデータを同期化(シンクロ又は逆シンクロ)させる処理を行い、両者を一致させる。シンクロ方向として「シンクロ」が選択されているときは、前記ステップS36において、CPU20は、バーチャル機器の動作データを、ネットワーク越しに、リアル機器の動作データに上書きする処理を行う。つまり、カレントプロジェクトのデータの設定状態にリアル機器のデータ設定状態を一致させる。また、シンクロ方向として「逆シンクロ」が選択されているときは、前記ステップS35において、CPU20は、ネットワークを介してリアル機器の動作データを受信し、バーチャル機器の動作データにそれぞれ上書きする処理を行う。つまり、リアル機器のデータ設定状態に、カレントプロジェクトのデータの設定状態を一致させる。
また、前記ステップS30の判断で「エディット不可」に分岐した場合は、図示しないステップで「モニタ要求」をリアル機器に送信し、「制御要求」の場合と同様に、リアル機器から「モニタ可」又は「拒絶」のレスポンスを受け取る。ここで「モニタ可」のレスポンスを受け取った場合、又は、前記ステップS32において判定したレスポンスが「モニタ可」であった場合には、ステップS37において、CPU20は、カレントプロジェクトに格納された当該同期化対象のアンプに対応する装置情報37のOnLineステータス情報39の値に、「MONITOR」をセットする。なお、リアル機器のレスポンスが「モニタ可」のときには、リアル機器は、該レスポンスとともに、該リアル機器に記憶されたコントローラID42(当該リアル機器の制御主、つまり当該同期化処理を実行中のPC2とは別のPC2が持つコントローラID)のデータも一緒に、PC2へ送信する。すなわち、PC2は、前記ステップS32で「モニタ可」のレスポンスとリアル機器の制御主のコントローラID42を受け取る。
そして、ステップS38において、CPU20は、バーチャル機器とリアル機器のデータを同期化(逆シンクロ)させる処理を行い、両者を一致させる。このように、アンプ(バーチャル機器)をモニタ状態にする場合には、強制的に「逆シンクロ」で同期化処理が行われる。ここでは、リアル機器のメモリ11の記憶内容(図6参照)のうち、エリアID43とUserInfo情報45を覗くデータがPC2側に送信され、カレントプロジェクト内の対応するデータが前記リアル機器から送信されたデータにより上書きされる。具体的には、装置情報37中の装置ID38、機種情報、IPアドレス、動作データ、およびコントローラID40と、エリア情報33中のグループ情報36(「RackTree」情報、「Feed Structure Tree」情報、「User Defined Tree」情報)が、リアル機器のメモリ11の記憶内容で上書きされる。つまり、リアル機器のデータ設定状態に、カレントプロジェクトのデータの設定状態を一致させる。これにより、当該バーチャル機器は「モニタ状態(リアル機器をモニタ可能な状態)」になる。
なお、上記ステップS38の逆シンクロ処理を行うとき(つまり、バーチャル機器をモニタ状態に移行するとき)に、リアル機器の装置ID41で、装置情報37中の装置ID38を上書きしていることに留意されたい。すなわち、後述する「マッチング処理」でバーチャル機器の装置ID38とリアル機器の装置ID41が部分的に一致していた状態MACアドレス又はエリア内IDのいずれか一方のみが一致していた状態)でマッチングを成立させた場合には、上記ステップS38の逆シンクロ処理を行うときに、リアル機器の装置ID41で、装置情報37中の装置ID38が上書きされることになる。
ステップS29の判断で再認証が失敗した場合(ステップS29の「NG」)、あるいはステップS32において判定したレスポンスが「拒絶」だった場合(ステップS32の「拒絶」)、あるいは、リアル機器からの「モニタ要求」に対するレスポンスが「拒絶」であった場合には、当該バーチャル機器に対する同期化処理を終了する。このように同期化処理を終了する場合や、上記ステップS26〜S38までの同期化処理中に何らかのエラーが発生したときには、CPU20は、ディスプレイに、図20に示す「警告ダイアログ画面」を表示する。「警告ダイアログ画面」のメッセージ表示部73には、例えば「認証失敗」など、エラー乃至警告内容をユーザに通知するメッセージが表示される。なお、例えば、前記ステップS26の処理で認証情報が不一致だったときなどのように、「警告ダイアログ画面」とともに「パスワード入力画面」を表示する場合もある。同期化処理の継続が可能なエラーの場合には、処理の継続を指示する「Continue」ボタン画像74、および処理の中止を指示する「Skip」ボタン画像75が表示され、ユーザに当該バーチャル機器に対する同期化処理を継続するか否かを問う。また、ステップS29やS32の判断により当該アンプについて同期化処理を中止するときなど、同期化処理が継続不可能なエラーが生じたときには、「Continue」ボタン画像74、および「Skip」ボタン画像75は表示されず、その代わりに、警告メッセージ内容の了承をユーザに問う「OK」ボタン画像が表示される。この「OK」ボタン画像の操作に応じて、当該バーチャル機器に対する同期化処理を終了する。
上記ステップS26〜S38の処理により、1つのバーチャル機器に対する同期化処理が終了したら、ステップS39の判断により、同期化すべきバーチャル機器として特定されている全てのバーチャル機器に対する同期化処理が終了するまで、1つのバーチャル機器ずつ順番に、ステップS26〜S38の処理を繰り返す。これにより、1つのエリアに登録された全てのバーチャル機器(リアル機器と対応付けられたエリア内のバーチャル機器)の同期化処理が行われる。この同期化処理によりエリア内の各アンプに対するユーザの制御権限が、先着順(先に制御主がいる場合にはモニタまでしか許可されない)で設定される。各アンプ1ごとにUserInfo情報45を持つことからも、アンプの制御権限はアンプ1台ごとに設定されうるものであることは理解できる。しかし、この実施例のリモート制御ソフトは、エリア単位で制御を行うこと、言い換えれば、1つのエリアに対して1人の制御主がつくこと(1つのエリアを1つのPC2で制御すること)を本来の狙いとしている。よって、エリアの編集権限を持つ者は、1エリアに対して1制御主となるよう、エリアを設計すべきである。なお、図18の同期化処理の終了時に、同期化処理を実施したエリアのエリア情報33内に格納されたエリアの「Online」ステータス情報に「ONLINE」をセットする。なお、エリアの「Online」ステータス情報に「ONLINE」をセットするのは、同期化処理開始時(オンライン化指示ボタン画像68操作時)でもよい。
図17に示す「シンクロナイズドダイアログ」画面には、処理経過状況を示す表示欄76が設けられている。表示欄76には同期化処理の対象になっているエリア内のバーチャル機器のうち、リアル機器と対応付けがなされているバーチャル機器(同期化候補のバーチャル機器)のリストが表示される。リストの内容は、各アンプ(バーチャル機器)のアンプ名と、エリア内IDと、IPアドレスと、OnLineステータス情報とからなる。図の例では、リスト上のアンプはアンプ名の順で整列されている。OnLineステータス情報の初期値は、各アンプのOnLineステータス情報に格納された値に応じて、「ONLINE」、「MONITOR」又は「OFFLINE」のいずれかである。1つのアンプについて同期化処理が開始すると、該同期化処理進行中のアンプに対応するステータス情報欄には「Now Synchronizing」と表示される。また、既に同期化処理が終了したアンプに対応するステータス情報欄には「Completed」と表示される。図17の例は、対象のエリアに対して途中まで同期化処理が進行した状態を示しており、アンプ名「Amp1」、「Amp2」、および「Amp3」が同期化処理を既に終了しており、アンプ名「Amp4」が現在同期化処理進行中である。表示欄76の下部には、1エリア全体に対する同期化処理進行状況をパーセンテージで表すメータ77が設けられている。なお、同期化処理対象のエリアにインターフェース装置(「Area(1)」における「ACD(1)」、「ACD(2)」など)が含まれる場合には、それらインターフェース装置も表示欄76にリストアップされてよい。
上記図18の同期化処理により、或るバーチャル機器が対応するリアル機器に対してオンライン状態(ONLINE)になると、PC2において、当該バーチャル機器の動作データを編集する編集操作が行われたとき、その編集操作がネットワークを介して対応するリアル機器に伝達され、対応するリアル機器の動作データが編集されるとともに、その編集結果がネットワークを介してPC2に伝達され、カレントプロジェクト中の当該バーチャル機器(装置情報37)の動作データに反映される。また、対応するリアル機器において、動作データを編集する編集操作が行われると、そのリアル機器内の動作データが編集されるとともに、その編集結果がPC2に伝達され、カレントプロジェクト中の当該バーチャル機器(装置情報37)の動作データに反映される。また、リアル機器において検出される各種動作状態を示すデータ(例えば、出力段の温度、入力や出力の信号レベル、電源電圧、出力電圧、出力電流、負荷インピーダンス、あるいはプロテクションの状態など)は、リアル機器からPC2へ送信され、必要に応じて基本画面のレベル表示部52や状態表示部53等に表示される。
また、上記図18の同期化処理により、或るバーチャル機器が対応するリアル機器に対してモニタ状態(MONITOR)になると、該バーチャル機器は、ツリー表示部50のグループツリーで、前記ステップS38の逆シンクロ処理でリアル機器から受け取ったグループ情報44に基づくグループ内の機器として表示される。そして、リアル機器の動作データやグループ情報44等が編集されると、その編集内容がPC2のカレントプロジェクト中の当該バーチャル機器(装置情報37)の動作データやグループ情報36等に反映される。リアル機器において検出される各種動作状態を示すデータは、リアル機器からPC2へ送信され、必要に応じて基本画面のレベル表示部52や状態表示部53等に表示される。
ユーザが、図17に示す「シンクロナイズドダイアログ」画面のオフライン化指示(「Go−Offline」)ボタン画像68を操作すると、CPU20は、同期化処理対象のエリア内のバーチャル機器のうち、OnLineステータス情報39が「ONLINE」又は「MONITOR」のバーチャル機器に対応付けられたリアル機器をオフライン状態にするオフライン化処理を実行する。図21は、ユーザがオフライン化指示ボタン画像58を操作したときに、CPU20が実行する処理の動作手順の一例を示すフローチャートである。
ステップS40において、CPU20は、当該エリア内のバーチャル機器のうち、OnLineステータス情報39が「ONLINE」又は「MONITOR」のバーチャル機器に対応付けられたリアル機器の各々に対して、「開放」要求のコマンドを送信する。「開放」要求を受信した各リアル機器のうちの、該「開放」要求の送信元のPC2による制御を受けていたリアル機器は、後述する処理により、自機器を「開放」する処理を行う。この「開放」処理を行ったリアル機器では、コントローラIDが「Null」にセットされるとともに、UserInfo情報45がクリアされる。つまり、それらのリアル機器は、ユーザからリモート制御を受けていないフリーの状態になる。ステップS41において、CPU20は、カレントプロジェクト内の当該エリアのOnLineステータス情報と、当該エリア内の各バーチャル機器のOnLineステータス情報39の値を、それぞれOFFLINEにする。これにより、オフライン化指示以前には、オンライン状態だった当該エリア、および、当該エリア内のオンライン状態若しくはモニタ状態だったバーチャル機器は、全て、オフライン状態になる。
図22は、PC2のCPU20が所定時間間隔で実行するタイマ動作の動作手順の一例を示すフローチャートである。ステップS42において、CPU20は、プロジェクト内のオンライン状態のアンプ(リアル機器)がネットワークに接続されているかどうかを定期的にチェックするためのアクティブセンシング処理を行う。このアクティブセンシング処理は、OnLineステータス情報39が「ONLINE」又は「MONITOR」のバーチャル機器に対応付けられたリアル機器が、一定時間異常無操作又は無要求だった(何のデータも送ってこない)場合にのみ行う。
ステップS43において、CPU20は、前回のタイマ動作実行時以降に各リアル機器から受信した各種データを、図示しない受信履歴バッファから取得する。ここで、取得する「各種データ」には、各リアル機器がネットワーク接続時に発する「接続」メッセージ、各リアル機器での各種設定変更時に発生される「設定変更」メッセージ、あるいはバーチャル機器がオンライン状態にあるリアル機器から所定時間応答がないことを表す「無応答」メッセージなどである。「無応答」状態は、そのリアル機器がネットワークから物理的に切り離されたこと、又は、そのリアル機器の電源がオフされたことを意味し、アクティブセンシングでこのことを確認できる。「無応答」の場合、本ルーチンでは、CPU20はそのリアル機器がネットワークから切断されたものと判断する。
前記ステップ43により、新たなリアル機器が接続されたことを示す「接続」メッセージを検出した場合(ステップS44のYES)、CPU20は、ステップS45において「マッチング処理」を行うことで、該接続を検出したリアル機器とバーチャル機器の対応付けを行う。
また、前記ステップ43により「無応答」メッセージを取得した場合、つまりリアル機器の切断が検出された場合(ステップS46のYES)、CPU20は、ステップS47において、該切断が検出されたリアル機器に対応するバーチャル機器のOnLineステータス情報39の値を「OFFLINE」に変更する。これにより、該切断が検出されたリアル機器に対応するバーチャル機器はオフライン状態になる。
ステップS48において、CPU20は、上記ステップS45又はS47の処理結果に応じて、基本画面のツリー表示部50の表示を更新する処理を行う。前記ステップS45のマッチング処理により接続されたリアル機器とマッチングが取れたバーチャル機器があれば、そのバーチャル機器に対応する表示物の表示形態が、「実体無し」を表す表示形態(点線)から「実体有り」を表す表示形態(実線)に変更される。新たに接続されたリアル機器とマッチングが取れたバーチャル機器がない場合は、対応するバーチャル機器を生成して、デバイスツリーの「Unknown Device」カテゴリに表示する。また、前記ステップS47でOnLineステータス情報39が「OFFLINE」に変更されたバーチャル機器(切断されたリアル機器に対応するもの)については、そのバーチャル機器に対応する表示物の表示形態が、「実体有り」を表す表示形態(実線)から「実体無し」を表す表示形態(点線)に変更される。なお、エリア外のバーチャル機器に対応するリアル機器が切断された場合にも、それに対応する表示物(デバイスツリーの「UnknownDevice」にカテゴライズされた表示物)は消去せずに、「実体無し」を表す表示形態(点線)で表示する。例えば、前記図8(a)のデバイスツリーに例示した「Unknown Device」内の「AmpX」の表示物は、このケースに該当する。このようにして「Unknown Device」カテゴリに「実体無し」で残されたバーチャル機器は、デバイスツリーのオフライン編集に利用できるので便利である。あるエリアでパワーユーザー以上の権限を有するユーザは、「Unknown Device」カテゴリのバーチャル機器を、そのエリア内に移動することができる。その移動が行われた場合、移動されたバーチャル機器にはエリア内IDが付与され、対応する機器情報37が当該エリアのエリア情報33内に記憶される。
なお、図22に示すフローチャートではリアル機器の接続又は切断が検出されたときの動作のみを示したが、前記ステップ43でリアル機器の「設定変更」メッセージなどその他のメッセージを取得したときには、該取得したメッセージに対応する処理をCPU20は必要に応じて実行される。
図23は、前記図11のステップS8、前記図13のステップS12、あるいは前記図22のステップS45においてCPU20が実行する「マッチング」処理の動作手順の一例を示すフローチャートである。図22に示す動作手順は、1台のアンプに対するマッチング処理を示している。PC2は、ネットワークに接続されているリアル機器(アンプ)群を検出し、該検出されたリアル機器の1台毎に、図23に示す処理を実行する。
ステップS49において、CPU20は、マッチング対象のリアル機器に記憶されたエリアID43を取得して、カレントプロジェクトに記憶された各エリアのエリアID46と照合して、マッチング対象のリアル機器の属するエリアを特定する。エリアIDのマッチング(一致)がとれた場合(ステップS49の「一致」)、ステップS50において、CPU20は、リアル機器に記憶された装置ID41と、前記ステップS49により特定したエリア(エリアIDが一致したエリア)内の各装置情報37の装置ID38を照合する。一方、リアル機器に記憶されたエリアID43がカレントプロジェクト中のいずれのエリアID46とも一致しなかったならば(ステップS48の「不一致」)、当該アンプについてマッチング処理を終了する。
装置IDは、前述の通り、MACアドレス及びエリア内IDにより構成される。前記ステップS50おける装置IDの照合処理では、CPU20は、MACアドレス及びエリア内IDの少なくとも一方が一致していれば、リアル機器に記憶された装置ID41と、装置情報37の装置ID38の対応付けが取れたものと判断する。具体的には、この実施例では、MACアドレスを使って装置IDのマッチングができなかった場合に、エリア内IDで装置IDのマッチングをするよう、前記ステップS50の装置IDの照合処理が構成されるものとする。MACアドレスを使って装置IDのマッチングができなかった場合とは、MACアドレスが不一致の場合、若しくは、バーチャル機器(装置情報37)の装置ID38にMACアドレスが入っていない場合である。
MACアドレス及びエリア内IDの少なくとも一方が一致していれば(ステップS50の「少なくとも片方が一致」)、ステップS51において、CPU20は、そのバーチャル機器とリアル機器とのマッチング(装置IDとエリアID)を記憶する。なお、装置IDに含まれるMACアドレス及びエリア内IDの少なくとも一方が一致していた場合(装置IDが部分的に一致していた場合)、バーチャル機器の装置ID38とリアル機器の装置ID41を一致させる処理(装置IDの上書き)はここでは行わない。その場合には、当座のところ、装置IDは部分的にのみ一致した状態にしておく。バーチャル機器の装置ID38とリアル機器の装置ID41を一致させる処理(装置IDの上書き)は、前記図18に示す同期化処理で行われるからである。なお、マッチングが取れた場合は、各ツリーの表示におけるその対応付けがとれたバーチャル機器の表示を、「実体無し」表示(点線)から「実体有り」表示(実線)に変更する。
ステップS52において、CPU20は、リアル機器に記憶された機種情報と、前記ステップS49で装置IDをマッチングしたバーチャル機器(装置情報37)の機種情報を照合して、機種情報が一致していれば、そのまま当該アンプについてマッチング処理を終了し、当該マッチング処理対象のリアル機器とバーチャル機器のマッチングが成立する。また、機種情報が不一致の場合(ステップS52の「不一致」)には、ステップS53において、CPU20は、機種情報が不一致であった旨をユーザに警告する警告表示をディスプレイに表示する処理を行い、当該アンプについてマッチング処理を終了する。すなわち、機種情報が不一致であってもバーチャル機器とリアル機器のマッチング自体は成立させる。その場合、マッチングされたバーチャル機器は、同期化処理によってオンライン状態にすることはできないが、モニタ状態にすることはできる。
また、前記ステップS50で、MACアドレス及びエリア内IDの両方が不一致の場合には(ステップS50の「不一致」)、当該アンプに対するマッチング処理を終了する。また、複数のアンプで装置IDの一部が重複してしまった場合には(ステップS50の「一部重複」)、ステップS54において、CPU20は、複数装置での装置IDの一部重複をユーザに警告する警告表示をディスプレイに表示する処理を行い、当該アンプについてマッチング処理を終了する。この場合には、重複が生じたバーチャル機器は、オンライン状態にもモニタ状態にもすることができない。このような重複を防ぐために、既にマッチング済みのバーチャル機器を、図23の処理におけるリアル機器とのマッチング処理の対象から外すようにしてもよい。
図23に示すマッチング処理により、ネットワークに接続されたリアル機器と、カレントプロジェクトのエリアに登録されたバーチャル機器との対応付け(マッチング)を自動的に行うことができる。このマッチング処理は、エリアIDに基づくマッチング(ステップS49)と、MACアドレス及びエリア内IDの少なくともいずれか一方に基づく装置IDを使ったマッチング(ステップS50)により実現される。従って、例えば、過去に使用したプロジェクトファイルを、該過去に使用したのと同じ構成の音響システムで利用する場合には、プロジェクト中の各エリア内のバーチャル機器に与えられたエリアIDや、MACアドレス等が、該音響システム中の各リアル機器が持つエリアIDや、MACアドレス等と一致するので、プロジェクト中の各エリア内のバーチャル機器と、音響システム上の各リアル機器とを、自動的に、マッチングすることができる。また、一部又は全部のリアル機器を同じ機種の別のリアル機器に置き換えた場合でも、そのリアル機器に同じエリアIDとエリア内IDをセットしておけば、同様に自動マッチングができる。この実施例では、ユーザは、アンプ1の操作パネル15を使って、エリアID43とエリア内IDとをそれぞれ入力できるようになっている。
なお、ログイン中のユーザが「パワーユーザ」(エリアの編集権限)以上の権限を持つユーザのときには、マッチング処理の構成は下記の通りに変更される。すなわち、ステップS49の「エリアIDの照合」行う前に、ステップS50の装置IDのMACアドレスでマッチングをとる。それでマッチングがとれない場合に、エリアIDとエリア内IDとでマッチングをとる。これにより、自動マッチングをよりフレキシブルに行うことができる。例えば、同じリアル機器を使用するあるプロジェクトファイルを閉じて別のプロジェクトファイルを開くとき、該あるプロジェクトファイルでオンラインしていた複数の機器を、別のプロジェクトファイルで自動マッチングすることができる。
なお、この実施例では、ユーザは、アンプ1の操作パネル15を使ってエリアIDとエリア内IDを入力できるようになっているが、これは、あくまでも自動マッチングのためである。オンライン状態のアンプ1のエリアIDやエリア内IDが操作パネルで変更されると、システム全体の動作に重大なエラーを起こしかねない。そのため、リアル機器(アンプ1)がオンライン状態にある場合には、操作パネル15からエリアIDやエリア内IDが変更できないようにロックがかけられている。同様に、PC2についても、オンライン中のエリアのエリアID、オンライン中のバーチャル機器のエリア内IDは、変更できないようにロックされる。
また、エリア内IDのみを使ったマッチング処理が可能なことから、例えば、音響システムで使用中の複数のアンプ1(リアル機器)のうちの1つ故障した場合など、既存のリアル機器を別のリアル機器に交換する場合に、該別のリアル機器のマッチング処理を簡単に行うことができる。すなわち、別のリアル機器のエリア内IDとして、前記既存のリアル機器(交換相手)に付与されていたエリア内IDと同じ値を設定しておき、該既存のリアル機器(交換相手)をネットワークから切断し、該別のリアル機器をネットワークに接続して、該別のリアル機器のマッチングを行えば、該既存のリアル機器(交換相手)に変えて、該別のリアル機器が、自動的に、元は既存のリアル機器に対応付けられていたバーチャル機器にマッチングされる。従って、音響システム上のアンプ1の交換(取替え)作業などが簡単に行えるようになる。
また、前記図23に示すマッチング処理によれば、エリアIDと装置IDを使ってリアル機器とバーチャル機器の対応付けを行っていることから、カレントプロジェクト中のいずれかのエリアに登録されたバーチャル機器の装置ID38に一致する装置ID41を持つリアル機器(該バーチャル機器に対応するリアル機器)がネットワーク接続されており、且つ、そのリアル機器が持つエリアID43が、該バーチャル機器が登録されたエリアのエリアID46に一致する場合、つまりリアル機器がカレントプロジェクト中のいずれかエリアに属する場合にのみ、バーチャル機器とリアル機器のマッチングが成立する。そして、該マッチング処理により、エリア内のバーチャル機器が実際のリアル機器と対応付けできた場合にのみ、PC2は、そのリアル機器を、前述した図17に示す同期化処理で同期化し、制御又はモニタすることができる。よって、例えば、或るPC2から或るエリア内のリアル機器をモニタしている(そのエリア内の各リアル機器には別の制御主がいる)ときに、該別の制御主のカレントプロジェクトで、そのエリアに新たにリアル機器が追加されたとしても、該或るPC2で立ち上げているカレントプロジェクト中のエリアに、その新たに追加されたリアル機器に対応すべきバーチャル機器が登録されていなければ、当該PC2から該新たに追加されたリアル機器をモニタすることはできない。この場合、同一エリア内の一部のリアル機器のみがPC2からモニタされることになる。
また、リアル機器が検出されても、カレントプロジェクト中のエリアに登録されたバーチャル機器に対応するものがなければ(ステップS49の「不一致」又はステップS50の「不一致」)、該リアル機器の対応付けは成立しない。この場合、ツリー表示部50のデバイスツリーに「エリア外のバーチャル機器」が表示されることは既に述べたとおりである。カレントプロジェクト中で或るエリアから削除されたバーチャル機器又は別のエリアに移動されたバーチャル機器に対応するリアル機器は、前記図23に示すマッチング処理によれば、エリアIDの不一致により、「エリア外のバーチャル機器」と判断される。この場合、そのバーチャル機器とリアル機器のマッチングが成立しないので、PC2は、そのリアル機器のことを、制御及びモニタすることはできない。あるエリアでパワーユーザ以上の権限を有するユーザは、そのエリアがオフライン状態にあるとき、エリア外のバーチャル機器をそのエリア内に移動することができる。その後に、そのエリアをオンライン化すれば、そのバーチャル機器には、そのエリアにおけるエリア内IDが付与され、対応するリアル機器には、そのエリア内のリアル機器としての設定が行われる。
また、バーチャル機器とリアル機器はそれぞれグループ情報(グループ情報36、グループ情報44)を記憶しており、エリア内でグループ化可能であるが、マッチング処理ではバーチャル機器とリアル機器の対応付けに、グループ情報は使用されない。よって、バーチャル機器を或るグループから同じエリア内の別のグループに移動された場合(つまりグループ情報36とグループ情報44が不整合になった場合)でも、そのバーチャル機器とリアル機器では、エリアIDと装置IDの一致は取れているので、両者のマッチングをとることができる。PC2から或るエリア内のリアル機器をモニタする場合に、該PC2のカレントプロジェクトの該或るエリアのエリア情報33内に格納されたグループ情報36と、該或るリアル機器が持っているグループ情報44が不整合であっても、(1)述べた通り、両機器のマッチングはエリアIDと装置IDでとることができ、(2)同期化処理によりモニタ状態に移行するときには前記ステップS38で「逆シンクロ」処理を行うため、該或るリアル機器が持っているグループ情報44でグループ情報36が上書きされる。よって、リアル機器が同じエリアの別のグループに移動された場合、モニタを行うPC2では、そのリアル機器を移動先のグループに属する機器として自動的に認識し、該移動先のグループに属する機器として、その動作データをモニタすることができる。
なお、この実施例では、前記ステップS50の装置IDの照合処理において、MACアドレスでマッチングがとれなかったときに、エリア内IDを使ってマッチングを行うように処理を構成するものとしたが、PC2側(装置情報37)の装置ID38にMACアドレスが記憶されていない場合に限り、エリア内IDを使ってマッチングを行うように処理を構成してもよい。このようにステップS50の処理を構成した場合、MACアドレスの不一致は、装置IDの不一致と判断される。
図24は、アンプ1のCPU10が実行する全体的な動作手順の概要を説明するフローチャートである。なお、ここで述べる動作は、CPU10が実行する制御プログラムによって実現されるアンプ1の制御に関する動作であって、音響信号処理の動作(DSP13及び電力増幅部14の動作)ではない。このフローチャートに示す処理はアンプ1の電源オンに応じて開始する。ステップS55において、CPU10は所定初期化処理を行う。この初期化処理には、IPアドレスの設定や、自機のネットワーク接続を通知する「接続」メッセージをネットワーク上にブロードキャストする処理等が含まれる。
ネットワーク上のPC2から何らかのコマンドを受信したときには(ステップS56の「あり」)、CPU10は、ステップS57において、該受信したコマンドに応じた処理を実行する。受信したコマンドに応じてCPU10が実行する処理の具体例は後述する。また、ユーザが、当該アンプ1のパネル操作子(ユーザインターフェース15)を操作した場合には(ステップS58の「あり」)、CPU10は、ステップS59において、前記パネル操作に応じた処理を実行する。パネル操作には、例えば、エリア内IDの設定操作などが含まれる。エリア内IDの設定操作は、具体的には、数値の入力である。エリア内IDの設定操作が行われた場合には、CPU10は、当該アンプ1(リアル機器)のメモリ11のエリア内IDに、前記入力された数値を格納する。
アンプ1は電源がオフされるまで、前記ステップS56〜S59の処理を繰り返し実行する。
図25は、前記図18のステップS31においてPC2から送信される「制御要求」を受信したときに、アンプ1のCPU10が前記ステップS57で実行する処理の動作手順の一例を示すフローチャートである。ステップS60において、CPU10は、アンプ1のメモリ11に格納されたUserInfo情報45と、前記「制御要求」の送信を行ったユーザ(カレントプロジェクトにログイン中のユーザ)のゆーざIDとアカウント情報34を比較して、ユーザ認証を行う。ユーザ認証では、当該アンプ1のメモリ11に記憶されたUserInfo情報45の中に、前記要求を行ったユーザのアカウント情報34(ユーザIDと認証情報)があるかどうか、また、UserInfo情報45の中にユーザのアカウントがあれば、そのアカウントに与えられた権限を調べて、アンプ1の制御権限を持っているかどうかを判断する。なお、前記UserInfo情報45がクリアされている場合は、ユーザのアカウント情報34が何であっても制御権限有り(ステップS61の「OK」)と判断する。
UserInfo情報45の中に、前記要求を行ったユーザのアカウント情報34があり、また、そのアカウントがアンプ1の制御権限を持っていれば、CPU10は、ユーザ認証が成立したものと判断(ステップS61の「OK」)する。そして、ステップS62において、CPU10は、アンプ1のメモリ11に記憶されたコントローラID42に制御主のIDが入っているかどうかを調べることで、前記制御要求を行ったPC2とは別のPC2によるリモート制御を、現在当該アンプ1が受けているかどうかを判断する。コントローラIDに制御主のコントローラIDが入っているならば、アンプ1のCPU10は、既に当該アンプ1をリモート制御している制御主(別のPC)があると判断する(ステップS62の「有り」)。その場合、もしくは、前記ステップS60のユーザ認証において、前記要求を行ったユーザのアカウント情報34が、アンプ1のUserInfo情報45に含まれているが、UserInfo情報45の中の対応するユーザロールの示す権限が、閲覧権限だった場合(つまりユーザの権限が不足する場合)には、ステップS63において、CPU10は、前記「制御要求」の送信したPC2に対して、モニタを許可する旨を伝えるレスポンス(「モニタ可」)を送信する。つまり、後発の制御要求は受け付けない。言い換えれば、アンプ1の制御権は先着順に取得される。なお、「モニタ可」のレスポンスを返すとき、コントローラID42に入っているIDの値(既にリモート制御をしている制御主(別のPC)のコントローラID)も一緒に、PC2へ送信される。これにより、該PC2に対して当該アンプ1をリモート制御している別のPCのコントローラIDが通知される。なお、ステップS62の判定で、PC2のコントローラIDとの一致を考慮するようにしてもよい。即ち、コントローラIDに制御主のコントローラIDが入っていない場合だけでなく、入っていてもそのコントローラIDがPC2から取得するコントローラIDと一致する場合に、ステップS62で「無し」(Null)に分岐させるようにしてもよい。
一方、アンプ1のメモリ11に記憶されたコントローラID42に値が入っていない(コントローラID=Null)ならば、このアンプ1をリモート制御をしている制御主(別のPC)がいないということを意味する。アンプ1のCPU10は、既に当該アンプ1をこのアンプ1がいずれのPCからもリモート制御を受けていないものと判断する(ステップS62の「無し」)。その場合、CPU10は、ステップS64において、前記「制御要求」の送信元のPC2(新たな制御主)から、そのPC2のコントローラIDと、カレントプロジェクト中で当該アンプ1に対応付けられたバーチャル機器が登録されているエリアのエリアID46と、同エリアのグループ情報36(「RackTree」、「Feed Structure Tree」、および「User Defined Tree」)を取得し、該取得した各情報に基づきアンプ1のメモリ11のコントローラID42と、エリアID43と、グループ情報44(「RackTree」、「Feed Structure Tree」、および「User Defined Tree」の各グループでの当該アンプの位置情報)を更新する。
また、ステップS65において、CPU10は、PC2(新たな制御主)から、そのPC2のカレントプロジェクトのユーザ情報(全ユーザのアカウント情報34)と、カレントプロジェクト中で当該アンプ1に対応付けられたバーチャル機器が登録されているエリアに含まれるユーザロール情報35とを取得して、該取得したアカウント情報34とユーザロール情報35とに基づきアンプ1のメモリ11のUserInfo情報45を更新する。これにより、アンプ1は、自機の制御主であるPC2(該PC2に現在開いているカレントプロジェクト)に設定されているのと同じアカウント情報、並びに、該アカウント中の各ユーザのユーザロール情報を持つことになる。
そして、CPU10は、ステップS66において、前記「制御要求」の送信したPC2に対して制御を許可する旨を伝えるレスポンス(「制御可」)を送信する。このとき、前記ステップS63で更新したコントローラIDの値も一緒に、PC2へ送信する。このコントローラIDは、その送信先のPC2のコントローラIDである。
前記ステップS66でPC2へ送信された「制御可」のレスポンス、又は、前記ステップS63PC2へ送信された「モニタ可」のレスポンスに基づき、該PC2のCPU20が前記図18の同期化処理におけるステップS31の判断を行うことは、既に述べたとおりである。
また、前記ステップS60のユーザ認証において、該「制御要求」を行ったユーザのアカウントがアンプ1に記憶されたUserInfo情報45の中に存在しない場合には、アンプ1のCPU10はユーザ認証に失敗したものと判断し(ステップS61の「NG」)、ステップS67において該「制御要求」の送信元のPC2に対して、制御要求を拒絶する旨を伝えるレスポンス(「拒絶」)を送信する。なお、前記ステップS60のユーザ認証で、PC2の対応するバーチャル機器のエリアIDとの一致を考慮するようにしてもよい。即ち、リアル機器のUserInfo情報45に前記要求を行ったユーザのアカウント情報34が存在しない場合だけでなく、PC2から取得する対応するバーチャル機器のエリアIDとリアル機器のエリアIDが不一致の場合に、ステップS61で「NG」に分岐させるようにしてもよい。
図26は、前記図21のステップS40においてPC2から送信される「開放」要求のコマンドを受信したときに、アンプ1のCPU10が前記ステップS57で実行する処理の動作手順の一例を示すフローチャートである。ステップS68において、CPU10は、自機のコントローラID42の値を「Null」にセットするとともに、UserInfo情報45をクリアする。これにより、当該アンプ1はいずれのユーザ(PC2)からもリモート制御を受けていないフリーの状態になる。ステップS69において、CPU10は、自機がリモート制御から「開放」された旨を通知するメッセージを、ネットワーク上にブロードキャストする。
図27は、PC2からアンプ1の各種データの設定状況や動作状況等に関する情報の提供を要求されたときに、アンプ1のCPU10が前記ステップS57で実行する処理の動作手順の一例を示すフローチャートである。CPU10は、PC2から要求された自機の設定状況や動作状況等に関する情報を、該要求したPC2に返信する(ステップS70)。前記ステップS70においてPC2へ返信される情報は、例えば、アンプ1の機種情報、当該アンプ1の動作データの値、音響信号の入力レベル、同出力レベル、あるいは、増幅部14の温度レベルなどであって、自機のメモリ11に記憶されたデータの一部(PC2から要求されたもの)である。なお、例えば音響信号のレベルなど、アンプ1の動作状況に関する情報等は、アンプ1を制御中又はモニタ中のPC2に定期的に提供されてもよい。つまり、図27と同種の動作(PC2への情報提供)は、PC2からのコマンドが無くとも実行される可能性がある。なお、図27の処理は、情報を要求したユーザのアカウント情報34がUserInfo情報45に含まれており、且つ、UserInfo情報45の中の対応するユーザロールの示す権限が閲覧権限以上であることを条件に実行されるようにしてもよい。この場合、アンプ側とPC2側での二重の権限チェックとなる。
図28は、図14のステップS15においてPC2から送信される「操作要求」のコマンドを受信したときに、アンプ1のCPU10が前記ステップS57で実行する処理の動作手順の一例を示すフローチャートである。ステップS71において、CPU10は、該操作要求の要求元のPC2による操作要求を受け入れるかどうか判断する。該ステップS71の判断で、操作要求を受け入れる場合とは、記操作要求を行った要求元のPC2のコントローラIDと自機のメモリ11に格納されたコントローラID42(制御主のコントローラID)が一致している場合、つまり操作要求の送信元のPC2が当該アンプ1の制御主である場合、且つ、要求元のPC2にログイン中のユーザが当該アンプ1の制御権限を持つ場合である。一方、該ステップS71の判断で、操作要求を受け入れない場合とは、前記操作要求を行った要求元のPC2のコントローラIDと自機のメモリ11に格納されたコントローラID42が不一致の場合、つまり操作要求の送信元のPC2とは別のPCが当該アンプ1の制御主である場合、および要求元のPC2にログイン中のユーザに権限が不足している場合の少なくともいずれか一方の場合である。操作要求が受け入れらない場合(ステップS71の「NG」)、この処理は終了する。なお、PC2のコントローラIDと同じIDがアンプのメモリ11のコントローラIDと一致するということは、図18のステップS30でログインユーザに当該エリアの制御権があると判断されPC2のコントローラIDがメモリ11に書き込まれたということを意味するので、ステップS71と合わせて二重の権限チェックが行われていることになる。
操作要求が受け入れられたら(ステップS71の「OK」)、CPU10は、ステップS72においてPC2から送信されたコマンド(操作の内容)に応じて、自身のメモリ11中のデータを更新し、ステップS73において、前記ステップS72によるデータ更新後の状態(設定変更メッセージ)をネットワーク上にブロードキャストする。ここで、変更状態(設定変更メッセージ)を、制御主のPC2のみならずネットワーク全体にブロードキャストしているのは、該変更状態(設定変更メッセージ)を、モニタのみ許可されたユーザ(制御主以外のPC2)にも通知するためである。これにより。設定変更メッセージを受け取った全てのPC(制御主のPCと、それ以外のPC)のバーチャル機器に、リアル機器の変更状態が反映される。
図29は、アンプ1のCPU10が所定時間間隔で実行するタイマ動作の動作手順の一例を示すフローチャートである。ステップS74において、アンプ1のCPU10は、ネットワーク上のPC2(全部)に対するアクティブセンシングを行い、その結果、ネットワーク上のPC2から所定時間無応答であれば(ステップS74の「YES」)、ステップS75において、自機のコントローラID42の値を「Null」にセットするとともに、UserInfo情報45をクリアする。これにより、アンプ1のCPU10は、自機をリモート制御を受けないフリーの状態にする。そして、ステップS75において、アンプ1のCPU10は、自機がリモート制御から「開放」された旨を通知するメッセージを、ネットワーク上にブロードキャストする。
なお、前記ステップS75でブロードキャストされた開放通知を受けたPC2において、当該アンプ1が属するエリアの編集権限を持った「パワーユーザ」がログオン中であったならば、そのPC2のCPU20は、前記図18に示す同期化処理を実行して、前記開放通知を発信したアンプ1をオンライン状態にする。このときに実行する同期化処理は、該開放通知を発信したアンプ1の1台のみを対象に、ステップS26以下の処理を実行するだけでもよいし、当該エリアに登録された全てのアンプを対象にしてもよい。
なお、上記図18の同期化処理の説明においては、ステップS31で制御要求を送信してから、ステップS32でレスポンスを受けるまでの間に、コントローラID、エリアID、グループ情報、ユーザ情報、およびユーザロール情報を、アンプ1に送信するものとしたが、図25のアンプ側の制御要求に応じた処理において、ステップS64及びステップS65の情報更新よりも先に、ステップS66の「制御可」のレスポンス返信を行うのであれば、PC2側から上記各情報を送信するタイミングは、ステップS31〜S32(OnLineステータスの設定)の間の適宜のタイミングであってよい。
また、上記実施例では、ステップS31の「制御要求」の送信後、そのレスポンスを受けるまでの間に、PC2からリアル機器に、エリアID46、コントローラID40、グループ情報36、アカウント情報34、およびユーザロール情報35を必ず送信するようになっていたが、それら送信した情報でリアル機器側の情報を「上書き」するのは、ステップS32で「制御可」の応答を受ける場合だけであり、それ以外の場合のネットワーク上のデータ転送は無駄である。この部分を改良して、ステップS32の判定後に、その判定が「制御可」であった場合のみ、それらの情報をPC2からリアル機器に送るようにしてもよい。その場合、図25のステップS64〜S66は、まずステップS66、次にステップS64、その次にステップS65という順に処理されるよう処理順序を変更しなければならない。
また、上記実施例では、権限チェックがアンプ側とPC側とで二重化されている所が複数あるが、それぞれ、アンプ側およびPC側の何れか一方のみで権限チェックするようにしても良い。
また、上記実施例では、装置ID38及び装置ID41は、アンプ1のMACアドレスとエリア内IDとから構成されるものとしたが、装置IDはアンプを特定する何らかのID情報(固定的なものが望ましい)と、エリア内IDとを組み合わせた情報であれば、実施例の構成に限定されない。
また、上記実施例においては、パワーアンプ装置1と、これを制御するパーソナルコンピュータ2がネットワーク接続された音響システムに、本発明を適用する例について説明したが、音響システムの構成は、上記実施例に限定されるものではなく、音響機器と、これを制御する制御装置がネットワーク接続された音響システムであれば、本発明を適用することができる。音響機器は、パワーアンプ装置に限らず、例えば、オーディオミキサ、レコーダなどを適用してもよい。
また、上記実施例のリモート制御ソフトでは、複数のエリアを作成できるようになっていたが、予め用意された1エリアのみを使用し、新規エリアを作成できないリモート制御ソフトであってもよい。
また、ツリー表示部50において、エリア、グループ、グループの構成(ツリー)、およびアンプを表す表示物(バーチャル機器)の各種表示態様、例えばアイコン形状、表示フォント、あるいは表示色などをユーザが設定できるようにして、音響システムをモニタするPCにおいて、エリア、グループ、グループの構成(ツリー)、およびアンプを表す表示物の各種表示態様も、モニタ対象を制御しているPCに設定された表示態様と同じにするよう構成することもできる。
以上説明した通り、この実施例によれば、アンプ1側に記憶されたUserInfo情報45にアカウントがないユーザ、および該UserInfo情報45が持つ権限が不足しているユーザの少なくともいずれか一方に該当すれば、PC2からアンプ1を制御又はモニタすることができないので、意図しないユーザによってアンプ1が制御又はモニタされてしまうことを効果的に抑止して、ネットワーク上のアンプ1を保護することができるという優れた効果を奏する。
1 パワーアンプ装置(音響機器)、2 パーソナルコンピュータ(制御装置)、10 CPU、11 メモリ、12 オーディオI/O 13 信号処理部(DSP)、14 電力増幅部、15 ユーザインターフェース、16 通信I/F、20 CPU、21 メモリ、22 HDD、23 通信I/Fオーディオ、24 ユーザインターフェース、31 プロジェクトライブラリ、32 プロジェクトファイル、33 エリア情報、34 アカウント情報、35、ユーザロール情報、36 グループ情報、37 装置情報、38 装置ID、39 OnLineステータス情報、40 コントローラID、41 装置ID、42 コントローラID、43 エリアID、44 グループ情報、45 UserInfo情報、50 ツリー表示部、52 レベル表示部、53 状態表示部、54 アッテネータ操作部、67 オンライン化指示ボタン画像、68 オフライン化指示ボタン画像