Erik asks: | Is there a good reason why the X: field is required?
Actually, lots of abc software if very casual about this. My ABC Tune Finder will dig tunes out of text if they just start with the T: line and have a K: line. The tune-extraction code generates X:1 if it is missing. I'm not the only one who has done this. So to a great degree, the initial X: line is no longer absolutely required; it is required by some but not all ABC software. | * It is not nessecary to separate the tunes since | an empty line is used for that purpose. Correct. | * It is of no "musical" use for a reader/parser Also correct. For another metaphor, a page number in a book has nothing to do with the subject material. But most books do have page numbers. They are useful despite being "irrelevant" to the text. | * Since its context is very small (file-specific), | the X: number cannot be used as a tune ID, since | other tunes in other files may have the same | number. Wrong. It's the equivalent of a track number on a recording. It need not be unique in the universe to be useful; it only needs to be unique within the file. There are a number of ABC tools that use the X index to select a subset of the tunes from a file. Of course, if a file contains only one tune, defaulting the index to X:1 works quite well. If there are two or more tunes, the index number can be very useful to users. | * "Inline tunes" (tunes sent by e-mail etc) often | lacks the X: field. This shows, I think, not the | lazyness of the writers, but rather that the X: | field has no meaning to them. If I e-mail a single | tune, why do I have to enumerate it? If I copy it | from an abc collection, I might want the X: field | to remain, but I'm not talking about abolishing it: | I'm talking about making it non-required. Correct. I've noticed that messages to mailing lists usually have the X: lines if there are several tunes in the message; the X: is omitted mostly when there's only one tune. This implies that the writers understand the use of X: as a simple way to distinguish the tunes. If there's only one tune, there's nothing to distinguish, so the X: line is superfluous. | * Merging abc files often creates X: doublettes. Yes, so its useful to have software that renumbers the tunes. I have a couple of perl scripts that combine ABC tunes in several ways, and they renumber the tunes by default. | IMHO, there is no reason at all to have X: as a required field in abc. | Again, it may have a good use, but why _required_? I'd agree. Currently, we have the problem that a lot of ABC tools do require the X: index and reject tunes that don't have it. We'd have to persuade a number of programmers to do a bit of coding to make the X: line optional. Or we could just leave it in the standard, but suggest that "user-friendly" software should make X: optional, and generate X:1 on output for the benefit of less friendly software. | BTW, changing this will not change the compability with any existing | abc files. True. And it would bring some of them into compliance. There's a larger issue that would argue for making everything in ABC optional: I've worked on some ABC documentation, and one of the real pains is producing the sort of tiny examples in illustrations that you'd expect in a text. Such examples are typically of fragments of music, and you often want to omit everything except the small bit that you're illustrating. Thus, I've often wanted to be able to produce a few bars of music with no title, no clef, no time or key signature, and maybe not even any bar lines. You can get "no key signature" by saying K:C, but the current standard doesn't allow omitting some of the others. M:none has been proposed to eliminate the time signature, but not many ABC tools implement it yet. I mostly use abc2ps, which has allowed me to omit the T: line for some years. But there's no way to say "no clef", for example. Maybe I'll implement a "clef=none" clause in the K: and V: lines, but this will produce ABC that other programs will consider an error. To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
