Merge pull request #334 from microsoft/pete-dev

Update index.md

docs/index.md

@@ -28,14 +28,24 @@ While we're in developer preview, get started by downloading and installing the
 * **Multi-client by default**. Unless an endpoint is configured to not allow shared connections, or there is some issue around multi-client in a third-party driver, any endpoint (including MIDI 1.0 devices) can be used by multiple applications at the same time. So far, in our testing, we haven't found any USB devices or drivers which cannot be multi-client.
 * **Faster**. In our testing, we've found that the new infrastructure is much faster at sending and receiving messages compared to the older API, even with plugins configured in the service. There are no built-in speed caps or throttling in Windows MIDI Services, even for older USB MIDI 1.0 devices. The driver is not limited USB full-speed, and supports USB 3.x speeds.
 * **Lower Jitter**. Along with higher speed comes lower jitter. This will vary by transport type (USB vs Network vs Virtual), and the device Windows is talking to, but the jitter is in the low microsecond range even without any compensation.
-* **More Deterministic**. Speaking of latency compensation, the new API enables timestamp-based message scheduling for outbound messages, and also will soon support Jitter Reduction timestamps for MIDI 2.0 devices which can use them.
+* **More Deterministic**. Speaking of latency compensation, the new API enables timestamp-based message scheduling for outbound messages for any apps using the new API. In addition, incoming messages are tagged with a timestamp when received by the service.
+* **Extensive Endpoint Metadata** We've built upon `Windows.Devices.Enumeration` with our own MIDI-specific device class, which provides much more information about a device. Not only do we have user-provided metadata (name, description, images, settings), but also more device-provided information. This is also where you have access to MIDI 2.0 device features like Function Blocks, Group Terminal Blocks, Device Identity, and much more.
+* **Device Connect/Disconnect Notification** No restarting your apps to detect the presence of a new device. Whenever an endpoint is created, updated, or removed, the app receives an event with all the required details. Additionally, apps can opt-in to automatic reconnect to any device they are communicating with, should it become disconnected during a session.
 * **Extensible**. The service has been designed to be extensible by Microsoft and third-parties. New types of transports can be added at any time, including during prototyping of a new transport specification. (We're working on Network MIDI 2.0, Bluetooth MIDI 1.0 and considering RTP, all using this model.) Similarly, message processing plugins can also be developed by Microsoft or third-parties and used for production and/or prototyping. **No kernel driver experience required in most cases.**
-* **Includes app-to-App and Virtual MIDI**. Windows MIDI Services includes virtual / app-to-app MIDI 2.0 to enable lightning fast communication between apps on the PC. We're also investigating flexible routing between any MIDI endpoints as a future feature.
+* **Includes app-to-App and Virtual Device MIDI**. Windows MIDI Services includes virtual / app-to-app MIDI 2.0 to enable lightning fast communication between apps on the PC. We're also investigating flexible routing between any MIDI endpoints as a future feature.
 * **Better tools**. We supply the `midi.exe` Windows MIDI Services Console for developers and power users, or anyone comfortable with the command line. You can use it to monitor endpoints, send and receive messages, send/capture SysEx data and much more. We'll deliver the MIDI Settings GUI app after our initial release. That app enables renaming devices, configuring your MIDI setup, testing, and more.
-* **UMP-Centric**. The new API fully embraces MIDI 2.0 and the Universal MIDI Packet format and handles all required translation in the service and driver. This makes the app model simple while ensuring all your existing devices continue to work.
+* **UMP-Centric**. The new API fully embraces MIDI 2.0 and the Universal MIDI Packet format and handles all required translation in the service and driver. This makes the app model simple while ensuring all your existing devices continue to work. Messages to and from any endpoint, whether it is MIDI 1.0 or MIDI 2.0 data format, are transparently translated in the service, and presented as UMP through the API.
 * **Open Source**. The source code is open and available to everyone under a permissive license. Not sure how something works? Want to create a transport but aren't sure how we did it? Want to investigate a bug or contribute a feature? The code is there for you to explore.
+* **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.
 
-> Note: Additionally MIDI CI functionality, which does not technically require OS support, will be coming after version 1.0. We intend to add helpers for profiles, property exchange, MUID tracking, and more. In the meantime, applications can send and receive MIDI CI messages without anything in their way, using custom code or third-party libraries. MIDI CI is just MIDI 1.0-compatible SysEx.
+## Release Plans
+
+We currently plan to release Windows MIDI Services in-box in the latest version of Windows by the end of this calendar year. We will then back-port to the supported versions of Windows 11 and the latest supported Window 10 shortly afterwards.
+
+(Plans are always subject to change, especially with quality-driven deliverables, but that's what we're currently working towards)
+
+The MIDI console and Settings app are planned to ship and be services through the Microsoft Store on Windows.
 
 ## Developer Samples