JP5391684B2 - 電子鍵盤楽器およびその制御方法を実現するためのプログラム - Google Patents

Description

本発明は、自動演奏データに基づいて鍵盤を自動駆動する電子鍵盤楽器およびその制御方法を実現するためのプログラムに関する。

自動演奏データに基づいて鍵盤を自動駆動する電子鍵盤楽器は、従来から知られている（たとえば、特許文献１参照）。

一方、オーディオデータやビデオデータを含む音楽コンテンツをストリーミング配信するサービスや、このサービスによってストリーミング配信された音楽コンテンツを受信し、ストリーミング再生する電子音楽装置も、一般化している。
特許第３７０４７４７号公報

ところで、オーディオデータやビデオデータを含む音楽コンテンツをストリーミング再生しながら、これに合わせて鍵盤を自動駆動できれば、その視聴者は、あたかも自分の目の前でミュージシャンが音楽を演奏しているような雰囲気を味わうことができる。

しかし、音楽コンテンツのストリーミング再生に合わせて自動鍵盤演奏できるシステムは、今までに提案されていないので、このような視聴者の要望に応えることはできなかった。

本発明は、この点に着目してなされたものであり、オーディオデータやビデオデータを含む音楽コンテンツをストリーミング再生しながら、これに合わせて鍵盤を自動駆動することが可能となる電子鍵盤楽器およびその制御方法を実現するためのプログラムを提供することを目的とする。

上記目的を達成するため、請求項１に記載の電子鍵盤楽器は、複数の鍵を備えた鍵盤と、該鍵盤の各鍵を自動駆動する鍵駆動手段と、オーディオデータまたはビデオデータを含む音楽コンテンツをストリーミング配信するストリーミング配信サーバと接続する接続手段と、該接続手段を介して接続されたストリーミング配信サーバに対して音楽コンテンツの配信要求を行う要求手段と、該要求手段による配信要求に応じてストリーミング配信サーバからストリーミング配信される音楽コンテンツと、該音楽コンテンツに対応する鍵駆動用の自動演奏データを受信する受信手段と、該受信手段によって受信された音楽コンテンツを一時的に記憶する一時記憶手段と、前記受信手段によって受信された自動演奏データを再生し、その再生によって得られたノートイベントを前記鍵駆動手段に供給することで、前記複数の鍵のうち、当該ノートイベントに対応する鍵を駆動させる第１の再生手段と、前記一時記憶手段に記憶された音楽コンテンツをストリーミング再生する第２の再生手段と、前記一時記憶手段に音楽コンテンツが所定量蓄積されてから、前記自動演奏データの再生と前記音楽コンテンツのストリーミング再生を開始させることで、前記第１の再生手段による自動演奏データの再生と前記第２の再生手段による音楽コンテンツのストリーミング再生とを連携して行うように制御する制御手段とを有し、前記制御手段はさらに、再生開始時には、前記自動演奏データの再生を開始した後、所定時間待ってから前記音楽コンテンツのストリーミング再生を開始させる一方、再生の一時停止時には、前記再生開始時に生じた時間的なずれを維持し、当該一時停止から再生を再開するときには、所定時間を待たずに再生を再開させることを特徴とする。

請求項２に記載の電子鍵盤楽器は、請求項１の電子鍵盤楽器において、ユーザの操作に応じて、前記一時停止を指示する指示手段をさらに有し、前記制御手段は、前記指示手段によって再生の一時停止が指示されたときに、前記一時停止および当該一時停止からの再生の再開を行うことを特徴とする。

請求項３に記載の電子鍵盤楽器は、請求項１の電子鍵盤楽器において、前記音楽コンテンツのストリーミング再生中に、前記一時記憶手段に蓄積された音楽コンテンツがなくなったときには、前記制御手段は、前記自動演奏データの再生を一時停止させることを特徴とする。

請求項４に記載の電子鍵盤楽器は、請求項１の電子鍵盤楽器において、前記ストリーミング配信サーバからは、前記音楽コンテンツおよび自動演奏データに加えて、当該音楽コンテンツのストリーミング再生と当該自動演奏データの再生を同期させるための同期用マップデータが配信され、前記受信手段は、該配信された同期用マップデータを受信し、前記制御手段は、該受信された同期用マップデータに基づいて当該音楽コンテンツのストリーミング再生と当該自動演奏データの再生を同期させることで、両再生を連携して行うことを特徴とする。

上記目的を達成するため、請求項５に記載のプログラムは、請求項１と同様の技術的思想によって実現できる。

請求項１または５に記載の発明によれば、ストリーミング配信サーバから配信された自動演奏データを再生し、その再生によって得られたノートイベントを鍵駆動手段に供給することで、鍵盤に備えられた複数の鍵のうち、当該ノートイベントに対応する鍵を駆動するとともに、ストリーミング配信サーバからストリーミング配信された音楽コンテンツをストリーミング再生し、前記自動演奏データの再生と前記音楽コンテンツのストリーミング再生とを連携して行うようにしたので、音楽コンテンツをストリーミング再生しながら、これに合わせて鍵盤を自動駆動することが可能となる。

以下、本発明の実施の形態を図面に基づいて詳細に説明する。

図１は、本発明の一実施の形態に係る電子鍵盤楽器１００の概略構成を示すブロック図である。

同図に示すように、電子鍵盤楽器１００は、音高情報を含む演奏情報を入力するための複数の鍵からなる鍵盤１と、各種情報を入力するための複数のスイッチやダイアル、ホイールを含む設定操作子２と、前記複数の鍵のそれぞれを自動駆動するための鍵駆動回路３と、鍵盤１の各鍵の操作状態を検出する検出回路４と、設定操作子２の操作状態を検出する検出回路５と、装置全体の制御を司るＣＰＵ６と、該ＣＰＵ６が実行する制御プログラムや各種テーブルデータ等を記憶するＲＯＭ７と、演奏情報、各種入力情報および演算結果等を一時的に記憶するＲＡＭ８と、各種情報等を表示する、たとえば液晶ディスプレイ（ＬＣＤ）および発光ダイオード（ＬＥＤ）等を備えた表示装置９と、前記制御プログラムを含む各種アプリケーションプログラムや各種楽曲データ、各種データ等を記憶する記憶装置１０と、通信ネットワーク３００を介して、ストリーミング配信サーバ２００とデータの送受信を行う通信インターフェース（Ｉ／Ｆ）１１と、鍵盤１から入力された演奏情報や、前記記憶装置１０に記憶されたいずれかの楽曲データを再生して得られた演奏情報等を楽音信号に変換するとともに、その楽音信号に各種効果を付与するための音源・効果回路１２と、該音源・効果回路１２からの楽音信号を音響に変換する、たとえば、ＤＡＣ（digital-to-analog converter）やアンプ、スピーカ等のサウンドシステム１３とにより構成されている。

上記構成要素３〜１２は、バス１４を介して相互に接続され、通信Ｉ／Ｆ１１には通信ネットワーク３００が接続され、音源・効果回路１２にはサウンドシステム１３が接続されている。

ストリーミング配信サーバ２００は、電子鍵盤楽器１００からの配信要求に応じてオーディオ／（または）ビデオデータをストリーミング配信する。これに応じて電子鍵盤楽器１００は、受信したオーディオ／ビデオデータをストリーミング再生する。ストリーミング配信サーバ２００からオーディオデータが配信されたときには、電子鍵盤楽器１００は、そのオーディオデータをストリーミング再生し、再生したオーディオデータを音源・効果回路１２に供給する。オーディオデータは通常、圧縮化されており、その上暗号化されているものもあるので、音源・効果回路１２には、圧縮化されたオーディオデータを伸長するとともに暗号化されたオーディオデータを解読するデコード回路（図示せず）が含まれている。音源・効果回路１２に供給されたオーディオデータが、圧縮化されたものであればデコード回路によって伸長され、暗号化されたものであればデコード回路によって解読された後、後段のサウンドシステム１３に供給される。一方、ストリーミング配信サーバ２００からビデオデータが配信されたときには、電子鍵盤楽器１００は、そのビデオデータをストリーミング再生する。ビデオデータには通常、映像データと音声データ（＝オーディオデータ）が含まれているので、ビデオデータの再生によって得られた映像データおよび音声データはそれぞれ表示装置９および音源・効果回路１２に供給される。表示装置８は、映像データのデコード回路（図示せず）を含み、供給された映像データをこのデコード回路でデコードして前記ＬＣＤに供給する。ＬＣＤは、供給された映像データを表示する。これによりＬＣＤ上には、動画像が表示される。音源・効果回路１２は、供給された音声データを前記オーディオデータと同様に処理する。

記憶装置１０は、たとえば、フレキシブルディスク（ＦＤ）、ハードディスク（ＨＤ）、ＣＤ−ＲＯＭ、ＤＶＤ（digital versatile disc）、光磁気ディスク（ＭＯ）および半導体メモリなどの記憶媒体とその駆動装置である。記憶媒体は、駆動装置から着脱可能であってもよいし、記憶装置１０自体が、電子鍵盤楽器１００から着脱可能であってもよい。あるいは、記憶媒体も記憶装置１０も着脱不可能であってもよい。なお、記憶装置１０（の記憶媒体）には、前述のように、ＣＰＵ６が実行する制御プログラムも記憶でき、ＲＯＭ７に制御プログラムが記憶されていない場合には、この記憶装置１０に制御プログラムを記憶させておき、それをＲＡＭ８に読み込むことにより、ＲＯＭ７に制御プログラムを記憶している場合と同様の動作をＣＰＵ６にさせることができる。このようにすると、制御プログラムの追加やバージョンアップ等が容易に行える。

通信Ｉ／Ｆ１１は、前述のように、たとえばＬＡＮ（local area network）やインターネット、電話回線等の通信ネットワーク３００に接続されており、該通信ネットワーク３００を介して、ストリーミング配信サーバ２００に接続される。このように本実施の形態では、通信Ｉ／Ｆ１１として、汎用ネットワークＩ／Ｆを採用しているが、これに他の種類のＩ／Ｆ、具体的には、ＭＩＤＩ（musical instrument digital interface）信号などの音楽信号を専用に送受信する音楽専用有線Ｉ／Ｆ、ＵＳＢ（universal serial bus）やＩＥＥＥ１３９４（アイトリプルイー１３９４）などの汎用近距離有線Ｉ／Ｆ、無線ＬＡＮ（local area network）やＢｌｕｅｔｏｏｔｈ（登録商標）などの汎用近距離無線Ｉ／Ｆを加えるようにしてもよい。

ストリーミング配信サーバ２００は、電子鍵盤楽器１００の上記構成から、鍵盤１、設定操作子２、鍵駆動回路３、検出回路４，５、表示装置９、音源・効果回路１２およびサウンドシステム１３を除き、その代わりに、キーボード、マウスおよび大型ディスプレイを加えた、通常のサーバ用コンピュータ上に構築される。なおストリーミング配信サーバ２００は、本実施の形態では１台によって構成されているが、これに限らず、複数台によって構成されていてもよい。

