JP6960674B2 - 作曲支援サーバ、作曲支援システム、作曲支援方法及び作曲支援プログラム - Google Patents

Description

本開示は、過去に作曲された曲情報のデータベースを用いて作曲を行う作曲支援サーバ、作曲支援システム、作曲支援方法及び作曲支援プログラムに関する。

従来から、自動的に楽曲の作曲を支援する方法は知られている。例えば、特許文献１では、特に既存楽曲の楽譜情報からフレーズデータを切出し、該フレーズデータを特徴ベクトルで表現した後、２つの特徴ベクトル間の距離により適合度を判定してフレーズデータを接合し、メロディを自動的に生成し作曲を行う方法が知られている。

また、作曲作業は、より一層人間の心に響くメロディを作曲すること、すなわち多くの聴衆の支持を獲得できるメロディを作曲することが求められるという側面もある。

特開２００７−２１９１３９号公報

しかし、特許文献１では、特徴量に基づく楽曲の自動生成を行うことができるが、その楽曲が聴衆からの指示を獲得できる可能性を高めるための手法は取り入れられていなかった。

そのため、本開示では、過去の楽曲構造であるストラクチャデータと過去の楽曲のメロディの断片であるリックデータから、新たなメロディを構成することで、聴衆からの支持を獲得できる可能性の高い楽曲を構成する作曲支援サーバ、作曲支援システム、作曲支援方法及び作曲支援プログラムを提供することを目的とする。

上記の課題を解決するために、本開示の作曲支援サーバは、過去に作曲された楽曲を構成するメロディの一部であって音程と音価の情報の配列により構成される複数のリックデータを記憶するリック記憶部と、楽曲の構造であってリックデータを配置する規則である複数のストラクチャデータを記憶するストラクチャ記憶部と、リック記憶部からリックデータを選択し、ユーザの指示に基づきストラクチャ記憶部から選択されたストラクチャデータの規則に従いリックデータを配置することで新たなメロディを生成するジェネレータエンジン部と、を備える。

また、本開示の作曲支援システムは、ユーザが操作するユーザ端末と、過去に作曲された楽曲を構成するメロディの一部であって音程と音価の情報の配列により構成される複数のリックデータを記憶するリック記憶部と、記楽曲の構造であってリックデータを配置する規則である複数のストラクチャデータを記憶するストラクチャ記憶部と、リック記憶部からリックデータを選択し、ユーザ端末からの指示に基づきストラクチャ記憶部から選択されたストラクチャデータの規則に従いリックデータを配置することで新たなメロディを生成するジェネレータエンジン部と、を備える。

また、本開示の作曲支援方法は、過去に作曲された楽曲を構成するメロディの一部であって音程と音価の情報の配列により構成される複数のリックデータと、楽曲の構造であってリックデータを配置する規則である複数のストラクチャデータと、を用いて、ジェネレータエンジン部が、リックデータを選択し、ユーザの指示に基づき選択されたストラクチャデータの規則に従いリックデータを配置することで新たなメロディを生成する。

また、本開示の作曲支援プログラムは、過去に作曲された楽曲を構成するメロディの一部であって音程と音価の情報の配列により構成される複数のリックデータと、楽曲の構造であってリックデータを配置する規則である複数のストラクチャデータと、を用いて、リックデータを選択し、ユーザの指示に基づき選択されたストラクチャデータの規則に従いリックデータを配置することで新たなメロディの生成をコンピュータによって実現する。

上記の作曲支援サーバ、作曲支援システム、作曲支援方法及び作曲支援プログラムによれば、過去の楽曲構造であるストラクチャデータと過去の楽曲のメロディの断片であるリックデータから、新たなメロディを構成することで、聴衆からの支持を獲得できる可能性の高い楽曲を構成することができる。

実施形態に係る作曲支援システムの構成を示す概略ブロック図である。 実施形態に係る作曲支援サーバの構成を示す概略ブロック図である。 実施形態に係る鍵盤の中央音域部分を示す図である。 実施形態に係るユーザがソングを選択するための表示画面を示す図である。 実施形態に係る選択したソングに基づく楽曲の構成を示すための表示画面を示す図である。 実施形態に係る選択したソングに基づく楽曲の構成を示すための表示画面を示す図である。 実施形態に係る楽曲データの蓄積の動作について説明するためのフローチャートである。 実施形態に係る作曲支援の動作について説明するためのフローチャートである。 実施形態に係るコンピュータの構成を示す概略ブロック図である。

以下、本開示の実施形態について説明する。なお、以下に説明する実施形態は、特許請求の範囲に記載された本開示の内容を不当に限定するものではない。また本実施形態で説明される構成の全てが、本開示の必須構成要件であるとは限らない。

＜用語の説明＞
まず、本開示の実施形態で用いる、ソング、メロディ、リック、ストラクチャ、ハーモニーの各用語について説明する。

＜＜ソング＞＞
ソング(Song)は、以下で説明するメロディ、ハーモニー、および、ストラクチャの情報が結合した楽曲を意味する。ソングは、ユニークＩＤが付されて楽曲単位に管理される。ユニークＩＤは作曲年、順位、分類、通し番号、BPM(Beat Per Minute)の情報により構成される。

ユニークＩＤについて具体的に下記の記述例１を用いて説明する。
［記述例１］
2012051000000000T129

記述例１で示すユニークＩＤの左から４桁は、そのユニークＩＤが付された楽曲の作曲年を示す。そのため記述例１の楽曲は2012年に作曲されたものである。次の２桁はその楽曲の順位を示す。順位は、ヒットチャート等による指標により定量化された値であり、その作曲年におけるヒットの程度を示す値である。記述例１の楽曲は、2012年に5位の順位であったものである。なお、順位情報の無い楽曲は00と記述する。次の１桁は、その楽曲の音楽分野の分類を示す値であり、例えば０は洋楽曲、１は邦楽曲、３から９が自動生成された楽曲のように示される。記述例１は１であることから、この楽曲は邦楽曲である。次の9桁は通し番号であり、楽曲の管理番号である。最後にＴで始まる3桁は、後述するBPMの値を示しており、一般的なテンポ情報に対応する。記述例１ではT129であるため、この楽曲は129BPMである。

＜＜メロディ＞＞
メロディ(Melody)は、ソングの１要素を構成する単旋律の音の並びである。メロディは、１音の音名を示す「C」から「B」の文字と、音程を示す１桁の数値と、音価を示す２桁の値によって記述し、それぞれを「/」で区切りながら記述する。休符は「r」 と音価を示す２桁の値によって記述する。音名とは、音の振動数をもとに決められた音の高さであり、例えば440Hzの音は「A」で記述する。半音上がる場合には「+」で記述し、例えば「C4」が半音上がったC#は「C4+」として記述する。次に、本開示における音程とは、オクターブの位置を示す数字であり、例えば「C4」の１オクターブ高い音は「C5」と記述する。音価とは、ある音または休止に与えられる時間の長さを示すものである。一般的な楽譜においては、全音符を基準として１の音価を与え、半分の長さを２分音符、さらに半分の長さを４分音符として定義される。しかし、本開示における音価は、後述するリニア値として、音の長さの絶対値を示すものとして定義するものである。また、本開示において、例えば楽譜において４分音符のスタッカートである場合、「C401/r03」のように、音と休符の組み合わせで記述する。またスラーは「/」の代わりに「_」を用いて音の接続状態を記述する。例えば、「C4」と「D4」がスラーの場合、「C404_D404」と記述する。上記の記述方法により、メロディは、例えば下記の記述例２のように記述できる。
［記述例２］
r04/E402/E402/E402/r04/E402/D402/E402/E402/r02/C404_D404/C401/r03/C401/r03/…

