> 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 calling
> program. You're going to have the parsed data in a structure *somewhere*
> for the parser itself to access -- may as well pass back that structure as
> part of the overall output, and save the calling application extra work.
That's a good point, and that brings up something that I was wondering
about. Do you think that the parser should figure out the correct pitch or
leave that to the app? I think that is what you are suggesting, and it would
be my preference, too.
In other words, I'm envisoning that the "pitch" field will be an integer
that is the that should be sounded. If we have:
K:C
F
K:G
F
Then the parser would store different notes, an F-natural in the first case
and an F-sharp in the second. That, of course, requires the parser to
understand the "K:" field, which could be complicated.
However, as you point out, somebody has to understand it anyway, so there
needs to be a requirement that the K: field be understandable, so any
extensions should be well formed and ignorable.
Some other fields, like rhythm, might not be as critical, but if you do it
one way for K:, you might as well do it the same way for the other fields.
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
