>> The user makes more difference than the developer here. If an ABC >> file is clearly written *as source*, with the right choice of default >> note length and laid out with some regard to the musical structure, >> it's easy to work round dialect differences because you can see what >> you're editing. Easier than it is to modify a sloppily-encoded piece >> that fits your own platform's model perfectly but in ways only a >> computer can understand. (We should maybe have an annual obfuscated >> ABC contest to underline this point). > Maybe, sorry to quote you entirely again, an upadated standard, ridden > of the inconsistencies and the ambiguities of the old one, and stating > clearly as a number of new features were to be notated, would give > exactly the same results, but with no need to learn different abc > dialects or to edit the files!
You can't change the past. There are tens of thousands of ABC files already out there on the web and a lot of them conform to no standard that has ever existed. They're not going to disappear, most are not going to be fixed on their home sites, many will go on echoing down the years in their original form on mirror sites even if they do get fixed by their creator, and they're not going to lose their musical value. So new standards won't help avoid the need for editing. For an example, look at the American fife tunes on my site. That was a rescue job: I had a copy from a defunct website. It was the only one anybody knew of and the original transcriber had vanished. Whatever print sources he was working from seemed to be unknown to anyone else. So this stuff was unique. It was also a thoroughly slapdash piece of work, with syntax errors and just plain gibberish making it unusable on *any* ABC implementation. I cleaned it up manually; the file on my site contains both the cleanup and the original so you can see what I've done. Creating a new standard would not have solved this problem: human editing was the only way out (which involved me learning a dialect of ABC which seems to have existed only in the transcriber's mind). It wasn't a particularly big job but it wasn't an automatable one. Being more standardized may not necessarily make a version of a tune preferable. When I'm looking for a tune in a hurry I quite often use John Chambers' versions: he has one irritating habit which invariably forces me to edit - putting empty bars into the ABC source because that way his typesetting software puts a barline at the start of each line given the linebreaks he prefers - but nonetheless his versions are accurate, they have good chordings and they are laid out readably so if I want to monkey about with something (e.g. rewriting a phrase of fiddle music to fit the flute) I can easily identify which bit needs monkeyed with. At this point, I think editing tools would be more useful than more standardization. Software for transposing, changing the default note length in tunes, introducing broken-rhythm signs in the right places when the original uses numbers, changing multivoice conventions, putting header fields into your preferred order, swapping between "T:.*, The" and "T:The .*", computing a checksum and putting it into the header, checking for gross mistakes and helping to fix them (bars that don't add up, ties between notes of different pitches, notes out of range or impossible gracenotes when using an HP key signature), "diff"-like tools that locate similar phrases and display their differences, tools to identify chunks that could be abbreviated using repeat syntax and to expand repeats into fully-written-out forms. Given enough whizzbangs like this, standards become less important, as it's easy to transform stuff from one style of ABC to another. > I [...] stated [...] that the abc standard, as far as the native > softwares were concerned, had a built in line break carachter: a > blank P: field in the body. Actually, Jean-Francois Moine hacked > abcm2ps (yes, as far as Windows is concerned, this is the only > native abc free source software that IMHO is worth consideration!) > to enable printing a part label in the middle of a music line - > yet, I don't think anybody else has done anything similar BarFly does what you want here (sort of: the part label doesn't appear where you type it but after the next bar, which is horrible for sections with upbeats, but at least you don't get a line break when you don't want one). > I am simply asking, to start with, to be able to notate a second > treble voice on the melody line, and a bass line on a second staff. There is no reason why every implementation has to allow this. If a developer's primary focus is on doing a really good job for a single kind of music - say, guitar-accompanied songs or Highland pipe music, both of which have picky requirements and neither of which needs the feature you're asking for - users who get the software because it does what they want don't necessarily need to worry about what it can't do. There are other standards like this. Do you say an RS-232 device is non-compliant because it doesn't use every pin on the connector, or that a peripheral fails to support ASCII because some of the control characters 0-31 don't do anything? (The only standard I know of that said "all or nothing" explicitly was Ada, and we know what happened to that). =================== <http://www.purr.demon.co.uk/jack/> =================== To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
