Getting additional messages after closing port under Windows

[jmeile]

Hi

I don't know if this is also the behavior on linux, but under Windows I'm getting additional messages after closing the MIDI Out port. First I start:

python midiin_callback.py
DEBUG:rtmidi.midiutil:Creating MidiIn object.
Available MIDI ports:

[0] Bome MIDI Translator 1 0
[1] loopMIDI Port 1

Select MIDI input port (Control-C to exit): 1
INFO:rtmidi.midiutil:Opening MIDI input port #0 (Bome MIDI Translator 1 0).
Attaching MIDI input callback handler.
Entering main loop. Press Control-C to exit.

Then I run:

python midioutwrapper.py
Available MIDI ports:

[0] Microsoft GS Wavetable Synth 0
[1] Bome MIDI Translator 1 1
[2] loopMIDI Port 2

Select MIDI output port (Control-C to exit): 2
Connect to new MIDI port and then press key...

I tried both ports: Bome MIDI Translator and loopMIDI and the result is the same. I always get:

[loopMIDI Port 1] @1576058149.982414 [194, 40]
[loopMIDI Port 1] @1576058149.983414 [146, 60, 127]
[loopMIDI Port 1] @1576058150.983414 [130, 60, 0]
[loopMIDI Port 1] @1576058161.087414 [176, 123, 0]
[loopMIDI Port 1] @1576058161.087414 [176, 121, 0]
[loopMIDI Port 1] @1576058161.088414 [177, 123, 0]
[loopMIDI Port 1] @1576058161.089414 [177, 121, 0]
[loopMIDI Port 1] @1576058161.091414 [178, 123, 0]
[loopMIDI Port 1] @1576058161.092414 [178, 121, 0]
[loopMIDI Port 1] @1576058161.093414 [179, 123, 0]
[loopMIDI Port 1] @1576058161.094414 [179, 121, 0]
[loopMIDI Port 1] @1576058161.094414 [180, 123, 0]
[loopMIDI Port 1] @1576058161.095413 [180, 121, 0]
[loopMIDI Port 1] @1576058161.096413 [181, 123, 0]
[loopMIDI Port 1] @1576058161.097413 [181, 121, 0]
[loopMIDI Port 1] @1576058161.098413 [182, 123, 0]
[loopMIDI Port 1] @1576058161.098413 [182, 121, 0]
[loopMIDI Port 1] @1576058161.099413 [183, 123, 0]
[loopMIDI Port 1] @1576058161.099413 [183, 121, 0]
[loopMIDI Port 1] @1576058161.100413 [184, 123, 0]
[loopMIDI Port 1] @1576058161.104413 [184, 121, 0]
[loopMIDI Port 1] @1576058161.107413 [185, 123, 0]
[loopMIDI Port 1] @1576058161.113413 [185, 121, 0]
[loopMIDI Port 1] @1576058161.115413 [186, 123, 0]
[loopMIDI Port 1] @1576058161.115413 [186, 121, 0]
[loopMIDI Port 1] @1576058161.116413 [187, 123, 0]
[loopMIDI Port 1] @1576058161.116413 [187, 121, 0]
[loopMIDI Port 1] @1576058161.117413 [188, 123, 0]
[loopMIDI Port 1] @1576058161.117413 [188, 121, 0]
[loopMIDI Port 1] @1576058161.118413 [189, 123, 0]
[loopMIDI Port 1] @1576058161.118413 [189, 121, 0]
[loopMIDI Port 1] @1576058161.119413 [190, 123, 0]
[loopMIDI Port 1] @1576058161.119413 [190, 121, 0]
[loopMIDI Port 1] @1576058161.123413 [191, 123, 0]
[loopMIDI Port 1] @1576058161.124413 [191, 121, 0]

Is this normal? Will this also happen under Linux? Will this affect other connected MIDI devices?

As far as I see it, the first three messages are sent by: midioutwrapper.py. The other ones are message like ALL NOTES OFF, etc..

Thanks

Best regards
Josef

[SpotlightKid]

Something is sending Reset All Controllers and All Notes Off CC messages on all 16 channels. It's not midioutwrapper.py, unless you changed it.

Maybe Bome MIDI Translator and loopMIDI do that when a MIDI source is closed?

