Fix #15726 (Barlines & Line Breaks): Some elements are lost when changing time signature #26256

pacebes · 2025-01-27T18:53:03Z

Resolves: #15726 (Barlines && Line Breaks)

(Updated) This PR keeps as much Barlines and Line and page Breaks as possible when changing time signature

I signed the CLA
The title of the PR describes the problem it addresses
Each commit's message describes its purpose and effects, and references the issue it resolves
If changes are extensive, there is a sequence of easily reviewable commits
The code in the PR follows the coding rules
There are no unnecessary changes
The code compiles and runs on my machine, preferably after each commit individually
I created a unit test or vtest to verify the changes I made (if applicable)

pacebes · 2025-01-27T18:59:49Z

(Updated)This PR try to keep as many barlines as possible. Obviously, the policy can be modified as to which elements and how they should be kept.
I am providing a couple of Scores to test the PR with duplicate Scores to facilitate testing and decision making about how to change this PR: Score_15726_BL_tests.zip

pacebes · 2025-01-28T06:50:56Z

Hi @cbjeukendrup

I have created a PR to keep BarLines, Marks and Jumps. Now a test fails, but I think it's related with the new expected behavior. I mean the error is:

2025-01-27T23:35:11.5771161Z 12: --- /home/runner/work/MuseScore/MuseScore/src/engraving/tests/timesig_data/timesig-03-ref.mscx	2025-01-27 22:57:29.590649477 +0000
2025-01-27T23:35:11.5771830Z 12: +++ timesig-03.mscx	2025-01-27 23:35:11.500019377 +0000
2025-01-27T23:35:11.5772262Z 12: @@ -278,7 +278,11 @@
2025-01-27T23:35:11.5772564Z 12:            </voice>
2025-01-27T23:35:11.5772858Z 12:          </Measure>
2025-01-27T23:35:11.5773137Z 12:        <Measure>
2025-01-27T23:35:11.5773416Z 12: +        <startRepeat/>
2025-01-27T23:35:11.5773637Z 12:          <voice>
2025-01-27T23:35:11.5773821Z 12: +          <BarLine>
2025-01-27T23:35:11.5774055Z 12: +            <subtype>start-repeat</subtype>
2025-01-27T23:35:11.5774330Z 12: +            </BarLine>
2025-01-27T23:35:11.5774534Z 12:            <Dynamic>
2025-01-27T23:35:11.5774765Z 12:              <subtype>p</subtype>
2025-01-27T23:35:11.5775024Z 12:              <velocity>49</velocity>
2025-01-27T23:35:11.5775269Z 12: @@ -429,6 +433,12 @@
2025-01-27T23:35:11.5775508Z 12:              <durationType>measure</durationType>
2025-01-27T23:35:11.5775802Z 12:              <duration>3/4</duration>
2025-01-27T23:35:11.5776057Z 12:              </Rest>
2025-01-27T23:35:11.5776263Z 12: +          <location>
2025-01-27T23:35:11.5776489Z 12: +            <fractions>-1/2</fractions>
2025-01-27T23:35:11.5776739Z 12: +            </location>
2025-01-27T23:35:11.5776949Z 12: +          <BarLine>
2025-01-27T23:35:11.5777173Z 12: +            <subtype>end-repeat</subtype>
2025-01-27T23:35:11.5777434Z 12: +            </BarLine>
2025-01-27T23:35:11.5777668Z 12:            </voice>
2025-01-27T23:35:11.5777862Z 12:          </Measure>
2025-01-27T23:35:11.5778049Z 12:        <Measure>
2025-01-27T23:35:11.5778643Z 12:    <diff -u /home/runner/work/MuseScore/MuseScore/src/engraving/tests/timesig_data/timesig-03-ref.mscx timesig-03.mscx failed, code: 1 
2025-01-27T23:35:11.5779348Z 12: ../src/engraving/tests/timesig_tests.cpp:109: Failure
2025-01-27T23:35:11.5779905Z 12: Value of: ScoreComp::saveCompareScore(score, u"timesig-03.mscx", TIMESIG_DATA_DIR + u"timesig-03-ref.mscx")

This error happens because we know keep BarLines. I mean

Original Score

Expected Score

