Arduino-BLE-MIDI: setHandleNoteOn called when it shouldn't

I’m using the Arduino-BLE-MIDI library in my project, latest version, it’s almost identical to the MidiBle.ino example. On my computer I have a 1 bar MIDI loop going in Ableton Live. Everything works for some time, but every now and then I get two weird Note-On events.

HUB :: Note-On channel: 2 note: 61 velocity: 100 HUB :: Note-Off channel: 2 note: 61 velocity: 64 HUB :: Note-On channel: 2 note: 129 velocity: 71 <- weird HUB :: Note-On channel: 2 note: 64 velocity: 145 <- weird HUB :: Note-On channel: 2 note: 61 velocity: 100 HUB :: Note-Off channel: 2 note: 61 velocity: 64 HUB :: Note-On channel: 2 note: 68 velocity: 100 HUB :: Note-Off channel: 2 note: 68 velocity: 64

The notes in my clip are 61, 57, 68 and 71 and have a velocity of 100. You can see that after a note-on message a note-off if received. In my clip there is no note 129 with velocity 71, and there is no note 64 with velocity 145 (obviously).

About this issue

Original URL
State: closed
Created 3 years ago
Comments: 37 (37 by maintainers)

Commits related to this issue

protect RxQueue with a Mutex (see issue #27) protect RxQueue with a Mutex See https://github.com/lathoub/Arduino-BLE-MIDI/issues/27 Add() calls to xQueueSend() and copies only 1 byte to Queue. When... — committed to lathoub/Arduino-BLE-MIDI by deleted user 3 years ago
bug fix https://github.com/lathoub/Arduino-BLE-MIDI/issues/27 — committed to lathoub/Arduino-BLE-MIDI by lathoub 3 years ago

Most upvoted comments

https://github.com/lathoub/Arduino-BLE-MIDI/blob/c20062ec6322ffff48d861511fedd906c5e2789c/src/BLEMIDI_Transport.h#L229-L231

You recommend not using RUNNING_ENABLE - yet the underlying parser does support runningStatus for incoming messages and runs fine with the RUNNING_ENABLE enabled or disabled (running msvc examples renders the same result). I kinda like the efficiency that runningStatus brings.

Based on the current examples in BLEMIDI_Sim.h, i recommend making RUNNING_ENABLE permanent. WDYT @RobertoHE ?

I only have tested the parser with default settings of serial parser of main midi class. I haven’t have time for check if any other options of setting class would interference with runningStatus mode.

If any setting option not interferences with it, runningStatus enable is prefered because it uses less resorces.

Other option is change #defines by if(Settings::option). This will add some computer cycles to parser but it would be transparent to end user or end application.

Would you check it in paralle?

RobertoHE on Aug 6, 2021

You are right, it is not neccessary.

0xF0s have 1 byte lenght, except SysEx.

https://github.com/lathoub/Arduino-BLE-MIDI/blob/c20062ec6322ffff48d861511fedd906c5e2789c/src/BLEMIDI_Transport.h#L341-L342

Is this code needed? Looks like it can be removed. The switch below does not test for SystemExclusive

RobertoHE on Aug 6, 2021

For this package (08 F7 80 34 2B F7 81 34 2B F8 82 34 2B), receive() had to add to the buffer the

The first byte (0x08) is not valid, bit 7 needs to be 1 (I guess a typo) (the message from the logs had the bit set to 1)

It is true. First byte is wrong in my example. It is possible that when I copied this I accidentally changed 0x80 to 0x08. First bit always must be 1 in high timeStamp byte

RobertoHE on Aug 2, 2021