Correct way to encode a tie to a note at the beginning of second ending.

[rpatters1]

I am trying to understand how to encode the ties circled in the image below.

Does this have a <tie> element?
Do I use continue for the <tied> element in <notations> or do I use <start> followed by <stop>?
How does it interact if the tie on the second ending continues to the next note as in this example:

[infojunkie]

<tie> and <tied> have got to be the most confusingly named elements in MusicXML...

As per the doc:

The <tied> element represents the notated tie. The <tie> element represents the tie sound.

So we're only talking about <tied> here.

In example 1, we have 3 ties, numbered 1, 2 and 3 respectively (order irrelevant). The notes in ending 2 would have <tied number="X" type="stop">, as would the notes in ending 1.

In example 2, there's a single tie so number is strictly not needed. The note in ending 2 would have <tied type="continue"> . Although I would recommend adding a number to help importers understand the situation.

Sorry, I misread the documentation. There's an explicit passage about this case:

Ties that are visually attached to only one note, other than undamped ties, should be specified with two <tied> elements on the same note, first type=“start” then type=“stop”. This can be used to represent ties into or out of repeated sections or codas.

@rpatters1 @lemzwerg ^

[lemzwerg]

Sounds sensible. Since this isn't covered by the documentation I suggest to add both some words and an example.

[infojunkie]

I was wrong - the documentation is clear about this case, and I updated my answer accordingly.

[rpatters1]

I tried hand-editing this and could not find any support for this among Dorico 5, MuseScore 4, or Finale importers. Anything we can do to get importers to read that doc is to the good. 🤣

Also, the callout in the docs does not say what happens when the tie continues past the beginning of the 2nd ending. It seems like there would be yet a third tied element, along with a tie start element. Putting that all in by hand just seems to confuse the above importers.

[lemzwerg]

Please post your hand-edited MusicXML code!

[rpatters1]

Here is a export of the first image I posted, with (as best as I understand it) the 2nd ending tie continuation hand coded as follows (for the E4)

      <note>
        <pitch>
          <step>E</step>
          <octave>4</octave>
        </pitch>
        <duration>16</duration>
        <voice>1</voice>
        <type>half</type>
        <notations>
          <tied type="start" />
          <tied type="stop" />
        </notations>
      </note>

Both Dorico 5 and MuseScore import them as forward lv ties rather than continuation ties to the left of the noteheads. Finale ignores them.

tie-target-types.musicxml.txt

Here is the musicxml for the second image above, with hand-crafted continuation tie mixed in with the forward tie (which seems to be what the spec is saying, though I could well be mistaken: hence why I opened this discussion).

      <note>
        <pitch>
          <step>B</step>
          <octave>4</octave>
          </pitch>
        <duration>4</duration>
        <tie type="start"/>
        <voice>1</voice>
        <type>whole</type>
        <notations>
          <tied type="start"/>
          <tied type="stop"/>
          <tied type="start"/>
        </notations>
      </note>

Finale, Dorico 5 and MuseScore both just ignore the extra <tied> elements.

tie_continuation.musicxml.txt

[lemzwerg]

Thanks for the code!

@infojunkie wrote:

the documentation is clear about this case, and I updated my answer accordingly.

Re-reading everything I now believe that this assertion is incorrect. The documentation is not clear at all.

AFAICS, the code

<tied type="start"/>
<tied type="stop"/>

attached to a single note should always indicate a single tie to the left. A single tie to the right gets indicated with the tied-type=let-ring attribute.

I think it would be best to change the text

Ties that are visually attached to only one note, other than undamped ties, should be specified with two elements on the same note, first type=“start” then type=“stop”. This can be used to represent ties into or out of repeated sections or codas.

to something like the following in MusicXML 4.1 to both clarify the specification and to support the following case (that could happen, say, in citing a single bar of a piece in a musicological paper).

Ties that are visually attached to only one note on the left, as can happen with ties out of repeated sections or codas, should be specified with two elements on the same note, first type=“start” then type=“stop”.

MuseScore and Dorico could easily handle both old code with the 'wrong' interpretation (i.e., making start-stop equivalent to laissez-vibrer ties) and new code with the 'correct' interpretation by looking at the MusicXML version.

[rpatters1]

MuseScore and Dorico could easily handle both old code with the 'wrong' interpretation (i.e., making start-stop equivalent to laissez-vibrer ties) and new code with the 'correct' interpretation by looking at the MusicXML version.

Or they could just start interpreting it correctly irrespective of version. I agree that the new proposed wording is clearer and would advocate making this change. But functionally it describes the current state of the spec in 4.0, at least if I understand the language. 😅

