Technical Updates for 2026? MIDI 2.0 support, support for ARM, move to .NET 10

Three technical questions about Cantabile plans for 2026:

  1. With Windows 11 getting the new MIDI/MIDI 2.0 support in the box in the coming months, will you be supporting the new stack directly in a forthcoming update? This is an important update given the growing number of MIDI 2.0 devices and controllers out there, as well as the significant technical improvements in the MIDI stack for all users in this.
  2. With .NET 8 being end of life later this year and .NET 10 the new LTS version (and claiming more performance improvements) will support for this be coming soon?
  3. With Windows on ARM making large strides and expected to be even more so in 2026, and the new MIDI 2.0 and Audio Stacks for Windows on ARM, are you looking at a specific build of Cantabile for Windows on ARM?
4 Likes

I would not rush with MIDI 2 support - there is a huge number of compatibility issues reported to Microsoft by users of older MIDI hardware and software.

Why would you NOT work towards adding support for the new MIDI stack even though there may still be some edge-case issues with its use (which I think you’ll find are much over-played now). The new stack is NOT going away and is already on every up-to-date Windows 11 25H2 install. The Microsoft team working on it are actively working to address any backwards compatibility issues that they can address inside Windows.

First of all, the majority of users have had no issues at all, and for those that did, most if not all of these have now been fixed over the last few months including the June preview release/July Patch Tuesday as well as by the software and or drivers being fixed by the original developers with the assistant of Microsoft.

The issues that have been shouted about (and amplified by social media) have almost all been for old (often unsupported) software and/or old drivers having issues as they behaved in ways the original stack was not designed for and/or made assumptions they shouldn’t have - breaking the backwards compatibility provided by the new stack which was based on a load of work and analysis across loads of hardware and software. In fact, quite a few of the issues have been because of the significantly better performance of the new stack!

Some very old unsupported software like MIDI loopback tools did some very odd things to work around the limits of 10 MIDI devices in the old stack, and Microsoft has fixed the stack for them EVEN though the new stack has these features built in.

The biggest issue out there that has not been fixed directly has been very old and now effectively unsupported DJ hardware and drivers, where the vendors are not offering ANY support on their side - so, for those people, Microsoft has also added in the ability to switch off the new stack completely and go back to the old one in the June/July updates!

It is also worth noting that using the new MIDI stack will actually avoid most of these issues - as well as opening up support for MIDI 2.0 devices.

To support Windows 10, Cantabile will need to retain the option for users to use the old stack. As the SDK runtime is being included in Windows 11 in the coming months, and the production-ready release (it has already been in beta around 18 months if not more) of the SDK is expected in the next month or so, so this is something that can be worked on ready for its release, as others have been doing for months if not years.

From a personal perspective, I have a complex setup with loads of software including many DAWs and Performance Hosts, a lot of hardware (controllers and synths) and have never had any blocking issues (one small one with WinRT in February with workarounds available), and zero issues at all since March/April — and I now have multi-client MIDI 1.0 devices without third party solutions (removed these now so reduced complexity, always a good thing), significantly improved (around 10ms better) MIDI 1.0 latency on class-compliant devices (which was more than I expected) as well as MIDI 2.0 support (at driver level) for my SL88 Mk2, and MIDI 1.0 and MIDI 2.0 loopback devices “in the box” if I need it.

I need to do a deep dive on this to figure out what’s involved. Short answer: yes, but not sure when.

Yes, but no time frame. Benefits to Cantabile are probably minimal since it’s only Cantabile’s UI that runs on .NET - not the audio engine.

I could do an arm build of Cantabile but with one big caveat - it would only support ARM plugins since .NET doesn’t support mixing arm/x64 code in the one process. Unless you’re willing and able to go completely ARM this doesn’t have much value. I’m not sure at which point this becomes feasible, let alone reasonable.

Or, I need to build bridge to host plugins in a separate process, but then you take another performance hit (bridge → emulation → x64 plugin)

