Music knowledge representation

[Aaron "Castironpi" Brady]

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.