図２は、鍵盤１の各鍵を自動駆動させる駆動方法の一例を示す図である。なお、本発明の特徴は鍵駆動の方法にある訳ではないので、周知の鍵駆動機構および鍵駆動方法を用いて各鍵を駆動させればよい。したがって同図には、各鍵（図示例では、そのうちの１つの鍵）を駆動させるための一般的な駆動機構および駆動方法の概略が示されている。そして、図２（ａ）は離鍵状態（非押鍵状態）を示し、図２（ｂ）は押鍵状態を示している。

図２（ａ）に示すように、鍵１ａは、係合部１ａ１を介してハンマ１ｂと係合されている。鍵１ａは、鍵支点１ｃを回動中心として回動し、ハンマ１ｂは、ハンマ支点１ｄを回動中心として回動する。ハンマ１ｂの長手方向の中心部よりやや後方部の下方には、たとえばソレノイドによって構成される鍵駆動機構１ｅが設けられている。

鍵１ａを自動押鍵するときには、前記ＣＰＵ６は、当該鍵１ａに割り当てられているノートナンバを含むノートオンイベントを前記鍵駆動回路３に供給する。これに応じて鍵駆動回路３から鍵駆動機構１ｅに所定の電力が供給され、鍵駆動機構１ｅは、図２（ｂ）に示すようにハンマ１ｂを上方向に押し上げる。ハンマ１ｂが上方向に押し上げられると、ハンマ１ｂの自由端１ｂ１は、ハンマ支点１ｄを回動支点として矢印Ａの方向に回動し、これに応じてハンマ１ｂの係合端１ｂ２は、矢印Ｂの方向に回動する。この係合端１ｂ２の回動が、係合部１ａ１を介して鍵１ａにも伝わり、鍵１ａは、鍵支点１ｃを回動支点として矢印Ｃの方向に回動する。これにより、鍵１ａは押鍵状態となる。

押鍵状態の鍵１ａを自動離鍵するときには、ＣＰＵ６は、当該鍵１ａに割り当てられているノートナンバを含むノートオフイベントを鍵駆動回路３に供給する。これに応じて鍵駆動回路３から鍵駆動機構１ｅへの電力供給が停止され、鍵１ａおよびハンマ１ｂは、離鍵状態から押鍵状態に至る際の動作と逆方向の動作により、離鍵状態となる。

なお鍵盤１の各鍵としては、上述のようにハンマを係合するタイプのものに限らず、ハンマを係合しないタイプのものを採用してもよい。また、ハンマを係合するタイプのものであっても、鍵駆動機構は、ハンマを介して鍵を駆動するのではなく、鍵を直接駆動するような構造としてもよい。さらに鍵駆動機構は、ソレノイドを用いたものに限らない。

図３は、ネットワーク構成の一例を示す図である。同図に示すように、インターネット等の通信ネットワーク３００には、電子鍵盤楽器１００と同様に構成された２台の電子鍵盤楽器１００ａおよび１００ｂと、１台のストリーミング配信サーバ２００が接続されている。このように本実施の形態では、１台のストリーミング配信サーバ２００が、複数の電子鍵盤楽器のそれぞれに異なったオーディオ／ビデオデータをストリーミング配信できるようになっている。ここで、オーディオデータのストリーミング配信とは、動画像データを含まない音声データのみ（ただし、静止画像データは含まれることがある）をストリーミング配信することを意味し、ビデオデータのストリーミング配信とは、動画像データとともに音声データもストリーミング配信することを意味する。

ストリーミング配信する方法には主として、ＲＴＰ（real-time transport protocol）やＲＴＳＰ（real time streaming protocol）によるものと、ＨＴＴＰ（hypertext transfer protocol）による擬似的なものとがある。電子鍵盤楽器１００は、後述するように、ストリーミング再生中のオーディオ／ビデオデータについて停止、早送り、巻き戻し、指定した位置からの再生などのＶＣＲ（video casette recorder） 形式の制御機能を実現するようにしている。そして上記３種類のプロトコルのうち、ＲＴＳＰだけに予めＶＣＲ形式の制御機能が備わっているので、ストリーミング配信のプロトコルとしてＲＴＳＰを採用すれば、電子鍵盤楽器１００上でＶＣＲ形式の制御機能を実現することが容易になる。具体的には、電子鍵盤楽器１００側からストリーミング配信サーバ２００に、ストリーミング配信中のオーディオ／ビデオデータの停止、早送り、巻き戻し、指定した位置からの再生などを指示すると、ストリーミング配信サーバ２００は、指示された制御機能が電子鍵盤楽器１００上で実現されるようなオーディオ／ビデオデータをストリーミング配信する。たとえば、電子鍵盤楽器１００からストリーミング配信サーバ２００に対して「早送り」を指示すると、ストリーミング配信サーバ２００は、電子鍵盤楽器１００が受信したオーディオ／ビデオデータをそのままストリーミング再生するだけで「早送り」となるようなオーディオ／ビデオデータを、電子鍵盤楽器１００にストリーミング配信する。このように電子鍵盤楽器１００上でＶＣＲ形式の制御機能を実現することが極めて容易になるので、ストリーミング配信のプロトコルとして、本実施の形態ではＲＴＳＰを採用することにする。ただし他のプロトコルを採用した場合でも、ＶＣＲ形式の制御機能を電子鍵盤楽器１００上で実現できない訳ではないので、ＲＴＳＰ以外のプロトコルを採用するようにしてもよい。

図４は、ストリーミング配信サーバ２００（の記憶装置）内に記憶されるストリーミング配信用データのフォーマットの一例を示す図であり、同図（ａ）〜（ｅ）に５種類の異なるフォーマットを採るストリーミング配信用データが示されている。ただし、ストリーミング配信サーバ２００が本実施の形態で実際にストリーミング配信するデータは、この５種類のストリーミング配信用データのうち、予め選択設定された１種類（たとえば、図４（ｂ）のストリーミング配信用データ）だけである。つまり、複数種類のフォーマットのストリーミング配信用データを例に挙げたのは、オーディオ／ビデオデータのストリーミング配信とこれに基づいたストリーミング再生は、特定の１種類のフォーマットのストリーミング配信用データに限られる訳ではなく、複数種類のフォーマットのストリーミング配信用データのいずれを用いても可能であることを明示するためである。

図４（ａ）は、ＭＩＤＩデータとオーディオ／ビデオデータを１つのファイル内に含むフォーマットを採るストリーミング配信用データ（以下、「第１フォーマットのストリーミング配信用データ」という）を示している。

同図（ａ）において、ＭＩＤＩデータは、鍵盤１を自動駆動するために用いられ、本実施の形態ではＳＭＦ（standard MIDI file）形式のもの、つまり、ヘッダチャンクとトラックチャンクからなり、トラックチャンクはＭＩＤＩイベント（＝デルタタイム＋ＭＩＤＩチャンネルメッセージ）、ＳｙｓＥｘイベント（＝デルタタイム＋システム・エクスクルーシブ・メッセージ）およびメタイベント（＝デルタタイム＋ＭＩＤＩチャンネルメッセージ以外の情報）を再生順に並べたシーケンスによって形成されたものを採用している。もちろん、他のフォーマットのＭＩＤＩデータを採用するようにしてもよいし、ＭＩＤＩのフォーマットを採らない自動演奏データであってもよい。

オーディオ／ビデオデータは、コンサート会場でのライブ演奏を録音／録画したライブ映像やプロモーション映像などの音楽コンテンツであって、少なくとも鍵盤楽器の演奏パートを含むものである。したがって当該音楽コンテンツは、鍵盤楽器のソロ演奏のみからなるものであってもよいし、鍵盤楽器のパートにボーカルパートやその他の楽器パートなどを加えた複数の演奏パートからなるものであってもよい。そしてオーディオ／ビデオデータは、複数のオーディオ／ビデオサンプルによって構成されている。つまり、オーディオ／ビデオサンプルを所定の周期で１サンプルずつ再生することにより、音声／映像が生成される。

オーディオ／ビデオデータがある曲のライブ演奏を録音／録画したものであり、ＭＩＤＩデータが汎用的に（たとえば、その曲の譜面通りに入力して）作成されたものであるとして、両者の再生を同時に開始させた場合、前者のテンポは演奏者の演奏に応じて変動するのに対して、後者のテンポは譜面通りに変動する（初期設定されたテンポがそのまま変動しないこともある）ので、生成された音声／映像と鍵盤１の駆動動作とは通常合わない。このため、ＭＩＤＩデータは、オーディオ／ビデオデータのテンポ変化に追従するように専用的に作成されている。たとえば、一定のテンポを設定せずに（フリーテンポで）各キーオンイベントを入力することにより、あるいは一定のテンポを設定し、適切な位置にテンポチェンジイベントを挿入することにより、当該オーディオ／ビデオデータと同様にテンポ変化するようなＭＩＤＩデータを作成する方法が考えられる。なおテンポチェンジイベントとしては、たとえばメタイベントに含まれる「セットテンポ」イベントを用いるようにすればよい。もちろんこれに限られず、ＳｙｓＥｘイベントで作るなどの他の方法を用いてもよい。また、ＭＩＤＩデータの再生には直接必要ではないものの、ＭＩＤＩデータの再生とオーディオ／ビデオデータの再生を連携させるために、ＭＩＤＩデータ内には、小節線の位置を示す小節線イベントを予め埋め込んでおくことにする。この小節線イベントも、メタイベントを用いればよいが、ＳｙｓＥｘイベントで作るなどの他の方法を用いてもよい。ただし、ＭＩＤＩデータにおける小節線の位置は演算によって簡単に求めることができるので、ＭＩＤＩデータ内に小節線イベントを予め埋め込んでおくことは、本発明に必須のものではなく、演算能力の低いＣＰＵ６を採用した場合に有用であるに過ぎない。

図４（ｂ）は、ＭＩＤＩデータと同期用マップデータとオーディオ／ビデオデータを１つのファイル内に含むフォーマットを採るストリーミング配信用データ（以下、「第２フォーマットのストリーミング配信用データ」という）を示している。

同図（ｂ）のＭＩＤＩデータは、図４（ａ）のＭＩＤＩデータに対して、汎用的に作られている点のみが異なっており、その使用目的およびフォーマットは同様である。同図（ｂ）のオーディオ／ビデオデータは、図４（ａ）のオーディオ／ビデオデータと同様に構成されたデータである。したがって、このようなＭＩＤＩデータおよびオーディオ／ビデオデータを同時に再生すると、図４（ａ）についての説明で上述した問題が生じるので、その問題を解消するために、同期用マップデータを含ませるようにしている。同期用マップデータとしては、具体的には、テンポを変化させるタイミングとテンポ値を示すテンポチェンジデータを１つ以上登録したテンポチェンジマップデータや、ＭＩＤＩデータの各小節線におけるオーディオ／ビデオデータのサンプル位置（つまり、ＭＩＤＩデータにおける各小節線の位置で再生されるべきオーディオ／ビデオデータのサンプル番号）を示すサンプル位置データを登録したサンプル位置マップデータなどを挙げることができる。

