"add to measure number" is not linked between score and parts after reload

In general I don't like when changing something in part change it also in score in a global way. Meaning, everything related to full measure should not be linked from part to score according to me because if the user changes it in a part, it will impact the score but also all the other parts without warning... It's the same problem for time signature.

As long as changes of this type made in the *score* propagate to the *parts*, I'd be OK with the reverse not being true.

See also #62416: Changes to staff transposition (and other properties) not reflected in linked parts for example of a property I think must work both ways. It doens't normally affect all parts, but could potentially affect multiple parts if the same instrument is involved in more than part.

The same problem exists with pickup measures - usually excluded from counting.

Bar numbers have to be consistent over all parts and in the score!
ok - no changes from one single part to the score (and all the other parts)

--> But then please
- do not allow this changes in parts
- allow this changes only in the score
- with automatically effect over all existing parts

It appears there was a conscious decision for most properties *not* to be linked, to allow you to have certain differences between score and parts. But it is worth discussing what actually makes sense, and what controls we could provide here. See https://musescore.org/en/node/73841 for discussion.

See #257581: Changes to Measure properties are not propagated between score and existing linked parts after save/reload

I have a straightforward Haydn score with 4 parts and many midbar repeat signs. Musescore treats the split bars as two. Normally they would be counted as one. To achieve this, I can imagine that MuseScore would ask me to adjust each one separately, though I wish I didn't have to. However, the adjustments do not propagate to the parts. Is there anything I can do that is less laborious than adjusting each of the parts as well? Should not the default be that the same measure in score and parts has the same number?
John P

What version of MuseScore? This should be working as of 3.3. If not please attach your score so we can investigate.

As for a generally recommended approach, I would say, don’t generate parts until you’re done with make edits like that. If you’ve already generated them, just delete them and regenerate them when you’re done with these sorts of edits.

Haydn Trio_Hob._XV_25b.mscz
I thought I was updating continuously. When I checked, it turned out not, but I discovered I had 3.3.4.9066. Otherwise I don't know how to find out.
Your recommendation is a counsel of perfect foresight, which unfortunately I lack. As it happens, it didn't even occur to me I might have this problem until late in the game. Other reasons for what you would consider premature part generation include: I'm stupid; I'm impatient; collaborator brings up problem; I want to look at parts to see if instruments are too busy or not busy enough or clarinets have significant passages above the staff where they are happy but I think they screech (much easier to see in parts than score); I notice stems that are too short (very common with beams on notes above the staff--MuseScore apparently follows different rules than my references) and I want to fix them before I forget; I want to make progress on parts while I wait for other decisions about the score; etc.--I'm sure there are many other reasons I'm not thinking of. Anyway, just regenerating loses adjustments made to parts. And you must agree that parts should have the same measure numbers in the same measure, however inept the compositor (and even after a free-form intro in one part, it seems to me).
Here's a file in which I made a change in the bar before the first repeat sign. I'm not sure whether I have sent a different one above.
Haydn Trio_Hob._XV_25b.mscz
Thanks for your responsiveness.

Hmm, I can confirm the problem in your score, but was at first unable to reproduce that from scratch. If I create a new score, the exclude from measure count property is linked as I expected, and it works whether I set it before generating parts or after. However, once I saved and reload the score, changes I already made are still honored but further changes are not.

Anyhow, the workaround for now is to delete and regenerate the parts if you need to make changes of this nature late in the game, and try not to make manual adjustments until the basic structure of your score is set. Or, if it is unavoidable, so you don't want to regenerate the part, then you will need to duplicate the setting manually.

Hmm indeed! Thank you for sleuthing this out. In this case, I have done far too much to regenerate the parts, especially since I wouldn't remember everything. I hope there aren't too many other reloading anomalies waiting to pounce.

This issue is solved as a side effect of PR 6214 , solving #257581: Changes to Measure properties are not propagated between score and existing linked parts after save/reload.

Fixed in branch 3.x, commit 2c7435b19e

_Fix #257581, Fix #64636 - Changes to Measure properties are not propagated between score and existing linked parts after save/reload

Saving link information into the MSCX file. Since measure information is written for
every staff, make sure the link information is written for the first staff only._

Fixed in branch 3.x, commit a470fc3037

_Revert "Fix #257581, Fix #64636 - Changes to Measure properties are not propagated between score and existing linked parts after save/reload"

This reverts commit 2c7435b19e4b774070985acfc8c25d8b356d30d3._

Fixed in branch 3.x, commit 529fe7f5c3

_Fix #257581, Fix #64636 - Changes to Measure properties are not propagated between score and existing linked parts
after save/reload

When reading a mscx file containing parts, link all measures of the part to the corresponding measure in the MasterScore._

Fixed in branch 3.x, commit 5431550f87

_Merge pull request #6743 from njvdberg/issue-257581-linking-measures

Fix #257581, Fix #64636 - Changes to Measure properties are not propagated between score and existing linked parts_

Fixed in branch 3.6alpha, commit 529fe7f5c3

_Fix #257581, Fix #64636 - Changes to Measure properties are not propagated between score and existing linked parts
after save/reload

When reading a mscx file containing parts, link all measures of the part to the corresponding measure in the MasterScore._

Fixed in branch 3.6alpha, commit 5431550f87

_Merge pull request #6743 from njvdberg/issue-257581-linking-measures

Fix #257581, Fix #64636 - Changes to Measure properties are not propagated between score and existing linked parts_

Automatically closed -- issue fixed for 2 weeks with no activity.