＜＜リック＞＞
リック（Lick）は、メロディを断片化したものであり、３から１０程度の音の連なりで構成される。リックは特徴値として、リックリニア値(Linear値)、韻律値(Cadence値)、リック傾向値(Tendency値)、および、評価値(Value値)で構成される４次元のベクトルとして特徴量が付与され管理される。例えば、上記で例に挙げたメロディからリックを抽出した場合、下記の記述例３で記述できる。
［記述例３］
r04/C402/C402/C402/r04/E402/D402/E402/E402/r02/

次に、各リックに付与される特徴値を示す４次元のベクトルである特徴量の各要素について説明する。

リニア値はリックを構成する各音、休符に付されている音価を合計した音価情報である。音価の情報は、リニア値として管理し、4リニア値(4Linear)はBPMで1Beatと定義する。例えば、上記の記述例３のリックの場合、音価は各音、休符に付与されている音価は04、02、02、02、04、02、02、02、02、02となる。そのため、当該リックのリニア値は合計値である24となる。リニア値は、音符（または休符）が拍に対する相対的な長さを示すものであることから、拍の長さ（テンポ）が変わればそれに伴って同じリニア値も長くなり短くなるように記述する。

２つ以上の音で構成されたメロディは、音楽的に次の音に進みたいという力を持つ。この力に従って導かれた音へとメロディが進む。韻律値は、隣接するリック間の隣接する音の差を示す値であり、リックの音が進もうとする次のリックとの関係を規定する値である。具体的には、あるメロディを構成するa番目のリックであるLick(a)の韻律値は、次の式（１）によって算出することができる。
韻律値=Lick(a)の終音とLick(a+1)の初音の差=Lick(a+1)の初音-Lick(a)の終音…（１）

メロディを分解して複数のリックを抽出した場合、例えば、前のリック(Lick(a))の終音が「C4」であり、隣接する次のリック(Lick(a+1))の初音が「G4」である場合、
・Lick(a)の終音=C4=60
・Lick(a+1)の初音=G4=67
となることから式（１）より、
韻律値=67-60=+7
を、算出することができる。

ここで、算出に用いた数値は、「C4」を60、「G4」を67としている。この値は半音を含めた１オクターブを12の値として、例えば、各音を図３に示すように割り当てる。図３は、ピアノやキーボード等の鍵盤の中央音域部分を示す図である。すなわち、「C4」の60の1オクターブ上の「C5」は60+12=72と割り当てられる。

リック傾向値は、１つのリック内での音の推移の傾向を数値化した値である。具体的には、あるメロディを構成するa番目のLickをLick(a)としてのリック傾向値は、次の式（２）によって算出することができる。
傾向値=Lick(a)の初音とLick(a)の終音の差=Lick(a)の終音-Lick(a)の初音…（２）

例えば、リックの初音が「G4」であり、リックの終音が「C4」である場合、
・Lick(a)の初音=G4=67
・Lick(a)の終音=C4=60
となることから式（２）より、
傾向値=60-67=-7
と算出することができる。ここで、算出に用いた数値は、韻律値を算出したときに使用した各音に対応するものである。

最後に評価値について説明する。評価値は、複数のリックのうち、それぞれのリックが、どの程度使用されたかを示す指標である。すなわち、本作曲支援システム１の動作に伴い、多くの人が、Lick(a)を使用した場合には、そのLick(a)の評価値が変化するものである。評価値は、その使用履歴から、Lick(a)がこれまでにどの程度「より一層人間の心に響くメロディ」の中で使用されたかを示すものと仮定することができる。評価値の初期値は、そのリックデータのもととなるソングのユニークＩＤの中の、順位によって定めることができる。１位の場合には10、２位の場合には9、のように付され10位が1となる。順位情報が無いソングの場合には1が付される。また、後述するリジェネレータ部で生成されてリック記憶部１９３に記憶されるリックデータも1が付される。なお、評価値は、一つの楽曲中で複数回同じリックデータが使用された場合も１の増加とする。なお、各リックデータには使用履歴からの使用度数データを付与し、そのデータに応じた順位付け、リックデータが使用される毎に更新を行い、順位を入れ替えるようにしてもよい。

このようにして、各リックには、そのリックの特徴量として４次元のベクトルが付与さる。例えば、リニア値が24、韻律値が+7、傾向値が-7、評価値が8であったとすると、（24、+7、-7、8）の特徴量のベクトルが付与されることになる。

＜＜ストラクチャ＞＞
ストラクチャ(structure)は、楽曲の構造を記述するものである。音楽は一般に、楽曲の導入部分であるヴァース（Verse、所謂Ａメロ）、楽曲の展開部分であるブリッジ（Bridge、所謂Ｂメロ）、楽曲の盛り上がりであるコーラス（Chorus、所謂サビ）の各構成要素により構成されることが多い。そのため、楽曲はまず、ヴァース、ブリッジ、コーラスに分解することができる。ストラクチャデータの構造について、下記の記述例４を用いて説明する。

[記述例４]
structure{
V:[a016b016a016c012x004d032e028x004]-5
V:[d032e028x004d032e028]-5
C:[f016f016f016g016f016f016f016h024]-7
B:[i016j016i016k012x004i016j016i016l024]+9
C:[f016f016f016g016f016f016f016h024]-7
}

記述例４は、ある楽曲のストラクチャを示している。この楽曲は、ヴァース、ヴァース、コーラス、ブリッジ、コーラスの順で演奏される構造である。そのため、ストラクチャはヴァースを示すV、ブリッジを示すB、コーラスを示すCの各符号が付されたセクション(Section)に分割して記述することができる。セクションは、記述例４の１行に相当するものである。

次に、セクションについて説明する。セクションは、さらにブロック(block)に分割されて記述される。ブロックは楽曲を構成するメロディを断片化したものであり、曲の初めから、a、ｂ、cの順に名称を割り当てられ、先のメロディの断片が再度出現する場合には、同じブロック名を割り当てる。名称の後ろには、各ブロックの音価の合計値としてセクションリニア値が付される。そのため、記述例４の１行目を見ると、
[a016b016a016c012x004d032e028x004]
で記述されており、これは16の音価を持つaのブロックと、次に16の音価を持つbのブロック、さらにaのブロックが再度繰り返される構造が記述されている。なおx004は4の音価を持つ無音部である。よって、記述例４のセクションリニア値は、
16+16+16+12+4+32+28+4＝128
となる。

また、セクションは、セクション毎にセクション傾向値を持つ。すなわち、セクションを構成する初音と終音の差をセクション傾向値として有する。例えば、記述例４の１行目を見ると、
V:[a016b016a016c012x004d032e028x004]-5
であることから、a016のブロックの初音とe028のブロックの終音の差としてのセクション傾向値は-5であることを示している。

このように、ストラクチャは、楽曲の構造であってリックデータを配置するための規則であるブロック、セクションリニア値、セクション傾向値を有する複数のセクションからなるストラクチャデータにより記述することができる。

＜＜ハーモニー＞＞
ハーモニー(Harmony)は、メロディを倍音で補助し和音を構成するものである。ハーモニーはメロディの束として記述する。また、記述方法はメロディと同じである。ハーモニーデータの構造について、下記の記述例５を用いて説明する。
［記述例５]
harmony{
@H015
E306/E306/E304/G3+06/G3+06/G3+04/E306/E306/E304/E306/E306/E304/
@H016
C306/C306/C304/E306/E306/E304/C306/C306/C304/C306/C306/C304/
@H017
G206/G206/G204/B206/B206/B204/G206/G206/G204/G206/G206/G204/
@H018
C104/C106/C106/E104/E106/E106/A104/A106/A106/G104/G106/G106/
}

