Many/most score markings removed in measures following a new time signature

• Jan 19, 2014 - 20:22
Type
Functional
Severity
S4 - Minor
Status
closed
Project

This is a pretty infuriating bug - if you change the time signature in an early part of the score, many of the features later in the score are removed. To wit:

1. create a score in 4/4 time
2. add a text box marking measure 4
3. add repeat bar lines around measures 5 & 6 |: :|
4. change the time signature in bar 2 to 2/4

Expected behavior:

- the text marking measure 4 remains at its same beat location even though the measures were subdivided (it would now be measure 6)
- the repeat should stay at it's beat locations now spanning measures 8-11 in 2/4 time

The actual behavior is that the text and two repeat bar lines disappear entirely.

In my case, I only wanted two bars of 2/4 time (I missed it when originally creating the score), so I tried these steps:

1. create a score in 4/4 time
2. add a text box marking measure 4
3. add repeat bar lines around measures 5 & 6 |: :|
3.1. place a 4/4 time signature on bar 4 to "protect" it
4. change the time signature in bar 2 to 2/4

I expected step 3.1 above to "protect" the time signature from bar 4 forward and have the 8 beats in bars 2-3 converted to four bars of 2/4 time with 4/4 time resuming in bar 4. Instead, just placing the 4/4 time signature on bar 4 removed the text block and repeat signs.

Needless to say, on a large, nearly complete score, it is a bummer to see all of your hard work removed when you tweak the time signature in an earlier measure.


Comments

As you may be aware, the current version of MuseScore doesn't reflow music at all when you - everything stays in its current measure. Meaning if you change to a shorter time signature, you lose beats in every measure, and if you change to a longer one, rests are inserted. So having the music reflow at all is an improvement. But it's inevitable some things will be lost. Consider, changing from 4/4 to 3/4, the old barlines won't even exist any more. So recreating repeats will be impossible in the general case.

When I did a test just now, it seems note and anything attached to them (like articulations and slurs) are retained in the reflowing, but anything attached to the measure or to arbitrary tick positions is lost (like text or bar line styles). Clef changes are rewritten correctly, key signature changes not. While I'm sure some headway can be made - particularly with text - I think you need to lower your expectations a bit here. Changing time signatures so late in the game that you've already added text and repeat bars is probably always going to be problematic in some way.

Thanks Marc. I understand that this may be technically challenging, but this is the sort of limitation that could really make the product unusable for serious work.

From a user perspective, my expectation was that the notes, annotations and such were aligned to a specific beat. I expected that changing the time signature would cause all subsequent objects to retain their numeric beat offset and land wherever that was in the new bar line system.

I spent some time thinking about this and how I expected it to work and I see this is very complicated when you add in time signatures that do not share bar line boundaries. However, I think something that may help with all this is to discover the user's intent up-front and act accordingly.

Please bear with the length of this, but I think this may help.

What if we asked user how many bars of time they wish to modify and how to execute the retiming process. With this information, the program could do something really smart and avoid data loss issues. For example:

1. 100 measure score in 4/4 time
2. drop a 7/8 time signature on bar 3 (this said bar 2 before, that was wrong)
3. dialog appears:

New Time Signature (7/8)
(*) Apply for __2__ measures
( ) Apply to end

Retiming behavior:
(*) From beginning
( ) Each bar

RESULT: using the settings above, I'm creating 2 bars of 7/8 time and instructing the app to retime from the beginning of the selection. So, in this case, I'd expect to have:

4/4 bar1 | bar 2 | 7/8 bar3 | bar4 | 1/4 bar5 | 4/4 bar6-101 ||

The "from beginning" retiming behavior basically says to drop all the bar lines and resubdivide from the start of the new time signature. Using the principle of never losing the users data, we create a single 1/4 "fixup" bar5 to hold whatever was left over in the process and to retain the 4/4 bar line starting at bar 6 (which in this case would be the old bar5 in our 100 measure 4/4 score). All of the notes, annotations, bar lines, etc. from the old measure 5-100 would now appear in bars 6-101. Viola!

The user can delete the fixup bar after moving anything out of it that they want to retain.

Another example:

New Time Signature (7/8)
(*) Apply for __2__ measures
( ) Apply to end

Retiming behavior:
( ) From beginning
(*) Each bar

RESULT: using the settings above, I'm creating 2 bars of 7/8 time and instructing the app to do this one bar at a time. So, in this case, I'd expect to have:

4/4 bar1 | bar 2 | 7/8 bar3 | 1/8 bar4 | 7/8 bar5 | 1/8 bar6 | 4/4 bar7-102 ||

So here we've retimed each bar and created a leftover measure for the straggling 1/8 note in each bar and have preserved the downbeat in each 7/8 bar.

However, having a bunch of 1/8 measures all over the score may create another mess to clean up, so how about one final tweak to the prompt:

New Time Signature (7/8)
(*) Apply for __2__ measures
( ) Apply to end

Retiming behavior:
(*) Each bar
( ) From beginning

Treatment of leftover beats:
( ) Create fixup measure
(*) Delete (WARNING : orphaned notes will be lost, annotations will go to nearest beat)

With the "leftover" options, we can suppress the creation of these "fixup" measures and just delete the straggling beats. I think notes/rests would go away but it would be great if text annotations would move to the nearest bar line so they were not lost.

The result with these settings:

4/4 bar1 | bar 2 | 7/8 bar3 | bar4 | 4/4 bar5-100 ||

We still have 100 bars and the downbeat of bar3 and bar4 are the same as when we started. The app removed a single 1/8 note from the end of each bar3 and bar4 and, hopefully, preserved any text annotations by moving them to the next nearest similar object.

I think this works well with time signatures that add beats as well, think of 4/4 -> 9/8. The "each bar" retiming would add an extra 1/8 note to the end of each measure. The "from beginning" would pull notes forward into the bar to fill the extra space.

I think long term, your suggestions make a lot of sense. However, given that 2.0 is basically feature-frozen at this point, I'm focusing more on just getting it work as best as possible given the current design. It's definitely a bug that annotations (text, etc) don't make it - also, you may have noticed, spanners (hairpins, etc) are positioned incorrectly, key signature messed up, etc. I think most of that is fixable and I'm working on it right now.

But given that a number of things are attached to measures or barlines and not specific beat positions, it's kind of inevitable that these things will be lost - or at best, placed "incorrectly" since the correct place no longer exists. It's the same with copy & paste and for the same reasons. These limitations are inherent in the process and don't make MuseScore unsuitable for serious work - 1.3 was already quite suitable, and 2.0 is already better and will be better still when the fixable bugs are fixed. But indeed, it could be better at some point in the future.

BTW, see also #13582: Tempo Text disappears after changing time signature and #17188: Changing time signature removes repeats and voltas.

Also, note there is a semi-effective workaround for some of these sorts of bugs: select the region you are about to rewrite and do a cut, then make the time signature change, then paste.

Status (old) active patch (ready to commit)

I have fixed a good deal of this. Text markings (including dynamics, chord symbols, D.S. al Coda, etc) now work correctly, as do spanners (hairpins, voltas, etc). Key signatures still have some issues (mostly cleared up on reload), and barline styles (including repeat bars) still don't carry over even in the cases where they happen to align.

https://github.com/musescore/MuseScore/pull/658

That's great news - thanks for the quick response and fixes!

I keep forgetting about the "cut, change, paste" workaround.

I tried this on a score with some time signature issues and it worked, but it was a bit of a challenge. I had fretboard symbols that did not copy out with the measures and, as you noted, bar line repeats were lost.

I was able to make it work but hopefully some of your changes will help make it even better. Looking forward to the next build.

Thanks.

I withdrew the patch because the barline thing was bugging me, also I discovered a problem with chord symbols not placed over notes or rests. I should have those fixed soon.

Status (old) active patch (ready to commit)

I have it working about as well as I can - including mid-measure chord changes, repeat barlines when they happen to align, and no hang on measure repeat (they turn back into rests, which is all they actually are internally anyhow.

BTW, copy/paste should have preserved fretboard diagrams - does for me. But they too should work with my fix.

Re: fretboard diagrams - it looks like the "cut" operation does not remove them from the screen. They appear to be on the pasteboard but it was confusing since they remained visible after cutting them. That may be another bug altogether.

Ah yes. It's "maybe" a bug. In 1.3, cut removed only the notes, not text, chords, etc. This was seen as a feature of sorts, because it enabled one to effectively copy chords only by copying the whole passage then deleting the notes - thus allowing you to enter new chords over the original chords in another part. Now that it possible to copy chords directly without copying the notes, it's an open question as to whether this "feature" has outlived its usefulness.

I'm kind of ambivalent on this. A few weeks ago I fixed a bug in this area where some annotations were being preserved on delete but others not. I could gone either way in terms of whether to fix this by preserving everything or nothing. I ended up preserving everything for consistency with 1.3. And I must admit, I *do* still find it useful to be able to remove notes while leaving chords, and it's easy enough to cleanup these leftovers separately when you don't want them. Still, I could be convinced otherwise.

If there is to be further discussion of this topic, it should probably go to the Technology Preview forum to reach a wider audience.

This is so much better! Thanks for tackling this!

I'd be happy to kick around ideas for the panel above if / when that comes into play.

Thanks again!