Old Linux MIDI/Audio Notes
Apr 30, 2006 Bought an Akai MPD16 USB/MIDI drum pad thingy. Linux sees it as a USB device, and I can see various info about it in /sys, but it does not show up as a MIDI device. Wonder if it has firmware that needs to be downloaded to it like the Midisport? I kind of doubt it, because, in addition to the usb port, it has a regular MIDI port, and a power supply jack for a 9V DC 700ma power supply (power supply not included, BTW.) I suspect if I got a power supply and connected the akai mpd16 to the Midisport, and the midisport to linux via usb -- I suspect that then it would work. But, since it's got a usb port, it'd be really really nice to use that instead of a midi cable -> midisport -> usb port PLUS a wall wart power supply.
I think I will hunt up a power supply just to make sure the thing can work in some way for me, but then try to spend a little time to see if I can get linux to use it by USB alone.
Apr 29, 2006 Last night, stayed up until the wee hours of the morning programming on Gneutronica. Added some code to allow importing of ascii drum tabs. You can now either import them from a file, or select them with the mouse and just paste them in. It is the slickest thing ever.
Still a little shaky, maybe, and has loads of debug code in there so it's probably be a few days before I make a new release, but it's in CVS on sourceforge for any who may want to try it. I impressed my own self this time, it really is pretty slick.
Apr 26, 2006 Made a new release of Gneutronica, 0.29. Added a "scramble" feature to scramble patterns. Added the ability to squeeze more space onto the beginning and endings of patterns, squeezing the already placed notes left or right as needed. Added the ability to cut off the front or back of patterns. Added a new "select" button so the current pattern can be selected for later pasting without having to switch to the arranger window. The adding/removing of space from the beginning/ending of patterns, combined with copying/pasting of patterns means that it is now possible to join and split patterns as well.
Jan 5, 2006 Added hotkeys, 'c', 'p', 'x', 'P', and 'X' into Gneutronica for copying and pasting the parts of one instrument into another (useful for transporting songs across different drum kits.)
I have begun looking into fluidsynth, a software synth that uses soundfonts and looks to have a reasonably simple interface, and seems easy to build not requiring jillions of hard to come by libraries. It provides a library that is meant to be embedded in other programs. I think I might be able to use it to get Gneutronica to do sample based drums, which would be bad ass! And I think it won't even be difficult!
Midishare might be something I need to look into...
Turns out, you can already drive softsynths with no changes, using snd_virmidi.
[scameron@zuul ~]$ fluidsynth fluidsynth: ALSA driver: Using format s16, rw, interleaved fluidsynth version 1.0.6 Copyright (C) 2000-2002 Peter Hanappe and others. FLUID Synth comes with ABSOLUTELY NO WARRANTY. This is free software, and you are welcome to redistribute it under certain conditions; see the COPYING file for details. SoundFont(R) is a registered trademark of E-mu Systems, Inc. Type 'help' to get information on the shell commands. > load /home/scameron/soundfonts/tr808.sf2 fluidsynth: warning: Failed to pin the sample data to RAM; swapping is possible.loaded SoundFont has ID 1 >
[root@zuul ~]# modprobe snd_virmidi [root@zuul ~]# amidi -l Device Name hw:0,0 Audigy MPU-401 (UART) hw:0,1 Audigy MPU-401 #2 hw:0,2 Emu10k1 Synth MIDI (16 subdevices) hw:0,3 Emu10k1 Synth MIDI (16 subdevices) hw:1,0,0 MOTIF-R MIDI 1 hw:1,0,1 MOTIF-R MIDI 2 hw:1,0,2 MOTIF-R MIDI 3 hw:1,0,3 MOTIF-R MIDI 4 hw:1,0,4 MOTIF-R MIDI 5 hw:1,0,5 MOTIF-R MIDI 6 hw:1,0,6 MOTIF-R MIDI 7 hw:1,0,7 MOTIF-R MIDI 8 hw:2,0 Virtual Raw MIDI (16 subdevices) hw:2,1 Virtual Raw MIDI (16 subdevices) hw:2,2 Virtual Raw MIDI (16 subdevices) hw:2,3 Virtual Raw MIDI (16 subdevices)The lines beginning with "hw:2..." are my virtual midi devices, and the '2' means it's the 3rd device (0 and 1 are the 1st and 2nd). This matches the 2 in /dev/snd/midiC2D0
[scameron@zuul tr808]$ aconnect -lo
client 64: 'Audigy MPU-401 (UART)' [type=kernel]
0 'Audigy MPU-401 (UART)'
32 'Audigy MPU-401 #2'
client 65: 'Emu10k1 WaveTable' [type=kernel]
0 'Emu10k1 Port 0 '
1 'Emu10k1 Port 1 '
2 'Emu10k1 Port 2 '
3 'Emu10k1 Port 3 '
client 72: 'MOTIF-R' [type=kernel]
0 'MOTIF-R MIDI 1 '
1 'MOTIF-R MIDI 2 '
2 'MOTIF-R MIDI 3 '
3 'MOTIF-R MIDI 4 '
4 'MOTIF-R MIDI 5 '
5 'MOTIF-R MIDI 6 '
6 'MOTIF-R MIDI 7 '
7 'MOTIF-R MIDI 8 '
client 80: 'Virtual Raw MIDI 2-0' [type=kernel]
0 'VirMIDI 2-0 '
client 81: 'Virtual Raw MIDI 2-1' [type=kernel]
0 'VirMIDI 2-1 '
client 82: 'Virtual Raw MIDI 2-2' [type=kernel]
0 'VirMIDI 2-2 '
client 83: 'Virtual Raw MIDI 2-3' [type=kernel]
0 'VirMIDI 2-3 '
client 128: 'FLUID Synth (17540)' [type=user]
0 'Synth input port (17540:0)'
[scameron@zuul tr808]$
Note the last entry, "client 128" which is "FLUID Synth,"
my running softsynth.
[root@zuul ~]# aconnect 80:0 128:0
[root@zuul ~]# aconnect -lo
client 64: 'Audigy MPU-401 (UART)' [type=kernel]
0 'Audigy MPU-401 (UART)'
32 'Audigy MPU-401 #2'
client 65: 'Emu10k1 WaveTable' [type=kernel]
0 'Emu10k1 Port 0 '
1 'Emu10k1 Port 1 '
2 'Emu10k1 Port 2 '
3 'Emu10k1 Port 3 '
client 72: 'MOTIF-R' [type=kernel]
0 'MOTIF-R MIDI 1 '
1 'MOTIF-R MIDI 2 '
2 'MOTIF-R MIDI 3 '
3 'MOTIF-R MIDI 4 '
4 'MOTIF-R MIDI 5 '
5 'MOTIF-R MIDI 6 '
6 'MOTIF-R MIDI 7 '
7 'MOTIF-R MIDI 8 '
client 80: 'Virtual Raw MIDI 2-0' [type=kernel]
0 'VirMIDI 2-0 '
Connecting To: 128:0
client 81: 'Virtual Raw MIDI 2-1' [type=kernel]
0 'VirMIDI 2-1 '
client 82: 'Virtual Raw MIDI 2-2' [type=kernel]
0 'VirMIDI 2-2 '
client 83: 'Virtual Raw MIDI 2-3' [type=kernel]
0 'VirMIDI 2-3 '
client 128: 'FLUID Synth (17540)' [type=user]
0 'Synth input port (17540:0)'
Connected From: 80:0
[root@zuul ~]#
clients 80,81,82,and 83 are the virtual midi devices and correspond
to /dev/snd/midiC2D0, /dev/snd/midiC2D1, /dev/snd/midiC2D2,
and /dev/snd/midiC2D3, respectively. The idea is you connect
one of these nodes up to the input of the fluid synth, then
let gneutronica send to this node, and it will get routed to
the softsynth.
[scameron@zuul ~]$ gneutronica -d /dev/snd/midiC2D0Now, gneutronica should be driving the softsynth, just use it as you normally would.
Also worked on adding hotkeys. There are some peculiarities about Gnome/gtk/gdk with keys which I should record. My implementation works something like this.
I catch key_press_events from the top window widgets. But the problem there is they are intercepted, so that if I tie 'q' to quit function, then if I'm in a text entry field and I type 'q' the application quits. Not what is wanted. So, I made a list of GtkWidget pointers, and for each widget which I want to have keystrokes (text entries and spin buttons mostly) I call a function which adds that widget to the list. Then, in my key press callback function, I determine which window is getting the event (passed in as first param) and convert this to a GtkWindow pointer, then look at the focus_widget member. (This is not documented, but found and example on the web, and it seems to work...) Look for this focus_widget in the list of GtkWidgets that I have previously constructed. If found, then I just return FALSE, which lets the widget handle the key press as it normally would.
If I wanted to get fancier, I could instead of having a list of widgets, have a list of widget/function pointer tuples. When I look up the widget, if I don't find it, I figure it's not interested in keypresses and process normally. If I do find it, but the function pointer is null, then figure it wants all keypresses and ignore the keypress and let the widget handle it. If the function pointer is not null, then call the function and pass in the keypress and let the function tell me whether the widget is interested in the keypress or not. That way, for instance, you could have a widget which was only interested in certain keypresses but let the top level window handle most of them.
Here is how you insert rows into a gtktable.
Use gtk_table_resize to make it one row bigger, then traverse from the highest item to insertion point and use gtk_container_child_set to scoot every widget down one row then use gtk_table_attach to attach the new item in the new space.
Similarly, to delete a row in a gtktable. Use gtk_container_remove to remove the widgets from a row, then traverse the table from the deleted row up to the highest row and use gtk_container_child_set to scoot each remaining widget one row up in the table.
Check the functions del_pattern_button_pressed and ins_pattern_button_pressed in gneutronica.c for a concrete example. Just putting this here because I had a hard time googling for examples of deleting and inserting rows from/into a gtktable. Maybe this will help someone else.
I dragged my v-amp-2 into where my computer is, and ran it into the 4-track as well, and can record guitar tracks too. But, I can't play back tracks and record tracks at the same time. If I attempt it, a) the playback is garbled, and b) the recording is garbled. By garbled, I mean very very glitchy. Hmmm. That sucks. Also, the sound quality kind of sucks. The monitor throws out a lot of EMF that the guitar picks up. It's ok, if you stand back a bit, but, even just sitting there doing stuff, the mic input is picking up weird sounds all the time -- low level, but audible if you crank up the volume. And it seems too easy to distort the input too. Headphone-out on the 4-track machine seems ok, but monitoring the mic input on the audigy, I'm pretty sure thre's crappy sound happening there. Not surprising that there's a crappy mic preamp there. Also, could be power cables messing with the signal, it's crowded there at the back of the computer.
Have to say though, with my AW4416 it is much easier to capture good quality recordings, though (provided it worked) the actual mechanics of doing the recording are easier on the computer. Problem is, it doesn't seem to actually work very well.
Noticed that "rushing" an instrument (using negative "drag") doesn't seem to actually work. Notes which get sucked into the previous measure appear at the beginning of that measure, instead of the end. Need to look into that.
Google is now turning up 6600 hits for gneutronica, of course, they are all the same repeat of Freshmeat info, pretty much, though some seem to be mirrors of sourceforge releases (tar.gz files).
Also got an email from somebody who suggested I should announce it at gnomefiles.org, which I did.
Hear gneutronica in action, just a little something I recorded yesterday.
Reading a book about drumming that I got from Half-Price books the other day, there's the notion of dragging or rushing certain instruments to affect feel of a piece. I've started on implementing a feature to accomplish this.
Also added some infrastructure for dealing with different access methods for devices, in case some of the stuff I read about using /dev/sequencer to access soundcard synths/soundfonts is accurate, maybe support for that could be added (which would vastly increase the potential userbase, as everybody has a soundcard, but not anything like everybody has a MIDI synthesizer hooked up to their linux box.) Of course not everybody (not even me) has soundcard synths/soundfonts actually working on linux...
I'm having trouble with sourceforge's CVS servers. At first, it worked OK, though it was a little slow. Now:
[scameron@zuul gneutronica]$ cvs -nq update Zzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzz connect to address 66.35.250.207: Connection timed out Trying krb4 rsh... cvs [update aborted]: received interrupt signal [scameron@zuul gneutronica]$(of course I added the Zzzzz's to indicate lots of waiting) That sucks. I can't do any commits!
Oh, duh, I figured it out. I needed to set CVS_RSH=ssh. Now it works.
Higher on the priorty list than those tow are some other things though. It would be nice to be able to switch drum kits without exiting the program, (or perhaps even mid-song? That would entail talking to multiple MIDI devices at once, something I as of yet have not contemplated.) Creating, editing, and saving of drum kits might be nice to have too, however, this is really more easily done using vi, so I'm torn. Newbies might be more inclined to make drum kits if there is an easy way, and "vi" probably isn't an easy or obvious enough way.
I wish I could get rid of that scheduling delay that happens at the beginning of creating the note schedule. It makes looping not work quite right, there's a little timing glitch there.
Also wish that changes to patterns/arrangement would immediately reflect in the current playback, but they don't. Other than that, and some minor UI design oddities (due to my lack of familiarity with gnome and my inclination to get by with what little I do know -- "I can draw lines? Oh, I can do anything then.") this thing is perfect. Not sure I've ever been this happy with the massive results of so little programming effort, and that's saying a lot since I've been programming computers since 1983 or so.
Some ideas:
. . . ok, implemented the hiding of instruments and the multiple patterns per measure ideas. Ran into some trouble on the copy/paste stuff. I have a drawing area per pattern, so to select multiple patterns, you have to cross several drawing area widgets, which means that you don't get the events to the right widgets, etc. Will have to think about this one some more. May have to rethink how I'm doing the arranger window. Ugh.
Today, I bought an M-audio Midisport 2x2, and got it working without too much difficulty. That adventure is described here.
Another idea about the copy/paste stuff. Maybe on the pattern window I could have a button called "copy from" which turns into a menu and allows you to copy in all the notes from a pattern, with all the patterns listed on the menu. It could superimpose the selected pattern on the current pattern, rather than replacing it, so you could combine several patterns together by several such copy operations. This duplicates to some extent the functionality of the multi-pattern measures already implemented, though this way allows per-pattern tweaking, which is important.
Also had the idea to implement "beatlets," a kind of sub-pattern grouping of notes which could be pasted into patterns at a selected point. My ideas on this aren't too concrete yet.
Also implemented "Save" and "Load" operations using the file-selector widget thingy. "Load" isn't quite working yet though, it seems to work the first time, and things look right the second time, but playback on the second time is screwed up. Some sort of data corruption, pointer wackiness is happening in there somewhere.
Also noticed some initial latency on the first beat, since the entire schedule is computed based on "now" and by the time the computation is done, "now" was "a little while ago." This could be fixed by injecting some lead time into the computations, or, just putting a blank measure at the front of compositions before I get around to automatically injecting the lead time.
Once Save and Load are working, I need to have a way to copy patterns, and then. Once I get that done, it will be far enough along that I could consider it "useful." It's just under 2000 lines, and it could probably reach the "useful" stage and remain under 2000 lines.
However, the whole app goes dead while it's playing, as it's single threaded, and it sits around waiting for timer signals most of the time. How to fix this is a bit of a mystery to me as of yet. As I recall, signals are per-process, and timing based on unix signals in a multi-threaded app are thus problematic. Maybe I could try a multi-process app, using unix domain sockets to send the entire note schedule from the editor process to the player process, and signals from the editor to control the player. Have to think about that some more. Off the top of my head, that seems like it should work, but I vaguely remember thinking about this before and seem to recall that there was some reason it would also be problematic, though it escapes me just now.
So far, the program is still quite small at roughly 1300 lines of code.
Today, put scrollbars on the pattern editor thingy to make dealing with large drumkits possible. Implemented a function to save the current composition, but have not hooked it up to a proper user interface. The file is a text file, human readable. I have not yet implemented the function to read it back in. Right now, on quitting, the current composition is dumped into /tmp/zzz.
Created an arranger window which contains a grid that has patterns on the vertical axis and measures on the horizontal axis. Each column of squares represents a measure. You click the square that lines up with the pattern you want for that measure. Very similar to hydrogen. There is a per-measure tempo setting, but currently no way in the UI to get or set it.
All in all, things are going well on this thing. Here's a pic of the arrangement editor...
As you can see, I've picked out a name for this thing, "Gnu Tattoo."
Also made it so you can now delete notes from patterns.
Now it reads a drum list specification from a file instead of hard coding it in the program. Made the buttons I used for labels for the instruments actually send MIDI Note ON messages so it makes sound now, but this is only temporary, because these buttons should only schedule the sound, rather than sending it directly. But hey, it makes sound! So, what's left? Hmm, well, lots, but here's a brief list of the biggest things.
Also last week, did some (probably a bit naive but working) scheduling code for scheduling MIDI events, though did not actually hook it up to drive midi events. It's really looking like this drum machine project is not all that big! Which is cool, since I had briefly looked at the hydrogen code to see if I could change it to do what I want, and it was quite a lot of code, and not so easy for me to just jump in. This way, I get to learn gnome, MIDI programming, and understand the whole project, which I suspect will turn out to be much much smaller than hydrogen.
As like as not, knowing me, I will never finish it however, as losing interest in these things about 3/4's through has always been a problem for me.
If I can make this work with the Motif, I may look into getting the USB-to-midi converter, so I can drive my BOSS drum machine and Kurzweil keyboard with it as well (now that I have a laptop which I can easily bring into the room where those devices live.) One I was looking at is the Midisport 2x2, for $70 or so at guitar center. I need to make sure it works with linux though. I seem to remember you have to get some proprietary firmware downloaded into it, and this seems a hassle to obtain. Perhaps it is on the CD, inside the windows driver, and they (random internet hackers) have some utility to suck it out of there for linux users? Will have to do some digging. Maybe there is some better usb-to-midi converter.
Verified the midi stuff is still working, which I hadn't done since I upgraded to Fedora Core 3 on my desktop machine. "amidi -l" shows the Motif, as before, the device to use for my C programs to talk to it seems to be /dev/snd/midi1.
Looks like this:
I found a lot of docs on the net, and have had some success. I'm happy to report that the programming interface is vastly improved over what I remember of Motif back in the '90s (different Motif than the Yamaha), which was quite a nightmare. The documentation is a bit spotty, but so far, with just a few hours of fiddling with it, I've managed to do some stuff which, as I recall, would have been much more difficult in Motif. The layout and positioning of widgets, in particular used to be a total nightmare with Motif (the "form" widget used to be horrible), and this layout aspect of UI programming appears to have been vastly improved. So far it's all been pretty simple to do what I've wanted to do, just a matter of details, really.
I noticed in /var/log/acpid, there are some events getting logged, I'm not sure they're synchronous with button presses or what, but I do get button events in there. Also, if I press the power button, it shuts the system down, looks like it's through acpid controlled by configuration files in /etc/acpid.
The sound works, the synaptics mouse pad thing works (though I think there may be a better driver I might want to look for.) Haven't tried to make wireless, network, or the modem work, they may well not work with linux, at least not right out of the box. Well, the wired network probably does.
Ordered an ASUS s5a laptop, supposed to arrive today I think. I'm going to try to put Fedora Core 4 on it (which is the reason I've been burning CDs.)
Also had some trouble with the USB drive. Fedora wanted to keep automounting it. Also, wanted to think it was vfat, when I put an ext2 filesystem on it, and due to the automounting thing, I crashed the FS on it once and the fsck fsck'ed it as vfat and destroyed it. Have to be very careful with this USB drive.
Worked on my genetic algorithm stuff some more. Implemented some forms of mutation, single note mutation (pitch change) dropping notes, adding notes, duplicating sections, transposing sections.
After playing with it for awhile, wrote a script called "bottleneck" which takes a single member of the population and makes a new generation by breeding that one with himself, then with each offspring in turn. to produce a big pile of descendants. What I found was, upon first getting a big pile of random riffs, the vast majority were complete garbage. One or two (out of 30 or 40) might have some sections which weren't too horrible. I would then take one out of the 30 or 40 and create a new set of 30 or 40 from that one with this bottleneck script. Then repeat the process.
After about 10 generations of this (which takes awhile, and a lot of listening to crap) you start to end up with something that is vaguely musical. However, it then becomes a bit difficult to decide which variations are "better" than which. You get a lot of very similar sounding examples (in fact the bottleneck script had to be fitted with a duplicate eliminator) You get many which have some variation which is clearly a defect, and these can be eliminated, but you will find several, 3 or 4, very similar sounding things which are all about equally "good." (How good? Not very.) Progress also becomes much slower. At first, tons of crap is eliminated in the early generations, so it seems progress is quick. But then once only variations of something vaguely tolerable are left, most mutations are "bad," and progress comes nearly to a halt, and the selection process becomes more difficult.
Last night, I worked on some code to try to produce some music by means of an evolutionary algorithm. I made several little programs:
I'll probably put it on sourceforge when it gets a little more mature, and if it turns out to be able to produce anything worth listening to.
Hot damn! I got MIDI working!
The last piece of the puzzle was to select device #10, channel #1 in Rosegarden, ignoring the other 9 devices labelled "Motif" I don't know what those other 9 devices with umpteen channels apiece are, but #10, channel #1 is working. That'll teach me that I need to exhaustively try every device/channel offered. I mean, jeez, you'd think the first device, first channel would be the one that'd work by default, but nope, it's the 10th. Go figure.
Er, hmmm. Now what am I going to do with it? That's a good question. I really don't know what I'm doing when faced with a blank score.
With some help from the alsa-user mailing list I found out a bit more...
It turns out that when I built alsa, I configured it for the emu10k1, (which is what Alsa calls the audigy2value) and I needed to also configure it for the usb-audio:
./configure --with-cards=emu10k1,usb-audio
That way, I got a "snd-usb-audio" module built, which contains both (so far as I know) USB audio driver and the USB midi driver.
Now I can "modprobe snd-usb-audio" and it will load the alsa usb midi driver, and I can forget about the 2.4.29 kernel's native "usb-midi" driver. Once I do that, I also ran this script, "snddevices" that was part of alsa, and it creates a bunch of device files in /dev/snd.
[root@localhost scameron]# ls /dev/snd controlC0 hwC2D3 midiC1D2 midiC3D1 pcmC0D4c pcmC1D3p pcmC2D3c pcmC3D2p controlC1 hwC3D0 midiC1D3 midiC3D2 pcmC0D4p pcmC1D4c pcmC2D3p pcmC3D3c controlC2 hwC3D1 midiC1D4 midiC3D3 pcmC0D5c pcmC1D4p pcmC2D4c pcmC3D3p controlC3 hwC3D2 midiC1D5 midiC3D4 pcmC0D5p pcmC1D5c pcmC2D4p pcmC3D4c hwC0D0 hwC3D3 midiC1D6 midiC3D5 pcmC0D6c pcmC1D5p pcmC2D5c pcmC3D4p hwC0D1 midiC0D0 midiC1D7 midiC3D6 pcmC0D6p pcmC1D6c pcmC2D5p pcmC3D5c hwC0D2 midiC0D1 midiC2D0 midiC3D7 pcmC0D7c pcmC1D6p pcmC2D6c pcmC3D5p hwC0D3 midiC0D2 midiC2D1 pcmC0D0c pcmC0D7p pcmC1D7c pcmC2D6p pcmC3D6c hwC1D0 midiC0D3 midiC2D2 pcmC0D0p pcmC1D0c pcmC1D7p pcmC2D7c pcmC3D6p hwC1D1 midiC0D4 midiC2D3 pcmC0D1c pcmC1D0p pcmC2D0c pcmC2D7p pcmC3D7c hwC1D2 midiC0D5 midiC2D4 pcmC0D1p pcmC1D1c pcmC2D0p pcmC3D0c pcmC3D7p hwC1D3 midiC0D6 midiC2D5 pcmC0D2c pcmC1D1p pcmC2D1c pcmC3D0p seq hwC2D0 midiC0D7 midiC2D6 pcmC0D2p pcmC1D2c pcmC2D1p pcmC3D1c timer hwC2D1 midiC1D0 midiC2D7 pcmC0D3c pcmC1D2p pcmC2D2c pcmC3D1p hwC2D2 midiC1D1 midiC3D0 pcmC0D3p pcmC1D3c pcmC2D2p pcmC3D2c
If I run my little test program against "/dev/snd/midiC1D0" it will produce sound.
Also, there is a program "amidi" that I can run
[root@localhost]# amidi -l Device Name hw:0,0 Audigy MPU-401 (UART) hw:0,1 Audigy MPU-401 #2 hw:0,2 Emu10k1 Synth MIDI (16 subdevices) hw:0,3 Emu10k1 Synth MIDI (16 subdevices) hw:1,0,0 MOTIF-R MIDI 1 hw:1,0,1 MOTIF-R MIDI 2 hw:1,0,2 MOTIF-R MIDI 3 hw:1,0,3 MOTIF-R MIDI 4 hw:1,0,4 MOTIF-R MIDI 5 hw:1,0,5 MOTIF-R MIDI 6 hw:1,0,6 MOTIF-R MIDI 7 hw:1,0,7 MOTIF-R MIDI 8
So the alsa usb driver is seeing the Motif now. Also I can "see" the Motif in Rosegarden, and select it, but when I play, I get no sound. However, I do see a little blinky light flashing on the Motif indicating it is receiving something as Rosegarden plays each note. When I press the "audition" button on the Motif I can hear, and as noted, my C program produces sound.
Progress, but still not quite there.
AHA!!! I have got a peep out of the Motif!!!! Yay!!!!
But, true to form, it is harder than you would believe.
I had to use this C program which sends a MIDI note-on message. So, I have got exactly one peep out of the Motif -- A middle C!
And there was a bit I had to twiddle on the front panel of the Motif to tell it to take MIDI in/out via the USB port instead of the usual MIDI sockets.
Baby steps. At least I know the hardware chain is working.
Rosegarden insists that I have software synths (the Audigy2, however all it's software synths have blank soundfonts) and two external MIDI channels (audigy UARTs (seial ports)) but this audigy card doesn't actually take the serial ports out, they are orphaned on the board, so far as I know, and rosegarden doesn't seem to see the USB MIDI ports at all.
I noticed that the usbmidi driver with alsa is not the same as the usbmidi that's part of the 2.4.29 kernel. I think it's the one with the 2.4.29 kernel that I'm able to get the middle C to come out.
Trying the midi stuff again. Today, went around looking for a cable to connect my audigy2 to a MIDI device... I thought I had remembered the card had a game port that could, with the right cable and software, drive a midi device. Well nobody had such a cable anywhere I tried to look, which was a good thing because the Audigy2 doesn't ahve any such game port, or any way at all to drive a MIDI device.
Well, when I realized that, it occurred to me that there's no reason there couldn't be such a thing as a USB-MIDI converter. So I started digging around on the internet, and found that yes, there are such things. So, then I started digging around in Linux to see if such devices had support, and I see there is a usb-midi driver, and it claims to support several of these things, though some of them need to have firmware downloaded into them in order to work -- something which a windows driver normally does. Well, I start digging around to see what devices are supported and notice that some are not USB-MIDI converters, but keyboards and such, and I see that it says it supports "yamaha devices" without being specific about which ones.
It occurs to me to look at the back of my motif rack. Well I'll be damned, it has a USB port! All I need is a USB cable? Can't be that easy.
And, of course it isn't that easy. But progress. I recompile the kernel with this usb-midi driver enabled, and now I see in the log messages:
hub.c: new USB device 00:10.0-1.1, assigned address 4 usb.c: USB device 4 (vend/prod 0x499/0x1015) is not claimed by any active driver. usb.c: registered new driver midi usb-midi: Found YAMAHA USB-MIDI device on dev 0499:1015, iface 0 usb-midi: Found MIDIStreaming device corresponding to Release 1.00 of spec. usb-midi: Found IN Jack 0x01 EXTERNAL usb-midi: Found OUT Jack 0x01 EXTERNAL, 1 pins usb-midi: Found OUT Jack 0x02 EXTERNAL, 1 pins usb-midi: Found OUT Jack 0x03 EXTERNAL, 1 pins usb-midi: Found OUT Jack 0x04 EXTERNAL, 1 pins usb-midi: Found OUT Jack 0x05 EXTERNAL, 1 pins usb-midi: Found OUT Jack 0x06 EXTERNAL, 1 pins usb-midi: Found OUT Jack 0x07 EXTERNAL, 1 pins usb-midi: Found OUT Jack 0x08 EXTERNAL, 1 pins string descriptor 0 found (length = 4) usb-midi: langid(0) 0x0409 usb-midi: langid(match) 0x0409 usb-midi: fetchString(2) usb-midi: fetchString = 14 usbmidi: found [ YAMAHA MOTIF-R ] (0x0499:0x1015), attached: usbmidi: /dev/midi01: in (ep:82 cid: 0 bufsiz: 0) out (ep:01 cid: 0 bufsiz:64)
Well looky there! It sees my Motif!!!! Cool!
Crank up rosegarden and see if it will see it. Hmm, no it doesn't. Looking in the alsa stuff, I see there is some kind of snd-usbmidi, and I'm just using the kernel's usbmidi driver. Maybe I need to use the alsa one? Not sure. Haven't been able to get a peep out of the Motif yet, but at least my linux sees it.
Downloaded a 2.4 29 kernel from kernel.org, plus the low latency patch for that kernel from Andrew Morton (google for it) plus a tiny CAPABILITY related patch (PM me if you want details.) and recompiled alsa emu10k1 driver for that kernel, and now I'm once again able to record Hydrogen drums thru JACK to ardour, glitch-free. It seems to be mandatory that JACK be started in real-time mode.
Well, more trouble. I decided to punt on the MIDI stuff for now, since I don't have a MIDI cable and don't want to drag my Motif in here and since I can't figure out how to load soundfonts into the Audigy2 either, and besides, I'm not sure what I would do with MIDI anyhow. I don't really know my way around a MIDI sequencer anyway.
So, went back to working on my Danzig-esque drum track (well, that's what I meant for it to be but it came out rather lamer than that.) I fired up ardour and connect hydrogen to it and start recording, and I'm getting all these glitches. I'm using redhat's 2.4.18-14 kernel (from redhat 8.0) on account of I didn't have the source for the CCRMA kernel I had been running, and being on dialup, didn't want to download it. I had tried to apply the low-latency patch for the kernel.org 2.4.18 kernel to my redhat kernel, but it started off right away saying that files appeared to already be patched, so I kind of thought, well, maybe redhat already incorporated it (they do that lots of times, grab patches ahead of kernel.org, or at least they used to. I think they're getting more conservative lately though.) Well, it seems the full fledged low-latency stuff must not be there because I was getting all kinds of glitches just trying to record the stereo drum tracks from hydrogen.
Sooo. Looks like I'm going to have to spend some time grabbing the latest CCRMA kernel, I guess. Unless I can find a low latency patch for redhat's 2.4.18-14 kernel somewhere.
> Third, at boot run: /usr/bin/sfxload /path/to/8MBGMSFX.SF2
There are some sound font files on the media, but not that one. In any case, this does not appear to work, it tries to open /dev/sequencer which is not attached to any device. Hmmm. :-/
So, last night I bought an Audigy2 sound card, as my (somewhat) new computer had a crappy-to-the-point-of-uselessness soundcard.
Took me awhile to figure out how to get it working. I ended up using the alsa emu10k1 driver after a false start with an emu10k1 driver I found on sourceforge. Had to patch and recompile my kernel a couple of times before I got Jack working again. So now I have hydrogen (my drum machine) working again (yay!) Was trying to make a Danzig-esque drum track, but I don't really know what I'm doing so it was coming out pretty lame.
This sound card has spdif input, so maybe I can use that with my aw4416 (though I may have to get an i/o card for my aw4416, I can't recall if it has spdif output builtin) That would be much nicer than what I've been doing. However, my AW4416 is located nowhere near my computer, so this may be impractical.
Also, I was playing around with rosegarden, a midi sequencer for linux. I can make it create midi files, then use timidity to play those files, but I haven't been able to get the audigy2 to act as a midi device and play sounds from within rosegarden... I wonder if this is supposed to work?
hmm, I just found this:
> After spending many hours trying to get native midi playback to work on > this card, I came across the solution, which I sure couldn't find > documented anywhere. Apparantly, this card does not include any > soundfonts in ROM, so in order for midi playback to work, one has to be > loaded in. > > Fortunately, the solution is very easy. > > First, get awesfx from [mitglied.lycos.de] > Second, get 8MBGMSFX.SF2 from the card install CD or a windows install. > Third, at boot run: /usr/bin/sfxload /path/to/8MBGMSFX.SF2
I will have to try that.
I suppose my next task will be to try to connect the audigy2 to my yamaha Motif rack, and see if I can make sound that way.