>: 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.
> 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).
You can't do a lot with a C function like
void thing()
{
x++;
}
unless you have a declaration for x in the environment, either.
You want to rewrite yaps in a language that uses those constraints?
(Only assembler does, as far as I know).
The point is that the non-local definability is USEFUL. Trivial tweaks
that only affect the typeface header fields are displayed in is an utter
waste of time. No ABC program is ever going to compete with a special-
purpose music typesetting engine and it's pointless trying. But ABC
*already* has richer semantics in some directions than they do, and much
greater flexibility of application. Those are directions in which further
extension will give it unique advantages among all other forms of musical
representation.
These non-local features are not exactly cutting-edge stuff to implement,
given that programming languages have had declarations since 1956 or
thereabouts and block scoping since 1960. And it was in the very first
computer implementation of ABC.
I don't *want* my tunes edited out of the context I presented them in.
Ever. Any proposal that helps prevent it is an advantage in my book.
Conversely, anyone who *does* want their tunes edited out of their
original file context can just avoid using non-local constructs. You
couldn't very well use them accidentally.
So the only people being hampered by this are people who want to use
music in a way that the original transcriber didn't want them to. Is
that a category of people we want to cripple the notation for?
] 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.
Perhaps having their messages automatically harvested by bots might not
have been what the authors intended either. You can't assume it unless
that was stated up-front as the policy of the list when they joined.
What was the problem with contacting the transcriber and asking them?
Maybe they might have wanted that history included (e.g. as comment
lines or embedded in H: fields). It's not like we're short of ways to
quote stuff. If somebody puts an ABC tune in an email message, a simple
default is just to put % signs at the start if every line that isn't the
tune.
=================== <http://www.purr.demon.co.uk/jack/> ===================
To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
