Phil Taylor wrote:

> To return to the original suggestion in the title of this thread, it
> has been suggested many, many times before.  One of the first postings
> I ever made to this list (or was it the developer's list?), made
> exactly the same suggestion - for goodness sake lets write the version
> of abc used in this file at the start so programs know what they have
> to deal with.  It's a great idea, but it won't work because:
> 
> (1) The fundamental unit of abc data is not the file, it's the tune.
> ... [snip]
> So the identifier would have to be added to individual tunes to be
> useful, rather than go in the file header.

I fully agree with you.  My suggestion is exactly that - this belongs in the
header of each tune, and in fact, might be best defined as the first line of
a new tune, making it a much more easily identifiable tune break.  (IMHO,
there should be NO data in an ABC2 file which exists outside the context of
the current tune -- I don't know if anyone else agrees with this, but it
makes the most sense to me...)
 
> (2) A surprisingly large proportion of users type their abc directly
> in a text editor.  There's no way you can make these people include
> the identifier.  They mostly won't bother, and if their software enforces
> it they'll prefer to use a program which doesn't.

Which is why I suggest it as part of a new ABC 2.0 standard.  If *all*
programs which support ABC 2.0 need that line, then people will use it when
writing new tunes to that format.  It's not like typing "%%ABC2" at the
start of your tune is a particularly onerous or time consuming task.
 
> If you really want to write an abc parser, you will have to get your
> head round the idea that abc is not a computer language, it's a
> natural language (albeit a very simple and regular one, with very
> few dialects).  It makes writing a parser a much more interesting
> task.  If you want an easy (to the point of being boring) job, write
> a MusicXML parser.

The issue with XML is you end up with something trivial to parse, but nearly
impossible to write without machine assistance.  The main reason I like ABC
(and I suspect others do also) is it's relatively easy to type in music in
that format.

Unfortunately, ABC as it exists now has indeed become a natural language,
and that limits it's usefulness immensely in the computer world.  And I beg
to differ about "few" dialects -- as near as I can tell, there are at least
as many dialects as there are programs to handle ABC, and from comments here
on this list, I suspect there are even more than that.

I have no problem developing a complex parser -- I've done that plenty of
times before, but developing one from scratch which has to deal with
multiple conflicting rules and absolutely no means of identifying which rule
applies, is absolutely no fun at all.  Writing a parser isn't the goal -
it's a necessary step in creating a new program, and there's no reason it
should be as bloody difficult as it currently is.  (Which reminds me -- is
there ANY other open source parser out there other than the several dozen
variants of the ones in ABC2PS and ABCM2PS?   I'd like to look at one,
especially an object oriented one if one exists...)

Maybe I should be proposing that the new standard not be called "ABC 2.0" at
all, but something entirely different.  It would still be the same goal --
establishing a truly standard computer-readable dialect of ABC, but by
changing the name, it loses the baggage that name currently carries...

-->Steve Bennett

To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html

Reply via email to