記述例５のハーモニーデータは@H015、@H016、@H017、@H018の４つのメロディで構成される和音を記述するものである。すなわち、記述例５は、「C1」、「G2」、「C3」、「E3」の４音の和音が06の音価で始まるものを記述している。

以上説明してきた、本開示におけるソング、メロディデータ、リックデータ、ストラクチャデータ、ハーモニーデータについて、その記述法は一例であって、各概念を記述できるものであれば他の記述法で代替することができるものである。

＜構成＞
図１を用いて本開示の実施形態における、ユーザ端末３０１からの操作により、作曲支援サーバ１０１内に記憶された過去に作曲された曲情報のデータベースを用いて作曲を行う作曲支援システム１の構成及びその概要について説明する。なお、図１は、本実施形態の作曲支援システム１のブロック図である。

本実施形態の作曲支援システム１は、図１に示すように、作曲支援サーバ１０１と、作曲支援サーバ１０１を操作するための管理端末２０１と、ユーザ端末３０１とが、例えばインターネットやＬＡＮ等のネットワークＮＷに接続可能に構成されている。

作曲支援サーバ１０１は、コンピュータやメインフレーム等の情報処理装置で構成される。詳細は後述する。

管理端末２０１は、作曲支援サーバ１０１を操作するための装置である。管理端末２０１は、コンピュータ、スマートフォン、携帯電話、ＰＨＳ、ＰＤＡ、腕時計、スマートウォッチ等の情報処理装置であり、インターネット（ＷＡＮ）、ＬＡＮなどのネットワークＮＷを介して作曲支援サーバ１０１に接続可能な装置である。なお、管理端末２０１と作曲支援サーバ１０１間の接続は、有線でもよいし無線でもよい。また、作曲支援サーバ１０１と一体に構成されていてもよい。また、後述するユーザ端末３０１で代替してもよい。

ユーザ端末３０１は、作曲を行おうとするユーザが作曲支援サーバ１０１にアクセスして作曲を行うための装置である。ユーザ端末３０１は、スマートフォン、携帯電話、ＰＨＳ、コンピュータ、ＰＤＡ、腕時計、スマートウォッチ、ヘッドマウントディスプレイ、画像生成装置等の情報処理装置であり、インターネット（ＷＡＮ）、ＬＡＮなどのネットワークＮＷを介して作曲支援サーバ１０１に接続可能な装置である。なお、ユーザ端末３０１と作曲支援サーバ１０１間の接続は、有線でもよいし無線でもよい。また、ユーザ端末３０１が管理端末２０１の機能を兼ねてもよい。

また、ユーザ端末３０１は、インストールされた専用のアプリケーションソフトウェアによって作曲支援サーバ１０１にアクセスしてもよい。また、コンピュータにインストールされたＤＡＷ（Ｄｉｇｉｔａｌ Ａｕｄｉｏ Ｗｏｒｋｓｔａｔｉｏｎ）ソフトウェアのプラグインソフトウェアからアクセスしてもよい。また、作曲支援サーバ１０１や、別途サーバ(不図示)が提供する動作環境（ＡＰＩ（アプリケーションプログラミングインタフェース）、プラットフォーム等）を利用して作曲支援サーバ１０１にアクセスしてもよい。

次に、図２を用いて第１の実施形態における、作曲支援サーバ１０１の構成及びその概要について説明する。なお、図２は、本実施形態の作曲支援サーバ１０１のブロック図である。

通信部１１１は、ネットワークＮＷを介して管理端末２０１やユーザ端末３０１と通信を行う通信インタフェースである。通信部１１１は、管理端末２０１から送信された音楽情報や、ユーザ端末３０１から送信された制御信号を受信し、またユーザ端末３０１にＭＩＤＩデータを送信する。

ディストリビュータ(Distributor)部１２１は、管理者が管理端末２０１から送信されるソングに対応する音楽情報を、管理者の指示により、ストラクチャ、メロディ、ハーモニーに対応するストラクチャデータ、メロディデータ、ハーモニーデータとして分配する処理部である。ディストリビュータ部１２１で分解されたストラクチャデータは、後述するストラクチャ記憶部１９１に記憶される。また、分解されたハーモニーデータは、後述するハーモニー記憶部１９２に記憶される。また分解されたメロディデータは、後述するフラグメンター部１２２に送信される。分配されたストラクチャデータ、メロディデータ、ハーモニーデータには、送信されたソングに対応するユニークＩＤが付与される。

フラグメンター(Fragmentor)部１２２は、ディストリビュータ部１２１から送信されたメロディを、メロディを構成するリックデータに分解し、それぞれに管理者が選択したヴァース、ブリッジ、コーラスのいずれかに該当するかの情報に基づき、ヴァース、ブリッジ、コーラス を示すV、B、Cのリック属性情報をそれぞれ付与する処理部である。リック属性情報が付与されたリックデータは、メジャラー部１２３へ送信される。

メジャラー(Measurer)部１２３は、フラグメンター部１２２から送信された各リックデータの特徴量を算出し、特徴量を付与する処理部である。その際、当該リックデータの元となるリックがメロディ内のどの位置に存在していたかを示す情報は削除される。そして、特徴量を付与された各リックデータは、それぞれのリック属性情報に応じて、リック記憶部１９３のうちリック記憶部(Verse)１９３ａ、リック記憶部(Bridge)１９３ｂ、リック記憶部(Chorus)１９３ｃに送信され、記憶される。

ジェネレータエンジン(Generate Engine)部１３１は、ストラクチャ記憶部１９１、ハーモニー記憶部１９２、リック記憶部１９３に記憶されているストラクチャデータ、ハーモニーデータ、リックデータに基づいて、曲データを生成する処理部である。具体的には、ユーザがユーザ端末３０１から選択したストラクチャに対して選択したストラクチャが有する規則に合致するリックデータを選択する。リックデータの選択においては、前に選択されたリックデータの韻律値に基づいて、次に選択するリックデータの候補を選択する。そのため、リックデータが配列した際に、リックデータのつながりが唐突で違和感のあるものとならず、音楽的に自然なものとなる。また、複数のリックデータにより完成されたメロディと、それに対応するセクションの傾向値が一致するようにリックデータを選択する。このように、次のリックデータの選択は、前のリックデータからの制限を受けることになる。なお、リックデータの選択において、韻律値は、オクターブの違い、すなわち±１２、±２４の値は韻律値が適合したものとすることができる。

また、ジェネレータエンジン部１３１は、選択するリックデータ候補となりうるリックをリック記憶部１９３から抽出し、それぞれに各リックデータに付与されている特徴量の中の評価値に応じて確率的に選択を行う。すなわち、ジェネレータエンジン部１３１は、評価値が大きいリックデータであるこれまで使用されてきた回数の多いリックデータより高い頻度で選択されるようにアルゴリズムが構成されている。このように、リックデータの選択において、ある程度の自由度が与えられることで、ユーザが同じソングが選択した場合でも、常に同じメロディとならずに新たなメロディを生成することができる。

ブラックエンジン(Black Engine)部１３２は、ジェネレータエンジン部１３１で付与されたハーモニーデータが、生成されたメロディデータに対して適切な倍音関係になっているかを確認する。ブラックエンジン部１３２は、メロディデータとハーモニーデータを、1リニア値毎に倍音関係を確認する。

リジェネレータ(Regenerator)部１３３は、完成した楽曲について、ユーザによる修正リクエストにより、修正の指示を受け付ける処理部である。修正指示のあった部分をジェネレータエンジン部１３１に戻し、リックデータの選択を繰り返すことで、修正指示のあった部分の後のリックデータの整合性が取れるように構成される。

