MakeMusic
SmartMusic Finale Garritan MusicXML

Ties, endings, and repeats

Moderator: Michael Good

Ties, endings, and repeats

Postby Frank Weinstock » Fri Jan 11, 2013 9:12 pm

Dear Michael and the MusicXML Community,

There are potentially two kinds of unusual ties that can be involved with repeats and 1st/2nd endings:

• A tie from the last note of a first ending back to the first note of the repeat (which is presumably also tied to the note before it); this needs to be drawn as a partial tie from the last note of the first ending more or less to the barline which contains the backwards repeat sign.

• A tie from the last note before a first ending to the first note of a second ending (in this case the last note before the first ending is probably also tied to the first note of the first ending); this needs to be drawn as a partial tie from more or less the barline which starts the second ending to the first note of that ending.

I've not seen anything in the documentation to indicate how these situation are represented, and my first point is to confirm that it is indeed the responsibility of the reading program to infer these situations. Unfortunately, they each involve a <tied> element with either a "start" or
"stop" attribute, without a corresponding opposite element. (Perhaps in a future version of MusicXML, it might be helpful to enable the <barline> element to include a <tied> element which would represent the beginning or end of such a partial slur?)

My second point is to let you know that a file set up in Finale for the second situation listed above (tie from the last note before the first ending to the first note of the second ending) which is then exported to XML and then imported back into Finale, appears to lose that tie. The first situation above seems to survive the double translation.

If any of this is confusing, I'd be happy to send a file or two off-list to clarify what I'm talking about.

Thanks, and best wishes to all!

Frank

****************

Frank Weinstock Professor Emeritus of Piano College-Conservatory of Music University of Cincinnati
Frank Weinstock
 
Posts: 24
Joined: March, 2014
Reputation: 0

Re: Ties, endings, and repeats

Postby Joe Berkovitz » Sat Jan 12, 2013 8:17 am

Frank,

This is a point that has come up before as a sideline to another discussion. Please see the thread in the archives titled "Order of number-based elements" (11/8/2012).

In the absence of a clear spec on how to deal with this, a number of encoding practices seem to be current:
- an outgoing tie with only a <start> and no <stop> at the end of a section.
- an incoming tie with only a <stop> and no <start> at the beginning of a section.
- a "faked tie" with a <slur> element that looks just like an outgoing or incoming tie. One is tempted to label this as simply careless engraving practice, but not all MusicXML-capable programs have always supported dangling ties in a clear way, and so engravers have made do. Some programs will import such slurs as the dangling ties that they were clearly intended to be.

The unmatched-tie approach appears to be the closest thing we have to an official MusicXML representation. I felt (and continue to feel) that an less ambiguous construct for single-endpoint objects would be a great improvement to MusicXML, although I'm not crazy about the bar line idea; I'd rather see an attribute on the tie that says it lacks a beginning or an end (since such a notation could conceivably be used in an unbarred context). I don't recall whether Michael agreed with this in the previous discussion, but it doesn't seem to be a settled point.

... . . . Joe

Joe Berkovitz President

Noteflight LLC Boston, Mass. phone: +1 978 314 6271 www.noteflight.com

wrote:

Dear Michael and the MusicXML Community,

There are potentially two kinds of unusual ties that can be involved with repeats and 1st/2nd endings:

• A tie from the last note of a first ending back to the first note of the repeat (which is presumably also tied to the note before it); this needs to be drawn as a partial tie from the last note of the first ending more or less to the barline which contains the backwards repeat sign.

• A tie from the last note before a first ending to the first note of a second ending (in this case the last note before the first ending is probably also tied to the first note of the first ending); this needs to be drawn as a partial tie from more or less the barline which starts the second ending to the first note of that ending.

I've not seen anything in the documentation to indicate how these situation are represented, and my first point is to confirm that it is indeed the responsibility of the reading program to infer these situations. Unfortunately, they each involve a <tied> element with either a "start" or
"stop" attribute, without a corresponding opposite element. (Perhaps in a future version of MusicXML, it might be helpful to enable the <barline>
element to include a <tied> element which would represent the beginning or end of such a partial slur?)

My second point is to let you know that a file set up in Finale for the second situation listed above (tie from the last note before the first ending to the first note of the second ending) which is then exported to XML and then imported back into Finale, appears to lose that tie. The first situation above seems to survive the double translation.