図４（ｃ）は、ＭＩＤＩデータとオーディオ／ビデオデータとをそれぞれ別ファイルで形成したフォーマットを採るストリーミング配信用データ（以下、「第３フォーマットのストリーミング配信用データ」という）を示している。

第３フォーマットのストリーミング配信用データは、前記第１フォーマットのストリーミング配信用データに対して、ＭＩＤＩデータとオーディオ／ビデオデータとを１つのファイル内に含ませるのではなく、別々のファイルで構成している点が主として異なっており、個々のデータの使用目的およびフォーマットは異なっていない。ただし、第３フォーマットのストリーミング配信用データのＭＩＤＩデータには、第３フォーマットのストリーミング配信用データのオーディオ／ビデオデータのファイルを特定するための情報（たとえば、コマンド）が含まれている。第３フォーマットのストリーミング配信用データがストリーミング配信される場合、まず電子鍵盤楽器１００は、ストリーミング配信サーバ２００に対してオーディオ／ビデオデータのストリーミング配信要求を送信する。これに応じてストリーミング配信サーバ２００は、当該オーディオ／ビデオデータのファイルに対応付けられたＭＩＤＩデータのファイルを電子鍵盤楽器１００に配信する。次に電子鍵盤楽器１００は、ストリーミング配信サーバ２００からのＭＩＤＩデータを受信し、そこに含まれている、オーディオ／ビデオデータのファイルを特定するコマンドを読み出し、そのコマンドによって特定されるオーディオ／ビデオデータのファイルのストリーミング配信要求をストリーミング配信サーバ２００に送信する。これに応じてストリーミング配信サーバ２００は、当該オーディオ／ビデオデータを電子鍵盤楽器１００にストリーミング配信する。

図４（ｄ）は、ＭＩＤＩデータとオーディオ／ビデオデータとをそれぞれ別ファイルで形成したフォーマットを採るストリーミング配信用データ（以下、「第４フォーマットのストリーミング配信用データ」という）を示している。

前記第３フォーマットのストリーミング配信用データが、ＭＩＤＩデータ中にオーディオ／ビデオデータのファイルを特定するコマンドを含ませるように構成されているのに対して、第４フォーマットのストリーミング配信用データは、オーディオ／ビデオデータ中にＭＩＤＩデータのファイルを特定するコマンドを含ませるように構成されている点が異なっている。したがって第４フォーマットのストリーミング配信用データがストリーミング配信される場合、電子鍵盤楽器１００からストリーミング配信サーバ２００に対してオーディオ／ビデオデータのストリーミング配信要求が送信されると、第３フォーマットのストリーミング配信用データとは逆に、まずストリーミング配信サーバ２００は電子鍵盤楽器１００に当該オーディオ／ビデオデータをストリーミング配信し、電子鍵盤楽器１００は、このストリーミング配信されたオーディオ／ビデオデータを受信し、そこに含まれている、ＭＩＤＩデータのファイルを特定するコマンドを読み出し、そのコマンドによって特定されるＭＩＤＩデータのファイルの配信要求をストリーミング配信サーバ２００に送信する。これに応じてストリーミング配信サーバ２００は、当該ＭＩＤＩデータを電子鍵盤楽器１００に配信する。なお、コマンドを含ませる（記載する）オーディオ／ビデオデータの一部は、オーディオ／ビデオデータの先頭近傍が望ましい。これは、オーディオ／ビデオデータのストリーミング配信が開始されてから、それと同時に再生すべきＭＩＤＩデータの配信要求をストリーミング配信サーバ２００に送信するため、オーディオ／ビデオデータのストリーミング配信が開始されてからできるだけ短時間でコマンドを見つける必要があるからである。

なお、第３フォーマットのストリーミング配信用データも第４フォーマットのストリーミング配信用データも、ＭＩＤＩデータは専用的に作成されたものを採用したが、ＭＩＤＩデータは汎用的に作成されたものを採用し、これに加えて、前記第２フォーマットのストリーミング配信用データの「同期用マップデータ」に相当するものを別ファイルで用意しておき、この同期用マップデータのファイルをＭＩＤＩデータあるいはオーディオ／ビデオデータから参照可能に構成してもよい。

図４（ｅ）は、設定ファイルとＭＩＤＩデータとオーディオ／ビデオデータとをそれぞれ別ファイルで形成したフォーマットを採るストリーミング配信用データ（以下、「第５フォーマットのストリーミング配信用データ」という）を示している。

同図（ｅ）において、設定ファイルは、同時に再生すべきＭＩＤＩデータのファイルとオーディオ／ビデオデータのファイルを特定するための情報（たとえば、ファイル名）を記載したものである。また、ＭＩＤＩデータとオーディオ／ビデオデータは、それぞれが別ファイルで構成されていることを除き、前記第１フォーマットのストリーミング配信用データのＭＩＤＩデータとオーディオ／ビデオデータと同様である。第５フォーマットのストリーミング配信用データでは、第１フォーマットのストリーミング配信用データのようにＭＩＤＩデータとオーディオ／ビデオデータとを１つのファイルにまとめたり、第３あるいは第４フォーマットのストリーミング配信用データのようにＭＩＤＩデータ内あるいはオーディオ／ビデオデータ内に特殊なコマンドを含ませたりする必要がないので、配信側では、既存のＭＩＤＩデータやおよびーディオ／ビデオデータに特別な加工を施さずにそのまま配信できる一方、受信側でも、受信したＭＩＤＩデータおよびオーディオ／ビデオデータに特別な加工を施さずにそのまま既存の再生手法で再生することができ、非常に都合がよい。

第５フォーマットのストリーミング配信用データがストリーミング配信される場合、電子鍵盤楽器１００からストリーミング配信サーバ２００に対してオーディオ／ビデオデータのストリーミング配信要求が送信されると、まずストリーミング配信サーバ２００は、当該オーディオ／ビデオデータのファイルに対応付けられた設定ファイルを電子鍵盤楽器１００に配信する。これに応じて電子鍵盤楽器１００は、ストリーミング配信サーバ２００からの設定ファイルを受信し、そこに記載されている、ＭＩＤＩデータのファイルおよびオーディオ／ビデオデータのファイルを特定する情報を読み出し、その情報によって特定されるＭＩＤＩデータのファイルおよびオーディオ／ビデオデータのファイルのストリーミング配信要求をストリーミング配信サーバ２００に送信する。これに応じてストリーミング配信サーバ２００は、電子鍵盤楽器１００に対して当該ＭＩＤＩデータのファイルを配信するとともにオーディオ／ビデオデータをストリーミング配信する。

なお、第５フォーマットのストリーミング配信用データも、ＭＩＤＩデータは専用的に作成されたものを採用したが、ＭＩＤＩデータは汎用的に作成されたものを採用し、これに加えて、前記第２フォーマットのストリーミング配信用データの「同期用マップデータ」に相当するものを別ファイルで用意しておき、設定ファイル内に、この同期用マップデータのファイルを特定する情報を記載しておくようにしてもよい。

以上のように構成された電子鍵盤楽器１００が実行する制御処理を、まずその概要を図２〜図４を参照して説明し、次に図５〜図８を参照して詳細に説明する。

まず電子鍵盤楽器１００（図３では、通信ネットワーク３００に２台の電子鍵盤楽器１００ａおよび１００ｂが接続されているが、そのうちのいずれか１台に相当する）は、ストリーミング配信サーバ２００に対して、ストリーミング配信サーバ２００がストリーミング配信可能なオーディオ／ビデオデータの、たとえば名称一覧の配信要求を送信する。これに応じてストリーミング配信サーバ２００がオーディオ／ビデオデータの名称一覧を配信すると、電子鍵盤楽器１００は、このオーディオ／ビデオデータの名称一覧を受信して、前記表示装置９のＬＣＤ上に表示する。ユーザが、ＬＣＤ上に表示されたオーディオ／ビデオデータの名称一覧からいずれかの名称を選択し、その名称のオーディオ／ビデオデータのストリーミング配信を指示すると、電子鍵盤楽器１００は、ストリーミング配信サーバ２００に対して当該オーディオ／ビデオデータの配信要求を送信する。これに応じてストリーミング配信サーバ２００は、電子鍵盤楽器１００に対して当該オーディオ／ビデオデータを含むストリーミング配信用データを配信する。ストリーミング配信サーバ２００は、前記図４に示したように第１フォーマットから第５フォーマットまでの５種類のストリーミング配信用データを配信可能であるが、説明の都合上、そのうちの１つ、たとえば第２フォーマットのストリーミング配信用データ（図４（ｂ））を常に配信するものとする。電子鍵盤楽器１００のユーザは通常、自分の選択指示したオーディオ／ビデオデータがストリーミング配信されて、電子鍵盤楽器１００上でストリーミング再生されれば、配信されるデータのフォーマットは問わないので、ストリーミング配信サーバ２００がどのようなフォーマットのストリーミング配信用データを配信しようと構わないからである。以下、ストリーミング配信用データのフォーマットが第２のフォーマットであって、他のフォーマットを用いていないことが明確である場合には、単に「ストリーミング配信用データ」と表現する。

ストリーミング配信サーバ２００は、自身の記憶装置に記憶されている複数のストリーミング配信用データ（のファイル）から、配信要求されたオーディオ／ビデオデータを含むストリーミング配信用データ（のファイル）を読み出し、そのストリーミング配信用データ（のファイル）に含まれる３種類のデータのうち、まずＭＩＤＩデータを配信し、次に同期用マップデータを配信する。ＭＩＤＩデータも同期用マップデータも、オーディオ／ビデオデータと比較してそのデータ容量は非常に小さく、ストリーミング配信によって配信する必要はないため、ダウンロード配信（本実施の形態では、ＴＣＰを用いた配信）によって配信される。ＭＩＤＩデータおよび同期用マップデータの配信が終了すると、ストリーミング配信サーバ２００は、オーディオ／ビデオデータのストリーミング配信を開始する。なお、ＭＩＤＩデータと同期用マップデータもストリーミング配信するようにしてもよい。

