> 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. > 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. > One problem I have that has been commented on by Jack Campin for > one is that our abc is not always as clear to read as it could be. > I agree with that but on the otherhand, on a site stuggling to get > any contributers, the last thing I want to do is stipulate rules > as to how the abc should be written (especially given our main aims > above - that it works on abcm2ps and abc2midi is the priority... > but it would be nice to improve in our abc for those who want to > read it) or even what software should be used (e.g. our main > contributer uses Harmony Assistant) as the tougher I make it, the > fewer will be willing to try. The answer to that one is a human editor. How much is there on your site? Maybe I could help if it isn't going to mean hours of connect time link-hopping. > A big problem with abc for me is the multiple ways abc has of doing > the same thing, e.g. broken notation vs explicit note lengths, the > ability to write 3/2 or 3/, etc. particularly when not everyone [and > that pretty much includes me because of music reading difficulties] > can use abc directly.) It needs to be like that to handle different kinds of music. Default note length is the one that makes the largest difference - for songs, you usually get the most readable source by making it 1/4, whereas for 2/4 pipe marches it's usually 1/16, and the default is in between. No way round that, there really are different numbers of notes per bar in each, and if you pick the wrong one you will reduce readability by introducing superfluous numerals or /'s. (Bruce Olson made a very bad decision of this type; his default length is twice what it should be, so nearly every note on his site has a /2 associated with it). > 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. ----------------------------------------------------------------------------- Jack Campin: 11 Third Street, Newtongrange, Midlothian EH22 4PU; 0131 6604760 <http://www.purr.demon.co.uk/jack> * food intolerance data & recipes, Mac logic fonts, Scots traditional music files, and my CD-ROM "Embro, Embro". ------> off-list mail to "j-c" rather than "abc" at this site, please <------ To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
