-
Notifications
You must be signed in to change notification settings - Fork 28
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
Arch Linux: No input or output devices listed #13
Comments
Hi, 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.
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 |
Patching MIDI inputs and outputs can be done using 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 When running qsynth, I can list my MIDI outs using
And my midi inputs with
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 :) |
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 |
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! |
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.... |
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. |
See if any of this helps: http://wiki.allegro.cc/index.php?title=Using_TiMidity%2B%2B_with_ALSA_raw_MIDI |
I read that and when I use I did the modprobe command and it completed fine. I'm guessing those virtual devices have something to do with that. |
maybe this: http://www.midi-howto.com/midi-howto-10.html#ss10.3 ? |
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:
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? |
nice!! well, that's progress at least. what about in this link where they talk about modules.conf? |
Hm. Now I've restarted my machine it doesn't seem to want to work... |
tough to help you there... maybe check your bash |
Aha! Got it. I had a typo in my /etc/modprobe.d/virmidi.conf file. I think You've been such a big help, thank you :) On 23 March 2012 00:40, Ari Russo <
|
For reference, I just wrote myself a little readme that explains the steps I took to solving the virmidi problem: The Virmidi ModuleIf you're on linux, you'll need to snd-virmidi module to be enabled. The
The index variable will change if you have more than one sound card. Run the
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 Setting it up to do this automatically on bootI personally use the Arch Linux distribution and setting up your machine to
To make sure it gets the right argument, you will need to open up a new
And put the following line in it:
Obviously change the number after index to reflect what you chose in the section Connecting it upAfter 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++:
Then, list your virtual midi devices with
We'll take the first one there, 24:0. Then check what port timidity is running on with
Okay, that's 128:0. Then we connect the two up:
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. |
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 |
Guys this really helped me! Thanks a bunch. (Using Ubuntu 11.10) |
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. |
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:
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? :)
The text was updated successfully, but these errors were encountered: