Remove "incoming" and "outgoing" from <slur> and <tie>

[adrianholovaty]

This proposal comes from @notator in #203. I'm splitting it into a separate issue to better organize things.

The <slur> and <tie> incoming, and outgoing attributes could be deleted. I can see no use for these, and suspect that they are a left over from MusicXML's "score-timewise" format. In MNX, slurs and ties are always defined in a "part-wise" context, so its always clear where they are going. Ties that end without a target note are used for laissez vibré indications (that are always horizontal), but these can easily be defined using a proper measure location in the <tied> location attribute. (Note that it is then possible to define whether or not a laissez vibré tie is repeated if it crosses a system boundary: it will do so if it crosses a barline, otherwise not.)

[joeberkovitz]

incoming and outgoing are not relics from MusicXML but are frequently encountered in the literature. I'll deal with these separately below.

1. incoming occurs frequently at the start of repeat endings and codas since these begin directly after a form jump. Example (see incoming tie on the F at the start of ending number 2):
   

It would also be possible to deal with this issue by specifying multiple or alternate targets for a tie, but that places encoders in the role of knowing exactly how to apply arbitrary form jumps to ties, which is hard to do for music in general. Do not assume that all form jumps can be encoded in machine-readable terms, as many jazz pieces only notate their form in textual terms.

2. While outgoing is usually a laissez vibrer, one does see dangling ties used for this purpose and with no particular end location to indicate where the tone stops ringing. In a busy passage, it does not make sense to extend all the ties to the same endpoint as this generates a lot of visual clutter.

[joeberkovitz]

Here is also a toy example demonstrating an outgoing tie across a form jump, kind of the mirror image of the first example:

[clnoel]

I think I agree with not needing incoming and outgoing here. The two examples here have location="0" and location="1" or maybe should use the barline location syntax we're proposing in #251.

[joeberkovitz]

It's true that if all you want is to render a tie that looks like the above examples, location should suffice, especially for an l.v. type of tie which does not connect to another event.

This might well be enough. Just one question to consider: is it useful to distinguish a tie that merely means "let this note ring" (where location really tells the whole story) from a tie to a real note on the other side of a form jump, like the 2nd example above (where something signifying outgoing might make sense).

I'm inclined to agree, no, we don't need this distinction. It does put more responsibility on software that renders an audio performance to make sense of such ties, in the same way that a performer would.

[joeberkovitz]

One quick follow up: if the initial proposal from #262 is adopted, then incoming becomes location=“start” and outgoing becomes location=“end” which seems quite simple and satisfying.

[notator]

I'm in very much in favour of @joeberkovitz' initial proposal in #262, and would really like to make incoming and outgoing redundant. I think they are inadequate as they stand anyway (see below).

Here's how I understand @joeberkovitz' current thoughts:

1. A location value of "start" ties a note (at the beginning of a measure) to the barline at the beginning of that measure.
2. A location value of "end" ties a note (at the end of a measure) to the barline at the end of that measure.
3. If a barline has a tie attached both before and after it, then its the same tie.

That's a really elegant way to cross structural boundaries! :-)

The problem (also with incoming and outgoing) is that there's no guarantee that the notes are in the same voice. What happens when notes in two different voices in the same <part> are tied across the same barline?

