>> 3) allow chord 'dialects'...
> Option 1 obviously means chaos. Option 3 means chaos too.
> As an implementer I just don't see myself supporting multiple different
> and incompatible dialects. Writing the code would be OK - just have a
> pile of tables. Supporting it and answering the questions from completely
> confused customers would be a nightmare.
The tables don't need to be in the application, they can be in the ABC
files. BarFly already allows for something like that with its macro
mechanism: I can write the macro
m:Mn = [npr]
in the header to define to get a major chord, so that if I later write MC,
in the tune body it will be expanded to [C,E,G,] . This isn't yet enough
for a guitar chord mechanism, as a particular macro only applies to notes
of one length, but an analogous syntax ought to work for an extensible
chord mechanism; it only has to give the user access to functionality
that's already there in the ABC application. A possible syntax might be
to give the relative pitches by specifying one case:
g:A dim = [A c _e]
in the header, and then "G dim" in the tune body would represent a chord
containing the pitch classes G, B flat and D flat. (I'm assuming the
program can do implicit transposition; there are other ways to notate
the same information, like that of the BarFly macro system used above -
I don't think there would be much difference in usability).
If the meaning of the chord symbols is right there in the tune file,
using the same notation already used in ABC, the user isn't likely to
get confused.
>>...Parsing "F sharp minor" to print "F#m" should be easy.
> No, it's impossible - because the range of things that
> might mean F#m is unlimited.
You missed the point. A user should not be constrained by a programmer's
idea of how to print chord names. This should be a display option. (My
preference for this particular chord would be a lower-case f followed by
a sharp sign, *not* a hash symbol).
The problem with the present staff display options for chords in ABC is
that are driven by their crappy ASCII approximations. Using a "b" for
a flat in the staff notation looks amateurish, but the present design
encourages implementers to do exactly that by just printing the user's
ABC notation for the chord verbatim. A design that decouples input
notation from displayed notation would avoid that mistake. (The only
occasion I can think of when displaying flats and sharps in ASCII would
have any positive benefit is when generating a chord chart in Braille
for a blind guitarist).
One particularly useful display format for guitar chords would be to
expand them into left-hand piano chords and put them on a different
stave. This could be a handy starting point for somebody doing a
keyboard arrangement.
=================== <http://www.purr.demon.co.uk/jack/> ===================
To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
