No time signature after section break

• Nov 26, 2018 - 12:41
Reported version
3.0
Priority
P1 - High
Type
Functional
Frequency
Few
Severity
S3 - Major
Reproducibility
Always
Status
active
Regression
No
Workaround
Yes
Project

After a section break there should be a time signature
no-clef-after-section-break.png

Attachment Size
no-clef-after-section-break.mscz 2.55 KB

Comments

Workaround No Yes

Workaround - just add it again. Actually, I'm not even 100% sure this isn't by design - I think the main purpose was to suppress courtesy signatures, not to force new ones. ut I agree it seems to make sense. Might be some people depending on current behavior, though?

In 2.x I often found behavior around sections breaks depended on the order I did them (add key change then add section break vs vice versa). But at least if I do add a time signature after adding the section break, I don't get a courtesy (true for both 2.3.2 and 3.0).

I'm more than happy to see this fixed, but given how long it's been the case and how easy the workaround is, maybe it's not as critical as some others...

If you add a timesig all following measures are reset to the timesig. This will destroy upbeats as well as modified measure lengths.

Maybe the XML import set this additional timesigs in MS2? I cannot remember this as issue there.

Priority P0 - Critical P1 - High

True, Still, one would normally be doing this before adding content to those measures. Anyhow, given this is same as 2.3.2 and some people might actually depend on this, I'm personally uncomfortable with a rush decision on fixing.

True, but I'm not understanding your point. Are you saying MusicXML is somehow relevant here? You have a sample MusicXML file that contains an element we are interpreting as a section break but not using the same semantics as defined in the spec?

Lets take this reduced example:
timesig-after-sectionbreak.mscz.png

  1. Export as pdf
  2. Scan in Capella and save as musicxml (attached)
  3. Import in MuseScore. Please try to insert the missing time signature at the start of the song...
    If you a) insert the time signature, all measures are reset to 4 / 4 which is a real mess.
    If you b) insert a section break at the end of the intro (which is correct anyway, to avoid courtesy clefs, keys or timesigs) it does not insert the timesig.
    timesig-after-sectionbreak.capellaxml.png

I see, so inserting the 4/4 at the beginning of the "Song" eliminates the pickup. So, first insert on the first full measure, thus "protecting" the content from there, then add it to the first measure, then correct the actual duration, then delete the extra time signature. Convulted yes, but anyhow, that's how to deal with this particular corner case in both 2.x and 3.0 for now.

Sorry, but your suggestion does not work. Did you really try that? If I insert the 4/4 at the first full measure, the shortened measures in the voltas get corrupted as well as the subsequent pickup measure thereafter.

And no, this is not a corner case. Many songs have such a structure.

Yes, I did try the suggestion, I just didn't look far enough ahead to see that there were problems further down.

There are several respects in which the scenario you describe is a corner. One is that what you are trying to do is actually incorrect notation - it's not normally correct to repeat the time signature after the intro to a song. Not sure why you're trying to do that, but the standard is not to. Only if it's a different song. And in that case, you almost certainly would not be importing both songs from a single MusicXML file, as that isn't really supported to begin with.

In normal use, section breaks would be added as you enter your music, left to right, start to finish, so there would be no issue simply adding the time signature then, before you've entered notes or done any other customization to the measures that follow.

Anyhow, I'm agreeing it would be worth revisiting the original intent of section breaks and consider extending the behavior to support the ability to display time signatures. That's why I didn't simply close this as "by design" even though it technically is. But if we do extend the behavior, it would be important to do so in a way that doesn't break compatibility for people relying on the current behavior - eg, people using section breaks as separators within worksheets and other situations where repeating the time signature is not desired.

I think the best way forward is to add a new property to the section break to control whether you want to generate time signatures or not, much as we already have properties to control the length of the playback pause, whether you want measure numbers to reset, and whether you want long instrument names to be used. This could be done in conjunction with moving these properties form the dialog where they are now to the Inspector. I think ideally the default for newly-added section breaks should be to have the time signature option on, but for compatibility, scores that don't have this set explicitly should continue to have it off. This could be done by having the actual property default to off but having it explicitly set to on in the palette.

While my PR solved my own issue with my current project it does not seams to be a generic solution.

  1. If there is no time signature in the first measure of the first movement - does it really make sense to generate one at the start of the second movement? Even though I updated my PR to display the time signature only when there is a time signature in the first measure of the score, what is if there are three movements and only the second has a local time signature..?

  2. Maybe a setting in Style > Page > "Create time signature after section break" whould be a generic solution?

  3. In MS2 after a MusicXML import, behind a section break a time signature got inserted and displayed. This is not the case in MS3 anymore. Is the real issue the missing time signature in the MusicXML import? But at the other hand there is this similar request in #284848 which does not seams to be related to MusicXML.

