John Henckel <[EMAIL PROTECTED]> wrote (regarding JC's good suggestion on the display of accidentals): >What you're saying is that the display program, such as "abc2ps", should >include options to > > 1. put global accidentals in the key signature (Yes or No) > 2. put global accidentals throughout the piece (yes, yes with >parens, or no) > >I hope you are not saying that ABC should have syntax to specify such >options. These options are not part of the musical content, therefore they >should not be in the ABC file. What John says here is in the spirit of several proposals I've made about the desirability of being clear that abc is centrally about musical content (rather than about display). Our Standards Document would be improved by keeping this in mind. For example, consider this part of the proposed revision of the standard: $ Alternate chords can be indicated for printing purposes (but not for $ playback) by enclosing them in parentheses inside the double-quotation $ marks after the regular chord, e.g., "G(Em)". The abc standard should _not_ enforce something like "for printing purposes (but not for playback)". Quite possibly, a playback program could have various options for dealing with alternate chords. Likewise, a printing program could well choose to omit alternate chords, or treat them in various imaginable ways. We can't forsee all this in abc. The revised standard should read simply: $ Alternate chords can be indicated $ by enclosing them in parentheses inside the double-quotation $ marks after the regular chord, e.g., "G(Em)". On the other hand, in some cases, it is probably desirable for a Standards Document to give users some idea of how "normal" programs which deal with (or import) abc are likely to treat the transcription in terms of playback or display, even though this may be fundamentally a matter for the documentation of these programs, rather than for the abc standard. (And, of course, if developers can achieve some sort of reasonable consensus on how they are going to display things, that's ok; though a perfect consistency may not necessarily be possible, or even desirable.) Two aspects of display are deeply engrained in abc: linebreaks and beaming. Admittedly, this is not part of abc syntax, strictly conceived as encoding musical information. However, surely something should be said about these things, if only in an advisory way in the any standards document. Consider the "tone" of the current statement about line-breaking and justification, with phrases like "generally" and "can look effective". My preference would be to clearly demarcate advisory comments about display and playback from matters of abc syntax. For example, following this philosophy, one might have a section in a standards document about allowable spaces within the tune. Something like this: "Spaces and linebreaks may be inserted into a tune with the following provisos: -A note-letter followed by a multiplier (e.g. A3) is considered a single note, and cannot be separated. -Compound bar lines, such as ||, |] |: :| ::, etc. must be written unseparated. -The repeat-indicator -- the two-character sequence of a square bracket followed by a numeral, e.g. [2 , is also considered an inseparable unit. However, a space or linebreak may intervene between a barline and a repeat-indicator. So, :| [1 is allowable. -The left-parenthesis followed by a number, to indicate triplets, quadruplets, etc. forms an inseparable unit." [ASIDE: this much is about abc itself; now on to display:] "If notes are grouped together without spaces, a display program will typically group the notes together under one beam. Thus in 2/4, A2BC would be displayed as an eighth note followed by two sixteenth notes under one beam whilst A2 B C would produce the same notes separated." "A program for displaying abc will typically create a new line of output at a linebreak in the tune. If the linebreak is preceded by a backslash \, such programs will normally not create a new line." None of the above is real proposal (and I'm certainly not proud of the writing style). I just want to reiterate that we distinguish, at least conceptually, between what you can and cannot do in abc from the way it will be treated by some program that displays, plays, or imports it. The standard must be complete and unambiguous with respect to the first question, though it need not be with respect to the second. (However, I would not go so far as to say that the second question is beyond the scope of discussion.) Robert Bley-Vroman Honolulu To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