Also, the bigger issue to me is the 2nd example, where they just ignore the "extra" <tied> elements. I think the documentation needs to be explicit about how to continue a tie to the right from a tie-stub to the left.

[lemzwerg]

Or they could just start interpreting it correctly irrespective of version. I agree that the new proposed wording is clearer and would advocate making this change. But functionally it describes the current state of the spec in 4.0, at least if I understand the language. 😅

You are probably right. 🙂

BTW, what do Dorico and MuseScore emit while exporting MusicXML if you enter a left-side tie attached to a single note?

[rpatters1]

Here is the MuseScore export. (It has a vestigial <tied type="stop"/> for the left-side tie-stub. On reimport it does not turn into a left-side tie-stub.)

I don't know Dorico at all, so I can't quickly test how it exports this. I have it because it was gifted to me by the folks at MakeMusic on their way out the door, as a reward helping them so much over the years. So I use it to test imports.

tie_continuation_musescore.musicxml.txt

[rpatters1]

Here is what Finale exports. It does not reimport either.

tie_continuation_finale.musicxml.txt

[lemzwerg]

Re-reading the documentation of <tied> I think I now got it 🙂

Consider this example.

According to the documentation, the right-side tie attached to the second note in the prima volta measure should be encoded with start-stop – this tie is not a laissez-vibrer tie!

If we strictly follow the current wording of the standard, and we encounter a start-stop tie in the MusicXML input, we are forced to check the following.

• The note the tie is attached to must be a first or a last note in a measure.
• If it is a first note, it must be at the beginning of a volta n box, with n > 1, or at the beginning of a piece outside of a repeat. If not at the beginning of a piece outside of a repeat, a last note in the bar before the first volta box must have a fitting tie into the first volta box.
• If it is a last note, it must be at the end of a volta n box, with n < max_volte, or at the end of a piece outside of a repeat. If not at the end of a piece outside of a repeat, a last note in the bar before the repeat must have a fitting tie into the repeat.

If these conditions are not met we have semantically invalid input.

Given that MusicXML is primarily used to visually represent music, I consider it very surprising that it is necessary to perform such a deep structural analysis just to find out whether to draw a right-side or a left-side tie attached to a single note.

[lemzwerg]

Given that MusicXML is primarily used to visually represent music, I consider it very surprising that it is necessary to perform such a deep structural analysis just to find out whether to draw a right-side or a left-side tie attached to a single note.

Of course, the 'cheap' solution for handling the start-stop case (which is probably intended by the standard) is to ignore semantic validity and to draw a left-side tie for a measure's first note and a right-side tie for a measure's last note, and to degenerate to a laissez-vibrer tie in all other cases. I only wonder why this is not described in the standard, and we have to find out all these things the hard way...

[mdgood]

Given that MusicXML is primarily used to visually represent music, I consider it very surprising that it is necessary to perform such a deep structural analysis just to find out whether to draw a right-side or a left-side tie attached to a single note.

MusicXML is primarily used to represent music notation semantically for interchange between apps. Visual details for near-lossless formatting came later.

For ties that aren't let ring indications, the <tie> element lets you know which type of tie it is if you have a start/stop pair.

Before we added the let-ring tie-type, apps had to use start-stop pairs for these too. In some complex cases you would have to resort to the formatting information on the <tied> element. That could still happen for cue notes theoretically, but extremely rarely if ever in practice.

[infojunkie]

I am keeping my answer as the "correct" one because I think that the original question ("Correct way to encode a tie to a note at the beginning of second ending") is addressed by the documentation that I quoted. There are more questions in the discussion, and I agree that if the interpretation that is formulated here is correct, the implications for the software algorithm are significantly complex. Would there be a way to handle the cases mentioned here in a simpler way, by modifying the expectations?

[lemzwerg]

I think that the original question ("Correct way to encode a tie to a note at the beginning of second ending") is addressed by the documentation

Is it really? Isn't it possible that this sentence

This can be used to represent ties into or out of repeated sections or codas.

rather describes the following two situations, being short-hands that avoid the usage of a more complicated repeat structures (i.e., with alternatives)?

This would then only discuss right-sided stubs...

[rpatters1]

The stated answer works would be straightforward to implement when there is not a tie continuing to the right. But when there is, it may become messy to disambiguate which tied elements go with which semantic "tie". Perhaps a new tie-type for tied would help. It would explicitly define a tie stub to the left the way "let-ring" defines one to the right. Of course, that would mean no support until importers had gone through enough dev cycles to implement it.

