Request for text offset to be propagated from score to parts
Reported version
3.6
Type
Functional
Frequency
Once
Severity
S5 - Suggestion
Reproducibility
Always
Status
active
Regression
No
Workaround
Yes
Project
I see this bug in MuseScore 3.6.2.
The attached score displays fine as a score. The placement of "Note 2" is manually adjusted so that it is somewhat below "Note 1": in the Inspector, I changed its vertical alignment and its Y offset.
But now create parts from this score, and that adjustment is not applied to the generated trumpet part. In particular, Note 2's vertical alignment setting is carried over, but not the Y offset.
| Attachment | Size |
|---|---|
| text_offset_bug.mscz | 4.86 KB |
Comments
As far as I can neither the X-- not the y-offset are propagated. Nor does the setting for automatic placem,ent.
these all probably should, on part creation, but neither should after, i.e. these settings should copy on part creation but not sync between score and existing parts (as being layout)
In reply to As far as I can neither the… by Jojo-Schmitz
Yeah, Marc noted over in #82566: Note properties (small, head group, etc.) not linked between score and parts that many score changes intentionally do not propagate to existing parts (though I agree with his side note that this ought to be configurable for those of us who do want them synchronized; I routinely delete and recreate all parts as a workaround, but this is annoying and has potential for introducing errors into parts if I forget that step. It's a simple, repetitive task, which shouldn't be required of humans when computers are so much better at it).
And the need for such a workaround makes the present bug worse, because now it's not a simple delete-parts-create-parts process: many parts require further manual fiddling as well. So a way to tell MuseScore to sync the parts with the score—that is, to not need the workaround at all—would make the current text-offset bug less severe.
The workaround is (of course) to manually apply those offsets in the part after its creatrion.
As noted elsewhere, it's by design that layout details are unique to each score. In some cases, the approach has been taken where adjustments made prior to generating parts get retained, but this has never been consistent, and is definitely not always or even usually desired. The vast majority of manual adjustments are in response to conditions that simply don't exist in the parts - eg, to avoid confusion with markings on other instruments' staves, or adjustments that are dependent on the measure width and this is extremely likely to be different in the part.
That said, there are special cases where simply retaining manual adjustments as a starting point could make sense, so I like the idea of an option to somehow make that the case. it's complicated in MsueScore 4, though, because part generation will be longer be a separate act. So it's not clear what that would actually look like. Maybe a command to simply copy all score adjustments to parts at any given time? Meanwhile, I wonder if a plugin could do that, much as there is one to copy breaks.
In reply to As noted elsewhere, it's by… by Marc Sabatella
"The vast majority of manual adjustments are in response to conditions that simply don't exist in the parts"
That's one possible workflow. Other users don't care at all what the score looks like, because the only thing that will ever be used in any real-life setting are the parts, so they don't bother adjusting the score to avoid overlaps or other uglinesses, as long as the parts look OK. For those users, all manual adjustments are responses to conditions in the parts.
"it's complicated in MsueScore 4, though, because part generation will be longer be a separate act."
Per previous comments, given how often I have to delete and regenerate parts to make them pick up changes to the score, this is an alarming development. I hope there'll be a global "sync everything" setting, otherwise every change to a score will have to be scrutinized in the parts to make sure it's picked up, or applied manually if not, making even simple editing extremely tedious.
In reply to "The vast majority of manual… by Amaiza
But that’s my point - in order to make adjustments based on the conditions that exist in the parts, you have actually be viewing the part. Because the conditions in the score don't match those in the parts.
Regarding the need to regenerate parts, it isn’t clear why you are resorting to that - should be incredibly rare - but best to start a forum discussion to get feedback on whatever it is you are doing. If there is some real world use case for this, then indeed, it would be important to support somehow, although hopefully a more intuitive and less drastic method than deleting and regenerating parts.
In reply to But that’s my point - in… by Marc Sabatella
Weird, it's not clear to me why you think that should be "incredibly rare," given that the development team intentionally does not automatically propagate many score changes to the parts. Users who want everything to remain in sync between score and parts have to either apply a lot of changes to both places, or delete/recreate all the parts—which is often a lot quicker, and doesn't require scrutinizing every change to the score to see whether it's picked up in the parts. Since the development team states this behavior is intentional, I haven't bothered cataloguing all the situations in which it's come up, so I don't see being able to start a particularly fruitful forum discussion about specifics.
But it ought to be clear that (a) as developers have said, many aspects are intentionally not synchronized; (b) some users do want everything synchronized, and therefore (c) if MuseScore 4 removes the one action that easily re-synchronizes things, it is regressing usability for that subset of users. I hope I'm misunderstanding something about the situation.
Two specific situations where I recall the problem coming up: (1) The one I linked to in my March 21 post, where marking certain notes as cues in the score does not propagate. This is not merely an aesthetic change; this alters the way the chart is interpreted by the player, changing the notes from "play these" to "be aware of these" (or sometimes "play these in the absence of some other player"). (2) Changing a time signature. This too is not an aesthetic change, but one that alters the way the player reads the music, and should not be different in the score and the parts.
Those are certainly not the only situations I've encountered the issue, but as I said, I've not kept track because there seemed little willingness on the MuseScore side to synchronize things. I am absolutely fine with this as long as I have a way to synchronize things. So that's why I hope MuseScore 4 offers a switch or setting for this if it takes away the mechanism I've been using in MuseScore 3.
I say it's rare because in my own hundreds of scores plus the tens of thousand of scores we used in our tests and that I've downloaded while supporting others users, it doesn't come up often.
There are indeed some adjustments that typically do need to be done in both places. Content adjustments, yes, absolutely,. like time signature s- and that's why they are linked. For most formatting adjustments, though, this is not the case. It's true that in some specific case - like size for cue notes - those could need to be done in both places, if you want the cue in the score as well as the parts (which itself is unusual; cues usually aren't included in the score, so instead you set them invisible, and only for the score).
But I was talking about the offset adjustments - needing those to be identical in score and parts is quite unusual. As I said, offset adjustments are usually done with respect to the surrounding context, and that context is different between score and parts. It would be absolutely disastrous if those adjustments were always automatically linked.
Someday it would indeed be nice to have a way to exercise more control over which properties get linked for a given score, and to break those links where needed. Meanwhile, we do always continue to tweak which properties do get linked and which don't, and this tweaking is always based on user input. So far from being fruitful, if you believe you have a legitimate case to be made that some property that currently isn't linked should be, or vice versa, definitely start a forum discussion and include real world examples demonstrating why you believe the default should be the other way, not just for that case but in general for that property. If it turns out this the majority of users agree the current default should be changed, it can be.