Hello,
Jack Campin wrote:
(...)
> there are some out there where the collection information is only given
> in non-ABC text at the beginning, and it's easier to simply add a dummy
> tune header there than go through the whole file putting S: and B: lines
> into each tune.
On the long term, for maintaining the correct source and not the least
copyright information it will be necessary anyway to store it with each
tune. About the tune finder itself:
* It files single tune files first, so this X:0 info is an endangered
species anyway.
* It is desiged to extract tunes from files so again X:0 info will get
lost.
The problem is not a solution that is o.k. for the next month, target in
all efforts of collections and catalogues should be the useability at
least for the next in five to fifteen years (in scientific terms much
longer).
(...)
> I'm not suggesting we change anything - this is a convention using the
> existing spec. The worst case is that we end up with a few incomplete
> tunes; what would that break?
The worst case is that people get used to this X:0 info and in five
years we can discuss solutions for clearing up files where some of this
info is lost completely,some in X:0 titles and W: fields other is in the
X:field, and some is in the B: and S: fields.
So to all programmers out there: find ways to include all (at least
source and copyright relevant) header information into your
notation/other output (by default)! So nobody can say he did not know or
did not see this info in the abc text.
> In the specific case of Atalanta Fugiens I haven't done *anything*
> nonstandard here - the extra T: line is something like
> T:Atalanta Fugiens (cantus firmus)
> a legitimate title which exactly describes the tune in the body that
> follows.
(...)
> It might also be a bit too late, as the ambiguity has already taken
> you and I in different directions in the way we use these (and other
> people have still different interpretations).
It is never to late to establish a standard if we are talking about abc
as something with a future.
(...)
> I often transcribe things from rare printed sources. So for me it's
> important to have a way of identifying the specific copy; often there
> may only be one copy in the world with a particular tune in it, because
> of an undocumented variant print run or hand-written annotation. So
> I've ended up with a convention where S: identifies the book generically
> (title, edition) and B: gives the details needed to identify the exact
> bit of paper I was looking at, e.g. a library catalogue number. I don't
> expect everybody to make this distinction, usually it doesn't matter.
So why this way? it would fit to the standard much better to store the
general generic info - title edition - in the B:field and the specific
info into the S:field.
And your example shows that we need some amendment to the standard.
> 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 the moment the only problem to discuss is to allow double letters for
fields. I know this is serious because its new but in principle I do not
see a problem.
So for the draft standard this would be:
Field name header tune elsewhere Used by Examples and notes
========== ====== ==== ========= ======= ==================
$ DA:dance yes no archive DA:Hamilton House,
DA:Maraichine
index
$DA - dance; sometimes it is helpfull to specify the dance which
$the music is meant for more than the "R:rhythm" field allows,
$like with musik compiled for a certain country dance.
> > by the way I do not know about the exact use of the "F:" field, can
> > someone show me. Maybe this would be a better place to store the
> > information in question.
> Nobody seems to be using it; whatever usage gets agreed on, it'll
> be years before there are enough files containing it for it to be
> worthwhile for the Tune Finder to search on it.
We are talking about info that cannot be stored propperly in the moment
anyway. To start something new always takes its time.
I am not an expert but to my expirience it cannot be a big problem to
store the content of empty fields in the tune finder. So Lets ask John
Chambers about this ?
regards
Simon Wascher - Vienna, Austria
To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
