MakeMusic
SmartMusic Finale Garritan MusicXML

cancel element

Moderator: Michael Good

cancel element

Postby Evan Brooks » Sun Mar 27, 2016 8:53 pm

Hi Michael,

Several questions about the <cancel> element, and how it is implemented in Finale:

(1) How and under what circumstances does Finale generate a <cancel> element for a key signature? How can or does the user control this process in Finale?

It appears that it is only generated when a key signature change occurs in a measure that is NOT the start of a system.

If Finale is automatically generating the cancel elements, then I would recommend that they be generated for ALL key signature changes, because when music can be re-flowed, a key signature change that used to be at the start of a system may well no longer be at the start of a system. The user's preference for how to cancel that key signature should be expressed in the MusicXML document in either case.

I would imagine that most applications would ignore the cancel data if that key signature change did happen at the start of a system when rendered, or the app might choose to apply the cancel parameters to how it drew the courtesy key signature for that key change at the end of the previous system.

(2) What is default behavior for key signature cancellation if no cancel element is specified in a traditional-key element? There is a default given for the cancel-location attribute in the cancel element, which I assume means what the cancel location should be if no cancel-location element is present. What is the equivalent default for <cancel> itself? It seems there should be a default behavior. If no cancel element is present, does the default for cancel-location still apply to whatever default the app assumes for cancel behavior?


(3) I note that the XSD documentation for <key-octave> states in part:

"If the cancel attribute is set to yes, then this number refers to an element specified by the cancel element."

Since the key-octave element can be used with both traditional and non-traditional key signatures, but the cancel element is only used with traditional key signatures, the documentation above and/or the XSD definition should somehow restrict its usage to traditional keys. Perhaps:

"If the cancel attribute is set to yes, then this number refers to an element specified by the cancel element. The cancel element cannot be set to yes if the key element it is embedded in is a traditional key."

I'll package this one as a W3C comment as well.

--Evan
Evan Brooks
 
Posts: 46
Joined: March, 2014
Reputation: 0

Re: cancel element

Postby Michael Good » Mon Mar 28, 2016 2:33 pm

Hi Evan,

Key signature cancellations are handled in Finale via Document Options | Key Signatures - specifically the "Cancel Outgoing Key Signature" option. Cancellations are exported at system breaks just as they do in mid-system, though you may not see it in Finale if the "Display Courtesy Key Signature at End of Staff System" option is unchecked.

If the cancel element isn't present, the cancellation should not appear. That may not always be feasible, though, so an application may have to do the best it can.

Thanks for filing the documentation issue. That should be something straightforward to fix for MusicXML 3.1.
Michael Good
VP of MusicXML Technologies
MakeMusic, Inc.
User avatar
Michael Good
 
Posts: 2197
Joined: March, 2014
Reputation: 0

Re: cancel element

Postby Evan Brooks » Tue Mar 29, 2016 12:48 am

Thanks, Michael.