また、リジェネレータ部１３３は、修正された部分のリックデータが、既存のリックデータであるかを判別する。すなわち、修正部分のリックデータが、リック記憶部１９３に記憶されたリックデータと同じであるかを判別する。リジェネレータ部１３３は、新たなリックデータであると判別すると、メジャラー部１２３でそのリックデータの特徴量を新たに算出し、新たなＩＤを付与してリック記憶部１９３に記憶する。これにより、新たなリックデータを作曲資源として蓄積することができる。

ＭＩＤＩ−オーディオコンバータ部１８１は、構成した楽曲をＭＩＤＩデータに変換する。変換したＭＩＤＩデータは、ユーザ端末３０１の音源で発音することでユーザの試聴を可能にする。

ストラクチャ記憶部１９１は、ディストリビュータ部１２１から送信されたストラクチャデータを記憶する記憶部である。また、ハーモニー記憶部１９２は、ディストリビュータ部１２１から送信されたハーモニーデータを記憶する記憶部である。

リック記憶部１９３は、メジャラー部１２３で特徴量が付与されたリックデータを記憶する記憶部である。リックデータはそれぞれのリック属性情報に応じて、リック記憶部１９３の中のリック記憶部(Verse)１９３ａ、リック記憶部(Bridge)１９３ｂ、リック記憶部(Chorus)１９３ｃに記憶する。なお、各リックデータは、リックデータの使用状況に応じて評価値が動的に変化し、各リック記憶部１９３ａ、１９３ｂ、１９３ｃの中で順位付けが行われる。

＜表示画面＞
次に、図４、５、６を用いて、ユーザ端末３０１から作曲支援の操作を行う際のユーザ端末３０１のディスプレイ３１０に表示される画面について説明する。なお、この場合のユーザ端末３０１はスマートフォンやタブレット端末等を想定しているが、コンピュータにインストールされたＤＡＷソフトウェアのプラグインソフトウェアが表示する画面であっても同様である。

図４は、ユーザが作曲支援サーバ１０１からソングを選択するための表示画面である。画面には、左側にソングの名称と、その右側にそのソングのＢＰＭ値が表示される。また、縦方向に複数のソングが配列される。ユーザは、過去の名曲であるソングの名称を想起し、またＢＰＭ値から曲のテンポを想起し、作曲のベースとなるソングを選択することができる。

図５、図６は、選択されたソングに基づき新たに生成された楽曲の構造の表示画面である。構成要素表示３２１〜３２９は、選択されたソングの構成要素である、ヴァース、ブリッジ、コーラスの割り付けを示す表示である。例えば、図５では構成要素表示３２１はヴァース、構成要素表示３２２もヴァース、構成要素表示３２３はコーラス、構成要素表示３２４はブリッジ、構成要素表示３２５は構成要素表示３２３のコーラスと同じコーラスを示すものである。すなわち、このソングは、ヴァース、ヴァース、コーラス、ブリッジ、コーラスの順で構成されるストラクチャデータに基づくものである。また、円の一周が一曲の構成であり、割り付けの分配はその部分の再生長さに対応する。

次に、再生位置表示バー３３０は、再生アイコン３３１を押した場合に、選択されたソングに基づいて新たに生成された楽曲を再生する場合の再生位置を示している。再生位置表示バー３３０は、紙面の上方を起点として右回りで回転する。図５では、構成要素表示３２３のコーラス部分を再生している状態である。早送りアイコン３３２を押すことで、再生位置表示バー３３０を速く順方向に移動させ、また巻き戻しアイコン３３３を押すことで、再生位置表示バー３３０を速く逆方向に移動させ再生位置を変更することができるメロディ音色切換えアイコン３３４は、楽曲を再生する際のメロディの音を変更するものであり、図５では３種類の音から選択することができる。また、ハーモニー音色切換えアイコン３３５は再生する際のハーモニーの音を変更するものであり、図５、図６では５種類の音から選択することができる。ユーザ端末３０１は、メロディ音色切換えアイコン３３４は、ハーモニー音色切換えアイコン３３５のよる選択により、再生するＭＩＤＩの楽器アサインを変更することで、再生音を変化させることができる。

図６は、図５で説明したものと別のソングを選択した場合であり、構成要素表示３２６はヴァース、構成要素表示３２７はコーラス、構成要素表示３２８はブリッジ、構成要素表示３２９は構成要素表示３２７のコーラスと同じコーラスを示すものである。このように、選択されるソングによって、さまざまな楽曲の構造を切換え、新たな楽曲を生成することができる。

＜処理の流れ＞
次に、本開示の実施形態に係る作曲支援システムの動作について、図７、図８に示すフローチャートを参照しながら説明する。

＜＜楽曲データの蓄積＞＞
図７のフローチャートは、楽曲データの蓄積を行う動作について、作曲支援サーバ１０１、管理端末２０１の各動作の関連状態を示している。ステップＳ１０１において、管理端末２０１は、ユーザからの楽曲情報の入力を受け付け、受け付けた楽曲情報を作曲支援サーバ１０１に送信する。ユーザは、入力する楽曲であるソングを、メロディデータとハーモニーデータとストラクチャデータの楽曲情報として入力する。メロディデータは、さらにメロディを構成する音の断片としてリックデータとなるメロディの区切り情報が入力されている。ストラクチャデータは、ストラクチャを構成するセクションに分割されており、それぞれのセクションに含まれるリックをリニア値としたブロック情報に分割されている。また、各セクションは、それぞれV（Verse）、C（Chorus）、B（Bridge）のセクション属性情報が付与されている。また、ソングに対応するユニークＩＤを情報として入力する。入力されたメロディとハーモニーとストラクチャは、ユニークＩＤと対応して作曲支援サーバ１０１に送信される。

ステップＳ１０２において、ディストリビュータ部１２１は、管理端末２０１から送信された楽曲情報を、メロディデータとハーモニーデータとストラクチャデータに分類する。ディストリビュータ部１２１は、分類したストラクチャデータをストラクチャ記憶部１９１に送信する。また、分類したハーモニーデータをハーモニー記憶部１９２に送信する。また、メロディデータをフラグメンター部１２２に送信する。

ステップＳ１０３において、ストラクチャ記憶部１９１はディストリビュータ部１２１で分類されたストラクチャデータを、そのストラクチャデータに対応するソングのユニークＩＤとともに記憶する。ストラクチャデータは、複数のセクションで構成され、セクション内の音価の合計値であるセクションリニア値と、セクションの初音と終音の差であるセクション傾向値が算出され、当該セクションに付与される。

ステップＳ１０４において、フラグメンター部１２２は、ディストリビュータ部１２１から送信されたメロディデータをリックデータに分解する。具体的には、フラグメンター部１２２は、メロディデータに付与されたリックの区切り情報に基づいて、メロディデータを複数のリックデータに分解する。また、その際に、フラグメンター部１２２は、各リックデータに、それぞれV（Verse）、B（Bridge）、C（Chorus）のリック属性情報を付与する。

ステップＳ１０５において、メジャラー部１２３は、各リックデータの特徴量であるリックリニア値、韻律値、リック傾向値を演算し、付与する。評価値の初期値は、そのリックデータのもととなるソングのユニークＩＤの中の、順位等によって定めることができる。メジャラー部１２３は、リックデータが分解される前のメロディデータに基づいて、当該リックデータの前後のリックデータを用いて韻律値を求めることができる。

ステップＳ１０６において、リック記憶部１９３は、メジャラー部１２３で特徴量が付与されたリックデータを記憶する。その際、各リックデータに付与されたV、B、Cのリック属性情報から、それぞれリック記憶部(Verse)１９３ａ、リック記憶部(Bridge)１９３ｂ、リック記憶部(Chorus)１９３ｃに記憶される。また、そのリックに対応するソングのユニークＩＤとともに記憶する。

