winmidi open_virtual_port() is not implemented

[atsushieno]

Currently midi_in and midi_out in winmidi backend do not implement open_virtual_port(). I believe the new winmidi supports virtual devices, unlike winmm API. Would there be some technical roadblocks to achieve that?

I'm trying to get my virtual MIDI 2.0 device application (it makes full use of libremidi on Linux and macOS) working on Windows and noticed this issue.
https://github.com/atsushieno/uapmd

Confirmed with v5.4.3.

[jcelerier]

thanks for the heads up, I'll look into getting them done this week!

[Psychlist1972]

There are two ways to create virtual devices in the new stack. Which you choose depends on your goals.

Everything follows a bidirectional pattern, to be compatible with MIDI 2.0

Loopback Endpoint Pair

You can create a transient loopback endpoint pair. That gives you two in/out pairs (A) and (B). Anything sent to A comes back on B. Anything sent to B comes back on A. This provides loopback functionality that is compatible with both MIDI 1.0 and MIDI 2.0, but you will end up with two MIDI 1.0 in ports/sources and two MIDI 1.0 out ports/destinations. You could always ignore one direction if it suits your needs. However, the ports will have different names, as is required. (By default, we use (A) and (B) but you can choose anything, as long as they are different.

Virtual MIDI 2.0 Device

The second is the virtual device approach linked in the issue. Virtual devices are full MIDI 2.0 devices, and participate in MIDI 2.0 discovery, can have function blocks and other MIDI 2.0 metadata. This is for those who want to have a full MIDI 2.0-compatible application that appears as a MIDI 2.0 device.

This also creates MIDI 1.0 compatible ports just for the client connections. The host app connection is MIDI 2.0-only.

Which one?

There is nothing that is exactly analogous to the MIDI 1.0 loopback port which gives you one unidirectional pair of endpoints (in and out). The closest is the loopback pair mentioned above.

Question for you all: for libremidi to work properly, can you use the bidirectional loopback endpoint pair? Or do you absolutely need a single unidirectional MIDI 1.0-style port in/out pair?

Pete
Microsoft

[atsushieno]

My report here is talking only about missing virtual UMP ports, but I'm sure people would like to create virtual MIDI 1.0 ports and have their MIDI 1.0 apps work with that. In such cases, MIDI 2.0-only stuff is not welcomed.

Every MIDI 2.0 app I build is based on pairing traditional in/out unidirectional ports and relies on users' choice of the right ports to be paired. That's a compromise, but I don't think x-plat libraries like libremidi could provide reliably-paired in/out ports (I also build similar library stack in Kotlin). At least it was impossible on Web MIDI API.

If there are x-plat way to commonize support for MIDI-2.0-only duplex ports (I guess JUCE was doing that in their ex-midi2 branch) I may end up switching to it, but so far I'm good with the current libremidi API nature.

[jcelerier]

thanks a lot @Psychlist1972 and @atsushieno for your comments !

@atsushieno I've started work towards having a separate new API which is based on MIDI 2 endpoint logic from the ground up but haven't gotten around finishing it yet: #191 (it will coexist next to the "classic" port based API and will only be for API that actually work like this with maybe optional shims if there is a meaningful way to have them - a hard / impossible problem as you saw -, e.g. the ALSA MIDI 2 impl, CoreMidi and Windows MIDI Services)

I think that the virtual midi 2 device is what I will use for this particular feature request, it feels somewhat closer semantically to how things work with e.g. JACK / PipeWire / ...

[jcelerier]

@atsushieno could you test my PR ? I see the devices being created correctly in the midi.exe CLI app but I have absolutely no idea how to connect them to another app to test - I think this is with the MIDI 2 control panel but it does not want to open at all here :/. I added a "midi2_virtual" test app that creates both a virtual in and out.

[Psychlist1972]

JFYI, in case it changes anything here, I've added preview support for simple MIDI 1.0-style loopback endpoints (like loopMIDI). It will be several months before it makes it into Windows, but I have preview bits available on Discord today, and on GitHub probably in a week.

microsoft/MIDI#869

[jcelerier]

that's going to solve one of the biggest and long-lasting pain points for musicians in windows :D

[atsushieno]

@jcelerier: I didn't have much time to test, but I couldn't get that example ports enumerated on my client either. Those ports show up on the MIDI Settings as well as MIDI2.0Workbench, but I don't think I got them communicating with those virtual ports either (but I'm not sure if I know how to use this app either).

[Psychlist1972]

@jcelerier: I didn't have much time to test, but I couldn't get that example ports enumerated on my client either. Those ports show up on the MIDI Settings as well as MIDI2.0Workbench, but I don't think I got them communicating with those virtual ports either (but I'm not sure if I know how to use this app either).

I'm assuming midicci is using one of the older MIDI 1.0 APIs. That will only work if Windows MIDI Services feature is enabled on your PC. Otherwise, you'll see everything through the MIDI 2 stack, but there will be no integration with WinMM or WinRT MIDI 1.0 APIs.

Tool to check for Windows MIDI Services feature enablement is near top of this post
https://devblogs.microsoft.com/windows-music-dev/windows-midi-services-rollout-known-issues-and-workarounds/