On Sat, Feb 24, 2001 at 02:00:00PM +0100, Jack Campin wrote:
> 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).
I think we need to be clear on what we're discussing here.
The way I see it there are THREE different things under discussion
here:
1) the format in what the user enters the chords
2) the format of chord names in an ABC file
3) the manner in which ABC outputs the chord
1) is dependent on the program: there is NOTHING to stop MacTune, or
whatever the program happens to be called, defining its own chord entry
format (as MUSE has), or even multiple dialects of same for German users
who prefer - for minor, etc. For straight text entry of ABC files, this
format is equivalent to 2). For other methods, it need not be, BUT the
program must convert to 2) when it exports to ABC.
2) is what goes in the ABC standard. IMHO there should be precisely one of
of these, and it really doesn't matter what it is as long as it's
clearly defined and reasonably easy to enter with a text editor. We
don't allow H for Bnatural in ABC, nor should we allow multiple ways
of specifying 'minor'.
As to how comprehensive it should be, that appears to be where we're arguing:
my opinion is it should be able to handle any cenventionbally accepted chord
type we can come up with, preferably using one of its conventional names.
(By which I do not mean we should (say) allow both Aaug and A+, but that we
should pick one consistent naming convention from those available and stick
to it.)
NOTE: format 2) is COMPLETELY independent of the program in use: it's an
aspect of the definition of the ABC language, nothing more.
3) is actually dependant on what the ABC-to-whatever program is trying to
produce. If it's ABC2MIDI, then it's parsing the chord to a set of
notes. if it's an abc2ps variant, then it's printing the chord name,
*quite* *possibly* in a manner specified by the user with command line
ot program-specific directives. over/under the music, it can look it
up in a dictionary of guitar chord boxes, or programmatically work
out a set of fingerings for cittern tuned DGDAD, etc etc etc. It can
do any and/or all of the above and more, provided that the format in 2)
is rich enough to allow it to draw out the necessary information.
The point is, these are three different issues, and the key one, *IF* we
think that it is a needed feature of the language, is that the chord naming
in *ABC* be rich enough to support the needs of the programs that read it
and generate output from it.
> 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).
Or perhaps for fast creation of a lead sheet (words plus chord) for import
into a wordprocessor or song database (I'd find abc2leadhseet handy sometime -
my songbook is moving over to ABC)
--
Mike Whitaker | Work: +44 1733 766619 | Work: [EMAIL PROTECTED]
System Architext | 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
