Re: [abcusers] Chord notation
Mike Whitaker said: ...we have three choices: 1) don't 2) pick one and stick with it... 3) allow chord 'dialects'... I would vote heavily for 2 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. There is in fact a high degree of consensus regarding all the simpler chords. I really wish that Frank Nordberg hadn't shot himself in the foot. (Frank - what you did was to give an example of a whole load of notation with no explanation. I simply have no idea what most of the chords you named are. I have no idea whether what you described was systematic or chaotic, whether you mixed multiple 'dialects' or just one, and so on. there was therefore no way that I could follow your lead. So we went of in various other directions). To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] Chord notation
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
Re: [abcusers] Chord notation
Laurie wrote: Mike Whitaker said: ...we have three choices: 1) don't 2) pick one and stick with it... 3) allow chord 'dialects'... I would vote heavily for 2 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. I agree wholeheartedly. There is in fact a high degree of consensus regarding all the simpler chords. I really wish that Frank Nordberg hadn't shot himself in the foot. (Frank - what you did was to give an example of a whole load of notation with no explanation. I simply have no idea what most of the chords you named are. I have no idea whether what you described was systematic or chaotic, whether you mixed multiple 'dialects' or just one, and so on. there was therefore no way that I could follow your lead. So we went of in various other directions). The main ambiguity seems to lie with the use of + and - symbols. "+" can mean augmented, sharpened or added, and there's really no way a program can determine which is correct. Even human readers have to be expert musicians and familiar with the harmony rules for this particular genre of music to interpret this correctly. I suggest, therefore, that we eliminate + and - from the standard and admit only the explicit namings, aug, #, add, dim, b and whatever we decide should mean "omit this note". Phil Taylor To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] Chord notation
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
Re: [abcusers] Chord notation
Mike Whitaker wrote: ... As far as I see it, if we *want* abc to require a standard for chord names, we have three choices: 1) don't 2) pick one and stick with it, either by democratic vote or the old "I wrote the code so I get to choose" argument *grin* 3) allow chord 'dialects' so that folks who do it different ways can load up the dialect they're used to with a %% directive. An important point here: this entire discussion has been about establishing a standard for how abc *playback* programs that tries to interpret chord symbols. ABC viewers and players that do not add automatic accompagniment shouldn't be affected at all. If we want to introduce such a standard at all, we have to find one that is: a) consequent b) as simply defined as possible c) able to express any combination of notes d) as close as possible to common chord notation There are definitely some conflicts between those four requirements, but we can handle that. I think the main problem is notating chord note alterations. I've been advocating the use of + and - rather than # and b because that simplifies the definition considerably. Example: The chord C E G Bb D is notated: C9 If we want to sharpen the 9th, we can just add a + in front of it: C+9 That simply won't work with the #/b system. C#9 is a completely different chord. The usual solution is to add a 7: C7#9 That's fair enough, of course, but it requires slightly more complex rules for the poor computer. In my first posting to this discussion I simply said that the idea was impossible. I still think it is. That is, it's impossible to define a set of rules that covers all the major systems for notating chords. But we don't have to do that. We can just define one particular system and say "this is what ABC uses". Then of course we have to allow for local definitons to override the defaults, such as adding the header field c: c- = Cm or c: c- = [C_EG] causes the chord "c-" to be interpreted as c minor in that particular tune. I'm sure there'll be hot debates about the exact syntax for this ;-) but the general principles shouldn't be too controvertial, should it? Frank Nordberg To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] Chord notation
On Sat, Feb 24, 2001 at 05:34:23PM +0100, Frank Nordberg wrote: Example: The chord C E G Bb D is notated: C9 If we want to sharpen the 9th, we can just add a + in front of it: C+9 I will repeat, for about the fifth time, that I and many others would read thatr as CADD9, C E G D. +/- That simply won't work with the #/b system. C#9 is a completely different chord. The usual solution is to add a 7: C7#9 Or to use brackets, which disambiguate nicely. C(#9). That's fair enough, of course, but it requires slightly more complex rules for the poor computer. You'll find my parser handles C#9 and C(#9) correctly. It's not hard. -- 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
Re: [abcusers] Chord notation
On Sat, Feb 24, 2001 at 05:34:23PM +0100, Frank Nordberg wrote: Example: The chord C E G Bb D is notated: C9 If we want to sharpen the 9th, we can just add a + in front of it: C+9 I';d further note that I just showed my wife this mail, without any prompting bar 'what's that chord' and her reaction (she's a keys player) was "C augmented 9th", i.e C E *G#* Bb D". Can we just abandon the idea of "+" and "-", please? It is TOO ambiguous, as I keep saying. There are no problems with # and b that cannot demonstrably be resolved with judicious use of brackets. From my test harness for parsechord: mike@andor:~$ ./parsechord 'C(#9)' C E G Bb D# mike@andor:~$ ./parsechord 'C#9' C# E# G# B D# mike@andor:~$ ./parsechord 'Caug9' C E G# Bb D -- 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
[abcusers] Proposal for (simple) ending syntax
While the great chord debate rages on, I thought I'd toss out what I've implemented in my abc2ps clone for handling more kinds of endings and repeats than the rather limited ABC 1.6 allows. This isn't a solution to all the world's repeat problems. It is merely something that is 1) very easy to implement and 2) covers 90% of what is needed. The current standard only allows first and second endings. It uses [1 and [2, where the [ may be omitted after a |, and there may be a : before or after a |. The abbreviation :: may be used for :|:, i.e., a combined end-repeat and start-repeat in the middle of a staff. The limitations here are that only twice-through repeats are possible using either of the notations: |: ... :| |: ... |[1 ... :|[2 ... || What I propose is that the new standard allow: - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 1. An alternate ending is indicated by [ immediately followed by a string of digits, hyphens and commas. If the [ follows a bar line, it may be omitted. It is expected that these define a sequence 1..N, in the same fashion as standard music notation, to indicate playing the phrase N times with two or more different endings.. 2. Multiple colons may be used before or after bar lines to mark the ends of repeated sections. These are used to indicate multiple times through the passage, one extra time per colon. If the multi--ending syntax is used, the extra colons may be omitted at the beginning of the phrase (to go along with conventional music notation). Multiple colons may be used to indicate multiple repeats without differences in the endings. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - The new standard might also include the statement that endings need not start at bar lines; i.e., it is legal to use [ to indicate an ending that is a partial measure. This is legal with the old standard, of course, but it often doesn't work, because implementors aren't familiar with the usage. Some examples of repeated phrases, where ... stands for the notes: A phrase played three times: |:: ... ::| A phrase played four times, with alternating endings: |: ... | ... |1,3 ... :|2,4 ... :| |::: ... | ... |1,3 ... :|2,4 ... :| |: ... | ... |[1,3 ... :|[2,4 ... :| |::: ... | ... |[1,3 ... :|[2,4 ... :| These are equivalent. The extra colons are useful for readability, but aren't needed because the 1,3 and 2,4 give the same information. A phrase played four times, with three different endings: |: ... | ... |1,3 ... :|2 ... :|4 ... || A phrase played four times, with a different ending the fourth time: |::: ... | ... |[1-3 ... ::|[4 ... || The extra colons may be omitted with no loss of meaning. A phrase played three times with partial-measure endings: |: ... | ... | ... [1 ... :[2 ... :[3 ... || Many musicians are not familiar with the multi-colon notation. But dance musicians usually know it very well, and like it because it makes the music easier to read. It's another "standard" that is not implemented by all ABC software due to lack of familiarity. I'd rather not see this degenerate into a discussion of how to notate all the possible repeat patterns. Granted, this isn't a completely general solution to all the world's problems. But it's something that handles most of the common repeat patterns, and can be implemented very quickly. Then we can discuss how best to handle all the remaining cases. I have a growing number of tunes in my collection that use these extensions ... To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
