音楽ネットワークシステムに用いる電子音楽装置及びプログラム
【課題】 バス全体での実質的なデータ送信量を増やす。
【解決手段】 所定のバスにより接続されて１つのネットワークを構成する複数の機器における各機器間の接続構成を取得する。該取得した各機器間の接続構成に応じて、前記バスを介したデータ送信に必要なバスの使用帯域幅を算出する。前記算出したバスの使用帯域幅の確保に応じて、少なくともネットワークを構成している複数の機器のいずれかに対して予め構築済みの論理的なパスに従いデータを送信する。このように、データ送信に先立って申請するバスの使用帯域幅を現状のネットワークの接続構成に応じて最適化するようにしたことから、前記バスの使用帯域幅に従来含まれていた余計なマージン分を減らすことができる。したがって、バス全体における実質的なデータ転送量を増やすことができ、効率的にデータ転送を行うことができるようになる。
【解決手段】 所定のバスにより接続されて１つのネットワークを構成する複数の機器における各機器間の接続構成を取得する。該取得した各機器間の接続構成に応じて、前記バスを介したデータ送信に必要なバスの使用帯域幅を算出する。前記算出したバスの使用帯域幅の確保に応じて、少なくともネットワークを構成している複数の機器のいずれかに対して予め構築済みの論理的なパスに従いデータを送信する。このように、データ送信に先立って申請するバスの使用帯域幅を現状のネットワークの接続構成に応じて最適化するようにしたことから、前記バスの使用帯域幅に従来含まれていた余計なマージン分を減らすことができる。したがって、バス全体における実質的なデータ転送量を増やすことができ、効率的にデータ転送を行うことができるようになる。
【発明の詳細な説明】
【技術分野】
【０００１】
この発明は、バス上に構築される論理的なパスに従うデータ転送が可能な音楽ネットワークシステムに用いるのに好適な電子音楽装置及びプログラムに関する。特に、バス全体における実質的なデータ送信量を増やすために、データ送信に先立って確保すべきバスの使用帯域幅を最適化する電子音楽装置及びプログラムに関する。
【背景技術】
【０００２】
従来から、マルチメディアに対応した例えばIEEE1394（アイトリプルイー1394）規格などの所定の通信規格に従って構成されたネットワークにおいて、ディジタルオーディオデータやMIDIデータ等の音楽データを送受できるように構成した音楽ネットワークシステムが知られている。こうした音楽ネットワークシステムにおいては、IEEE1394規格に準拠したインタフェース（IEEE1394シリアルバス）を有する各種の制御機器や音楽関連機器等の電子音楽装置（ノードと呼ぶ）が複数接続されており、IEEE1394シリアルバスを用いたアイソクロナス転送に基づき多数の音楽データをストリームデータとして、複数ノードによって構成された一の論理的な音楽システム（例えば、商標「mLAN」で呼ばれる当出願人に係る音楽システム）に従う各ノード相互間で送受できるようにしている。これに関連するものとして、例えば下記に示す特許文献１に記載の技術などがある。
【特許文献１】特許第3271493号公報
【０００３】
ここで、IEEE1394インタフェースを用いた音楽ネットワークシステム（音楽LAN）について、図７を参照しながら説明する。図７は、従来知られた音楽ネットワークシステムの一実施例を示すシステムブロック図である。この図７に示す音楽ネットワークシステムは、IEEE1394インタフェースを装備した５台のノードＡ〜Ｅが、IEEE1394ケーブルＣによりツリー状に接続されたネットワークの接続構成（トポロジーと呼ぶ）となっている。IEEE1394インタフェースはIEEE1394規格に準拠してデータ通信を行うハードウェア及びソフトウェアで構成されるインタフェースであり、各ノード同士を物理的に接続しているIEEE1394ケーブルＣを介して実際に音楽データの送受信動作を行う。ネットワーク接続される前記ノードとしては、パーソナルコンピュータ、ミュージックシンセサイザのような電子楽器、シーケンサのような自動演奏装置、レコーダのような波形記録装置、ミキサやエフェクタのような信号処理装置、音源装置等、任意の制御機器や音楽関連機器が相当する。
【０００４】
従来知られているように、全てのノードがIEEE1394ケーブルＣでツリー接続されている上記した音楽ネットワークシステムにおいては、任意のノード同士がIEEE1394ケーブルで直接接続されていなくても、ユーザにより設定されたバス上に構築される論理的なパス（これを仮想接続と呼ぶ）により接続されていれば任意のノード間での音楽データの送受が可能となる。すなわち、各ノードが有するMIDIin/outやAUDIOin/out等の物理端子を用いて任意のノード同士を物理的に直接接続していなくても仮想接続されていれば、あたかも各ノード同士を物理的に直接接続したのと同様にして特定ノード間で音楽データを送受することができるようになる。例えば図７に示すように、ノードＡ（Ｎａ）は、ノードＢ（Ｎｂ）、ノードＣ（Ｎｃ）、ノードＤ（Ｎｄ）のいずれのノードともIEEE1394ケーブルＣで直接接続されていないにもかかわらず、図中において矢印で示す仮想接続線ＶＣにより任意のノード同士を繋ぐように予めバス上に論理的なパスを構築するよう設定しておくだけで、ユーザはIEEE1394ケーブルＣによる物理的な接続を意識することなく、例えばノードＡ（Ｎａ）からノードＢ（Ｎｂ）、ノードＣ（Ｎｃ）、ノードＤ（Ｎｄ）のいずれのノードに対しても音楽データを送信させることができるようになる。
【０００５】
IEEE1394シリアルバス（以下、単にバスと呼ぶ）を用いた上記音楽ネットワークシステムでは、例えば１２５μｓ（マイクロ秒）の周期で通信サイクルが設定されており、アイソクロナス・チャンネルを確保しているノードはこの通信サイクル毎に１回だけ確保した帯域分のパケット化した音楽データ（アイソクロナスパケット）を転送することができる。図８にIEEE1394シリアルバスを用いた音楽ネットワークシステムにおける通信サイクルの一例を示す。バスにおける通信サイクルの管理は、ネットワークのルートとなり通信システム全体を管理するよう割り当てられたノード（以下、これをルートノードと呼ぶ）がバス上にサイクルスタートパケットを送出することにより開始される。このルートノードはバスにリセットがかかった際に、IEEE1394の仕様書に規定する手法によってネットワークに接続されたノードの中からいずれかのノードが自動的に割り当てられる。図８において、バスにサイクルスタートパケットが送出された所定時間経過後に、ノードがサイクルスタートパケットを受信すると、所定の時間（所謂アイソクロナスギャップ）だけ待機してから、ルートノードに対してバスの使用要求を行う。複数のノードがバスの使用要求を行ったときは、ルートノードは最も早くバスの使用要求をしてきたノードに対してのみにバスの使用を許可する。こうした処理に係る時間が、図８に示すアービトレーションタイム（Arbitration time）である。
【０００６】
ルートノードからバスの使用許可を得られたノードでは、バスに上記アイソクロナスパケット（Isochronous packet）を送出してデータ送信を開始する。このとき、アイソクロナスパケットの前後には、それぞれデータプリフィクス（data prefix）とデータエンド（data end）が付加される。一方、バスの使用許可が得られなかったノードでは、バスの使用許可を得たノードがアイソクロナスパケットを送出してから、伝搬遅延時間（Propagation delay）以内に受信が完了し、データエンド完了から所定のアイソクロナスギャップ（Isochronous gap）を待って再びルートノードに対してバスの使用要求を行う。そして、バスの使用許可が得られたら、バスに新たなアイソクロナスパケット（図示せず）を送出する。上記伝搬遅延時間（Propagation delay）は、あるノードから通信システム内で最も離れているノードまでの間をパケットが伝搬するのに必要な時間に応じて決まるものである。従来においては上記伝搬遅延時間（Propagation delay）として、通信システム内で最も離れた２つのノード間で必要な時間を一律に使用している。また、アービトレーションタイム（Arbitration time）は、各ノードとルートノードとの間の経路の長さに応じて決まるものであり、各ノード毎に独自の値となる。そして、アイソクロナスギャップ（Isochronous gap）、データプリフィックス（data prefix）、データエンド（data end）はIEEE1394の仕様書に規定されている固定値である。したがって、図８に示すように、１個のアイソクロナスパケットの伝送には最大で（最も離れたノード間を伝わるまでに）アイソクロナスギャップから伝搬遅延時間までの時間帯域が必要となる。この明細書では、こうした時間帯域をバスの使用帯域幅と呼ぶ。また、バスの使用帯域幅のうち、アイソクロナスパケット以外の分、つまりアイソクロナスギャップ、データプリフィックス、データエンド、アービトレーションタイム、及び伝搬遅延時間のトータルを「オーバーヘッド」と呼び、このオーバーヘッドはネットワークの接続構成（トポロジー）によって変わるものである。
【０００７】
上記した音楽ネットワークシステムにおいて、バスにアイソクロナスパケットを送出しようとするノードは、データ送信のために使用する使用チャンネル（つまりアイソクロナス・チャンネル）やデータ送信に必要なだけのバスの使用帯域幅などのリソースをまず確保する必要がある。そのため、データ送信に先立ち、バスのチャンネルとIEEE1394バス帯域を一元管理する機器である所謂アイソクロナスリソースマネージャーノードに対して、確保すべき使用チャンネル（アイソクロナス・チャンネル）やバスの使用帯域幅などのリソースを申請し、これらの使用許可をもらってはじめてネットワークを介してのデータ送信を開始することができる。そこで、従来においてはデータ送信に先立ち申請するバスの使用帯域幅として、最も離れた２つのノード間で必要とされるオーバーヘッド（既定値）に基づくバスの使用帯域幅を申請して確保するようにしていた。しかし、現状のネットワークの接続構成が想定されているネットワークの接続構成とはかけ離れた構成である場合には、上記したような想定されているネットワークの接続構成に従う既定のオーバーヘッドに基づくバスの使用帯域幅を用いると余分なマージンを確保することから帯域に無駄が生じて、その分だけバス全体におけるデータ転送量が少なくなってしまうこととなりデータ転送の効率が悪くなる、という問題点があった。
【発明の開示】
【発明が解決しようとする課題】
【０００８】
本発明は上述の点に鑑みてなされたもので、データ送信に先立って確保するバスの使用帯域幅を現状のネットワークの接続構成に応じて最適化することのできるようにした音楽ネットワークシステムに用いる電子音楽装置及びプログラムを提供することを目的とする。
【課題を解決するための手段】
【０００９】
本発明の請求項１に係る電子音楽装置は、所定のバスにより接続されて１つのネットワークを構成する複数の機器に対し、前記バス上に構築される論理的なパスに従いデータを送信する電子音楽装置であって、前記所定のバスにより接続されている各機器間の接続構成を取得する取得手段と、前記取得した各機器間の接続構成に応じて、前記バスを介したデータ送信に必要なバスの使用帯域幅を算出する算出手段と、前記算出したバスの使用帯域幅の確保に応じて、少なくともネットワークを構成している複数の機器のいずれかに対して予め構築済みの論理的なパスに従いデータを送信する送信手段とを具備する。
【００１０】
本発明によると、所定のバスにより接続されて１つのネットワークを構成する複数の機器における各機器間の接続構成を取得し、該取得した各機器間の接続構成に応じて算出した前記バスを介したデータ送信に必要なバスの使用帯域幅を確保して、少なくともネットワークを構成している複数の機器のいずれかに対して予め構築済みの論理的なパスに従いデータを送信する。このようにして、データ送信に先立って申請するバスの使用帯域幅を現状のネットワークの接続構成に応じて最適化するようにしたことから、前記バスの使用帯域幅に従来含まれていた余計なマージン分を減らすことができる。こうすることで、バス全体における実質的なデータ転送量を増やすことができ、効率的にデータ転送を行うことができるようになる。
【００１１】
本発明は装置の発明として構成し実施することができるのみならず、方法の発明として構成し実施することができる。また、本発明は、コンピュータまたはＤＳＰ等のプロセッサのプログラムの形態で実施することができるし、そのようなプログラムを記憶した記憶媒体の形態で実施することもできる。
【発明の効果】
【００１２】
この発明によれば、データ送信に先立って申請するバスの使用帯域幅を現状のネットワークの接続構成に応じて最適化するようにしたことから、バスの使用帯域幅に従来含まれていた余分のマージン分を減らすことができ、これに応じてバス全体における実質的なデータ転送量を増やすことができる、という効果を奏する。
【発明を実施するための最良の形態】
【００１３】
以下、この発明の実施の形態を添付図面に従って詳細に説明する。
【００１４】
まず、本発明に係る電子音楽装置の全体構成について、図１を用いて説明する。図１は、本発明に係る電子音楽装置の全体構成の一実施例を示すハード構成ブロック図である。
【００１５】
ここに示される電子音楽装置はコンピュータを用いて構成されており、そこにおいて、図示しないアイソクロナスリソースマネージャーノードに対してデータ送信のために必要とされる時間帯域（バスの使用帯域幅）や使用チャンネル（アイソクロナス・チャンネル）などのリソースを申請し、該リソースの確保に応じて音楽データ（詳しくはアイソクロナスパケット）の送信を開始することのできる機器である。本明細書では説明の便宜上、こうした音楽データを送信する機器を送信ノード、音楽データの送信先の機器を受信ノードと呼んで区別する。送信ノードにおいて音楽データの送信を開始する処理は、コンピュータが該処理を実現する所定の制御プログラム（後述する図２参照）を実行することにより実施される。勿論、こうした処理はコンピュータソフトウエアの形態に限らず、DSP（ディジタル・シグナル・プロセッサ）によって処理されるマイクロプログラムの形態でも実施可能であり、また、この種のプログラムの形態に限らず、ディスクリート回路又は集積回路若しくは大規模集積回路等を含んで構成された専用ハードウエア装置の形態で実施してもよい。なお、電子音楽装置はここに図示したものに限らず、図示した以外の構成要素を具えていてよい。
【００１６】
本実施例に示す電子音楽装置（送信ノード）は、マイクロプロセッサユニット（ＣＰＵ）１、リードオンリメモリ（ＲＯＭ）２、ランダムアクセスメモリ（ＲＡＭ）３からなるマイクロコンピュータによって制御される。ＣＰＵ１は、この電子音楽装置全体の動作を制御するものである。このＣＰＵ１に対して、データ及びアドレスバス１Ｄを介してＲＯＭ２、ＲＡＭ３、検出回路４、表示回路５、外部記憶装置６、IEEE1394インタフェース（Ｉ／Ｆ）７、各種インタフェース（Ｉ／Ｆ）８、不揮発メモリ９がそれぞれ接続されている。更に、ＣＰＵ１には、タイマ割込み処理（インタラプト処理）における割込み時間や各種時間を計時するタイマ１Ａが接続されている。例えば、タイマ１Ａはクロックパルスを発生し、発生したクロックパルスをＣＰＵ１に対して処理タイミング命令として与えたり、あるいはＣＰＵ１に対してインタラプト命令として与える。ＣＰＵ１は、これらの命令に従って各種処理を実行する。
【００１７】
ＲＯＭ２は、ＣＰＵ１により実行される各種プログラムや各種データを格納するものである。ＲＡＭ３は、ＣＰＵ１が所定のプログラムを実行する際に発生する各種データを一時的に記憶するワーキングメモリとして、あるいは現在実行中のプログラムやそれに関連するデータを記憶するメモリ等として使用される。ＲＡＭ３の所定のアドレス領域がそれぞれの機能に割り当てられ、レジスタやフラグ、テーブル、メモリなどとして利用される。操作子４Ａは、各種設定等を行うためのスイッチやボタン、数値データ入力用のテンキーや文字データ入力用のキーボード、あるいはディスプレイ５Ａに表示された所定のポインティングデバイスを操作するマウスなどの各種操作子である。例えば、後述するような自ノードから最も離れたノードまでのホップ数を指定するディップスイッチなどを含む（後述する図３参照）。勿論、これら以外にも各種操作子を含んでいてよい。検出回路４は、上記各操作子４Ａの操作状態を検出し、その操作状態に応じた情報をデータ及びアドレスバス１Ｄを介してＣＰＵ１に出力する。
【００１８】
表示回路５は例えば液晶表示パネル（ＬＣＤ）やＣＲＴ等から構成されるディスプレイ５Ａに、例えばバス上に構築される論理的なパス（仮想接続）を設定する画面（図示せず）などの各種画面を表示したり、あるいはＣＰＵ１の制御状態などを表示する。ユーザは該ディスプレイ５Ａに表示される各種画面を参照することにより、各種設定を容易に行うことができる。外部記憶装置６は、各種データやＣＰＵ１が実行する各種制御プログラムなどを記憶する。なお、上述したＲＯＭ２に制御プログラムが記憶されていない場合、この外部記憶装置６（例えばハードディスク）に制御プログラムを記憶させておき、それをＲＡＭ３に読み込むことにより、ＲＯＭ２に制御プログラムを記憶している場合と同様の動作をＣＰＵ１にさせることができる。このようにすると、制御プログラムの追加やバージョンアップ等が容易に行える。なお、外部記憶装置６はハードディスク（HD）に限られず、フレキシブルディスク（FD）、コンパクトディスク（CD‐ROM・CD‐RAM）、光磁気ディスク（MO）、あるいはDVD（Digital Versatile Disk）等の着脱自在な様々な形態の外部記憶媒体を利用する記憶装置であればどのようなものであってもよい。
【００１９】
IEEE1394インタフェース（Ｉ／Ｆ）７はIEEE1394規格に準拠してデータ通信を行うハードウェア及びソフトウェアで構成される高速通信インタフェース（IEEE1394シリアルバス）であって、このIEEE1394インタフェース７を介して物理的に接続している他のノードと実際に音楽データなどの各種情報の送受信動作を行うことができる。このIEEE1394インタフェース７を介してツリー接続された各ノードはネットワークＸを構成し、既に説明したように該ネットワークＸを構成するノード間では任意の特定ノード間で音楽データを送受するよう仮想接続を設定することができるようになっている（図７に示した仮想接続線ＶＣ参照）。
【００２０】
各種インタフェース８はIEEE1394インタフェース以外のMIDIインタフェースやオーディオインタフェースなど、他のノードと直接接続するためのインタフェースである。すなわち、MIDIインタフェース（又はオーディオインタフェース）は、外部接続された他の外部機器ＡＤからMIDIデータ（又はオーディオデータ）を当該ノードへ入力したり、あるいは当該ノードからMIDIデータ（又はオーディオデータ）を他の外部機器ＡＤへ出力するためのインタフェースである。外部機器ＡＤは、MIDIデータ又はオーディオデータを発生することが可能である機器であればどのような機器であってもよい。なお、各種インタフェース８は専用のインタフェースを用いるものに限らず、RS-232C等のシリアル・インタフェース、USB（ユニバーサル・シリアル・バス）等の、IEEE1394インタフェース以外の汎用インタフェースを用いて構成するようにしてよい。
【００２１】
不揮発メモリ９は、各ノードにおいて作成される「送信情報」などの各種情報を記憶する。この「送信情報」の内容は、ネットワークＸ上に新たなノードを追加接続する、あるいは各ノードにおける送信シーケンス数を変更するなど、ノードの増減や仮想接続の設定を変更したような場合に自動的に行われるバスの使用帯域幅の確保などにあわせて更新される。なお、この「送信情報」は従来知られているものであることから、その内容についてはここでの説明を省略する。
【００２２】
なお、本発明に係る電子音楽装置は、パーソナルコンピュータ、ミュージックシンセサイザのような電子楽器、シーケンサのような自動演奏装置、レコーダのような波形記録装置、ミキサやエフェクタのような信号処理装置、音源装置等、任意の製品応用形態をとっているものであってよい。
【００２３】
従来知られているように、上述した音楽ネットワークシステムにおいては、IEEE1394ケーブルを用いてネットワークに新たな電子音楽装置を接続する、又はネットワークからIEEE1394ケーブルにより既に接続済みの電子音楽装置を取り外すなどして当該音楽ネットワークシステムを構成するノードの数を増減させることができるだけでなく、各送信ノードのIEEE1394における１つのアイソクロナス転送に含まれる送信シーケンス数を変更する、あるいは任意の送信ノードに割り当てるバスの使用帯域幅を変更するなどの、各ノードの送信設定を変更することができる。こうした場合、既に説明したように、送信ノードにおいてはデータ送信に先立ち、データ送信用の使用チャンネル（アイソクロナス・チャンネル）とデータ送信に必要なだけのバスの使用帯域幅とをまず確保するために、バスのチャンネルとIEEE1394バス帯域を一元管理する機器である所謂アイソクロナスリソースマネージャーノードに対して、確保すべきバスの使用帯域幅や使用チャンネル（アイソクロナス・チャンネル）を申請する。そして、これらの使用許可をもらってはじめて、送信ノードはIEEE1394シリアルバスを介して任意の受信ノードに対してデータ送信を開始することができる。
【００２４】
そこで、各送信ノードで実行されるデータ送信開始のための処理について、図２を用いて説明する。図２は、各送信ノードで実行する「送信制御処理」の一実施例を示すフローチャートである。ただし、この処理を実行する送信ノードとしては、次の３つに分けられる。第一にバスリセット時においては音楽ネットワークシステムを構成する全ての送信ノード、第二に送信設定を変更された送信ノード、第三にデータ送信中止となった後に送信復旧が指示された送信ノード、のいずれかに分けられる。
【００２５】
ステップＳ１では、オーバーヘッドを求める「オーバーヘッド算出処理」を実行する。「オーバーヘッド算出処理」では、IEEE1394シリアルバスで接続されることにより構成された現状のネットワークの接続構成（トポロジー）に応じてオーバーヘッドを求める。このオーバーヘッドを求める処理としては、第１にユーザによるディップスイッチ等の操作により予め設定された内容に従いオーバーヘッドを求める処理方式、第２にネットワークを介して所定のノードから取得したIEEE1394規格に従うトポロジーマップを用いて自動的にオーバーヘッドを求める処理方式、第３に実際にPingパケットをネットワーク内に流すことによりオーバーヘッドを求める処理方式などがあり、これらの各処理方式に基づく「オーバーヘッド」の算出の詳細な説明については後述する（後述する図３、図４、図６参照）。ステップＳ２では、上記求めたオーバーヘッドに基づきバスの使用帯域幅を求める。つまり、求めたオーバーヘッドに送信対象データであるアイソクロナスパケット分を加算することにより、１つのアイソクロナスパケットをデータ送信するために必要なだけのバスの使用帯域幅を算出する（図８参照）。
【００２６】
ステップＳ３では、バスのチャンネルやIEEE1394バス帯域などのリソースを一元管理する機器であるアイソクロナスリソースマネージャノードに対してデータ送信に必要なリソース、ここでは前記求めたバスの使用帯域幅や使用チャンネル（アイソクロナス・チャンネル）などを確保するための申請を行う。ステップＳ４では、リソース獲得に成功したか否かを判定する。リソース獲得に成功した場合には（ステップＳ４のＹＥＳ）、データ送信開始の処理を実行する（ステップＳ５）。他方、リソース獲得に失敗した場合には（ステップＳ４のＮＯ）、データ送信が開始できなかった旨をユーザに伝えるなどのエラー処理を実行する（ステップＳ６）。すなわち、申請したバスの使用帯域幅がバス全体の帯域のうち未だ割り当てられていない分の帯域（残存帯域）を超えてしまう、あるいは申請した使用チャンネル（アイソクロナス・チャンネル）が既に割り当て済みでありチャンネル競合が生じるなどの理由により、データ送信のために必要なバスの使用帯域幅や使用チャンネル（アイソクロナス・チャンネル）を確保することができなかった送信ノードについては音楽データ送信を開始することができず、ぞの旨をユーザに対して示すためのエラー処理を実行する。
【００２７】
次に、上述した「送信制御処理」において実行する「オーバーヘッド算出処理」（図２のステップＳ１参照）について、上記したような３つの処理方式毎に図を分けてそれぞれ説明する。まず、ユーザによるディップスイッチ等の操作により予め設定された内容に従い「オーバーヘッド」を求める処理方式について、図３を用いて説明する。図３は、ユーザによるディップスイッチ等の操作により予め設定された内容に従いオーバーヘッドを求める「オーバーヘッド算出処理」の一実施例を示すフローチャートである。
【００２８】
ステップＳ１１では、自ノードから最も離れたノードまでのホップ数をディップスイッチの設定内容から、あるいは不揮発メモリから取得する。ここで、ホップ数とは、IEEE1394シリアルバスにより接続されている任意のノードと任意の他のノードとの間の経路にある標準ケーブルの本数に相当するバスの数である。例えば図７に示したネットワークにおいて、自ノードであるノードＡ（ＮＡ）から最も離れたノードＣ（ＮＣ）までのホップ数は「３」となる。このホップ数が大きいほど任意のノード間を多数の標準ケーブルで繋いでいることになるので、それだけ任意のノード間の通信距離は長くなる。この処理では、ユーザ自身が目視等により確認した現状のネットワークの接続構成（トポロジー）に応じて、自機からデータ送信先の受信ノードまでのホップ数をディップスイッチを操作することにより設定する。
【００２９】
ステップＳ１２では、オーバーヘッドを計算する。この実施例においては、オーバーヘッドのうち固定値であるアイソクロナスギャップ（Isochronous gap）、データプリフィックス（data prefix）、データエンド（data end）以外の、伝搬遅延時間（Propagation delay）を上記ホップ数から、アービトレーションタイム（Arbitration time）を所定のホップ数からそれぞれ求める。そして、求めた伝搬遅延時間及びアービトレーションタイムと、上記アイソクロナスギャップ、データプリフィックス、データエンドとを加算することにより「オーバーヘッド」を算出する。ここで、アービトレーションタイムを求めるときに参照されるホップ数は、予め特定されたバスにおける通信サイクルの管理を行うルートノードでIEEE1394の仕様書に規定する手法により自動的に決定されるものである。そのため、伝搬遅延時間を求める際に参照されるホップ数と異なり、ユーザ自身ではネットワーク上のどのノードがルートノードに決定されるかを予め把握することができないために、アービトレーションタイムを求めるときに参照されるホップ数についてはユーザ自身で設定することができない。したがって、ここでは前提として、ルートノードを自機から最も離れたノードとして、その間のホップ数をもとにしてアービトレーションタイムを求めるようにするとよい。以上のように、アービトレーションタイム及び伝搬遅延時間は送信ノードからのホップ数、つまりネットワークの接続構成に応じてその値が変わりうるものであって、これを厳密に現状のネットワークの接続構成（トポロジー）にあわせて調整するようにしたことにより、余分なマージンのないバスの使用帯域幅のみを申請することができるようになる。
【００３０】
なお、ここでは自機におけるディップスイッチ操作に応じた設定内容に従ってオーバーヘッドを求めるようにしたがこれに限らず、ネットワークにある自機以外の他のノードで設定された内容を自機の不揮発メモリ９に取り込んで、これを用いてオーバーヘッドを求めるようにしてもよい。
【００３１】
次に、ネットワークからIEEE1394規格に従うトポロジーマップを取得し、これを用いて自動的に「オーバーヘッド」を求める処理方式について、図４を用いて説明する。図４は、ネットワークから取得したIEEE1394規格に従うトポロジーマップを用いて自動的にオーバーヘッドを求める「オーバーヘッド算出処理」の一実施例を示すフローチャートである。
【００３２】
ステップＳ２１では、音楽ネットワークシステム（音楽LAN）上のバスマネジャーノードを探す。このバスマネジャーノードのノードＩＤは、アイソクロナスリソースマネージャーノードから取得することができる。また、アイソクロナスリソースマネジャーノードのノードＩＤは、自機のＬＡＮにおけるプロトコル階層の物理層から取得することができる。したがって、自機からアイソクロナスリソースマネジャーノードを介して、バスマネジャーノードを特定することができる。ステップＳ２２では、バスマネジャーノードからトポロジーマップを取得する。ここで、バスマネジャーノードから取得するトポロジーマップについて、図５を用いて簡単に説明する。図５は、トポロジーマップを説明するための概念図である。ただし、ここでは図７に示した接続構成である音楽ネットワークシステムの場合におけるトポロジーマップを例に示した。
【００３３】
トポロジーマップはバスリセット時の初期化の際に、現状のネットワークにおける各ノード間の接続を解析することに応じて、バスマネージャノード上に作成される。すなわち、バスマネージャノードではネットワークを構成する各ノードから、ノードＩＤとそのノードが有するポート（物理端子）の状態を取得して、図５に示すようなトポロジーマップを作成する。ただし、バスマネージャノード上に、図５に示すようなデータ構造のトポロジーマップを実際に作成するわけではない。トポロジーマップでは各ノード（ノードＩＤ）毎にその有するポート（物理端子）の状態を示しており、マップ全体として各ノード間の接続構成（ネットワークの接続構造）が分かるようになっている。例えば、図７に示すように、ツリー最下位に位置するノードＩＤが「０」であるノードＡ（ＮＡ）ではその有するポートのうち、第１ポート（Port1）のみがその上位に位置する親となるノードＩＤが「４」であるノードＥ（ＮＥ）に繋がっている。また、ノードＥ（ＮＥ）ではその有するポートのうち、第１ポート（Port1）は子となる前記ノードＡ（ＮＡ）と、第２ポート（Port2）はその下位に位置する子となるノードＩＤが「３」であるノードＤ（ＮＤ）に繋がっている。このような場合、トポロジーマップでは、ノードＩＤ「０」（つまりノードＡ）の第１ポート（Port1）に「親（ここではノードＥ）と繋がっている」、第２ポート（Port2）及び第３ポート（Port3）に「繋がっていない」と示される。また、ノードＩＤ「４」（つまりノードＥ）の第１ポート（Port1）に「子（ここではノードＡ）と繋がっている」、第２ポート（Port2）に「子（ここではノードＤ）と繋がっている」、第３ポート（Port3）に「ポートが無い」と示される。同様にして、ノードＩＤ「１」（つまりノードＢ）、ノードＩＤ「２」（つまりノードＣ）、ノードＩＤ「３」（つまりノードＤ）の各ノードについても、各ポートの状態が示される。こうした各ノード毎の各ポート状態の組み合わせから、各ノード間の接続構成を把握することができる。
【００３４】
図４のフローチャートの説明に戻って、ステップＳ２３では、取得した上記トポロジーマップ（つまり各ノード間の接続構成）に従い、自機からルートノードまでのホップ数と、現状のネットワークにおける自機から最も離れたノードまでのホップ数を求める。ステップＳ２４では、上記求めた各ホップ数に基づきオーバーヘッドを計算する。すなわち、ネットワークの接続構成により変化するアービトレーションタイム及び伝搬遅延時間をホップ数から求め、これに固定値であるアイソクロナスギャップ、データプリフィックス、データエンドを加算して「オーバーヘッド」を算出する。ただし、この処理では、各ノード間が全て標準ケーブル（つまり長さやデータ伝送量が同一のケーブル）で繋がれているものとして求めたアービトレーションタイム及び伝搬遅延時間を用いて「オーバーヘッド」を算出する。
【００３５】
次に、実際にPingパケットをネットワーク内に流すことにより「オーバーヘッド」を求める処理方式について、図６を用いて説明する。図６は、実際にPingパケットをネットワーク内に流すことによりオーバヘッドを求める「オーバーヘッド算出処理」の一実施例を示すフローチャートである。一般的に音楽ネットワークシステム（音楽LAN）上で標準でないケーブルでネットワークが構成されている場合、ホップ数に基づく計算からでは伝搬遅延時間及びアービトレーションタイムを正しく算出することができない。そこで、こうしたことを避けるために、この処理ではPingパケットを送信先の受信ノードに対して送ることで実際にかかる伝搬遅延時間を測定し、同様にPingパケットをルートノードに対して送ることで実際にかかるアービトレーションタイムを測定する。
【００３６】
ステップＳ３１では、音楽ネットワークシステム（音楽LAN）上におけるバスマネジャーノードを探す。ステップＳ３２では、バスマネジャーノードからトポロジーマップを取得する。ステップＳ３３では、トポロジーマップから各リーフノード（ツリー状に接続されたネットワーク接続構成において、１つの機器としかつながっていない末端に位置する機器）のノードＩＤを求める。ステップＳ３４では、各リーフノードに向けてPingパケットを送る。ステップＳ３５では、各リーフノードからのPingパケットの返答を待つ。ここでPingパケットはネットワークの速度や状態を確認するためのものであり、宛先となるノードＩＤを含む。各リーフノードに対してPingパケットが送られると、その宛先となっているノードはPingパケットの発信元であるノードに対して返答を返す。ステップＳ３６では、Pingパケット送信時刻と返答時刻との時間差から最も時間がかかったノードを最も離れたノードとし、前記時間差に基づき伝播遅延時間（Propagation delay）を求める。このようなPingパケットを用いる方法は、標準でないケーブルを用いてネットワークが構成されている場合に有効である。
【００３７】
ステップＳ３７では、トポロジーマップからルートノードのノードＩＤを求める。ステップＳ３８では、ルートノードに向けてPingパケットを送る。ステップＳ３９では、Pingパケットの返答を待つ。ステップＳ４０では、Pingパケット送信時刻と返答時刻の時間差からルートノードとのアービトレーションタイム（Arbitration time）を求める。ステップＳ４１では、上記求めた伝播遅延時間とアービトレーションタイムに基づきオーバーヘッドを算出する。
【００３８】
以上のようにして、現状のネットワークの接続構成（トポロジー）に従ってアービトレーションタイム及び伝搬遅延時間を調整し、現状のネットワークの接続構成（トポロジー）に対応させた余分なマージンの少ないバスの使用帯域幅のみをデータ送信に先立って確保するようにした。こうすると、バス全体における実質的なデータ転送量を増やすことができることから、効率的にデータ転送を行うことができるようになる。
【００３９】
なお、ルートノードとアイソクロナスマネージャーノードとは同じ機器であってよい。
なお、上述した実施例においては音楽ネットワークシステムとしてオーディオやMIDIなどの音楽データをストリームデータとして送受するシステムを例に挙げたがこれに限らず、動画データ等をストリームデータとして送受する音楽ネットワークシステムであってもよい。
なお、各送信ノードにおけるバスの使用帯域幅を変更する変更契機としては、IEEE1394において１つのアイソクロナス転送に含まれる送信シーケンス数を変更することに限らず、１つの送信ノードが送信するアイソクロナス転送の数を変更することもバスの使用帯域幅の変更契機に該当する。例えば、オーディオをステレオで送信していた状態からモノラルの送信に変更することが挙げられる。また、デジタルオーディオデータを送信する際のサンプリングレート変更に応じて送信するデータ量が変わることも、バスの使用帯域幅の変更契機に含まれる。
【図面の簡単な説明】
【００４０】
【図１】本発明に係る電子音楽装置の全体構成の一実施例を示すハード構成ブロック図である。
【図２】各送信ノードで実行する送信制御処理の一実施例を示すフローチャートである。
【図３】ユーザにより予め設定された内容に従いオーバーヘッドを求める「オーバーヘッド算出処理」の一実施例を示すフローチャートである。
【図４】トポロジーマップを用いて自動的にオーバーヘッドを求める「オーバーヘッド算出処理」の一実施例を示すフローチャートである。
【図５】トポロジーマップを説明するための概念図である。
【図６】Pingパケットをネットワーク内に流すことによりオーバヘッドを求める「オーバーヘッド算出処理」の一実施例を示すフローチャートである。
【図７】従来知られた音楽ネットワークシステムの一実施例を示すシステムブロック図である。
【図８】IEEE1394シリアルバスを用いた音楽ネットワークシステムにおける通信サイクルの一例を示すタイムチャートである。
【符号の説明】
【００４１】
１…ＣＰＵ、２…ＲＯＭ、３…ＲＡＭ、４…検出回路、４Ａ…操作子、５…表示回路、５Ａ…ディスプレイ、６…外部記憶装置、７…IEEE1394インタフェース、８…各種インタフェース、９…不揮発メモリ、１Ｄ…通信バス（データ及びアドレスバス）、Ｘ…ネットワーク、ＡＤ…外部機器、ＮＡ（ＮＢ、ＮＣ、ＮＤ、ＮＥ）…ノード、ＶＣ…仮想接続線
【技術分野】
【０００１】
この発明は、バス上に構築される論理的なパスに従うデータ転送が可能な音楽ネットワークシステムに用いるのに好適な電子音楽装置及びプログラムに関する。特に、バス全体における実質的なデータ送信量を増やすために、データ送信に先立って確保すべきバスの使用帯域幅を最適化する電子音楽装置及びプログラムに関する。
【背景技術】
【０００２】
従来から、マルチメディアに対応した例えばIEEE1394（アイトリプルイー1394）規格などの所定の通信規格に従って構成されたネットワークにおいて、ディジタルオーディオデータやMIDIデータ等の音楽データを送受できるように構成した音楽ネットワークシステムが知られている。こうした音楽ネットワークシステムにおいては、IEEE1394規格に準拠したインタフェース（IEEE1394シリアルバス）を有する各種の制御機器や音楽関連機器等の電子音楽装置（ノードと呼ぶ）が複数接続されており、IEEE1394シリアルバスを用いたアイソクロナス転送に基づき多数の音楽データをストリームデータとして、複数ノードによって構成された一の論理的な音楽システム（例えば、商標「mLAN」で呼ばれる当出願人に係る音楽システム）に従う各ノード相互間で送受できるようにしている。これに関連するものとして、例えば下記に示す特許文献１に記載の技術などがある。
【特許文献１】特許第3271493号公報
【０００３】
ここで、IEEE1394インタフェースを用いた音楽ネットワークシステム（音楽LAN）について、図７を参照しながら説明する。図７は、従来知られた音楽ネットワークシステムの一実施例を示すシステムブロック図である。この図７に示す音楽ネットワークシステムは、IEEE1394インタフェースを装備した５台のノードＡ〜Ｅが、IEEE1394ケーブルＣによりツリー状に接続されたネットワークの接続構成（トポロジーと呼ぶ）となっている。IEEE1394インタフェースはIEEE1394規格に準拠してデータ通信を行うハードウェア及びソフトウェアで構成されるインタフェースであり、各ノード同士を物理的に接続しているIEEE1394ケーブルＣを介して実際に音楽データの送受信動作を行う。ネットワーク接続される前記ノードとしては、パーソナルコンピュータ、ミュージックシンセサイザのような電子楽器、シーケンサのような自動演奏装置、レコーダのような波形記録装置、ミキサやエフェクタのような信号処理装置、音源装置等、任意の制御機器や音楽関連機器が相当する。
【０００４】
従来知られているように、全てのノードがIEEE1394ケーブルＣでツリー接続されている上記した音楽ネットワークシステムにおいては、任意のノード同士がIEEE1394ケーブルで直接接続されていなくても、ユーザにより設定されたバス上に構築される論理的なパス（これを仮想接続と呼ぶ）により接続されていれば任意のノード間での音楽データの送受が可能となる。すなわち、各ノードが有するMIDIin/outやAUDIOin/out等の物理端子を用いて任意のノード同士を物理的に直接接続していなくても仮想接続されていれば、あたかも各ノード同士を物理的に直接接続したのと同様にして特定ノード間で音楽データを送受することができるようになる。例えば図７に示すように、ノードＡ（Ｎａ）は、ノードＢ（Ｎｂ）、ノードＣ（Ｎｃ）、ノードＤ（Ｎｄ）のいずれのノードともIEEE1394ケーブルＣで直接接続されていないにもかかわらず、図中において矢印で示す仮想接続線ＶＣにより任意のノード同士を繋ぐように予めバス上に論理的なパスを構築するよう設定しておくだけで、ユーザはIEEE1394ケーブルＣによる物理的な接続を意識することなく、例えばノードＡ（Ｎａ）からノードＢ（Ｎｂ）、ノードＣ（Ｎｃ）、ノードＤ（Ｎｄ）のいずれのノードに対しても音楽データを送信させることができるようになる。
【０００５】
IEEE1394シリアルバス（以下、単にバスと呼ぶ）を用いた上記音楽ネットワークシステムでは、例えば１２５μｓ（マイクロ秒）の周期で通信サイクルが設定されており、アイソクロナス・チャンネルを確保しているノードはこの通信サイクル毎に１回だけ確保した帯域分のパケット化した音楽データ（アイソクロナスパケット）を転送することができる。図８にIEEE1394シリアルバスを用いた音楽ネットワークシステムにおける通信サイクルの一例を示す。バスにおける通信サイクルの管理は、ネットワークのルートとなり通信システム全体を管理するよう割り当てられたノード（以下、これをルートノードと呼ぶ）がバス上にサイクルスタートパケットを送出することにより開始される。このルートノードはバスにリセットがかかった際に、IEEE1394の仕様書に規定する手法によってネットワークに接続されたノードの中からいずれかのノードが自動的に割り当てられる。図８において、バスにサイクルスタートパケットが送出された所定時間経過後に、ノードがサイクルスタートパケットを受信すると、所定の時間（所謂アイソクロナスギャップ）だけ待機してから、ルートノードに対してバスの使用要求を行う。複数のノードがバスの使用要求を行ったときは、ルートノードは最も早くバスの使用要求をしてきたノードに対してのみにバスの使用を許可する。こうした処理に係る時間が、図８に示すアービトレーションタイム（Arbitration time）である。
【０００６】
ルートノードからバスの使用許可を得られたノードでは、バスに上記アイソクロナスパケット（Isochronous packet）を送出してデータ送信を開始する。このとき、アイソクロナスパケットの前後には、それぞれデータプリフィクス（data prefix）とデータエンド（data end）が付加される。一方、バスの使用許可が得られなかったノードでは、バスの使用許可を得たノードがアイソクロナスパケットを送出してから、伝搬遅延時間（Propagation delay）以内に受信が完了し、データエンド完了から所定のアイソクロナスギャップ（Isochronous gap）を待って再びルートノードに対してバスの使用要求を行う。そして、バスの使用許可が得られたら、バスに新たなアイソクロナスパケット（図示せず）を送出する。上記伝搬遅延時間（Propagation delay）は、あるノードから通信システム内で最も離れているノードまでの間をパケットが伝搬するのに必要な時間に応じて決まるものである。従来においては上記伝搬遅延時間（Propagation delay）として、通信システム内で最も離れた２つのノード間で必要な時間を一律に使用している。また、アービトレーションタイム（Arbitration time）は、各ノードとルートノードとの間の経路の長さに応じて決まるものであり、各ノード毎に独自の値となる。そして、アイソクロナスギャップ（Isochronous gap）、データプリフィックス（data prefix）、データエンド（data end）はIEEE1394の仕様書に規定されている固定値である。したがって、図８に示すように、１個のアイソクロナスパケットの伝送には最大で（最も離れたノード間を伝わるまでに）アイソクロナスギャップから伝搬遅延時間までの時間帯域が必要となる。この明細書では、こうした時間帯域をバスの使用帯域幅と呼ぶ。また、バスの使用帯域幅のうち、アイソクロナスパケット以外の分、つまりアイソクロナスギャップ、データプリフィックス、データエンド、アービトレーションタイム、及び伝搬遅延時間のトータルを「オーバーヘッド」と呼び、このオーバーヘッドはネットワークの接続構成（トポロジー）によって変わるものである。
【０００７】
上記した音楽ネットワークシステムにおいて、バスにアイソクロナスパケットを送出しようとするノードは、データ送信のために使用する使用チャンネル（つまりアイソクロナス・チャンネル）やデータ送信に必要なだけのバスの使用帯域幅などのリソースをまず確保する必要がある。そのため、データ送信に先立ち、バスのチャンネルとIEEE1394バス帯域を一元管理する機器である所謂アイソクロナスリソースマネージャーノードに対して、確保すべき使用チャンネル（アイソクロナス・チャンネル）やバスの使用帯域幅などのリソースを申請し、これらの使用許可をもらってはじめてネットワークを介してのデータ送信を開始することができる。そこで、従来においてはデータ送信に先立ち申請するバスの使用帯域幅として、最も離れた２つのノード間で必要とされるオーバーヘッド（既定値）に基づくバスの使用帯域幅を申請して確保するようにしていた。しかし、現状のネットワークの接続構成が想定されているネットワークの接続構成とはかけ離れた構成である場合には、上記したような想定されているネットワークの接続構成に従う既定のオーバーヘッドに基づくバスの使用帯域幅を用いると余分なマージンを確保することから帯域に無駄が生じて、その分だけバス全体におけるデータ転送量が少なくなってしまうこととなりデータ転送の効率が悪くなる、という問題点があった。
【発明の開示】
【発明が解決しようとする課題】
【０００８】
本発明は上述の点に鑑みてなされたもので、データ送信に先立って確保するバスの使用帯域幅を現状のネットワークの接続構成に応じて最適化することのできるようにした音楽ネットワークシステムに用いる電子音楽装置及びプログラムを提供することを目的とする。
【課題を解決するための手段】
【０００９】
本発明の請求項１に係る電子音楽装置は、所定のバスにより接続されて１つのネットワークを構成する複数の機器に対し、前記バス上に構築される論理的なパスに従いデータを送信する電子音楽装置であって、前記所定のバスにより接続されている各機器間の接続構成を取得する取得手段と、前記取得した各機器間の接続構成に応じて、前記バスを介したデータ送信に必要なバスの使用帯域幅を算出する算出手段と、前記算出したバスの使用帯域幅の確保に応じて、少なくともネットワークを構成している複数の機器のいずれかに対して予め構築済みの論理的なパスに従いデータを送信する送信手段とを具備する。
【００１０】
本発明によると、所定のバスにより接続されて１つのネットワークを構成する複数の機器における各機器間の接続構成を取得し、該取得した各機器間の接続構成に応じて算出した前記バスを介したデータ送信に必要なバスの使用帯域幅を確保して、少なくともネットワークを構成している複数の機器のいずれかに対して予め構築済みの論理的なパスに従いデータを送信する。このようにして、データ送信に先立って申請するバスの使用帯域幅を現状のネットワークの接続構成に応じて最適化するようにしたことから、前記バスの使用帯域幅に従来含まれていた余計なマージン分を減らすことができる。こうすることで、バス全体における実質的なデータ転送量を増やすことができ、効率的にデータ転送を行うことができるようになる。
【００１１】
本発明は装置の発明として構成し実施することができるのみならず、方法の発明として構成し実施することができる。また、本発明は、コンピュータまたはＤＳＰ等のプロセッサのプログラムの形態で実施することができるし、そのようなプログラムを記憶した記憶媒体の形態で実施することもできる。
【発明の効果】
【００１２】
この発明によれば、データ送信に先立って申請するバスの使用帯域幅を現状のネットワークの接続構成に応じて最適化するようにしたことから、バスの使用帯域幅に従来含まれていた余分のマージン分を減らすことができ、これに応じてバス全体における実質的なデータ転送量を増やすことができる、という効果を奏する。
【発明を実施するための最良の形態】
【００１３】
以下、この発明の実施の形態を添付図面に従って詳細に説明する。
【００１４】
まず、本発明に係る電子音楽装置の全体構成について、図１を用いて説明する。図１は、本発明に係る電子音楽装置の全体構成の一実施例を示すハード構成ブロック図である。
【００１５】
ここに示される電子音楽装置はコンピュータを用いて構成されており、そこにおいて、図示しないアイソクロナスリソースマネージャーノードに対してデータ送信のために必要とされる時間帯域（バスの使用帯域幅）や使用チャンネル（アイソクロナス・チャンネル）などのリソースを申請し、該リソースの確保に応じて音楽データ（詳しくはアイソクロナスパケット）の送信を開始することのできる機器である。本明細書では説明の便宜上、こうした音楽データを送信する機器を送信ノード、音楽データの送信先の機器を受信ノードと呼んで区別する。送信ノードにおいて音楽データの送信を開始する処理は、コンピュータが該処理を実現する所定の制御プログラム（後述する図２参照）を実行することにより実施される。勿論、こうした処理はコンピュータソフトウエアの形態に限らず、DSP（ディジタル・シグナル・プロセッサ）によって処理されるマイクロプログラムの形態でも実施可能であり、また、この種のプログラムの形態に限らず、ディスクリート回路又は集積回路若しくは大規模集積回路等を含んで構成された専用ハードウエア装置の形態で実施してもよい。なお、電子音楽装置はここに図示したものに限らず、図示した以外の構成要素を具えていてよい。
【００１６】
本実施例に示す電子音楽装置（送信ノード）は、マイクロプロセッサユニット（ＣＰＵ）１、リードオンリメモリ（ＲＯＭ）２、ランダムアクセスメモリ（ＲＡＭ）３からなるマイクロコンピュータによって制御される。ＣＰＵ１は、この電子音楽装置全体の動作を制御するものである。このＣＰＵ１に対して、データ及びアドレスバス１Ｄを介してＲＯＭ２、ＲＡＭ３、検出回路４、表示回路５、外部記憶装置６、IEEE1394インタフェース（Ｉ／Ｆ）７、各種インタフェース（Ｉ／Ｆ）８、不揮発メモリ９がそれぞれ接続されている。更に、ＣＰＵ１には、タイマ割込み処理（インタラプト処理）における割込み時間や各種時間を計時するタイマ１Ａが接続されている。例えば、タイマ１Ａはクロックパルスを発生し、発生したクロックパルスをＣＰＵ１に対して処理タイミング命令として与えたり、あるいはＣＰＵ１に対してインタラプト命令として与える。ＣＰＵ１は、これらの命令に従って各種処理を実行する。
【００１７】
ＲＯＭ２は、ＣＰＵ１により実行される各種プログラムや各種データを格納するものである。ＲＡＭ３は、ＣＰＵ１が所定のプログラムを実行する際に発生する各種データを一時的に記憶するワーキングメモリとして、あるいは現在実行中のプログラムやそれに関連するデータを記憶するメモリ等として使用される。ＲＡＭ３の所定のアドレス領域がそれぞれの機能に割り当てられ、レジスタやフラグ、テーブル、メモリなどとして利用される。操作子４Ａは、各種設定等を行うためのスイッチやボタン、数値データ入力用のテンキーや文字データ入力用のキーボード、あるいはディスプレイ５Ａに表示された所定のポインティングデバイスを操作するマウスなどの各種操作子である。例えば、後述するような自ノードから最も離れたノードまでのホップ数を指定するディップスイッチなどを含む（後述する図３参照）。勿論、これら以外にも各種操作子を含んでいてよい。検出回路４は、上記各操作子４Ａの操作状態を検出し、その操作状態に応じた情報をデータ及びアドレスバス１Ｄを介してＣＰＵ１に出力する。
【００１８】
表示回路５は例えば液晶表示パネル（ＬＣＤ）やＣＲＴ等から構成されるディスプレイ５Ａに、例えばバス上に構築される論理的なパス（仮想接続）を設定する画面（図示せず）などの各種画面を表示したり、あるいはＣＰＵ１の制御状態などを表示する。ユーザは該ディスプレイ５Ａに表示される各種画面を参照することにより、各種設定を容易に行うことができる。外部記憶装置６は、各種データやＣＰＵ１が実行する各種制御プログラムなどを記憶する。なお、上述したＲＯＭ２に制御プログラムが記憶されていない場合、この外部記憶装置６（例えばハードディスク）に制御プログラムを記憶させておき、それをＲＡＭ３に読み込むことにより、ＲＯＭ２に制御プログラムを記憶している場合と同様の動作をＣＰＵ１にさせることができる。このようにすると、制御プログラムの追加やバージョンアップ等が容易に行える。なお、外部記憶装置６はハードディスク（HD）に限られず、フレキシブルディスク（FD）、コンパクトディスク（CD‐ROM・CD‐RAM）、光磁気ディスク（MO）、あるいはDVD（Digital Versatile Disk）等の着脱自在な様々な形態の外部記憶媒体を利用する記憶装置であればどのようなものであってもよい。
【００１９】
IEEE1394インタフェース（Ｉ／Ｆ）７はIEEE1394規格に準拠してデータ通信を行うハードウェア及びソフトウェアで構成される高速通信インタフェース（IEEE1394シリアルバス）であって、このIEEE1394インタフェース７を介して物理的に接続している他のノードと実際に音楽データなどの各種情報の送受信動作を行うことができる。このIEEE1394インタフェース７を介してツリー接続された各ノードはネットワークＸを構成し、既に説明したように該ネットワークＸを構成するノード間では任意の特定ノード間で音楽データを送受するよう仮想接続を設定することができるようになっている（図７に示した仮想接続線ＶＣ参照）。
【００２０】
各種インタフェース８はIEEE1394インタフェース以外のMIDIインタフェースやオーディオインタフェースなど、他のノードと直接接続するためのインタフェースである。すなわち、MIDIインタフェース（又はオーディオインタフェース）は、外部接続された他の外部機器ＡＤからMIDIデータ（又はオーディオデータ）を当該ノードへ入力したり、あるいは当該ノードからMIDIデータ（又はオーディオデータ）を他の外部機器ＡＤへ出力するためのインタフェースである。外部機器ＡＤは、MIDIデータ又はオーディオデータを発生することが可能である機器であればどのような機器であってもよい。なお、各種インタフェース８は専用のインタフェースを用いるものに限らず、RS-232C等のシリアル・インタフェース、USB（ユニバーサル・シリアル・バス）等の、IEEE1394インタフェース以外の汎用インタフェースを用いて構成するようにしてよい。
【００２１】
不揮発メモリ９は、各ノードにおいて作成される「送信情報」などの各種情報を記憶する。この「送信情報」の内容は、ネットワークＸ上に新たなノードを追加接続する、あるいは各ノードにおける送信シーケンス数を変更するなど、ノードの増減や仮想接続の設定を変更したような場合に自動的に行われるバスの使用帯域幅の確保などにあわせて更新される。なお、この「送信情報」は従来知られているものであることから、その内容についてはここでの説明を省略する。
【００２２】
なお、本発明に係る電子音楽装置は、パーソナルコンピュータ、ミュージックシンセサイザのような電子楽器、シーケンサのような自動演奏装置、レコーダのような波形記録装置、ミキサやエフェクタのような信号処理装置、音源装置等、任意の製品応用形態をとっているものであってよい。
【００２３】
従来知られているように、上述した音楽ネットワークシステムにおいては、IEEE1394ケーブルを用いてネットワークに新たな電子音楽装置を接続する、又はネットワークからIEEE1394ケーブルにより既に接続済みの電子音楽装置を取り外すなどして当該音楽ネットワークシステムを構成するノードの数を増減させることができるだけでなく、各送信ノードのIEEE1394における１つのアイソクロナス転送に含まれる送信シーケンス数を変更する、あるいは任意の送信ノードに割り当てるバスの使用帯域幅を変更するなどの、各ノードの送信設定を変更することができる。こうした場合、既に説明したように、送信ノードにおいてはデータ送信に先立ち、データ送信用の使用チャンネル（アイソクロナス・チャンネル）とデータ送信に必要なだけのバスの使用帯域幅とをまず確保するために、バスのチャンネルとIEEE1394バス帯域を一元管理する機器である所謂アイソクロナスリソースマネージャーノードに対して、確保すべきバスの使用帯域幅や使用チャンネル（アイソクロナス・チャンネル）を申請する。そして、これらの使用許可をもらってはじめて、送信ノードはIEEE1394シリアルバスを介して任意の受信ノードに対してデータ送信を開始することができる。
【００２４】
そこで、各送信ノードで実行されるデータ送信開始のための処理について、図２を用いて説明する。図２は、各送信ノードで実行する「送信制御処理」の一実施例を示すフローチャートである。ただし、この処理を実行する送信ノードとしては、次の３つに分けられる。第一にバスリセット時においては音楽ネットワークシステムを構成する全ての送信ノード、第二に送信設定を変更された送信ノード、第三にデータ送信中止となった後に送信復旧が指示された送信ノード、のいずれかに分けられる。
【００２５】
ステップＳ１では、オーバーヘッドを求める「オーバーヘッド算出処理」を実行する。「オーバーヘッド算出処理」では、IEEE1394シリアルバスで接続されることにより構成された現状のネットワークの接続構成（トポロジー）に応じてオーバーヘッドを求める。このオーバーヘッドを求める処理としては、第１にユーザによるディップスイッチ等の操作により予め設定された内容に従いオーバーヘッドを求める処理方式、第２にネットワークを介して所定のノードから取得したIEEE1394規格に従うトポロジーマップを用いて自動的にオーバーヘッドを求める処理方式、第３に実際にPingパケットをネットワーク内に流すことによりオーバーヘッドを求める処理方式などがあり、これらの各処理方式に基づく「オーバーヘッド」の算出の詳細な説明については後述する（後述する図３、図４、図６参照）。ステップＳ２では、上記求めたオーバーヘッドに基づきバスの使用帯域幅を求める。つまり、求めたオーバーヘッドに送信対象データであるアイソクロナスパケット分を加算することにより、１つのアイソクロナスパケットをデータ送信するために必要なだけのバスの使用帯域幅を算出する（図８参照）。
【００２６】
ステップＳ３では、バスのチャンネルやIEEE1394バス帯域などのリソースを一元管理する機器であるアイソクロナスリソースマネージャノードに対してデータ送信に必要なリソース、ここでは前記求めたバスの使用帯域幅や使用チャンネル（アイソクロナス・チャンネル）などを確保するための申請を行う。ステップＳ４では、リソース獲得に成功したか否かを判定する。リソース獲得に成功した場合には（ステップＳ４のＹＥＳ）、データ送信開始の処理を実行する（ステップＳ５）。他方、リソース獲得に失敗した場合には（ステップＳ４のＮＯ）、データ送信が開始できなかった旨をユーザに伝えるなどのエラー処理を実行する（ステップＳ６）。すなわち、申請したバスの使用帯域幅がバス全体の帯域のうち未だ割り当てられていない分の帯域（残存帯域）を超えてしまう、あるいは申請した使用チャンネル（アイソクロナス・チャンネル）が既に割り当て済みでありチャンネル競合が生じるなどの理由により、データ送信のために必要なバスの使用帯域幅や使用チャンネル（アイソクロナス・チャンネル）を確保することができなかった送信ノードについては音楽データ送信を開始することができず、ぞの旨をユーザに対して示すためのエラー処理を実行する。
【００２７】
次に、上述した「送信制御処理」において実行する「オーバーヘッド算出処理」（図２のステップＳ１参照）について、上記したような３つの処理方式毎に図を分けてそれぞれ説明する。まず、ユーザによるディップスイッチ等の操作により予め設定された内容に従い「オーバーヘッド」を求める処理方式について、図３を用いて説明する。図３は、ユーザによるディップスイッチ等の操作により予め設定された内容に従いオーバーヘッドを求める「オーバーヘッド算出処理」の一実施例を示すフローチャートである。
【００２８】
ステップＳ１１では、自ノードから最も離れたノードまでのホップ数をディップスイッチの設定内容から、あるいは不揮発メモリから取得する。ここで、ホップ数とは、IEEE1394シリアルバスにより接続されている任意のノードと任意の他のノードとの間の経路にある標準ケーブルの本数に相当するバスの数である。例えば図７に示したネットワークにおいて、自ノードであるノードＡ（ＮＡ）から最も離れたノードＣ（ＮＣ）までのホップ数は「３」となる。このホップ数が大きいほど任意のノード間を多数の標準ケーブルで繋いでいることになるので、それだけ任意のノード間の通信距離は長くなる。この処理では、ユーザ自身が目視等により確認した現状のネットワークの接続構成（トポロジー）に応じて、自機からデータ送信先の受信ノードまでのホップ数をディップスイッチを操作することにより設定する。
【００２９】
ステップＳ１２では、オーバーヘッドを計算する。この実施例においては、オーバーヘッドのうち固定値であるアイソクロナスギャップ（Isochronous gap）、データプリフィックス（data prefix）、データエンド（data end）以外の、伝搬遅延時間（Propagation delay）を上記ホップ数から、アービトレーションタイム（Arbitration time）を所定のホップ数からそれぞれ求める。そして、求めた伝搬遅延時間及びアービトレーションタイムと、上記アイソクロナスギャップ、データプリフィックス、データエンドとを加算することにより「オーバーヘッド」を算出する。ここで、アービトレーションタイムを求めるときに参照されるホップ数は、予め特定されたバスにおける通信サイクルの管理を行うルートノードでIEEE1394の仕様書に規定する手法により自動的に決定されるものである。そのため、伝搬遅延時間を求める際に参照されるホップ数と異なり、ユーザ自身ではネットワーク上のどのノードがルートノードに決定されるかを予め把握することができないために、アービトレーションタイムを求めるときに参照されるホップ数についてはユーザ自身で設定することができない。したがって、ここでは前提として、ルートノードを自機から最も離れたノードとして、その間のホップ数をもとにしてアービトレーションタイムを求めるようにするとよい。以上のように、アービトレーションタイム及び伝搬遅延時間は送信ノードからのホップ数、つまりネットワークの接続構成に応じてその値が変わりうるものであって、これを厳密に現状のネットワークの接続構成（トポロジー）にあわせて調整するようにしたことにより、余分なマージンのないバスの使用帯域幅のみを申請することができるようになる。
【００３０】
なお、ここでは自機におけるディップスイッチ操作に応じた設定内容に従ってオーバーヘッドを求めるようにしたがこれに限らず、ネットワークにある自機以外の他のノードで設定された内容を自機の不揮発メモリ９に取り込んで、これを用いてオーバーヘッドを求めるようにしてもよい。
【００３１】
次に、ネットワークからIEEE1394規格に従うトポロジーマップを取得し、これを用いて自動的に「オーバーヘッド」を求める処理方式について、図４を用いて説明する。図４は、ネットワークから取得したIEEE1394規格に従うトポロジーマップを用いて自動的にオーバーヘッドを求める「オーバーヘッド算出処理」の一実施例を示すフローチャートである。
【００３２】
ステップＳ２１では、音楽ネットワークシステム（音楽LAN）上のバスマネジャーノードを探す。このバスマネジャーノードのノードＩＤは、アイソクロナスリソースマネージャーノードから取得することができる。また、アイソクロナスリソースマネジャーノードのノードＩＤは、自機のＬＡＮにおけるプロトコル階層の物理層から取得することができる。したがって、自機からアイソクロナスリソースマネジャーノードを介して、バスマネジャーノードを特定することができる。ステップＳ２２では、バスマネジャーノードからトポロジーマップを取得する。ここで、バスマネジャーノードから取得するトポロジーマップについて、図５を用いて簡単に説明する。図５は、トポロジーマップを説明するための概念図である。ただし、ここでは図７に示した接続構成である音楽ネットワークシステムの場合におけるトポロジーマップを例に示した。
【００３３】
トポロジーマップはバスリセット時の初期化の際に、現状のネットワークにおける各ノード間の接続を解析することに応じて、バスマネージャノード上に作成される。すなわち、バスマネージャノードではネットワークを構成する各ノードから、ノードＩＤとそのノードが有するポート（物理端子）の状態を取得して、図５に示すようなトポロジーマップを作成する。ただし、バスマネージャノード上に、図５に示すようなデータ構造のトポロジーマップを実際に作成するわけではない。トポロジーマップでは各ノード（ノードＩＤ）毎にその有するポート（物理端子）の状態を示しており、マップ全体として各ノード間の接続構成（ネットワークの接続構造）が分かるようになっている。例えば、図７に示すように、ツリー最下位に位置するノードＩＤが「０」であるノードＡ（ＮＡ）ではその有するポートのうち、第１ポート（Port1）のみがその上位に位置する親となるノードＩＤが「４」であるノードＥ（ＮＥ）に繋がっている。また、ノードＥ（ＮＥ）ではその有するポートのうち、第１ポート（Port1）は子となる前記ノードＡ（ＮＡ）と、第２ポート（Port2）はその下位に位置する子となるノードＩＤが「３」であるノードＤ（ＮＤ）に繋がっている。このような場合、トポロジーマップでは、ノードＩＤ「０」（つまりノードＡ）の第１ポート（Port1）に「親（ここではノードＥ）と繋がっている」、第２ポート（Port2）及び第３ポート（Port3）に「繋がっていない」と示される。また、ノードＩＤ「４」（つまりノードＥ）の第１ポート（Port1）に「子（ここではノードＡ）と繋がっている」、第２ポート（Port2）に「子（ここではノードＤ）と繋がっている」、第３ポート（Port3）に「ポートが無い」と示される。同様にして、ノードＩＤ「１」（つまりノードＢ）、ノードＩＤ「２」（つまりノードＣ）、ノードＩＤ「３」（つまりノードＤ）の各ノードについても、各ポートの状態が示される。こうした各ノード毎の各ポート状態の組み合わせから、各ノード間の接続構成を把握することができる。
【００３４】
図４のフローチャートの説明に戻って、ステップＳ２３では、取得した上記トポロジーマップ（つまり各ノード間の接続構成）に従い、自機からルートノードまでのホップ数と、現状のネットワークにおける自機から最も離れたノードまでのホップ数を求める。ステップＳ２４では、上記求めた各ホップ数に基づきオーバーヘッドを計算する。すなわち、ネットワークの接続構成により変化するアービトレーションタイム及び伝搬遅延時間をホップ数から求め、これに固定値であるアイソクロナスギャップ、データプリフィックス、データエンドを加算して「オーバーヘッド」を算出する。ただし、この処理では、各ノード間が全て標準ケーブル（つまり長さやデータ伝送量が同一のケーブル）で繋がれているものとして求めたアービトレーションタイム及び伝搬遅延時間を用いて「オーバーヘッド」を算出する。
【００３５】
次に、実際にPingパケットをネットワーク内に流すことにより「オーバーヘッド」を求める処理方式について、図６を用いて説明する。図６は、実際にPingパケットをネットワーク内に流すことによりオーバヘッドを求める「オーバーヘッド算出処理」の一実施例を示すフローチャートである。一般的に音楽ネットワークシステム（音楽LAN）上で標準でないケーブルでネットワークが構成されている場合、ホップ数に基づく計算からでは伝搬遅延時間及びアービトレーションタイムを正しく算出することができない。そこで、こうしたことを避けるために、この処理ではPingパケットを送信先の受信ノードに対して送ることで実際にかかる伝搬遅延時間を測定し、同様にPingパケットをルートノードに対して送ることで実際にかかるアービトレーションタイムを測定する。
【００３６】
ステップＳ３１では、音楽ネットワークシステム（音楽LAN）上におけるバスマネジャーノードを探す。ステップＳ３２では、バスマネジャーノードからトポロジーマップを取得する。ステップＳ３３では、トポロジーマップから各リーフノード（ツリー状に接続されたネットワーク接続構成において、１つの機器としかつながっていない末端に位置する機器）のノードＩＤを求める。ステップＳ３４では、各リーフノードに向けてPingパケットを送る。ステップＳ３５では、各リーフノードからのPingパケットの返答を待つ。ここでPingパケットはネットワークの速度や状態を確認するためのものであり、宛先となるノードＩＤを含む。各リーフノードに対してPingパケットが送られると、その宛先となっているノードはPingパケットの発信元であるノードに対して返答を返す。ステップＳ３６では、Pingパケット送信時刻と返答時刻との時間差から最も時間がかかったノードを最も離れたノードとし、前記時間差に基づき伝播遅延時間（Propagation delay）を求める。このようなPingパケットを用いる方法は、標準でないケーブルを用いてネットワークが構成されている場合に有効である。
【００３７】
ステップＳ３７では、トポロジーマップからルートノードのノードＩＤを求める。ステップＳ３８では、ルートノードに向けてPingパケットを送る。ステップＳ３９では、Pingパケットの返答を待つ。ステップＳ４０では、Pingパケット送信時刻と返答時刻の時間差からルートノードとのアービトレーションタイム（Arbitration time）を求める。ステップＳ４１では、上記求めた伝播遅延時間とアービトレーションタイムに基づきオーバーヘッドを算出する。
【００３８】
以上のようにして、現状のネットワークの接続構成（トポロジー）に従ってアービトレーションタイム及び伝搬遅延時間を調整し、現状のネットワークの接続構成（トポロジー）に対応させた余分なマージンの少ないバスの使用帯域幅のみをデータ送信に先立って確保するようにした。こうすると、バス全体における実質的なデータ転送量を増やすことができることから、効率的にデータ転送を行うことができるようになる。
【００３９】
なお、ルートノードとアイソクロナスマネージャーノードとは同じ機器であってよい。
なお、上述した実施例においては音楽ネットワークシステムとしてオーディオやMIDIなどの音楽データをストリームデータとして送受するシステムを例に挙げたがこれに限らず、動画データ等をストリームデータとして送受する音楽ネットワークシステムであってもよい。
なお、各送信ノードにおけるバスの使用帯域幅を変更する変更契機としては、IEEE1394において１つのアイソクロナス転送に含まれる送信シーケンス数を変更することに限らず、１つの送信ノードが送信するアイソクロナス転送の数を変更することもバスの使用帯域幅の変更契機に該当する。例えば、オーディオをステレオで送信していた状態からモノラルの送信に変更することが挙げられる。また、デジタルオーディオデータを送信する際のサンプリングレート変更に応じて送信するデータ量が変わることも、バスの使用帯域幅の変更契機に含まれる。
【図面の簡単な説明】
【００４０】
【図１】本発明に係る電子音楽装置の全体構成の一実施例を示すハード構成ブロック図である。
【図２】各送信ノードで実行する送信制御処理の一実施例を示すフローチャートである。
【図３】ユーザにより予め設定された内容に従いオーバーヘッドを求める「オーバーヘッド算出処理」の一実施例を示すフローチャートである。
【図４】トポロジーマップを用いて自動的にオーバーヘッドを求める「オーバーヘッド算出処理」の一実施例を示すフローチャートである。
【図５】トポロジーマップを説明するための概念図である。
【図６】Pingパケットをネットワーク内に流すことによりオーバヘッドを求める「オーバーヘッド算出処理」の一実施例を示すフローチャートである。
【図７】従来知られた音楽ネットワークシステムの一実施例を示すシステムブロック図である。
【図８】IEEE1394シリアルバスを用いた音楽ネットワークシステムにおける通信サイクルの一例を示すタイムチャートである。
【符号の説明】
【００４１】
１…ＣＰＵ、２…ＲＯＭ、３…ＲＡＭ、４…検出回路、４Ａ…操作子、５…表示回路、５Ａ…ディスプレイ、６…外部記憶装置、７…IEEE1394インタフェース、８…各種インタフェース、９…不揮発メモリ、１Ｄ…通信バス（データ及びアドレスバス）、Ｘ…ネットワーク、ＡＤ…外部機器、ＮＡ（ＮＢ、ＮＣ、ＮＤ、ＮＥ）…ノード、ＶＣ…仮想接続線
【特許請求の範囲】
【請求項１】
所定のバスにより接続されて１つのネットワークを構成する複数の機器に対し、前記バス上に構築される論理的なパスに従いデータを送信する電子音楽装置であって、
前記所定のバスにより接続されている各機器間の接続構成を取得する取得手段と、
前記取得した各機器間の接続構成に応じて、前記バスを介したデータ送信に必要なバスの使用帯域幅を算出する算出手段と、
前記算出したバスの使用帯域幅の確保に応じて、少なくともネットワークを構成している複数の機器のいずれかに対して予め構築済みの論理的なパスに従いデータを送信する送信手段と
を具備した電子音楽装置。
【請求項２】
前記算出手段は、前記取得した各機器間の接続構成に従い自機から最も離れた機器まで、又は／及び自機から予め特定された通信サイクルを管理する機器までデータ送信をする際に経由される機器或いはケーブルの数を求め、該求めた機器或いはケーブルの数に基づき前記バスを介したデータ送信に必要なバスの使用帯域幅を算出することを特徴とする請求項１に記載の電子音楽装置。
【請求項３】
前記算出手段は、前記取得した各機器間の接続構成に従い自機から、１つの機器としかつながっていない機器に対して、又は／及び予め特定された通信サイクルを管理する機器に対して所定のパケットを送信し、前記パケット送信から該パケット送信に応じた応答を受信するまでの時間を計測し、自機から最も離れた機器又は／及び自機から通信サイクルを管理する機器までにかかる時間に基づき前記バスを介したデータ送信に必要なバスの使用帯域幅を算出することを特徴とする請求項１に記載の電子音楽装置。
【請求項４】
ユーザ操作に応じて、前記所定のバスにより接続された自機から最も離れた機器までの各機器間又は最も離れている２つの機器間でデータ送信する際に経由される機器或いはケーブルの数を設定する設定手段を有してなり、
前記取得手段は、前記設定された機器或いはケーブルの数を各機器間の接続構成として取得することを特徴とする請求項１に記載の電子音楽装置。
【請求項５】
コンピュータに、
所定のバスにより接続されて１つのネットワークを構成している複数の機器間の接続構成を取得する手順と、
前記取得した各機器間の接続構成に応じて、前記バスを介したデータ送信に必要なバスの使用帯域幅を算出する手順と、
前記算出したバスの使用帯域幅の確保に応じて、少なくともネットワークを構成している複数の機器のいずれかに対して予め構築済みの論理的なパスに従いデータを送信する手順と
を実行させるためのプログラム。
【請求項１】
所定のバスにより接続されて１つのネットワークを構成する複数の機器に対し、前記バス上に構築される論理的なパスに従いデータを送信する電子音楽装置であって、
前記所定のバスにより接続されている各機器間の接続構成を取得する取得手段と、
前記取得した各機器間の接続構成に応じて、前記バスを介したデータ送信に必要なバスの使用帯域幅を算出する算出手段と、
前記算出したバスの使用帯域幅の確保に応じて、少なくともネットワークを構成している複数の機器のいずれかに対して予め構築済みの論理的なパスに従いデータを送信する送信手段と
を具備した電子音楽装置。
【請求項２】
前記算出手段は、前記取得した各機器間の接続構成に従い自機から最も離れた機器まで、又は／及び自機から予め特定された通信サイクルを管理する機器までデータ送信をする際に経由される機器或いはケーブルの数を求め、該求めた機器或いはケーブルの数に基づき前記バスを介したデータ送信に必要なバスの使用帯域幅を算出することを特徴とする請求項１に記載の電子音楽装置。
【請求項３】
前記算出手段は、前記取得した各機器間の接続構成に従い自機から、１つの機器としかつながっていない機器に対して、又は／及び予め特定された通信サイクルを管理する機器に対して所定のパケットを送信し、前記パケット送信から該パケット送信に応じた応答を受信するまでの時間を計測し、自機から最も離れた機器又は／及び自機から通信サイクルを管理する機器までにかかる時間に基づき前記バスを介したデータ送信に必要なバスの使用帯域幅を算出することを特徴とする請求項１に記載の電子音楽装置。
【請求項４】
ユーザ操作に応じて、前記所定のバスにより接続された自機から最も離れた機器までの各機器間又は最も離れている２つの機器間でデータ送信する際に経由される機器或いはケーブルの数を設定する設定手段を有してなり、
前記取得手段は、前記設定された機器或いはケーブルの数を各機器間の接続構成として取得することを特徴とする請求項１に記載の電子音楽装置。
【請求項５】
コンピュータに、
所定のバスにより接続されて１つのネットワークを構成している複数の機器間の接続構成を取得する手順と、
前記取得した各機器間の接続構成に応じて、前記バスを介したデータ送信に必要なバスの使用帯域幅を算出する手順と、
前記算出したバスの使用帯域幅の確保に応じて、少なくともネットワークを構成している複数の機器のいずれかに対して予め構築済みの論理的なパスに従いデータを送信する手順と
を実行させるためのプログラム。
【図１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【公開番号】特開２００６−２７０７１５（Ｐ２００６−２７０７１５Ａ）
【公開日】平成１８年１０月５日（２００６．１０．５）
【国際特許分類】
【出願番号】特願２００５−８８０２２（Ｐ２００５−８８０２２）
【出願日】平成１７年３月２５日（２００５．３．２５）
【出願人】（０００００４０７５）ヤマハ株式会社 (5,930)
【Ｆターム（参考）】
【公開日】平成１８年１０月５日（２００６．１０．５）
【国際特許分類】
【出願日】平成１７年３月２５日（２００５．３．２５）
【出願人】（０００００４０７５）ヤマハ株式会社 (5,930)
【Ｆターム（参考）】
[ Back to top ]