MIDI input breaks for rest of session

• Jul 18, 2017 - 06:55
Reported version
2.1
Type
Functional
Severity
S4 - Minor
Status
needs info
Project

Steps to reproduce bug:

  1. Follow handbook instructions for MIDI keyboard input
  2. (optional) Play single note(s) on MIDI keyboard
  3. Play multiple notes on MIDI keyboard at the same time
  4. Release notes at the same time

Expected behavior:

MIDI input should continue to work, even if multiple keys are played simultaneously and released simultaneously.

Actual behavior:

One can, in fact play multiple keys at a time, but one must be careful to release them one at a time. If one releases multiple notes at the same time, the notes that were already input on the attack are input again on the release. Afterwards, MIDI input becomes restricted to the current note location and any subsequent notes played will simply stack on top of the existing chord. If a different location is then selected by mouse or arrow keys, MIDI input ceases to work at all. This state persists until the session is ended and MuseScore is relaunched.

Version number:

  • 2.1 revision 871c8ce
  • 3.0.0, Revision 7bb6f4e

Operating System:

Mac OS X 10.11.3.

Other Equipment:

  • MIDI keyboard: Roland RS-5
  • MIDI connection: AGPtek MIDI-to-USB cable.

Comments

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.

MIDI input method: Step Time.

How quickly do I need to release to trigger this problem... I really don't know how to measure that.

I doubt it's my keyboard, as I've never had any problems with it before. But this is a new (and rather inexpensive) MIDI-to-USB connector, so I would buy that that's the source of the problem.

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.

I guess I didn't make that clear in my original post. If I release them a second apart, there is no problem whatsoever. So, yes, the problem only kicks in when releasing them super fast.

Additional details:

The attacks can be any amount of time apart or at any velocity, and that makes no difference. The order the notes are released in doesn't appear to have an impact, if they are released far enough apart.

But, if more than one note is released within a second of each other, that's when the problem occurs. Taking rmattes' suggestion, I ran MIDIMonitor. The offending results are here:

23:42:07.662 From Port 1 Note On 1 C3 50
23:42:07.667 From Port 1 Note On 1 D3 62
23:42:07.720 From Port 1 Active Sense
23:42:07.976 From Port 1 Active Sense
23:42:07.993 From Port 1 Note Off 1 D3 75
23:42:08.008 From Port 1 Note On 1 C3 64

The second Note Off becomes a Note On. So, I concede that it may be a hardware problem after all (hopefully in the adapter rather than the keyboard itself).

However, In Step Time, the duration of the note is not determined by the MIDI keyboard. So, is there a reason MuseScore is even listening for Note Off events in this context? Could a future release ignore them while in Step Time (or at least have an option to do so)?

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?

In reply to by Marc Sabatella

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.

In reply to by rmattes

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.

In reply to by rickfitz

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.

In reply to by rmattes

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.

Status (old) active needs info
Status active needs info

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

In reply to by Jojo-Schmitz

Title MIDI input breaks for rest of session notes hanging after stopping player (using MIDI instrument)
Reported version 2.1 3.0

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.