Laura wrote:
> Phil> An M: field in the header (i.e. before the K:) is mandatory,
> Phil> I think.
>
>I don't see that in my copy of the standard. abc2ps defaults to 4/4,
>I think, if there isn't an M: field at all. Is that wrong?
You are right, it's not in the standard. BarFly will accept an M:
field after the K:, so it's not a problem, but it needs an M: somewhere
before the tune starts or it will give an error message. M: none is
OK.
> Phil> However, it's actually not that but the N: in the tune which
> Phil> foxes BarFly.
>
>Yes, that's a change I'd like to see in the standard. Either N: or
>some other text field should be allowed in the body, so that notes
>that actually apply to a particular note or lyric can be entered _in
>situ_. abc2ps does the right thing already. abc2midi complains, but
>wouldn't do anything about the N: field wherever it was.
Yes, I can see no reason for not permitting notes within the tune. I'll
add it to the next version, at least to pass it without comment.
> >>
> >> I agree about the multiple ways of displaying a17, but what about a16?
> >> If I want to transport ABC from a program that knows what a longa
> >> looks like to one that doesn't, how should I do that?
> >>
>
> Phil> Perhaps the breve and longa should go in the standard.
>Certainly the
> Phil> breve should, as it's sometimes used even in modern music. In the
> Phil> meantime we're stuck with a8-a8, or even a4-a4-a4-a4.
>
>So you think a program that does handle longas should be able to parse
>a4-a4-a4-a4 as a16?
>
No, I think programs should display exactly what the user entered, as far
as possible. a16 should give a longa and a4-a4-a4-a4 should give four
tied semibrieves. If that was originally entered as a work-around for
the absence of the longa then the text should be edited accordingly once
the software has caught up.
Phil Taylor
To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
