sauloverissimo

@yeahtuna< Yes, and it covers more than SysEx. In the fork the UMP writes are atomic: a message goes on the wire whole or not at all, never a fragment. That holds for any multi-word UMP, and multi-packet SysEx stops at the first short write...

@yeahtuna Nice, if it's your code you've got all the room to move things around. RAM2 should do it. By the numbers you were only 4288 bytes over on DTCM, so pushing a handful of variables to RAM2 (DMAMEM) should let the rest settle in. Less...

@yeahtuna, from what I'm seeing (I could be wrong), it's not the variables, it's ITCM. The variables are identical in both builds (168128). What grew is code: MIDI 2.0 adds ~20.7KB (340080 vs 319344), and that pushes ITCM from 10 to 11 32KB...

@yeahtuna, thanks a lot for the writeup, this really helps. A real-world install log is exactly what smooths the path for others. I'll fold it into the recipe README, because it matters. On C++17: Teensyduino 1.60+ already ships -std=gnu++17 by...

Hi @yeahtuna! Glad you're trying it out. I think it's something simple, and this should do it: The usb_midi2.h: No such file or directory error is from the other half of the setup, not from the library. Your midi2cpp from the Library Manager is...

Closing the validation loop on the Teensy 4.1 MIDI 2.0 device: the cores fork descriptors now pass the two references that matter. Windows MIDI Services (Microsoft's native stack): the Teensy enumerates as a native MIDI 2.0 endpoint over Kernel...

@yeahtuna, The current work lives entirely in the Teensy 4.x USB stack (iMXRT), and the 3.2 uses a different USB peripheral (Kinetis, Full Speed), so it isn't a recompile, it's a real port of the descriptors and the raw UMP I/O against the other...

Glad to hear it, @ETMoody3. The Korg Keystage is one of the very devices that satisfy the criteria Paul set, so plugging it into the Teensy host port is a solid test. Tell me more about your MIDI-to-CV build. It's exactly the kind of project...