[EMAIL PROTECTED] writes:
> First, create a chord from a given label
> supplied by the user and second, label a chord from a collection of pitches
> that the user supplies.
We already have a mechanism for making things from labels. It is
called `identifier'. Do not duplicate this mechanism.
> Also, I noticed in the parser that it
> creates a chord object only to throw it away after translating the pitches
> into a Simultaneous_music object.
Yes, I know. That's why it says "Junkme" in the comment.
> The problem with this approach is that
> you lose everything that tells you what the chord is--its identifier, its
> inversion, the additions, and subtractions.
No, the chord is reduced to its essence: a list of pitches. From this
list it should be possible reconstruct the name. The only thing that
perhaps should be stored as an extra is the bottom pitch (the
inversion pitch).
> information doesn't get lost. Ideally, the Simultaneous_music object would
> have a chord object inside of it so that all of that info doesn't get lost
> (and would keep the ugliness factor or going through the back door down).
I would disagree on this one: Simultaneous_music per se has nothing to
do with chords as harmonic devices. I do not want to mix those.
Remember that Simultaneous_music are used at a lot of places where
Chords don't make sense.
> And don't even get me started on the whole translating a group of pitches
> into a chord label idea (which is an even hairier subject than I care to
> talk about at the moment)!
Then you should apply Occams razor until it is no longer hairy :-)
(Seriously: think harder, there must be a way to do distill chordnames
from lists of pitches without resorting to an endless list of
if-thens.)
--
Han-Wen Nienhuys, [EMAIL PROTECTED] ** GNU LilyPond - The Music Typesetter
http://www.cs.uu.nl/people/hanwen/lilypond/index.html