ストリーミング配信サーバ２００は、ＭＩＤＩデータおよび同期用マップデータとオーディオ／ビデオデータとを異なったプロトコルで配信するものの、いずれのデータもパケット形式で配信するので、電子鍵盤楽器１００は、各データのパケットを、たとえば前記通信Ｉ／Ｆ１１内に設けられた１つの受信バッファ（図示せず）で受信し、所定量溜まった（受信した）時点でデータの種類に応じた処理を行う。具体的には、受信したデータがＭＩＤＩデータあるいは同期用マップデータの場合には、そのデータを受信バッファから前記ＲＡＭ８内に移動させて保存し、受信したデータがオーディオ／ビデオデータの場合には、そのデータを受信バッファから直接読み出してストリーミング再生する。

電子鍵盤楽器１００は、オーディオ／ビデオデータのストリーミング再生に合わせてＭＩＤＩデータを再生し、ＭＩＤＩデータの再生によって得られたノートイベント（ノートオンイベントあるいはノートオフイベント）を前記鍵駆動回路３に供給することで鍵盤１を自動駆動させるようにしている。このため、オーディオ／ビデオデータのストリーミング再生を開始させるタイミングとＭＩＤＩデータの再生を開始させるタイミングとを連携させるようにしている。より具体的には、オーディオ／ビデオデータが所定量溜まった時点で、そのオーディオ／ビデオデータのストリーミング再生を開始させるとともに、ＭＩＤＩデータの再生を開始させる。さらに、ＭＩＤＩデータの再生によって得られたノートイベントが鍵駆動回路３に供給されてから駆動対象となる鍵の押鍵あるいは離鍵が完了するまでにかかる時間差（たとえば、５０〜１００ｍｓｅｃ程度）を考慮して、ＭＩＤＩデータの再生を開始させてから当該時間差だけ待った後、オーディオ／ビデオデータのストリーミング再生を開始させるようにしている。これにより、オーディオ／ビデオデータのストリーミング再生とＭＩＤＩデータの再生を同時に開始させたときに生じる、サウンドシステム１３から発生するピアノ音と鍵盤１の押離鍵とのわずかなずれまでをも解消させることができる。ただしこのずれの程度は、鍵駆動回路３や前記鍵駆動機構１ｅの性能によって変動するため、このずれがその性能によって無視できる程度であれば、オーディオ／ビデオデータのストリーミング再生とＭＩＤＩデータの再生を同時に開始させるようにしてもよい。

オーディオ／ビデオデータのストリーミング再生とＭＩＤＩデータの再生が進んで行くと、両データの元々のテンポの違いから、オーディオ／ビデオデータのストリーミング再生とＭＩＤＩデータの再生との間にずれが生じることになる。そこで電子鍵盤楽器１００では、同期用マップデータに基づいてＭＩＤＩデータの再生テンポを当該ＭＩＤＩデータの元々のテンポから変動させ、オーディオ／ビデオデータの再生テンポに合わせる（同期させる）ようにしている。同期用マップデータが前記テンポチェンジマップデータである場合には、ＭＩＤＩデータの再生タイミングがテンポチェンジマップデータに登録されている各テンポチェンジデータに含まれるタイミング（テンポを変化させるタイミング）に至る度に、電子鍵盤楽器１００は、現在の再生テンポを当該テンポチェンジデータに含まれるテンポ値に変更する。これにより、ＭＩＤＩデータの再生テンポがその都度更新されて、オーディオ／ビデオデータの再生テンポに追従することになる。一方、同期用マップデータが前記サンプル位置マップデータである場合には、ＭＩＤＩデータの再生タイミングが各小節の先頭（小節線の位置）に至る度に、電子鍵盤楽器１００は、当該小節線の位置を含むサンプル位置データから、そこに含まれるオーディオ／ビデオデータのサンプル位置を読み出し、そのオーディオ／ビデオデータのサンプル位置（サンプル番号）と実際に再生されているオーディオ／ビデオデータのサンプル位置（サンプル番号）を比較し、両者が一致するようにＭＩＤＩデータの再生タイミングを合わせる。これにより、ＭＩＤＩデータの再生タイミングがその都度更新されて、オーディオ／ビデオデータの再生タイミングに追従することになる。なお本実施の形態では、ＭＩＤＩデータの再生テンポや再生タイミングを変動させ、オーディオ／ビデオデータの再生テンポは元々の再生テンポのままとしたが、これは説明の都合上そうしたに過ぎないので、オーディオ／ビデオデータの再生テンポあるいは再生タイミングを変動させ、ＭＩＤＩデータの再生テンポは元々のテンポのままとしてもよい。

なお、ストリーミング配信用データとして前記第１フォーマットのストリーミング配信用データを用いた場合、電子鍵盤楽器１００はＭＩＤＩデータをそのまま再生するだけで、ＭＩＤＩデータの再生テンポがオーディオ／ビデオデータの再生テンポに追従して行くことになる。

このように本実施の形態では、オーディオ／ビデオデータをストリーミング再生しながら、これに合わせて鍵盤を自動駆動することが可能となる。

次に、この制御処理を詳細に説明する。

ユーザが前記設定操作子２に含まれるモード切替スイッチ（図示せず）を操作することにより、動作モードを他のモードからストリーミング再生モードに切り替えた後、前述のように、ストリーミング配信サーバ２００に対して、ストリーミング配信可能なオーディオ／ビデオデータの名称一覧の配信を要求すると、ストリーミング配信サーバ２００から電子鍵盤楽器１００にその名称一覧が送信されて、電子鍵盤楽器１００の表示装置９上に表示される。この中からユーザがいずれかの名称を選択して、その名称のオーディオ／ビデオデータのストリーミング配信を指示すると、前記ＣＰＵ６は、ファイル要求＆（および）受信処理を起動する。

図５は、このファイル要求＆受信処理の手順を示すフローチャートであり、同図には、この処理に応じてストリーミング配信サーバ２００が実行するストリーミング配信処理の手順を示すフローチャートも記載されている。

本ファイル要求＆受信処理が起動されると、まずＣＰＵ６は、ユーザによってストリーミング配信が指示されたオーディオ／ビデオデータを含むファイルの配信要求をストリーミング配信サーバ２００に送信する（ステップＳ１）。これに応じてストリーミング配信サーバ２００は、配信要求されたファイルをストリーミング配信する（ステップＳ１０１）。このときストリーミング配信サーバ２００は、前述のように第２フォーマットのストリーミング配信用データを配信するので、ステップＳ１０１の処理では、ストリーミング配信サーバ２００は、ストリーミング配信要求されたオーディオ／ビデオデータを含むストリーミング配信用データ（のファイル）から、まずＭＩＤＩデータを読み出して（ダウンロード）配信し、すべてのＭＩＤＩデータの配信が完了すると、次に同期用マップデータを読み出して（ダウンロード）配信し、すべての同期用マップデータの配信が完了すると、次にオーディオ／ビデオデータを読み出してストリーミング配信する。

ストリーミング配信サーバ２００から電子鍵盤楽器１００に配信されて来たデータ（前述のようにパケット形式のデータ）は、前述のようにそのデータの種類に拘わらず前記受信バッファに蓄積される（ステップＳ２）。そして、受信バッファへのデータの蓄積は、ストリーミング配信サーバ２００からのデータの配信が完了するまでなされる（ステップＳ３）。ただし、受信バッファにデータが所定量溜まると、図６を用いて後述するように、その溜まったデータは、前記ＲＡＭ８内に保存されて受信バッファから消去されるか、あるいはストリーミング再生されて再生された分だけ受信バッファから消去されるので、受信したデータが受信バッファから溢れてしまうことはない。

図６は、電子鍵盤楽器１００、特にＣＰＵ６が実行するストリーミング再生制御処理の手順を示すフローチャートである。本ストリーミング再生制御処理は、前記ファイル要求＆受信処理が起動されたときに起動され、ファイル要求＆受信処理が終了したときに終了する。

本ストリーミング再生制御処理が起動されると、まずＣＰＵ６は、受信バッファに所定量のデータが溜まっているかどうかをチェックし（ステップＳ１１）、受信バッファに所定量のデータが溜まっていなければ溜まるまで待ち、溜まっていればそのデータの種類を判別する（ステップＳ１２）。そしてＣＰＵ６は、溜まったデータがＭＩＤＩデータ、同期用マップデータまたはオーディオ／ビデオデータのいずれであるかに応じて処理を分岐させる。

溜まったデータがＭＩＤＩデータである場合には、ＣＰＵ６は、処理をステップＳ１３に進め、そのＭＩＤＩデータをＲＡＭ８の所定位置に確保されたＭＩＤＩデータ再生用バッファ（図示せず）に保存し、受信バッファに溜まったＭＩＤＩデータを消去する。なお所定量のデータが、ストリーミング配信サーバ２００が配信すべきＭＩＤＩデータ全体のデータ量より小さい場合もあるが、この場合には、所定量のＭＩＤＩデータを受信する毎にＣＰＵ６は、その受信した所定量のＭＩＤＩデータをＭＩＤＩデータ再生用バッファに追加保存して行く。これにより、何度かの追加保存が繰り返された後、最終的にＭＩＤＩデータ全体がＭＩＤＩデータ再生用バッファに保存される。

また、溜まったデータが同期用マップデータである場合には、ＣＰＵ６は、処理をステップＳ１４に進め、その同期用マップデータをＲＡＭ８の所定位置に確保された同期用マップデータ保存用バッファ（図示せず）に保存し、受信バッファに溜まった同期用マップデータを消去する。同期用マップデータ全体のデータ量も、受信バッファで受信される所定量より大きい場合があるが、この場合には、ＭＩＤＩデータでの場合と同様に、所定量の同期用マップデータが何度か同期用マップデータ保存用バッファに追加保存された後、最終的に同期用マップデータ全体が同期用マップデータ保存用バッファに保存される。なお図６において、ステップＳ１４の処理の枠が破線で描かれているが、これは、前記第１フォーマットのストリーミング配信用データが配信される場合のように同期用マップデータが配信されないことがあり、この場合にはステップＳ１４の処理は省略されることを意味している。

