musescore
Mapping MIDI button executes command twice - on both press and release
Issue type
Other type of issue
Bug description
Assigning a MIDI button to command executes the command twice: once on press and once on release. This means:
-
Note input: toggles on when the button is pressed, toggles off again when released
-
Duration dot: toggles on when button is pressed, off again when released
-
Play: starts playing on press, immediately stops on release
-
Tied note: adds two tied notes: one on press, one on release
-
Undo: undoes two commands
-
Rest: toggles on and off again on press and release. But Rest should probably enter a rest of the current duration, not select Rest mode (because otherwise there is no way to enter a rest from a MIDI keyboard)
Steps to reproduce
- Attach a MIDI keyboard (I used an MAUDIO Oxygen 49)
- Go to Preferences -> MIDI mappings
- Choose Note Input, Assign MIDI Mapping, and then click a button on the MIDI keyboard
- Go back to the score. Press the newly assigned button. Instead of toggling into Note Input mode, Musescore switches into Note Input mode when the button is pressed, and out again when it's released.
Screenshots/Screen recordings
MuseScore Version
OS: macOS 13.3, Arch.: x86_64, MuseScore version (64-bit): 4.0.2-230651546, revision: github-musescore-musescore-dbe7c6d
Regression
I don't know
Operating system
macOS 13.3.1, Apple M1 Max MacBook Pro
Additional context
No response
Additional information:
Using MIDI Monitor, I can see that the buttons are sending
- Control
127 on button down (eg. B0 66 7F) - Control
0 on button up (e.g. B0 66 00)
I think this is pretty normal default behaviour for a MIDI button.
It is possible to change the button to behave as a toggle (e.g. send 127 on the first press, 0 on the second press). However, this still leaves the issue of actions like Undo and Tie. These probably shouldn't be executing on the 0 (up/off) message.
My Akai MPK Mini III keyboard has a similar problem.
When I press down on a pad, it sends [185, 21, 127]. When I release the pad it sends [185, 21, 0].
The result of this is as this issue describes. If I bind CC 21 to "Play", MuseScore will play my music only when I am holding it down, as it registers the release message (level 0) as another press.
MuseScore 3 behaves correctly when it receives the same sequence of events. I suspect that it simply ignores CC messages with level 0. This behavior would seem to be appropriate in MuseScore 4 as well. Certainly as an option, if not the default.
I am glad to see #15219 fixed, as it was a major reason I was unable to upgrade to MuseScore 4.0. Unfortunately, due to this issue, MIDI controller bindings are still relatively unusable.
Can reproduce with my Arturia KeyLab 66 as well (4.2 master, Win10)
Doesn't occur in MS3
https://github.com/musescore/MuseScore/assets/90187801/6549ac1e-9cbd-4260-ac50-6f9c7253c1cf
Can reproduce with my Novation LaunchKey 37.
OS: Windows 10 Version 2009 or later, Arch.: x86_64, MuseScore version (64-bit): 4.1.1-232071203, revision: github-musescore-musescore-e4d1ddf
bumping this again, reproducible with a novation launchkey 49 that does indeed send a midi message with strength 0 when releasing a key, that musescore interprets as "release the button". For some reason this behaviour does not apply when selecting a note length in editing mode (I have CC 51 to 56 mapped to choice of length).
This leads to me having to hold the button for things like playing, entering editing mode, etc.
As @tsumare said, it works as intented in the latest musescore 3 version and you don't need to hold the button.
OS: Windows 10 Version 2009 or later, Arch.: x86_64, MuseScore Studio version (64-bit): 4.3.2-241630831, revision: github-musescore-musescore-22b46f2
consecutive down/up commands • 127 • 0 • from the same midi button (1 second or less) should count as a single button hit for MuseScore midi mappings.
I'd like to work on this issue. I have an Arturia KeyLab Essential 49, so this really bothers me. I managed to fix it by changing the following in MidiRemote::needIgnoreEvent(1):
diff --git a/src/framework/shortcuts/internal/midiremote.cpp b/src/framework/shortcuts/internal/midiremote.cpp
index faa7b6af63..2e7bfd2a88 100644
--- a/src/framework/shortcuts/internal/midiremote.cpp
+++ b/src/framework/shortcuts/internal/midiremote.cpp
@@ -218,7 +218,8 @@ bool MidiRemote::needIgnoreEvent(const Event& event) const
Event::Opcode::NoteOff
};
- bool release = releaseOps.contains(event.opcode());
+ bool release = releaseOps.contains(event.opcode())
+ || (event.opcode() == Event::Opcode::ControlChange && event.data() == 0);
if (release) {
bool advanceToNextNoteOnKeyRelease = configuration()->advanceToNextNoteOnKeyRelease();
if (!advanceToNextNoteOnKeyRelease) {
This just checks whether the Input is a control key changing state with a velocity of 0 and, if so, ignores it.
I think this change will introduce issues on Keyboards with the other behavior, please let me know if I'm wrong about that. Also please let me know if I should continue working on this.
I could either try to find a condition that works for both behaviors or put a checkbox or similar somewhere in the preferences that changes MuseScore Studio's behavior. I'm also open to other suggestions.
Is there a way to test the effects of my changes without another Master-Keyboard?
I'd like to work on this issue. I have an Arturia KeyLab Essential 49, so this really bothers me. I managed to fix it by changing the following in
MidiRemote::needIgnoreEvent(1):diff --git a/src/framework/shortcuts/internal/midiremote.cpp b/src/framework/shortcuts/internal/midiremote.cpp index faa7b6af63..2e7bfd2a88 100644 --- a/src/framework/shortcuts/internal/midiremote.cpp +++ b/src/framework/shortcuts/internal/midiremote.cpp @@ -218,7 +218,8 @@ bool MidiRemote::needIgnoreEvent(const Event& event) const Event::Opcode::NoteOff };
- bool release = releaseOps.contains(event.opcode());
- bool release = releaseOps.contains(event.opcode())
|| (event.opcode() == Event::Opcode::ControlChange && event.data() == 0);This just checks whether the Input is a control key changing state with a velocity of 0 and, if so, ignores it. I think this change will introduce issues on Keyboards with the other behavior, please let me know if I'm wrong about that. Also please let me know if I should continue working on this. I could either try to find a condition that works for both behaviors or put a checkbox or similar somewhere in the preferences that changes MuseScore Studio's behavior. I'm also open to other suggestions. Is there a way to test the effects of my changes without another Master-Keyboard?
Hello, I am currently having this exact issue with my FL key 37. How would I go about changing this code as a means to fix the issue? I have no idea where to find it because I have no knowledge on the subject of code. I just want my keyboard to work properly in the program. Thank you
Hello, I am currently having this exact issue with my FL key 37. How would I go about changing this code as a means to fix the issue? I have no idea where to find it because I have no knowledge on the subject of code. I just want my keyboard to work properly in the program. Thank you
If you have no knowledge of how code/compiling works, you'll have a really hard time trying to implement this yourself. In my previous comment you'll find the file and line number as well as which lines to remove and add. After changing it, you can use this guide to compile MuseScore into an executable program. However, this guide assumes you have at least a little knowledge of running stuff in the command line and you will get error messages even if you exactly follow the guide, which you'll have to resolve on your own.
Attached you may find a link to a ZIP-file containing a (hopefully) portable version of MuseScore with the fix applied. If this version doesn't work for you, please let me know, but then I don't know how else to help you.
Download fixed portable Version of MuseScore
Hello, I am currently having this exact issue with my FL key 37. How would I go about changing this code as a means to fix the issue? I have no idea where to find it because I have no knowledge on the subject of code. I just want my keyboard to work properly in the program. Thank you
If you have no knowledge of how code/compiling works, you'll have a really hard time trying to implement this yourself. In my previous comment you'll find the file and line number as well as which lines to remove and add. After changing it, you can use this guide to compile MuseScore into an executable program. However, this guide assumes you have at least a little knowledge of running stuff in the command line and you will get error messages even if you exactly follow the guide, which you'll have to resolve on your own.
Attached you may find a link to a ZIP-file containing a (hopefully) portable version of MuseScore with the fix applied. If this version doesn't work for you, please let me know, but then I don't know how else to help you.
Thank you very much, but what exactly do you mean by "portable" version of Musescore? Is there any sort of downside to if I try and use this instead of my current one? Can it still receive updates and so on? Thank you for your time.
A portable executable is an executable that doesn't need to be installed. The version I provided is just a folder with a "MuseScore4.exe", which you can run if you want to start MuseScore with the fix applied as well as all files this .exe-file needs. You can't really install this version, just use it inside the folder. It may happen that you have to reapply your settings or it could just work as-is, I don't know. I also don't know if the auto-updater will work, I don't think so. Other than that, there shouldn't be a downside. You should be able to keep the old version of MuseScore installed and once there is an update with the fix applied, you should be able to update your installed version. After that, you won't need the portable version any more. You could also just wait until an update is ready. The Pull Request is already approved so hopefully it will be merged into one of the next 3 updates.
This were correct, if you were talking about a PortableApp, but what you provided there isn't that, it is just a regular development build. So it does use the settings of a previously installed development version. It is correct though that these development builds cannot get installed, just unpacked.
