(57)【要約】【課題】  本発明は楽曲の共同制作に関し、より詳細にはネットワークを介して他のメンバーとの間で演奏によって得られた楽曲データを送受信して楽曲の共同制作を行う楽曲共同制作方法および楽曲共同制作プログラムを提供することを目的とする。  【解決手順】  楽譜データに属性情報が付加された楽曲データを受取って、その属性情報を基に楽譜データを再生し、その再生に合わせて演奏された楽譜データに属性情報を付加し楽曲データを他のメンバーに送信するよう構成する。【選択図】    図１
2006215210.tif 000002
【特許請求の範囲】
【請求項１】
複数のメンバーがネットワークを介して楽曲を共同制作する楽曲共同制作方法であって、
楽譜データに属性情報が付加された第１の楽曲データを前記メンバーから受信する楽曲データ受信手順と、
前記属性情報から楽曲ＩＤを抽出し、該楽曲ＩＤをキー情報として前記楽譜データと前記属性情報とをそれぞれを記憶部に記憶する受信データ記憶手順と、
前記楽曲ＩＤにより前記記憶部から前記属性情報と楽譜データとを取り出し、該属性情報に基づいて該楽譜データを再生し、該再生に合わせて演奏された楽譜データを取得する楽譜データ取得手順と、
前記取得した楽譜データに、該楽譜データの属性情報を付加した第２の楽曲データを全ての前記メンバーに送信する楽曲データ送信手順と
を有することを特徴とする楽曲共同制作方法。
【請求項２】
前記楽曲共同制作方法は、さらに前記記憶された楽譜データに対して小節数の繰り返し、テンポ、音量および拍子の変更を受け付ける編集手順を有し、
前記楽譜データ取得手順は、前記編集された楽譜データを再生し、該再生に合わせて演奏された楽譜データを取得する
ことを特徴とする請求項１記載の楽曲共同制作方法。
【請求項３】
前記楽譜取得手順は、前記楽譜データの再生に合わせた演奏に加えて、引き続き新たに演奏された楽譜データを取得する
ことを特徴とする請求項１または請求項２記載の楽曲共同制作方法。
【請求項４】
複数のメンバーがネットワークを介して楽曲を共同制作する楽曲共同制作方法であって、
楽譜データに属性情報とメッセージとが付加された第１の楽曲データを前記メンバーから受信する楽曲データ受信手順と、
受信した前記第１の楽曲データを前記楽譜データと前記属性情報とメッセージとに分け、該属性情報から抽出した楽曲ＩＤをキー情報とし該楽譜データと該属性情報とをそれぞれ記憶部に記憶すると共に、該メッセージを表示部に表示する受信データ記憶手順と、
前記楽曲ＩＤにより前記属性情報と楽譜データとを取り出し、該属性情報に基づいて前記楽譜データを再生し、該再生に合わせて演奏された楽譜データを取得する楽譜データ取得手順と、
前記取得した楽譜データに、該楽譜データの属性情報とメッセージとを付加した第２の楽曲データを全ての前記メンバーに送信する楽曲データ送信手順と
を有することを特徴とする楽曲共同制作方法。
【請求項５】
複数のメンバーがネットワークを介して楽曲を共同制作する楽曲共同制作プログラムであって、
楽譜データに属性情報が付加された第１の楽曲データを前記メンバーから受信する楽曲データ受信手順と、
前記属性情報から楽曲ＩＤを抽出し、該楽曲ＩＤをキー情報として前記楽譜データと前記属性情報とをそれぞれを記憶部に記憶する受信データ記憶手順と、
前記楽曲ＩＤにより前記記憶部から前記属性情報と楽譜データとを取り出し、該属性情報に基づいて該楽譜データを再生し、該再生に合わせて演奏された楽譜データを取得する楽譜データ取得手順と、
前記取得した楽譜データに、該楽譜データの属性情報を付加した第２の楽曲データを全ての前記メンバーに送信する楽曲データ送信手順と
をコンピュータに実行させるための楽曲共同制作プログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は楽曲の共同制作に関し、より詳細にはネットワークを介して複数のメンバーがＭＩＤＩ（Musical Instruments Digital Interface）楽器等の電子楽器の演奏によりそれぞれのパートの楽曲データを作成し、楽曲の制作を行う楽曲共同制作方法および楽曲共同制作プログラムに関する。
【背景技術】
【０００２】
ＤＴＭ（Desk Top Music）と呼ばれるコンピュータ・ミュージックは、パソコンや関連するツール（ＭＩＤＩ楽器やシーケンスソフト等）の普及もあって、フォーラムが作られたり毎年コンテストが開かれるなど熱心な愛好者が多く存在する。
【０００３】
従来、このようなＤＴＭは個人がデータを打ち込んだり、あるいはＭＩＤＩ楽器を弾いて楽譜データを記録し、これを編集して曲の作成を行っていた。しかし、個人では曲のイメージや構成がワンパターンになりがちで、面白みに欠けると感ずる人もいる。このようなことから、曲の作成を一人で行うのではなく複数の人と共同で制作しょうとすることが行われている。
【０００４】
共同で音楽の制作を行う場合の方法として、主に次の二つの方法が挙げられる。
【０００５】
１）それぞれのメンバーが音楽データを作成して編集者にそのデータを送付し、編集者はその送付された音楽データを編集し、１つの曲を作成する。
【０００６】
２）音楽データを１人の共同作成者に送付し、その共同作成者が送付された音楽データに自分の作曲した音楽データを編集して作成した音楽データをもう１人の共同作成者に送付し、これを何人かの人にバトンタッチしてリレー式に作曲をしていく方法。
【０００７】
この時の音楽データの送付の方法として次の方法が考えられる。
【０００８】
１）電子メールを利用して送付する方法。
【０００９】
２）インターネット上に音楽データをアップロードし、それをダウンロードする方法。
【００１０】
３）音楽データをフロッピー・ディスク（商標登録）等の記録媒体に格納し、郵送する方法。
【００１１】
また、近年ネットワークのコスト低減が進んだことから、ネットワークを介して複数の人と共同制作する方法も提案されている。
【００１２】
例えば、複数のメンバーがチャット機能を用いてアイディアを出して共通の曲を合作する方法で、複数のクライアントＰＣとサーバで構成し、サーバはクライアントＰＣから送られてきた作曲用データに基づいて曲データを作成し、クライアントＰＣに作成した曲データを送信するものである（特許文献１）。
【特許文献１】特開２００１−１９５０６４号公報
【発明の開示】
【発明が解決しようとする課題】
【００１３】
前述したそれぞれの共同制作者が作成した音楽データを編集者に送って編集者が編集して１つの曲とする方法や、共同制作者がリレー式に音楽データを送って曲を完成して行く方法は、作曲の作業が別々の場所で異なる時間に行われるのでインスピレーションを発揮しにくい、と言う問題がある。
【００１４】
また、特許文献１で提案された方法は、複数のクライアントＰＣからの作曲用データを取得し、作曲を行う機能をサーバに持たせる必要があり、容易にシステムを構築できるものではない。
【００１５】
本発明の楽曲共同制作方法は、共同制作者から送られた楽曲データの再生に合わせて演奏した楽譜データを取得し、その楽曲データを共同制作者全員に送り、これを繰り返すことで１つの曲を作成するもので、瞬間的なインスピレーションの発揮が活かされ、サーバは特別の機能を持たすことを必要としない楽曲共同制作方法および楽曲共同制作プログラムを提案する。
【課題を解決するための手段】
【００１６】
本発明の楽曲共同制作方法および楽曲共同制作プログラムは以下のように構成される。
（１）第１の発明
第１の発明は、複数のメンバーの１人から送られた楽曲データを受信して再生し、その再生に合わせてクライアント端末を使用するメンバー自身が演奏したデータを取得し、その演奏した楽曲データを他のメンバーに送信するものである。
【００１７】
図１は第１の発明の原理を示すもので楽曲データ受信手順１０、受信データ記憶手順２０、楽譜データ取得手順３０および楽曲データ送信手順４０で構成する。
【００１８】
楽曲データ受信手順１０は、メンバーの１人から送信された第１の楽曲データを受信する。受信した楽曲データは楽譜データに属性情報が付加されたものである。
【００１９】
受信データ記憶手順２０は、受信した第１の楽曲データを楽譜データと属性情報に分け、属性情報に含まれる楽曲を識別する楽曲ＩＤを抽出してこの楽曲ＩＤをキー情報として記憶部にそれぞれを記憶する。
【００２０】
楽譜データ取得手順３０は、記憶部から楽曲ＩＤにより属性情報と楽譜データを取り出し再生し、この再生に合わせて例えばメンバーが弾くＭＩＤＩ楽器の演奏により新たな楽譜データを取得する。
【００２１】
楽曲データ送信手順４０は、第１の楽曲データを受信し、それを聴いたメンバーの更なる演奏により取得した新たな楽譜データに属性情報を付加した楽曲データを他のメンバーに送信する。このときの楽曲データを第２の楽曲データとする。
【００２２】
以上により、例えばメンバーからメロディラインが第１の楽曲データとして提示されたとき、これに基づいてメンバーが他のパートを演奏した楽譜データを取得し（例えば、第１の楽曲データがピアノのパートであった場合、このピアノに合わせてベースを演奏し、ベースパートの楽譜データを取得する）、この楽曲データを更にメンバーに送信して曲を完成させる、といったことができる。
（２）第２の発明
第２の発明は、第１の発明において、受信して記憶した楽譜データに対して、小節数の繰り返し（リピート）、テンポ、音量、拍子の編集手順を持つものである。そして、楽譜データ取得手順３０において、編集がなされた楽譜データを再生し、その再生に合わせてメンバーが演奏した楽譜データを取得する。
【００２３】
これにより、第１の楽曲データを受信したメンバーは、自分の感性によりテンポ等を変えて第１の楽曲データの楽譜データをアレンジ（編曲）し、このアレンジした曲に合わせて演奏した楽譜データを取得する。
（３）第３の発明
第３の発明は、第１と第２の発明の楽譜データ取得手順３０において、受信した楽譜データの再生に合わせて演奏すると共に、引き続いて新たに演奏した楽譜データも含めて取得する。
【００２４】
これにより、例えば最初に提示されたメロディラインに対して、次のメロディラインの提示ができる。
（４）第４の発明
第４の発明は、楽曲データにメッセージを含むものである。
【００２５】
楽曲データ受信手順１０では、メンバーから送信された楽曲データには楽譜データに属性情報とメッセージが付加されたもので、この楽曲データを第１の楽曲データとして受信する。
【００２６】
受信データ記憶手順２０は、受信した第１の楽曲データを楽譜データ、属性情報およびメッセージとに分け、属性情報に含まれる楽曲を識別する楽曲ＩＤを抽出してこの楽曲ＩＤをキー情報として楽譜データと属性情報をそれぞれ記憶部に記憶し、メッセージは表示部に表示する。
【００２７】
楽譜データ取得手順３０は、第１の発明と同様である。
【００２８】
楽曲データ送信手順４０は、演奏により取得した楽譜データに属性情報とメッセージを付加した楽曲データを全てのメンバーに送信する。このときの楽曲データを第２の楽曲データとする。
（５）第５の発明
第５の発明は、第１の発明に基づいた楽曲共同制作プログラムである。
【発明の効果】
【００２９】
第１の発明では、メンバーの一人が作成した曲に合わせて他のパートの曲の制作ができ、これを繰り返すことで多くのパートから成る曲の共同制作が可能な方法の提供ができる。
【００３０】
第２の発明では、受信した曲のテンポや拍子を変えることにより、送信者の曲想をさらに発展させたアイディアで曲の制作ができる。
【００３１】
第３の発明では、送信者から送られた曲に引き続き新たな曲の展開ができる。
【００３２】
第４の発明では、メッセージを同時に送ることができ、他のメンバーに曲に対するコメント等を通知できる。
【００３３】
第５の発明では、多くのパートから成る曲の共同制作が可能な方法の提供ができる。
【実施例】
【００３４】
本発明の実施例について図２から図１２を用いて説明する。
（実施例その１）
図２は本発明の全体のシステム構成の例を示す図である。この構成例では、サーバにチャットを行うＩＲＣ（Internet Relay Chat）サーバ１００用い、ネットワーク２００を介してクライアント端末（管理者）３００、クライアント端末（制作者）３０１およびクライアント（鑑賞者）３０２が接続されている。
【００３５】
クライアント端末（管理者）３００は、ＩＲＣのチャンネルオペレータであり、例えば楽曲共同制作に対する参加制限を行う権限を持つ端末である。また、クライアント端末（管理者）３００は、楽曲の共同制作もできる。クライアント端末（制作者）３０１は、楽曲の共同制作が行える端末である。即ち、楽曲データの送受信を可能とする。クライアント（鑑賞者）３０２は、鑑賞を行う端末で、楽曲データの受信のみを行う。
【００３６】
次にクライアント端末（管理者）３００の構成例を図３に示す。クライアント端末（管理者）３００は、データやプログラムを制御するＣＰＵ(Central Processing Unit)３１０、ネットワーク２００に対して送受信の通信を制御する通信制御部３２０、演奏しながら楽譜データを取得するためのＭＩＤＩ楽器３３１、メッセージ等を表示するディスプレイ３３２、コンピュータ入力やプログラムの起動をかけるための指示を行うキーボード３３３、曲の再生を行うためのＭＩＤＩ音源３３４とスピーカー３３５、入出力機器を制御する入出力制御部３３０、楽譜データを格納する楽譜データ記憶部３４０、楽譜データの属性情報を含め方法を管理する情報を格納する管理情報記憶部３５０および楽曲の共同制作を行うプログラムである楽曲共同制作プログラム３６０から構成する。
【００３７】
楽曲共同制作プログラム３６０は更に楽曲データの受信を行う楽曲データ受信部３６１、受信したデータを楽譜データ記憶部３４０や管理情報記憶部３５０に記憶する受信データ記憶部３６２、ＭＩＤＩ楽器３３１を演奏して楽譜データを取得する楽譜データ取得部３６３および取得した楽譜データを他のクライアント端末に送信する楽曲データ送信部３６４から構成する。
【００３８】
以上のクライアント端末（管理者）３００の構成にはチャットの機能は省略してある。また、クライアント端末（制作者）３０１の構成もこの構成と同一である。クライアント端末（鑑賞者）３０２の構成は、楽譜データの取得や楽曲データの送信を必要としないので、楽譜データ取得部３６３、楽曲データ送信部３６４は備えていない。さらに楽曲データの再生のみを行うため、ＭＩＤＩ楽器３３１（ＭＩＤＩ音源とスピーカーが内蔵されているものとする）またはＭＩＤＩ音源３３４とスピーカー３３５の何れかを備えてあればよい。
【００３９】
次に本実施例におけるデータ例について説明する。
【００４０】
まず、ＩＲＣサーバ１００を介してクライアント端末間で送受信されるデータ（クライアント端末（鑑賞者）３０２は受信のみ）について説明する。図４は、そのデータ例を示すもので、大きく分けてコメント部、属性情報部、楽譜データ部から構成する。コメント部はテキストデータで、例えば送信者が作成したパートについてのコメント等を記すものである。属性情報部は、送信する楽譜データに関連する情報で送信者のニックネームや楽曲ＩＤ、バージョン、演奏開始位置、送信小節数、送信日時等で構成する。属性情報部の情報は他の情報とともに管理情報記憶部３５０に記憶される。楽譜データ部はＭＩＤＩ楽器３３１を演奏することにより取得された楽譜データでＭＩＤＩデータである。ここでは、ＭＩＤＩチャンネルＮｏ．とＭＩＤＩデータとのセットが複数ある状態を示している。楽譜データは楽曲ＩＤとバージョンをキー情報として楽譜データ記憶部３４０に記憶される。
【００４１】
次に管理情報記憶部３５０に記憶される管理情報について説明する。管理情報の説明の前に、この実施例では「ｔａｒｏ」と言う人が音楽の共同制作を行うチャンネルを開設した人であり、チャンネルの開設によってＩＲＣの従来技術によりチャットが行われ、このチャットにより曲の制作に参加するメンバーあるいは鑑賞だけのメンバーが定まったものとする。そして、例えば「ｒａｒｏ」がこれから説明する管理情報記憶部３５０にこのメンバーを登録してこの管理情報記憶部３５０を各メンバーに送信するものとする。各メンバーはそれぞれの端末（クライアント端末）に受信したこの管理情報記憶部３５０を備えるものとする。
【００４２】
図５は、この「ｔａｒｏ」のクライアント端末が備える管理情報記憶部３５０のデータ例を示すもので、既に数回の楽曲データの遣り取りが行われた状態にあるものである。管理情報記憶部３５０は、メンバーＩＤ（ニックネーム）、区分、楽曲ＩＤ、バージョン、演奏開始位置、小節数、送受信日時で構成する。メンバーＩＤの「ｔａｒｏ」には「ｔａｒｏ」がチャンネルを開設したので区分には「ｃｈａｎｎｅｌ  ｏｐｅｒａｔｏｒ」が設定されている。チャンネルオペレータは曲の制作にも参加でき、ここでは楽曲ＩＤ「ｓｏｒａ」のバージョン「１．００」を作成し他のメンバーに送信している（バージョンが１．００なので、最初に他のメンバーに提示された曲である）。その曲の演奏開始位置は第１小節目からで、全体の曲の長さは３０小節からなっており、この楽曲データは、「２０００４年１２月２２日１９時３０分」に送信されたものである。同じ、「ｔａｒｏ」の２行目は、「ｓｏｒａ」の曲についてバージョンが「２．００」となっているが、これは先のバージョン１．００に引き続き、「３１」小節目から次のメロディ「２１」小節を作成し、他のメンバーに送信したことを示すものである。メンバーＩＤがｔａｒｏ以外のものは、そのメンバーＩＤから受信した楽曲データの内容を示している。
【００４３】
メンバーＩＤの「ｊｉｒｏ」と「ｓａｂｕｒｏ」は、曲の共同制作を行うメンバーであることを示す「ｃｏｍｐｏｓｅｒ」が区分に設定されている（これは、「ｔａｒｏ」がメンバーが定まった時点で設定したものである）。「ｊｉｒｏ」からは、「ｔａｒｏ」から送信された「ｓｏｒａ」を再生しながら演奏して得られた楽曲データを「２０００４年１２月２２日２１時５分」に受信している。その時のバージョンは「１．０１」、演奏開始位置は「１」小節目からで、小節数は「３０」小節である（「ｔａｒｏ」の送った曲に合わせて作成されたものであるので小節数は同じものとなる）。「ｓａｂｕｒｏ」も同様である。
【００４４】
メンバーＩＤの「ｈａｎａｋｏ」は鑑賞専門であるので、区分は「ｌｉｓｔｅｎｅｒ」が設定されている。従って、「ｔａｒｏ」は「ｈａｎａｋｏ」から楽曲データを受信することがないので、楽曲ＩＤ以降のフィールドは空白となっている。
【００４５】
次に、クライアント端末におけるシステムの処理フローについて説明する。
【００４６】
図６は例えば「ｔａｒｏ」のクライアント端末で最初に楽曲データを作成して他のメンバーに送信するフローである。先ず、ｔａｒｏが提示曲としてあるパート（例えばピアノ）のメロディラインをＭＩＤＩ楽器３３１で演奏すると、システムはその演奏された楽譜データを取得する。楽譜データの取得後、システムはｔａｒｏの指示に基づいて図示しないダイアロボックスを立ち上げ、これにｔａｒｏが入力した楽曲ＩＤ、バージョン、演奏開始位置（これは「１」となる）、小節数を取得する。この取得した情報を属性情報として管理情報記憶部３５０に格納する。また、取得した楽譜データに楽曲ＩＤとバージョンを付けて楽譜データ記憶部３４０に格納する（Ｓ１００〜Ｓ１２０）。
【００４７】
続いて、メンバーに対するコメント入力用のダイアロボックス（図示しない）を表示し、そこにｔａｒｏがコメントを入力して送信の指示を行うと、システムはこのコメントの情報と、属性情報および楽譜データを基にＩＲＣのメッセージコマンドを作成する。例えば、システムは図７に示すようにＩＲＣのメッセージコマンドを作成する。図７の「ｐｒｉｖｍｓｇ」はＩＲＣのプライベートメッセージのコマンドである。チャンネル名は接続しているチャンネルの名称。その後のコロン以降は「処理種別；」（例えば、コメントであれば「１」、属性情報なら「２」、ＭＩＤＩデータであれば「３」とする）に続いて、データが付け加えられる（Ｓ１３０、Ｓ１４０）。
【００４８】
作成したメッセージコマンドをＩＲＣサーバ１００に送信し、管理情報記憶部３５０に送信日時を記録する（Ｓ１５０、Ｓ１６０）。
【００４９】
以上の処理でＩＲＣサーバ１００は受け取ったデータをチャットデータとしてそのチャンネルのメンバーに配信することになる。
【００５０】
続いて、図８を用いてＩＲＣサーバ１００から「ｊｉｒｏ」のクライアント端末が楽曲データを受信し、この楽曲データをもとにｊｉｒｏが新たに作成した楽曲データを他のメンバーに送信する処理のフローを説明する。先ず、ｊｉｒｏのクライアント端末はチャットデータとしてＩＲＣサーバ１００から楽曲データを受信する。クライアント端末のシステムは、この楽曲データの処理種別を基にデータの種類を識別してコメントと属性情報と楽譜データとを抽出する（Ｓ２００、Ｓ２１０）。
【００５１】
コメントは、通常のチャットと同様にディスプレイに表示する。属性情報は、受信日時とともに管理情報記憶部３５０に格納する。さらに、楽譜データは楽譜データ記憶部３４０に格納する（Ｓ２２０〜Ｓ２４０）。
【００５２】
次に、ｊｉｒｏの指示により楽譜データ記憶部３４０から楽曲ＩＤを基に楽譜データを取り出す（今回受信したデータの他に前に受信した他のパートの楽譜データがあればそれらを含めた全ての楽譜データを取り出す）。さらに、ｊｉｒｏから繰り返しの小節、テンポ、拍子が指示されれば、それに応じて設定する。ｊｉｒｏはこの設定条件の下で楽譜データを再生の指示を行い、その再生に合わせてｊｉｒｏがＭＩＤＩ楽器３３１を演奏すると、システムは演奏したパートの楽譜データを取得する。演奏後、ｊｉｒｏの指示で立ち上がったダイアロボックス（図示しない）には再生した楽曲データの属性情報を参照して楽曲ＩＤや演奏開始位置、小節数、今回付与したバージョンなどを今回の演奏で得られた楽譜データに対する属性情報として表示する。ｊｉｒｏは必要に応じてこの表示を修正する。システムは、この表示した属性情報を管理情報記憶部３５０に格納するとともに、演奏によって取得した楽譜データに楽曲ＩＤとバージョンを付け楽譜データ記憶部３４０に格納する。（Ｓ２５０〜Ｓ２８０）。
【００５３】
以降はコメントを作成し、コメントと属性情報および楽譜データでＩＲＣのメッセージコマンドを作成してＩＲＣサーバに送信する処理は図６に示したＳ１１０〜Ｓ１５０と同様である（Ｓ２９０〜Ｓ３２０）。
【００５４】
Ｓ２６０において、再生に合わせて演奏を行うが、その後引き続き新たに演奏を行うか、あるいは再生せずにその後に続く曲を演奏するようにしてもよい。何れにしても演奏した楽譜データを取得し、属性情報に開始位置を記録しておけばその位置から楽譜データは再生される。
【００５５】
また、繰り返した小節やテンポ、拍子を変えて作られた楽曲データを再生する場合は、システムがそれ以前の楽曲データにこれらの情報を反映させて再生されるものとする（即ち、最新のバージョンの楽曲データに合わせて再生される）。
【００５６】
以上の処理を繰り返すことにより、各メンバーのクライアント端末の楽譜データ記憶部３４０と管理情報記憶部３５０には各メンバーが作成した楽曲データが蓄積され、曲は完成されていくことになる。
【００５７】
上記に示した処理フローに基づいて、より詳細にクライアント端末とＩＲＣサーバ間における処理と楽曲データの蓄積の状況を図９と図１０により説明する。ここでは、曲の制作が行えるクライアント端末１〜クライアント端末３の３台で構成されているものとする。先ず、クライアント端末１において提示する主旋律（メロディ）をＭＩＤＩ楽器で演奏し（演奏１）、楽曲データ１が取得される。この楽曲データはクライアント端末１の記憶部に格納され、続いてＩＲＣサーバに送信される。ここで演奏によって直接楽曲データが得られるように表現しているが、本来は演奏によって楽譜データが得られ、これに属性情報を付加して楽曲データとするものである。ここでは表現を省略してこのように表現している（Ｓ４００〜Ｓ４２０）。
【００５８】
ＩＲＣサーバはクライアント端末２とクライアント端末３に対して、楽曲データ１を配信する（ＩＲＣサーバは、従来技術のチャットデータの配信と同様に、このチャネルに参加しているメンバー配信を行っていることになる）。クライアント端末２は、楽曲データ１を受信し記憶部に格納する。そして、この楽曲データ１に合わせて演奏を行い（演奏１’）、楽曲データ１’を得る。楽曲データ１’はクライアント端末２に格納され、そのデータをＩＲＣサーバに送信する。クライアント端末３は単に楽曲データ１を受信し、そのデータを格納しておく。この時点で、クライアント端末１には楽曲データ１が、クライアント端末２には楽曲データ１と楽曲データ１’が、クライアント端末３は楽曲データ１が格納されていることになる（Ｓ４３０〜Ｓ４８０）。
【００５９】
ＩＲＣサーバは、楽曲データ１’をクライアント端末１とクライアント端末３に送信する。クライアント端末１とクライアント端末３はこの楽曲データ１’を格納する。そして、クライアント端末３は楽曲データ１と楽曲データ１’との再生に合わせて演奏（演奏１”）を行って楽曲データ１”を取得し、このデータを格納した後にＩＲＣサーバに送信する（Ｓ４９０〜Ｓ５４０）。
【００６０】
ＩＲＣサーバは、クライアント端末１とクライアント端末２に対して楽曲データ１”を送信する。図１０に移って、クライアント端末１は次に提示する主旋律を演奏し、楽曲データ２を得る。このデータをＩＲＣサーバに送信し、ＩＲＣサーバはクライアント端末２とクライアント端末３にこの楽曲データ２を配信する。クライアント端末２とクライアント端末３では、楽曲データ１〜楽曲データ１”および楽曲データ２を記憶しており、これらのデータに合わせて演奏を行い（演奏２’と演奏２”）、それぞれ楽曲データ２’と楽曲データ２”を得る。そして、クライアント端末２は楽曲データ２’をＩＲＣサーバに送信する。この時点で、クライアント端末１には楽曲データ１〜１”と楽曲データ２が、クライアント端末２には楽曲データ１〜１”と楽曲データ２、２’が、クライアント端末３には楽曲データ１〜１”と楽曲データ２、２”が格納されていることになる（Ｓ５５０〜Ｓ６８０）。
【００６１】
続いて、ＩＲＣサーバは楽曲データ２’をクライアント端末１とクライアント端末３に配信し、さらに続いて楽曲データ２”をクライアント端末１とクライアント端末２に送信する。この時点で、クライアント端末１〜３において、楽曲データ１〜１”と楽曲データ２〜２”が格納されていることになる（Ｓ６９０〜Ｓ７５０）。
【００６２】
以上の説明により、各クライアント端末で演奏して得られた楽曲データを一旦自身の端末に格納し、その後他のクライアント端末に送信するので、各端末は多少の時間送れがあっても同じ楽曲データが格納されるようになっている。以上により、ＩＲＣサーバを用いた楽曲共同制作が可能な方法を構築することができる。ＩＲＣサーバは従来そのままのチャット機能でよい。
【００６３】
上記の実施例のＳ６２０〜Ｓ７３０において、クライアント端末２はクライアント端末３が作成した楽曲データを見ることなしに自身が作成した楽曲データを送っている。また、クライアント端末３も同様である。このようなとき、例えばクライアント端末１がそれぞれ別の曲に発展させたいと考えたような場合は、一方の楽曲データの楽曲ＩＤを強制的に変え、他のメンバーに変更したデータ一式を送信するようにすればよい（そのような場合、２つの楽曲データが作られることになる）。
（実施例その２）
実施例その１では、ＩＲＣサーバを用いて行った。実施例その２では、従来の電子メールサーバの方法を用いて楽曲共同制作方法を構築する例を示す。図１１と図１２は、電子メールサーバであるＰＯＰ３サーバとＳＭＴＰサーバがＩＲＣサーバに代わって用いている。この場合、各クライアント端末の管理情報記憶部３５０にはメンバーＩＤに対するメールアドレスが記憶されているものとする（これは、例えば音楽の共同制作のリーダーが予め管理情報記憶部３５０にメンバーを設定して各メンバーに送信しておけばよい）。各クライアント端末は、演奏によって得られた楽曲データをこのメールアドレスを参照してＳＭＴＰに送信する。クライアント端末では、メーラーが定められた時間毎にＰＯＰ３サーバに対して自分宛の電子メールが来ているかどうかを照会し、来ていればこの電子メールを取得する。電子メールには、コメントと属性情報を本文に、添付資料としてＭＩＤＩデータを付けるようにしておけばよい。図１１と図１２は、実施例その１と以上に述べた部分が異なるだけで、あとは同様の方法でよい。それぞれのクライアント端末での演奏、楽曲データの送信、受信は実施例その１と同じであるので説明は省略する。このようにすることにより、従来の電子メールの方法を利用しても楽曲の共同制作が可能である。
【００６４】
これはまた、Ｐｅｅｒ  ｔｏ  Ｐｅｅｒの通信方法を用いても同様に行うことができる。
【００６５】
以上の実施例に関し、さらに以下の付記を開示する。
【００６６】
（付記１）
複数のメンバーがネットワークを介して楽曲を共同制作する楽曲共同制作方法であって、
楽譜データに属性情報が付加された第１の楽曲データを前記メンバーから受信する楽曲データ受信手順と、
前記属性情報から楽曲ＩＤを抽出し、該楽曲ＩＤをキー情報として前記楽譜データと前記属性情報とをそれぞれを記憶部に記憶する受信データ記憶手順と、
前記楽曲ＩＤにより前記記憶部から前記属性情報と楽譜データとを取り出し、該属性情報に基づいて該楽譜データを再生し、該再生に合わせて演奏された楽譜データを取得する楽譜データ取得手順と、
前記取得した楽譜データに、該楽譜データの属性情報を付加した第２の楽曲データを全ての前記メンバーに送信する楽曲データ送信手順と
を有することを特徴とする楽曲共同制作方法。
【００６７】
（付記２）
前記楽曲共同制作方法は、さらに前記記憶された楽譜データに対して小節数の繰り返し、テンポ、音量および拍子の変更を受け付ける編集手順を有し、
前記楽譜データ取得手順は、前記編集された楽譜データを再生し、該再生に合わせて演奏された楽譜データを取得する
ことを特徴とする付記１記載の楽曲共同制作方法。
【００６８】
（付記３）
前記楽譜取得手順は、前記楽譜データの再生に合わせた演奏に加えて、引き続き新たに演奏された楽譜データを取得する
ことを特徴とする付記１または付記２記載の楽曲共同制作方法。
【００６９】
（付記４）
複数のメンバーがネットワークを介して楽曲を共同制作する楽曲共同制作方法であって、
楽譜データに属性情報とメッセージとが付加された第１の楽曲データを前記メンバーから受信する楽曲データ受信手順と、
受信した前記第１の楽曲データを前記楽譜データと前記属性情報とメッセージとに分け、該属性情報から抽出した楽曲ＩＤをキー情報とし該楽譜データと該属性情報とをそれぞれ記憶部に記憶すると共に、該メッセージを表示部に表示する受信データ記憶手順と、
前記楽曲ＩＤにより前記属性情報と楽譜データとを取り出し、該属性情報に基づいて前記楽譜データを再生し、該再生に合わせて演奏された楽譜データを取得する楽譜データ取得手順と、
前記取得した楽譜データに、該楽譜データの属性情報とメッセージとを付加した第２の楽曲データを全ての前記メンバーに送信する楽曲データ送信手順と
を有することを特徴とする楽曲共同制作方法。
【００７０】
（付記５）
前記楽曲共同制作方法は、管理者端末と制作者端末と鑑賞者端末とがネットワークを介して接続しており、
前記管理者端末は前記制作者と鑑賞者とから参加許諾の依頼情報を受信したとき該参加許諾の回答を送信し、
前記制作者端末は、前記管理者端末から参加許諾を得て前記メンバーに前記楽曲データの送受信を行い、
前記鑑賞者端末は、前記管理者端末から参加許諾を得て前記楽曲データの受信を行う
ことを特徴とする付記１記載の楽曲共同制作方法。
【００７１】
（付記６）
複数のメンバーがネットワークを介して楽曲を共同制作する楽曲共同制作プログラムであって、
楽譜データに属性情報が付加された第１の楽曲データを前記メンバーから受信する楽曲データ受信手順と、
前記属性情報から楽曲ＩＤを抽出し、該楽曲ＩＤをキー情報として前記楽譜データと前記属性情報とをそれぞれを記憶部に記憶する受信データ記憶手順と、
前記楽曲ＩＤにより前記記憶部から前記属性情報と楽譜データとを取り出し、該属性情報に基づいて該楽譜データを再生し、該再生に合わせて演奏された楽譜データを取得する楽譜データ取得手順と、
前記取得した楽譜データに、該楽譜データの属性情報を付加した第２の楽曲データを全ての前記メンバーに送信する楽曲データ送信手順と
をコンピュータに実行させるための楽曲共同制作プログラム。
【図面の簡単な説明】
【００７２】
【図１】発明の原理図である。
【図２】全体のシステム構成例である。
【図３】クライアント端末の構成例である。
【図４】送受信されるデータ例である。
【図５】管理情報のデータ例である。
【図６】処理のフロー例（その１）である。
【図７】ＩＲＣのメッセージコマンドの作成例である。
【図８】処理フロー例（その２）である。
【図９】実施例１のセッション処理フロー例（その１）である。
【図１０】実施例１のセッション処理フロー例（その２）である。
【図１１】実施例２のセッション処理フロー例（その１）である。
【図１２】実施例２のセッション処理フロー例（その２）である。
【符号の説明】
【００７３】
１０    楽曲データ受信手順 
２０    受信データ記憶手順 
３０    楽譜データ取得手順 
４０    楽曲データ取得手順 
１００  ＩＲＣサーバ
２００  ネットワーク
３００  クライアント端末（管理者）
３０１  クライアント端末（制作者）
３０２  クライアント端末（鑑賞者）
３１０  ＣＰＵ
３２０  通信制御部
３３０  入出力制御部
３３１  ＭＩＤＩ楽器
３３２  ディスプレイ
３３３  キーボード
３３４  ＭＩＤＩ音源
３３５  スピーカー
３４０  楽譜データ記憶部
３５０  管理情報記憶部
３６０  楽曲共同制作プログラム
３６１  楽曲データ受信部
３６２  受信データ記憶部
３６３  楽譜データ取得部
３６４  楽曲データ送信部
【図１】
2006215210.tif 000003
【図２】
2006215210.tif 000004
【図３】
2006215210.tif 000005
【図４】
2006215210.tif 000006
【図５】
2006215210.tif 000007
【図６】
2006215210.tif 000008
【図７】
2006215210.tif 000009
【図８】
2006215210.tif 000010
【図９】
2006215210.tif 000011
【図１０】
2006215210.tif 000012
【図１１】
2006215210.tif 000013
【図１２】
2006215210.tif 000014