Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Show HN: Perfect Bluetooth MIDI for Windows

news.ycombinator.com

Post reply on HN
Print view View original

31–40 of 45 posts

Re: Show HN: Perfect Bluetooth MIDI for Windows

#31

Post by steve1977 »

bitwize wrote: post #17
moomin wrote: post #13

Earlier quoted context omitted.

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.

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.

Re: Show HN: Perfect Bluetooth MIDI for Windows

#32

Post by steve1977 »

maksut wrote: post #9
QuantumNomad_ wrote: post #4

> 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 R…

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 p…

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.

Re: Show HN: Perfect Bluetooth MIDI for Windows

#33

Post by steve1977 »

harrouet wrote: post #8
QuantumNomad_ wrote: post #4

> 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 R…

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.

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.

Re: Show HN: Perfect Bluetooth MIDI for Windows

#35

Post by jongalloway2 »

embedding-shape wrote: post #16
brudgers wrote: post #10

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.

Re: Show HN: Perfect Bluetooth MIDI for Windows

#36

Post by SyneRyder »

jongalloway2 wrote: post #35
embedding-shape wrote: post #16

Earlier quoted context omitted.

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.

Re: Show HN: Perfect Bluetooth MIDI for Windows

#37

Post by rafabulsing »

steve1977 wrote: post #32
maksut wrote: post #9

Earlier quoted context omitted.

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 p…

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.

Re: Show HN: Perfect Bluetooth MIDI for Windows

#39

Post by bitwize »

brudgers wrote: post #24
piltdownman wrote: post #21

Earlier quoted context omitted.

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 M…

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".

Re: Show HN: Perfect Bluetooth MIDI for Windows

#40

Post by brudgers »

bitwize wrote: post #39
brudgers wrote: post #24

Earlier quoted context omitted.

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".

No matter how solid the source of Midi clock, the receiver has to interpolate it’s own clock from multiple midi clock messages. Those messages arrive after passing through a network with arbitrary reliability, latency, and jitter.

The instability is at the protocol level. That is why Midi timecode exists.

Post reply on HN