>> I'm probably going to have to provide an "abcfix" program that >> attempts to "standardize" non-compliant abc files. > I'd like to see how that handles BarFly output.
BarFly doesn't *have* output; it's a text editor, it doesn't enforce any ABC dialect any more than Emacs does. I've used it to write ABC that no version of the program itself could play or print. While I'd like to see a bit more interoperability, I'd be more interested in functionality - there are still lots of musical features that could be fitted into ABC without drastic upheaval but which no ABC implementation yet does right. There is no way ABC is going to take off in any genres beyond those it's got to already unless some extensions are made available; why should users with divergent specialist needs (rehearsal marks, editorial annotations, microtonality, lead sheets, text in two-byte character sets...) have to wait until *every* application implements them? One problem with using a common library: turnaround time for bugfixes. Some of the most-used ABC applications out there get updated no more than yearly, others get fixed within days of having a bug reported. If a bug is discovered in a library, this adds a new source of delay; the library maintainer will need to work fast to keep up with the quickest application developers. For some specialized library functions the open-source model might not help all that much as there might only be one developer in the group who understands what the code is supposed to do. On the other hand, a common specification (a real one, rather than the handwaving in the current documents or purely syntactic stuff like Henrik's BNF) would benefit everybody without introducing new problems like this. What formalisms would all the developers find readable? =================== <http://www.purr.demon.co.uk/jack/> =================== To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
