Arch Linux: No input or output devices listed

[samwho]

I realise that this error is similar to other existing errors but the solutions all appear to be for OSX machines, so I thought I'd open up a new issue to troubleshoot this on Arch :)

I had to install alsa-rawmidi, midi-jruby and midi-winmm to actually require the unimidi gem in my code.

Running "unimidi list" at the command line returns:

input:
output:

I'm running a software midi synth. I tried with timidity and qsynth and I get the same result with both.

Am I doing something wrong? :)

[arirusso]

Hi,

@samwho

I think I see what's happening...

Yeah, there have been similar questions in OSX. Unfortunately, OSX may make it a bit easier to deal with because it has native internal MIDI patching.

unimidi list will show you what MIDI devices you have connected to your OS

Just running another program (eg qsynth) doesn't necessarily mean that the program will connect to the OS as a MIDI IO device.

There ARE programs that will adapt qsynth to do that. I've never used this, but...

http://pkl.net/~node/software/alsa-patch-bay/

Looks like it may work ? Also, looks very old so I'm not sure.

Another option is to connect a hardware MIDI interface ala http://bit.ly/GH1NU4. It will then appear in your unimidi list as well as in qsynth and the other programs. So you could run a cable to physically patch the I/Os to each other...

[samwho]

Patching MIDI inputs and outputs can be done using aconnect. I've been using MIDIator up to now but Ben declared it a dead project as of quite recently.

What I was doing with MIDIator was registering my program as a MIDI input and then hooking it up to a MIDI output using the aconnect command.

When running qsynth, I can list my MIDI outs using aconnect -ol and get this:

client 14: 'Midi Through' [type=kernel]
    0 'Midi Through Port-0'
client 128: 'FLUID Synth (19210)' [type=user]
    0 'Synth input port (19210:0)'

And my midi inputs with aconnect -il:

client 0: 'System' [type=kernel]
    0 'Timer           '
    1 'Announce        '
client 14: 'Midi Through' [type=kernel]
    0 'Midi Through Port-0'

When using MIDIator, I would have an extra listing in the inputs that was my program (client 129 it was). I don't get that with UniMIDI. If I could get to that point, I could do the patching :)

[arirusso]

Oh ok, hmm, I wonder why midiator would see it but not unimidi. That's odd.

Unfortunately, I don't have a linux computer with me right now. I will in a couple of weeks when I get back from the west coast if you can wait that long.

this library is what handles the device selection and IO on linux: https://github.com/arirusso/alsa-rawmidi. it's not super complicated, you may want to take a shot at debugging it

[samwho]

MIDIator didn't necessarily see the software synth output. It just registered itself as an input device and let the user manually patch it to an output. Not necessarily the most ideal solution but I made it work with a little fiddling :)

I took a swift look at the code behind alsa-rawmidi Devices and it looks like you're just scanning for hardware devices, which explains the problem.

Do you think you would be able to modify unimidi slightly to allow users to register their program as an input device that sends MIDI data to an output device? That's what MIDIator appears to do when you create a MIDIator::Interface and call autodetect_driver on it.

Time is, unfortunately, a little limited. I'm using MIDIator for my dissertation for my undergrad degree. I'm working on generative audio ^_^ Nothing overly complicated, just researching and demonstrating a few techniques. The final hand in is at the start of May.

I imagine what I will do is keep using MIDIator for the time being but switch over to UniMIDI whenever we manage to get it working. There isn't really any pressure, MIDIator works fine at the moment. I don't really know enough of the low level ideas behind MIDI to help you but I appreciate your swift responses. Thank you!

[arirusso]

Do you think you would be able to modify unimidi slightly to allow users to register their program as an input device that sends MIDI data to an output device?

I'd certainly be willing to try! but yeah, I'll need my linux laptop, which is unfortunately 3000 miles away :)

I'm not 110% convinced though -- I'm just using the "snd_ctl_rawmidi_next_device" function to find devices. When you connect a virtual rawmidi device with aconnect, it should in theory show up there. I believe I tested that at some point....

[samwho]

I was always directly connecting a virtual input device (my program) to a virtual output device (software synth, ei. qsynth or timidity). What steps would I go through to connect a virtual midi device to the system?

I'm absolutely open to being wrong or underinformed about various aspects of MIDI :) I'm still quite wet behind the ears.

[arirusso]

See if any of this helps: http://wiki.allegro.cc/index.php?title=Using_TiMidity%2B%2B_with_ALSA_raw_MIDI

[samwho]

I read that and when I use aplaymidi to play a midi file, it plays fine. aconnect -i doesn't list any virtual devices, though. Just the standard System and Midi Through.

I did the modprobe command and it completed fine. I'm guessing those virtual devices have something to do with that.

[arirusso]

maybe this: http://www.midi-howto.com/midi-howto-10.html#ss10.3

?

[samwho]

Aha! I seem to have life.

