On Friday 05 April 2002 15:12 pm, John Chambers wrote: > 1. ABC users who play jazz and other styles that need "fancy" chords > should discuss the subject with the idea of coming up with one > machine-readable chord standard, and
Erm, some folk does! ok, ok - some 'contemporary acoustic music' does. > 2. Musicians who don't need such chords should be casually ignored. > > I'd actually put myself in the latter category. I mostly play "folk" > music. In a number of radically different styles perhaps, but none of > them makes any use of complex chords. I often find myself casually > ignoring chord modifiers like '7', on the grounds that such things > just muddy the sound and shouldn't be used unless they contribute > something useful such as a hint of a key change. So you should just > ignore me. ;-) > > Probably all the current software understands this minimum form of a > chord inside double quotes: > > 1. A letter [A-G] giving the root of the chord; > 2. A '#' or 'b' for sharp or fla; > 3. One of 'm', 'min', 'maj', 'dim' or 'aug'; > 4. A number (7, 9, ...) to indicate the "top" of the chord. > > Some but not all programs also recognize: > > 5. '/' followed by a bass note [A-G] and accidental [#b]; abc2 midi being one that doesn't. > 6. (...) giving alternate chords. I've not seen this one in use. If we can keep () out of the chord notation, it's fine. > We might add that the case of the root and bass note letter is not > significant. I guess. > This s a good idea because current practice isn't at > all consistent here, and it doesn't really make much difference. Note > that this does eliminate the common practice of using lower case to > mean "minor". As elegant as that might be, we're probably better off > if abc doesn't adopt it. Agreed. > (Just as we should officially ban the use of > "B" to mean B flat and "H" to mean B. ;-) YES! > I'd suggest that we treat these as the *only* things that are > actually defined in the abc chord notation as of April 2002. Then we > turn the subject over to a cabal of musicians who need fancier > chords, and let them come up with a good way to handle the rest of > the job. The two constraints are that it must be plain text and > reasonably easy for a computer to parse. It need not agree with any > current notation in printed music, though of course it's best if we > can get as close to common practice as we can with plain text. > > Membership in the chord cabal should be voluntary, but anyone who > ever says "Who needs it?" should be summarily evicted. We want a way > to notate whatever chords people think they need. Those who don't > need them don't have to use them. Note that this is VERY different from 'we need a way to represent my pet notation for this chord'. > The best place to start might be to list the features that are needed > in the eventual full chord notation. > > (Well, maybe someone might want to say what I've missed in the above > summary. ;-) Not a lot. Well put. I offer for consideration (once again) http://www.altrion.org/cgi-bin/parsechord.cgi. It has a couple of bugs, which I will fix shortly, and I haven't *clearly* documented what it accepts, which again, if there is sufficient interest, I will do. I will note, though, that its position in the great "what does + and - signify?" debate is simply that THEY ARE NOT LEGAL CHARACTERS IN A CHORD NAME. If anyone tries to tell me that they are in THEIR chord naming scheme and thus this one is invalid, I will take my toys away *grin*. This is intended to be an UNAMBIGUOUS, MACHINE PARSEABLE chord syntax, that just happens to correspond in most respects to what I consider the least ambiguous one in use out there. -- Mike Whitaker | Work: +44 1733 766619 | Work: [EMAIL PROTECTED] System Architect | Fax: +44 1733 348287 | Home: [EMAIL PROTECTED] CricInfo Ltd | GSM: +44 7971 977375 | Web: http://www.cricinfo.com/ To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