If any of this is confusing, I'd be happy to send a file or two off-list to clarify what I'm talking about.

Thanks, and best wishes to all!

Frank

****************

Frank Weinstock Professor Emeritus of Piano College-Conservatory of Music University of Cincinnati
Joe Berkovitz
 
Posts: 79
Joined: March, 2014
Reputation: 0

Re: Ties, endings, and repeats

Postby Frank Weinstock » Sun Jan 13, 2013 12:08 am

Thank you, Joe, for this very helpful information, including the reference to the earlier thread.

I agree with you that a construct for a single-endpoint tie would be good, and that my idea of letting a barline be the pseudo-other-endpoint is not so good. Perhaps something analogous to the "forward hook" and "backward hook" values for the <beam> element would do the trick?

Interestingly, five minutes after reading your email, for the first time I saw a file where there was a slur from a note to itself, clearly meant to describe one of the situations which are the subject of this thread. It is indeed unfortunate that there appear to be at least two different way to to represent the same notation.

Thanks again for your help!

All best,

Frank

****************

Frank Weinstock Professor Emeritus of Piano College-Conservatory of Music University of Cincinnati


Frank,

This is a point that has come up before as a sideline to another discussion. Please see the thread in the archives titled "Order of number-based elements" (11/8/2012).

In the absence of a clear spec on how to deal with this, a number of encoding practices seem to be current:
- an outgoing tie with only a <start> and no <stop> at the end of a section.
- an incoming tie with only a <stop> and no <start> at the beginning of a section.
- a "faked tie" with a <slur> element that looks just like an outgoing or incoming tie. One is tempted to label this as simply careless engraving practice, but not all MusicXML-capable programs have always supported dangling ties in a clear way, and so engravers have made do. Some programs will import such slurs as the dangling ties that they were clearly intended to be.

The unmatched-tie approach appears to be the closest thing we have to an official MusicXML representation. I felt (and continue to feel) that an less ambiguous construct for single-endpoint objects would be a great improvement to MusicXML, although I'm not crazy about the bar line idea; I'd rather see an attribute on the tie that says it lacks a beginning or an end (since such a notation could conceivably be used in an unbarred context). I don't recall whether Michael agreed with this in the previous discussion, but it doesn't seem to be a settled point.

... . . . Joe

Joe Berkovitz President

Noteflight LLC Boston, Mass. phone: +1 978 314 6271 www.noteflight.com

wrote:

Dear Michael and the MusicXML Community,

There are potentially two kinds of unusual ties that can be involved with repeats and 1st/2nd endings:

• A tie from the last note of a first ending back to the first note of the repeat (which is presumably also tied to the note before it); this needs to be drawn as a partial tie from the last note of the first ending more or less to the barline which contains the backwards repeat sign.

• A tie from the last note before a first ending to the first note of a second ending (in this case the last note before the first ending is probably also tied to the first note of the first ending); this needs to be drawn as a partial tie from more or less the barline which starts the second ending to the first note of that ending.

I've not seen anything in the documentation to indicate how these situation are represented, and my first point is to confirm that it is indeed the responsibility of the reading program to infer these situations. Unfortunately, they each involve a <tied> element with either a "start" or
"stop" attribute, without a corresponding opposite element. (Perhaps in a future version of MusicXML, it might be helpful to enable the <barline>
element to include a <tied> element which would represent the beginning or end of such a partial slur?)

My second point is to let you know that a file set up in Finale for the second situation listed above (tie from the last note before the first ending to the first note of the second ending) which is then exported to XML and then imported back into Finale, appears to lose that tie. The first situation above seems to survive the double translation.

If any of this is confusing, I'd be happy to send a file or two off-list to clarify what I'm talking about.

Thanks, and best wishes to all!

Frank

****************

Frank Weinstock Professor Emeritus of Piano College-Conservatory of Music University of Cincinnati
Frank Weinstock
 
Posts: 24
Joined: March, 2014
Reputation: 0

Re: Ties, endings, and repeats

Postby Walter Hewlett » Sun Jan 13, 2013 7:59 pm

Hello,

Walter Hewlett here -- designer of Musedata.

Regarding the partial tie question:

We have cobbled together a solution, which seems to work for the time being but could, I am sure, be improved upon.

For the tie that starts on a note and extends to the end of a measure, we conjured up a new type of musical direction called a tie-terminator, with a data descriptor that gives the pitch on which the tie started. This gives the right-hand end of the tie something to anchor to. You need this, since the length of the tie cannot be known until the music is typeset. The tie-terminator would be placed just before the bar line.

On the other hand, the tie that terminates into a pitch from the left does not need to have variable length, so we treat this just like any other notation attached to a note, like, say, a musical ornament (from the notation point of view).

This solution does not directly address the question of how you generate real sound output from the representation, but since this question involves things like repeats and first/second endings, the solution is complicated in any case.

We initiated this data specification only after Michael Good starting working on Music XML, so no form of it appears in his design (as far as I know).

-- Walter B. Hewlett CCARH

Frank Weinstock wrote:Dear Michael and the MusicXML Community,

There are potentially two kinds of unusual ties that can be involved with repeats and 1st/2nd endings:

• A tie from the last note of a first ending back to the first note of the repeat (which is presumably also tied to the note before it); this needs to be drawn as a partial tie from the last note of the first ending more or less to the barline which contains the backwards repeat sign.

• A tie from the last note before a first ending to the first note of a second ending (in this case the last note before the first ending is probably also tied to the first note of the first ending); this needs to be drawn as a partial tie from more or less the barline which starts the second ending to the first note of that ending.

I've not seen anything in the documentation to indicate how these situation are represented, and my first point is to confirm that it is indeed the responsibility of the reading program to infer these situations. Unfortunately, they each involve a <tied> element with either a "start" or "stop" attribute, without a corresponding opposite element. (Perhaps in a future version of MusicXML, it might be helpful to enable the <barline> element to include a <tied> element which would represent the beginning or end of such a partial slur?)

My second point is to let you know that a file set up in Finale for the second situation listed above (tie from the last note before the first ending to the first note of the second ending) which is then exported to XML and then imported back into Finale, appears to lose that tie. The first situation above seems to survive the double translation.

If any of this is confusing, I'd be happy to send a file or two off-list to clarify what I'm talking about.

Thanks, and best wishes to all!

Frank

****************

Frank Weinstock Professor Emeritus of Piano College-Conservatory of Music University of Cincinnati
Walter Hewlett
 
Posts: 3
Joined: March, 2014
Reputation: 0

Re: Ties, endings, and repeats

Postby Michael Good » Tue Jan 15, 2013 12:49 pm

Hi Frank, Joe, and Walter,

Thanks for the great discussion on this.

As Walter mentions, there are two aspects to this: playback (via the tie element) and appearance (via the tied element). For playback, I'm not sure what really can be added to MusicXML. Music notation has a lot of context, so the application interpreting the MusicXML needs to be able to interpret repeats correctly in order to get the playback correct, ties or no ties. I don't think MusicXML is missing anything here.

For appearance, probably the best way to do this in MusicXML 3.0 is to specify two tied elements on the note: one with type="start", one with type="stop". This specifies that the tie graphically is just associated with a single note. You can specify full positioning of both the start and stop points of the tie if you wish.

I think this is pretty much equivalent to the idea of associating one point of the tied element with either the barline or a position near the barline. I think it is also equivalent to Joe's request for a single-ended distinction. Please let me know if I am missing something.

The problem I see here is more of a software issue than a format issue. I don't know if any MusicXML software is exporting this type of tie in this way.

The Finale issue you mention is a known issue in Finale's MusicXML support, and is on our list of things we would like to address in the future.

Any program that uses different mechanisms to represent slurs and ties will lead to MusicXML files where you see slurs where ties were really intended, not just in these dangling tie situations. There are lots of cases where engravers have traditionally worked for how it looks in print, not how it works in digital (including playback). Addressing that area is both a social and technical issue.

Best regards,

Michael Good MakeMusic, Inc.
Michael Good
VP of MusicXML Technologies
MakeMusic, Inc.
User avatar
Michael Good
 
Posts: 2197
Joined: March, 2014
Reputation: 0

Re: Ties, endings, and repeats

Postby Joe Berkovitz » Tue Jan 15, 2013 1:21 pm