さらに、溜まったデータがオーディオ／ビデオデータである場合には、ＣＰＵ６は、処理をステップＳ１５に進め、まずＭＩＤＩデータの再生を開始するとともに鍵盤１から入力されるキーオン／キーオフを無効化する。ＭＩＤＩデータの再生は、図７を用いて後述するように、所定時間（本実施の形態では、１ティック（tick））毎に発生する第１のタイマ割込み信号（以下、「タイマ割込み信号＃１」という）に応じて起動されるＭＩＤＩデータ再生処理によってなされるので、上記「ＭＩＤＩデータの再生を開始する」とは、タイマ割込み信号＃１の発生を許可することを意味する。なお、タイマ割込み信号＃１は、ＭＩＤＩデータが「再生中」でないとき（たとえば、早送り／巻き戻し／一時停止などが継続中のとき）でも発生させ、さらに「再生中」かどうかによってＭＩＤＩデータ再生処理内の手順を異ならせているので、つまり、「再生中」かどうかの判別を必要とするので、本実施の形態ではこの判別を、現在の再生状況を示すためにＲＡＭ８の所定位置に設けた再生状況インデックス（図示せず）に基づいて行うようにしている。再生状況インデックスには、「再生中」、「早送り中」、「巻き戻し中」、「一時停止中」、「再開」および「停止中」などを示す情報のいずれかが格納される。そしてＣＰＵ６は、タイマ割込み信号＃１の発生を許可する際に、再生状況インデックスへ「再生中」（を示す情報）の書き込みも行うようにしている。また、鍵盤１からのキーオン／キーオフを無効化するのは、ストリーミング再生モードでは、鍵盤１が自動駆動されたとしても（もちろんユーザ自身が押離鍵したとしても）、そのキーオン／キーオフに応じた楽音信号を音源・効果回路１２から発生させないようにしているからである。つまりストリーミング再生モードでは、サウンドシステム１３からは、鍵盤１に対する鍵操作に応じて得られる（通常の演奏モードでは得られるはずの）楽音は発生されず、オーディオ／ビデオデータをストリーミング再生することで得られた楽音が発生される。なお、キーオン／キーオフを無効化する方法としては、前記検出回路４が鍵盤１の各鍵に対して行うキースキャンを停止させる方法や、鍵盤１に対する押離鍵があったとしても検出回路４からキーオン／キーオフを出力させない方法などが考えられる。もちろん、これらの方法以外でも、鍵盤１に対する押離鍵があったとしても音源・効果回路１２からそれに応じた楽音信号を発生させないようにする方法であれば、どのような方法を採用してもよい。

次にＣＰＵ６は、所定時間（前述のように、たとえば５０〜１００ｍｓｅｃ程度）待った（ステップＳ１６）後、オーディオ／ビデオデータの再生を開始させる（ステップＳ１７）。所定時間待つ理由は、制御処理の概要の説明内で前述したので、ここでは繰り返さない。ただし一時停止状態から再生が再開されたとき（前記「再開」時）には、ステップＳ１６の「所定時間待つ処理」は行わない。その理由は、再生開始時に生じさせた時間的なずれが再開時にも維持されているからである。したがって「早送り」や「巻き戻し」などで、再生開始時に生じさせた時間的なずれが解消された場合には、その後の再生時に再度、ステップＳ１６の「所定時間待つ処理」を行うようにすればよい。オーディオ／ビデオデータの再生は、図８を用いて後述するように、所定時間（本実施の形態では、１０ｍｓｅｃ）毎に発生する第２のタイマ割込み信号（以下、「タイマ割込み信号＃２」という）に応じて起動されるオーディオ／ビデオデータ再生処理によってなされるので、上記「オーディオ／ビデオデータの再生を開始させる」とは、タイマ割込み信号＃２の発生を許可することを意味する。なお、タイマ割込み信号＃２は、オーディオ／ビデオデータが「再生中」でないときでも発生させ、さらに「再生中」かどうかによってオーディオ／ビデオデータ再生処理内の手順を異ならせているので、オーディオ／ビデオデータ再生処理用の再生状況インデックスも必要であるが、ＭＩＤＩデータの再生状況とオーディオ／ビデオデータの再生状況とは連動するので、再生状況インデックスは１つだけ設けることにし、これをＭＩＤＩデータ再生処理でもオーディオ／ビデオデータ再生処理でも用いることにする。

次にＣＰＵ６は、ＭＩＤＩデータおよびオーディオ／ビデオデータの再生中（＝再生状況インデックスに「再生中」が書き込まれているとき）に受信バッファが空になったかどうかを判別する（ステップＳ１８）。この判別は、オーディオ／ビデオデータのストリーミング再生中に、通信ネットワーク３００が混雑したり、ユーザが早送り／巻き戻し／一時停止などを指示したりして、受信バッファ内のオーディオ／ビデオデータが空になっても、ＭＩＤＩデータおよびオーディオ／ビデオデータの再生を続けていれば、ＭＩＤＩデータの再生とオーディオ／ビデオデータの再生との間にずれが生じる（つまり、ＭＩＤＩデータの再生は前記ＭＩＤＩデータ再生用バッファに保存されているＭＩＤＩデータに基づいてなされるので、受信バッファ内のデータが空であるかどうかに拘わらずその再生は適正に進行するのに対して、オーディオ／ビデオデータの再生は受信バッファ内のデータに基づいてなされるので、受信バッファ内のデータが空になるとその再生は不可能となって、適正に進行しなくなるからである）などの問題を事前に解消するために行っている。したがって、ステップＳ１８の判別で、ＭＩＤＩデータおよびオーディオ／ビデオデータの再生中に受信バッファが空になったときには、ＣＰＵ６は、その再生を一時停止させる。つまり、再生状況インデックスに「一時停止中」を書き込む。

図７は、前記ＭＩＤＩデータ再生処理の手順を示すフローチャートであり、本ＭＩＤＩデータ再生処理は、前述のように１ティック毎に発生するタイマ割込み信号＃１に応じて起動され、実行される。ここでタイマ割込み信号＃１の発生周期として１ティックを用いたのは、ＳＭＦにおけるデルタタイムは１ティックを単位とする整数値によって表されているため簡単にＭＩＤＩデータを再生することができるからである。これ以上の理由はないので、ＭＩＤＩデータの再生を適正に行うことができれば、タイマ割込み信号＃１の発生周期は１ティックに限らない。なお、１ティック＝６０×１０００／テンポ／タイムベース（ｍｓｅｃ）によって算出される。ただし、タイムベースは４分音符長のティック数を示し、前記ヘッダチャンク内に記載されている。

本ＭＩＤＩデータ再生処理は主として、
（１）同期用マップデータに応じたテンポ／タイミング変更処理（ステップＳ２１）
（２）早送り／巻き戻し／一時停止／再開等の指示に応じた制御処理（ステップＳ２２）
（３）再生中の処理（ステップＳ２４〜Ｓ２９）
によって構成され、
上記（３）の再生中の処理は主として、
（３ａ）テンポチェンジイベントに応じたテンポ変更処理（ステップＳ２４）
（３ｂ）ノートイベントに応じた鍵駆動処理（ステップＳ２６）
（３ｃ）ＭＩＤＩデータ再生処理の終了時処理（ステップＳ２８，Ｓ２９）
によって構成されている。ただし上記（１）の処理と上記（３ａ）の処理は、後述するように、ストリーミング配信用データのフォーマットの種類（つまり、同期用マップデータが含まれるかどうか）に応じていずれか一方が選択的に実行される。

本ＭＩＤＩデータ再生処理が起動されると、まずＣＰＵ６は、処理を前記（１）の同期用マップデータに応じたテンポ／タイミング変更処理に進める。この（１）同期用マップデータに応じたテンポ／タイミング変更処理では、ＣＰＵ６は、前記同期用マップデータ保存用バッファに保存されている同期用マップデータを検索し、同期用マップデータに登録されているデータの中で現在読み出すべきものがあれば、それを読み出す。

同期用マップデータが前記テンポチェンジマップデータである場合には、このテンポチェンジマップデータには、前述のようにテンポチェンジデータが１つ以上登録されているので、前記検索では、現在の再生タイミングと各テンポチェンジデータ内のタイミングとを比較し、一致するものがあれば、そのタイミングを含むテンポチェンジデータからそこに含まれているテンポ値を読み出す。そしてＣＰＵ６は、読み出したテンポ値に応じてタイマ割込み信号＃１の発生周期を変更する。タイマ割込み信号＃１の発生周期である１ティックは、その算出式から分かるようにテンポに依存するので、タイマ割込み信号＃１の発生周期を変更することが、ＭＩＤＩデータ再生処理のテンポを変更することになる。ここで現在の再生タイミングは、本実施の形態では、当該ＭＩＤＩデータの再生を開始してから現在に至るまでの総ティック数で表現する方法を採用する。そしてティック数のカウントは、前記（３）の再生中の処理内で行うようにすればよい。なお現在の再生タイミングを表現する方法には、上記総ティック数で表現する方法の他にも、当該ＭＩＤＩデータの再生を開始してから現在に至るまでの経過時間で表現する方法も考えられるが、経過時間を本ＭＩＤＩデータ再生処理中で計時した場合、本ＭＩＤＩデータ再生処理の起動周期としてテンポに応じて値の変動するティックを用い、しかもテンポは頻繁に変動する可能性があるので、テンポが変動する度にそれを考慮して経過時間を計時しなければならず、他方、経過時間を計時するために作成した専用ルーチン中で計時した場合、ＭＩＤＩデータの再生を開始すると同時に経過時間の計時を開始させ、その再生が一時停止あるいは停止すると同時に経過時間の計時も一時停止あるいは停止させなければならず、双方とも制御処理が複雑化するため、本実施の形態では、制御処理がより簡単な総ティック数で表現する方法を採用している。ただし、既に他の目的で、たとえばＭＩＤＩデータの再生時間を表示させる目的で経過時間を計時している場合には、それを現在の再生タイミングに利用するようにしてもよい。

一方、同期用マップデータが前記サンプル位置マップデータである場合には、まずＣＰＵ６は、
（Ａ）現在の再生タイミングが当該ＭＩＤＩデータに含まれるいずれかの小節線イベントの発生タイミングに一致しているかどうか
（Ｂ）オーディオ／ビデオデータの現在の再生位置（現在サンプル位置）がサンプル位置マップデータに登録されているいずれかのサンプル位置データによって示されるサンプル位置に一致しているかどうか
の各判別を常時行う。次にＣＰＵ６は、上記（Ａ）および（Ｂ）の各判別結果に応じて、次の処理を行う。つまり、
（Ａ）の判別結果が否定＆（Ｂ）の判別結果が否定：この場合は、現在の再生タイミングを変更すべきかどうかを判定すべきタイミングになっていない場合に相当するので、ＣＰＵ６は特に何もしない、
（Ａ）の判別結果が肯定＆（Ｂ）の判別結果が肯定：この場合は、現在の再生タイミングがいずれか１つの小節線の位置にあり、かつその小節線の位置で再生されるべきオーディオ／ビデオデータが再生されている場合に相当し、現在の再生タイミングを変更する必要はないので、ＣＰＵ６は特に何もしない。ただしこの場合、（Ａ）の判別で対象となっている小節線の番号と（Ｂ）の判別で対象となっている小節線の番号とが“１”（あるいは２以上の整数値）だけずれていることもあり得るが、ＭＩＤＩデータの再生とオーディオ／ビデオデータの再生とが１小節（あるいは２小節以上）ずれて一致することは通常考えられないので、ここではこのような特別な場合は考えない
（Ａ）の判別結果が肯定＆（Ｂ）の判別結果が否定：この場合は、ＭＩＤＩデータの現在の再生タイミングがオーディオ／ビデオデータの現在の再生位置に対応して再生されるべきタイミングより速い場合に相当するので、ＣＰＵ６は、サンプル位置マップデータに登録されているサンプル位置データのうち、（Ａ）の判別で対象となっている小節線の番号に一致するものによって示されるサンプル位置に達するまでの間、ＭＩＤＩデータの再生を一時停止させ、オーディオ／ビデオデータの再生が追いつくのを待つ
（Ａ）の判別結果が否定＆（Ｂ）の判別結果が肯定：この場合は、ＭＩＤＩデータの現在の再生タイミングがオーディオ／ビデオデータの現在の再生位置に対応して再生されるべきタイミングより遅い場合に相当するので、ＣＰＵ６は、現在の再生タイミングの総ティック数を次の小節線の位置（小節線イベント）のティック数に変更する。

