Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Hierarchical approach to sorting MIDI ports #15

Open
keinstein opened this issue Mar 25, 2014 · 0 comments
Open

Hierarchical approach to sorting MIDI ports #15

keinstein opened this issue Mar 25, 2014 · 0 comments

Comments

@keinstein
Copy link

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:

Hierarchical_device * GetRootDevice();
std::list<Hierarchical_device *> GetSubDevice(Hierarchical_device *);
Hierarchical_device * GetSuperDevice(Hierarchical_device *);

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 .

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant