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.
They also make certain things possible to express that cannot be done
reasonably any other way.
I have beside me a book of Galician folksongs, Daniel Gonzalez's Asi
Canta Galicia (1963). Most of the tempi are given in Italian, with no
numerical equivalent. What speed is andantino as used by a Spanish
folklorist in the Sixties? I've no idea; I could look it up, but why
should I do so before I start transcribing? What speed is implied by
aire de muineira, one of the non-Italian ones? Not a clue. But if
I had redefinable file-global tempi I could still transcribe these
pieces, knowing that I could *later* consult the New Grove or someone
with specific knowledge and insert the correct definition.
I have a bunch of files like this already, with tempi using the syntax
I suggested. BarFly can't process them unless I comment the textual
tempi out. But there is no way in hell I am going to post them on the
web, ever, with my guess at the numerical values fixed per-tune; that
would be utterly irresponsible stupidity, as bad as the abc2win tempo
fuckup.
Another example: ornamentation, as BarFly does it by macros. There
are some ornament signs which are essentially style-dependent, and for
that matter instrument-dependent. If you want to hear what a piece
written for flute with trills might sound like on the harp, you had
better redefine those trills to be no-ops, because the result would
otherwise both be unplayable and sound hellacious. For the Highland
pipes, there are tunes which have been played for 150 years or so with
the ornaments getting steadily more complicated as players get more
virtuosic. The natural way to write this in ABC is to have the ornament
given as a macro defined at the start of the file or in an external file:
that way you take a single tune and get 19th or 20th century versions of
it just by changing one line. Editing pipe ornamentation in ABC is not
easy, and any sort of abstraction mechanism will cut the workload by a
substantial factor.
It means you can't take a large collection and turn it into a ZIP
archive, one member per tune,
There are collections already that you can't do this with, simply because
you won't have a clue how to use the music without the textual commentary
provided by the file. Look at the George Skene pipe tunes on my website.
Some are gibberish if you don't know their background. (I've had more
emails about those than every other tune on my site put together; they're
getting careful and informed attention by people who want to use them for
real).
or store an arbitrarily large collection of tunes in a relational
database, etc., etc.
Twaddle. Add a few extra fields to represent the values inherited from
the environment and, to be on the safe side, another one identifying
the file (or other environment) the tune was extracted from. It takes
a certain amount of pre-processing to get that information (something
you could write in Awk or Perl in an afternoon if you're halfway
competent with either) but *storing* it is no problem at all for the
relational model. In fact the relational model is specifically
designed to avoid update anomalies of the sort I was talking about,
and the reasoning behind my proposal is absolutely standard in data
modelling. *Not* doing some such normalization in a relational design
for a tune database would be laughable - what do you think higher
normal forms are for? Is 1NF as far as you think? Do you even know
the difference between a relational database and a personal computer
address book?
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.
It's safe except that it loses global redefinability, which is the point
of using the more interesting global fields in the first place. There
might be times when such a tool could be useful - e.g. when adapting
well-structured ABC files to a crippled or legacy implementation - but
for most purposes it would be better inside the ABC interpreter. (For
macros, BarFly already provides this as a source-to-source utility, as
well as an internal function).
In these days of cut and paste, the saved typing convenience is
inconsequential.
If you've looked at any of the ABC I've written you should see instantly
that typing convenience is *not* something I concern myself with. Some
of that stuff must be among the slowest-entered ABC on the web.
A fast 6/8 Jig should not become a slow 3/4 March
just because you re-organize how you store your tunes.
And *how* fast is a jig,