Score output with this PR

Why does this happen?

We now keep the BarLines, so the output is different because it is now the expected behavior. We can't change it as long as we try to keep BarLines.

How should we proceed now?

pacebes · 2025-01-28T06:51:13Z

Hi @cbjeukendrup

I have created a PR to keep BarLines, Marks and Jumps. Now a test fails, but I think it's related with the new expected behavior. I mean the error is:

2025-01-27T23:35:11.5771161Z 12: --- /home/runner/work/MuseScore/MuseScore/src/engraving/tests/timesig_data/timesig-03-ref.mscx	2025-01-27 22:57:29.590649477 +0000
2025-01-27T23:35:11.5771830Z 12: +++ timesig-03.mscx	2025-01-27 23:35:11.500019377 +0000
2025-01-27T23:35:11.5772262Z 12: @@ -278,7 +278,11 @@
2025-01-27T23:35:11.5772564Z 12:            </voice>
2025-01-27T23:35:11.5772858Z 12:          </Measure>
2025-01-27T23:35:11.5773137Z 12:        <Measure>
2025-01-27T23:35:11.5773416Z 12: +        <startRepeat/>
2025-01-27T23:35:11.5773637Z 12:          <voice>
2025-01-27T23:35:11.5773821Z 12: +          <BarLine>
2025-01-27T23:35:11.5774055Z 12: +            <subtype>start-repeat</subtype>
2025-01-27T23:35:11.5774330Z 12: +            </BarLine>
2025-01-27T23:35:11.5774534Z 12:            <Dynamic>
2025-01-27T23:35:11.5774765Z 12:              <subtype>p</subtype>
2025-01-27T23:35:11.5775024Z 12:              <velocity>49</velocity>
2025-01-27T23:35:11.5775269Z 12: @@ -429,6 +433,12 @@
2025-01-27T23:35:11.5775508Z 12:              <durationType>measure</durationType>
2025-01-27T23:35:11.5775802Z 12:              <duration>3/4</duration>
2025-01-27T23:35:11.5776057Z 12:              </Rest>
2025-01-27T23:35:11.5776263Z 12: +          <location>
2025-01-27T23:35:11.5776489Z 12: +            <fractions>-1/2</fractions>
2025-01-27T23:35:11.5776739Z 12: +            </location>
2025-01-27T23:35:11.5776949Z 12: +          <BarLine>
2025-01-27T23:35:11.5777173Z 12: +            <subtype>end-repeat</subtype>
2025-01-27T23:35:11.5777434Z 12: +            </BarLine>
2025-01-27T23:35:11.5777668Z 12:            </voice>
2025-01-27T23:35:11.5777862Z 12:          </Measure>
2025-01-27T23:35:11.5778049Z 12:        <Measure>
2025-01-27T23:35:11.5778643Z 12:    <diff -u /home/runner/work/MuseScore/MuseScore/src/engraving/tests/timesig_data/timesig-03-ref.mscx timesig-03.mscx failed, code: 1 
2025-01-27T23:35:11.5779348Z 12: ../src/engraving/tests/timesig_tests.cpp:109: Failure
2025-01-27T23:35:11.5779905Z 12: Value of: ScoreComp::saveCompareScore(score, u"timesig-03.mscx", TIMESIG_DATA_DIR + u"timesig-03-ref.mscx")

This error happens because we know keep BarLines. I mean

Original Score

Expected Score

Score output with this PR

Why does this happen?

We now keep the BarLines, so the output is different because it is now the expected behavior. We can't change it as long as we try to keep BarLines.

How should we proceed now?

Jojo-Schmitz · 2025-01-30T08:16:17Z

In the unit tests I see lots of
21:37:22.338 | ERROR | main_thread | ChordList::read | Cannot open chord description: /styles/chords_std.xml
I though we had overcome those by running the tests from the install dir rather than the build dir? Do I misremember or did it break again?
With so many wrong error messages it is hard to not miss the tree in the forrest...

Jojo-Schmitz · 2025-01-30T08:25:04Z

Hi @cbjeukendrup

I have created a PR to keep BarLines, Marks and Jumps. Now a test fails, but I think it's related with the new expected behavior. I mean the error is:

