>> There's another situation (already out there on the web) where getting >> a bunch of related tunes together matters but where they don't all come >> from the same book: when you want a set of tunes for a specific country >> dance. If you type "Hamilton House" into a search engine you might want >> the tune of that name, but you might also want an entire set for the >> corresponding dance. There is no unique source for such sets; different >> bands have different ones. There's no standard ABC field to put in the >> header saying which dance the tune is for, and even if there were it >> wouldn't help much, because some sequences of tunes work and others >> don't, you can't just put any tunes associated with the dance together >> in any order and expect to get a playable result. > You are right, there is no satisfying solution for it and this is a > shame. On the other hand it could simply and instantainously be done by > implementing a DA: = dance field into the header. Since there is no such > field, it cannot make any existing abc's outdated, and since it is not > active, I belive it could be used from now on.
In itself, this doesn't completely meet the requirement: the same tune may be used for many dances, and in a specific dance set it has to occur at a specific point in the sequence. So your DA: header field would need to point to multiple instances of sequences of tunes or (more concretely) multiple segments of files; this would need a rather complex syntax, and you can't expect a danceband arranger to think in terms of database schema design when typing up a few sets for new players. Surely it's better just to have a way of identifying dance sets in their own right and saying what individual tunes comprise them and in what order? - this is what the people who put a header like X:0 T:<dance set title> at the start of each set are doing. Doesn't existing software already complain on encountering an unknown header field more often than it does on encountering an instance of the zero-index no-tune-body convention? James Allwright wrote: : Sorry, this won't work. You can only have 1 character before the : colon, otherwise you are going to have lots of parsers complaining. This has surely *got* to be fixed, or ABC is going to keep on banging against that limit over and over again for years to come. The header namespace is too darn crowded. Comaptibility with existing software isn't a very serious consideration. Nearly every ABC tune you download off the web needs some sort of editing before you can use it the way you want to. How difficult can it be to just remove a header field your program doesn't understand? It only takes a few seconds and it'll take far longer than that to make any real use of the music. There's quite a bit of useful ABC out there that no currently supported program can use directly, and the proportion's going to keep growing. But you have to locate it before you can massage it, so tweaks that help the Tune Finder do its thing have to receive higher priority than compatibility with players and formatters. =================== <http://www.purr.demon.co.uk/jack/> =================== To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
