Question: The future of MIDI

[LeonarddeR]

The Win2 MIDI has been stable for many years and years and is used in many Digital Area Workstations. Several major DAW's, like Cockos Reaper, never bothered to implement support for the new UWP MIDI APi that is the only API that provides access to BLE-MIDI devices.
I'd be curious to know what the plans with MIDI are in this project. Idially BLE-MIDI would be available through the old WIN32 API, but I assume that's a no go. Alternatively, it would help if there could be something like a drop in replacement that makes it possible for DAW authors to switch without too much afford, or give the end user the ability to use these new devices with older software.

[LeonarddeR]

CC @Psychlist1972, who recently blogged about BLE-MIDI related things.

[mdtauk]

Midi 2.0 support should be added to any new APIs

[Psychlist1972]

Hi All

I spoke about our MIDI work at the NAMM event in January just before the COVID lockdown.

The MIDI stack refresh and MIDI 2.0 are coming, but they are not part of the Reunion project. However, we share many of the same goals, including making the APIs available to all applications on Windows. It's a multi-phase project, with full MIDI 2.0 (which requires a new USB class driver) as part of the final phase. Before that, the stack refresh will offer a lot of what the community and DAW companies have been asking for, including multi-client, virtual MIDI, bluetooth, and more.

I'll have more to say about MIDI earlier next year. There's no current place for you to go to ask questions about it, but I will have an appropriate place at that time. Thanks for your interest!

Hope that helps.

Pete

[LeonarddeR]

Hello Pete,

Is there any news about this subject? Really looking forward to improvements in this area.

Regards,
Leonard

[Psychlist1972]

"Alternatively, it would help if there could be something like a drop in replacement that makes it possible for DAW authors to switch without too much afford, or give the end user the ability to use these new devices with older software."

The API is based on the WinRT MIDI API, not the WinMM/Win32 MIDI API. We simply can't extend that one without doing everything at the driver level, which is not the approach here. The main reasons DAW companies haven't adopted WinRT MIDI today are:

• Our naming for ports is not what everyone wants, and it's confusing.
• BLE MIDI is not a big enough carrot for companies to take on the API, and there are alternatives
• Incorporating it into a C++ Win32 app was challenging until C++/WinRT came around

There are three places where you'll see WinRT MIDI being used today. In all three, it's an optional switch. Cakewalk, Chromium, and JUCE.

I've personally heard the issues from community and developers, and are making sure we address those. But it will require companies to adopt the API. There will be more guidance there, and also the structure of the project will make it easier for folks to adopt earlier. More on that in the future.

Pete

[mdtauk]

@Psychlist1972 Is there any consideration going into supporting Soundfonts for MIDI playback - or is that all prohibitive due to patents?

[Psychlist1972]

@mdtauk I'm not investing in that as baked into the stack, but I am making it much easer for applications to plug into MIDI in a way where you could have a proper synthesizer (or a third-party soundfont player, or something else) that is available to everyone.

[LeonarddeR]

First of all, I"m sorry for my late reply. Thanks a lot for giving us more insight in what's coming.

The MIDI stack refresh and MIDI 2.0 are coming, but they are not part of the Reunion project. However, we share many of the same goals, including making the APIs available to all applications on Windows. It's a multi-phase project, with full MIDI 2.0 (which requires a new USB class driver) as part of the final phase. Before that, the stack refresh will offer a lot of what the community and DAW companies have been asking for, including multi-client, virtual MIDI, bluetooth, and more.

Is there any time frame when this can be expected? I assume it will be part of a particular Windows 10, but likely not before 21H1?

I'll have more to say about MIDI earlier next year. There's no current place for you to go to ask questions about it, but I will have an appropriate place at that time. Thanks for your interest!

Looking forward to that.

* BLE MIDI is not a big enough carrot for companies to take on the API, and there are alternatives

I've been searching for alternatives, but couldn't find something that works reliably for me. Could you please elaborate on what alternatives you'd advise in the meanwhile?

* Incorporating it into a C++ Win32 app was challenging until C++/WinRT came around

True. It is now actually pretty easy to incorporate it into C++ application, apart from handling connecting to Bluetooth devices that aren't in range. I created a Stack overflow question to get info on that, but no luck so far.

[Noemata]

