JP5720656B2 - 音楽システム管理方法 - Google Patents

Description

この発明は、１のコンピュータで起動された管理ソフトプロセスが、このコンピュータにネットワークを介して接続された複数のコンピュータで起動された複数の音楽ソフトプロセスと、該ネットワークに接続された複数のコントローラとを制御して、１つの音楽システムとして動作させる音楽システム管理方法に関する。

従来から、コンピュータを用いて、演奏データの録音や編集、ミキシング等の音響処理作業を行うことが知られている。コンピュータは、ＰＣ（パーソナルコンピュータ）等の汎用のコンピュータとされ、オーディオインターフェースやＭＩＤＩ Ｉ／Ｆ（Musical Instrument Digital Interface）などの各種ハードウェア装置を備えており音楽ソフトがインストールされている。ＰＣにインストールされる従来の音楽ソフトとして、ＤＡＷ（Digital Audio Workstation ）と呼ばれるアプリケーションソフトウェアが知られている。ＤＡＷプロセスが起動されたＰＣは、音楽処理装置として機能し、演奏データに応じた楽曲の演奏や、オーディオ信号の録音／再生、編集、ミキシングなどの音楽処理を実行することができるようになる。

ＰＣで動作するＤＡＷの音楽ソフトの機能は充実しており、ＰＣに音楽ソフトをインストールすることで個人でも簡単に音楽制作ができるようになる。一方、音楽ソフトの機能が豊富になったことから、マウスやＰＣのキーボードで、ＰＣで起動された音楽ソフト（ＤＡＷ）プロセスの全ての操作やパラメータの設定を行う場合は、その操作が煩雑になってきている。そこで、高度な音楽制作の現場では、音楽ソフトがインストールされたＰＣに、音楽ソフトプロセスの操作のためのフィジカルコントローラを接続して、このフィジカルコントローラに備えられているつまみ、スライダ、ボタンなどの操作子を使用して演奏データやオーディオデータの録音／再生、編集、ミキシングを行う際の操作やパラメータの設定を行うことが行われている（特許文献１参照）。

また、音楽ソフトをインストールした複数のＰＣをネットワークに接続すると共に、各ＰＣで起動された音楽ソフトプロセスを制御するコントローラをネットワーク接続する音楽システムが知られている。この音楽システムでは、コントローラとＤＡＷプロセスの接続を管理するプロセス（管理ソフトプロセス）が、ＤＡＷプロセスと共に各ＰＣで起動される。そして、コントローラの操作パネル上の接続切替用のスイッチの操作に応じて、コントローラの制御対象である音楽ソフトプロセスを切り替えるようにしている（非特許文献１参照）。

特開２０１１−５９２３２号公報

Mc Mix ユーザーオペレーションガイドマニュアル（和文），P.11-18,P.38-42，［online］, ［平成２４年４月３日検索］，インターネット<http://connect.euphonix.com/documents/MC_Mix_User_Guide_rB_Jap.pdf>

従来の音楽システムにおいては、複数のＰＣで音楽ソフトプロセスが起動されている場合、各ＰＣ毎に独立した管理ソフトプロセスが起動されているので、あるコントローラがリモート制御する音楽ソフトプロセスを別の音楽ソフトプロセスに切り替えるためには、複数のＰＣの複数の管理ソフトプロセス間で通信を行い、複数の管理ソフトが連携して切り替えなければならないことから、音楽ソフトプロセスの切り替えに時間がかかってしまうという問題点があった。
そこで、本発明は、１のコンピュータで起動された管理ソフトプロセスが、このコンピュータにネットワークを介して接続された複数のコンピュータで起動された複数の音楽ソフトプロセスと、該ネットワークに接続された複数のコントローラとを制御して、１つの音楽システムとして動作させることにより、音楽ソフトプロセスの切り替えを高速に行うことができる音楽システム管理方法を提供することを目的としている。

上記目的を達成するために、本発明の請求項１にかかる音楽システム管理方法は、１のコンピュータで起動された管理ソフトプロセスが、ネットワークを介して接続されている複数のコンピュータで起動された複数の音楽ソフトプロセスと、該ネットワークに接続された複数のコントローラとを制御して、１つの音楽システムとして動作させる音楽システム管理方法であって、前記管理ソフトプロセスは、ユーザから、前記複数の音楽ソフトプロセスと前記複数のコントローラの中から所望の音楽ソフトプロセスとコントローラの選択を受け付ける第１の過程と、前記ネットワークを介して、前記第１の過程で受け付けられた音楽ソフトプロセスおよびコントローラと通信を行い、該音楽ソフトプロセスおよびコントローラと前記管理ソフトプロセスの間で管理通信を行うための管理セッションを前記ネットワーク上に確立する第２の過程と、ユーザから、各コントローラに対して制御対象となる１の音楽ソフトプロセスの選択を受け付ける第３の過程と、前記管理セッションを介して、各コントローラおよび前記第３の過程で受け付けられた１の音楽ソフトプロセスと通信を行い、該コントローラの現在の制御セッションを開放するとともに、前記ネットワーク上に、該コントローラと該１の音楽ソフトプロセスの間で制御通信を行うための新たな制御セッションを確立する第４の過程とを有し、ユーザによる各コントローラの操作に応じて、当該コントローラは、当該コントローラとの間に制御セッションが確立された音楽ソフトプロセスを、前記制御セッションを介してリモート制御することを最も主要な特徴としている。

また、本発明の請求項２にかかる音楽システム管理方法は、前記ネットワーク上の複数のコンピュータで複数の管理ソフトプロセスが起動され、前記複数の音楽ソフトプロセスおよび前記複数のコントローラは、それぞれ、前記複数の管理ソフトプロセスのうちの何れか１つの管理ソフトプロセスのみとの間に前記管理セッションを確立することができ、前記複数の管理ソフトプロセスのうちの何れか１つの管理ソフトプロセスと、当該管理ソフトプロセスとの間に管理セッションが確立された音楽ソフトプロセスおよびコントローラにより１つの音楽システムが構築され、結果として、前記ネットワーク上には、複数の管理ソフトプロセスに対応する複数の音楽システムが構築されることを特徴としている。

さらに、本発明の請求項３にかかる音楽システム管理方法は、請求項２に記載の音楽システム管理方法において、前記複数の管理ソフトプロセスのそれぞれは、さらに、当該管理ソフトプロセスとは異なる管理ソフトプロセスとの間において、既に管理セッションが確立されている音楽ソフトプロセス又はコントローラとの間で、割込通信を行うための割込セッションを一時的に確立する第５の過程と、前記割込セッションを介して、該割込セッションが確立された音楽ソフトプロセス又はコントローラと通信を行い、該割込セッションを開放させるとともに、前記ネットワーク上に、該音楽ソフトプロセスおよびコントローラと当該管理ソフトプロセスの間で管理通信を行うための管理セッションを確立する第６の過程とを有していることを特徴としている。

さらにまた、本発明の請求項４にかかる音楽システム管理方法は、請求項２に記載の音楽システム管理方法において、前記複数の管理ソフトプロセスのそれぞれは、さらに、当該管理ソフトプロセスとは異なる管理ソフトプロセスとの間において、既に管理セッションが確立されている音楽ソフトプロセス又はコントローラとの間で、割込通信を行うための割込セッションを一時的に確立する第７の過程と、前記割込セッションを介して、該割込セッションが確立された音楽ソフトプロセス又はコントローラに情報を送信、又は、同音楽ソフトプロセス又はコントローラから情報を入手する第８の過程とを有していることを特徴としている。

さらにまた、本発明の請求項５にかかる音楽システム管理方法は、請求項１記載の音楽システム管理方法において、あるコンピュータで起動された音楽ソフトプロセスに確立された各制御セッションは、同じコンピュータで確立されている前記管理セッションおよび他の制御セッションで使用されていないポート番号を使用して確立されることを特徴としている。

本発明の請求項１にかかる音楽システム管理方法では、１つの音楽システムを構成する音楽ソフトプロセスとコントローラとの間の制御セッションを、専用の管理セッションを介して、１つの管理ソフトが一括して管理するので、各コントローラの制御対象となる音楽ソフトプロセスの切り替えをレスポンス良く行うことができる。
また、本発明の請求項２にかかる音楽システム管理方法では、１つのネットワークに接続された複数のコンピュータで複数の管理ソフトプロセスを起動することにより、該１つのネットワーク上に、複数の音楽システムを構築することができる。
さらに、本発明の請求項３にかかる音楽システム管理方法では、ある音楽システムの管理ソフトプロセスは、他の音楽システムの音楽ソフトプロセス又はコントローラを横取りして、当該音楽システムに組み込むことができる。
さらにまた、本発明の請求項４にかかる音楽システム管理方法では、ある音楽システムの管理ソフトプロセスは、他の音楽システムの音楽ソフトプロセス又はコントローラとの間で、該他の音楽システムの動作を邪魔することなく直接情報を伝達することができる。
さらにまた、本発明の請求項５にかかる音楽システム管理方法では、各音楽ソフトプロセスとコントローラの組み合わせ毎に異なるポート番号を使用して制御セッションが確立されるので、制御通信をより効率的に行うことができる。このため、受信処理での条件分岐を減少させることができる。

本発明の実施例の音楽システム管理方法が適用された音楽システムのハードウェア構成を示すブロック図である。 本発明の実施例の音楽システム管理方法におけるワークグループの設定例を示す図である。 本発明の実施例の音楽システム管理方法におけるグループマネージャ画面を示す図である。 本発明の実施例の音楽システム管理方法において確立されるセッションを示す図である。 本発明の実施例の音楽システム管理方法におけるフェーダコントローラのパネル構成を示す図である。 本発明の実施例の音楽システム管理方法におけるメインコントローラのパネル構成を示す図である。 本発明の実施例の音楽システム管理方法におけるＰＣのハードウェア構成を示すブロック図である。 本発明の実施例の音楽システム管理方法におけるＤＡＷプロセスの機能構成を示す図である。 本発明の実施例の音楽システム管理方法におけるＵＩデバイスのハードウェア構成を示すブロック図である。 本発明の実施例の音楽システム管理方法におけるイーサネットフレームの構成を示す図である。 本発明の実施例の音楽システム管理方法におけるＨＢ生成送信処理のフローチャートである。 本発明の実施例の音楽システム管理方法におけるＨＢ受信処理のフローチャートである。 本発明の実施例の音楽システム管理方法におけるメイン処理のフローチャートである。 本発明の実施例の音楽システム管理方法におけるセッションの確立手順、データ伝送手順、開放手順を示すシーケンス図である。 本発明の実施例の音楽システム管理方法におけるメンバ追加処理のフローチャートである。 本発明の実施例の音楽システム管理方法におけるＨＢエラー処理のフローチャートである。 本発明の実施例の音楽システム管理方法においてＤＡＷの選択ボタンが操作された時にＵＩデバイスとグループマネージャで実行される処理のフローチャートである。 本発明の実施例の音楽システム管理方法においてパラメータの操作子が操作された時にＵＩデバイスとＤＡＷで実行される処理のフローチャートである。

本発明の実施例の音楽システム管理方法が適用される音楽システムの構成を示すブロック図を図１に示す。
音楽システム１は、イーサネット（Ethernet）（登録商標）のネットワーク２を備えており、ネットワーク２に７台のパーソナルコンピュータ（ＰＣ）であるＰＣ１，ＰＣ２，ＰＣ３，ＰＣ４，ＰＣ５，ＰＣ６，ＰＣ７と、８台のＵＩ（User Interface）デバイスであるＭ１，Ｆ１，Ｆ２，Ｆ３，Ｆ４，Ｍ２，Ｍ３，Ｆ５が接続されている。イーサネットは、ＬＡＮ (Local Area Network)用のネットワーク技術規格の名称である。ネットワーク２に接続された７台のＰＣおよび８台のＵＩデバイスには、各々がネットワーク２に新たに接続された際に、ネットワーク２に既に接続されているＤＨＣＰ（Dynamic Host Configuration Protocol）サーバから相互に異なるＩＰアドレスがそれぞれ割り当てられる。この場合、専用のＤＨＣＰサーバを設けても良いし、あるいは１のＰＣあるいはＵＩデバイスのいずれかがＤＨＣＰサーバの役割りを果たしても良い。なお、固定のＩＰアドレスを予め７台のＰＣおよび８台のＵＩデバイスに設定しておいても良い。７台のパーソナルコンピュータではＯＳ（Operating System）上で、管理ソフトプロセスおよび／または音楽ソフト（ＤＡＷ）プロセスが起動されており、ＰＣ１ではＧＭ１の管理ソフトプロセスが起動され、ＰＣ２ではＤＡＷ１のＤＡＷプロセスが起動され、ＰＣ３ではＧＭ２の管理ソフトプロセスと、ＤＡＷ２のＤＡＷプロセスが起動され、ＰＣ４ではＤＡＷ３，ＤＡＷ４の２つのＤＡＷプロセスが起動され、ＰＣ６ではＤＡＷ５，ＤＡＷ６の２つのＤＡＷプロセスが起動され、ＰＣ７ではＤＡＷ７のＤＡＷプロセスが起動されている。ＤＡＷプロセスが起動されているＰＣでは、ＭＩＤＩイベントやオーディオ信号の録音／再生、編集、ミキシングなどの音楽処理を実行することができる。なお、本明細書においては、ＰＣに、協同で１台のＤＡＷ（Digital Audio Workstation）としての機能を果たさせる一組の複数プロセスを「ＤＡＷプロセス」と呼び、また、協同で１台の音楽システム管理装置としての機能を果たさせる一組の複数プロセスを「管理ソフトプロセス」と呼んでいる。また、ＵＩデバイスであるＭ１，Ｆ１，Ｆ２，Ｆ３，Ｆ４，Ｍ２，Ｍ３，Ｆ５は、ユーザが操作するつまみ、フェーダ、ボタンなどを備えるフィジカルコントローラであり、Ｍ１，Ｍ２，Ｍ３はメインコントローラ、Ｆ１，Ｆ２，Ｆ３，Ｆ４，Ｆ５はフェーダコントローラである。
図１に示す音楽システム１における各ＵＩデバイス、各ＤＡＷプロセス、各管理ソフトプロセスには、それぞれ、そのＵＩデバイスあるいはプロセスを特定するための、ユニークなＩＤがそれぞれ付与されている。このユニークＩＤは、ＵＩデバイスやプロセスの起動、停止によって変化することはない。従って、後述するハートビートパケットによりＵＩデバイスやプロセスがネットワーク上で発見されたとき、ユニークＩＤを利用して同一のＵＩデバイスあるいはプロセスが後述するＨＢリストにあるか否かを判定することができる。

なお、ＤＡＷプロセスにおいては、プロジェクトと呼ばれる各音楽ファイルについて、ＭＩＤＩイベントを記録するＭＩＤＩトラック、オーディオ信号を記録するオーディオトラック、オーディオ信号をミキシングするバスをそれぞれ任意数ずつ、ユーザが作成することができるようにされている。オーディオトラックは、ＤＡＷプロセスが備える１ないし複数の入力ポート／チャンネルの１つから入力するオーディオ信号を、各オーディオトラック毎に選択的に録音することができ、オーディオトラックで再生されるオーディオ信号の出力先として、ＤＡＷプロセスが備える複数の出力ポート／チャンネルの中から任意の１つを選択することができるようにされている。そして、ユーザがオーディオトラックを作成する毎に、ミキサ画面には対応するチャンネルストリップの表示が追加されるようになる。なお、ミキサ画面のチャンネルストリップでは、種々のチャンネルのパラメータが調整されるが、そのうちのオーディオチャンネルの詳細については、図８を参照して後述する。

ＰＣ１で起動されているＧＭ１の管理ソフトプロセスとＰＣ３で起動されているＧＭ２の管理ソフトプロセスとは、それぞれに設定されているワークグループの管理を行っており、ワークグループにはネットワーク２上に存在するＤＡＷプロセスやＵＩデバイスを登録することができる。ワークグループの設定例が図２に示されており、図２に示す設定例では、ワークグループＷＧ１には、ＤＡＷ３，ＤＡＷ５，ＤＡＷ７のＤＡＷプロセスと、Ｍ１，Ｆ２，Ｆ３のＵＩデバイスが登録されており、ワークグループＷＧ２には、ＤＡＷ２，ＤＡＷ６のＤＡＷプロセスと、Ｍ３，Ｆ４，Ｆ５のＵＩデバイスが登録されており、ＤＡＷ１，ＤＡＷ４とＭ２，Ｆ１はいずれのワークグループにも登録されていない。そして、ＧＭ１の管理ソフトプロセスはワークグループＷＧ１の管理を行い、ＧＭ２の管理ソフトプロセスはワークグループＷＧ２の管理を行っている。なお、ワークグループの管理は、そのワークグループの管理ソフトプロセスを実行しているＰＣで行われることになる。そして、１つのワークグループに含まれる、ＤＡＷプロセスと、ＵＩデバイスとが、１つの音楽システムとして動作する。すなわち、図２に示す場合はＷＧ１からなる第１音楽システムとＷＧ２からなる第２音楽システムとが独立して動作している。それぞれの音楽システムでは、入力されたＭＩＤＩイベントやオーディオ信号の録音／再生、編集、ミキシングなどの音楽処理を実行することができる。なお、ワークグループの管理では、ワークグループを構成するＤＡＷやＵＩデバイスとされるメンバ間の通信の管理やメンバの追加あるいは削除の管理を行っているが、詳細については後述する。

ここで、Ｆ１，Ｆ２，Ｆ３，Ｆ４，Ｆ５で示されるフェーダコントローラ１０のパネル構成を図５に示す。
図５に示すようにフェーダコントローラ１０のパネルには、例えば８本とされる複数本のｃｈストリップからなるｃｈストリップ部２０ａと、コントロール部２０ｂとが設けられている。ｃｈストリップ部２０ａの各ｃｈストリップには、ミキサ画面の１ｃｈストリップが割り当てられ、割り当てられたｃｈストリップの調整を指示するための操作子が設けられている。操作子は、フェーダ２１と複数のノブ２３等とされ、そのｃｈストリップに割り当てられた操作対象のｃｈ名をｃｈ名表示部２２に表示することができる。そして、フェーダ２１を操作することにより操作対象のｃｈのレベルを調整することができ、ノブ２３を操作することにより操作対象のｃｈの所定のパラメータを調整することができる。

また、コントロール部２０ｂにおいては、ｃｈストリップ部２０ａでは行えない操作を行う操作子群である第１操作子２４と、第２操作子２５と、選択ボタン２６とが設けられている。第１操作子２４はｃｈストリップ部２０ａにおけるノブ２３へ割り当てるパラメータの種類を切り替えるための操作子であり、第２操作子２５はｃｈストリップ部２０ａの各ｃｈストリップに割り当てる操作対象のｃｈを切り替えるための操作子である。また、選択ボタン２６は制御対象とされるＤＡＷプロセスを切り替える選択ボタンであり、「ａ」が表記されたボタン２６ａを押すことにより制御対象を「ａ」に割り当てられているＤＡＷプロセスに切り替えられ、「ｂ」が表記されたボタン２６ｂを押すことにより制御対象を「ｂ」に割り当てられているＤＡＷプロセスに切り替えられ、「ｃ」が表記されたボタン２６ｃを押すことにより制御対象を「ｃ」に割り当てられているＤＡＷプロセスに切り替えられる。
上記したように、選択ボタン２６ａ〜２６ｃが操作されて、制御対象として操作された選択ボタンに対応する１のＤＡＷプロセスが選択されると、当該ＵＩデバイスと該選択されたＤＡＷプロセスを実行しているＰＣとの間に制御セッションが確立される。さらに、選択ボタン２６ａ〜２６ｃのうちの、制御セッションが確立されたＤＡＷプロセスに対応する選択ボタンが点灯し、確立されていないＤＡＷプロセスに対応する選択ボタンが消灯する。これにより、ユーザは、選択ボタン２６ａ〜２６ｃの点灯／消灯の状態を確認することにより、当該ＵＩデバイスで現在制御しているＤＡＷプロセスを確認することができる。
なお、各ＤＡＷプロセスをワークグループへ追加した時は、そのＤＡＷプロセスに対しては、その時点で存在しているＤＡＷプロセスに割り当てられていない「ａ」、「ｂ」、「ｃ」のうちの、何れか１つが割り当てられる。

次に、Ｍ１，Ｍ２，Ｍ３で示されるメインコントローラ１１のパネル構成を図６に示す。
メインコントローラ１１は、トランスポートの制御や、各チャンネルの詳細なパラメータの制御などを行うコントローラとされており、図６に示すようにメインコントローラ１１のパネルには、ｃｈストリップ部は設けられていない。メインコントローラ１１のパネルには、トランスポートの制御や、各チャンネルの詳細なパラメータの制御などを行うためのノブやボタン等の複数の操作子が設けられている。典型的には、ＤＡＷプロセスのメイン画面の各種操作を行うための複数の操作子がパネルに配置されている。すなわち、「ＤＡＷプロセスの詳細なパラメータを制御するための各種ポップアップ画面を開くための複数のボタン」、「トラック上の現在時刻を示す時間カーソルの位置を変更する操作子」、「録音の開始／停止、再生の開始／停止を指示する操作子」、「カーソル位置のパラメータに、値をセットするための操作子」、「ライブラリへのパラメータセットのストア／リコールをするための操作子などが配置されている。また、制御対象とされるＤＡＷプロセスを切り替える選択ボタン３１が設けられており、「ａ」が表記されたボタン３１ａを押すことにより制御対象を「ａ」に割り当てられているＤＡＷプロセスに切り替えられ、「ｂ」が表記されたボタン３１ｂを押すことにより制御対象を「ｂ」に割り当てられているＤＡＷプロセスに切り替えられ、「ｃ」が表記されたボタン３１ｃを押すことにより制御対象を「ｃ」に割り当てられているＤＡＷプロセスに切り替えられる。
また、フェーダコントローラ１０のｃｈストリップ部２０ａおよびコントロール部２０ｂの操作子、メインコントローラ１１の操作子を使って、制御対象のＤＡＷプロセスにおける各種設定の調整を行うことができる。この場合、制御対象のＤＡＷプロセス（ＰＣ）へ操作子の操作量に応じた制御情報を送ることにより制御を行っている。

