réactions à la news Les spécifications du MIDI 2.0 sont à présent publiques

Exploring MIDI 2.0: A Conversation with Microsoft's Pete Brown

00:00 Introduction
00:19 Intro to Pete
02:09 What is MIDI?
07:22 Why do we need MIDI 2.0?
09:18 MIDI MPE
10:26 Bi-directional communication
12:10 MIDI CI
13:33 MIDI CI over 1.0 / CI over 2.0 UMP
14:04 Why is Microsoft implementing MIDI 2.0?
18:23 Network MIDI 2.0
19:20 Is this the end of OEM MIDI drivers?
22:40 App to app MIDI communication
25:32 What do developers need to do?
28:21 Bringing old devices into MIDI 2.0
31:17 MIDI 2.0 tools in Windows
32:05 Live demo of the new MIDI 2.0 tools in Windows 11
42:31 Bluetooth MIDI
43:45 Windows as MIDI router
45:17 Open Source Project
47:19 How will it ship?
50:58 Links for developers
52:02 Pete's Windows Audio workstation guides
53:10 What's your favorite synth?

MIDI2.dev aims to promote the adoption of MIDI 2.0 by providing tools and libraries useful to developers.

Resources include C++ Libraries, USB helpers, testing applications, and more from leading contributors to the MIDI 2.0 specifications. Our repositories are at https://github.com/midi2-dev

Windows MIDI Services Info

Main Links:

Docs: https://aka.ms/midi
Repo: https://aka.ms/midirepo
Discord: https://aka.ms/mididiscord

Windows MIDI Services is a complete rewrite of the MIDI stack in Windows. It has been designed from the ground up to support both MIDI 2.0 and MIDI 1.0. It's open source so anyone can see the code, contribute, etc. but we ingest it into Windows internally to ship in-box later this year.

Selected features folks will probably want to know about

• Everything is multi-client by default, so more than one app can connect to the same device at the same time.
• Full MIDI 1.0 and MIDI 2.0 support
• New USB MIDI Class driver which will run, in the case of MIDI 2.0, as fast as the USB port supports.
• New cross-process data transfer that is much faster than what we had for MIDI 1.0.
• User metadata for endpoints, including name, description, images, and more, available to every application.
• JSON configuration files holding all the metadata can be easily ported/copied to other machines.
• Incoming and outgoing timestamps, and outbound message scheduling.
• New Windows service that handles MIDI 1.0/MIDI 2.0 data format translation, MIDI mapper-type plugins, and more
• Support for existing kernel streaming drivers, but we hope to make them completely or mostly unnecessary going forward.
• Built-in loopback MIDI to enable apps to easily communicate with each other. These can be created through the MIDI Settings app, or in the case of temporary ones, through the API
• Built-in app-to-app MIDI. Similar to loopback, but the endpoints are tied to the lifetime of the application that is offering itself up as a MIDI device.
• MIDI Console tool for power users, developers, and those who want to test and or script things through the command line.
• MIDI Settings app for configuration
• Will be available in-box later this year for Windows 11, and shortly after (depends on servicing intervals) for latest supported Windows 10.

A few other things we're working on related to this:

• Network MIDI 2.0 (this will ship after our initial release)
• BLE MIDI 1.0 reimplementation from scratch, fully open source.
• Plumbing the old WinMM and WinRT MIDI 1.0 APIs through to the new service so existing apps can get some of the benefits, including multi-client.
• Considering implementing RTP MIDI 1.0

This specification will define the mechanisms and the message format for exchanging Universal MIDI Packet messages via a local area network. This enables the transport of MIDI 1.0 Protocol and MIDI 2.0 Protocol. This also defines discovery of available Network MIDI devices and Hosts, and management of Network MIDI Sessions.

The new USB MIDI 2.0 driver will go nearly as fast as the underlying USB port has been negotiated to go and uses an approach similar to WaveRT audio for transferring data.

On the second part, Network MIDI 2.0 was just approved and published as a spec, and I think will ultimately turn out to be more important than the USB transport. I'll have a preview of the Windows implementation at NAMM.

Network MIDI 2.0 to DIN MIDI 1.0 translation boxes will be a thing.

On the first part, we had a lot more work to do than Apple did on this. We rewrote the entire MIDI stack from the ground up, and have also built a very complete solution for MIDI 2.0 while also supporting MIDI 1.0.

Yes, we're behind time-wise, but this month we did start putting the features into Insider builds for partner developer testing.

If not for the backwards compatibility we need to finish (for apps using the old WinMM APIs), we'd be done with 1.0. But we're still finishing up the backwards compatibility work, which has taken quite some time to write. The new API wouldn't be of much use if all the apps using the old one weren't able to be plumbed into the same infrastructure, and able to be multi-client.

At the NAMM Show in January, we’ll have a preview demonstration of the upcoming Network MIDI 2.0 transport standard using Windows MIDI Services. Network MIDI 2.0 is really promising because it enables a different type of connectivity, unencumbered by USB cable length limitations. The Network MIDI 2.0 standard is nearing final review and approval. There are already a number of devices in development which support the upcoming standard, and you’ll be able to use them with Windows.

Supports your Existing Devices. Windows MIDI Services supports the MIDI 1.0 devices you own today, including those with vendor-supplied kernel streaming drivers, as well as class-compliant MIDI 1.0 and MIDI 2.0 devices. The experience will be better/faster if they use the new class driver, but we recognize that is not always possible or desirable with some existing devices.

Supports your Existing Apps. When Windows MIDI Services ships in-box in Windows, the existing WinMM and WinRT MIDI 1.0 APIs will be repointed to the new Windows Service. This will provide a subset of the new features, including multi-client. Those apps will not have access to the user metadata, auto-reconnect, device connect/disconnect detection, rich device details, MIDI 2.0 messages, etc. but will continue to work as today, with the benefit of multi-client (more than one app using the same port) support.

At Music China, our Chinese members created a series of videos highlighting how important MIDI is to the music industry in China.

This is the first of 8 and is the trailer that provides an overview of the series

Some continued work on Network MIDI 2.0

I've enabled creating WinMM-compatible ports from the network endpoint. So Network MIDI 2.0, via the new service, is translated to MIDI 1.0 and surfaced to applications which do not use the new API, like REAPER. It's also multi-client, like everything else.

Of course, apps using the new API/SDK will have more capabilities, including message scheduling, better device names, etc. but we wanted to provide at least basic IO to other apps.

Easier to view on YouTube on a larger screen.

In this example:

• Connected to the BomeBox using Network MIDI 2.0, across the network
• BomeBox is set to loop back the messages sent to it
• REAPER is listening on that WinMM Port using the older MIDI 1.0 API (no changes have been made to REAPER code to support this)
• Windows MIDI Services Console also monitors the Network MIDI Endpoint, using the MIDI 2.0 API.
• The play-notes command on the Windows MIDI Services console sends the specified notes to the selected endpoint.

Pete

When will we go into retail (mainstream) Windows releases?

Once we are happy with the compatibility with existing apps and devices, we’ll move Windows MIDI Services into the latest supported releases of Windows 11 as well as the supported Windows 10 release. We hope this will be soon, but this is a quality-driven decision and we need your feedback. We’ve tested dozens of apps and MIDI devices here, and involved partners testing with their newest offerings, but there are thousands of MIDI devices released in the wild over the past 40+ years and we don’t have every one of them. We don’t want to break your MIDI workflow.

A savoir obtenir plus d'efficience en changeant de technologie de processeur.