JP4090925B2 - 演奏データ送信装置、通信システム、送信方法及びプログラム - Google Patents
演奏データ送信装置、通信システム、送信方法及びプログラム Download PDFInfo
- Publication number
- JP4090925B2 JP4090925B2 JP2003088338A JP2003088338A JP4090925B2 JP 4090925 B2 JP4090925 B2 JP 4090925B2 JP 2003088338 A JP2003088338 A JP 2003088338A JP 2003088338 A JP2003088338 A JP 2003088338A JP 4090925 B2 JP4090925 B2 JP 4090925B2
- Authority
- JP
- Japan
- Prior art keywords
- performance data
- data
- key
- performance
- transmitting
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Expired - Lifetime
Links
Images
Landscapes
- Electrophonic Musical Instruments (AREA)
Description
【０００１】
【発明の属する技術分野】
本発明は、演奏データ通信技術に関する。
【０００２】
【従来の技術】
ネットワークを利用して演奏データを送受信することにより、遠隔地の演奏者同士が合奏を行う、いわゆるネットセッションがある。通信のプロトコルとしてリアルタイム性の高いＵＤＰ(User Datagram Protocol)を利用した場合には、データの信頼性が保障されていないため、演奏データの欠落による鳴りっ放しや音抜けなどの問題を生じることがあった。一方、データの信頼性が保障されているＴＣＰ(Transmission Control Protocol)を利用した場合には、リアルタイムの演奏の送受信を行うことができなくなり、合奏を実現することができない。
【０００３】
また、下記の特許文献１及び２が公開されている。
【０００４】
【特許文献１】
特開平９−２８１９６１号公報
【特許文献２】
特許第３２７１５７２号公報
【０００５】
【発明が解決しようとする課題】
本発明の目的は、演奏データのリアルタイム性及び信頼性を保障する通信技術を提供することである。
【０００６】
【課題を解決するための手段】
本発明の一観点によれば、演奏データをＵＤＰの通信プロトコルで送信する演奏データ送信手段と、前記演奏データの欠落を補正するためのリファレンスデータをＴＣＰの通信プロトコルで送信するリファレンスデータ送信手段とを有し、前記リファレンスデータ送信手段は、所定時間間隔で該所定時間内に送信済みの演奏データがあるときには最新の送信済みの演奏データをリファレンスデータとして送信する演奏データ送信装置が提供される。
本発明の他の観点によれば、演奏データ送信装置及び演奏データ受信装置がネットワークを介して接続される演奏データ通信システムであって、前記演奏データ送信装置は、演奏データをＵＤＰの通信プロトコルで前記演奏データ受信装置へ送信する演奏データ送信手段と、前記演奏データの欠落を補正するためのリファレンスデータをＴＣＰの通信プロトコルで前記演奏データ受信装置へ送信するリファレンスデータ送信手段とを有し、前記演奏データ受信装置は、前記演奏データ送信装置から演奏データをＵＤＰの通信プロトコルで受信する演奏データ受信手段と、前記演奏データ送信装置から前記演奏データの欠落を補正するためのリファレンスデータをＴＣＰの通信プロトコルで受信するリファレンスデータ受信手段と、前記受信した演奏データを基に現在の演奏状態を記憶する演奏状態記憶手段と、前記受信したリファレンスデータ及び前記現在の演奏状態を比較し、一致していないときには該受信したリファレンスデータの処理を行うリファレンスデータ処理手段とを有し、前記リファレンスデータ送信手段は、所定時間間隔で該所定時間内に送信済みの演奏データがあるときには最新の送信済みの演奏データをリファレンスデータとして送信する演奏データ通信システムが提供される。
本発明のさらに他の観点によれば、演奏データをＵＤＰの通信プロトコルで送信する演奏データ送信ステップと、前記演奏データの欠落を補正するためのリファレンスデータをＴＣＰの通信プロトコルで送信するリファレンスデータ送信ステップとを有し、前記リファレンスデータ送信ステップは、所定時間間隔で該所定時間内に送信済みの演奏データがあるときには最新の送信済みの演奏データをリファレンスデータとして送信する演奏データ送信方法が提供される。
本発明のさらに他の観点によれば、演奏データをＵＤＰの通信プロトコルで送信する演奏データ送信ステップと、前記演奏データの欠落を補正するためのリファレンスデータをＴＣＰの通信プロトコルで送信するリファレンスデータ送信ステップとをコンピュータに実行させるためのプログラムであって、前記リファレンスデータ送信ステップは、所定時間間隔で該所定時間内に送信済みの演奏データがあるときには最新の送信済みの演奏データをリファレンスデータとして送信するプログラムが提供される。
【０００７】
本発明によれば、演奏データをＵＤＰの通信プロトコルで通信し、リファレンスデータをＴＣＰの通信プロトコルで通信する。演奏データの他に、リファレンスデータを通信することにより、演奏データが欠落した場合でもその演奏データをリカバリすることができる。ＵＤＰはリアルタイム性が高い通信プロトコルであるので、演奏データをＵＤＰで通信することにより演奏データのリアルタイム通信を保障することができる。また、ＴＣＰはデータ信頼性が高い通信プロトコルであるので、リファレンスデータをＴＣＰで通信することにより、リファレンスデータの信頼性が保障され、ひいては演奏データの信頼性を保障することができる。
【０００８】
【発明の実施の形態】
図１（Ａ）は、本発明の実施形態による演奏データ通信システムの第１の構成例を示す。２個の電子楽器１０１及び１０２は、それぞれ送信部１１１及び受信部１１２を有し、ネットワーク（例えばインターネット）を介して相互に接続される。送信部１１１は演奏データ（ＭＩＤＩデータ）を送信することができ、受信部１１２は演奏データを受信することができる。電子楽器１０１の送信部１１１が演奏データを送信すると、電子楽器１０２の受信部１１２がその演奏データを受信する。逆に、電子楽器１０２の送信部１１１が演奏データを送信すると、電子楽器１０１の受信部１１２がその演奏データを受信する。電子楽器１０１及び１０２は、例えば鍵盤を有する。２人の演奏者がそれぞれ電子楽器１０１及び１０２で演奏すると、自己の電子楽器で楽音を発音すると共に、相手の電子楽器に演奏データを送信して発音させることができる。ネットワークを利用して演奏データを送受信することにより、遠隔地の演奏者同士が合奏を行う、いわゆるネットセッションを行うことができる。
【０００９】
図１（Ｂ）は、本発明の実施形態による演奏データ通信システムの第２の構成例を示す。３個の電子楽器１２１〜１２３は、ネットワークサーバー１２０を介して相互に接続される。３個の電子楽器１２１〜１２３とネットワークサーバー１２０とは、ネットワーク（例えばインターネット）を介して接続される。電子楽器１２１〜１２３は、図１（Ａ）と同様に、それぞれ送信部及び受信部を有し、ネットワークサーバー１２０を介して演奏データの通信を行うことができる。この場合も、遠隔地の演奏者同士が合奏を行うことができる。
【００１０】
図１（Ａ）のように、２人が電子楽器１０１及び１０２で合奏する場合には、電子楽器１０１及び１０２を直接接続して通信を行うことが好ましい。電子楽器１０１及び１０２間を直接接続すると、高速に通信を行うことができる。しかし、３個以上の電子楽器を直接接続すると、各電子楽器がそれぞれ複数の電子楽器に対して通信を行うため負荷が増大する。したがって、図１（Ｂ）のように、３個以上の電子楽器１２１〜１２３で合奏する場合には、ネットワークサーバー１２０を介して３個以上の電子楽器１２１〜１２３を接続して通信を行うことが好ましい。ネットワークサーバー１２０を介して電子楽器１２１〜１２３を接続すると、各電子楽器はネットワークサーバー１２０のみに対して通信すればよいので、各電子楽器の負荷を軽減することができる。
【００１１】
図２は、本実施形態による演奏データ通信システムの通信方法を示す図である。横軸は時間を示す。
まず、送信側の電子楽器の演奏処理手順を説明する。タイミングｔ１にて、鍵盤を押鍵すると、キーオンイベント（キーナンバ（音高）を含む）が発生し、発音処理を行う。次に、タイミングｔ３で、同一のキーナンバの鍵を離鍵すると、キーオフイベント（キーナンバを含む）が発生し、消音処理を行う。次に、タイミングｔ４で、同一のキーナンバの鍵を押鍵すると、キーオンイベントが発生し、発音処理を行う。次に、タイミングｔ７で、同一のキーナンバの鍵を離鍵すると、キーオフイベントが発生し、消音処理を行う。
【００１２】
次に、送信側の電子楽器の演奏データ送信処理手順を説明する。タイミングｔ１でキーオンイベントが発生すると、受信側の電子楽器にそのキーオンイベントを送信する。次に、タイミングｔ３でキーオフイベントが発生すると、受信側の電子楽器にそのキーオフイベントを送信する。次に、タイミングｔ４でキーオンイベントが発生すると、受信側の電子楽器にそのキーオンイベントを送信する。次に、タイミングｔ７でキーオフイベントが発生すると、受信側の電子楽器にそのキーオフイベントを送信する。これらのキーオンイベント及びキーオフイベントは、ＵＤＰ(User Datagram Protocol)の通信プロトコルで送信する。
【００１３】
ＵＤＰは、データの信頼性が保障されていない欠点があるが、データ保障のための通信を行わないため、リアルタイム性が保障される。演奏データ（例えばキーオンイベント及びキーオフイベント）をＵＤＰで送信することにより、演奏データのリアルタイム性を保障することができる。ただし、ＵＤＰはデータ保障されていないので、送信側の電子楽器が送信した演奏データを受信側の電子楽器が受信できずにデータが欠落する場合がある。そこで、本実施形態では、下記に示すリファレンスデータ通信によりデータ保障を行う。
【００１４】
次に、送信側の電子楽器のリファレンスデータ送信処理手順を説明する。リファレンスデータ送信処理は、所定時間ｔ間隔のタイミングｔ２，ｔ５，ｔ６，ｔ８，ｔ９において行う。タイミングｔ２では、その所定時間ｔ前以内に送信済みのキーオンイベント（タイミングｔ１）が存在するので、そのキーオンイベント（タイミングｔ１）をリファレンスデータｒｅｆ２として送信する。受信側の電子楽器が、タイミングｔ１で発生したキーオンイベントを受信した場合には、正常な発音処理を行っているので、リファレンスデータｒｅｆ２の処理を行う必要がない。一方、受信側の電子楽器が、タイミングｔ１で発生したキーオンイベントを受信していない場合には、受信したリファレンスデータｒｅｆ２を基に発音処理をすることによりリカバリすることができる。
【００１５】
次に、タイミングｔ５では、その所定時間ｔ前以内に送信済みのキーイベント（タイミングｔ３及びｔ４）が存在するので、最新の送信済みのキーイベント（タイミングｔ４）をリファレンスデータｒｅｆ５として送信する。受信側の電子楽器が、タイミングｔ４で発生したキーオンイベントを受信していない場合には、受信したリファレンスデータｒｅｆ５を基に発音処理をすることによりリカバリすることができる。この場合、タイミングｔ３及びｔ４のキーイベント（キーオンイベント又はキーオフイベント）のうち、最新の送信済みのキーイベント（タイミングｔ４）をリファレンスデータｒｅｆ５として送信することにより、現在の演奏状態をリカバリすることができる。
【００１６】
次に、タイミングｔ６では、その所定時間ｔ前以内に送信済みのキーイベントが存在しないので、リファレンスデータの送信を行わない。
【００１７】
次に、タイミングｔ８では、その所定時間ｔ前以内に送信済みのキーオフイベント（タイミングｔ７）が存在するので、そのキーオフイベント（タイミングｔ７）をリファレンスデータｒｅｆ８として送信する。受信側の電子楽器が、タイミングｔ７で発生したキーオフイベントを受信していない場合には、受信したリファレンスデータｒｅｆ８を基に消音処理をすることによりリカバリすることができる。
【００１８】
次に、タイミングｔ９では、その所定時間ｔ前以内に送信済みのキーイベントが存在しないので、リファレンスデータの送信を行わない。
【００１９】
上記のリファレンスデータは、ＴＣＰ(Transmission Control Protocol)の通信プロトコルで送信する。ＴＣＰは、データ保障がされているプロトコルであるので、リファレンスデータは確実に送信することができる。したがって、演奏データの通信欠落が生じた場合でも、リファレンスデータ通信により確実にリカバリすることができる。
【００２０】
以上のように、所定時間間隔で該所定時間内に送信済みの演奏データがあるか否かを判断し、あるときには最新の送信済みの演奏データをリファレンスデータとして送信する。また、所定時間間隔で最新の送信済みの演奏データをリファレンスデータとして送信してもよい。
【００２１】
図３は、送信側電子楽器３０１及び受信側電子楽器３０２の構成例を示す。説明の簡単のため、送信側電子楽器３０１及び受信側電子楽器３０２のそれぞれの構成を示しているが、実際の電子楽器は送信側電子楽器３０１及び受信側電子楽器３０２の両方の構成を有する。
【００２２】
送信側電子楽器３０１は、音源３１１、中央演算処理装置（ＣＰＵ）３１２、メモリ３１３、ネットワークデバイス３１５及びキーボード（鍵盤）３１６を有する。メモリ３１３は、リファレンスデータバッファ３１４を有する。
【００２３】
演奏者がキーボード３１６にて押鍵又は離鍵を行うと、ＣＰＵ３１２はそれらを検出してキーオンイベント又はキーオフイベントを生成し、ネットワークデバイス３１５を介してキーデータＫＥＹをＵＤＰで電子楽器３０２に送信する。キーデータＫＥＹは、キーオンイベント又はキーオフイベントである。音源３１１は、生成されたキーオンイベント又はキーオフイベントを基に発音処理又は消音処理を行う。次に、ＣＰＵ３１２は、送信したキーデータＫＥＹをリファレンスデータバッファ３１４に記録する。リファレンスデータバッファ３１４は、キーナンバ毎に最新の送信済みのキーオンイベント又はキーオフイベントを記憶する。すなわち、各キーナンバのキーが現在キーオン又はキーオフのいずれであるのかを知ることができる。また、ＣＰＵ３１２は、所定時間間隔で該所定時間内に送信済みのキーデータがあるか否かを判断し、あるときにはリファレンスデータバッファ３１４内の最新の送信済みの演奏データをリファレンスデータＲＥＦとして送信する。この際、リファレンスデータＲＥＦは、ネットワークデバイス３１５を介してＴＣＰで電子楽器３０２に送信される。
【００２４】
受信側電子楽器３０２は、音源３２１、中央演算処理装置（ＣＰＵ）３２２、メモリ３２３及びネットワークデバイス３２５を有する。メモリ３２３は、キーステータスバッファ３２４を有する。
【００２５】
ＣＰＵ３２２は、ネットワークデバイス３２５を介してキーデータＫＥＹをＵＤＰで電子楽器３０１から受信する。音源３２１は、受信したキーデータ（キーオンイベント又はキーオフイベント）ＫＥＹを基に発音処理又は消音処理を行う。次に、ＣＰＵ３２２は、受信したキーデータＫＥＹをキーステータスバッファ３２４に記録する。キーステータスバッファ３２４は、キーナンバ毎に最新の受信済みのキーオンイベント又はキーオフイベントを記憶する。すなわち、各キーナンバのキーが現在キーオン又はキーオフのいずれであるのかの現在の演奏状態を知ることができる。電子楽器３０２がキーデータＫＥＹを受信成功したときには、そのキーデータＫＥＹがキーステータスバッファ３２４に登録され、受信失敗したときには、そのキーデータＫＥＹはキーステータスバッファ３２４に登録されない。
【００２６】
また、ＣＰＵ３２２は、ネットワークデバイス３２５を介してリファレンスデータＲＥＦをＴＣＰで電子楽器３０１から受信する。次に、ＣＰＵ３２２は、受信したリファレンスデータＲＥＦ及びキーステータスバッファ３２４内の現在の演奏状態を比較し、一致していないときには該受信したリファレンスデータＲＥＦの処理を音源３２１に指示する。音源３２１は、リファレンスデータＲＥＦがキーオンイベントであれば発音処理を行い、キーオフイベントであれば消音処理を行う。この処理により、キーデータＫＥＹが通信欠落した場合でも、リファレンスデータＲＥＦを基にリカバリすることができる。
【００２７】
ＣＰＵ３１２及び３２２は、それぞれメモリ３１３及び３２３内のコンピュータプログラムを読み出して実行することにより上記の処理を行う。すなわち、本実施形態は、コンピュータがプログラムを実行することによって実現することができる。また、プログラムをコンピュータに供給するための手段、例えばかかるプログラムを記録したＣＤ−ＲＯＭ等のコンピュータ読み取り可能な記録媒体又はかかるプログラムを伝送するインターネット等の伝送媒体も本発明の実施形態として適用することができる。また、上記のプログラムを記録したコンピュータ読み取り可能な記録媒体等のコンピュータプログラムプロダクトも本発明の実施形態として適用することができる。上記のプログラム、記録媒体、伝送媒体及びコンピュータプログラムプロダクトは、本発明の範疇に含まれる。記録媒体としては、例えばフレキシブルディスク、ハードディスク、光ディスク、光磁気ディスク、ＣＤ−ＲＯＭ、磁気テープ、不揮発性のメモリカード、ＲＯＭ等を用いることができる。
【００２８】
図４は、送信側電子楽器３０１のメインルーチンの処理を示すフローチャートである。ステップＳ４０１では、キー入力があるか否かをチェックする。すなわち、キーイベント（キーオンイベント又はキーオフイベント）が発生したか否かをチェックする。キーイベントが発生していればステップＳ４０２へ進み、発生していなければステップＳ４０３へ進む。ステップＳ４０２では、キーイベント処理を行う。この処理の詳細は、後に図５を参照しながら説明する。その後、ステップＳ４０３へ進む。
【００２９】
ステップＳ４０３では、所定時間ｔ（図２）が経過したか否かをチェックする。所定時間が経過していればステップＳ４０４へ進み、経過していなければステップＳ４０１へ戻る。ステップＳ４０４では、タイマーイベント処理を行う。この処理の詳細は、後に図７を参照しながら説明する。その後、ステップＳ４０１へ戻り、上記の処理を繰り返す。
【００３０】
図５は、図４のステップＳ４０２のキーイベント処理の詳細を示すフローチャートである。ステップＳ５０１では、上記で発生したキーイベントがキーオンイベントであれば発音処理を行い、キーオフイベントであれば消音処理を行う。次に、ステップＳ５０２では、そのキーイベントをＵＤＰで送信処理する。次に、ステップＳ５０３では、リファレンスデータ管理処理を行う。この処理の詳細は、後に図６を参照しながら説明する。以上で、処理を終了し、図４の処理に戻る。
【００３１】
図６は、図５のステップＳ５０３のリファレンスデータ管理処理の詳細を示すフローチャートである。ステップＳ６０１では、上記の発生したキーイベントに対して、同じキーナンバのキーイベントがリファレンスデータバッファ３１４（図３）内に存在するか否かをチェックする。存在すればステップＳ６０２へ進み、存在しなければステップＳ６０３へ進む。ステップＳ６０２では、リファレンスデータバッファ３１４から同じキーナンバのキーイベントを削除する。その後、ステップＳ６０３へ進む。ステップＳ６０３では、上記の発生した新規キーイベントをリファレンスデータバッファ３１４に追加登録する。これにより、リファレンスデータバッファ３１４にはキーナンバ毎に最新のキーイベントのみが保存される。以上で、処理を終了し、図５の処理に戻る。
【００３２】
図７は、図４のステップＳ４０４のタイマーイベント処理の詳細を示すフローチャートである。ステップＳ７０１では、リファレンスデータバッファ３１４内にリファレンスデータ（キーイベント）が存在するか否かをチェックする。存在する場合にはステップＳ７０２へ進み、存在しない場合には処理を終了して図４の処理に戻る。ステップＳ７０２では、リファレンスデータを信頼性の高いＴＣＰで送信処理する。次に、ステップＳ７０３では、リファレンスデータバッファ３１４をクリアする。すなわち、その送信したリファレンスデータがリファレンスデータバッファ３１４から削除される。以上で、処理を終了し、図４の処理に戻る。
【００３３】
図８は、受信側電子楽器３０２のメインルーチンの処理を示すフローチャートである。ステップＳ８０１では、キーデータＫＥＹ（図３）を受信したか否かをチェックする。キーデータを受信したときにはステップＳ８０２へ進み、受信していないときにはステップＳ８０３へ進む。ステップＳ８０２では、キーデータ受信処理を行う。この処理の詳細は、後に図９を参照しながら説明する。その後、ステップＳ８０３へ進む。
【００３４】
ステップＳ８０３では、リファレンスデータＲＥＦ（図３）を受信したか否かをチェックする。リファレンスデータを受信したときにはステップＳ８０４へ進み、受信していないときにはステップＳ８０１へ戻る。ステップＳ８０４では、リファレンスデータ受信処理を行う。この処理の詳細は、後に図１０を参照しながら説明する。その後、ステップＳ８０１へ戻り、上記の処理を繰り返す。
【００３５】
図９は、図８のステップＳ８０２のキーデータ受信処理の詳細を示すフローチャートである。ステップＳ９０１では、上記の受信したキーデータがキーオンイベントであれば発音処理を行い、キーオフイベントであれば消音処理を行う。次に、ステップＳ９０２では、上記のキーデータを基にキーステータスバッファ３２４内の該当するキーのステータス（キーオン又はキーオフ）を更新する。これにより、キーナンバ毎に現在の演奏状態がキーステータスバッファ３２４に登録される。以上で、処理を終了し、図８の処理に戻る。
【００３６】
図１０は、図８のステップＳ８０４のリファレンスデータ受信処理の詳細を示すフローチャートである。ステップＳ１００１では、上記の受信したリファレンスデータが、キーステータスバッファ３２４内のキーステータスと一致しているか否かをチェックする。一致していれば処理を終了して図８の処理に戻り、一致していなければステップＳ１００２へ進む。ステップＳ１００２では、受信したリファレンスデータがキーオンイベントであれば発音処理を行い、キーオフイベントであれば消音処理を行う。この処理により、キーデータＫＥＹが欠落した場合に、正しい演奏状態に修正することができる。次に、ステップＳ１００３では、キーステータスバッファ３２４内の該当するキーのステータスを更新する。すなわち、リファレンスデータに基づき、現在の演奏状態をキーステータスバッファ３２４に登録する。その後、処理を終了し、図８の処理に戻る。
【００３７】
なお、上記では、演奏データの例としてキーデータの場合を例に説明したが、その他の演奏データであってもよい。演奏データは、ＭＩＤＩ(Musical Instrument Digital Interface)データであることが好ましいが、その他の演奏データであってもよい。また、ＭＩＤＩデータのうち、キーデータが好ましいが、ボリューム等の他のＭＩＤＩデータを同様に処理してもよい。
【００３８】
以上のように、本実施形態によれば、演奏データをＵＤＰの通信プロトコルで通信し、その演奏データの欠落を補正するためのリファレンスデータをＴＣＰの通信プロトコルで通信する。演奏データの他に、リファレンスデータを通信することにより、演奏データが欠落した場合でもその演奏データをリカバリすることができる。ＵＤＰはリアルタイム性が高い通信プロトコルであるので、演奏データをＵＤＰで通信することにより演奏データのリアルタイム通信を保障することができる。また、ＴＣＰはデータ信頼性が高い通信プロトコルであるので、リファレンスデータをＴＣＰで通信することにより、リファレンスデータの信頼性が保障され、ひいては演奏データの信頼性を保障することができる。
【００３９】
なお、上記実施形態は、何れも本発明を実施するにあたっての具体化の例を示したものに過ぎず、これらによって本発明の技術的範囲が限定的に解釈されてはならないものである。すなわち、本発明はその技術思想、またはその主要な特徴から逸脱することなく、様々な形で実施することができる。
【００４０】
【発明の効果】
以上説明したように、演奏データをＵＤＰの通信プロトコルで通信し、リファレンスデータをＴＣＰの通信プロトコルで通信する。演奏データの他に、リファレンスデータを通信することにより、演奏データが欠落した場合でもその演奏データをリカバリすることができる。ＵＤＰはリアルタイム性が高い通信プロトコルであるので、演奏データをＵＤＰで通信することにより演奏データのリアルタイム通信を保障することができる。また、ＴＣＰはデータ信頼性が高い通信プロトコルであるので、リファレンスデータをＴＣＰで通信することにより、リファレンスデータの信頼性が保障され、ひいては演奏データの信頼性を保障することができる。
【図面の簡単な説明】
【図１】図１（Ａ）及び（Ｂ）は本発明の実施形態による演奏データ通信システムの構成例を示す図である。
【図２】本実施形態による演奏データ通信システムの通信方法を示す図である。
【図３】送信側電子楽器及び受信側電子楽器の構成例を示す図である。
【図４】送信側電子楽器のメインルーチンの処理を示すフローチャートである。
【図５】キーイベント処理の詳細を示すフローチャートである。
【図６】リファレンスデータ管理処理の詳細を示すフローチャートである。
【図７】タイマーイベント処理の詳細を示すフローチャートである。
【図８】受信側電子楽器のメインルーチンの処理を示すフローチャートである。
【図９】キーデータ受信処理の詳細を示すフローチャートである。
【図１０】リファレンスデータ受信処理の詳細を示すフローチャートである。
【符号の説明】
１０１，１０２ 電子楽器
１１１ 送信部
１１２ 受信部
１２０ ネットワークサーバー
１２１〜１２３ 電子楽器
３０１ 送信側電子楽器
３０２ 受信側電子楽器
３１１ 音源
３１２ ＣＰＵ
３１３ メモリ
３１４ リファレンスデータバッファ
３１５ ネットワークデバイス
３１６ キーボード
３２１ 音源
３２２ ＣＰＵ
３２３ メモリ
３２４ キーステータスバッファ
３２５ ネットワークデバイス
【発明の属する技術分野】
本発明は、演奏データ通信技術に関する。
【０００２】
【従来の技術】
ネットワークを利用して演奏データを送受信することにより、遠隔地の演奏者同士が合奏を行う、いわゆるネットセッションがある。通信のプロトコルとしてリアルタイム性の高いＵＤＰ(User Datagram Protocol)を利用した場合には、データの信頼性が保障されていないため、演奏データの欠落による鳴りっ放しや音抜けなどの問題を生じることがあった。一方、データの信頼性が保障されているＴＣＰ(Transmission Control Protocol)を利用した場合には、リアルタイムの演奏の送受信を行うことができなくなり、合奏を実現することができない。
【０００３】
また、下記の特許文献１及び２が公開されている。
【０００４】
【特許文献１】
特開平９−２８１９６１号公報
【特許文献２】
特許第３２７１５７２号公報
【０００５】
【発明が解決しようとする課題】
本発明の目的は、演奏データのリアルタイム性及び信頼性を保障する通信技術を提供することである。
【０００６】
【課題を解決するための手段】
本発明の一観点によれば、演奏データをＵＤＰの通信プロトコルで送信する演奏データ送信手段と、前記演奏データの欠落を補正するためのリファレンスデータをＴＣＰの通信プロトコルで送信するリファレンスデータ送信手段とを有し、前記リファレンスデータ送信手段は、所定時間間隔で該所定時間内に送信済みの演奏データがあるときには最新の送信済みの演奏データをリファレンスデータとして送信する演奏データ送信装置が提供される。
本発明の他の観点によれば、演奏データ送信装置及び演奏データ受信装置がネットワークを介して接続される演奏データ通信システムであって、前記演奏データ送信装置は、演奏データをＵＤＰの通信プロトコルで前記演奏データ受信装置へ送信する演奏データ送信手段と、前記演奏データの欠落を補正するためのリファレンスデータをＴＣＰの通信プロトコルで前記演奏データ受信装置へ送信するリファレンスデータ送信手段とを有し、前記演奏データ受信装置は、前記演奏データ送信装置から演奏データをＵＤＰの通信プロトコルで受信する演奏データ受信手段と、前記演奏データ送信装置から前記演奏データの欠落を補正するためのリファレンスデータをＴＣＰの通信プロトコルで受信するリファレンスデータ受信手段と、前記受信した演奏データを基に現在の演奏状態を記憶する演奏状態記憶手段と、前記受信したリファレンスデータ及び前記現在の演奏状態を比較し、一致していないときには該受信したリファレンスデータの処理を行うリファレンスデータ処理手段とを有し、前記リファレンスデータ送信手段は、所定時間間隔で該所定時間内に送信済みの演奏データがあるときには最新の送信済みの演奏データをリファレンスデータとして送信する演奏データ通信システムが提供される。
本発明のさらに他の観点によれば、演奏データをＵＤＰの通信プロトコルで送信する演奏データ送信ステップと、前記演奏データの欠落を補正するためのリファレンスデータをＴＣＰの通信プロトコルで送信するリファレンスデータ送信ステップとを有し、前記リファレンスデータ送信ステップは、所定時間間隔で該所定時間内に送信済みの演奏データがあるときには最新の送信済みの演奏データをリファレンスデータとして送信する演奏データ送信方法が提供される。
本発明のさらに他の観点によれば、演奏データをＵＤＰの通信プロトコルで送信する演奏データ送信ステップと、前記演奏データの欠落を補正するためのリファレンスデータをＴＣＰの通信プロトコルで送信するリファレンスデータ送信ステップとをコンピュータに実行させるためのプログラムであって、前記リファレンスデータ送信ステップは、所定時間間隔で該所定時間内に送信済みの演奏データがあるときには最新の送信済みの演奏データをリファレンスデータとして送信するプログラムが提供される。
【０００７】
本発明によれば、演奏データをＵＤＰの通信プロトコルで通信し、リファレンスデータをＴＣＰの通信プロトコルで通信する。演奏データの他に、リファレンスデータを通信することにより、演奏データが欠落した場合でもその演奏データをリカバリすることができる。ＵＤＰはリアルタイム性が高い通信プロトコルであるので、演奏データをＵＤＰで通信することにより演奏データのリアルタイム通信を保障することができる。また、ＴＣＰはデータ信頼性が高い通信プロトコルであるので、リファレンスデータをＴＣＰで通信することにより、リファレンスデータの信頼性が保障され、ひいては演奏データの信頼性を保障することができる。
【０００８】
【発明の実施の形態】
図１（Ａ）は、本発明の実施形態による演奏データ通信システムの第１の構成例を示す。２個の電子楽器１０１及び１０２は、それぞれ送信部１１１及び受信部１１２を有し、ネットワーク（例えばインターネット）を介して相互に接続される。送信部１１１は演奏データ（ＭＩＤＩデータ）を送信することができ、受信部１１２は演奏データを受信することができる。電子楽器１０１の送信部１１１が演奏データを送信すると、電子楽器１０２の受信部１１２がその演奏データを受信する。逆に、電子楽器１０２の送信部１１１が演奏データを送信すると、電子楽器１０１の受信部１１２がその演奏データを受信する。電子楽器１０１及び１０２は、例えば鍵盤を有する。２人の演奏者がそれぞれ電子楽器１０１及び１０２で演奏すると、自己の電子楽器で楽音を発音すると共に、相手の電子楽器に演奏データを送信して発音させることができる。ネットワークを利用して演奏データを送受信することにより、遠隔地の演奏者同士が合奏を行う、いわゆるネットセッションを行うことができる。
【０００９】
図１（Ｂ）は、本発明の実施形態による演奏データ通信システムの第２の構成例を示す。３個の電子楽器１２１〜１２３は、ネットワークサーバー１２０を介して相互に接続される。３個の電子楽器１２１〜１２３とネットワークサーバー１２０とは、ネットワーク（例えばインターネット）を介して接続される。電子楽器１２１〜１２３は、図１（Ａ）と同様に、それぞれ送信部及び受信部を有し、ネットワークサーバー１２０を介して演奏データの通信を行うことができる。この場合も、遠隔地の演奏者同士が合奏を行うことができる。
【００１０】
図１（Ａ）のように、２人が電子楽器１０１及び１０２で合奏する場合には、電子楽器１０１及び１０２を直接接続して通信を行うことが好ましい。電子楽器１０１及び１０２間を直接接続すると、高速に通信を行うことができる。しかし、３個以上の電子楽器を直接接続すると、各電子楽器がそれぞれ複数の電子楽器に対して通信を行うため負荷が増大する。したがって、図１（Ｂ）のように、３個以上の電子楽器１２１〜１２３で合奏する場合には、ネットワークサーバー１２０を介して３個以上の電子楽器１２１〜１２３を接続して通信を行うことが好ましい。ネットワークサーバー１２０を介して電子楽器１２１〜１２３を接続すると、各電子楽器はネットワークサーバー１２０のみに対して通信すればよいので、各電子楽器の負荷を軽減することができる。
【００１１】
図２は、本実施形態による演奏データ通信システムの通信方法を示す図である。横軸は時間を示す。
まず、送信側の電子楽器の演奏処理手順を説明する。タイミングｔ１にて、鍵盤を押鍵すると、キーオンイベント（キーナンバ（音高）を含む）が発生し、発音処理を行う。次に、タイミングｔ３で、同一のキーナンバの鍵を離鍵すると、キーオフイベント（キーナンバを含む）が発生し、消音処理を行う。次に、タイミングｔ４で、同一のキーナンバの鍵を押鍵すると、キーオンイベントが発生し、発音処理を行う。次に、タイミングｔ７で、同一のキーナンバの鍵を離鍵すると、キーオフイベントが発生し、消音処理を行う。
【００１２】
次に、送信側の電子楽器の演奏データ送信処理手順を説明する。タイミングｔ１でキーオンイベントが発生すると、受信側の電子楽器にそのキーオンイベントを送信する。次に、タイミングｔ３でキーオフイベントが発生すると、受信側の電子楽器にそのキーオフイベントを送信する。次に、タイミングｔ４でキーオンイベントが発生すると、受信側の電子楽器にそのキーオンイベントを送信する。次に、タイミングｔ７でキーオフイベントが発生すると、受信側の電子楽器にそのキーオフイベントを送信する。これらのキーオンイベント及びキーオフイベントは、ＵＤＰ(User Datagram Protocol)の通信プロトコルで送信する。
【００１３】
ＵＤＰは、データの信頼性が保障されていない欠点があるが、データ保障のための通信を行わないため、リアルタイム性が保障される。演奏データ（例えばキーオンイベント及びキーオフイベント）をＵＤＰで送信することにより、演奏データのリアルタイム性を保障することができる。ただし、ＵＤＰはデータ保障されていないので、送信側の電子楽器が送信した演奏データを受信側の電子楽器が受信できずにデータが欠落する場合がある。そこで、本実施形態では、下記に示すリファレンスデータ通信によりデータ保障を行う。
【００１４】
次に、送信側の電子楽器のリファレンスデータ送信処理手順を説明する。リファレンスデータ送信処理は、所定時間ｔ間隔のタイミングｔ２，ｔ５，ｔ６，ｔ８，ｔ９において行う。タイミングｔ２では、その所定時間ｔ前以内に送信済みのキーオンイベント（タイミングｔ１）が存在するので、そのキーオンイベント（タイミングｔ１）をリファレンスデータｒｅｆ２として送信する。受信側の電子楽器が、タイミングｔ１で発生したキーオンイベントを受信した場合には、正常な発音処理を行っているので、リファレンスデータｒｅｆ２の処理を行う必要がない。一方、受信側の電子楽器が、タイミングｔ１で発生したキーオンイベントを受信していない場合には、受信したリファレンスデータｒｅｆ２を基に発音処理をすることによりリカバリすることができる。
【００１５】
次に、タイミングｔ５では、その所定時間ｔ前以内に送信済みのキーイベント（タイミングｔ３及びｔ４）が存在するので、最新の送信済みのキーイベント（タイミングｔ４）をリファレンスデータｒｅｆ５として送信する。受信側の電子楽器が、タイミングｔ４で発生したキーオンイベントを受信していない場合には、受信したリファレンスデータｒｅｆ５を基に発音処理をすることによりリカバリすることができる。この場合、タイミングｔ３及びｔ４のキーイベント（キーオンイベント又はキーオフイベント）のうち、最新の送信済みのキーイベント（タイミングｔ４）をリファレンスデータｒｅｆ５として送信することにより、現在の演奏状態をリカバリすることができる。
【００１６】
次に、タイミングｔ６では、その所定時間ｔ前以内に送信済みのキーイベントが存在しないので、リファレンスデータの送信を行わない。
【００１７】
次に、タイミングｔ８では、その所定時間ｔ前以内に送信済みのキーオフイベント（タイミングｔ７）が存在するので、そのキーオフイベント（タイミングｔ７）をリファレンスデータｒｅｆ８として送信する。受信側の電子楽器が、タイミングｔ７で発生したキーオフイベントを受信していない場合には、受信したリファレンスデータｒｅｆ８を基に消音処理をすることによりリカバリすることができる。
【００１８】
次に、タイミングｔ９では、その所定時間ｔ前以内に送信済みのキーイベントが存在しないので、リファレンスデータの送信を行わない。
【００１９】
上記のリファレンスデータは、ＴＣＰ(Transmission Control Protocol)の通信プロトコルで送信する。ＴＣＰは、データ保障がされているプロトコルであるので、リファレンスデータは確実に送信することができる。したがって、演奏データの通信欠落が生じた場合でも、リファレンスデータ通信により確実にリカバリすることができる。
【００２０】
以上のように、所定時間間隔で該所定時間内に送信済みの演奏データがあるか否かを判断し、あるときには最新の送信済みの演奏データをリファレンスデータとして送信する。また、所定時間間隔で最新の送信済みの演奏データをリファレンスデータとして送信してもよい。
【００２１】
図３は、送信側電子楽器３０１及び受信側電子楽器３０２の構成例を示す。説明の簡単のため、送信側電子楽器３０１及び受信側電子楽器３０２のそれぞれの構成を示しているが、実際の電子楽器は送信側電子楽器３０１及び受信側電子楽器３０２の両方の構成を有する。
【００２２】
送信側電子楽器３０１は、音源３１１、中央演算処理装置（ＣＰＵ）３１２、メモリ３１３、ネットワークデバイス３１５及びキーボード（鍵盤）３１６を有する。メモリ３１３は、リファレンスデータバッファ３１４を有する。
【００２３】
演奏者がキーボード３１６にて押鍵又は離鍵を行うと、ＣＰＵ３１２はそれらを検出してキーオンイベント又はキーオフイベントを生成し、ネットワークデバイス３１５を介してキーデータＫＥＹをＵＤＰで電子楽器３０２に送信する。キーデータＫＥＹは、キーオンイベント又はキーオフイベントである。音源３１１は、生成されたキーオンイベント又はキーオフイベントを基に発音処理又は消音処理を行う。次に、ＣＰＵ３１２は、送信したキーデータＫＥＹをリファレンスデータバッファ３１４に記録する。リファレンスデータバッファ３１４は、キーナンバ毎に最新の送信済みのキーオンイベント又はキーオフイベントを記憶する。すなわち、各キーナンバのキーが現在キーオン又はキーオフのいずれであるのかを知ることができる。また、ＣＰＵ３１２は、所定時間間隔で該所定時間内に送信済みのキーデータがあるか否かを判断し、あるときにはリファレンスデータバッファ３１４内の最新の送信済みの演奏データをリファレンスデータＲＥＦとして送信する。この際、リファレンスデータＲＥＦは、ネットワークデバイス３１５を介してＴＣＰで電子楽器３０２に送信される。
【００２４】
受信側電子楽器３０２は、音源３２１、中央演算処理装置（ＣＰＵ）３２２、メモリ３２３及びネットワークデバイス３２５を有する。メモリ３２３は、キーステータスバッファ３２４を有する。
【００２５】
ＣＰＵ３２２は、ネットワークデバイス３２５を介してキーデータＫＥＹをＵＤＰで電子楽器３０１から受信する。音源３２１は、受信したキーデータ（キーオンイベント又はキーオフイベント）ＫＥＹを基に発音処理又は消音処理を行う。次に、ＣＰＵ３２２は、受信したキーデータＫＥＹをキーステータスバッファ３２４に記録する。キーステータスバッファ３２４は、キーナンバ毎に最新の受信済みのキーオンイベント又はキーオフイベントを記憶する。すなわち、各キーナンバのキーが現在キーオン又はキーオフのいずれであるのかの現在の演奏状態を知ることができる。電子楽器３０２がキーデータＫＥＹを受信成功したときには、そのキーデータＫＥＹがキーステータスバッファ３２４に登録され、受信失敗したときには、そのキーデータＫＥＹはキーステータスバッファ３２４に登録されない。
【００２６】
また、ＣＰＵ３２２は、ネットワークデバイス３２５を介してリファレンスデータＲＥＦをＴＣＰで電子楽器３０１から受信する。次に、ＣＰＵ３２２は、受信したリファレンスデータＲＥＦ及びキーステータスバッファ３２４内の現在の演奏状態を比較し、一致していないときには該受信したリファレンスデータＲＥＦの処理を音源３２１に指示する。音源３２１は、リファレンスデータＲＥＦがキーオンイベントであれば発音処理を行い、キーオフイベントであれば消音処理を行う。この処理により、キーデータＫＥＹが通信欠落した場合でも、リファレンスデータＲＥＦを基にリカバリすることができる。
【００２７】
ＣＰＵ３１２及び３２２は、それぞれメモリ３１３及び３２３内のコンピュータプログラムを読み出して実行することにより上記の処理を行う。すなわち、本実施形態は、コンピュータがプログラムを実行することによって実現することができる。また、プログラムをコンピュータに供給するための手段、例えばかかるプログラムを記録したＣＤ−ＲＯＭ等のコンピュータ読み取り可能な記録媒体又はかかるプログラムを伝送するインターネット等の伝送媒体も本発明の実施形態として適用することができる。また、上記のプログラムを記録したコンピュータ読み取り可能な記録媒体等のコンピュータプログラムプロダクトも本発明の実施形態として適用することができる。上記のプログラム、記録媒体、伝送媒体及びコンピュータプログラムプロダクトは、本発明の範疇に含まれる。記録媒体としては、例えばフレキシブルディスク、ハードディスク、光ディスク、光磁気ディスク、ＣＤ−ＲＯＭ、磁気テープ、不揮発性のメモリカード、ＲＯＭ等を用いることができる。
【００２８】
図４は、送信側電子楽器３０１のメインルーチンの処理を示すフローチャートである。ステップＳ４０１では、キー入力があるか否かをチェックする。すなわち、キーイベント（キーオンイベント又はキーオフイベント）が発生したか否かをチェックする。キーイベントが発生していればステップＳ４０２へ進み、発生していなければステップＳ４０３へ進む。ステップＳ４０２では、キーイベント処理を行う。この処理の詳細は、後に図５を参照しながら説明する。その後、ステップＳ４０３へ進む。
【００２９】
ステップＳ４０３では、所定時間ｔ（図２）が経過したか否かをチェックする。所定時間が経過していればステップＳ４０４へ進み、経過していなければステップＳ４０１へ戻る。ステップＳ４０４では、タイマーイベント処理を行う。この処理の詳細は、後に図７を参照しながら説明する。その後、ステップＳ４０１へ戻り、上記の処理を繰り返す。
【００３０】
図５は、図４のステップＳ４０２のキーイベント処理の詳細を示すフローチャートである。ステップＳ５０１では、上記で発生したキーイベントがキーオンイベントであれば発音処理を行い、キーオフイベントであれば消音処理を行う。次に、ステップＳ５０２では、そのキーイベントをＵＤＰで送信処理する。次に、ステップＳ５０３では、リファレンスデータ管理処理を行う。この処理の詳細は、後に図６を参照しながら説明する。以上で、処理を終了し、図４の処理に戻る。
【００３１】
図６は、図５のステップＳ５０３のリファレンスデータ管理処理の詳細を示すフローチャートである。ステップＳ６０１では、上記の発生したキーイベントに対して、同じキーナンバのキーイベントがリファレンスデータバッファ３１４（図３）内に存在するか否かをチェックする。存在すればステップＳ６０２へ進み、存在しなければステップＳ６０３へ進む。ステップＳ６０２では、リファレンスデータバッファ３１４から同じキーナンバのキーイベントを削除する。その後、ステップＳ６０３へ進む。ステップＳ６０３では、上記の発生した新規キーイベントをリファレンスデータバッファ３１４に追加登録する。これにより、リファレンスデータバッファ３１４にはキーナンバ毎に最新のキーイベントのみが保存される。以上で、処理を終了し、図５の処理に戻る。
【００３２】
図７は、図４のステップＳ４０４のタイマーイベント処理の詳細を示すフローチャートである。ステップＳ７０１では、リファレンスデータバッファ３１４内にリファレンスデータ（キーイベント）が存在するか否かをチェックする。存在する場合にはステップＳ７０２へ進み、存在しない場合には処理を終了して図４の処理に戻る。ステップＳ７０２では、リファレンスデータを信頼性の高いＴＣＰで送信処理する。次に、ステップＳ７０３では、リファレンスデータバッファ３１４をクリアする。すなわち、その送信したリファレンスデータがリファレンスデータバッファ３１４から削除される。以上で、処理を終了し、図４の処理に戻る。
【００３３】
図８は、受信側電子楽器３０２のメインルーチンの処理を示すフローチャートである。ステップＳ８０１では、キーデータＫＥＹ（図３）を受信したか否かをチェックする。キーデータを受信したときにはステップＳ８０２へ進み、受信していないときにはステップＳ８０３へ進む。ステップＳ８０２では、キーデータ受信処理を行う。この処理の詳細は、後に図９を参照しながら説明する。その後、ステップＳ８０３へ進む。
【００３４】
ステップＳ８０３では、リファレンスデータＲＥＦ（図３）を受信したか否かをチェックする。リファレンスデータを受信したときにはステップＳ８０４へ進み、受信していないときにはステップＳ８０１へ戻る。ステップＳ８０４では、リファレンスデータ受信処理を行う。この処理の詳細は、後に図１０を参照しながら説明する。その後、ステップＳ８０１へ戻り、上記の処理を繰り返す。
【００３５】
図９は、図８のステップＳ８０２のキーデータ受信処理の詳細を示すフローチャートである。ステップＳ９０１では、上記の受信したキーデータがキーオンイベントであれば発音処理を行い、キーオフイベントであれば消音処理を行う。次に、ステップＳ９０２では、上記のキーデータを基にキーステータスバッファ３２４内の該当するキーのステータス（キーオン又はキーオフ）を更新する。これにより、キーナンバ毎に現在の演奏状態がキーステータスバッファ３２４に登録される。以上で、処理を終了し、図８の処理に戻る。
【００３６】
図１０は、図８のステップＳ８０４のリファレンスデータ受信処理の詳細を示すフローチャートである。ステップＳ１００１では、上記の受信したリファレンスデータが、キーステータスバッファ３２４内のキーステータスと一致しているか否かをチェックする。一致していれば処理を終了して図８の処理に戻り、一致していなければステップＳ１００２へ進む。ステップＳ１００２では、受信したリファレンスデータがキーオンイベントであれば発音処理を行い、キーオフイベントであれば消音処理を行う。この処理により、キーデータＫＥＹが欠落した場合に、正しい演奏状態に修正することができる。次に、ステップＳ１００３では、キーステータスバッファ３２４内の該当するキーのステータスを更新する。すなわち、リファレンスデータに基づき、現在の演奏状態をキーステータスバッファ３２４に登録する。その後、処理を終了し、図８の処理に戻る。
【００３７】
なお、上記では、演奏データの例としてキーデータの場合を例に説明したが、その他の演奏データであってもよい。演奏データは、ＭＩＤＩ(Musical Instrument Digital Interface)データであることが好ましいが、その他の演奏データであってもよい。また、ＭＩＤＩデータのうち、キーデータが好ましいが、ボリューム等の他のＭＩＤＩデータを同様に処理してもよい。
【００３８】
以上のように、本実施形態によれば、演奏データをＵＤＰの通信プロトコルで通信し、その演奏データの欠落を補正するためのリファレンスデータをＴＣＰの通信プロトコルで通信する。演奏データの他に、リファレンスデータを通信することにより、演奏データが欠落した場合でもその演奏データをリカバリすることができる。ＵＤＰはリアルタイム性が高い通信プロトコルであるので、演奏データをＵＤＰで通信することにより演奏データのリアルタイム通信を保障することができる。また、ＴＣＰはデータ信頼性が高い通信プロトコルであるので、リファレンスデータをＴＣＰで通信することにより、リファレンスデータの信頼性が保障され、ひいては演奏データの信頼性を保障することができる。
【００３９】
なお、上記実施形態は、何れも本発明を実施するにあたっての具体化の例を示したものに過ぎず、これらによって本発明の技術的範囲が限定的に解釈されてはならないものである。すなわち、本発明はその技術思想、またはその主要な特徴から逸脱することなく、様々な形で実施することができる。
【００４０】
【発明の効果】
以上説明したように、演奏データをＵＤＰの通信プロトコルで通信し、リファレンスデータをＴＣＰの通信プロトコルで通信する。演奏データの他に、リファレンスデータを通信することにより、演奏データが欠落した場合でもその演奏データをリカバリすることができる。ＵＤＰはリアルタイム性が高い通信プロトコルであるので、演奏データをＵＤＰで通信することにより演奏データのリアルタイム通信を保障することができる。また、ＴＣＰはデータ信頼性が高い通信プロトコルであるので、リファレンスデータをＴＣＰで通信することにより、リファレンスデータの信頼性が保障され、ひいては演奏データの信頼性を保障することができる。
【図面の簡単な説明】
【図１】図１（Ａ）及び（Ｂ）は本発明の実施形態による演奏データ通信システムの構成例を示す図である。
【図２】本実施形態による演奏データ通信システムの通信方法を示す図である。
【図３】送信側電子楽器及び受信側電子楽器の構成例を示す図である。
【図４】送信側電子楽器のメインルーチンの処理を示すフローチャートである。
【図５】キーイベント処理の詳細を示すフローチャートである。
【図６】リファレンスデータ管理処理の詳細を示すフローチャートである。
【図７】タイマーイベント処理の詳細を示すフローチャートである。
【図８】受信側電子楽器のメインルーチンの処理を示すフローチャートである。
【図９】キーデータ受信処理の詳細を示すフローチャートである。
【図１０】リファレンスデータ受信処理の詳細を示すフローチャートである。
【符号の説明】
１０１，１０２ 電子楽器
１１１ 送信部
１１２ 受信部
１２０ ネットワークサーバー
１２１〜１２３ 電子楽器
３０１ 送信側電子楽器
３０２ 受信側電子楽器
３１１ 音源
３１２ ＣＰＵ
３１３ メモリ
３１４ リファレンスデータバッファ
３１５ ネットワークデバイス
３１６ キーボード
３２１ 音源
３２２ ＣＰＵ
３２３ メモリ
３２４ キーステータスバッファ
３２５ ネットワークデバイス
Claims (8)
- 演奏データをＵＤＰの通信プロトコルで送信する演奏データ送信手段と、
前記演奏データの欠落を補正するためのリファレンスデータをＴＣＰの通信プロトコルで送信するリファレンスデータ送信手段とを有し、
前記リファレンスデータ送信手段は、所定時間間隔で該所定時間内に送信済みの演奏データがあるときには最新の送信済みの演奏データをリファレンスデータとして送信する演奏データ送信装置。 - 前記演奏データは、ＭＩＤＩデータである請求項１記載の演奏データ送信装置。
- 前記ＭＩＤＩデータは、キーデータである請求項２記載の演奏データ送信装置。
- 演奏データ送信装置及び演奏データ受信装置がネットワークを介して接続される演奏データ通信システムであって、
前記演奏データ送信装置は、
演奏データをＵＤＰの通信プロトコルで前記演奏データ受信装置へ送信する演奏データ送信手段と、
前記演奏データの欠落を補正するためのリファレンスデータをＴＣＰの通信プロトコルで前記演奏データ受信装置へ送信するリファレンスデータ送信手段とを有し、
前記演奏データ受信装置は、
前記演奏データ送信装置から演奏データをＵＤＰの通信プロトコルで受信する演奏データ受信手段と、
前記演奏データ送信装置から前記演奏データの欠落を補正するためのリファレンスデータをＴＣＰの通信プロトコルで受信するリファレンスデータ受信手段と、
前記受信した演奏データを基に現在の演奏状態を記憶する演奏状態記憶手段と、
前記受信したリファレンスデータ及び前記現在の演奏状態を比較し、一致していないときには該受信したリファレンスデータの処理を行うリファレンスデータ処理手段とを有し、
前記リファレンスデータ送信手段は、所定時間間隔で該所定時間内に送信済みの演奏データがあるときには最新の送信済みの演奏データをリファレンスデータとして送信する演奏データ通信システム。 - 前記演奏データは、ＭＩＤＩデータである請求項４記載の演奏データ通信システム。
- 前記ＭＩＤＩデータは、キーデータである請求項５記載の演奏データ通信システム。
- 演奏データをＵＤＰの通信プロトコルで送信する演奏データ送信ステップと、
前記演奏データの欠落を補正するためのリファレンスデータをＴＣＰの通信プロトコルで送信するリファレンスデータ送信ステップとを有し、
前記リファレンスデータ送信ステップは、所定時間間隔で該所定時間内に送信済みの演奏データがあるときには最新の送信済みの演奏データをリファレンスデータとして送信する演奏データ送信方法。 - 演奏データをＵＤＰの通信プロトコルで送信する演奏データ送信ステップと、
前記演奏データの欠落を補正するためのリファレンスデータをＴＣＰの通信プロトコルで送信するリファレンスデータ送信ステップとをコンピュータに実行させるためのプログラムであって、
前記リファレンスデータ送信ステップは、所定時間間隔で該所定時間内に送信済みの演奏データがあるときには最新の送信済みの演奏データをリファレンスデータとして送信するプログラム。
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2003088338A JP4090925B2 (ja) | 2003-03-27 | 2003-03-27 | 演奏データ送信装置、通信システム、送信方法及びプログラム |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2003088338A JP4090925B2 (ja) | 2003-03-27 | 2003-03-27 | 演奏データ送信装置、通信システム、送信方法及びプログラム |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| JP2004294868A JP2004294868A (ja) | 2004-10-21 |
| JP4090925B2 true JP4090925B2 (ja) | 2008-05-28 |
Family
ID=33402496
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP2003088338A Expired - Lifetime JP4090925B2 (ja) | 2003-03-27 | 2003-03-27 | 演奏データ送信装置、通信システム、送信方法及びプログラム |
Country Status (1)
| Country | Link |
|---|---|
| JP (1) | JP4090925B2 (ja) |
Families Citing this family (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| KR100734247B1 (ko) | 2007-03-12 | 2007-07-02 | 주식회사 셀런 | 유디피를 이용한 에프티피 전송 방법 |
-
2003
- 2003-03-27 JP JP2003088338A patent/JP4090925B2/ja not_active Expired - Lifetime
Also Published As
| Publication number | Publication date |
|---|---|
| JP2004294868A (ja) | 2004-10-21 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| JP3242028B2 (ja) | データ送受信方法およびシステム | |
| US7396993B2 (en) | Transmission of MIDI using TCP and UDP | |
| US20040154460A1 (en) | Method and apparatus for enabling music error recovery over lossy channels | |
| JP2009535988A (ja) | データ信号を処理するシステム及び方法 | |
| JP3493737B2 (ja) | 送信ノードおよび受信ノード | |
| US6627807B2 (en) | Communications apparatus for tone generator setting information | |
| US7254644B2 (en) | Communication method and system for transmission and reception of packets collecting sporadically input data | |
| JP4090925B2 (ja) | 演奏データ送信装置、通信システム、送信方法及びプログラム | |
| US7977559B2 (en) | Tone generation system controlling the music system | |
| JP2009127375A (ja) | 認証システム、認証装置、及び、認証装置のプログラム | |
| US6525253B1 (en) | Transmission of musical tone information | |
| JP2022552893A (ja) | ワイヤレスｍｉｄｉヘッドセット | |
| JP3196681B2 (ja) | 通信データ一時記憶装置 | |
| JP2004094683A (ja) | サーバ、通信方法及び観客端末 | |
| JP2002062884A (ja) | データ送受信方法、送受信端末、およびデータ送受信方法に係るプログラムを記憶した記憶媒体 | |
| JP4035076B2 (ja) | データ処理装置及び方法 | |
| JP4626429B2 (ja) | Ｍｉｄｉデータ送信装置及びプログラム | |
| JP4200996B2 (ja) | 楽音発生システムにおける処理装置 | |
| JP2005292655A (ja) | 電子楽器演奏システム | |
| JP3658661B2 (ja) | データ受信装置、及びデータ送信装置 | |
| JPH10240242A (ja) | 楽音情報の通信方法、通信装置及びプログラムを記録した媒体 | |
| Mandrekar et al. | An Audio Stream Redirector for the Internet Speaker | |
| JP4506063B2 (ja) | 楽曲情報配信装置および楽曲情報を配信するためのプログラム | |
| JP2011209506A (ja) | カラオケ端末 | |
| JP6492754B2 (ja) | 楽器及び楽器システム |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| A621 | Written request for application examination |
Free format text: JAPANESE INTERMEDIATE CODE: A621 Effective date: 20060120 |
|
| A977 | Report on retrieval |
Free format text: JAPANESE INTERMEDIATE CODE: A971007 Effective date: 20071003 |
|
| A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20071009 |
|
| A521 | Written amendment |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20071207 |
|
| TRDD | Decision of grant or rejection written | ||
| A01 | Written decision to grant a patent or to grant a registration (utility model) |
Free format text: JAPANESE INTERMEDIATE CODE: A01 Effective date: 20080219 |
|
| A61 | First payment of annual fees (during grant procedure) |
Free format text: JAPANESE INTERMEDIATE CODE: A61 Effective date: 20080227 |
|
| R150 | Certificate of patent (=grant) or registration of utility model |
Free format text: JAPANESE INTERMEDIATE CODE: R150 |
|
| FPAY | Renewal fee payment (prs date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20110307 Year of fee payment: 3 |
|
| FPAY | Renewal fee payment (prs date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20120307 Year of fee payment: 4 |
|
| FPAY | Renewal fee payment (prs date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20120307 Year of fee payment: 4 |
|
| FPAY | Renewal fee payment (prs date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20130307 Year of fee payment: 5 |