(57)【要約】【課題】  音楽セッションの相手が複数に及ぶ場合でも、それらの相手との間の楽音情報の遣り取りを円滑に行えるようにすること。【解決手段】音楽セッションに参加する各演奏者のうち、マスタ演奏者のセッション端末へ、他の演奏者のセッション端末から実行可能な符号化の方式申告情報を送信する。マスタ演奏者のセッション端末は、受信した方式申告情報を基に、自端末と他のセッション端末のいずれによっても実行可能な符号化方式を求め、その符号化方式に従った楽音信号の符号化を他のセッション端末へ指示する。【選択図】    図１
2006227566.tif 000002
【特許請求の範囲】
【請求項１】
自身が実行可能な楽音信号の符号化アルゴリズムの方式を夫々表す複数の符号化方式情報を記憶した記憶手段と、
楽音信号を入力する入力手段と、
セッションの相手となる各端末が実行可能な楽音信号の符号化アルゴリズムの方式を表す符号化方式情報を夫々内包した方式申告情報を前記各端末の各々から受信する受信手段と、
前記記憶手段に記憶された複数の符号化方式情報が表す符号化アルゴリズムの方式の各組み合わせと前記受信した各方式申告情報に含まれる符号化方式情報が表す符号化アルゴリズムの方式とを照合し、符号化効率を最適化すべく予め設定された所定の条件を満たす方式の組み合わせを特定する方式制御手段と、
前記特定した組み合わせの複数の符号化アルゴリズムの方式に従った個別の符号化処理を前記入力手段から入力される楽音信号に対して施し、当該符号化アルゴリズムの方式毎の楽音情報を夫々生成する楽音情報生成手段と、
前記生成した各楽音情報を送信する楽音情報送信手段と
を備えたセッション端末。
【請求項２】
請求項１に記載のセッション端末において、
前記方式制御手段が特定した組み合わせの複数の符号化アルゴリズムの方式を示す方式符号化情報を含む確定方式通知情報をそれら各端末の各々に宛てて送信する手段
を更に備えたセッション端末。
【請求項３】
請求項１に記載のセッション端末において、
前記方式制御手段が予め設定された所定の条件を満たす方式の組み合わせを特定できなかったとき、前記各端末又は前記所定の条件に応じて選定した一部の端末に宛ててセッションが不可能である旨のメッセージを送信する手段
を更に備えたセッション端末。
【請求項４】
請求項１に記載のセッション端末において、
前記記憶手段は、
符号化方式の優先度を表す優先度情報を前記各符号化方式情報と各々対応付けて記憶し、
前記方式制御手段は、
前記特定した組み合わせが複数に及ぶとき、前記記憶手段にてより高い優先情報と対応付けられた符号化方式情報の符号化アルゴリズムの方式を多く含んだ１つの組み合わせを前記特定した複数の組み合わせのうちから更に特定する
ことを特徴とするセッション端末。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、楽音情報を端末間で遣り取りすることにより行われる音楽セッションを支援する技術に関する。
【背景技術】
【０００２】
従来より、電子楽器の楽音信号を専用端末を介して送受信することにより、遠隔にある者同士で音楽セッションを行う試みがなされてきた。
この種の音楽セッションを円滑に行うためには、各種電子楽器から専用端末へ供給される楽音信号の内容をリアルタイムで相互に遣り取りする必要がある。従って、この種の音楽セッションには、標準化された圧縮符号化方式に従って楽音信号をエンコードし及びデコートする機能をサポートした端末が用いられることが多い。楽音信号を、デコードされたデータとして遣り取りするようにすれば、音楽セッションを行っている間にネットワークを流通させるデータ量を低く抑えることができるからである。
【０００３】
ここで、「標準化された圧縮符号化方式」といっても、その規格は、ＭＰ３やＲｅａｌＡｕｄｉｏなど多岐に及んでいるのが現状である。従って、ある演奏者が自らの端末と別の演奏者の端末とを結んで音楽セッションを行う際は、楽音信号をエンコード及びデコードするための互いの圧縮符号化方式を一致させるための準備工程が不可避となる。かかる工程を効率化する技術を開示した文献としては、例えば、特許文献１がある。同文献に開示されたデータ伝送装置は、複数の方式でデータをエンコードする手段を備えており、他のデータ伝送装置へエンコードしたデータを引き渡す際、その装置から前もって取得したプロファイルを基にその装置へ引き渡すデータのエンコード方式を決定するようになっている。
【特許文献１】特開平５−３０３７０号公報
【発明の開示】
【発明が解決しようとする課題】
【０００４】
ところで、音楽セッションは、ベース、ドラム、ピアノといったような各パートの演奏者が揃った段階で開始されることが多い。このような場合、当然ながら、全演奏者の端末がサポートしている圧縮符号化方式でデコード及びエンコードを行うようにすることが最も望ましい。しかしながら、特許文献１に開示されたデータ伝送装置は一対一でのデータの遣り取りを想定したものとなっており、複数の相手との通信を並行して行う場合における圧縮符号化方式の調整までも円滑に行うことは出来なかった。
本発明は、このような背景の下に案出されたものであり、複数の相手と音楽セッションを行う場合でも、それらの相手との間の圧縮符号化方式の調整を円滑に行い、楽音信号を符号化して遣り取りする際の処理の負荷を低減し得るような仕組みを提供することを目的とする。
【課題を解決するための手段】
【０００５】
本発明の好適な態様であるセッション端末は、自身が実行可能な楽音信号の符号化アルゴリズムの方式を夫々表す複数の符号化方式情報を記憶した記憶手段と、楽音信号を入力する入力手段と、セッションの相手となる各端末が実行可能な楽音信号の符号化アルゴリズムの方式を表す符号化方式情報を夫々内包した方式申告情報を前記各端末の各々から受信する受信手段と、前記記憶手段に記憶された複数の符号化方式情報が表す符号化アルゴリズムの方式の各組み合わせと前記受信した各方式申告情報に含まれる符号化方式情報が表す符号化アルゴリズムの方式とを照合し、符号化効率を最適化すべく予め設定された所定の条件を満たす方式の組み合わせを特定する方式制御手段と、前記特定した組み合わせの複数の符号化アルゴリズムの方式に従った個別の符号化処理を前記入力手段から入力される楽音信号に対して施し、当該符号化アルゴリズムの方式毎の楽音情報を夫々生成する楽音情報生成手段と、前記生成した各楽音情報を送信する楽音情報送信手段とを備える。
【０００６】
この態様において、前記方式制御手段が特定した組み合わせの複数の符号化アルゴリズムの方式を示す方式符号化情報を含む確定方式通知情報をそれら各端末の各々に宛てて送信する手段を更に備えてもよい。
【０００７】
また、前記方式制御手段が予め設定された所定の条件を満たす方式の組み合わせを特定できなかったとき、前記各端末又は前記所定の条件に応じて選定した一部の端末に宛ててセッションが不可能である旨のメッセージを送信する手段を更に備えてもよい。
【０００８】
前記記憶手段は、符号化方式の優先度を表す優先度情報を前記各符号化方式情報と各々対応付けて記憶し、前記方式制御手段は、前記特定した組み合わせが複数に及ぶとき、前記記憶手段にてより高い優先情報と対応付けられた符号化方式情報の符号化アルゴリズムの方式を多く含んだ１つの組み合わせを前記特定した複数の組み合わせのうちから更に特定するようにしてもよい。
【発明の効果】
【０００９】
本発明によると、音楽セッションの相手が複数に及ぶ場合であっても、それらの相手との間の楽音情報の遣り取りを円滑に行うことが出来る。
【発明を実施するための最良の形態】
【００１０】
（第１実施形態）
本願発明の第１実施形態にかかるセッションシステムについて説明する。
まず、以降の説明で用いる主要な用語を定義しておく。「符号化方式」とは、楽音信号を圧縮符号化するアルゴリズムの各種方式を意味し、ＭＰ３（MPEG Audio Layer-3）方式やＲｅａｌＡｕｄｉｏ方式、ＱｕｉｃｋＴｉｍｅ方式などが夫々該当する。「楽音情報」とは、楽音信号を任意の符号化方式に従って圧縮符号化して得た符号列を表す情報を意味する。「運営者」とは、ネットワークを利用した音楽セッションサービスを提供している事業者を意味する。「演奏者」とは、運営者による支援の下、セッション端末の持ち主として音楽セッションに参加する個人を意味する。なお、各演奏者には、各々を識別するための演奏者ＩＤが運営者より交付されている。
【００１１】
図１は、本実施形態にかかるセッションシステムの全体構成図である。図に示すように、本システムは、各演奏者に夫々利用される複数のセッション端末１０と、運営者による管理の下に稼動されるセッション管理サーバ装置２０とから構成される。
【００１２】
図２は、セッション端末１０のハードウェア構成を示すブロック図である。図に示すように、セッション端末１０は、楽音信号入力部１１、楽音信号出力部１２、通信部１３、エンコード／デコード部１４、符号化方式記憶部１５、表示部１６、操作部１７、及び制御部１８を備える。
楽音信号入力部１１は、電子楽器３０から自端末１０へ楽音信号を入力する。一方、楽音信号出力部１２は、自端末１０からスピーカ４０へ楽音信号を出力する。通信部１３は、予め登録されたセッション管理サーバ装置２０のネットワークアドレスを基に同装置２０とコネクションを確立し、各種情報の送受信を行うようになっている。
【００１３】
エンコード／デコード部１４は、楽音信号入力部１１から楽音信号が供給されると、その楽音信号にある特定の符号化方式に従った符号化処理を施して得た楽音情報を通信部１３へ供給する一方、通信部１３から楽音情報が供給されると、その楽音情報に復号化処理を施して得た楽音信号を楽音信号出力部１２へ供給する。
ここで、各セッション端末１０は、異なる符号化方式に準拠した複数の圧縮符号化アルゴリズムを実装している。そして、実装された圧縮符号化アルゴリズムが従う符号化方式の内容は、各端末１０の仕様に応じて異なるものになっている。各セッション端末１０のエンコード／デコード部１４は、自らが符号化処理及び復号化処理を行う際に従う符号化方式を、制御部１８からの指示に応じて一意に特定するようになっている。
【００１４】
図３は、符号化方式記憶部１５のデータ構造図である。図に示すように、この記憶部１５は、符号化方式情報とプライオリティ情報とを対応付けて記憶する。符号化方式情報とは、自端末１０が実装している圧縮符号化アルゴリズムの符号化方式を示す情報を意味する。プライオリティ情報は、符号化方式の優先度を表す情報である。例えば、自端末１０が符号化方式Ａに従った符号化と符号化方式Ｂに従った符号化とを共に実行可能であり、且つ符号化方式Ａの方を優先的に採用する場合は、「符号化方式Ａ」の符号化方式情報と「１」のプライオリティ情報の対、及び「符号化方式Ｂ」の圧縮符号化情報と「２」のプライオリティ情報の対が符号化方式記憶部１５に記憶される。
【００１５】
表示部１６は、各種情報を表示するディスプレイである。操作部１７は、各種情報を入力するタッチパネルである。制御部１８は、上記各部の動作を制御する。この制御部１８が行う特徴的な動作については、後にフローチャートを参照しつつ詳述する。
【００１６】
図４は、セッション管理サーバ装置２０のハードウェア構成を示すブロック図である。図に示すように、このサーバ装置２０は、各種制御を行うＣＰＵ２１、ＣＰＵ２１にワークエリアを提供するＲＡＭ２２、ＩＰＬ（initial program loader）を記憶したＲＯＭ２３の他、通信インターフェース２４、コンピュータディスプレイ２５、マウス２６、キーボード２７、ハードディスク２８などを備える。そして、ハードディスク２８は、演奏者登録データベース２８ａ及び音楽セッション支援プログラム２８ｂを記憶する。
【００１７】
演奏者登録データベース２８ａは、自装置２０にアクセスしてくるセッション端末１０の認証のために設けられており、運営者が各演奏者に交付した全ての演奏者ＩＤを記憶している。
音楽セッション支援プログラム２８ｂは、本実施形態に特有の機能をＣＰＵ２１に実現させるためのプログラムである。ＣＰＵ２１によってこのプログラムが実行されると、ＲＡＭ２２にはセッション管理テーブルが形成される。
【００１８】
図５は、セッション管理テーブルのデータ構造図である。このテーブルは、各々が１つの音楽セッションと対応する複数のレコードの集合体である。図５の例では４つのレコードが設けられている。これは、セッション管理サーバ装置２０が４つの音楽セッションを個別に取り仕切ることができることを意味している。このテーブルを構成する１つのレコードは、「セッション」、「演奏者１」、「演奏者２」、「演奏者３」、「演奏者４」、及び「セッション中フラグ」の６つのフィールドを有している。
【００１９】
「セッション」のフィールドには、各音楽セッションに予め割り振られた固有の番号であるセッション識別情報が記憶される。「演奏者１」乃至「演奏者４」の各フィールドには、音楽セッションへの参加を求めて自装置２０へアクセスしてきたセッション端末１０から受信した演奏者ＩＤが、「演奏者１」→「演奏者２」→「演奏者３」→「演奏者４」の順番で順次記憶される。図から明らかなように、１つの音楽セッションには最大４名の演奏者まで参加できるようになっている。そして、後に詳述するように、あるレコードの「演奏者１」のフィールドに自らの演奏者ＩＤが記憶されている演奏者（以下、この演奏者を「マスタ演奏者」と呼ぶ。）には、同じレコードの「演奏者２」乃至「演奏者４」のフィールドにその演奏者ＩＤが記憶された他の演奏者と共に行う音楽セッションの開始の合図を下す権限が与えられることになっている。「セッション中フラグ」のフィールドには、音楽セッションが開始された状態にあることを示す「１」、又は音楽セッションが開始されていない状態にあることを示す「０」の何れか一方の情報が記憶される。
【００２０】
次に、本システムの動作を説明する。本システムの動作は、セッション参加申込処理とセッション処理とに分けることができる。
図６は、セッション参加申込処理を示すフローチャートである。この処理は、何れかのセッション端末１０がセッション管理サーバ装置２０にアクセスすると開始される。
【００２１】
セッション端末１０にアクセスされたセッション管理サーバ装置２０のＣＰＵ２１は、演奏者ＩＤ要求画面の表示データをそのセッション端末１０へ送信する（Ｓ１００）。
表示データを受信したセッション端末１０の制御部１８は、演奏者ＩＤ要求画面を表示部１６に表示させる（Ｓ１１０）。この画面には、「演奏者ＩＤを入力して下さい。」という内容を示す文字列と演奏者ＩＤの入力欄とが表示される。
【００２２】
演奏者ＩＤ要求画面の入力欄に演奏者ＩＤが入力されると、セッション端末１０の制御部１８は、入力された演奏者ＩＤを、通信部１３を介してセッション管理サーバ装置２０へ送信する（Ｓ１２０）。
演奏者ＩＤを受信したセッション管理サーバ装置２０のＣＰＵ２１は、その演奏者ＩＤが演奏者登録データベース２８ａに記憶されているか否かを判断する（Ｓ１３０）。
【００２３】
ステップ１３０において、演奏者ＩＤが演奏者登録データベース２８ａに記憶されていないと判断したＣＰＵ２１は、ログインを拒否するメッセージをセッション端末１０へ送信する（Ｓ１４０）。このメッセージをセッション端末１０が受信すると本処理が終了となる。
一方、ステップ１３０において、演奏者ＩＤが演奏者登録データベース２８ａに記憶されていると判断したＣＰＵ２１は、ＲＡＭ２２のセッション管理テーブルの記憶内容を基に生成したセッションルーム案内画面の表示データを、ステップ１２０にて演奏者ＩＤを送信してきたセッション端末１０に宛てて送信する（Ｓ１５０）。
【００２４】
表示データを受信したセッション端末１０の制御部１８は、セッションルーム案内画面を表示部１６に表示させる（Ｓ１６０）。
図７は、セッションルーム案内画面である。この画面は、セッション管理テーブルにおける各レコードの記憶内容を、「セッションルーム」と呼ばれる仮想的な部屋への入室の有無として表している。即ち、同画面の上段には、「入室するセッションルームを選択して下さい。但し、既にセッションが開始されているセッションルームには入室できません。」という内容を示す文字列が表示され、同画面の下段には、セッションルームのルーム番号と、それらの各セッションルームに入室している演奏者の演奏者ＩＤと、音楽セッションの開始の有無の状態を示す文字列とが対応付けて表示されている。
【００２５】
図７の例を見ると、セッションルーム１と２には演奏者が一人も入室していない。従って、これら２つのセッションルームについては、セッションが開始されていないことを示す「募集中」の文字列が表示されている。一方、セッションルーム３には４人の演奏者の入室があり、それらの演奏者によるセッションが既に開始されていることを示す「セッション中」の文字列が表示されている。セッションルーム４には２人の演奏者の入室があるにもかかわらず、「募集中」の文字列が表示されている。これは、マスタ演奏者による判断の下、新たな演奏者の入室があるまで待機した状態にあることを意味している。
【００２６】
セッションルーム案内画面を参照した演奏者は、自らが入室するセッションルームを操作部１７により選択する。未だセッションが開始されていないものであれば、既に何人かの演奏者が入室しているセッションルームを選択してもよいし、演奏者が一人も入室していないセッションルームを選択し、自らがそのセッションルームのマスタ演奏者となってもよい。
操作部１７によってセッションルームが選択されると、セッション端末１０のＣＰＵ２１は、選択されたセッションルームと対応するセッション識別情報と、演奏者ＩＤ要求画面にて入力された演奏者ＩＤとをセッション管理サーバ装置２０へ送信する（Ｓ１７０）。
【００２７】
セッション識別情報と演奏者ＩＤとを受信したセッション管理サーバ装置２０のＣＰＵ２１は、受信したセッション識別情報と対応するレコードをセッション管理テーブルから特定する（Ｓ１８０）。
続いて、ＣＰＵ２１は、ステップ１８０で特定したレコードの「演奏者１」乃至「演奏者４」の各フィールドのうち、未だ演奏者ＩＤが入力されていないフィールドへ演奏者ＩＤを記憶する（Ｓ１９０）。ある演奏者のセッション端末１０から受信した演奏者ＩＤが、このステップ１９０にて「演奏者１」のフィールドに記憶された場合、その演奏者は、「マスタ演奏者」として他の演奏者の入室を待ってから音楽セッションの開始の合図を自ら下すことになる一方、「演奏者２」乃至「演奏者４」のフィールドに記憶された場合、その演奏者は、既に入室していたマスタ演奏者によって音楽セッション開始の合図が下されるのをそのまま待つことになる。
【００２８】
演奏者ＩＤを記憶すると、ＣＰＵ２１は、ステップ１８０にて特定したレコードの「演奏者１」乃至「演奏者４」のフィールドから読み出した一又は複数の演奏者ＩＤを所定の雛形に埋め込んでセッション開始案内画面の表示データを生成し、生成した表示データを、「演奏者１」のフィールドから読み出した演奏者ＩＤの発信元であったセッション端末（マスタ演奏者のセッション端末）に宛てて送信する（Ｓ２００）。
【００２９】
表示データを受信したセッション端末１０の制御部１８は、セッション開始案内画面を表示部１６に表示させる（Ｓ２１０）。
図８は、セッション開始案内画面である。この画面の上段には、「新しい演奏者が入室しました。現在入室している演奏者のＩＤは以下の通りです。セッションを開始しますか。」という内容を示す文字列が表示され、その下には、セッションルームに入室している全演奏者の演奏者ＩＤが表示される。更にその下には、「セッション開始」と記したボタンが表示される。
この画面を参照したマスタ演奏者は、セッションを開始してもよいか否かを判断する。セッションを開始してもよいと判断したときは、画面下のボタンを操作部１７によって選択する。
【００３０】
「セッション開始」のボタンが選択されると、制御部１８は、セッションの開始を要求するメッセージをセッション管理サーバ装置２０へ送信する（Ｓ２２０）。
セッションの開始を要求するメッセージをセッション管理サーバ装置２０が受信すると、セッション参加申込処理が終了し、続いてセッション処理が開始される。
【００３１】
図９及び図１０は、セッション処理を示すフローチャートである。
セッションの開始を要求するメッセージを受信したセッション管理サーバ装置２０のＣＰＵ２１は、ステップ１８０にて特定したレコードの「演奏者２」乃至「演奏者４」の各フィールドに記憶された各演奏者ＩＤの発信元であるセッション端末１０へ、符号化方式の申告を要求するメッセージを夫々送信する（Ｓ３００）。
【００３２】
符号化方式の申告を要求するメッセージを受信した各セッション端末１０の制御部１８は、自らの符号化方式記憶部１５に記憶されている一又は複数の符号化方式情報を読み出す（Ｓ３１０）。
各セッション端末１０の制御部１８は、ステップ３１０で読み出した一又は複数の符号化方式情報を内包させた方式申告情報をセッション管理サーバ装置２０へ送信する（Ｓ３２０）。
【００３３】
方式申告情報を受信したセッション管理サーバ装置２０のＣＰＵ２１は、受信した方式申告情報を、セッションの開始を要求するメッセージの発信元であるセッション端末１０、つまり、マスタ演奏者のセッション端末１０へ転送する（Ｓ３３０）。
セッション管理サーバ装置２０から方式申告情報を受信したセッション端末１０の制御部１８は、受信した全ての方式申告情報に内包されている符号化方式情報と同じ符号化方式情報が自らの符号化方式記憶部１５に記憶されているか否かを判断する（Ｓ３４０）。
【００３４】
ステップ３４０において、同じ符号化方式情報が自らの符号化方式記憶部１５に記憶されていないと判断した制御部１８は、音楽セッションが不可能である旨のメッセージをセッション管理サーバ装置２０へ送信する（Ｓ３５０）。このメッセージをセッション管理サーバ装置２０を経由して各セッション端末１０が受信すると本処理が終了となる。
【００３５】
一方、ステップ３４０において、全ての方式申告情報に内包されている符号化方式情報と同じ符号化方式情報が自らの符号化方式記憶部１５に記憶されていると判断した制御部１８は、その条件を満たす１つの符号化方式情報を符号化方式記憶部１５から特定する（Ｓ３６０）。なお、条件を満たす符号化方式情報が複数に及ぶときは、自端末１０の符号化方式記憶部１５にてそれら複数の符号化方式情報の各々と対応付けられているプライオリティ情報を夫々参照し、最も高い優先度を示すプライオリティ情報と対応付けられている符号化方式情報を特定する。
【００３６】
続いて、制御部１８は、ステップ３６０にて特定した符号化方式情報が示す符号化方式に従った符号化及び復号化を、自端末１０のエンコード／デコード部１４に指示する（Ｓ３７０）。
更に、制御部１８は、ステップ３６０にて特定した符号化方式情報を内包させた確定方式通知情報をセッション管理サーバ装置２０へ送信する（Ｓ３８０）。
セッション管理サーバ装置２０のＣＰＵ２１は、マスタ演奏者のセッション端末１０から受信した確定方式通知情報を、方式申告情報の発信元であった各セッション端末１０、つまりマスタ演奏者を除いた各演奏者のセッション端末１０に宛てて送信する（Ｓ３９０）。
【００３７】
確定方式通知情報を受信したセッション端末１０の制御部１８は、受信した確定方式通知情報に内包されている符号化方式情報に従った符号化及び復号化を、自端末１０のエンコード／デコード部１４に指示する（Ｓ４００）。
ステップ４００の指示を行ったセッション端末１０の制御部１８は、音楽セッションの準備が完了したことを示すメッセージをセッション管理サーバ装置２０へ送信する（Ｓ４１０）。
【００３８】
確定方式通知情報の宛先であった全てのセッション端末１０からセッションの準備が完了した旨のメッセージを受信したセッション管理サーバ装置２０装置のＣＰＵ２１は、音楽セッションの開始タイミングまでの残り時間長を表すカウントダウン信号を、セッション端末１０へ送信する（Ｓ４２０）。
このカウントダウン信号を受信したセッション端末１０の制御部１８は、音楽セッションの開始タイミングまでの残り時間長を表示部１６に表示させる（Ｓ４３０）。具体的には、「スタート３秒前」→「スタート２秒前」→「スタート１秒前」の各内容を示す文字列をこの順番で一秒おきに表示させ、更に「スタート１秒前」の文字列を表示してから１秒経過したタイミングで、「スタート！」の文字列を表示させる。
【００３９】
各演奏者は、自らのセッション端末１０の表示部１６に表示されるカウントダウン表示を参照し、「スタート！」の文字列が表示されたタイミングに合わせて一斉に電子楽器３０の演奏を開始する。
演奏が開始されると、楽音信号入力部１１からは、電子楽器３０の楽音信号がエンコード／デコード部１４へ供給される一方、通信部１３からは、セッション管理サーバ装置２０を経由して他のセッション端末１０から受信した楽音情報がエンコード／デコード部１４へ供給される。
各セッション端末１０のエンコード／デコード部１４は、自らに供給された楽音信号にステップ３７０又はステップ４００で指示された符号化方式に従った符号化処理を施し、その処理によって得た楽音情報を通信部１３へ供給する処理と、自らに供給された楽音情報に復号化処理を施して得た楽音信号を楽音信号出力部１２へ供給する処理とを並行して行う。
また、セッション管理サーバ装置２０は、一方のセッション端末１０から自装置２０へ送信されてきた楽音情報を他方のセッション端末１０へ直ちに転送する処理を行う。
このようなセッション管理サーバ装置２０を介した楽音情報の遣り取りが実行されることで、各セッション端末１０は、遠隔にある他のセッション端末１０に入力された楽音信号をも自らのスピーカ４０から楽音として放音することが可能になり、その結果、遠隔にある演奏者同士によるリアルタイムの音楽セッションが実現する。
【００４０】
ここで、図１１に示されるような４つのセッション端末１０ａ乃至ｄによって音楽セッションを行う場合を想定し、本実施形態におけるセッション処理の内容について更に詳述する。図に示すように、セッション端末１０ａは、符号化方式Ａと符号化方式Ｂに従った符号化処理を実行可能な仕様となっている。また、セッション端末１０ｂは符号化方式Ａと符号化方式Ｃに従った符号化処理を実行可能な仕様になっており、セッション端末１０ｃは符号化方式Ａと符号化方式Ｂに従った符号化処理を実行可能な仕様になっている。更に、セッション端末ｄは符号化方式Ａと符号化方式Ｄに従った符号化処理を実行可能な仕様になっている。
このような状況において、セッション端末１０ａが、セッションの開始を要求するメッセージをセッション管理サーバ装置２０へ送信し、このメッセージを受信したセッション管理サーバ装置２０から符号化方式の申告を要求するメッセージがセッション端末１０ｂ乃至１０ｄに宛てて送信されると、セッション端末１０ｂは、符号化方式ＡとＣの符号化方式情報を内包させた方式申告情報を、セッション端末１０ｃは、符号化方式ＡとＢの符号化方式情報を内包させた方式申告情報を、セッション端末１０ｄは、符号化方式ＡとＤの符号化方式情報を内包させた方式申告情報をセッション端末１０ａへ夫々送信する。
セッション端末１０ｂ乃至ｄの各々から方式申告情報を受信したセッション端末１０ａは、受信した全ての方式申告情報に内包されている符号化方式情報と自身に共通する符号化方式情報として、符号化方式Ａの符号化方式情報を特定する。その後、セッション端末１０ａは、自端末１０のエンコード／デコード部１４に対して符号化方式Ａに従った符号化及び復号化を指示すると共に、セッション端末１０ｂ乃至ｄへ確定方式通知情報を送信する。この確定方式通知情報には、符号化方式Ａの符号化方式情報が内包されることになる。確定方式通知情報を受信したセッション端末１０ｂ乃至ｄは、自端末のエンコード／デコード部１４に対して符号化方式Ａに従った符号化及び復号化を指示する。
これにより、セッション端末１０ａ乃至ｄは、全端末に共通する符号化方式である符号化方式Ａに従った符号化及び復号化を実行する。
【００４１】
以上説明した本実施形態によると、複数の演奏者による音楽セッションを開始する前に、マスタ演奏者のセッション端末１０による指揮の下、全てのセッション端末１０で実行可能な符号化方式が特定される。そして、各セッション端末１０は、特定された符号化方式に従って符号化及び復号化を行うようになっている。従って、セッションの相手となるセッション端末１０毎に異なる符号化方式に従って楽音信号を符号化するといったような非効率的な処理を行う必要が無くなる。
また、マスタ演奏者のセッション端末１０が符号化方式の調整を行った結果、自らと共に音楽セッションを行う全てのセッション端末１０が実行可能な符号化方式が複数に及んだ場合、自端末１０の符号化方式記憶部１５にて各符号化方式と対応付けていたプライオリティ情報を基に１つの符号化方式を特定するようになっている。従って、全てのセッション端末１０が実行可能な符号化方式が複数に及ぶ場合であっても、符号化及び復号化に用いる符号化方式を円滑に決定することができる。
【００４２】
（第２実施形態）
本実施形態においては、マスタ演奏者のセッション端末１０のエンコード／デコード部１４に複数の符号化方式での符号化処理を並列に行わせることにより、異なる符号化方式を実装したセッション端末１０らによる音楽セッションを実現させる。また、マスタ演奏者のセッション端末１０は、自端末１０が実装している複数の符号化方式のうち何れの方式に従った符号化をエンコード／デコード部１４に行わせるかを所定のアルゴリズムに従って判断する。
【００４３】
本実施形態にかかるセッションシステムは、第１実施形態と同様に複数のセッション端末１０とセッション管理サーバ装置２０とから構成される。ここで、本実施形態においては、複数の符号化方式を実装しているセッション端末１０のエンコード／デコード部１４が、楽音信号入力部１１から供給される楽音信号に対して複数の符号化方式に従った圧縮符号化処理を個別に施し得るようになっている。そして、自端末１０が実装する複数の符号化方式のうち何れの組み合わせの方式で圧縮符号化処理を行うかについては、制御部１８からの指示に従う。
【００４４】
次に、本実施形態の動作を説明する。本実施形態の動作は、セッション参加申込処理とセッション処理とに分けることができ、セッション処理の内容が第１実施形態と異なる。
図１２は、セッション処理の内容を示すフローチャートである。図に示す処理は、ステップ３３０の後の内容が第１実施形態と異なる。
ステップ３３０にてセッション管理サーバ装置２０が方式申告情報をマスタ演奏者のセッション端末１０へ転送すると、セッション端末１０の制御部１８は、その転送されてきた方式申告情報に含まれる符号化方式情報を基に、方式申告情報の発信元であった各セッション端末１０が実装している符号化方式を夫々特定する（Ｓ３４１）。
【００４５】
符号化方式を特定した制御部１８は、方式申告情報の発信元であった各セッション端末１０のうちの最も多くの端末と自端末１０とが共に実装している符号化方式を特定する（Ｓ３４２）。
制御部１８は、方式申告情報の発信元であったセッション端末１０の中にステップ３４２で特定した符号化方式を実装していないものがあるか否か判断する（Ｓ３４３）。
特定した符号化方式を全ての端末が実装していると判断されたら、ステップ３７１以降の処理に移る。
特定した符号化方式を実装していないものがあると判断した制御部１８は、その符号化方式を実装していない残りのセッション端末１０のうちの最も多くの端末と自端末１０とが共に実装している符号化方式を更に特定する（Ｓ３４４）。
制御部１８は、方式申告情報の発信元であったセッション端末１０の中にステップ３４２及びステップ３４４で特定した両符号化方式を実装していないものがあるか否かを判断する（Ｓ３４５）。
【００４６】
両符号化方式を実装していないセッション端末１０があると判断した制御部１８は、その端末に宛ててセッションが不可能である旨のメッセージを送信する（Ｓ３５１）。一方で、そのようなセッション端末１０がないと判断したときは、ステップ３５１を実行することなく次のステップに進む。
マスタ演奏者のセッション端末１０の制御部１８は、ステップ３４２及びステップ３４４で特定した両符号化方式に従った符号化及び復号化を、エンコード／デコード部１４に指示する（Ｓ３７１）。
【００４７】
更に、制御部１８は、ステップ３４２及びステップ３４４で特定した両符号化方式を示す符号化方式情報を内包させた確定方式通知情報をセッション管理サーバ装置２０へ送信する（Ｓ３８１）。
セッション管理サーバ装置２０のＣＰＵは、マスタ演奏者のセッション端末１０から受信した確定方式通知情報を、方式申告情報の発信元であった各セッション端末１０、つまりマスタ演奏者を除いた各演奏者のセッション端末１０に宛てて送信する（Ｓ３９１）。
確定方式通知情報を受信したセッション端末１０の制御部１８は、その確定方式通知情報に内包されている符号化方式情報が示す両符号化方式のうち自端末１０が実装している一方の符号化方式に従った符号化及び復号化を、エンコード／デコード部１４に指示する（Ｓ４０１）。
ステップ４０１が実行された後は、図１０に示したステップ４１０以降と同様の処理が実行される。
【００４８】
ここで、図１３に示されるような７つのセッション端末１０ａ乃至ｇによって音楽セッションを行う場合を想定し、本実施形態におけるセッション処理の内容について更に詳述する。図に示すように、セッション端末１０ａは符号化方式Ａ、Ｂ、Ｃ、Ｄに従った符号化処理を実行可能な仕様となっている。そして、セッション端末１０ｂは符号化方式Ａと符号化方式Ｂに従った符号化処理を実行可能な仕様となっており、セッション端末１０ｃ及びｄは共に符号化方式Ａと符号化方式Ｄに従った符号化処理を実行可能な仕様になっている。また、セッション端末１０ｅ及び１０ｆは共に符号化方式Ｂに従った符号化処理を実行可能な仕様になっており、セッション端末１０ｇは符号化方式Ｄに従った符号化処理を実行可能な仕様になっている。
このような状況において、セッション端末１０ａが、セッションの開始を要求するメッセージをセッション管理サーバ装置２０へ送信し、このメッセージを受信したセッション管理サーバ装置２０が、符号化方式の申告を要求するメッセージをセッション端末１０ｂ乃至１０ｇに宛てて送信した場合、これらセッション端末１０ａ乃至１０ｇが従う符号化方式の調整は以下のように行われることになる。
【００４９】
まず、セッション端末１０ｂは符号化方式ＡとＢの符号化方式情報を内包させた方式申告情報を、セッション端末１０ｃ及び１０ｄは符号化方式ＡとＤの符号化方式情報を内包させた方式申告情報を、セッション端末１０ｅ及び１０ｆは符号化方式Ｂの符号化方式情報を内包させた方式申告情報を、セッション端末１０ｇは符号化方式Ｄの符号化方式情報を内包させた方式申告情報を夫々セッション端末１０ａへ送信する。
セッション端末１０ｂ乃至ｇの各々から方式申告情報を受信したセッション端末１０ａは、自らを含む最も多くのセッション端末１０ａ、ｂ、ｃ、ｄが実装している符号化方式Ａをまず特定する。続いて、それらを除いた残りのうち最も多くのセッション端末１０ｅ、ｆが実装している符号化方式Ｂを特定する。そして、セッション端末１０ａは、セッション端末１０ｇへセッションが不可能であることを示すメッセージを送信した後、自端末１０のエンコード／デコード部１４に対して符号化方式ＡとＢに従った符号化及び復号化を指示する。更に、セッション端末１０ａは、セッション端末１０ｂ乃至ｆへ確定方式通知情報を送信する。この確定方式通知情報には、符号化方式ＡとＢの符号化方式情報が内包されることになる。確定方式通知情報を受信したセッション端末１０ｂ乃至ｆは、自端末１０のエンコード／デコード部１４に対して符号化方式Ａ又はＢの一方に従った符号化及び復号化を指示する。
【００５０】
以上説明した本実施形態では、マスタ演奏者のセッション端末１０が、自端末１０のエンコード／デコード部１４に複数の符号化方式で圧縮符号化処理を行わせる。これにより、異なる符号化方式を実装したセッション端末１０らによる音楽セッションを実現させることができる。
【００５１】
（第３実施形態）
本実施形態においては、マスタ演奏者のセッション端末１０が、自端末１０が実装している複数の符号化方式のうち何れの方式に従った符号化をエンコード／デコード部１４に行わせるかを第２実施形態とは別のアルゴリズムに従って判断する。
本実施形態にかかるセッションシステムは、複数のセッション端末１０とセッション管理サーバ装置２０とから構成される。各々のハードウェア構成は第２実施形態と同様である。
【００５２】
次に、本実施形態の動作を説明する。本実施形態の動作は、セッション参加申込処理とセッション処理とに分けることができ、セッション処理の内容が上記両実施形態と異なる。
ステップ３３０にてセッション管理サーバ装置２０が方式申告情報をマスタ演奏者のセッション端末１０へ転送すると、セッション端末１０の制御部１８は、その転送されてきた方式申告情報に含まれる符号化方式情報を基に、方式申告情報の発信元であった各セッション端末１０が実装している符号化方式を夫々特定する（Ｓ３４６）。
【００５３】
符号化方式を特定した制御部１８は、自端末１０が実装する複数の符号化方式によって得られる全ての組み合わせを特定する（Ｓ３４７）。
制御部１８は、ステップ３４７で特定した組み合わせの各々とステップ３４６で特定した各セッション端末１０の符号化方式とを照合することにより、全てのセッション端末１０が実行可能で且つ符号化方式の数が最小となる組み合わせを特定する（Ｓ３４８）。なお、全てのセッション端末１０が実行可能で且つ符号化方式の数が最小となる組み合わせが複数に及ぶときは、自端末１０の符号化方式記憶部１５においてより高い優先度を示すプライオリティ情報と対応付けられている符号化方式を多く含む１つの組み合わせをそれらの中から特定する。
制御部１８は、ステップ３４８で特定した組み合わせの符号化方式に従った符号化及び復号化を、エンコード／デコード部１４に指示する（Ｓ３７２）。
【００５４】
更に、制御部１８は、ステップ３４８で特定した組み合わせの符号化方式を示す符号化方式情報を内包させた確定方式通知情報をセッション管理サーバ装置２０へ送信する（Ｓ３８２）。
ステップ３８２が実行された後は、図１２に示したステップ３９１以降と同様の処理が実行される。
【００５５】
ここで、図１５に示されるような７つのセッション端末１０ａ乃至ｇによって音楽セッションを行う場合を想定し、本実施形態におけるセッション処理の内容について更に詳述する。図１５に示す各セッション端末１０ａ乃至ｇの各々の仕様は図１３と同様なので再度の説明を割愛する。
このような状況において、セッション端末１０ａが、セッションの開始を要求するメッセージをセッション管理サーバ装置２０へ送信し、このメッセージを受信したセッション管理サーバ装置２０から符号化方式の申告を要求するメッセージがセッション端末１０ｂ乃至１０ｇに宛てて送信されると、セッション端末１０ｂは符号化方式ＡとＢの符号化方式情報を内包させた方式申告情報を、セッション端末１０ｃ及び１０ｄは符号化方式ＡとＤの符号化方式情報を内包させた方式申告情報を、セッション端末１０ｅ及び１０ｆは符号化方式Ｂの符号化方式情報を内包させた方式申告情報を、セッション端末１０ｇは符号化方式Ｄの符号化方式情報を内包させた方式申告情報をセッション端末１０ａへ夫々返信する。
【００５６】
セッション端末１０ｂ乃至ｇの各々から方式申告情報を受信したセッション端末１０ａは、自端末１０が実装している複数の符号化方式（Ａ，Ｂ，Ｃ，Ｄ）により得られる全ての組み合わせをまず特定する。この結果、１つの符号化方式からなる４通りの組み合わせ（Ａ，Ｂ，Ｃ，Ｄ）と、２つの符号化方式からなる６通りの組み合わせ（ＡＢ，ＡＣ，ＡＤ，ＢＣ，ＢＤ，ＣＤ）と、３つの符号化方式からなる４通りの組み合わせ（ＡＢＣ，ＡＢＤ，ＡＣＤ，ＢＣＤ）と４つの符号化方式からなる１通りの組み合わせ（ＡＢＣＤ）の合計１５通りの組み合わせが特定される。セッション端末１０ａは、それらの各組み合わせと、セッション端末１０ｂ乃至ｇの各々から受信した方式申告情報とを照合することにより、全てのセッション端末１０が実行可能で且つ符号化方式の数が最小となる、符号化方式ＢとＤの組み合わせを特定する。そして、セッション端末１０ａは、自端末１０のエンコード／デコード部１４に対して符号化方式ＢとＤに従った符号化及び復号化を指示する。更に、セッション端末１０ａは、セッション端末１０ｂ乃至ｆへ確定方式通知情報を送信する。この確定方式通知情報には、符号化方式ＢとＤの符号化方式情報が内包されることになる。確定方式通知情報を受信したセッション端末１０ｂ乃至ｇは、自端末１０のエンコード／デコード部１４に対して符号化方式Ｂ又はＤの一方に従った符号化及び復号化を指示する。
【００５７】
以上説明した本実施形態では、マスタ演奏者のセッション端末１０が、全てのセッション端末１０が実行可能で且つ符号化方式の数が最小となる組み合わせを特定するようになっている。従って、楽音信号を符号化及び復号化する際の処理の負担を最小化することができる。
【００５８】
（他の実施形態）
本実施形態は、種々の変形実施が可能である。
上記実施形態において、セッション管理サーバ装置２０のＲＡＭ２２には、４つのレコードからなるセッション管理テーブルが形成され、同装置２０は４つの音楽セッションを個別に取り仕切ることができるようになっていた。これに対し、セッション管理テーブルのレコード数を増やすことで、より多くの音楽セッションを取り仕切れるようにしてもよい。また、上記実施形態においては、１つの音楽セッションに参加できる演奏者が４名までであったが、これよりも多くの演奏者が参加して１つの音楽セッションが行われるようにしてももちろんよい。
【００５９】
上記実施形態において、マスタ演奏者のセッション端末１０は、自らと共に音楽セッションを行う全てのセッション端末１０で実行可能な符号化方式がない場合、セッションが不可能である旨のメッセージを送信するようになっていた。これに対し、マスタ演奏者のセッション端末１０が複数の符号化方式での符号化処理及び復号化処理をパラレルに実行するようにしてもよい。
【００６０】
第２実施形態において、マスタ演奏者のセッション端末１０のエンコード／デコード部１４が同時に実行できる符号化方式の上限は２つであったが、これを３つ以上としてもよい。この変形例では、符号化方式の数が上限値に到達するまで図１２のステップ３４４乃至３４５のループが繰り返されることになる。
また、ステップ３４５において符号化方式を実装していないと判断されたセッション端末１０にはセッションが不可能であることを示すメッセージが送信されていたが、そのような端末１０にも他の端末と同様に確定方式通知情報が送信されるようにしてもよい。セッション端末１０の仕様によっては、音質が悪いなどの事情から自身が実装している符号化方式の一部の利用を希望せず、そのような符号化方式を方式申告情報として申告しないケースもあるが、本変形例によれば、そのような未申告の符号化方式を代替的に利用した音楽セッションへの参加を促すことも可能となる。
【図面の簡単な説明】
【００６１】
【図１】セッションシステムの全体構成図である。
【図２】セッション端末のハードウェア構成図である。
【図３】符号化方式記憶部のデータ構造図である。
【図４】セッション管理サーバ装置のハードウェア構成図である。
【図５】セッション管理テーブルのデータ構造図である。
【図６】セッション参加申込処理を示すフローチャートである。
【図７】セッションルーム案内画面である。
【図８】セッション開始案内画面である。
【図９】セッション処理を示すフローチャートである（前半部分）。
【図１０】セッション処理を示すフローチャートである（後半部分）。
【図１１】符号化方式の調整の一例を示す図である。
【図１２】セッション処理を示すフローチャートである（第２実施形態）。
【図１３】符号化方式の調整の一例を示す図である（第２実施形態）。
【図１４】セッション処理を示すフローチャートである（第３実施形態）。
【図１５】符号化方式の調整の一例を示す図である（第３実施形態）。
【符号の説明】
【００６２】
１０…セッション端末、１１…楽音信号入力部、１２…楽音信号出力部、１３…通信部、１４…エンコード／デコード部、１５…符号化方式記憶部、１６…表示部、１７…操作部、１８…制御部、２０…セッション管理サーバ装置、２１…ＣＰＵ、２２…ＲＡＭ、２３…ＲＯＭ、２４…通信インターフェース、２５…コンピュータディスプレイ、２６…マウス、２７…キーボード、２８…ハードディスク、３０…電子楽器、４０…スピーカ
【図１】
2006227566.tif 000003
【図２】
2006227566.tif 000004
【図３】
2006227566.tif 000005
【図４】
2006227566.tif 000006
【図５】
2006227566.tif 000007
【図６】
2006227566.tif 000008
【図７】
2006227566.tif 000009
【図８】
2006227566.tif 000010
【図９】
2006227566.tif 000011
【図１０】
2006227566.tif 000012
【図１１】
2006227566.tif 000013
【図１２】
2006227566.tif 000014
【図１３】
2006227566.tif 000015
【図１４】
2006227566.tif 000016
【図１５】
2006227566.tif 000017