Closed sadguitarius closed 10 months ago
An update: I am able to connect a USB-connected MIDI device to an rtpMIDI port, so I guess the problem is limited to connecting two rtpMIDI ports together.
Hi, thanks for the report.
I just did a huge rewrite of the server... I'm sorry it broke some use cases. I will look into it ASAP.
Ok thank you and let me know if there are any tests you’d like me to do to help troubleshoot. I’m a little unclear on the midirouter functionality. Would this in theory allow direct connection between two existing rtpMIDI ports bypassing ALSA MIDI? That would certainly help out with the issues I was having with ALSA dropping long sysex messages. I’m mostly just using rtpmidid as a CLI MIDI patchbay on a Rasbperry Pi.
Fixed the compilation problem.
For the connect two rtpmidi peers, I think it should be possible with an easy addition to the CLI to allow random connections of midipeers.. I will check it out too. And also now there is a INI file that could be used for default connections.
I keep looking into the bug of using rtpmidid as rtpmidi repeater. I was able to reproduce it.
I think all is fixed. Can you confirm?
Also the client now has a TUI mode (works as before too, can send commands). And has commands to interconnect two peers directly, although ALSA is still needed.
I would suggest to open another issue with your exact use case, and we can work on it there.
Hmm, still getting the same problem with MIDI message forwarding. Are there some logs I should try enabling so we can see where the messages are getting dropped?
I think I found it and fixed it!
It was that when connecting a port from my ALSA client to another port of my ALSA client, it was sending only one side of the connection (A to B). So B was connecting properly, but as A never knew there was a connection, it did not try to connect. Now I tell both sides A and B that they have an ALSA connection, so both can initiate the rtpmidi connections.
Using the new "top" mode of rtpmidid-cli was very helpful for me as I saw the A side was not even trying to establish connection.
Please tell me if its fixed now.
Ah yeah that totally makes sense! And it's working now, at least when connecting devices together via ALSA. I haven't totally grokked the cli interface yet, but so far things seem to be working fine. Thank you!
I guess I'll go ahead and close this. If anything else comes up as I'm testing things out I'll open a new issue. Thanks!
Thanks!
If you see anything else, please open an issue!
Hi David, since I've update to your latest commit, I'm experiencing some issues.
The first one, which seems simple enough, is that I am unable to build the project unless I change line 269 of control_socket.hpp to
{"id", js["id"]}, {"error", fmt::format("Unknown method '{}'", nlohmann::to_string(method))},
I'm using a Arch PKGBUILD that is mostly copied from the Arch AUR, but I haven't had issues with this in the past, although it's possible some dependency changes have messed something up. I'm happy to submit a pull request if this change doesn't present any other issues.
The other more serious problem is that rtpMIDI connections are completely broken for me.
When I initiate a connection through one of the ALSA ports created by rtpmidid, the connection shows up in aconnect, and I can see the rtpMIDI latency measurements in the journal, but no MIDI can be sent through to the receiving port. I do, however, see the incoming MIDI in aseqdump.
Basically it seems like the router and ALSA aren't actually communicating with each other.
Granted, there may be some differences in my setup on Arch, but everything's been working perfectly up until now. Are you able to suggest where I could look for the source of the problem? Thanks!