Missing MIDI Note On/Off Messages with Akai MPK Mini Play Mk3

[tomdude126]

Hi,

First off, thank you for your work on this repository! I've been using it extensively and have found it very helpful.

Background
I have successfully used this library with several digital pianos (Yamaha and Casio) for my project. My main use case involves reading MIDI Note On and Off messages and controlling WS2812 LEDs based on those messages. However, I’m encountering issues when using the Akai MPK Mini Play Mk3 MIDI controller.

I’m using the up-to-date usb_midi_host with the EZ_USB_MIDI_HOST wrapper on a Raspberry Pi Pico 2, writing in C++ with VSCode on SDK 2.1.0 on Windows 11. A quick note: I’m not a highly experienced programmer, so a lot of the USB driver code is beyond my understanding.

Problem Description
When sending simultaneous Note On or Off messages (e.g., pressing 5–6 note chords), some messages are not received. During troubleshooting, I observed that the likelihood of missed messages increases if there are delays in the code, such as logic processing or sleep_ms commands. If I simplify the program to only output serial messages without additional processing, the issue seems to not be as bad, and no or minimal messages are missed.

I understand that when dealing with a large volume of MIDI data, it’s possible to overflow the buffer if the callback functions don’t process the data in time. However, this issue feels different—it seems like the messages never even sit in the buffer. Below is an example serial output when pressing four notes simultaneously with a sleep_ms(5) in the Note On and Note Off callbacks:

C1: Note on#48 v=95
C1: Note on#50 v=101
C1: Note off#50 v=0
C1: Note off#52 v=0
C1: Note off#48 v=0
C1: Note off#53 v=0

As you can see, two of the Note On messages were not detected. Additionally, I don’t see any FIFO overflow messages.

What Confuses Me
When using a different digital piano, everything works as expected. Messages stay in the buffer, and the program eventually processes them, even with delays in the code. With the Akai, however, the behavior is inconsistent.

I’ve been troubleshooting this issue using the EZ_USB_MIDI_HOST_example.cpp as a starting point. When I connect the Akai, I see the expected message:
MIDI device at address 1 has 1 IN cables and 1 OUT cables

When pressing single notes (even rather rapidly), all Note On and Off messages are received correctly. The MIDI sequence also plays through the Akai’s speakers as expected.

I’ve tried adjusting the buffer size (e.g., changing buffer[48] to smaller and larger sizes), but this did not resolve the issue. I’ve also confirmed that the Akai sends all messages correctly when tested with Ableton and MIDI diagnostic tools on Windows (MIDI-OX and MIDIView), so the issue doesn’t seem to be hardware-related.

Request for Help
I’m unsure where to go from here. Could this be a quirk with this specific MIDI controller's timing over USB, or is there something in the code that can be adjusted to fix this behavior? If additional details or tests would help diagnose the problem, I’d be happy to provide them.

Thank you in advance for any insights or suggestions, and apologies if I’ve missed any important information.

[tomdude126]

Oh and here is the contents of my tusb_config.h if its relevant

#ifndef _TUSB_CONFIG_H_
#define _TUSB_CONFIG_H_

