First of all, thanks for some great insights! I knew that I should post my
ideas here first before doing any coding.
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.
As long as the structure contains all the information present in the
original abc it should be possible to perform any function which could
have
been done starting from scratch.
Yes, the trick is to contain the original ABC, as well as the
interpretation. We should be able to go backwards from the structure to the
original file, too.
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.
Anticipating future requirements is the difficult part.
Yes, that's why I used the words "with luck". In our case, we have the
advantage of being about to look at piles of existing sheet music from many
traditions and spanning centuries. If we're clever
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.
Not too sure about this. A guitar chord like "Gm" can imply much more
than
just a Gm chord at that point - the chord continues until the next chord
symbol, and can have a complex rhythmic structure. Producing this from
the simple text "Gm" is a matter of interpretation, and probably belongs
in a player program, rather than in the first-stage parser.
I'm not sure I completely understand what you are saying. I think that we
would put the chord in only once, and the player would know to continue the
chord until the next chord is specified. The rhythm is an interesting
problem. I don't think there is a way to indicate what the rhythm is in ABC.
The simplest form would be a header element that would say the equivolent of
"play all chords as boom-chick with alternating bass", and the more complex
form would be to specify an entire rhythm part that varies. That sounds way
beyond the scope of this, but its something to keep in mind so that it could
be added.
If we are going to write this out to disk, would it not be better to
adopt
an existing public format (e.g. NIFF or MusicXML), rather than create a
new
one? In any case, pointers are not a problem, as you can simply convert
them to file offsets.
I wasn't aware of MusicXML (I'm pretty new at this!). I think you are
absolutely right that we shouldn't make up a new disk format.
MusicXML requires its own parser though, so I don't think that is the right
format to pass between the parser and the formatter/player. Figuring out
what goes in the structure just became easier, though. I should support
exactly what MusicXML supports. I've just glanced at it so far, but I plan
to spend some time on it when I can.
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.
Some elements in the array will contain much more information than
others,
which makes for problems finding your way around. Would you pad the
smaller
elements to make them all the same size, use a separate index with
pointers
to the start of each element or what?
I think that the largest possible element could be pretty large and would
also be very rare, so variable sized fields are the only way to go.
In BarFly I use a doubly-linked list, each element consisting of a
fixed and
a variable part. The fixed part contains stuff which is common to all
elements (e.g. the back and forward pointers). Some elements contain
pointers
to subsidiary lists (e.g. beam elements and chord elements contain
pointers
to the start and end of a list of notes).
I was thinking of something along those lines, too.
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.
You will also have to deal with multiple slurs at the same point, so
you either
need to indicate both start and end positions at both ends, or attach a
unique
i.d. number to each slur.
OK.
Looks a bit daunting when you write it all out doesn't it?
I think the real trick is to build extensibility into it from the
beginning,
so that you can start with something simple and build up to more complex
capabilities in a predictable way. I would leave out consideration of
a file structure for some time, since that will tie you down badly if
you want to make changes later.
Yes, so I was planning on creating a comprehensive structure, then only
implement the parts that I need for my tradition at first. (Single voice,
with guitar chords and words, on a treble clef, with some orniments, and
first and second endings.)
I need to do more searching around to make sure I'm using all available
tools. There may be a publicly available structure like what I need already.
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
