Controlling links
There have been requests for control over what is linked between score and parts. So that one could have elements appear in the score but not parts or vice versa, or otherwise differ. I'm trying to understand what makes sense here.
Right now, most elements are linked so that adding one to or deleting one from the score also affects the parts. But many properties of those elements are *not* linked. So for instance, you can set an element invisible in the score and have it still be visible in the parts. That seems expected, but other properties one might expect to be linked are not - such as note properties like small, head group, etc, line properties like style, hook height, etc. Or maybe some *don't* expect these to be linked.
I don't actually have a specific problem with any specific choices made, but it does seem a bit unpredictable, and I know people do want more control. So like I said, I'm trying to figure out what makes sense.
I had been thinking mostly in terms of breaking the link between elements, to allow an element to be deleted in score or part without affecting the other, but now I'm realizing that perhaps at least as interesting would be provide control over how proerties are handled.
Thoughts?
Comments
Whether or not an element is linked is a property of that element I think. Exposing that property via Inspector should be the cleanest way of allowing to link / unlink / reset to default.
Other than that we should probably think about what a sane set of defaults are for the various element types or rather which of the current defaults are suboptimal. However, with a way to link/unlink these defaults become far less important
In reply to Whether or not an element is by Jojo-Schmitz
The thing is, you might well want the *element* linked (so deleting it from one place deletes it from all) but not certain *properties* of that element. So yes, a control to completely break the link for an element still amkes sense, but what I am realizing is that this might be be enough - what we might really be more interested in is control over individual properties.
There are various ways this could be modelled. We could have a page in the Style dialog, for example, that controlls the linking of each property where there is room for debate. Or, we could have something like "Select / All linked elements" command to make sure the linked elements are all actually selected, to ensure that changes in Inspector apply to all linked elements even for properties that normally are not linked.
In general, the current situation is that the issue tracker contains a lot of bug reports concerning linked parts, nearly all of those bug reports are to the effect of "links don't work for this type of element," and in nearly all cases it is agreed that the link should work, it is a bug, and it ought to be fixed.
The first priority should be to sort out all of these cases and make sure that there's a way to make the links work, and then have a conversation to decide which few it really would be better to leave unlinked. At that point, it makes sense to take a look at implementing a set of advanced controls, but I would not like to see the ideal delay the necessary.
In reply to In general, the current by Isaac Weiss
Well, I count less than half a dozen such reports, and I don't think there is actually enough data to say there "it is agreed that the link should work". At best, we can say that there exist cases in which some subset of users agree that linking a given property would be desired, but there may well be other cases where those same users might feel the other way around, or there may be other users who differently about the same cases. I'm not quite ready to say that just because my initial thought was that some givne propety should be linked, that means it absolutely should.
Here are the specific issues I have in mind:
#64636: "add to measure number" is not linked between score and parts after reload
#64641: Modfying the jump targets of jumps like D.S. are not linked between score and part
#69836: Changes to text line not reflected in linked parts
#72901: Brackets for accidental do not propagate to linked parts
Then there are a couple more that are more complicated - not just simple setting of properties:
#62416: Changes to staff transposition (and other properties) not reflected in linked parts
#57136: Adding new staff to existing instrument does not appear in linked part
Interestingly, no one has yet complained that changes to note properties like small / head group / etc are not linked.
In reply to Well, I count less than half by Marc Sabatella
Actually, a few months ago that caused me a huge hassle completing a concert band score, but I guess I never reported it. Shall I do so now, or would you like to?
By the way, I'm also considering fixed issues as still being present in the tracker, such as
#66076: When entering note too long for measure, tie not created in linked staves/parts
and
#67026: Parts do not pick up articulation applied with keyboard shortcut
—but you're right, "a lot" is something of an exaggeration.
In reply to Actually, a few months ago by Isaac Weiss
Well, if we consider *fixed* issues, sure, there are a lot, especially if we go back to last summer.
Feel free to file an issue about note properties, but do include a link to this discussion as I did for the other issue that turned out out to basically the same.
Anyhow, my point is not that we shouldn't change the behavior in any of these cases. Just that it do us well to step back and look at the bigger picture, really asking ourselves what is the expected behavior *in general*, and what makes sense to provide in terms of overriding whatever defaults we decide on, before changing any defaults for individual cases.
For instance, maybe we'd decide it would make for a more consistent / predictable experience if we just made it a rule that properties applied via the Inspector never affect linked parts by default. After all, that's definitely got to be the case for visibility and offsets. In which case, instead of changing the defaults for specific properties from "don't link" to "link", we'd concentrate on providing an easy way of overriding this default to force any given change - including changes to visibility or offset - to follow links.
Revisiting this. Over the summer I managed to implement a few of the things I had in mind for possible inclusion in 2.1. Of the things I had personally considered doing, something having to do with controlling links is really the one main thing left. With the school year in full swing, I don't have a ton of time so I'm not sure what I'd be able to do, but I'd like to spark some more discussion.
I'm looking for some real world use cases where people have encountered a need for more control over what elements or operations are linked between score & parts (similar question for links between staves within a score - eg, guitar standard and tab notation).
In reply to Revisiting this. Over the by Marc Sabatella
The first things that come to my mind are, in linked staves (standard staff / Tab staff):
![text.jpg]( "text.jpg")
![ligne texte.jpg]( "ligne texte.jpg")
![hairpins.jpg]( "hairpins.jpg")
- text lines (and straight lines)
- hairpins, and crescendo / decrescendo lines.
Among the publications that I consult, I do not see this kind of duplication, eg.
Text lines:
Hairpins:
In reply to The first things that come to by cadiz1
That is good feedback, but maybe I should be more clear. I'm not looking for suggestions for how specific elements should be treated by default. I'm looking for suggestion on what sort of controls should be offered to *override* the defaults.
So for instance, here, I might guess you are suggesting you'd want a control that would specify what types of elements get linked for any given staff. Something sort of like the Selection Filter, perhaps - a lsit of element types with checkboxes. That's one possibility. But I'm also wondering if there are real world use cases where you might want *some* elements of a certain type linked, others not. So in that case, something more like a single button in the Inspector to break a link might be preferable.
But also, there are questions about what exactly it means to break a link. Does it mean deleting the element from one staff does not delete it from the other? Or just that *changes* to the element in one do not affect the other?
In reply to Revisiting this. Over the by Marc Sabatella
I posted some thoughts about property linking in this post on MuseScore dev mailing list .
My main point is that the score part <=> separate part link is potentially on the "link all" side (with some exceptions), while the link between two different staves in the same score is potentially on the "link only something" side. and that the two types of links should probably be separated.
Just a starting point for thought, however, to be greatly refined.
In reply to I posted some thoughts about by Miwarre
Yes, I saw that and responded there with a couple of very general observations. I agree the defaults probably should different in some/many cases between the linked parts case and linked staves within a single score case. But I would assume the overrides that are provided should be of the same type - whether a control in the Inspector, or Style options, etc.
In reply to Yes, I saw that and responded by Marc Sabatella
Yes, I saw your reply and appreciated it.
_________________
About how to control "individual" linkages, there are at least 3 different scenarios:
1) "individual" means specific for a single element type but, in it, applying to all elements of that type in all staves; turning on/off this linkage has to be almost by necessity a score style parameter.
2) "individual" means specific for a single element type but, in it, applying to all elements of that type only in certain staff types; cadiz1 example above seems to refer to this case: "do not link hairpins onto tab staves" (but link it onto other types of staves); turning on/off this linkage has to be a staff type style parameter.
3) "individual" means specific for a single element, not to be generalized in any way; turning on/off this linkage has to be in the element specific data (which presumably means the Inspector).
_________________
1) and 3) of these scenarios can happen in 2 kind of contexts:
A) "link" means linking a score part to its separate part (and necessarily vice versa?);
B) "link" means linking a score staff to another score staff;
( I think 2) - link across different staff types, can only happen in scenario B), as a score part and a separate part are necessarily of the same type (at least, I believe so).
_________________
So, we have a grand total of at least 5 cases:
1A) all elements of a type between score part and separate part;
1B) all elements of a type between two staves whatsoever of the score;
2B) all elements of a type between two staves of given types of the same score;
3A) single element between score part and separate part;
3B) single element between two staves of the same score.
Of course, this assumes that the normally supported case is a binary link (any staff can be linked to another single staff only); if a staff is allowed to link to several other staves, cases grow exponentially!
In reply to Yes, I saw your reply and by Miwarre
Currently none of the limitation you mention applies.
1/ A staff can be linked to another staff in the same score and to another staff in a parts. The 3 staves are linked together.
2/ A standard staff in the score can be linked to a standard staff and a tab staff in a part if the user imports a guitar pro file. We don't have a UI to create this kind of scores though.
Also, about individual, there is a 4th level, between 2 and 3 probably. The staff level. An element type in a given staff.
With this, I think we cover most of the cases but the challenge will be to pick only the most interesting ones depending on use cases, because adding UI and code for the 4 cases will not be user friendly.
In reply to Currently none of the by [DELETED] 5
Yes, I am definitely concerned about the complexity of handling every possible case.
Which is is why I am really concerned with real world use cases. So far, with the possibility of marking elements invisible in one instance but not another, it seems to me anything I personally care about is covered, so I'm still trying to understand what use cases others might have.
The one example that I know has come up is the possibility of having cue notes in the parts but not the score. I'm not quite sure how that could be pulled off, as an underlying assumption has been that we would not be talking about unlinking the actual notes. But, I could imagine a measure property that could be set to force a measure to display as empty even though it is not.
In reply to Yes, I am definitely by Marc Sabatella
The mention of cue notes (i.e., small notes) reminds me that nobody had created this issue yet: #82566: Note properties (small, head group, etc.) not linked between score and parts
In reply to Currently none of the by [DELETED] 5
"Also, about individual, there is a 4th level, between 2 and 3 probably. The staff level. An element type in a given staff.": on the spot I cannot see in what this would be different from case 2B) above; could you elaborate?
In reply to Yes, I saw your reply and by Miwarre
A possible approach simplifying both the UI and the code, at the cost of more user manual work in non-standard cases could be:
PropertyData::linkflag (see https://github.com/musescore/MuseScore/blob/master/libmscore/property.c… ) into two:PropertyData::linkInScoreto control property linking between staves in the same score (typically, standard+tab) andPropertyData::linkAcrossScoresto control property linking between staves in different scores (typically, score part and separate part)and set reasonable default (to be decided, but easy to fine tune during development) for either flag of each property.
PropertyData::linkto check the within-score/across-scores link type and use either flag accordingly.By carefully choosing the default flag values, it is possible that a fair lot of cases could be managed 'automagically', reducing the cases when the user would have to manually use the Unlink command.
On the spot, I cannot figure out if the opposite function Re-link to rebuild a removed link would be really necessary (beyond the mere Undo, of course and in addition to removing and re-adding the unlinked element); possibly not?
Would it make sense?
In reply to A possible approach by Miwarre
About the staff level:
* Applying to all elements of that type only in a given staff
About your proposed implementation.
3. What would be the added value of Unlink compared to the current workaround of Make Invisible?
1.2. I like very much that the exact same mechanism is used for all linked staves, across or in scores. I understand what it would buy us to split the link property but just like Marc, I would like to see specific use case that are not currently covered before any implementation work. There are dozens of possible implementations, from local unlink function to score wide style for each element type but which one is really useful?
In reply to About the staff level: * by [DELETED] 5
General observation I: "having the same mechanism for all linked staves" becomes both just a petitio principii and a source of problems once "linked staff" is defined as encompassing different things like it does now.
General observation II: looking at the examples of bug reports about linking quoted above, several seem related not the link/unlink issue, but to the fact that a link, once established (and in these cases the agreement is generally that the link should be there in the first place), it is not updated if either side is modified. This is a different aspect (related, but different) from discussing what should be linked or not and where or not in the first place.
Some use cases (including those quoted above) of elements which make sense to be linked between a score part and its separate part but not (or not necessarily) between two staves (of different type) in the same score
Group A):
- text lines
- cresc., dim. and their symbolic equivalents (I am not entirely sure about these, but I tend to trust cadiz1 experience on this)
- fingering
- articulations.
Group B):
- beam mode
- ornaments
- ottavas
- transposition (or details of it)
Note that group A) can in principle be addressed by making things invisible (dumping on the user quite a deal of manual work, which could easily be automated), while group B) cannot: they are not simply ON on one side and OFF on the other, but they are (or might be) different between the two sides and a manual "invisibility spell" would not solve the problem.
Note also that I personally do not use linked staves so much (practically never linked staves in the same score and rarely the separate part mechanism); so I may easily miss other relevant cases; users relying more on this feature(s) may have more examples (and are kindly invited to express them!).