[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.
>
> This is not what I meant. I meant a chord identifier such as m7 or maj7b5.
> It is *not* the same thing...
Currently it is not. But if we decide that we're going to do some
kind of Label => Chord mapping, we should make this mapping an
extension of existing system, and not attach some arbitrary coding
with duct-tape onto existing structures.
> I can see that you didn't understand what I said at all. That approach
> won't work because there are things that you can construct that are
> ambiguous e.g., CM6 vs. Am7: how are you supposed to decide, especially if
> the picthes are in an open spacing? Like I said before, there are two
So what ambiguities do we have left if we store the tonic of the chord
as well? <c e g a> can not be confused with Am7 if you know that
the tonic is C.
> contexts that this whole chord thing can occur in: One where the user has a
> certain flavor of chord in mind and you go look in the box to see what
> matches that flavor and you give it to them, and one where the user hands
> you a list of pitches and says, "Here, figure out what this is." The second
> case is a lot more problem prone (just ask anyone who uses Cubase) and
> subject to ambiguities while the first case is not. And, in the second
> case, you're still going to have to do a whole bunch of if-then statements
> anyway, so what's the problem (I can fix the stuff in Chord::Chord BTW)?
There are two issues: the first is that the implementation is not up
to my standard, with the lengthy if-then syntax and bugprone
synchronisation between various input and C++ files. That is something
minor, and it can be fixed. (Because it is minor, it was the first
thing I saw)
The second issue is that the implementation has a specific, limited
set of chordnames hardcoded. I don't think this is a good solution,
because at some point someone will pop up and say ``Hey, how do I get
{American|Australian|Swahili} chordnames for {oriential|baroque|jazz}
chords?''. I don't want to tell this someone that it is not possible,
because we decided that there only be One Set Of Names together with
One Set Of Pitchlists.
So I think a solution should be
1. Be Generic
2. Failing that, Be Configurable.
I think the interesting questions are:
1. What extra information is needed to make a list pitches uniquely
represent one "flavor" of a certain chord,
2. How do we offer end-user customizability of every mapping between
names (labels) and pitches
Sorry that I sound so harsh; I know I do. But there is a reason: past
experience has taught that it is always better to get thing Right from
the beginning. I fear the future bugreports that result from this
approach.
PS. Please don't get upset with me because I am critical of the things
you make. It's nothing personal: I am critical of almost everything,
including stuff I write myself.
--
Han-Wen Nienhuys, [EMAIL PROTECTED] ** GNU LilyPond - The Music Typesetter
http://www.cs.uu.nl/people/hanwen/lilypond/index.html
