Actions that should and shouldn't apply to linked elements in part extracts
I'm curious about what adjustments/property modifications etc. that are made to an element in the full score do and don't apply to linked elements in any part extracts.
I do understand that some adjustments don't necessary make sense to transfer, whereas others might or might not depending on what the user wants to do. A classic examples would be "visibility" - if you're adding an element just for playback purposes and don't want it shown, you'd want its visibility to be the same between the full score and any extracted parts. But if you're changing the visibility because there are certain directions that have to appear in all parts but don't need to appear against every staff in the full score (an obvious example being when you add "staff text" above, say, the first 1 violins in the full score to duplicate tempo markings etc. that are otherwise only shown above the top staff) then you need the ability to change properties in a way that allows them to differ between the full score and any parts.
Whereas, for instance, something like changing the line style (dotted vs dashed etc.) I would think would almost always want to be applied to both the full score and any extract parts (but isn't currently).
But surprisingly even something like which note an element is associated with is not always the same between the full score and any parts - e.g. it is for lines (start and end), but not for dynamics (which seem to be one of the few types of "text" element you can drag around and re-attach to other notes).
Is there a way to force alterations made to the elements in full score to be apply to parts (or v/v)?
Is there any documentation around what alterations do and don't get applied to both?
Comments
The only documentation for this is in the source code, the
struct PropertyMetaDatain [property.cpp lines 52-58]https://github.com/musescore/MuseScore/blob/b2e227e8887478adceb3d80926e…), esp. its
linkelement and the initialisation ofstatic constexpr PropertyMetaData propertyList[]below that, in the lines 68-389In reply to The only documentation for… by Jojo-Schmitz
Hah, that's my favourite line to anyone asking where various settings/configuration properties are documented - "it's all in the source code!". After all, it's the only place you can be sure is actually correct/up-to-date!
But yeah, I had access to that, just wondering how regular users are supposed to know what to expect.
In reply to Hah, that's my favourite… by Dylan Nicholson1
The line to draw is between content and layout. Everything that might be seen as layout is not synced, everything that surely is content is linked. As we can't break the link, we're staying on the conservative side and rather do not link in cases where it is not 100% content
In reply to The line to draw is between… by Jojo-Schmitz
But which note a dynamic is attached to is surely not layout, yet isn't synced...
Likewise whether a note is stemless (or small size) wouldn't seem to be layout, but isn't synced (I'd certainly be curious in what case you'd want a note to be, e.g. full-size in the full score but cue-size in a part. Obviously if the cue notes are for another instrument you'd want that, but that's not the same thing, as those notes will simply be invisible in the full score). Even note-head groups aren't synced (I can see a case you mightn't want note-scheme to be synced, but not so much whether a notehead is shown as a diamond etc.).
It does seem reasonably easy to re-sync everything by just copying from the full score and into the part (or v/v) at least.
In reply to But which note a dynamic is… by Dylan Nicholson1
That sure is content, yes. The dynamic's position, relative to ist anchor, and its velocity is would be layout
Stemless or small notes are layout though
In reply to But which note a dynamic is… by Dylan Nicholson1
Dynamics aren't attached to notes, they are free-standing annotations to the segment. I guess you are referring to what happens when you drag a dynamic from one segment to another. This actually re-parents the dynamic to a different segment and as such this should absolutely affect both score and parts. Seems a pretty major bug that it doesn't. In fact, that breaks the link completely - making changes to the text doesn't affect the part either. Looks like it does at first, but it doesn't survive save/open.
In reply to Dynamics aren't attached to… by Marc Sabatella
Yes I understand internally it's not actually attached to the note itself but from a user perspective that's how it appears to behave.
I'm now more curious why you can't seem to do the same for any other sort of text object (I'm just as likely to need to change which segment a "ten." or an "a 2" marking belongs to, yet I haven't figured any way of doing so).
I'll have a look at that dynamic re- parenting issue.
In reply to Yes I understand internally… by Dylan Nicholson1
Actually I can see from the source code that dynamics are the only elements at all that even support the internal ChangeParent operation (there are a lot of other calls to setParent, but none are part of undoable-action).
I'm assuming to fix it you'd have to work out the time difference between the old and the new parent and find an appropriate segment in any link parts to reparent their linked elements to (there's no links between the segments themselves as far as I can tell).
The bug with saving/reloading a score where the dynamic text has been edited is actually unrelated and occurs even if you don't reparent, and appears to simply be that the internal "dynamicType" property doesn't get updated for linked elements in Dynamic::endEdit, and when saving a dynamic the xmlText is not written out unless the dynamicType has been set to "OTHER", so that's a trivial fix.
In reply to Yes I understand internally… by Dylan Nicholson1
The reason you can't reparent other text markings is that when this was implemented for dynamics a few years back, it proved to be extremely unpopular among users, who wondered why a simple manual adjustment to the position of a dynamic ended up moving it to another note or even another staff entirely. Frankly, it should have been scrapped entirely even for dynamics based on the user feedback, but for whatever reason, it wasn't.
Now that (some) lines now allow anchros to be changed when you drag, it is conceivable we might want to revisit this for other markings as well. But with hairpins in particular, the initial change, while it seemed logical enough, also proved quite unpopular, as it made it really hard to adjust the endpoint without changing the anchor. We then added code so that Ctrl+drag would allow the fine tuning of position without changing anchor. Something similar should probably be done for dynamics, and perhaps other text, but then againthe need for Ctrl is hardly intuitive. So really this needs a better design to begin with. Choosing Ctrl was just a stop-gap to address the flood of complaints when the automatic anchor-changing facility was added.
In reply to The reason you can't… by Marc Sabatella
Whereas I find it quite frustrating that you can't re-parent other text elements!
I wouldn't necessarily expect to be able to reparent across staves though (and my preference would actually be to use the keyboard).
I can see how re-parenting would be annoying if it did it too readily (e.g. the moment it thought the element was closer to one note/staff than another), but it doesn't - it actually works pretty well, you have to drag the element all the way to the left coordinate of the next (or previous) note for it to re-parent, though arguably it'd better with a few extra pixels leeway, and likewise to change staff you have to drag it completely onto the new staff. Actually there is ONE case it has an issue, where you drag over a barline - it re-parents the moment the element slightly crosses it. I'd say that needs to be fixed (I don't see why it should treat barlines as a special case at all).
Ctrl+Drag doesn't prevent re-parenting, it just prevents vertical adjustment as per other element types. Ctrl+Shift seems to do so, but you must press them down AFTER you start dragging (otherwise you can't drag at all).
Personally I think this behaviour is fine, but one possible alternative would be to allow first selecting an element to show the anchor lines, then dragging the anchor points. The way slur grip handles reanchor is interesting too but not really suitable for elements that can sit far from the note heads.
In reply to Whereas I find it quite… by Dylan Nicholson1
Sorry I realised your comment about Ctrl+Drag referred to hairpins (and some other lines like trills) which seem to be a special case where Ctrl+drag does mean something different for the start and end grip handles (in fact it both restrains vertical dragging, even for hairpins with "allow diagonal" on, AND prevents re-anchoring). Ctrl+Shift+Drag also works though, allowing free movement in both directions but preventing re-anchoring, and for hairpin handles doesn't require you press Ctrl/Shift after you start dragging.
The problem with over-eager re-anchoring when you drag over a barline is present for lines too.
In reply to Whereas I find it quite… by Dylan Nicholson1
Dynamics re-parenting is too aggressive, by a lot - in any sufficiently crowded score, it's virtually impossible to drag dynamics anywhere without re-parenting kicking in. And it's truly disastrous in many cases where it actually moves the dynamic to another staff entirely. I've personally never encountered the barline case, but every score is different, and for pretty much any but to most trivial scores, the re-parenting is way too sensitive.
There are cases where it's useful to reparent though, and yes, that applies to other text. So somehow it would be great to have a design in which both actions are easily discoverable and easily performed. So far, I don't think anyone has proposed such a design.
For Ctrl+drag, to clarify - I'm talking about hairpins specifically, zCtrl+drag does suppress the re-anchoring. We implemented that after the initial re-anchor feature led to so many complaints, but again, more of a stop gap. Ctrl was chosen because we use that elsewhere to make changes "local" (eg, for applying barlines, time signatures, and key signatures).
In reply to Dynamics re-parenting is too… by Marc Sabatella
I specifically tested dragging dynamics with a very crowded full orchestral score and the only time it re-parented unexpectedly was dragging across a barline. If you have a portion of a score you're willing to share here and an example case of a dynamic getting reparented over aggressively I'll see if I can figure out why.
In reply to I specifically tested… by Dylan Nicholson1
Interesting, I've never noticed the connection before because I long ago gave up on dragging things as a way of making adjustments, but indeed, it does seem to be proximity to measure start/end specifically that seems to trigger the issue the most. But not exclusively by any means. Here's a trivial but very typical example (MSCZ attached):
As I related elsewhere, I think recent refinements to reduce the likelihood of changing staves have cut down on that issue. But still, it's virtually impossible to drag that dynamic far enough to either side to allow the extra space to be closed up in cases like the above.
In reply to Interesting, I've never… by Marc Sabatella
Yeah fff is the sort of dynamic that's more likely to re-parent when you don't want it to, due to the width.
But in that example it's surely the barline that's the problem, as I said, I don't know why it has special logic around crossing barlines at all.
If there was a keyboard shortcut for re-parenting I'd use that in preference, but other than Ctrl+X arrow Ctrl+V (whereby you have no idea what the result will be until you paste) there doesn't seem to be one.
At least Ctrl+X/Ctrl+Y ensures the linked parts are correct too, deletion & creation seems to be pretty reliable between linked scores.
In reply to Yeah fff is the sort of… by Dylan Nicholson1
It's not only the barline that triggers problems, same issue occurs mid-measure but not quite so severely. Reduce stretch a notch in that measure of switch to sixteenth and the same difficulty occurs. I promise I'm not making this up, or the many complaints we've received about this over the years. Some of those complaints come directly from people who recognize what happened, some are in the form of "why doesn't my score play correctly" that turn out to be dynamics that were accidentally reparented during an attempt to drag them for layout reasons.
For reparenting, cut/paste works just fine, not sure what you mean about not knowing what the result will be?
In reply to It's not only the barline… by Marc Sabatella
I just mean that cutting makes the element disappear so you can't get any feedback on where it will be (and what it might clash with) before pasting it back.
Anyway I readily accept that there are times you may need to override re-parenting, and it IS possible now (albeit via a rather non-intuitive method), but with a few tweaks the existing algorithm would produce what I'd expect 95% of the time when dragging a text element between notes/rests in the score - so it's extra frustrating that there appears to be no way to even force it to do so (other than creating all your text directions as dynamics!).
In reply to I just mean that cutting… by Dylan Nicholson1
When I'm re-parenting a dynamic, it's no different from just adding a new one - I don't care at first exactly what the layout is, I want it to appear with that note because that is the first note I actually want it to apply to. Then I worry about if I want to make manual adjustments.
Anyhow, if you have a design to propose for how re-parenting might work for other elements without causing the sorts of problems that exist for dynamics, feel free to post it. But it definitely would need to work a lot better than it does for dynamics in order for me and the many others who have complained about or otherwise been bitten by the dynamics behavior over the years to see it as an improvement rather than an annoying step backwards.
In reply to When I'm re-parenting a… by Marc Sabatella
Pretty straightforward - I'd have all text objects automatically re-parent on regular dragging the way dynamics do now but a) remove the special logic for dragging over barlines b) use the relevant left or right edge of the element rather than its centre to determine when to re-parent c) fix Ctrl+Shift so they can be held down before you begin dragging if you definitely don't want to re-parent.
In reply to Pretty straightforward - I… by Dylan Nicholson1
Again, for me, if the mere act of dragging reparents, it's a step backward. In my opinion there should be a special modifier or button or something to enable this and allow dragging to continue to perform the much more common operation of manual positioning.
In reply to Again, for me, if the mere… by Marc Sabatella
How is it a step backwards, providing the logic is such that if you drag an item so that if it clearly to a human performer now could only apply to a different note/rest than it did originally, the visual connection should match the underlying connection in the score?
The "more common" operation might by manual re-positioning, but that's fine, most of the time you won't be moving an object far enough that it will be re-parented.
What surely should be "hard" to do is what happens currently, which is that an element can internally/invisibly belong to something that's completely on the other side of the page. And remembering to hold down two keys while dragging isn't exactly a major hurdle...
In reply to How is it a step backwards,… by Dylan Nicholson1
There are all sorts of reasons one might want/need to move a text element a significant distance left or right from the note it is attached to, especially for longer texts. Human musicians can use context and common sense to help them understand what is going on on a case-by-case basis. MuseScore cannot.
It's possible that changing the logic to use left or right edge depending on alignment would help enough to make this issue not come up so often, although there would still be cases of centered text to contend with. And I'd still want to see it in practice with usability studies involving real users and real world scores to get a better sense of whether the reparenting would still feel as over-aggressive as it currently does.
The point is that the most common operation needs to be the most discoverable, the less common one is the one that should require the extra effort. Otherwise you end up with people accidentally doing the wrong thing over and over. We've made that mistake in our design far too many times in the past - something seemed "logical" but real world use proved otherwise. I don't want to see that mistake repeated here. If truly it works out that usabilities studies show the danger of accidental reparenting is less than the benefit of the automation in the cases where you actually wanted the reparenting, then great. But my gut feel here is that the number of cases where you want the reparenting is probably well under 10%, and no matter how clever the algorithm, the danger of accidental reparenting is probably well over 10%.
In reply to There are all sorts of… by Marc Sabatella
And I would strongly argue that 9 times out of 10 if I drag a text element left such that its right-edge moves to the left of a previous note/rest, then I clearly intend it to apply to that note/rest (or an earlier one still).
I've looked through a large number of scores and I can't find a single instance with anything like:
In fact using the test that right edge must be to the left of a note/rest to re-parent to an earlier note/rest is likely to make re-parenting to an earlier note/rest somewhat awkward 50% of the time - you'd likely need to drag it further than necessary then drag back to where you want it. It's less of an issue dragging right (though this is only true for languages with left-right reading direction).
In reply to And I would strongly argue… by Dylan Nicholson1
I can see one problematic scenario, where the user adds a descriptive tempo marking, then adds a metronome marking and wants it next to the descriptive one:
I will say the the nature of the default set of tempo markings available in palette seems likely to encourage users to do exactly this. Potentially there could be special handling for cases like this too, though arguably it's better to ensure users realise it's better done as a single tempo marking containing both the descriptive text and MM marking. In fact I quite like the idea that if I add a MM marking from the palette to a note that already has a tempo marking, it just inserts it into the existing marking rather than creating a new one.
In reply to I can see one problematic… by Dylan Nicholson1
BTW...it just occurred to me to lookup why the abbreviation for Metronome was "MM", and apparently it actually stands for "Maezel's Metronome", so there you go. Been reading scores with MM=100 for decades and never thought to check until now!
In reply to I can see one problematic… by Dylan Nicholson1
And no need for that, you can have a single Tempo text of "Andante (quarternote) = 80", that'd be less confusing (to the playback engine, mind that both tempo texts might have a different BPM set) anyhow
In reply to And no need for that, you… by Jojo-Schmitz
Yes, I made that point, but it's not obvious how to do for a first time user. I'm willing to bet a significant % of less experienced users try to do exactly what I described, first adding a descriptive tempo then adding an MM marking.
In reply to Yes, I made that point, but… by Dylan Nicholson1
Reading that, I think of a useful new feature:
A setting that displays a grey dotted line between each of the items attached to a chord/rest and their corrsponding chord/rest.
Like the pink line that you show in your examples. That setting would display all these "attaching" lines, not item by item.
Or such a feature already exists perhaps ?
In reply to I can see one problematic… by Dylan Nicholson1
That's but one example, yes, Tons of similar ones that come up regularly in day to day usage, not just to fix mistakes like having entered it incorrectly the first time, but as legitimate uses for which there really is no other method than manual adjustment. That's why to me it is important not to break this just on the off-chace that someone might enter a text on the wrong note and then for whatever reason ry dragging it rather than re-adding it correctly.
In reply to Hah, that's my favourite… by Dylan Nicholson1
Ideally, we get the defaults "right" so the average user doesn't have to know how it works - they just find it does.
In practice, indeed, that generally means content is linked, layout is not. Another general principle is that when in doubt, don't link, because it's far easier for a user to duplicate an element or property setting if we default to unlinked and they want it reproduced, than it is to somehow fake the converse (eg, adding an extra element, making it invisible, hope that doesn't mess up anything else).
But there has been a lot of fine-tuning of details that has taken place over the years in response to user feedback about specific properties here and there that the consensus agreed was formerly on the wrong side of those lines. And a few open issues in the tracker where there does seem to be consensus a given property should change but it hasn't happened yet - sometimes for compatibility reasons.
Ultimately we want to support a more robust system where we link more by default but give the ability to break links where desired (and possibly vice versa, although that's considerably more complex and less clearly needed).
Dylan Nicholson1 wrote >> Is there a way to force alterations made to the elements in full score to be apply to parts (or v/v)?
Is there any documentation around what alternations do and don't get applied to both?
I have not found command/function that forces non-sync properties into parts or visa versa. And I was just about to request one.
Additionally, I'd like to see a similar feature for Linked Staves. In other words, a command that forces property changes made in one linked staff to occur on the other linked staff.
There is pertenant existing discussion here and here: #322562: Request to synchronize note playback properties by default once it becomes possible to unlink them on command
scorster