So, I read through that post and realised when I did the modprobe call I didn't give it a snd_index. This command gave me all of the virtual midi devices that I was missing:

sudo modprobe snd-virmidi snd_index=2

I gave it 2 because I have 2 sound cards (USB headset apparently counts as a sound card). Then it was just a case of running an aconnect to connect the first virtual midi device to Timidity and then the example code on your site worked :)

That setup seems a bit involved, though... Is there no way it could be easier than that?

[arirusso]

nice!! well, that's progress at least.

what about in this link where they talk about modules.conf?

http://tldp.org/HOWTO/MIDI-HOWTO-10.html

[samwho]

Hm. Now I've restarted my machine it doesn't seem to want to work...

[arirusso]

tough to help you there... maybe check your bash history for a command that you forgot you did earlier?

[samwho]

Aha! Got it. I had a typo in my /etc/modprobe.d/virmidi.conf file. I think I got it this time...

You've been such a big help, thank you :)

On 23 March 2012 00:40, Ari Russo < reply@reply.github.com

wrote:

tough to help you there... maybe check your history for a command that you forgot you did earlier?

---

Reply to this email directly or view it on GitHub: https://github.com/arirusso/unimidi/issues/13#issuecomment-4651514

[samwho]

For reference, I just wrote myself a little readme that explains the steps I took to solving the virmidi problem:

The Virmidi Module

If you're on linux, you'll need to snd-virmidi module to be enabled. The following command will do that (you may need to run this as root):

modprobe snd-virmidi index=1

The index variable will change if you have more than one sound card. Run the following commands to see your sound cards:

cat /proc/asound/cards

If there is 1 item in the list, use 1 as your index. If 2, use 2 etc.

This will give you some virtual midi devices that unimidi will be able to connect to and send output to.

Setting it up to do this automatically on boot

I personally use the Arch Linux distribution and setting up your machine to perform this module loading on boot is easy. In your favourite text editor, load up the file /etc/rc.conf and add snd-virmidi to your list of modules, so your MODULES array might look something like this:

MODULES=(snd-virmidi)

To make sure it gets the right argument, you will need to open up a new configuration file in your modprobe.d directory like this:

vim /etc/modprobe.d/virmidi.conf

And put the following line in it:

options snd-virmidi index=1

Obviously change the number after index to reflect what you chose in the section above.

Connecting it up

After you've sorted all of that out (you might need to reboot your machine to check it all works) you will need to connect a virtual midi device to an output device.

First, make sure you have an appropriate output device running. I'm using timidity++:

timidity -iA

Then, list your virtual midi devices with aconnect -il:

client 0: 'System' [type=kernel]
    0 'Timer           '
    1 'Announce        '
client 14: 'Midi Through' [type=kernel]
    0 'Midi Through Port-0'
client 24: 'Virtual Raw MIDI 2-0' [type=kernel]
    0 'VirMIDI 2-0     '
client 25: 'Virtual Raw MIDI 2-1' [type=kernel]
    0 'VirMIDI 2-1     '
client 26: 'Virtual Raw MIDI 2-2' [type=kernel]
    0 'VirMIDI 2-2     '
client 27: 'Virtual Raw MIDI 2-3' [type=kernel]
    0 'VirMIDI 2-3     '

We'll take the first one there, 24:0. Then check what port timidity is running on with aconnect -ol:

client 14: 'Midi Through' [type=kernel]
    0 'Midi Through Port-0'
client 24: 'Virtual Raw MIDI 2-0' [type=kernel]
    0 'VirMIDI 2-0     '
client 25: 'Virtual Raw MIDI 2-1' [type=kernel]
    0 'VirMIDI 2-1     '
client 26: 'Virtual Raw MIDI 2-2' [type=kernel]
    0 'VirMIDI 2-2     '
client 27: 'Virtual Raw MIDI 2-3' [type=kernel]
    0 'VirMIDI 2-3     '
client 128: 'TiMidity' [type=user]
    0 'TiMidity port 0 '
    1 'TiMidity port 1 '
    2 'TiMidity port 2 '
    3 'TiMidity port 3 '

Okay, that's 128:0. Then we connect the two up:

aconnect 24:0 128:0

And whatever comes from the first virtual midi device (the one that unimidi will connect to) will be sent straight to timidity and timidity will send it to your speakers.

[arirusso]

No problem! Perhaps I'll assemble a separate readme for each platform and work this into the linux one.

Good luck w your dissertation! Let me know if you wind up using this, I'd love to check out what you've done

[digitalWestie]

Guys this really helped me! Thanks a bunch. (Using Ubuntu 11.10)

[ericwilk]

Hmm, strange -- it doesn't list the programs I have open when I load the module, only a bunch of virtual devices. I'm not going straight through ALSA though; I'm using JACK on top of that. I'm assuming that's the reason why. aconnect -il/ol still gives me what I need, so I'll probably fiddle around with this a bit. I'm assuming if I can get the client ID I can somehow get this working.