Why on earth is the "Windows MIDI Services is Here" thing a slider/carousel with one element in it? Why are the buttons completely misplaced with no margin between them? Has a human seen and tried this before they just deployed everything and went live?
Why so mean? You can look at all of the commits and see that the same dev who has been writing these drivers and apps pretty much single handedly has been making commits on the site for the past few years. https://github.com/microsoft/MIDI/commits/main/docs
You can even PR fixes if you want to show off your web dev skills.
Pete is one of those rare Microsoft developers who is actively interacting with customers publicly. He's active on the Gearspace forums where musicians hang out, helping people with their Windows issues relating to operating system level audio issues. Here's his Gearspace thread announcing the new Windows 11 MIDI drivers:
I wish there were more people like Pete working at Microsoft. He's someone who is genuinely trying to improve the OS and make it a great experience for users.
EDIT: Re-read the original post and I see Pete even checked this project out and commented on Reddit. Sorry I missed that the first time.
Specifically for Windows, the Intel 2001 Guidelines and Microsoft WHQL (Windows Hardware Quality Labs) which prohibit the use of MPU401-style interfaces, as well as direct driver access to either the serial or parallel ports.
Doing Direct-To-Bus MIDI handling can't be replicated in modern architecture like the ST was configured.
That said, given the popularity in analog semi-modulars to be used as DAW outboard with MIDI over USB implementations that add latency and jitter, is it even a consideration for most users?
Ableton and other performance oriented DAWs automatically compensate for MIDI and audio latency caused by plugins and devices; in Ableton's case it will delay the audio by the overall system latency, and/or bypasses plugin delay compensation only for armed/monitored tracks, making them more responsive.
The real answer to the question is, as always, to use hardware sequencers and control voltage triggered off your master clock or DAW. SQ-64 is as rock solid as an Atari ST for CV work, although the 64ppqn limit doesn't match the Atari ST' 384pqqn capabilities. That said, standard MIDI Beat Clock is much lower at 24 PPQN. If you want to go all Autechre/Aphex Twin there's plenty of ways to skin that cat.
If you care about timing over Midi, use MTC not Midi Clock. Because receivers have to derive clock frequency by counting pulses, Midi clock is inherently unstable.
MIDI clock on the Atari ST was rock solid. It being "inherently unstable" is one of those accidental things, like Windows 9x users assuming "computers just crash all the time".
Fun, I do the opposite, explicitly use Midi Clock so everything is purposefully a tiny bit out of sync, seems to sound better to me, "Midi clock is inherently unstable" is the feature I like :)
There are technologies like MTS (MIDI timestamping), where you basically send timestamped data early to the interface so that it can then play them out exactly (or more exactly) at the right time. This was initially made by MOTU but I think the implementation in Core MIDI is based on it.
Emagic and Steinberg also implementation of this (AMT in case of Emagic, LTB for Steinberg IIRC.
This only really works with recorded data of course. It's also very old already (like 25 years old), I'm not sure how well it is still supported in current DAWs.
With these technologies, timing should be as good or better as on an Atari.
All of my synths are hooked up via USB or Focusrite interface (wired MIDI) because that makes sense for my setup, but this could be cool for more portable setups. The big question is what does your average latency look like?
> Windows only natively exposes BLE-MIDI through the WinRT API, which almost no DAW polls.
I haven’t used Windows for ages. Does this mean that almost every Windows user with any Bluetooth MIDI keyboard is unable to use it out of the box with their DAW without installing additional third-party software?
Does it apply even to latest version of the very widely used DAWs like Ableton, Pro Tools, FL Studio, Reason, and Reaper?
Surprisingly Windows audio stack is a mess. I have a mini keyboard with Bluetooth and it was an adventure to get it working in Windows. In Linux it was pretty much plug and play.
Low latency audio drviers are also messy in Windows when not using an audio interface with well written ASIO drivers. Pipewire in Linux is much easier to configure. Looks like MacOS also does not have this driver problem.
It is surprising. Because most audio plugins and DAWs support only Windows and MacOS.
If you are using Windows professionally for audio, you will be using ASIO. So in practice, this is not really a problem. Especially considering that ASIO drivers often even perform a bit better than their CoreAudio counterparts and don't have hidden doublebuffering.
macOS also seemed or seems to have quite a few problems with DriverKit USB drivers for large channel count interfaces.
In practice it is a problem, because not everyone who needs low latency audio is a professional.
Case in point: just the other week I was trying to get Rocksmith (a guitar game where you plug in an actual guitar with their custom USB cable) working on windows, and I could not do it. The latency was too high for it to be usable.
The community has many workarounds for it, but most involve getting an audio interface and connecting through that. But that really, really shouldn't be needed. I used to play this game on MacOS, and it worked perfectly. It's ridiculous that Windows fails at this.
Actually I thought the same for macOS for certain things, like window management was way better on Windows than on macOS (snapping etc.) Luckily after years macOS finally has something decent to organize windows. I know that there were 3rd party apps like rectangles but something simple like organizing windows missing from a desktop OS always felt weird.
On the other hand, at least since a couple of releases, I have lots of troubles with the highlight annotation in Preview, especially in PDFs with tables. So much so that I have to resort to 3rd party software for that (PDF Expert in my case).
But yeah, PDF support is basically native in macOS since Mac OS X.
This is a weird comment because I feel the same about getting macOS to a useable place.
I probably have 5 or 6 things installed on my Mac like Scroll Reverse and Rectangle, just trying to beat the window manager into something that resembles useable.
Wow. That looks really painful. I have multiple pianos, always used cable because I wanted it to work without problems in Linux and Mac. Also I can't stand delays.
I have created 20 utils or so with the help of Claude, in order to practice multiple things like reading sheet music, or rhythms, or different scales. I never expected it to be that useful as my new Yamaha was bought before Claude existed, and having a cable that just works is so great.
I have spent way less effort doing all my utils than this man into just connecting its machine.
Before using it with Claude I used them a lot with Synthesia and GarageBand, but with Claude is like having a personal trainer.
This is really interesting. Windows device handling can be tricky sometimes, especially when things work at one layer but fail silently at another. The channel detection approach is clever.
For what it is worth, Microsoft is in the process of rolling out Windows Midi Services for Windows 11.
https://microsoft.github.io/MIDI/
Why on earth is the "Windows MIDI Services is Here" thing a slider/carousel with one element in it? Why are the buttons completely misplaced with no margin between them? Has a human seen and tried this before they just deployed everything and went live?
Why so mean? You can look at all of the commits and see that the same dev who has been writing these drivers and apps pretty much single handedly has been making commits on the site for the past few years. https://github.com/microsoft/MIDI/commits/main/docs
You can even PR fixes if you want to show off your web dev skills.
+1 to this. Psychlist1972 / Pete is good people.
Pete is one of those rare Microsoft developers who is actively interacting with customers publicly. He's active on the Gearspace forums where musicians hang out, helping people with their Windows issues relating to operating system level audio issues. Here's his Gearspace thread announcing the new Windows 11 MIDI drivers:
https://gearspace.com/board/new-product-alert-2-older-thread...
I wish there were more people like Pete working at Microsoft. He's someone who is genuinely trying to improve the OS and make it a great experience for users.
EDIT: Re-read the original post and I see Pete even checked this project out and commented on Reddit. Sorry I missed that the first time.
Most choices are not between bread and cake.
Most choices are between bread and nothing.
Good engineering is the art of good enough.
Outrage is hardly warranted.
> Good engineering is the art of good enough.
Sure, agree. When will this website reach the state of "good enough"?
> Outrage is hardly warranted.
Agreed, but I also don't see any outrage in any of the comments for this submission, what outrage are you talking about?
It's good enough if it conveys the information to its intended audience.
If the comment isn't outrage, it's even less warranted.
Valid questions even if all of them are rhetorical.
Because slopsoft.
A few more years and we might be able to approach Atari ST levels of MIDI performance…
Never gonna happen. The architecture of modern hardware and operating systems won't allow for that kind of low latency and jitter.
Specifically for Windows, the Intel 2001 Guidelines and Microsoft WHQL (Windows Hardware Quality Labs) which prohibit the use of MPU401-style interfaces, as well as direct driver access to either the serial or parallel ports.
Doing Direct-To-Bus MIDI handling can't be replicated in modern architecture like the ST was configured.
That said, given the popularity in analog semi-modulars to be used as DAW outboard with MIDI over USB implementations that add latency and jitter, is it even a consideration for most users?
Ableton and other performance oriented DAWs automatically compensate for MIDI and audio latency caused by plugins and devices; in Ableton's case it will delay the audio by the overall system latency, and/or bypasses plugin delay compensation only for armed/monitored tracks, making them more responsive.
The real answer to the question is, as always, to use hardware sequencers and control voltage triggered off your master clock or DAW. SQ-64 is as rock solid as an Atari ST for CV work, although the 64ppqn limit doesn't match the Atari ST' 384pqqn capabilities. That said, standard MIDI Beat Clock is much lower at 24 PPQN. If you want to go all Autechre/Aphex Twin there's plenty of ways to skin that cat.
If you care about timing over Midi, use MTC not Midi Clock. Because receivers have to derive clock frequency by counting pulses, Midi clock is inherently unstable.
Midi Time Code is SMPTE.
MIDI clock on the Atari ST was rock solid. It being "inherently unstable" is one of those accidental things, like Windows 9x users assuming "computers just crash all the time".
Fun, I do the opposite, explicitly use Midi Clock so everything is purposefully a tiny bit out of sync, seems to sound better to me, "Midi clock is inherently unstable" is the feature I like :)
There are technologies like MTS (MIDI timestamping), where you basically send timestamped data early to the interface so that it can then play them out exactly (or more exactly) at the right time. This was initially made by MOTU but I think the implementation in Core MIDI is based on it.
Emagic and Steinberg also implementation of this (AMT in case of Emagic, LTB for Steinberg IIRC.
This only really works with recorded data of course. It's also very old already (like 25 years old), I'm not sure how well it is still supported in current DAWs.
With these technologies, timing should be as good or better as on an Atari.
Multi-client support? I must be dreaming!
Wow very cool project! I will test it out later today - i have always been using cabled connection for my midi keyboard
All of my synths are hooked up via USB or Focusrite interface (wired MIDI) because that makes sense for my setup, but this could be cool for more portable setups. The big question is what does your average latency look like?
> Windows only natively exposes BLE-MIDI through the WinRT API, which almost no DAW polls.
I haven’t used Windows for ages. Does this mean that almost every Windows user with any Bluetooth MIDI keyboard is unable to use it out of the box with their DAW without installing additional third-party software?
Does it apply even to latest version of the very widely used DAWs like Ableton, Pro Tools, FL Studio, Reason, and Reaper?
That wouldn't surprise me.
Surprisingly Windows audio stack is a mess. I have a mini keyboard with Bluetooth and it was an adventure to get it working in Windows. In Linux it was pretty much plug and play.
Low latency audio drviers are also messy in Windows when not using an audio interface with well written ASIO drivers. Pipewire in Linux is much easier to configure. Looks like MacOS also does not have this driver problem.
It is surprising. Because most audio plugins and DAWs support only Windows and MacOS.
If you are using Windows professionally for audio, you will be using ASIO. So in practice, this is not really a problem. Especially considering that ASIO drivers often even perform a bit better than their CoreAudio counterparts and don't have hidden doublebuffering.
macOS also seemed or seems to have quite a few problems with DriverKit USB drivers for large channel count interfaces.
In practice it is a problem, because not everyone who needs low latency audio is a professional.
Case in point: just the other week I was trying to get Rocksmith (a guitar game where you plug in an actual guitar with their custom USB cable) working on windows, and I could not do it. The latency was too high for it to be usable.
The community has many workarounds for it, but most involve getting an audio interface and connecting through that. But that really, really shouldn't be needed. I used to play this game on MacOS, and it worked perfectly. It's ridiculous that Windows fails at this.
If you use a Mac, you'd be amazed at how many things can't be done on Windows without 3rd-party software.
Do you know how to spot a Windows user ? They print-and-scan to merge their PDFs.
Actually I thought the same for macOS for certain things, like window management was way better on Windows than on macOS (snapping etc.) Luckily after years macOS finally has something decent to organize windows. I know that there were 3rd party apps like rectangles but something simple like organizing windows missing from a desktop OS always felt weird.
That is a nice function of Preview indeed.
On the other hand, at least since a couple of releases, I have lots of troubles with the highlight annotation in Preview, especially in PDFs with tables. So much so that I have to resort to 3rd party software for that (PDF Expert in my case).
But yeah, PDF support is basically native in macOS since Mac OS X.
This is a weird comment because I feel the same about getting macOS to a useable place.
I probably have 5 or 6 things installed on my Mac like Scroll Reverse and Rectangle, just trying to beat the window manager into something that resembles useable.
Wow. That looks really painful. I have multiple pianos, always used cable because I wanted it to work without problems in Linux and Mac. Also I can't stand delays.
I have created 20 utils or so with the help of Claude, in order to practice multiple things like reading sheet music, or rhythms, or different scales. I never expected it to be that useful as my new Yamaha was bought before Claude existed, and having a cable that just works is so great.
I have spent way less effort doing all my utils than this man into just connecting its machine.
Before using it with Claude I used them a lot with Synthesia and GarageBand, but with Claude is like having a personal trainer.
This is really interesting. Windows device handling can be tricky sometimes, especially when things work at one layer but fail silently at another. The channel detection approach is clever.
Did you try https://github.com/celtera/libremidi ? It should poll BLE devices
Very interesting writeup about a niche windows aspect I never even thought about. Thank you
I've been looking at building a "Linux MIDI gadget" to send signals from my Casio DG20 to my PC over BLE -- this is just what i need for the PC end
Impressive work! Alas I don’t use windows but if I did I would certainly check this out.
Tried with the Yamaha Seqtrak on Windows 10, didn't work.