Adding system-flag to text does not affect linked parts (or move text to top staff in score)
Priority
P1 - High
Type
Functional
Severity
S4 - Minor
Status
active
Regression
No
Workaround
No
Project
In a score with multiple linked parts, add a dynamic to the main score. Secondary-click it and select "Text Properties…". Check the "System flag" box. Expected behavior: the dynamic will be copied to all the parts (the same way it works if you first System flag the dynamic and then create linked parts). Actual behavior: it doesn't happen.
Comments
This applies to all text, not just dynamics - setting the system flag after both the element and parts already exist is too late.
Workaround is to create the element, then cut it, then paste it back. Or add one to your palette and place it that way.
BTW, setting the system flag also doens't force the element to the top staff of the score if it wasn't already there.
While I can see how this functionality might be expected given that we provide the ability to set the system flag in the firsat place, we *could* simply leave it as is for now and make clear it doesn't work. Which I mention because I have the sense that fixing this would be a not-small job.
Of course, if an element has the system flag and parts are created and If the user uncheck the system flag, I guess the expected result would be to delete the elements from all the parts but the one the text is attached to? That will be funny if the system flag is unchecked from a part which is not the one the text is attached to... the text will disappear...
This is definitely not major and my sense is that it will not make it into 2.0.
Yeah, I don't see an easy way of dealing with all the ramifications of this. On the other hand, we can't just disable the "System" flag checkbox outright. We could for "Text Properties", I guess, and maybe that's not a bad idea. For *Text Style* though, we it would need to still be in place if we are to allow people to create new styles or modify the behavior of styles, but it could not affect existing text, and is actually the only setting in that dialog for that is true. Maybe just a note to that effect in the dialog. Or, hmm, grey it out if it is currently in use for any existing elements.
Or just leave as is and document it...
Should the title be changed?
I don't think it's exclusive to linked parts?
Indeed, given my observation about not moving the text the text to the top of the score.
It occurs to me we *could* actually enforce something like what I described in #5. What if we disabled (grayed out) the system flag checkbox in both Text Properties and Text Style by default, enabled it on pressing the "New" button, and then disabled it again on Apply/OK? This would allow you to to set the initial state of the checkbox when creating a new style, but would wouldn't be able to change it later (since it won't work anyhow, that's the point).
I really, really don't like that idea. In fact, I can't even say how much I dislike it. You're saying that it doesn't work anyhow, but it does work, perfectly fine, unless linked parts have been added already. If you create the linked parts after you've set it to "System flag," it is copied into all the parts. Please don't take that option away!
But what about #3, what lasconic described? He's right about that "expected result." You said you "don't see an easy way of dealing with all the ramifications of this," but when you say ramifications you mean lasconic's simple expected results. And I don't think it actually would be all that "funny." It just makes sense.
I think perhaps you are misundersatand what I am talking about. Changing the system flag on an existing text style does *not* currently work correctly, whether or not parts exist. Try it and see. Setting the system flag on a text item attached to the third (say) staff does not magically move it up to the top staff, and adding system to text to the third staff then unsetting the system flag does not restore it to the third staff. It really truly does not work. I agree what lasconic describes would be expected; what I am saying is, it does not happen, and changing the code to make it happen would be a bigger change than I am confortable with at this stage, for relatively little gain.
So again, to be clear, I am proposing removing only a fucntion that does *not* work. By disabling the option for existing styles and enabling it only when initially creating a new style, the intended workflow becomes more clear: it you want a text style that has the system property set, you must create it that way from the beginning. And if you want an element to have this style, you must create it that way from the beginning. For instance, if you wish to have "system dynamics", create a new text style by that name, set the flag, create some elements using that style, add them to your palette, and use those rather than the standard dynamics.
Given that, again, it just doesn't work right now and isn't likely to any time soon, this seems a very small thing to ask for a function that is likely to be very rarely used anyhow (you are to my recollection the first person to bring it up in the several years these builds have been available). It just doesn't seem to be too limiting to say the system property has to be set you you create the element. Create the element correctly, and you won't have to change it. What's the big deal?
The alternative is we continue to provide a function that just plain doens't work. I don't see how that is preferable. All it will do is confuse people if they try to do it.
Another way of looking at it - think of regular and system text as just two different beasts. You cannot convert one into the other any more than you can convert a femrata into a staccato mark. If you enter one but later decide you want the other, simply delete the one and add the other. You wouldn't think twice about that for articulations, so having the same be true for text really should not be a hardship.
Well, if this is really the only way you see to go, I plead that you at least include a System Dynamics style out-of-the-box. For ease-of-use, keep it right next to the plain "Staff Dynamics" style in the list.
And—as it's not really viable to include two different versions of each dynamic in the Palettes (as there is a Staff Text and a System Text)—I would ask that, upon entering a dynamic, a dialog appears, asking, "Do you want this dynamic to apply to all parts? Yes/No". Is that too much to ask?
Once again, though: if, in a score, you create some *staff* text or a non-system-flagged dynamic—if you then secondary-click it, open Text Properties, and check "System flag"—and if you then open Parts from the File menu and create new linked parts—the text or dynamic will be present in all of them. No, it doesn't move it to the top staff of the score, but it does, in my definition, work.
I'm not really comfortable with MuseScore providing non-standard styles out of the box. What you are apparently trying to do with dynamics is simply not how music is normally published. If it were, then I'm have no problem with it. But as it is, it's a non-standard thing to do, so it makes sense to me that you should have to take a couple of simple extra steps to get that non-standard result if you really want it. And I am certainly very opposed with a dialog box coming up every time someone places a dynamic, asking them if they want to do a very non-standard thing with it. That would just annoy people for no good reason.
I agree that *some portion* of what system text is "works" if changing before parts are generated , but *only* a portion. Appearing in parts is but part of what it means for system text to "work" - it also has to behave reasonably in the score (appearing in the top staff, regardless of which staff happens to be on top - remember Hide Empty Staves). And in any case, as you have seen, it will only "work" even partially if done before parts are generated. So working only partially and even then only if you do things in a certian order is not really "working". That's why I think it wise to disable it. Plus, I don't know if you've looked at the code much, but there are any number of places where we assume that system text is in track 0 (eg, on the top staff). Making it easy to create scores that violate this is pretty much asking for a crash to happen down the road.
All that said, I'm just one member of the development team. If someone else thinks a different approach makes sense to pursue, that's fine.
The ability to make dynamics apply to the whole system—and be reflected as such when parts are created—goes back at least to version 1.1, which was current when I started using MuseScore. (Note that there was no question of affecting linked parts back then, because the parts weren't linked.) Maybe my usage is nonstandard. Forget the dialog. Disable the system flag checkbox. But what in the world is wrong with then including a "System Dynamic" style?
Is there anybody else who wants to weigh in on this? What do you think?
Yes, 1.1 had the ability to change the system flag, but it didn't work correctly there either - the dynamic remained attached to the original staff.
As for what is wrong with including a special style for "system dynamics", I guess nothing in particular. But I'm not keen on building in support for non-standard usages when there are perfectly simple ways of doing what you want. Really, the system flag is the wrong tool for the job, because as you've also observed, it breaks multimeasure rests. That's part of the point of the system flag too. What you really want are ordinary dynamics, but with some of them made invisible for whatever reason.
Anyhow, sure, I welcome other opinions too. But mine remains this:
Some day, sure, it would be nice to support changing the system flag and have it actually work correctly in all respects. But given that it is pretty far from working now, and it's not the right tool for the job anyhow, and there are better ways of doing the job that *do* work, and there's only about a week before the RC and far more important things to address before then, I'd rather see the development effort focused on those other more important issues. But I certainly won't argue if someone else decides to fix this now.
I've come around to agree with Marc on this. It does make the most sense simply to remove the option to add a system flag. So, if somebody wants to make the change, I won't object.
Just wanted to say again that I think you can go ahead and disable the system flag checkbox when not creating a new style, and an included system dynamic style is not needed.
came up again in https://musescore.org/en/node/286042
Worth investigating and either fixing or closing as "by design" and then removing any no-longer-relevant UI elements.
I know there is some concern about importing of 2.x scores that have the "system" flag set on custom text styles, would be good to at least figure that much out. See #282236: Custom text ignores system flag when imported into 3.x