2025-01-27T23:35:11.5771161Z 12: --- /home/runner/work/MuseScore/MuseScore/src/engraving/tests/timesig_data/timesig-03-ref.mscx	2025-01-27 22:57:29.590649477 +0000
2025-01-27T23:35:11.5771830Z 12: +++ timesig-03.mscx	2025-01-27 23:35:11.500019377 +0000
2025-01-27T23:35:11.5772262Z 12: @@ -278,7 +278,11 @@
2025-01-27T23:35:11.5772564Z 12:            </voice>
2025-01-27T23:35:11.5772858Z 12:          </Measure>
2025-01-27T23:35:11.5773137Z 12:        <Measure>
2025-01-27T23:35:11.5773416Z 12: +        <startRepeat/>
2025-01-27T23:35:11.5773637Z 12:          <voice>
2025-01-27T23:35:11.5773821Z 12: +          <BarLine>
2025-01-27T23:35:11.5774055Z 12: +            <subtype>start-repeat</subtype>
2025-01-27T23:35:11.5774330Z 12: +            </BarLine>
2025-01-27T23:35:11.5774534Z 12:            <Dynamic>
2025-01-27T23:35:11.5774765Z 12:              <subtype>p</subtype>
2025-01-27T23:35:11.5775024Z 12:              <velocity>49</velocity>
2025-01-27T23:35:11.5775269Z 12: @@ -429,6 +433,12 @@
2025-01-27T23:35:11.5775508Z 12:              <durationType>measure</durationType>
2025-01-27T23:35:11.5775802Z 12:              <duration>3/4</duration>
2025-01-27T23:35:11.5776057Z 12:              </Rest>
2025-01-27T23:35:11.5776263Z 12: +          <location>
2025-01-27T23:35:11.5776489Z 12: +            <fractions>-1/2</fractions>
2025-01-27T23:35:11.5776739Z 12: +            </location>
2025-01-27T23:35:11.5776949Z 12: +          <BarLine>
2025-01-27T23:35:11.5777173Z 12: +            <subtype>end-repeat</subtype>
2025-01-27T23:35:11.5777434Z 12: +            </BarLine>
2025-01-27T23:35:11.5777668Z 12:            </voice>
2025-01-27T23:35:11.5777862Z 12:          </Measure>
2025-01-27T23:35:11.5778049Z 12:        <Measure>
2025-01-27T23:35:11.5778643Z 12:    <diff -u /home/runner/work/MuseScore/MuseScore/src/engraving/tests/timesig_data/timesig-03-ref.mscx timesig-03.mscx failed, code: 1 
2025-01-27T23:35:11.5779348Z 12: ../src/engraving/tests/timesig_tests.cpp:109: Failure
2025-01-27T23:35:11.5779905Z 12: Value of: ScoreComp::saveCompareScore(score, u"timesig-03.mscx", TIMESIG_DATA_DIR + u"timesig-03-ref.mscx")

This error happens because we know keep BarLines. I mean

