Richard Robinson wrote: >What programs are currently capable of reading abc2win output, as is ? >BarFly, I guess, since you're saying this.
Sort of. All it does at present is just ignore the exclamation marks. In many cases abc2win files are laid out in a reasonable fashion, with the bangs only at the end of text lines. These files produce reasonably good music. The files with bangs in the middle of lines, and newlines in totally erratic places (like the VMP collection) just have to be edited. >And, yes, it _is_ a point - >if it does have that capability I can see you'd be reluctant to cut your >users off from access to those files. But I also think it's a point that >can be made too much of. Maybe I'm getting bad-tempered about this; but, >I've never, not ever, been able to use abc2win files without having to >edit them by hand first. abc2win introduced constructs, out of the blue, >that the abc->ps family have never _been_ able to read. Some of them, >particularly the mid-line ! linebreak, I would actually like to have the >use of, as it turns out (and, I like abcm2ps's approach to mixed barline >thingies like :|: - what's written is what gets printed. Not always what >I want to see, but the basic idea seems right, clear, simple), if we >could reach agrrement such that they were generally available - but my >point here is that, to have a "standard" which makes it necessary to >fiddle about with abc2win files before being able to use them is not to >construct a new situation. It's where we've always been. Maybe it would >be necessary (maybe it would be an improvement) to tell a program >explicitly whether a user wanted to read abc2win or standard. That's what I'm doing for the next release. I thought this would be quite easy (just do it in the preprocessor), but it turns out there are a few gotchas. Plan A was to do this: Take out all the newlines (except the last one). Substitute a newline for each ! This runs into trouble where you have inline fields like this: G6 B6 | G6 B6 | E4 EG E4 G2 | M:3/4 F4 G2 | M:6/4 (B6 B6) |] Here the transcriber has tried to stay within the abc standard, putting each of his fields on a separate line, but because abc2win doesn't require it, he hasn't continued the lines with a backslash. So the Plan A preprocessor produces this: G6 B6 | G6 B6 | E4 EG E4 G2 |M:3/4 F4 G2 |M:6/4 (B6 B6) |] which is worse than the original. So plan B was to first locate each in-tune fields and substitute [ for the preceding newline and ] for the following newline before doing plan A. That gives this: G6 B6 | G6 B6 | E4 EG E4 G2 |[M:3/4] F4 G2 |[M:6/4] (B6 B6) |] which is fine until you meet a tune with consecutive fields: M:6/4 L:1/8 ... By the time the preprocessor gets to the L: field, the preceding newline has been replaced by ]. Plan C has a workaround for that, locating consecutive fields and substituting ][ for the newline between them. That seems to be working OK at the moment, and I'm ploughing through the VMP files. There are lots of other errors though. How about K: B_ or the ones which have bare inline fields with no delimiters at all? Phil Taylor To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
