> 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, exactly? Different standards are applied to identical tunes depending on their context of performance. I would hope that an "aire de muineira" would eventually be played as an aire de muineira once I'd got it right. On your proposal there would be no integrity constraint to enforce that. You are insisting that bad guesswork should be immortalized. I am getting more than a little pissed off with this. There may be a subculture of ABC users who have no interest in any functionality beyond plundering the web for Irish session tunes for quick-hack programs to print in PostScript, but some of us have wider visions and tougher requirements. Stop getting in the way. =================== <http://www.purr.demon.co.uk/jack/> =================== To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