ステップＳ１０７において、ハーモニー記憶部１９２はディストリビュータ部１２１で分類されたハーモニーデータを、そのストラクチャデータに対応するソングのユニークＩＤとともに記憶する。

以上の処理により、管理者がソングを音楽情報として入力することで、過去に作曲された楽曲のメロディデータとハーモニーデータとストラクチャデータをデータベースとして蓄積することができる。過去に作曲された楽曲を、ヒットした名曲であることを指標として選択し、データベースとして構築することにより、そのデータベースを用いて生成した新たな楽曲がヒットする可能性を高めることができる。

＜＜作曲支援＞＞
次に、図８のフローチャートを用いて、ユーザの作曲支援の動作について説明する。図８のフローチャートは、ユーザの作曲支援の動作について、作曲支援サーバ１０１、ユーザ端末３０１の各動作の関連状態を示している。ステップＳ２０１において、ユーザはユーザ端末３０１において、ソングの選択を行う。選択されたソングは、作曲支援サーバ１０１に送信される。

ステップＳ２０２において、ジェネレータエンジン部１３１は、ステップＳ２０１で受信した選択されたソングに対応したストラクチャデータを、ストラクチャ記憶部１９１から読出する。

ステップＳ２０３において、ジェネレータエンジン部１３１は、読出されたストラクチャデータからセクションｘを選択する。ジェネレータエンジン部１３１は、初期値をｘ＝１としてセクションを選択する。

ステップＳ２０４において、ジェネレータエンジン部１３１は、ステップＳ２０３で選択されたストラクチャｘからブロックｙを選択する。ジェネレータエンジン部１３１は、初期値をｙ＝１としてブロックを選択する。

ステップＳ２０５において、ジェネレータエンジン部１３１は、ステップＳ２０４で選択されたブロックｙが、既出のブロックであるか否かを判別する。例えば、ストラクチャｘ内のブロックの配列が、
［a016b016a016］
である場合、ブロック１は［a016］、ブロック２は［b016］、ブロック３は［a016］である。ブロック３が選択された場合、すでにブロック１で選択されている［a016］と同じであることから既出のブロックであると判別される。ブロックが既出である場合は［Ｙ］としてステップＳ２１０へ処理を進め、既出のブロックで選択されたリックデータをブロックとして決定する。ブロックが既出でない場合は［Ｎ］としてステップＳ２０６へ処理を進める。

ステップＳ２０６において、ジェネレータエンジン部１３１は、リックデータをリック記憶部１９３から選択する。その際、ジェネレータエンジン部１３１は、ステップＳ２０３で選択されたセクションｘのセクション属性情報に対応するリック記憶部１９３ａから１９３ｃの中から選択する。例えば、セクションｘのセクション属性情報がｖである場合、ジェネレータエンジン部１３１は、ｖに対応するリック記憶部(Verse)１９３ａに記憶されているリックデータから選択を行う。ジェネレータエンジン部１３１は、リックデータを、リック記憶部１９３内に記憶されているリックデータにそれぞれ付与されている評価値に応じて選択される確率を付与した上で、その確率に応じてランダムに選択する。また、先に選択されたリックデータにつなげるリックデータを選択する場合、ジェネレータエンジン部１３１は、先に選択されたリックデータに付されている特徴量の中の韻律値に基づいて、次に選択すべきリックデータを選択する。ある程度の選択秩序を持たせつつ、確率的な要素を取り入れることにより、多様性のある音楽を生成可能としている。

ステップＳ２０７において、ジェネレータエンジン部１３１は、ステップＳ２０６で選択されたリックデータのリックリニア値（或いは複数選択されたリックデータの合計のリニア値）と、ブロックｙの音価の長さを比較する。リックリニア値とブロックｙの音価が同じ場合、ステップＳ２０９へ処理を進める。リックリニア値よりもブロックｙの音価が長い場合、ステップＳ２０８へ処理を進める。リックリニア値よりもブロックｙの音価が短い場合、選択されたリックデータを採用することはできず、ステップＳ２０６へ処理を進め、再度リックデータの選択を行う。

ステップＳ２０８において、ジェネレータエンジン部１３１は、選択されたリックデータを仮に決定する。リックリニア値よりもブロックｙの音価は長いため、ブロックｙの残りの長さに対してリックデータをさらに選択するためにステップＳ２０６へ処理を進める。

ステップＳ２０９において、ジェネレータエンジン部１３１は、選択されたリックデータを仮に決定する。

ステップＳ２１０において、ジェネレータエンジン部１３１は、ブロックｙを決定する。

ステップＳ２１１において、ジェネレータエンジン部１３１は、ブロックｙの次のブロック、すなわちブロックｙ＋１が有るか否かを判別する。ブロックｙ＋１が有る［Ｙ］と判別された場合、ステップＳ２１２へ処理を進める。ブロックｙ＋１が無い［Ｎ］と判別された場合、当該セクションには決定していないブロックはないものとして、ステップＳ２１３へ処理を進める。

ステップＳ２１２において、ジェネレータエンジン部１３１は、ブロックｙのｙ値をインクリメントし、ステップＳ２０４へ処理を進め、インクリメントした次のブロックの選択を行う。

ステップＳ２１３において、ジェネレータエンジン部１３１は、決定した複数のブロックにおける、最初のブロックの初音と最後のブロックの終音から傾向値を算出する。そして、算出された傾向値と、セクションｘの傾向値を比較する。ジェネレータエンジン部１３１は、傾向値が同じと判別した場合、ステップＳ２１５に処理を進め、異なっていると判別した場合、ステップＳ２１４へ処理を進める。なお、最初に選択されたリックデータの列を一旦記憶し、ステップＳ２１３の処理を所定回数繰り返したのちに適合する条件を発見できない場合に、記憶された最初に選択したリックデータの列を採用しても構わない。それにより、作曲支援システムの処理が、長い時間にわたってステップＳ２１３の処理を繰り返すことを防ぎ、全体の処理を高速化させることができる。

ステップＳ２１４において、ジェネレータエンジン部１３１は、選択されたリックデータを破棄する。そして、再度リックデータを選択するために、ステップＳ２０６へ処理を進める。破棄するリックデータは、一つ前の処理で選択されたリックデータであっても良いし、さらに遡ったリックデータから破棄してもよい。

ステップＳ２１５において、ジェネレータエンジン部１３１は、セクションｘを決定する。

ステップＳ２１６において、ジェネレータエンジン部１３１は、セクションｘの次のセクション、すなわちセクションｘ＋１が有るか否かを判別する。セクションｘ＋１が有る［Ｙ］と判別された場合、ステップＳ２１６へ処理を進める。セクションｘ＋１が無い［Ｎ］と判別された場合、当該ストラクチャには決定していないセクションはないものとして、ステップＳ２１８へ処理を進める。

ステップＳ２１７において、ジェネレータエンジン部１３１は、セクションｘのｘ値をインクリメントし、ステップＳ２０４へ処理を進め、インクリメントした次のブロックの選択を行う。

ステップＳ２１８において、ジェネレータエンジン部１３１は、仮に全てのセクションを決定し、ストラクチャデータに対応するメロディを仮完成させる。

ステップＳ２１９において、ジェネレータエンジン部１３１は、「仮に決定したリックデータ」に対して、一部を他のリックデータと置換して、メロディを再構成する。具体的には、ジェネレータエンジン部１３１は、リック記憶部１９３の中から、複数のリックデータを選択し、選択したリックデータから１つのリックデータを合成（生成）し、かつリック傾向値が「仮に決定されたリックデータ」と同じものを選択する。合成され、選択された当該リックデータを、「仮に決定したリックデータ」の一部とランダムに置換する。その置換の頻度は、全リックデータの３０％とする。このことにより、生成されるメロディは、それまでに生成されたメロディとは異なり、かつ一定のクオリティ以上のメロディを持った楽曲を生成することができる。

