Shift+letter shortcuts for drum entry enter wrong notes

• Sep 7, 2014 - 01:32
Type
Functional
Severity
S4 - Minor
Status
closed
Project
MuseScore

1. Open drumset score.
2. Click on stave.
3. Enable 'Note Entry'.
4. Press 'A' (Acoustic Snare).

5. Hold shift and press 'A' again.

Expected result: Acoustic Snare is entered unison.
Actual result: Low Tom is entered.

6. Repeat step 5.

Result: A unison Low Tom is entered.

-----

5. Hold Shift and press any letter from B-G.

Result: Another drum is entered.

Workaround: Enter note higher/lower and move it to achieve unison.

Using MuseScore 2.0 Nightly Build 32fe6c4 - Mac 10.7.5

Comments

• Sep 7, 2014 - 13:10

I'm a bit perplexed as to why you would need a unison on a drum???

The only time you would use both sticks for a note usually is to perform a flam which isn't performed as a unison anyway.

In fact using both sticks in this manner would tend to flatten the sound as the head is designed to resonate from one node, and making it resonate from 2 would be a bad idea acoustically, as you could end up with phase cancellation making the beat quieter.

I am willing to be enlightened, however.

Reply

• Sep 7, 2014 - 21:19
Title Shortcuts for drum entry enter wrong notes ⇒ Shift+letter shortcuts for drum entry enter wrong notes

I take it my title change is accurate? Eg, the letters themselves work fine; it's the combinations with "Shift" that do not?

BTW, it's not uncommon in the rock world to hit a drum hard with both sticks at once.

Reply

• Sep 13, 2014 - 02:26

It's not just unisons that are problem: Shift+letter enters the wrong drum, period. So you cannot enter two drums on same voice using keyboard. Worse, neither click nor shift+click seem to work to add a note to a "chord" in drum mode either. So the only way I can to enter one is use Shift+letter to enter whatever random drum results, then arrow up and down until you find the right one. Or maybe I am missing something?

Reply

• Sep 13, 2014 - 09:04

This is a result of the request to disable entry of unisons by the simple letter key. #11001: Can add same note to chord many times

I thought it was a bad idea at the time.

We need to think about the full implications of implementing requests which alter the established UI behaviour before going ahead with them.

At the end of the day the user must take responsibility for what (s)he inputs. It is not our job as developers to restrict that.

Reply

• Sep 13, 2014 - 12:36

We need to think about the full implications of implementing requests which alter the established UI behaviour before going ahead with them.
Like if it was not what we are trying to do, every single day. If one think to much, one does nothing.

Reply

• Sep 13, 2014 - 20:33

Nicolas it was not my intention to allocate blame here to anyone.

Sorry if I got under your skin.

At the risk of upsetting you again - the biggest thing this project lacks is an overall flowchart of what is called from where, enabling us to see what could be affected by a change in one of the modules.

I realise that this could only be produced by you or Werner, but it would make debugging much easier.

I also realise the implications of what I'm saying - this would have a considerable time cost, but in the end I think it would help the project to progress faster.

In a big project like this adequate documentation is essential.

Reply

• Sep 13, 2014 - 21:54

the biggest thing this project lacks is an overall flowchart

So far, the release of MuseScore worked without this essential piece. If you mean what could make the development faster, I disagree. The biggest thing that would be needed in this case is more good and dedicated coders.

An overall flowchart is more or less what the code is ... I once tried to make a documentation for the code and quickly realize that the way it is, documenting it enough to "see what could be affected by a change" would just create a bunch of english text and diagrams that would be as hard to understand than the code itself... And so it would defeat the point.

One more thing. You seem to assume that MuseScore is modular. AFAIK, it's not the case, or at least not enough to draw a flow chart between the few modules that would magically "make all clear". Especially problems like the one discussed in this issue.

Still more documentation wouldn't hurt, but mainly for other reasons. In particular, it would lower the barrier to entry for new developers. Along the years, the community made an great effort making this barrier lower starting with the developer handbook then moving to GitHub, then setting up regression tests, visuals tests, automating them, participating in GSoC etc... It's kind of working https://www.openhub.net/p/musescore/contributors/summary and we will continue.

In my opinion, the good tool to detect if a change in the code will affect other features are regression tests. So let's write more tests!

Reply