>>> C13 = C,E,G,_B,d,f,a >> Well that's the next step. And *that* is wrong. C13 would imply >> a #11, since that is (almost) the only 11 used in dominant chords.
It's not wrong if that's what the transcriber *meant* by C13. > This is surely an issue for the interpretation of the ABC/MIDI player, > not for the standard (*laugh*) to define. It's neither. It's for the *transcriber* to define. There is no chance that chord names beyond the simplest can be standardized in ABC, since they aren't anywhere else. What we should have is a uniform definition mechanism that makes it possible for transcribers to invent arbitrary chord names and give them a semantics that can be used by player software. The top line above does that, albeit with an ambiguity about what the commas mean. I've done this with BarFly's macro mechanism, which isn't ideal for the job but shows the sort of thing that could be done. A new kind of defining header line like c:FTris=F B ^d ^g % Tristan chord, I guess there's no jazzer's name for it would be more like it. Any "standard" chords should be those on which there is *absolutely no* divergence of interpretation between different musical genres. (Perhaps only major and minor triads, diminished and seventh chords). Anything else would need to be defined (in a file header, say) and software would have every right to complain about it if no definition were available in the environment. > Any chord naming standard within ABC [...] should exist purely to > define what are legal, unambiguous chord names and the full spelling > of the chord they name, NOT how any player software, chord name to > guitar chord box translator, auto-accompaniment generator, harmony > generator or anything should play or voice them. Better we have no chords at all than a construct with no semantics. =================== <http://www.purr.demon.co.uk/jack/> =================== To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
