>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 said it was ugly! :-p So basically, you'd have something like c-\maj7
instead of c-maj.7. That would be workable. Only where would the
definitions go? And how would the user be able to configure them? I know
you've already been able to do this with languages (via the english.ly,
etc). Chords indentifiers of this kind would be a natural extension of this
idea. Glad I thought of it! ;-p
>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.
The problem comes in when you call banter_str and you have to figure out
what chord that list of pitches is. You'd still have to check it against a
preset list of chord formulas, so you gain nothing--you'd be doing extra
work to figure out a chord that the user already informed you of. Now, in
the Chord_indentifier structure (that has yet to be written) you would have
a chord_type variable that would tell you on the on hand what kind of chord
I should construct (that the user supplied) and on the other, that the user
sent a list of pitches and that I should figure out what it is. This is
*not* a bad way to handle things! I'm curious to know why you think it
is...
Also, what happens when you have a bass tone thrown in for good measure?
How would you name <g d f a c> when you don't know whether or not G is the
tonic?
>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)
I completely agree--having to go through four different files to get what
you want is *not* a good way to implement things. You (well, mainly Jan)
were asking for me to post what I had even though I knew it was far from
complete, so I post and get blasted for it. But that's beside the point.
The point is, what else can you do with a list of pitches other than check
what the user has given you against a list of known chords?
>The second issue is that the implementation has a specific, limited
>set of chordnames hardcoded. ...
>So I think a solution should be
>
>1. Be Generic
I don't believe that this will satisfy anyone.
>2. Failing that, Be Configurable.
This is probably the best way to go about it.
>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,
You can't. When you put it all together, you can't possibly come up with a
smart enough algorithm to do this because there exist too many
ambiguities--especially if there are additions, subtractions, added bass
tones or what have you (this is completely different from if I *want* to
have lily try to name a list of pitches for me). Besides, if I tell lily
that I want to print (in the text part, mind you!) a Cmaj9no5/F chord, I
don't want it to guess at what I mean! This is the worst of all possible
scenarios--the computer telling *you* what you want instead of doing what
you want it to do in the first place! Imagine if you were typing away in
mcedit or what have you, and all the sudden what you typed didn't match up
with what you saw on the screen? You'd be pretty upset, wouldn't you? ;-p
>2. How do we offer end-user customizability of every mapping between
> names (labels) and pitches
This can probably be done in the same manner as the language customizations
that you already have in place. The question then is, how do you pass that
information to the Chord object?
>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.
I totally agree, again. But the way the current structure is, I don't see
any good alternative than the approach that I posted a couple days ago. If
the chord shouldn't be a Simultaneous_music object, then it should be a
Chord object. Plain and simple. It should exist from the time the user
creates it, up until the chord-name-engraver calls on it. The existing
approach of trying to stick it in the score as a group of pitches is not a
Right approach, IMO.
>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.
I've tried not to, but it's awfully tough not to when people call your
approaches stupid! It's not a good way to encourage development! I can
tell you, that I'm not a slouch when it comes to coding--I've written large
and complex programs all on my own, so I have a pretty good idea of what
good code and good algorithms look like! And I don't mind constructive
criticism, as long as it's *constructive*.
-- Shamus
