On Thu, 16 Nov 2000, Phil Taylor wrote:
> It's a lovely idea, but it gets awfully complicated when you think
> about it. What would the output of such a parser be? Some programs want
> to make a picture of the staff notation, and would therefore want
> postscript, gif or something of that ilk. Others want to play the music,
> and need MIDI or something equivalent. The first kind of parser can
> take a single pass through the abc, while the second needs to loop
> to deal with repeats. In practice, they are so different that I
> wrote two entirely separate tune parsers for BarFly. The only common
> code is the part which parses the header.
It's really even more troublesome than that. Programs that will also write abc,
such as abc2abc or what have you, also need to retain a lot of source
formatting information that is nothing but unnecessarily complex dross to a
program that is producing a printed score or MIDI output.
Did the original abc use a decoration shortcut before this note? Or, did
it use !fermata! syntax? That's not important to a MIDI player or a scoring
utility, but critically important to a transposer or (my current pet project) an
automatic accompaniment generator.
> What is needed perhaps is an intermediate representation of the music
> which is easy to convert to either picture or sound. The first stage
> parser which converts abc to this intermediate format could be used
> by us all, while the remaining part of the job would be handled by
> the developer's own code. The trouble is, we'd spend forever arguing
> about the details of the intermediate format...
Nah, I can't imagine that happening ;-)
--
John Atchley
----------------------------------
<http://www.guitarnut.com>
<http://www.guitarnuts.com>
So many guitars, so little time...
To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
