0

Ruby on Rails を使用して Web アプリを構築しています。データ モデルにはユーザーがいて、各ユーザーはキー (A# マイナーなどの音楽キー) を作成できます。

キーは和音で構成され、和音は音符で構成されます。ノートの数は有限ですが、コードとキーの数は無限にあります (各ユーザーが独自に作成できるため、複製が可能です)。

私は現在、キー、コード、およびノー​​トがそれぞれデータベース内のテーブルになるという仮定の下で作業しています (それが間違っていると思われる場合は止めてください)。

キーを選択してその中のすべてのコードを表示し、コードを選択してそれが含まれるすべてのキーを表示できるようにしたいと思います (コード/ノートと同じ)。さらに、ユーザー、キー、コード、ノートのリスト (インデックス) を互いに独立して表示できるようにしたいと考えています。これは、属している : 関連付けを介して使用するのに適していますか?

まだ明確でない場合は、私は RoR の初心者なので、ガイダンスやアドバイスをいただければ幸いです。前もって感謝します。

4

3 に答える 3

1

Rubyに関する以前の回答に追加するものは何もありません。これは、プログラミングの問題に対する答えというよりも、あなたの質問に対する音楽理論のコメントです。私はあなたの道をたどり、デザインの選択に影響を与える可能性のあるいくつかのことを学びました. 一連の音符のコードの意味はあいまいであるため、一連の音符をどのようにキーに関連付けるかについて、適切な答えはありません。同じ一連の音符でも、作曲者がどのように使用または意図したかによって、コード名 (および意味) が異なる場合があります。コードが複雑になると、問題はさらに悪化します。キーからコード、そして音符へと簡単に進むことができますが、作曲家の頭脳を選ばずに戻る方法は保証されていません。問題は、基本的な音楽の二分法から生じます。そこでは、音符は、ハーモニックの関係 (3 を持つちょうど完全 5 度) のいずれかの観点から定義できます。2 比率) または調律された半音階での位置。(ピアノで演奏される調律完全 5 度は 700 セント、または約 1.498 の比率です。) 調律された音階は必要な妥協点ですが、曲を表現するためにそれを使用すると、重要な音楽理論の情報が失われます。調律された音階のすべての音程には、類似した完全に調律された音程が多数存在する可能性があります。たとえば、3:2、40:27、および 243:160 の比率で定義された音程はすべて同じ調律された音に変換されるほど十分に近いですが、コードが何であるかを知るには、意図された比率を知る必要があります。調律された音は近似値であるため、実際の音を選択すると、音から和音に移動するために必要な比率情報が失われます。構成的な意味でコードを定義するのは比率です。(ピアノで演奏される調律完全 5 度は 700 セント、または約 1.498 の比率です。) 調律された音階は必要な妥協点ですが、曲を表現するためにそれを使用すると、重要な音楽理論の情報が失われます。調律された音階のすべての音程には、類似した完全に調律された音程が多数存在する可能性があります。たとえば、3:2、40:27、および 243:160 の比率で定義された音程はすべて同じ調律された音に変換されるほど十分に近いですが、コードが何であるかを知るには、意図された比率を知る必要があります。調律された音は近似値であるため、実際の音を選択すると、音から和音に移動するために必要な比率情報が失われます。構成的な意味でコードを定義するのは比率です。(ピアノで演奏される調律完全 5 度は 700 セント、または約 1.498 の比率です。) 調律された音階は必要な妥協点ですが、曲を表現するためにそれを使用すると、重要な音楽理論の情報が失われます。調律された音階のすべての音程には、類似した完全に調律された音程が多数存在する可能性があります。たとえば、3:2、40:27、および 243:160 の比率で定義された音程はすべて同じ調律された音に変換されるほど十分に近いですが、コードが何であるかを知るには、意図された比率を知る必要があります。調律された音は近似値であるため、実際の音を選択すると、音から和音に移動するために必要な比率情報が失われます。構成的な意味でコードを定義するのは比率です。) 平均律は必要な妥協点ですが、それを使用して作曲を表現すると、重要な音楽理論の情報が失われます。調律された音階のすべての音程には、類似した完全に調律された音程が多数存在する可能性があります。たとえば、3:2、40:27、および 243:160 の比率で定義された音程はすべて同じ調律された音に変換されるほど十分に近いですが、コードが何であるかを知るには、意図された比率を知る必要があります。調律された音は近似値であるため、実際の音を選択すると、音から和音に移動するために必要な比率情報が失われます。構成的な意味でコードを定義するのは比率です。) 平均律は必要な妥協点ですが、それを使用して作曲を表現すると、重要な音楽理論の情報が失われます。調律された音階のすべての音程には、類似した完全に調律された音程が多数存在する可能性があります。たとえば、3:2、40:27、および 243:160 の比率で定義された音程はすべて同じ調律された音に変換されるほど十分に近いですが、コードが何であるかを知るには、意図された比率を知る必要があります。調律された音は近似値であるため、実際の音を選択すると、音から和音に移動するために必要な比率情報が失われます。構成的な意味でコードを定義するのは比率です。たとえば、3:2、40:27、および 243:160 の比率で定義された音程はすべて同じ調律された音に変換されるほど十分に近いですが、コードが何であるかを知るには、意図された比率を知る必要があります。調律された音は近似値であるため、実際の音を選択すると、音から和音に移動するために必要な比率情報が失われます。構成的な意味でコードを定義するのは比率です。たとえば、3:2、40:27、および 243:160 の比率で定義された音程はすべて同じ調律された音に変換されるほど十分に近いですが、コードが何であるかを知るには、意図された比率を知る必要があります。調律された音は近似値であるため、実際の音を選択すると、音から和音に移動するために必要な比率情報が失われます。構成的な意味でコードを定義するのは比率です。

