#1572 Incorrect MIDI Port Assignments
I am quite new to Rosegarden (on Ubuntu Studio), but have used another MIDI sequencer for many years. I am in the process of importing my collection of MIDI arrangements into Rosegarden and have been making reasonable progress. I have a 4 port MIDI box attached via USB with a Korg synthesiser on port 1, a Zoom guitar effects on port 2 and a Yamaha synthesier on port 4. I have set these up in Rosegarden and created a default studio. On most occasions, this works fine and I have imported a number of MIDI files, edited them, and saved them as .rg files. On three occasions (including the latest today) when I open Rosegarden (and Jack of course), I find that the default studio has moved my Korg to port 2 and my Zoom to port 4. When I open any of the previosly saved files they have the same settings and (of course) will not play correctly. After this problem happened the second time, I reconfigured the MIDI device settings and re-saved the default studio. I then went through about 50 .rg files, applied the corrected default studio and re-saved them. Today I find that they have all reverted to the wrong settings.
Please can you tell me why the MIDI device ports keep changing and how I can stop it happening.
Please provide a screenshot of the Manage MIDI Devices window configured the way you want it.
I have attached the screenshot of the MIDI devices setup. This works fine, but on a number occasions when starting up Rosegarden the setup had changed two of the connections. When opening saved .rg files these also showed the incorrect setup. I have since found that if this problem arises, and I re-start the PC the correct settings sometimes return return without me having changed anything in Rosegared, Jack or in the physical connections. I am at a loss to understand this.
Last edit: Ted Felix 2020-03-05
I'm thinking what's probably happening here is that the driver is randomly assigning :0 through :3 to different ports on the MIDI interface at boot time. Rosegarden tries to compensate for things moving around, but as I recall, it does so by matching text strings. It's going to find a match for what it matched last time, only now that particular string is associated with something different.
My memory on this is pretty distant, and not the clearest, but I vaguely recall having similar issues back when I had multiple cards with MIDI interfaces in my computer. The order of assignment at boot time was random, and there was no solution to that problem other than at the kernel level. In that case, the text matching helped, because the emu10k1 card and the ice24whatever card had plainly distinguishable strings. I suppose the sub-ports on each always went in the same order, or maybe it wasn't relevant to my circumstances. I'm afraid I haven't dealt with that as a user in quite some years.
I've cropped the screenshot down to just the dialog. The full screenshot was quite interesting, though, from the standpoint of seeing how rg looks at 2560x1440. I'm holding on to this for future HiDPI research.
On the topic at hand... The code that does the matching can be found in AlsaDriver::setPlausibleConnection(). When things go wrong, go to Edit > Preferences... and press the Details... button. Select all of the text in the pop-up (Ctrl+A), copy it (Ctrl+C), then paste it into this bug report. That might provide some clues.
Oh, and I forgot. Screenshot the Manage MIDI Devices dialog when things go wrong as well. Might be some clues there as well.
Thankyou for the helpful comments. Over the past week the problem has not returned. On each occasion I have followed the sequence of:
1. Start up the external MIDI devices
2. Start the PC and boot into Ubuntu Studio
3. Start Rosegarden
4. Start Jack
Each time the MIDI devices have been assigned to the correct ports. I am therefore keeping to this sequence and hope that the problem does not come, particularly as Rosegarden is the best Linux based MIDI sequencer that I have found with a score view function. It is the closest that I have found to Cakewalk Sonar that I have used for many years, although there are some strange differences (eg Sysex handdling) that I have had to find ways to work around.
Thankyou again for your help.
Ok. We'll hold the bug report open for a month or so in case it happens again.
Closing as this appears to be working now. Please reopen if it happens again, or open a new bug report.
Also, I've fixed a number of issues related to sysex recently. I'd love to hear what sort of issues you've had and how you'd like to see sysex work in Rosegarden. Feel free to open a bug report or feature request related to that. Or send an email to the rosegarden-user mailing list. Thanks.
Reopening this as Christophe Malhaire has reported this same problem on the user list June 30, 2020.
Last edit: Ted Felix 2020-07-03
Hi,
I set up the connections and saved my model as autoload.rg in ~/.local/share/rosegarden/autoload/autoload.rg. After that, I launched/left Rosegarden several times and the connections remained good. I did the same test with another file and it also worked.
But then I left the application, I turned off the instruments, turned them back on, and I restarted the application, and in this case some connections were mixed, unfortunately.
Regards.
Last edit: Ted Felix 2020-07-06
Thanks for that. This shows that the port name appears to be getting truncated. That could be an issue. XV-5050 is getting truncated to "X":
While MOTIF-R is getting truncated to MOTI:
Status...
The cut-off issue above is caused by the hyphen character not being included in the regexp search for the end of the port name.
Fixing that does seem to improve things a bit, but there are still more issues with the algorithm in general. E.g. no prioritization of match quality across ports, reliance on client number, etc...
I've been able to do some digging and experimentation and I think I'm going to redesign the algorithm for matching up ports. I'm thinking a two-pass approach that will assign obvious ports first, then backfill any that didn't get connected. The Levenshtein Distance algorithm seems to do a really good job of matching port names that are a little bit off (e.g. Fluidsynth and its inclusion of the process ID in the name).
The only issue is that the existing code doesn't seem very amenable to a two-pass approach, so some rearranging is in order to make this simple and clear.
That's the plan. Hope to have some time shortly to implement it.
[r15875] should improve port matching for the MOTIF-R and XV-5050 cases. Please test the latest svn and let me know how it goes. If there are problems, post the details window logging. Thanks.
Related
Commit: [r15875]
It still does not work. See the result of the test in attachment. Regards.
Ok. That's one of the things I noticed in the code. For a port number of 0 it gives the client number (24 in this case) priority. And that's what's causing the problem. I can easily just fix that and it should significantly improve things. I will have a look when I have a moment.
Just pushed [r15879] which should fix this. We now ignore the ALSA client numbers. They can change without warning and shouldn't be given priority when searching for a matching port.
Let me know how it goes. Thanks.
Related
Commit: [r15879]
After a quick test, it seems to work well, well done! It will be a very big improvement. But I need a few days to test all of this in more detail. I will add other instruments and test different configurations. One thing that might be interesting is that I have two Roland XV-5050, so I'm curious to see how it will be if both are on.
Thanks for all that work.
I did a few more tests and everything works fine. How nice it is to open a file and see that all the instruments are well connected! Many thanks.