Odd paste behaviour using piano Grand staff plus

• Mar 2, 2017 - 00:17

I am writing a score in 2.0.3 3c7a69d copying parts from a tune I wrote in 1.3.

I started with the piano part and added a flute and a trombone part above and a bass part below. I have made a number of modifications and am not rewriting the piano part. There was more than one voice, but I don't need that anymore so all of those bars have been erased.

The new piano part is a simple rhythmic/harmonic riff repeated for 4 or 8 bars.

So, I write one bar and then I copy it in the required number of bars, using the arrow key to move to the next bar after pasting (or copying).

What I expect to see is the pasted bar to paste in the grand staff.

However, the cursor moves in the bass clef of the GS., and so the treble part of the bar is copied to the bass parts of the GS. and the bass part is copied into the Bass part below the GS.

This happens no matter how the bar is selected, either selecting the notes themselves or the 2 staves of the bar, no matter the order.

This is a bug as the program should understand that we are dealing with a grand staff and should act accordingly.

Regards,


Comments

This isn't a bug. You need to put the cursor on the treble clef to paste. The paste destination starts where you paste, not where you copied from.

In reply to by Jojo-Schmitz

There seems to be confusion, so I will try to be clearer:

This is about copying a bar in a grand staff.

To select the entire bar requires clicking on both the treble and bass parts of the bar.
Once the full bar(s) is selected, moving to the next bar using the arrow key is the way to get to the next bar without using the mouse.

When one does that, the active part of the bar is in the bass clef, therefore when the paste is invoked, the information is place with the treble part in the bass and the bass part in the unrelated staff below.

The active point is in the bass clef no matter what order or method the full bar(s) are selected.

It is my contention that the active point should be in the upper clef, not the lower clef.

In reply to by xavierjazz

I would agree with xavierjazz, but maybe it's more a feature request as a bug if you want to copy notes/measures from more than one staff?

The same behavior if you select elements with shift+arrow key down. Normally I would start with the staff above and select then the next staffs below. If I using then the arrow key right and paste it would be more in sense of usability when the next element in the first staff would be selected.

In reply to by xavierjazz

You can select a section of music by clicking the last note and then the first note. If you copy and paste it, it still gets pasted in the same order as it was originally in the score.

If you select one note (or measures or measures) above another it doesn't matter what order you selected it in, the one on top is going to be on top when you paste it. A staff is a staff. What if you were pasting it to the 2nd violin and viola (a very realistic example). This is not a grand staff. Do you expect the paste to fail since it's not on a grand staff? No, you expect the treble to be pasted in the 2nd violin (in a normal score) and the bass in the viola.

As the left end of notes aligned vertically get pasted on the left, the top measure horizontally gets pasted on top.

In reply to by xavierjazz

I get that in this particular use case, it makes sense that Shift+down should extend the selection downward but still leave the "active point" in the original staff. You are trying to copy music from the same set of staves to another places on the same set of staves. But there are an equal number of use cases where the opposite is true - where you'd want the active point to follow the selection downward. Like if you are copying a passage to the same point in time on different staves.

In reply to by Marc Sabatella

I never tried "shift/down".

One point is that we are dealing in this case with a Grand staff, and as such it makes sense to have the active point in the upper staff at all times.

As to whether or not it is a bug, I don't see that as important. It is the behaviour that is important.

In reply to by Marc Sabatella

1. Select bar by clicking either on that bar in upper or lower staff of Grand staff, or on the (first/last depending on direction) note.
2. Select the other "hand" by shift/clicking on that hand. (This was either by selecting the whole bar or by selecting the first note/then last note OR working backwards with the last selection being in the upper hand).
3. Ctrl/c to copy.
3. Use arrow key to move to required bar (in this case, next bar.
4. Ctrl/v to paste.

The active point is in the lower stave - should be in the upper.

I have now tried "select lower stave, use shift/up arrow, copy", then use rt. arrow to move to the next bar and now the active point IS in the upper stave, thanks.

I still think that no matter the way the selection is done, since we are talking about a Grand Staff, the program should automatically understand that when a whole part of the GS is selected, it should automatically select the upper staff for the active point.

In reply to by xavierjazz

This does seem to make sense. I still suspect that at least sometimes, this *won't* be what you want - that often, you will want the active element to be the thing you most recently clicked. Consider, selecting a range of several measure using click / shift+click in a *single* staff in preparation to copy that passage to the next measure (ie, if you didn't know about the "R" command). So it really would be special-casing this operation to take the *time position* of the shift+click but keeping the *staff* of the original click - not sure how intuitive that would really feel in other situations. But worth thinking about.

