-
Notifications
You must be signed in to change notification settings - Fork 275
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
Comments
Another port naming issue, with no clear solution. |
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. |
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. |
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 ( |
@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. |
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.
The text was updated successfully, but these errors were encountered: