Don't eliminate layout elements upon some cases of time signature change

• Sep 22, 2014 - 15:24
Type
Functional
Frequency
Many
Severity
S5 - Suggestion
Status
active
Regression
No
Workaround
Yes
Project

See the score attached to http://musescore.org/en/node/34041#comment-144441, delete the time sig in measure 1.
All system breaks up to the next timesig get deleted

1fb21eb, Windows 7 Enterprise, 64bit


Comments

OK, what is the timesig once it is deleted from score? It changes ro 4/4. If it was 4/4 before, or any 'compatible' version, common or cut time, there is no need at all to delete the system breaks. Same for changes between these 'compatible' (mathmatical identical) types, not much reason for shorter types, only longer ones may not fit anymore

Yes, I'm sure it would be possible to detect changes that are not actually significant and then avoid calling the rewrite code (which is where the breaks are removed, I believe).

For most people, though, I think it's going to be a bigger issue that time signature *changes* delete breaks than the fact that time signature *non-changes* do. So if we're to come up with special case code, I'd rather it address the problems more people are likely to see.

Status by design active

Ir should not do this if the time signatures are mathmatically identical, i.e. don't lead to different measure boundaries. Cut time is 2/2, common time is 4/4, so there's no need at all to loose the system breaks, as all measures stay the same length.

To my understanding, system break are always at the and of a measure, am I correct?
In that case Ir should not do this if the time signatures are mathmatically identical a solution could be: Remove system break which are not at the end of a measure anymore (or even move them the the end of a measure, although I'm not sure that's a good thing to do).

Title deleting a timesig destroys layout (deletes system breaks) Don't eliminate layout elements upon some cases of time signature change
Severity S4 - Minor S5 - Suggestion

That'd push it even further than just leave them at mathmatical identcal time sigs, like a system with 3 measures of 4/4 are the same as 4 measures of 3/4. May or may not fit the same page width.

In reply to by njvdberg

If the user really wants to delete these breaks, he can do it quite easily (select all similar blablabla...)
If he does NOT want to delete them and MuseScore did it for him, there is no way to make them come back other than reputting them one by one.
So, in case of hesitation (should MuseScore delete or not), I would rather say not.

Workaround No Yes

In cases where the duration of the measures isn't actually changing (i.e. 2/2 to 4/4, 3/4 to 6/8), a workaround is to select the time signature at the left of the staff, right-click (or two-finger tap, or whatever input brings up your contextual menu) —> Time Signature Properties, then change the "Text" setting in the Appearance area at the upper right of the dialogue box that appears. Don't change anything else. That should change the time signature marking to whatever you want it to be without disrupting any of your formatting. You'll have to do this individually for each staff, because it's purely cosmetic and staff-specific.

If you want to insert a change from one compatible time signature to another, just drop an extra instance of the current time signature where you want the change to be, then (cosmetically) alter that instance.

Closely related but not quite the same: if you want to change a time signature for a certain passage, but don't want the change to disrupt formatting beyond a certain point, create a new instance of the current time signature at the point beyond which you don't want any disruption to occur. Do this before you insert the new/different time signature. Then insert the new/different time signature. This way notes won't get pushed along and split by barlines etc. Instead, Muse Score will create an extra measure with some rests in it as a buffer, re-syncing the barlines to the later, unchanged content.

It seems like this issue has come up in several threads. I don't want to try to hunt them all down, but I hope this solution propagates to them, or they end up leading here.