図２に示すようなワークグループの設定は図３に示すグループマネージャ（ＧＭ）画面３において行うことができる。このＧＭ画面は、管理ソフト（ＧＭ）プロセスが起動されているＰＣの表示デバイスに表示される。図３に示すＧＭ画面３の例は、ＧＭ１プロセスが起動されているＰＣ１の表示デバイスに表示される。
ＧＭ画面３において、「Workgroup」の欄３ａにはＧＭ１プロセスが管理するＷＧ１のワークグループに登録されているメンバであり、かつ、ネットワーク２上に存在するＵＩデバイスおよびＤＡＷプロセスが表示される。また、「Outside」の欄３ｂには、ＷＧ１には登録されていないがネットワーク２上に存在するＤＡＷプロセスとＵＩデバイスとが表示される。
ここで、欄３ａおよび欄３ｂに表示される名称のうちの、名称「Conobase」、「Anotool」、「Orando」、「CTH」、「FDH」は、各ＤＡＷプロセスあるいはＵＩデバイスのモデル名であり、そのＤＡＷプロセスあるいはＵＩデバイスから受信した後述するＨＢメッセージに含まれるモデルＩＤに対応して表示される。また、役割り「DAW A」、「DAW B」、「DAW C」は、ＤＡＷプロセスに対する、当該ワークグループの第１のＤＡＷ（「ａ」）、第２のＤＡＷ（「ｂ」）、第３のＤＡＷ（「ｃ」）の役割りの割り当てを示しており、また、役割り「MU」は、メインコントローラ１１に対する、当該ワークグループの第１のメインコントローラの役割りの割り当てを、役割り「FU1」、「FU2」は、フェーダコントローラ１０に対する、当該ワークグループの第１、第２のフェーダコントローラの役割りの割り当てを示している。なお、これらの「役割り」は、管理ソフトプロセスのＣＰＵ処理で、そのＤＡＷプロセスあるいはＵＩデバイスが、新たなメンバとして当該ワークグループに登録されたときに割り当てられた「役割り」である。

この場合、他のワークグループに登録されていてもネットワーク２上に存在していれば「Outside」の欄３ｂに表示される。図示する場合は、「Conobase(PC2)」「Anotools(PC4)」「Orando(PC3)」「Conobase(PC6)」の名称のＤＡＷプロセスと、「CTH(M2)」「CTH(M3)」「FDH(F3)」「FDH(F4)」「FDH(F5)」の名称のＵＩデバイスがネットワーク２上に存在しており、「Outside」の欄３ｂに表示されている。
さらに、左矢印ボタン３ｃはワークグループ（この場合は、ＷＧ１）にメンバを追加させるボタンであり、「Outside」の欄３ｂにおいて追加したいメンバを選択して左矢印ボタン３ｃをクリックすることにより、ＷＧ１に選択されたメンバが追加されるようになる。この場合、追加されたメンバは「Outside」の欄３ｂから消去されて「Workgroup」の欄３ａに表示されるようになる。また、右矢印ボタン３ｄはＷＧ１に登録されているメンバを削除するボタンであり、「Workgroup」の欄３ａにおいて削除したいメンバを選択して右矢印ボタン３ｄをクリックすることにより、選択されたメンバがＷＧ１から削除されるようになる。この場合、削除されたメンバは「Workgroup」の欄３ａから消去されて「Outside」の欄３ｂに表示されるようになる。

本発明にかかる音楽システム管理方法では、管理ソフトプロセスが管理している音楽システムとして動作するワークグループ内において、管理ソフトプロセスと各メンバとの間で通信を行うための管理セッションが常時確立されている。また、管理ソフトプロセスが管理しているワークグループ内において、管理ソフトプロセスとメンバとの間で一時的に通信を行う時に、割込セッションが一時的に確立される。ワークグループにおける管理セッションおよび割込セッションの確立の態様を図４（ａ）に示す。図４（ａ）に示すように、ＧＭ１が管理している音楽システムとして動作しているＷＧ１においては、ＧＭ１が、管理セッションのクライアントとして、それぞれサーバとしての動作をしているＤＡＷ３、ＤＡＷ５、ＤＡＷ７のＤＡＷプロセス、および、Ｍ１、Ｆ２、Ｆ３のＵＩデバイスとの間に実線で示す６つの管理セッションを確立している。さらに、ＧＭ１は、サーバとしての動作をしている、それ以外のＤＡＷプロセスあるいはＵＩデバイスとの間に、必要に応じて割込セッションを一時的に確立する。また、ＧＭ２が管理しているＷＧ１とは異なる音楽システムとして動作しているＷＧ２においては、ＧＭ２が、管理セッションのクライアントとして、それぞれサーバとして動作をしているＤＡＷ２，ＤＡＷ６のＤＡＷプロセス、および、Ｆ４，Ｍ３，Ｆ５のＵＩデバイスとの間に実線で示す５つの管理セッションを確立している。さらに、ＧＭ２は、サーバとしての動作をしている、それ以外のＤＡＷプロセスあるいはＵＩデバイスとの間に、必要に応じて割込セッションを一時的に確立する。
ここで、本発明にかかる音楽システム１における「セッションを確立」は、ネットワーク２において、クライアントとなる管理ソフトプロセスを実行中のＰＣあるいはＵＩデバイスから、サーバとなるＵＩデバイスあるいはＤＡＷプロセスを実行中のＰＣへの論理的な通信経路（ＴＣＰコネクション）を確立し、その確立された経路を、そのクライアントとそのサーバの間のセッション（データのやり取り）に割り当てることを言う。セッションには、「管理セッション」、「割込セッション」、「制御セッション」の３つの種類があり、セッション種類に応じたデータのやり取りが行われる。また、本発明に係る音楽システム１における「セッションを開放」は、そのセッションに割り当てられた通信経路（ＴＣＰコネクション）を開放することを言う。

管理セッションは、ＰＣにおいて管理ソフトプロセスが起動された後に、ＧＭ１あるいはＧＭ２が自己のワークグループのメンバから最初の後述するハートビートパケットを受信した際にそのメンバとの間で確立されたり、新しいメンバがワークグループに加わった際に、そのメンバとの間で確立される。また、管理セッションは、音楽システムが動作中の間は確立され続けるが、ワークグループからメンバが削除された際には、当該メンバとの間の管理セッションが開放される。例えば、ＷＧ１にＤＡＷ２を追加する場合は、ＤＡＷ２プロセスとＧＭ２との間の管理セッションを開放し、ＧＭ１とＤＡＷ２プロセスとの間に管理セッションを確立させる。さらに、ＷＧ２にＭ２を追加する場合は、Ｍ２はいずれのワークグループにも登録されていないことから開放する管理セッションはなく、ＧＭ２とＭ２との間に管理セッションを確立させる。なお、各サーバは、確立された管理セッションがない時に管理セッションの接続指示をいずれかのクライアントから受けた時、および、確立された割込セッションがない時に割込セッションの接続指示をいずれかのクライアントから受けた時には、接続指示されたセッションを確立するが、各サーバは、確立された管理セッションがある時に管理セッションの接続指示をいずれかのクライアントから受けた時、および、確立された割込セッションがある時に割込セッションの接続指示をいずれかのクライアントから受けた時には、その接続指示は拒否する。また、１つのＰＣで複数のＤＡＷプロセスが起動されている場合は、ＤＡＷプロセスは互いに異なるポート番号で待ち受けを行う。この場合、ネットワーク２上の複数のＰＣおよび複数のＵＩデバイスは、それぞれに割り当てられたＩＰアドレスにより特定できることから、各管理ソフトプロセスは、相手のＩＰアドレスとポート番号との組（ソケット）で、何れか１つのＤＡＷプロセスあるいはＵＩデバイスを特定することができる。

また、割込セッションは、前述したＧＭ画面３において左矢印ボタン３ｃが操作された際に、新しくメンバとなるサーバ（ＤＡＷプロセスあるいはＵＩデバイス）との間で一時的に確立される。例えば、図４（ａ）に破線で示すように、ＧＭ１とＤＡＷ２プロセスとの間に割込セッションが確立されており、また、ＧＭ２とＭ２との間に割込セッションが確立されている。確立された割込セッションを用いてクライアント（ＧＭ）は新しくメンバとなるサーバと交渉し、交渉が終了した際に割込セッションを開放する。ここで、交渉が成立した場合はそのサーバとの間に管理セッションが確立されて、当該サーバが新しいメンバとして追加されるが、交渉が不成立の場合は、そのサーバとの間に管理セッションは確立されず、当該サーバは新しいメンバとして追加されない。交渉が成立する具体的条件は、後述するメンバ追加処理（図１５）のステップＳ４６に関連して説明する。
さらに、前述したＧＭ画面３において「Workgroup」の欄３ａあるいは「Outside」の欄３ｂにおけるいずれかの「Identify」欄の□がクリックされた際に、当該「Identify」欄の□に対応するＤＡＷプロセスあるいはＵＩデバイスとの間で一時的に割込セッションが確立される。そして、割込セッションが確立されたＤＡＷプロセスあるいはＵＩデバイスに割込セッションにより確認メッセージを送り、その確認メッセージを受信したＤＡＷプロセスあるいはＵＩデバイスが、自身がそのＤＡＷプロセスあるいはＵＩデバイスであることをユーザに通知する。通知方法としては、例えば、ＤＡＷプロセスの管理下にある少なくとも１のウィンドウをフラッシュさせたり、ＤＡＷプロセスのウィンドウ上や、ＵＩデバイスのパネル上の少なくとも１のランプの明るさや色を変えたり、点滅させたりすることで通知することができる。

さらにまた、本発明にかかる音楽システム管理方法では、ワークグループ内のＤＡＷプロセスと、このＤＡＷプロセスをコントロールするＵＩデバイスとの間で通信を行うための制御セッションが常時確立されている。ワークグループにおける制御セッションの確立の態様を図４（ｂ）に示す。図４（ｂ）に示すように、ＧＭ１が管理している音楽システムとして動作するＷＧ１においては、クライアントであるＭ１，Ｆ２，Ｆ３のＵＩデバイスは、サーバとなるＤＡＷ３，ＤＡＷ５，ＤＡＷ７のいずれか１つのＤＡＷプロセスとの間に制御セッションが確立されており、各ＤＡＷプロセスは、任意の数のＵＩデバイスとの間に制御セッションが確立されている。具体的には、ＤＡＷ３プロセスはＭ１およびＦ２との間に実線で示すように制御セッションが確立されて、ユーザがＭ１およびＦ２を操作することにより、該制御セッションを介して、ＤＡＷ３プロセスの動作をリモートコントロールすることができる。また、ＤＡＷ７プロセスはＦ３との間に実線で示すように制御セッションが確立されて、ユーザがＦ３を操作することにより、該制御セッションを介して、ＤＡＷ７プロセスの動作をリモートコントロールすることができる。さらに、ＧＭ２が管理している音楽システムとして動作するＷＧ２においては、クライアントであるＦ４，Ｍ３，Ｆ５のＵＩデバイスは、サーバとなるＤＡＷ２，ＤＡＷ６のいずれか１つのＤＡＷプロセスとの間に制御セッションが確立されており、各ＤＡＷプロセスは、任意の数のＵＩデバイスとの間に制御セッションが確立されている。具体的には、ＤＡＷ２プロセスはＦ５との間に実線で示すように制御セッションが確立されて、ユーザがＦ５を操作することにより、該制御セッションを介して、ＤＡＷ２プロセスの動作をリモートコントロールすることができる。また、ＤＡＷ６プロセスはＦ４およびＭ３との間に実線で示すように制御セッションが確立されて、ユーザがＦ４およびＭ３を操作することにより、該制御セッションを介して、ＤＡＷ６プロセスの動作をリモートコントロールすることができる。