The first chunk of that diff looks correct to me (as does the start repeat in theScore output with this PR' image), I'd just adjust the test file.
The 2nd chunk though looks wrong, like a corrupt measure. What us a negative fraction supposed to mean? Why is the end reperat barline not falling on a measure boundary, but sits amids a measure, and without any chord or rest between it and the next barline?

pacebes · 2025-01-30T10:22:09Z

HI @Jojo-Schmitz . Thanks for your answer

The first chunk of that diff looks correct to me (as does the start repeat in theScore output with this PR' image), I'd just adjust the test file. The 2nd chunk though looks wrong, like a corrupt measure. What us a negative fraction supposed to mean? Why is the end reperat barline not falling on a measure boundary, but sits amids a measure, and without any chord or rest between it and the next barline?

I changed the behaviour to keep as much barlines as possible, keeping them in the middle of a Measure if it was the initial position (Fraction within the score). MuseScore allows that. I have just created from the scratch the following Score: Score_15726_test2ss.zip:

I haven't changed the time signature with this PR and you could also see a negative fraction:

          <location>
            <fractions>-13/16</fractions>
            </location>
          <BarLine>
            <subtype>heavy</subtype>
            <eid>lZ+ydJyREYG_aa3OXOBd+SL</eid>
            </BarLine>

Current PR version try always to keep as much barlines as possible when changing TS even if they are in the middle of the Measure. I don't know if this is the expected behavior or not. That's why I have included two scores with duplicated lines ( https://github.com/user-attachments/files/18563141/Score_15726_tests.zip ) to assist in deciding which BarLines should be kept (perhaps, as you suggest only the falling on the final measure boundary, or only the ones which were in the original measure boundary and also in the final measure boundary...). It is up to you. I would appreciate any hint about it

Jojo-Schmitz · 2025-01-30T10:29:52Z

It it adds/keems/moves a repeat barline mid-measure, it should at least create the appropriate chords/rests before and after, or split the measure at that spot (else the repeat barline won't play)
So I'd say the current behavoir is not wanted or expected.

pacebes · 2025-01-30T10:45:37Z

It it adds/keems/moves a repeat barline mid-measure, it should at least create the appropriate chords/rests before and after, or split the measure at that spot (else the repeat barline won't play) So I'd say the current behavoir is not wanted or expected.

There isn't a problem with chords because they were before and after the barline before changing the time signature. I agree about splitting rests. I will try to change the PR.

Anyway. The repeat barlines don't play right now when you create a Score whith them in the middle of a Measure. I have just create this one from the scratch (a different color per measure) and insert two repeat barlines within the second measure and they dont' "work" (not repeating the middle chords). It seems a "visual" thing:

So, again I'm not saying this is the expected behavior of the PR. I can change it.
I'll work on changing rests when a "middle" barline is within a rest.

pacebes · 2025-01-30T11:06:01Z

It it adds/keems/moves a repeat barline mid-measure, it should at least create the appropriate chords/rests before and after, or split the measure at that spot (else the repeat barline won't play) So I'd say the current behavoir is not wanted or expected.

Hello again @Jojo-Schmitz . I have seen that this is also an expected behavior with current version (not time signature change involved). I have recorded this video where I get the same behaviour:

Issue_17226_Example_middlebar.mp4

It seems that the rests isn't splitted ( Score_15726_test4.zip )

          <Rest>
            <eid>lPuinjuBF6M_MU9VUZkC2DE</eid>
            <durationType>measure</durationType>
            <duration>4/4</duration>
            </Rest>
          <location>
            <fractions>-3/4</fractions>
            </location>
          <BarLine>
            <subtype>start-repeat</subtype>
            <eid>/SPqExQb2RJ_9obf7y6E7GN</eid>
            </BarLine>

Therefore I think there isn't a problem with the PR itself. A remaining question could be if we should keep "middle" (on initial or final scores).. barlines...

pacebes · 2025-02-01T18:48:04Z

As mentioned in #15726 (comment) I have created a different PR (#26298) for Marks and Jumps and I have updated this PR to include only BarLines

BanjoJake · 2025-02-09T22:02:47Z

Hi, I'm confused about whether this is ready to be tested. I've been using 3.7 only, but would be happy to test 4.xx if that would be useful.
I see this:
Fix #15726 (Barlines): Some elements are lost when changing time signature #3030
(github.com/musescore/MuseScore/actions/runs/13091403937)
which contains this:
MU4_250321841_Win_26256_Fix #15726 (Barlines & Jumps & Marks)_ Some elements are lost when changing time signature
No rush, but I'm eager to test barlines when ready.

pacebes · 2025-02-11T09:27:01Z

Hi, I'm confused about whether this is ready to be tested. I've been using 3.7 only, but would be happy to test 4.xx if that would be useful. I see this: Fix #15726 (Barlines): Some elements are lost when changing time signature #3030 (github.com/musescore/MuseScore/actions/runs/13091403937) which contains this: MU4_250321841_Win_26256_Fix #15726 (Barlines & Jumps & Marks)_ Some elements are lost when changing time signature No rush, but I'm eager to test barlines when ready.

I'm not sure either. This PR try to keep as much BL as possible, but it is my understanding that the creator (@cbjeukendrup) should decide which BL should be kept and the rules. I mean, you can choose between different options:

We should just keep the BL that were at the beginning or the end of the former measure
We should just keep the BL that are now at the beginning or the end of the new measure
We should just keep the BL that were at the beginning or the end of the former measure and at the beginning or the end of the new measure
We should also try to keep BL that were at the middle of the former measure if they are now also at the middle of the new measure
We should also try to keep BL that were at the middle of the former measure and are in the beginning or end of the new measure if the same type of bar were in every staff
if there is a "middle" BL of type "END_START_REPEAT" in the former measure and now it is placed at the end of a new measure: we should try to change to a "END_REPEAT" in the current new measure and a "START_REPEAT" in the next new measure as long as the "middle" BL in the former measure was in every staff.
We should keep as much BL as possible and it is to the user to determine which ones should be deleted
Any additional combination..

BanjoJake · 2025-02-13T22:53:52Z

I haven't seen a response from cbjeukendrup, so here's my feedback:
(item 3): " beginning or the end of the former measure and at the beginning or the end of the new measure", which, as I understand it, includes items 1 & 2. These are simple and obvious.

Or the last item "keep as much BL as possible and it is to the user to determine which ones should be deleted",

I don't understand the scenarios where there is a barline in the middle of a measure; I've never used that or even seen it, so if it were up to me, I would leave it out for now and address specific issues as they arise in the future.

pacebes · 2025-02-14T07:14:39Z

I haven't seen a response from cbjeukendrup, so here's my feedback: (item 3): " beginning or the end of the former measure and at the beginning or the end of the new measure", which, as I understand it, includes items 1 & 2. These are simple and obvious.

Thanks for the feedback @BanjoJake. I really appreciate it!. Just to answer and clarify things. Option 3 does not include items 1 & 2. I rewrite these options:

Keep the BL that were at the beginning or the end of the former measure regardless of whether they are in the new Measure when Time signature changes
Keep the BL that are at the the beginning or the end of the new measure when Time Signature changes regardless of whether they were in the former Measure
Keep the BL that were at the beginning or the end of the former measure and at the beginning or the end of the new measure when Time Signature changes

I agree that the third one is the one which could generate less problems. I you agree I will change the PR to agree with the third option.

Or the last item "keep as much BL as possible and it is to the user to determine which ones should be deleted",

This is what the PR does now (regardless of potential errors)

I don't understand the scenarios where there is a barline in the middle of a measure; I've never used that or even seen it, so if it were up to me, I would leave it out for now and address specific issues as they arise in the future.

I don't really understand either the need for "middle" BL, but I am not a musician expert. You can create any BL wherever you like. Just select a chord or a rest and click on a BL. Example provided: Score_15726_BL_tests.zip. You could use it also as a test Score. Each line is duplicated so you can check the result

BanjoJake · 2025-02-14T15:42:11Z

Or the last item "keep as much BL as possible ...
This is what the PR does now (regardless of potential errors)

Sorry for my ignorance of Github - where can I find this PR to test ?

BanjoJake · 2025-02-15T07:12:05Z

I agree that the third one is the one which could generate less problems.
If you agree I will change the PR to agree with the third option.

Yes, although I am also happy to test the existing PR if I can find it.

Jojo-Schmitz · 2025-02-15T08:41:15Z

As usual: the artifacts of the builds, like at https://github.com/musescore/MuseScore/actions/runs/13091403937?pr=26256 (for Windows)

BanjoJake · 2025-02-15T15:06:44Z

A ... github.com/musescore/MuseScore/actions/runs/13091403937?pr=26256

Thanks, I tested this a while ago (and again just now), and it failed this simple test*, so I didn't think it was what pacebes was referring to.

Test of 'elements lost when changing time signature #15726'.zip

pacebes · 2025-02-15T15:38:48Z

A ... github.com/musescore/MuseScore/actions/runs/13091403937?pr=26256

Thanks, I tested this a while ago (and again just now), and it failed this simple test*, so I didn't think it was what pacebes was referring to.
* [Test of 'elements lost when changing time signature #15726'.zip](https://github.com/user-attachments/files/18811538/Test.of.elements.lost.when.changing.time.signature.15726.zip)

I think it's explained at the begining of this Page ( #26256 (comment)). The test fails because It expects the previous behaviour when changing time signature meant BLs were deleted. It now keeps BLs, so this test can't pass.

BanjoJake · 2025-02-15T15:45:29Z

Now a test fails ... (#26256 (comment))
The test fails ... this test can't pass.

I'm sorry, still confused - when you say "test", you're not referring to the test file I just sent ?

pacebes · 2025-02-15T15:54:21Z

Now a test fails ... (#26256 (comment))
The test fails ... this test can't pass.

I'm sorry, still confused - when you say "test", you're not referring to the test file I just sent ?

Sorry. My fault. I am reading this from my mobile. and a I missed the file I will test It back in my computer at home

pacebes · 2025-02-16T20:25:11Z

Now a test fails ... (#26256 (comment))
The test fails ... this test can't pass.

I'm sorry, still confused - when you say "test", you're not referring to the test file I just sent ?

Hi @BanjoJake.
I don't know if I am missing something but it looks like it works to me: https://github.com/user-attachments/assets/bfb67c2f-e090-48c1-9b60-d09fa1f1105c

Result file: Test of 'elements lost when changing time signature #15726'_4_4.zip

I have tested the file with the version in my computer and also with the version @Jojo-Schmitz suggested: https://github.com/musescore/MuseScore/actions/runs/13091403937?pr=26256

Could you please tell me what's wrong?.

Initial

Final

I think it keeps all the barlines

BanjoJake · 2025-02-17T00:09:56Z

Hi @BanjoJake. I don't know if I am missing something but it looks like it works to me:
https://github.com/user-attachments/assets/bfb67c2f-e090-48c1-9b60-d09fa1f1105c

Yes, Thank you, it works ! I don't know where I got the version I was testing ( 4.2.0-233521124/eb8d33c instead of 4.5.0-250321841/2899ec4). I guess I'm not that familiar with the v4 world (I mainly use v3.7).

Very sorry for wasting your time and thank you very much again !!

BanjoJake · 2025-02-17T15:55:22Z

Final

This is great ! If you're still working on this, I wonder if it would be a big deai to also preserve the line breaks ? That would restore the more even staff spacing in the original. Also wondering when this could be backported to 3.7 ? THANKS !!

pacebes · 2025-02-17T16:06:49Z

Final

This is great ! If you're still working on this, I wonder if it would be a big deai to also preserve the line breaks ? That would restore the more even staff spacing in the original. Also wondering when this could be backported to 3.7 ? THANKS !!

Yes, I can work on it. @Jojo-Schmitz , should I include the preserving of line breaks in this PR??

Jojo-Schmitz · 2025-02-17T17:40:04Z

Sure!

…t when changing time signature

…time signature

pacebes · 2025-02-18T09:17:25Z

Sure!

Done!

BanjoJake · 2025-02-19T01:01:00Z

Yes, MuseScore Studio version (64-bit): 4.5.0-250490915 / 9f2c4ae (Windows 10) works perfectly on my test case ! I will try on this some real-world sheets in the next couple of days. Thank you very much !!

pacebes mentioned this pull request Jan 27, 2025

Some elements are lost when changing time signature #15726

Open

pacebes force-pushed the 15726-someElementsLostWhenChangingTimeSiganture_BarlinesJumpsMarks branch 2 times, most recently from 5574453 to f26e342 Compare January 27, 2025 22:57

pacebes force-pushed the 15726-someElementsLostWhenChangingTimeSiganture_BarlinesJumpsMarks branch 2 times, most recently from eae198b to b6e5ecc Compare January 28, 2025 21:00

pacebes force-pushed the 15726-someElementsLostWhenChangingTimeSiganture_BarlinesJumpsMarks branch from b6e5ecc to 8fdc09e Compare February 1, 2025 18:41

pacebes changed the title ~~Fix #15726 (Barlines & Jumps & Marks): Some elements are lost when changing time signature~~ Fix #15726 (Barlines): Some elements are lost when changing time signature Feb 1, 2025

pacebes added 2 commits February 18, 2025 10:14

Fix musescore#15726 (Barlines & Jumps & Marks): Some elements are los…

bbda24a

…t when changing time signature

Fix musescore#15726 (Barlines): Some elements are lost when changing …

1979847

…time signature

pacebes force-pushed the 15726-someElementsLostWhenChangingTimeSiganture_BarlinesJumpsMarks branch from 8fdc09e to 1979847 Compare February 18, 2025 09:14

pacebes changed the title ~~Fix #15726 (Barlines): Some elements are lost when changing time signature~~ Fix #15726 (Barlines & Line Breaks): Some elements are lost when changing time signature Feb 18, 2025

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Fix #15726 (Barlines & Line Breaks): Some elements are lost when changing time signature #26256

Fix #15726 (Barlines & Line Breaks): Some elements are lost when changing time signature #26256

pacebes commented Jan 27, 2025 •

edited

Loading

pacebes commented Jan 27, 2025 •

edited

Loading

pacebes commented Jan 28, 2025

pacebes commented Jan 28, 2025

Jojo-Schmitz commented Jan 30, 2025 •

edited

Loading

Jojo-Schmitz commented Jan 30, 2025

pacebes commented Jan 30, 2025

Jojo-Schmitz commented Jan 30, 2025 •

edited

Loading

pacebes commented Jan 30, 2025

pacebes commented Jan 30, 2025

pacebes commented Feb 1, 2025

BanjoJake commented Feb 9, 2025

pacebes commented Feb 11, 2025

BanjoJake commented Feb 13, 2025 •

edited

Loading

pacebes commented Feb 14, 2025 •

edited

Loading

BanjoJake commented Feb 14, 2025

BanjoJake commented Feb 15, 2025

Jojo-Schmitz commented Feb 15, 2025

BanjoJake commented Feb 15, 2025

pacebes commented Feb 15, 2025

BanjoJake commented Feb 15, 2025

pacebes commented Feb 15, 2025

pacebes commented Feb 16, 2025

BanjoJake commented Feb 17, 2025

BanjoJake commented Feb 17, 2025

Final

pacebes commented Feb 17, 2025

Final

Jojo-Schmitz commented Feb 17, 2025

pacebes commented Feb 18, 2025

BanjoJake commented Feb 19, 2025

Fix #15726 (Barlines & Line Breaks): Some elements are lost when changing time signature #26256

Are you sure you want to change the base?

Fix #15726 (Barlines & Line Breaks): Some elements are lost when changing time signature #26256

Conversation

pacebes commented Jan 27, 2025 • edited Loading

pacebes commented Jan 27, 2025 • edited Loading

pacebes commented Jan 28, 2025

Original Score

Expected Score

Score output with this PR

Why does this happen?

pacebes commented Jan 28, 2025

Original Score

Expected Score

Score output with this PR

Why does this happen?

Jojo-Schmitz commented Jan 30, 2025 • edited Loading

Jojo-Schmitz commented Jan 30, 2025

pacebes commented Jan 30, 2025

Jojo-Schmitz commented Jan 30, 2025 • edited Loading

pacebes commented Jan 30, 2025

pacebes commented Jan 30, 2025

pacebes commented Feb 1, 2025

BanjoJake commented Feb 9, 2025

pacebes commented Feb 11, 2025

BanjoJake commented Feb 13, 2025 • edited Loading

pacebes commented Feb 14, 2025 • edited Loading

BanjoJake commented Feb 14, 2025

BanjoJake commented Feb 15, 2025

Jojo-Schmitz commented Feb 15, 2025

BanjoJake commented Feb 15, 2025

pacebes commented Feb 15, 2025

BanjoJake commented Feb 15, 2025

pacebes commented Feb 15, 2025

pacebes commented Feb 16, 2025

Initial

Final

BanjoJake commented Feb 17, 2025

BanjoJake commented Feb 17, 2025

Final

pacebes commented Feb 17, 2025

Final

Jojo-Schmitz commented Feb 17, 2025

pacebes commented Feb 18, 2025

BanjoJake commented Feb 19, 2025

pacebes commented Jan 27, 2025 •

edited

Loading

pacebes commented Jan 27, 2025 •

edited

Loading

Jojo-Schmitz commented Jan 30, 2025 •

edited

Loading

Jojo-Schmitz commented Jan 30, 2025 •

edited

Loading

BanjoJake commented Feb 13, 2025 •

edited

Loading

pacebes commented Feb 14, 2025 •

edited

Loading