ステップＳ２２０において、ジェネレータエンジン部１３１は、ストラクチャデータに対応するハーモニーデータを、ハーモニー記憶部１９２から選択する。

ステップＳ２２１において、ブラックエンジン部１３２は、ステップＳ２２０で選択されたハーモニーデータが、ステップＳ２１９で再構成されたメロディとハーモニーデータが、適切な倍音関係になっているかを確認する。ブラックエンジン部１３２は、１リニア値を単位として、倍音関係の確認を行う。すなわち、不適切な倍音関係を含むリックデータを抽出することができる。ブラックエンジン部１３２は、倍音関係が不適切、すなわち不協和音の関係に有る［Y］と判別した場合にはステップＳ２２１へ処理を進め、再度ハーモニーデータを選択する。適切である［N］と判別した場合にはステップＳ２２３に処理を進める。

ステップＳ２２２において、ジェネレータエンジン部１３１は、ステップＳ２２１で、不適切な倍音関係と判別され、抽出されたリックデータを破棄し、新たなリックデータの選択を行う。ジェネレータエンジン部１３１は、ステップＳ２０６からステップＳ２１８で説明してきたアルゴリズムで、選択するリックデータを選択することができる。ジェネレータエンジン部１３１は、新たなリックデータを選択するとステップＳ２２１へ処理を進め、再度ハーモニーデータとの倍音関係の確認を行う。

ステップＳ２２３において、ジェネレータエンジン部１３１は生成されたメロディとハーモニーデータが適切であるものとして、メロディを決定する。これで、メロディとハーモニーが決定して楽曲が構成されたことになる。

ステップＳ２２４において、ＭＩＤＩ−オーディオコンバータ部１８１は、ステップＳ２２３で構成されたメロディに基づく楽曲をＭＩＤＩデータに変換して、ユーザ端末３０１へ送信する。なお、当該処理は、楽曲に関するデータをユーザ端末３０１へ送信して、ユーザ端末３０１の内部でＭＩＤＩデータへの変換を行ってもよい。

ステップＳ２２５において、ユーザ端末３０１は、ステップＳ２２４で送信されたＭＩＤＩデータを再生する。それにより、ユーザはステップＳ２２３で決定された楽曲を音として確認することができる。

ステップＳ２２６において、ユーザは必要に応じて、ユーザ端末３０１から楽曲の修正を行うことができる。ユーザは、ストラクチャデータにおける、セクションのメロディ等を気に入らない場合、修正リクエストを作曲支援サーバ１０１へ送信することができる。

ステップＳ２２７において、リジェネレータ部１３３は、修正リクエストの情報を受信したか否かを判別する。修正リクエストが有り［Ｙ］の場合、ステップＳ２２８へ処理を進める。修正リクエストが無し［Ｎ］の場合、ステップＳ２３０へ処理を進める。

ステップＳ２２８において、リジェネレータ部１３３は、修正リクエストに基づいてリックデータを破棄し、当該リックデータを再度選択する。リジェネレータ部１３３は、ステップＳ２０６からステップＳ２２３で説明してきたアルゴリズムで、選択するリックデータを選択することができる。

ステップＳ２２９において、ユーザはステップＳ２２５で確認した楽曲に満足した場合、ユーザ端末３０１から楽曲の記憶リクエストを行うことができる。すなわち、楽曲を完成データとして、記憶し、保存するためのリクエストを送ることができる。

ステップＳ２３０において、作曲支援サーバ１０１は、楽曲をデータとして記憶する。その際、合成されたリックデータを、リック記憶部１９３に記憶されたリックデータと比較し、既出であるか否かを判別する。すなわち、合成されたリックデータがリック記憶部１９３に記憶されたリックデータと同じであるか否かを判別する。記憶されたリックデータと異なる、すなわち、新たなリックデータが合成された場合、当該リックデータは、リック記憶部１９３へ送信され記憶される。その際、合成されたリックデータが、どのセクション属性情報に対応するセクションに含まれているかにより、その属性に対応するリック記憶部１９３のうち、リック記憶部(Verse)１９３ａ、リック記憶部(Bridge)１９３ｂ、リック記憶部(Chorus)１９３ｃのいずれかに記憶される。その際、メジャラー部１２３で特徴量が算出され、リックデータに付与される。このように、リックデータが増加することで、新たな作曲資源を蓄積することができる。

以上の処理が終了し、ユーザが楽曲の記憶（セーブ）を行うことで、新たな楽曲の生成が完了する。なお、ユーザが楽曲のセーブを行わない場合、リックデータに付される評価値は変化させなくてもよい。また、修正されたリックデータは、破棄されてもよい。

以上説明してきた作曲支援サーバ１０１の動作は、任意に不必要なステップを除外してもよい。例えばハーモニーを用いない楽曲においては、ステップＳ２２０からステップＳ２２２を除外してもよい。また、ステップＳ２１９を除外して、楽曲を生成してもよい。

＜作曲支援の具体例＞
次に、先に説明した作曲支援の方法について、具体例を挙げて説明する。

図８で示す、ステップＳ２０１で、ユーザが選択したソングに対応して、ステップＳ２０２で読み出されるストラクチャデータを、以下の具体例１のデータとして説明する。
[具体例１]
structure{
V:[a016b016a016c012x004d032e028x004]-5
V:[d032e028x004d032e028]-5
C:[f016f016f016g016f016f016f016h024]-7
B:[i016j016i016k012x004i016j016i016l024]+9
C:[f016f016f016g016f016f016f016h024]-7
}

ステップＳ２０３において、ｘ＝１としてセクション１を選択する。すなわち以下の具体例２のセクションが選択される。
[具体例２]
V:[a016b016a016c012x004d032e028x004]-5

次にステップＳ２０４において、ｙ＝１としてセクション１におけるブロック１を選択する。すなわち、[a016]がブロック１として選択される。ブロック１は、選択されたストラクチャの先頭であるため[a]が付され、元となったソングにおいて16の音価を有するものである。

ステップＳ２０５において、ステップＳ２０４で選択されたブロック１が既出か否かを判別する。セクション１において、ブロック３はブロック１と同じであるため、ブロック３が選択された場合、既出のブロックであるとしてステップＳ２１０へ処理を進める。

ステップＳ２０６において、ステップＳ２０４で選択されたブロック１に対してリックデータを選択する。その際、セクション１はヴァースの属性であるため、リック記憶部（Verse）１９３ａに記憶されたリックデータから選択される。ジェネレータエンジン部１３１は、リックデータを、リック記憶部(Verse)１９３ａ内に記憶されているリックデータに付与されている評価値に対応する確率に応じてランダムに選択する。評価値は１０のリックデータ１、評価値が９のリックデータ２から評価値が１のリックデータ１０の１０個のリックデータから確率的にリックデータを選択する場合について説明する。リックデータ１に付与される確率は１０／（１＋２＋３＋４＋５＋６＋７＋８＋９＋１０）＝１０／５５となる。同様にリックデータ１０に付与される確率は１／５５となる。また、先に選択されたリックデータにつなげるリックデータを選択する場合、ジェネレータエンジン部１３１は、先に選択されたリックデータに付されている特徴量の中の韻律値に基づいて、次に選択すべきリックデータを選択する。先に選択されたリックデータの終音が「E4」であり、そのリックデータの韻律値が−４である場合、「E4」＝６４に−４とした６０＝「C4」が初音のリックデータを、リック記憶部１９３の中から選択する。なお、評価値が１の場合と１０の場合の選択確率の差を小さくするような係数を設定し、評価値が１のリックデータと１０のリックデータの選択確率を３倍程度に抑えることで、極端に評価値が高いリックデータばかりが選択されないように調整してもよい。また、選択確率の倍率は任意に設定してもよい。