For appearance, probably the best way to do this in MusicXML 3.0 is to specify two tied elements on the note: one with type="start", one with type="stop". This specifies that the tie graphically is just associated with a single note. You can specify full positioning of both the start and stop points of the tie if you wish

I think this is pretty much equivalent to the idea of associating one point of the tied element with either the barline or a position near the barline. I think it is also equivalent to Joe's request for a single-ended distinction. Please let me know if I am missing something.

Hmmm, I wish you'd appended an example because I'm not sure I understand what you're proposing, but I think that there may be a problem here.

If your proposal dispenses with the distinction between incoming single-ended ties and outgoing single-ended ties, then this is not the same as my request. I would like to see a semantic distinction between those cases because they mean different (in fact, diametrically opposed) things musically.

I do not want to see this distinction between the two flavors of single-ended tie enshrined in the graphical positioning of endpoints. That would turn a semantic difference into a presentation difference -- similar to saying, "don't look at the verse number of a lyric, look at its Y position". That kind of approach is the bane of MusicXML import.

Any program that uses different mechanisms to represent slurs and ties will lead to MusicXML files where you see slurs where ties were really intended, not just in these dangling tie situations. There are lots of cases where engravers have traditionally worked for how it looks in print, not how it works in digital (including playback). Addressing that area is both a social and technical issue.

Agreed. And a specification that clearly treats this case and prescribes a representation will be both a social and technical solution.

... . . . Joe

Joe Berkovitz President

Noteflight LLC Boston, Mass. phone: +1 978 314 6271 www.noteflight.com
"Your Music, Everywhere"
Joe Berkovitz
 
Posts: 79
Joined: March, 2014
Reputation: 0

Re: Ties, endings, and repeats

Postby Michael Good » Tue Jan 15, 2013 1:43 pm

Hi Joe,

I understand your point about not distinguishing the two cases based on graphics. But I think we can distinguish the two cases via the tie element. An incoming single-ended tie after a repeat has a <tie type="stop"/> element; an outgoing single-ended tie before a repeat has a <tie type="start"/> element. Does that work or am I still missing something?

I'm slammed with meetings today, but if this is still unclear please let me know, and I'll reply later with some MusicXML examples of this suggestion.

I do think a clarified MusicXML encoding specification - for this or any other issue - is only a technical solution, not a social solution. Getting engravers and publishers to use their notation entry tools as semantic tools, not just appearance tools, involves much more than that.

Best regards,

Michael Good MakeMusic, Inc.
Michael Good
VP of MusicXML Technologies
MakeMusic, Inc.
User avatar
Michael Good
 
Posts: 2197
Joined: March, 2014
Reputation: 0

Re: Ties, endings, and repeats

Postby Joe Berkovitz » Tue Jan 15, 2013 1:54 pm

Michael Good wrote:Hi Joe,

I understand your point about not distinguishing the two cases based on graphics. But I think we can distinguish the two cases via the tie element. An incoming single-ended tie after a repeat has a <tie type="stop"/> element; an outgoing single-ended tie before a repeat has a <tie type="start"/> element. Does that work or am I still missing something?

I think it works -- it's just ambiguous compared to having something explicit like "stop-only" or "start-only", which creates more possibility for import errors. Such explicit attributes would cue the importer that there is no matching tie to be found at the opposite end of the relationship.

Michael Good wrote:I do think a clarified MusicXML encoding specification - for this or any other issue - is only a technical solution, not a social solution. Getting engravers and publishers to use their notation entry tools as semantic tools, not just appearance tools, involves much more than that.

Very true, very true! A spec is only part of the picture -- but having a robust spec and conversion landscape means there is a tangible benefit for engravers to follow the rules.
Joe Berkovitz
 
Posts: 79
Joined: March, 2014
Reputation: 0

Re: Ties, endings, and repeats

Postby Frank Weinstock » Tue Jan 15, 2013 2:44 pm

Hi again,

