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