以上のようにして現在の再生タイミングを変更することにより、タイマ割込み信号＃１の発生周期（本ＭＩＤＩデータ再生処理の起動周期）を変更しなくても、ＭＩＤＩデータ再生処理はオーディオ／ビデオデータ再生処理に追従することになる。なお上述のように、本ＭＩＤＩデータ再生処理中で適宜オーディオ／ビデオデータの再生位置を使用するので、本ＭＩＤＩデータ再生処理は常時、オーディオ／ビデオデータ再生処理からその再生位置を検知可能に構成されているものとする。

なお図７のステップＳ２１の処理中に記載の“／”は、同期用マップデータがテンポチェンジマップデータであるかサンプル位置マップデータであるかに応じて、“／”の前または後の処理のいずれかの処理がなされることを示している。またステップＳ２１の処理の枠が破線で描かれているが、これは、前記図６のステップＳ１４の処理と同様に、同期用マップデータが配信されない場合には、ステップＳ２１の処理も省略されることを意味している。

次にＣＰＵ６は、処理を前記（２）の早送り／巻き戻し／一時停止／再開等の指示に応じた制御処理に進める。この（２）早送り／巻き戻し／一時停止／再開等の指示に応じた制御処理では、ＣＰＵ６は、ユーザによって早送り／巻き戻し／一時停止／再開等の指示がなされると、その指示に応じた制御処理を行う。なお、ここでの早送り／巻き戻し／一時停止／再開等の指示は、本ＭＩＤＩデータ再生処理に対してのものではなく、オーディオ／ビデオデータ再生処理に対してのものである。つまり、ここでの早送り／巻き戻し／一時停止／再開等の指示は、ユーザがオーディオ／ビデオデータ再生処理に対して行った早送り／巻き戻し／一時停止／再開等の指示が、オーディオ／ビデオデータ再生処理中の、後述する（１１）の早送り／巻き戻し／一時停止／再開等の指示に応じた制御処理（特に、ステップＳ３３の処理）を介して本ＭＩＤＩデータ再生処理側に送信されたものである。本ＭＩＤＩデータ再生処理の主たる目的は、オーディオ／ビデオデータの再生に連携して鍵盤１を自動駆動することにあるので、ＭＩＤＩデータ再生処理のみに対する早送り／巻き戻し／一時停止／再開等について考慮する必要がないからである。このように、この（２）早送り／巻き戻し／一時停止／再開等の指示に応じた制御処理はオーディオ／ビデオデータ再生処理中の（１１）早送り／巻き戻し／一時停止／再開等の指示に応じた制御処理と密接に関連するので、この（２）早送り／巻き戻し／一時停止／再開等の指示に応じた制御処理についての説明は、（１１）早送り／巻き戻し／一時停止／再開等の指示に応じた制御処理についての説明の中で一緒に行うことにする。

次にＣＰＵ６は、前記再生状況インデックスに書き込まれている情報をチェックし（ステップＳ２３）、再生状況インデックスに「再生中」が書き込まれているときには、処理を前記（３）の再生中の処理に進める（ステップＳ２３→Ｓ２５）一方、再生状況インデックスに「再生中」が書き込まれていないときには、処理を本ＭＩＤＩデータ再生処理から抜けさせる（ステップＳ２３→リターン）。

処理が（３）再生中の処理に進むと、まずＣＰＵ６は、現在の再生タイミングがノートイベントの処理タイミングかどうかを判別する（ステップＳ２５）。現在の再生タイミングが、前述のように当該ＭＩＤＩデータの再生を開始してから現在に至るまでの総ティック数であるのに対して、ＭＩＤＩデータを構成する各イベントに含まれるデルタタイムは、隣接するイベント間の時間間隔（相対時間）をティック数で表現したものである。したがって上記ステップＳ２５の判別では、先頭のイベントから判別対象のイベントまでの各イベントに含まれているデルタタイム（のティック数）を加算した結果（累積ティック数）が現在の再生タイミング（総ティック数）と一致するかどうかを判別し、その結果、両者が一致しかつそのイベントがノートイベントであるときに、現在の再生タイミングがノートイベントの処理タイミングであると判定する。ステップＳ２５の判別で、現在の再生タイミングがノートイベントの処理タイミングであるときには、ＣＰＵ６は、処理を前記（３ｂ）のノートイベントに応じた鍵駆動処理に進める。この（３ｂ）ノートイベントに応じた鍵駆動処理では、ＣＰＵ６は、そのノートイベントを前記鍵駆動回路３に供給する。このとき、供給されたノートイベントがノートオンイベントであれば、鍵駆動回路３からそのノートオンイベントに含まれるノートナンバが割り当てられた鍵の鍵駆動機構に所定の電力が供給されて、当該鍵は押鍵状態になる一方、供給されたノートイベントがノートオフイベントであれば、鍵駆動回路３からそのノートオフイベントに含まれるノートナンバが割り当てられた鍵の鍵駆動機構に供給されている電力が停止されて、当該鍵は離鍵状態になる。なお、処理がこの（３ｂ）ノートイベントに応じた鍵駆動処理に移行する際の再生状況は、前述のように「再生中」であるので、再生状況が「再生中」から「早送り中」、「巻き戻し中」あるいは「一時停止中」に変化して、その再生状況が継続する場合には、鍵盤１の押鍵状態が継続してしまうことがある。したがって、この場合に押鍵状態の鍵があれば、それを離鍵状態に戻すようにすることが望ましい。

次にＣＰＵ６は、現在の再生タイミングが当該ＭＩＤＩデータの末尾に到達したかどうかを判別し（ステップＳ２７）、末尾に到達したときには、処理を前記（３ｃ）のＭＩＤＩデータ再生処理の終了時処理に進める。この（３ｃ）ＭＩＤＩデータ再生処理の終了時処理では、ＣＰＵ６は、タイマ割込み信号＃１の発生を不許可にすることで、本ＭＩＤＩデータ再生処理を終了させる（ステップＳ２８）とともに、鍵盤１から入力されるキーオン／キーオフを有効化する（ステップＳ２９）。

なお、現在の再生タイミングの更新（総ティック数のインクリメント）は、本ＭＩＤＩデータ再生処理を「リターン」で抜ける直前、ただし（３）再生中の処理内で行うようにすればよい。

前記（３ａ）のテンポチェンジイベントに応じたテンポ変更処理は、前記第１フォーマットのストリーミング配信用データのように同期用マップデータを含まないストリーミング配信用データが配信されたときに実行される処理である。つまり、この（３ａ）テンポチェンジイベントに応じたテンポ変更処理と前記（１）同期用マップデータに応じたテンポ／タイミング変更処理とは、ストリーミング配信用データのフォーマットの種類に応じて選択されたいずれか一方が実行される。このため、図７におけるステップＳ２１の処理の枠は破線で描かれ、ステップＳ２４の処理の枠は一点鎖線で描かれている。この（３ａ）テンポチェンジイベントに応じたテンポ変更処理では、まずＣＰＵ６は、現在の再生タイミングがテンポチェンジイベントの処理タイミングかどうかを判別する。この判別は、前記ステップＳ２５の判別に対してイベントの種類が異なるだけであるので、その説明は省略する。この判別の結果、現在の再生タイミングがテンポチェンジイベントの処理タイミングのときには、そのテンポチェンジイベントで示されるテンポに現在テンポを変更する。つまりＣＰＵ６は、前記ステップＳ２１の処理のうち、“／”の前の処理と同様にして、そのテンポチェンジイベントで示されるテンポ値に応じてタイマ割込み信号＃１の発生周期を変更する。なお、処理がこの（３ａ）テンポチェンジイベントに応じたテンポ変更処理に移行する際の再生状況は、前述したように「再生中」であるが、「早送り中」および「巻き戻し中」などの「一時停止中」以外であっても、この（３ａ）テンポチェンジイベントに応じたテンポ変更処理が実行されることが望ましい。このため、図７のステップＳ２３の処理中にはカッコ書きで「一時停止中ではない？」と記載されている。ただし「早送り中」および「巻き戻し中」に鍵盤１が自動駆動されると、ユーザに違和感を生じさせる虞があるので、前記（３ｂ）のノートイベントに応じた鍵駆動処理は「再生中」だけ（もちろん「再開」時も含む）に実行されることが望ましい。

図８は、前記オーディオ／ビデオデータ再生処理の手順を示すフローチャートであり、本オーディオ／ビデオデータ再生処理は、前述のように１０ｍｓｅｃ毎に発生するタイマ割込みに応じて起動され、実行される。ここでタイマ割込みの周期として１０ｍｓｅｃを用いたのは、オーディオ／ビデオデータの再生に適当な時間と考えられるからである。したがって、オーディオ／ビデオデータの再生を適正に行うことができれば、１０ｍｓｅｃに限らない。

本オーディオ／ビデオデータ再生処理は主として、
（１１）早送り／巻き戻し／一時停止／再開等の指示に応じた制御処理（ステップＳ３２〜Ｓ３４）
（１２）再生中の処理（ステップＳ３６〜Ｓ３９）
によって構成され、
上記（１２）の再生中の処理は主として、
（１２ａ）オーディオ／ビデオデータ再生処理（ステップＳ３６，Ｓ３７）
（１２ｂ）オーディオ／ビデオデータ再生処理の終了時処理（ステップＳ３９）
によって構成されている。

本オーディオ／ビデオデータ再生処理が起動されると、まずＣＰＵ６は、ユーザによって早送り／巻き戻し／一時停止／再開等の操作があったかどうかを判別し（ステップＳ３１）、早送り／巻き戻し／一時停止／再開等の操作があったときには、処理を前記（１１）の早送り／巻き戻し／一時停止／再開等の指示に応じた制御処理に進め（ステップＳ３１→Ｓ３２）、早送り／巻き戻し／一時停止／再開等の処理がなかったときには、処理を後述するステップＳ３５に進める（ステップＳ３１→Ｓ３５）。