なお、１つのＰＣ内で複数のＤＡＷプロセスが起動されている場合は、それぞれのＤＡＷプロセスは、そのＰＣ内でユニークなポート番号を使用している。これにより、当該ＰＣでは、受信した制御パケットのポート番号に基づき、どのＤＡＷプロセスへ渡す制御パケットかを判別できるようになる。制御セッションでは、クライアントであるＵＩデバイスにおいてパラメータを操作する操作子が操作された際に、そのＵＩデバイスと制御セッションが確立しているサーバであるＤＡＷプロセスにおいて、その操作に応じたパラメータが操作されるようになる。
なお、ＤＡＷ１，ＤＡＷ４のＤＡＷプロセスと、Ｍ２，Ｆ１のＵＩデバイスはいずれのワークグループにも登録されていないことから、管理セッション、割込セッションおよび制御セッションはいずれも確立されていない。ただし、上記ＤＡＷプロセスおよび上記ＵＩデバイスは各セッションの待ち受け状態（Listen状態）となっており、セッションの接続指示を受けた時には指示を受けたセッションを確立することができる。

つぎに、図１に示すＰＣ１〜ＰＣ７のパーソナルコンピュータ（ＰＣ）のハードウェア構成を図７に示す。
図７に示すように、ＰＣは汎用のコンピュータであり、 Windows（登録商標）等のＯＳを実行するＣＰＵ（Central Processing Unit）４０を有し、電源投入時に実行されるＢＩＯＳ（Basic Input/Output System）等のソフトウェアが格納されている不揮発性のＲＯＭ（Read Only Member）と、ＣＰＵ４０のワークエリアや各種データ等が記憶されるＲＡＭ（Random Access Memory）からなるＲＯＭ・ＲＡＭ４１を備えている。また、不揮発Mem.４２は、ＣＰＵ４０が実行する管理ソフトやＤＡＷソフト等のソフトウェアが格納されているフラッシュメモリ等の書き換え可能な不揮発メモリである。さらに、ＰＣには、キーボード、マウス等の操作Device４６が接続される操作ＩＯ４５と、１ないし数台のディスプレイ４８が接続される表示ＩＯ４７と、マイク、ＣＤプレーヤ、レコーダ、ヘッドフォン、アンプ等のAudio Device４４が接続されるAudio IO４３とが備えられている。さらに、ＬＡＮケーブルが接続されるイーサネットのネットワークアダプタであるＮＩＯ４９が備えられている。各部はＣＰＵバス５０に接続されており、ＮＩＯ４９はネットワーク２に接続されている。また、ＣＰＵ４０で実行されているＯＳ上では、Cubase（登録商標）、Nuendo（登録商標）、Protools、Sonar等のＤＡＷプロセスを起動することができる。また、ＰＣのＯＳ上では、さらに、管理ソフトプロセス（ＧＭ）を起動することができる。

次に、ＰＣで起動されているＤＡＷプロセスの機能構成の一例を図８に示す。ＤＡＷプロセスはＰＣにおいてWindows等のＯＳ上で起動されるプロセスであり、音響信号のレコーディング、ミキシング、ミックスダウン等を行う機能を有している。そして、ＰＣのディスプレイ４８にトラック画面を開き、該トラック画面のＧＵＩ（Graphical User Interface）により、複数の各トラックへの音響信号の録音、及び録音された各トラックの音響信号の再生を制御することができる。また、ＰＣのディスプレイ４８にミキサ画面を開き、該ミキサ画面のＧＵＩにより、各入力ｃｈ、各トラックｃｈ、各バスｃｈ、各出力ｃｈを制御することができる。
図８に示す音響信号が入力される複数の入力（Inputs）の各１つのインプット（Input）は、Audio IO４３の１の入力ポートを介して、外部から音響信号を受け取り、入力ｃｈにて音響信号の周波数特性、振幅特性等を制御して、１つのトラック又はバスに供給する。また、図８に示す音響信号を録音／再生する複数のトラック（Tracks）の各１つのトラック（Track）は、１つのインプット又はバスからの音響信号を受け取り、タイムコードに同期して録音する。この場合、録音される音響信号の特性の調整は、該インプット又はバスで行われる。そして、録音された音響信号を、タイムコードに同期して再生し、トラックｃｈにて音響信号の周波数特性、振幅特性等を制御して、１つのバス又はアウトプットに供給する。なお、タイムコードは、各種 録音・再生機能の時間軸上における現在位置（現在時刻）を示しており、１つのプロジェクトの全トラックで共通の時刻である。

さらに、図８に示す音響信号を混合する複数のバス（Buses）の各１つのバス（Bus）は、１乃至複数のインプットあるいはトラックからの音響信号を受け取って混合する。この場合、混合される音響信号の特性の調整は、各インプット又はトラックで行う。そして、バスｃｈにて混合結果の音響信号の周波数特性、振幅特性等を制御して、１つのトラック又はアウトプットに供給する。
さらにまた、図８に示す音響信号を出力する複数の出力（Outputs）の各１つのアウトプット（Output）は、１乃至複数のトラック乃至バスからの音響信号を受け取って混合する。そして、混合結果の音響信号を、出力ｃｈにて音響信号の周波数特性、振幅特性等を制御して、Audio IO４３の１の出力ポートを介して外部に出力する。

次に、ＵＩデバイス４のハードウェア構成を示すブロック図を図９に示す。ＵＩデバイス４はフィジカルコントローラであるフェーダコントローラ１０あるいはメインコントローラ１１であり、両コントローラは同様のハードウェア構成とされている。
ＵＩデバイス４は、図９に示すようにWindows（登録商標）等のＯＳを実行するＣＰＵ（Central Processing Unit）５１を有し、電源投入時に実行されるＢＩＯＳ（Basic Input/Output System）等のソフトウェアが格納されている不揮発性のＲＯＭ（Read Only Member）と、ＣＰＵ５１のワークエリアや各種データ等が記憶されるＲＡＭ（Random Access Memory）からなるＲＯＭ・ＲＡＭ５２を備えている。また、不揮発Mem.５３は、ＣＰＵ５１が実行する後述する「HB生成送信処理」（図１１参照）、「メイン処理」（図１３参照）、「Ｂ押下時処理」および「当該ＵＩデバイスの処理」（図１７参照）、「Ｐ操作時処理」および「表示更新処理」（図１８参照）のプログラムなどのコントローラ用のプログラム等が格納されているフラッシュメモリ等の書き換え可能な不揮発性メモリである。さらに、ＵＩデバイス４には、ノブ、フェーダ、ボタン等の操作子５４と、液晶等の表示器５５と、ＬＡＮケーブルが接続されるイーサネットのネットワークアダプターであるＮＩＯ５６が備えられている。各部はＣＰＵバス５７に接続されており、ＮＩＯ５６はネットワーク２に接続されている。なお、ネットワーク２にはフェーダコントローラ（Ｆ１，Ｆ２，Ｆ３，・・・）１０とメインコントローラ（Ｍ１，Ｍ２，・・・）１１とを含む、複数種類のＵＩデバイスが接続されている。また、１つのワークグループで構成される１つの音楽システムには、最大１台のメインコントローラと、最大３台のフェーダコントローラとを含めることができる。

次に、管理セッションおよび割込セッション、制御セッションで伝送されるイーサネットフレームの構成を図１０（ａ）（ｂ）に示す。図１０（ａ）はトランスポート層のプロトコルとしてＴＣＰ（Transmission Control Protocol）を利用する場合のイーサネットフレーム（ＴＣＰ）の構成であり、図１０（ｂ）はトランスポート層のプロトコルとしてＵＤＰ（User Datagram Protoco）を利用する場合のイーサネットフレーム（ＵＤＰ）の構成である。
図１０（ａ）に示すイーサネットフレーム（ＴＣＰ）は、１４バイトのＥＮ（イーサネット）ヘッダと、２０バイトのＩＰ（Internet Protocol）ヘッダと、２０バイトのＴＣＰヘッダと、データ本体とから構成されている。ＥＮヘッダは、フレームの始まりを示すプリアンブル、送信先ＭＡＣアドレス、送信元ＭＡＣアドレス、イーサネット（データリンク層）の上位のネットワーク層のプロトコル情報（この場合はインターネットプロトコル（ＩＰ）を示している。）、サイズなどから構成されている。また、ＩＰヘッダは、バージョン、ヘッダ長、サービスタイプ、パケット長、識別子、ＩＰ（ネットワーク層）の上位のトランスポート層のプロトコル情報（この場合は、ＴＣＰまたはＵＤＰ）、当該ヘッダのデータエラーを検出するためチェックサム、送信元ＩＰアドレス、送信先ＩＰアドレスなどから構成されている。さらに、ＴＣＰヘッダは、送信元ポート番号、送信先ポート番号、シーケンス番号、ＡＣＫ番号、ＡＣＫ、ＳＹＮ、ＦＩＮなどの各種フラグ、ウィンドウサイズ、当該ヘッダのデータエラーを検出するためチェックサムなどから構成されている。ＴＣＰでは、送信するデータ全体をバイトデータ列と見なしたときの、現ＴＣＰパケットに載せる先頭のバイトデータのバイト位置を示している「シーケンス番号」が定義されており、シーケンス番号に基づいてデータの整列や、ウィンドウ制御が行われる。また、ＡＣＫ番号は、既に受信した一連のＴＣＰパケットによって、同バイトデータ列の中のどのバイト位置までデータが揃ったかを示す情報である。

イーサネットフレーム（ＴＣＰ）で伝送されるデータ本体は、管理パケット、制御パケット、割込パケットのいずれかとされ、ヘッダ部とメッセージ部とにより構成される。管理パケットは、管理セッションにおいて伝送され、管理ヘッダと管理メッセージとエラー検出するＣＲＣコード（Cyclic Redundancy Check）とから構成されており、制御パケットは、制御セッションにおいて伝送され、制御ヘッダと制御メッセージとＣＲＣコードとから構成されており、割込パケットは、割込セッションにおいて伝送され、割込ヘッダと割込メッセージとＣＲＣコードとから構成されている。データ本体のヘッダ部分のデータに基づいて、そのデータ本体が、管理／制御／割込の何れのパケットであるか判別される。

図１０（ｂ）に示すイーサネットフレーム（ＵＤＰ）は、１４バイトのＥＮ（イーサネット）ヘッダと、２０バイトのＩＰ（Internet Protocol）ヘッダと、８バイトのＵＤＰヘッダと、データ本体とから構成されている。ＥＮヘッダおよびＩＰヘッダは、上記した通りであるのでその説明は省略する。ＵＤＰヘッダは、送信元ポート番号、送信先ポート番号、サイズ、当該ヘッダのデータエラーを検出するためチェックサムなどから構成されている。
イーサネットフレーム（ＵＤＰ）で伝送されるデータ本体は、ハートビート（ＨＢ）パケットとされ、ＨＢパケットは、ＨＢヘッダとＨＢメッセージとＣＲＣコードとから構成されている。データ本体のＨＢヘッダ部分のデータに基づいて、そのデータ本体が、ＨＢパケットであることを判別できる。ＨＢメッセージは、ＵＩデバイスやＤＡＷの種別及びバージョンを特定するモデルＩＤ、個々のＵＩデバイスあるいはＤＡＷプロセスを特定するユニークＩＤ、システムＩＤ（ワークグループＩＤと同義）、管理、割込、制御の各セッションが確立されているか否かを示す状態フラグ、待ち受けポート番号などから構成されている。

