On 27 Mar 2004, at 18:53, Richard Robinson wrote:

The question that gets raised at this point, which I don't know the
answer to, is - how easy is it to translate abc to xml ? How well does
xml accomodate the concepts of ABC, how much of the possible information
in an ABC file does MusicXML have encodings for ? So far as there are
things in an ABC file that MusicXML can't represent, we'd have to invent
some way of wrapping them up in comments, or something - find a way of
shoehorning it into ABC - in a way that xml->abc translators could
recognise, preferrably a way generally agreed upon (rather than carry
the issue of dialects across to our generated XML).

MusicXML is a very comprehensive music description language. For example,
it is possible to include in a MusicXML file both the information to construct
the staff notation, and that needed to construct a midi file. These are
fairly independent of one another, so you can specify e.g. a mordent to be
printed, but the notes which correspond to be played.


The only feature I can think of which is present in abc but not MusicXML is
the bagpipe key signatures. So abc -> MusicXML is relatively easy. The
reverse translation is much more difficult. (e.g. MusicXML permits multiple
voices within the same part, so in a piano part, which may include four or more
voices, each bar has several <backup> tags to allow the different voices to
coexist. The voices can move independently across staves, change clefs and
so on, and there's no way to do that in abc.)



(A further question here; are there descriptions of MusicXML anywhere ? I
have Recordare's Tutorial (V1.0), and I know the DTDs give all the sordid
details, but they're a bit bulky for a beginner to find their way around).

I think that's all there is. There is also a MusicXML mailing list, which is
quite active, and is usually the best place to go to ask questions.


And, yes, I guess that points of formatting would the trickiest to preserve,
recording whitespace between ABC elements, comments and so on. Not
impossible, but I can imagine a temptation to cut corners in the coding.

Yes, whitespace which doesn't convey any information (as opposed to that which
determines beaming) would be very hard to preserve. Since MusicXML is not
intended to be read by humans, comments in the source would be useless, so
abc comments would have to be preserved differently.


Phil Taylor

To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html

Reply via email to