MIDI input breaks for rest of session

Which MIDI input method are you using? Step time?

In MIDI, there is no such thing as doing anything simultaneously; everything is one at a time just a question of how quickly one event follows another. So even when you think you are releasing simultaneously, what MuseScore receives are one at a time release messages, just quickly all right in a row. How quickly do you find you need to release to trigger this?

My guess is it will turn out your keyboard is not correctly sending note-off messages for all the notes, and that is why MuseScore thinks you haven't moved on. But it's also possible that in some specific case MuseScore is dropping one fo the note off messages.

You could try releasing the keys say, one second apart, and see if that works or not. If so, try releasing somewhat more quickly. If not, try releasing a little more slowly. Basically, trying to understand whether this problem only kicks in when releasing keys super fast or if it happens even when releasing a second or more apart.

Just because the keyboard works in other respects doesn't mean the keyboard isn't doing the wrong thing here. In other situations, it might not matter so much if all the note off messages get sent or not.

It might be a good idea to watch/record your incoming Midi with a midi monitor.
For OSX you might give MidiMonitor a try (https://www.snoize.com/MIDIMonitor/).
This will show you the timing and data of all midi events.

Thanks for the investigation!

My understanding is we trigger the completion of entry on note off. The reason is to facilitate the building of chords - to allow several notes played "at once" (which really note on events in quick succession before any note off event) to be understood as part of the same chord.

I believe this issue is the cause of https://musescore.org/en/node/196816#comment-808577, so it's clearly happening with multiple users, including me. Although the root cause is external (lost midi event), the result is an internal state error within Musescore which is not easily recovered, and gives the impression that Musescore has crashed.

Musescore counts the number of "active" notes by incrementing a counter for each "note-on" event, and decrementing for each "note-off" event. It does this all the time, regardless of "note entry" mode. If a "note-off" event is lost - for whatever reason - the counter value is wrong, and midi input is useless from this point on.

I think this could be fixed by resetting the counter to zero when entering "note entry" mode. As far as I can see, the counter value is only useful in "note entry" mode, so zeroing here would be a good defensive approach. Alternatively, the counter could be held at zero while not in "note entry" mode (which would have the same effect).

Relevant code is in mscore/musescore.cpp, method: MuseScore::midiNoteReceived().
This declares: static int active = 0; and increments, decrements etc. as note events are processed.

Two workarounds for now:
1. Force extra "note-off" events: disable midi input, press midi key, enable midi input, release key. Repeat as required...
2. Enable midi remote control, and allocate a midi key to do something - which then zeroes the counter when pressed.

I like the idea of adding a failsafe to the note input command. Probably we should reset our internal state and also send an "all notes off" event.

I'm not super familiar with the MIDI handling code in MuseScore, but this is something I feel would be good to address for 2.2. Anyone want to give it a shot?

The MIDI standard does have an all-notes-off message which was probably meant for such usecases.
Older MIDI applications often had a 'panic' button to stop all sounds (Aeolus still has example).

Maybe MuseScore needs such a button/action/menu entry. And MuseScore should react to an all-note-off message (I have this mapped to one of my keyboard's buttons). Performing 'magic' on entering/leaving note-input mode seems like a really bad idea. That's fixing broken hardware at the wrong place.

Agreed that supporting the "all-notes-off" midi message would be a good thing to have. Also strongly agree that 'magic' fixes are a very bad idea - the unintended side effects are generally a real pain.

But there's no magic fix here. The "active note counter" is only used in note-entry mode. It's a state variable that belongs within a note-entry session, and so it should be initialised at the start of each new note-entry session.

If I've missed something here, and the active note counter has some other use outside of a note entry session, then that would be quite different, so please advise if that is the case.

Been looking some more at MuseScore::midiNoteReceived(), and found why MuseScore gets into this bad mode. As I suspected, it's not necessarily caused by hardware - and this explains why I've been seeing the issue so often.

QWidget* w = QApplication::activeModalWidget();
if (!cv || w) {
active = 1;
return;
}

So if there's no view open, any midi note received sets active to 1. Later on, when a score is opened and note-entry is enabled, it's still set to 1 - so midi input can't enter new notes. Bingo! I've no idea why this is needed, or what it's trying to achieve.

To try this, open MuseScore but don't open any actual score. Enter a midi note. Create a new score, enable note-input mode, and try entering notes using midi.

There's other weird stuff in there too. static int iter = 0; is compared to a (magic number) threshold of 3 etc., but it's never incremented. This is something to do with drum modules, but it looks unfinished.

So I think someone who knows how this is meant to work needs to take a look and comment on what should be done here.

So, according to your diagnose this is a different bug from the originally reported one (where the Midi dump clearly shows that note-off events are missing).

The bug report is "MIDI input breaks for rest of session". However, there is more than one way way to trigger this fault condition. The OP reported one way (missing note-off event); I have found another way (any midi note event while no score is open). Different triggers, but both resulting in the exact same problem - that "MIDI input breaks for rest of session".

A bump on this to put it on the radar - wondering if we can also do something about the many reports we receive about MIDI input not working. I had assumed it was that we were looking for "note on, velocity = 0" when we were actually getting "note off" messages, and maybe that is the case as well, but this seems also relevant.

See also #273660: MIDI Keyboard Not Responded when Pressed Before Opening a Score

Please check whether this issue here got fixed with the most recent 2.3 development build

Hi Guys,
I am evaluating Musescore "development" version. First, let me thank you for making such good software and available for free, i tried others and Musescore remain the best one.

I still have issue when playing music and stopping the play, using midi channels instrument, most of the time it is hanging playing continuous notes.

I have a SY77 from Yamaha and an organ Electone EL90. My computer is connected to SY77 with Midi in and out and SY77 forward the midi IN via midi truth port to my EL90.

Mostly I use MIDI file that I modify to use adequate channel to send the midi to my devices.
If I want to play ... I just need to mute the track i want to play and when I play Musescore, I physically play my instrument in the background. If I need to stop then it is hanging and there is no panic button to reset so I must switch off either my SY77 or EL90.

I have tried different configurations and it is always ending with hanging if i stop the play from Musescore (i don't even need to play myself to make it hang).

So, would it be possible to have a panic button or to change the code in order to “kind of” send an all notes off when you press stop on the player?

MIDI CC 120 All Sound Off Mutes all sounding notes. It does so regardless of release time or sustain. (See MIDI CC 123)
MIDI CC 121 Reset All Controllers It will reset all controllers to their default.
MIDI CC 122 Local On/Off Switch Turns internal connection of a MIDI keyboard/workstation, etc. On or Off. If you use a computer, you will most likely want local control off to avoid notes being played twice. Once locally and twice whent the note is sent back from the computer to your keyboard.
MIDI CC 123 All Notes Off Mutes all sounding notes. Release time will still be maintained, and notes held by sustain will not turn off until sustain pedal is depressed.
MIDI CC 124 Omni Mode Off Sets to “Omni Off” mode.
MIDI CC 125 Omni Mode On Sets to “Omni On” mode.
MIDI CC 126 Mono Mode Sets device mode to Monophonic.
MIDI CC 127 Poly Mode Sets device mode to Polyphonic.

No need to change this issue's properties...
Maybe You'd better start a new thread in the Development and Technologogy Preview Forum?

so how is everyone still using musescore with this bug? I suffered from this bug daily and there seems to be no plans to fix it at all. I have tried with so many midi keyboards, like 5-6 and all of them have this problem. how can i solve it?

This issue tracker here has been discontinued so better report it on GitHub