#ifdef __cplusplus
 extern "C" {
#endif

#include "pico/stdio_usb.h"
//--------------------------------------------------------------------
// COMMON CONFIGURATION
//--------------------------------------------------------------------

// defined by compiler flags for flexibility
#ifndef CFG_TUSB_MCU
  #error CFG_TUSB_MCU must be defined
#endif

#if CFG_TUSB_MCU == OPT_MCU_LPC43XX || CFG_TUSB_MCU == OPT_MCU_LPC18XX || CFG_TUSB_MCU == OPT_MCU_MIMXRT10XX
  #define CFG_TUSB_RHPORT0_MODE       (OPT_MODE_HOST | OPT_MODE_HIGH_SPEED)
#else
  #define CFG_TUSB_RHPORT0_MODE       OPT_MODE_HOST
#endif

#ifndef CFG_TUSB_OS
#define CFG_TUSB_OS                 OPT_OS_NONE
#endif

// CFG_TUSB_DEBUG is defined by compiler in DEBUG build
// #define CFG_TUSB_DEBUG           0

/* USB DMA on some MCUs can only access a specific SRAM region with restriction on alignment.
 * Tinyusb use follows macros to declare transferring memory so that they can be put
 * into those specific section.
 * e.g
 * - CFG_TUSB_MEM SECTION : __attribute__ (( section(".usb_ram") ))
 * - CFG_TUSB_MEM_ALIGN   : __attribute__ ((aligned(4)))
 */
#ifndef CFG_TUSB_MEM_SECTION
#define CFG_TUSB_MEM_SECTION
#endif

#ifndef CFG_TUSB_MEM_ALIGN
#define CFG_TUSB_MEM_ALIGN          __attribute__ ((aligned(4)))
#endif

//--------------------------------------------------------------------
// CONFIGURATION
//--------------------------------------------------------------------

// Size of buffer to hold descriptors and other data used for enumeration
#define CFG_TUH_ENUMERATION_BUFSIZE 256

#define CFG_TUH_HUB                 0 // Enable USB hubs
#define CFG_TUH_CDC                 0
#define CFG_TUH_HID                 0 // typical keyboard + mouse device can have 3-4 HID interfaces
//NOTE: Do note #define CFG_TUH_MIDI 1 to enable MIDI Host. A code fragment in usbh.c that breaks the build if you do that
#define CFG_TUH_MSC                 1
#define CFG_TUH_VENDOR              0

// max device support (excluding hub device)
#define CFG_TUH_DEVICE_MAX          1//(CFG_TUH_HUB ? 4 : 1) // hub typically has 4 ports

// MIDI Host string support
#define CFG_MIDI_HOST_DEVSTRINGS 1

#ifdef __cplusplus
 }
#endif

#endif /* _TUSB_CONFIG_H_ */

[rppicomidi]

@tomdude126 Please have a look here. It is very hard to say why you are seeing missed packets without looking at your code. Do you observed dropped packets with the example programs for this library? If so, how about for the example programs for the underlying usb_midi_host library's example programs? Running the example program tests will give you more clues.

It could even be your hardware. The problem could be the power supply your hardware provides to the USB host or marginal signaling over USB. The easiest way to eliminate hardware as the issue is to enable hub support in your config file and attach a powered hub between your keyboard and your Pico board USB host. As long as the controller works through the powered hub to your computer, and as long as your other MIDI controllers work through the powered hub to your code, it seems likely that, if you are still having issues, that the problem is not hardware.

[tomdude126]

Thanks for your idea. While I have tried just about everything I can think of to no avail, I do have more data.

Hardware I’ve tried:

• Without USB Hub
• With USB Hub
  • Insignia 4 Port Powered Hub – Didn’t work at all. Maybe failed to enumerate
  • RSHTECH 4 Port USB 3.0 Powered HUB – Saw MIDI messages as expected but with missed messages as described.
• 3 Different USB Host powered MIDI controllers – All same issue
  -AKAI MPK Mini Play MK3
  -Donner Mini N-25
  -AKAI LPK25
• 3 Different USB Cables
  -USB A/B
  -USB C/C
• Raspberry Pico 1, Raspberry Pico 2
• Power Supplies Connected to VBus & GND Pin on Pico
  -5V/3A
  -5V/4A

For software, I'm using usb_midi_host_example.c from your usb_midi_host repository. And to restate the issue: I see messages coming in through UART fine if I press just a note at a time or even notes rather quickly in succession but if I press 4+ notes simultaneously there are missed midi messages. I've tested all of the 3 MIDI controllers listed above on windows MIDI diagnostic programs, and I don't see any dropped midi messages regardless of how many simultaneous notes I press. If I add a sleep_ms statement to the while loop, the problem exacerbates:

int main() {

    bi_decl(bi_program_description("A USB MIDI host example."));

    board_init();

    printf("Pico MIDI Host Example\r\n");
    tusb_init();
    while (1) {
        tuh_task();

        //blink_led();
        //bool connected = midi_dev_addr != 0 && tuh_midi_configured(midi_dev_addr);

        //send_next_note(connected);
        sleep_ms(2); //adjust this for testing
    }
}

Given that I have not had any issue with any keyboards that use an external power supply, I'm inclined to believe this issue is isolated to MIDI keyboards that use USB Host for power. I've also put a multimeter on Vbus and GND and it consitently reads ~5.2V regardless of what notes I was playing on the controller.

I've made my set up as bare bones as possible wiring wise as you can see in the attached pic. It only contains power and UART/SWD going to my pico debugger. And of course, the USB cable to the midi device.