この（１１）早送り／巻き戻し／一時停止／再開等の指示に応じた制御処理では、ＣＰＵ６は、オーディオ／ビデオデータの再生を早送り／巻き戻し／一時停止／再開等する（ステップＳ３２）。具体的には、「早送り」の操作がなされたときには、ＣＰＵ６は、たとえば、前記図５のファイル要求＆受信処理のステップＳ１によりストリーミング配信サーバ２００に「早送り」を指示する。これに応じてストリーミング配信サーバ２００は、前記ステップＳ１０１によりその「早送り」の指示に応じたオーディオ／ビデオデータをストリーミング配信する。本実施の形態で採用しているＲＴＳＰは、前述のようにＶＣＲ形式の制御機能が備わっているので、電子鍵盤楽器１００からストリーミング配信サーバ２００に「早送り」の指示を行うだけで、ストリーミング配信サーバ２００からその「早送り」の指示に応じたオーディオ／ビデオデータがストリーミング配信される。「巻き戻し」、「一時停止」、「再開」および「指定した位置からの再生」などの操作がなされたときにも同様に、ＣＰＵ６は対応する指示をストリーミング配信サーバ２００に行う。なおステップＳ３２では、ストリーミング配信サーバ２００に指示した再生状態を前記再生状況インデックスに書き込む処理も行うことにする。

次にＣＰＵ６は、上記ステップＳ３２でストリーミング配信サーバ２００に行った指示と同様の指示をＭＩＤＩデータ再生処理に対しても行う（ステップＳ３３）。

さらにＣＰＵ６は、オーディオ／ビデオデータの現在サンプル位置（現在の再生位置）を更新する（ステップＳ３４）。ここで現在サンプル位置の更新は、電子鍵盤楽器１００からの早送り／巻き戻し／一時停止／再開等の指示に応じてストリーミング配信サーバ２００がストリーミング配信しようとするオーディオ／ビデオデータのサンプルを決定し、そのサンプル位置を電子鍵盤楽器１００に送信したときに、このサンプル位置を用いて行われる。そして現在サンプル位置の更新を、当該オーディオ／ビデオデータを実際に再生する時点より前に行うのは、ＭＩＤＩデータ再生処理において、当該オーディオ／ビデオデータが実際に再生される時点より前に、現在サンプル位置の更新値が使用されるからである。またＲＴＳＰ以外の、ＶＣＲ形式の制御機能が備わっていないプロトコルを採用した場合には、早送り／巻き戻し／指定した位置からの再生等の操作がなされると、電子鍵盤楽器１００側でその操作に応じたサンプル位置を決定し、決定したサンプル位置のオーディオ／ビデオデータがストリーミング配信されるようにストリーミング配信サーバ２００に要求しなければならないので、この場合には、現在サンプル位置の更新は当然ながら、当該オーディオ／ビデオデータを実際に再生する時点より前に行われる。

前記ステップＳ３３で、ＣＰＵ６がＭＩＤＩデータ再生処理に対して、早送り／巻き戻し／一時停止／再開等の指示を行うと、前記図７のステップＳ２２の（２）早送り／巻き戻し／一時停止／再開等の指示に応じた制御処理で、ＣＰＵ６は、その指示に応じた制御を行う。具体的には、「早送り」が指示されるとＣＰＵ６は、現在サンプル位置をオーディオ／ビデオデータ再生処理から検知し、この現在サンプル位置に基づいて、ＭＩＤＩデータ再生処理における現在の再生タイミングを更新する。たとえば、ＭＩＤＩデータに含まれる各小節線イベントと、該各小節線イベントの再生位置でそれぞれ再生すべき各オーディオ／ビデオデータのサンプル位置（サンプル番号）とを対応付けたマップデータ（前記同期用マップデータとは異なる）を予め作成しておき、上記再生タイミングの更新は、このマップデータに基づいて行うようにすればよい。もちろん、検知された現在サンプル位置が常に、いずれかの小節線イベントの再生位置に一致する訳ではないので、一致しないときには、ＣＰＵ６は、現在サンプル位置とこれに最も近い小節線イベントの再生位置から演算によって現在の再生タイミングを算出する。そしてＣＰＵ６は、更新後の再生タイミングに基づいて同期用マップデータを検索し、現在テンポ／現在タイミングを変更する。具体的には、同期用マップデータが前記テンポチェンジマップデータである場合には、ＣＰＵ６は、同期用マップデータから更新後の再生タイミングに一致するあるいはその直前のテンポチェンジデータを検索し、前記ステップＳ２１の処理と同様にして、そのテンポチェンジデータに含まれているテンポ値を読み出し、読み出したテンポ値に応じてタイマ割込み信号＃１の発生周期を変更する。一方、同期用マップデータが前記サンプル位置マップデータである場合には、ＣＰＵ６は特に何もしない。その後に前記ステップＳ２１の処理が実行されると、現在タイミングが変更されて、ＭＩＤＩデータ再生処理は自動的にオーディオ／ビデオデータ再生処理に追従するからである。「巻き戻し」あるいは「指定した位置からの再生」が指示されたときの各制御処理は、「早送り」が指示されたときの上記処理から簡単に類推できるので、その説明は省略する。「一時停止」あるいは「再開」が指示されたときには、ＣＰＵ６は特に何もしない。「一時停止」が指示されたときになされるべき「現在の再生タイミングのインクリメントの停止」は、再生状況インデックスに「一時停止中」が書き込まれていれば（このとき再生状況インデックスには、前述のように「一時停止中」が書き込まれている）、前記（３）再生中の処理の処理が迂回されることで自動的になされ、「再開」が指示されたときになされるべき「現在の再生タイミングのインクリメントの再開」は、前記再生状況インデックスに「再開」が書き込まれていれば（このとき再生状況インデックスには、前述のように「再開」が書き込まれている）、前記（３）再生中の処理が再開されることで自動的になされるからである。

図８に戻り、次にＣＰＵ６は、再生状況インデックスに書き込まれている情報をチェックし（ステップＳ３５）、再生状況インデックスに「再生中」が書き込まれているときには、処理を前記（１２）の再生中の処理に進める（ステップＳ３５→Ｓ３６）一方、再生状況インデックスに「再生中」が書き込まれていないときには、処理を本オーディオ／ビデオデータ再生処理から抜けさせる（ステップＳ３５→リターン）。

処理が（１２）再生中の処理に進むと、ＣＰＵ６は、処理を前記（１２ａ）のオーディオ／ビデオデータ再生処理に進める。この（１２ａ）オーディオ／ビデオデータ再生処理では、まずＣＰＵ６は、前記ステップＳ３４と同様にして、オーディオ／ビデオデータの現在サンプル位置を更新する（ステップＳ３６）。次にＣＰＵ６は、前記受信バッファからオーディオ／ビデオデータを読み出して再生する（ステップＳ３７）。このとき、読み出したオーディオ／ビデオデータが暗号化されていればそれを解読し、圧縮化されていればそれを伸長した上で、再生する。なお、読み出したオーディオ／ビデオデータが暗号化されたものであるか圧縮化ものであるかなどの情報は、当該データパケットのヘッダに記載されているので、それを利用すればよい。また、この（１２ａ）オーディオ／ビデオデータ再生処理は、「早送り中」および「巻き戻し中」などの「一時停止中」以外であっても実行されることが望ましいので、図８のステップＳ３５の処理中にはカッコ書きで「一時停止中ではない？」と記載されている。

次にＣＰＵ６は、現在サンプル位置が当該オーディオ／ビデオデータの末尾に到達したかどうかを判別し（ステップＳ３８）、末尾に到達したときには、処理を前記（１２ｂ）のオーディオ／ビデオデータ再生処理の終了時処理に進める。この（１２ｂ）オーディオ／ビデオデータ再生処理の終了時処理では、ＣＰＵ６は、タイマ割込み信号＃２の発生を不許可にすることで、本オーディオ／ビデオデータ再生処理を終了させる（ステップＳ３９）。なおステップＳ３９の終了処理では、再生状況インデックスへの「停止中」の書き込みも行う。

以上の制御処理についての説明では、第２フォーマットのストリーミング配信用データが常に配信されるものとしたので、以下、他のフォーマットのストリーミング配信用データが配信されるときの制御処理について説明する。ただし、前者の制御処理と後者の制御処理との間には共通する部分が多いので、相違する部分について説明する。

第１フォーマットのストリーミング配信用データが配信される場合、図５のステップＳ１０１で、ストリーミング配信サーバ２００は当然ながら、同期用マップデータを配信しない。このため電子鍵盤楽器１００（のＣＰＵ６）は、同期用マップデータに関連する処理、つまり図６のステップＳ１４および図７のステップＳ２１の各処理（輪郭が破線で描かれた処理）を実行しないが、同期用マップデータが配信されるときには実行されない図７のステップＳ２４の処理（輪郭が一点鎖線で描かれた処理）を実行する。

第３フォーマットのストリーミング配信用データが配信される場合、図５のステップＳ１で、電子鍵盤楽器１００からストリーミング配信サーバ２００に対して、ユーザによってストリーミング配信が指示されたオーディオ／ビデオデータを含むファイルの配信要求が送信されたとしても、ステップＳ１０１で、ストリーミング配信サーバ２００は配信対象となるＭＩＤＩデータのファイルのみ配信し、オーディオ／ビデオデータのファイルのストリーミング配信は行わない。これは、ストリーミング配信サーバ２００側では当該ＭＩＤＩデータのファイルに対応付けられたオーディオ／ビデオデータのファイルがどれであるか分からないからである。前述のように、オーディオ／ビデオデータのファイルを特定するコマンドはＭＩＤＩデータ内に埋め込まれているので、電子鍵盤楽器１００は受信したＭＩＤＩデータ（のファイル）から、そこに埋め込まれているコマンドを読み出し、そのコマンドによって特定されるオーディオ／ビデオデータのファイルのストリーミング配信要求を、ステップＳ１の処理によりストリーミング配信サーバ２００に送信する。これに応じてストリーミング配信サーバ２００は、当該オーディオ／ビデオデータを電子鍵盤楽器１００にストリーミング配信する。これ以降の制御処理は、第１フォーマットのストリーミング配信用データが配信される場合の制御処理と同様であるので、その説明は省略する。

第４フォーマットのストリーミング配信用データが配信される場合、図５のステップＳ１で、電子鍵盤楽器１００からストリーミング配信サーバ２００に対して、ユーザによってストリーミング配信が指示されたオーディオ／ビデオデータを含むファイルの配信要求が送信されると、ステップＳ１０１で、まずストリーミング配信サーバ２００は当該オーディオ／ビデオデータの一部（先頭からＭＩＤＩデータのファイルを特定するコマンドが埋め込まれている部分まで）のみを配信する。電子鍵盤楽器１００は、このオーディオ／ビデオデータの一部を受信し、そこに含まれているコマンドを読み出し、そのコマンドによって特定されるＭＩＤＩデータのファイルの配信要求を、ステップＳ１の処理によりストリーミング配信サーバ２００に送信する。これに応じてストリーミング配信サーバ２００は、当該ＭＩＤＩデータのファイルを電子鍵盤楽器１００に配信する。ＭＩＤＩデータのファイルの配信が終了するとストリーミング配信サーバ２００は、残りのオーディオ／ビデオデータをストリーミング配信する。これ以降の制御処理は、第１フォーマットのストリーミング配信用データが配信される場合の制御処理と同様であるので、その説明は省略する。

