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.

Sign up for GitHub

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

Jump to bottom

MidiOutputConnection.drop() produces unwanted output on Windows? #122

Open
dwmuller opened this issue Oct 16, 2022 · 1 comment · May be fixed by #123
Open

MidiOutputConnection.drop() produces unwanted output on Windows? #122

dwmuller opened this issue Oct 16, 2022 · 1 comment · May be fixed by #123

Comments

@dwmuller
Copy link

When a MIDI output connection is closed on Windows, this results in a call to midiOutReset. This sends "all notes off" and "reset all controllers" MIDI commands to every MIDI channel, 32 commands in all.

For the application I'm working on, this is at least unnecessary, and possibly harmful, depending on my hardware setup. The app targets a controller, only, and this activity could have undesirable side-effects on other devices. It also seems somewhat out of keeping with midir's low-level target functionality.

However, the documentation for midiOutReset also specifies that it stops processing of pending output buffers. midiOutClose will return an error if output is still pending (MIDIERR_STILLPLAYING). I wonder if that's why the call to midiOutReset exists. It might be better to retry midiOutClose until that error no longer occurs (similar to what happens on a call to midiOutUnprepareHeader on a send).

If there's interest in such a change I could try it out, and produce a pull request.

https://learn.microsoft.com/en-us/windows/win32/api/mmeapi/nf-mmeapi-midioutreset
@Boddlnagg
Copy link
Owner

Boddlnagg commented Oct 16, 2022 •
edited
Loading

However, the documentation for midiOutReset also specifies that it stops processing of pending output buffers. midiOutClose will return an error if output is still pending (MIDIERR_STILLPLAYING). I wonder if that's why the call to midiOutReset exists. It might be better to retry midiOutClose until that error no longer occurs (similar to what happens on a call to midiOutUnprepareHeader on a send).

Yes, I actually do not know the reason for the midiOutReset call any more, but this is likely it (I assume that other platforms do not show this behavior of sending "all notes off", therefore I agree that it should not be done on Windows, and it's probably also not done with the winrt backend?). You're welcome to try the alternative approach and open a PR if you can show that it works. Thank you!

dwmuller added a commit to dwmuller/midir that referenced this issue Oct 16, 2022
@dwmuller
drop() no longer calls midiOutReset
4ccaf57 
Fixes Boddlnagg#122

On Windows, midiOutReset was being called before midiOutClose,
presumably to cancel any pending output. This caused extra MIDI
commands to be sent. Instead, we now call midiOutClose repeatedly
until it's no longer blocked by pending output.
@dwmuller dwmuller linked a pull request Oct 16, 2022 that will close this issue
Open
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

Successfully merging a pull request may close this issue.

drop() no longer calls midiOutReset dwmuller/midir
2 participants
@Boddlnagg @dwmuller