USB devices are in many ways great. They are easy to connect to the computer and you can usually hotplug them or remove them, change ports etc without any problems. However, when it comes to USB-MIDI devices and a VPO there have been issues with all OS versions because of the very nature of how USB connections work. The issues have for instance manifested themselves as keyboards changing identifier names with reboots which in turn made earlier connections in GrandOrgue not valid anymore.
Later on this page I'll describe the issues further and provide the workaround I used with Ubuntu Linux 14.04 some time ago, but now there's a much better way built in with GrandOrgue that take care of the USB-MIDI device detection/naming. To take advantage of it you'll need a very recent Linux distribution as OS (like for instance Ubuntu 16.10+, Fedora 24+ or openSuSE Tubmleweed) and a new build of GrandOrgue (a revision version greater than 2173). Now the names of USB-MIDI devices should be stable and not changing with every (other) reboot. I recommend this approach.
The rest of this page is kept for legacy reasons only. It's not certain that any of the information presented hereafter is relevant or working with newer distributions of Linux.
After playing with my organ setup for a while some irritating issues started showing themselves that in fact were linked to each other and how computers/OS behave with usb devices. They were:
- The soundcard I used for audio playback got a different identification number with every reboot which forced me to change the audio settings in GO every time that happened.
- The three keystations I used for manuals could get different identification numbers too that would require a reconfiguration of what manual was connected to what keyboard with every reboot.
Suffering from the above issues made saving the configurations kind of pointless as I anyway had to change things around every now and then. Having read and understood that this was a common problem with usb devices I long thought that this was inevitable and something I'd have to live with.
One possible solution for the MIDI issue would be to get a MIDI interface that the keyboards (and pedal) would connect to with real MIDI cables. Then the jumping around would disappear as the computer would only see one device with different ports. Drawbacks would be that external power would have to be used for the keyboards and more hardware required to fit into the console case (not to mention the cost of buying the things). A separate MIDI interface could in fact be good to have but recently I've found another way to fix my issues. Lots of googling and reading different guides on the internet gave hope for a software fix of this but no complete manual existed and I did have to adapt a few things on what I found to make it really work.
First I should probably say that the fix is for (Ubuntu) Linux OS machines and involves some configuration file changes done manually. Even though the same problem obviously affect users of other OS (eg. Windows) I've got no clue how to fix it on them as I personally don't use anything else than Linux for serious computer work.
First off I made sure that the soundcard I use for audio would always be getting the first card index number followed by four usb devices (three manuals and one pedal). This is done by modifying the settings file /etc/modprobe.d/alsa-base.conf quite easily. I opened a terminal and typed:
gksudo gedit /etc/modprobe.d/alsa-base.conf
typed in my password and added a new line at the end of the file reading:
options snd slots=snd-hda-intel,snd-usb-audio,snd-usb-audio,snd-usb-audio,snd-usb-audio
that in effect reserves the first index (slot) to the built in soundcard and the next four for usb audio devices. After saving that file the soundcard would always stay the same but the MIDI keyboards could still change.
The solution to be able to differentiate between the (identical) usb MIDI devices was to give them unique identifiers based on what usb port they are connected to. This is done by creating a udev rule file. But first we need to find out what device paths the devices have. That's done by using udevadm in the terminal. Unfortunately for me the information on the internet for how to use the command didn't really work so I had to do some extra steps.
From internet I knew that the devices should be in /dev/snd but using that as a path was not accepted at first. Then I looked in the by-path folder there and from right-clicking the files and checking their properties I could find what files they were linking to. Now I could use the udevadm command like this in a terminal (do note that the path and filename likely are unique for my setup):
udevadm info -a -n /dev/snd/controlC1
that would spit out an extreme amount of information. What I was interested in though was the device path that would be found in a string looking like:
looking at parent device '/devices/pci0000:00/0000:00:1a.1/usb4/4-1/4-1:1.0/sound/card1':
that would have a line with
somewhere below it. Then I did the same with the files controlC2, controlC3 and controlC4 too. Still remember that your files could be named something else! See above for how I found out mine.
What I needed was the path that I could put into a udev rule file of my creation that would assign the device at this usb port with the same identifier every time. Thus I created a file named 85-my-usb-audio.rules that's located in the /etc/udev/rules.d folder. I simply started gedit as an administrator with:
and wrote the following lines into the file:
and saved the file as /etc/udev/rules.d/85-my-usb-audio.rules. Do note that I after the device path card removed the number and added a ? to match whatever card number would be assigned. What I think that this whole procedure does is to always force the same identifier attribute to the device on the usb port that then alsa will recognize and use for ordering of the devices.
Anyway, now after reboots I always have the same soundcard set so I don't have to change it all the time, also the MIDI devices always gets the same numbering that eliminates the need for reconfigurations. So far this has worked and I can start saving configurations within GO for serious work!
Another GrandOrgue user has reported only partial success with the method above, the main difference seems to be him using an external USB-hub that (some of) the keyboards connnect through whereas I have all the keyboards directly fed into the computer USB ports. So far I've myself not had any problems with changing device numbers anymore so I can only recommend connecting the MIDI keyboards directly to the computer (always the same ports too!) to have this fix work as it should.
If anyone has ideas for improvements or corrections they can feel free to provide feedback to me by using the Contact form in the menu to the right! Otherwise I hope that this writeup can help someone with similar issues that I've had.