The solution depends, I think, on us first agreeing about voice identifiers (in #185). (That's coming very soon!)

[ahankinson]

A location value of "start" ties a note (at the beginning of a measure) to the barline at the beginning of that measure.

From a semantic point of view, is it actually accurate to say a note is 'tied' to a barline in the same way that it is 'tied' to another note? This makes sense from a visual encoding perspective, but not necessarily from a semantic encoding. This would be very confusing in the first example posted by @joeberkovitz -- the note on the second ending is only location="start" if you're encoding the visuals; semantically, of course, it's tied to the F in the first measure. (You could imagine that a renderer could automatically expand the repeat, in which case location="start" for the second tie element wouldn't actually do what was expected...)

Another alternative for the outgoing ties: MEI has the <lv> element, which is described as a 'tie-like' symbol. Given that it doesn't actually "tie" two notes elements together, but rather acts simply to extend the duration of a single note, distinguishing between a tie and a l.v. might be another option.

[notator]

@ahankinson
I think it does make semantic sense to tie a note to a barline: After playing the first-time measure (measure 2) in the first example above, the barline at the end of measure 1 is semantically the same barline as the one at the beginning of the second-time measure. Performing applications should have no trouble working that out. This finesse is the key to coding cross-structural ties (and possibly other cross-structural information).

We could indeed have a separate <lv> element, but I rather agree with @joeberkovitz that its covered by the location attribute.

[ahankinson]

After playing the first-time measure (measure 2) in the first example above, the barline at the end of measure 1 is semantically the same barline as the one at the beginning of the second-time measure.

In the first ending the note is tied to the F in the second measure; it's only the second time around where it's tied to the barline. So is the second third F tied to the F in the first measure, or is it tied to the note immediately prior to the barline that is, semantically speaking, the same as a barline n barlines prior (assuming first endings can be more than one measure long)?

Performing applications should have no trouble working that out.

You must be new here. 😁

We could indeed have a separate element ...

I find one of the hardest tasks in making music encoding systems is identifying different things in XML that look exactly the same on paper. The old 'if it walks like a duck' rule doesn't always hold true.

[joeberkovitz]

This is a thorny problem and I think @ahankinson's objections need to be talked through carefully. As I asked here:

is it useful to distinguish a tie that merely means "let this note ring" ... from a tie to a real note on the other side of a form jump...?

I did move away from that point of view, but after thinking about it I can't dismiss the need for a semantic distinction here. Some notation programs (Dorico) appear to distinguish between the two kinds of ties even though they look the same, while others (Noteflight and I think Sibelius) do not.

First off, I believe the <tie location="start|end"> approach is useful in expressing what one sees notated, which seems like the minimum we need. We might be encoding some artifact where the interpretation is unknown, and we just need to represent the found notation. The question here is, do we sometimes need more than that? If so, what form might that take?

Here are some ideas for how we might allow encodings to resolve the cases in play. They're not mutually exclusive.

• For incoming ties, combine location="start" with target=#ID to identify the preceding <note> element on the other side of a form jump. In example 1 above, the target attribute of the incoming tie to F at the start of measure 3, would refer to the F at the end of measure 2. It is a backwards-pointing target, which may be understood from the presence of start. Or we could use a different attribute name from target. At any rate, this seems like an unambiguous semantic rep. of an incoming tie.
• For outgoing ties crossing a form boundary, combine location="end" with target=#ID, similarly identifying the tie destination. In example 2, the tie at the end of measure 3 would target the F at the beginning of measure 2.
• For "let-ring" ties, allow either <lv> or something like <tie type="lv|tied"> to identify a tie that indicates l.v.. One cannot supply a target for such a tie. (I'm a little concerned that <lv> is ambiguous with the bracket-span notation l.v..)

One important note: a real-life notation editor will not be easily able to validate the targets of form-jump ties, because documents can never be assumed to be in a complete state with the entire form represented. A composer could author bar 3 of example 1, and then later fill in bars 1 and 2. So this is one more reason we may still need bare <tie location="start|end"> with no additional known semantics (other than that it's not an l.v. tie).

[notator]

I have no strong feelings about "let-ring" ties. Both <lv> and <tie type="lv|tied"> seem okay. I'd choose the latter if pushed. However, I'm not sure I understand @joeberkovitz' caveat:

(I'm a little concerned that <lv> is ambiguous with the bracket-span notation l.v..)

Perhaps you could say a bit more about that?

---

Ties across structural boundaries:
For simplicity of reference, we are talking about this diagram:

@ahankinson said

In the first ending the note is tied to the F in the second measure; it's only the second time around where it's tied to the barline. So is the second third F tied to the F in the first measure, or is it tied to the note immediately prior to the barline that is, semantically speaking, the same as a barline n barlines prior (assuming first endings can be more than one measure long)?

I was imagining tying the final F in measure 1 to the barline at the end of measure1 (which is semantically equal to the barline at the beginning of the first-time bar the first time through, and semantically equal to the barline at the beginning of the second-time bar the second time around.
The first F in measure 2 is tied to the barline at the beginning of the first-time bar, not to the final F in measure 1.
The first F in measure 3 (the second-time measure) is tied to the barline at the beginning of measure 3.

In other words, I'm saying that it would be possible to code ties across structural boundaries by tying to the barlines that define those structural boundaries. All that's necessary, is to say that if a graphical barline is tied to notes on both its left and right, then those ties should be rendered as a single tie.

Performing applications can easily find the structurally relevant barlines, since they are explicitly present in the MNX code.
See, for example, https://w3c.github.io/mnx/docs/mnx-reference/examples/repeats-alternate-endings-advanced/

Note that this strategy would work regardless of how many different repeat endings there are (1st time, 2nd time, 3rd time etc.), and how many measures each of them contains.

[joeberkovitz]

@notator:

• The <lv> question was this: at some point down the road we need an element representing an l.v. that renders as text (not ties) and can cover a whole range of events that are allowed to let ring (instead of just one event). So I'm more comfortable calling this as a <tie> with an indicator to interpret it as an l.v..
• It sounds like you may be proposing that a single, regular tie that crosses an intervening barline with no form jumps, should be encoded as two ties on either side, each tied to a barline? If so, I don't think this makes things simpler, as it makes normal ties across a barline encoded differently from normal ties within a bar even when there are no form jumps in sight. I think the form jump case of cross-barline ties is the special case, and we don't need to encode it identically to the regular case.
• Encoding a visually unitary tie into two pieces would allow each half of the tie to have different, inconsistent properties. For example, in a sort of chimera, one half could go up while the other goes down. This kind of problem arises when one takes whole things and encodes them as pieces.
• I share @ahankinson's cynicism about applications can easily finding the relevant barlines. Regardless of how clear one thinks the algorithm might be, documents can be incomplete and have ill-defined forms (e.g. only a 2nd ending to a repeat), yet they still must be encodable in MNX.

[notator]

@joeberkovitz
Thanks for the responses. Your points:

Point 1:
I now understand your l.v. to be like a pedal marking on a piano. That's a different subject, for which we should have a separate issue. I don't think we need to be worried that such markings will conflict with <tie> types. They exist parallel to <tie> types.

Point 4:
We went to a lot of trouble, when defining the repeat-bar code, to ensure that it is easy to reconstruct the order in which the notes are played. I think we were successful, and that there's no need to be sceptical.
I think renderable MNX documents must be both complete and well defined. Of course, it must be possible to save and re-load MNX documents that are in an incomplete state, but MNX is only XML (=text) so it should always be possible to do that. The loading application can then check if the file is complete and well defined or not. If its intelligent enough, it could even flag errors and/or deficiencies (e.g. missing first-time measure(s)).

Points 2 and 3:
There is a simpler and more powerful alternative to the strategy I outlined in my previous post.
First, note that there is no way, inside a <part> element, to know where a system break is going to come. That means that MNX applications have to be able to split (singly defined) ties into two parts (graphically -- the semantics don't change): the dangling tie at the end of one system, and the connecting tie at the beginning of the next system. MNX applications must be able to split a single tie into two graphic parts regardless of how we decide to code ties across 1st, 2nd and 3rd-time barlines.
So here's the alternative (Comments welcome, of course.):

1. Contrary to the current definition of <tied>, ties that connect notes should always be connected "backwards". The (note) target of a tie is always the note on the left of the note containing the tie definition. The tie definition effectively says that "this note has no attack; it is the continuation of the previous one". (I'm not sure if we still need <tie location="start|end"> ...)
2. In the above example, that means:
   1. The F at the beginning of measure 2 is tied to the F in measure 1 using the ID of the F in Measure 1
   2. The F at the beginning of measure 3 is also tied to the F in measure 1 using the ID of the F in Measure 1

(As we've discovered, the use of noteIDs gets around the voice-identity problem.)
Since MNX applications must be able to split ties (graphically) when they hit a system break, I think its reasonable enough to expect them to notice that ties should not span more than one barline (graphically). If they do so (as in 2.ii above), they should be truncated at the closest barline to the tie definition.

[joeberkovitz]

I think the backwards-tie idea does not work because 1) authors conventionally create a tie on its starting note (as when engraving by hand), 2) the ending note may not exist at this time, while a passage is being actively notated, and 3) MNX must encode partial-edit states such that document authoring can resume smoothly across a save/reload cycle.

It doesn't matter how careful we are to make nice rules, documents will be incomplete and they must still be completely renderable and meaningful in order for authoring to resume. We cannot have cases where a partially-authored document fails to export. Consider that we may be migrating from one application (or author) to another in the midst of the engraving process, using MNX as an interchange format. If you don't agree with this principle, that should be taken up in another issue, because making incomplete documents nonrenderable wille cut across many different features of MNX.

[clnoel]

I don't consider the backward-tie idea to solve any of these problems. It's exactly programmatically equivalent to a forward tie. The other end might be on the other side of a barline. It might be on the on the other side of a system break. It might be on the other side of a jump. I also can't see why an editor would have more problems with an incomplete document one way or the other. When doing actual editing on music, do you really draw one note, draw the tie, and then draw the other note? No, you (or at least I) put in both notes, and then define the tie in between them, so it doesn't matter which note it's on. As long as it is only defined once.

(I also object to @notator's "define it on both notes" proposal. A tie should be defined once. If you need a system break, then so be it.)

@notator I noticed that you picked only one of the two examples in order to make your backward-tie proposal. It does, in fact, make sense to say that the note in measure 3 is tied backward to the note in measure 1. But it makes far less sense for the other example, where we would have to say that the note in measure 2 is tied backward to the note in measure 3 (on the other side of the D.S.) It's exactly the same problem that we have with forward ties, but in the other direction!

I think that we have to actually consider these to be two separate ties. One tie is going to the note in the next measure, one is going over a jump. Here's my current proposal:

1. A "let ring" tie is not actually a tie. It's a different semantic element that happens to sometimes look like a tie. (It can also be notated with the direction "l.v.", just as pedals can be represented either as brackets or with Ped markings, but mean the same thing.)
2. Therefore, "target" is a required tie element, notating the note on the other side of a tie, even if that note is on the other side of a jump.
3. Ties should be notated once, on their start note, but a tie that goes across a jump is a different tie, since it joins to a different note.

In this case, the tie representation is simple enough

...
<note id="m1note">
    <tie target="m2note"/>
</note>
...
<note id="m2note"/>
...
<note id="m3note">
    <tie target="m2note" start-location="this" end-location="end"/>
</note>
...

<note id="m1note">
    <tie target="m2note"/>
    <tie target="m3note" start-location="3:start" end-location="m3note"/>
</note>
...
<note id="m2note"/>
...
<note id="m3note"/>
...

I'm a little wonky about describing a tie that is only visually present in m3 on the m1 note, so I'm absolutely willing to hear alternate syntax around that one. Maybe we do allow the tie to be specified on the ending note, by renaming target to end-target and adding start-target and making one of those two required for the semantic other end of the tie. The problem with allowing that is that there becomes two ways to specify regular ties, which we are trying not to do.

[joeberkovitz]

@clnoel: In response to your question, yes, when authoring music in a notation editor (in all the editors I've used, actually) it is very common to apply the tie to the starting note before there is an ending note. Writing music fast in an editor typically requires one to use keyboard shortcuts, and the sequence of editing keys for a tied pair is always [starting note] [tie] [next note]. Virtually all editors I have used automatically attach the dangling tie on the first note to the next note, once the latter has been supplied — otherwise one would have the inefficiency of having to go back, select both notes, and apply a tie. This is how it works whether there is an intervening barline or not.

In the case of incoming/outgoing ties it's even easier to imagine that the target is not identifiable at the time the tie is specified. Composers do not write pieces in the order that they are played. I have often written repeat endings before the material that preceded them.

For this reason, it's possible (and quite common) to have a savable/encodable document in a state where there is a dangling tie before a barline, or before a rest. Likewise it's possible (though less common) to have a document with a dangling tie coming into a bar for which an algorithm would be able to find no target note, because the author hasn't engraved that note yet, or because the musical form is non-standard.

Back to your proposals.

1. Agree on the need to distinguish the l.v. case. I want to make sure we are addressing the need for both a tie-style l.v. (discussed here) and a spanning l.v. (typically the text "l.v." with an optional bracket or line after it).
2. Due to the need to encode non-l.v. ties whose target may not exist yet, we cannot require target all the time. But we can require it whenever the target is known.
3. a. (outgoing tie at end of m3). We do not need start and end locations. The tie is on a note, which always designates one of its ends. So I would say this encodes as <tie location="end" target="m2note"/> when the target is known, and <tie location="end"/> when the target isn't known.
4. b. (incoming tie at start of m3). I don't see why we need this to work any different than 3a. It can be <tie location="start" target="m2note"/>or <tie location="start"/> . We do not need different attributes to show that the tie that is going back to a prior target, because location="start" unambiguously flags this as such a case, and there are no other kinds of backward-directed target.

3a/3b thus only differ from your suggestion in not requiring a redundant start-location="this" or end-location="this", and in always allowing the target to be optional.

[joeberkovitz]

One more point. Consider short excerpts of scores encoded as MNX. These must be able to encode all the missing-target cases: regular non-l.v. ties where the next measure is missing, and incoming/outgoing ties where the measure on the other end of the form jump is missing.