There’s a larger blog post with the features and benefits of Windows MIDI Services coming later this month (February 2026). This is just a quick post here to assist users with known issues or workarounds, in the interest of remaining transparent on this project.

We performed a ton of testing with customers, partners, and our own equipment over the development cycle for Windows MIDI Services, but some bugs have made it through, as is known to happen with software development. We’re working on them in priority order, but I wanted to ensure the most impactful ones have more detail here.

Full issue list and updates for bugs may be found on our GitHub Repo

Info: How do I know if the new Windows MIDI Services Stack is enabled?

Windows MIDI Services is part of a Phased Rollout. This means that after you install the KB which contains the Windows MIDI Services binaries, you will get the new feature enabled at some point in the next month. Who gets enabled depends on the algorithms that control the rollout phases.

To see if your PC has the feature enabled, go to https://aka.ms/midi and download the checker tool there. It will be up until the next SDK release, where it will be included as part of the SDK and Tools package. Run this checker from a Windows Terminal / command prompt and pay attention to the output. It will tell you if the new stack has been enabled on your PC as part of the phased rollout.

There is no way for customers to force enablement of the Windows MIDI Services stack. Everyone who has installed the KB update will be enabled by the end of February as part of the phased rollout.

Bug: Dynamic ports (loopMIDI, loopBE, Bome, virtualTE) are not always visible.

Problem: Third-party drivers which dynamically create MIDI ports in Windows do not work as before. Unless the ports were created before the service was started, they are not visible.

Github Issue 835

Workaround 1: Restart the service

Close all apps using MIDI. Create the ports in the tool and then restart the MIDI Service through either the Services app or the command line. The service shows up as “Windows MIDI Service” and is named midisrv.

Administrator command prompt method: 1. Create your MIDI ports in the third-party tool. 2. Close all MIDI apps 3. Open Windows Terminal as an Administrator (“run as administrator”) 4. Type net stop midisrv 5. After that completes, type net start midisrv

Workaround 2: Use the built-in loopbacks instead

Only if you see that Windows MIDI Services is enabled, you can download the SDK Runtime and Tools package (it is currently unsigned and so you will receive several warnings) and then install it. This will install the MIDI and Musician Settings app. In that app, the first-run experience will prompt you to complete setting up MIDI. Part of that includes creating some default loopback endpoints. You can create as many other loopback endpoints as you need after the initial setup has created a configuration file for you.

Please pay attention to how these bidirectional loopbacks work, using the information provided in the MIDI Settings app Loopbacks page when you create a loopback endpoint. Loopback A sends to Loopback B. Loopback B sends to Loopback A.

Of course, this will only work for you if what you need are loopback endpoints.

Bug: Apps using the WinMM MIDI 1.0 API may not see newly plugged-in devices.

If you connect or power on a USB MIDI device after you’ve already started an app using the older WinMM MIDI 1.0 API, the device may not be visible.

GitHub Issue 783

Workaround:

Plug in the device and ensure it has fully booted up before starting the app.

Bug: Apps using the WinMM MIDI 1.0 API may crash if you disconnect or power down a plugged-in device

If you disconnect or power down a USB MIDI device while an app is using it, that application may crash, depending upon how it has opened the device.

GitHub Issue 831

Workaround:

Wait until the app has exited before unplugging or powering down a device. This also applies to dynamically-created devices that are not physical USB devices.

Bug: VirtualDJ Not able to communicate with controller

This is new and something we’re actively debugging. No additional information or workarounds available just yet.

GitHub Issue 843

Other Important Notes

Do not use the Korg Driver Uninstaller or any other tool which works to change the ordering of midi…midi9 entries in the registry. Windows MIDI Services requires only that midi is set to wdmaud.drv and midi1 is set to wdmaud2.drv. If those two entries are not present, Windows MIDI Services will not work on your system. The SDK runtime and tools includes a tool midifixreg which will ensure these two settings exist, in case you’ve already run one of these tools on your system.

How to File Bugs or Report Issues

Please do not comment on this post with issues/bugs/questions.

Questions/Discussion, and for customers without access to GitHub, issue reporting: https://aka.ms/mididiscord

Developers and anyone else with access to GitHub can file issues here: https://aka.ms/midirepoissues

The post Windows MIDI Services rollout – known issues and workarounds appeared first on Windows MIDI and Music dev.

The updates just keep coming. This release was focused on 2 features:

1. On device translation powered by Copilot+ PCs
   • Available in the Grab Frame via bottom bar button and options under the File menu
   • Also in the Edit Text Window under the Local AI menu
