You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
on some of the supported systems the MIDI ports are hierarchically ordered. On some systems we have different APIs, on others ports are assigned to clients or devices. So it would be nice to have a tree-like structure to assist users to find the right MIDI port. I don't think it would be a good idea to hardwire this relationship to any assumption about the “hardware” structure. Just a superdevice-subdevice relationship would be ok. This would include to have RtMidi branching devices which are neither input ports nor output ports.
The interpretation of this relationship should be left to the API that is used. So it should not be a problem if Windows has an API/Port structure while ALSA provides API/Client_or_device/port. Some network defined protocol might use Server/Network_Port/API/client_or_device/port. It might be more complex if the protocol allows to reexport MIDI ports. I think the API for such a feature can be realised with just a view functions:
Hi,
on some of the supported systems the MIDI ports are hierarchically ordered. On some systems we have different APIs, on others ports are assigned to clients or devices. So it would be nice to have a tree-like structure to assist users to find the right MIDI port. I don't think it would be a good idea to hardwire this relationship to any assumption about the “hardware” structure. Just a superdevice-subdevice relationship would be ok. This would include to have RtMidi branching devices which are neither input ports nor output ports.
The interpretation of this relationship should be left to the API that is used. So it should not be a problem if Windows has an API/Port structure while ALSA provides API/Client_or_device/port. Some network defined protocol might use Server/Network_Port/API/client_or_device/port. It might be more complex if the protocol allows to reexport MIDI ports. I think the API for such a feature can be realised with just a view functions:
The first function could be ommitted by calling GetSubDevice(null_ptr).
Such an API could avoid the problem that are discussed in #6 and #11 .
The text was updated successfully, but these errors were encountered: