[Feature] Shipping a default loopback device

[Fannon]

Is your feature request related to a problem? Please describe.
I created some web-apps that use web MIDI to enhance / transform the MIDI of existing controllers. To make those work, its always mandatory to have at least one MIDI loopback device. This is a big barrier of trying things out, that's why I'm really happy that the new MIDI stack will have loopback MIDI devices inbuilt.

Describe the solution you'd like

Would it be reasonable to create and enable one MIDI Loopback device by default, so users don't have to worry creating it? It would be similar to e.g. my audio interface also coming with one loopback channel by default. This would have a well-defined default name, so tools / webapps could pick that as a default, making things work out-of-the box, without asking users to set some things up first.

Describe alternatives you've considered

I understand that this feature request is debatable. Alternatively make it really easy to create a loopback device via Windows Settings and have a documentation page that tools can link to, so users can follow this step-by-step.

Do you wish to contribute a solution?
no (I assume this is no coding task, but more like default configuration)

Additional context

The simplest web-app example may be https://fannon.github.io/midi-deduper/
It deduplicates MIDI notes, as some pad controllers have issues with that.

[Psychlist1972]

Due to file protections/ownership with anything shipped in-box, we can't ship a default MIDI Configuration file. That means that a loopback would need to be created by the user.

The MIDI Settings app we ship with the SDK runtime and tools does make it easy to create a loopback, but it doesn't create a well-known loopback.

I could also put in something that, the first time it is run, it asks the user a few questions. I had been planning on something like that, but hadn't thought of asking about creating a default loopback with some known values.

That might be a nice one-click approach in addition to this one

(please ignore the "IO" part of the name. I'm working on some port naming stuff at the moment)

[Fannon]

Thanks for the quick response, @Psychlist1972 !

I totally understand that having a default loopback device wouldn't work then.
But having this in the settings is the next best thing!

Curious: Will those loopback devices then always be MIDI 2.0 and then fall back to 1.0 if one of the connected applications is only 1.0 capable?

In the screenshot, it looks like you always create a pair. How do the two devices interact with each other? What goes into A gets back out to B and vice versa? Could both have the same name? In the next screen I cannot see anymore that the two entries are a pair together / how they relate.

I'm asking because I'm now used to creating a single loopback device (with one name), which is input and output and just forwards input to output.

Thanks for your great work on this, I'm really looking forward seeing this land in Windows!

[Psychlist1972]

Because MIDI 2.0 is bidirectional, the loopback endpoints work a little differently now compared to what you may be used to from MIDI 1.0. It requires a pair of endpoints, but you end up with two sets to choose from because of the two bidirectional endpoints.

• Loopback A out goes to Loopback B in
• Loopback B out goes to Loopback A in

I don't recommend naming them the same because Loopback A does not route back to Loopback A, and so you could end up with some confusion. WinMM doesn't provide any good way to associate them. In the Windows MIDI Services SDK, you can see the association via the association id.

If you want to talk to yourself, you need to open two MIDI 1 ports: Loopback A out and Loopback B in, or Loopback B out and Loopback A in.

By default, we create MIDI 1.0 in/out pairs for Group 0 for each loopback endpoint. This is using the same code we use which also exposes MIDI 1.0-compatible endpoints for other MIDI 2.0 devices (USB, network, etc.) for all active groups.

(A MIDI 2.0 group is approximately equivalent to a MIDI 1.0 (which in MIDI 1.0 is an abstraction over a virtual cable number 0-15 on an endpoint). But now the group index is in the UMP message itself, so ports are a MIDI 1.0-only concept.)

We handle all MIDI 1.0-MIDI 2.0 protocol and format translation in the service.

This video shows how MIDI 1.0 and MIDI 2.0 apps and devices work together with translation in the service. MIDI 2.0 and MIDI 1.0 clients can use the same endpoints at the same time and get messages formatted (and downscaled, as appropriate) for what they understand.
https://www.youtube.com/watch?v=Oa6_pVveqPI

Loopbacks are the simplest app-to-app MIDI in Windows MIDI Services. We also have proper virtual device app support, because the MIDI 2.0 protocol involves a discovery and negotiation step to be compliant, and we want to simplify that for apps on Windows.

Long-term, there is planned more patch-bay style routing between any number of any type of endpoints. That's not going to be in the first version, however.

[Psychlist1972]

I'll also update this docs page with more info. So much documentation to write :)

https://microsoft.github.io/MIDI/endpoints/virtual-loopback.html

[Fannon]

Thanks, appreciate the explanations!

[Psychlist1972]

The first-run experience in the MIDI Settings app now includes creating the default loopback endpoints. I'm still tweaking this dialog, but here you go:

You can see the MIDI UMP Endpoint names here (Default Loopback A and Default Loopback B)

And the WinMM Endpoint names (I'm likely to ditch the "IO" at the end as it is not helpful)

Any number of other loopback endpoints can still be created, of course

[Fannon]

@Psychlist1972 awesome - thank you!