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

(Optionally) do not make Win32 port names unique #100

Closed
sagamusix opened this issue Feb 6, 2017 · 5 comments
Closed

(Optionally) do not make Win32 port names unique #100

sagamusix opened this issue Feb 6, 2017 · 5 comments

Comments

@sagamusix
Copy link
Contributor

In the general case, MIDI port names are unique for most users and as such, it's not required to add a number at the end. Currently my own code tries to reverse this behaviour by removing the number again if it finds one. It would be great if this behaviour could be disabled, if not by default then at least optionally.

I guess this might also be related to #30.

@garyscavone
Copy link
Contributor

Another port naming issue, with no clear solution.

@sagamusix
Copy link
Contributor Author

I would like to discuss this a bit further than just saying there's no clear solution, because the current state of the API is not optimal either. So by definition we have no guarantee that port names are unique, and as such it's a bad idea to rely on their uniqueness.
As far as I understand the current solution tries to make this easier for applications that rely on the port names being unique, but actually I think it's very bad to rely on this: The names are no longer stable. Depending on the order in which you plug in MIDI devices, they will now have a different name every time, making the problem just worse if you want to somehow rely on port names.
So in my opinion RtMidi should not try to make port names unique but rather let the library user do this if they require it. It should be recommended to instead open ports by their ID rather than name, and a combination of ID+name should be used for remembering devices. This way, if the ordering stays the same, the application can still tell devices apart, and if it changes, you have already lost anyway.

@garyscavone
Copy link
Contributor

I don't disagree with what you are saying. But there have been many posts about the port naming scheme without any general solutions proposed. There was a PR (#27) submitted a long time ago but the solution was overly complicated for my tastes.

I don't have time to work on a solution to this problem so it will be necessary for one or more people from the development community to find a solution and submit a new PR.

@garyscavone garyscavone reopened this Aug 21, 2017
@sagamusix
Copy link
Contributor Author

As a compromise for the time being, would it be a good idea to submit a pull request which at least makes the current behaviour optional by means of a preprocessor switch (#ifdef RTMIDI_ENSURE_UNIQUE_PORTNAMES or such)? This way, software authors who prefer to ensure uniqueness themselves or do not need uniqueness at all could bypass this feature relatively easily without having to edit the RtMidi source (which I always dislike doing) or working around it in other ways.

@keinstein
Copy link

@sagamusix I had some busy time and was able to return to RtMidi upstream, only shortly. Though this patches have improved RtMidi a lot this does not solve #30 . It does not resolve the race condition. Suppose you are loading a JACK or ALSA session where two programmes open a lot of virtual ports and many connections. Each of them has to query all the port names for opening trice (once for getPortCount, a second time for getPortName, and a third one for openPort). Each result may have been rendered unusable by other processes. You can enhance your luck, when you allways check all port names and take the last one and call getPortCount during every loop iteration, which gives you quadratic complexity for opening just one port. The additional time taken to compare the strings might make the problem even worse. At the end you have at least cubic complexity in the number of available ports of all clients and cannot be sure that your software has opened the right ports.

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

3 participants