Well, considering you really need to parse most fields *anyway* in order for
the parser to have a context for parsing the actual tune data (for example,
if Key is currently G, then the F note I just read is actually an F#...),
I'm not sure it makes much sense to leave that decision up to the
In message [EMAIL PROTECTED], Paul Rosen
[EMAIL PROTECTED] writes
What about fermata over a barline?
I didn't know it was possible, but, OK.
For a little book giving a lot of information about Music notation I
commend Gerou: Essential Dictionary of Music Notation. I don't think any
writer of
On Sat, Sep 11, 2004 at 02:17:00AM -0400, Paul Rosen wrote:
First of all, I was working from the 1.6 document, I probably should have
been using a newer one. I noticed that
http://www.gre.ac.uk/%7Ec.walshaw/abc/abc-draft.txt contains some
interesting stuff. Is that the latest that has
On 11 Sep 2004, at 07:17, Paul Rosen wrote:
rhythm - arbitrary length string.[can this be interpreted in any
way?]
Yes. Several programs (BarFly, abcMus, abc2midi) use it to invoke a
stress
program when playing. However, it's probably best to leave it as a
string
here and let the controlling
In message [EMAIL PROTECTED], Paul Rosen
[EMAIL PROTECTED] writes
as you might have read in other posts, I would be very interested in any
work on API for accessing ABC file once parsed. I still did not have a
clue
for creating one and I would welcome any suggestion! Just let me know when
you
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
as you might have read in other posts, I would be very interested in any
work on API for accessing ABC file once parsed. I still did not have a
clue
for creating one and I would welcome any suggestion! Just let me know when
you got an idea.
I would break the problem into two parts: first
