Midi In misses Start (250) and Clock messages (248)

[max-circlefade]

Hey everyone,

midi_in.get_message() misses the start and clock messages, this is really weird.
I know they are sent by my device cause aseqdumb shows them in the terminal, however no trace of them within python..
I'm on a Rpi

All the other messages (stop, notes..) I receive with no problem.

Any idea how this can be?
Many thanks :)

[SpotlightKid]

Re: MIDI Clock (0xF8), have you enabled reception with MidiIn.ignore_types(timing=False)?

https://spotlightkid.github.io/python-rtmidi/rtmidi.html#rtmidi.MidiIn.ignore_types

Re. START (0xFA), I can't reproduce it. Please try the midiin_callback.py and midiin_poll.py example scripts and test whether they work for you or not.

[max-circlefade]

Hey, thanks a lot for the quick answer.
The ignore types line solved the clock messages issue, this is awesome thanks a lot :)

However still no start message, even when running the two test scripts...
From time to time, I do receive a start message but it's like once every ten times

Any idea ? The weird thing is that I get absolutely all the messages using aseqdump so maybe the problem comes from rpi - rtmidi ?

[SpotlightKid]

Weird. Can you check with the Jack API? Use the rtapi argument to the constructor.

https://spotlightkid.github.io/python-rtmidi/rtmidi.html#rtmidi.MidiIn

[max-circlefade]

So here is the test I ran:

import rtmidi
midi_in = rtmidi.MidiIn(rtapi=3)
midi_in.open_port(0)
api=midi_in.get_current_api()
if api == rtmidi.API_UNIX_JACK:
	print("Using JACK API for MIDI input.")
while 1:
	message= midi_in.get_message()
	if message:
		print(message)

Resulting in

MidiInJack::getPortName: no ports available!
Using JACK API for MIDI input.

I can't open the midi port :/
I'm going to try to solve this so I can test if I receive the start message with JACK api

[SpotlightKid]

• Did you compile python-rtmidi yourself (via pip install) or did you install it via apt-get?

• Do you use Jack1 or Jack2 (1.9.x)?

• How do you start JACK? Do you use the -X seq option?

[SpotlightKid]

Another thing you could test:

1. Clone my fork of rtmidi
2. cd into the rtmidi folder and switch to the python-rtmidi branch (git checkout python-rtmidi)
3. Compile it with ./autogen.sh --prefix=/usr; make
4. Run the ./tests/cmidiin program (or tests/qmidiin), open a virtual MIDI port with it and connect your MIDI source to it.

If this also drops MIDI START messages, the source of the problem is likely in RtMidi itself (or my fork) and not the Python binding. I tested this on my laptop and couldn't reproduce the problem. I will test this on a Raspi 3 with Raspbian later.

[SpotlightKid]

I have tried to reproduce your problem on a Raspi 3 with Raspbian 8 (Jessie), so Python 3.4, but I can't Everything is working as it should.

First, I tested with the Rtmidi cmidiin test program (compiled from my fork, as described above). I sent MIDI from another shell with the following Python code:

$ python
Python 3.4.2 (default, Jul 11 2019, 21:20:47) 
[GCC 4.9.2] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import time
>>> from rtmidi.midiutil import open_midioutput
>>> from rtmidi.midiconstants import TIMING_CLOCK, SONG_START, SONG_STOP
>>> mo, name = open_midioutput()
Do you want to create a virtual MIDI output port? (y/N) 
Available MIDI ports:

[0] Midi Through:Midi Through Port-0 14:0
[1] RtMidi Input Client:RtMidi Input 128:0

Select MIDI output port (Control-C to exit): 1
>>> while True:
...     mo.send_message([SONG_START])
...     mo.send_message([SONG_STOP])
...     mo.send_message([TIMING_CLOCK])
...     time.sleep(0.1)
... 

All messages were received and displayed by cmidiin without problems.

Then I attached a Novation Remote SL Zero MkII controlelr to the Raspi 3 via USB and programmed two buttons to send START and STOP and configured it to send out MIDI clock via USB. Again, All messages sent by the Remote SL Zero were received by cmidiin without problems.

Then I did the same test using the examples/basic/midiin_callback.py and examples/basic/midiin_poll.py scripts from python-rtmidi. Again, all START and STOP messages from the Remote SL Zero were received without problems. I inserted a midiin.ignore_types(timing=False) call into both scripts at the appropriate place and repeated the tests. Now also the MIDI clock messages were received and displayed without problems.

---

I'm afraid I can't offer any further help without some feedback on how to reproduce your problem. Can you give some more information on how you are testing this? From where are you sending the MIDI input? Is there any MIDI hardware involved? How did you install python-rtmidi?

[max-circlefade]

Hey, thanks so much for investigating the issue :)

I'm using an Arturia Drumbrute to send the messages, connected directly to the USB port of the rpi3. But the hardware doesn't seem to be the issue cause I am receiving all the messages using aseqdump.

Unfortunately I can't remember how I installed rtmidi, it was about a year ago..

I'm going to re-compile rtmidi asap yes, so I can check if this was the issue.
I will let you know!!

Best regards, Max

[SpotlightKid]

Could you reproduce the issue with the latest python-rtmidi? Otherwise I'm going to assume this was caused by an outdated version of python-rtmdii and close this issue as invalid in a couple of days.

[max-circlefade]

Hey!
Unfortunately no, didn't manage to do it yet.. yes close the issue no worries I'll let you know when I've run the tests

[lorenzofattori]

Just tested and Start - Stop and Clock work fine after enabling
midiin.ignore_types(timing=False)

This shall be added in some examples to improve the quality of the library

[SpotlightKid]

For receiving Start and Stop it is not necessary to use midiin.ignore_types(timing=False), only for MIDI clock ( F8).

Just re-tested this with the JACK and ALSA backends. If this does behave otherwise on the current version of python-rtmidi using other backend APIs, it would be a bug in the RtMidi C++ library and should be reported.