[jmeile]

Hi

I guess it may be as you said. I just wanted to be sure that it is not the same on linux. Don't you get this on linux or on the system you are testing?

Best regards
Josef

[SpotlightKid]

No, I don't (Linux/ALSA, yes, Manjaro).

[jmeile]

So, I guess it must be a platform issue. The only change I did to midioutwrapper.py was to fix the inexistent constant: "MODULE" and I'm calling: "midiutil.open_midioutput()". Here it is:

if __name__ == '__main__':
	import time

	mout = None
	try:
		mout, in_port = midiutil.open_midioutput()
		mw = MidiOutWrapper(mout, ch=3)
		input('Connect to new MIDI port and then press key...')
		mw.send_program_change(40)
		mw.send_note_on(60)
		time.sleep(1)
		mw.send_note_off(60)
		time.sleep(0.1)
	except (EOFError, KeyboardInterrupt):
		print('')

	if mout != None:
		time.sleep(10)
		#mout.close_port()
		del mout

I thought that the problem was "mout.close_port()", so, I commented it, but it was the same.

[SpotlightKid]

python-rtmidi (or midioutwrapper.py) is not sending any MIDI messages implicitly, unless you tell it to.

You could also test midioutwrapper.py with midi-ox, which has a MIDI monitor.

[SpotlightKid]

So, I guess it must be a platform issue. The only change I did to midioutwrapper.py was to fix the inexistent constant: "MODULE" and I'm calling: "midiutil.open_midioutput()".

( I guess you mean MODULATION.)

As mentioned in #51 (comment) I pushed a similar fix.

[jmeile]

Yes, it is. It has an "if name == 'main':" line, so, if you call it without arguments, it shoud send a PROGRAM CHANGE, a NOTE ON, and finally a note off.

Regarding your fix: I'm aware of it; however, I'm using the PIP version, so, I guess it is not yet implemented there.

I will try this with my real MIDI hardware and see.

[jmeile]

I tried this on my Windows 10 PC by connecting two USB cables to my Laptop, then to a MIDI Switch (an EMAGIC Unitor 8) and python-rtmidi. It keeps sending those messages.

Doing this with another software called Bome SendSX (without python-rtmidi), exactly the same result, after disconnecting the output port, here is what I got on the input:

B0 7B 00
B0 79 00
B1 7B 00
B1 79 00
B2 7B 00
B2 79 00
B3 7B 00
B3 79 00
B4 7B 00
B4 79 00
B5 7B 00
B5 79 00
B6 7B 00
B6 79 00
B7 7B 00
B7 79 00
B8 7B 00
B8 79 00
B9 7B 00
B9 79 00
BA 7B 00
BA 79 00
BB 7B 00
BB 79 00
BC 7B 00
BC 79 00
BD 7B 00
BD 79 00
BE 7B 00
BE 79 00
BF 7B 00
BF 79 00

It seems that they are the same messages, so, I guess this is how MIDI is supposed to work on Windows.

[SpotlightKid]

That's good to know. Thanks for investigating.

[jmeile]

Yes, this doesn't happen on my Raspberry Pi (Raspbian Linux).

By the way, I see that on the midioutwrapper example at the end, you do:
del mout

Is this enough to close the ports? I'm doing something like this:

mout = None
try:
  mout, in_port = midiutil.open_midioutput()
  #Do some MIDI here
except (EOFError, KeyboardInterrupt):
  #Print exception here
  pass

if mout != None:
  mout.close_port()
del mout

Not sure if mout.close_port() is redundant here.

Best regards
Josef

[SpotlightKid]

It depends on the backend API and the Python implementation. If you want to be safe, either do .close_port() or use the MidiIn / MidiOut instance as a context manager:

mout = rtmidi.MidiOut()
mout.open_port(0)

with mout:
    mout.send_message(...)
    ...

[jmeile]

So, with the context manager will be "close_port" implicitly called? Or perhaps this will be done by the destructor of MidiOut?

[SpotlightKid]

The former.

The destructor just de-allocates the underlying C++ object. With some backend APIs this also closes open ports properly. With the Windows backend I'm not sure, probably not.

Also, you can't really control when the destructor is called.