> How does different platforms handle tarballs anyways? (You did did find > the slightly hidden (at the bottom of the "songs" page) tarball with all > tunes in abc, right?)
I used two programs in succession: Stuffit Expander and then Tar (a Mac port of the Unix utility). The problem was that Tar doesn't have a way to rename files on the fly to fit them within MacOS naming restrictions, and just omitted those that it couldn't make names for, so in the end I just left the tunes all in one file; more convenient on my platform anyway. (This led to an interesting gotcha: tar file format uses lots of null characters, and not all Macintosh text editors make them visible - BarFly doesn't. I thought I'd cleaned up the file after removing visible tar instructions, but BarFly kept crashing in weird ways. It turned out there were still 26,000 null characters in the file; everything worked fine once I removed them). The F: field ought to be usable here; think up a filename for each tune (since you're doing it you can guarantee uniqueness), preferably within 8+3 conventions, put it in an F: field in the header for each tune, and have your archiver use that instead of the real filename you use locally. I think that for all non-Unix systems having all the tunes in one file is going to be easier than one-tune-per-file anyway, so perhaps there's no need to do more than concatenate. > My idea behind using the same two voice approach to all tunes is that > > 1) Although a certain tune can be set within the standard, I often find > mysel adding alternate chords later where I suddenly need My Hack. So > might as well to it from the beginning > > 2) All tunes follow the same conventions which for instance means that: > > 3) It is more easy to extract the correct voices (using abcselect), for > the different types of output. Good reasons, I wasn't suggesting you abandon this practice. But does abcselect give you a way of creating a one-voice file from what you've got, in cases where you wouldn't lose anything? - if so it would help people with less flexible software to provide such an alternative. >> (2) there are some non-ASCII characters used in the chords - F8 and B0. >> What do these represent? > o-slash (for m7b5) and superscripted-o (for dim). But they do show up > in the pdf/ps outputs, right? I don't have an abc-to-PS generator; the current Mac port of abc2ps needs more memory than there is on any machine I have regular access to - didn't think to download your PDFs to check. >> !fine! exclamation-point abuse > Then I guess I should avoid repeats alltogether, since I use the !fine! > to indicate where the form actually ends... There are two ways to do it: use "P:" in the header so player software gets the order right, and use the more-standard textual annotation method of "^Fine" to get the screen/print display correct in a portable way. I often use both at once (and have to since BarFly doesn't print the playing order). ABC's "P:" construct doesn't quite work with your tunes, since you have A parts that are nearly but not exactly repeated. Makes perfect musical sense to label them both the same but an ABC player isn't going to see it that way. It would be ideal if you could use part labels like "A - reprise" and expect the player software to understand it. I don't think any player can yet handle multi-character part labels in header "P:" fields. > I thought about putting tempi in the tunes, but I hate to see it in the > ps-output. Don't know if it's possible to make abcm2ps not output the > tempo (?) otherwise I should just strip the Q: line before sending to > abcmp2s. This is one of BarFly's most annoying features too; a bit sneakier because it won't print the tempo in the header but insists on printing changes of tempo (the worst of both worlds) directly in ABC syntax. Having the "Q:" field commented out so only humans could read it would be a reasonable compromise. =================== <http://www.purr.demon.co.uk/jack/> =================== To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
