In the next major step in our AI Infrastructure evolution, last week we introduced Maia 200, a breakthrough inference accelerator engineered to dramatically improve the economics of AI token generation.

Microsoft engineering leaders will be showcasing our latest silicon innovation in San Francisco this month. Here are a few ways you can learn more and engage with this exciting technology and the team behind it:

Maia 200 ISSCC Whitepaper

Microsoft has submitted a technical whitepaper around Maia 200 as part of the International Solid-State Circuits Conference (ISSCC). The paper will be released on Friday, February 13^th to ISSCC attendees and be available after the conference digitally on IEEE.

The paper is titled “Maia: A Reticle-Scale AI Accelerator” by Sherry Xu, Partner, Silicon Architecture at Microsoft.

ISSCC Session

Leadership from Azure Hardware and Systems will present a 25-minute session on Maia development titled "MAIA: A Reticle-Scale AI Accelerator" at the ISSCC conference at 2:45 PM (Session 17.4) as part of the wider ISSCC Session 17 "Highlighted Chip Releases for AI" that begins at 1:30 PM inside the Marriott Marquis in downtown San Francisco.

During the session, we will highlight our design approach for Maia 200 and walk through the architecture and implementation of Microsoft’s Maia AI silicon. We’ll also share how the team engineered a reticle‑limited, ~750W AI SoC and the innovations that enabled a scalable, high‑performance accelerator.

Join us at the Microsoft Silicon Social Event

Microsoft will also be hosting a Silicon Social in downtown San Francisco on the evening of the 17^th. Maia 200 will be on-site marking its first public appearance outside of Microsoft labs and Azure datacenters, along with a selection of other Microsoft silicon hardware. Microsoft’s silicon engineering leadership will be attending, and we will provide food and drink during the event.

All ISSCC attendees and others in the Bay Area silicon community are invited to register interest in attending by February 13^th. Due to limited capacity, confirmed attendees will receive a follow‑up email with event details, including the venue.

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.