| Although what I said was valid, I want to retract my proposal to make ABC
| be XML compatible.
Rats! You beat me to it.
| One look at MusicXML (see http://www.recordare.com/stanford.html )
| convinced me that using XML would sacrifice too much of the clarity and
| usability of ABC.
However, there's a good chance that MusicXML will have a future.
True, it's not as concise and clear as ABC, but it's already more
powerful. And it's not really any worse that the proprietary binary
formats used by most of the commercial packages. If a few good
java-coded packages come out that use MusicXML, it could become a
significant challenge to the proprietary packages' formats.
Meanwhile, ABC will likely continue to chug along, since it has all
the advantages of a compact, typable and readable notation. Missing a
few of the fancier features will be a problem for some users, and
they will go to more complex packages. But ABC and MusicXML may not
be true competitors. It's more likely that they will end up sharing
the territory. Neither HTML nor XML has made serious inroads in the
use of plain text, and neither will MusicXML.
| for instance, this is one note in MusicXML.........
|
| <note>
| <pitch>
| <step>B</step>
| <alter>-1</alter>
| <octave>4</octave>
| </pitch>
| <duration>1</duration>
| <type>eighth</type>
| <stem>up</stem>
| <beam number="1">end</beam>
| </note>
Yeah; it's pretty wordy, isn't it? But it's probably still smaller
(and a lot more readable) than PS or PDF, as well as free of possible
licensing problems.
I've been seriously wondering when I should add an XML button to my
Tune Finder's output formats. Is there a population of MusicXML users
out there yet? If so, as you say, a perl script could probably do the
conversion fairly easily, and we could enrich them with our body of
tunes. But there is a chicken-and-egg problem here: I probably won't
be very motivated to do it until I know that there will be some users
who want it.
To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
