[TODO] Consider creating Device Manager function to create multiple MIDI 1.0 endpoints

[Psychlist1972]

To ensure consistency in how the MIDI 1.0 endpoints are created, consider creating a MidiSrv Device Manager function which takes in a UMP endpoint and a set of parameters for which MIDI 1.0 ports to create and how they related to the groups (or pins as appropriate).

[MusicMaker]

Any more details on what this entails, what does means for the API , the clients to connect or naming of the connections for users
?

[Psychlist1972]

Any more details on what this entails, what does means for the API , the clients to connect or naming of the connections for users ?

Currently, each transport is responsible for creating all of its endpoints: UMP and MIDI 1.0 Data format. This task is just to create a standard way to create the MIDI 1.0 endpoints (for the older WinMM and WinRT MIDI 1.0 APIs) so we don't have the code duplicated in each of the transports/abstractions.

More detail: when a MIDI 2.0 device is connected to the UMP driver (or a MIDI 1.0 device is connected to the new driver), we create the UMP Endpoint for it with group terminal blocks and/or function blocks which indicate active groups. That is what clients using Windows MIDI Services directly see and interact with.

In order to allow apps using our existing MIDI 1.0 APIs to use those same devices, we need to create classic input/output port(s) for each active group in the UMP endpoint. We also have to ignore stream messages and translate between MIDI 1.0 data format and UMP data format (that code is already in place).

This is essentially a refactoring task.

[Psychlist1972]

Related
#347
#346
#345
#344

[Psychlist1972]

Gary has a slightly different approach here. Closing this.