Drum input palette: notes set to enter as voice 2 are entered into voice 1 in error

This is intentional - otherwise there would be no easy way to override the default voice assignment. Keyboard uses the default, mouse uses whatever your voice control is set to. A single click in the palette automatically sets the vopice control appropriately, but you can then override it and your change sticks.

I take that back, there does seem to be a problem, it doesn't work to select voice 2. That is, double clicking seems to force everything to voice 1 regardless of the default for the drumset or the state of the voice control.

Not sure how this managed to escape notice until now?

A number of weird things with voices and stem directions in unpitched percussion entry didn't quite escape my notice, but I got so used to them I didn't notice anymore.

What's odd is I know I fixed an issue specifically relating to this before the initial release of 2.0, and that section of code doesn't appear to have changed since then. So apparently my fix didn't do what I thought it did. I need to investigate further.

See #39456: Double clicking icon on drum palette enters note at wrong location / voice, undo moves cursor to wrong staff - this is the issue I supposedly fixed, via https://github.com/musescore/MuseScore/pull/1463. Also see discussion in https://musescore.org/en/node/39366 that led to the issue being filed. Nowhere in any of this discussion do I now see a clear statement about what expected results should be - just general observation that it should be possible to override the default voice.

What I find now is that the current behavior depends on the "input position" - the chord or rest that the next note input would otherwise replace. If you currently have voice 2 selected on the note input toolbar, *and* there is already a rest (or note) for voice 2, then double click will enter the drum note into that voice. At least, it will until you try entering a voice 2 note somewhere that doesn't already have a rest or note there, which does indeed appear to change the palette itself, and now things are a bit more messed up going forward.

I rather doubt this was this the behavior I thought I was implementing, but looking at my code, it pretty much seems to be what I wrote, so I must have been thinking *something*. Does someone have access to the original 2.0 release to see if this works the same way there?

More importantly, I guess now we get to consider again how this really *should* work. I'm open to suggestions.

FWIW, the bug where the voice of the palette itself changes is possibly the result of unrelated change to applyDrop(), might also have been something I did while making double click work for more palette items. Hard to be sure since I don't have a 2.x build environment set up, so my investigation thus far is on master where there have already been other significant changes (and the drum palette is quite messed up in terms of stems, BTW).

FWIW, simply doing an score->expandVoice() call before we check for a chord/rest at the current input position here:

https://github.com/musescore/MuseScore/blob/master/mscore/palette.cpp#L…

fixes the behavior to be more consistent what I think I expect. Not sure it is exactly perfect, but the lack of this call is why currently you can't enter anything into voice 2 by double click unless there is something there already. The call to score->inputState().cr() returns null, so we go with the selection instead, which is likely to be something in voice 1 (since there is nothing in voice 2), and drop the new note there.

There's a little more to good fix than this - I'm also concerned about the possible voice change within the palette itself - and I am sure there are other ways of dealing with this. Mostly, though,I'd still love to hear more input on expected behavior. Should I move this to the forum? Maybe revisit the original thread from two years ago (https://musescore.org/en/node/39366)?

What you described sounds good to me. I'm not sure what you mean by "I'm also concerned about the possible voice change within the palette itself," though—could you elaborate?

See the part in the original report about the color (and indeed, the actual default voice assignment) of the drum icon *in the palette* changing upon double-click. My one-line "fix" does improve the situation but still leaves cases (*) where the note is entered into the wrong voice, and in those cases the drum icon does still change.

(*) The case fix doesn't address is where there is content in voice 2 but not on the specific beat you are trying to enter on. That is, a half rest in voice 2 on beat one, cursor currently on beat 2 (possibly if there is something in voice 1 on that beat and voice 1 is currently selected in the toolbar) and then you double click a an icon assigned to voice 2. I'm not really sure what the expected result *should* be in that case - maybe convert the half rest in voice 2 to a quarter rest so the new note can be entered on beat two? Or maybe back the cursor up to beat 1 and enter the new note there? Or move it forward to beat 3 and enter it there?

Right now, what would happen is that the new note gets entered into voice 1 because that is what you have selected in the toolbar - that is, with double click, the current voice in the toolbar "wins" in this particular case, but not in the general case. I'm still torn on the business of this voice override. On one hand it should be *possible* to override the default voice, but right now that's doable if you single click the icon then click in the score - this uses the current voice selection. And of course, once you select a voice, the cursor moves, if necessary, to a place where it is actually possible to enter a note, so the issue I am talking about here never arises.

So I'm still trying to understand at a basic level here: say your voice selector - and hence the cursor - is on voice 1, then you double click an icon in the drum palette that is set to voice 2. What do we really expect to happen? Said another way, should double click honor the default voice for the icon or the current voice selection? I'm leaning now toward honoring the default, as it seems that would more commonly be how I would want notes entered. If I have a drumset definition that has bass drum in voice 2, that's where I want it 99% of the time. So while it needs to be *possible* to override it, I think the most basic note entry methods should probably take advantage of the defaults. Otherwise what is the point of having them (which is itself a good question...)

Good detail! Speaking for myself, I would expect the note to be entered in its default voice if double-clicking, whatever is selected in the toolbar. In the "(*)" case, I think ideally the preceding half rest in voice 2 would be shortened and the new note entered at the selected point.

FWIW, the keyboard shortcut will back the cursor up and enter the note there. That's probably easier to implement in any case.

Please no! Don't get rid of unpitched percussion's voices.

The current plan for percussion input seems to be a very logical alternative to having to click a note on a toolbar. It is the equivalent of entering notes in any other staff. You just have to remember what A, B and C mean on a/your drumset. The input palette is bascially a diagram of what keys make which instruments in the drum set, with the option of double clicking it if you like. The "notes" are simply the shortcuts available on many other palette actions.