At this point, I'm not sure if it's a problem with the underlying TinyUSB code (i've tried V18 as well as the latest master branch) or with your MIDI code, but I'm interested in getting your thoughts. Do you have access to a USB Host powered MIDI keyboard you could test yourself to see if you get similar results?

[rppicomidi]

@tomdude126 Sorry for the delay in my reply (I have been away from home), and thank you for posting this issue. There may be a software bug here, or maybe not. First some questions.

Did you change your configuration file? With this line:

#define CFG_TUH_HUB                 0 // Enable USB hubs

I am not sure how hubs worked at all. What is your target hardware board? It seems to have a USB C connector instead of Micro B. Also, it has no Raspberry Pi logo.

With an Arturia Keylab Essential 88, I was able to duplicate missing one note on a 4-note chord once using the EZ_USB_MIDI_HOST_example in the C-code directory, but it is very hard. With 5+ simultaneous notes, it is easier. I believe that bus power vs. self-power might be a distraction or a complicating factor. I was not able to duplicate the issue at all with 2 different bus powered Korg fader control surfaces that send note messages on certain button presses (8 simultaneous button presses). I suspect that it depends on how the controller packs note messages into USB packets and how quickly the TinyUSB host controller driver polls the attached MIDI device, but I will need to hook up my packet sniffer to confirm. That will be an experiment for another day.

If you want to investigate the issue yourself with a packet sniffer of your own, have a look at this article. The Pico USB Host Troubleshooting](https://github.com/rppicomidi/pico_usb_host_troubleshooting) document also has information on looking at USB descriptors and debugging power issues. It might be worth your time.

[tomdude126]

@rppicomidi

No worries on the delay. I appreciate your time.

Did you change your configuration file? With this line:

Yes I changed the 0 to a 1 to make the 1 hub work. You are correct that it does not work without that change.

What is your target hardware board? It seems to have a USB C connector instead of Micro B. Also, it has no Raspberry Pi logo.

In that picture I was using a raspberry pico 1 clone w/ usb c from aliexpress. But, I have been doing most of my testing with an official raspberry pico 2 (with the logo and all!) with a Micro B to USB A adapter.

Thanks for the troubleshooting link. It's very insightful for a USB noob. I ordered one of those usb breakout boards. I will attempt to get 'usb-sniffer-lite' working when it comes in. I'm not super confident in my ability to be able to recognize what I should be looking for, but maybe I'll see a smoking gun.

With an Arturia Keylab Essential 88, I was able to duplicate missing one note on a 4-note chord once using the EZ_USB_MIDI_HOST_example in the C-code directory, but it is very hard. With 5+ simultaneous notes, it is easier.

Interesting! All of the pianos that I have tried that don't have any issue are full size or 61 key digital pianos with speakers built in. And as I noted before, the problem gets even worse for me if I have a bunch of processing in my callback functions (controlling WS2812 lights, building chords and sending midi back to piano, arpeggiation, etc.). My understanding was that even if the processor is busy while a new midi packet is sent from the device to the pico, it wouldn't get lost unless the buffer was full. Can you provide any clarity on if this is correct or am I misunderstanding how USB MIDI works? Like is tinyusb's FIFO supposed to populate even when not calling tuh_task()?

Can you test something on your Arturia 88? I know it has a wall adapter but I'm curious if the wall adapter is powering the USB port or if it actually requires power on VBUS from the pico. I've found that on my Casio 88 key digital piano, that I don't need to have power on VBUS for your library to work. I can put it on Vsys instead, indicating it requires no USB bus power (from the pico) at all to talk over USB. Maybe the wall adapter for the Arturia is used to power the LEDs, screen, etc, but not provide power to USB?

Apologies if any of these questions are nonsensical. I'll report back if I'm able to find any smoking guns after running the usb sniffer. I probably won't get to that til mid week. Look forward to hearing if you have any more suggestions before that! Thanks!

Also, I did run the usb descriptor dump you linked, and here's my output. Again, the AKAI is the problematic device, and the Casio works great, I can smash down all of the keys at the same time and tinyusb/usb_midi_host processes all the messages.

AKAI MPK MINI PLAY MK3.txt
CASIO-S110.txt

[rppicomidi]

@tomdude126 First off, none of your observations or questions are nonsensical. Thank you for filing this issue.

If you build your own sniffer, you might find the USB MIDI Class specification helpful. Click the PDF link. There is a lot of stuff in that specification that you don't need to understand to debug this issue. What you do need is the packet specification. Each MIDI message is in 4 bytes. The first byte indicates the virtual cable that carries the message and how many bytes of the 3 remaining bytes in the 4 byte packet contain useful data. The remaining 3 bytes contain the standard MIDI 1.0 message. In USB Sniffer Lite, the terminal window will have something like this for note on message

  1000 : SOF #1971                                                                                                                     
     4 : IN: 0x01/1                                                                                                                    
     6 : DATA0 (4): 09 90 1c 48                                                                                                        
    12 : ACK       

The 09 means virtual cable 0, note on message (3-bytes). 90 1c 48 is Note On, note number 0x1c, velocity 0x48. See section 4 of the USB MIDI class specification document for more information.

This brings me to why I just tagged this issue a bug. I copied that message from a USB Sniffer Lite buffer output. When I observe missing note messages displayed on the EZ_USB_MIDI_HOST_example printout, I also observe that the message is not being displayed on the sniffer output.

The usb_midi_host driver is called by the tuh_task() function call. That function looks to see if there are any completed IN transfers (data from the keyboard to the Pico board) and calls the midih_xfer_cb() function, which stashes all transferred bytes into a buffer and then starts a new transfer. So if tuh_task() is not being called fast enough, the driver relies on the keyboard to buffer note data until the tuh_task() function is called again.

It just might be that the keyboard is not sending the missing note on messages. The only things I can think of that could cause that would be if the host is not polling the keyboard fast enough to pull all the messages from the keyboard's output buffer before they get overwritten inside the keyboard or if the sniffer is introducing USB data errors and is not detecting them. This is a very puzzling issue. I need to think on what to do.

The reason I asked for the descriptors is I was curious how large the endpoint transfer buffers are. Some keyboards only have 8 byte endpoint buffers. USB data moves via endpoints. An 8-byte buffer has room for at most 2 MIDI messages. The Akai endpoint buffer is 32 bytes and the Casio is 64 bytes. Since a note message is 4 bytes, both are theoretically large enough to hold multiple messages. However, I observe with my Arturia keyboard that only one note message gets packed into a transfer.

BTW, my Keylab Essential 88 accepts a 9V supply, but it is bus powered in my setup.

[tomdude126]

@rppicomidi Thanks for the resource. Very informative!

When I observe missing note messages displayed on the EZ_USB_MIDI_HOST_example printout, I also observe that the message is not being displayed on the sniffer output.

I got 'usb_sniffer_lite' set up and experienced the same thing when the sniffer is between my midi controller and the pico. I also put the sniffer in between my midi controller and my windows PC and found that the buffer fills up so fast that I don't even really have time to test my midi controller before the capture stops. Just a bunch of:

Capture buffer:
     0 : NAK
    58 : IN: 0x18/2
    61 : NAK
   116 : IN: 0x18/2
   119 : NAK
   178 : IN: 0x18/2
   181 : NAK
   235 : IN: 0x18/2
......
......
.......

The only things I can think of that could cause that would be if the host is not polling the keyboard fast enough to pull all the messages from the keyboard's output buffer before they get overwritten inside the keyboard or if the sniffer is introducing USB data errors and is not detecting them.

I think you're right about this. I'm assuming the usb sniffer buffer filled up so fast on my windows PC because its polling much faster and my midi controller is sending the negative acknowledgement much faster than when it's connected to the pico. And I'm guessing they built these midi controllers assuming they'd be hooked up to a PC and not a much lower clock rate MCU. I'm assuming the clock frequency of the processor is the ultimate bottleneck unless you can think of any other way to increase the potential USB polling rate.

With this in mind, I did have the idea to take my first stab at multi-threaded programming. My idea is to just put all the USB stuff on core 0 ( tuh_task(), usbhMIDI.readAll(), usbhMIDI.writeFlushAll) and do all my other processing on core 1. The callbacks will also run on core0 ,and to reduce processing time as much as possible the callbacks could maybe just write the midi data into some sort of FIFO that core1 will process. And vice versa, when I need to send MIDI to my keyboard, I will write to some FIFO in core1 and core0 will send it out.

I'm doing some proof of concept testing now and it has definitely been positive. On the AKAI MPK MINI PLAY MK3 and DONER N25 I am able to smash keys and see an equal amount of note on and note off events. BUT the AKAI LPK25 MK2 still misses messages. I do hope there's some other solution than relying on multithreading so I don't have to rewrite a bunch of code on the project I'm working on but atleast it's seemed to improve the problem on 2 of the 3 problematic controllers but I am trying to maximize compatibility.

Below is where I'm at on my multi threaded proof of concept. I only am testing Note On and Note Off MIDI events for now and the program will also send a 5th above of the note detected back to the MIDI device. I'm sure it's still buggy atm and disclaimer - I used chatgpt to generate a lot of it:

#include <stdio.h>
#include "pico/stdlib.h"
#include "pico/multicore.h" //make sure to add pico_multicore to target_link_libraries in cmakelists.txt
#include "pico/binary_info.h"
#include "bsp/board_api.h"
#include "EZ_USB_MIDI_HOST.h"

USING_NAMESPACE_MIDI
USING_NAMESPACE_EZ_USB_MIDI_HOST
RPPICOMIDI_EZ_USB_MIDI_HOST_INSTANCE(usbhMIDI, MidiHostSettingsDefault);

// MIDI message structure
struct MidiMessage {
    uint8_t status;   // Note On/Off
    uint8_t note;     // Note Number
    uint8_t velocity; // Velocity
    uint8_t channel;  // MIDI Channel (0-15)
};

// Buffer sizes (must be power of 2)
#define MIDI_BUFFER_SIZE 64

// **Ring Buffers**
volatile MidiMessage midiInBuffer[MIDI_BUFFER_SIZE];
volatile uint8_t midiInHead = 0, midiInTail = 0;
volatile MidiMessage midiOutBuffer[MIDI_BUFFER_SIZE];
volatile uint8_t midiOutHead = 0, midiOutTail = 0;

// USB MIDI device
static uint8_t midiDevAddr = 0;

/* 🔹 Core 0: USB MIDI Handling (MIDI IN & OUT) */
void usb_task_loop() {
    while (true) {
        tuh_task();  
        usbhMIDI.readAll();  

        if (midiOutHead != midiOutTail) {
            // Copy message from volatile buffer
            MidiMessage msg;
            msg.status = midiOutBuffer[midiOutTail].status;
            msg.note = midiOutBuffer[midiOutTail].note;
            msg.velocity = midiOutBuffer[midiOutTail].velocity;
            msg.channel = midiOutBuffer[midiOutTail].channel;

            // Advance tail index
            midiOutTail = (midiOutTail + 1) % MIDI_BUFFER_SIZE;

            // Send MIDI message
            auto intf = usbhMIDI.getInterfaceFromDeviceAndCable(midiDevAddr, 0);
            if (intf != nullptr) {
                if (msg.status == 0x90 && msg.velocity > 0) {
                    intf->sendNoteOn(msg.note, msg.velocity, msg.channel + 1);
                } else {
                    intf->sendNoteOff(msg.note, msg.velocity, msg.channel + 1);
                }
            }

            usbhMIDI.writeFlushAll();

            // Log output
            printf("CPU0 W Ch%u N%u V%u %s\n", 
                   msg.channel, msg.note, msg.velocity, 
                   (msg.status == 0x90 && msg.velocity > 0) ? "NoteOn" : "NoteOff");
        }

       // sleep_ms(1);
    }
}

/* 🔹 Core 1: MIDI Processing (Reads midiInBuffer, Writes to midiOutBuffer) */
void core1_main() {
    while (true) {
        if (midiInHead != midiInTail) {
            // Copy message from volatile buffer
            MidiMessage msg;
            msg.status = midiInBuffer[midiInTail].status;
            msg.note = midiInBuffer[midiInTail].note;
            msg.velocity = midiInBuffer[midiInTail].velocity;
            msg.channel = midiInBuffer[midiInTail].channel;

            // Advance tail index
            midiInTail = (midiInTail + 1) % MIDI_BUFFER_SIZE;

            // Log input
            printf("CPU1 R Ch%u N%u V%u %s\n", 
                   msg.channel, msg.note, msg.velocity, 
                   (msg.status == 0x90 && msg.velocity > 0) ? "NoteOn" : "NoteOff");

            // **Handle Note On (Generate Arpeggio)**
            if (msg.status == 0x90 && msg.velocity > 0) {
                // Generate an arpeggio note (perfect fifth above)
                uint8_t newNote = msg.note + 7;
                uint8_t newVelocity = msg.velocity - 20;

                // Store the new Note On message
                uint8_t nextHead = (midiOutHead + 1) % MIDI_BUFFER_SIZE;
                if (nextHead != midiOutTail) {
                    midiOutBuffer[midiOutHead].status = 0x90;
                    midiOutBuffer[midiOutHead].note = newNote;
                    midiOutBuffer[midiOutHead].velocity = newVelocity;
                    midiOutBuffer[midiOutHead].channel = msg.channel;
                    midiOutHead = nextHead;
                }
            }

            // **Handle Note Off (Turn Off Original & Arpeggio Notes)**
            if (msg.status == 0x80 || (msg.status == 0x90 && msg.velocity == 0)) {
                // Store Note Off for the original note
                uint8_t nextHead = (midiOutHead + 1) % MIDI_BUFFER_SIZE;
                if (nextHead != midiOutTail) {
                    midiOutBuffer[midiOutHead].status = 0x80;
                    midiOutBuffer[midiOutHead].note = msg.note;
                    midiOutBuffer[midiOutHead].velocity = msg.velocity;
                    midiOutBuffer[midiOutHead].channel = msg.channel;
                    midiOutHead = nextHead;
                }

                // Store Note Off for the arpeggio note
                uint8_t arpeggioNote = msg.note + 7;
                nextHead = (midiOutHead + 1) % MIDI_BUFFER_SIZE;
                if (nextHead != midiOutTail) {
                    midiOutBuffer[midiOutHead].status = 0x80;
                    midiOutBuffer[midiOutHead].note = arpeggioNote;
                    midiOutBuffer[midiOutHead].velocity = msg.velocity;
                    midiOutBuffer[midiOutHead].channel = msg.channel;
                    midiOutHead = nextHead;
                }
            }
        }
    }
}

/* 🔹 Core 0: Store Incoming MIDI Data in midiInBuffer */
static void storeMidiMessage(uint8_t status, uint8_t note, uint8_t velocity, uint8_t channel) {
    uint8_t nextHead = (midiInHead + 1) % MIDI_BUFFER_SIZE;
    if (nextHead != midiInTail) {  
        midiInBuffer[midiInHead].status = status;
        midiInBuffer[midiInHead].note = note;
        midiInBuffer[midiInHead].velocity = velocity;
        midiInBuffer[midiInHead].channel = channel;
        midiInHead = nextHead;
    }
}

/* 🔹 Core 0: MIDI Callbacks */
static void onNoteOff(Channel channel, byte note, byte velocity) {
    storeMidiMessage(0x80, note, velocity, channel - 1);
}

static void onNoteOn(Channel channel, byte note, byte velocity) {
    storeMidiMessage(0x90, note, velocity, channel - 1);
}

/* 🔹 Core 0: Register Callbacks */
static void registerMidiInCallbacks() {
    auto intf = usbhMIDI.getInterfaceFromDeviceAndCable(midiDevAddr, 0);
    if (intf == nullptr) return;
    intf->setHandleNoteOff(onNoteOff);
    intf->setHandleNoteOn(onNoteOn);
}

/* 🔹 Core 0: Handle MIDI Device Connections */
static void onMIDIconnect(uint8_t devAddr, uint8_t nInCables, uint8_t nOutCables) {
    printf("MIDI device at address %u connected.\n", devAddr);
    midiDevAddr = devAddr;
    registerMidiInCallbacks();
}

static void onMIDIdisconnect(uint8_t devAddr) {
    printf("MIDI device at address %u disconnected.\n", devAddr);
    midiDevAddr = 0;
}

/* 🔹 Main Entry Point */
int main() {
    bi_decl(bi_program_description("USB MIDI Host with MIDI Channel Support"));
    board_init();
    usbhMIDI.begin(0, onMIDIconnect, onMIDIdisconnect);

    printf("Starting USB MIDI Host...\n");

    sleep_ms(500);  

    multicore_launch_core1(core1_main); // Start Core 1
    usb_task_loop(); // Core 0 handles USB tasks

    return 0;
}

I look forward to seeing if you come up with anything else! Thanks!