Port name reported as "None"

[funfunfunfunfunmike]

I'm on macOS Sierra 10.12.3, and running Python 2.7.11 in a virtualenv with only rtmidi 1.1.0 installed.

When I go to Audio MIDI Setup, or other applications that let me view the port names of connected MIDI devices, I see one of my devices port names listed as:

Midi Fighter 3D�̨w

Note the unicode character: http://www.fileformat.info/info/unicode/char/0328/index.htm

I've e-mailed DJTechTools, the developers of this hardware, to ask if it's intentional that there is a strange character in their firmwares reporting of the port name.

However, when I perform the following with rtmidi:

rtmidi.MidiIn().get_ports()
[u'IAC Driver Plustype_IAC', u'nanoKONTROL2 SLIDER/KNOB', u'FastTrack Pro', None, u'Midi Fighter Twister']

I see the device with the unicode character have its port name reported as "None". If I connect to this device by port index rather than by name, I can successfully receive messages from the device, so I know this is the correct port. I'm not sure if this issue is in the underlying C++ rtmidi or in the Python bindings.

[SpotlightKid]

Try to pass an appropriate encoding parameter to get_port_name.

get_port_name(self, unsigned int port, encoding='auto')

Return the name of the MIDI input or output port with given number.

Ports are numbered from zero, separately for input and output ports. The number of available ports is returned by the get_port_count method.

The port name is decoded to a (unicode) string with the encoding given by encoding. If encoding is "auto" (the default), then an appropriate encoding is chosen based on the system and the used backend API. If encoding is None, the name is returned un-decoded, i.e. as type str in Python 2 or bytes in Python 3.

[funfunfunfunfunmike]

Unfortunately, I've tried None, utf-8, utf-16,utf-32 and continue to receive None as the portname:

rtmidi.MidiIn().get_ports()
[u'IAC Driver Plustype_IAC', u'nanoKONTROL2 SLIDER/KNOB', u'FastTrack Pro', None, u'from Max 1', u'from Max 2']
rtmidi.MidiIn().get_ports(encoding=None)
['IAC Driver Plustype_IAC', 'nanoKONTROL2 SLIDER/KNOB', 'FastTrack Pro', None, 'from Max 1', 'from Max 2']
rtmidi.MidiIn().get_ports(encoding="utf-8")
[u'IAC Driver Plustype_IAC', u'nanoKONTROL2 SLIDER/KNOB', u'FastTrack Pro', None, u'from Max 1', u'from Max 2']
rtmidi.MidiIn().get_ports(encoding="utf-16")
[u'\u4149\u2043\u7244\u7669\u7265\u5020\u756c\u7473\u7079\u5f65\u4149', u'\u616e\u6f6e\u4f4b\u544e\u4f52\u324c\u5320\u494c\u4544\u2f52\u4e4b\u424f', u'\u6146\u7473\u7254\u6361\u206b\u7250', None, u'\u7266\u6d6f\u4d20\u7861\u3120', u'\u7266\u6d6f\u4d20\u7861\u3220']
rtmidi.MidiIn().get_ports(encoding="utf-32")
[u'', u'', u'', None, u'', u'']

[SpotlightKid]

It seems that the C++ RtMidi call getPortName returns an empty string for your device.

Are you able to run the example code from here and confirm this or report any errors it may give?

http://www.music.mcgill.ca/~gary/rtmidi/index.html#probing

See here for an explanation on how to compile the example:

http://www.music.mcgill.ca/~gary/rtmidi/index.html#compiling

[funfunfunfunfunmike]

Yes, I was able to compile this. It does appear to return the empty string:

$ ./midiprobe

Compiled APIs:
OS-X CoreMidi

Current input API: OS-X CoreMidi

There are 2 MIDI input sources available.
Input Port #1: IAC Driver Plustype_IAC
Input Port #2:

Current output API: OS-X CoreMidi

There are 2 MIDI output ports available.
Output Port #1: IAC Driver Plustype_IAC
Output Port #2:

Interesting, since the port name is read and shows up in Audio Midi Setup, and in utility apps like MIDI Monitor and in Ableton.

[SpotlightKid]

It seems like this is a bug in RtMidi. Can you please report it here?

https://github.com/thestk/rtmidi/issues

Be sure to mention your OS version and how the device name appears in other software.

[funfunfunfunfunmike]

Thanks for all your help - sorry for the false alarm reporting this on the Python side.

I've submitted the bug here:
thestk/rtmidi#115

[SpotlightKid]

Thanks and no worries. Getting to the bottom of problems is what this issue tracker is here for.

[SpotlightKid]

The upstream issue was closed as fixed, so I'm assuming this is fixed in python-rtmidi too. Of not, feel free to re-open the issue.