As of January 2026, Microsoft has started rolling out Windows MIDI Services which includes multi-client MIDI ports, lower latency / jitter and MIDI 2.0 support. I don't really care for MIDI 2.0 support to satisfy my needs, but I'm certain my customers are going to be asking for it.
Midi 2.0
- Thread starter yeahtuna
- Start date
I just hope that MIDI 1.0 will continue to be supported. I have lots of hardware using good old midi that just work. Also I have my own projects that I use good old MIDI and 127 different values per potentiometer is more than enough (can't move the knob more precisely). Zipper noise is not an issue as I have adaptive exponential parameter smoothing in software in 32 bit float so changes are both perfectly smooth (way beyond 16K promised by MIDI2) and quick and absolutely zero zipper noise. This is also the technique that hardware VA synths use (like Access Music Virus TI).
Thundercat
Well-known member
Can you share what you mean by "zipper noise"?
Zipper noise occurs when you change a parameter of sound synthesis path such as oscillator freq, amp, filter cutoff, delay time, etc, in a "stepped" way.
Analog signals are smooth, so when you turn say frequency knob in analog circuit the frequency sweeps in smooth way.
When you control digital oscillator using MIDI parameter (such as CC message) it has 127 discrete "steps" and changes occur in stepped way that creates audible ("zipper") noise, UNLESS you perform parameter smoothing that interpolates single-step big change into thousands of perfectly smooth, per-sample microscopic changes (something like smooth "bezier curve" between points). Then you have noise-free parameter change, even if your CC resolution is 7 bit MIDI 1.0.
Analog signals are smooth, so when you turn say frequency knob in analog circuit the frequency sweeps in smooth way.
When you control digital oscillator using MIDI parameter (such as CC message) it has 127 discrete "steps" and changes occur in stepped way that creates audible ("zipper") noise, UNLESS you perform parameter smoothing that interpolates single-step big change into thousands of perfectly smooth, per-sample microscopic changes (something like smooth "bezier curve" between points). Then you have noise-free parameter change, even if your CC resolution is 7 bit MIDI 1.0.
Last edited:
Thundercat
Well-known member
Beautiful explanation, thank you!
To be fair, the only times I can recall personally having this issue was with older outboard gear (e.g. my JP-8000), and obviously those can't get fixed by MIDI2.0. I don't know how much current equipment and software do interpolation. Most? All? Not sure. While it's a really smart fix for an old limitation, it's not great separation of concerns. Maybe I'm just being pedantic.
That aside. I am having a lot of fun with my Teensy4.1s. I eventually realized it's a lot more enjoyable to build what I want now rather than sitting around waiting for everyone from Microsoft to firmware developers to wrap up all their hard work first. I have a pretty ambitious project (for me anyway) that I'm almost done with the hardware for. If I learned anything it's that the Teensy4.1 is a beast with a ton of attention to detail. Super impressed.
I can always update the SW side later. MIDI2.0 will def. be backwards compatible. Knobs are knobs, and I can future proof my analog interfaces with higher bit ADCs.
What kind of MIDI 1.0 support are you worried about? My understanding is that MIDI 2.0 is backwards compatible.
I mean that I hope that Teensy 4.x USB MIDI (when Teensy libs are upgraded to MIDI2.0) will continue to work with MIDI 1.0 drivers and devices, so we can continue using old devices and "old" OS (I don't know what plans does Microsoft have for MIDI 2, but chances are that they won't release new drivers for Windows 10 just because they want to push W11).
MIDI Capability Inquiry (MIDI-CI) exists exactly for that purpose. A MIDI 2.0 implementation does not just assume MIDI 2.0 support in the devices it talks to: it sends a capability inquiry to find out exactly what features are supported. A MIDI 1.0 implementation will not respond to this query, so the fallback is to use MIDI 1.0.
midi.org
Details about MIDI 2.0, MIDI-CI, Profiles and Property Exchange (Updated June, 2023)
This article is for companies looking to develop MIDI 2.0 products, both software developers and hardware manufacturers. If you are a MIDI user looking for the benefits of MIDI 2.0, [...]
midi.org
Any proper implementation of MIDI2.0 has to be able to fall back to MIDI1.0, otherwise it's not in spec. It'd be a nightmare otherwise. I don't think you can even patch a piece of gear that totally relies on DIN MIDI connectors to handle MIDI2.0 data, not at real-time levels of latency anyway. The MIDI1.0 spec for DIN connectors required optoisolators, like the 6N138, and set the bandwidth at 31.25Kbs, meaning the HW is already kneecapped to not support RT data rates for MIDI2.0's 32 bit UMP packets. IOW, dropping MIDI1.0 support is not an option.
Theres already drivers available that implement this. I would expect those to be capitalized on in whatever is implemented by PJRC. Since other MCUs like the RP2040 have already been shown using these drivers and running MIDI2.0 (with MIDI1.0 fallback), I imagine it won't be a hurdle for the better spec'd Teensy4.1 to handle this expertly.
Theres already drivers available that implement this. I would expect those to be capitalized on in whatever is implemented by PJRC. Since other MCUs like the RP2040 have already been shown using these drivers and running MIDI2.0 (with MIDI1.0 fallback), I imagine it won't be a hurdle for the better spec'd Teensy4.1 to handle this expertly.