Paul Rosen writes:
>elemskip - arbitrary length string.[What does this do?]
>
Elemskip is the distance between notes, a real number. It is used by abc2mtex,
but probably not by any other program. It's good to have the parser accept an
arbitrary
string, tho, since if the field is eventually re-cycled, it could be used for something
having only text; then there'd be no backward compatibility problem.
>The thing that has always puzzled me about ABC is all the header fields. As
>far as I can tell, not all programs treat the headers the same, and some
>ignore some of them. Is there a recommended place that each of the header
>text fields should go?
>
Yes---elemskip is a good example---all programs but one ignore it. In the
header
section, only the X: and K: fields have fixed positions. (Of course, it is important
whether the fields occur in the header or inline.) But the order of the fields is
purposely flexible; makes parsing harder, perhaps, but it cuts down enough on the
errors
in writing tunes to make that worthwhile, especially to musicians. (!) This goes for a
number of other features of the language, since it's supposed to be both human-readable
and human-writable, as well as machine-readable. I gather from the comments I read in
these threads that the result is an uncomfortable cross between computer and human
languages, which might be aggravating when you're the one who has to write the parser.
But then, this is yet another reason that a universal parser would be a boon.
>There is one major limitation with the data as expressed above: If the point
>of the application using it is to modify the file, then comments, line
>breaks, and other details are important so that the file looks as much like
>the original as possible. In other words, not only should the structure be a
>straightforward description of the music, it should have all the information
>that is required to write the tune back out identically. For instance, we
>should be able to tell between "C" and "4/4" in the time signature. One way
>to handle comments, spaces, and line breaks is to have a second structure
>that contained them and instructions for inserting them back where they need
>to be. Many programs would ignore that, a transposing program wouldn't.
>
A good point. Since the notation is supposed to be human readable, you want to
keep just about everything in place--it's difficult to know beforehand what small
changes
will confuse a human reader, or, for that matter, for what purposes the parser will be
used. Secondly, this is a good test of your parser: if you can replace the tune from
its
representation in the parser, you know that the parser is complete, i.e. it has all the
information it needs. (In mathematical terms, the mapping abc ---> parsed abc is
invertible.)
Cheers,
John Walsh
To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