There is also the "continue" type, and near as I can tell no one uses it, at least among the exporters I'm working with. The "continue" type illustrates perfectly a challenge of working with the musicxml spec. The definition:

Continuation of a tie, usually used for cross-system formatting.

This definition leaves more questions than it answers.

• Continuation to the right at the end of a system?
• Continuation from the left at the beginning of a system?
• What other uses are there that are less "usual"?

As it is, "continue" seems like it is tied to system layout when the name implies it could be used for so much more. (A seeming example is @lemzwerg's 1st ending example above.)

I don't mean to pick on this spec, and I know @infojunkie has just inherited it. I am not casting aspersions. I just wish the spec could be less afraid to be highly specific about how the committee envisions elements should be used. It is an opportunity for improvement in 4.1 without the risk of introducing new features.

[mdgood]

The stated answer works would be straightforward to implement when there is not a tie continuing to the right. But when there is, it may become messy to disambiguate which tied elements go with which semantic "tie".

How is this messy? The spec states that the <tied> elements should be in musical score order.

[rpatters1]

How is this messy? The spec states that the elements should be in musical score order.

Fair question. Perhaps not messy, but neither Finale, MuseScore, nor Dorico 5 do anything at all with them, at least from what displays, so perhaps not obvious either.

One possible issue is that there is no explicit distinction between which <tied> elements apply to the dangling tie end on the left and which apply to the tie on the right. It seems like an opportunity for importers to get it wrong (which they clearly do).

[mdgood]

This definition leaves more questions than it answers.

• Continuation to the right at the end of a system?
• Continuation from the left at the beginning of a system?
• What other uses are there that are less "usual"?

Yes for both the end of a system and the beginning of a system, which seemed clear to me at the time since there was no restriction mentioned. The other use would be for complex ties, similar to complex slurs as mentioned in the start-stop-continue type. I don't know if that exists in repertoire but it seemed best not to exclude it. Mentioning it explicitly for ties seemed to be inviting even more confusion.

[lemzwerg]

It would explicitly define a tie stub to the left the way "let-ring" defines one to the right.

Yes! Such a feature would be very much in the spirit of MusicXML, visually describing what's going on. BTW, in LilyPond the command to create such a left-side tie stub is called \repeatTie, so maybe the tie type could be named repeat-tie. But see below.

This definition leaves more questions than it answers.

• Continuation to the right at the end of a system?
• Continuation from the left at the beginning of a system?
• What other uses are there that are less "usual"?

From my experience with the MusicXML specification, the word 'usually' actually means 'you must use it exactly as described if you are using it' 🙂

While I often have difficulties with the interpretation of the standard, I think that the meaning here is clear: it is 'continuation from the left at the beginning of a system' and nothing else. As far as I can tell, it is intended for applications that work on the lowest, purely visual representation level; such applications don't have any built-in logic to handle broken ties between systems automatically; sophisticated system thus would ignore <tied type="continue"> as being redundant.

An alternative to the suggested repeat-tie tie type could be to say that a start-stop tie without an attribute is the right-side stub, and a continue-stop tie is the left-side stub.

[lemzwerg]

To summarize: I see two alternative ways to fix the discussed problem.

1. A start-stop tie is a left-side stub at the beginning of a measure, and a right-side stub at the end of a measure.
2. A start-stop tie without an attribute is a right-side stub, and a continue-stop tie is a left-side stub.

Thanks to the discussion I now favor solution 2, for three reasons:

• It is compatible with what major applications do, namely to create a right-side stub for a start-stop tie.
• It doesn't need semantical analysis.
• It fits nicely into the standard, using only attributes that are already present, not defining anything new.

[lemzwerg]

Example code, assuming that the right-side stub is not a laissez-vibrer tie:

<note>
  <pitch>
    <step>B</step>
    <octave>4</octave>
  </pitch>
  <duration>4</duration>
  <type>whole</type>
  <notations>
    <tied type="continue"/>
    <tied type="stop"/>
    <tied type="start"/>
    <tied type="stop"/>
  </notations>
</note>

[lemzwerg]

It just occurred to me that an even simpler solution is available, namely to say that type="continue" is a left-side stub! It is nowhere written that we need the semantic element order start–continue–stop for ties. For the above image we would thus have the following.

<note>
  <pitch>
    <step>B</step>
    <octave>4</octave>
  </pitch>
  <duration>4</duration>
  <type>whole</type>
  <notations>
    <tied type="continue"/>
    <tied type="start"/>
    <tied type="stop"/>
  </notations>
</note>

[lemzwerg]

Another idea to encode a left-side tie stub: stop-start – the previous image would then be encoded as

<note>
  <pitch>
    <step>B</step>
    <octave>4</octave>
  </pitch>
  <duration>4</duration>
  <type>whole</type>
  <notations>
    <tied type="stop"/>
    <tied type="start"/>
    <tied type="start"/>
    <tied type="stop"/>
  </notations>
</note>

I'm really, really curious to see what @mdgood will show us 🙂

[infojunkie]

Thanks for the thorough discussion here.

To help it reach a conclusion, I think it would be feasible to change the documented expectation to something that makes more sense, IF we can reasonably ascertain that the top major engravers are not already handling the cases described here during MusicXML import / export.

It would be useful to classify the cases (into repeated section, out of repeated section, with continuation, etc.) and document what survives MusicXML export then re-import.

Also, documenting the way that other formats encode these cases would be instructive. For example, MuseScore 4.x uses the following schema to indicate an incoming tie that's not connected to a previous note:

 <Note>
  <PartialTie>
    <partialSpannerDirection>incoming</partialSpannerDirection>
  </PartialTie>
 [...]

[mdgood]

Does this have a <tie> element? Do I use continue for the <tied> element in <notations> or do I use <start> followed by <stop>? How does it interact if the tie on the second ending continues to the next note as in this example:

Yes, it has a <tie type="stop"> element so the note is not attacked when the second ending starts. Use a start/stop pair of <tied> elements, as you would at the end of a first ending. Make sure the start precedes the stop. Add a second tie/tied pair after the first if the tie continues on to the next note.

[lemzwerg]

I really wonder whether there is a single application in the real world that supports the encoding of left-side tie stubs the way you envision.

Using this test file, I can partially answer my question:

• MuseScore (tested a nightly build from 2026-Jul-13 of version 5.0.0) ignores <tie type="stop"> in a seconda-volta box to indicate left-side tie stubs; it displays right-side tie stubs instead.

  

• Finale (tested version 27.4.1.112) doesn't support this either; it is generally quite weak while importing MusicXML tie types (i.e., no cross-voice ties, no right-side tie-stubs, no laissez-vibrer ties, no 'arpeggio' ties).

  

Can people please provide renderings from Sibelius and Dorico?

[rpatters1]

Dorico 5 writes forward (lv) ties.

[lemzwerg]

Ping! Asking again if someone™ can contribute a rendering of the abovementioned MusicXML file using Sibelius!

[infojunkie]

Here's Sibelius First 2025.4 build 7105 for Windows.

[infojunkie]

And here's Verovio 6.3.0-dev-fb5c4db

It complains about the ties:

[Warning] tie with @xml:id k10vn21n will not get rendered as it has identical values in @startid and @endid
[Warning] tie with @xml:id m1l7vw6d will not get rendered as it has identical values in @startid and @endid
[Warning] tie with @xml:id o1k81tku will not get rendered as it has identical values in @startid and @endid
[Warning] tie 'k10vn21n' is ignored, since start 'iq422ci' does not occur temporally before end 'iq422ci'.
[Warning] tie 'm1l7vw6d' is ignored, since start 'lu7mr3s' does not occur temporally before end 'lu7mr3s'.
[Warning] tie 'o1k81tku' is ignored, since start 'nj8ohpa' does not occur temporally before end 'nj8ohpa'.

[rpatters1]

Speaking for myself, I'm interested in any situation involving "jump" ties:

• tie skipping over a first ending to a second ending (with another forward tie continuing there): the second example in my original post
• tie from first ending back to beginning repeat measure
• tie from DS back to Segno.

To use Finale terminology, all of these involve "tie-ends" on notes from notes that do not immediately precede them. The first ending and D.S. case also involve tie-forwards to notes that do not come immediately after them. And they also involve tie-forwards to multiple notes. (As in the examples in my original post, where one tie forward ties to notes in both 1st & 2nd endings.)

[mdgood]

@rpatters1 I think all these cases are covered in the 3 examples that @lemzwerg asked for. If it's still unclear, please let me know.

[rpatters1]

The one I still would like to see is bar 4 of my second example in the O.G. post. It combines a jump tie continuation (across the first ending) with a tie starting at the same note continuing to bar 5.

[mdgood]

That one would be:

   <note>
     <pitch>
        <step>B</step>
        <octave>4</octave>
     </pitch>
     <duration>4</duration>
     <tie type="stop"/>
     <tie type="start"/>
     <voice>1</voice>
     <type>whole</type>
     <notations>
        <tied type="start"/>
        <tied type="stop"/>
        <tied type="start"/>
     </notations>
  </note>

The continue type is just used for specifying formatting details at system breaks.