search

microsoft / MIDI

Windows MIDI Services
MIT License
285 stars 23 forks source link

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

Open Psychlist1972 opened 1 month ago

Psychlist1972 commented 1 month ago

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 commented 1 month ago

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 commented 1 month ago

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 commented 1 month ago

Related

347

346

345

344