なお、ＴＣＰは通信相手の応答があって初めて通信を開始するコネクション型プロトコルであり、データ転送を行う前にセッションの確立が行われる。また、ＴＣＰではより確実に相手にデータ（セグメント）を届けるために、スリーウェイハンドシェイク、確認応答、フロー制御、輻輳制御など様々な機能を備えている。このＴＣＰに対してＵＤＰはセッションを確立せずにデータ転送を行うプロトコルであり、上記したＴＣＰが備える機能を備えていない。このため、ＵＤＰは信頼性が低いが転送速度が高く、マルチキャストやブロードキャストなどの１対多の通信に向いている。

ネットワーク２上の全てのＵＩデバイスおよびＤＡＷプロセスから、ネットワーク２上の全ての管理ソフトプロセス（ＧＭ）に届くように所定周期毎に、ＨＢパケットはマルチキャストされる。ここで、ネットワーク２上の全てのＵＩデバイスにおけるＣＰＵ５１およびＤＡＷプロセスを実行しているＣＰＵ４０が、所定周期毎に実行するＨＢ生成送信処理のフローチャートを図１１に示し、ＨＢ生成送信処理を説明する。
ネットワーク２上のＵＩデバイスにおけるＣＰＵ５１およびＤＡＷプロセスを実行しているＰＣのＣＰＵ４０のいずれかにおいて、ＨＢ生成送信処理を実行するタイミングに達したと判断されるとＣＰＵ５１あるいはＣＰＵ４０によりＨＢ生成送信処理が実行開始されて、自身の情報からなる上記したＨＢメッセージが作成され、このＨＢメッセージにＨＢヘッダを付加したＨＢパケットがステップＳ１０にて生成される。次いで、作成されたＨＢパケットがカプセル化されたイーサネットフレーム（ＵＤＰ）がステップＳ１１にて作成されてマルチキャストされ、ＨＢ生成送信処理は終了する。このマルチキャストする場合のイーサネットフレーム（ＵＤＰ）におけるＩＰヘッダの送信先ＩＰアドレスは、管理ソフトプロセス（ＧＭ）が動作している複数のＰＣにより構成されるマルチキャストグループのＩＰアドレスであり、ＵＤＰヘッダの送信先ポート番号は、全てのシステム、全てのＵＩデバイス、全てのＤＡＷプロセスに共通の１つのポート番号である。

ＨＢパケットがカプセル化されたイーサネットフレーム（ＵＤＰ）を各管理ソフトプロセス（ＧＭ）が受信すると、各管理ソフトプロセス（ＧＭ）を実行しているＰＣのＣＰＵ４０が、ＲＯＭ・ＲＡＭ４１に記憶されているＨＢリストを、各ＵＩデバイスあるいは各ＤＡＷプロセスから送信されたＨＢメッセージの情報と、その受信時刻とで更新する。これにより、ＨＢリストには、受信できている全てのＨＢメッセージについて、最新の受信時刻、送信元のＵＩデバイスあるいはＤＡＷプロセスのＩＰアドレス、当該ＨＢメッセージに記載されたモデルＩＤ、ユニークＩＤ、システムＩＤ、状態フラグ、待ち受けポート番号等が記憶されるようになる。なお、各ＵＩデバイスには、不要なＨＢパケットが送信されないので、その分だけ、各ＵＩデバイスの処理負荷を下げることができる。ただし、マルチキャストの代わりにＨＢメッセージがカプセル化されたイーサネットフレーム（ＵＤＰ）をブロードキャストするようにしてもよい。
ここで、管理ソフトプロセス（ＧＭ）がＨＢパケットがカプセル化されたイーサネットフレーム（ＵＤＰ）を受信した際に、管理ソフトプロセス（ＧＭ）を実行しているＣＰＵ４０で実行されるＨＢ受信処理のフローチャートを図１２に示し、ＨＢ受信処理を説明する。ネットワーク２上のいずれかのＵＩデバイスおよびＤＡＷプロセスから送信されたＨＢパケットがカプセル化されたイーサネットフレーム（ＵＤＰ）をＰＣが受信すると、該ＰＣのＣＰＵ４０は管理ソフトプロセス（ＧＭ）の一部としてＨＢ受信処理を開始し、受信したイーサネットフレーム（ＵＤＰ）におけるＨＢメッセージで特定されるＵＩデバイスあるいはＤＡＷプロセスが、保存されているＨＢリストに既に存在するか否かがステップＳ２０にて判断される。この判断は、ＨＢメッセージとＨＢリストとでユニークＩＤの一致を検出することにより行われ、ステップＳ２０にて保存されているＨＢリストに既に存在すると判断された場合は、ステップＳ２１に進みＨＢリストの受信時刻を、今回イーサネットフレーム（ＵＤＰ）を受信した時刻に更新したり、受信したＨＢメッセージでＨＢリストの既存データを最新のデータで更新する既存データ更新処理が行われ、ＨＢ受信処理は終了する。

また、ステップＳ２０にて保存されているＨＢリストに存在しないと判断された場合は、ステップＳ２２に分岐してＨＢリストに、受信したイーサネットフレーム（ＵＤＰ）におけるＨＢメッセージで特定されるＵＩデバイスあるいはＤＡＷプロセスの情報を新規データとして追加して記憶する。追加して記憶される情報は、ＨＢパケットを受信した時刻、ＨＢメッセージに記載されているモデルＩＤ（機種、バージョン）、ユニークＩＤ、管理セッションを確立する時に管理ソフトプロセス（ＧＭ）により書き込まれたシステムＩＤ（ワークグループＩＤ）、各セッションが確立されているか開放されているかを示す通信状態フラグ、待ち受けポート番号などの情報とされる。なお、管理ソフトプロセス（ＧＭ）を実行しているＰＣのＲＯＭ・ＲＡＭ４１が記憶するＨＢリストでは、当該ＵＩデバイスおよびＤＡＷプロセスからＨＢパケットを周期的に受信している間は、そのＨＢパケットに関する情報が保持されている。ステップＳ２２の処理が終了すると、受信したイーサネットフレーム（ＵＤＰ）におけるＨＢメッセージに記載されているユニークＩＤがＧリストに既に存在するか否かがステップＳ２３にて判断される。管理ソフトプロセス（ＧＭ）を実行しているＰＣのＲＯＭ・ＲＡＭ４１が記憶するＧリストには、その管理ソフトプロセス（ＧＭ）が管理している音楽システム（ワークグループ）に登録されたＵＩデバイスおよびＤＡＷのユニークＩＤが少なくとも記憶されており、ここで、Ｇリストに既に存在すると判断された場合は、その音楽システムのメンバであることが確認されてステップＳ２４に進む。

ステップＳ２４では、受信したイーサネットフレーム（ＵＤＰ）におけるＨＢメッセージに記載されているシステムＩＤ（ワークグループＩＤ）が、管理ソフトプロセス（ＧＭ）が管理している音楽システム（ワークグループ）のシステムＩＤと一致しているか否かが判断される。ステップＳ２４でシステムＩＤが一致すると判断された場合は、新たに発見されたＵＩデバイスあるいはＤＡＷプロセスが、当該システムに参加しているＵＩデバイスあるいはＤＡＷプロセスである場合であり、ＨＢメッセージを送信したＵＩデバイスあるいはＤＡＷプロセスが、その音楽システムのメンバであることを認識していることが確認されたことになる。そこで、ステップＳ２５に進み（１）管理セッションを確立する処理、および、（２）制御セッションの初期設定処理が実行される。管理セッションを確立する処理では、ＨＢリストにステップＳ２２で追加された上記情報のうちの待ち受けポート番号のポートとの間で管理セッションが確立される。この場合、もし、ＨＢリストに上記追加された情報のうちの通信状態フラグが、「管理セッション確立を示すフラグ」のときは、管理セッションを確立する処理の代わりに、エラー処理（ユーザへの警告等）を行う。このとき、ＧＭ画面３が表示されていれば、ステップＳ２５で、制御セッションが確立されるＵＩデバイスあるいはＤＡＷプロセスは、当該ワークグループに参加しているので、欄３ａに表示される。

また、制御セッションの初期設定処理は、ネットワーク２上において新しいＵＩデバイスあるいはＤＡＷプロセスが発見された場合にのみ実行され、（１）で確立された管理セッションを用いて、当該ＵＩデバイスあるいはＤＡＷプロセスとの間に制御セッションが確立される。この処理の詳細は後述するが、まず、ＤＡＷプロセスに「待受要求」を送信し、次に、ＵＩデバイスに「確立要求」を送信する。ここでは、所定の制御セッションを設定してもよいし、直前の制御セッションの情報を記憶し、それを設定（再現）してもよい。ここで、「所定の制御セッション」とは、予め決められた相手ＤＡＷプロセスとの制御セッションを意味しており、この予め決められた相手ＤＡＷプロセスの例としては、複数のＤＡＷプロセスのうちの１番目のＤＡＷプロセスとか、当該ＵＩデバイスの番号（同じＵＩデバイスが複数接続されたとき、各ＵＩデバイスに付与される通し番号）に対応する順番のＤＡＷプロセスとかとすることができる。この場合、管理ソフトプロセス（ＧＭ）のカレントメモリには、ＨＢパケットに基づいて発見された各ＤＡＷプロセスの情報が、管理ソフトプロセス（ＧＭ）が付与した通し番号と共に記憶されている。この番号は、上記した管理ソフトプロセス（ＧＭ）のＣＰＵ処理で、そのＤＡＷプロセスあるいはＵＩデバイスが、新たなメンバとして当該ワークグループに登録されたときに割り当てられた「役割り」である。また、「直前の制御セッション」は、直前に当該ＵＩデバイスとの間で制御セッションが確立されていた（今は開放されている）相手ＤＡＷプロセスとの制御セッションを意味している。この場合、相手先のＤＡＷプロセスを特定する情報は、管理ソフトプロセス（ＧＭ）が記憶しているＧリストの中にある。

ステップＳ２３においてＧリストに存在しないと判断された場合、あるいは、ステップＳ２４にてシステムＩＤが一致しないと判断された場合は、何れの音楽システム（ワークグループ）にも参加していないか、或いは、他の音楽システム（ワークグループ）に参加しているＵＩデバイスあるいはＤＡＷプロセスである場合である。このため、ＨＢメッセージを送信したＵＩデバイスあるいはＤＡＷプロセスが、管理ソフトプロセス（ＧＭ）が管理している音楽システム（ワークグループ）のメンバと確認できないことから、ＨＢ受信処理は終了する。このとき、ＧＭ画面３が表示されていれば、メンバと確認できないＵＩデバイスあるいはＤＡＷプロセスは、欄３ｂに表示される。また、ステップＳ２５の処理が終了した場合は、ＨＢ受信処理は終了する。
なお、ＨＢ受信処理におけるステップＳ２４において、システムＩＤが一致しない場合に、何もせずに処理を終了していたが、ユーザに対し、そのシステムＩＤが異なるＵＩデバイスあるいはＤＡＷプロセスが発見された旨の警告を行ったり、さらに、ユーザから、そのＵＩデバイスあるいはＤＡＷプロセスを当該システムに入れる指示を受け付け、その指示に応じて後述するメンバ追加処理（図１５参照）と同様の処理を行うことにより、発見されたＵＩデバイスあるいはＤＡＷプロセスを当該システムに再組み込みするようにしてもよい。

