> You need to make a decision early (i.e. right now) as to the scope of > your project - do you want to be able to do useful things with the > bulk of existing abc on the net, which may be full of comments > and ropey abc, or do you want to pick a well constrained subset > of abc (for example, one tune per file, strict 1.6 standard) and > use that to build your program. I started by defining my requirements > as being able to display Henrik Norbeck's collection, and added to > it as I went.
I think Henrik goes a bit beyond the 1.6 standard in places? Given the vagueness of that standard, what Wil is suggesting seems a better idea. A large set of test cases amounts to a more precise specification than the standard, and Henrik is careful enough in the way he writes ABC that you wouldn't end up trying to accept gross mistakes. You might also find my Dalkeith material: <http://www.purr.demon.co.uk/dalkeith/Dalkeith.htm> useful as a test case, because I've got all the tunes in other formats as well, and I did the conversions myself, checking that they sounded and looked the way I intended. But I go far beyond the 1.6 standard. One restriction I impose there that I would never ordinarily have if I had any choice in the matter is to structure things one-tune-per-file without any prefatory text - that's simply to make it easier for a web browser to fire up an ABC application at the right place. I'd rather have had all the tunes from each section in the same file, with the browser triggering the ABC program to do its thing on tunes identified by something that worked like HTML anchors - e.g. the browser passing the "X:" line as a parameter to the ABC app, perhaps with another flag to say what to do ("print", "display in new window", "MIDIfy"). But there's no way to do anything like that with current software. =================== <http://www.purr.demon.co.uk/jack/> =================== To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
