Re: [abcusers] Re: Tune finder, collections, header fields

[Jack Campin]

>> 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 itself, this doesn't completely meet the requirement: the same
tune may be used for many dances, and in a specific dance set it has
to occur at a specific point in the sequence.  So your DA: header
field would need to point to multiple instances of sequences of tunes
or (more concretely) multiple segments of files; this would need a
rather complex syntax, and you can't expect a danceband arranger to
think in terms of database schema design when typing up a few sets
for new players.

Surely it's better just to have a way of identifying dance sets in
their own right and saying what individual tunes comprise them and
in what order? - this is what the people who put a header like

   X:0
   T:

at the start of each set are doing.

Doesn't existing software already complain on encountering an unknown
header field more often than it does on encountering an instance of
the zero-index no-tune-body convention?


James Allwright wrote:
: Sorry, this won't work. You can only have 1 character before the
: colon, otherwise you are going to have lots of parsers complaining.

This has surely *got* to be fixed, or ABC is going to keep on banging
against that limit over and over again for years to come.  The header
namespace is too darn crowded.

Comaptibility with existing software isn't a very serious consideration.
Nearly every ABC tune you download off the web needs some sort of editing
before you can use it the way you want to.  How difficult can it be to
just remove a header field your program doesn't understand?  It only
takes a few seconds and it'll take far longer than that to make any real
use of the music.  There's quite a bit of useful ABC out there that no
currently supported program can use directly, and the proportion's going
to keep growing.  But you have to locate it before you can massage it,
so tweaks that help the Tune Finder do its thing have to receive higher
priority than compatibility with players and formatters.


===  ===


To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html

Re: [abcusers] Re: Tune finder, collections, header fields

[Simon Wascher]

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 yesno 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.

[abcusers] Re: Tune finder, collections, header fields

[Jack Campin]

[ putting the collection name in the title field
  of a zero-numbered tune at the start of a file ]

>> This might be worth doing for other instances where people have encoded
>> entire collections - if the first entry is of the form
>>X:0
>>T:Skye Collection [...]
>> if somebody enters "Skye Collection" as a search string [downloading
>> the entire file] is most likelyto  be what they want to happen.

> noplisnot! If there is a need of searching the tunefinder for the source
> or book a tune is taken from it would be reasonable to ask for the S:
> and the B: fields to be included in the tunefinder.

Sure, and it would be nice to be able to search on any of the header
fields too, but meanwhile this is a way of working with what we've got.
This way of doing it also makes it easier to update existing ABC files;
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.


> Please do not change the way of writing a abc header to bend it to the
> needs of an peripheral application.

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? - tunes without bodies are out there already
(not just on my site).

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.


> The abc format gives advice where to store such info. It will not make
> things better to establish some primitive dialectinstead.
> B:book yes yes   archiveB:O'Neills
> S:source   yes  S:collected in Brittany

> Maybe it would be a reasonable effort to give some detail information
> for these fields in the comentary section of the standard.

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).


> To me B: is the print from which I transcribed and/or a book in which
> this tune can be found in a similar version (I use "B:from:" to
> indicate the first and "B:also in:" for the second).
> S:is the source in the scientific meaning - the manuscript or even the
> person who carried the tradition.

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.

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.


> by the way I do not know about te 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.

===  ===


To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html