USBMIDI library leads to weird behavior on applications

Projects Networking, Protocols, and Devices
1

I'm using the well-known USBMIDI library on a Leonardo-based board.
My code is pretty simple and very similar to the examples. It works fine on a test environment, but when I use it with common music applications like Cubase or Kontact leads to weird behaviors.

I've already opened an issue on github but it hasn't received any answer yet.

I try to ask an advice also here. Perhaps someone has already faced the same problem.
Here the relevant code of my firmware:

#define ADC_BASE              18

typedef struct
{
    int value;
    int shadow;
} slider_t;

slider_t sliders[3];
byte cc[3] = {1, 11, 2};

void loop() 
{
  // MidiUSB.read();
  for (byte i = 0; i < 3; i++) sendMIDI(i, analogRead(ADC_BASE + i));
}

void sendMIDI(byte idx, int adc)
{  
    sliders[idx].value = map(adc, 0, 1023, 0, 127);
    if (sliders[idx].shadow != sliders[idx].value)
    {
        if (MidiUSB.isAvailable() == 0) sendControlChange(0, cc[idx], sliders[idx].value);
        sliders[idx].shadow = sliders[idx].value;
    }
}

void sendControlChange(byte channel, byte control, byte value) 
{
    midiEventPacket_t event = { EVENT_CONTROL_CHANGE, (byte) (0xB0 | channel), control, value };
    MidiUSB.sendMIDI(event);
    MidiUSB.flush();
    // delay(10);
}

The comments are some trials I made with no success.

Cubase v12.0.60 on Windows 10 stops to receive messages after a while. Sometimes, the window does not respond anymore.

Kontakt Full Standalone v7.3.0 often loses the instrument and I have to assign it again. But whenever I send another message it happens again.

Do you see any mistake in my code?

2

Are you sure you know which part of your code is relevant for the problem?

Given the posted code contains the relevant parts, you flood the consuming program with changes which mostly aren't changes. Save the sent value and resend it only if it actually changed.

3

Are you sure you know which part of your code is relevant for the problem?

The handling of the display or the manipulations of the ADC value should not matter. I tried to report all the code about the MIDI stuff.

you flood the consuming program with changes which mostly aren't changes. Save the sent value and resend it only if it actually changed.

I already do this, at least if I understand correctly what you're saying. This line:

if (sliders[idx].shadow != sliders[idx].value)

compare the current value with the previous one (shadow). It sends the message only if they differ.

Anyway, I have an update after spending the whole day to try it.
The issue is not related to those softwares only, but happens in any case. I tried different monitors to show the actual MIDI packets and after some time (seconds or minutes) no messages are received anymore.

From the Arduino side I noticed the channel is no more writable, i.e. USB_Available(MIDI_TX); returns 0. And this may happen in few seconds or in several minutes, regardless how many packets I sent. The USB device is still there, it's like the "communication channel" will be closed but I cannot understand why and by who.

Furthermore, the issue does not happen in either Linux or Mac, it seems only a Windows problem (tried on 3 different machines).

4

You're right, I was wrong, sorry about that.

5

This topic was automatically closed 180 days after the last reply. New replies are no longer allowed.