FYI: Cantabile UI thread .NET activity affects audio thread efficiency when plugins access .NET in their audio threads. I’ve traced audio glitches to .NET resource contention when this happens (diagnosed using a kernel profiler). So if .NET 10 is more efficient, this might actually have unanticipated benefits.

1 Like

I’m not really sure how that happens, but ok.

I’m not really sure either, but it surprised me when I discovered it so I thought it might be useful info to pass along to you. It seems to have something to do with .NET containerization. A plugin’s audio thread requests creation of a .NET object that requires global synchronization while some other thread (e.g., Cantabile’s UI) happens to hold the same global .NET lock, and suddenly the plugin audio thread blocks. The locks aren’t explicitly requested by the apps; they’re down deep within the chain of parent objects that .NET initializes internally during container creation.

As Cantabile has shifted more to .NET for bindings processing and UI, I’ve found it more important to avoid plugins that use .NET from their audio threads (which it seems like they shouldn’t be doing anyway, but some do).

Update from today: just up on the Discord channel:

Here are the bits that are a candidate to go in-box for the SDK. This is what was discussed earlier. The release has all the details, but if something is unclear, bugging, or really anything else needing discussion about this…

This is NOT A CUSTOMER release. This is for DEVELOPERS ONLY. There is no customer support for this outside of Developer workloads.

Release In-box SDK/API Developer Preview 1 · microsoft/MIDI · GitHub

Some useful links:

1 Like

Personally I am still confused about Windows MIDI Stack updates. I’ve been allowing all Windows updates, but Last time I uninstalled the interim fix and came out of developer mode, everything stopped working, so I put the fix back on and am still in developer mode. With the next gig a month away, I am probably going to now go into “cautious mode”!

1 Like

@Derek can I ask a few questions to see if I can help:

  • What issues were you/are you facing that needed the “fixed drivers” to be manually installed?
  • Are you on Windows 11 25H2 build 26200.8875 (this month’s patch Tuesday)?
  • Did you download the preview update (26200.8737) on 24/06?

The reason I ask these last two is that this build has all the major bugs dealt with – BUT all these changes get switched on over time (up to 30 days) through Controlled Feature Release – which, for these is a pain, but it happens to anything like this on Windows.

  • Was the Developer’s Mode for the manual driver fix and/or for the MIDI 1.0 Loopback service?

If it was for the MIDI 1.0 Loopback, then Developer’s Mode is still required for that – this requirement will go when the SDK Runtime is included in Windows (Autumn time) at which point the Developer’s Mode can be switched off. Developer’s Mode does not do much except changing some security around installing lower-level things and can be switched off and back on at any time.

Have you joined the Windows MIDI and Audio Discord channel, as there is loads of information there (and, unlike some of the web pages, it is completely up-to-date)? As a reminder, you can join here. There are channels where you can ask your specific question of the developers, who will typically respond very quickly and may help you resolve this quickly.

A summary from the various releases (all subject to the 30-day CFR process) extracted from the Discord channel – I have done this in code format (manually wrapped) as, otherwise it would have taken way too many pages:

February Fixes - started week of February 23
* Incorrect midiInGetNumDevs and midiOutGetNumDevs when a single device is 
  plugged in after the app starts (this is the bug that made it so you had 
  to plug in and power on a MIDI device before opening the app)
* Crashes with removing devices when open
* Too-long message send timeout (service lockup)
* Issue with a spinlock with MIDI2 devices

March Fixes - started week of March 23
* Built-in retry logic for apps not allocating SysEx buffers in time
  (this is the bug discovered by VirtualDJ)
* Fix for crashes caused when opening non-MIDI pins on certain audio devices
* Fix for in-service translation not taking into account the group index in some 
  cases, which in some MIDI 2 devices could cause messages to cross.

