(57)【要約】【課題】記録媒体へのデータの書き込みにより生じる待ち時間をユーザーに意識させないようにするための技術を提供する。【解決手段】サーバー１２０は、保存用の演奏データに、再生用の演奏データを混合する形で送信する。データ処理装置の送受信装置１０６は、通信ネットワーク１２１を介してサーバー１２０が送信したデータを受信する。ＣＰＵ１０１は、送受信装置１０６が受信したデータの種類を判別し、その判別結果に従い、保存用の演奏データはフラッシュメモリ１０４に書き込んで保存し、再生用の演奏データはサウンドシステム１０５に送出して再生する。それにより、演奏データの保存と再生を並行して行う。【選択図】            図１
2004347877.tif 000002
【特許請求の範囲】
【請求項１】
第１の装置から第２の装置に、該第２の装置が保存の対象とする保存用データを送信して保存させる場合に用いられる方法であって、
前記第１の装置に、前記保存用データ、及び所定の媒体を介して再生するための再生用データを混合させた形で前記第２の装置に送信させ、
前記第２の装置に、前記第１の装置から受信したデータの種類を判別させ、該判別結果に従って、前記保存用データは記録媒体に記録して保存させ、前記再生用データは前記所定の媒体を介して再生させる、
ことを特徴とするデータ保存方法。
【請求項２】
第１の装置から第２の装置に、該第２の装置が保存の対象とする保存用データを送信して保存させる場合に用いられる方法であって、
所定の媒体を介して再生するための再生用データを前記保存用データとして前記第１の装置が送信するとき、前記第２の装置に、該第１の装置から受信した該保存用データの再生を、該保存用データの記録媒体への記録による保存と併せて行わせる、
ことを特徴とするデータ保存方法。
【請求項３】
前記第１の装置に、再生単位となる範囲を指定する範囲指定用データが挿入された前記保存用データを前記第２の装置に送信させ、
前記第２の装置に、前記範囲指定用データで指定される範囲を再生単位とした前記保存用データの再生を、該保存用データの記録の進行に応じて行わせる、
ことを特徴とする請求項２記載のデータ保存方法。
【請求項４】
前記第１の装置から受信した前記再生用データの再生に必要なデータが不足していたとき、前記第２の装置に、該不足のデータと代替可能なデータが前記記録媒体に保存された前記保存用データ中に存在するか否か確認させ、該確認結果に従って、該代替可能なデータを該再生用データの再生に使用させる、
ことを特徴とする請求項１記載のデータ保存方法。
【請求項５】
前記第２の装置が前記保存用データを記録する記録媒体は、フラッシュメモリ、或いは該第２の装置がアクセス可能な補助記憶装置に搭載の記録媒体である、
ことを特徴とする請求項１、２、３、または４記載のデータ保存方法。
【請求項６】
外部装置から送信されたデータを受信できるデータ処理装置において、
前記データを受信する受信手段と、
前記受信手段が受信したデータを記録媒体上に保存する保存手段と、
前記データを再生する再生手段と、
保存の対象となる保存用データ、及び再生の対象となる再生用データを混合させた形で前記外部装置が送信した場合に、前記受信手段が受信したデータの種類を判別して、該保存用データは前記保存手段により前記記録媒体上に保存させ、該再生用データは前記再生手段に再生させる制御手段と、
を具備することを特徴とするデータ処理装置。
【請求項７】
外部装置から送信されたデータを受信できるデータ処理装置において、
前記データを受信する受信手段と、
前記受信手段が受信したデータを記録媒体上に保存する記憶手段と、
前記データを再生する再生手段と、
所定の媒体を介して再生するための再生用データを前記保存用データとして前記外部装置が送信した場合に、前記受信手段が受信した該保存用データの前記再生手段による再生を、該保存用データの前記保存手段による前記記録媒体上への保存と併せて行わせる制御手段と、
を具備することを特徴とするデータ処理装置。
【請求項８】
外部装置から送信されたデータを受信できるデータ処理装置に実行させるプログラムであって、
前記データを受信する機能と、
前記受信する機能により受信したデータを記録媒体上に保存する機能と、
前記データを再生する機能と、
保存の対象となる保存用データ、及び再生の対象となる再生用データを混合させた形で前記外部装置が送信した場合に、前記受信する機能により受信したデータの種類を判別して、該保存用データは前記保存する機能により前記記録媒体上に保存させ、該再生用データは前記再生する機能により再生させる機能と、
を実現させるためのプログラム。
【請求項９】
外部装置から送信されたデータを受信できるデータ処理装置に実行させるプログラムであって、
前記データを受信する機能と、
前記受信する機能により受信したデータを記録媒体上に保存する機能と、
前記データを再生する機能と、
所定の媒体を介して再生するための再生用データを前記保存用データとして前記外部装置が送信した場合に、前記受信する機能により受信した該保存用データの前記再生する機能による再生を、該保存用データの前記保存する機能による前記記録媒体上への保存と併せて行わせる機能と、
を実現させるためのプログラム。
【発明の詳細な説明】
【０００１】
【発明の属する技術分野】
本発明は、異なる装置間で保存の対象となるデータを送受信させて保存させるための技術に関する。
【０００２】
【従来の技術】
データの保存に使用される記録媒体には、多くの種類が存在し、それぞれ特有の仕様が定められている。パーソナル・コンピュータ（以下「ＰＣ」）やＰＤＡ（Ｐｅｒｓｏｎａｌ  Ｄｉｇｉｔａｌ  Ａｓｓｉｓｔａｎｔｓ  ）などといったデータ処理装置には、その用途や求められている性能などを考慮して記録媒体、或いはそれにアクセスする装置が選択・搭載される。
【０００３】
【特許文献１】
特開２００１−２６５３４４号公報
【０００４】
【発明が解決しようとする課題】
近年では、情報インフラストラクチャとして通信ネットワークが急速に発展したことに伴い、通信ネットワークは情報の発信（配信）や商品の販売などといった各種サービスの提供に幅広く利用されている。それにより、他の装置から情報として送信されたデータをデータ処理装置がアクセス可能な記録媒体に保存させるケースが非常に増えている。
【０００５】
周知のように、アクセスする速度は、記録媒体によって大きな差がある。例えばフラッシュメモリやフレキシブルディスクでは、アクセス速度が比較的に遅いことが知られている。そのようなアクセス速度が遅い記録媒体にアクセスする程、そのアクセスにかかる時間は長くなる。
【０００６】
そのアクセスにはデータ処理装置の資源が使用される。そのために、アクセスを行っている間はユーザーの操作に応答しない、或いは応答速度が非常に低下するのが普通である。この結果、アクセスにかかる時間は基本的に、ユーザーにとってはその終了を待たなければならない待ち時間となる。しかし、そのような待ち時間は、ユーザーにとっては時間を浪費しているような形となる。このことから、待ち時間はユーザーに意識させないようにすることが望ましいと考えられる。
【０００７】
本発明の課題は、記録媒体へのデータの書き込みにより生じる待ち時間をユーザーに意識させないようにするための技術を提供することにある。
【０００８】
【課題を解決するための手段】
本発明の第１、及び第２の態様のデータ保存方法は、第１の装置から第２の装置に、該第２の装置が保存の対象とする保存用データを送信して保存させる場合に用いられることを前提とし、以下のようにデータ保存を行う。
【０００９】
第１の態様のデータ保存方法では、第１の装置に、保存用データ、及び所定の媒体を介して再生するための再生用データを混合させた形で第２の装置に送信させ、第２の装置に、第１の装置から受信したデータの種類を判別させ、該判別結果に従って、保存用データは記録媒体に記録して保存させ、再生用データは所定の媒体を介して再生させる。
【００１０】
第２の態様のデータ保存方法では、所定の媒体を介して再生するための再生用データを保存用データとして第１の装置が送信するとき、第２の装置に、該第１の装置から受信した該保存用データの再生を、該保存用データの記録媒体への記録による保存と併せて行わせる。
【００１１】
なお、上記第２の態様のデータ保存方法では、第１の装置に、再生単位となる範囲を指定する範囲指定用データが挿入された保存用データを第２の装置に送信させ、第２の装置に、範囲指定用データで指定される範囲を再生単位とした保存用データの再生を、該保存用データの記録の進行に応じて行わせる、ことが望ましい。
【００１２】
また、第１の態様のデータ保存方法では、第１の装置から受信した再生用データの再生に必要なデータが不足していたとき、第２の装置に、該不足のデータと代替可能なデータが記録媒体に保存された保存用データ中に存在するか否か確認させ、該確認結果に従って、該代替可能なデータを該再生用データの再生に使用させる、ことが望ましい。
【００１３】
上記第２の装置が保存用データを記録する記録媒体は、フラッシュメモリ、或いは該第２の装置がアクセス可能な補助記憶装置に搭載の記録媒体である、ことが望ましい。
本発明の第１、及び第２の態様のデータ処理装置は共に、外部装置から送信されたデータを受信できることを前提とし、データを受信する受信手段と、受信手段が受信したデータを記録媒体上に保存する保存手段と、データを再生する再生手段と、を具備する。
【００１４】
第１の態様のデータ処理装置は、上記手段に加えて、保存の対象となる保存用データ、及び再生の対象となる再生用データを混合させた形で外部装置が送信した場合に、受信手段が受信したデータの種類を判別して、該保存用データは保存手段により記録媒体上に保存させ、該再生用データは再生手段に再生させる制御手段、を更に具備する。
【００１５】
第２の態様のデータ処理装置は、上記手段に加えて、所定の媒体を介して再生するための再生用データを保存用データとして外部装置が送信した場合に、受信手段が受信した該保存用データの再生手段による再生を、該保存用データの保存手段による記録媒体上への保存と併せて行わせる制御手段、を更に具備する。
【００１６】
本発明の第１、及び第２の態様のプログラムは、それぞれ、上記第１、及び第２の態様のデータ処理装置を実現させるための機能を具備する。
本発明では、第１の装置に、保存用データ、及び所定の媒体を介して再生するための再生用データを混合させた形で第２の装置に送信させ、第２の装置に、第１の装置から受信したデータの種類を判別させ、判別結果に従って、保存用データは記録媒体に記録して保存させ、再生用データは所定の媒体を介して再生させる。それにより、ユーザーは、保存用データを保存している間、並行して行われる再生用データの再生を楽しめるようになる。その再生を楽しめるようになる結果、保存用データを保存している時間を意識する度合は低減させられるようになる。
【００１７】
本発明では、所定の媒体を介して再生するための再生用データを保存用データとして第１の装置が送信するとき、第２の装置に、第１の装置から受信した該保存用データの再生を、保存用データの記録媒体への記録による保存と併せて行わせる。そのようにしても、ユーザーは、保存用データを保存している間、並行して行われる再生用データの再生を楽しめることとなる。その結果、保存用データを保存している時間を意識する度合は低減させられるようになる。
【００１８】
【発明の実施の形態】
以下、本発明の実施の形態について、図面を参照しながら詳細に説明する。
＜第１の実施の形態＞
図１は、第１の実施の形態によるデータ処理装置の回路構成図である。
【００１９】
図１中の１２１は、例えば通信ネットワークである。それにより、第１の実施の形態によるデータ処理装置は、通信ネットワーク１２１を介してサーバー１２０から送信されたデータを受信して保存できる端末装置として利用できるように実現されている。なお、サーバー１２０などの外部装置との接続は、通信ネットワーク１２１を介して行うのではなく、ケーブルなどにより直接的、或いは間接的に行っても良い。
【００２０】
そのデータ処理装置は、図１に示すように、装置全体の制御を行うＣＰＵ１０１と、プログラムや各種制御用データ等を格納したＲＯＭ１０２と、ＣＰＵ１０１がワークに使用するＲＡＭ１０３と、サーバー１２０からダウンロードしたデータの保存に使用されるフラッシュメモリ（ＦＭ）１０４と、ＣＰＵ１０１の指示に従って楽音を放音するサウンドシステム１０５と、サーバー１２０と通信ネットワーク１２１を介してデータの送受信を行う送受信装置１０６と、ユーザーが操作の対象とする入力装置１０７と、各部１０１〜１０７を相互に接続するバス１０８と、を備えて構成されている。
【００２１】
上記入力装置１０７は、例えばキーボードやマウスなどのポインティングデバイスをまとめて表したものである。サウンドシステム１０５は、例えばＣＰＵ１０１の指示に従って、発音させるべき楽音の波形データを生成する音源、その音源が生成した波形データのＡ／Ｄ変換を行い、アナログのオーディオ信号を出力するＡ／Ｄ変換器、そのＡ／Ｄ変換器が出力するオーディオ信号の増幅を行う増幅器、及びその増幅器が出力するオーディオ信号を音声に変換するスピーカ、などを備えたものである。
【００２２】
上記ＦＭ１０４は、現在の状況を示すフラグ（書込み終了フラグ）を、データの書き込みを開始するとリセットし（値を０にし）、その書き込みが終了すると（書き込みの待機中になると）セットする（値を１にする）ものである。
以上の構成において動作を説明する。
【００２３】
上記通信ネットワーク１２１は、特に限定するものではないが、ここではインターネットを含むネットワークであるとの前提、つまり、サーバー１２０は、インターネット上にサイトを開設するために設置されたものであるとの前提で説明する。そのサイト用のシステムは通常、複数のサーバーを用いて構築されるが、説明上、便宜的にそのシステムはサーバー１２０のみで構築されていると仮定する。
【００２４】
上記の前提では、データ処理装置は、例えば電話網、或いはケーブルテレビ網などの公衆網、及びインターネットとの接続サービスを行っているＩＳＰ（Ｉｎｔｅｒｎｅｔ  Ｓｅｒｖｉｃｅ  Ｐｒｏｖｉｄｅｒ  ）、或いは交換機などを介してそのインターネットと接続される。サーバー１０２との接続は、インターネットとの接続を行った後、そのＵＲＬ（Ｕｎｉｆｏｒｍ  Ｒｅｓｏｕｒｃｅ  Ｌｏｃａｔｅｒ）を送受信装置１０６から送信させることで行われる。
【００２５】
そのサーバー１０２は、通信ネットワーク１２１を介して接続されたデータ処理装置のような端末装置のユーザーに対し、情報（コンテンツ）を有償、或いは無償でダウンロードするサービスを提供するものである。そのダウンロードの対象となる情報は特に限定するものではないが、ここでは説明上、便宜的に、楽曲を再生するための演奏データであるとする。その演奏データは、例えば演奏上のイベントを示すイベントデータ（例えばＭＩＤＩデータ。以降、ＭＩＤＩデータであるとして説明する）にそのイベントを発生すべきタイミングを示す時間データを付した形で構成されている。
【００２６】
データ処理装置のユーザーは、サーバー１２０が提供する情報のなかで所望するものを選択してダウンロードをそのサーバー１２０に要求する。データ処理装置は、その要求によってサーバー１２０が送信した情報（保存用データ）を受信して図２に示すようにＦＭ１０４に保存する。
【００２７】
図２中に表記の「データ群」はサーバー１２０から受信して保存した情報を示している。そのサーバー１２０から情報として演奏データのみを受信（ダウンロード）するのであれば、データ群は１つ以上の演奏データが対応する。本実施の形態では、「データブロック（０）」と表記したエリアに、サーバー１２０からダウンロードした演奏データをブロックに分けて順次、書き込んでいくようになっている。以降、そのエリアを「データブロックエリア」と総称し、そのうちの特定のエリアを指す場合には、「データブロック（０）エリア」等と表記することにする。
【００２８】
上記データブロックエリアのなかでデータが書き込まれているものを把握するために、ＲＡＭ１０３には、各エリア毎に用意したフラグ（有効フラグ）を格納している。図３中の「有効フラグ群」は、そのフラグをまとめて表したものである。その有効フラグ群を構成する各フラグに付した「（０）」等は、そのフラグとデータブロックエリアの対応関係を表している。つまり例えば「（０）」が付された有効フラグはデータブロック（０）エリア用のものであることを表している。
【００２９】
サーバー１２０は、要求された演奏データをデータ処理装置に送信する場合、その演奏データに、リアルタイムに再生すべき再生用データを挿入することにより、それらを混合させた形で送信する。その再生用データとは、例えば映像を再生するためのデータ、或いは楽曲を再生するための演奏データである。ここでは後者であるとの前提で説明を行うこととする。後者は、例えば要求されて送信する演奏データと同じ構成のものである。通信ネットワーク１２１における遅延やその変動が無視できるレベルであれば、そのネットワーク１２１を介して送信するのはＭＩＤＩデータ等の楽音の発音に係わるデータ（コマンド）のみであっても良い。
【００３０】
他方のデータ処理装置は、送受信装置１０６が受信した演奏データが保存用、及びリアルタイムに再生用の何れであるか判別し、その判別結果に応じて、保存用の演奏データはＦＭ１０４に書き込み、再生用の演奏データはそれを随時、処理してサウンドシステム１０５によりその再生を行うようになっている。それにより、保存用の演奏データをダウンロードして保存する場合、その保存と並行して、再生用の演奏データの再生を行う。
【００３１】
演奏データの再生は、例えば時間データが示す処理タイミングとなったＭＩＤＩデータを順次サウンドシステム１０５の音源に送出していくことで行われる。このことから、再生用の演奏データは、保存用の演奏データと同じ構成のものであれば、例えばそれを複数の部分に分け、再生が途切れてしまうことがないように各部分を保存用の演奏データ中に配置する形で挿入される。楽音の発音に係わるデータ（コマンド）のみを送信する場合には、それを処理すべきタイミングで保存用の演奏データ中に挿入される。ここでは、後者の方法で挿入される場合を想定することにする。
【００３２】
そのように再生用の演奏データの再生を並行してデータ処理装置に行わせると、保存用の演奏データのダウンロードを開始してからその保存が終了するまでの間に、演奏データの再生による演奏をユーザーに聞かせることができる。それにより、その間の時間を単に待たせるような場合と比較して、その時間を浪費していると感じる度合を大幅に緩和させることができる。この結果、その時間をユーザーが意識する度合も大幅に低下させられるようになる。
【００３３】
その時間で再生が終了する演奏データを混合した場合には、その再生による演奏からその時間の経過、即ちデータの保存の終了をユーザーに予測させる、或いは通知することができるようになる。従って、そのようにした場合には、その時間の経過を表示等によりデータ処理装置に通知させるといったことはしなくとも済むようになる。
【００３４】
サーバー１２０からダウンロードしたデータの保存は、既に保存したデータに追加する、或いは少なくとも一部を書き換えて更新するために行う場合がある。しかし、そのような更新も、それにかかる時間をユーザーが意識する度合を低下させられることから、より意識させない形で行えることとなる。
【００３５】
以降は、図４〜図７に示す各種フローチャートを参照して、サーバー１２０からダウンロードしたデータを処理するデータ処理装置の動作について詳細に説明する。
図４、及び図５は、受信処理のフローチャートである。ユーザーが選択した演奏データをサーバー１２０から受信する場合に実行する処理に着目してその全体的な流れを示したものである。始めに図４、及び図５を参照して、その受信処理について詳細に説明する。その受信処理は、例えばＣＰＵ１０１が、ＲＯＭ１０２に格納されているプログラムを実行することで行われる。
【００３６】
図２に示すように、演奏データはデータブロックエリア単位に分けて保存する。そのブロックエリアのなかでデータが格納されているエリアを把握するために、図３に示すような有効フラグを用意している。このことから、先ず、ステップ４０１では、その有効フラグのイニシャライズを行い、データが保存されていないデータブロックエリアの有効フラグにそのことを示す値の０を代入し、次にデータを書き込む対象とすべきデータブロックエリアを示す値を変数ｎに代入する。その後はステップ４０２に移行する。
【００３７】
ステップ４０２では、送受信装置１０６が演奏データを構成するＭＩＤＩデータ等を受信したか否か判定する。そのＭＩＤＩデータ等を受信していなかった場合、判定はＮＯとなって図５のステップ４０９に移行し、そうでない場合には、判定はＹＥＳとなってステップ４０３に移行する。
【００３８】
ステップ４０３では、送受信装置１０６が受信したＭＩＤＩデータ等が再生用の演奏データのものか否か判定する。そのＭＩＤＩデータ等が再生用の演奏データのものであった場合、判定はＹＥＳとなってステップ４０４に移行し、その再生を行うための演奏処理を実行した後、上記ステップ４０２に戻る。そうでない場合には、判定はＮＯとなってステップ４０５に移行する。
【００３９】
その演奏処理では、図６に示すように、ステップ６０１として、受信したＭＩＤＩデータ（処理タイミングとなったＭＩＤＩデータ）をサウンドシステム１０５の音源に送出する処理が行われる。そのようにして送出されたＭＩＤＩデータに従い音源が楽音の波形データを生成することにより、楽音が放音される。
【００４０】
ステップ４０５では、受信したＭＩＤＩデータ等が保存用の演奏データのものか否か判定する。そのＭＩＤＩデータ等が保存用の演奏データのものでなかった場合、判定はＮＯとなり、特には図示しない処理を必要に応じて実行した後、上記ステップ４０２に戻る。そうでない場合には、判定はＹＥＳとなってステップ４０６に移行する。
【００４１】
ステップ４０６では、そのＭＩＤＩデータ等が保存用の演奏データとして最初に受信したものか否か判定する。それが保存用の演奏データとして初めて受信したものであった場合、判定はＹＥＳとなってステップ４０７に移行し、初めての受信に対応するための書き込み開始処理を実行した後、上記ステップ４０２に戻る。一方、そうでない場合には、判定はＮＯとなってステップ４０８に移行し、書き込みを継続して行うための書き込み処理を実行した後、上記ステップ４０２に戻る。
【００４２】
このようにして、送受信装置１０６が受信したデータはその種類が判別され、その判別結果に従って処理される。それにより、再生用の演奏データを構成するＭＩＤＩデータは随時、処理されてサウンドシステム１０５により楽音が放音され、保存用の演奏データを構成するＭＩＤＩデータ等はＦＭ１０４に書き込まれて保存される。このため、それらを混合した形で送信した場合には、ＦＭ１０４にデータを書き込んでいる間、楽曲の演奏をデータ処理装置のユーザーに聴かせることができることになる。
【００４３】
ＦＭ１０４へのデータの書き込みは、それを行っている状態か否か把握するために変数を用意し、その変数の値を参照して、その値が書き込みを行っていない状態を示す値であれば書き込みを行っている状態を示す値を新たに代入して行うようにしている。以降、その変数については「書込みモード」と呼びことにする。それに代入される０は書き込みを行っていない状態、１はその書き込みを行っている状態を示すこととする。上記ステップ４０７として実行される書き込み開始処理では、後述するように、書込みモードの値が０であればそれに１を代入してＦＭ１０４へのデータの書き込みを開始するようになっている。
【００４４】
上記ステップ４０２の判定がＮＯとなって移行する図５のステップ４０９では、書込みモードの値が１か否か判定する。その１が書込みモードに代入されていた場合、判定はＹＥＳとなってステップ４１０に移行し、そうでない場合には、判定はＮＯとなって図４のステップ４０２に戻る。
【００４５】
ステップ４１０では、ＦＭ１０４から書込み終了フラグを受け取り、そのフラグの値を調べる。続くステップ４１１では、そのフラグの値が１か否か判定する。データの書き込みが終了していない場合、そのフラグの値は１であることから、判定はＹＥＳとなり、次にステップ４１２で書込みモードに０を代入した後、ステップ４１３に移行する。そうでない場合には、判定はＮＯとなって図４のステップ４０２に戻る。
【００４６】
ＦＭ１０４へのデータの書き込みは、データブロックエリア単位で行っている（図２参照）。そのエリア単位でのデータの書き込みを行うために、本実施の形態では、そのエリアへのデータの書き込みが終了したか否か判定するための変数を用意し、その書き込みが終了した時点でその旨を示す値を代入するようにしている。以降、その変数については「ブロック書込み終了フラグ」と呼び、その時点で代入する値は１、その１を代入する前の値、つまりデータの書き込みが終了していない状態を示す値は０であることとする。
【００４７】
ステップ４１３では、上記ブロック書込み終了フラグの値が１か否か判定する。現在、対象とするデータブロックエリアへのデータの書き込みが終了した場合、その終了によって１が代入されることから、判定はＹＥＳとなってステップ４１４に移行する。そうでない場合には、判定はＮＯとなって図４のステップ４０２に戻る。
【００４８】
ステップ４１４では、データの書き込みが終了したデータブロックエリアに対応する有効フラグ（図３参照）の値を１にする。次のステップ４１５では、書き込みの対象とするデータブロックエリアを変更するために変数ｎの値をインクリメントする。その次に移行するステップ４１６では、ブロック書込み終了フラグに０を代入する。図４のステップ４０２にはその後に戻る。
【００４９】
データを送出してからＦＭ１０４がその書き込みを終了するまでに比較的に長い時間がかかる。上記ステップ４０９〜４１６の処理は、基本的に、その書き込み終了に対応するために実行される。
次に、上記ステップ４０７として実行される書込み開始処理について、図７に示すそのフローチャートを参照して詳細に説明する。
【００５０】
先ず、ステップ７０１では、書込みモードの値が０か否か判定する。ＦＭ１０４へのデータの書き込みを行っている場合、そのモードには１が代入されていることから、判定はＮＯとなり、次にステップ７０２で送受信部１０６に、保存用のデータの受信が行えない状態であることを示すＮＧ信号を送出させた後、一連の処理を終了する。そうでない場合には、そのモードには０が代入されていることから、判定はＹＥＳとなってステップ７０３に移行する。
【００５１】
ステップ７０３では、書込みモードに１を代入する。次のステップ７０４では、送受信部１０６が受信したデータ（図中では「入力データ」と表記）をＦＭ１０４の変数ｎの値で指定されるデータブロックエリアに書き込む。その書き込みを行った後は、変数ｎの値で指定される有効フラグ（図中「有効フラグ（ｎ）」と表記）の値を０にし（ステップ７０５）、ＦＭ１０４に書込み終了フラグをリセット、つまりその値を０にさせて（ステップ７０６）からステップ７０７に移行する。
【００５２】
ステップ７０７では、ステップ７０４でのデータの書き込みによりデータブロックエリアへのデータの書き込みが終了したか否か判定する。そのエリアへのデータの書き込みが終了した場合、判定はＹＥＳとなり、次にステップ７０８でブロック書込み終了フラグに１を代入した後、一連の処理を終了する。そうでない場合には、判定はＮＯとなり、ここで一連の処理を終了する、
このようにして、書込み開始処理では、書込みモードの値を参照し、その値が１であった場合に、ＦＭ１０４へのデータの書き込みを開始するようにしている。なお、図４のステップ４０８として実行される書き込み処理は、例えばステップ７０４、７０７、及び７０８を図７に示すようにその順序で実行するようになっているサブルーチン処理である。
＜第２の実施の形態＞
上記第１の実施の形態では、保存用のデータに再生用の演奏データを混合する形でサーバー１２０から送信させることにより、データ処理装置が受信したデータを判別して、再生用の演奏データを再生するようにしている。これに対し、第２の実施の形態は、保存用のデータが演奏データのような再生の対象となるデータであった場合、その保存を行いながらその再生も併せて行えるようにしたものである。
【００５３】
そのように再生も併せて行う場合、保存用のデータが再生の対象となるデータであれば再生用の演奏データ等を混合しなくとも済むようになる。それにより、送信側における処理の負荷の増大を抑えつつ、第１の実施の形態と同様の効果が得られることとなる。
【００５４】
また、送信の対象となるデータの量は小さくなるために、その送信はより短時間に行えることとなる。それにより、受信側では、データの処理にかかる負荷が低減することから、データを混合して送信する場合と比較して、データの保存をより短時間に行えるようになる。
【００５５】
第２の実施の形態におけるデータ処理装置の構成は、第１の実施の形態におけるそれと基本的に同じである。動作も大部分は基本的に同じである。このため、第１の実施の形態の説明で付した符号をそのまま用いつつ、第１の実施の形態から異なる部分についてのみ説明することとする。保存用のデータについても第１の実施の形態と同じく、演奏データのみを想定することとする。
【００５６】
図８は、第２の実施の形態でＦＭ１０４に保存される演奏データを説明する図である。
本実施の形態でも図８に示すように、ＦＭ１０４にはデータブロックエリア単位で演奏データ（データ群）を書き込んで保存するようになっている。
【００５７】
その演奏データは、上述したように、ＭＩＤＩデータにその処理タイミングを示す時間データを付加して構成されている。本実施の形態では、そのようなデータの他に、繰り返し命令が挿入されている。その繰り返し命令は、それ自体が最後の区切りを示す範囲（繰り返し範囲）の演奏を再度、行うことを指示する命令である。演奏データを保存する際、予め定めた条件を満たした場合にのみ有効とされる。
【００５８】
上記条件とは、繰り返し命令の直後に位置する繰り返し命令、及び演奏データの最後の何れかまでデータを書き込んでいない、つまり、繰り返し命令の後に繰り返し範囲分のデータを書き込んでいないことである。その条件を満たしていた場合、繰り返し命令は実行され、その条件が満たされなくなるまでの間、その繰り返し命令が最後の区切りを示す繰り返し範囲の再生が繰り返し行われる。その再生を繰り返し行う繰り返し範囲の最初の区切りは、本実施の形態では、直前の繰り返し命令の次に位置するデータ、及び演奏データの先頭に位置するデータの何れかとしている。
【００５９】
例えば各データブロックエリアに１小節分の演奏データを書き込む場合、上記繰り返し命令は、例えばその最後に挿入される。そのように挿入された演奏データをデータブロック（０）エリアから書き込む場合には、その演奏データは次のように再生される。
【００６０】
演奏データの再生により演奏は１小節目から開始される。その１小節目の演奏は、データブロック（１）エリアへのデータの書き込みが終了するまでの間に終了しなければ、再度、行われ、２小節目の演奏には、そのエリアへのデータ（２小節目のデータ）の書き込みが終了した後に移行する。そのようにして、データブロックエリアへのデータの書き込みが終了するに伴い、演奏される小節が切り換わり、最後の小節の演奏は、演奏データ全ての書き込みが完了した後に行われる。このため、ユーザーは、演奏される小節の切り換わりにより、データの書き込みによる保存の進行状況を把握することができるようになっている。
【００６１】
上記繰り返し命令が挿入された演奏データをサーバー１２０からダウンロードしてその保存、及び再生を行うために、データ処理装置が実行する受信処理は第１の実施の形態におけるそれから大きく異なっている。このことから、図９〜図１３に示すフローチャートを参照して、第２の実施の形態における受信処理について詳細に説明する。
【００６２】
先ず、ステップ９０１では、その有効フラグのイニシャライズを行い、データが保存されていないデータブロックエリアの有効フラグには０を代入し、次にデータを書き込む対象とすべきデータブロックエリアを示す値を変数ｎに代入する。また、書き込んだ演奏データを構成するデータの読み出しのために用意した変数（以降「演奏読み込みアドレス」と呼ぶ）に、そのデータブロックエリアの先頭アドレスを示すアドレス値を代入する。
【００６３】
ステップ９０１に続くステップ９０２では、送受信装置１０６が演奏データを構成するＭＩＤＩデータ等を受信したか否か判定する。そのＭＩＤＩデータ等を受信していなかった場合、判定はＮＯとなって図１０のステップ９０８に移行し、そうでない場合には、判定はＹＥＳとなってステップ９０３に移行する。
【００６４】
ステップ９０３では、送受信装置１０６が受信したＭＩＤＩデータ等が保存用の演奏データのものか否か判定する。そのＭＩＤＩデータ等が保存用の演奏データのものでなかった場合、判定はＮＯとなってステップ９０４に移行し、その他の処理を実行した後、上記ステップ９０２に戻る。そうでない場合には、判定はＹＥＳとなってステップ９０５に移行する。
【００６５】
ステップ９０５では、受信したＭＩＤＩデータ等が演奏データとして最初に受信したものか否か判定する。それが保存用の演奏データとして初めて受信したものであった場合、判定はＹＥＳとなってステップ９０６に移行し、図７に示す書き込み開始処理を実行した後、上記ステップ９０２に戻る。一方、そうでない場合には、判定はＮＯとなってステップ９０７に移行し、書き込みを継続して行うための書き込み処理を実行した後、上記ステップ９０２に戻る。
【００６６】
上記ステップ９０２の判定がＮＯとなって移行する図１０のステップ９０８では、上記演奏読み込みアドレスに代入された値で指定されるアドレスからデータの読み出しを行う。続くステップ９０９では、読み出したデータが繰り返し命令か否か判定する。そのデータが読み出し命令でなかった場合、判定はＮＯとなって図１２のステップ９２１に移行し、そうでない場合には、判定はＹＥＳとなってステップ９１０に移行する。
【００６７】
上述したように、繰り返し命令は、それより後に処理する繰り返し命令、或いは演奏データの最後までデータが書き込まれていない場合に実行する。このことから、ステップ９１０〜図１１のステップ９２０では、読み出した繰り出し命令を実行する条件が満たされているか否か確認し、その確認結果に応じてその命令を実行するための処理が行われる。
【００６８】
ステップ９１０では、変数であるサーチアドレスに、演奏読み込みアドレスの値を代入する。次に移行するステップ９１１では、サーチアドレスの値を進める（ここでは、より遅いタイミングで処理するデータを読み出す方向に値を更新するという意味である）。その次に移行するステップ９１２では、そのサーチアドレスの値で指定されるアドレスからデータの読み込みを行う。その読み込み後に移行するステップ９１３では、その値で指定されるアドレスにデータがないか否か判定する。そのアドレスからデータを読み出せなかった場合、つまりステップ９０８で読み出した繰り返し命令が演奏データの最後のデータの直前に位置する繰り返し命令であった場合、判定はＹＥＳとなって図１２のステップ９２５に移行する。それにより、その繰り返し命令以降に位置するデータを対象にした再生を行う。一方、そうでない場合には、判定はＮＯとなって図１１のステップ９１４に移行する。
【００６９】
ステップ９１４では、上記ステップ９１２で読み出したデータが繰り返し命令か否か判定する。そのデータが繰り返し命令でなかった場合、判定はＮＯとなって図１０のステップ９１１に戻る。それにより、繰り返し命令、或いは演奏データの最後に位置するデータを読み出すまで、サーチアドレスの値を進める。一方、そうでない場合には、判定はＹＥＳとなってステップ９１５に移行する。
【００７０】
ステップ９１５では、読み出した繰り出し命令が書き込まれていたデータブロックエリアを示す番号を変数ｍに代入する。次のステップ９１６では、その変数ｍに代入した番号で指定される有効フラグ（図３参照）の値が０か否か判定する。そのデータブロックエリアへのデータの書き込みが終了していた場合、それに対応する有効フラグの値は１であることから、判定はＮＯとなってステップ９１７に移行し、再生の対象とするデータが書き込まれたデータブロックエリアを変更するために、例えば演奏する小節を次の小節に進めるために、演奏読み込みアドレスにサーチアドレスの値を代入した後、図１０のステップ９１１に戻る。一方、そうでない場合には、つまり図１０のステップ９０８、或いは９１２で読み出した繰り返し命令の後に繰り返し命令、或いは演奏データの最後に位置するデータまでデータが書き込まれていない場合（対応する有効フラグの値が１となっていなければ書き込まれていないとみなされる）には、判定はＹＥＳとなってステップ９１８に移行する。
【００７１】
ステップ９１８では、演奏読み込みアドレスの値を後退、つまりそれまでよりも処理すべきタイミングが早いデータを読み出す方向に値を更新する。続くステップ９１９では、そのアドレスの値で指定されるデータの読み出しを行う。その後に移行するステップ９２０では、読み出したデータが繰り返し命令、或いは演奏データの先頭に位置するデータか否か判定する。そのデータが繰り返し命令、及び演奏データの先頭に位置するデータであった場合、判定はＹＥＳとなって図１２のステップ９２５に移行する。そうでない場合には、判定はＮＯとなって上記ステップ９１８に戻る。それにより、処理すべき繰り返し範囲の先頭を特定するまでの間、つまりステップ９２０の判定がＹＥＳとなるまでの間、ステップ９１８〜９２０で形成される処理ループを繰り返し実行する。
【００７２】
演奏データを構成するＭＩＤＩデータの処理は、それの処理タイミングを示す時間データを変数ＴＩＭＥＲに代入し、時間データの分解能に対応する時間が経過する毎に代入した値をデクリメントし、その値が０となったときに行うようになっている。図１０のステップ９０９の判定がＮＯとなって移行する図１２のステップ９２１では、その変数ＴＩＭＥＲの値が０か否か判定する。その値が０でなかった場合、判定はＮＯとなって図１３のステップ４０９に移行し、そうでない場合には、判定はＹＥＳとなってステップ９２９に移行する。
【００７３】
ステップ９２２では、演奏読み込みアドレスの値で指定されるデータを読み出す。その次に移行するステップ９２３では、読み出しによってデータを読み出せたか否か判定する。データを読み出せなかった場合、つまり演奏データの再生を最後まで行ったような場合、判定はＹＥＳとなり、ここで一連の処理を終了する。そうでない場合には、判定はＮＯとなってステップ９２４に移行する。
【００７４】
ステップ９２４では、処理すべきタイミングとなったＭＩＤＩデータを処理するために演奏処理を実行する。その演奏処理を実行すると、次に演奏読み込みアドレスを先に進め（ステップ９２５）、更新後のアドレスの値で指定される時間データの読み出しを行い（ステップ９２６）、読み出した時間データを変数ＴＩＭＥＲに代入する（ステップ９２７）。その後に図１３のステップ４０９に移行する。
【００７５】
図１３に示すステップ９２８〜９３５の各処理内容は、図５に示すステップ４０９〜４１６のそれと基本的に同じである。このことから、詳細な説明は省略する。ステップ９３５の処理を実行した後に、図９のステップ９０２に戻る。
なお、本実施の形態では、繰り返し範囲を特定できるように繰り返し命令を挿入しているが、その範囲は別の方法で特定させるようにしても良い。例えば各繰り返し範囲をデータ量、或いは演奏時間等で示すテーブルなどを用意して、その範囲を特定できるようにしても良い。
＜第３の実施の形態＞
周知のように、ＭＩＤＩデータ等を用いて構成された演奏データでは、再生時に放音される楽音の音色を指定することができる。その音色で楽音を発音させるためのデータ（例えば波形データ。以降「音色データ」と呼ぶ）は、例えばエクスクルーシブ・メッセージの形で演奏データ中に挿入することができる。それにより、任意の音色で楽音を放音させることもできるようになっている。
【００７６】
保存用の演奏データと混合される形の再生用の演奏データ中に音色を指定するデータ（命令。以降「音色選択データ」と呼ぶ）が挿入されていた場合、その音色選択データを受信した時点（処理すべき時点）でそれが指定する音色に対応する音色データが保存されていない状況が考えられる。そのような状況になると、その音色で楽音を発音させることができない。それにより、演奏データの再生も行えなくなる。第３の実施の形態は、そのような状況にも対応できるようにして、保存用の演奏データの保存中における再生用の演奏データの再生をより確実に行えるようにしたものである。
【００７７】
第３の実施の形態におけるデータ処理装置の構成は、第１の実施の形態におけるそれと基本的に同じである。動作も大部分は基本的に同じである。このため、第２の実施の形態と同様に、第１の実施の形態の説明で付した符号をそのまま用いつつ、第１の実施の形態から異なる部分についてのみ説明することとする。保存用のデータについても第２の実施の形態と同じく、演奏データのみを想定することとする。
【００７８】
図１４は、第３の実施の形態でＦＭ１０４に保存される演奏データを説明する図である。
本実施の形態でも図１４に示すように、ＦＭ１０４にはデータブロックエリア単位で演奏データ（データ群）を書き込んで保存するようになっている。その演奏データは、音色を指定する音色選択データや、その選択データによって指定される音色で楽音を発音させるための音色データを挿入できるものである。
【００７９】
上記音色選択データや音色データを挿入可能な演奏データをサーバー１２０からダウンロードするデータ処理装置が実行する受信処理は第１の実施の形態におけるそれから大きく異なっている。このことから、図１５〜図１７に示す各種フローチャートを参照して、第３の実施の形態における受信処理、更にはその受信処理内で実行されるサブルーチン処理について詳細に説明する。
【００８０】
図１５は、第３の実施の形態における受信処理のフローチャートである。第１の実施の形態におけるそれ（図４、及び図５参照）から異なる部分を抜粋して示したものである。始めに図１５を参照して、第３の実施の形態における受信処理について詳細に説明する。
【００８１】
先ず、ステップ１５０１では、有効フラグのイニシャライズを行い、データが保存されていないデータブロックエリアの有効フラグにそのことを示す値の０を代入し、次にデータを書き込む対象とすべきデータブロックエリアを示す値を変数ｎに代入する。その後はステップ１５０２に移行する。
【００８２】
ステップ１５０２では、送受信装置１０６が演奏データを構成するＭＩＤＩデータ等を受信したか否か判定する。そのＭＩＤＩデータ等を受信していなかった場合、判定はＮＯとなって図５のステップ４０９に移行し、それ以降の処理を同様に実行した後、再度ステップ１５０２での判定を行う。一方、そうでない場合には、判定はＹＥＳとなってステップ１５０３に移行する。
【００８３】
ステップ１５０３では、送受信装置１０６が受信したＭＩＤＩデータ等の判別を行い、再生用の演奏データを構成するＭＩＤＩデータ、音色選択データ、及び保存用の演奏データを構成するデータのうちの何れであるか特定する。再生用の演奏データを構成するＭＩＤＩデータと判別すると、ステップ１５０４に移行してそのＭＩＤＩデータをサウンドシステムの音源に送出する演奏処理を実行した後、上記ステップ１５０２に戻る。その演奏データを構成する音色選択データと判別すると、ステップ１５０５に移行して、音色の選択を行う音色選択処理を実行した後、上記ステップ１５０２に戻る。保存用の演奏データを構成するデータと判別すると、ステップ１５０６に移行する。
【００８４】
ステップ１５０６では、保存用の演奏データを構成するデータが最初に受信したものか否か判定する。それが保存用の演奏データとして初めて受信したものであった場合、判定はＹＥＳとなってステップ１５０７に移行し、図７に示す書き込み開始処理を実行した後、上記ステップ１５０２に戻る。一方、そうでない場合には、判定はＮＯとなってステップ１５０８に移行し、書き込みを継続して行うための書き込み処理を実行した後、上記ステップ１５０２に戻る。
【００８５】
図１６、及び図１７は、上記ステップ１５０５として実行される音色選択処理のフローチャートである。次に図１６、及び図１７を参照して、その選択処理について詳細に説明する。
ＦＭ１０４に保存した演奏データ中に、音色選択データが指定する音色に対応した音色データが存在している可能性がある。このことから、本実施の形態では、ＦＭ１０４に保存した演奏データ中に存在する音色データの確認を行い、その確認結果に応じて音色の指定、つまりサウンドシステムの音源に音色データを送出している。
【００８６】
先ず、ステップ１６０１では、ステップ１５０７の書込み開始処理、及びステップ１５０８の書き込み処理のうちで直前に実行したほうの処理で最後にデータをＦＭ１０４に書き込んだアドレスの値を変数である読み込みアドレスに代入する。次のステップ１６０２では、そのアドレスに代入した値で指定されるアドレスからデータの読み出しを行う。その読み出しの後はステップ１６０３に移行する。
【００８７】
ステップ１６０３では、読み出したデータが音色データか否か判定する。そのデータが音色データでなかった場合、判定はＮＯとなってステップ１６０８に移行し、そうでない場合には、判定はＹＥＳとなってステップ１６０４に移行する。
【００８８】
ステップ１６０４では、音色データが音色選択データの指定する音色に対応しているか否か判定する。音色選択データの指定する音色が音色データで発音される楽音の音色と一致していない場合、判定はＮＯとなってステップ１６０８に移行する。そうでない場合には、即ちそれらの音色が一致していた場合には、判定はＹＥＳとなってステップ１６０５に移行し、音色データを読み出したデータブロックエリアの番号を変数ｍに代入する。ステップ１６０６にはその後に移行する。
【００８９】
ステップ１６０６では、変数ｍの値に対応する有効フラグの値が１か否か判定する。音色データを読み出したデータブロックエリアへのデータの書き込みが終了していない場合、その有効フラグの値は０であることから、判定はＮＯとなって図１７のステップ１６１１に移行する。そうでない場合には、つまりその書き込みが終了していた場合には、判定はＹＥＳとなってステップ１６０７に移行し、データブロックエリアに書き込まれている音色データをサウンドシステムの音源に送出した後、一連の処理を終了する。その音色データを音源に送出することにより、受信した音色選択データで指定された音色で楽音の発音が行われることとなる。
【００９０】
上記ステップ１６０３、或いは１６０４の判定がＮＯとなって移行するステップ１６０８では、読み込みアドレスを後退、即ちより早いタイミングで処理すべきデータを読み出す方向にその値を更新する。その次に移行するステップ１６０９では、更新後の読み込みアドレスの値で指定されるアドレスからデータの読み出しを行う。その読み出し後に移行するステップ１６１０では、読み出したデータがなかったか否か判定する。保存したデータの先頭までデータを既に読み出していた場合、それ以上データを読み出せないことから、判定はＹＥＳとなり、ここで一連の処理を終了する。そうでない場合には、判定はＮＯとなって上記ステップ１６０３に戻る。それにより、既に保存されたデータの最後から先頭に向けて、音色データを探す探索を継続する。
【００９１】
上記ステップ１６０６の判定がＮＯとなって移行する図１７のステップ１６１１では、読み込みアドレスの値を後退させて更新する。続くステップ１６１２では、更新後の読み込みアドレスの値で指定されるアドレスからデータの読み出しを行う。その読み出し後に移行するステップ１６１３では、読み出したデータがなかったか否か判定する。データを読み出せなかった場合、判定はＹＥＳとなり、ここで一連の処理を終了する。そうでない場合には、判定はＮＯとなってステップ１６１４に移行する。
【００９２】
ステップ１６１４では、読み出したデータが音色データか否か判定する。そのデータが音色データでなかった場合、判定はＮＯとなって上記ステップ１６１１に戻る。それにより、音色データを探す探索を続行する。一方、そうでない場合には、判定はＹＥＳとなってステップ１６１５に移行する。
【００９３】
ステップ１６１５では、音色データを読み出したデータブロックエリアの番号を変数ｍに代入する。次に実行するステップ１６１６では、変数ｍの値に対応する有効フラグの値が１か否か判定する。音色データを読み出したデータブロックエリアへのデータの書き込みが終了していない場合、その有効フラグの値は０であることから、判定はＮＯとなって上記ステップ１６１１に戻る。それにより、音色データを探す探索を続行する。一方、そうでない場合には、つまりその書き込みが終了していた場合には、判定はＹＥＳとなって図１６のステップ１６０７に移行する。
【００９４】
なお、第３の実施の形態では、最後に書き込まれた音色データが音色選択データの指定する音色に対応していればその音色データ、そうでなければ、それよりも前に、有効フラグの値が１となっているデータブロックエリアに書き込まれた音色データをサウンドシステムの音源に送出して、音色を選択するようにしている。しかし、最後に書き込まれた音色データが音色選択データの指定する音色に対応していない場合は、別の方法で音色を選択しても良い。例えば既に書き込まれた音色データ全て、或いは予め定めた範囲内に存在する音色データを調べて、音色選択データの指定する音色を選択（設定）するようにしても良い。
【００９５】
本実施の形態（第１〜第３の実施の形態）では、ＦＭ（フラッシュメモリ）１０４にダウンロードしたデータを保存しているが、データを保存する記録媒体はＦＭ１０４のような半導体メモリに限定されるわけではない。フレキシブルディスクや光磁気ディスク等のデータを書き込む速度が比較的に遅い他の記録媒体であっても良い。
【００９６】
上述したようなデータ処理装置の動作、或いはその変形例の動作を実現させるようなプログラムは、ＣＤ−ＲＯＭ、ＤＶＤ、或いは光磁気ディスク等の記録媒体に記録させて配布しても良い。或いは、公衆網等で用いられる伝送媒体を介して、そのプログラムの一部、若しくは全部を配信するようにしても良い。そのようにした場合には、ユーザーはプログラムを取得してコンピュータなどのデータ処理装置にロードすることにより、そのデータ処理装置に本発明を適用させることができる。このことから、記録媒体は、プログラムを配信する装置がアクセスできるものであっても良い。
【００９７】
【発明の効果】
以上、説明したように本発明は、第１の装置に、保存用データ、及び所定の媒体を介して再生するための再生用データを混合させた形で第２の装置に送信させ、第２の装置に、第１の装置から受信したデータの種類を判別させ、判別結果に従って、保存用データは記録媒体に記録して保存させ、再生用データは所定の媒体を介して再生させる。このため、ユーザーは、保存用データを保存している間、並行して行われる再生用データの再生を楽しめるようになる。その再生を楽しめるようになる結果、保存用データを保存している時間を意識する度合を低減させることができる。
【００９８】
本発明は、所定の媒体を介して再生するための再生用データを保存用データとして第１の装置が送信するとき、第２の装置に、第１の装置から受信した該保存用データの再生を、保存用データの記録媒体への記録による保存と併せて行わせる。このため、上記の発明と同様に、保存用データを保存している時間を意識する度合を低減させることができる。
【図面の簡単な説明】
【図１】第１の実施の形態によるデータ処理装置の回路構成図である。
【図２】フラッシュメモリのマップを示す図である。
【図３】ＲＡＭに格納されたデータブロックエリア管理用のデータを説明する図である。
【図４】受信処理のフローチャートである。
【図５】受信処理のフローチャートである（続き）。
【図６】演奏処理のフローチャートである。
【図７】書込み開始処理のフローチャートである。
【図８】フラッシュメモリに保存される演奏データを説明する図である（第２の実施の形態）。
【図９】受信処理のフローチャートである（第２の実施の形態）。
【図１０】受信処理のフローチャートである（第２の実施の形態：続き１）。
【図１１】受信処理のフローチャートである（第２の実施の形態：続き２）。
【図１２】受信処理のフローチャートである（第２の実施の形態：続き３）。
【図１３】受信処理のフローチャートである（第２の実施の形態：続き４）。
【図１４】フラッシュメモリに保存される演奏データを説明する図である（第３の実施の形態）。
【図１５】受信処理のフローチャートである（第３の実施の形態）。
【図１６】音色選択処理のフローチャートである。
【図１７】音色選択処理のフローチャートである（続き）。
【符号の説明】
１０１    ＣＰＵ
１０２    ＲＯＭ
１０３    ＲＡＭ
１０４    フラッシュメモリ（ＦＭ）
１０５    サウンドシステム
１０６    送受信装置
１０７    入力装置
１２０    サーバー
１２１    通信ネットワーク
【図１】
2004347877.tif 000003
【図２】
2004347877.tif 000004
【図３】
2004347877.tif 000005
【図４】
2004347877.tif 000006
【図５】
2004347877.tif 000007
【図６】
2004347877.tif 000008
【図７】
2004347877.tif 000009
【図８】
2004347877.tif 000010
【図９】
2004347877.tif 000011
【図１０】
2004347877.tif 000012
【図１１】
2004347877.tif 000013
【図１２】
2004347877.tif 000014
【図１３】
2004347877.tif 000015
【図１４】
2004347877.tif 000016
【図１５】
2004347877.tif 000017
【図１６】
2004347877.tif 000018
【図１７】
2004347877.tif 000019