Christian writes: | I've already recanted my heresay, but, I'm in a recanting mood so I'll | say, 'yeah. I hadn't considered the -inline- issue'.
But maybe you don't want to take it that seriously. You could use ABC as the basic of a more powerful notation that requires a GUI interface. If you don't mind abandoning the advantages of ABC's rather loose plain-text form, you could making your notation more precise and controlled. This isn't practical with ABC, because so much ABC is typed by hand. This has been a major reason for ABC's success, but it's also the source of a lot of problems and headaches for programmers. | I do wonder however how many people read the standard and tutorial, even | with it's multiple restatements of header and body order, and get to the | end thinking that they are 'just suggestions' for formatting, and as long | as they've got the info 'in there' that the order does not matter so much. I think you're onto something here. ABC is used by musicians who are mostly not programmers. We can't expect them to understand the picky details that programmers accept. The looseness of many ABC programs has contributed to ABC's success. But there is a lot of really bad ABC out there, and some of it is beyond what even a lenient program can manage. What's interesting is how successful ABC has been despite this. To a great extent, it's because users can get away with learning only 4 or 5 headers plus notes, bar lines and accidentals. This suffices to transcribe tunes, and takes maybe 10 minutes to learn. Add chords and endings, and you can match any tune in any fake book. Add W: and w: lines, and you can do songbooks, after maybe another 10 minutes of learning. Most users never need anything more than this. And this basic ABC notation is hard to get wrong. | It certainly seems imperative now after hearing all the discussion on the | list, and learning that so many of the developers hinge the success of | their parsing on the existance of a T: or X: at the start of a tune. | | Am I off in this perception? Sounds pretty good. Note my earlier suggestion that you also accept P: as the (potential) start of a tune. In fact, if you want to have a really simple way of separating ABC from text, you could just look for a line with a letter in column 1 and a colon in column 2. Your code could then accumulate everything until the next blank line as a (potential) tune, and attempt to parse it. This is simple, though you'd also want to have a way to reject things that turn out to make no sense as music. Or maybe not; you could get some interesting "modern music" at times. One thing that I've found with the work on my Tune Finder: ABC's headers have a distinct similarity to online bibliographic data. This isn't surprising, since they are doing similar jobs. Most allow "Title:" to be abbreviated to "T:", for example. Several biblio packages use "X:<digits>" as a sequencing mechanism. And so on. The early versions of the Tune Finder found a number of "tunes" that turned out to be the bibliographies at the end of online articles. I added some (rather subtle) code to weed out the ones that don't work as tunes, and I think there are only a handful of such "false positives" left in the 100000+ tunes in my index. I've suggested in the past that people looking to extend ABC should also look at a number of the online biblio and card catalog sites, with the idea of making ABC's headers evolve in the same direction. Then we could use the catalog software with ABC collections. But this might not happen, because musicians and librarians aren't in very good contact. To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