これは、少なくとも単純なコードでは不可能な作業であるという意味ではありません。トライアドでは通常、反転でも有効な選択肢が 1 つしかありませんが、7 度追加すると厄介になります。あなたは選択をしなければなりません。おそらく十分である可能性が最も高い選択肢があります。私は可能な限り最も調和のとれた和音を選ぶことに決めました (音程比の最小の整数を持つ和音とほぼ同じです)。これは、それらを構成する音符から主要な関連する和音名を推測しようとして 100% 信頼できないことを意味します。平均的なジャズ構成 (ジャズは複雑なコードが大好き) では、ほとんど絶望的なケースになります。

調律された楽器のパフォーマンスのためにデータを使用しているだけであれば、おそらく何の違いもありません。平均律では、これらのコードはすべて同じように聞こえます。アカペラ (人間の声は無限にチューニング可能で、完璧なチューニングに向かう傾向があります) をチューニングしようとしたり、作曲者の音楽的意図を理解しようとしたりすると、問題が発生します。

于 2013-11-02T22:56:15.153 に答える
1

1対多has_manyの関係がある場合と、多対多の関係がある場合は、関係を使用has_many :throughします。たとえば、あなたの説明では、和音は多くの音で構成されていると言っているので、和音は和音has_manyです。音符にはコードが 1 つしかありませんか、have_manyそれとも和音ですか? 音符にコードが 1 つしかない場合は、has_many/のbelongs_to関係が適切です。

ウィキペディアで検索したところ、C メジャー コードは C、E、G の音符で構成されていることがわかりhas_manyました。音は和音だと思いますので、おそらく関係性の方が適切でしょう。belongs_tochord_idhave_manyhas_manymany_to_many

リレーションシップに関するコード クイズを作成しましたmany_to_many。参考になるかもしれません。

于 2013-08-07T02:09:47.253 に答える
0

答えを出すと、私の力が前進します。many-to-manyあなたの申請書に関係があるという点では同意しません。これを取るための悪いデータベース設計アプローチ。何らかのmany-to-many関係が進行している場合は、両方の複合キーを格納する解決テーブルが必要になると思います。chord_idこのnote_idテーブルは、多対多の関係を分解し、潜在的に発生する可能性のあるこの形式のカーディナリティを解決しますここ。効果的には、ChordNoteを介して Chord has_manyノートを作成し、Note テーブルにChordNoteを介して Note has_many chordsを作成することができます。気づけばキーワードがthrough次のリンクは、この種の関係のセットアップがHas-Many-Through を行うことを正確に説明しています。この SO の質問は、 Why No Many To Many Relationships という私の推論を擁護するため、モデル アソシエーション Chord has_many Notes と Note has_many Chords を持つことを擁護するのは正しいことです。多対多の関連付けを使用してアプリケーションをセットアップする理由がわかりません。

したがって、これをすべて言うと、セットアップは次のようになります（多対多の場合）

コード

class Chord < ActiveRecord::Base 
   Chord has_many :notes, :through ChordNote
end

コードノート

class ChordNote < ActiveRecord::Base 
  belongs_to :chords
  belongs_to :notes
end

ノート

class Note < ActiveRecord::Base
  has_many :chords, :through => :ChordNote
end
于 2013-08-07T03:18:12.093 に答える