ステップＳ２０７において、リックリニア値が16であるリックデータが選択された場合、ステップＳ２０９でそのリックデータは決定され、さらに、ステップＳ２１０でブロック１が決定する。リックリニア値が８であるリックデータが選択された場合、ステップＳ２０８でそのリックデータは決定され、さらに残りリックリニア値が8のリックデータを選択するためステップＳ２０６へ処理を進める。リックリニア値が24のリックデータが選択された場合、ブロック１の16の音価には入りきらないため、再度リックデータを選択するためにステップＳ２０６へ処理を進める。

ステップＳ２１１において、ブロック１の次のブロックがあるか否かを判別する。次のブロックがある場合、ｙを１だけインクリメントして、ステップＳ２０６へ処理を進め、次のブロックに対応するリックデータを選択する。セクション１ではブロック８の次のブロックはないため、その場合ステップＳ２１３へ処理を進める。

ステップＳ２１３において、セクション１のセクション傾向値である−５と、ブロック全体の傾向値、すなわち、ブロック１で選択されたリックデータの初音と、ブロック７（ブロック８は無音であるため）の終音の差が一致するか否かを判別する。一致しない場合、ブロック７で最後に選択されたリックデータが破棄され、ステップＳ２０６へ戻り、再度リックデータが選択される。リック記憶部１９３ａに選択可能なリックデータが存在しない場合、さらに一つ前に選択されたリックデータを破棄し、再度選択を行う。選択可能なリックデータが決定するまで、破棄を遡る処理を行う。それでも一致しない場合には、セクション傾向値を±１として、再度リックデータの選択を行う。一致する場合、ステップＳ２１５においてセクション１は決定する。なお、前述したように、セクション傾向値とブロック全体の傾向値が一致しない、最初に選択されたリックデータの配列データを一旦記憶しておいてもよい。一致するリックデータの探索を行い、さらにセクション傾向値を±１として探索を行い、それでも選択が終了しない場合に、最初に選択されたリックデータの配列データを採用することができる。そのことで、システムの処理を高速化し、システムの動作の安定化を図ることができる。

ステップＳ２１６において、セクション１の次のセクションがあるかどうかを判別する。次のセクションがある場合、ｘを１だけインクリメントして、ステップＳ２０３へ処理を進め、次のセクションに対応するブロックを選択する。セクション５は次のセクションはないため、その場合ステップＳ２１８へ処理を進め、すべてのセクションが決定され、メロディが決定する。

ステップＳ２１９において、各セクション内で決定されたリックデータの置換を行う。

ステップＳ２２０からステップＳ２２２において、ステップＳ２１８で決定したメロディに適切なハーモニーが選択される。適切かどうかの判断は、メロディを構成する音を音価の単位で不協和音となっていないかを判別することで行う。不協和音が有ると判別されると、その不協和音を構成するリックデータをステップＳ２２２で破棄し、再選択し、再度ステップＳ２２１で不協和音の有無の確認を行う。これらのステップを繰り返すことで、最終的にステップＳ２２３でメロディとハーモニーが決定され、仮の楽曲が完成する。

ステップＳ２２４とステップＳ２２５において、ユーザは「仮の楽曲」の音を聴くことができる。ユーザ端末３０１は図５や図６の表示となり、選択したソングに対応する新しい楽曲の再生を行う。

ステップＳ２２７からステップＳ２２８において、ユーザからの、修正リクエストがある場合、修正リクエストのあった個所のリックデータを他のリックデータに置換する。例えば、図５において、ユーザが、構成要素表示３２２にヴァースを修正したいと思った場合、図５の画面上で、構成要素表示３２２をタップ及びスワイプすることで選択することで、当該箇所の修正をリクエストすることができる。構成要素表示３２２のヴァースに対応するセクションのリックデータはステップＳ２０３からステップＳ２１５の処理、及び、ステップＳ２１９からステップＳ２２３の処理のアルゴリズムを用いて、再度選択される。

ステップＳ２２９とステップＳ２３０において、ユーザはステップＳ２２５で確認した楽曲に満足した場合、ユーザ端末３０１から楽曲の記憶リクエストを行うことができる。すなわち、楽曲を完成データとして、記憶し、保存するためのリクエストを送ることができる。ユーザは記憶した楽曲のＭＩＤＩデータに基づいて、新たな作曲行為を行うことができる。また、作曲支援サーバ１０１の運営者は、楽曲の記憶が行われたことに基づいて、ユーザに対して課金を行うことができる。

以上のように、過去に作曲された楽曲から新たな楽曲を生成することができる。

＜効果の説明＞
以上のように、本開示の実施形態に係る作曲支援サーバ１０１は、過去の楽曲構造であるストラクチャデータと過去の楽曲のメロディの断片であるリックデータから、新たなメロディを構成することで、聴衆からの支持を獲得できる可能性の高い楽曲を生成することができる。また、リックデータに使用された頻度に応じて、使用された頻度の高い、すなわち人気の高いリックデータを用いる確率を高めることで、より聴衆からの支持を獲得する可能性の高いメロディや楽曲を生成することができる。また、生成したメロディに対して、リックデータを一定の制約のもと確率的要素で入れ替える、それをノイズとしてメロディに混入させることで、それまでに生成されたメロディとは異なり、かつ一定のクオリティ以上のメロディを持った楽曲を生成することができる。さらに、生成されたメロディや楽曲を、ユーザが確認し、適宜修正を行うことで、ユーザの作曲行為の支援を行うことができる。そして、修正により新たに生成されたリックデータを蓄積することで、再帰的に作曲資源であるリックデータを増加させ、新たに生成される楽曲のバリエーションを増やすことができる。

（プログラム）
図９は、コンピュータ８０１の構成を示す概略ブロック図である。コンピュータ８０１は、ＣＰＵ８０２、主記憶装置８０３、補助記憶装置８０４、インタフェース８０５を備える。

ここで、実施形態に係る作曲支援サーバ１０１を構成する各機能を実現するためのプログラムの詳細について説明する。

作曲支援サーバ１０１は、コンピュータ８０１に実装される。そして、作曲支援サーバ１０１の各構成要素の動作は、プログラムの形式で補助記憶装置８０４に記憶されている。ＣＰＵ８０２は、プログラムを補助記憶装置８０４から読み出して主記憶装置８０３に展開し、当該プログラムに従って上記処理を実行する。また、ＣＰＵ８０２は、プログラムに従って、上記した記憶部に対応する記憶領域を主記憶装置８０３に確保する。

当該プログラムは、具体的には、コンピュータ８０１において、作曲支援プログラムは、過去に作曲された楽曲を構成するメロディの一部であって音程と音価の情報の配列により構成される複数のリックデータと、楽曲の構造であってリックデータを配置する規則である複数のストラクチャデータと、を用いて、リックデータを選択し、ユーザの指示に基づき選択されたストラクチャデータの規則に従いリックデータを配置することで新たなメロディの生成をコンピュータによって実現するものである。

なお、補助記憶装置８０４は、一時的でない有形の媒体の一例である。一時的でない有形の媒体の他の例としては、インタフェース８０５を介して接続される磁気ディスク、光磁気ディスク、ＣＤ−ＲＯＭ、ＤＶＤ−ＲＯＭ、半導体メモリ等が挙げられる。また、このプログラムがネットワークを介してコンピュータ８０１に配信される場合、配信を受けたコンピュータ８０１が当該プログラムを主記憶装置８０３に展開し、上記処理を実行してもよい。