In reply to by Marc Sabatella

(Concerning the R-option I wasn't aware ;-).

But beside this I noticed, and I'm not sure it's helpful for this discussion and will really improve MuseScore to use easier/more simple, there's a difference between the range selection of chords + arrow right and the range selection of elements of several staffs+arrow right.
In the first case after moving forward the upper note of the next chord will be selected, in the second case the element of the lower staff is selected. Or am I wrong?

In reply to by kuwitt

What I'd personally expect is that if Right moves the cursor to the right, then Shift+right would do the same (thus moving the "active" element) while also selecting. Similarly, if (Alt+)Down moves the cursor to the next lower staff, then Shift+Down should do the same.

And if clicking a spot in the score then shift+clicking another spot on the *same* staff move the active element to that second point, then the same should be true when shfit+clicking another spot on a *different* stff. I am not sure most people will like the inconsistently that would result from having Shift+click *sometimes* move the active element to the new location but sometimes not. Do other applications work that way? For instance, in a text editor, click somewhere in the first line of a paragrah, then shift+click something in the middle of a line further down. Now move the cursor right. What happens? All the programs I tried move the cursor to the spot right after where I shift+clicked.

So again, I can see how in the specific case of copying and pasting range of measures on a grand staff to the next measure on that same staff you might hope for the cursor to act a little differently than it does in general. But I'm not crazy about the inconsistency this would introduce, and would be very concerned that there would be other cases where the current behavior is in fact exactly what one would prefer. Like, if the goal were to copy the selection to the next instrument down in the score.

In reply to by Marc Sabatella

I just experimented with more than 2 stave. The active point is always the lowest stave, so I can't really understand your use case where everything goes down one stave. It varies according to the number of staves and generally it makes no sense to me to expect that the "paste to" point varies as to number of stave selected.

" ..... And if clicking a spot in the score then shift+clicking another spot on the *same* staff move the active element to that second point, then the same should be true when shfit+clicking another spot on a *different* stff. I am not sure most people will like the inconsistently that would result from having Shift+click *sometimes* move the active element to the new location but sometimes not. ....."

I don't really understand this. My use of shift/click is only for selection, not for placement.

If you click 1st on the first note in the top stave and then shift/click in the other stave then press right arrow - the active spot is in the first beat of the lower stave.

If you reverse the process the active spot is in the lower stave.

Shift/click is only for selection, so I am confused as to your "other cases".

In reply to by xavierjazz

The point is, the active element after a shift+click selection is the thing you shift+clicked. This is the same whether you are creating selection from scratch (shift+click with nothing selected) or whether you are selecting a range on a single staff, or selecting a range across multiple staves, or extending an existing range selection. It's true whether the point your shift+clicked is above or below the original click, whether before or after. It's true across the board in all cases, and as mentioned, it's like that in all other programs I mentioned as well. In every single case that I can think of - and there are quite a few - shift+click extends the selection to the place you shift+clicked, *and* it changes the active element to that place as well. Maybe you aren't always thinking about where the active element is, after a shift+click but that doesn't mean no one ever does, or that it wouldn't be important to be consistent.

Which is why *despite* the fact I can see why in this one specific case it might be more efficient for it to work differently, I would be reluctant to make this one case work differently from all others. Again, though, I'd like to see if someone can show examples in other software of this rule being broken for specific cases.

In reply to by Marc Sabatella

I wouldn't also be crazy if the actual behavior would change or stay ;-).

But sorry Marc, in my philosophy is a single text document the same like a single staff. When I try out the same in a spreadsheet: select a single cell (=a single staff), click shift down to select several cells (=staffs), move right. At least for Libre Office I see another behavior.

In reply to by xavierjazz

"R" is provided just for this purposes - to make this particular use case more efficient.

But if you're still having trouble seeing why people might expect shift+click to behave in the usual way - extend selection *and* move the active element, here are some other use cases to consider:

Instead of copying a range to the next measure on the same staff or staves, imagine copying to the *same* measure on a different staff.

Or, imagine that instead of copying, you were actually going to do something else, like transpose the selection, or delete it, or add slurs.

Or, imagine that you accidentally shift+click the wrong spot - one note too far to the left or right - and now you want to use Shift+Left/Right to further fine tune the selection.

There are *lots* of use cases to consider besides the one that at hand. So merely doing the thing that happens to be most efficient in the special case of coyping a range to the next measure of the same staves could easily make the other cases *less* efficient - or at the very least, disrupt the workflow because of the surprise factor from the lack of consistency.

In reply to by Marc Sabatella

"Instead of copying a range to the next measure on the same staff or staves, imagine copying to the *same* measure on a different staff."
In that case I would expect to select that staff. I seem to remember that there is a keyboard shortcut for that? (Down/up staff).

"Or, imagine that instead of copying, you were actually going to do something else, like transpose the selection, or delete it, or add slurs."
I don't see how this is relevant - I am not talking about how to select the appropriate range, just that, after selection, using the right arrow should place the active spot in the uppermost staff rather than the lowest.

"Or, imagine that you accidentally shift+click the wrong spot - one note too far to the left or right - and now you want to use Shift+Left/Right to further fine tune the selection.".
Again, this is not the issue I am talking about, I am not talking about changing the selection, it is the cursor movement AFTER by using the r/l arrows.

We seem to be talking about 2 completely different things. :)