The plan is good in my opinion, it just needs to work properly. When you select a percussion that is supposed to go into voice 2, it should. MS should also pad the measure with the appropriate rests in the correct voice to accommodate the location of the cursor in the measure. So if you start with an instrument in voice 2 and at beat 2.5 you enter a note that should be in voice 1 MS should change the voice 1 measure rest to a 1/2 rest and an 1/8th rest and then enter the selected note. If note C goes into a different voice than the current note, then shift-C should put the note in the correct voice at the current location. This is the percussion idea of a chord on any other instrument.

This is good discussion, and I have some ideas to add, but it definitely feels like this should be on the forum. I'll start a new thread.

https://musescore.org/en/node/156161

Although I started a discussion of this on the forum and get little response, I still feel there should be more discussion of the desired behavior, especially in light of MDL. What is happening here is definitely a bug (nd I'm not sure why it works sometimes but not other times), but I feel we should be looking at the bigger picture here as well.

Came up again in #300160: Drum palette: clicking on staff sometimes enters note in wrong voice and #300267: Percussion staff: mouse click wrongly enters voice 1 percussion in voice 2

We’re reverting that change for the drum palette. But, this issue still applies either way, just differently. Eventually we want to think of some better designs, and the info in this thread will remain good for reference.

https://github.com/musescore/MuseScore/pull/6334

I finally sorted through everything that is going on here.

When you double-click a drum palette note, the input voice changes the moment of the first click, so we're definitely always trying to use the voice defined in the palette. In fact there would have been no easy way to change that behavior to use the toolbar voice instead - that info is actually gone by the time we are processing the double-click.

In the course of processing the double-click, we try to enter the note at the current cursor position using the voice we get from the drumset definition. But if there is nothing at that position & voice this will fail, and we will fall back on the selected note, and use its position and voice instead. Which, if you are entering notes left to right, is the note you just entered. And in the process, we actually apply that voice to the palette itself as well due to a silly mistake I made quite a few years back.

So what I have done is get rid of the fall back to the selected note - well, to only fall back if the next thing we try also fails, which it shouldn't. That next thing I copied directly from the code handling keyboard shortcuts: we look backwards in the current measure and voice looking for a place we can safely enter the note, and if nothing else, the beginning of the measure works.

So, if you enter a few snare drum hits into an empty measure then press "B" to enter a bass drum, a voice 2 bass drum gets entered back at the beginning of the measure. This is, I believe, now the expected result, so I just made it so the exact same thing happens if you double-click the bass drum icon instead. And also, just as with the keyboard shortcut, if there is something at the cursor position in voice 2, you'll get a bass drum note there instead.

So basically, with my PR double-click now works virtually the same as keyboard shortcut - including the ability to press Shift to add to chord (see #47821: Drum input palette: Allow Shift + double-click on an icon to add a note to a chord).

The idea of allowing the voice selected on the toolbar to override the palette sounded nice for a minute, but once I realized that the first click already changed the toolbar to reflect the drumset, it became clear we needed to enter into that voice. So if you wish to override voice, use the method of click palette icon, change voice in toolbar, then click in score. Or let it enter at the default then change it after leaving note input mode.

Fixed in branch 3.x, commit 01599e6780

_fix #47821, fix #153686: issues with voice and chords with drum input

Resolves: https://musescore.org/en/node/47821
Resolves: https://musescore.org/en/node/153686

When adding drum notes to a score by double-clicking in the palette,
the semantics have always been a bit odd,
and even with some bugs fixed, there have still be inconsistencies,
as well as needless limitations and outright bugs.
This fixes a number of interrelated problems,
that stem from two main issues.
The issues are conceptually separate,
but they exists in the exact same blocks of code,
so there is no practical way to separate these

1) Shift+double-click should add note to chord, not replace

This mostly required checking for ShiftModifier in Note::drop()
and calling addNote instead of setNoteRest.
But also, it required correcting the management of the selection
and of the note input cursor, which was non-standard.
All other note input methods leave the note you just entered selected,
then move the input cursor.
Double-click was selecting the note or rest at the new input position.
That would have resulted in Shift adding to the next chord
rather than the one you just entered.
It also caused a bug in itself: entering a note before an existing one
caused playback of the existing note after the playback of the new one.
Changing the selection to stay on the new note helped,
but now it meant the new note got played twice -
once because you clicked it on the palette,
then again in endCmd because the note was selected.
Preventing the double playback was achieved
by turning off setPlayNote and setPlayChord in applyPaletteElement.
A change to that function was also needed
to make sure we use the selection when adding to the chord with Shift.
The code designed to favor the input cursor position over the selection
is now skipped when using Shift.

2) Double-click should use the voice defined for the note in the drumset

This happened "sometimes" but it was unpredictable,
and in some of the cases where it didn't work,
it actually changed the voice of the note in the palette itself.
That turned out to be a bad side effect of a fix I made many years ago.
Removing the assignment of track of the element in applyPaletteElement
fixes that problem, then I made the corresponding change
to how we select the track in Note::drop.
But this still would leave us with the issue that the note
would be added in the wrong voice any time
there was no existing note or rest in that voice
at the current input position.
The solution to this was to borrow the code from putNote,
which is what gets used when entering a note via keyboard shortcut:
walking backwards until we find a place to enter the note._

Fixed in branch 3.x, commit 0059c7960a

_Merge pull request #6334 from MarcSabatella/shift-drum

fix #47821, fix #153686: issues with voice and chords with drum input_

Automatically closed -- issue fixed for 2 weeks with no activity.