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

Unify getPortName() across drivers #6

Open
wants to merge 1 commit into
base: master
Choose a base branch
from

Conversation

drewish
Copy link
Contributor

@drewish drewish commented Jan 19, 2014

On OS X if you open a virtual port using input->openVirtualPort("foo bar") then call input->getPortName(1) (assuming that's the right port number) it returns foo bar.

Looking at the Windows code it seems to also just return the name.

Annoyingly, under ALSA it returns RtMidi Input Client:0 making 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.

Before it was client:portnumber which didn't match what was passed by
openVirtualPort().
@drewish
Copy link
Contributor Author

drewish commented Jan 20, 2014

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.

@drewish
Copy link
Contributor Author

drewish commented Jan 21, 2014

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.

@garyscavone
Copy link
Contributor

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:

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.


Reply to this email directly or view it on GitHub.

@drewish
Copy link
Contributor Author

drewish commented Jan 30, 2014

@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.

@garyscavone
Copy link
Contributor

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:

@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.

@keinstein
Copy link

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).

@keinstein
Copy link

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.

@garyscavone
Copy link
Contributor

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.

@keinstein
Copy link

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.

@radarsat1
Copy link
Contributor

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?

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

Successfully merging this pull request may close these issues.

4 participants