What I see is that the "Cancel Outgoing Key Signature" box is unchecked, but a change in key in mid-system from 3 sharps (F# minor) to 0 sharps (A minor) shows three canceling naturals in the first bar of A minor, and the cancel element is in the MusicXML export as well.

I know that a lot of systems default to only showing canceling naturals when changing to C major/A minor. Is Finale doing this in spite of the user document preference? I'm not finding the place in the Finale documentation where it talks about this, but I would expect that it would have to override the document preference in this case or the music would read incorrectly. Do I have this right?

--Evan
Evan Brooks
 
Posts: 46
Joined: March, 2014
Reputation: 0

Re: cancel element

Postby Michael Good » Tue Mar 29, 2016 9:47 am

Yes, this happens automatically which is what you nearly always want. If you didn't cancel the outgoing key signature when going to C major or A minor, how could you tell the key signature changed?
Michael Good
VP of MusicXML Technologies
MakeMusic, Inc.
User avatar
Michael Good
 
Posts: 2197
Joined: March, 2014
Reputation: 0

Re: cancel element

Postby Evan Brooks » Tue Mar 29, 2016 2:22 pm

Thanks, Michael.

If I un-check Display Courtesy Key Signature at End of Staff System, but check Cancel Outgoing Key Signature, what I notice is that cancellation naturals appear on all key signatures that you would expect, except if the measure is the start of a system. In that case, there are no cancellation naturals.

However, the MusicXML output issues a cancel element in the key element for ALL of the key signatures that need canceling, INCLUDING the ones at the start of systems.

In fact, if I check Cancel Outgoing Key Signature, there is no difference in the MusicXML output between checking or un-checking Display Courtesy Key Signature at End of Staff System. In either case, all key elements that could use a cancel element are given one.

I take this to mean that Finale considers cancellation itself to be an exportable quality, but whether courtesy key signatures are drawn at the ends of systems is not an exportable quality.

I also take this to mean that Finale will never put cancellation naturals in the first measure of a system, even if the user requests them and they are warranted due to the key signature in the previous measure.

Is my thinking right here, or is something amiss with either Finale or its MusicXML export in this regard?

And lastly, the cancel element provides for a location attribute. How does one specify this location in Finale?

--Evan
Evan Brooks
 
Posts: 46
Joined: March, 2014
Reputation: 0

Re: cancel element

Postby Michael Good » Tue Mar 29, 2016 7:53 pm

Not handling the "Display Courtesy Key Signature at End of Staff System" option is an oversight in the MusicXML export code. I have added it to our list of possible things to fix in the future. Finale doesn't have a built-in way to support the location attribute of the cancel element.
Michael Good
VP of MusicXML Technologies
MakeMusic, Inc.
User avatar
Michael Good
 
Posts: 2197
Joined: March, 2014
Reputation: 0

Re: cancel element

Postby Evan Brooks » Wed Mar 30, 2016 1:52 pm

Hi Michael,

I'd still like to clarify the issues:

(1) Is it Finale's intent to never display cancellation naturals on the key signature in measures at the start of systems, even if the MusicXML it generates indicates a cancel element in those key signatures?

(2) What would the expected (when fixed) MusicXML output and desired app behavior look like for the 4 possible conditions that can happen when a key change occurs at a system start? I'll give you my takes on them below - please correct any that are wrong:

Scenario: Measure 4 is the last measure in a system, has key (fifths = 5), Measure 5 is the first measure in the next system, has key (fifths = -2)

Case 1:
Cancel Outgoing Key Signature = TRUE
Display Courtesy Key Signature at End of Staff System = TRUE

Measure 4:
(at end of Measure - indicates a canceling courtesy key signature at system end)
<key>
<cancel>5</cancel>
<fifths>-2</fifths>
</key>
Measure 5:
(at start of Measure - indicates new key signature only, cancel has already been done)
<key>
<fifths>-2</fifths>
</key>

In Case 1, the reading app can see that the engraver wanted a cancellation and courtesy key signature at the end of Measure 4, and since it was done there, the cancellation did not need to be repeated at the start of Measure 5.


Case 2:
Cancel Outgoing Key Signature = TRUE
Display Courtesy Key Signature at End of Staff System = FALSE

Measure 4:
(no information about new key signature or cancellation here)
Measure 5:
(at start of Measure - indicates new key signature only, cancel requested)
<key>
<cancel>5</cancel>
<fifths>-2</fifths>
</key>

In Case 2, if the reader app as a rule does not put cancellation naturals in the first measure of a system, if would ignore the cancel element in Measure 5, unless the location attribute of the cancel element specified that the cancellation naturals were to occur in the previous measure.


Case 3:
Cancel Outgoing Key Signature = FALSE
Display Courtesy Key Signature at End of Staff System = TRUE

Measure 4:
(at end of Measure - indicates a courtesy key signature at system end)
<key>
<fifths>-2</fifths>
</key>
Measure 5:
(at start of Measure - indicates new key signature only)
<key>
<fifths>-2</fifths>
</key>

In Case 3, as in Case 1, we use redundant key elements in both Measure 4 and 5. The key element at the end of Measure 4 represents a courtesy key signature only. The key element at the start of Measure 5 represents the actual key signature change. Any reading app could figure this out and eliminate the courtesy key signature in Measure 4 if Measure 4 was no longer at the end of a system (due to editing or re-flowing of the music).


Case 4:
Cancel Outgoing Key Signature = FALSE
Display Courtesy Key Signature at End of Staff System = FALSE

Measure 4:
(no information about new key signature or cancellation here)
Measure 5:
(at start of Measure - indicates new key signature only)
<key>
<fifths>-2</fifths>
</key>

In Case 4, no cancellation or courtesy key signature exists. If the reader re-flowed the music, it would have to infer that the engraver originally did not want courtesy key signatures at system breaks. This inference breaks if Measure 4 was originally a mid-system measure, because it is unlikely that Finale would export any courtesy key signature for a mid-system key change.

Unfortunately, I don't see a good way around this. If Measures 4 and 5 are mid-system, you could put a courtesy key signature at the end of Measure 4 in order to impart that the user wants that courtesy key signature there, but only if Measure 4 comes at a system end (due to reflowing). However, you are also inadvertently saying that you also want the courtesy key signature there even if Measure 4 is NOT at a system end.

One could reasonably argue that no one would draw a mid-system key change in the previous measure, so this "signaling mechanism" might be fine.

However, it is clear that in a world where music can be reflowed, it is not possible to unambiguously specify a global preference such as "Display Courtesy Key Signature at End of Staff System" by embedding literal key elements to match a particular rendering of the music.

(3) Perhaps we need to consider the concept of global "preferences" in a MusicXML file that would be (in this case) the equivalent of the two user preferences we are examine. Then, the MusicXML itself could just have normal key elements at the start of the actual measures they occur in, and the reading app could determine, based on the global "preferences", where and how to draw courtesy key signatures and cancellation naturals.

What do you think about this type of a solution?

--Evan
Evan Brooks
 
Posts: 46
Joined: March, 2014
Reputation: 0

Who is online

Users browsing this forum: No registered users and 2 guests

cron