James Allwright wrote (regarding file-global header fields like R: and M:)
>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). > Hear, Hear! File-global header symbols are a minor convenience in that they save some typing if you have a large collection of say, 6/8 Jigs. But as James noted, they make it impossible to operate on one or more individual tunes without reading and parsing through the ABC file from beginning to each particular tune of interest. This means you can't just grab a specific tune out of a file and paste it in a E-mail message with confidence it will be correctly printed/played by the recipient. It means you can't take a large collection and turn it into a ZIP archive, one member per tune, or store an arbitrarily large collection of tunes in a relational database, etc., etc. Adopting James' proposal represents a significant gain at a trivial cost. A simple one-pass conversion tool could be provided to read in any valid existing ABC file and spit out a copy, with all the global fields properly distributed to each individual tune which lacked them. Since it would only alter tunes lacking the global fields, such a tool is always safe to run, even on input already converted. In these days of cut and paste, the saved typing convenience is inconsequential. A fast 6/8 Jig should not become a slow 3/4 March just because you re-organize how you store your tunes. Naturally, the same argument applies to any other file-global operators various implementors may have added through special comments like '%MIDI'. Alan S. Watt [EMAIL PROTECTED] 770-469-7544 (USA) [Voice/FAX] http://www.mindspring.com/~alan.watt To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
