Unify getPortName() across drivers #6
Conversation
Before it was client:portnumber which didn't match what was passed by openVirtualPort().
|
I tried to do some testing with the Jack library but didn't have much luck. I was able to get the RtMidi built against it but couldn't seem to get it to connect to jackd. |
|
If the maintainers would like to keep including the client name then I'm fine with that. I think the important thing is to return the port name. So just let me know how you'd like to proceed. |
|
Hi Andrew, Did you ever get it working with Jack? I haven’t tried it in a while but it worked for the last release and I know there are other users out there using RtMidi with Jack. —gary On Jan 20, 2014, at 12:28 PM, andrew morton [email protected] wrote:
|
|
@garyscavone no I wasn't quite sure how to get Jack up and running for testing so I'm not 100% sure what it's return format looks like. If you're interested in pursuing this patch I'm happy to spend the time figuring out how to get it installed and tested. |
|
In terms of port names, we are pretty much at the mercy of what the drivers provide, and that may vary from one OS to another. The main problem reported by users in the past has been that having two or more devices of the same make/model produced the same names, and thus there was no way to distinguish the two. Some people have submitted patches (which I accepted) for some of the APIs to remedy this, usually by appending port numbers or client names to the device names. I think the most uniform approach would be to append port numbers only, as the concept of clients is not available on all OSes. But the port numbering thing can get a bit messy if users are plugging and unplugging devices during a given instance. I’m still in the middle of trying to incorporate some other patches that have been submitted. I’ll look more closely at the port naming issue when I finish that. —gary On Jan 29, 2014, at 8:54 PM, andrew morton [email protected] wrote:
|
|
I think this problem could be simplified if RtMidi would provide a mechanism to use the system provided Ids instead of the enumeration of the devices. I think this is possible using a common API and some abstraction class, just a matter of implementing it. At least for ALSA the RtMidi Id is useless as it changes when a client with a smaller Id adds a device. I came across this problem when I used Mutabor together with several other clients like VPMK and some individual MIDI filters. The software starts in a passive mode and claims the devices only when the whole patch bay is activated. As RtMidi provides a full software output devices as soon as the program connects to some filter, synth or output device chances are high that you MIDI setup gets messed. The current workaround is to keep Mutabor being the client with the highest client Id (I'm up to address this issue, thats why I found this thread). |
|
Playing around with node-midi I came to the conclusion that something is missing in the RtMidi API: If you have opened a port, there is no way to get information about it. Getting the generated port name would be sufficient at least for ALSA in this case as the test suite may control how many port it opens in which order. This implies that both input and output device names are the same as #11 suggests. |
|
In ALSA, the getPortName() function returns the client name, the client # and the port #. Thus, if you named your client "foo bar," you'd get "foo bar" back in the name. I agree that there are inconsistencies between the APIs but I don't know how best to fix those (at the moment). I tried returning the port name in the getPortName() function (in ALSA), but the results are more cryptic. I think I need to make a new release with all the various fixes I've been collecting and then we can try to figure out a better port naming / IDing scheme. |
|
In #21 I address this issue by providing different naming schemes. It should work for ALSA, now. midiprobe2 uses this API and shows you the possible alternatives. |
|
This PR no longer applies cleanly and the conflict seems to affect the functionality of the PR. I'd like to apply it but I'm not sure of the right fix. Would anyone be willing to take a critical look at the port naming issues once again? |
On OS X if you open a virtual port using
input->openVirtualPort("foo bar")then callinput->getPortName(1)(assuming that's the right port number) it returnsfoo bar.Looking at the Windows code it seems to also just return the name.
Annoyingly, under ALSA it returns
RtMidi Input Client:0making all but impossible to match to the name given when opening it. I modified this code to only return the port name.I'm not quite clear what the Jack code returns.