David Webber writes:
| From: "John Chambers" <[EMAIL PROTECTED]>
| >... You have to buffer the entire tune in
| > memory, and examine the text after the tune to see if
| there's a
| > "%..." line that contains "abc2win".
|
| That in itself is no problem. ABC is so concise that buffering a
| tune in memory is completely trivial these days. In fact when I
| started writing my import filter, that was the first thing I did -
| read the whole file into a string with '\n' for newlines and stick a
| '\0' on the end. Then one can start parsing it sensibly.
Right. In perl, this is technically known as "slurping up" a file,
and is such a useful technique that the language has a conventional
idiom for doing it:
@data = <FILE>;
Perl programmers will appreciate the subtlety of this command. The
'@' signals that "data" is to hold an array, and forces the input <>
operator to be in "array context". So it delivers the entire file
chopped into lines according to whatever you have said the line
separator is. You could follow this with
if (@data =~ /abc2win/i) ...
to check whether there is any mention of abc2win (with any
capitalization) within the file. Books on perl will include warnings
about the impact that such simple-looking commands may have if there
are other processes competing for memory. But now that laptops with a
gigabyte of memory are common, this can be a lot simpler than
grovelling through the data with lots of loops and complex data
structures.
| The dual use of ! is still, as far as I can see, the worst conflict
| which has come up in existing files, and something therefore which
| urgently needs sorting out in a standard.
Actually, I'd say that if this is the worst we've done, we've done a
pretty good job of it. And, in my experience, it probably is the
worst incompatibility in abc tools. So we can congratulate ourselves
on being such a cooperative bunch. Who'd have ever thought anyone
could say that about a gang of musicians?
| *Anything* which helps divine its purpose in existing files is
| useful at this stage.
Yup. And note that, as someone else pointed out, sometimes the only
clue that the music came out of abc2ps is the very last line of the
file.
Note also that if you downloaded the tune from my Tune Finder, and
didn't use the "GET" link that returns the whole file, then you
didn't get the abc2win comment. All the other links return just a
single tune (except for the X:0 case). I'm not sure that this is a
problem that's worth spending time on. The heuristic that I described
earlier (scan for a second ! and see if the intervening text looks
like abc music or an annotation) seems to do a sufficiently good job
that it's likely not worthwhile spotting the few possible remaining
pathological cases.
Maybe we should ask Jim Vint if he could move that comment into the
tune's headers. That would be useful. For that matter, it could be
useful if all abc-generating programs identified themselves this way.
"% name version" at least. I'd bet this could come in very handy for
a lot of reasons.
Of course, now that I've made that suggestion, I should add this to
my tune-finder's tune-extraction script. It already inserts the URL
and date just before the K: line. Maybe it should also identify
itself as the culprit that chopped the tune out of the file and added
an HTTP header to the beginning.
To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
