Tied notes revisited

[ahankinson]

Following on from this comment: #110 (comment)

Currently, both ends of the tied note must be specified: C_C would be two C notes tied together. The problem that we run into with this is that, without validation, it's possible to change the second note: C_E, which is no longer a tie, and it makes calculating sounding note durations difficult, among other things.

We could consider using the _ as the stand-in for the tied note, instead of just the tie. So instead of C_C, a pair of tied Cs would simply be C_. This makes it impossible to change the note at the end of the tie.

C_C would then result in:

Since the underscore would stand for both the tie and the note.

This could also be applied for tied chords. (Using the current proposal from #110):

^CEG>_ would be two C Major tied chords.

It should also be noted that bar lines could intervene to have tied notes across bars. So:

C/_/_

Would result in this:

^CEG>/_/_

is also possible.

[lpugin]

What about duration change? The need to be allowed. It is an interesting idea, but I fear it is going to create more confusion. A few examples:

2C/_4 needs to be allowed for

However, this will be confusing (not ambiguous, but confusing) if you have 2C/_4C

Maybe you could say that the note is implied only if the duration is the same. But then you would not know if 2C/_4C is:
or

[ahankinson]

Good points. Allow duration on the tie at the beginning, but not pitch or octave?

2C/_

2C/4_

2C/4_C

[lpugin]

This seems ambiguous 2C/4_:
or ?

[ahankinson]

A note name is required to have a note, so it can't be the last one. That would be 2C/4C_

[ahankinson]

Clarification from conversations: The underscore _ will act as a "stand-in" for the previously-stated note name. This will allow for alteration and groupings to intervene.

This also makes it not possible to have an open tie at the end of an incipit. (~700 incipits currently have this, so they would need to be fixed. The ties are not rendered by Verovio anyway).

Some examples:

Showing an accidental on the tied notes:

bB/b_

A note tied to the beginning of a tuplet:

bB({6_AG})

q8G4_

[BaMikusi]

@ahankinson This is a truly brilliant idea, but I must admit it has proven a bit difficult to wrap my head around it, which makes me strongly believe that catalogers would hate it -- simply because it appears to require an extra step of contemplation about what is on the page before them, instead of just allowing one to copy it. I mean, I see a tie in the source, so I can simpy hit _, then I move on to describe the next note as a new entity, again as I see it on the page -- that's of course boring, but if one needs to encode a dozen incipits in sequence, better be bored than have to think about it. So, while the old way admittedly results in a less elegant code, it should still be easier to write for the cataloger, which seems a central concern to me.

[ahankinson]

I think the expectation (on my part) is that this won't be done in a vacuum, and there will be a renderer available to turn it into notation as the cataloger types. If they see the note being drawn when they type the _, then I think they will know to move on to the next note.

My guiding principle here is "make impossible states impossible" -- that is, if it's "impossible" to have a tied note that has a different pitch, then the method of encoding that tie should make it impossible to do that. There may be alternative ways to do that while making it a better experience for the cataloguer? In my mind, specifying the note at both ends provides a way for the cataloger to do the impossible, either on purpose or by mistake, so I guess I was privileging data integrity here by removing that option from them.

(And yes, we could do validation on the notes to see if they're the same pitch, but a) there's no guarantee that the cataloguers would see or acknowledge that, and b) it means building and maintaining those rules, when we could simply not make them necessary in the first place)