midifilter.lv2 VS tinyusb

You can use the MIDI Key-Range Filter (by Robin Gareus) https://x42-plugins.com/x42/x42-midifilter . Add an Ardour midi bus. Use Ardour to change the output of your piano to the new midi bus. Add 2 plugins to the midi bus 1) an instance of the Midi Key-Range Filter, 2) copy your piano midi instrument to the midi bus. Left click on the Midi Key-Range Filter, set the low and high note to E4, set the operation range to "Exclude Range". You are instructing the Midi Key Range Filter to output all notes except #E4.

And don't forget about midi humanization/randomization plugins, though, like X42 ones, so it won't sound dull or robotic.

i'd suggest using one of R Gareus lv2filters (https://x42-plugins.com/x42/x42-midifilter) possibly hosted by the jalv program if there is no other LV2 host in your setup. The "midi keys transpose filter" might do what you want. It might be agood starting point if you need to roll your own.

I am not specialist by complex MIDI work, but as I know there are MIDI filters. So you can route the same Musescore MIDI output to some MIDI tracks in Ardour and filter out all except of required instrument for each Ardour track. May be MIDI Channel filter will do this work: https://x42-plugins.com/x42/x42-midifilter

Not sure if FLStudio supports LV2 plugins, but there might be something here: https://x42-plugins.com/x42/x42-midifilter

Does qsampler support lv2.plugins or can you run it in a plugin host? https://github.com/x42/midifilter.lv2 has a plugins to filter on a variety of criteria, I'd be surprised if it can filter pitch-bends.

Implementing the required USB host interface is another hurdle, but tinyusb seems to have sorted most of that out, except that UAC2 is implemented as a device while you need a host.

Have a look at TinyUSB. It supports the STM32WB and demo programs for the Nucleo-WB55RG. It even offers an example for dual CDC ports, so very close to what you're looking for.

Second: Distrust, misunderstanding, and out of date opinions of C++ in embedded spaces. I often see "compatibilty" thrown around as a goal for using C and not C++, but for most modern embedded systems, C++ compilers exist and are (usually) well tuned. Arm is a shining example here*. C++ is more optimizable than C as the intent can be clearer to the compiler. C++ constexpr and templates are a godsend for embedded systems, and I used both heavily in my recent arduino and pico testing. I combined both of them for a really cool experimental USB interface descriptor builder that runs at compile time and avoids the need to count byte sizes, but I gave up on it when the maintainer said C only, despite the fact that C can't do that. I was similarly disappointed when the pico "C++" was C only, as there was no backwards compatibility necessary.

I looked at this but the fork seems to have had a lot of problems from looking at the PR: https://github.com/hathach/tinyusb/pull/1219

I think a better solution might be to use a USB flash drive in the usbc port. Unfortunately micropython and circuitpython don't support this (yet), so you'd have to use c++ https://github.com/hathach/tinyusb

It's possible to make the s3 be a mass storage device via TinyUSB. https://github.com/hathach/tinyusb/tree/master/examples/device/cdc_msc_freertos