Steven Bennett wrote: >Phil Taylor wrote: > >> To return to the original suggestion in the title of this thread, it >> has been suggested many, many times before. One of the first postings >> I ever made to this list (or was it the developer's list?), made >> exactly the same suggestion - for goodness sake lets write the version >> of abc used in this file at the start so programs know what they have >> to deal with. It's a great idea, but it won't work because: >> >> (1) The fundamental unit of abc data is not the file, it's the tune. >> ... [snip] >> So the identifier would have to be added to individual tunes to be >> useful, rather than go in the file header. > >I fully agree with you. My suggestion is exactly that - this belongs in the >header of each tune, and in fact, might be best defined as the first line of >a new tune, making it a much more easily identifiable tune break. (IMHO, >there should be NO data in an ABC2 file which exists outside the context of >the current tune -- I don't know if anyone else agrees with this, but it >makes the most sense to me...)
I have to disagree. One very useful feature of abc is the possibility of embedding abc tunes in other text. This makes it a fine tool for writing about music. See Jack Campin's tutorial on modes in Scottish music for a good example of this. >> (2) A surprisingly large proportion of users type their abc directly >> in a text editor. There's no way you can make these people include >> the identifier. They mostly won't bother, and if their software enforces >> it they'll prefer to use a program which doesn't. > >Which is why I suggest it as part of a new ABC 2.0 standard. If *all* >programs which support ABC 2.0 need that line, then people will use it when >writing new tunes to that format. It's not like typing "%%ABC2" at the >start of your tune is a particularly onerous or time consuming task. I dunno. Some people can't even bother typing in the X: field at present. >> If you really want to write an abc parser, you will have to get your >> head round the idea that abc is not a computer language, it's a >> natural language (albeit a very simple and regular one, with very >> few dialects). It makes writing a parser a much more interesting >> task. If you want an easy (to the point of being boring) job, write >> a MusicXML parser. > >The issue with XML is you end up with something trivial to parse, but nearly >impossible to write without machine assistance. The main reason I like ABC >(and I suspect others do also) is it's relatively easy to type in music in >that format. Very true. It's also (surprisingly) much easier to debug an abc parser than an XML parser, just because it's so hard to find your way around those huge files (an error on line 3 is much easier to locate than one on line 2872). >Unfortunately, ABC as it exists now has indeed become a natural language, >and that limits it's usefulness immensely in the computer world. And I beg >to differ about "few" dialects -- as near as I can tell, there are at least >as many dialects as there are programs to handle ABC, and from comments here >on this list, I suspect there are even more than that. I meant few compared with English or French:-) >I have no problem developing a complex parser -- I've done that plenty of >times before, but developing one from scratch which has to deal with >multiple conflicting rules and absolutely no means of identifying which rule >applies, is absolutely no fun at all. Writing a parser isn't the goal - >it's a necessary step in creating a new program, and there's no reason it >should be as bloody difficult as it currently is. (Which reminds me -- is >there ANY other open source parser out there other than the several dozen >variants of the ones in ABC2PS and ABCM2PS? I'd like to look at one, >especially an object oriented one if one exists...) There's the parser used in abc2midi and yaps, but it's ansi C not C++. >Maybe I should be proposing that the new standard not be called "ABC 2.0" at >all, but something entirely different. It would still be the same goal -- >establishing a truly standard computer-readable dialect of ABC, but by >changing the name, it loses the baggage that name currently carries... Yes it used to drive me mad too. But abc as it stands at present isn't going to go away, and while a new, strict language is undeniably attractive to programmers it may well prove to be much less so to the public at large. Phil Taylor To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