第５フォーマットのストリーミング配信用データが配信される場合、図５のステップＳ１で、電子鍵盤楽器１００からストリーミング配信サーバ２００に対して、ユーザによってストリーミング配信が指示されたオーディオ／ビデオデータを含むファイルの配信要求が送信されたとしても、ステップＳ１０１で、ストリーミング配信サーバ２００は配信対象となる設定ファイルのみ配信し、ＭＩＤＩデータおよびオーディオ／ビデオデータの各ファイルの配信は行わない。これは、ストリーミング配信サーバ２００側では当該設定ファイルに対応付けられたＭＩＤＩデータおよびオーディオ／ビデオデータの各ファイルがどれであるか分からないからである。前述のように、ＭＩＤＩデータおよびオーディオ／ビデオデータの各ファイルを特定する情報は設定ファイル内に記載されているので、電子鍵盤楽器１００は受信した設定ファイルから、そこに記載されている特定情報を読み出し、その特定情報によって特定されるＭＩＤＩデータおよびオーディオ／ビデオデータの各ファイルの配信要求を、ステップＳ１の処理によりストリーミング配信サーバ２００に送信する。これに応じてストリーミング配信サーバ２００は、当該ＭＩＤＩデータおよびオーディオ／ビデオデータの各ファイルを電子鍵盤楽器１００に配信する。これ以降の制御処理は、第１フォーマットのストリーミング配信用データが配信される場合の制御処理と同様であるので、その説明は省略する。

なお本実施の形態では、ビデオデータがストリーミング配信され、これをストリーミング再生する場合に、その映像（動画像）を電子鍵盤楽器１００に設けた表示装置９（のＬＣＤ）に表示するようにしたが、これに限らず、電子鍵盤楽器１００にディスプレイを外部接続し、このディスプレイ上に映像を表示するようにしてもよい。

また本実施の形態では、オーディオ／ビデオデータのストリーミング再生も鍵盤１の自動駆動も電子鍵盤楽器１００内で行うようにしたが、これに限らず、本発明をＰＣ（パーソナルコンピュータ）とそれにＭＩＤＩ接続した自動駆動可能の鍵盤によって構成し、ＰＣ側でオーディオ／ビデオデータのストリーミング再生を行わせ、鍵盤の自動駆動はＰＣから鍵盤側にノートイベントを送信して行わせるようにしてもよい。さらに、オーディオデータのストリーミング再生を行う場合には、ＰＣに代えて通信ネットワークに接続可能なオーディオ機器を採用してもよいし、ビデオデータのストリーミング再生を行う場合には、ＰＣに代えて通信ネットワークに接続可能なＴＶ装置を採用してもよい。

なお、上述した実施の形態の機能を実現するソフトウェアのプログラムコードを記録した記憶媒体を、システムまたは装置に供給し、そのシステムまたは装置のコンピュータ（またはＣＰＵやＭＰＵ）が記憶媒体に格納されたプログラムコードを読出し実行することによっても、本発明の目的が達成されることは言うまでもない。

この場合、記憶媒体から読出されたプログラムコード自体が本発明の新規な機能を実現することになり、そのプログラムコードおよび該プログラムコードを記憶した記憶媒体は本発明を構成することになる。

プログラムコードを供給するための記憶媒体としては、たとえば、フレキシブルディスク、ハードディスク、光磁気ディスク、ＣＤ−ＲＯＭ、ＣＤ−Ｒ、ＣＤ−ＲＷ、ＤＶＤ−ＲＯＭ、ＤＶＤ−ＲＡＭ、ＤＶＤ−ＲＷ、ＤＶＤ＋ＲＷ、磁気テープ、不揮発性のメモリカード、ＲＯＭなどを用いることができる。また、通信ネットワークを介してサーバコンピュータからプログラムコードが供給されるようにしてもよい。

また、コンピュータが読出したプログラムコードを実行することにより、上述した実施の形態の機能が実現されるだけでなく、そのプログラムコードの指示に基づき、コンピュータ上で稼働しているＯＳなどが実際の処理の一部または全部を行い、その処理によって上述した実施の形態の機能が実現される場合も含まれることは言うまでもない。

さらに、記憶媒体から読出されたプログラムコードが、コンピュータに挿入された機能拡張ボードやコンピュータに接続された機能拡張ユニットに備わるメモリに書込まれた後、そのプログラムコードの指示に基づき、その機能拡張ボードや機能拡張ユニットに備わるＣＰＵなどが実際の処理の一部または全部を行い、その処理によって上述した実施の形態の機能が実現される場合も含まれることは言うまでもない。

本発明の一実施の形態に係る電子鍵盤楽器の概略構成を示すブロック図である。 図１中の鍵盤の各鍵を駆動する駆動方法の一例を示す図である。 ネットワーク構成の一例を示す図である。 図１中のストリーミング配信サーバがストリーミング配信可能な複数種類のデータのフォーマットを示す図である。 図１の電子鍵盤楽器、特にＣＰＵが実行するファイル要求＆受信処理の手順を示すフローチャートである。 図１の電子鍵盤楽器、特にＣＰＵが実行するストリーミング再生制御処理の手順を示すフローチャートである。 図１の電子鍵盤楽器、特にＣＰＵが実行するＭＩＤＩデータ再生処理の手順を示すフローチャートである。 図１の電子鍵盤楽器、特にＣＰＵが実行するオーディオ／ビデオデータ再生処理の手順を示すフローチャートである。

符号の説明

１…鍵盤，１ｅ…鍵駆動機構（鍵駆動手段），３…鍵駆動回路（鍵駆動手段），６…ＣＰＵ（要求手段、受信手段、第１の再生手段、第２の再生手段、制御手段），８…ＲＡＭ（一時記憶手段），１１…通信Ｉ／Ｆ（接続手段、受信手段）

Claims (5)

1. 複数の鍵を備えた鍵盤と、
   該鍵盤の各鍵を自動駆動する鍵駆動手段と、
   オーディオデータまたはビデオデータを含む音楽コンテンツをストリーミング配信するストリーミング配信サーバと接続する接続手段と、
   該接続手段を介して接続されたストリーミング配信サーバに対して音楽コンテンツの配信要求を行う要求手段と、
   該要求手段による配信要求に応じてストリーミング配信サーバからストリーミング配信される音楽コンテンツと、該音楽コンテンツに対応する鍵駆動用の自動演奏データを受信する受信手段と、
   該受信手段によって受信された音楽コンテンツを一時的に記憶する一時記憶手段と、
   前記受信手段によって受信された自動演奏データを再生し、その再生によって得られたノートイベントを前記鍵駆動手段に供給することで、前記複数の鍵のうち、当該ノートイベントに対応する鍵を駆動させる第１の再生手段と、
   前記一時記憶手段に記憶された音楽コンテンツをストリーミング再生する第２の再生手段と、
   前記一時記憶手段に音楽コンテンツが所定量蓄積されてから、前記自動演奏データの再生と前記音楽コンテンツのストリーミング再生を開始させることで、前記第１の再生手段による自動演奏データの再生と前記第２の再生手段による音楽コンテンツのストリーミング再生とを連携して行うように制御する制御手段と
   を有し、
   前記制御手段はさらに、再生開始時には、前記自動演奏データの再生を開始した後、所定時間待ってから前記音楽コンテンツのストリーミング再生を開始させる一方、再生の一時停止時には、前記再生開始時に生じた時間的なずれを維持し、当該一時停止から再生を再開するときには、所定時間を待たずに再生を再開させることを特徴とする電子鍵盤楽器。
2. ユーザの操作に応じて、前記一時停止を指示する指示手段をさらに有し、
   前記制御手段は、前記指示手段によって再生の一時停止が指示されたときに、前記一時停止および当該一時停止からの再生の再開を行うことを特徴とする請求項１に記載の電子鍵盤楽器。
3. 前記音楽コンテンツのストリーミング再生中に、前記一時記憶手段に蓄積された音楽コンテンツがなくなったときには、前記制御手段は、前記自動演奏データの再生を一時停止させることを特徴とする請求項１に記載の電子鍵盤楽器。
4. 前記ストリーミング配信サーバからは、前記音楽コンテンツおよび自動演奏データに加えて、当該音楽コンテンツのストリーミング再生と当該自動演奏データの再生を同期させるための同期マップデータが配信され、
   前記受信手段は、該配信された同期マップデータを受信し、
   前記制御手段は、該受信された同期マップデータに基づいて当該音楽コンテンツのストリーミング再生と当該自動演奏データの再生を同期させることで、両再生を連携して行うことを特徴とする請求項１に記載の電子鍵盤楽器。
5. 複数の鍵を備えた鍵盤と、該鍵盤の各鍵を自動駆動する鍵駆動手段と、オーディオデータまたはビデオデータを含む音楽コンテンツをストリーミング配信するストリーミング配信サーバと接続する接続手段と、前記ストリーミング配信サーバから配信された音楽コンテンツを一時的に記憶する一時記憶手段とを備えた電子鍵盤楽器を制御する制御方法をコンピュータに実行させるプログラムであって、
   前記制御方法は、
   前記接続手段を介して接続されたストリーミング配信サーバに対して音楽コンテンツの配信要求を行う要求ステップと、
   該要求ステップによる配信要求に応じてストリーミング配信サーバからストリーミング配信される音楽コンテンツと、該音楽コンテンツに対応する鍵駆動用の自動演奏データを受信する受信ステップと、
   該受信ステップによって受信された自動演奏データを再生し、その再生によって得られたノートイベントを前記鍵駆動手段に供給することで、前記複数の鍵のうち、当該ノートイベントに対応する鍵を駆動させる第１の再生ステップと、
   前記受信ステップによって受信され、前記一時記憶手段に記憶された音楽コンテンツをストリーミング再生する第２の再生ステップと、
   前記一時記憶手段に音楽コンテンツが所定量蓄積されてから、前記自動演奏データの再生と前記音楽コンテンツのストリーミング再生を開始させることで、前記第１の再生ステップによる自動演奏データの再生と前記第２の再生ステップによる音楽コンテンツのストリーミング再生とを連携して行うように制御する制御ステップと
   を有し、
   前記制御ステップではさらに、再生開始時には、前記自動演奏データの再生を開始した後、所定時間待ってから前記音楽コンテンツのストリーミング再生を開始させる一方、再生の一時停止時には、前記再生開始時に生じた時間的なずれを維持し、当該一時停止から再生を再開するときには、所定時間を待たずに再生を再開させることを特徴とするプログラム。

Images