The recently fixed UWP MIDI API still needs a UWP equivalent for multi media timers. Developing a UWP MIDI app requires IPC events to be sent from Win32 (where WinMM is available), back to a UWP process where WinMM isn't. No UWP MIDI App in the store is able to do this because of the security sandbox. So MIDI is not yet complete as far as the WinRT API is concerned. Lack of adoption of the UWP MIDI API was always more about quality than anything else. Microsoft has been great at recognizing the importance of gaming, hence gaming APIs tend to be very robust. Music production has not been given nearly the same level of consideration by Microsoft, even though apps in this problem domain have far reaching consequences for an OS and how it is perceived. Ipad MIDI apps are a major factor in what made the Ipad and Iphone such a success out of the gate. Apple gets the importance of Rich Media authoring tools. Microsoft has its head in the cloud.

[LeonarddeR]

@Psychlist1972 I hope you don't mind me asking for a status update about all this.

[leehu]

Hi. Any updates? thx

[Psychlist1972]

I know this has taken quite a while.

But we've been working on this for a bit now. We have MIDI 2.0 experts working on the new class driver. We're working on the API in concert with that. We have also been working with hardware and software partners for feedback and eventually for implementation.

There's a repo for the driver, API, and tools, but it has to stay closed until November due to implementing some as-yet non-ratified MIDI 2.0 changes. The only exceptions are for invited MIDI Association/AMEI corporate members.

I'll be presenting alongside Apple and Google at the Audio Developer Conference in November. We'll each spend a few minutes talking about our implementations. https://audio.dev/schedule/ . I expect to be able to open the repo at that time.

Pete

[leehu]

Great 0- thx for the update and will look forward to that!

[hawkerm]

New Midi repo is here: https://github.com/microsoft/MIDI

[hawkerm]

I did try the WinRT APIs in a Windows App SDK WinUI 3 app; however, they only seemed to correctly load/register the Midi Out device when I had my application unpackaged. If it was packaged, MidiOutPort.FromIdAsync returned null.

Seems folks calling the raw APIs in this thread saw similar behavior as well: https://learn.microsoft.com/en-us/answers/questions/762823/winui-3-and-ms-general-midi

Castorix31
Mar 27, 2022, 11:39 PM
I'm also on 64-bit,

but it works for me with Unpackaged app,

with in the .csproj :

Copy

<WindowsPackageType>None</WindowsPackageType>

I just tested with a packaged app and I don't have any sound too

[Psychlist1972]

Per our other discussion, I suspect this is because the general MIDI DLS (the in-box old Roland synth) normally needs to be packaged with the app if you are using the GS Synth from WinRT MIDI 1.0 APIs. I'm surprised this fails with unpackaged apps, though, because you don't need to package the DLS if you build a plain win32 desktop app, and you do need to include it for UWP apps.

I've been focused on the new MIDI APIs so haven't looked at this scenario with Win App SDK and WinRT MIDI 1.0.

[hawkerm]

It works for unpackaged without including anything just adding the msbuild packaging type property and changing the run selection in VS, but it doesn't work for packaged (default for new project). This time, I tried the DryWetMidi project with the same results.

Trying packaged again, I added the SDK reference to the GM dlls like, as if it was a UWP app (grabbed from that sample here), but that didn't help either:

<ItemGroup>
  <SDKReference Include="Microsoft.Midi.GmDls, Version=$(TargetPlatformMinVersion)">
	<Name>Microsoft General MIDI DLS for Universal Windows Apps</Name>
  </SDKReference>
</ItemGroup>

1>C:\Program Files\Microsoft Visual Studio\2022\Preview\MSBuild\Current\Bin\amd64\Microsoft.Common.CurrentVersion.targets(2659,5): warning MSB3774: Could not find SDK "Microsoft.Midi.GmDls, Version=10.0.19044.0".

(Also tried 17763 min version with no effect)

I also tried just copying the gm.dls file from the drivers folder into my AppX folder, but that didn't seem to help either.

I suppose, for now, I can tinker around unpackaged as I'm just trying to play any sort of sounds in time (nice benefit of the DryWetMidi library is it handles timing itself). Just if I go beyond that, seems like I'm going to get stuck somewhere.

[roxk]

I know it sound odd but you might be able to find some help from this thread on the terminal repo: microsoft/terminal#13520