Minimum distance property for all kinds of fermata is not saved
Reported version
3.2
Priority
P1 - High
Type
Functional
Frequency
Once
Severity
S3 - Major
Reproducibility
Always
Status
closed
Regression
No
Workaround
No
Project
1) Add a fermata to a score.
2) Change its "min. distance" property.
3) Save/reload file.
Result: minimum distance for fermata has its default value rather than that assigned before saving.
Possibly some other element types are also affected, I didn't check them yet.
The issue exists both in 3.1 (where that property got introduced) and 3.3 Beta2 versions.
Fix version
3.3.0
Comments
Confirmed, all fermatas (fermata, short fermata, long fermata...) affected but not other articulations (tried a handful).
Sorry.
See https://github.com/musescore/MuseScore/pull/5360.
There might indeed be some other elements affected, but I know it does work for most. Most of my testing wasn't based on changing min distance directly, but rather moving elements into the skyline, which automatically updates min distance as necessary. This did cause me to miss one case, with lines, where min distance only got written if the offset had been changed due to how the line properties were handled. But I just fixed that (see #294728: Lines: Minimum distance is not saved with score unless it is part of the style).
In reply to There might indeed be some… by Marc Sabatella
Good to know!
BTW, that bug I fixed with lines is exactly why you don't want to move your write of min distance underneath the "if (!isStyled(Pid::OFFSET))". The reason it failed is we were only writing min distance if offset was changed also, because there was no separate checked for min distance. It might be uncommon to change min distance without also changing offset, but not unheard of. And that's what the isStyled() is checking - whether the property has in fact been changed from the default.
In reply to BTW, that bug I fixed with… by Marc Sabatella
Oh, sorry, I was actually talking about adding a
if (!isStyled(Pid::MIN_DISTANCE)), but it isn't needed anyway.Fixed in branch master, commit 911ea73f71
_fix #295153: minimum distance property for all kinds of fermata is not saved
Resolves: https://musescore.org/node/295153.
Fermata uses a different cpp file than other articulations, so it is possible that this part of property read-and-writing was simply forgotten._
Fixed in branch master, commit 79beac5538
_Merge pull request #5360 from Howard-C/fermata-min-distance
fix #295153: minimum distance property for all kinds of fermata is not saved_
@Jojo-Schmitz Not 3.3.0 but 3.3.1 according to Anatoly.
In reply to @Jojo-Schmitz Not 3.3.0 but… by RobFog
It was indeed added to the 3.3.1 milestone, but it was actually merged before 3.3.0 is released, so 3.3.0 includes this fix.
No, it was merged to master but will not be added to the 3.3 branch as per https://github.com/musescore/MuseScore/pull/5360#issuecomment-541691004.
We'll see, once 3.3.0 final got branched off of master (or whether the 3.3RC branch gets used to branch of 3.3.0 final and some commits from master get cherry-picked)
In reply to No, it was merged to master… by Marc Sabatella
OK, I thought 3.3 branch would be based on all commits done on master.
My assumption too, until proved to be wrong
In reply to My assumption too, until… by Jojo-Schmitz
Well, https://github.com/musescore/MuseScore/pull/5360#issuecomment-541691004 already proved that wrong.
EDIT: OK, I get what you mean. Can't we delete comments on musescore.org? Why? I can edit or delete comments on musescore.com any time I want, but not on musescore.org. Is there some historical reason?
Being able to edit comments (in forum or on musescore.com groups) any time is a bug, at least after replies edditing should be prevented. In forums on musescore.org, there is a time limit, in the issue tracker (where no replies really exist) there is no limit at all, but deleting is not possible on .org, just 'emptying' (it possible is on .com)
In reply to Being able to edit comments … by Jojo-Schmitz
Well, to be frank, musescore.org is the first website I've every seen of having a time limit of editing and restriction of deleting. GitHub, Atlassian, and many more, they don't have that. I can see troubles arousing from no limits or restriction, such as overall replacing the topic, making all comments below invalid, or other tricks. But what if the user really wants to delete something? Do that by telling the maintainers?
Automatically closed -- issue fixed for 2 weeks with no activity.