また、当該プログラムは、前述した機能の一部を実現するためのものであってもよい。さらに、当該プログラムは、前述した機能を補助記憶装置８０４に既に記憶されている他のプログラムとの組み合わせで実現するもの、いわゆる差分ファイル（差分プログラム）
であってもよい。

以上、本開示のいくつかの実施形態を説明したが、これら実施形態は、その他の様々な形態で実施されることが可能であり、発明の要旨を逸脱しない範囲で種々の省略、置き換え、変更を行うことができる。これら実施形態やその変形は、発明の範囲や要旨に含まれると同様に、特許請求の範囲に記載された発明とその均等の範囲に含まれるものとする。

１…作曲支援システム
１０１…作曲支援サーバ
１１１…通信部
１２１…ディストリビュータ部
１２２…フラグメンター部
１２３…メジャラー部
１３１…ジェネレータエンジン部
１３２…ブラックエンジン部
１３３…リジェネレータ部
１８１…ＭＩＤＩ−オーディオコンバータ部
１９１…ストラクチャ記憶部
１９２…ハーモニー記憶部
１９３…リック記憶部
１９３ａ…リック記憶部(Verse)
１９３ｂ…リック記憶部(Bridge)
１９３ｃ…リック記憶部(Chorus)
２０１…管理端末
３０１…ユーザ端末
３１０…ディスプレイ
３２１〜３２９…構成要素表示
３３０…再生位置表示バー
３３１…再生アイコン
３３２…早送りアイコン
３３３…巻き戻しアイコン
３３４…メロディ音色切換えアイコン
３３５…ハーモニー音色切換えアイコン
８０１…コンピュータ
８０２…ＣＰＵ
８０３…主記憶装置
８０４…補助記憶装置
８０５…インタフェース

Claims (14)

1. 過去に作曲された楽曲を構成するメロディの一部であって音程と音価の情報の配列により構成される複数のリックデータを記憶するリック記憶部と、
   前記楽曲の構造であってリックデータを配置する規則であるストラクチャデータを記憶するストラクチャ記憶部と、
   前記リック記憶部から前記リックデータを選択し、ユーザの指示に基づきストラクチャ記憶部から選択された前記ストラクチャデータの規則に従い前記リックデータを配置することで新たなメロディを生成するジェネレータエンジン部と、
   を備える作曲支援サーバ。
2. 前記リックデータは、当該リックデータに含まれる音価の合計値であるリックリニア値を有し、
   前記ストラクチャデータは、前記ストラクチャデータを構成するセクション内の音価の合計値であるセクションリニア値を有し、
   前記ジェネレータエンジン部は、前記セクションリニア値と、リックデータのリックリニア値の合計値が一致するようにリックデータを選択する請求項１に記載の作曲支援サーバ。
3. 前記リックデータは、前記リックデータの終音と当該リックデータに隣接するリックデータの初音の音程の差の情報である韻律値を有し、
   前記ストラクチャデータは、前記ストラクチャデータを構成するセクション内の初音と終音の音程の差であるセクション傾向値を有し、
   前記ジェネレータエンジン部は、前記韻律値に基づいて配列するリックデータを前記リック記憶部から順次選択し、かつ、配列したリックデータの初音と終音の差と前記セクション傾向値の比較結果に基づいてリックデータを決定し、又は前記リック記憶部から再度選択する請求項１又は２に記載の作曲支援サーバ。
4. 前記リックデータは、当該リックデータの使用履歴に応じた評価値をさらに有し、
   前記ジェネレータエンジン部は、前記評価値に基づいて、前記リック記憶部から前記リックデータを選択する請求項１から３のいずれか一項に記載の作曲支援サーバ。
5. 前記ジェネレータエンジン部は、前記評価値が高い前記リックデータを、前記評価値が低い前記リックデータよりも高い確率で選択する請求項４に記載の作曲支援サーバ。
6. 前記リックデータは、音楽の構成要素であるヴァース、ブリッジ、コーラスのいずれかのリック属性情報が割り当てられ、
   セクションは、音楽の構成要素であるヴァース、ブリッジ、コーラスのいずれかのセクション属性情報が割り当てられ、
   前記ジェネレータエンジン部は、前記セクションに対応する前記リックデータを選択する際に、前記セクションのセクション属性情報と同じ前記リック属性情報が割り当てられたリックデータを選択する請求項１から５のいずれか一項に記載の作曲支援サーバ。
7. メロディを倍音で補助し和音を構成するハーモニーデータを複数記憶するハーモニー記憶部をさらに備え、
   前記ジェネレータエンジン部は、前記ストラクチャデータに基づいて生成した前記新たなメロディに対応するハーモニーデータを前記ハーモニー記憶部から選択する請求項１から６のいずれか一項に記載の作曲支援サーバ。
8. 前記ハーモニーデータが前記メロディに対して適切であるかを判別するブラックエンジン部をさらに備え、
   前記ブラックエンジン部が、前記ハーモニーデータと前記メロディの対応が適切でないと判別した場合、適切でないと判別された前記メロディを構成するリックデータを破棄し、前記ジェネレータエンジン部が、前記破棄したリックデータに代替するリックデータを新たに選択する請求項７に記載の作曲支援サーバ。
9. 生成されたメロディのユーザ端末からの修正リクエストを受け付けるリジェネレータ部をさらに備え、
   前記リジェネレータ部は、前記修正リクエストに基づいて、前記生成されたメロディを構成するリックデータの一部を、他のリックデータと置換する請求項１から８のいずれか一項に記載の作曲支援サーバ。
10. 前記ジェネレータエンジン部は、複数のリックデータを合成して生成したリックデータと、前記生成されたメロディを構成する前記リックデータの一部と置換する請求項１から９のいずれか一項に記載の作曲支援サーバ。
11. リジェネレータ部は、前記複数のリックデータを合成して生成したリックデータを、前記リック記憶部に記憶されたリックデータと比較し、一致しないと判別した場合、前記合成して生成したリックデータをリック記憶部に記憶する請求項１０に記載の作曲支援サーバ。
12. ユーザが操作するユーザ端末と、
    過去に作曲された楽曲を構成するメロディの一部であって音程と音価の情報の配列により構成される複数のリックデータを記憶するリック記憶部と、
    前記楽曲の構造であってリックデータを配置する規則である複数のストラクチャデータを記憶するストラクチャ記憶部と、
    前記リック記憶部から前記リックデータを選択し、前記ユーザ端末からの指示に基づきストラクチャ記憶部から選択された前記ストラクチャデータの規則に従い前記リックデータを配置することで新たなメロディを生成するジェネレータエンジン部と、
    を備える作曲支援システム。
13. 過去に作曲された楽曲を構成するメロディの一部であって音程と音価の情報の配列により構成される複数のリックデータと、
    前記楽曲の構造であってリックデータを配置する規則である複数のストラクチャデータと、
    を用いて、
    ジェネレータエンジン部が、前記リックデータを選択し、ユーザの指示に基づき選択された前記ストラクチャデータの規則に従い前記リックデータを配置することで新たなメロディを生成する作曲支援方法。
14. 過去に作曲された楽曲を構成するメロディの一部であって音程と音価の情報の配列により構成される複数のリックデータと、
    前記楽曲の構造であってリックデータを配置する規則である複数のストラクチャデータと、
    を用いて、
    前記リックデータを選択し、ユーザの指示に基づき選択された前記ストラクチャデータの規則に従い前記リックデータを配置することで新たなメロディの生成をコンピュータによって実現するための作曲支援プログラム。
    
    

Images