米国特許情報 | 欧州特許情報 | 国際公開(PCT)情報 | Google の米国特許検索
 
     特許分類
A 農業
B 衣類
C 家具
D 医学
E スポ−ツ;娯楽
F 加工処理操作
G 机上付属具
H 装飾
I 車両
J 包装;運搬
L 化学;冶金
M 繊維;紙;印刷
N 固定構造物
O 機械工学
P 武器
Q 照明
R 測定; 光学
S 写真;映画
T 計算機;電気通信
U 核技術
V 電気素子
W 発電
X 楽器;音響


  ホーム -> 楽器;音響 -> カシオ計算機株式会社

発明の名称 合奏実現方法、ネット合奏システム、及びプログラム
発行国 日本国特許庁(JP)
公報種別 公開特許公報(A)
公開番号 特開2007−41174(P2007−41174A)
公開日 平成19年2月15日(2007.2.15)
出願番号 特願2005−223621(P2005−223621)
出願日 平成17年8月2日(2005.8.2)
代理人 【識別番号】100074099
【弁理士】
【氏名又は名称】大菅 義之
発明者 南高 純一 / 副島 淳一郎
要約 課題
ネットワークを利用して合奏の効率的な練習を行えるように支援するための技術を提供する。

解決手段
演奏者A〜Cの3人のメンバーによる合奏を仮想的に実現させる場合、その合奏は3段階でそれぞれ行う演奏によって実現させる。第1段階で演奏者Aが演奏を行って得られる演奏情報は、その次の第2段階の演奏を行う演奏者Bに送り、演奏者Aの演奏を聴きながら演奏を行える環境を提供する。最終の第3段階で演奏を行う演奏者Cには、演奏者Bから、自身の演奏による演奏情報と併せて、演奏者Aの演奏による演奏情報を送ることにより、演奏者A、Bの演奏を聴きながら演奏を行える環境を提供する。そのようにして、各段階の演奏者には、より上流の段階に位置する演奏者の演奏を聴きながらの合奏を行える環境を提供する。
特許請求の範囲
【請求項1】
ネットワークを利用して複数の演奏者による合奏を仮想的に可能とさせるための方法であって、
前記合奏を所望する演奏者毎に、該合奏のために演奏者が行った演奏内容を示す演奏情報を送信すべき他の演奏者を送信対象者として予め設定し、
前記設定により前記送信対象者が存在する演奏者が使用するそれぞれの端末装置に、該演奏者自身の演奏による演奏情報を前記ネットワーク上に送信させ、
前記設定により、前記送信対象者、及び自身を該送信対象者とする他の演奏者が共に存在する演奏者が使用するそれぞれの端末装置に、該他の演奏者の使用する端末装置から送信されて受信される演奏情報を更に前記ネットワーク上に送信させ、
前記送信対象者である各演奏者に、前記端末装置が受信する演奏情報による一人以上の演奏者の演奏と合わせた演奏をそれぞれ行わせて前記合奏を仮想的に実現させる、
ことを特徴とする合奏実現方法。
【請求項2】
ネットワークを介して接続される端末装置のユーザーを対象に合奏を仮想的に実現させるシステムであって、
前記ネットワークを介して、前記ユーザーが楽器に対して行なった演奏内容を示す演奏情報をリアルタイムに前記端末装置から受信する情報受信手段と、
複数のユーザーが合奏を行う場合に、該複数のユーザー間で予め設定される演奏情報を送受信すべき関係に従って、前記情報受信手段が受信した演奏情報を、該演奏情報を送信させた端末装置のユーザーによって特定されるユーザーの使用する端末装置に必要に応じて送信する情報送信手段と、
を具備することを特徴とするネット合奏システム。
【請求項3】
前記合奏のための演奏をユーザーが行っている端末装置から前記情報受信手段が受信する演奏情報を保存する情報保存手段、
を更に具備することを特徴とする請求項2記載のネット合奏システム。
【請求項4】
ネットワークを介して接続される端末装置のユーザーを対象に合奏を仮想的に実現させるネット合奏システムの構築に用いられるデータ処理装置に実行させるプログラムであって、
前記ネットワークを介して、前記ユーザーが楽器に対して行なった演奏内容を示す演奏情報をリアルタイムに前記端末装置から受信する機能と、
複数のユーザーが合奏を行う場合に、該複数のユーザー間で予め設定される演奏情報を送受信すべき関係に従って、前記受信する機能により受信した演奏情報を、該演奏情報を送信させた端末装置のユーザーによって特定されるユーザーの使用する端末装置に必要に応じて送信する機能と、
を実現させるためのプログラム。
発明の詳細な説明
【技術分野】
【0001】
本発明は、ネットワークを利用して複数の演奏者による合奏を仮想的に可能とさせるための技術に関する。
【背景技術】
【0002】
2つ以上の楽器によって行われる合奏は、一人で演奏するときとは異なる楽しさや充実感を味わうことができ、多くの人に楽しまれている。その合奏では、それを行う全てのメンバー(演奏者)が同じ場所に集まることが望まれる。しかし、それは個々のメンバーの都合や、時間的、或いは地理的な事情によって困難なことも少なくないのが実情である。このようなことから、例えば特許文献1に記載されているように、合奏を行う音楽活動を支援できるものが創案されている。
【0003】
特許文献1に記載された従来のネット合奏システムでは、ネットワークを介して、各メンバーが行った演奏内容を示す演奏情報をそれぞれ取得し、それらを対応付けて記録するようにしている。それにより、各メンバーがそれぞれ行った演奏を合奏の結果として確認できるようにしている。特許文献2には、音楽的な不具合の発生を回避できるように、ネットワークを介して演奏情報を送信する技術が記載されている。
【0004】
その従来のネット合奏システムでは、演奏開始を知らせることにより、各メンバーにそれぞれ並行して演奏を行わせるようになっている。そのために、各メンバーは基本的にそれぞれ自身の考えに沿った演奏を行っていた。
【0005】
周知のように、合奏では全体的なまとまりを考慮する必要がある。そのまとまり感は、各メンバーがそれぞれ自身の考えに沿った演奏(独奏)を行っては得にくいのが実情である。合奏結果を確認することにより、各メンバーはまとまり感を考慮した演奏を行うことができる。しかし、そのためには、合奏結果の確認を随時、行わなければならないことから、演奏(合奏のための演奏)に割り当てられる時間はより短くなる。他のメンバーによる演奏内容を正確に把握するには何度も合奏結果を確認しなければならないのが普通であるから、他のメンバーによる演奏に合った演奏を行えるようになるには通常(同じ場所に集まっての合奏)よりも非常に時間がかかることになる。
【0006】
上記のようなことから、特許文献1に記載された従来のネット合奏システムでは、所望の合奏を実現できるように効率的な練習を行うことは困難となっていた。考え方や感性は演奏者によって異なるのが普通であり、まとまり感のある合奏を行えるようにするには、数多く合奏の練習をしなければならないのが実情である。このことから、合奏の効率的な練習を行えるようにすることも極めて重要なことであると考えられる。
【特許文献1】特開2004−212632号公報
【特許文献2】特開2000−181447号公報
【発明の開示】
【発明が解決しようとする課題】
【0007】
本発明の課題は、ネットワークを利用して合奏の効率的な練習を行えるように支援するための技術を提供することにある。
【課題を解決するための手段】
【0008】
本発明の合奏実現方法は、ネットワークを利用して複数の演奏者による合奏を仮想的に可能とさせるための方法であって、合奏を所望する演奏者毎に、該合奏のために演奏者が行った演奏内容を示す演奏情報を送信すべき他の演奏者を送信対象者として予め設定し、設定により送信対象者が存在する演奏者が使用するそれぞれの端末装置に、該演奏者自身の演奏による演奏情報をネットワーク上に送信させ、設定により、送信対象者、及び自身を該送信対象者とする他の演奏者が共に存在する演奏者が使用するそれぞれの端末装置に、該他の演奏者の使用する端末装置から送信されて受信される演奏情報を更にネットワーク上に送信させ、送信対象者である各演奏者に、端末装置が受信する演奏情報による一人以上の演奏者の演奏と合わせた演奏をそれぞれ行わせて合奏を仮想的に実現させる。
【0009】
本発明の第1の態様のネット合奏システムは、ネットワークを介して接続される端末装置のユーザーを対象に合奏を仮想的に実現させるシステムであって、ネットワークを介して、ユーザーが楽器に対して行なった演奏内容を示す演奏情報をリアルタイムに端末装置から受信する情報受信手段と、複数のユーザーが合奏を行う場合に、該複数のユーザー間で予め設定される演奏情報を送受信すべき関係に従って、情報受信手段が受信した演奏情報を、該演奏情報を送信させた端末装置のユーザーによって特定されるユーザーの使用する端末装置に必要に応じて送信する情報送信手段と、を具備する。
【0010】
本発明の第2の態様のネット合奏システムは、上記第1の態様における構成に加えて、合奏のための演奏をユーザーが行っている端末装置から情報受信手段が受信する演奏情報を保存する情報保存手段、を更に具備する。
【0011】
本発明のプログラムは、ネットワークを介して接続される端末装置のユーザーを対象に合奏を仮想的に実現させるネット合奏システムの構築に用いられるデータ処理装置に実行させることを前提とし、ネットワークを介して、ユーザーが楽器に対して行なった演奏内容を示す演奏情報をリアルタイムに端末装置から受信する機能と、複数のユーザーが合奏を行う場合に、該複数のユーザー間で予め設定される演奏情報を送受信すべき関係に従って、受信する機能により受信した演奏情報を、該演奏情報を送信させた端末装置のユーザーによって特定されるユーザーの使用する端末装置に必要に応じて送信する機能と、を実現させる。
【発明の効果】
【0012】
本発明は、合奏を所望する演奏者毎に、その合奏のために演奏者が行った演奏内容を示す演奏情報を送信すべき他の演奏者を送信対象者として予め設定し、その送信対象者が存在する演奏者が使用するそれぞれの端末装置に、自身の演奏による演奏情報をネットワーク上に送信させ、送信対象者、及び自身を送信対象者とする他の演奏者が共に存在する演奏者が使用するそれぞれの端末装置に、その他の演奏者の使用する端末装置から送信されて受信される演奏情報を更にネットワーク上に送信させる。
【0013】
そのような演奏情報の送受信を行うことにより、送信対象者である各演奏者には、ネットワークを介して、他の一人以上の演奏者の演奏によって得られる演奏情報が送られる。このため、送られる演奏情報によって再生可能な他の一人以上の演奏者の演奏と合わせた演奏を行える環境が提供される。その環境の提供により、送信対象者である演奏者は他の演奏者との合奏を実質的に行える形となる。その結果、よりまとまり感の得られる演奏、或いは全体としてより所望の音楽表現が実現される演奏がより容易となる。
【0014】
それは、合奏上、より望ましい演奏をより容易に行えるようになることを意味する。このことから、他の演奏者の演奏を聴かないで合奏の練習(演奏)を行う場合と比較して、より質の高い練習を行えるようになる。より多くの演奏者が合奏上、より質の高い演奏を行えるようになるから、合奏結果の確認もより容易、且つより短い時間で行えるようになる。それらは何れもより効率的な練習を行えるように作用する。
【発明を実施するための最良の形態】
【0015】
以下、本発明の実施の形態について、図面を参照しながら詳細に説明する。
図1は、本実施の形態によるネット合奏システムを用いて構築されたネットワークシステムの構成を説明する図である。
【0016】
そのネットワークシステムは、図1に示すように、ネットワーク1に対し、サーバー2、各視聴者がそれぞれ使用する端末装置である複数のパーソナルコンピュータ(PC)3、及び各演奏者がそれぞれ使用する端末装置である複数のPC4、が接続されて構築されている。
【0017】
上記ネットワーク1は、例えばインターネット、及びPC3、或いは4をインターネットと接続する公衆網を含むものである。演奏者用のPC4にはそれぞれ、そのユーザーが演奏を行う電子楽器5が接続されている。そのPC4は、電子楽器5への演奏操作の内容を示す演奏情報をサーバー2に送信する。そのサーバー2は、PC4から送信された演奏情報を受信し、他のPC4、或いはPC3に必要に応じて自動的に送信するサービスを提供する。そのサービスにより、PC3のユーザーはPC4のユーザーによる演奏を視聴できるようになっている。本実施の形態によるネット合奏システムは、そのサーバー2上に実現されている。
【0018】
図2は、上記サーバー2の構成を説明する図である。図2に示すように、サーバー2は、全体の制御を行うCPU21と、そのCPU21がワークに用いるRAM22と、電源投入時に実行される起動用のプログラム等を格納したROM23と、ネットワーク1を介した通信を行うためのネットワークインターフェース24と、例えばキーボードやポインティングデバイス(マウス等)、CD−ROMやDVD等の記録媒体にアクセスする媒体駆動装置、及びそれらのインターフェース等からなる入力装置25と、表示装置に画像を表示させる表示部26と、例えばハードディスク装置である補助記憶装置27と、それら各部21〜27を互いに接続するバス28と、を備えた構成となっている。
【0019】
電源が投入されると、CPU21はROM23に格納された起動用のプログラム読み出して実行することにより、その制御によって補助記憶装置27にアクセスする。そのアクセスにより、補助記憶装置27に格納されたOS(オペレーティングシステム)を読み出し、そのOSに制御を移す。それ以降は、OS上で動作するアプリケーション・プログラム(以降「アプリケーション」と略記)を実行する。上記サービスは、対応するアプリケーションを実行することで実現される。
【0020】
図3は、上記PC4、及び電子楽器5の構成を説明する図である。
そのPC4は、図3に示すように、CPU41、RAM42、ROM43、ネットワークインターフェース44、入力装置45、表示部46、MIDIインターフェース(I/F)47、補助記憶装置48、及びバス49を備えた構成となっている。それにより、上記サーバー2と殆ど同じ構成となっている。サーバー2に存在しないMIDI I/F47は、電子楽器5とMIDIデータの送受信を行うためのものである。
【0021】
その電子楽器5は、図3に示すように、PC4とMIDIデータの送受信を行うためのMIDI I/F51と、演奏操作の対象となるキーボード52と、放音すべき楽音の波形データを生成して放音する音源・サウンドシステム(以降「音源システム」と略記)53と、を備えた構成となっている。
【0022】
電子楽器5のキーボード52は、例えばユーザーの鍵への操作を検出し、操作を検出した鍵、及びその操作内容を示す操作情報をMIDI I/F51に出力する。そのI/F51は、例えばその操作情報に対応するMIDIデータを生成して音源システム53、及びPC4のMIDI I/F47にそれぞれ出力する。そのI/F47から入力したMIDIデータも音源システム53に出力する。それにより、ユーザーのキーボード52に対する演奏操作に応じた楽音の放音、及びPC4から出力されたMIDIデータによる楽音の放音を行わせるようになっている。このことから、PC4とそれに接続された電子楽器5は、ネットワーク5を介し、ユーザーが電子楽器5に対して行った演奏内容を示す演奏情報を送受信できる演奏者用システムを構成している。本実施の形態では、その演奏情報としてMIDIデータを採用している。
【0023】
他方のPC3は、PC4の構成と同じか、或いは音源システム53に相当するシステムを搭載しているものである。ここでは説明上、便宜的に、図3に示す構成において、MIDI I/F47の代わりに音源システム53を搭載していると想定する。その想定により、構成要素の符号としてPC4のそれを用いることにする。
【0024】
PC3、4は、電源が投入されると、CPU41はROM43に格納された起動用のプログラム読み出して実行することにより、その制御によって補助記憶装置48にアクセスする。そのアクセスにより、補助記憶装置48に格納されたOS(オペレーティングシステム)を読み出し、そのOSに制御を移す。それ以降は、入力装置45を介したユーザーの指示に応じた制御を行う。OS上で動作するアプリケーション・プログラム(以降「アプリケーション」と略記)の起動/終了は、その制御によって実現される。
【0025】
図4は、仮想的な合奏の実現方法を説明する図である。その実現方法は、演奏者A〜Cの3人のメンバーによる合奏を仮想的に実現させる場合のものである。
本実施の形態では、図4に示すように、演奏者A〜Cの3人のメンバーによる仮想的な合奏は3段階でそれぞれ行う演奏によって実現させるようにしている。第1段階で演奏者Aが演奏を行って得られる演奏情報は、その次の第2段階の演奏を行う演奏者Bに送ることにより、その演奏を聴きながら演奏を行える環境(演奏者Aとの合奏を行える環境)を演奏者Bに提供する。最終の第3段階で演奏を行う演奏者Cには、演奏者Bから、自身の演奏による演奏情報と共に、演奏者Aの演奏による演奏情報を送ることにより、演奏者A、Bの演奏を聴きながら演奏を行える環境(演奏者A、Bとの合奏を行える環境)を演奏者Cに提供する。その第3段階で演奏者Cが演奏を行うことにより、全ての演奏者A〜Cによる合奏の最終結果が得られる。視聴者Dは、その結果として得られる、各演奏者A〜Cの演奏による演奏情報が送られる人であり、演奏者A〜Cの何れも視聴者Dとなることができる。
【0026】
このようにして、本実施の形態では、各演奏段階で演奏を行う演奏者に対し、それよりも上流に位置する演奏段階で行われた演奏による演奏情報を提供することにより、第1段階(最上流の演奏段階)で演奏を行う演奏者A以外は、それよりも上流の演奏段階で行われた演奏を聴きながら、その演奏に合わせた演奏(合奏)を行えるようにさせている。このため、第1段階以外の演奏段階の演奏者にとっては、全体としてまとまり感のある(所望の音楽表現が実現されている)合奏結果が得られるような演奏、つまり合奏のためのより適切な演奏を容易に行うことができるようになる。それにより、合奏のための演奏はより効率的に練習できることとなる。
【0027】
第1段階以外の演奏段階の演奏者が合奏上、より質の高い演奏を行えるようになると、合奏上、望ましくない演奏方法や演奏箇所はより少なくなる。このため、合奏結果の確認もより容易に行えるようになって、その確認に必要な時間はより短縮させることができる。このことからも、より効率的な練習を行えることとなる。
【0028】
第1段階の演奏者Aは、その演奏を聴きながら他の演奏者が演奏を行うことから、他の演奏者が合わせるべき演奏を行う者、合奏曲のベースとなる演奏を行う者、或いは最も演奏の上手な者、とすることが望ましい。そのような者を演奏者Aとすることにより、より望ましい合奏結果がより容易に得られるようになる。
【0029】
なお、本実施の形態では、各演奏段階の演奏者を一人のみとしているが、第1段階以外の演奏段階の演奏者は複数であっても良い。その場合、複数の演奏者全てに同じ種類の楽器、或いはパートを演奏させる必要はない。演奏段階数は、2つ以上であればあれば良く、合奏曲、演奏者数、及び演奏するパート数等を考慮して適宜、決定すれば良い。ネットワーク1上に送信される演奏情報はその送信元(演奏者)が明らかとなっているので、何れの演奏段階に複数の演奏者が存在していても、演奏者毎にその演奏情報をまとめることができる。
【0030】
演奏段階に分けて各演奏者に演奏を行わせる場合、各演奏者に演奏情報を送るべき相手、その演奏者から演奏情報を送るべき相手はその演奏者の演奏段階に応じて自動的に特定することができる。このことから本実施の形態では、図4に示すような実現方法を採用しているが、演奏者に演奏情報を送信すべき他の演奏者を演奏者毎に個別に設定するようにしても良い。演奏情報を送信する流れのパターン(例えば演奏位置と演奏情報が送受信される演奏位置の関係を示すもの)を幾つか用意し、そのパターン上で各演奏者の演奏位置を指定するようにしても良い。当然のことながら、別の方法を採用しても良い。
【0031】
図4に示すような合奏は、サーバー2、PC4(PC3)のCPU21、41がそれぞれ専用のアプリケーションを実行することで実現される。以降は、図5〜図16の説明図を参照して、サーバー2、PC4別に、合奏を実現させるための動作について詳細に説明する。
【0032】
サーバー2は、PC4間に入って図4に示すような演奏情報の送受信を実現させるサービス(合奏サービス)を提供する。PC3のユーザー(視聴者D)に対しては、合奏結果として保存した演奏情報を提供するサービス(視聴サービス)を行う。それらのサービスを提供するために、図5に示すようなデータを管理している。図5(a)はサービスを提供するPC3、4のユーザーを管理するためのユーザーデータベース(DB)のデータ構成を示し、図5(b)はPC4間のデータの送受信用のリングバッファの構成を示している。
【0033】
図5(a)に示すように、ユーザーDBには、ユーザー毎に、データiFD、cUserID、cStat、及びcUserModeが格納されている。データiFDは、ユーザー毎に異なる通信識別用番号であり、PC3、4は送信するデータにそれを付加するようになっている。データcUserIDはユーザーID、データcStatは対応するユーザーが接続(ログオン)状態か否かを管理するためのデータ、データcUserModeは対応するユーザーのモードを管理するためのデータである。そのユーザーモードとしては、ここでは演奏者A〜C、及び視聴者Dのみを考慮することとする。
【0034】
上記リングバッファは、図5(b)に示すように、「buffer」を表記した部分(以降「データバッファ」と呼ぶ)、「iSize」を表記した部分(以降「サイズバッファ」と呼ぶ)、及び「iUDBid」を表記した部分(以降「ユーザーバッファ」と呼ぶ)の3つの部分から構成されている。データバッファにはPC4から受信したデータの本体(実体)が格納される。サイズバッファには、データバッファに格納されたデータのサイズが格納される。ユーザーバッファには、データバッファに格納されたデータを送信させたユーザーを示す識別情報(ここではデータiFD)が格納される。それにより、リングバッファは、データ本体、データサイズ、及びデータを送信させたユーザーのデータを格納したユーザーDB中のレコードを示すインデクス値をセットで参照できるようになっている。図5(a)において[]内に表記の「0」や「n」はそのインデクス値を表している。データのサイズ、及び識別情報は受信データ中から抽出される。
【0035】
上記ユーザーDBは、補助記憶装置27に保存されており、RAM22に読み出されて参照・更新される。上記リングバッファはRAM22に確保された領域である。
図7は、サーバー2が実行する全体処理のフローチャートである。その全体処理は、上記合奏サービス、及び視聴サービスを提供するためにサーバー2が実行する処理を抜粋してその流れを示したものである。それらサービス提供用のアプリケーションを補助記憶装置27からRAM22に読み出してCPU21が実行することで実現される。次に図7を参照して、その全体処理について詳細に説明する。
【0036】
先ず、ステップ101では、ユーザーDBの読み込みや、各種変数、及びリングバッファの初期化、クライアントであるPC3、4との送受信準備といった初期化を行う。その次に移行するステップ102では、並行して実行すべきスレッドを起動させる。そのスレッドの一つとして、図9にフローチャートを示す送信スレッドが存在する。その送信スレッドは、PC4間のデータの送受信を実現させるためのものである。
【0037】
ステップ102に続くステップ103では、変数iContに1を代入する。その代入後はステップ104に移行して、変数iContの値は1か否か判定する。その値が1であった場合、判定はYESとなってステップ105に移行し、そうでない場合には、判定はNOとなり、ここで一連の処理を終了する。このように変数iContは、アプリケーションの終了を管理するためのものであり、特に詳細な説明は省略するが、管理者の終了指示によって、他のアプリケーション、或いはOSが1以外の値を代入するようになっている。
【0038】
ステップ105では、PC3、4(以降「クライアント」と総称する)からデータを受信するのを待つ。そのデータをネットワークインターフェース24が受信すると、判定がYESとなってステップ106に移行し、変数fdに0を代入する。その次に移行するステップ107では、変数fdの値が、受信データに含まれているデータiFDの値と一致するか否か判定する。それらの値が一致する場合、判定はYESとなってステップ109に移行する。そうでない場合には、判定はNOとなり、ステップ108で変数fdの値をインクリメントした後、再度、ステップ107の判定処理を行う。それにより、受信データに含まれているデータiFDの値の特定を行う。
【0039】
ステップ109では、受信データがログオフを要求するものか否か判定する。そのログオフを要求するものであった場合、判定はYESとなってステップ110に移行し、ユーザーDBのログオフを要求したユーザーのレコードに格納されているデータcStatをログオフのものに更新するとともに、ログオン中のユーザーが使用するクライアントにログオフしたユーザーを通知するための情報をネットワークインターフェース24により送信させた後、上記ステップ105に戻る。そうでない場合には、判定はNOとなってステップ111に移行する。
【0040】
ステップ111では、リングバッファを構成するデータバッファのなかで受信データを格納すべき場所を示す値(図中「リングバッファポインター」と表記)を変数bufに代入する。その受信データのデータバッファへの格納に対応して、サイズバッファ、及びユーザーバッファにそれぞれデータを格納すべき場所を示す値(図中、共に「リングバッファポインター」と表記)を変数iSizePtr、及びiUDBPtrに代入する(ステップ112、113)。その代入後はステップ114に移行して、データバッファ中の変数bufの値で指定される場所から受信データを格納し、サイズバッファ中の変数iSizePtrの値で指定される場所にそのサイズ(を示す値)を格納する。ステップ115にはその格納後に移行する。
【0041】
ステップ115では、変数jに0を代入する。続くステップ116では、ユーザーDBの変数jの値をインデクス値として持つレコードに格納されているデータiFD(図中「udb[j].iFD」と表記。他のデータも同様の表記法を用いる)の値が上記変数fdの値と一致するか否か判定する。それらの値が一致する場合、判定はYESとなってステップ118に移行する。そうでない場合には、判定はNOとなり、ステップ117で変数jの値をインクリメントした後、再度ステップ116の判定処理を行う。それにより、受信データを送信させたユーザーに対応するレコードのインデクス値の特定を行う。
【0042】
ステップ118では、ユーザーバッファ中の変数iUDBPtrの値で指定される場所に、受信データを送信させたユーザーに対応するレコードのインデクス値として変数jの値を格納する。次のステップ119では、データバッファ、サイズバッファ、及びユーザーバッファのそれぞれにおいて、次のデータを格納すべき場所を示す値(図中「リングバッファポインター」と表記)を更新する。それらの更新後はステップ120に移行する。
【0043】
クライアントのユーザーがサーバー2に対してログオフ以外の要求を行う場合にも、そのクライアントからその要求に応じたデータがサーバー2に送信される。ステップ120以降では、そのようなデータに対応するための処理が行われる。ここではその要求として、ログオン要求、モード変更要求、録音要求、及び再生要求のみを想定することとする。録音要求は、視聴者Dが視聴の対象とする合奏結果の録音(保存)を要求するためのものであり、再生要求はその合奏結果の再生を要求するためのものである。
【0044】
先ず、ステップ120では、受信データがログオンを要求するものか否か判定する。そのログオンを要求するものであった場合、判定はYESとなってステップ121に移行し、認証処理を実行した後、上記ステップ105に戻る。そうでない場合には、判定はNOとなってステップ122に移行し、受信データがユーザーモードの変更を要求するものか否か判定する。そのモードの変更を要求するものであった場合、判定はYESとなり、ステップ123でその要求に対応するためのユーザーモード更新処理を実行した後、上記ステップ105に戻る。そうでない場合には、判定はNOとなってステップ124に移行する。
【0045】
上記ステップ123のユーザーモード更新処理では、ユーザーDBのなかで変数jの値をインデクス値とするレコードに格納されているデータcUserModeを、受信データで指定されたモードを表すものに更新する。そのような更新を行うことにより、クライアントのユーザーは演奏者A〜C、視聴者Dのうちの何れかに任意に変更できるようになっている。ユーザーモードを変更したレコードは、ログオン中のユーザーが使用するクライアント全てに送信する。
【0046】
ステップ124では、受信データが録音、或いは再生を要求するものか否か判定する。その録音、或いは再生を要求するものであった場合、判定はYESとなってステップ125に移行し、要求された録音、或いは再生を開始するための処理を実行した後、上記ステップ105に戻る。そうでない場合には、判定はNOとなってそのステップ105に戻る。
【0047】
図8は、上記ステップ121として実行される認証処理のフローチャートである。次に図8を参照して、その認証処理について詳細に説明する。
本実施の形態では、上述したように、サーバー2によるサービスを利用するには専用のアプリケーションをクライアントに実行させるようにしている。そのアプリケーションは、アプリケーション毎に異なるID(データcUserID)と共にCD−ROM等の記録媒体に記録して、ネットワークを利用した合奏を望む人を対象に配布している。そのアプリケーションは、ログオン要求時に自身に割り当てられたデータcUserIDを送信するようになっている。
【0048】
ユーザーDBに格納されるデータiFDは、ログオンを要求したユーザーに、そのときの状況に応じて割り当てるようにしている。このため、受信データがログオン要求のためのものであった場合、その受信データにはデータiFDに対応するものが付加されていない。そのような受信データに対応するために、特には図示していないが、上記ステップ107では受信データにデータcUserIDが付加されていればYESと判定するようにしている。また、上記ステップ116、117で形成される処理ループでは、データが格納されていないレコードが見つかるまで、変数jの値をインデクス値とするレコードのデータiFDを順次、参照することにより、データiFDとして割り当て可能な値(例えば最小値)を特定し、その特定した値を変数fdに代入するようになっている。認証処理は、そのような値が変数fdに代入されている状況下で実行される。
【0049】
先ず、ステップ201では、変数jに0を代入する。続くステップ202では、ユーザーDBの変数jの値をインデクス値とするレコードを参照し、そのレコードにデータが格納されていないか否か判定する。ユーザーDBは、データが格納されたレコードは連続するインデクス値の何れかで指定できるようにしている。つまり、ユーザー登録の抹消によりデータを消去したレコードが一つ発生すると、それよりも大きいインデクス値の各レコードのデータをそれまでより一つ小さいインデクス値のレコードにそれぞれコピーするようにしている。このことから、データが格納されている全てのレコードを参照した場合、次に変数jの値によって参照するレコードにはデータが格納されていないこととなる。その結果、判定はYESとなってステップ208に移行する。そうでない場合には、判定はNOとなってステップ203に移行する。そのYESの判定は、未登録のユーザーがログオン要求を行ったことを意味する。
【0050】
ステップ203では、参照するレコードのデータcUserIDが受信データに存在するデータcUserIDと同じか否か判定する。それらが同じものであった場合、判定はYESとなってステップ205に移行する。そうでない場合には、判定はNOとなり、ステップ204で変数jの値をインクリメントした後、上記ステップ202に戻る。そのYESの判定は、登録済みのユーザーがログオン要求を行ったことを意味する。
【0051】
ステップ205では、ユーザーDBの変数jの値をインデクス値として持つレコードのデータiFD(図中「udb[j].iFD」と表記)として変数fdの値を格納する。続くステップ206では、そのレコードのデータcStatとして、ログオン状態であることを示す値の1を格納する。次に移行するステップ207では、そのレコードのデータcUserModeとして演奏者Aを表す値の1を格納し、ユーザーバッファ中の変数iUDBPtrのステップ119で更新する前の値で指定される場所に、受信データを送信させたユーザーに対応するレコードのインデクス値として変数jの値を格納する。その格納を行った後に、認証を行ったユーザーのクライアントにユーザーDBを送信する。そのユーザーのレコードは、ログオン中となっている他のユーザーのクライアント全てに送信する。そのような送信を行った後、一連の処理を終了する。
【0052】
上記全体処理では、受信データを送信させたユーザーに対応するレコードのインデクス値として変数jの値をステップ118でユーザーバッファに格納するようになっている。しかし、受信データがログオン要求のためのものであった場合、受信データにはデータiFDが付加されていないことから、その変数jの値は正しいインデクス値となっていない。このことから、認証処理ではユーザーバッファに格納したインデクス値を正しいインデクス値に更新するようにしている。
【0053】
上記ステップ202の判定がYESとなって移行するステップ208では、変数jに0を代入する。次のステップ209では、ユーザーDBの変数jの値をインデクス値とするレコードを参照し、それがデータの格納されていないレコード(未登録エリア)か否か判定する。参照したレコードにデータが格納されていない場合、判定はYESとなり、ステップ211でudb[j].iFDとして変数fdの値、udb[j].cUserIDとして受信データに付加されているデータcUserIDをそれぞれ格納した後、上記ステップ206に移行する。そうでない場合には、判定はNOとなり、ステップ210で変数jの値をインクリメントした後、再度、ステップ209の判定処理を行う。
【0054】
図9は、上記送信スレッドの実行によって実現される処理のフローチャートである。その送信スレッドは、図7に示す全体処理内のステップ102で起動される。次に図9を参照して、その送信スレッドについて詳細に説明する。その送信スレッドは、上述したように、PC4間のデータの送受信を実現させるためのものである(図4)。
【0055】
先ず、ステップ301では、送信スレッドの終了を管理するための変数iSendThreadに1を代入する。続くステップ302では、その変数iSendThreadの値が1か否か判定する。その値が1でなかった場合、判定はNOとなってステップ318に移行する。そうでない場合には、判定はYESとなってステップ303に移行する。特に詳細な説明は省略するが、変数iSendThreadへの1以外の値の代入は、例えばPC4からの合奏の停止要求、録音中であれば録音停止要求によって図7に示す全体処理を実現させるアプリケーションが行うようになっている。再度の1の代入は、合奏の開始要求によってそのアプリケーションが行う。
【0056】
上述したように、クライアント間で送受信させるデータはリングバッファ(図5)に一時的に格納するようになっている。ステップ303では、そのリングバッファに送信の対象となるデータがないか否か判定する。そのようなデータがリングバッファに存在していない場合、判定はYESとなって上記ステップ302に戻る。そうでない場合には、判定はYESとなり、次のステップ304で変数iに0を代入した後、ステップ305に移行する。
【0057】
ステップ305以降では、変数iの値を順次、インクリメントしながら、その値をインデクス値とするレコードにデータが格納されたユーザーに、リングバッファに格納されている送信すべき受信データを送信するための処理が行われる。
【0058】
先ず、ステップ305では、変数iの値がユーザーDBに登録済みのユーザー数MAX_USER未満か否か判定する。変数iに初期値として代入する値は0であり、その値を順次、インクリメントして更新するようにしている。このため、受信データの送信を考慮すべきユーザーの全てに送信すべき受信データの送信を行った場合、変数iの値はユーザー数MAX_USER以上となる。その結果、判定はNOとなって上記ステップ303に戻る。そうでない場合には、判定はYESとなってステップ306に移行する。
【0059】
ステップ306では、リングバッファに格納されている送信対象の受信データがユーザーモード変更要求のためのものか否か判定する。その要求のためのものであった場合、判定はYESとなり、ステップ307で受信データを、変数iの値をインデクス値とするレコードにデータが格納されているユーザー宛に送信し、更にステップ308で変数iの値をインクリメントした後、上記ステップ305に戻る。一方、そうでない場合には、判定はNOとなってステップ309に移行する。
【0060】
上記ステップ307では、受信データと併せてリングバッファに格納されたインデクス値が変数iの値と一致している場合、その受信データの送信は行わない。それにより、データを受信したクライアントにそのデータを送信することを回避させている。
【0061】
ステップ309では、送信対象の受信データが録音、或いは再生を指示するためのものか否か判定する。そのような指示のためのものであった場合、判定はYESとなって上記ステップ307に移行する。そうでない場合には、判定はNOとなってステップ310に移行する。
【0062】
このようにして本実施の形態では、演奏情報(MIDIデータ)以外の受信データは他のユーザーに送信している。それにより、ログオンさせている他のユーザーのユーザーモード、他のユーザーが行っている要求を把握できるようにさせている。これは、合奏を行うためには他のユーザーの動きを把握する必要があるためである。録音の指示のための受信データを送信することにより、合奏を行う演奏者にとっては、録音の開始に合わせて合奏を開始させることができる。視聴者Dにとっては、そのような合奏の開始を知ることができる。
【0063】
ステップ310では、受信データと併せてリングバッファに格納されたインデクス値を変数iUDBfrに代入する。次のステップ311では、変数aに、ユーザーDBの変数iUDBfrの値をインデクス値とするレコードに格納されているデータcUserModeを代入する。その次のステップ312では、変数bに、ユーザーDBの変数iの値をインデクス値とするレコードに格納されているデータcUserModeを代入する。ステップ313にはその後に移行する。上記想定により、ステップ313への移行は送信対象とする受信データがMIDIデータであることを意味する。そのMIDIデータには、処理すべきタイミングを示す時間データが付加されている。
【0064】
ステップ313では、変数aの値が示すユーザーモードは演奏者Aであり、且つ変数bの値が示すユーザーモードは演奏者Bであるか否か判定する。受信データが演奏者AをユーザーモードとするユーザーのPC4から送信されたMIDIデータ(を含む演奏情報)であり、且つその受信データの送信を考慮しているユーザーのユーザーモードが演奏者Bであった場合、判定はYESとなってステップ307に移行する。そうでない場合には、判定はNOとなってステップ314に移行する。
【0065】
ステップ314では、変数aの値が示すユーザーモードは演奏者Bであり、且つ変数bの値が示すユーザーモードは演奏者Cであるか否か判定する。受信データが演奏者BをユーザーモードとするユーザーのPC4から送信されたMIDIデータ(を含む演奏情報)であり、且つその受信データの送信を考慮しているユーザーのユーザーモードが演奏者Cであった場合、判定はYESとなってステップ307に移行する。そうでない場合には、判定はNOとなってステップ315に移行する。
【0066】
ステップ315では、変数aの値が示すユーザーモードは演奏者Cであり、且つ変数bの値が示すユーザーモードは視聴者Dであるか否か判定する。受信データが演奏者CをユーザーモードとするユーザーのPC4から送信されたMIDIデータ(を含む演奏情報)であり、且つその受信データの送信を考慮しているユーザーのユーザーモードが視聴者Dであった場合、判定はYESとなってステップ316に移行する。そうでない場合には、判定はNOとなってステップ308に移行する。
【0067】
このようにして、PC4からサーバー2に送信された演奏情報は、そのユーザーによって特定される、それを送信すべきユーザーに限定して送信する。それにより、図4に示すような演奏情報の流れが実現される。
【0068】
ステップ316では、録音を行っているか否か判定する。その録音を行っている場合、判定はYESとなり、ステップ317で受信データを録音用に確保したバッファに保存した後、上記ステップ307に移行する。そうでない場合には、判定はNOとなり、他のステップの処理を実行することなく、そのステップ307に移行する。
【0069】
上記ステップ302の判定がNOとなって移行するステップ318でも同様に、録音を行っているか否か判定する。その録音を行っている場合、判定はYESとなり、録音用に確保したバッファに保存した受信データ(演奏情報)をステップ319でファイルとして保存した後、一連の処理を終了する。そうでない場合には、判定はNOとなり、ここで一連の処理を終了する。
【0070】
図10は、再生スレッドの実行によって実現される処理のフローチャートである。その再生スレッドは、再生指示のためのデータを受信した場合に、図7に示す全体処理内のステップ125で起動される。次に図10を参照して、その再生スレッドについて詳細に説明する。その再生スレッドは、上述したようにファイルとして保存した演奏情報を随時、ログオン中の全てのユーザーのクライアントに送信することにより、そのクライアントに合奏結果を再生させて視聴させるためのものである。演奏情報の送信は、再生指示を行った後、再生開始を指示することで開始される。
【0071】
その演奏情報は、MIDIデータに時間データを付加したものである。PC4は、その時間データとして、MIDIデータの発生時刻(を示す値)を付加している。その発生時刻は、MIDIデータがキーボード52への演奏操作によって生成されたものであればその演奏操作が行われた時刻であり、そのMIDIデータが受信したものであればそれを処理した時刻である。その時刻は、CPU21に搭載されたハードタイマから取得されるものである。これはPC4(PC3)でも同様である。
【0072】
先ず、ステップ401では、再生スレッドの終了を管理するための変数iPlayThreadに1を代入する。続くステップ402では、その変数iPlayThreadの値が1か否か判定する。その値が1でなかった場合、判定はNOとなり、ここで一連の処理を終了する。そうでない場合には、判定はYESとなってステップ403に移行する。特に詳細な説明は省略するが、変数iPlayThreadへの1以外の値の代入は、例えばクライアントからの再生の停止要求によってステップ125で行われる。
【0073】
ステップ403では、変数iPlayStartの値が1か否か判定する。その値が1でなかった場合、判定はNOとなって上記ステップ402に戻る。そうでない場合には、判定はYESとなってステップ404に移行する。変数iPlayStartへの1の代入は、例えばクライアントからの再生開始要求によってステップ125で行われる。ステップ402、403で形成される処理ループを繰り返し実行することにより、その再生開始要求が行われるのを待つ。
【0074】
ステップ404では、再生の対象とするファイルをオープンする。続くステップ405では、送信対象とする演奏情報を管理するための変数iCに0を代入し、変数iFirstDataに1を代入する。その後は、ステップ406で変数lTimeOffsetに現在時刻を示す値を代入してからステップ407に移行する。
【0075】
録音によって得られたファイルは、例えば所定期間、保存するようにしている。そのため、再生の対象となるファイルが複数、存在している場合、その対象とするファイルを選択できるようになっている。ここでは、それらについての詳細な説明は省略する。
【0076】
ステップ407では、変数iPlayStartの値が1か否か判定する。その値が1であった場合、変数iCの値で指定される演奏情報をステップ408でファイルから読み込んだ後、ステップ409に移行する。そうでない場合には、判定はNOとなって上記ステップ402に戻る。
【0077】
ステップ409では、変数iCの値で指定される演奏情報がないか否か判定する。演奏情報の再生(送信)が終了した場合、変数iCの値で指定される演奏情報は存在しなくなることから、判定はYESとなって上記ステップ402に戻る。それにより、演奏情報の再生を先頭から再度、開始させる。一方、そうでない場合には、判定はNOとなってステップ410に移行する。
【0078】
ステップ410では、ステップ408で読み込んだ演奏情報中の時間データを変数lMidiTimeに代入する。続くステップ411では、変数lTimeに、現在時刻を示す値を代入する。その次に移行するステップ412では、変数iFirstDataの値が1か否か判定する。その値が1であった場合、判定はYESとなり、変数lTimeOffsetの値から変数lMidiTimeの値を減算し、その減算結果に定数CONSTAを加算した値(=lTimeOffset−lNidiTime+CONSTA)をステップ413で変数lDivに代入し、更にステップ414で変数iFirstDataに0を代入した後、ステップ415に移行する。そうでない場合には、判定はNOとなり、次にそのステップ415に移行する。
【0079】
MIDIデータには発生時刻を示す時間データが付加されている。このため、変数lTimeOffsetの値から変数lMidiTimeの値を減算して得られる値は、サーバー2上の現在時刻と最初のMIDIデータの発生時刻の時間差を示している。その値に加算する定数CONSTAは、ネットワーク1を介した通信に要する時間の変動を吸収するためのものである。
【0080】
ステップ415では、変数lTimeの値から変数lDivの値を引いた値が、変数lMidiTimeの値より大きいか否か判定する。その大小関係が成立している場合、判定はYESとなり、ステップ417で変数jに0を代入した後、ステップ418に移行する。そうでない場合には、判定はNOとなって上記ステップ407に戻る。
【0081】
変数lDivには上述したような値が代入されている。このため、上記大小関係は、ステップ408で読み込んだ演奏情報のMidiデータを処理すべきタイミングとなる前に成立することになる。それにより、本実施の形態では、通信に要する時間が変動しても、クライアントに送信したMIDIデータの処理が遅れるのを確実に回避できるように送信している。
【0082】
ステップ418では、変数jの値が上記ユーザー数MAX_USER未満か否か判定する。その値がユーザー数MAX_USER未満であった場合、判定はNOとなってステップ419に移行する。そうでない場合には、判定はYESとなり、ステップ416で変数iCの値をインクリメントした後、上記ステップ407に戻る。
【0083】
ステップ419では、ユーザーDBの変数jの値をインデクス値とするレコードのデータcStatの値が1、つまりそのレコードにデータが格納されたユーザーがログオン中か否か判定する。そのユーザーがログオン中であった場合、判定はYESとなり、ステップ408で読み込んだ演奏情報をそのユーザーにステップ420で送信し、更にステップ421で変数jの値をインクリメントした後、上記ステップ418に戻る。そうでない場合には、判定はNOとなり、次にステップ421に移行する。
【0084】
次にPC4の動作について詳細に説明する。
サーバー2は、ユーザーがログオンしたクライアントにユーザーDB(図5)を送信する。また、図6に示すように、サーバー2が随時、送信するデータは、ヘッダー、及びそれが付加されたデータ本体に分けて、RAM42、或いは補助記憶装置48に確保した領域であるバッファに格納している。ヘッダーには、データサイズ、データ本体の内容、データ本体の送信者情報、などが格納されている。
【0085】
上述したように本実施の形態では、サーバー2によるサービスを利用するには専用のアプリケーションをクライアントに実行させるようにしている。以降は、そのアプリケーションを実行することで実現されるPC4の動作について、図11〜図16のフローチャートを参照して詳細に説明する。そのアプリケーションは、入力装置45を構成する媒体駆動装置にそれが格納された記録媒体をセットしてインストールを指示することで補助記憶装置48に格納される。
【0086】
図11は、PC4が実行する全体処理のフローチャートである。その全体処理は、上記アプリケーションを実行することで実現される。始めに図11を参照して、その全体処理について詳細に説明する。そのアプリケーションは、例えば補助記憶装置48からRAM42に読み出して実行される。
【0087】
先ず、ステップ501では、各種変数の初期化や図6に示すバッファの確保といった初期化を行う。次のステップ502では、ユーザーが入力装置45を操作して行う入力待ちを行う。その入力が行われることでステップ503に移行する。
【0088】
ステップ503では、入力がサーバー2との接続要求のためのものか否か判定する。ユーザーが入力装置45に対して接続要求のための操作を行った場合、判定はYESとなり、ステップ504でサーバー2との接続を行うための接続処理を実行した後、上記ステップ502に戻る。そうでない場合には、つまり再生指示、録音指示、或いはユーザーモード変更指示といった別の目的のための操作をユーザーが行った場合には、判定はNOとなり、ステップ503でその操作に対応するためのその他の処理を実行した後、そのステップ502に戻る。
【0089】
図12は、上記ステップ504として実行される接続処理のフローチャートである。次に図12を参照して、その接続処理について詳細に説明する。
先ず、ステップ601では、各種変数等の初期化を行う。続くステップ602では、サーバー2に接続するための送準備を行う。その準備により、サーバー2との接続を行ううえでの通信条件が確定され、ネットワークインターフェース44は確定された通信条件に応じて設定される。その準備後に移行するステップ603では、ネットワークインターフェース44を用いて、サーバー2に対する接続要求を行う。この接続要求により、アプリケーションに割り当てられたデータcUserIDが送信される。
【0090】
ステップ603に続くステップ604では、サーバー2との接続が確立し、ログオンが承認されたか否か判定する。ログオンが承認された旨がサーバー2から通知された場合、判定はYESとなってステップ605に移行する。そうでない場合には、判定はNOとなり、ここで一連の処理を終了する。
【0091】
ステップ605では、ログオンを承認したユーザーに対してサーバー2が送信するユーザーDBを受信するのを待って、それをRAM42、或いは補助記憶装置48に保存する。それ以降は、受信スレッド、送信スレッド、MIDIアウトスレッドを順次、起動させ(ステップ606〜608)、変数iOnConnectに1を代入する(ステップ609)。一連の処理はその代入を行った後に終了する。
【0092】
上記変数iOnConnectはサーバー2との接続状態を特定するためのものであり、それに代入した1はサーバー2と接続されていることを示す値である。以降は、接続処理で起動させる各種スレッドについて詳細に説明する。
【0093】
図13は、受信スレッドの実行によって実現される処理のフローチャートである。各種スレッドの説明では、始めに図13を参照してその受信スレッドについて詳細に説明する。その受信スレッドは、サーバー2から受信するデータに対応するためのプログラムである。
【0094】
先ず、ステップ701では、変数flagに1を代入する。その変数flagは、受信スレッドの終了を管理するための変数であり、それに代入した1は、受信スレッドは実行を継続すべき状況にあることを示す値である。それに1を代入した後は、ステップ702に移行して、その値が1か否か判定する。その値が1であった場合、判定はYESとなり、ステップ703でサーバー2からデータを受信するのを待つ。一方、そうでない場合には、判定はNOとなり、ここで一連の処理を終了する。変数flagへの1以外の値の代入は、例えばアプリケーションが実行を終了させる際に行われる。
【0095】
サーバー2からデータを受信すると、ステップ703の判定がYESとなってステップ704に移行する。そのステップ704では、一時的なデータ保存用のバッファrecv_bufに受信データを保存する。次のステップ705では、変数jに0を代入する。その代入後に移行するステップ706では、ユーザーDBの変数jの値をインデクス値とするレコードのデータiFDの値が、バッファrecv_bufに保存した受信データ中の送信者情報(ここではデータiFD)の値(図中「recv_buf[SEND_USER_ID]」と表記)と一致するか否か判定する。それらの値が一致する場合、判定はYESとなってステップ708に移行する。そうでない場合には、判定はNOとなり、次にステップ707で変数jの値をインクリメントした後、再度ステップ706の判定処理を実行する。
【0096】
ステップ708では、変数iUDBidに変数jの値を代入する。続くステップ709では、受信データがMIDIデータ(演奏情報)か否か判定する。それがMIDIデータであった場合、判定はYESとなり、受信したMIDIデータに対応するためのMIDI処理をステップ710で実行した後、上記ステップ702に戻る。そうでない場合には、判定はNOとなってステップ711に移行する。
【0097】
ステップ711では、受信データがユーザーモードの変更要求のためのものか否か判定する。それがその変更要求のためのものであった場合、判定はYESとなり、その変更要求を送信させたユーザーの変更後のユーザーモードを表示部46により通知するためのユーザーモード処理をステップ712で実行した後、上記ステップ702に戻る。そうでない場合には、判定はNOとなってステップ713に移行する。
【0098】
ステップ713では、受信データがユーザーDBのレコードのデータか否か判定する。そのレコードのデータを受信した場合、判定はYESとなり、保存しているユーザーDBにそのレコードのデータを格納して更新するためのユーザーDB処理を実行した後、上記ステップ702に戻る。そうでない場合には、判定はNOとなってステップ715に移行する。
【0099】
上述したようにサーバー2は、ユーザーDBの更新を行うと、その更新によって内容が変化したレコードのデータを各クライアントに送信する。そのため、各クライアントは、サーバー2で行われたユーザーDBに対する更新に連動させる形で自身が管理するユーザーDBを更新し、サーバー2が更新後のユーザーDBを実現させる。そのようにして、サーバー2、クライアントに同じユーザーDBを共有化させることから、そのレコードに格納するデータの設定により、クライアント間で送受信すべきデータの送受信を自動的に行わせることができる。それにより、例えば或る演奏者による音色の変更、音響効果の付加/解除、或いは付加する音響効果の変更、等の設定変更に対し、他のユーザーが使用する各クライアントに自動的に対応させることができるようになる。その結果、各クライアントのユーザーは、演奏者のより実際の演奏に近い演奏を自動的に聴くことができるから、高い利便性が得られる。
【0100】
上記設定変更は、再生する演奏情報に対して行うことができる。つまり、オリジナルの演奏の音色を変更させることや、種類、或いは内容がオリジナルとは異なる音響効果を付加させるといったことができる。そのような設定変更をクライアントのユーザーが行っても、各演奏者が演奏を行った際の設定内容を示すデータがユーザーDBに残っていれば、変更前の設定内容に自動的、或いはユーザーの指示により戻すことができる。
【0101】
ステップ715では、受信データが録音、或いは再生を指示するためのものか否か判定する。録音、或いは再生を指示するためのデータを受信した場合、判定はYESとなり、その指示内容を表示部46により通知するための録音・再生処理をステップ716で実行した後、上記ステップ702に戻る。そうでない場合には、判定はNOとなって次にそのステップ702に移行する。
【0102】
図14は、上記ステップ710として実行されるMIDI処理のフローチャートである。次にそのMIDI処理について、図14に示すそのフローチャートを参照して詳細に説明する。
【0103】
先ず、ステップ801では、変数iFirstMidiの値が1か否か判定する。その値が1だった場合、判定はYESとなってステップ802に移行し、そうでない場合には、判定はNOとなってステップ806に移行する。その変数iFirstMidiへの1の代入は、図12に示す接続処理内のステップ601で行われる。
【0104】
ステップ802では、変数iFirstMidiに0を代入する。続くステップ803では、変数lStartTimeに現在時刻を示す値を代入する。それに続くステップ804では、変数ulMに、受信データに付加された時間データを代入する。その代入後はステップ805に移行する。その時間データは、MIDIデータの後に付加されて送信される。
【0105】
ステップ805では、変数lTimeOffsetに、変数lStartTimeの値から変数ulMの値を減算した値(=lStartTime−ulM)を代入する。次のステップ806では、電子楽器5に出力すべきMIDIデータ用に確保したバッファ(MIDIアウトバッファ)の変数wPtrの値で指定される場所、及びその値をインクリメントした値で指定される場所(図中それらは「lMidiOutBuf[wPtr,wPtr+P1]」と表記)に、バッファrecv_bufに格納した受信データ中のMIDIデータ、時間データをそれぞれ格納する。その次のステップ807では、変数wPtrの値を更新、ここではそれまでの値に2を加算した値への更新を行う。その後、一連の処理を終了する。
【0106】
その変数wPtrは、図12に示す接続処理内のステップ601で初期値(例えば0)が代入される変数である。変数lTimeOffsetに代入する、変数lStartTimeの値から変数ulMの値を減算した値(=lStartTime−ulM)は、現在時刻を基準にした場合に、最初の受信したMIDIデータに付加されている時間データが示す発生時刻の考慮すべきシフト量(時間差)を表している。
【0107】
図15は、図12に示す接続処理内のステップ607で起動される送信スレッドの実行によって実現される処理のフローチャートである。次に図15を参照して、その送信スレッドについて詳細に説明する。
【0108】
サーバー2に送信する対象とすべきMIDIデータは時間データと共にその送信用に確保したバッファ(送信バッファ)に格納するようにしている。図15中に表記の「rPtrS」は、そのバッファからデータを読み出す場所を管理するための変数であり、図12に示す接続処理内のステップ601で初期値(例えば0)が代入される。また、表記の「iMidiSendThreadCont」は、送信スレッドの終了を管理するための変数である。
【0109】
先ず、ステップ901では、変数iMidiSendThreadContに1を代入する。続くステップ902では、変数iMidiSendThreadContの値が1か否か判定する。その値が1でなかった場合、判定はNOとなり、ここで一連の処理を終了する。そうでない場合には、判定はYESとなってステップ903に移行する。
【0110】
その変数iMidiSendThreadContへの1以外の値の代入は、例えばユーザーがユーザーモードとして視聴者Dへの変更を要求した場合に、図11に示す全体処理内のステップ505で行われる。そのステップ505では、視聴者Dから演奏者A〜Cへのユーザーモードの変更が要求された場合に、初期化を行い送信スレッドを起動させるようになっている。
【0111】
ステップ903では、送信バッファに送信すべきデータがないか否か判定する。送信すべきデータが存在していない場合、判定はYESとなって上記ステップ902に戻る。そうでない場合には、判定はNOとなってステップ904に移行する。
【0112】
ステップ904では、変数wParamに、送信バッファの変数rPtrSの値で指定される場所に格納されているデータ(図中「ulMidiSendBuf[wPtrS]」と表記のMIDIデータ)を代入する。その次に移行するステップ905では、変数lParamに、送信バッファの変数rPtrSの値をインクリメントした値で指定される場所に格納されているデータ(図中「ulMidiSendBuf[wPtrS+1]」と表記の時間データ)を代入する。その後に実行するステップ906では、MIDIデータ送信用のヘッダーを生成しバッファsend_bufにセットする。以降は、変数wParam、lParamrにそれぞれ代入した値をバッファsend_bufにセットし(ステップ907)、バッファsend_bufにセットしたデータをサーバー2に送信させ(ステップ908)、変数rPtrSにそれまでの値に2を加算した値を新たに代入する(ステップ909)。ステップ910にはその代入後に移行する。
【0113】
ステップ910では、変数rPtrSの値が送信バッファにデータを格納可能な最大数SIZE以上か否か判定する。その値が最大数SIZE以上であった場合、判定はYESとなり、ステップ911で変数rPtrSに0を代入した後、上記ステップ903に戻る。そうでない場合には、判定はNOとなり、他のステップの処理を実行することなく、そのステップ903に戻る。
【0114】
図16は、図12に示す接続処理内のステップ608で起動されるMIDIアウトスレッドの実行によって実現される処理のフローチャートである。最後に図16を参照して、そのアウトスレッドについて詳細に説明する。そのアウトスレッドは、MIDIアウトバッファに格納されたMIDIデータの処理、処理したMIDIデータ、及び電子楽器5から入力したMIDIデータの送信バッファへの格納を実現させるためのものである。
【0115】
クライアント間で送受信すべき演奏情報の送受信はサーバー2の制御下で行われる。このことから、MIDIアウトスレッドは、受信したMIDIデータ、及び電子楽器5から入力したMIDIデータを共にサーバー2に送信する対象としている。MIDIデータに付加された時間データが示す発生時刻は、それを送信したPC4での過去のものであるから、そのMIDIデータを処理した時刻に変更している。それにより、受信したMIDIデータ、及び電子楽器5から入力したMIDIデータの時間データはそれらを送信するPC4を基準としたものとさせている。このため、送信したMIDIデータを受信するクライアントは、MIDIデータを区別することなく、全てのMIDIデータを適切に処理することができる。
【0116】
図16中に表記の「rPtr」は、送信バッファからデータを読み出す場所を管理するための変数であり、図12に示す接続処理内のステップ601で初期値(例えば0)が代入される。また、表記の「iMidiOutThreadCont」は、MIDIアウトスレッドの終了を管理するための変数である。
【0117】
先ず、ステップ1001では、変数iMidiOutThreadContに1を代入する。続くステップ1002では、変数iMidiOutThreadContの値が1か否か判定する。その値が1でなかった場合、判定はNOとなり、ここで一連の処理を終了する。そうでない場合には、判定はYESとなってステップ1003に移行する。
【0118】
その変数iMidiOutThreadContへの1以外の値の代入は、例えばユーザーがユーザーモードとして視聴者Dへの変更を要求した場合に、図11に示す全体処理内のステップ505で行われる。そのステップ505では、視聴者Dから演奏者A〜Cへのユーザーモードの変更が要求された場合に、初期化を行いMIDIアウトスレッドを起動させるようになっている。
【0119】
ステップ1003では、変数lNowTimeに現在時刻を示す値を代入する。続くステップ1004では、定数lDelay、及びMIDIアウトバッファの変数rPtrの値をインクリメントした値で指定される場所に格納された時間データ(図中「lMidiOutBuf[rPtr+1]」と表記)の値をそれぞれ変数lTimeOffsetの値に加算し、その加算結果を変数lNowTimeの値から減算した値(=lNowTime−(lTimeOffset+lDelay+lMidiOutBuf[rPtr+1]))を変数aに代入する。その代入後はステップ1005に移行する。
【0120】
上記定数lDelayは、ネットワーク1、及びサーバー2を介した送受信に係る通信時間の変動を吸収するために定めた定数である。変数lTimeOffsetの値は上記時間データ(iMidiOutBuf[rPtr+1])が示す発生時刻の考慮すべきシフト量(時間差)を表していることから、ステップ1004で変数aに代入する値は、その時間データが付加されたMIDIデータを処理すべきタイミングが到来することで0以上の値となる。その定数lDelayは各クライアントのユーザーが変更できるようにしても良い。
【0121】
ステップ1005では、その変数aの値が0以上か否か判定する。その値が0未満であった場合、判定はNOとなってステップ1012に移行する。そうでない場合には、判定はYESとなってステップ1006に移行し、MIDIアウトバッファの変数rPtrの値で指定される場所に格納されたMIDIデータ(図中「lMidiOutBuf[rPtr]」と表記)が楽音の発音に係わるものか否か判定する。そのMIDIデータが楽音の発音に係わるものでない場合、判定はNOとなってステップ1012に移行する。そうでない場合には、判定はYESとなってステップ1007に移行する。
【0122】
ステップ1007では、そのMIDIデータをMIDI I/F47により電子楽器5に出力させる。次のステップ1008では、ユーザーのユーザーモードを示す値を変数bに代入する。それに続くステップ1009では、変数bの値とステップ1007で処理したMIDIデータの送信者のユーザーモードを示す値(図中「USER_MODE_PLAYERMAX」と表記。そのMIDIデータのヘッダーに格納されているデータiFDを用いてユーザーDBを参照することにより特定される)の大小関係を比較して、その送信者がユーザーよりも上流で演奏する演奏者か否か判定する。その送信者がユーザーよりも上流で演奏する演奏者であった場合、判定はYESとなってステップ1010に移行する。そうでない場合には、判定はNOとなって上記ステップ1004に戻る。
【0123】
ステップ1010では、変数bの値と視聴者Dのユーザーモードを示す値(図中「USER_MODE_AUDIENCE」と表記)の大小関係を比較して、ユーザーが視聴者Dでないか否か判定する。そのユーザーが視聴者Dでない場合、判定はYESとなり、ステップ1007で処理したMIDIデータ、及び時間データとして変数lNowTimeの値をステップ1011で送信バッファに格納した後、上記ステップ1004に戻る。そうでない場合には、判定はNOとなり、他のステップの処理を実行することなく、そのステップ1004に戻る。MIDIデータに時間データとして変数lNowTimeの値を付加することにより、そのMIDIデータの発生時刻はそのMIDIデータを送信するPC4で処理した時刻に更新される。
【0124】
上記ステップ1005、或いは1006の判定がNOとなって移行するステップ1012では、電子楽器5からMIDIデータを入力したか否か判定する。そのMIDIデータを入力した場合、判定はYESとなってステップ1011に移行し、そのMIDIデータ、及び時間データとしての変数lNowTimeの値を送信バッファに格納する。一方、そうでない場合には、判定はNOとなって上記ステップ1002に戻る。
【0125】
なお、本実施の形態では、演奏操作の内容を示すデータとしてMIDIデータを採用しているが、別のデータ、例えば楽音の波高値を示す波形データ、或いはその符号化データを採用しても良い。時間データも同様に、発生時刻を示すものではなくとも良い。例えば直前に送信した演奏情報との間の処理タイミングの差を示すものであっても良い。ネットワーク2の送信に要する通信時間に生じる変動分が無視できるような場合には、時間データは付加しなくとも良い。
【0126】
また、合奏結果として録音する対象は、演奏者CをユーザーモードとするユーザーのPC4から送信されるMIDIデータ(演奏情報)としているが、その対象を任意に選択できるようにしても良い。PC4の複数のユーザーがその選択をそれぞれ行えるようにしても良い。送信される演奏情報には送信者を示す情報が付加されていることから、複数のユーザーのそれぞれの要望に沿った録音を並行して行うことは容易である。
【0127】
上述したようなサーバー2(ネット合奏システム)を実現させるようなプログラム(アプリケーション)は、CD−ROM、DVD、或いは着脱自在なフラッシュメモリ等の記録媒体に記録させて配布しても良い。公衆網等のネットワークを介して、そのプログラムの一部、若しくは全部を配信するようにしても良い。そのようにした場合には、ユーザーはプログラムを取得してデータ処理装置にロードすることにより、その装置を用いて本発明を適用したネット合奏システムを構築することができる。このことから、記録媒体は、プログラムを配信する装置がアクセスできるものであっても良い。
【図面の簡単な説明】
【0128】
【図1】本実施の形態によるネット合奏システムを用いて構築されたネットワークシステムの構成を説明する図である。
【図2】本実施の形態によるネット合奏システムを搭載したサーバーの構成を説明する図である。
【図3】合奏を行う演奏者が使用するパーソナルコンピューター、及び電子楽器の構成を説明する図である。
【図4】仮想的な合奏の実現方法を説明する図である。
【図5】本実施の形態によるネット合奏システムを搭載したサーバーが合奏実現用に管理するデータを説明する図である。
【図6】パーソナルコンピューターによる受信したデータの保存方法を説明する図である。
【図7】本実施の形態によるネット合奏システムを搭載したサーバーが実行する全体処理のフローチャートである。
【図8】認証処理のフローチャートである。
【図9】図7に示す全体処理で起動される送信スレッドの実行によって実現される処理のフローチャートである。
【図10】図7に示す全体処理で起動される再生スレッドの実行によって実現される処理のフローチャートである。
【図11】合奏を行う演奏者のパーソナルコンピューターが実行する全体処理のフローチャートである。
【図12】接続処理のフローチャートである。
【図13】図12に示す接続処理で起動される受信スレッドの実行によって実現される処理のフローチャートである。
【図14】MIDI処理のフローチャートである。
【図15】図12に示す接続処理で起動される送信スレッドの実行によって実現される処理のフローチャートである。
【図16】図12に示す接続処理で起動されるMIDIアウトスレッドの実行によって実現される処理のフローチャートである。
【符号の説明】
【0129】
1 ネットワーク
2 サーバー
3、4 パーソナルコンピューター
5 電子楽器
21、41 CPU
22、42 RAM
23、43 ROM
24、44 ネットワークインターフェース
25、45 入力装置
27、48 補助記憶装置
28、49 バス
47、51 MIDI I/F
52 キーボード
53 音源・サウンドシステム




 

 


     NEWS
会社検索順位 特許の出願数の順位が発表

URL変更
平成6年
平成7年
平成8年
平成9年
平成10年
平成11年
平成12年
平成13年


 
   お問い合わせ info@patentjp.com patentjp.com   Copyright 2007-2013