I've finally gotten a few free moments of time, and started thinking about
the "universal parser" that we talked about a few months back. I started to
write down the requirements for the output, which I've included below. I've
included everything I could think of for formatting and playing music.
The idea here is to create a universal data structure suitable for all ABC
applications. Then someone writing a better parser and someone writing a
better formatter could work independently.
If you are interested in this, please comment on the following and tell me
if I've left anything out or made incorrect assumptions. When I get a little
more time, I'll create a C structure that can handle this and post that.
-----
ABC parser output data structure.
Goal
3. This is the data structure between the ABC parser and the application.
There are two main applications: a sheet music formatter, and music player.
I think other applications (like a transposer) would not have any unique
demands on the structure.
4. The goal is to have a flexible enough structure that additional
requirements would be handled without requiring fundamental changes to the
structure. With luck, some additional requirements may be handled without
any changes to the structure at all.
5. The purpose of this structure is to completely separate the parser, the
formatter, and the player. Each one of these three functions can be
developed independently, and different developers can have their pieces snap
in.
General requirements
7. This structure is for a single tune. To do multiple tunes, you can simply
have an array of these.
8. Everything possible should be interpreted as much as possible. In other
words, a chord of "Gm" would be stored as a G minor chord, not the text
"Gm". This allows the player to not need to do any parsing.
9. however, the original wording should be available if needed. In other
words, "GM" and "G" are both a G major chord. Some formatting programs may
wish to use one or the other exclusively, or may choose to parrot whatever
was specified.
10. Extra formatting information may be in the structure. The most obvious
is the new staff indicator (the exclamation point) and the
don't-connect-eighths indicator (the space). Room should be made for many
others that may be put in the language later. For instance, what if the user
wanted a measure to be spaced out more than the formatter naturally would?
Or wanted to force the notes to be pointed up? Or wanted more room between
two particular staffs? Or a new page? Or wanted to decide whether the last
staff was justified or aligned to the left? In any case, no formatting is
required, and in that case, the formatter makes all its own decisions.
11. The structure should have a simple, fixed format so that it can be saved
to disk easily, or passed between programs written in different languages.
The saved version would be something of a "compiled" version, that is, our
equivalent of an OBJ file. This means that there can't be any pointers in
the structure.
12. A C++ class will encapsulate the structure, so that users of C++ can
easily gain access to the data in a natural way.
General structure
14. There are two parts:
15. The header contains one-time only information. that includes the title,
etc. It also contains global information, like whether to force all notes to
be pointed up.
16. The body is an array of items. These items define a particular vertical
space on the notation, and a particular time for the player. Note that the
amount of space and amount of time is variable for each item. A simple
example follows. Three possible items are a whole note, a half note, and a
bar. each of the three takes a different amount of time to play (the bar
takes no time to play). The bar takes a different amount of space to display
than the notes.
17. Items need to refer to neighboring (and farther off) items. For
instance, an item may indicate that a slur has begun, and another item would
indicate that it has ended.
Elements in the item
19. (All of the following are for a single stave. An element may also have
multiple staves.)
20. Multiple notes, each with a separate rhythm, and a voice number.
21. Chord symbol
22. Singing words (possibly multiple verses)
23. slurs and ties (connected to a particular note if multiple notes are
present)
24. The greater and less than signs that show the differences in volume.
25. New key signature, new tempo, new time signature.
26. The following accents (multiple ones could be in each item, and
sometimes multiple ones can be on each note in an item): slide up and down,
muffled (note head is an X), diamond head note, loudness markings, fingering
numbers, trill indicator, ritard, fermat, arpeggio, legato, staccato &
pizzicato, bowing symbols, pedal on, pedal off, accent, attack,
27. This item is part of a set of grace notes (the rhythm for them should be
stolen from the previous note.)
28. First ending, second ending, etc.
29. Bar line type: repeat, double, thick on left, etc.
30. Text in the staff instead of notes. That is: "8 bar intro", "piano
solo", etc.
31. Non-chord note above the staff. for instance, to indicate a different
instrument should start playing, or to label an interesting spot.
Elements in the header
33. All of the items in the header section of the ABC spec.
34. Additional verses. (probably printed at the bottom)
35. Global indicators, like number of staves and their clef.
36. Instrument name to the left of the staff.
37. Amount of swing (8th notes played dotted by how much)
Paul Rosen
--- Life is a musical, every once in a while
the plot stops and you start singing and dancing ---
http://home.earthlink.net/~catharsis.music/
http://home.earthlink.net/~theplums/
To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
