Stephen Kellett wrote:
>In message <[EMAIL PROTECTED]>, Phil Taylor
><[EMAIL PROTECTED]> writes
>>>In message <[EMAIL PROTECTED]>, Phil Taylor
>>><[EMAIL PROTECTED]> writes
>>>>>a) Symbols can be on notes, rests and bar lines
>>>>
>>>>Bad Idea. This breaks all existing programs which support aligned words,
>>>>and any existing files which include aligned words and rests.
>>
>>>Forgive my ignorance, why is this a bad idea? Have I misunderstood the
>>>spec? I'm writing my parser/player/display program. I've already
>>>implemented the above and it was not hard to achieve (I can make the
>>>symbols attach to anything in the markup, pretty much).
>>
>>
>>Then anyone who uses your program to make abcs with aligned words will
>>find that their files don't work properly with any other software.
>>Likewise they will find that in any files they download from the net
>>the lyrics won't align properly.
>
>As far as I can see this doesn't answer the second question (am I
>mistaken, or are you just disagreeing with ABC2.0 and not my
>interpretation of it), and only states that the proposed ABC2.0 spec is
>more advanced than the programs to which you refer (but do not name) in
>their current state.
The second question was "Have I misunderstood the spec?". I don't think
so. In fact the spec (see below) is ambiguous, so you can be forgiven
for taking a different interpretation to everybody else, provided that
you realise the consequences.
>This is no more different than putting an ABC file
>with V: voicing into ABCWin - it doesn't like it. I don't think anyone
>is claiming ABCWin is broken because the standard has advanced past its
>capabilities.
It's very different. The introduction of the V: field represented a new
extension to abc. It did not invalidate abc2win's existing data files,
and its use could be avoided by newer programs if the user wanted to
achieve backwards compatibility with abc2win. And it was a very important
extension in that it made available whole swathes of music which could
previously not have been represented in abc. What you are proposing is
not a new extension, but a change in the interpretation of an existing
one. This means that programs which work in the way you suggest will
interpret existing files differently, and not in the way that their
authors intended. And all of this just to enable the alignment of
lyrics with rests and bar lines? That's a whole can of worms being
opened to achieve an infinitesimal extra feature.
>My program will be backwards compatible. If you've aligned your words on
>notes that is fine. Using my app you can align on notes/rests/barlines
>as the spec dictates.
How will it be backward-compatible? These are two different and totally
incompatible sets of behaviour. You could give your users the option
of interpreting aligned lyrics one way or the other, but it would be
quite difficult to make this choice automatic.
>I made a mistake in my previous posting. The ABC2.0 draft spec actually
>includes "note groups" and doesn't specifically disallow grace notes.
>Given that the spec does not define "note group" (or if it does I
>haven't found it), I am not sure if a note group is
>a) ABC
>which is notes next to each other
>b) [ABC]
>which is chords
>c) {abc}
>which is grace notes - these are clearly "grouped" in one sense.
>d) either of (a) (b) (c)
\
I don't know what abc2.0 draft you are reading but it doesn't say
anything about "note groups" under section 5, Lyrics:
-----------------------------
5. Lyrics
The W field (uppercase W) can be used for lyrics to be printed separately
below the tune.
The w field (lowercase w) in the body, supplies a line of lyrics to be
aligned syllable by syllable below the previous line of notes. Syllables
are not aligned on grace notes and tied notes are treated as two separate
notes; slurred or beamed notes are also treated as separate notes in this
context. Note that lyrics are always aligned to the beginning of the
preceding music line.
It is possible for a music line to be followed by several w fields. This
can be used together with the part notation to create verses. The first w
field is used the first time that part is played, then the second and so
on.
The lyrics lines are treated as an ABC string. Within the lyrics, the words
should be separated by one or more spaces and to correctly align them the
following symbols may be used:
-
(hyphen) break between syllables within a word
_
(underscore) last syllable is to be held for an extra note
*
one note is skipped (i.e. * is equivalent to a blank syllable)
~
appears as a space; aligns multiple words under one note
\-
appears as hyphen; aligns multiple syllables under one note
|
advances to the next bar
Note that if '-' is preceded by a space or another hyphen, it is regarded
as a separate syllable.
When an underscore is used next to a hyphen, the hyphen must always come first.
If there are not as many syllables as notes in a measure, typing a '|'
automatically advances to the next bar; if there are enough syllables the
'|' is just ignored.
Some examples:
w: syll-a-ble is aligned with three notes
w: syll-a--ble is aligned with four notes
w: syll-a -ble (equivalent to the previous line)
w: time__ is aligned with three notes
w: of~the~day is treated as one syllable (i.e. aligned with one note)
but appears as three separate words
gf|e2dc B2A2|B2G2 E2D2|.G2.G2 GABc|d4 B2
w: Sa-ys my au-l' wan to your aul' wan\
Will~ye come to the Wa-x-ies dar-gle?
Please see section Continuation of input lines for the meaning of the
backslash (||) character.
If a word starts with a digit, this is interpreted as numbering of a stanza
and is pushed forward a bit. In other words, use something like
w: 1.~Three blind mice
to put a number before "Three".
---------------------------------------------------
>>>I couldn't see (from reading 1.7.6 and 2.0) what the difference was,
>>>except that 2.0 provided me with more information to work with (i.e. 2.0
>>>stated it was notes/rests/bar lines, where as I don't 1.7.6 stating that
>>>(implying it was everything).
>>
>>As far as I can see all of the existing standards mention only lyrics
>>aligning with notes, and while they specifically state that gracenotes are
>>not included, make no mention of rests or bar lines. Existing software
>>(e.g. BarFly and abcm2ps) interpret this to mean that rests and bar
>>lines are to be skipped.
>>Admittedly the standards are a little ambiguous
>>here, but there is a well-established precedent, and lots of files which
>>will be broken if you make a different interpretation.
>
>I don't see how extending a definition breaks things. The old files will
>still play/display correctly, and the existing software such as the two
>you mention (especially BarFly, a commercial app) will be extended to
>handle the new standard. In any other walk of life we accept that new
>standards require backwards compatibility, and expect the software
>vendors to provide this.
No the old files _won't_ still display correctly.
Here's the first line of a song:
X:1
T:The Generous Lover
M:none
K:Cmix
G EC2 D E F D | G2 CE E DB,3 |
w:Oh the first time I saw my love, hap-py was I_
the lyric aligns like this:
G E C2 D E F D | G2 C E E DB,3 |
w:Oh the first time I saw my love, hap-py was I_
You are suggesting that by default lyrics should align with bar lines
and rests, so your program should display it like this:
G E C2 D E F D | G2 C E E DB,3 |
w:Oh the first time I saw my love, hap-py was I_
I doubt if you really want the word "love" on a bar line, but that's
what is going to happen.
Phil Taylor
To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
