Leading space adjustment for generated elements lost on save/reload

• Nov 4, 2016 - 14:11
Reported version
3.x-dev
Priority
P1 - High
Type
Functional
Severity
S3 - Major
Status
closed
Regression
No
Workaround
No
Project
MuseScore

2.0.3 / Win 7

See attached file. Except for the clef/key signature at the beginning of the score, any changes the user makes to the leading/trailing space of clefs or key signatures is lost when the score is closed. Time signatures seem to be unaffected.

Attachment Size
leading_trailing_space.mscz 25.04 KB

Comments

• Nov 5, 2016 - 04:59

This may be analogous to the fact that setting elements which are generated 'on-the-fly' (such as clefs, key sigs, and staff names) as 'invisible' isn't saved. I have had that problem with scores requiring an incipit before the main part of the music begins. I create the incipit, insert a frame and a section break, and then start the main score. Because of the section break, the long instrument names appear again where I don't want them to. Setting them as 'invisible' only lasts until the score is closed and reopened. To print properly, I have to export to PDF before the score is closed and reopened.

My understanding is that because MuseScore's automatic layout algorithm generates these elements for the start of each new line as that line is defined it is not possible for the program to respect manual changes to the 'parent' element from which they are generated.

Reply

• Nov 5, 2016 - 14:46

Well, visibility *is* saved, so we do have at least some of the code we need to read/write these elements. Probably just additional code needs to be added to handle other properties. Could be others too.

Reply

• Feb 4, 2019 - 17:51
Reported version 2.1 ⇒ 3.x-dev
Regression ⇒ No
Workaround ⇒ No

OS: Windows 10 (10.0), Arch.: x86_64, MuseScore version (64-bit): 3.0.3.5341, revision: e06ea8e

Reply

• Feb 6, 2019 - 22:05
Title Leading and trailing space for clefs and key sigs reset to zero when score is closed ⇒ Leading space adjustment for clefs and key sigs lost on save/reload
Priority ⇒ P0 - Critical

(trailing space is no longer a thing)

Reply

• Feb 6, 2019 - 22:37
Title Leading space adjustment for clefs and key sigs lost on save/reload ⇒ Leading space adjustment for generated elements lost on save/reload

Clefs, keysigs, and barlines at least.

Reply

• Mar 28, 2019 - 05:47

It does get saved if you also change some other property like offset. The issue is that changing leading space doesn't cause the element to be marked non-generated, so it is never written. Once some other property triggers the element to be marked non-generated, then the properties are written properly.

See also #279245: Stacking order, autoplace not saved for generated stems which is similar. Not sure if it makes sense to address these issues individually for each property or if it is better to find a more global solution.

Reply

Fix version
3.1.0