Using without a matching (or vice versa) invites problems in the somewhat special case (but not uncommon) where the note before the first ending has a certain pitch and is tied to the first note of the first ending as well as to the first note of the second ending, and the last note of the first ending has that same pitch and is tied back to the first note of the repeat. Â In this case, if the reading program does not make proper notice of the repeat, this looks like a normal sequence of ties, with the last note before the first ending tied to the first note of the first ending and the last note of the first ending tied to the first note of the second ending--that last tie being incorrect. Â (I'd be happy to send a file illustrating this if that would help...)

Michael's earlier suggestion of putting a "start" and "stop" element on the same note would signal to the reading program that this is, indeed, not a normal tie. Â However, as Joe says, that doesn't explicitly give the direction of the single-ended tie, and the program would, again, need to understand the repeat and its endings correctly. Â (Which, of course it should...)

Best,

Frank

****************

Frank Weinstock Professor Emeritus of Piano College-Conservatory of Music University of Cincinnati



Hi Joe,

I understand your point about not distinguishing the two cases based on graphics. But I think we can distinguish the two cases via the tie element. An incoming single-ended tie after a repeat has a type="stop"/> element; an outgoing single-ended tie before a repeat has a element. Does that work or am I still missing something?

I think it works -- it's just ambiguous compared to having something explicit like "stop-only" or "start-only", which creates more possibility for import errors. Â Such explicit attributes would cue the importer that there is no matching tie to be found at the opposite end of the relationship.

I do think a clarified MusicXML encoding specification - for this or any other issue - is only a technical solution, not a social solution. Getting engravers and publishers to use their notation entry tools as semantic tools, not just appearance tools, involves much more than that.

Very true, very true! A spec is only part of the picture -- but having a robust spec and conversion landscape means there is a tangible benefit for engravers to follow the rules.

 Post your message to the list by sending it to
.

 To contact the list owner, send your message to      .

du
Frank Weinstock
 
Posts: 24
Joined: March, 2014
Reputation: 0

Re: Ties, endings, and repeats

Postby Joe Berkovitz » Tue Jan 15, 2013 2:56 pm

Excellent example, Frank. I think it's very clear, anyway.

This case is also very frequently found at the start of a coda.

One could try to resolve such cases by taking note that there is a musical form discontinuity between the two measures, hence such a tie can only be interpreted as two separate, dangling ties that do not connect. Clearly this is not robust, since some discontinuities are only signaled by textual directions in the score.

…Joe

wrote:

Frank Weinstock wrote:Hi again,

Using without a matching (or vice versa) invites problems in the somewhat special case (but not uncommon) where the note before the first ending has a certain pitch and is tied to the first note of the first ending as well as to the first note of the second ending, and the last note of the first ending has that same pitch and is tied back to the first note of the repeat. Â In this case, if the reading program does not make proper notice of the repeat, this looks like a normal sequence of ties, with the last note before the first ending tied to the first note of the first ending and the last note of the first ending tied to the first note of the second ending--that last tie being incorrect. Â (I'd be happy to send a file illustrating this if that would help...)

Michael's earlier suggestion of putting a "start" and "stop" element on the same note would signal to the reading program that this is, indeed, not a normal tie. Â However, as Joe says, that doesn't explicitly give the direction of the single-ended tie, and the program would, again, need to understand the repeat and its endings correctly. Â (Which, of course it should...)

Best,

Frank

****************

Frank Weinstock Professor Emeritus of Piano College-Conservatory of Music University of Cincinnati
>


Hi Joe,

I understand your point about not distinguishing the two cases based on graphics. But I think we can distinguish the two cases via the tie element. An incoming single-ended tie after a repeat has a type="stop"/> element; an outgoing single-ended tie before a repeat has a element. Does that work or am I still missing something?

I think it works -- it's just ambiguous compared to having something explicit like "stop-only" or "start-only", which creates more possibility for import errors. Â Such explicit attributes would cue the importer that there is no matching tie to be found at the opposite end of the relationship.

I do think a clarified MusicXML encoding specification - for this or any other issue - is only a technical solution, not a social solution. Getting engravers and publishers to use their notation entry tools as semantic tools, not just appearance tools, involves much more than that.

Very true, very true! A spec is only part of the picture -- but having a robust spec and conversion landscape means there is a tangible benefit for engravers to follow the rules.

 Post your message to the list by sending it to
.

 To contact the list owner, send your message to      .

du
Joe Berkovitz
 
Posts: 79
Joined: March, 2014
Reputation: 0

Next

Who is online

Users browsing this forum: No registered users and 1 guest

cron