電子楽器用バスシステム
【課題】 電子楽器を構成する複数種類のデバイスの間で行う通信を、バスを通じて行う。
【解決手段】 メインコントローラデバイス１０が鍵盤デバイス１４と通信を行う場合は、標準プロトコルで通信が行われる。この場合、メインコントローラデバイス１０がマスターとなって、スレーブアドレスである鍵盤デバイス１４に固有のアドレスを送信先アドレスとし、メインコントローラデバイス１０の標準プロトコル用のアドレスを送信元アドレスとしてヘッダ部を構成し、データ部と共にＥバス１１上に送信する。鍵盤デバイス１４は、送信先アドレスが自機のアドレスと一致することから、その後に続く送信元アドレスおよびデータ部を受信する。
【解決手段】 メインコントローラデバイス１０が鍵盤デバイス１４と通信を行う場合は、標準プロトコルで通信が行われる。この場合、メインコントローラデバイス１０がマスターとなって、スレーブアドレスである鍵盤デバイス１４に固有のアドレスを送信先アドレスとし、メインコントローラデバイス１０の標準プロトコル用のアドレスを送信元アドレスとしてヘッダ部を構成し、データ部と共にＥバス１１上に送信する。鍵盤デバイス１４は、送信先アドレスが自機のアドレスと一致することから、その後に続く送信元アドレスおよびデータ部を受信する。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、電子楽器に内蔵されるに適している電子楽器用バスシステムに関する。
【背景技術】
【０００２】
従来の電子楽器において、１つのＣＰＵ（Central Processing Unit）だけを有している電子楽器においては、鍵盤における各鍵の操作を検出する鍵盤スイッチや音色設定等の各種設定を行うパネルスイッチ等のパネル操作子は、パラレルＩ／Ｏ（Input-output）に接続されている。そして、パラレルＩ／Ｏを介して鍵盤スイッチやパネル操作子の操作情報をＣＰＵが取り込んで、取り込まれた操作情報に基づく音源パラメータを生成し、発音タイミングに対応させてその音源パラメータを音源に転送することにより発音するようにしている。
【０００３】
また、従来の電子楽器において、複数のＣＰＵを備えている電子楽器も知られている。このように複数のＣＰＵを備えている電子楽器においては、複数のＣＰＵで機能を分担するようにしている。例えば、鍵盤ＣＰＵは、鍵盤スイッチのスキャンを行い各鍵の操作情報を検出して出力するようにしており、パネルＣＰＵは、パネル操作子のスキャンを行い各パネル操作子の操作情報を検出して出力したり、パネル表示器の表示制御等を行っている。また、メインＣＰＵは、鍵盤ＣＰＵから鍵盤の操作信号を、パネルＣＰＵからパネル操作子の操作情報を受けて、操作情報に基づく音源パラメータを生成し、発音タイミングに対応させてその音源パラメータを音源に転送することにより発音するようにしている。この場合、メインＣＰＵは、鍵盤ＣＰＵおよびパネルＣＰＵとそれぞれ独立してシリアル通信路により接続されており、このシリアル通信路を介して相互に通信を行っている。
【発明の概要】
【発明が解決しようとする課題】
【０００４】
従来のＣＰＵを１つだけ備える電子楽器においては、製品毎に機能や形状が異なることから電子楽器に内蔵される基板をその都度設計して搭載しなければならず、既に開発された製品や他の製品に搭載した基板を流用することができないという問題点があった。
【０００５】
また、従来の複数のＣＰＵを備える電子楽器においては、各製品毎にメインＣＰＵと鍵盤ＣＰＵとの通信仕様、および、メインＣＰＵとパネルＣＰＵとの通信仕様を決定するようにしていたため、既に開発された製品や他の製品に搭載した各種基板間においては相互に接続することができない場合があり、それらの基板を流用することができないという問題点があった。さらに、例えば複数の鍵盤が必要とされる場合は、鍵盤ＣＰＵを搭載した新たな鍵盤基板をメインＣＰＵが搭載されたメイン基板に接続しなければならない。すると、新たな接続ハードウェアをメイン基板に追加しなければならず、メイン基板を開発し直さなければならないという問題点があった。
【０００６】
そこで、本発明は、電子楽器を構成する複数種類のデバイスの間で行う通信を、バスにデバイスを接続することでバスを通じて通信を行うことのできる電子楽器用バスシステムを提供することを目的としている。
【課題を解決するための手段】
【０００７】
上記目的を達成するために、本発明は、双方向シリアルバスに接続されているホストデバイスと、操作入力デバイスと、ＭＩＤＩデバイスとを接続して電子楽器を構成することを最も主要な特徴としている。
【発明の効果】
【０００８】
このような発明によれば、ホストデバイスが接続されているバスに、鍵盤やパネルの操作入力デバイスや、ＭＩＤＩデバイスを任意に接続して電子楽器を構成することができるようになる。
【図面の簡単な説明】
【０００９】
【図１】本発明の電子楽器用バスシステムが適用されている電子楽器の実施例におけるハードウェア構成を示すブロック図である。
【図２】本発明の実施例にかかる電子楽器用バスシステムの結線の概要を示す構成図である。
【図３】本発明の実施例にかかるＥバスシステムの具体的構成を示す図である。
【図４】本発明の実施例にかかるＥバスシステムにおけるＳＣＬラインとＳＤＡラインにおけるデータ転送時の波形タイミング図を示す図である。
【図５】本発明の実施例にかかるＥバスシステムにおけるカテゴリーＩＤ、サブアドレス範囲、カテゴリー名および適応される通信プロトコルを示すテーブルである。
【図６】本発明の実施例にかかるＥバスシステムにおけるデータフォーマットを示す図である。
【図７】本発明の実施例にかかるＥバスシステムにおける共通プロトコルのホスト送信およびホスト受信のコマンドを示す図表である。
【図８】本発明の実施例にかかるＥバスシステムにおける標準プロトコルのホスト送信およびホスト受信のコマンドを示す図表である。
【図９】本発明の実施例にかかるＥバスシステムにおけるＭＩＤＩプロトコルのホスト送受信のコマンドを示す図表である。
【図１０】本発明の実施例にかかるＥバスシステムにおけるＥバス起動手順を示すフローチャートである。
【図１１】本発明の実施例にかかるＥバスシステムにおけるホスト受信処理のフローチャートである。
【図１２】本発明の実施例にかかるＥバスシステムにおけるホスト送信処理のフローチャートである。
【図１３】本発明の実施例にかかるＥバスシステムにおける鍵盤送信／受信処理のフローチャートである。
【図１４】本発明の実施例にかかるＥバスシステムにおけるＭＩＤＩ送信／受信処理のフローチャートである。
【発明を実施するための形態】
【００１０】
本発明の電子楽器用バスシステムが適用されている電子楽器における実施例のハードウェア構成をブロック図で図１に示し、本発明の電子楽器用バスシステムの結線の概要を図２に示す。
本発明の電子楽器用バスシステムは、図１に示す電子楽器１に内蔵されているＥバス１１からなるＥバスシステム、および図２に示すＥバス１１からなるＥバスシステムとして示されている。このＥバスシステムにおけるＥバス１１には、メインＣＰＵ（Central Processing Unit）やメインＲＯＭ（Read Only Memory）、メインＲＡＭ（Random Access Memory）等が搭載されているメイン基板１０ａを備えるメインコントローラデバイス１０（ホストデバイス）と、パネルＣＰＵやパネルＲＯＭ、パネルＲＡＭ等が搭載されているパネル基板１２ａ、１３ａをそれぞれ備えるパネルデバイス１２，１３と、鍵盤ＣＰＵや鍵盤ＲＯＭ、鍵盤ＲＡＭ等が搭載されている鍵盤基板１４ａ、１５ａをそれぞれ備える鍵盤デバイス１４，１５と、ＭＩＤＩＣＰＵやＭＩＤＩＲＯＭ、ＭＩＤＩＲＡＭ等が搭載されているＭＩＤＩ基板１６ａを備えるＭＩＤＩデバイス１６とが接続されている。
【００１１】
メインコントローラデバイス１０は、電子楽器１の全体の動作を制御することにより、鍵盤デバイス１４，１５やパネルデバイス１２，１３から取り込んだ鍵盤スイッチやパネル操作子の操作情報に基づく楽音を発生するための制御処理や、ＭＩＤＩデバイス１６から受信したＭＩＤＩ（Musical Instrument Digital Interface）メッセージに応じた楽音を発生するための制御処理を行っている。また、メインコントローラデバイス１０におけるメイン基板１０ａに搭載されているメインＲＯＭには、メインＣＰＵが実行する制御プログラムや、音色データ、伴奏パターン、楽曲データ等のプリセットデータが格納されている。さらに、メイン基板１０ａに搭載されているＲＡＭには、メインＣＰＵが制御プログラム等を実行する際に使用するワーキングメモリ領域、音色データや伴奏パターン等のユーザ領域等が設定される。
【００１２】
また、パネルデバイス１２，１３には、音色設定やエフェクト設定用のパネルスイッチや、ボリュームやホイール等のコンティニュアスコントローラ、ＪＯＧコントローラ等のパネル操作子が設けられており、音色の選択や音色パラメータを変更することができるようにされている。パネルＣＰＵは、パネルデバイス１２，１３に設けられているパネル操作子をスキャンしてその操作イベントや操作量を検出している。この場合、パネル操作子によっては操作量を相対値で検出するようにする。パネルデバイス１２，１３におけるパネル基板１２ａ、１３ａにそれぞれ搭載されているパネルＲＯＭには、パネルＣＰＵが実行するスキャンプログラム等が格納されている。さらに、パネル基板１２ａ、１３ａにそれぞれ搭載されているパネルＲＡＭには、パネルＣＰＵがスキャンプログラム等を実行する際に使用するワーキングメモリ領域等の領域が設定される。
【００１３】
さらにまた、鍵盤デバイス１４，１５には、複数の鍵と各鍵の操作に応じてオン／オフする鍵盤スイッチが設けられている。鍵盤ＣＰＵは、鍵盤デバイス１４，１５に設けられている鍵盤スイッチをスキャンして、ノートオン／ノートオフのキーイベントやベロシティおよびアフタータッチの値を検出している。鍵盤デバイス１４，１５における鍵盤基板１４ａ、１５ａにそれぞれ搭載されている鍵盤ＲＯＭには、鍵盤ＣＰＵが実行するスキャンプログラム等が格納されている。さらに、鍵盤基板１４ａ、１５ａにそれぞれ搭載されている鍵盤ＲＡＭには、鍵盤ＣＰＵがスキャンプログラム等を実行する際に使用するワーキングメモリ領域等が設定される。
【００１４】
さらにまた、ＭＩＤＩデバイス１６は、ＭＩＤＩ端子やTo Host端子を備えたＭＩＤＩ入出力デバイス、自動演奏が可能なＭＩＤＩシーケンスデバイス、ＭＩＤＩ鍵盤等のＭＩＤＩ対応のデバイスであり、ホストコンピュータに接続するためのTo Host端子を備えることができる。Ｅバスシステムにおいては、ＭＩＤＩデバイス１６は、演奏データや演奏関連データをＭＩＤＩのフォーマットのままで送受信することができるようにされている。ＭＩＤＩＣＰＵは、ＭＩＤＩデバイス１６の動作を制御しており、ＭＩＤＩデバイス１６におけるＭＩＤＩ基板１６ａに搭載されているＭＩＤＩＲＯＭには、ＭＩＤＩＣＰＵが実行するＭＩＤＩ制御プログラムやＭＩＤＩ制御データが格納されている。さらに、ＭＩＤＩ基板１６ａに搭載されているＭＩＤＩＲＡＭには、ＭＩＤＩＣＰＵがＭＩＤＩ制御プログラム等を実行する際に使用するワーキングメモリ領域等が設定される。なお、ＭＩＤＩデバイス１６にTo Host端子を設けると、電子楽器１をTo Host端子付きモデルとすることができる。
【００１５】
図１および図２に示す電子楽器１において、メインコントローラデバイス１０は、メインコントローラデバイス１０とパネルデバイス１２，１３、鍵盤デバイス１４，１５およびＭＩＤＩデバイス１６との間を接続しているＥバス１１を介して、演奏イベントデータや音色等に関する演奏関連データを受け取り、イベント開始時刻に達した際にバス２１を介して音源ユニット２２，２３，２４に音源制御データを送り楽音の生成を開始させる。音源ユニット２２，２３，２４で生成された楽音はバス３１を介してサウンドシステム３２に供給されて、サウンドシステム３２から放音されるようになる。バス２１には、Ｉ／Ｏユニット２５，２６を介して他のユニットを接続することができる。
【００１６】
ところで、本発明の実施例にかかるＥバスシステムに、メインコントローラデバイス１０、パネルデバイス１２，１３、鍵盤デバイス１４，１５およびＭＩＤＩデバイス１６を接続する場合には、図２に示すようにそれぞれのデバイスにおける基板のバス端子に、Ｅバス１１を構成しているワイヤーの一端に設けられているコネクタを装着する。このワイヤーの他端は、分岐基板１７におけるＥバス１１を構成している信号線および電源線にそれぞれ接続されている。このように、それぞれのデバイスの基板にＥバス１１のコネクタを装着することにより、そのデバイスをＥバスシステムに接続することができる。このため、必要に応じてデバイスをＥバス１１のコネクタから脱着することにより、Ｅバスシステムからデバイスの追加／取り外しを可能とすることができる。なお、Ｅバスシステムに接続されたデバイスにはＥバス１１から電源が供給されるようになる。図２に示す構成の場合は、分岐基板１７に図示しない電源部から電源が供給されている。そして、Ｅバス１１のコネクタは例えば７ピンとされ、そのうち３ピンが信号線用として使用され、残る４ピンが電源用として使用される。
【００１７】
本発明の実施例にかかるＥバスシステムを電子楽器１に用いるようにすると、例えば電子楽器１をオルガン型の２段鍵盤電子楽器モデルとしたい場合には、図２に示すように鍵盤デバイス１４と鍵盤デバイス１５とをそれぞれメイン基板、パネル基板等の接続されたＥバスのコネクタに装着すればよいようになる。また、３段鍵盤電子楽器モデルとしたい場合は、さらに鍵盤デバイスをＥバス１１のコネクタに装着すればよい。さらに、メイン基板、パネル基板、鍵盤基板をＥバスに接続した電子楽器において、鍵盤デバイスのみを交換することにより、例えば６１鍵電子楽器モデルから７６鍵電子楽器モデルとすることができる。さらにまた、パネルデバイスを交換することにより、パネルスイッチの多いモデルや少ないモデルに対応させることができる。このように、電子楽器を構成する複数基板のうちの一部の基板を、自由に追加、削除、あるいは変更することが可能である。
【００１８】
本発明にかかる電子楽器用バスシステムであるＥバスシステムについて、以下に詳細に説明する。
Ｅバスシステムは、双方向シリアルバスとされており、信号線はシリアルクロックライン（以下、「ＳＣＬライン」という）と、シリアルデータライン（以下、「ＳＤＡライン」という）と、イニシャルクリアラインの３本とされている。この場合、ＳＤＡラインにはＳＣＬラインに送出されるクロックに同期したデータ信号が送出される。そして、イニシャルクリアラインには、Ｅバスシステムの立ち上げ時やリセット時にリセット信号が送出される。Ｅバスシステムの電源ラインは４本とされており、この電源ラインからＥバスシステムに接続されているデバイスに電源が供給されている。Ｅバスシステムの通信速度は、１００ｋｂｐｓ、４００ｋｂｓまたは３．４Ｍｂｐｓのいずれかとすることができる。
【００１９】
また、Ｅバスシステムには、複数のデバイスを順次接続（バス型接続）することができ、接続されたデバイスは、唯一無二の固有のアドレスを持つようにされている。この固有のアドレスは、例えば７ビットとされる。この固有のアドレスのテーブルを図５に示すが、固有のアドレスは４ビットのカテゴリーＩＤと３ビットのサブアドレスから構成される。カテゴリーＩＤは、デバイスのカテゴリーの種類を示しており、サブアドレスは同種のカテゴリーのデバイスの内の自デバイスを示すアドレスである。カテゴリー種類を示す上位アドレスであるカテゴリーＩＤは、そのデバイスの基板の作成時においてデバイスのカテゴリー種類に応じて予め設定されており、サブアドレスは電子楽器１に組み込まれる際に他の同種のデバイスのサブアドレスと重複しないようにジャンパピンやディップスイッチにより設定される。なお、カテゴリーの種類は、メインコントローラデバイス１０が属するホスト系、鍵盤デバイス１４，１５が属する鍵盤系、パネルデバイス１２，１３が属するパネル系、ＭＩＤＩデバイスが属するＭＩＤＩ系、鍵盤／パネルが複合されている鍵盤／パネル複合系とされる。
【００２０】
Ｅバスシステム上のデバイス間の通信は、マスター・スレーブ動作による通信とされ、マルチ・マスター可能とされている。なお、マスターとはＥバスシステム上でデータ転送を開始すると共に、転送を可能にするクロックパルスを生成してＳＣＬラインに送出し、さらにデータ転送を終了することのできるデバイスである。また、スレーブはマスターによってアドレス指定される送信先のデバイスである。なお、マルチ・マスターとはメッセージを失うことなく、複数のマスターが同時にＥバスシステムをコントロールすることができることをいう。
【００２１】
さらに、Ｅバスシステムにおいて、複数のマスターが同時にＥバスシステム上にデータを転送しようとした際には、データ破壊を防止するためにデータの衝突検出機能およびアービトレーション（調停）の機能が備えられている。Ｅバスシステムでは、送信先のデバイスにおけるカテゴリー名の優先順位に従うアービトレーションが行われる。カテゴリー名は、カテゴリーの種類を拡張したものであり、図５に固有のアドレスとカテゴリー名とのテーブルが示されている。その優先順位は、カテゴリー名が全てのデバイスが送信先とされるゼネラルコールの優先順位が最も高くされ、カテゴリー名がホスト系の優先順位が２番目とされ、カテゴリー名が鍵盤系の優先順位が３番目とされ、カテゴリー名が鍵盤／パネル複合系の優先順位が４番目とされ、カテゴリー名がパネル系の優先順位が５番目とされ、カテゴリー名がＭＩＤＩ系の優先順位が最後とされている。これらの優先順位は、重要度およびリアルタイム性を勘案して決められている。
【００２２】
さらにＥバスシステムでは、送信元アドレスおよび送信先アドレスにおいて、該アドレスの属するカテゴリー名に対応する通信プロトコルを使用して通信するようにしている。図５に、カテゴリー名と通信プロトコルとのテーブルを示している。図５に示すように、鍵盤デバイス１４，１５が属する鍵盤系あるいはパネルデバイス１２，１３が属するパネル系と、メインコントローラデバイス１０が属するホスト系との間で通信を行う場合は、マンマシンインタフェース用プロトコルである後述する標準プロトコルを使用して通信が行われる。また、ＭＩＤＩデバイス１６が属するＭＩＤＩ系とメインコントローラデバイス１０が属するホスト系との間で通信を行う場合は、演奏情報伝達用プロトコルである後述するＭＩＤＩプロトコルを使用して通信が行われる。また、カテゴリー名がゼネラルコールの場合は、制御用プロトコルである後述する共通プロトコルを使用して、ホスト系は、鍵盤系、パネル系、ＭＩＤＩ系と通信を行う。共通プロトコルは、標準プロトコルおよびＭＩＤＩプロトコルの共通部分から構成されている。なお、ゼネラルコールのアドレス「００００ ０００」に送信を行なえるのはホスト系のみであり、他の鍵盤系、パネル系、ＭＩＤＩ系のデバイスが共通プロトコルによる送信を行ないたい場合は各自の固有のアドレスを使用する。
【００２３】
このように、ホスト系のメインコントローラデバイス１０は、カテゴリー名に適応する通信プロトコルで通信を行うことができるようにされている。ホスト系が他のカテゴリー名のデバイスと通信を行う際には、通信プロトコルを決定する必要があるが、通信に先立ってホスト系は送信先アドレスをアドレス指定する。この送信先アドレスは、デバイスにおける固有のアドレスであり、固有のアドレスの上位４ビットはカテゴリーＩＤとなっている。そこで、ホスト系は送信先アドレスから通信相手であるデバイスのカテゴリー名および使用する通信プロトコルを図５のテーブルを参照して知ることができる。なお、図５に示すようにホストには、ホスト系の２つの通信プロトコルに対応する２つの固有アドレスが与えられており、通信相手とされるデバイスのカテゴリー名に適応する通信プロトコルのアドレスを用いて通信を行うようにしている。それ以外に、ホスト系のデバイスは標準プロトコルによる通信を行うことができるが、そこでは該２つの固有アドレスとゼネラルコールのアドレスの内の何れかを使用する。
【００２４】
次に、本発明にかかるＥバスシステムの具体的構成を図３に示す。ただし、図３においてはＥバスシステムを構成する７本のワイヤーのうちのＳＣＬラインとＳＤＡラインとの２本の信号線だけを示している。なお、図示していない信号線はイニシャルクリアライン（Ｅ−ＩＣ）であり、残る４本のワイヤーは電源ラインとされている。
図３に示すように、デバイス１（Device1）、デバイス２（Device2）、デバイス３（Device3）はＳＣＬラインおよびＳＤＡラインにそれぞれバス接続されている。それぞれのデバイスとＳＣＬラインおよびＳＤＡラインとの結線構成は同様とされているので、デバイス１についてのみ説明する。デバイス１において、クロックが転送されるＳＣＬラインにはクロック入力部（SCL IN）とされるバッファＢ２が接続されており、バッファＢ２を介してクロックパルスがデバイス１に取り込まれる。また、ＳＣＬラインにはクロック出力部（SCL OUT）とされるオープンドレインとされた電界効果トランジスタ（以下、「トランジスタ」という）ＴＲ２のドレインが接続され、トランジスタＴＲ２をオン／オフすることによりクロックパルスをＳＣＬラインに送出することができる。さらに、データ信号が転送されるＳＤＡラインにはデータ入力部（SDA IN）とされるバッファＢ１が接続されており、バッファＢ１を介してデータ信号がデバイス１に取り込まれる。また、ＳＤＡラインにはデータ出力部（SDA OUT）とされるオープンドレインとされたトランジスタＴＲ１のドレインが接続され、トランジスタＴＲ１をオン／オフすることによりデータ信号をＳＤＡラインに送出することができる。
【００２５】
デバイス２およびデバイス３においても同様の回路構成でＳＣＬラインおよびＳＤＡラインに接続されている。なお、図３に示すデバイス１〜デバイス３においては、トランジスタＴＲ１ないしトランジスタＴＲ６は電界効果トランジスタとしたが、オープンコレクタとされたバイポーラトランジスタとしてもよい。また、ＳＣＬラインおよびＳＤＡラインはプルアップ抵抗Ｒｐによりそれぞれプルアップされている。すなわち、ＳＣＬラインおよびＳＤＡラインは開放状態ではハイ（Ｈ）レベルとなっており、デバイスにおけるデータ出力部のいずれかのトランジスタＴＲ１，ＴＲ３，ＴＲ５・・・がオンされることによりＳＤＡラインはロー（Ｌ）レベルとなる。すなわち、ＳＤＡラインにデバイス１〜デバイス３のデータ出力部がワイヤードアンド接続されている。ＳＣＬラインも同様に開放状態ではＨレベルとなり、デバイスにおけるクロック出力部のいずれかのトランジスタＴＲ２，ＴＲ４，ＴＲ６・・・がオンすることによりＳＣＬラインはＬレベルとなる。すなわち、ＳＣＬラインにデバイス１〜デバイス３のクロック出力部がワイヤードアンド接続されている。
【００２６】
このようなＥバスシステムにおけるＳＣＬラインとＳＤＡラインにおけるデータ転送時の波形タイミング図を図４に示す。Ｅバスシステムにおいては、バスが開放状態（Ｈレベル）の時のみにデータ転送を開始することができ、データの転送開始時には、マスターはスタートビット（Start Bit）を転送する。この場合、ＳＣＬラインがＨレベル（開放状態）とされている際に、ＳＤＡラインをＬレベルに反転することによりスタートビットが図示するように送出される。このスタートビットをＥバスシステムに接続されているデバイスが検出することにより、デバイスはデータ転送が開始されることを知る。次いで、データ部に前置して置かれたヘッダ部が転送される。データ部は複数バイト（１バイト＝８ビット）で構成されており、ヘッダ部も複数バイトで構成されている。このヘッダ部では、７ビットの送信先アドレス（スレーブアドレス）と、データの読込／書込（Ｒ／Ｗ）を指示する１ビットとで最初の１バイトが構成され、７ビットの送信元アドレス（マスターアドレス）と“０”のダミービットの１ビットとで次の１バイトが構成されている。ヘッダ部に続いて、１バイト単位のデータが後述するように３バイトあるいは１５バイト連続しているデータ部が転送される。また、ヘッダ部およびデータ部の各ビットに同期してＳＣＬラインにクロックパルスが送出される。この場合、ヘッダ部およびデータ部は１バイト単位のデータで構成されていることから、ヘッダ部およびデータ部の１バイト毎に、図示するように各ビットに同期したクロックパルスが１，２，３・・・，８の８発送出される。なお、ヘッダ部およびデータ部における各ビットのレベルを反転できるタイミングは、クロックパルスがＬレベルとされている期間とされ、各ビットのデータが有効となるようにクロックパルスがＨレベルの期間においては、ＳＤＡラインのレベルを安定させて転送しなければならない。
【００２７】
Ｅバスシステムにおいてはマスターから送出されるクロックパルスやヘッダ部およびデータ部は、ＳＣＬラインおよびＳＤＡラインを介して全てのデバイスに到達する。そこで、各デバイスは最初に受信されるヘッダ部におけるスレーブアドレスと自機に固有のアドレスとを１ビットずつ対比していく。そして、７ビットのスレーブアドレスと自機のアドレスとが一致した場合は、自機がスレーブとしてアドレス指定されたと知り以後に続くデータを受信する。また、ＳＤＡラインのレベルがＬ（ｏｒＨ）であるのに、対応する自機のアドレスのビットが“１”（ｏｒ”０”）であった場合は、自機のアドレスがスレーブアドレスとしてアドレス指定されておらず、自機はデータ転送先でないと判断して以後に続く受信データは捨てるようにする。これにより、アドレス指定したデバイスだけがデータを受信することができる。
なお、ヘッダ部においてはそれぞれのバイトにおける８ビット目が、データの読込／書込を指示するビットとされているが、Ｅバスシステムにおいてはこのビットは常にＬ（＝“０”）とされて、書き込みしか存在しないデータフォーマットとされている。電子楽器では鍵盤、パネル等の操作に対するリアルタイムな応答が求められているが、このように、鍵盤系、パネル系における操作イベントを書き込みによりホスト系へ送信することによりそのレスポンスを高めている。
【００２８】
ところで、マスターはＳＤＡラインに送出したヘッダ部あるいはデータ部における１バイト毎の信号が正常に受信されたことを知った後に、次の１バイトの信号を送出するようにしている。そこで、１バイトの信号が送出された後に、１バイトの信号が有効な信号として受信されたか否かを示すアクノリッジ用の９番目のクロックパルス（ＡＣＫ）を、マスターはＳＣＬラインに送出している。同時に、マスターはＳＤＡラインを開放してＨレベルの状態にしている。そして、ヘッダ部のスレーブアドレスでアドレス指定された送信先のデバイスは、１バイトの信号が有効な信号として受信された際に、データ出力部のトランジスタをオンさせて、ＳＤＡラインをＬレベルに保持する。マスターは、９番目のＡＣＫ用クロックがＨレベルとなった期間においてＳＤＡラインのレベルを取り込んで、アクノリッジがＬレベルならば正常に送信先のデバイスが１バイトの信号を受信したことを知る。これにより、マスターは次の１バイトをＳＤＡラインに送出可能となる。この際に、送信先のデバイスは受信準備できるまでＳＣＬラインをＬレベルに保持する。マスターは、所定の時間の後に、次の１バイトを最初のビットよりＳＤＡラインに順次送出開始すると共に、同期するクロックパルスをＳＣＬラインに送出開始する。ここで、送信先のデバイスの受信準備ができている場合、ＳＣＬラインのクロックパルスが順次立ち上がり、送信先のデバイスではそのクロックパルスに応じて、次の１バイトのデータを取り込むことができる。一方、その時点で送信先のデバイスの準備ができていない場合、該送信先のデバイスによりＳＣＬラインはＬレベルに保持されている。従って、マスターが送出しようとしたクロックパルスはＳＣＬラインに現れず、マスターはＳＣＬラインが立ち上がるのを待つ。送信先のデバイスの受信準備が完了すると、ＳＣＬラインは解放されるのでクロックパルスがＳＣＬラインにおいて立ち上がり、次の１バイトの送信が行われる。
なお、送信先のデバイスが有効な１バイトの信号を受信することができなかった場合は、Ｈレベルのアクノリッジが生成されて、このアクノリッジをマスターが受け取るようになる。この場合、マスターはＳＣＬラインをＨレベルに保持した状態でＳＤＡラインをＨレベルに反転させることによりストップビット（Stop Bit）を送出し、データ転送を中止するようにする。このストップビットは、通信を終了する際においても、マスターによりＥバス１１上に送信される。
【００２９】
次に、アービトレーションについて説明する。Ｅバスシステムにおいては、バスが開放状態（Ｈレベル）の時のみにデータ転送を開始することができるが、複数のデバイスがマスターとしてほぼ同時にデータ転送を開始することがある。この場合は、いずれかのマスターに通信を許可するアービトレーションが行われる。このアービトレーションでは、ＳＤＡラインに各デバイスのデータ出力部のトランジスタがワイヤードアンド接続されていることを利用している。具体的に説明すると、データ転送開始した際には、図４に示すようにスタートビットに続いてスレーブアドレスがＳＤＡラインに送出されるので、複数のマスターにおいてこのＳＤＡラインから受信したアドレスと自機がアドレス指定したスレーブアドレスとを１ビットずつ対比する。この場合、同時に複数のデバイスからデータがＳＤＡラインに送出された場合には、ワイヤードアンドされていることからいずれかのデバイスがＬレベルを送出した際にＳＤＡラインはＬレベルに保持されるようになる。
【００３０】
すると、デバイスによっては自機が指定したスレーブアドレスの対比するビットが“１”であるのに対して、ＳＤＡラインから取り込まれたビットが“０”（＝Ｌレベル）となる。このようにアドレスが不一致となった場合は、他のマスターの優先順位が高いと判断してデータ出力部をオフする。この処理を続けると、最終的に優先順位の最も高いマスターに通信が許可されるようになる。この場合の優先順位は、上述したように、ＳＤＡラインのレベルはＬレベルが優先とされていることから、スレーブアドレスとして最上位ビット（ＭＳＢ）から多く“０”が続くアドレスの優先順位が高いことになる。アービトレーションにおける優先順位はカテゴリー名により決定されており、前述したようにゼネラルコールの順位が最も高くされ、２番目の順位はホスト系（メインコントローラ）のデバイスが送信先の場合とされ、３番目の順位は鍵盤系のデバイスが送信先の場合とされ、４番目の順位はパネル系のデバイスが送信先の場合とされ、５番目の順位はＭＩＤＩ系のデバイスが送信先の場合とされている。なお、鍵盤系の順位が高くされているのは、鍵盤ではリアルタイム性が重要となるからである。
【００３１】
このような理由から、図５に示すようにカテゴリーＩＤをカテゴリー名の優先順位に応じて各カテゴリーに付与している。図５は、カテゴリーＩＤ、サブアドレス範囲、カテゴリー名および使用される通信プロトコルの種類を示すテーブルである。図５に示すテーブルにおいてカテゴリーＩＤを参照すると、全てのデバイスに転送するゼネラルコールのカテゴリーＩＤは”００００”とされ、“０”が最も長く続くようにされている。また、ホスト系（メインコントローラ）のカテゴリーＩＤは”０００１”とされ、鍵盤系のカテゴリーＩＤは”００１０”とされ、パネル系のカテゴリーＩＤは”００１１”とされ、鍵盤／パネル複合系のカテゴリーＩＤは”０１００”とされ、ＭＩＤＩ系のカテゴリーＩＤは”０１０１”とされている。これにより、上述した優先順位でアービトレーションを行えるようになる。なお、カテゴリーＩＤが同一であり、カテゴリーＩＤだけを対比しただけではマスターが決定されない場合は、サブアドレスも対比してマスターを決定する。これでも決定できない場合は、送信元アドレスも対比してマスターを決定する。送信先アドレスと送信元アドレスの両方が一致することはないので、送信元アドレスまでで必ずアービトレーションが完了する。（特別な通信であるゼネラルコールを除いた中で、最も優先度の高い）ホスト系のデバイスを送信先とした通信では、送信元が鍵盤系、送信元がパネル系、送信元が鍵盤／パネル複合系、ＭＩＤＩ系の順番で通信が優先されるが、これもリアルタイム性の要請により決められている。
【００３２】
サブアドレスについて述べると、ホスト系には、通信相手のデバイスのカテゴリー名が鍵盤・パネル系（鍵盤系、パネル系、または鍵盤／パネル複合系）の時に使用するサブアドレス“０００”と、ＭＩＤＩ系の時に使用するサブアドレス“００１”とが用意されている。すなわち、鍵盤・パネル系のカテゴリー名のデバイスをアドレス指定した際にＭＩＤＩ系より優先して通信を行えるようになる。なお、サブアドレス“０１０”〜“１１１”は異なるバス・フォーマット用あるいは将来の使用に備えて予約されている。さらに、アドレス指定した送信先であるスレーブアドレスが一致してマスターが決定されない場合は、次に送出されるマスターアドレスも対比してマスターを決定するようにする。
また、鍵盤系、パネル系、鍵盤／パネル複合系、ＭＩＤＩ系のサブアドレスには“０００”ないし“１１１”の８つのサブアドレス範囲が与えられている。このため、これらのカテゴリー名のデバイスは、それぞれ８つまでの同種のカテゴリーのデバイスをＥバスシステムに接続することができるようになる。
【００３３】
ところで、Ｅバスシステムにおいてはデバイス間で通信を行う際には、デバイスのカテゴリーに適応する通信プロトコルで通信を行うようにしているが、全てのカテゴリーのデバイスと通信するゼネラルコールの通信プロトコルは、共通プロトコルとされている。図５に示すように、具体的には、ホスト系と通信するカテゴリー名が鍵盤系、パネル系、鍵盤／パネル複合系とされている場合は標準プロトコルで通信される。また、ホスト系と通信するカテゴリー名がＭＩＤＩ系とされている場合はＭＩＤＩプロトコルで通信される。この場合、デバイスにはそのカテゴリー名に対応するカテゴリーＩＤが与えられていることから、アドレス指定されたスレーブアドレスのカテゴリーＩＤから通信プロトコルを決定することができる。なお、ホスト系（メインコントローラ）は通信相手のデバイスが属するカテゴリー名に適応している通信プロトコルを使用して通信を行う必要があることから、図５に示すように標準プロトコル用のアドレスと、ＭＩＤＩプロトコル用のアドレスとを備えている。例えば、ホスト系のデバイスとＭＩＤＩ系のデバイスとが通信する際には、ホスト系のデバイスは自機のアドレスとして“０００１ ００１”を使用し、ＭＩＤＩ系のデバイスがマスターとなった際には、アドレス指定するスレーブアドレスを“０００１ ００１”とする。これにより、ホスト系のデバイスとＭＩＤＩ系のデバイスとはＭＩＤＩプロトコルを使用して通信を行えるようになる。また、ホスト系のデバイスと鍵盤系（パネル系あるいは鍵盤／パネル複合系）のデバイスとが通信する際には、ホスト系のデバイスは自機のアドレスとして“０００１ ０００”を使用し、鍵盤系（パネル系あるいは鍵盤／パネル複合系）のデバイスがマスターとなった際には、アドレス指定するスレーブアドレスを“０００１ ０００”とする。これにより、ホスト系のデバイスと鍵盤系（パネル系あるいは鍵盤／パネル複合系）のデバイスとが標準プロトコルを使用して通信を行えるようになる。
【００３４】
次に、本発明にかかるＥバスシステムにおけるパケットのデータフォーマットを図６に示す。
図６に示すように、Ｅバスシステムにおけるデータフォーマットには全体の長さが５バイト長とされる標準データのデータフォーマットと、全体の長さが１７バイト長とされる拡張データのデータフォーマットとが定義されている。標準データのデータフォーマットにおいては、アドレス指定する１バイトの送信先アドレス（スレーブアドレス）と、１バイトの送信元アドレス（マスターアドレス）と、それぞれ１バイトのデータ１，データ２，データ３の合計５バイトで構成されている。また、拡張データのデータフォーマットにおいては、アドレス指定する１バイトの送信先アドレス（スレーブアドレス）と、１バイトの送信元アドレス（マスターアドレス）と、それぞれ１バイトのデータ１〜データ１５の合計１７バイトから構成されている。この場合の送信元アドレスにはダミービット“０”が１ビット、送信先アドレスにはＲ／Ｗの１ビットがそれぞれ含まれている。標準データのデータフォーマットは、共通プロトコル、標準プロトコルおよびＭＩＤＩプロトコルにおいて用いられ、拡張データのデータフォーマットはＭＩＤＩプロトコルにおいてシステムエクスクルーシブメッセージ等を転送する際に用いられる。なお、送信先アドレスと送信元アドレスとで図４に示すヘッダ部が構成され、続く３バイトのデータあるいは１５バイトのデータによりデータ部が構成されている。なお、標準データおよび拡張データにおけるデータ１は、転送されるデータの種別を示すインデックスとされている。具体的にはインデックスは、各通信プロトコルにおけるコマンドを示している。このように、パケットの長さ（あるいは、データバイトの長さ）を２通りに統一することにより、通信を行う各デバイスでの処理を簡略化することができる。電子楽器において、エクスクルーシブを除く通常のコマンドをやりとりするのに、データバイトが３バイトのパケットは最適である。また、その通常のコマンドのパケット長を５バイト程度（１０バイト以下）の短い長さにすることにより、一つ一つのパケットのバスにおける占有時間が短縮され、電子楽器の鍵盤やパネルからの入力に対する応答時間を短縮することができる。
【００３５】
次に、共通プロトコルのコマンドについて説明する。共通プロトコルは、通信を行うデバイスのカテゴリーを問わず使用することのできる通信プロトコルとされているため、各デバイスはそれが共通プロトコルであることを判別することなく、自分の属するカテゴリの処理の中で共通プロトコルを扱うことができる。前述したように、本発明の電子楽器用バスシステムにかかるＥバスシステムにおいてはメインコントローラデバイス１０であるホスト系のデバイスと、他のデバイスとの間で通信を行うことを前提としている。そこで、ホスト受信とホスト送信のコマンドについて図７に示す。共通プロトコルにおけるコマンドはいずれも標準データのデータフォーマットとされており、図示する順と逆になるがホスト送信欄のコマンドにはカテゴリーＩＤ・サブアドレスリクエストがある。このコマンドは、ホスト系のデバイスがＥバスシステムに接続されているデバイスのアドレスを検出するためのコマンドであり、ゼネラルコールすることができる。このコマンドにおけるインデックスであるデータ１は“００ｈ”（ｈは１６進表記を示す：００ｈ＝００００ ００００）とされ、データ２およびデータ３も“００ｈ”とされている。
【００３６】
カテゴリーＩＤ・サブアドレスリクエストのコマンドをホスト系のデバイスからゼネラルコールする際には、“００００ ０００”を送信先アドレス、“０００１ ０００”を送信元アドレス（図５参照）、“００ｈ”とされたデータ１ないしデータ３からなる標準データのコマンドを発行する。ゼネラルコールされたカテゴリーＩＤ・サブアドレスリクエストコマンドは、Ｅバスシステムに接続されている全てのカテゴリのデバイスが受信するようになり、各デバイスはホスト受信欄に示されているカテゴリーＩＤ・サブアドレスリプライのコマンドをホストに返す。このカテゴリーＩＤ・サブアドレスリプライは、自機に固有のアドレスをホスト系のデバイスに知らせるコマンドである。カテゴリーＩＤ・サブアドレスリプライコマンドを発行するには、アドレス指定する送信先アドレスを“０００１ ０００”、送信元アドレスを自機の７ビットのアドレス、インデックスであるデータ１を“００ｈ”、データ２が自機のカテゴリーＩＤ、データ３が自機のサブアドレスの標準データを送信する。これにより、ホストはＥバスシステムに接続されているデバイスと、そのアドレスを知ることができる。なお、カテゴリーＩＤ・サブアドレスリクエストのコマンドはＥバスシステムの動作開始時にホスト系のデバイスがゼネラルコールするようにされており、このコマンドによりＥバスシステムに接続されているデバイスと、そのアドレスを知り、知ったアドレスからカテゴリー名と使用する通信プロトコルを知ることができる。このようにして、ホスト系のデバイスは図５に示すテーブルを作成でき、以降の通信は作成されたテーブルにおけるアドレスを設定して通信することができる。また、ホスト系以外のデバイスはホスト系のデバイスとの通信を行うことを原則としており、ホスト系に割り当てられている複数のアドレスはＥバスシステムで予め定められたアドレスとされている。したがって、ホスト系以外のデバイスは通信する際に設定するアドレスを予め知っているので図５に示すテーブルを作成する必要はない。ゼネラルコールはホスト以外の各デバイスも受信する通信であるので、仮に、各デバイスからのカテゴリーＩＤ・サブアドレスリプライ時にゼネラルコールを使用すると、それを受信するホスト以外の各デバイスでそれを無視するための処理が必要になってしまう。そこで、本発明にかかるＥバスシステムでは、該リプライ時に、ゼネラルコールではなく送信先をホストの標準アドレスとした通信を行ない、ホスト以外の各デバイスでの処理を簡略化するようになっている。
【００３７】
また、ホスト送信欄のＥバススタートのコマンドは原則的にメインコントローラデバイス１０からゼネラルコールされるコマンドであり、Ｅバスシステムの立ち上げ時にＥバスシステムを動作可能にするためのコマンドである。Ｅバススタートのコマンドをゼネラルコールする際は、“００００ ０００”が送信先アドレス、“０００１ ０００”が送信元アドレス、インデックスであるデータ１が“０１ｈ”、データ２が“００ｈ”、データ３が“００ｈ”の標準データを送信する。
【００３８】
次に、図８に示す標準プロトコルのホスト受信およびホスト送信のコマンドについて説明する。標準プロトコルは、ホスト系のデバイス（メインコントローラ）と、鍵盤系、パネル系、鍵盤／パネル複合系のカテゴリーのデバイスとが通信を行う場合に使用することのできる通信プロトコルとされている。標準プロトコルにおけるコマンドはいずれも標準データのデータフォーマットとされている。
標準プロトコルにおけるホスト受信欄のコマンドのうちの共通プロトコルのコマンドは、図７に示す共通プロトコルと同様であるのでその説明は省略するが、この部分が同じになっているために、当該デバイスでは動作を標準プロトコルと共通プロトコルの間で切り換えることなく、共通プロトコルを送受信することができる。次のＳＷ ＯＦＦコマンドおよびＳＷ ＯＮコマンドは、パネルデバイスに設けられているパネルスイッチのＯＦＦイベントおよびＯＮイベントをホストに転送するコマンドである。例えば、パネルデバイスにおけるパネルスイッチのスイッチ番号ｎのスイッチがＯＦＦされた場合は、送信先アドレスがホストを示す“０００１ ０００”とされ、送信元アドレスがそのパネルデバイスのアドレス“００１１ ａａａ”（“ａａａ”は当該パネルデバイスのサブアドレス）とされ、インデックスであるデータ１が“６ｘｈ”、データ２がオフされたスイッチ番号ｎ（８ビット）、データ３がダミーの“００ｈ”とされたＳＷ ＯＦＦコマンドが発行される。
【００３９】
また、パネルデバイスにおけるパネルスイッチのスイッチ番号ｍのスイッチがＯＮされた場合は、送信先アドレスがホストを示す“０００１ ０００”とされ、送信元アドレスがそのパネルデバイスのアドレス“００１１ ｂｂｂ”（“ｂｂｂ”は当該パネルデバイスのサブアドレス）とされ、インデックスとされるデータ１が”７ｘｈ”、データ２がオンされたスイッチ番号ｍ（８ビット）、データ３がダミーの“００ｈ”とされたＳＷ ＯＮコマンドが発行される。なお、いずれのコマンドにおいても“ｘｈ”はポート番号を示しており、スイッチ番号が８ビットとされることから、１６ポート×２５６個のパネルスイッチのＳＷ ＯＦＦコマンドおよびＳＷ ＯＮコマンドを発行することができる。
【００４０】
標準プロトコルにおけるホスト受信欄の鍵盤 ＯＦＦコマンドおよび鍵盤 ＯＮコマンドは、鍵盤デバイスにおける各鍵のノートオンイベントおよびノートオフイベントをホストに転送するコマンドである。ここで、鍵盤デバイスにおけるノート番号ｎに対応する鍵がノートオフされた場合は、送信先アドレスがホストを示す“０００１ ０００”とされ、送信元アドレスがその鍵盤デバイスのアドレス“００１０ ａａａ”（“ａａａ”は当該鍵盤デバイスのサブアドレス）とされ、インデックスとされるデータ１が”８ｖｈ”、データ２がノートオフされたノート番号ｎ（８ビット）、データ３がベロシティの上位８ビットとされた鍵盤 ＯＦＦコマンドが発行される。なお、”ｖｈ”はベロシティの下位４ビットとされており、合計１２ビットとされたベロシティ情報が転送され、そのうちの上位７ビットはＭＩＤＩ互換とされている。
【００４１】
また、鍵盤デバイスにおけるノート番号ｍに対応する鍵がノートオンされた場合は、送信先アドレスがホストを示す“０００１ ０００”とされ、送信元アドレスがその鍵盤デバイスのアドレス“００１０ ｂｂｂ”（“ｂｂｂ”は当該鍵盤デバイスのサブアドレス）とされ、インデックスとされるデータ１が”９ｖｈ”、データ２がノートオンされたノート番号ｍ（８ビット）、データ３がベロシティの上位８ビットとされた鍵盤 ＯＮコマンドが発行される。このコマンドでは、鍵盤 ＯＦＦコマンドと同様に合計１２ビットとされたベロシティ情報が転送され、そのうちの上位７ビットがＭＩＤＩ互換とされている。また、いずれのコマンドでもノート番号が８ビットとされることから、２５６個のノートに対応する鍵盤 ＯＦＦコマンドおよび鍵盤 ＯＮコマンドを発行することができる。ここで、鍵盤 ＯＦＦコマンド、および鍵盤 ＯＮコマンドにおいて、ポート番号を削ってベロシティ情報を１２ビットとしているのは、鍵盤演奏の取り込みにおいては、タッチカーブ等の処理のため、ＭＩＤＩのベロシティより高分解能の１２ビットのベロシティ分解能が必要であるためである。
【００４２】
標準プロトコルにおけるホスト受信欄の鍵盤デバイスにおけるポリフォニックアフタータッチ（各鍵毎のアフタータッチ）の値を転送するポリフォニックアフタータッチコマンドは、送信先アドレスがホストを示す“０００１ ０００”とされ、送信元アドレスがその鍵盤デバイスのアドレス“００１０ ａａａ”（“ａａａ”は当該鍵盤デバイスのサブアドレス）とされ、インデックスとされるデータ１が“Ａｘｈ”、データ２がアフタータッチをかけるノートのノート番号ｎ（８ビット）、データ３が８ビットのアフター値とされている。“ｘｈ”はポート番号とされているので、１６ポートのポリフォニックアフタータッチコマンドを発行することができる。
【００４３】
また、標準プロトコルにおけるホスト受信欄のパネルデバイスにおけるボリュームやホイール等の操作された操作値を転送するコンティニュアスコントローラコマンドは、送信先アドレスがホストを示す“０００１ ０００”とされ、送信元アドレスがそのパネルデバイスのアドレス“００１１ ａａａ”（“ａａａ”は当該パネルデバイスのサブアドレス）とされ、インデックスとされるデータ１が“Ｂｘｈ”、データ２がボリュームやホイール等のコントローラの種別（８ビット）、データ３が８ビットのコントローラの操作値とされている。“ｘｈ”はポート番号とされており、種別は８ビットとされているので、１６ポート×２５６個のコンティニュアスコントローラコマンドを発行することができる。
【００４４】
また、標準プロトコルにおけるホスト受信欄のパネルデバイスにおけるロータリエンコーダ等のジョグコントローラにおける操作された操作値を転送するＪＯＧコントローラコマンドは、送信先アドレスがホストを示す“０００１ ０００”とされ、送信元アドレスがそのパネルデバイスのアドレス“００１１ ａａａ”（“ａａａ”は当該パネルデバイスのサブアドレス）とされ、インデックスとされるデータ１が“Ｃｘｈ”、データ２がジョグコントローラの種別（８ビット）、データ３がコントローラにおける操作値の２の補数の相対値（８ビット）とされている。“ｘｈ”はポート番号とされており、種別は８ビットとされているので、１６ポート×２５６個のＪＯＧコントローラコマンドを発行することができる。
【００４５】
標準プロトコルにおけるホスト受信欄の鍵盤デバイスにおけるアフタータッチ（１つの鍵盤の複数鍵に共通のアフタータッチ）の値を転送するアフタータッチコマンドは、送信先アドレスがホストを示す“０００１ ０００”とされ、送信元アドレスがその鍵盤デバイスのアドレス“００１０ ａａａ”（“ａａａ”は当該鍵盤デバイスのサブアドレス）とされ、インデックスとされるデータ１が“Ｄｘｈ”、データ２がタッチ値の上位８ビット、データ３がタッチ値の下位８ビットとされている。“ｘｈ”はポート番号とされているので、１６ポートのアフタータッチコマンドを発行することができる。このアフタータッチコマンドで転送されるタッチ値は、マスター（送信元）とされている鍵盤デバイスにおいて複数ノートオンされているノートの全てにかけられているタッチ値である。
【００４６】
また、標準プロトコルにおけるホスト受信欄のパネルデバイスにおけるボリュームやホイール等の操作された操作値を転送する１６ビットのコンティニュアスコントローラコマンドは、送信先アドレスがホストを示す“０００１ ０００”とされ、送信元アドレスがそのパネルデバイスのアドレス“００１１ ａａａ”（“ａａａ”は当該パネルデバイスのサブアドレス）とされ、インデックスとされるデータ１が“Ｅｘｈ”、データ２がコントローラの操作値の上位８ビット、データ３がコントローラの操作値の下位８ビットとされている。“ｘｈ”はポート番号とされているので、１６ポートの１６ビットのコンティニュアスコントローラコマンドを発行することができる。なお、鍵盤／パネル複合系のデバイスでは、鍵盤デバイスとパネルデバイスの両方のコマンドを送信可能である。また、コンティニュアスコントローラコマンド、ジョグコントローラコマンドについては、鍵盤デバイスから送信できるようにしてもよい。
【００４７】
次に、標準プロトコルにおけるホスト送信欄のコマンドについて説明する。まず、ホスト送信欄の共通プロトコルのコマンドは、図７に示す共通プロトコルと同様であるのでその説明は省略する。
ホスト送信欄のＬＥＤコントロールのコマンドは、パネルデバイスに設けられているＬＥＤ（Light Emitting Diode）が属するとされたグループの輝度を、ホストがコントロールするコマンドである。ＬＥＤコントロールコマンドは、送信先アドレスが輝度コントロールされるパネルデバイスのアドレス“００１１ ａａａ”（“ａａａ”は当該パネルデバイスのサブアドレス）とされ、送信元アドレスがホストを示す“０００１ ０００”とされ、インデックスとされるデータ１が“６ｘｈ”、データ２が輝度をコントロールするグループ番号（８ビット）、データ３が輝度コントロール値である８ビットのＬＥＤ輝度値とされている。“ｘｈ”はポート番号とされているので、１６ポートのＬＥＤコントロールコマンドを発行することができる。ただし、グループ“００ｈ”の輝度は最小（オフ相当）とされ、グループ“ＦＦｈ”の輝度は最大（オン相当）とされているため、そのグループの輝度は変更することができないようにされている。
【００４８】
ホスト送信欄のＬＥＤコマンドは、パネルデバイスに設けられているＬＥＤをホストがグループに振り分けるコマンドである。ＬＥＤコマンドは、送信先アドレスがコントロールされるパネルデバイスのアドレス“００１１ ａａａ”（“ａａａ”は当該パネルデバイスのサブアドレス）とされ、送信元アドレスがホストを示す“０００１ ０００”とされ、インデックスとされるデータ１が“７ｘｈ”、データ２がグループに振り分ける８ビットのＬＥＤ番号、データ３が振り分けられる８ビットのグループ番号とされている。“ｘｈ”はポート番号とされており、ＬＥＤ番号は８ビットとされているので、１６ポート×２５６個のＬＥＤコマンドを発行することができる。
【００４９】
ここで、ＬＥＤコントロールコマンドとＬＥＤコマンドの使い方を説明すると、ホストがパネルデバイスへＬＥＤ“ｉ”をグループ“ＦＦｈ”に振り分けるＬＥＤコマンドを送信すると、このＬＥＤコマンドを受信したパネルデバイスではＬＥＤ番号“ｉ”のＬＥＤを点灯するようになる。また、ＬＥＤ“ｊ”をグループ“００ｈ”に振り分けるＬＥＤコマンドを送信すると、このＬＥＤコマンドを受信したパネルデバイスではＬＥＤ番号“ｊ”のＬＥＤを消灯するようになる。
また、ホストからパネルデバイスへ、まず、グループ“０１ｈ”の輝度を“００ｈ”（最小値）に設定するＬＥＤコントロールを送信すると共に、所望の複数ＬＥＤのＬＥＤ番号をそれぞれグループ“０１ｈ”に振り分ける複数のＬＥＤコマンドを送信し、最後に、グループ“０１ｈ”の輝度を“ＦＦｈ”（最大値）に設定するＬＥＤコントロールを送信することで、該パネルデバイスの該複数ＬＥＤを同時に点灯することができるようになる。
【００５０】
ホスト送信欄の鍵盤ＬＥＤコントロールのコマンドは、鍵盤デバイスの各鍵に設けられているＬＥＤ（演奏ガイド用ＬＥＤ）が属するグループの輝度をホストがコントロールするコマンドである。鍵盤ＬＥＤコントロールコマンドは、送信先アドレスが輝度コントロールされる鍵盤デバイスのアドレス“００１０ ａａａ”（“ａａａ”は当該鍵盤デバイスのサブアドレス）とされ、送信元アドレスがホストを示す“０００１ ０００”とされ、インデックスとされるデータ１が“８ｘｈ”、データ２が輝度コントロールされるグループ番号（８ビット）、データ３が輝度コントロール値である８ビットのＬＥＤ輝度値とされている。“ｘｈ”はポート番号とされているので、１６ポートの鍵盤ＬＥＤコントロールコマンドを発行することができる。ただし、グループ“００ｈ”の輝度は最小（オフ相当）とされ、グループ“ＦＦｈ”の輝度は最大（オン相当）とされているため、その輝度を変更することができないようにされている。
【００５１】
ホスト送信欄の鍵盤ＬＥＤコマンドは、鍵盤デバイスに設けられているＬＥＤをホストがグループに振り分けるコマンドである。鍵盤ＬＥＤコマンドは、送信先アドレスがコントロールされる鍵盤デバイスのアドレス“００１０ ａａａ”（“ａａａ”は当該鍵盤デバイスのサブアドレス）とされ、送信元アドレスがホストを示す“０００１ ０００”とされ、インデックスとされるデータ１が“９ｘｈ”、データ２がグループに振り分けるＬＥＤが設けられている鍵のノート番号（８ビット）、データ３が振り分けられる８ビットのグループ番号とされている。“ｘｈ”はポート番号とされており、ノート番号は８ビットとされているので、１６ポート×２５６個の鍵盤ＬＥＤコマンドを発行することができる。鍵盤ＬＥＤコントロールコマンドと鍵盤ＬＥＤコマンドによる鍵盤ＬＥＤの制御の態様は、ＬＥＤコントロールコマンドとＬＥＤコマンドによるパネルデバイスのＬＥＤの制御の態様と同様である。なお、鍵盤 ＯＦＦコマンド、鍵盤 ＯＮコマンドによれば各鍵盤デバイスの鍵は最大２５６個とされているので、鍵盤ＬＥＤコントロールコマンドと鍵盤ＬＥＤコマンドにおけるポート番号は、例えば、各鍵に複数色の複数ＬＥＤを用意して色の制御を行うために使用したり、あるいは、各鍵の複数個所にＬＥＤを用意して光る位置の制御を行うために使用することができる。
【００５２】
また、標準プロトコルにおけるホスト送信欄のパネルデバイスにおける電動ボリュームや電動ホイール等の操作値をホストから制御するコンティニュアスコントローラコマンドは、送信先アドレスがコントロールされるパネルデバイスのアドレス“００１１ ａａａ”（“ａａａ”は当該パネルデバイスのサブアドレス）とされ、送信元アドレスがホストを示す“０００１ ０００”とされ、インデックスとされるデータ１が“Ｂｘｈ”、データ２が電動ボリュームや電動ホイール等のコントローラの種別（８ビット）、データ３が８ビットの電動コントローラの制御値とされている。“ｘｈ”はポート番号とされており、種別は８ビットとされているので、１６ポート×２５６個のコンティニュアスコントローラコマンドを発行することができる。
【００５３】
また、標準プロトコルにおけるホスト送信欄のパネルデバイスにおけるロータリエンコーダ等の電動ジョグコントローラの操作値をホストから制御するＪＯＧコントローラコマンドは、送信先アドレスがコントロールされるパネルデバイスのアドレス“００１１ ａａａ”（“ａａａ”は当該パネルデバイスのサブアドレス）とされ、送信元アドレスがホストを示す“０００１ ０００”とされ、インデックスとされるデータ１が“Ｃｘｈ”、データ２が電動ジョグコントローラの種別（８ビット）、データ３が電動コントローラを制御する２の補数の相対値（８ビット）とされている。“ｘｈ”はポート番号とされており、種別は８ビットとされているので、１６ポート×２５６個のＪＯＧコントローラコマンドを発行することができる。
【００５４】
また、標準プロトコルにおけるホスト送信欄のパネルデバイスにおける電動ボリュームや電動ホイール等の操作値をホストから制御する１６ビットのコンティニュアスコントローラコマンドは、送信先アドレスがコントロールされるパネルデバイスのアドレス“００１１ ａａａ”（“ａａａ”は当該パネルデバイスのサブアドレス）とされ、送信元アドレスがホストを示す“０００１ ０００”とされ、インデックスとされるデータ１が“Ｅｘｈ”、データ２が電動コントローラの制御値の上位８ビット、データ３が電動コントローラの制御値の下位８ビットとされている。“ｘｈ”はポート番号とされているので、１６ポートの１６ビットのコンティニュアスコントローラコマンドを発行することができる。
【００５５】
次に、図９に示すＭＩＤＩプロトコルのコマンドについて説明する。ＭＩＤＩプロトコルは、ホスト系のデバイス（メインコントローラ）とＭＩＤＩ系のデバイスとが通信を行う場合に使用することのできる通信プロトコルとされている。ＭＩＤＩプロトコルにおけるコマンドは標準データおよび拡張データのデータフォーマットとが用いられる。なお、ＭＩＤＩプロトコルではホスト送信とホスト受信とのコマンドが共通とされており、ホスト受信とホスト送信では、送信先アドレスと送信元アドレスだけが異なるようになる。すなわち、ホスト受信のコマンドの場合は、送信先アドレスがホストのＭＩＤＩプロトコル用のアドレスである”０００１ ００１”とされ、送信元アドレスが送信するＭＩＤＩデバイスのアドレスとされる。また、ホスト送信のコマンドの場合は、送信先アドレスがＭＩＤＩデバイスのアドレスとされ、送信元アドレスがホストのＭＩＤＩプロトコル用のアドレスである”０００１ ００１”とされる。図９に示すＭＩＤＩプロトコルの各コマンドでは上述のように、送信先アドレスおよび送信元アドレスが設定され、以下のコマンドの説明では、各コマンドのデータ形式およびデータ部についてだけ説明するものとする。
【００５６】
ＭＩＤＩプロトコルにおける共通プロトコルのコマンドは、図７に示す共通プロトコルと同様であるのでその説明は省略する。
システムエクスクルーシブ（Sys EX）の開始および続きコマンドおよびシステムエクスクルーシブ（Sys EX）の終了または１パケットコマンドは、データフォーマットが共に拡張モードとされ１７バイト長とされている。システムエクスクルーシブ（Sys EX）の開始および続きコマンドは、システムエクスクルーシブの開始および続きを示すインデックスとされる”４ｉｈ”がデータ１とされ、データ２ないしデータ１５における１バイトずつのデータにより音色パラメータやシーケンス・データ等が転送される。システムエクスクルーシブ（Sys EX）の終了または１パケットコマンドは、システムエクスクルーシブの終了または１パケットを示すインデックスとされる”５ｉｈ”がデータ１とされ、１パケットの場合にデータ２ないしデータ１５において１パケットのデータが１バイトずつ転送される。
なお、ＭＩＤＩにおいてはシステムエクスクルーシブの開始は“Ｆ０ｈ”終了は“Ｆ７ｈ”で示されるが、Ｅバスシステムではこれに替えて上記のようにシステムエクスクルーシブの開始は“４ｉｈ”終了は“５ｉｈ”とし、“Ｆ０ｈ”、“Ｆ７ｈ”は使用しないこととしている。また、“ｉｈ”は、当該システムエクスクルーシブを送信するＭＩＤＩのポート番号を示す。
【００５７】
ソングポジション（Song Pos）コマンドは演奏を開始する位置を知らせるコマンドであり、標準データのデータフォーマットとされている。ソングポジションコマンドは、そのインデックスとされる“６ｉｈ”がデータ１とされ、データ２が演奏開始位置のポインターのＬＳＢとされ、データ３が演奏開始位置のポインターのＭＳＢとされる。なお、ＭＩＤＩではソングポジションポインターのメッセージは“Ｆ２ｈ”で示され、データ２およびデータ３はこのメッセージと互換とされている。
ＭＩＤＩポートセレクトコマンドは、カレントのＭＩＤＩポート番号（ノートオンメッセージ、ノートオフメッセージが授受されるＭＩＤＩポートの番号）を選択するコマンドであり、標準データのデータフォーマットとされている。ＭＩＤＩポートセレクトコマンドは、そのインデックスとされる“７ｉｈ”がデータ１とされ、データ２が“００ｈ”とされ、データ３が“００ｈ”とされる。例えば、ＭＩＤＩポートセレクトコマンドがホストからＭＩＤＩデバイスに送信された場合、受取ったＭＩＤＩデバイスではカレントのＭＩＤＩポート番号を上記インデックスに含まれる値“ｉｈ”に設定する。なお、ＭＩＤＩスタンダードではポートセレクトのメッセージは規定されていない（実装では“Ｆ５ｈ”が使われる場合もある）。なお、ＭＩＤＩポートセレクトコマンドはＭＩＤＩにおけるＭＩＤＩタイムピースメッセージの機能に相当する。
【００５８】
２つのＭＩＤＩ互換（note,vel）コマンドは、ＭＩＤＩにおけるノートオンメッセージおよびノートオフメッセージと互換とされており、標準データのデータフォーマットとされている。これらのコマンドにおいて、データ１がＭＩＤＩにおけるノートオフのインデックスとされる“８ｎｈ”とされ、データ２がＭＩＤＩ互換の８ビットのノートオフされたノート番号、データ３がＭＩＤＩ互換の８ビットのオフベロシティとされると、ノートオフコマンドとなる。また、データ１がＭＩＤＩにおけるノートオンのインデックスとされる“９ｎｈ”とされ、データ２がＭＩＤＩ互換の８ビットのノートオンされたノート番号、データ３がＭＩＤＩ互換の８ビットのベロシティとされると、ノートオンコマンドとなる。なお、データ１がＭＩＤＩにおけるノートオンのインデックスとされる“９ｎｈ”とされ、データ２がＭＩＤＩ互換の８ビットのノートオフされたノート番号、データ３が“００ｈ”（ベロシティがゼロ）とされたものをノートオフコマンドとして使用してもよい。なお、“ｎｈ”はＭＩＤＩチャンネル番号である。
【００５９】
ＭＩＤＩ互換（note,Aft）コマンドは、ＭＩＤＩにおけるポリフォニック・キー・プレッシャーメッセージと互換とされており、鍵ごとに独立したアフター・タッチ情報を送ることができるコマンドとされている。このコマンドは、標準データのデータフォーマットとされている。このコマンドでは、データ１がＭＩＤＩにおけるポリフォニック・キー・プレッシャーのインデックスとされる“Ａｎｈ”とされ、データ２がＭＩＤＩ互換の８ビットのアフター・タッチ情報を送るノート番号、データ３がＭＩＤＩ互換の８ビットのタッチ値とされる。なお、“ｎｈ”はＭＩＤＩチャンネル番号である。
ＭＩＤＩ互換（CtnNo. ,Value）コマンドは、ＭＩＤＩにおけるコントロール・チェンジメッセージと互換とされており、ダンパー・ペダル、ボリューム、モジュレーション、ホイールなどのコントローラの情報を送ることのできるコマンドとされている。このコマンドは、標準データのデータフォーマットとされている。このコマンドでは、データ１がＭＩＤＩにおけるコントロール・チェンジのインデックスとされる“Ｂｎｈ”とされ、データ２がコントロール機能を示すＭＩＤＩ互換の８ビットのコントロール番号、データ３がＭＩＤＩ互換の８ビットのコントロール値とされる。なお、“ｎｈ”はＭＩＤＩチャンネル番号である。
【００６０】
ＭＩＤＩ互換（PrgNo. ,00）コマンドは、ＭＩＤＩにおけるプログラム・チェンジメッセージと互換とされており、音色を切り替えるコマンドとされている。このコマンドは、標準データのデータフォーマットとされている。このコマンドでは、データ１がＭＩＤＩにおけるプログラム・チェンジのインデックスとされる“Ｃｎｈ”とされ、データ２がＭＩＤＩ互換の８ビットのプログラム番号、データ３はＭＩＤＩにおけるプログラム・チェンジメッセージでは必要とされていないので“００ｈ”とされる。なお、“ｎｈ”はＭＩＤＩチャンネル番号である。
ＭＩＤＩ互換（Aft,00）コマンドは、ＭＩＤＩにおけるチャンネル・プレッシャーと互換とされており、音色を切り替えるコマンドとされている。このコマンドは、標準データのデータフォーマットとされている。このコマンドでは、データ１がＭＩＤＩにおけるチャンネル・プレッシャーのインデックスとされる“Ｄｎｈ”とされ、データ２がＭＩＤＩ互換の８ビットのアフター・タッチ値、データ３はＭＩＤＩにおけるプログラム・チェンジメッセージでは必要とされていないので“００ｈ”とされる。なお、“ｎｈ”はＭＩＤＩチャンネル番号である。このコマンドは、代表とされるアフター・タッチ情報を送るコマンドであるので、複数ノートオンされていた場合は、全てのノートオンのアフター・タッチ情報となる。
【００６１】
ＭＩＤＩ互換（BendL,H）コマンドは、ＭＩＤＩにおけるピッチ・ベンドメッセージと互換とされており、ホイールやジョイスティックなどから構成されるピッチ・ベンダーの情報を送るコマンドとされている。このコマンドは、標準データのデータフォーマットとされている。このコマンドでは、データ１がＭＩＤＩにおけるピッチ・ベンドのインデックスとされる“Ｅｎｈ”とされ、データ２がＭＩＤＩ互換の８ビットのピッチ・ベンド値のＬＳＢ、データ３がＭＩＤＩ互換の８ビットのピッチ・ベンド値のＭＳＢとされる。なお、“ｎｈ”はＭＩＤＩチャンネル番号である。
【００６２】
ＭＩＤＩにおいては、ステータス“Ｆ０ｈ”〜“Ｆ７ｈ”が定義されている。ただし、ステータス“Ｆ４ｈ”、“Ｆ５ｈ”は未定義である。また、上述したようにＭＩＤＩにおけるシステム・エクスクルーシブの開始および終了のステータス“Ｆ０ｈ”、“Ｆ７ｈ”は、Ｅバスシステムのインデックス“４ｉｈ”、“５ｉｈ”に変換して使用しない。同様に、ＭＩＤＩにおけるステータス“Ｆ２ｈ”は、Ｅバスシステムのインデックス“６ｘｈ”に変換し、ＭＩＤＩにおけるステータス“Ｆ５ｈ”がMIDI Time Pieceとして定義されている場合は、Ｅバスシステムのインデックス“７ｘｈ”に変換する。このように、“Ｆ０ｈ”〜“Ｆ７ｈ”の一部のステータスを変換しているが、これは、標準データのフォーマットの中で、その一部のステータスについてバイト数を１バイト増やすため、あるいは、その増えたバイトでＭＩＤＩポート番号を指定できるようにするためである。また、ＭＩＤＩスタンダードでは、メッセージの各バイトの最上位ビットにより、そのバイトがステータスバイトであるかデータバイトであるかを判定するようになっているが、上述したＭＩＤＩプロトコルでは標準データのデータ１が必ずコマンドであるので、同様の目的で最上位ビットを使う必要がない。そこで、上述したＭＩＤＩプロトコルでは、ＭＩＤＩのステータスバイトから外れる“００ｈ”〜“７Ｆｈ”を、共通プロトコルのコマンドやＭＩＤＩを拡張するコマンドとして使用するようにしている。
【００６３】
さらに、Ｆ１（MIDI Timecode Quater Frame）コマンドは、ＭＩＤＩタイムコードにおける時／分／秒の情報を送るコマンドとされている。このコマンドは、標準データのデータフォーマットとされている。このコマンドでは、データ１がインデックスとされる“Ｆｉｈ”とされ、データ２がＭＩＤＩタイムコード・クォーター・フレームのステータスである“Ｆ１ｈ”、データ３がＭＩＤＩ互換の８ビットの時／分／秒の値とされる。
さらにまた、Ｆ３（Song Select）コマンドは、ソング・メモリや記憶媒体に記憶されている曲を選択するコマンドとされている。このコマンドは、標準データのデータフォーマットとされている。このコマンドでは、データ１がインデックスとされる“Ｆｉｈ”とされ、データ２がＭＩＤＩにおけるソング・セレクトのステータスである“Ｆ３ｈ”、データ３がＭＩＤＩ互換の８ビットのソング番号とされる。
【００６４】
さらにまた、Ｆ６（Tune Request）コマンドは、オート・チューニング機能のあるＭＩＤＩデバイスをチューニングするコマンドとされている。このコマンドは、標準データのデータフォーマットとされている。このコマンドでは、データ１がインデックスとされる“Ｆｉｈ”とされ、データ２がＭＩＤＩにおけるチューン・リクエストのステータスである“Ｆ６ｈ”、データ３はＭＩＤＩにおいて必要とされていないため“００ｈ”とされる。
【００６５】
さらにまた、システムリアルタイムメッセージコマンドは、リアルタイムで処理される必要のあるメッセージを送るコマンドである。このコマンドは、標準データのデータフォーマットとされている。このコマンドでは、データ１がインデックスとされる“Ｆｉｈ”とされ、データ２がＭＩＤＩにおけるシステムリアルタイムメッセージのステータスである“Ｆ８ｈ”〜“ＦＦｈ”のいずれか、データ３はＭＩＤＩにおいて必要とされていないため“００ｈ”とされる。なお、データ２は次のようになる。
機能がタイミング・クロックとされている場合は、ステータス“Ｆ８ｈ”
機能がスタートとされている場合は、ステータス“ＦＡｈ”
機能がコンティニューとされている場合は、ステータス“ＦＢｈ”
機能がストップとされている場合は、ステータス“ＦＣｈ”
機能がシステム・リセットとされている場合は、ステータス“ＦＦｈ”
なお、ステータス“Ｆ９ｈ”“ＦＤｈ”は未定義であり、ステータス“ＦＥｈ”はアクティブ・センシングとして定義されているが、本発明にかかるＥバスシステムにおいてはアクティブ・センシング（“ＦＥｈ”）は使用しない。なお、以上のデータ１が“Ｆｉｈ”となっているコマンドでは、“ｉｈ”は当該コマンドを送出するＭＩＤＩポート番号を示している。
【００６６】
次に、本発明にかかるＥバスシステムのＥバス起動手順を図１０に示すフローチャートに示す。
Ｅバスシステムにおいて電源を投入する（ステップＳ１）と、Ｅバス１１の４本の電源ラインを介して、Ｅバスシステムに接続されているデバイスの全てに電源が供給される。ここで、ホスト（メインコントローラデバイス１０）はＥバス１１におけるイニシャルクリアラインをＬレベルにする。これにより、Ｅバスシステムに接続されているデバイスが機能を停止してリセットされ、デバイスのハードウェア初期化が行われる（ステップＳ２）。次いで、ホスト（メインコントローラデバイス１０）はＥバス１１におけるイニシャルクリアラインをＨレベルにして、Ｅバスシステムに接続されているデバイスを起動する。これにより、Ｅバスシステムに接続されているデバイスにおいてソフトウェアが初期化される（ステップＳ３）。ここで、図７に示す「Ｅバススタート」コマンドをホスト（メインコントローラデバイス１０）がゼネラルコールで送信する（ステップＳ４）。Ｅバスシステムに接続されている各デバイスは、この「Ｅバススタート」コマンドを受信して動作開始し、これにより、Ｅバスシステムが動作開始するようになる。なお、前述したホスト系におけるカテゴリーＩＤ・サブアドレスリクエストのコマンドを使用したテーブルの作成は、この「Ｅバススタート」コマンドが送出された直後に行われる。
【００６７】
次に、本発明にかかるＥバスシステムにおけるホスト受信処理のフローチャートを図１１に示す。
図１１に示すホスト受信処理において、ホスト（メインコントローラデバイス１０）がＥバス１１から信号を受信すると、ステップＳ１０において受信した送信先アドレスが“１０ｈ”か“１２ｈ”かが判定される。この場合の送信先アドレスは、ホスト受信であることからアドレス指定されたホストのアドレスとなる。ただし、ステップＳ１０において判定されるホストのアドレスには、常時“０”とされるＲ／Ｗ用の１ビットが含まれている。そして、受信した送信先アドレスが“１０ｈ”（＝“０００１ ００００”）と判定された場合は、標準プロトコルのホストのアドレスが指定されていることから、ステップＳ１１に進み送信元アドレスの受信およびデータ１〜データ３からなるデータ部を受信する標準プロトコル受信処理が行われる。また、有効な信号を受信できた場合は１バイト毎にアクノリッジを返す。この標準プロトコル受信処理では、ホストは、例えば鍵盤デバイスからの鍵盤 ＯＦＦや鍵盤 ＯＮ等のコマンドを受信したり、パネルデバイスからのＳＷ ＯＮやコンティニュアスコントローラ等のコマンドを受信したりする。
【００６８】
さらに、受信した送信先アドレスが“１２ｈ”（＝“０００１ ００１０”）と判定された場合は、ＭＩＤＩプロトコルのホストのアドレスが指定されていることから、ステップＳ１２に分岐し送信元アドレスの受信およびデータ１〜データ３、あるいはデータ１〜データ１５からなるデータ部を受信するＭＩＤＩプロトコル受信処理が行われる。さらにまた、有効な信号を受信できた場合は１バイト毎にアクノリッジを返す。ステップＳ１１あるいはステップＳ１２の受信処理が終了すると、ホスト受信処理も終了する。このＭＩＤＩプロトコル受信処理では、ホストは、例えばＭＩＤＩ入出力デバイスからノートオンやノートオフ等のＭＩＤＩメッセージのコマンドを受信する。
【００６９】
次に、本発明にかかるＥバスシステムにおけるホスト送信処理のフローチャートを図１２に示す。
図１２に示すホスト送信処理において、ホスト（メインコントローラデバイス１０）がＥバス１１に送信する際には、ステップＳ２０においてアドレス指定した送信する送信先アドレスの上位４ビットが“２ｈ”〜“４ｈ”か“５ｈ”かが判定される。この場合の送信先アドレスの上位４ビットは、ホスト送信であることからホストがアドレス指定した送信先のデバイスのカテゴリーＩＤとなる。そして、送信する送信先アドレスの上位４ビットが“２ｈ”〜“４ｈ”（＝“０００１”〜“０１００”）と判定された場合は、鍵盤系、パネル系あるいは鍵盤／パネル複合系のデバイスが送信先のデバイスとされていることになる。これらのカテゴリーのデバイスは図５に示すように通信プロトコルが標準プロトコルとされていることから、ステップＳ２１に進み標準プロトコルにおけるホストのアドレスである“０００１ ０００”の送信元アドレスが付加され、次いでデータ１〜データ３からなるデータ部が送信される標準プロトコル送信処理が行われる。この標準プロトコル送信処理では、ホストは、例えばパネルデバイスに対してＬＥＤ番号ｉのＬＥＤを点灯させるＬＥＤコマンド（ＬＥＤ“ｉ”をグループ“ＦＦｈ”に振り分けるコマンド）を送信する。
【００７０】
また、送信する送信先アドレスの上位４ビットが“５ｈ”（＝“０１０１”）と判定された場合は、ＭＩＤＩ系のデバイスが送信先のデバイスとされていることになる。ＭＩＤＩ系のカテゴリーのデバイスは図５に示すように通信プロトコルがＭＩＤＩプロトコルとされていることから、ステップＳ２２に分岐しＭＩＤＩプロトコルにおけるホストのアドレスである“０００１ ００１”の送信元アドレスが付加され、次いでデータ１〜データ３、あるいはデータ１〜データ１５からなるデータ部が送信されるＭＩＤＩプロトコル送信処理が行われる。ステップＳ２１あるいはステップＳ２２の送信処理が終了すると、ホスト送信処理も終了する。このＭＩＤＩプロトコル送信処理では、ホストは、例えばＭＩＤＩシーケンサデバイスに対しノートオンやノートオフ等のＭＩＤＩメッセージのコマンドを送信する。
【００７１】
次に、本発明にかかるＥバスシステムにおける鍵盤デバイスの送信／受信処理のフローチャートを図１３に示す。
図１３に示す鍵盤送信／受信処理においては、通信プロトコルが標準プロトコルとされていることから、ステップＳ３０において標準プロトコル送信／受信処理が行われる。この標準プロトコル送信処理では、アドレス指定する送信先アドレスとして、ホストにおける標準プロトコルのアドレスである“０００１ ０００”を指定して送信し、送信元アドレスとして自機のアドレスを指定して送信する。自機のアドレスは、カテゴリーＩＤが“００１０”とされサブアドレスは自機に設定されている３ビットのアドレスとなる。これらのアドレスに続いてデータ１〜データ３からなるデータ部を送信する。
また、標準プロトコル受信処理では、アドレス指定された送信先アドレスが自機のアドレスと一致した場合に、後続する送信元アドレスおよびデータ１〜データ３からなるデータ部を受信する。この場合の送信元アドレスには、ホストにおける標準プロトコルのアドレスである“０００１ ０００”が指定されている。
標準プロトコルではパネル系および鍵盤／パネル複合系のデバイスも通信を行うが、この際の送信／受信処理はカテゴリーＩＤが異なるだけで上記した鍵盤送信／受信処理と同様の処理が行われる。
【００７２】
次に、本発明にかかるＥバスシステムにおけるＭＩＤＩデバイスの送信／受信処理のフローチャートを図１４に示す。
図１４に示すＭＩＤＩ送信／受信処理においては、通信プロトコルがＭＩＤＩプロトコルとされていることから、ステップＳ４０においてＭＩＤＩプロトコル送信／受信処理が行われる。このＭＩＤＩプロトコル送信処理では、アドレス指定する送信先アドレスとして、ホストにおけるＭＩＤＩプロトコルのアドレスである“０００１ ００１”を指定して送信し、送信元アドレスとして自機のアドレスを指定して送信する。自機のアドレスは、カテゴリーＩＤが“０１０１”とされサブアドレスは自機に設定されている３ビットのアドレスとなる。これらのアドレスに続いてデータ１〜データ３、あるいはデータ１〜データ１５からなるデータ部を送信する。
また、ＭＩＤＩプロトコル受信処理では、アドレス指定された送信先アドレスが自機のアドレスと一致した場合に、後続する送信元アドレスおよびデータ１〜データ３、あるいはデータ１〜データ１５からなるデータ部を受信する。この場合の送信元アドレスには、ホストにおけるＭＩＤＩプロトコルのアドレスである“０００１ ００１”が指定されている。
【００７３】
ところで、ホストは、鍵盤からの鍵盤 ＯＮコマンドに応じて、ＭＩＤＩのノートオンメッセージを生成し、該ノートオンメッセージに応じて音源ユニットにおける楽音生成を制御したり、Ｅバスを介して該ノートオンメッセージをＭＩＤＩデバイスに送出したりする。また、パネルからのＳＷ ＯＮコマンドを受信した場合、そのＳＷ ＯＮコマンドの種類に応じて、発音用の音色データの選択、音色データの編集、自動演奏用の楽曲データの録音／再生、楽曲データの編集、自デバイスの設定変更、Ｅバスに接続された各デバイスの設定変更、等の処理を行なう。さらに、音色データの選択時は、例えば、パネルデバイスに対してＬＥＤコマンドを送信して選択された音色データに対応したＬＥＤを点灯させるとともに、ＭＩＤＩデバイスに当該選択に対応したプログラムチェンジのメッセージを送出する。さらにまた、ホストにおいて楽曲データの再生をしている時（自動演奏時）は、順次再生されるＭＩＤＩメッセージに応じて音源ユニットの楽音生成を制御するとともに、Ｅバスを介して同ＭＩＤＩメッセージをＭＩＤＩデバイスに送出する。
【００７４】
以上説明した本発明によれば、電子楽器を構成するデバイス間の通信をバスシステムを通じて行えるようになる。この場合、マスターから送出されるデータ信号に送信先とされるデバイスに固有のアドレスが付与されており、該アドレスはデバイスのカテゴリーを表すカテゴリー情報と、同種のカテゴリーのデバイスの内のいずれか１つのデバイスを特定するサブアドレスとから構成されている。これにより、バスシステムを通じて種々のカテゴリーのデバイス間で通信を行うことができるようになる。従って、電子楽器において、例えばデバイスとして鍵盤を新たに開発した際には、その鍵盤を電子楽器用バスシステムに接続するだけで新規開発した鍵盤を備える電子楽器を構成することができる。この場合、他のカテゴリーのデバイス、例えばパネル系やホスト系のデバイスはそのまま流用して使用することができるようになる。
さらに、機能の追加に伴ってデバイスを追加する場合には、追加するデバイスを電子楽器用バスシステムに接続するだけで、新たなデバイスを追加した電子楽器を構成できるようになる。これにより、製品開発コストを著しく低下させることができるようになる。また、機能の追加を短時間で行うことができるようになる。
このように本発明においては、各デバイスを他の製品に流用することができると共に、デバイス毎に分けて開発することを可能とすることができる。
【００７５】
さらに、鍵盤やパネルの操作入力デバイスとＭＩＤＩデバイスとで主要なパケット長を第１所定長に統一することにより、各デバイスにおける受信処理を単純化することができる。さらにまた、バイト長が長くなりがちなシステムエクスクルーシブのみ第１所定長より長い第２所定長で通信を行なうようにすることにより、システムエクスクルーシブの通信効率が落ちないようになる。さらにまた、複数の表示要素を同時に制御することが可能であり、同時に制御すべき表示要素の組に変更があまりない場合は、表示制御のためのコマンドの発行回数を少なくすることができる。さらにまた、ＭＩＤＩメッセージに影響を与えずに、電子楽器用バスシステムにおいてＭＩＤＩメッセージを送受信することができるようになる。
【産業上の利用可能性】
【００７６】
上記の説明では、鍵盤デバイスやパネルデバイスに備えられている各ＬＥＤはいずれか１つのグループに属するようになっていたが、１つのＬＥＤを複数のグループに所属させることができるようにしてもよい。その場合、そのＬＥＤの制御値は、そのＬＥＤが所属するグループの制御値の最大値、最小値、あるいは合成値とすればよい。また、上記の説明ではＥバスに接続されるデバイスとして「ホスト系」「鍵盤系」「パネル系」「ＭＩＤＩ系」を示したが、さらにこれ以外の種類のデバイスを接続するようにしてもよい。さらに、上記の説明ではＥバス上のデータのプロトコルとして「共通プロトコル」「標準プロトコル」「ＭＩＤＩプロトコル」の３つを示したが、さらにこれ以外のプロトコルを使用するようにしてもよい。
以上説明した本発明にかかるＥバスシステムは、アイ・スケア・シー（Ｉ2Ｃ）バスをベースとしている。そして、Ｅバスシステムにおいて言及しなかった点についてはＩ2Ｃバスに準拠している。
【符号の説明】
【００７７】
１ 電子楽器、１０ メインコントローラデバイス、１０ａ メイン基板、１１ Ｅバス、１２，１３ パネルデバイス、１２ａ パネル基板、１４，１５ 鍵盤デバイス、１４ａ 鍵盤基板、１６ ＭＩＤＩデバイス、１６ａ 基板、１７ 分岐基板、２１ バス、２２，２３，２４ 音源ユニット、２５，２６ Ｉ／Ｏユニット、３１ バス、３２ サウンドシステム、Ｂ１〜Ｂ６ バッファ、Ｒｐ プルアップ抵抗、ＴＲ１〜ＴＲ６ トランジスタ
【技術分野】
【０００１】
本発明は、電子楽器に内蔵されるに適している電子楽器用バスシステムに関する。
【背景技術】
【０００２】
従来の電子楽器において、１つのＣＰＵ（Central Processing Unit）だけを有している電子楽器においては、鍵盤における各鍵の操作を検出する鍵盤スイッチや音色設定等の各種設定を行うパネルスイッチ等のパネル操作子は、パラレルＩ／Ｏ（Input-output）に接続されている。そして、パラレルＩ／Ｏを介して鍵盤スイッチやパネル操作子の操作情報をＣＰＵが取り込んで、取り込まれた操作情報に基づく音源パラメータを生成し、発音タイミングに対応させてその音源パラメータを音源に転送することにより発音するようにしている。
【０００３】
また、従来の電子楽器において、複数のＣＰＵを備えている電子楽器も知られている。このように複数のＣＰＵを備えている電子楽器においては、複数のＣＰＵで機能を分担するようにしている。例えば、鍵盤ＣＰＵは、鍵盤スイッチのスキャンを行い各鍵の操作情報を検出して出力するようにしており、パネルＣＰＵは、パネル操作子のスキャンを行い各パネル操作子の操作情報を検出して出力したり、パネル表示器の表示制御等を行っている。また、メインＣＰＵは、鍵盤ＣＰＵから鍵盤の操作信号を、パネルＣＰＵからパネル操作子の操作情報を受けて、操作情報に基づく音源パラメータを生成し、発音タイミングに対応させてその音源パラメータを音源に転送することにより発音するようにしている。この場合、メインＣＰＵは、鍵盤ＣＰＵおよびパネルＣＰＵとそれぞれ独立してシリアル通信路により接続されており、このシリアル通信路を介して相互に通信を行っている。
【発明の概要】
【発明が解決しようとする課題】
【０００４】
従来のＣＰＵを１つだけ備える電子楽器においては、製品毎に機能や形状が異なることから電子楽器に内蔵される基板をその都度設計して搭載しなければならず、既に開発された製品や他の製品に搭載した基板を流用することができないという問題点があった。
【０００５】
また、従来の複数のＣＰＵを備える電子楽器においては、各製品毎にメインＣＰＵと鍵盤ＣＰＵとの通信仕様、および、メインＣＰＵとパネルＣＰＵとの通信仕様を決定するようにしていたため、既に開発された製品や他の製品に搭載した各種基板間においては相互に接続することができない場合があり、それらの基板を流用することができないという問題点があった。さらに、例えば複数の鍵盤が必要とされる場合は、鍵盤ＣＰＵを搭載した新たな鍵盤基板をメインＣＰＵが搭載されたメイン基板に接続しなければならない。すると、新たな接続ハードウェアをメイン基板に追加しなければならず、メイン基板を開発し直さなければならないという問題点があった。
【０００６】
そこで、本発明は、電子楽器を構成する複数種類のデバイスの間で行う通信を、バスにデバイスを接続することでバスを通じて通信を行うことのできる電子楽器用バスシステムを提供することを目的としている。
【課題を解決するための手段】
【０００７】
上記目的を達成するために、本発明は、双方向シリアルバスに接続されているホストデバイスと、操作入力デバイスと、ＭＩＤＩデバイスとを接続して電子楽器を構成することを最も主要な特徴としている。
【発明の効果】
【０００８】
このような発明によれば、ホストデバイスが接続されているバスに、鍵盤やパネルの操作入力デバイスや、ＭＩＤＩデバイスを任意に接続して電子楽器を構成することができるようになる。
【図面の簡単な説明】
【０００９】
【図１】本発明の電子楽器用バスシステムが適用されている電子楽器の実施例におけるハードウェア構成を示すブロック図である。
【図２】本発明の実施例にかかる電子楽器用バスシステムの結線の概要を示す構成図である。
【図３】本発明の実施例にかかるＥバスシステムの具体的構成を示す図である。
【図４】本発明の実施例にかかるＥバスシステムにおけるＳＣＬラインとＳＤＡラインにおけるデータ転送時の波形タイミング図を示す図である。
【図５】本発明の実施例にかかるＥバスシステムにおけるカテゴリーＩＤ、サブアドレス範囲、カテゴリー名および適応される通信プロトコルを示すテーブルである。
【図６】本発明の実施例にかかるＥバスシステムにおけるデータフォーマットを示す図である。
【図７】本発明の実施例にかかるＥバスシステムにおける共通プロトコルのホスト送信およびホスト受信のコマンドを示す図表である。
【図８】本発明の実施例にかかるＥバスシステムにおける標準プロトコルのホスト送信およびホスト受信のコマンドを示す図表である。
【図９】本発明の実施例にかかるＥバスシステムにおけるＭＩＤＩプロトコルのホスト送受信のコマンドを示す図表である。
【図１０】本発明の実施例にかかるＥバスシステムにおけるＥバス起動手順を示すフローチャートである。
【図１１】本発明の実施例にかかるＥバスシステムにおけるホスト受信処理のフローチャートである。
【図１２】本発明の実施例にかかるＥバスシステムにおけるホスト送信処理のフローチャートである。
【図１３】本発明の実施例にかかるＥバスシステムにおける鍵盤送信／受信処理のフローチャートである。
【図１４】本発明の実施例にかかるＥバスシステムにおけるＭＩＤＩ送信／受信処理のフローチャートである。
【発明を実施するための形態】
【００１０】
本発明の電子楽器用バスシステムが適用されている電子楽器における実施例のハードウェア構成をブロック図で図１に示し、本発明の電子楽器用バスシステムの結線の概要を図２に示す。
本発明の電子楽器用バスシステムは、図１に示す電子楽器１に内蔵されているＥバス１１からなるＥバスシステム、および図２に示すＥバス１１からなるＥバスシステムとして示されている。このＥバスシステムにおけるＥバス１１には、メインＣＰＵ（Central Processing Unit）やメインＲＯＭ（Read Only Memory）、メインＲＡＭ（Random Access Memory）等が搭載されているメイン基板１０ａを備えるメインコントローラデバイス１０（ホストデバイス）と、パネルＣＰＵやパネルＲＯＭ、パネルＲＡＭ等が搭載されているパネル基板１２ａ、１３ａをそれぞれ備えるパネルデバイス１２，１３と、鍵盤ＣＰＵや鍵盤ＲＯＭ、鍵盤ＲＡＭ等が搭載されている鍵盤基板１４ａ、１５ａをそれぞれ備える鍵盤デバイス１４，１５と、ＭＩＤＩＣＰＵやＭＩＤＩＲＯＭ、ＭＩＤＩＲＡＭ等が搭載されているＭＩＤＩ基板１６ａを備えるＭＩＤＩデバイス１６とが接続されている。
【００１１】
メインコントローラデバイス１０は、電子楽器１の全体の動作を制御することにより、鍵盤デバイス１４，１５やパネルデバイス１２，１３から取り込んだ鍵盤スイッチやパネル操作子の操作情報に基づく楽音を発生するための制御処理や、ＭＩＤＩデバイス１６から受信したＭＩＤＩ（Musical Instrument Digital Interface）メッセージに応じた楽音を発生するための制御処理を行っている。また、メインコントローラデバイス１０におけるメイン基板１０ａに搭載されているメインＲＯＭには、メインＣＰＵが実行する制御プログラムや、音色データ、伴奏パターン、楽曲データ等のプリセットデータが格納されている。さらに、メイン基板１０ａに搭載されているＲＡＭには、メインＣＰＵが制御プログラム等を実行する際に使用するワーキングメモリ領域、音色データや伴奏パターン等のユーザ領域等が設定される。
【００１２】
また、パネルデバイス１２，１３には、音色設定やエフェクト設定用のパネルスイッチや、ボリュームやホイール等のコンティニュアスコントローラ、ＪＯＧコントローラ等のパネル操作子が設けられており、音色の選択や音色パラメータを変更することができるようにされている。パネルＣＰＵは、パネルデバイス１２，１３に設けられているパネル操作子をスキャンしてその操作イベントや操作量を検出している。この場合、パネル操作子によっては操作量を相対値で検出するようにする。パネルデバイス１２，１３におけるパネル基板１２ａ、１３ａにそれぞれ搭載されているパネルＲＯＭには、パネルＣＰＵが実行するスキャンプログラム等が格納されている。さらに、パネル基板１２ａ、１３ａにそれぞれ搭載されているパネルＲＡＭには、パネルＣＰＵがスキャンプログラム等を実行する際に使用するワーキングメモリ領域等の領域が設定される。
【００１３】
さらにまた、鍵盤デバイス１４，１５には、複数の鍵と各鍵の操作に応じてオン／オフする鍵盤スイッチが設けられている。鍵盤ＣＰＵは、鍵盤デバイス１４，１５に設けられている鍵盤スイッチをスキャンして、ノートオン／ノートオフのキーイベントやベロシティおよびアフタータッチの値を検出している。鍵盤デバイス１４，１５における鍵盤基板１４ａ、１５ａにそれぞれ搭載されている鍵盤ＲＯＭには、鍵盤ＣＰＵが実行するスキャンプログラム等が格納されている。さらに、鍵盤基板１４ａ、１５ａにそれぞれ搭載されている鍵盤ＲＡＭには、鍵盤ＣＰＵがスキャンプログラム等を実行する際に使用するワーキングメモリ領域等が設定される。
【００１４】
さらにまた、ＭＩＤＩデバイス１６は、ＭＩＤＩ端子やTo Host端子を備えたＭＩＤＩ入出力デバイス、自動演奏が可能なＭＩＤＩシーケンスデバイス、ＭＩＤＩ鍵盤等のＭＩＤＩ対応のデバイスであり、ホストコンピュータに接続するためのTo Host端子を備えることができる。Ｅバスシステムにおいては、ＭＩＤＩデバイス１６は、演奏データや演奏関連データをＭＩＤＩのフォーマットのままで送受信することができるようにされている。ＭＩＤＩＣＰＵは、ＭＩＤＩデバイス１６の動作を制御しており、ＭＩＤＩデバイス１６におけるＭＩＤＩ基板１６ａに搭載されているＭＩＤＩＲＯＭには、ＭＩＤＩＣＰＵが実行するＭＩＤＩ制御プログラムやＭＩＤＩ制御データが格納されている。さらに、ＭＩＤＩ基板１６ａに搭載されているＭＩＤＩＲＡＭには、ＭＩＤＩＣＰＵがＭＩＤＩ制御プログラム等を実行する際に使用するワーキングメモリ領域等が設定される。なお、ＭＩＤＩデバイス１６にTo Host端子を設けると、電子楽器１をTo Host端子付きモデルとすることができる。
【００１５】
図１および図２に示す電子楽器１において、メインコントローラデバイス１０は、メインコントローラデバイス１０とパネルデバイス１２，１３、鍵盤デバイス１４，１５およびＭＩＤＩデバイス１６との間を接続しているＥバス１１を介して、演奏イベントデータや音色等に関する演奏関連データを受け取り、イベント開始時刻に達した際にバス２１を介して音源ユニット２２，２３，２４に音源制御データを送り楽音の生成を開始させる。音源ユニット２２，２３，２４で生成された楽音はバス３１を介してサウンドシステム３２に供給されて、サウンドシステム３２から放音されるようになる。バス２１には、Ｉ／Ｏユニット２５，２６を介して他のユニットを接続することができる。
【００１６】
ところで、本発明の実施例にかかるＥバスシステムに、メインコントローラデバイス１０、パネルデバイス１２，１３、鍵盤デバイス１４，１５およびＭＩＤＩデバイス１６を接続する場合には、図２に示すようにそれぞれのデバイスにおける基板のバス端子に、Ｅバス１１を構成しているワイヤーの一端に設けられているコネクタを装着する。このワイヤーの他端は、分岐基板１７におけるＥバス１１を構成している信号線および電源線にそれぞれ接続されている。このように、それぞれのデバイスの基板にＥバス１１のコネクタを装着することにより、そのデバイスをＥバスシステムに接続することができる。このため、必要に応じてデバイスをＥバス１１のコネクタから脱着することにより、Ｅバスシステムからデバイスの追加／取り外しを可能とすることができる。なお、Ｅバスシステムに接続されたデバイスにはＥバス１１から電源が供給されるようになる。図２に示す構成の場合は、分岐基板１７に図示しない電源部から電源が供給されている。そして、Ｅバス１１のコネクタは例えば７ピンとされ、そのうち３ピンが信号線用として使用され、残る４ピンが電源用として使用される。
【００１７】
本発明の実施例にかかるＥバスシステムを電子楽器１に用いるようにすると、例えば電子楽器１をオルガン型の２段鍵盤電子楽器モデルとしたい場合には、図２に示すように鍵盤デバイス１４と鍵盤デバイス１５とをそれぞれメイン基板、パネル基板等の接続されたＥバスのコネクタに装着すればよいようになる。また、３段鍵盤電子楽器モデルとしたい場合は、さらに鍵盤デバイスをＥバス１１のコネクタに装着すればよい。さらに、メイン基板、パネル基板、鍵盤基板をＥバスに接続した電子楽器において、鍵盤デバイスのみを交換することにより、例えば６１鍵電子楽器モデルから７６鍵電子楽器モデルとすることができる。さらにまた、パネルデバイスを交換することにより、パネルスイッチの多いモデルや少ないモデルに対応させることができる。このように、電子楽器を構成する複数基板のうちの一部の基板を、自由に追加、削除、あるいは変更することが可能である。
【００１８】
本発明にかかる電子楽器用バスシステムであるＥバスシステムについて、以下に詳細に説明する。
Ｅバスシステムは、双方向シリアルバスとされており、信号線はシリアルクロックライン（以下、「ＳＣＬライン」という）と、シリアルデータライン（以下、「ＳＤＡライン」という）と、イニシャルクリアラインの３本とされている。この場合、ＳＤＡラインにはＳＣＬラインに送出されるクロックに同期したデータ信号が送出される。そして、イニシャルクリアラインには、Ｅバスシステムの立ち上げ時やリセット時にリセット信号が送出される。Ｅバスシステムの電源ラインは４本とされており、この電源ラインからＥバスシステムに接続されているデバイスに電源が供給されている。Ｅバスシステムの通信速度は、１００ｋｂｐｓ、４００ｋｂｓまたは３．４Ｍｂｐｓのいずれかとすることができる。
【００１９】
また、Ｅバスシステムには、複数のデバイスを順次接続（バス型接続）することができ、接続されたデバイスは、唯一無二の固有のアドレスを持つようにされている。この固有のアドレスは、例えば７ビットとされる。この固有のアドレスのテーブルを図５に示すが、固有のアドレスは４ビットのカテゴリーＩＤと３ビットのサブアドレスから構成される。カテゴリーＩＤは、デバイスのカテゴリーの種類を示しており、サブアドレスは同種のカテゴリーのデバイスの内の自デバイスを示すアドレスである。カテゴリー種類を示す上位アドレスであるカテゴリーＩＤは、そのデバイスの基板の作成時においてデバイスのカテゴリー種類に応じて予め設定されており、サブアドレスは電子楽器１に組み込まれる際に他の同種のデバイスのサブアドレスと重複しないようにジャンパピンやディップスイッチにより設定される。なお、カテゴリーの種類は、メインコントローラデバイス１０が属するホスト系、鍵盤デバイス１４，１５が属する鍵盤系、パネルデバイス１２，１３が属するパネル系、ＭＩＤＩデバイスが属するＭＩＤＩ系、鍵盤／パネルが複合されている鍵盤／パネル複合系とされる。
【００２０】
Ｅバスシステム上のデバイス間の通信は、マスター・スレーブ動作による通信とされ、マルチ・マスター可能とされている。なお、マスターとはＥバスシステム上でデータ転送を開始すると共に、転送を可能にするクロックパルスを生成してＳＣＬラインに送出し、さらにデータ転送を終了することのできるデバイスである。また、スレーブはマスターによってアドレス指定される送信先のデバイスである。なお、マルチ・マスターとはメッセージを失うことなく、複数のマスターが同時にＥバスシステムをコントロールすることができることをいう。
【００２１】
さらに、Ｅバスシステムにおいて、複数のマスターが同時にＥバスシステム上にデータを転送しようとした際には、データ破壊を防止するためにデータの衝突検出機能およびアービトレーション（調停）の機能が備えられている。Ｅバスシステムでは、送信先のデバイスにおけるカテゴリー名の優先順位に従うアービトレーションが行われる。カテゴリー名は、カテゴリーの種類を拡張したものであり、図５に固有のアドレスとカテゴリー名とのテーブルが示されている。その優先順位は、カテゴリー名が全てのデバイスが送信先とされるゼネラルコールの優先順位が最も高くされ、カテゴリー名がホスト系の優先順位が２番目とされ、カテゴリー名が鍵盤系の優先順位が３番目とされ、カテゴリー名が鍵盤／パネル複合系の優先順位が４番目とされ、カテゴリー名がパネル系の優先順位が５番目とされ、カテゴリー名がＭＩＤＩ系の優先順位が最後とされている。これらの優先順位は、重要度およびリアルタイム性を勘案して決められている。
【００２２】
さらにＥバスシステムでは、送信元アドレスおよび送信先アドレスにおいて、該アドレスの属するカテゴリー名に対応する通信プロトコルを使用して通信するようにしている。図５に、カテゴリー名と通信プロトコルとのテーブルを示している。図５に示すように、鍵盤デバイス１４，１５が属する鍵盤系あるいはパネルデバイス１２，１３が属するパネル系と、メインコントローラデバイス１０が属するホスト系との間で通信を行う場合は、マンマシンインタフェース用プロトコルである後述する標準プロトコルを使用して通信が行われる。また、ＭＩＤＩデバイス１６が属するＭＩＤＩ系とメインコントローラデバイス１０が属するホスト系との間で通信を行う場合は、演奏情報伝達用プロトコルである後述するＭＩＤＩプロトコルを使用して通信が行われる。また、カテゴリー名がゼネラルコールの場合は、制御用プロトコルである後述する共通プロトコルを使用して、ホスト系は、鍵盤系、パネル系、ＭＩＤＩ系と通信を行う。共通プロトコルは、標準プロトコルおよびＭＩＤＩプロトコルの共通部分から構成されている。なお、ゼネラルコールのアドレス「００００ ０００」に送信を行なえるのはホスト系のみであり、他の鍵盤系、パネル系、ＭＩＤＩ系のデバイスが共通プロトコルによる送信を行ないたい場合は各自の固有のアドレスを使用する。
【００２３】
このように、ホスト系のメインコントローラデバイス１０は、カテゴリー名に適応する通信プロトコルで通信を行うことができるようにされている。ホスト系が他のカテゴリー名のデバイスと通信を行う際には、通信プロトコルを決定する必要があるが、通信に先立ってホスト系は送信先アドレスをアドレス指定する。この送信先アドレスは、デバイスにおける固有のアドレスであり、固有のアドレスの上位４ビットはカテゴリーＩＤとなっている。そこで、ホスト系は送信先アドレスから通信相手であるデバイスのカテゴリー名および使用する通信プロトコルを図５のテーブルを参照して知ることができる。なお、図５に示すようにホストには、ホスト系の２つの通信プロトコルに対応する２つの固有アドレスが与えられており、通信相手とされるデバイスのカテゴリー名に適応する通信プロトコルのアドレスを用いて通信を行うようにしている。それ以外に、ホスト系のデバイスは標準プロトコルによる通信を行うことができるが、そこでは該２つの固有アドレスとゼネラルコールのアドレスの内の何れかを使用する。
【００２４】
次に、本発明にかかるＥバスシステムの具体的構成を図３に示す。ただし、図３においてはＥバスシステムを構成する７本のワイヤーのうちのＳＣＬラインとＳＤＡラインとの２本の信号線だけを示している。なお、図示していない信号線はイニシャルクリアライン（Ｅ−ＩＣ）であり、残る４本のワイヤーは電源ラインとされている。
図３に示すように、デバイス１（Device1）、デバイス２（Device2）、デバイス３（Device3）はＳＣＬラインおよびＳＤＡラインにそれぞれバス接続されている。それぞれのデバイスとＳＣＬラインおよびＳＤＡラインとの結線構成は同様とされているので、デバイス１についてのみ説明する。デバイス１において、クロックが転送されるＳＣＬラインにはクロック入力部（SCL IN）とされるバッファＢ２が接続されており、バッファＢ２を介してクロックパルスがデバイス１に取り込まれる。また、ＳＣＬラインにはクロック出力部（SCL OUT）とされるオープンドレインとされた電界効果トランジスタ（以下、「トランジスタ」という）ＴＲ２のドレインが接続され、トランジスタＴＲ２をオン／オフすることによりクロックパルスをＳＣＬラインに送出することができる。さらに、データ信号が転送されるＳＤＡラインにはデータ入力部（SDA IN）とされるバッファＢ１が接続されており、バッファＢ１を介してデータ信号がデバイス１に取り込まれる。また、ＳＤＡラインにはデータ出力部（SDA OUT）とされるオープンドレインとされたトランジスタＴＲ１のドレインが接続され、トランジスタＴＲ１をオン／オフすることによりデータ信号をＳＤＡラインに送出することができる。
【００２５】
デバイス２およびデバイス３においても同様の回路構成でＳＣＬラインおよびＳＤＡラインに接続されている。なお、図３に示すデバイス１〜デバイス３においては、トランジスタＴＲ１ないしトランジスタＴＲ６は電界効果トランジスタとしたが、オープンコレクタとされたバイポーラトランジスタとしてもよい。また、ＳＣＬラインおよびＳＤＡラインはプルアップ抵抗Ｒｐによりそれぞれプルアップされている。すなわち、ＳＣＬラインおよびＳＤＡラインは開放状態ではハイ（Ｈ）レベルとなっており、デバイスにおけるデータ出力部のいずれかのトランジスタＴＲ１，ＴＲ３，ＴＲ５・・・がオンされることによりＳＤＡラインはロー（Ｌ）レベルとなる。すなわち、ＳＤＡラインにデバイス１〜デバイス３のデータ出力部がワイヤードアンド接続されている。ＳＣＬラインも同様に開放状態ではＨレベルとなり、デバイスにおけるクロック出力部のいずれかのトランジスタＴＲ２，ＴＲ４，ＴＲ６・・・がオンすることによりＳＣＬラインはＬレベルとなる。すなわち、ＳＣＬラインにデバイス１〜デバイス３のクロック出力部がワイヤードアンド接続されている。
【００２６】
このようなＥバスシステムにおけるＳＣＬラインとＳＤＡラインにおけるデータ転送時の波形タイミング図を図４に示す。Ｅバスシステムにおいては、バスが開放状態（Ｈレベル）の時のみにデータ転送を開始することができ、データの転送開始時には、マスターはスタートビット（Start Bit）を転送する。この場合、ＳＣＬラインがＨレベル（開放状態）とされている際に、ＳＤＡラインをＬレベルに反転することによりスタートビットが図示するように送出される。このスタートビットをＥバスシステムに接続されているデバイスが検出することにより、デバイスはデータ転送が開始されることを知る。次いで、データ部に前置して置かれたヘッダ部が転送される。データ部は複数バイト（１バイト＝８ビット）で構成されており、ヘッダ部も複数バイトで構成されている。このヘッダ部では、７ビットの送信先アドレス（スレーブアドレス）と、データの読込／書込（Ｒ／Ｗ）を指示する１ビットとで最初の１バイトが構成され、７ビットの送信元アドレス（マスターアドレス）と“０”のダミービットの１ビットとで次の１バイトが構成されている。ヘッダ部に続いて、１バイト単位のデータが後述するように３バイトあるいは１５バイト連続しているデータ部が転送される。また、ヘッダ部およびデータ部の各ビットに同期してＳＣＬラインにクロックパルスが送出される。この場合、ヘッダ部およびデータ部は１バイト単位のデータで構成されていることから、ヘッダ部およびデータ部の１バイト毎に、図示するように各ビットに同期したクロックパルスが１，２，３・・・，８の８発送出される。なお、ヘッダ部およびデータ部における各ビットのレベルを反転できるタイミングは、クロックパルスがＬレベルとされている期間とされ、各ビットのデータが有効となるようにクロックパルスがＨレベルの期間においては、ＳＤＡラインのレベルを安定させて転送しなければならない。
【００２７】
Ｅバスシステムにおいてはマスターから送出されるクロックパルスやヘッダ部およびデータ部は、ＳＣＬラインおよびＳＤＡラインを介して全てのデバイスに到達する。そこで、各デバイスは最初に受信されるヘッダ部におけるスレーブアドレスと自機に固有のアドレスとを１ビットずつ対比していく。そして、７ビットのスレーブアドレスと自機のアドレスとが一致した場合は、自機がスレーブとしてアドレス指定されたと知り以後に続くデータを受信する。また、ＳＤＡラインのレベルがＬ（ｏｒＨ）であるのに、対応する自機のアドレスのビットが“１”（ｏｒ”０”）であった場合は、自機のアドレスがスレーブアドレスとしてアドレス指定されておらず、自機はデータ転送先でないと判断して以後に続く受信データは捨てるようにする。これにより、アドレス指定したデバイスだけがデータを受信することができる。
なお、ヘッダ部においてはそれぞれのバイトにおける８ビット目が、データの読込／書込を指示するビットとされているが、Ｅバスシステムにおいてはこのビットは常にＬ（＝“０”）とされて、書き込みしか存在しないデータフォーマットとされている。電子楽器では鍵盤、パネル等の操作に対するリアルタイムな応答が求められているが、このように、鍵盤系、パネル系における操作イベントを書き込みによりホスト系へ送信することによりそのレスポンスを高めている。
【００２８】
ところで、マスターはＳＤＡラインに送出したヘッダ部あるいはデータ部における１バイト毎の信号が正常に受信されたことを知った後に、次の１バイトの信号を送出するようにしている。そこで、１バイトの信号が送出された後に、１バイトの信号が有効な信号として受信されたか否かを示すアクノリッジ用の９番目のクロックパルス（ＡＣＫ）を、マスターはＳＣＬラインに送出している。同時に、マスターはＳＤＡラインを開放してＨレベルの状態にしている。そして、ヘッダ部のスレーブアドレスでアドレス指定された送信先のデバイスは、１バイトの信号が有効な信号として受信された際に、データ出力部のトランジスタをオンさせて、ＳＤＡラインをＬレベルに保持する。マスターは、９番目のＡＣＫ用クロックがＨレベルとなった期間においてＳＤＡラインのレベルを取り込んで、アクノリッジがＬレベルならば正常に送信先のデバイスが１バイトの信号を受信したことを知る。これにより、マスターは次の１バイトをＳＤＡラインに送出可能となる。この際に、送信先のデバイスは受信準備できるまでＳＣＬラインをＬレベルに保持する。マスターは、所定の時間の後に、次の１バイトを最初のビットよりＳＤＡラインに順次送出開始すると共に、同期するクロックパルスをＳＣＬラインに送出開始する。ここで、送信先のデバイスの受信準備ができている場合、ＳＣＬラインのクロックパルスが順次立ち上がり、送信先のデバイスではそのクロックパルスに応じて、次の１バイトのデータを取り込むことができる。一方、その時点で送信先のデバイスの準備ができていない場合、該送信先のデバイスによりＳＣＬラインはＬレベルに保持されている。従って、マスターが送出しようとしたクロックパルスはＳＣＬラインに現れず、マスターはＳＣＬラインが立ち上がるのを待つ。送信先のデバイスの受信準備が完了すると、ＳＣＬラインは解放されるのでクロックパルスがＳＣＬラインにおいて立ち上がり、次の１バイトの送信が行われる。
なお、送信先のデバイスが有効な１バイトの信号を受信することができなかった場合は、Ｈレベルのアクノリッジが生成されて、このアクノリッジをマスターが受け取るようになる。この場合、マスターはＳＣＬラインをＨレベルに保持した状態でＳＤＡラインをＨレベルに反転させることによりストップビット（Stop Bit）を送出し、データ転送を中止するようにする。このストップビットは、通信を終了する際においても、マスターによりＥバス１１上に送信される。
【００２９】
次に、アービトレーションについて説明する。Ｅバスシステムにおいては、バスが開放状態（Ｈレベル）の時のみにデータ転送を開始することができるが、複数のデバイスがマスターとしてほぼ同時にデータ転送を開始することがある。この場合は、いずれかのマスターに通信を許可するアービトレーションが行われる。このアービトレーションでは、ＳＤＡラインに各デバイスのデータ出力部のトランジスタがワイヤードアンド接続されていることを利用している。具体的に説明すると、データ転送開始した際には、図４に示すようにスタートビットに続いてスレーブアドレスがＳＤＡラインに送出されるので、複数のマスターにおいてこのＳＤＡラインから受信したアドレスと自機がアドレス指定したスレーブアドレスとを１ビットずつ対比する。この場合、同時に複数のデバイスからデータがＳＤＡラインに送出された場合には、ワイヤードアンドされていることからいずれかのデバイスがＬレベルを送出した際にＳＤＡラインはＬレベルに保持されるようになる。
【００３０】
すると、デバイスによっては自機が指定したスレーブアドレスの対比するビットが“１”であるのに対して、ＳＤＡラインから取り込まれたビットが“０”（＝Ｌレベル）となる。このようにアドレスが不一致となった場合は、他のマスターの優先順位が高いと判断してデータ出力部をオフする。この処理を続けると、最終的に優先順位の最も高いマスターに通信が許可されるようになる。この場合の優先順位は、上述したように、ＳＤＡラインのレベルはＬレベルが優先とされていることから、スレーブアドレスとして最上位ビット（ＭＳＢ）から多く“０”が続くアドレスの優先順位が高いことになる。アービトレーションにおける優先順位はカテゴリー名により決定されており、前述したようにゼネラルコールの順位が最も高くされ、２番目の順位はホスト系（メインコントローラ）のデバイスが送信先の場合とされ、３番目の順位は鍵盤系のデバイスが送信先の場合とされ、４番目の順位はパネル系のデバイスが送信先の場合とされ、５番目の順位はＭＩＤＩ系のデバイスが送信先の場合とされている。なお、鍵盤系の順位が高くされているのは、鍵盤ではリアルタイム性が重要となるからである。
【００３１】
このような理由から、図５に示すようにカテゴリーＩＤをカテゴリー名の優先順位に応じて各カテゴリーに付与している。図５は、カテゴリーＩＤ、サブアドレス範囲、カテゴリー名および使用される通信プロトコルの種類を示すテーブルである。図５に示すテーブルにおいてカテゴリーＩＤを参照すると、全てのデバイスに転送するゼネラルコールのカテゴリーＩＤは”００００”とされ、“０”が最も長く続くようにされている。また、ホスト系（メインコントローラ）のカテゴリーＩＤは”０００１”とされ、鍵盤系のカテゴリーＩＤは”００１０”とされ、パネル系のカテゴリーＩＤは”００１１”とされ、鍵盤／パネル複合系のカテゴリーＩＤは”０１００”とされ、ＭＩＤＩ系のカテゴリーＩＤは”０１０１”とされている。これにより、上述した優先順位でアービトレーションを行えるようになる。なお、カテゴリーＩＤが同一であり、カテゴリーＩＤだけを対比しただけではマスターが決定されない場合は、サブアドレスも対比してマスターを決定する。これでも決定できない場合は、送信元アドレスも対比してマスターを決定する。送信先アドレスと送信元アドレスの両方が一致することはないので、送信元アドレスまでで必ずアービトレーションが完了する。（特別な通信であるゼネラルコールを除いた中で、最も優先度の高い）ホスト系のデバイスを送信先とした通信では、送信元が鍵盤系、送信元がパネル系、送信元が鍵盤／パネル複合系、ＭＩＤＩ系の順番で通信が優先されるが、これもリアルタイム性の要請により決められている。
【００３２】
サブアドレスについて述べると、ホスト系には、通信相手のデバイスのカテゴリー名が鍵盤・パネル系（鍵盤系、パネル系、または鍵盤／パネル複合系）の時に使用するサブアドレス“０００”と、ＭＩＤＩ系の時に使用するサブアドレス“００１”とが用意されている。すなわち、鍵盤・パネル系のカテゴリー名のデバイスをアドレス指定した際にＭＩＤＩ系より優先して通信を行えるようになる。なお、サブアドレス“０１０”〜“１１１”は異なるバス・フォーマット用あるいは将来の使用に備えて予約されている。さらに、アドレス指定した送信先であるスレーブアドレスが一致してマスターが決定されない場合は、次に送出されるマスターアドレスも対比してマスターを決定するようにする。
また、鍵盤系、パネル系、鍵盤／パネル複合系、ＭＩＤＩ系のサブアドレスには“０００”ないし“１１１”の８つのサブアドレス範囲が与えられている。このため、これらのカテゴリー名のデバイスは、それぞれ８つまでの同種のカテゴリーのデバイスをＥバスシステムに接続することができるようになる。
【００３３】
ところで、Ｅバスシステムにおいてはデバイス間で通信を行う際には、デバイスのカテゴリーに適応する通信プロトコルで通信を行うようにしているが、全てのカテゴリーのデバイスと通信するゼネラルコールの通信プロトコルは、共通プロトコルとされている。図５に示すように、具体的には、ホスト系と通信するカテゴリー名が鍵盤系、パネル系、鍵盤／パネル複合系とされている場合は標準プロトコルで通信される。また、ホスト系と通信するカテゴリー名がＭＩＤＩ系とされている場合はＭＩＤＩプロトコルで通信される。この場合、デバイスにはそのカテゴリー名に対応するカテゴリーＩＤが与えられていることから、アドレス指定されたスレーブアドレスのカテゴリーＩＤから通信プロトコルを決定することができる。なお、ホスト系（メインコントローラ）は通信相手のデバイスが属するカテゴリー名に適応している通信プロトコルを使用して通信を行う必要があることから、図５に示すように標準プロトコル用のアドレスと、ＭＩＤＩプロトコル用のアドレスとを備えている。例えば、ホスト系のデバイスとＭＩＤＩ系のデバイスとが通信する際には、ホスト系のデバイスは自機のアドレスとして“０００１ ００１”を使用し、ＭＩＤＩ系のデバイスがマスターとなった際には、アドレス指定するスレーブアドレスを“０００１ ００１”とする。これにより、ホスト系のデバイスとＭＩＤＩ系のデバイスとはＭＩＤＩプロトコルを使用して通信を行えるようになる。また、ホスト系のデバイスと鍵盤系（パネル系あるいは鍵盤／パネル複合系）のデバイスとが通信する際には、ホスト系のデバイスは自機のアドレスとして“０００１ ０００”を使用し、鍵盤系（パネル系あるいは鍵盤／パネル複合系）のデバイスがマスターとなった際には、アドレス指定するスレーブアドレスを“０００１ ０００”とする。これにより、ホスト系のデバイスと鍵盤系（パネル系あるいは鍵盤／パネル複合系）のデバイスとが標準プロトコルを使用して通信を行えるようになる。
【００３４】
次に、本発明にかかるＥバスシステムにおけるパケットのデータフォーマットを図６に示す。
図６に示すように、Ｅバスシステムにおけるデータフォーマットには全体の長さが５バイト長とされる標準データのデータフォーマットと、全体の長さが１７バイト長とされる拡張データのデータフォーマットとが定義されている。標準データのデータフォーマットにおいては、アドレス指定する１バイトの送信先アドレス（スレーブアドレス）と、１バイトの送信元アドレス（マスターアドレス）と、それぞれ１バイトのデータ１，データ２，データ３の合計５バイトで構成されている。また、拡張データのデータフォーマットにおいては、アドレス指定する１バイトの送信先アドレス（スレーブアドレス）と、１バイトの送信元アドレス（マスターアドレス）と、それぞれ１バイトのデータ１〜データ１５の合計１７バイトから構成されている。この場合の送信元アドレスにはダミービット“０”が１ビット、送信先アドレスにはＲ／Ｗの１ビットがそれぞれ含まれている。標準データのデータフォーマットは、共通プロトコル、標準プロトコルおよびＭＩＤＩプロトコルにおいて用いられ、拡張データのデータフォーマットはＭＩＤＩプロトコルにおいてシステムエクスクルーシブメッセージ等を転送する際に用いられる。なお、送信先アドレスと送信元アドレスとで図４に示すヘッダ部が構成され、続く３バイトのデータあるいは１５バイトのデータによりデータ部が構成されている。なお、標準データおよび拡張データにおけるデータ１は、転送されるデータの種別を示すインデックスとされている。具体的にはインデックスは、各通信プロトコルにおけるコマンドを示している。このように、パケットの長さ（あるいは、データバイトの長さ）を２通りに統一することにより、通信を行う各デバイスでの処理を簡略化することができる。電子楽器において、エクスクルーシブを除く通常のコマンドをやりとりするのに、データバイトが３バイトのパケットは最適である。また、その通常のコマンドのパケット長を５バイト程度（１０バイト以下）の短い長さにすることにより、一つ一つのパケットのバスにおける占有時間が短縮され、電子楽器の鍵盤やパネルからの入力に対する応答時間を短縮することができる。
【００３５】
次に、共通プロトコルのコマンドについて説明する。共通プロトコルは、通信を行うデバイスのカテゴリーを問わず使用することのできる通信プロトコルとされているため、各デバイスはそれが共通プロトコルであることを判別することなく、自分の属するカテゴリの処理の中で共通プロトコルを扱うことができる。前述したように、本発明の電子楽器用バスシステムにかかるＥバスシステムにおいてはメインコントローラデバイス１０であるホスト系のデバイスと、他のデバイスとの間で通信を行うことを前提としている。そこで、ホスト受信とホスト送信のコマンドについて図７に示す。共通プロトコルにおけるコマンドはいずれも標準データのデータフォーマットとされており、図示する順と逆になるがホスト送信欄のコマンドにはカテゴリーＩＤ・サブアドレスリクエストがある。このコマンドは、ホスト系のデバイスがＥバスシステムに接続されているデバイスのアドレスを検出するためのコマンドであり、ゼネラルコールすることができる。このコマンドにおけるインデックスであるデータ１は“００ｈ”（ｈは１６進表記を示す：００ｈ＝００００ ００００）とされ、データ２およびデータ３も“００ｈ”とされている。
【００３６】
カテゴリーＩＤ・サブアドレスリクエストのコマンドをホスト系のデバイスからゼネラルコールする際には、“００００ ０００”を送信先アドレス、“０００１ ０００”を送信元アドレス（図５参照）、“００ｈ”とされたデータ１ないしデータ３からなる標準データのコマンドを発行する。ゼネラルコールされたカテゴリーＩＤ・サブアドレスリクエストコマンドは、Ｅバスシステムに接続されている全てのカテゴリのデバイスが受信するようになり、各デバイスはホスト受信欄に示されているカテゴリーＩＤ・サブアドレスリプライのコマンドをホストに返す。このカテゴリーＩＤ・サブアドレスリプライは、自機に固有のアドレスをホスト系のデバイスに知らせるコマンドである。カテゴリーＩＤ・サブアドレスリプライコマンドを発行するには、アドレス指定する送信先アドレスを“０００１ ０００”、送信元アドレスを自機の７ビットのアドレス、インデックスであるデータ１を“００ｈ”、データ２が自機のカテゴリーＩＤ、データ３が自機のサブアドレスの標準データを送信する。これにより、ホストはＥバスシステムに接続されているデバイスと、そのアドレスを知ることができる。なお、カテゴリーＩＤ・サブアドレスリクエストのコマンドはＥバスシステムの動作開始時にホスト系のデバイスがゼネラルコールするようにされており、このコマンドによりＥバスシステムに接続されているデバイスと、そのアドレスを知り、知ったアドレスからカテゴリー名と使用する通信プロトコルを知ることができる。このようにして、ホスト系のデバイスは図５に示すテーブルを作成でき、以降の通信は作成されたテーブルにおけるアドレスを設定して通信することができる。また、ホスト系以外のデバイスはホスト系のデバイスとの通信を行うことを原則としており、ホスト系に割り当てられている複数のアドレスはＥバスシステムで予め定められたアドレスとされている。したがって、ホスト系以外のデバイスは通信する際に設定するアドレスを予め知っているので図５に示すテーブルを作成する必要はない。ゼネラルコールはホスト以外の各デバイスも受信する通信であるので、仮に、各デバイスからのカテゴリーＩＤ・サブアドレスリプライ時にゼネラルコールを使用すると、それを受信するホスト以外の各デバイスでそれを無視するための処理が必要になってしまう。そこで、本発明にかかるＥバスシステムでは、該リプライ時に、ゼネラルコールではなく送信先をホストの標準アドレスとした通信を行ない、ホスト以外の各デバイスでの処理を簡略化するようになっている。
【００３７】
また、ホスト送信欄のＥバススタートのコマンドは原則的にメインコントローラデバイス１０からゼネラルコールされるコマンドであり、Ｅバスシステムの立ち上げ時にＥバスシステムを動作可能にするためのコマンドである。Ｅバススタートのコマンドをゼネラルコールする際は、“００００ ０００”が送信先アドレス、“０００１ ０００”が送信元アドレス、インデックスであるデータ１が“０１ｈ”、データ２が“００ｈ”、データ３が“００ｈ”の標準データを送信する。
【００３８】
次に、図８に示す標準プロトコルのホスト受信およびホスト送信のコマンドについて説明する。標準プロトコルは、ホスト系のデバイス（メインコントローラ）と、鍵盤系、パネル系、鍵盤／パネル複合系のカテゴリーのデバイスとが通信を行う場合に使用することのできる通信プロトコルとされている。標準プロトコルにおけるコマンドはいずれも標準データのデータフォーマットとされている。
標準プロトコルにおけるホスト受信欄のコマンドのうちの共通プロトコルのコマンドは、図７に示す共通プロトコルと同様であるのでその説明は省略するが、この部分が同じになっているために、当該デバイスでは動作を標準プロトコルと共通プロトコルの間で切り換えることなく、共通プロトコルを送受信することができる。次のＳＷ ＯＦＦコマンドおよびＳＷ ＯＮコマンドは、パネルデバイスに設けられているパネルスイッチのＯＦＦイベントおよびＯＮイベントをホストに転送するコマンドである。例えば、パネルデバイスにおけるパネルスイッチのスイッチ番号ｎのスイッチがＯＦＦされた場合は、送信先アドレスがホストを示す“０００１ ０００”とされ、送信元アドレスがそのパネルデバイスのアドレス“００１１ ａａａ”（“ａａａ”は当該パネルデバイスのサブアドレス）とされ、インデックスであるデータ１が“６ｘｈ”、データ２がオフされたスイッチ番号ｎ（８ビット）、データ３がダミーの“００ｈ”とされたＳＷ ＯＦＦコマンドが発行される。
【００３９】
また、パネルデバイスにおけるパネルスイッチのスイッチ番号ｍのスイッチがＯＮされた場合は、送信先アドレスがホストを示す“０００１ ０００”とされ、送信元アドレスがそのパネルデバイスのアドレス“００１１ ｂｂｂ”（“ｂｂｂ”は当該パネルデバイスのサブアドレス）とされ、インデックスとされるデータ１が”７ｘｈ”、データ２がオンされたスイッチ番号ｍ（８ビット）、データ３がダミーの“００ｈ”とされたＳＷ ＯＮコマンドが発行される。なお、いずれのコマンドにおいても“ｘｈ”はポート番号を示しており、スイッチ番号が８ビットとされることから、１６ポート×２５６個のパネルスイッチのＳＷ ＯＦＦコマンドおよびＳＷ ＯＮコマンドを発行することができる。
【００４０】
標準プロトコルにおけるホスト受信欄の鍵盤 ＯＦＦコマンドおよび鍵盤 ＯＮコマンドは、鍵盤デバイスにおける各鍵のノートオンイベントおよびノートオフイベントをホストに転送するコマンドである。ここで、鍵盤デバイスにおけるノート番号ｎに対応する鍵がノートオフされた場合は、送信先アドレスがホストを示す“０００１ ０００”とされ、送信元アドレスがその鍵盤デバイスのアドレス“００１０ ａａａ”（“ａａａ”は当該鍵盤デバイスのサブアドレス）とされ、インデックスとされるデータ１が”８ｖｈ”、データ２がノートオフされたノート番号ｎ（８ビット）、データ３がベロシティの上位８ビットとされた鍵盤 ＯＦＦコマンドが発行される。なお、”ｖｈ”はベロシティの下位４ビットとされており、合計１２ビットとされたベロシティ情報が転送され、そのうちの上位７ビットはＭＩＤＩ互換とされている。
【００４１】
また、鍵盤デバイスにおけるノート番号ｍに対応する鍵がノートオンされた場合は、送信先アドレスがホストを示す“０００１ ０００”とされ、送信元アドレスがその鍵盤デバイスのアドレス“００１０ ｂｂｂ”（“ｂｂｂ”は当該鍵盤デバイスのサブアドレス）とされ、インデックスとされるデータ１が”９ｖｈ”、データ２がノートオンされたノート番号ｍ（８ビット）、データ３がベロシティの上位８ビットとされた鍵盤 ＯＮコマンドが発行される。このコマンドでは、鍵盤 ＯＦＦコマンドと同様に合計１２ビットとされたベロシティ情報が転送され、そのうちの上位７ビットがＭＩＤＩ互換とされている。また、いずれのコマンドでもノート番号が８ビットとされることから、２５６個のノートに対応する鍵盤 ＯＦＦコマンドおよび鍵盤 ＯＮコマンドを発行することができる。ここで、鍵盤 ＯＦＦコマンド、および鍵盤 ＯＮコマンドにおいて、ポート番号を削ってベロシティ情報を１２ビットとしているのは、鍵盤演奏の取り込みにおいては、タッチカーブ等の処理のため、ＭＩＤＩのベロシティより高分解能の１２ビットのベロシティ分解能が必要であるためである。
【００４２】
標準プロトコルにおけるホスト受信欄の鍵盤デバイスにおけるポリフォニックアフタータッチ（各鍵毎のアフタータッチ）の値を転送するポリフォニックアフタータッチコマンドは、送信先アドレスがホストを示す“０００１ ０００”とされ、送信元アドレスがその鍵盤デバイスのアドレス“００１０ ａａａ”（“ａａａ”は当該鍵盤デバイスのサブアドレス）とされ、インデックスとされるデータ１が“Ａｘｈ”、データ２がアフタータッチをかけるノートのノート番号ｎ（８ビット）、データ３が８ビットのアフター値とされている。“ｘｈ”はポート番号とされているので、１６ポートのポリフォニックアフタータッチコマンドを発行することができる。
【００４３】
また、標準プロトコルにおけるホスト受信欄のパネルデバイスにおけるボリュームやホイール等の操作された操作値を転送するコンティニュアスコントローラコマンドは、送信先アドレスがホストを示す“０００１ ０００”とされ、送信元アドレスがそのパネルデバイスのアドレス“００１１ ａａａ”（“ａａａ”は当該パネルデバイスのサブアドレス）とされ、インデックスとされるデータ１が“Ｂｘｈ”、データ２がボリュームやホイール等のコントローラの種別（８ビット）、データ３が８ビットのコントローラの操作値とされている。“ｘｈ”はポート番号とされており、種別は８ビットとされているので、１６ポート×２５６個のコンティニュアスコントローラコマンドを発行することができる。
【００４４】
また、標準プロトコルにおけるホスト受信欄のパネルデバイスにおけるロータリエンコーダ等のジョグコントローラにおける操作された操作値を転送するＪＯＧコントローラコマンドは、送信先アドレスがホストを示す“０００１ ０００”とされ、送信元アドレスがそのパネルデバイスのアドレス“００１１ ａａａ”（“ａａａ”は当該パネルデバイスのサブアドレス）とされ、インデックスとされるデータ１が“Ｃｘｈ”、データ２がジョグコントローラの種別（８ビット）、データ３がコントローラにおける操作値の２の補数の相対値（８ビット）とされている。“ｘｈ”はポート番号とされており、種別は８ビットとされているので、１６ポート×２５６個のＪＯＧコントローラコマンドを発行することができる。
【００４５】
標準プロトコルにおけるホスト受信欄の鍵盤デバイスにおけるアフタータッチ（１つの鍵盤の複数鍵に共通のアフタータッチ）の値を転送するアフタータッチコマンドは、送信先アドレスがホストを示す“０００１ ０００”とされ、送信元アドレスがその鍵盤デバイスのアドレス“００１０ ａａａ”（“ａａａ”は当該鍵盤デバイスのサブアドレス）とされ、インデックスとされるデータ１が“Ｄｘｈ”、データ２がタッチ値の上位８ビット、データ３がタッチ値の下位８ビットとされている。“ｘｈ”はポート番号とされているので、１６ポートのアフタータッチコマンドを発行することができる。このアフタータッチコマンドで転送されるタッチ値は、マスター（送信元）とされている鍵盤デバイスにおいて複数ノートオンされているノートの全てにかけられているタッチ値である。
【００４６】
また、標準プロトコルにおけるホスト受信欄のパネルデバイスにおけるボリュームやホイール等の操作された操作値を転送する１６ビットのコンティニュアスコントローラコマンドは、送信先アドレスがホストを示す“０００１ ０００”とされ、送信元アドレスがそのパネルデバイスのアドレス“００１１ ａａａ”（“ａａａ”は当該パネルデバイスのサブアドレス）とされ、インデックスとされるデータ１が“Ｅｘｈ”、データ２がコントローラの操作値の上位８ビット、データ３がコントローラの操作値の下位８ビットとされている。“ｘｈ”はポート番号とされているので、１６ポートの１６ビットのコンティニュアスコントローラコマンドを発行することができる。なお、鍵盤／パネル複合系のデバイスでは、鍵盤デバイスとパネルデバイスの両方のコマンドを送信可能である。また、コンティニュアスコントローラコマンド、ジョグコントローラコマンドについては、鍵盤デバイスから送信できるようにしてもよい。
【００４７】
次に、標準プロトコルにおけるホスト送信欄のコマンドについて説明する。まず、ホスト送信欄の共通プロトコルのコマンドは、図７に示す共通プロトコルと同様であるのでその説明は省略する。
ホスト送信欄のＬＥＤコントロールのコマンドは、パネルデバイスに設けられているＬＥＤ（Light Emitting Diode）が属するとされたグループの輝度を、ホストがコントロールするコマンドである。ＬＥＤコントロールコマンドは、送信先アドレスが輝度コントロールされるパネルデバイスのアドレス“００１１ ａａａ”（“ａａａ”は当該パネルデバイスのサブアドレス）とされ、送信元アドレスがホストを示す“０００１ ０００”とされ、インデックスとされるデータ１が“６ｘｈ”、データ２が輝度をコントロールするグループ番号（８ビット）、データ３が輝度コントロール値である８ビットのＬＥＤ輝度値とされている。“ｘｈ”はポート番号とされているので、１６ポートのＬＥＤコントロールコマンドを発行することができる。ただし、グループ“００ｈ”の輝度は最小（オフ相当）とされ、グループ“ＦＦｈ”の輝度は最大（オン相当）とされているため、そのグループの輝度は変更することができないようにされている。
【００４８】
ホスト送信欄のＬＥＤコマンドは、パネルデバイスに設けられているＬＥＤをホストがグループに振り分けるコマンドである。ＬＥＤコマンドは、送信先アドレスがコントロールされるパネルデバイスのアドレス“００１１ ａａａ”（“ａａａ”は当該パネルデバイスのサブアドレス）とされ、送信元アドレスがホストを示す“０００１ ０００”とされ、インデックスとされるデータ１が“７ｘｈ”、データ２がグループに振り分ける８ビットのＬＥＤ番号、データ３が振り分けられる８ビットのグループ番号とされている。“ｘｈ”はポート番号とされており、ＬＥＤ番号は８ビットとされているので、１６ポート×２５６個のＬＥＤコマンドを発行することができる。
【００４９】
ここで、ＬＥＤコントロールコマンドとＬＥＤコマンドの使い方を説明すると、ホストがパネルデバイスへＬＥＤ“ｉ”をグループ“ＦＦｈ”に振り分けるＬＥＤコマンドを送信すると、このＬＥＤコマンドを受信したパネルデバイスではＬＥＤ番号“ｉ”のＬＥＤを点灯するようになる。また、ＬＥＤ“ｊ”をグループ“００ｈ”に振り分けるＬＥＤコマンドを送信すると、このＬＥＤコマンドを受信したパネルデバイスではＬＥＤ番号“ｊ”のＬＥＤを消灯するようになる。
また、ホストからパネルデバイスへ、まず、グループ“０１ｈ”の輝度を“００ｈ”（最小値）に設定するＬＥＤコントロールを送信すると共に、所望の複数ＬＥＤのＬＥＤ番号をそれぞれグループ“０１ｈ”に振り分ける複数のＬＥＤコマンドを送信し、最後に、グループ“０１ｈ”の輝度を“ＦＦｈ”（最大値）に設定するＬＥＤコントロールを送信することで、該パネルデバイスの該複数ＬＥＤを同時に点灯することができるようになる。
【００５０】
ホスト送信欄の鍵盤ＬＥＤコントロールのコマンドは、鍵盤デバイスの各鍵に設けられているＬＥＤ（演奏ガイド用ＬＥＤ）が属するグループの輝度をホストがコントロールするコマンドである。鍵盤ＬＥＤコントロールコマンドは、送信先アドレスが輝度コントロールされる鍵盤デバイスのアドレス“００１０ ａａａ”（“ａａａ”は当該鍵盤デバイスのサブアドレス）とされ、送信元アドレスがホストを示す“０００１ ０００”とされ、インデックスとされるデータ１が“８ｘｈ”、データ２が輝度コントロールされるグループ番号（８ビット）、データ３が輝度コントロール値である８ビットのＬＥＤ輝度値とされている。“ｘｈ”はポート番号とされているので、１６ポートの鍵盤ＬＥＤコントロールコマンドを発行することができる。ただし、グループ“００ｈ”の輝度は最小（オフ相当）とされ、グループ“ＦＦｈ”の輝度は最大（オン相当）とされているため、その輝度を変更することができないようにされている。
【００５１】
ホスト送信欄の鍵盤ＬＥＤコマンドは、鍵盤デバイスに設けられているＬＥＤをホストがグループに振り分けるコマンドである。鍵盤ＬＥＤコマンドは、送信先アドレスがコントロールされる鍵盤デバイスのアドレス“００１０ ａａａ”（“ａａａ”は当該鍵盤デバイスのサブアドレス）とされ、送信元アドレスがホストを示す“０００１ ０００”とされ、インデックスとされるデータ１が“９ｘｈ”、データ２がグループに振り分けるＬＥＤが設けられている鍵のノート番号（８ビット）、データ３が振り分けられる８ビットのグループ番号とされている。“ｘｈ”はポート番号とされており、ノート番号は８ビットとされているので、１６ポート×２５６個の鍵盤ＬＥＤコマンドを発行することができる。鍵盤ＬＥＤコントロールコマンドと鍵盤ＬＥＤコマンドによる鍵盤ＬＥＤの制御の態様は、ＬＥＤコントロールコマンドとＬＥＤコマンドによるパネルデバイスのＬＥＤの制御の態様と同様である。なお、鍵盤 ＯＦＦコマンド、鍵盤 ＯＮコマンドによれば各鍵盤デバイスの鍵は最大２５６個とされているので、鍵盤ＬＥＤコントロールコマンドと鍵盤ＬＥＤコマンドにおけるポート番号は、例えば、各鍵に複数色の複数ＬＥＤを用意して色の制御を行うために使用したり、あるいは、各鍵の複数個所にＬＥＤを用意して光る位置の制御を行うために使用することができる。
【００５２】
また、標準プロトコルにおけるホスト送信欄のパネルデバイスにおける電動ボリュームや電動ホイール等の操作値をホストから制御するコンティニュアスコントローラコマンドは、送信先アドレスがコントロールされるパネルデバイスのアドレス“００１１ ａａａ”（“ａａａ”は当該パネルデバイスのサブアドレス）とされ、送信元アドレスがホストを示す“０００１ ０００”とされ、インデックスとされるデータ１が“Ｂｘｈ”、データ２が電動ボリュームや電動ホイール等のコントローラの種別（８ビット）、データ３が８ビットの電動コントローラの制御値とされている。“ｘｈ”はポート番号とされており、種別は８ビットとされているので、１６ポート×２５６個のコンティニュアスコントローラコマンドを発行することができる。
【００５３】
また、標準プロトコルにおけるホスト送信欄のパネルデバイスにおけるロータリエンコーダ等の電動ジョグコントローラの操作値をホストから制御するＪＯＧコントローラコマンドは、送信先アドレスがコントロールされるパネルデバイスのアドレス“００１１ ａａａ”（“ａａａ”は当該パネルデバイスのサブアドレス）とされ、送信元アドレスがホストを示す“０００１ ０００”とされ、インデックスとされるデータ１が“Ｃｘｈ”、データ２が電動ジョグコントローラの種別（８ビット）、データ３が電動コントローラを制御する２の補数の相対値（８ビット）とされている。“ｘｈ”はポート番号とされており、種別は８ビットとされているので、１６ポート×２５６個のＪＯＧコントローラコマンドを発行することができる。
【００５４】
また、標準プロトコルにおけるホスト送信欄のパネルデバイスにおける電動ボリュームや電動ホイール等の操作値をホストから制御する１６ビットのコンティニュアスコントローラコマンドは、送信先アドレスがコントロールされるパネルデバイスのアドレス“００１１ ａａａ”（“ａａａ”は当該パネルデバイスのサブアドレス）とされ、送信元アドレスがホストを示す“０００１ ０００”とされ、インデックスとされるデータ１が“Ｅｘｈ”、データ２が電動コントローラの制御値の上位８ビット、データ３が電動コントローラの制御値の下位８ビットとされている。“ｘｈ”はポート番号とされているので、１６ポートの１６ビットのコンティニュアスコントローラコマンドを発行することができる。
【００５５】
次に、図９に示すＭＩＤＩプロトコルのコマンドについて説明する。ＭＩＤＩプロトコルは、ホスト系のデバイス（メインコントローラ）とＭＩＤＩ系のデバイスとが通信を行う場合に使用することのできる通信プロトコルとされている。ＭＩＤＩプロトコルにおけるコマンドは標準データおよび拡張データのデータフォーマットとが用いられる。なお、ＭＩＤＩプロトコルではホスト送信とホスト受信とのコマンドが共通とされており、ホスト受信とホスト送信では、送信先アドレスと送信元アドレスだけが異なるようになる。すなわち、ホスト受信のコマンドの場合は、送信先アドレスがホストのＭＩＤＩプロトコル用のアドレスである”０００１ ００１”とされ、送信元アドレスが送信するＭＩＤＩデバイスのアドレスとされる。また、ホスト送信のコマンドの場合は、送信先アドレスがＭＩＤＩデバイスのアドレスとされ、送信元アドレスがホストのＭＩＤＩプロトコル用のアドレスである”０００１ ００１”とされる。図９に示すＭＩＤＩプロトコルの各コマンドでは上述のように、送信先アドレスおよび送信元アドレスが設定され、以下のコマンドの説明では、各コマンドのデータ形式およびデータ部についてだけ説明するものとする。
【００５６】
ＭＩＤＩプロトコルにおける共通プロトコルのコマンドは、図７に示す共通プロトコルと同様であるのでその説明は省略する。
システムエクスクルーシブ（Sys EX）の開始および続きコマンドおよびシステムエクスクルーシブ（Sys EX）の終了または１パケットコマンドは、データフォーマットが共に拡張モードとされ１７バイト長とされている。システムエクスクルーシブ（Sys EX）の開始および続きコマンドは、システムエクスクルーシブの開始および続きを示すインデックスとされる”４ｉｈ”がデータ１とされ、データ２ないしデータ１５における１バイトずつのデータにより音色パラメータやシーケンス・データ等が転送される。システムエクスクルーシブ（Sys EX）の終了または１パケットコマンドは、システムエクスクルーシブの終了または１パケットを示すインデックスとされる”５ｉｈ”がデータ１とされ、１パケットの場合にデータ２ないしデータ１５において１パケットのデータが１バイトずつ転送される。
なお、ＭＩＤＩにおいてはシステムエクスクルーシブの開始は“Ｆ０ｈ”終了は“Ｆ７ｈ”で示されるが、Ｅバスシステムではこれに替えて上記のようにシステムエクスクルーシブの開始は“４ｉｈ”終了は“５ｉｈ”とし、“Ｆ０ｈ”、“Ｆ７ｈ”は使用しないこととしている。また、“ｉｈ”は、当該システムエクスクルーシブを送信するＭＩＤＩのポート番号を示す。
【００５７】
ソングポジション（Song Pos）コマンドは演奏を開始する位置を知らせるコマンドであり、標準データのデータフォーマットとされている。ソングポジションコマンドは、そのインデックスとされる“６ｉｈ”がデータ１とされ、データ２が演奏開始位置のポインターのＬＳＢとされ、データ３が演奏開始位置のポインターのＭＳＢとされる。なお、ＭＩＤＩではソングポジションポインターのメッセージは“Ｆ２ｈ”で示され、データ２およびデータ３はこのメッセージと互換とされている。
ＭＩＤＩポートセレクトコマンドは、カレントのＭＩＤＩポート番号（ノートオンメッセージ、ノートオフメッセージが授受されるＭＩＤＩポートの番号）を選択するコマンドであり、標準データのデータフォーマットとされている。ＭＩＤＩポートセレクトコマンドは、そのインデックスとされる“７ｉｈ”がデータ１とされ、データ２が“００ｈ”とされ、データ３が“００ｈ”とされる。例えば、ＭＩＤＩポートセレクトコマンドがホストからＭＩＤＩデバイスに送信された場合、受取ったＭＩＤＩデバイスではカレントのＭＩＤＩポート番号を上記インデックスに含まれる値“ｉｈ”に設定する。なお、ＭＩＤＩスタンダードではポートセレクトのメッセージは規定されていない（実装では“Ｆ５ｈ”が使われる場合もある）。なお、ＭＩＤＩポートセレクトコマンドはＭＩＤＩにおけるＭＩＤＩタイムピースメッセージの機能に相当する。
【００５８】
２つのＭＩＤＩ互換（note,vel）コマンドは、ＭＩＤＩにおけるノートオンメッセージおよびノートオフメッセージと互換とされており、標準データのデータフォーマットとされている。これらのコマンドにおいて、データ１がＭＩＤＩにおけるノートオフのインデックスとされる“８ｎｈ”とされ、データ２がＭＩＤＩ互換の８ビットのノートオフされたノート番号、データ３がＭＩＤＩ互換の８ビットのオフベロシティとされると、ノートオフコマンドとなる。また、データ１がＭＩＤＩにおけるノートオンのインデックスとされる“９ｎｈ”とされ、データ２がＭＩＤＩ互換の８ビットのノートオンされたノート番号、データ３がＭＩＤＩ互換の８ビットのベロシティとされると、ノートオンコマンドとなる。なお、データ１がＭＩＤＩにおけるノートオンのインデックスとされる“９ｎｈ”とされ、データ２がＭＩＤＩ互換の８ビットのノートオフされたノート番号、データ３が“００ｈ”（ベロシティがゼロ）とされたものをノートオフコマンドとして使用してもよい。なお、“ｎｈ”はＭＩＤＩチャンネル番号である。
【００５９】
ＭＩＤＩ互換（note,Aft）コマンドは、ＭＩＤＩにおけるポリフォニック・キー・プレッシャーメッセージと互換とされており、鍵ごとに独立したアフター・タッチ情報を送ることができるコマンドとされている。このコマンドは、標準データのデータフォーマットとされている。このコマンドでは、データ１がＭＩＤＩにおけるポリフォニック・キー・プレッシャーのインデックスとされる“Ａｎｈ”とされ、データ２がＭＩＤＩ互換の８ビットのアフター・タッチ情報を送るノート番号、データ３がＭＩＤＩ互換の８ビットのタッチ値とされる。なお、“ｎｈ”はＭＩＤＩチャンネル番号である。
ＭＩＤＩ互換（CtnNo. ,Value）コマンドは、ＭＩＤＩにおけるコントロール・チェンジメッセージと互換とされており、ダンパー・ペダル、ボリューム、モジュレーション、ホイールなどのコントローラの情報を送ることのできるコマンドとされている。このコマンドは、標準データのデータフォーマットとされている。このコマンドでは、データ１がＭＩＤＩにおけるコントロール・チェンジのインデックスとされる“Ｂｎｈ”とされ、データ２がコントロール機能を示すＭＩＤＩ互換の８ビットのコントロール番号、データ３がＭＩＤＩ互換の８ビットのコントロール値とされる。なお、“ｎｈ”はＭＩＤＩチャンネル番号である。
【００６０】
ＭＩＤＩ互換（PrgNo. ,00）コマンドは、ＭＩＤＩにおけるプログラム・チェンジメッセージと互換とされており、音色を切り替えるコマンドとされている。このコマンドは、標準データのデータフォーマットとされている。このコマンドでは、データ１がＭＩＤＩにおけるプログラム・チェンジのインデックスとされる“Ｃｎｈ”とされ、データ２がＭＩＤＩ互換の８ビットのプログラム番号、データ３はＭＩＤＩにおけるプログラム・チェンジメッセージでは必要とされていないので“００ｈ”とされる。なお、“ｎｈ”はＭＩＤＩチャンネル番号である。
ＭＩＤＩ互換（Aft,00）コマンドは、ＭＩＤＩにおけるチャンネル・プレッシャーと互換とされており、音色を切り替えるコマンドとされている。このコマンドは、標準データのデータフォーマットとされている。このコマンドでは、データ１がＭＩＤＩにおけるチャンネル・プレッシャーのインデックスとされる“Ｄｎｈ”とされ、データ２がＭＩＤＩ互換の８ビットのアフター・タッチ値、データ３はＭＩＤＩにおけるプログラム・チェンジメッセージでは必要とされていないので“００ｈ”とされる。なお、“ｎｈ”はＭＩＤＩチャンネル番号である。このコマンドは、代表とされるアフター・タッチ情報を送るコマンドであるので、複数ノートオンされていた場合は、全てのノートオンのアフター・タッチ情報となる。
【００６１】
ＭＩＤＩ互換（BendL,H）コマンドは、ＭＩＤＩにおけるピッチ・ベンドメッセージと互換とされており、ホイールやジョイスティックなどから構成されるピッチ・ベンダーの情報を送るコマンドとされている。このコマンドは、標準データのデータフォーマットとされている。このコマンドでは、データ１がＭＩＤＩにおけるピッチ・ベンドのインデックスとされる“Ｅｎｈ”とされ、データ２がＭＩＤＩ互換の８ビットのピッチ・ベンド値のＬＳＢ、データ３がＭＩＤＩ互換の８ビットのピッチ・ベンド値のＭＳＢとされる。なお、“ｎｈ”はＭＩＤＩチャンネル番号である。
【００６２】
ＭＩＤＩにおいては、ステータス“Ｆ０ｈ”〜“Ｆ７ｈ”が定義されている。ただし、ステータス“Ｆ４ｈ”、“Ｆ５ｈ”は未定義である。また、上述したようにＭＩＤＩにおけるシステム・エクスクルーシブの開始および終了のステータス“Ｆ０ｈ”、“Ｆ７ｈ”は、Ｅバスシステムのインデックス“４ｉｈ”、“５ｉｈ”に変換して使用しない。同様に、ＭＩＤＩにおけるステータス“Ｆ２ｈ”は、Ｅバスシステムのインデックス“６ｘｈ”に変換し、ＭＩＤＩにおけるステータス“Ｆ５ｈ”がMIDI Time Pieceとして定義されている場合は、Ｅバスシステムのインデックス“７ｘｈ”に変換する。このように、“Ｆ０ｈ”〜“Ｆ７ｈ”の一部のステータスを変換しているが、これは、標準データのフォーマットの中で、その一部のステータスについてバイト数を１バイト増やすため、あるいは、その増えたバイトでＭＩＤＩポート番号を指定できるようにするためである。また、ＭＩＤＩスタンダードでは、メッセージの各バイトの最上位ビットにより、そのバイトがステータスバイトであるかデータバイトであるかを判定するようになっているが、上述したＭＩＤＩプロトコルでは標準データのデータ１が必ずコマンドであるので、同様の目的で最上位ビットを使う必要がない。そこで、上述したＭＩＤＩプロトコルでは、ＭＩＤＩのステータスバイトから外れる“００ｈ”〜“７Ｆｈ”を、共通プロトコルのコマンドやＭＩＤＩを拡張するコマンドとして使用するようにしている。
【００６３】
さらに、Ｆ１（MIDI Timecode Quater Frame）コマンドは、ＭＩＤＩタイムコードにおける時／分／秒の情報を送るコマンドとされている。このコマンドは、標準データのデータフォーマットとされている。このコマンドでは、データ１がインデックスとされる“Ｆｉｈ”とされ、データ２がＭＩＤＩタイムコード・クォーター・フレームのステータスである“Ｆ１ｈ”、データ３がＭＩＤＩ互換の８ビットの時／分／秒の値とされる。
さらにまた、Ｆ３（Song Select）コマンドは、ソング・メモリや記憶媒体に記憶されている曲を選択するコマンドとされている。このコマンドは、標準データのデータフォーマットとされている。このコマンドでは、データ１がインデックスとされる“Ｆｉｈ”とされ、データ２がＭＩＤＩにおけるソング・セレクトのステータスである“Ｆ３ｈ”、データ３がＭＩＤＩ互換の８ビットのソング番号とされる。
【００６４】
さらにまた、Ｆ６（Tune Request）コマンドは、オート・チューニング機能のあるＭＩＤＩデバイスをチューニングするコマンドとされている。このコマンドは、標準データのデータフォーマットとされている。このコマンドでは、データ１がインデックスとされる“Ｆｉｈ”とされ、データ２がＭＩＤＩにおけるチューン・リクエストのステータスである“Ｆ６ｈ”、データ３はＭＩＤＩにおいて必要とされていないため“００ｈ”とされる。
【００６５】
さらにまた、システムリアルタイムメッセージコマンドは、リアルタイムで処理される必要のあるメッセージを送るコマンドである。このコマンドは、標準データのデータフォーマットとされている。このコマンドでは、データ１がインデックスとされる“Ｆｉｈ”とされ、データ２がＭＩＤＩにおけるシステムリアルタイムメッセージのステータスである“Ｆ８ｈ”〜“ＦＦｈ”のいずれか、データ３はＭＩＤＩにおいて必要とされていないため“００ｈ”とされる。なお、データ２は次のようになる。
機能がタイミング・クロックとされている場合は、ステータス“Ｆ８ｈ”
機能がスタートとされている場合は、ステータス“ＦＡｈ”
機能がコンティニューとされている場合は、ステータス“ＦＢｈ”
機能がストップとされている場合は、ステータス“ＦＣｈ”
機能がシステム・リセットとされている場合は、ステータス“ＦＦｈ”
なお、ステータス“Ｆ９ｈ”“ＦＤｈ”は未定義であり、ステータス“ＦＥｈ”はアクティブ・センシングとして定義されているが、本発明にかかるＥバスシステムにおいてはアクティブ・センシング（“ＦＥｈ”）は使用しない。なお、以上のデータ１が“Ｆｉｈ”となっているコマンドでは、“ｉｈ”は当該コマンドを送出するＭＩＤＩポート番号を示している。
【００６６】
次に、本発明にかかるＥバスシステムのＥバス起動手順を図１０に示すフローチャートに示す。
Ｅバスシステムにおいて電源を投入する（ステップＳ１）と、Ｅバス１１の４本の電源ラインを介して、Ｅバスシステムに接続されているデバイスの全てに電源が供給される。ここで、ホスト（メインコントローラデバイス１０）はＥバス１１におけるイニシャルクリアラインをＬレベルにする。これにより、Ｅバスシステムに接続されているデバイスが機能を停止してリセットされ、デバイスのハードウェア初期化が行われる（ステップＳ２）。次いで、ホスト（メインコントローラデバイス１０）はＥバス１１におけるイニシャルクリアラインをＨレベルにして、Ｅバスシステムに接続されているデバイスを起動する。これにより、Ｅバスシステムに接続されているデバイスにおいてソフトウェアが初期化される（ステップＳ３）。ここで、図７に示す「Ｅバススタート」コマンドをホスト（メインコントローラデバイス１０）がゼネラルコールで送信する（ステップＳ４）。Ｅバスシステムに接続されている各デバイスは、この「Ｅバススタート」コマンドを受信して動作開始し、これにより、Ｅバスシステムが動作開始するようになる。なお、前述したホスト系におけるカテゴリーＩＤ・サブアドレスリクエストのコマンドを使用したテーブルの作成は、この「Ｅバススタート」コマンドが送出された直後に行われる。
【００６７】
次に、本発明にかかるＥバスシステムにおけるホスト受信処理のフローチャートを図１１に示す。
図１１に示すホスト受信処理において、ホスト（メインコントローラデバイス１０）がＥバス１１から信号を受信すると、ステップＳ１０において受信した送信先アドレスが“１０ｈ”か“１２ｈ”かが判定される。この場合の送信先アドレスは、ホスト受信であることからアドレス指定されたホストのアドレスとなる。ただし、ステップＳ１０において判定されるホストのアドレスには、常時“０”とされるＲ／Ｗ用の１ビットが含まれている。そして、受信した送信先アドレスが“１０ｈ”（＝“０００１ ００００”）と判定された場合は、標準プロトコルのホストのアドレスが指定されていることから、ステップＳ１１に進み送信元アドレスの受信およびデータ１〜データ３からなるデータ部を受信する標準プロトコル受信処理が行われる。また、有効な信号を受信できた場合は１バイト毎にアクノリッジを返す。この標準プロトコル受信処理では、ホストは、例えば鍵盤デバイスからの鍵盤 ＯＦＦや鍵盤 ＯＮ等のコマンドを受信したり、パネルデバイスからのＳＷ ＯＮやコンティニュアスコントローラ等のコマンドを受信したりする。
【００６８】
さらに、受信した送信先アドレスが“１２ｈ”（＝“０００１ ００１０”）と判定された場合は、ＭＩＤＩプロトコルのホストのアドレスが指定されていることから、ステップＳ１２に分岐し送信元アドレスの受信およびデータ１〜データ３、あるいはデータ１〜データ１５からなるデータ部を受信するＭＩＤＩプロトコル受信処理が行われる。さらにまた、有効な信号を受信できた場合は１バイト毎にアクノリッジを返す。ステップＳ１１あるいはステップＳ１２の受信処理が終了すると、ホスト受信処理も終了する。このＭＩＤＩプロトコル受信処理では、ホストは、例えばＭＩＤＩ入出力デバイスからノートオンやノートオフ等のＭＩＤＩメッセージのコマンドを受信する。
【００６９】
次に、本発明にかかるＥバスシステムにおけるホスト送信処理のフローチャートを図１２に示す。
図１２に示すホスト送信処理において、ホスト（メインコントローラデバイス１０）がＥバス１１に送信する際には、ステップＳ２０においてアドレス指定した送信する送信先アドレスの上位４ビットが“２ｈ”〜“４ｈ”か“５ｈ”かが判定される。この場合の送信先アドレスの上位４ビットは、ホスト送信であることからホストがアドレス指定した送信先のデバイスのカテゴリーＩＤとなる。そして、送信する送信先アドレスの上位４ビットが“２ｈ”〜“４ｈ”（＝“０００１”〜“０１００”）と判定された場合は、鍵盤系、パネル系あるいは鍵盤／パネル複合系のデバイスが送信先のデバイスとされていることになる。これらのカテゴリーのデバイスは図５に示すように通信プロトコルが標準プロトコルとされていることから、ステップＳ２１に進み標準プロトコルにおけるホストのアドレスである“０００１ ０００”の送信元アドレスが付加され、次いでデータ１〜データ３からなるデータ部が送信される標準プロトコル送信処理が行われる。この標準プロトコル送信処理では、ホストは、例えばパネルデバイスに対してＬＥＤ番号ｉのＬＥＤを点灯させるＬＥＤコマンド（ＬＥＤ“ｉ”をグループ“ＦＦｈ”に振り分けるコマンド）を送信する。
【００７０】
また、送信する送信先アドレスの上位４ビットが“５ｈ”（＝“０１０１”）と判定された場合は、ＭＩＤＩ系のデバイスが送信先のデバイスとされていることになる。ＭＩＤＩ系のカテゴリーのデバイスは図５に示すように通信プロトコルがＭＩＤＩプロトコルとされていることから、ステップＳ２２に分岐しＭＩＤＩプロトコルにおけるホストのアドレスである“０００１ ００１”の送信元アドレスが付加され、次いでデータ１〜データ３、あるいはデータ１〜データ１５からなるデータ部が送信されるＭＩＤＩプロトコル送信処理が行われる。ステップＳ２１あるいはステップＳ２２の送信処理が終了すると、ホスト送信処理も終了する。このＭＩＤＩプロトコル送信処理では、ホストは、例えばＭＩＤＩシーケンサデバイスに対しノートオンやノートオフ等のＭＩＤＩメッセージのコマンドを送信する。
【００７１】
次に、本発明にかかるＥバスシステムにおける鍵盤デバイスの送信／受信処理のフローチャートを図１３に示す。
図１３に示す鍵盤送信／受信処理においては、通信プロトコルが標準プロトコルとされていることから、ステップＳ３０において標準プロトコル送信／受信処理が行われる。この標準プロトコル送信処理では、アドレス指定する送信先アドレスとして、ホストにおける標準プロトコルのアドレスである“０００１ ０００”を指定して送信し、送信元アドレスとして自機のアドレスを指定して送信する。自機のアドレスは、カテゴリーＩＤが“００１０”とされサブアドレスは自機に設定されている３ビットのアドレスとなる。これらのアドレスに続いてデータ１〜データ３からなるデータ部を送信する。
また、標準プロトコル受信処理では、アドレス指定された送信先アドレスが自機のアドレスと一致した場合に、後続する送信元アドレスおよびデータ１〜データ３からなるデータ部を受信する。この場合の送信元アドレスには、ホストにおける標準プロトコルのアドレスである“０００１ ０００”が指定されている。
標準プロトコルではパネル系および鍵盤／パネル複合系のデバイスも通信を行うが、この際の送信／受信処理はカテゴリーＩＤが異なるだけで上記した鍵盤送信／受信処理と同様の処理が行われる。
【００７２】
次に、本発明にかかるＥバスシステムにおけるＭＩＤＩデバイスの送信／受信処理のフローチャートを図１４に示す。
図１４に示すＭＩＤＩ送信／受信処理においては、通信プロトコルがＭＩＤＩプロトコルとされていることから、ステップＳ４０においてＭＩＤＩプロトコル送信／受信処理が行われる。このＭＩＤＩプロトコル送信処理では、アドレス指定する送信先アドレスとして、ホストにおけるＭＩＤＩプロトコルのアドレスである“０００１ ００１”を指定して送信し、送信元アドレスとして自機のアドレスを指定して送信する。自機のアドレスは、カテゴリーＩＤが“０１０１”とされサブアドレスは自機に設定されている３ビットのアドレスとなる。これらのアドレスに続いてデータ１〜データ３、あるいはデータ１〜データ１５からなるデータ部を送信する。
また、ＭＩＤＩプロトコル受信処理では、アドレス指定された送信先アドレスが自機のアドレスと一致した場合に、後続する送信元アドレスおよびデータ１〜データ３、あるいはデータ１〜データ１５からなるデータ部を受信する。この場合の送信元アドレスには、ホストにおけるＭＩＤＩプロトコルのアドレスである“０００１ ００１”が指定されている。
【００７３】
ところで、ホストは、鍵盤からの鍵盤 ＯＮコマンドに応じて、ＭＩＤＩのノートオンメッセージを生成し、該ノートオンメッセージに応じて音源ユニットにおける楽音生成を制御したり、Ｅバスを介して該ノートオンメッセージをＭＩＤＩデバイスに送出したりする。また、パネルからのＳＷ ＯＮコマンドを受信した場合、そのＳＷ ＯＮコマンドの種類に応じて、発音用の音色データの選択、音色データの編集、自動演奏用の楽曲データの録音／再生、楽曲データの編集、自デバイスの設定変更、Ｅバスに接続された各デバイスの設定変更、等の処理を行なう。さらに、音色データの選択時は、例えば、パネルデバイスに対してＬＥＤコマンドを送信して選択された音色データに対応したＬＥＤを点灯させるとともに、ＭＩＤＩデバイスに当該選択に対応したプログラムチェンジのメッセージを送出する。さらにまた、ホストにおいて楽曲データの再生をしている時（自動演奏時）は、順次再生されるＭＩＤＩメッセージに応じて音源ユニットの楽音生成を制御するとともに、Ｅバスを介して同ＭＩＤＩメッセージをＭＩＤＩデバイスに送出する。
【００７４】
以上説明した本発明によれば、電子楽器を構成するデバイス間の通信をバスシステムを通じて行えるようになる。この場合、マスターから送出されるデータ信号に送信先とされるデバイスに固有のアドレスが付与されており、該アドレスはデバイスのカテゴリーを表すカテゴリー情報と、同種のカテゴリーのデバイスの内のいずれか１つのデバイスを特定するサブアドレスとから構成されている。これにより、バスシステムを通じて種々のカテゴリーのデバイス間で通信を行うことができるようになる。従って、電子楽器において、例えばデバイスとして鍵盤を新たに開発した際には、その鍵盤を電子楽器用バスシステムに接続するだけで新規開発した鍵盤を備える電子楽器を構成することができる。この場合、他のカテゴリーのデバイス、例えばパネル系やホスト系のデバイスはそのまま流用して使用することができるようになる。
さらに、機能の追加に伴ってデバイスを追加する場合には、追加するデバイスを電子楽器用バスシステムに接続するだけで、新たなデバイスを追加した電子楽器を構成できるようになる。これにより、製品開発コストを著しく低下させることができるようになる。また、機能の追加を短時間で行うことができるようになる。
このように本発明においては、各デバイスを他の製品に流用することができると共に、デバイス毎に分けて開発することを可能とすることができる。
【００７５】
さらに、鍵盤やパネルの操作入力デバイスとＭＩＤＩデバイスとで主要なパケット長を第１所定長に統一することにより、各デバイスにおける受信処理を単純化することができる。さらにまた、バイト長が長くなりがちなシステムエクスクルーシブのみ第１所定長より長い第２所定長で通信を行なうようにすることにより、システムエクスクルーシブの通信効率が落ちないようになる。さらにまた、複数の表示要素を同時に制御することが可能であり、同時に制御すべき表示要素の組に変更があまりない場合は、表示制御のためのコマンドの発行回数を少なくすることができる。さらにまた、ＭＩＤＩメッセージに影響を与えずに、電子楽器用バスシステムにおいてＭＩＤＩメッセージを送受信することができるようになる。
【産業上の利用可能性】
【００７６】
上記の説明では、鍵盤デバイスやパネルデバイスに備えられている各ＬＥＤはいずれか１つのグループに属するようになっていたが、１つのＬＥＤを複数のグループに所属させることができるようにしてもよい。その場合、そのＬＥＤの制御値は、そのＬＥＤが所属するグループの制御値の最大値、最小値、あるいは合成値とすればよい。また、上記の説明ではＥバスに接続されるデバイスとして「ホスト系」「鍵盤系」「パネル系」「ＭＩＤＩ系」を示したが、さらにこれ以外の種類のデバイスを接続するようにしてもよい。さらに、上記の説明ではＥバス上のデータのプロトコルとして「共通プロトコル」「標準プロトコル」「ＭＩＤＩプロトコル」の３つを示したが、さらにこれ以外のプロトコルを使用するようにしてもよい。
以上説明した本発明にかかるＥバスシステムは、アイ・スケア・シー（Ｉ2Ｃ）バスをベースとしている。そして、Ｅバスシステムにおいて言及しなかった点についてはＩ2Ｃバスに準拠している。
【符号の説明】
【００７７】
１ 電子楽器、１０ メインコントローラデバイス、１０ａ メイン基板、１１ Ｅバス、１２，１３ パネルデバイス、１２ａ パネル基板、１４，１５ 鍵盤デバイス、１４ａ 鍵盤基板、１６ ＭＩＤＩデバイス、１６ａ 基板、１７ 分岐基板、２１ バス、２２，２３，２４ 音源ユニット、２５，２６ Ｉ／Ｏユニット、３１ バス、３２ サウンドシステム、Ｂ１〜Ｂ６ バッファ、Ｒｐ プルアップ抵抗、ＴＲ１〜ＴＲ６ トランジスタ
【特許請求の範囲】
【請求項１】
クロックが転送されるシリアルクロックラインと、該シリアルクロックラインのクロック信号に同期したデータ信号が転送されるシリアルデータラインとを少なくとも備える電子楽器に内蔵されるバスシステムであって、
前記バスシステムに接続されている複数種類のデバイス間においては前記バスシステムを通じてデータの送受信が行われ、
前記デバイスはそれぞれ固有のアドレスを有し、
前記デバイスは、ホストデバイスと、前記バスシステムに対して着脱可能な任意の１ないし複数の鍵盤やパネル等とされる操作入力デバイスと、前記バスシステムに対して着脱可能な任意の１ないし複数のＭＩＤＩデバイスとを含み、
前記アドレスは、デバイスのカテゴリーを表すカテゴリー情報と、同種のカテゴリーのデバイスの内のいずれか１つのデバイスを特定するサブアドレスとでなり、
前記データの送受信は、少なくとも送信先アドレスを含むヘッダ部と送信されるデータの種別を示すインデックス情報とがデータに付加された固定長パケットによりなされ、
前記ホストデバイスは、前記アドレスのカテゴリー情報に基づき、前記データの送受信を行う他のデバイスが、前記操作入力デバイスであるか前記ＭＩＤＩデバイスであるかを識別し、
前記ホストデバイスと前記操作入力デバイスの間においては、第１プロトコルにて、送信しようとする制御・操作内容に対応するコントロールコマンドの種別を示すインデックス情報を含む前記固定長パケットが前記バスシステムに送信され、
前記ホストデバイスとＭＩＤＩデバイスとの間においては、第２プロトコルにて、送信しようとするＭＩＤＩメッセージのステータスバイトに対応した該ＭＩＤＩメッセージの種別を示すインデックス情報を含むとともに該ＭＩＤＩメッセージのデータバイトを前記パケットのデータとし、前記ＭＩＤＩメッセージが前記固定長パケットに変換されて前記バスシステムに送信されることを特徴とする電子楽器用バスシステム。
【請求項２】
クロックが転送されるシリアルクロックラインと、該シリアルクロックラインのクロック信号に同期したデータ信号が転送されるシリアルデータラインとを少なくとも備える電子楽器に内蔵されるバスシステムであって、
前記バスシステムに接続されている複数種類のデバイス間においては前記バスシステムを通じてデータの送受信が行われ、
前記デバイスはそれぞれ固有のアドレスを有し、
前記デバイスは、ホストデバイスと、前記バスシステムに対して着脱可能な任意の１ないし複数の鍵盤やパネル等とされる操作入力デバイスと、前記バスシステムに対して着脱可能な任意の１ないし複数のＭＩＤＩデバイスとを含み、
前記アドレスは、デバイスのカテゴリーを表すカテゴリー情報と、同種のカテゴリーのデバイスの内のいずれか１つのデバイスを特定するサブアドレスとでなり、
前記データの送受信は、少なくとも送信先アドレスを含むヘッダ部と送信されるデータの種別を示すインデックス情報とがデータに付加された固定長パケットによりなされ、
前記ホストデバイスは、前記アドレスのカテゴリー情報に基づき、前記データの送受信を行う他のデバイスが、前記操作入力デバイスであるか前記ＭＩＤＩデバイスであるかを識別し、
前記ホストデバイスと前記操作入力デバイスの間においては、第１プロトコルにて、制御・操作内容に対応するコントロールコマンドの種別を示すインデックス情報を含む前記固定長パケットが前記バスシステムから受信され、
前記ホストデバイスとＭＩＤＩデバイスとの間においては、第２プロトコルにて、ＭＩＤＩメッセージの種別を示すインデックス情報を含む前記固定長パケットが前記バスシステムから受信され、該受信した固定長パケットを、前記受信した固定長パケットのインデックス情報に対応するステータスバイトとし、前記受信した固定長パケットのデータをデータバイトとしたＭＩＤＩメッセージに変換することを特徴とする電子楽器用バスシステム。
【請求項１】
クロックが転送されるシリアルクロックラインと、該シリアルクロックラインのクロック信号に同期したデータ信号が転送されるシリアルデータラインとを少なくとも備える電子楽器に内蔵されるバスシステムであって、
前記バスシステムに接続されている複数種類のデバイス間においては前記バスシステムを通じてデータの送受信が行われ、
前記デバイスはそれぞれ固有のアドレスを有し、
前記デバイスは、ホストデバイスと、前記バスシステムに対して着脱可能な任意の１ないし複数の鍵盤やパネル等とされる操作入力デバイスと、前記バスシステムに対して着脱可能な任意の１ないし複数のＭＩＤＩデバイスとを含み、
前記アドレスは、デバイスのカテゴリーを表すカテゴリー情報と、同種のカテゴリーのデバイスの内のいずれか１つのデバイスを特定するサブアドレスとでなり、
前記データの送受信は、少なくとも送信先アドレスを含むヘッダ部と送信されるデータの種別を示すインデックス情報とがデータに付加された固定長パケットによりなされ、
前記ホストデバイスは、前記アドレスのカテゴリー情報に基づき、前記データの送受信を行う他のデバイスが、前記操作入力デバイスであるか前記ＭＩＤＩデバイスであるかを識別し、
前記ホストデバイスと前記操作入力デバイスの間においては、第１プロトコルにて、送信しようとする制御・操作内容に対応するコントロールコマンドの種別を示すインデックス情報を含む前記固定長パケットが前記バスシステムに送信され、
前記ホストデバイスとＭＩＤＩデバイスとの間においては、第２プロトコルにて、送信しようとするＭＩＤＩメッセージのステータスバイトに対応した該ＭＩＤＩメッセージの種別を示すインデックス情報を含むとともに該ＭＩＤＩメッセージのデータバイトを前記パケットのデータとし、前記ＭＩＤＩメッセージが前記固定長パケットに変換されて前記バスシステムに送信されることを特徴とする電子楽器用バスシステム。
【請求項２】
クロックが転送されるシリアルクロックラインと、該シリアルクロックラインのクロック信号に同期したデータ信号が転送されるシリアルデータラインとを少なくとも備える電子楽器に内蔵されるバスシステムであって、
前記バスシステムに接続されている複数種類のデバイス間においては前記バスシステムを通じてデータの送受信が行われ、
前記デバイスはそれぞれ固有のアドレスを有し、
前記デバイスは、ホストデバイスと、前記バスシステムに対して着脱可能な任意の１ないし複数の鍵盤やパネル等とされる操作入力デバイスと、前記バスシステムに対して着脱可能な任意の１ないし複数のＭＩＤＩデバイスとを含み、
前記アドレスは、デバイスのカテゴリーを表すカテゴリー情報と、同種のカテゴリーのデバイスの内のいずれか１つのデバイスを特定するサブアドレスとでなり、
前記データの送受信は、少なくとも送信先アドレスを含むヘッダ部と送信されるデータの種別を示すインデックス情報とがデータに付加された固定長パケットによりなされ、
前記ホストデバイスは、前記アドレスのカテゴリー情報に基づき、前記データの送受信を行う他のデバイスが、前記操作入力デバイスであるか前記ＭＩＤＩデバイスであるかを識別し、
前記ホストデバイスと前記操作入力デバイスの間においては、第１プロトコルにて、制御・操作内容に対応するコントロールコマンドの種別を示すインデックス情報を含む前記固定長パケットが前記バスシステムから受信され、
前記ホストデバイスとＭＩＤＩデバイスとの間においては、第２プロトコルにて、ＭＩＤＩメッセージの種別を示すインデックス情報を含む前記固定長パケットが前記バスシステムから受信され、該受信した固定長パケットを、前記受信した固定長パケットのインデックス情報に対応するステータスバイトとし、前記受信した固定長パケットのデータをデータバイトとしたＭＩＤＩメッセージに変換することを特徴とする電子楽器用バスシステム。
【図１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図１３】
【図１４】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図１３】
【図１４】
【公開番号】特開２０１０−１７６１４７（Ｐ２０１０−１７６１４７Ａ）
【公開日】平成２２年８月１２日（２０１０．８．１２）
【国際特許分類】
【出願番号】特願２０１０−８６８６９（Ｐ２０１０−８６８６９）
【出願日】平成２２年４月５日（２０１０．４．５）
【分割の表示】特願２００５−３６４４１０（Ｐ２００５−３６４４１０）の分割
【原出願日】平成１３年２月２７日（２００１．２．２７）
【出願人】（０００００４０７５）ヤマハ株式会社 (5,930)
【Ｆターム（参考）】
【公開日】平成２２年８月１２日（２０１０．８．１２）
【国際特許分類】
【出願日】平成２２年４月５日（２０１０．４．５）
【分割の表示】特願２００５−３６４４１０（Ｐ２００５−３６４４１０）の分割
【原出願日】平成１３年２月２７日（２００１．２．２７）
【出願人】（０００００４０７５）ヤマハ株式会社 (5,930)
【Ｆターム（参考）】
[ Back to top ]