次に、ＵＩデバイスが電源オンされたあるいはＰＣでＤＡＷプロセスが起動されたときに開始されるメイン処理のフローチャートを図１３に示し、メイン処理を説明する。
ＵＩデバイスあるいはＤＡＷプロセスが起動されると、起動されたＵＩデバイスにおけるＣＰＵ５１およびＤＡＷプロセスを実行しているＰＣのＣＰＵ４０においてメイン処理が開始され、ステップＳ３０にて初期化の処理が行われる。初期化の処理では、ワークメモリの初期化や前回の設定内容が読み出されて設定される。また、ＤＡＷプロセスが起動された場合はプロジェクトが読み込まれ、ディスプレイ４８に図３に示すＧＭ画面３が表示される。次いで、ステップＳ３１にて１つの待ち受けポート番号が決定され、そのポート番号のポートで「管理セッション」及び「割込セッション」の待ち受けを行う状態（Listen状態）とされる。この場合、「管理セッション」と「割込セッション」は通信頻度が「制御セッション」より高くないので、同じ待受ポート番号のポートを使用するようになっているが、待受ポート番号を相互に異ならせても良い。その場合は、ＨＢパケットに両待ち受けポート番号を記載すれば、何れの管理ソフトプロセス（ＧＭ）も、ＨＢパケットに基づいて「管理セッション」と「割込セッション」とを、ポート番号が相互に異なる２ポートを用いて確立可能になる。

なお、ＰＣ１〜ＰＣ７では１台のＰＣにおいて、複数のＤＡＷプロセスなどの複数のアプリケーションを同時に立ち上げることができ、それぞれのアプリケーションに異なるポート番号を設定することができる。そこで、ＰＣで複数のＤＡＷプロセスが起動された場合は、複数のＤＡＷプロセス間で異なる待受ポート番号が決定されて、ＤＡＷプロセス毎の待ち受け通信路が準備される。他方、ＵＩデバイスではコントローラソフトのみが立ち上げられることから、ＵＩデバイスが決定する待受ポート番号には制約がなく、任意の待受ポート番号を決定することができる。例えば、全てのＵＩデバイスで共通の、所定のポート番号とすることができる。

ステップＳ３１の処理が終了すると、ステップＳ３２ないしステップＳ３４の処理に進むが、ステップＳ３２ないしステップＳ３４の処理はイベントドリブンの処理とされ、ユーザが操作子の操作を行っていないときは待機状態となり、ユーザが操作子の操作を行ったときにイベントの処理が行われる。すなわち、ステップＳ３２にてイベントの検出が行われ、ステップＳ３３にてイベントがあるかないかが判断される。ステップＳ３３においてイベントがないと判断された場合はステップＳ３２に戻り、ステップＳ３２とステップＳ３３の処理が繰り返し行われることから待機状態となる。そして、ユーザがＵＩデバイスに備えられているいずれかの操作子あるいはＤＡＷプロセスによりＰＣのディスプレイに表示されているいずれかの操作子の操作を行うと、ステップＳ３３にて該操作子のイベントがあると検出されてステップＳ３４に進み、検出されたイベント、すなわち、該操作子の操作内容に対応する処理がステップＳ３４にて行われる。また、ＤＡＷの現在時刻の進行、タイマのタイムアップ、操作Device４６としてＰＣに接続されているマウスの操作、他の機器からのデータ受信、同じ機器内の他のプロセスからのデータ受信等があった時も、ステップＳ３３にてイベントがあると検出されて、検出されたイベントに対応する処理がステップＳ３４にて行われる。

次に、図１４を用いて、管理セッション、制御セッションおよび割込セッションに共通の、セッションの確立、データ転送、および開放の手順を説明する。この手順における論理的な経路の確立は、ＴＣＰにおける標準的なコネクションの確立、データ転送、および開放の手順に準ずる。
上記した各セッションを確立する場合は、クライアントとされるホストＡが待ち受け状態（Listen）のサーバとされるホストＢに、ＴＣＰパケットにおけるＳＹＮ（接続指示）フラグが「１」とされたイーサネットフレーム（ＴＣＰ）が、ネットワーク２を介して送信される。このイーサネットフレーム（ＴＣＰ）における宛先ＩＰアドレスはホストＢに割り当てられているＩＰアドレスとされ、ポート番号はホストＢの待ち受けポート番号が設定される。確立するセッションが管理セッションあるいは割込セッションの場合は、ホストＡ（クライアント）は、管理ソフトプロセス（ＧＭ）を実行しているＰＣであり、ホストＢ（サーバ）は、ＵＩデバイスあるいはＤＡＷプロセスを実行しているＰＣである。ホストＡは、ＨＢリストに記憶されているホストＢのＩＰアドレスと待ち受けポート番号を用いて、ＳＹＮ（接続指示）を送信する。ＳＹＮ（接続指示）の送信は、ＳＹＮフラグが「１」とされたイーサネットフレーム（ＴＣＰ）を送信することにより行われる。
また、確立するセッションが制御セッションの場合は、ホストＡ（クライアント）は、ＵＩデバイスであり、ホストＢ（サーバ）は、ＤＡＷプロセスを実行しているＰＣである。どのホストＡとどのホストＢを繋ぐかは、管理ソフトプロセス（ＧＭ）の管理下にあり、ホストＡは、管理ソフトプロセス（ＧＭ）を実行しているＣＰＵ４０から指示されたＩＰアドレスおよび待ち受けポート番号を用いて、ＳＹＮ（接続指示）を送信する。

ホストＡから送信されたＳＹＮフラグが「１」とされたイーサネットフレーム（ＴＣＰ）を受信したホストＢは、ホストＡからの接続指示に応えて接続確立を行うと共に、ホストＢからのセッションの確立を要求するＳＹＮフラグとＡＣＫフラグが「１」とされたイーサネットフレーム（ＴＣＰ）を、ネットワーク２を介してホストＡに送信する。ホストＡはこれに応えて接続確立を行い、ＡＣＫフラグが「１」とされたイーサネットフレーム（ＴＣＰ）を、ネットワーク２を介してホストＢに送信する。これにより、セッションが確立される。このセッションの確立手法が３ウェイハンドシェイクと云われる。
セッションが確立される（ESTBLISHED）と、このセッションを利用してホストＡからデータをホストＢに送信できると共に、ホストＢからデータをホストＡに送信することができるようになる。なお、イーサネットフレーム（ＴＣＰ）で送れるデータ量が所定量とされていることから、一般にデータは複数に分割されて送信される。このように分割したデータを送信する状態がシーケンス図において、ホストＡからホストＢへ向かう「ＤＡＴＡ」シーケンスで示されている。図示するようにホストＢが２回に分割したデータを正常に受信した場合は、ホストＢはＡＣＫフラグが「１」とされたイーサネットフレーム（ＴＣＰ）を、ホストＡに送信する。また、シーケンス図において、ホストＢからホストＡへ向かう「ＤＡＴＡ」シーケンスで示されている２回に分割されたデータを、ホストＡが正常に受信した場合は、ホストＡはＡＣＫフラグが「１」とされたイーサネットフレーム（ＴＣＰ）を、ホストＢに送信する。

そして、確立されたセッションを開放する場合は、ＦＩＮ（切断指示）フラグが「１」とされたイーサネットフレーム（ＴＣＰ）をネットワーク２を介して相手のホストに送信する。図示する場合は、ホストＡがホストＢにＦＩＮ（切断指示）フラグが「１」とされたイーサネットフレーム（ＴＣＰ）をネットワーク２を介してホストＢに送信する。ホストＡから送信されたＦＩＮフラグが「１」とされたイーサネットフレーム（ＴＣＰ）を受信したホストＢは、ホストＡからの切断指示に応えて接続開放を行うと共に、ホストＢからのセッションの開放を要求するＦＩＮフラグとＡＣＫフラグとが「１」とされたイーサネットフレーム（ＴＣＰ）を、ネットワーク２を介してホストＡに送信する。ホストＡはこれに応えて接続開放を行い、ＡＣＫフラグが「１」とされたイーサネットフレーム（ＴＣＰ）を、ネットワーク２を介してホストＢに送信する。これにより、セッションが開放される。これにより、ホストＢにおけるセッションが確立状態（ESTBLISHED）から待ち受け状態（Listen）になる。

なお、セッションの確立シーケンスにおいて、所定時間内にＡＣＫが帰ってこなかった場合や、サーバから待ち受け状態にないことを示すＡＣＫ（ＮＡＣＫ：Negative ACKnowledgement）が送信された場合には、セッションを確立することができない。また、各セッションは、所定時間以上アクセスがない状態が継続した際に、タイマがタイムアップしてセッションは自動的に開放される。そこで、本発明にかかる音楽システム管理方法の実施例では、管理セッションおよび制御セッションについては、データの送信を行わない時間がタイムアップする直前に、そのセッションを継続するためのダミーデータ（KeepAliveパケット）を送信するようになっている。これにより、管理セッションおよび制御セッションは一度確立されると、音楽システムがシャットダウンされるまでは継続されるようになる。

管理ソフトプロセス（ＧＭ）は、ＨＢリストのデータに基づいて、ＰＣのディスプレイ４８に図３に示すＧＭ画面３を表示する。ＨＢリストは、図１２のＨＢ受信処理が実行される毎に更新されることから、ＧＭ画面３には、ネットワーク２上に存在する最新のＵＩデバイス及びＤＡＷプロセスが表示されている。ＧＭ画面３の「Outside」の欄３ｂで、ユーザが所望の１つのＵＩデバイスあるいはＤＡＷプロセスを選択（以下、「対象Ｄ」と呼ぶ）して、左矢印ボタン３ｃ（「←」）を操作したときに、対象Ｄの選択が受け付けられ、管理ソフトプロセスＧＭを実行しているＰＣのＣＰＵ４０が図１５に示すフローチャートのメンバ追加処理を実行する。このメンバ追加処理を、以下に説明する。なお、図３に示すＧＭ画面３における「追加（←）」、「削除（→）」の操作は、システムの一般のユーザは行うことができず、システムの管理者のみに許された操作である。
ＧＭ画面３において、左矢印ボタン３ｃ（「←」）が操作されると管理ソフトプロセスＧＭを実行しているＰＣのＣＰＵ４０がメンバ追加処理を開始し、管理ソフトプロセス（ＧＭ）を実行しているＰＣのＲＯＭ・ＲＡＭ４１に記憶されているＨＢリストがステップＳ４０にて参照され、ＧＭ画面３の「Outside」の欄３ｂで選択された対象ＤのＨＢメッセージに記載されていた情報が読み出される。そして、対象ＤのＨＢメッセージに、メンバ追加処理を実行している管理ソフトプロセスが管理している音楽システム（ワークグループ）ではない他のシステムＩＤがあるか否かがステップＳ４１にて判断される。