2. Configuring the Fullscreen Grab post grab actions
   • Add/remove options as well as editing the default behavior

This release I also refactored the language service to be more memory efficient. As always working to catch and fix bugs. If you have any feedback or suggestions I’m always listening feel free to open an issue or email joe at joefinapps dot com. https://github.com/TheJoeFin/Text-Grab

Joe

We’re thrilled to announce that the Pulumi Cloud REST API is now described by an OpenAPI 3.0 specification, and we’re just getting started.

This is a feature that has been a long time coming. We have heard your requests for OpenAPI support loud and clear, and we’re excited to share that not only do we have a published specification for consumption, but our API code is now built from this specification as well. Moving forward, this single source of truth unlocks better tooling, tighter integration, and a more predictable API experience for everyone.

You can fetch the spec directly from the API at runtime or use it for client generation, validation, and documentation, all from one machine-readable contract.

A single contract for the Pulumi Cloud REST API

The Pulumi Cloud API powers the Pulumi CLI, the Pulumi Console, and third-party integrations. Until now, there was no single, published machine-readable description of that API. We’ve changed that. The API is now defined and served as a standard OpenAPI 3.0.3 document.

• Runtime discovery: You can retrieve the spec from the API itself, so your tooling always sees the same surface the service implements.
• Client generation: Use your favorite OpenAPI tooling (e.g. OpenAPI Generator, Swagger Codegen) to generate API clients in the language of your choice.
• Validation and testing: Validate requests and responses, or build mocks and tests, from the same spec the service uses.
• Documentation: The spec is the source of truth, not a separate, hand-maintained API doc that can drift from reality. Load the spec into Swagger UI, Redoc, or another viewer to browse the Pulumi Cloud API interactively.

How to get the spec

Send a GET request to:

https://api.pulumi.com/api/openapi/pulumi-spec.json

No authentication is required. The response is the OpenAPI 3.0 document for the Pulumi Cloud API, describing the supported, documented API surface.

Source of truth and stability

We do not hand-write the OpenAPI spec. We generate it from the same API definition that drives our backend and console code. When we add or change API routes or models, we regenerate the spec so the published document stays in sync with what the service actually implements. That gives you a clear, stable contract for the Pulumi Cloud API.

What we are building next

We are using this spec as the foundation for our own tooling, and have plans to continue leveraging the spec in our toolchain long-term.

• CLI: We plan to drive the Pulumi CLI’s API client from the OpenAPI spec so that CLI and API stay in lockstep.
• Pulumi Service Provider: We are also building towards day 1 updates to the Pulumi Service Provider so that new and changed API resources are generated from the spec and ship in sync with the service.
• Docs Enhancements: Although you can load the spec using Swagger UI for your own browsing, we are intent on shipping enhancements to our public REST API docs that will keep them up-to-date according to the OpenAPI spec.

As we ship those updates, you will get a single source of truth from API to CLI to provider.

If you have questions or feedback about the OpenAPI spec or the Pulumi Cloud API, reach out in our Community Slack or open an issue in the Pulumi repository. We’re excited to see what you build with it.

When I started working with Kafka, I installed it locally on Docker and used a combination of the Confluent Command Line Interface (CLI) and C# programs I wrote.

One of the CLI tools from Confluent let me produce and consume messages on a Kafka topic by specifying the topic name and broker address. It was an easy way try things out.

But when I used this more recently, I couldn’t get it to work. I had updated the Docker image and the CLI. There seem to be new authentication requirements when using the CLI, authentication requirements that are not needed when using a C# consumer. I also could not find a tutorial on Confluent about local Kafka usage.

I messed around with it for a while, but eventually decided to write my own simple CLI consumer in C# using the new dotnet run app.cs approach.

Here is the code -

 1#!/usr/bin/dotnet run
 2#:package Confluent.Kafka@2.5.0
 3using Confluent.Kafka;
 4
 5if (args.Length < 2 || args.Length > 3 )
 6{
 7 Console.WriteLine("Usage: url topic [groupId]");
 8 return;
 9}
10
11string url = args[0];
12string topic = args[1];
13string groupId = args.Length == 3 ? args[2] : Guid.NewGuid().ToString();
14Console.WriteLine($"Using groupId: {groupId}");
15ConsumerConfig _consumerConfig = new ConsumerConfig
16{
17 BootstrapServers = url,
18 GroupId = groupId,
19 AutoOffsetReset = AutoOffsetReset.Latest,
20 EnableAutoCommit = true, // this is the default but good to know about
21 EnableAutoOffsetStore = true // this is the default but good to know about
22};
23
24using var consumer = new ConsumerBuilder<string, string>(_consumerConfig).Build();
25consumer.Subscribe(topic);
26
27Console.WriteLine($"Looking for messages on topic: {topic}");
28while (true)
29{
30 var consumeResult = consumer.Consume();
31 Console.WriteLine($"{consumeResult.Message.Value}");
32}

This can be executed like a script after it is made executable with chmod +x consumer.cs.

I’ll write a follow up with an example of a producer in a day or two.

Today I was impressed by so many thought-provoking articles and blogs. Maybe the most all year so far!

[article] Google parent beats on revenue, projects significant AI spending increase. Wowza, Cloud had a remarkable quarter (and year). We’re doing a few things right over here.

[article] How should AI agents consume external data? It’s a good question and one I haven’t seen discussed much. Locked down data sources? APIs? Secured caches? Make sure you have some gateways in front.

[article] Leaders, gainers and unexpected winners in the Enterprise AI arms race. It’s early, of course, but there are signals about who the real players are. Interesting to see third party apps GROWING in the enterprise.

[lab] Build and Deploy to Google Cloud with Antigravity. I clicked through this new step-by-step tutorial. It’s an excellent way to see how AI can help with more than just generating new code.

[article] Shared memory is the missing layer in AI orchestration. This has been on my mind a lot. What type of shared knowledge/memory should be stored, who should access it, and how is it fed into tools and apps?

[blog] Self-Improving Coding Agents. Speaking of memory, this excellent post from Addy highlights the value of the “right” memories passed between iterations of agentic loops.

[blog] Advancing AI benchmarking with Game Arena. Why not use games to really test the decision-making of AI models?

[article] My View of Software Engineering Has Changed For Good. It’s unavoidable at this point. Fairly soon, if not already, it’s not going to make much sense to sling all the code yourself.

[article] Most People Can’t Vibe Code. Here’s How We Fix That. Even with millions of new “builders” out there, there’s still a lot of assumed knowledge about software that many don’t have. Do we need different surfaces and platforms than what we have now?

[blog] AI Slopageddon and the OSS Maintainers. With all these new builders, however, we’re breaking open source workflows and maintainer morale.

[blog] Researching Topics in the Age of AI — Rock-Solid Webhooks Case Study. Should we share our AI-driven research reports publicly? Does that contribute to the “slop” problem? Or when guided well, do these reports represent useful knowledge worth disseminating? I lean towards the latter.

[article] How Do Workers Develop Good Judgment in the AI Era? Great question. How do you get good judgement without experience? We have to redesign how we develop that judgement.

[blog] MCP Development with COBOL, Cloud Run, and Gemini CLI. The fact that you can even do this is the takeaway. Not that you should start building MCP servers with COBOL.

Want to get this update sent to you every day? Subscribe to my RSS feed or subscribe via email below:

What’s new in Canary Build 28020.1546

Changes and Improvements gradually being rolled out with toggle on*

• This update includes a small set of general improvements and fixes that improve the overall experience for Insiders running this build on their PCs.
• We fixed an issue with apps when working with files on OneDrive or Dropbox.

Reminders for Windows Insiders in the Canary Channel

• These builds can be unstable and may be released with limited documentation. Join Windows Insider – Get early access to Windows 11 features & updates

• The builds we release to the Canary Channel represent the latest platform changes early in the development cycle and should not be seen as matched to any specific release of Windows. Features and experiences included in these builds may never get released as we try out different concepts and get feedback. Features may change over time, be removed, or replaced and never get released beyond Windows Insiders. Some of these features and experiences could show up in future Windows releases when they’re ready.

• Many features in the Canary Channel are rolled out using Control Feature Rollout technology, starting with a subset of Insiders and ramping up over time as we monitor feedback to see how they land before pushing them out to everyone in this channel.
• The desktop watermark shown at the lower right corner of the desktop is normal for Windows Insider pre-release builds.
• Some features may show up in the Dev and Beta Channels first before showing up in the Canary Channel.
• Some features in active development we preview with Windows Insiders may not be fully localized and localization will happen over time as features are finalized. As you see issues with localization in your language, please report those issues to us via Feedback Hub.
• To get off the Canary Channel, a clean install of Windows 11 will be required. As a reminder - Insiders can’t switch to a channel that is receiving builds with lower build numbers without doing a clean installation of Windows 11 due to technical setup requirements.

• Check out Flight Hub for a complete look at what build is in which Insider channel.