Any opinions?

I don't have strong feelings. I am uneasy about changing behavior that has worked a given way for years with few complaints, and adding the new time signature manually is not difficult. But indeed, in the most common cases, you do want to see it, so if it's equally simple to remove the generated one in your PR, then it's fine with me in principle. Do you handle existing scores OK? That is, if they have a section break but the user did not choose to add a time signature, will they continue to look that way, or will the user be forced to remove it now? Is this the case both for scores imported from 2.x and for score created in 3.0?

In reply to by Marc Sabatella

  1. Existing scores will get a new time signatures. Thats the initial purpose of the fix.
  2. You cannot remove the time signature, because it will then be regenerated again. You have to make it invisible.
  3. There is no difference in MS2, MS3 or MusicXML files.

Because of your points, I suggested the new setting which would keep the existing behaviour if not checked.

I do not share your opinion regarding the simplicity of the insertion of a new time signature. As demonstrated above, when you add a time signature it will reset any following measures with deviating length. This is not manageable in existing scores. At the other hand, would it be a possible fix if there is a special mode of inserting a time signature which makes no changes to any measure length but just insert the signature?

I'm not sure why you would have so many existing scores that are missing these time signatures - again, in normal usage they have been added when you added the section breaks? I mentioned that above and am still not completely understanding how you got yourself into this mess. Something having to do with MusicXML import I guess? Maybe it makes more sense to take a step back and see if there isn't something that could be done at that level?

Anyhow, it's a deal breaker if time signatures after section breaks can't be controlled individually. Hiding them leaves the space behind, and a style setting is all-or-nothing. There needs to be a way to specify this per section break, maybe in the section break properties.

In reply to by Marc Sabatella

Yes, my problem originates from MusicXML import. And I agree (and have already suggested) that it should (also) be fixed there. But leave that aside and let just imagine a single score in which the time signature is missing because it slipped through. You simply can not enter it if your score contains shorted or extended measures as for example a repeat and subsequent upbeat. This will destroy the structure of the score. And that does not neccessarily must be behind a section break. Hence the "insert mode" suggestion.

Btw, you can set a negative Leading space to avoid the space of a hidden element.

Finally: A section break property is a better idea then a global option. Thank you!

My point is that in normal use, you won't have anything after this point that would be messed up, because the normal use would be to enter this before entering the other stuff. So it's really an extremely rare use case where this is a problem. That's why it is absolutely crucial not to break the common things people do today that work well. I think existing scores need to not be affected by default, but it should be easy to take advantage of the new capability - like, selecting all section breaks and then applying the proposed new setting manually. This is probably also the time, then, to move section break properties to the Inspector, which will facilitate that as well as improve general usability.

So, to summarize:

  • section breaks should have a property to control the appearance of timesigs after
  • existing scores with section breaks should have this off for compatibility
  • it should be easy to select section breaks and turn them on via the Inspector
  • newly added section breaks should behave the same whether added to old or new scores
  • I don't care which way these newly added breaks go, sounds like there is some consensus for setting the new property to "on"

Is this a real issue. Or is it a Musescore => pdf > xml => Musescore issue?

I note that the example involved creating a pdf, converting to xml and then opening that. If I take the example timesig-after-sectionbreak_0.mscz and export as musicxml and then open it the only difference I see is that there is a system break rather than a section break. A time signature is shown at the start of the second system.

If I look in the example xml file I see no second time signature.

Is the real problem that the pdf => xml didn't find that second time signature?

The problem of a new time signature screwing up bar lengths only arises if those modified bar lengths are from an import and if what you are importing does not contain that information, well bad luck! If you are entering rather than importing music you can add a time signature and key signature when you start the new section after the section break. Indeed, you probably want a new (i.e. different) time and key signature for a new section most times.

