James Allwright writes: | > They're in the 1.6 standard for other header fields: | > | > : Most of | > : the information fields are for use within a tune header but in | > : addition some may be used in the tune body, or elsewhere in the | > : tune file. Those which are allowed elsewhere can be used to set | > : up a default for the whole or part of a file. ... | | This is not a widely implemented feature of the abc standard and I | would personally like it to become deprecated. My reasoning is that | if you have global fields, you can't treat a single abc tune as | something that can be edited out of its source file (which you might | do if you wanted to print off just one tune from a collection).
Some time back, I ran across a nasty "gotcha" with this that encouraged me to "deimplement" such per-file header info for a number of my own programs. I'm on a number of mailing lists that use abc a lot, and I have some little programs to extract tunes from email messages and do something with them. The problem is that messages often have a bit of discussion of the tunes, including history and variants and other similar tunes. It isn't at all unusual for the text before the tunes to have fragments of abc, sometimes just a few header lines, and these fragments often have little or nothing to do with the later tunes in the message. So if the fragments are added into later tunes, the result is often not at all what was intended. Writing software to understand English and do the right thing in such cases is utterly hopeless. I don't think I've ever seen a case where abc header fragments in a message were a useful addition to later abc tune(s), so I've just made my programs ignore such fragments. If I ever have occasion to use these programs on actual abc files, I may re-enable processing of "global header lines". But so far, I haven't seen a need for this. To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
