Leading/Trailing Reset, Objects' Position Shift
I find that when coming back to a file that trailing space and leading space I assigned to beginning of system items, with the exception of time signatures, gets reset.
Also, some hairpin and dynamic positions get shifted.
I get that this program is free .... but I mean ....
Comments
Which version of MuseScore and on which OS are you using?
Can you create a small sample score showing each problem with steps to reproduce? I know there have been problems with wandering hairpins in the past, most of them have been solved and one scenario still needs fixing (see #250381: Wandering hairpin in score with mmrest & invisible staves )
If you can make those examples, it'll be way easier for the developers (mostly volunteers) to find out the reason and fix it.
In reply to Which version of MuseScore… by jeetee
MuseScore 2.1
Windows 10
You can try this yourself. Adjust the length of hairpin, save, close, and reopen.
Adjust the leading and trailing of a clef and key signature; ditto.
The dynamic markings seems to be occasional or perhaps in connection with a custom positioning style when the file is reopened.
In reply to MuseScore 2.1… by HG19
I can't try this myself as I don't have Windows 10 easily available.. Which is why we're asking for simple sample scores.
If they're simple it is easier to see what information is actually inside the file. For me for example, hairpins work exactly as they should.
As for leading/trailing space on clef/key signature, see the linked bug report.
And for me, so far, dynamics are also working just as expected, which again is why we need files that have the problem for you.
In reply to MuseScore 2.1… by HG19
The trailing/leading space stuff is not meant for causal use and is only supported for certain element types for very specific effects. Probably best not to rely on it much anyhow since this will all likely change with 3.0.
As for hairpin length, in general this of course should and does work. There have been some bugs involving very specific combinations of things that can causes glitches, and I've been fixing them as they've been reported. Several were fixed for 2.1, but maybe you are seeing a new one not yet reported. If you can reproduce this reliably, please attach your score and give us precisely steps to reproduce the problem so we can investigate further.
In reply to The trailing/leading space… by Marc Sabatella
It seems that a lot of the positioning issues stem from the fact that I have Dorico installed on my computer.
However, regarding the trailing space and clef/key signature, I attached 2 pics to show what I am using it for. (I think I'm using it right.)
You say "specific effects" ... like what exactly? What's the point of being able to edit it if it can't be saved.
In reply to It seems that a lot of the… by HG19
What I mean is, as far as I know the facility was introduced primarily to allow for tweaking spacing between notes in a way that preserved vertical alignment between staves. It just happened that the way this was implemented also worked for certain other element types, so the controls were added to the Inspector, but obviously not fully developed or tested. Of course if the control is provided it should save/restore, so this is indeed a bug. I'm just explaining how something like this can easily slip through the cracks. And also giving fair warning that as of how things stand right now, the way this facility works is changing for 3.0. Instead of both trailing and leading space, there will only be leading space, so instead of setting the space after the clef you'd need to set the space before the barline.
But the larger point is that this shouldn't be needed at all. If you believe the default spacing in MuseScore is incorrect, best to point that out, ideally accompanied by examples / references. Then we can simply change the defaults if it seems there is widespread agreement, or add more controls to Style / General / Measure to control defaults on a per-score basis. The idea being, it is generally better not to rely on these sort of manual adjustments but instead take advantage of defaults and style settings where possible.
Currently in 2.x, there is a setting in Style / General / Measure for "Clef to barline distance" that I would have thought was to control this, but it seems to not be effective. In current 3.0 builds, the corresponding setting does work for this. Actually, there are three separate settings, one for clef to barline, one for keysig to barline, one for timesig to barline. So for 3.0, there shouldn't be a need for individual overrides.
Anyhow, for 2.x, what we need to do is figure out the following:
In reply to What I mean is, as far as I… by Marc Sabatella
Great response, Mr. Sabatella! I really appreciate the discourse.
Regarding MuseScore 2.X functionality:
Other than the beginning-of-system-items trailing space parameter, the only other option I have found for spacing a repeat bar is to adjust its horizontal position and readjust note positions for the measure or system. Setting the trailing space is much easier by comparison as music spacing is factored in. I think fixing the bug would be better than making 2.X a light 3.0 version (just my opinion). The "Clef to Barline" parameter from the General Style dialog box should control the space between a clef and barline when a clef change begins a measure and a courtesy clef at the end of a system. However, it creates space BEFORE the clef change (i.e., bewteen notes to clef) and not AFTER the clef (clef to barline).
Thinking of a repeat bar as a barline is a common misconception and highlights an erroneous MuseScore practice in regards to key and time signatures changes that occur mid system in connection with a repeat bar. (See Gardner Read attachment; Example 12-12.)
Repeat Bar Spacing Beginning A System (See Ted Ross attachment):
I don't necessarily agree to the letter of Ross' recommendation but agree that there should be adequate space between a repeat bar and clef/signature items. How much space depends on how the music is spaced and the discretion of the "engraver/copyist." Tightly-spaced music may have little to no space between signature items and a repeat bar. In general, though, it's best to keep music moderately spaced and so there should be a little more space for the repeat bar by default. I'm not sure how items are spaced in MS but it seems like it is spaced from the end of the first item to the beginning the the next item (right>left) rather than the methods Ross describes (left>right; left>left). If this is the case, then maybe a distance of 4 pt. to 1 space between might be good.
In reply to Great response, Mr… by HG19
I agree that editing the position of the barline and then of all other notes is a worse workaround. better would be for the style setting to actually work. I just don't fully understand the intent here in the code. Right now, we are literally only applying this setting if the barline directly follows the clef, and even then only for end barlines. So I guess is more to handle a clef change at the end of a measure. Except that as you say, it actually ends up placing the space before the clef, which makes no sense at all to me. Anyhow, if I knew what this setting was supposed to accomplish, it would be easy enough to fix it I think, but right now it just isn't clear. Luckily, as I said, for 3.0, it seems like this is already going to be better.
I don't fully understand your comment about a repeat sign not being a barline, though. It is a barline most senses I can think of, although of course not in others. To me its not a misconception but a gray area; Read's interpretation seems idiosyncratic (as it is in other matters as well, it seems to ). Gould doesn't make any such distinction - she explicitly calls them "repeat barlines" and says "at a conventional barline, they replace it". But in any case, where other calls it a barline or not, you are correct that it should behave differently in terms of the positioning of the key and time signature. Not sure this has been pointed out before. You might want to file a bug report for this, it probably isn't terribly difficult to fix but might have to wait until 3.0 if it breaks compatibility.
Thanks for the Ross example, which states a clear rule for spacing. Gould doesn't that I can see, and she uses less space than Ross in her own examples, though more than we do. I'm reluctant to change the default for 2.x because it would have an adverse effect on existing scores that might be depending on the existing spacing,. but definitely worth considering for 3.0. If there is no way to get the style setting working better, though, this could potnetially be revisited for 2.x as well.
In reply to I agree that editing the… by Marc Sabatella
Yeah, I think it's clear that the "Clef to Barline" setting is a bug and is not working as it should, by its definition. I also think it's clear that this is not meant to space beginning-of-system clefs as there are other settings for that (and, therefore, shouldn't be used for spacing a repeat bar and beginning-of-system items). Another reason why repeat "bars" should be considered a thing unto itself and not a barline. It's great that there is actually a setting for repeat bars in the next major version.
I think the Gardner Read example speaks for itself, though. Why is it considered correct to place a key/time change ahead of a repeat rather than after it?
He seems to be speaking out against a common incorrect practice, as one will find examples of both the "correct" and "incorrect" in manually engraved music (of the same piece, even). His concern seems to be that of orthodoxy over prevalency. I mean, yes, repeat bars coincide with barlines. But it's one those things ..... like, you put tomatoes in a salad but it's not, technically, a vegetable.
In reply to Yeah, I think it's clear… by HG19
I don't think it's necessarily true that this setting "is not meant to space beginning-of-system clefs. There are no other settings for that - at least, not for space after clef and before the (repeat) barline. And that is exactly what this very same setting affects in 3.0. And to be clear - I am not saying 3.0 treats repeat barlines differently from other barlines. I am saying there are separate settings for clef to barline, key signature to barline, and time signature to barline. All of these affect repeat barlines if they directly follow the clef, key, or time signature in question - just as they also affect end barlines in the same cases. It's still not clear to be there needs to be separate control over those two case (space after clef at beginning of measure before start repeat versus space after clef at end of measure before end barline) - your examples didn't really make this clear.
As for the Read example, the reasoning for placing a key/time change before the repeat is that it doesn't actually cause a change on the repeat - it's just more of the same. So it's a logical / musical decision that has nothing to do with whether you choose to conceptualize the repeat barline as just one special type of barline (as Gould does and also most other sources I am have seen) or as a new animal entirely (as Read does).
In reply to I don't think it's… by Marc Sabatella
Ok. So there isn't a separate setting that controls the distance between a clef and barline in 3.0 when a clef change begins a measure (mid-system) and at the end of the line for a courtesy clef? This is a specific instance and is separate from a repeat bar at the start of a system. The thing is, I would want quite a bit of space for a repeat bar than I would for a mid-system clef change or courtesy clef (actually, very little space here). The default setting for "clef to barline" in 2.1 is actually not much which supports that it probably was intended for a clef change beginning a measure and courtesy clefs; the code was just written incorrectly to affect the space before the clef instead of after it.
Also, Ross is in agreement with Read (see attachment, bottom of page)
In reply to Ok. So is there a separate… by HG19
In current 3.0 builds, the same "Clef to barline distance" setting affects both cases: the distance from a system-initial clef to a repeat barline, also the distance from a clef change at the end of a measure to the right barline for that measure. Having separate controls makes sense indeed, feel free to formally request by filing an issue in the tracker.
EDIT: BTW< it's still worth trying to track down the shifts you are seeing on reload. It could be an artifact of a Bravura inconsistency, sure, but it might be an actual bug. If it were just the font, I'd expect it to look wrong but always the same.
See #139846: Leading space adjustment for generated elements lost on save/reload.