They do indeed, so it's only the time signature.
Since vertical and text frames implies a kind of section break, maybe extend these two frame with the same option as the section break. Also the horizontal frame should have to option to draw a time signature too (now it only optionally creates a system header which doesn't include the time signature).

In reply to by njvdberg

But my point is that if you start with an empty score and start entering music, when you get to a section break, the chances are you will not want the same time signature or key signature after the break. You are starting a new section. If time and key signatures are automatically added you more often than not end up changing them.

The problem described seemed to be that no time signature was imported with an xml file that didn't have a time signature to import. Should we invent a time signature in such a case, or should we honour what the imported xml actually says?

Since vertical and text frames implies a kind of section break, maybe extend these two frame with the same option as the section break no, not at all. Apply a section break to those frames if you want them to mark a section break.
Hmm, maybe let them have such a property, but off by default, on by default only for a true section break

@SteveBlower When it come to imported XML files, that file should be honoured. For the other use case, a section break is used to indicate a new section indeed. And often the time and/or key signature will change. But not always, I have seen examples of that. Now the key signature is created after a section break, but no time signature. This is slightly inconsistent and, if the next section has the same time signature, it might be forgotten.

In reply to by njvdberg

@njvdberg The influence of time and key signatures are different and therefore it is reasonable that the behaviour is different The time signature specifies the division of the following bars; changing it changes the structure of the music. There is a big adverse impact on layout and rhythm groupings if you enter notes in what is currently 4/4 and then later change the time signature to 6/8 say, but entering notes following a G maj key signature and then changing that to Db maj is handled quite gracefully.

I think we agree that you rarely don't need a time signature after the section break, but Musescore can't know which time signature is needed or indeed whether any time signature is needed in a particular case. It seems just as reasonable (and easier) to have "no time signature" as the default as it is to have "repeat the previous time signature" or "guess a time signature". The user will always to have to make the decision about what is needed and most probably change what is provided as a default. Is it worth the effort of implementing a new default when that is no more likely to be useful? You argue that it is to avoid a perceived inconsistency in behaviour, but that inconsistency in behaviour is between what are necessarily quite differently behaving elements.

It is a similar but not so important consideration for key signatures. As I noted changing the key signature "after the event" causes less upheaval. And in this case the default of "continue with the last key signature" is as good as any other default.

MuseScore does know exactly what time signature is needed (in the 1st measure after a section break): either the one explicitly set at section start, or the one from the previous (end of the) section. Same as for clef and key signature, as well as for long and short instrument name etc.
No guess work involved at all, it is not reasonable at all to have none (unless explicitly disabled in the section break's properties)

It seems just as reasonable (and easier) to have "no time signature" as the default
There is always a time signature so the question is, do we want to show it after a section break.

If you want the new section to start with anew and different timesig that's what you need to do indeed, in any case.
The problem at hand here is that if there is no change in time sig between those sections, the new section doesn't show it.
The workaround to add that same time signature again is all but that: a workaround.

@Tobik The example (if we are talking about the same one) seems to be created from an xml file that doesn't contain the time signature after the section break. You said the steps to create it were

1. Export as pdf
2. Scan in Capella and save as musicxml (attached)
3. Import in MuseScore.

As I said earlier, if I open the example timesig-after-sectionbreak_0.mscz and export from Musescore to musicxml and then open that, the time signature shows up when it is opened. However, I couldn't see a second time signature in timesig-after-sectionbreak.capella_0.xml (unless I was looking in the wrong place!) which presumably is why it doesn't show up when you open it in Musescore. It seems that the time signature got lost in step 1 or 2.

The problem you describe shouldn't happen when you are entering notes rather than importing a (malformed) musicxml file. You just need to enter the time signature and adjust the pick up and ending bar lengths yourself as you would even if section breaks weren't involved.

After a section break a time signature is not shown. This is a bug (and the bug this issue here is all about) and needs to get fixed.
Whether or not Key signatures (and time signatures and clefs) could get disabled on a section break via its properties would be a missing feature, probably better handled in a separate issue as a suggestion.

MusicXML ex- and import has got nothing to do with this at all, section breaks don't get exported in the first place, this might be a bug, but more likely is a MusicXML design limitation. MuseScore exports them as a system break though. Capella apprently too:

           <print new-system="yes">

MuseScore 2.3.2 and 3.4.2 behave identical on importing that xml; they show a system break, not a section break. And after a system break indeed a time signature is not shown, that is by design and 100% correct behavoir.
The assertion In MS2 after a MusicXML import, behind a section break a time signature got inserted and displayed. This is not the case in MS3 anymore. is just plain wrong. Again, that section break gets imported as a system break, entirely different thing.
One thing MuseScore MusicXML export should or could do though, is exporting that time signature as explicitly set for the first measure after that section break, so om import that section break still becomes a system break, but the next measure has the time signature set (along with measure number restarting at 1 and maybe disabling courtesy time- and key sigs, and -clefs, and long instrument names). This again is a different issue and should be filed as such, also as a suggestion I think, as it doesn't seem to be a bug. No filed as #305283: Improve MusicXML export of section breaks

There's another interesting bug (?) in that area: after a system break, a key sig change to the same key as before does not lead to a courtesy key sig, but a time sig change to the same time sig as before does lead to such a courtesy time sig, so there is some inconsistency.
Also there is a style setting (Format > Style > Page) to create a clef and a key sig for every system, but no such setting for a time sig.