April Fixes - KB5083631 on April 30
* Updated KSA transport with fixes for dynamic ports like loopMIDI, rtpMIDI, 
  LoopBE, NI Service etc. as well as the inMusic driver bug workaround
  (hang on close, and the zero-padded message data) in the KSA transport 
  and BS2UMP transform. Also supports > 16 dynamic ports from any one 
  direction and device (primarily impacts loopMIDI and LoopBE30)
* Duplicate devices do not have disambiguated MIDI 1 port names like "2 - Device"
* Remove vid/pid from endpoint personalization matching to prevent confusion 
  when multiple copies of the same device are attached.
* Change container ids for diagnostics and virtual endpoint parent devices.
* New Device Manager entry for UMP Endpoints to help avoid folks thinking they 
  are a duplicate entry
* Fix for WinRT MIDI 1.0 timestamps not being correctly calculated based on the 
  port open start time.
* Fix for apps using an incorrectly sized MIDIHDR structure

May Fixes - KB5089573 on May 26
* WinRT MIDI 1.0 not triggering service start (djay pro, and possibly Cubase
  if using WinRT MIDI 1.0)
* Multiple messages received at same time do not end up with the same timestamp
  in WinRT MIDI 1.0 APIs.
* WebMIDI missing Manufacturer and Product information.
* Bytestream to UMP Conversion fix (no mishandling of running status)
* WinMM timestamp fix

June Fixes - KB5095093 on 24 June
* Ability to turn of the new stack and revert to the older MIDI stack if, 
  for example, you have a device which will not work under Windows
  MIDI Services (like those with DirectMusic drivers), and do not need
  the multi-client and other capabilities.There will be three modes:
  [1] Legacy stack only; [2] hybrid - MIDI 2.0 devices through new stack
  and new API only, everything else through legacy; and [3] fully enabled.
* Update to force `midi = wdmaud.drv` and `midi1 = wdmaud2.drv` in the 
  registry upon reboot (or any time Audio Endpoint Builder has been restarted). 
  This is to help eliminate the Korg driver uninstaller issue.
* USB MIDI 2 fill stream crash
* Improved USB MIDI 2 driver handling of peripherals with malformed descriptors
* Couple of low-frequency service crash fices
* WinMM performance improvements for retrieving device count. Fixes most
  hanging UI problems with apps doing a tight loop getnumdevs call on the UI
  thread, as well as fixes problems where apps don't call getnumdevs before
  trying to open a port.
1 Like

Hi.

My problem is that every time I try removing the preview KSA, I lose the MIDI ports for all of my devices visible in the MIDI Devices and EndPoints view - and my applications cannot see any of the ports either. I only get the Default Loop Back Ports. But I have just read something on Discourse that simply uninstall the KSA does not properly remove it. So I will try their suggestion for a full removal

At the time of writing this, I am on 25H2 26200.8875

I cannot see 26200.8737 in my update history, but I am now being advised that 26200.8894 is available, so I might try that next.

Windows MIDI is on 1.017-rc.4.25

What I do know is I have a very glitchy system tonight, which has been losing my Kronos MIDI, I have ended up with duplicate devices in Device Manager…

So first step is install that update, then try and clean up the KSA

OK, it looks like my naivety in thinking that uninstalling the KSA from Add or Remove Programs would actually fully remove it…

You also have to do the following from an administrator CMD console

regsvr32 %windir%\System32\Midi2.KSAggregateTransport.dll
regsvr32 %windir%\System32\Midi2.BS2UMPTransform.dll
net stop midisrv
net start midisrv

RTFM…

I have now fully removed the KSA and backed out of developer mode on my DAWPC, GIGPC and Video PC, and it all seems to be working fine now (including RTPMIDI). It’s late here now, so will check again after a full cold start tomorrow, but finger’s crossed…

1 Like

Other than having to remap a port for my FC300 DIN MIDI connection on a MIOXL port via RTP MIDI, everything seems to be working fine today.

1 Like

Good news.