Appending anything always goes in wrong spot
I consider this a bug although seems like it's an oversight.
When you want to add (insert or append) a feature like a measure or horizontal or vertical frame,
you define where to insert it by highlighting a measure as a reference point.
However it does not work as expected - while insertion does work and the feature inserted in front of the highlighted measure (not at the very beginning of the score), appending a feature does not append it
immediately after the highlighted measure, and always appends at the very end of the score.
This can be worked around by highlighting the "wrong" (next) measure and inserting in front of it, resulting in appending after the measure you really want to get appended after, but that's messy and requires editing measure's contents.
This has to be fixed.
Any comments?
Thank you.
Comments
Indeed appane, does append to the end of the score, that much is by design.
But that design is under discussion, and an Insert at front as well as an append to selection might come woth MuseScore 4
See #244381: Add options for "Append to current measure" and "Insert at beginning of score", for measures and frames
It's not clear what you mean about being messy and requiring editing though. Should work perfectly. Except - whether appending after a measure, or inserting before the next, if there is a clef / key / time signature change at that exact point, then MuseScore will need to guess which one should apply to the new measure. Adding a new append-after-selected measure won't magically make MuseScore guess correctly, but if the behavior is such that appending does it one way and inserting does it the other, then at least you'd be able to choose between the two commands based on which result you want. Other than that though - where there is no clef/key/time change at that point there would be no difference whatsoever, no editing required.
In reply to It's not clear what you mean… by Marc Sabatella
To me that's the difference between append after slection and Insert before selection, in the former case keep the current selection's key and time sig, in the latter take that selection's changed one.
So no need to guess here. And same as with Append to end or Insert at beginning of score.
In reply to To me that's the difference… by Jojo-Schmitz
If not for the fact that fixing this after the fact is a bit of a pain and thus it makes sense to have different behaviors, I'd actually expect the two to behave the same, honoring the previous clef / key time signature. I compare to things like inserting characters in a word processor at the point of a format change. I think of the cursor as existing between characters, and change as happening after that, so typing characters gets the previous formatting. The distinction between appending and inserting seems pretty artificial in that world, and intuitively would to me here also - again, except for this practical matter, for which I could learn to pretend it's relevant.
In reply to If not for the fact that… by Marc Sabatella
That is what Insert does and should do.
But not what Append should do. Else an Append to selection is nothing but an Insert at first measure after selection, and as such pretty useless (but certainly easier to implement)
In reply to That is what Insert does and… by Jojo-Schmitz
Actually, that's not what insert currently does - quite the opposite. It inserts a measure with the new, not the old, clef / key / time signature. Which is, I'd suggest, as it "should" be if there is to be a distinction. But again, it's exactly the opposite of how most word processors I know work, where it's normally the old formatting that gets applied when inserting new characters at the point of a formatting change. So that to me is what's intuitive - regardless of what you call the command, adding a measure between two existing would be expect to take on the old properties, not the new ones. just as happens in word processors.
So, again, my point is that if not for this special situation, it would be useless to have two commands, and that's why it doesn't exist already (and why I'm not aware of any word processors that provide multiple commands for this). The "intuitive" behavior would be the same as a word processor, which is the opposite of what it is now. To me, this is a case where what's intuitive and what's actually useful are at odds here. I think (?) we all agree that the current insert-before behavior makes sense to retain even though it's not intuitive based on experience with other programs. Then the new append-after command should do what actually would have been intuitive.
In reply to Actually, that's not what… by Marc Sabatella
It is what it does for me: selecting a measure with a key- or time signature or clef change, pressing Ins and it inserts a measure so that the now new measure has that key- or time signature or clef change.
What I'd like it to do is if I select the measure before that and Append to selection, that this nee measure keeps the time- or key signature or clef that is in effect for the selected measure
Actually keep the time- or key signature or clef that is in effect for the selection in any case, for append and for insert.
In reply to It is what it does for me:… by Jojo-Schmitz
Right - currently, it does the exact opposite of what it does in a word processor, where it would the formatting in effect before the change that wins out. We are proposing keeping this non-intuitive behavior for the insert command, but adding a new command to balance it by don g what many users would have expected the current command to do, and hoping that users will figure out which command to uses for which case. It’s not a bad idea, but let’s be realistic: most users will not somehow magically “intuit” this difference, given they have encountered it exactly zero times in their entire lives previously.
In reply to Actually, that's not what… by Marc Sabatella
Except that your comparison with word processor is invalid:
In word processor, like you said your cursor can be "between" formats change.
While in MuseScore your cursor is "on" an object in a measure with, e.g. a clear time signature.
So from that selected object there is no question about what the correct behaviour must be: both insert and append must use the time signature in force at the selected object (and apparently will do so in V4, great).
If the cursor could really be "between" formats like in word processor, then yes there would be a potential question on which one to use for insert/append operation and like you said the logical thing to do if we want to align with word processor would be to always use the previous format.
In reply to Except that your comparison… by frfancha
I agree it’s not directly comparable because the cursor isn’t between measures. I’m just saying, people don’t come to MuseScore with a predetermined set of expectation around this, because they’ve probably literally never experienced a situation where this distinction exists in their entire lives. It’s only in hindsight - after using music notation software for years as you and Jojo and I have - that it becomes even possible to talk about expected behavior is based on these differences. For everyone else, I think I the word processor analogy will hold, and people will need to be taught the difference - it won’t feel as “intuitive” as it does in hindsight to old timers like us.
Which isn’t a reason not to do this. Just to point out that there is a need to be sensitive to differences in expectations based on previous experience, and that this has implications for design, documentation, and support. Pretending that simply adding the append-after command solves the problem in a way that would be equally “intuitive” for everyone is unrealistic.
In reply to I agree it’s not directly… by Marc Sabatella
Thanks Marc,
My situation with editing is inability to append a horizontal frame immefiately after a currently selected measure (unlike inserting it right before such measure, not at the beginning of a score, which is I hope you agree, seem inconsistent, either by design or not). Reasonfor doing this is to have some rows of meadures not extending all the way across the page, but cobtinue on a line if previous group of measures logically ends with only one or two from the left. You can sure squeeze more measures in a row, but for students it is far easier to stick to s grid where there are always, say, 4 measures in a row.
I can get around this limitation with several more clicks, and msy be no need to introduce a new command. Ir would be enough to have a check box in general prefetences one can tick an option "Append after selected feature rather than to the end of score".
Then this behavior will be set as a default until changed. Everyone is happy.
Just a suggestion.
Thank you,
Victor
In reply to Thanks Marc, My situation… by VT
Generally speaking, adding a preference that changes how a command works is not considered good design, much simpler and more useful is to add a second commend.
In any case, if I am understanding correctly, I don't see how a new command to add a frame would help in your case. I assume you currently have a system break on the measure you'd be appending after. So, now you'll have a frame after the system break - so, still on the next system, exactly the same place it would be if you used the insert command. So either way you need those few extra clicks to remove the break on the measure and add it to the frame instead. Probably a plugin could automate this if someone wanted to.
If that isn't what you mean, please attach a score and explain the issue in more detail.
"This has to be fixed"
Really? Append = add to the end, so seems to work fine for me.