On Sat, Mar 27, 2004 at 05:17:14PM +0000, Jack Campin wrote: > > > as far as our site is concerned, abc's importance lies more in > > a simple storage method and having nice programs to produce > > graphics and MIDI than in human readability of abc. (perhaps > > John Chambers for example to confirm or deny this... Do most > > casual visitors to a site want a MIDI to play back or a GIF > > or to download the abc itself for a tune?).. > > Most people want GIFs. But if they're going to do it on their own > machines, rather than via the TuneFinder interface, the ABC better > be straightforward and easily editable, since the usual reason for > wanting a different score than the way it comes off the Web is if > you want to change the notes themselves in some way.
Or, maybe, to print ? web-gifs aren't normally (sensibly) at a decent resolution for that. Though I know I've seen a lot of 72dpi screen-dumps ... > > If there were abc2MusicXML and MusicXML2abc converters, would it > > possible to produce abc that always conformed to the same set of > > abc "rules"? > > It would be, but it would throw away many of the distinctive things > ABC can express. For eample, look at the pibroch example in my modes > tutorial. I put the canntaireachd form of the music at the right > margin as an ABC comment (it would be messy to include it as if it > were a song text). Unless your ABC -> XML translator retained the > original ABC source, there'd be no way to recover that information > after a round-trip translation. What I've done there is perfectly > standard and works in any reasonable ABC implementation, but it's > not invariant under translation to anything else whatever. > > Also, if other programs can export XML directly, I guess that will > > help to if we can produce abc from that? > > Only given a *very* sophisticated translator. Why use ABC as an > intermediate format if you aren't using its distinctive advantages? > As a base for computer-translation-to-anything, XML is surely going > to outdo ABC as its toolbase grows. ABC only wins out when you need > to tinker with the music yourself, and that needs readability. That's the way I see it, yes. If it catches on. ABC for people to interact with, xml where machines are dealing with it (possibly up to and including transferring it from one system to anoter), and storage could be either depending on which of those 2 you're most interested in. Depending on, as you say, sophisticated translation. There are several different dialects of ABC - defined, on the ground, by the parsers that people use, which ABC program they're feeding it into (plus comments, layout, etc, intended for the direct benefit of humans, so far as it can be shoehorned in). Neatest here would be if the abc parsers came to feel it was worth their while to translate the ABC that they can parse into xml - rather than trying to build a one-program-fits-all universal abc->xml translator that understands everything about all dialects. The reverse translation, "back" into ABC - some programs are already importing xml, presumably they generate ABC tailored to suit whichever parser, style of ABC, that program uses. In the long run, we might have .xls stylesheets independent of any particular ABC parser (decent ones, I mean) - these might become a central point for bug reports, wherever they generate ABC of a style that doesn't work as input to a particular parser, in which case they could (presumably) be tweaked till they generate your particular choice of dialect. In, as I say, the long run; that's not the case yet. 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). (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). 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. Easy to test, of course. Take an ABC file, translate to MusicXML, translate back to ABC, and keep on sending in bug reports until the 2 abc files match up ;-) And vice versa ... I imagine the reverse case would be harder, preserving all xml information that ABC doesn't represent inside an ABC file for xml->abc->xml. -- Richard Robinson "The whole plan hinged upon the natural curiosity of potatoes" - S. Lem To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