In reply to by xavierjazz

Yes, there is a shortcut to move to the next staff - but if we don't change the active element, it won't work - you'd still be on the top staff. That's exactly why the current behavior is more logical for that is case.

The reason transposing or other actions are relevant is that it may well change your notion of where you expect the active element to be. You can't just optimize for one use case then ignore the possibly detrimental effects on others. Depending on what you were going to do next, you very likely *do* want the active element to be right where just clicked.

Same with my example of using shift+left/right to tweak the selection - you absolutely want the active element to be where you just clicked.

So no, we aren't talking about different things - I'm simply expalining your use case is one of many, and in the others, the current behavior is best.

In reply to by kuwitt

You are right that LibreOffice Calc works differently, so that's one good example :-) They basically don't change the active cell on *any* shift click, or on shift+arrow. So it's different from MuseScore in other ways, too - like even if you select several cells in the *same* row, the active cell doesn't change. So it's actually a significant step *backwards* with regard to this use case (copying a range to the next position to the right). Also, because a "cell" is such a fundamental element in Calc, LibreOffice is able to continue to visually show that it is the active cell.

So at least LibreOffice is consistent - they *don't* change the active cell on shift+click or on shift+arrow. It could be worth considering whether that approach makes sense for us too, but I suspect it would be seen as a big step backwards. Consider the case at hand. Select 20 measures across the two staves of a piano score by clicking the top staff first measure then shift+clicking the 20th measure bottom staff, hit Ctrl+C to copy, now move the cursor right. In MuseScore, you are in measure 21, bottom staff. So right measure, wrong staff, but it takes only a single click to get the cursor where you want. In the LibreOffice model, you'd still be measure 1. It would actually be quite a bit more work to get to measure 21.

In reply to by Marc Sabatella

A good point with your example too (and I can see the discussion with serenity;-).

If I select in Libre Office Calc a cell in a row to another cell from another row and click arrow right (maybe from A1 to T2 = 20 measures in two staffs), it moves to cell B1 (not to U1=measure 21). But at least it remains in the same row of the first selected cell.
So in fact Libre Office Calc has potential for improvements, but I'm afraid MuseScore is the the wrong forum therefore ;-).

In reply to by Marc Sabatella

This of course does not apply to a single staff, but on consideration the most obvious case it would be that someone selecting a number of stave would most likely want to paste to those staves.

There is no reason I can see to lower the copy on to the lower staff if there is more than one staff.

Do you still have an unanswered question? Please log in first to post your question.