ステップＳ４１にて他のシステムＩＤがないと判断された場合は、対象Ｄはいずれの音楽システム（ワークグループ）にも登録されていないことから、ステップＳ４２に進み、対象Ｄとの間に管理セッションを確立して、管理ソフトプロセスが管理している音楽システムのシステムＩＤを管理セッションを通じて対象Ｄに書き込む。次いで、ステップＳ４３にて制御セッションの初期設定処理が行われる。この初期設定処理が行われると、ステップＳ４２で確立された管理セッションを用いて、対象ＤをコントロールするＵＩデバイスあるいは対象ＤがコントロールするＤＡＷプロセスとの間に制御セッションが確立される。そして、ステップＳ４４にてＧＭ画面３において「Outside」の欄３ｂで選択された対象Ｄを消去して、「Workgroup」の欄３ａに対象Ｄを表示させる。これにより、メンバ追加処理は終了する。

また、ステップＳ４１にて他のシステムＩＤがあると判断された場合、すなわち、そのＵＩデバイスあるいはＤＡＷプロセスが、他のシステムに参加している場合は、対象Ｄは他の管理ソフトプロセス（ＧＭ’）にメンバとして登録されており、その管理ソフトプロセスとの間に管理セッションが確立されていることから、ステップＳ４５に分岐して、対象Ｄとの間に割込セッションを、読み出されたＨＢリストに書かれている待ち受けポート番号で確立する。この場合、対象Ｄが他の管理ソフトプロセス（ＧＭ’）と割込セッション中であれば、その終了を待って行う。ただし、待ち時間が長すぎ得る場合はユーザにその旨を警告する。そして、確立された割込セッションを利用して対象Ｄをメンバとする交渉をステップＳ４６にて行う。そして交渉が成立した場合は、現在メンバとなっている音楽システム（ワークグループ）から対象Ｄを外すために、対象Ｄが、既存の管理セッションを利用して、前記他の管理ソフトプロセス（ＧＭ’）に管理セッションの開放を要求し、該他の管理ソフトプロセス（ＧＭ’）は、その開放要求に応じて、管理セッションを開放する。ここでの交渉は、例えば、当該管理ソフトプロセス（ＧＭ）にログオンしたユーザが、他の管理ソフトプロセス（ＧＭ’）に登録されている（権限を有している）場合に成立し、登録されていない場合に不成立となるようにすればよい。あるいは、対象Ｄに、「横取りを禁止する」設定が行われていなければ交渉が成立し、同設定が行われていれば不成立となるようにしてもよい。あるいは、先述したとおり、メンバ追加処理を実行できるユーザは、管理者に限られるため、ステップＳ４６に関しては、無条件で（必ず）交渉成立するようにしてもよい。
次いで、ステップＳ４５で確立した割込セッションをステップＳ４７にて開放する。割込セッションを開放する処理が終了するとステップＳ４８において、他の管理ソフトプロセス（ＧＭ’）に要求した管理セッションが開放されたか否かが判断される。ここで、対象Ｄの管理セッションの状態を示すフラグを参照して、当該管理セッションが開放されたと判断された場合は、上記したステップＳ４２ないしステップＳ４４の処理が行われて、メンバ追加処理を実行している管理ソフトプロセス（ＧＭ）が管理する音楽システムのメンバに対象Ｄが追加される。また、ステップＳ４８にて管理セッションが開放されていないと判断された場合は、対象Ｄは依然として他の管理ソフトプロセス（ＧＭ’）が管理する音楽システムのメンバとなっており、対象Ｄをメンバとして追加できないことから、ステップＳ４９に進み横取りできない旨をＰＣのディスプレイ４８に表示するなどしてユーザに警告する。ステップＳ４４あるいはステップＳ４９の処理が終了すると、メンバ追加処理は終了する。
なお、ＧＭ画面３において、対象Ｄを同時に複数選択して追加できるようにしてもよい。この場合は、複数選択された対象Ｄ毎に上記した処理が行われるようになる。

管理ソフトプロセス（ＧＭ）は、記憶しているＨＢリストにおけるＨＢメッセージの受信時刻を監視しており、その受信時刻が更新されずに所定時間以上経過したとき、すなわち、ＨＢリストにデータが有るＵＩデバイスあるいはＤＡＷプロセス（以下、「対象Ｄ」と呼ぶ）からのＨＢパケットを、所定時間以上受信することができなかったときに管理ソフトプロセス（ＧＭ）を実行しているＰＣのＣＰＵ４０が実行するＨＢエラー処理のフローチャートを図１６に示し、ＨＢエラー処理を説明する。
管理ソフトプロセス（ＧＭ）が記憶しているＨＢリストの対象Ｄのうちの何れかの対象Ｄについて、受信時刻からの経過時間が所定時間を越えたことが検出されると、管理ソフトプロセス（ＧＭ）を実行しているＰＣのＣＰＵ４０がＨＢエラー処理を開始して、ステップＳ５０にて管理セッションを用いて当該対象Ｄにアクセスする。このアクセスでは、例えば空のデータ本体のイーサネットフレーム（ＴＣＰ）を対象Ｄに送信する。そして、当該対象ＤからＡＣＫフラグが「１」のイーサネットフレーム（ＴＣＰ）が返信されるかを確認する。このイーサネットフレーム（ＴＣＰ）が返信されてきたときは、その管理ソフトプロセス（ＧＭ）が管理する音楽システム（ワークグループ）に当該対象Ｄが存在していることになるから、ステップＳ５１にて当該対象Ｄが存在すると判断されてステップＳ５４に分岐する。ステップＳ５４では、ＨＢリストにおける当該対象Ｄからの受信時刻が現在の時刻に更新されて、ＨＢエラー処理は終了する。

また、当該対象Ｄからの上記したイーサネットフレーム（ＴＣＰ）の返信がないときは、その管理ソフトプロセス（ＧＭ）が管理する音楽システム（ワークグループ）に当該対象Ｄが存在していないことになる。この場合は、ステップＳ５１にて当該対象Ｄが存在しないと判断されてステップＳ５２に進み、その管理ソフトプロセス（ＧＭ）が記憶しているＨＢリストから当該対象Ｄを消去する。そして、ステップＳ５３にてＧＭ画面３において「Workgroup」の欄３ａから当該対象Ｄが消去される。これにより、ＨＢエラー処理は終了する。以上に説明したステップＳ２３〜Ｓ２５、および、ステップＳ５３の処理により、欄３ａ、３ｂには、現在、ＨＢメッセージの受信により存在が確認されているＵＩデバイスおよびＤＡＷプロセスのみが表示され、ＨＢメッセージが届いていないＵＩデバイスおよびＤＡＷプロセスは表示されないよう制御される。

本発明にかかる音楽システム制御方法において、ＵＩデバイスがコントロールするＤＡＷプロセスを選択する選択ボタンがＵＩデバイスにおいて操作されると、ＵＩデバイスおよび当該ＵＩデバイスがメンバとなっている音楽システムを管理する管理ソフトプロセス（ＧＭ）において一連の処理が行われて、選択されたＤＡＷプロセスをそのＵＩデバイスによりコントロールできるようになる。この際にＵＩデバイスにおけるＣＰＵ５１で行われるＢ（ボタン）押下時処理および当該ＵＩデバイスがメンバとなっている音楽システムを管理する管理ソフトプロセス（ＧＭ）を実行しているＰＣのＣＰＵ４０で行われるＢ押下受信処理のフローチャートを図１７に示し、これらの一連の処理を説明する。
ＵＩデバイスであるフェーダコントローラ１０において選択ボタン２６のいずれかが操作されたとき、あるいは、メインコントローラ１１において選択ボタン３１のいずれかが操作されたときに、選択ボタンが操作されたＵＩデバイスにおけるＣＰＵ５１がＢ押下時処理を開始し、選択ボタンが操作されたことによりどのＤＡＷプロセスが選択されたかの情報が管理セッションを用いて、当該ＵＩデバイスがメンバとなっている音楽システムを管理する管理ソフトプロセス（ＧＭ）にステップＳ６０にて送信される。これにより、Ｂ押下時処理は終了し、上記した情報を、当該ＵＩデバイスがメンバとなっている音楽システムを管理する管理ソフトプロセス（ＧＭ）が受信すると、ＤＡＷプロセスの選択が受け付けられ、当該管理ソフトプロセス（ＧＭ）を実行しているＰＣのＣＰＵ４０がＢ押下受信処理を開始する。

Ｂ押下受信処理が開始されると、選択されたＤＡＷプロセスが、当該ＵＩデバイスで確立されている現制御セッションの相手先のＤＡＷプロセスと同じか否かが判断される。ここで、同じと判断された場合は現設定を変更する必要がないことから、Ｂ押下受信処理は終了し、同じでないと判断された場合は、ステップＳ６２に進む。ステップＳ６２では、管理ソフトプロセス（ＧＭ）を実行中のＰＣは、当該ＵＩデバイスに対して、管理セッションを用いて、現制御セッションの開放要求を送信する。現制御セッションの開放要求を受信した当該ＵＩデバイスは、当該制御セッションを用いて、接続先のＤＡＷプロセスを実行しているＰＣに対して切断指示（ＦＩＮ）を送信し、これにより、図１４に示す手順に従い、当該制御セッションが開放される。そして、該開放を確認した当該ＵＩデバイスは、当該制御セッションの開放完了を通知する開放応答を、管理セッションを用いて、管理ソフトプロセス（ＧＭ）を実行しているＰＣに送信する（ステップＳ６６）。これを受けて、管理ソフトプロセス（ＧＭ）を実行しているＰＣは、ＵＩデバイスで選択されたＤＡＷプロセスを実行しているＰＣに対して、管理セッションを用いて、新たな制御セッションのための待受要求を送信する（ステップＳ６３）。ステップＳ６７では、このポート番号を待ち受けポート番号として決定するだけでなく、そのポート番号を使用したサーバ動作を開始する。すなわち、当該ＤＡＷプロセスを実行しているＰＣは、その待受要求を受信し、当該ＰＣで未使用のポート番号を待ち受けポート番号として決定し、サーバとしての、該待ち受けポート番号の示すポートでの制御セッションの待ち受け動作を開始するとともに、該待ち受けポート番号を記入した待受応答を、管理セッションを用いて、管理ソフトプロセス（ＧＭ）を実行しているＰＣに送信する。

