I dont know if this message was lost or deliberately killed, but here it is again just in case it was merely lost... ------------------------------------------------- >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
