Music knowledge representation
Aaron "Castironpi" Brady
castironpi at gmail.com
Mon Sep 29 23:35:15 CEST 2008
On Sep 29, 3:56 pm, "D'Arcy J.M. Cain" <da... at druid.net> wrote:
> On Mon, 29 Sep 2008 20:29:44 +0200
> "Mr.SpOOn" <mr.spoo... at gmail.com> wrote:
> > > Couldn't the note class simply have a list of all the notes and have a
> > > simple method calculate the actual pitch?
> > That's not really how it works. There exists just 12 octave
> > independent pitch classes. This means that there is a pitch class C
> > with all possible Cs. There ambiguities with accidentals, because
> > different named notes fall in the same pitch class. The difference is
> > important for the musical theory, because C# and Db belongs to the
> > same pitch class (actually they are the same note, they sounds
> > completely identical -- because on the piano you play them pressing
> > the same key), but in a scale they have a very different role.
> Sure, they are enharmonically identical but in our tempered scale.
> That's why my example showed it as (note, octave, accidental) rather
> than a specific note. It would differentiate between these.
> > For example, the interval C F# is an "augmented fourth", because what
> > really matters are the natural note (C and F), and their distance if
> > 4. Then it is augmented due to the #-
> > But the interval C Gb (Gb is the same as F#) is a "diminished fifth".
> This is true. My simple example would not have dealt with this. The
> arguments would have to be the full tuple rather than the actual pitch.
> > So I can't list all pitches.
> You can but you can't store them as raw pitches.
> > > def interval(self, lower, higher)
> > > if lower > higher:
> > > # uncomment one of the two following lines depending
> > > # on the behaviour you want
> > > #lower,higher = higher,lower
> > > #higher += 12
> > > # could use some error trapping
> > > return self.interval_name[higher - lower]
> > > Note that lower and higher could be a note object that you have to
> > > convert to integers first.
> > I can't estabilish which note is higher, because all the analysis part
> > is octave independent. Anyway thanks for the ideas.
> I'm not sure I understand this. You either have to assume that the
> first note is the root or the lower one is. What other options are
> there? It sounds like your requirement is "higher += 12" or some
> variant. It also depends on whether you need to deal with things like
> ninths and thirteenths.
> Anyway, I was just tossing out ideas. You know what your requirements
> are better than I.
> D'Arcy J.M. Cain <da... at druid.net> | Democracy is three wolveshttp://www.druid.net/darcy/ | and a sheep voting on
> +1 416 425 1212 (DoD#0082) (eNTP) | what's for dinner.
I like D'Arcy's tuples so far. You could have a 4th element that
contains adjustment for temper. Octave could be None.
You want ( 4, None, 1 ) "sharp 4th" == ( 5, None, -1 ) "flat 5th", but
you can't have it. The closest ones are Note( 4, None, 1 )== Note( 5,
None, -1 ) or Note(4, None, 1 ).enh_cmp( Note( 5, None, -1 ) ). More
elaborate code means more options for calling, though: Note(4, None,
1 ).cmp_enh( 5, None, -1 ), and just call the constructor on the 3
arguments. You also want Note( 9, None, 0 ).cmp_octave( 2, Rel+ 1,
0 ), 9th== 2nd + 1 octave, and Note( 9, None, 0 ).cmp_nooctave( 2,
None, 0 ), where cmp_... functions return in ( -1, 0, 1 ), and the
middle term can be a class Relative instance, which indicates a
relative octave instead of absolute... or just start at 4.
More information about the Python-list