この待受応答を受信したＰＣ（管理ソフトプロセス（ＧＭ））は、当該ＵＩデバイスに対して、当該ＤＡＷプロセスを実行しているＰＣのＩＰアドレス、および該待受応答に記載されていた待ち受けポート番号の情報が含まれる制御セッション確立要求を管理セッションを通じて送信する（ステップＳ６４）。この確立要求を受信した当該ＵＩデバイスは、そこに記載されているＩＰアドレスのＰＣの、同記載されているポート番号のポートに、制御セッションの接続指示（ＳＹＮ）を送信し、これにより、図１４に示す手順に従い、該ＰＣの当該ＤＡＷプロセスとの間の制御セッションが確立される。そして、該確立を確認したＵＩデバイスは、当該制御セッションの確立完了を通知する確立応答を、管理セッションを用いて、管理ソフトプロセス（ＧＭ）を実行しているＰＣに送信する（ステップＳ６８）。ここで、ステップＳ６６〜Ｓ６８の各処理が全て成功し、当該ＵＩデバイスと選択されたＤＡＷプロセスとの間の制御セッションが確立された場合には、管理ソフトプロセス（ＧＭ）が、当該ＵＩデバイスの操作された選択ボタンの点灯要求を管理セッションを通じて送信する（ステップＳ６５）。点灯要求を受信した当該ＵＩデバイスは、選択前に点灯していた選択ボタンを消灯して、選択された選択ボタンを点灯させ、選択された選択ボタンが点灯された旨を管理ソフトプロセス（ＧＭ）に送信する（ステップＳ６９）。管理ソフトプロセス（ＧＭ）では、選択ボタンが点灯された旨の応答があったことを確認してＢ押下受信処理を終了する。また、ステップＳ６６〜Ｓ６８の何れかの処理が失敗した場合は、管理ソフトプロセス（ＧＭ）を実行しているＰＣの表示デバイスに、エラーの発生を示すエラー表示を行う。

上記したように、ＵＩデバイスはＤＡＷプロセスの１つに制御セッションを介して接続されており、ＵＩデバイスに設けられている操作子を操作することにより、一連の処理が行われてＤＡＷプロセスのパラメータを操作することができる。この際にＵＩデバイスにおけるＣＰＵ５１で行われるＰ（パラメータ）操作時処理および表示更新処理と、当該ＵＩデバイスで制御されるＤＡＷプロセスを実行しているＰＣのＣＰＵ４０で行われるＰ操作受信処理のフローチャートを図１８に示し、これらの一連の処理を説明する。
ＵＩデバイスに設けられているいずれかの操作子を操作すると、当該ＵＩデバイスにおけるＣＰＵ５１がＰ操作時処理を開始し、ステップＳ７０にて制御セッションを用いて操作された操作子のＰ（パラメータ）操作イベントを、当該ＵＩデバイスがＤＡＷプロセスに制御セッションを用いて送信する。これにより、Ｐ操作時処理は終了するが、Ｐ操作イベントを受信したＤＡＷプロセスを実行しているＰＣのＣＰＵ４０がＰ操作受信処理を開始し、ステップＳ７１にて対応するパラメータ値をＰ操作イベントに応じて変更する。次いで、ステップＳ７２にてパラメータ値の変更結果に応じた表示用データを当該ＵＩデバイスに制御セッションを用いて送信する。これにより、Ｐ操作受信処理は終了するが、表示用データを受信した当該ＵＩデバイスにおけるＣＰＵ５１が表示更新処理を開始し、ステップＳ７３にて表示用データに基づいて、パラメータの値が表示されたり、操作された操作子がボタンの場合はＬＥＤが点灯されたり、あるいは、パラメータがフェーダレベルの場合はフェーダ２１が駆動される。これにより、表示更新処理処理は終了する。
なお、ＵＩデバイスにおいて操作することのできる対象パラメータとしては、ＤＡＷプロセスが起動されたＰＣのディスプレイ４８に表示される各種画面のオープンまたはクローズ、トラックに関しては、音響データの時間軸上の位置の設定、録音の開始および停止、再生の開始および停止、などとされ、ミキサ画面に関しては、各入力ｃｈ、各トラックｃｈ、各バスｃｈ、各出力ｃｈのパラメータ設定とされ、各ｃｈに関しては、フェーダ値、オン／オフ、センドレベル値、イコライザ設定、コンプレッサ設定などとされる。さらに、各ｃｈにインサートされたプラグインエフェクトの設定の操作とされる。

以上説明した本発明にかかる音楽システム管理方法は、管理ソフトプロセスが、まず、ネットワーク上の選択した音楽ソフトプロセス及びコントローラとの間に管理コネクションを確立する。そして、その管理コネクションを介して、各コントローラと所望の音楽ソフトプロセスとの間に制御コネクションを確立する。そして、コントローラによる音楽ソフトプロセスのリモート制御は、該制御コネクションを介して行われる。このような本発明にかかる音楽システム管理方法において、図３に示すＧＭ画面３には、他の音楽システムに属するＵＩデバイスやＤＡＷプロセスについて、どの音楽システムに属するかを識別できるように表示してもよい。
また、上記説明した音楽システムは、ＤＡＷプロセスとＵＩデバイスとで構成されるシステムであったが、ミキサエンジンとＵＩデバイスによるシステムや、音源デバイスとＵＩデバイスによるシステムなどに本発明にかかる音楽システム管理方法を適用しても良い。その場合、管理ソフトプロセス（ＧＭ）は、別途用意されたＰＣで起動しても良いし、ミキサエンジンや音源デバイスのＣＰＵで起動してもよい。また、ユーザは、ＵＩデバイスで、ミキサエンジンや音源デバイスなどをリモート制御できる。
なお、本発明にかかる音楽システム管理方法において、各セッションの種類が管理セッションであるか制御セッションであるかは、管理ソフトプロセス、ＤＡＷ（音楽ソフト）プロセス、及びＵＩデバイス（コントローラ）が、それぞれ、自身に確立された各セッション毎に区別しており、パケットをセッションを介して送信する際に、そのセッションの種類に応じたパケットを形成して送信するようになっている。本発明にかかる音楽システム管理方法では、セッションは何れも皆ＴＣＰコネクションであり、ここでの種類の違いは、流れるパケットの違いということになる。
また、本発明にかかる音楽システム管理方法において、ネットワーク技術規格はイーサネットに限るものではなく、他のネットワーク技術規格を採用することができる。この場合、採用されたネットワーク技術規格に応じたフレームやパケットのデータ構成とされる。さらに、コントローラのパネル構成は一例であり、操作子をロータリエンコーダ等としたり、任意の位置に所望の種類の操作子等を配置することができる。さらにまた、コントローラにおいて、物理的な操作子に替えてディスプレイに表示したＵＩ画面の操作子としてもよく、例えば、コントローラソフトウェアをインストールしたタブレット端末をコントローラとすることができる。さらにまた、ＰＣやＵＩデバイスのハードウェア構成は一例であって、図示した構成に限るものではない。

１ 音楽システム、２ ネットワーク、３ ＧＭ画面、３ａ 「Workgroup」の欄、３ｂ 「Outside」の欄、３ｃ 左矢印ボタン、３ｄ 右矢印ボタン、４ ＵＩデバイス、１０ フェーダコントローラ、１１ メインコントローラ、２０ａ ストリップ部、２０ｂ コントロール部、２１ フェーダ、２２ ｃｈ名表示部、２３ ノブ、２４ 第１操作子、２５ 第２操作子、２６ 選択ボタン、２６ａ〜２６ｃ ボタン、３１ 選択ボタン、３１ａ〜３１ｃ ボタン、４０ ＣＰＵ、４１ ＲＯＭ・ＲＡＭ、４２ 不揮発Mem.、４３ Audio IO、４４ Audio Device、４５ 操作ＩＯ、４６ 操作Device、４７ 表示ＩＯ、４８ ディスプレイ、４９ ＮＩＯ、５０ ＣＰＵバス、５１ ＣＰＵ、５２ ＲＯＭ・ＲＡＭ、５３ 不揮発Mem.、５４ 操作子、５５ 表示器、５６ ＮＩＯ、５７ バス、ＤＡＷ 音楽ソフト、ＧＭ 管理ソフトプロセス、ＰＣ１〜ＰＣ７ パソコン、Ｍ１〜Ｍ３ メインコントローラ、Ｆ１〜Ｆ５ フェーダコントローラ

Claims (5)

1. １のコンピュータで起動された管理ソフトプロセスが、ネットワークを介して接続されている複数のコンピュータで起動された複数の音楽ソフトプロセスと、該ネットワークに接続された複数のコントローラとを制御して、１つの音楽システムとして動作させる音楽システム管理方法であって、
   前記管理ソフトプロセスは、
   ユーザから、前記複数の音楽ソフトプロセスと前記複数のコントローラの中から所望の音楽ソフトプロセスとコントローラの選択を受け付ける第１の過程と、
   前記ネットワークを介して、前記第１の過程で受け付けられた音楽ソフトプロセスおよびコントローラと通信を行い、該音楽ソフトプロセスおよびコントローラと前記管理ソフトプロセスの間で管理通信を行うための管理セッションを前記ネットワーク上に確立する第２の過程と、
   ユーザから、各コントローラに対して制御対象となる１の音楽ソフトプロセスの選択を受け付ける第３の過程と、
   前記管理セッションを介して、各コントローラおよび前記第３の過程で受け付けられた１の音楽ソフトプロセスと通信を行い、該コントローラの現在の制御セッションを開放するとともに、前記ネットワーク上に、該コントローラと該１の音楽ソフトプロセスの間で制御通信を行うための新たな制御セッションを確立する第４の過程と、
   を有し、
   ユーザによる各コントローラの操作に応じて、当該コントローラは、当該コントローラとの間に制御セッションが確立された音楽ソフトプロセスを、前記制御セッションを介してリモート制御することを特徴とする音楽システム管理方法。
2. 前記ネットワーク上の複数のコンピュータで複数の管理ソフトプロセスが起動され、前記複数の音楽ソフトプロセスおよび前記複数のコントローラは、それぞれ、前記複数の管理ソフトプロセスのうちの何れか１つの管理ソフトプロセスのみとの間に前記管理セッションを確立することができ、
   前記複数の管理ソフトプロセスのうちの何れか１つの管理ソフトプロセスと、当該管理ソフトプロセスとの間に管理セッションが確立された音楽ソフトプロセスおよびコントローラにより１つの音楽システムが構築され、結果として、前記ネットワーク上には、複数の管理ソフトプロセスに対応する複数の音楽システムが構築されることを特徴とする請求項１に記載の音楽システム管理方法。
3. 前記複数の管理ソフトプロセスのそれぞれは、
   さらに、当該管理ソフトプロセスとは異なる管理ソフトプロセスとの間において、既に管理セッションが確立されている音楽ソフトプロセス又はコントローラとの間で、割込通信を行うための割込セッションを一時的に確立する第５の過程と、
   前記割込セッションを介して、該割込セッションが確立された音楽ソフトプロセス又はコントローラと通信を行い、該割込セッションを開放させるとともに、前記ネットワーク上に、該音楽ソフトプロセスおよびコントローラと当該管理ソフトプロセスの間で管理通信を行うための管理セッションを確立する第６の過程と、
   を有していることを特徴とする請求項２に記載の音楽システム管理方法。
4. 前記複数の管理ソフトプロセスのそれぞれは、
   さらに、当該管理ソフトプロセスとは異なる管理ソフトプロセスとの間において、既に管理セッションが確立されている音楽ソフトプロセス又はコントローラとの間で、割込通信を行うための割込セッションを一時的に確立する第７の過程と、
   前記割込セッションを介して、該割込セッションが確立された音楽ソフトプロセス又はコントローラに情報を送信、又は、同音楽ソフトプロセス又はコントローラから情報を入手する第８の過程と、
   を有していることを特徴とする請求項２に記載の音楽システム管理方法。
5. あるコンピュータで起動された音楽ソフトプロセスに確立された各制御セッションは、同じコンピュータで確立されている前記管理セッションおよび他の制御セッションで使用されていないポート番号を使用して確立されることを特徴とする請求項１記載の音楽システム管理方法。

Images