Phil Taylor wrote: >> (IMHO, >> there should be NO data in an ABC2 file which exists outside the context of >> the current tune -- I don't know if anyone else agrees with this, but it >> makes the most sense to me...) > > I have to disagree. One very useful feature of abc is the possibility > of embedding abc tunes in other text. This makes it a fine tool for > writing about music. See Jack Campin's tutorial on modes in Scottish > music for a good example of this.
Oops. I see I really phrased that one wrong. I've put ABC tunes embedded inside emails myself. What I meant to say is that there should be no ABC2 data outside the context of an individual tune inside a file. Each ABC2 tune should be capable of being parsed outside the context of the file it's in. Unfortunately, doing so means more or less doing away with the file header support, or at least disallowing any field that's affects how the tune is processed. (ie. M:, m:, R:, T:, U:) But I expect there would be quite a bit of resistance to that idea, which is why it's just an opinion, and not something I was suggesting we actually do. I *do* think the %%ABC2 tag on each compliant tune, or something similar, is needed. And given we have the file header anyway, I could accept a compromise that the %%ABC2 tag could be placed in the header and thus apply to all tunes in the file. The header has to be copied out anyway whenever you break a tune out of a file, so that's not a big deal. >> (Which reminds me -- is >> there ANY other open source parser out there other than the several dozen >> variants of the ones in ABC2PS and ABCM2PS? I'd like to look at one, >> especially an object oriented one if one exists...) > > There's the parser used in abc2midi and yaps, but it's ansi C not C++. Thanks, I'll look at them. C++ isn't necessary - I used to be a big C++ advocate but now I *much* prefer Objective-C. -->Steve Bennett To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
