Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Enable MIDI input state resets after switching between processes #24850

Open
4 tasks done
wizofaus opened this issue Sep 21, 2024 · 4 comments
Open
4 tasks done

Enable MIDI input state resets after switching between processes #24850

wizofaus opened this issue Sep 21, 2024 · 4 comments

Comments

@wizofaus
Copy link
Contributor

wizofaus commented Sep 21, 2024

Issue type

UX/Interaction bug (incorrect behaviour)

Description with steps to reproduce

  1. Ensure MuseScore is configured for MIDI input, and that multiple instances can read from the MIDI device (on Windows this requires using LoopMIDI and something like MidiTools or MidiOX)
  2. In one instance of MuseSore with a score open, confirm that playing notes on a MIDI input device causes them to sound
  3. In the playback toolbar settings menu, turn off "Enable MIDI input" and confirm that notes played on the MIDI keyboard no longer sound
  4. Start a second instance of MuseScore with a (different) score, ensuring the current staff is for a different instrument than the first one. Note that "Enable MIDI input" is turned off there, so now turn it on.
  5. Confirm that MIDI keyboard plays back notes for just the instrument for the current staff in the second instance.
  6. Switch to the first instance and then back to second instance, and play notes via a MIDI device again.
  7. Expected: notes should continue to play just for the second (active) instance and not the first.
  8. Actual: MIDI playback now occurs via BOTH instances simultaneously (esp. noticeable if the current staff in one is a transposing instrument).

Supporting files, videos and screenshots

N/A, can record video if really needed a bit involved to demonstrate.

What is the latest version of MuseScore Studio where this issue is present?

4.4

Regression

I was unable to check

Operating system

Windows 11

Additional context

I've noted before that Windows doesn't handle MIDI input devices well with multiple processes - the fact that you need special software for it work at all is obviously not ideal, but in this case it's really MuseScore that's not doing what seems reasonable to expect, which is to maintain a separate "Enable MIDI input" state between instances - it seems to be trying to sync them all to use the same setting, though the menu itself doesn't always reflect that.

Ultimately all I want to do is to have MIDI input only work for the instance with the focus (exactly the same way computer keyboard input works), but if I'm able to at least turn it off for one instance and on for another, that's fine too.

Checklist

  • This report follows the guidelines for reporting bugs and issues
  • I have verified that this issue has not been logged before, by searching the issue tracker for similar issues
  • I have attached all requested files and information to this report
  • I have attempted to identify the root problem as concisely as possible, and have used minimal reproducible examples where possible
@wizofaus
Copy link
Contributor Author

wizofaus commented Sep 22, 2024

BTW this is easily fixed by changing NotationConfiguration::setIsMidiInputEnabled to use setLocalValue instead of setSharedValue.
Is there a good reason to use setSharedValue here? Personally I wouldn't expect any of the settings in this menu (auto-pan, play repeats etc.) to automatically sync between instances while they're still open. At most I'd expect that after changing such an option, the next instance I start of MuseScore will use that setting.

What I'd actually like to change it to is:

void NotationConfiguration::setIsMidiInputEnabled(bool enabled)
{
    settings()->setLocalValue(IS_MIDI_INPUT_ENABLED, Val(enabled));
    if (!enabled) {
        midiInPort()->disconnect();
    } else {
        midiInPort()->connect(midiConfiguration()->midiInputDeviceId());
    }
}

(requires injecting midiInPort and midiConfiguration into NotationConfiguration, but creates no additional dependencies).
This allows you do disable MIDI input for one instance so another can grab exclusive access if you're not using LoopMIDI etc.
However it's not really enough on its own to work smoothly, so is probably best done as part of a separate change.

@cbjeukendrup
Copy link
Contributor

I think this should be solved in the following way:

  • MuseScore instances should only react to MIDI input when they have focus; just like the computer keyboard
  • "Enable MIDI input" should stay a global setting, and when changing it in one instance, other instances should update their UI too

Or, @bkunda, what is your opinion about the following?

Personally I wouldn't expect any of the settings in this menu (auto-pan, play repeats etc.) to automatically sync between instances while they're still open. At most I'd expect that after changing such an option, the next instance I start of MuseScore will use that setting.

@cbjeukendrup cbjeukendrup removed their assignment Sep 24, 2024
@wizofaus
Copy link
Contributor Author

"MuseScore instances should only react to MIDI input when they have focus; just like the computer keyboard"

Yes, that would be my preference too, though on Windows that means explicitly having to release the MIDI in port on losing focus, and on gaining focus, attempting to repeated grab it until it succeeds.

But then what's the purpose of that "Enable MIDI input" menu option at all?

@wizofaus
Copy link
Contributor Author

BTW some related issues:
#16075
#23870

If it's agreed the behaviour should be "only enable MIDI input when window has the focus" and that for Windows, it should release the MIDI port when it doesn't (and try at least a couple of times when it does receive the focus, to allow time for it to be released by other processes), then I'm more than happy to implement that.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants