This bug is still present after five years. This bug ticket seems to have been made during the discussion on the comment thread linked above, but has never been addressed.
In the linked discussion, members talk about ambiguity on whether some note properties should be linked between the main score and the associated parts. There is no scenario I can imagine where a composer would want, for example, note head group to differ in this way. The fact that note head groups are not linked means that any deviation from the default requires duplicating the change on each affected part.
I cannot speak for all note properties, but at the very least, note head groups should always be linked between score and parts. To do otherwise defeats the purpose of using alternate note head groups.
Workaround is to create the parts after having set those note properties, as these do get copied accross ion part creation.
OTOH the 'small' property surely is a layout thing and as such should not be linked. Notehead type though to me is content and as such should be linked
I would say this isn't a bug per se. As discussed in the forum thread, we really need to err on the side of caution when deciding which properties to link. That's because it is far easier to simply repeat the setting in score and part in cases where we don't link but you want them the same, than it is to fiddle with workarounds (invisible notes in other voices, fiddling with autoplace or other layout settings to compensate, etc) if we link something and it turns out you don't want it the same.
So I'd still personally recommend leaving this alone given there has not been any sort of clamoring for it. This suggests to me that people may actually be finding it useful to have independent control and thus aren't seeing anything to complain about.
In principle part of this is not even that hard with respect to properties. There is a big table of properties with a field saying whether it should be linked or not. The code doesn't really care for the most part, it just checks the table and either links or not. So providing some sort of dialog to override those defaults could turn out to be trivial. No doubt there are any number of places where particular properties are special-cased in the code would need to be handled specifically, or we just don't provide overrides for those
What's more involved and probably more useful, though, is providing a way to override linking behavior for individual elements as opposed to properties.
BTW, I would also observe that the "toggle rhythmic slash notation" command already does go through and make the corresponding changes to both score and parts. And that appears to be what the example posted was attempting to minmic. So in at at least this one common situation, the issue is non-existent in practice.
I appreciate the quick reply to such an old ticket. Given that this is obviously part of a larger philosophical discussion on overall software implementation, the workarounds are greatly appreciated. Please note that in my case, I am using note heads of various types throughout the score, not simply slash notation from start to finish.
In regards to the suggestion that composers appreciate being required to manually set note heads within individual parts (if the parts were created before the note heads were changed from default) due to the potential flexibility it provides, I would humbly encourage the development team to seek out concrete examples of such sentiments from real world users. Because, for what it's worth, there is at least one real world user who believes that this behavior is a bug.
Thanks for all your hard work in creating such an excellent piece of music notation software!
I wouldn't say people appreciate being required to manually set noteheads individually. I would say they may appreciate the option of having note properties in general be independent. Things like size of notehead, whether the note plays or not, all sorts of other properties can in fact quite often need to be controlled independently - I say this from my own experience, so I don't really need additional example. Of course, it's less common than wanting them in sync. But I would also observe that if you wait until you're done with that sort of adjustment to generate your parts - as I would almost always recommend anyhow - the properties do get copied over at the time of part generation. So I think most people actually seldom run into this as an issue.
Anyhow, as I said, given that the situation is relatively uncommon (only happens for manually adjusted noteheads as opposed to slash notation, only happens for adjustments made after parts are generated), the workaround is trivially easy, and changing the default would make it much more complex for the cases where you do want independent control, I still don't really feel a change in the default is warranted. But I absolutely feel an easy way to override this per-score if not per-element would be fantastic.
Comments
This bug is still present after five years. This bug ticket seems to have been made during the discussion on the comment thread linked above, but has never been addressed.
In the linked discussion, members talk about ambiguity on whether some note properties should be linked between the main score and the associated parts. There is no scenario I can imagine where a composer would want, for example, note head group to differ in this way. The fact that note head groups are not linked means that any deviation from the default requires duplicating the change on each affected part.
I cannot speak for all note properties, but at the very least, note head groups should always be linked between score and parts. To do otherwise defeats the purpose of using alternate note head groups.
Added an demonstration score replicating the bug.
Issue exists ever since linked parts got introduced, with 2.0
Workaround is to create the parts after having set those note properties, as these do get copied accross ion part creation.
OTOH the 'small' property surely is a layout thing and as such should not be linked. Notehead type though to me is content and as such should be linked
I would say this isn't a bug per se. As discussed in the forum thread, we really need to err on the side of caution when deciding which properties to link. That's because it is far easier to simply repeat the setting in score and part in cases where we don't link but you want them the same, than it is to fiddle with workarounds (invisible notes in other voices, fiddling with autoplace or other layout settings to compensate, etc) if we link something and it turns out you don't want it the same.
So I'd still personally recommend leaving this alone given there has not been any sort of clamoring for it. This suggests to me that people may actually be finding it useful to have independent control and thus aren't seeing anything to complain about.
Instead, though, I definitely think we should concentrate efforts on designing a way to provide user control over the defaults. I've been saying this for years of course - see #25248: Add ability to explicitly break links between linked staves/parts.
In principle part of this is not even that hard with respect to properties. There is a big table of properties with a field saying whether it should be linked or not. The code doesn't really care for the most part, it just checks the table and either links or not. So providing some sort of dialog to override those defaults could turn out to be trivial. No doubt there are any number of places where particular properties are special-cased in the code would need to be handled specifically, or we just don't provide overrides for those
What's more involved and probably more useful, though, is providing a way to override linking behavior for individual elements as opposed to properties.
BTW, I would also observe that the "toggle rhythmic slash notation" command already does go through and make the corresponding changes to both score and parts. And that appears to be what the example posted was attempting to minmic. So in at at least this one common situation, the issue is non-existent in practice.
I appreciate the quick reply to such an old ticket. Given that this is obviously part of a larger philosophical discussion on overall software implementation, the workarounds are greatly appreciated. Please note that in my case, I am using note heads of various types throughout the score, not simply slash notation from start to finish.
In regards to the suggestion that composers appreciate being required to manually set note heads within individual parts (if the parts were created before the note heads were changed from default) due to the potential flexibility it provides, I would humbly encourage the development team to seek out concrete examples of such sentiments from real world users. Because, for what it's worth, there is at least one real world user who believes that this behavior is a bug.
Thanks for all your hard work in creating such an excellent piece of music notation software!
I wouldn't say people appreciate being required to manually set noteheads individually. I would say they may appreciate the option of having note properties in general be independent. Things like size of notehead, whether the note plays or not, all sorts of other properties can in fact quite often need to be controlled independently - I say this from my own experience, so I don't really need additional example. Of course, it's less common than wanting them in sync. But I would also observe that if you wait until you're done with that sort of adjustment to generate your parts - as I would almost always recommend anyhow - the properties do get copied over at the time of part generation. So I think most people actually seldom run into this as an issue.
Anyhow, as I said, given that the situation is relatively uncommon (only happens for manually adjusted noteheads as opposed to slash notation, only happens for adjustments made after parts are generated), the workaround is trivially easy, and changing the default would make it much more complex for the cases where you do want independent control, I still don't really feel a change in the default is warranted. But I absolutely feel an easy way to override this per-score if not per-element would be fantastic.