I can't seem to replicate this exact bug. It's true that when I follow your steps I get the result from the first picture: it looks like 1/1, but the actual value of the time signature remains 4/4, it is just not drawn correctly on zoom 100%. If I zoom in, 4's middle line reapears (second picture). This also happens with other time signatures containing 4 like 2/4, 3/4 for the following values of the zoom: 100%, 68.3013%, 62.0921% (it could also happen for smaller values, but I can't make the diference). Can you please try and see if this is what is happening for you also, or this is something diferent?
I did test this with XML's exported some time ago from 1.3. Any 4/4 scores show this problem so Jojo's assertion the 2.0 import is at fault is likely correct.
At this point we have no knowledge about the time signature. A possible small fix would be to compare the len with the time signature after xmlMeasure and if they are equal (1/1 = 4/4) changes the actual duration to be 4/4, or something even smarter to deal with the case of (1/2 = 2/4)...
I was experimenting with some older 1.3 XML files, and that was when I noticed this "actual duration" problem. One XML file I have can't be reloaded once I import into 2.0 and save as MSCZ. I don't know if the problem is the "actual duration" bug, but I will attach the files.
MS 1.3 can load the attached XML, and save to MSCZ fine, and I can load this MSCZ into MS 2.0
MS 2.0 can load the attached XML, save to MSCZ, but the resulting file can't be reloaded into MS 2.0.
Also, when I try to drag/drop the broken MSCZ file onto MS 1.3 it won't even comment that the file is too new, as it should, and nothing happens.
The "broken" file of comment #7 is another different bug: it cannot be imported because there is an "&" character in the text of measure 41 "Part 2: Tribulation & sacrifice".
It is imported wrongly from the xml as " & " instead of the correct escaped version " & ", so that that character and trailing words are not visualized.
This "error" is then written as it is in the mscz (mscx) file, causing a syntax error during import.
Windows 8.1, commit 4fc4667
When calculating measure duration MuseScore 1.3 explicitly tried to keep the measure actual duration consistent with the time signature. This code had to be removed in a redesign, but the equivalent function was never restored.
Will repair this shortly, even though I consider this to be only a minor annoyance.
I wasn't sure if any unforeseen consequence would come out of leaving the fraction this way. It will make the measure dialog look correct, and make adjusting the values for custom measures more straightforward.
Comments
I can't seem to replicate this exact bug. It's true that when I follow your steps I get the result from the first picture: it looks like 1/1, but the actual value of the time signature remains 4/4, it is just not drawn correctly on zoom 100%. If I zoom in, 4's middle line reapears (second picture). This also happens with other time signatures containing 4 like 2/4, 3/4 for the following values of the zoom: 100%, 68.3013%, 62.0921% (it could also happen for smaller values, but I can't make the diference). Can you please try and see if this is what is happening for you also, or this is something diferent?
picture1: zoom 100%
picture2: zoom 110%
I'm using Windows7 64-bits, MS-2.0
@AndreiTuicu: see #1702: Antialiasing with staff lines and #25025: Except staff lines from antialiazing, I think they explain what you see?
I can reproduce the issue with the wrong actual time sig, following schepers' steps, self-built d2a6835, Windows 7 Enterprise 64bit
And loading the XML in 1.3 indicates that the 2.0 import is to blame, not the export
I did test this with XML's exported some time ago from 1.3. Any 4/4 scores show this problem so Jojo's assertion the 2.0 import is at fault is likely correct.
1/1 is mathematically correct...
Here we set the actual duration https://github.com/musescore/MuseScore/blob/master/mscore/importxml.cpp…
and the fraction is reduced.
At this point we have no knowledge about the time signature. A possible small fix would be to compare the len with the time signature after xmlMeasure and if they are equal (1/1 = 4/4) changes the actual duration to be 4/4, or something even smarter to deal with the case of (1/2 = 2/4)...
If we don't have the knowledge, then how does 1.3 get it right?
I was experimenting with some older 1.3 XML files, and that was when I noticed this "actual duration" problem. One XML file I have can't be reloaded once I import into 2.0 and save as MSCZ. I don't know if the problem is the "actual duration" bug, but I will attach the files.
MS 1.3 can load the attached XML, and save to MSCZ fine, and I can load this MSCZ into MS 2.0
MS 2.0 can load the attached XML, save to MSCZ, but the resulting file can't be reloaded into MS 2.0.
Also, when I try to drag/drop the broken MSCZ file onto MS 1.3 it won't even comment that the file is too new, as it should, and nothing happens.
The "broken" file of comment #7 is another different bug: it cannot be imported because there is an "&" character in the text of measure 41 "Part 2: Tribulation & sacrifice".
It is imported wrongly from the xml as " & " instead of the correct escaped version " & ", so that that character and trailing words are not visualized.
This "error" is then written as it is in the mscz (mscx) file, causing a syntax error during import.
Windows 8.1, commit 4fc4667
Thanks for the investigation! I will post a new issue for this.
When calculating measure duration MuseScore 1.3 explicitly tried to keep the measure actual duration consistent with the time signature. This code had to be removed in a redesign, but the equivalent function was never restored.
Will repair this shortly, even though I consider this to be only a minor annoyance.
I wasn't sure if any unforeseen consequence would come out of leaving the fraction this way. It will make the measure dialog look correct, and make adjusting the values for custom measures more straightforward.
Fixed in 4c8689c877
Automatically closed -- issue fixed for 2 weeks with no activity.