Linux MIDI/Audio Notes

Back to my main page

View older notes

Tue, Jan 15, 2008

Not exactly audio related, but not sure where to put this. If you're looking for qlogic or emulex fibre channel libraries for HP storage SNMP agents (the hpasm package) on vmware, (the libraries are named libqlsdm.so, for qlogic, and libemsdm.so and libdfc.so for emulex) here's where to go. The library versions must be matched with the driver versions -- not the version numbers per se, just that certain library versions go with certain driver versions, and mismatches cause mysterious things to happen -- agents don't see your storage boxes, or maybe crash. But it is very hard to tell just by looking at the .so files what version you have. It's best to get the libraries with the drivers. Anyway, here's where I'm told you're supposed to get the correct libraries:

On other linuxes (redhat, SuSE) the libraries are bundled with the driver kits, so it's not usually such a problem to find the right libraries.

The problem is exacerbated a bit by the fact that hpasm contained versions of these libraries for vmware, as vmware didn't natively have these libraries. This caused problems in these were apt to be the wrong versions.

The hpasm provided versions of these libraries will reside in /opt/compaq/storage/bin, if they are present.

Thur, Sep 6, 2007 Finally figured out why my Roland DR-880 was having such problems receiving MIDI data. If you set the MIDI channel to 10, it's really 9 1-16 is mapped to 0-15. So, in gneutronica, set the channel to 9, on the roland, to 10. Also, on the roland press EDIT, then choose MIDI, then for sync, choose MIDI. BTW, this disables the front keypad of the roland for the most part, and it's saved in flash. To use the keypad again, you have to change it back to internal sync, or what have you. Really weird. DR-660 didn't act that way.

Anyway, it does work, finally got off my lazy ass and figured out what I was previously doing wrong.

Mon, May 7, 2007

Put my game up on sourceforge: Word War vi.

Sun, May 6, 2007 Got sound working awesomely in my silly '80s style retro Defender/Scramble type arcade agame. I say again, it's working awesome!

Awesome.

Here's the code: audio_engine.c

It uses portaudio and libsndfile. It's actually pretty simple. The hardest part is the idea of updating data structures in a multi threaded way. I simplified it down to updating one int to trigger sound playback, but, evne then, I want to be able to do memory barriers from userspace, which I haven't figured out how to do.

Despite this, the code seems to work ok. Sound plays back when it's supposed to, and it doesn't seem to crash to do weird things... So, eh, maybe, on uniprocessoor x86, the code is alright.

Sat, May 5, 2007 Just saw an ad on TV for Yahoo Answers, and it reminded me of this experience, so here goes:

Yahoo Answers sucks. No, it FUCKING sucks.

You ask a question, you are prohibited from "answering your own question" (which is weird, since there's a pretty good chance someone might come across an answer elsewhere if that person has gone to the trouble to post on yahoo answers, but, if they do find the answer? They can't post it. That is fucking retarded. You're fucking retarded yahoo.

Secondly, you can't even comment on the "answers" which are provided. For my question, (How to send patch files intact via yahoo mail) I was given a bogus answer which did not work. I couldn't say that the answer didn't work, I couldn't do anything. Then, the person that provided the answer "rated" their answer as being "best." and then discussion was closed. What the FUCK?!?!

Yahoo answers is clown answers.

Yahoo answers is a dishonest, fraudulent piece of shit with no ethics, or, evil ethics.

FUCK YOU yahoo answers. Fuck you.

Thu, May 3, 2007

Last couple of weeks, been working on an old-school shootin' game, kind of like Defender, kind of like Scramble. It's turning out alright, better than I hoped, though, really, not all that great. Well, I never did like playing games, but programming them is fun. Been thiking about adding sound to it. Found the portaudio library, which seems to be able to do what I need, supposing I have the audio data in an array somehow (sndfile library is for that, I think.)

I was able to hack up one of the test programs as a proof of concept to be able to mix sixteen channels of sound, and begin a new sound at will. Here's that code: example C program code mixing sixteen sound clips, each started at arbitrary times, using portaudio.

Sat, Feb 24, 2007 (Really gotta work on that "swing" feature for gneutronica sometime...)

Tried to hook up gneutronica to my Roland DR880. Using just the USB cable, no MIDI devices showed up. Guess I'm not too surprised. Using the Midisport, of course I can see MIDI devices (the midisport itself). Tried to send to the DR880 to drums on channel 10, but didn't seem to work. (I could see that I was sending to the midisport, via the lights on it.) Not sure what's wrong there.

Tried to use multimidicast, which I've used before, so I could work on the big computer, and drive the MIDI crap via the laptop, but, it complained of "no /dev/snd/seq" on the big computer. I am running, I think, 2.6.18 or maybe 2.6.20, can't recall, but my config should be alright (that is, derived from older, working .config). Maybe I forgot to modprobe some module?

Really bothers me that the DR880 doesn't receive MIDI. Wonder what I'm doing wrong?

Thurs, Dec 7, 2006 You know how you come to some websites, and they say, "Best Viewed with Internet exploer", or "This page uses ASP, etc."

Recently I found myself at such a site, and I went to close the tab, right click, "Close Tab"... but it wasn't satisfying. It was like that bit Jerry Seinfeld did ages ago about the new phones with the tiny button to hang up vs. slamming the receiver down. Firefox needs a way to slam the receiver down. "Close Tab" doesn't cut it. I want a "Close tab and fuck you to death with a red hot poker" selection.

Wed, Dec 6, 2006 To record tracks from the AW4416 to the PC, use Jack and ecasound. However, I'm still having a bit of trouble, as the recorded audio has glitches and dropouts. I'm thinking this is a linux issue though it may be cable problems, hard to say.

Anyway, this appears to almost work:

  • On the AW4416, on the PAN/ROUTE screen, select the MONItor tab, and make sure the recorder channels you're interested are routed to a bus, 1-8. That's because on the setup/patch out screen, the busses are routed to the ADAT outputs, so to get the recorder channels to the ADAT outs, you can route them to the busses.
  • start ecasound, as for example: 
    ecasound -c -r -b:128 -a:1,2 -i jack -o drums.wav -a:3,4 -i jack -o guitar.wav
  • Type "engine-launch" in ecasound.
  • In qjackctl, on the connections screen, connect the hammerfall's capture channels (corresponding to AW4416 busses) to ecasound's inputs.
  • Type "start" in ecasound, and start playback on the AW4416.
    Mon, Dec 4, 2006, later that night...
    It works!!!!!

    To send audio from the computer to the AW4416, do the following:

  • Start Jack, via qjackctl (make sure LD_LIBRARY_PATH includes /usr/local/lib)
  • In qjackctl, enter the setup menu, and select the Hammerfall, and stop and start JACK.
  • Start ecasound, like: 
    ecasound -c -b:1024 -i:planet-zoing-zoing-banjomix.wav -o:jack
  • In ecasound, enter "engine-launch"
  • In qjackctl, connect the ecasound outputs to the playback channels 1-8, which correspond to inputs 9-16 on the AW4416.
  • type "start" in ecasound.
  • To restart, type "setpos 0", and "start" in ecasound.
    Mon, Dec 4, 2006 Matthias Carstens from RME wrote me back to tell me, based on the symptoms (garbled sound with 48dB loss in volue) that I was using the Mac EPROM and I need the Windows EPROM. D'oh! I should have contacted RME a long time ago, I guess. I hope I haven't misplaced the proper EPROM chip in the meantime.
    Fri, Dec 1, 2006

    Dean Brown, who I met via the AW4416 mailing list and who lives not far at all from me, helped me try out my RME Hammerfall Lite board in his Windows PC, in which he has a working RME Hammerfall HDSP board. The driver would load, but, none of the applications, including the test application from RME could seem to see my board. So, it seems my board really is broken. Hmmm.

    Dean gave me some contacts at RME. Maybe something can yet be made to work. In any case, I think I've proven to myself at least that the problem isn't (only) with linux, the board itself seems to have some problems, or at least, it doesn't work with Windows either.

    Many thanks owed to Dean Brown for graciously answering my request for help.

    Sun Nov 12, 2006 Dave Phillips wrote about Gneutronica on LinuxJournal.com.

    Got some bug reports and feature requests from people that I'll need to work on. "Swing" and "humanize" features requested, and also some sort of config file for default settings, e.g.: whether automag is turned off, maybe default settings for visible instruments in a drum kit, default height of non-automag instruments, etc. Apparently rushing some instruments makes them disappear? New one on me, but I don't really use rushing... I'm aware of other bugs... I think if a note gets pushed to the previous or next measure, weird things happen. Also, if you start it up, make a bunch of patterns, then switch to the arranger, the patterns don't immediately show up. You have to go back to the pattern editor, click backwards for forwards arrow, then switch back to the arranger. Not sure what's going on there, probably some problem with the "expose" callback in the arranger or something.

    Tue, July 18, 2006 Been studying the Motif Data List Manual. It is very opaque to someone who doesn't already know how it all works. However, I think I am slowly sort of getting the hang of it... however, I haven't written any programs to verify what I imagine myself to be getting the hang of, so I could be completely confused and not realize it.

    Anyway, I think you cannot, by using of Bank Select MSB/LSB plus Program Change (0xB0, 0xC0) commands assing channels to instruments.

    Perversely, I think you must construct a "Multi", and store this in the Motif. There's a big data structure, each byte of which is set via a "Parameter Change" command, which is some kind of "system exclusive" message. If my understanding is right, it's not that difficult, just tedious. I still don't know how to store the information permanently in the Motif, but I might have some idea how to "blast" the data down to the motif... I am thinking of writing some kind of Motif Multi/Voice editor for linux. There is already a project on sourceforge that seems to fit this purpose, but it seems not to have gotten past the planning stage. There is nothing there. So, for fuck's sake, just to get a freakin' patch that's got drums on one channel and bass on another channel, without dinking with the stupid front panel, it appears I will have to write a fairly hefty app to be able to create MULTI's on the motif. I really wish the documentation were a bit better.

    Sun, July 16, 2006 Figured out how to do bank / patch changes on the Motif. Somebody from motifator.com helped me find the piece of the puzzle I was missing, which was that you can't combine the selection of MSB and LSB into a single command, you need to send two commands to select them individually.

    Here's the meat of the answer: Quote:

    Thus if you wanted, for example, to set track 6 to Preset Bank 4, 
Voice 10 you would send the following commands:

B5 00 3F - Bank MSB for track 6 = 3FH (63 decimal)
B5 20 03 - Bank LSB for track 6 = 03H (3 decimal)
C5 09    - Program number for track 6 = 09H (9 decimal - one less 
           than voice 10 which you are selecting)
    And, see p. 46 of the Motif Rack Data List manual (PDF). David's MIDI spec also seems to be pretty good.
    Tues, July 11, 2006 (not really audio related): I often have a load of shell (gnome-terminal) windows up, usually zoomed to full screen which I switch between using Alt-Tab. Sometimes I get lost and can't remember which window is which. So sometime back, I create a bunch of profiles for terminals which had different background colors. They're all nearly white, so that all that coloring that vi does still works ok, they're just slightly tinted. Well, that still requires me to select a profile, which I often don't bother to do until AFTER I've gotten confused about which window is which. So I made a little script that launches gnome-terminals, cycling through colors as I go, and attached it to the panel. Each time I click on the icon for gnome-terminal it makes a new one with a different color. Here's that script: 
    [scameron@quandary ~]$ cat start_gt
#!/bin/sh

PROFILELIST=$HOME/lastprofile.txt

if [ ! -f $PROFILELIST ]
then
        echo orange > $PROFILELIST
fi

lastprofile=`cat $PROFILELIST`

make_next_profile()
{
        awk '
                BEGIN { found=0 }
                /'"$1"'/ { found=1 ; next }
                { if (found == 1) print;
                  if (found != 0)
                        found++;
                  if (found == 3)
                        exit;
                }' << EOF
red
orange
green
blue
gray
white
yellow
red

EOF
}


nextcolor=`make_next_profile $lastprofile`
echo $nextcolor > $PROFILELIST

gnome-terminal --window-with-profile=$nextcolor &

[scameron@quandary ~]$
    It assumes you have gnome terminal profiles named red orange green blue gray white yellow red. Notice red is listed twice, that makes it loop around to the beginning in the sequence.
    Thurs, July 6, 2006

    All these from gtk.org:

    Reconfigured om... noticed it complained about lash not being found...

    Reconfigured om-, and recompiled and installed. Still complains about the glade stuff...

    July 5, 2006

    For the record, the 2.6.16.11 kernel that has working USB has proc/interrupts like this: 

    [scameron@zuul ~]$ cat /proc/interrupts
           CPU0
  0:    3930701          XT-PIC  timer
  1:      10088          XT-PIC  i8042
  2:          0          XT-PIC  cascade
  3:          2          XT-PIC  ohci1394
  4:     878732          XT-PIC  serial
  7:          2          XT-PIC  parport0
  9:        128          XT-PIC  acpi
 10:          0          XT-PIC  uhci_hcd:usb2, uhci_hcd:usb3
 11:        299          XT-PIC  EMU10K1, rme9652, ehci_hcd:usb1, uhci_hcd:usb4, uhci_hcd:usb5
 12:     262004          XT-PIC  i8042
 14:      73214          XT-PIC  ide0
 15:         67          XT-PIC  ide1
NMI:          0
ERR:          0
[scameron@zuul ~]$ uname -r
2.6.16.11
[scameron@zuul ~]$

    Set out to install Smack, a percussion soft synth. It has quite a dependency list...

    Tried to start om_gtk... First it complained about not being able to find libgnomecanvasmm.2.6.so.1, so, try 

    ln -s libgnomecanvasmm-2.6.so.1.0.1 libgnomecanvasmm-2.6.so.1
    Now, it complains... 
    [scameron@zuul ~]$ om_gtk
[StateManager] Unable to open settings file /home/scameron/.omgtkrc
(om_gtk:2173): libglade-WARNING **: unknown property `focus_on_map' for class `gtkmm__GtkWindow'
(om_gtk:2173): libglade-WARNING **: unknown property `ellipsize' for class `gtkmm__GtkLabel'
(om_gtk:2173): libglade-WARNING **: unknown property `width_chars' for class `gtkmm__GtkLabel'
(om_gtk:2173): libglade-WARNING **: unknown property `single_line_mode' for class `gtkmm__GtkLabel'
(om_gtk:2173): libglade-WARNING **: unknown property `angle' for class `gtkmm__GtkLabel'
(om_gtk:2173): libglade-WARNING **: unknown property `ellipsize' for class `gtkmm__GtkLabel'
    And finally, it dies with a bunch of crap like this: 
    ** (om_gtk:2173): CRITICAL **: Gnome::Glade::Xml::get_widget(): dynamic_cast<> failed.

    Hmm, seems like my libgnomecanvasmm, or libglade is crap. I really hate C++, and this bleeding edge gnome crap.

    July 1, 2006 Worked on Gneutronica a bit. Added a track/channel mute control matrix thingy, the idea being that you might compose a drum track and some melody parts all executed on the same piece of MIDI hardware, but might like to record them as separate tracks for later mixing, or, e.g. replacing a MIDI bass part with a real bass part, etc. So you can just mute various channels of various tracks leaving whatever it is you want to record as the only thing going.

    Added ability to transpose melodic parts.

    Fixed a bug in the scramble function (wasn't mindful of note-off events).

    I seem to have introduced and found a few bugs too though. It seems the pattern name field no longer captures certain keystrokes (e.g. 'C', 'P', "X', etc, which are my hotkeys. I had a way around that, but my way around must have gotten broken -- maybe when I added the notebook thing.

    The height of melody notes doesn't match the mouse, somehow. Maybe broke that when I changed the width of the piano notes.

    ...

    On the more general linux/audio front, I dowloaded 2.6.17.3 kernel and Ingo's 2.6.17-rt5 patch, and applied it and run. Xruns in jack are much fewer than they were, but not completely absent. I haven't done anything about priorities, etc. Also with the 2.6.17.3 kernel, it seems to build the AC97 driver even though I tell it not to in the config, and so my crappy via sound card is showing up. I haven't built the out-of-tree ALSA drivers for 2.6.17.3. The USB stuff didn't work with 2.6.17.3, even before Ingo's patch. I think it broke sometime between 2.6.16.11 (working) and 2.6.16.20 (broken). Somebody says it's something to do with my interrupt routing. I'm not sure. I have the same hardware with 2.6.16.11 as I do with 2.6.16.20, and the same .config file.

    Jun 28, 2006Finally got off my ass and hauled my aw4416 into where my computer is to try out some shorter ADAT cables. Tried 17 foot cables -- same results, crap. Tried 1.5 meter cables, same results, crap. Also tried moving the MY8AT board from slot 2 in the AW to slot 1, just to see if that made a diff. Nope. I am starting to think the RME board may be bad.
    Jun 25, 2006 Made a new release of Gneutronica. Now it uses the ALSA sequencer interface, and includes a melodic sequencer as well as the percussion sequencer. It can send on multiple ALSA sequencer ports (to multiple MIDI devices) and on multiple MIDI channels.

    On the ADAT front...

    It seems the 50 foot ADAT cables do not work. I can transmit from the PC to the AW, however, at a huge loss in signal level and integrity. The signal arrives at the AW with about a 40dB loss (means, almost silent), and all chopped up and crappy.

    I cannot transmit from the AW to the PC at all.

    I got some 17 foot ADAT cables, we'll see how those do.

    Some technical details about how to try to use the ADAT/RME stuff.

    In qjackctl, in the setup thingy, some points to remember:

    Set sample rate to 44100 Hz. Set channels to zero. (Zero means "use however many channels the card has", but this is not obvious)

    To get ecasound to send to the RME, invoke it like this: 

     ecasound -c -i:FreedomPlea_alex_mix.mp3 -o:jack
    (Argh... I'm not completely sure about that, I tried so many different things... the "-c" means interactive mode. Then, type in "engine-launch" at the ecasound prompt. Now, you can see it in the connection window of qjackctl. Connect it up to whatever you want to connect to. Then type "start" to start playing. (or use the qjackctl jack transport controls.)

    On the AW side, I monitored on the "Home/input 1-24/rtn" screen. Could barely see stuff coming in on channels 2/3 at between -30 and -48dB. Listening, it was horribly mangled as well as being nearly silent.

    I learned that for ADAT the clock sync is only needed on two of the 8 channels (it serves for all, I guess.) I seemed to get better sync on 1/2 than the other channels, judging by the way the AW complained, but I'm not sure that's a good way to judge. In any case, it didn't work worth a damn.

    Went to guitar center yesterday (for new, shorter ADAT cables) and was playing around with a Roland DR-880 drum machine. It's pretty cool, the drum patterns in it put anything I can do to shame, and it's got cool basslines and little songs in there too. Kind of expensive at around $500 though. Almost bought it, but the only one they had was the demo model, with no manuals. Gave me a discount to $375... but I wasn't biting.

    Jun 20, 2006

    Ran qjackctl as root. 

    --------------
On the setup/Settings page:

Checked: Realime/hw monitor/hw meter.
Left other messages alone.

Priority: 0
Prames/period: 1024 (a guess)
sample rate:22050 (default...)
Periods/Buffer: 2
Port Max: 128
Timeout: 500ms
Interface: hw:1
Dither: none
Audio:duplex
Input device:(default)
output device:(default)
input channels: 0
output channels: 0
input latency: 0
output latency: 0
Latency: 92.9 msec
-----------

    The "input channels: 0" and "output channels: 0" seem suspicious. If I try to change them Jack won't start and says: "ALSA: cannot set channel count to 1 for capture" If I leave them zero, jack will start (but I don't know if that's right.)

    On the AW4416:

    On the Setup/Patch In page, it looks like SL2-1 through SL2-8 are mapped to mixer input channels 17-24. For the mixer 1-24/rtn-1-2, I pushed the faders up. On the "Home" screen, 1-24/rtn, I can monitor the inputs.

    I ran ecasound like so: 

    ecasound -c -b:1024 -i:planet-zoing-zoing-banjomix.wav -o:jack

    Then "start"

    Then in qjackctl, I can see ecasound in the "capture" column, and I routed it to every single output (all 18 of them -- presumably 2 s/pdif outs + 16 ADAT outs.) So I am seeing the hammerfall having 18 ports, which is encouraging

    I got nothing on the AW4416 where I would expect the sound from the wav file to show up on all 8 ADAT inputs.

    That's where things stand right now.

    June 19, 2006,

    I got my 50 ft ADAT lightpipe cables from Audiomidi today. Hooked them up between my hammerfall and the AW4416, and fired up both of them. On the AW4416 setup page... the ADAT interface showed X's on all 4 stereo pairs... switched the cables around on the computer side, and the X's disappeared.

    I (with such foresight) hat put duct tape on both ends of one of the two cables. So now, I can record that setup which I think is physically correct.

    On the computer side. As viewed from the rear, The non-duct taped cable is in the rightmost ADAT port, the one closest to the DIN connector. The duct taped cable is in the ADAT port next to that. The remaining ADAT ports on the hammerfall are covered by lens caps (dust plugs?).

    On the AW side, the duct-taped cable is in the rightmost port as viewed from the FRONT of the AW. It is the one labeled "IN". So the duct-taped cable goes FROM the computer TO the AW, presumably. The non-duct taped cable is plugged into the leftmost port (again, as viewed from the front of the AW), the one labeled "OUT," so presumably the non-duct taped cable is for traffic FROM the aw TO the computer.

    arecord -l has the same output whether the cables are plugged in correctly or incorrectly.

    Speaking of plugging... The tips of the ADAT cables look roughly like this: 

                  -----------
              |         |
             <    /-\    >
              |   \-/   |
               \_______/

    Notice the top is slightly wider than the bottom. On the computer, the wide flat side seems to go to the LEFT, (when facing the rear of the computer.) On the AW, the wide flat side faces up.

    June 18, 2006 Got the ALSA sequencer stuff working. Began working to make gneutronica do other instruments besides percussion.
    June 16, 2006 Worked on Gneutronica... fixed a bug that a new measure inserted at the beginning of a song got a bogus tempo. Abstracted out a MIDI interface, and implemented a raw midi variant of that abstraction and began working on an ALSA variant of that abstraction. I think I'm very close to having the ALSA one working too, but I'm missing some piece.

    A couple of intersting links:

  • a very simple C code example from Rosegarden test cases using the ALSA sequencer interface.
  • Another pretty simple C code example of using the ALSA sequencer interface from Matthias Nagorni's miniArp.c

    You'd think, using those, I could make mine work... Probably just need to keep banging my head.

    Jun 13, 2006 Figured out why xmms was dying with glibc detecting "double free or corruption:" It's because of a bug in the flac lib. Not wanting to waste time getting a new flac (I haven't at the moment got a need for FLAC) I straced xmms and found where it was loading the lib (from /usr/lib/xmms/Input/libxmms-flac.*) moved those files out of there and now xmms runs again.
    Jun 11, 2006 Was fishing around in proc, and noticed had about 0.5Gb of ram, when it occurred to me that my old, dead computer, sitting over in the corner, probably contained a DIMM. Bingo! Another 0.5Gb. Snapped it in, and now I've got 1Gb of RAM. Audacity and ecasound seem to work a little better now, still not perfect.
    Jun 10, 2006 Playing around with ecasound... it's not working so well, the multitrack recording thing seems kind of jittery and glitchy. Probably due to my kernel. I wrote a script to make some of the stuff described in Jesse S.A. Bridgewater's ecasound examples a little easier... Here is that script

    Downloaded 2.6.16.20 kernel, and recompiled alsa drivers for that. Didn't seem to help much with the glitchiness... wonder what you have to do to get a kernel that's good for audio? (Besides download one someone else has already tweaked?)

    Jun 8, 2006

    Got my MY8AT (ADAT lightpipe interface) today for my AW4416. Installation was a snap. Still don't have the cables I need, should be in in a few days, I guess.

    Installed gobs of software today, in a quest to install ardour from source.

    Check the the DOCUMENTATION/BUILD file in the ardour source tree to find where to get most of these.

    Well, actually ardour doesn't build yet: 

    [scameron@zuul ardour-0.99.3]$ PKG_CONFIG_PATH=/usr/local/lib/pkgconfig
[scameron@zuul ardour-0.99.3]$ export PKG_CONFIG_PATH
[scameron@zuul ardour-0.99.3]$ scons
scons: Reading SConscript files ...
Checking for C header file alsa/asoundlib.h... no
Checking for C header file /System/Library/Frameworks/CoreMIDI.framework/Headers/CoreMIDI.h... no
system triple: i686-pc-linux-gnu

*******************************
detected DIST_TARGET = i686
*******************************

Checking for internationalization support ...
Checking for C header file libintl.h... no
Checking for C header file /System/Library/Frameworks/CoreAudio.framework/Versions/A/Headers/CoreAudio.h... no
Checking for C function posix_memalign()... no
Did not find posix_memalign(), using malloc
Checking for C function getmntent()... no
KeyError: 'SYSMIDI':
  File "SConstruct", line 727:
    SConscript (subdir + '/SConscript')
  File "/usr/lib/scons-0.96.92/SCons/Script/SConscript.py", line 557:
    return apply(method, args, kw)
  File "/usr/lib/scons-0.96.92/SCons/Script/SConscript.py", line 494:
    return apply(_SConscript, [self.fs,] + files, {'exports' : exports})
  File "/usr/lib/scons-0.96.92/SCons/Script/SConscript.py", line 226:
    exec _file_ in call_stack[-1].globals
  File "libs/midi++/SConscript", line 35:
    if env['SYSMIDI'] == 'CoreMIDI':
  File "/usr/lib/scons-0.96.92/SCons/Environment.py", line 295:
    return self._dict[key]
[scameron@zuul ardour-0.99.3]$

    Hmm, after a reboot, xmms quits, d'oh! 

    [scameron@zuul ~]$ xmms
*** glibc detected *** double free or corruption: 0xb74787e4 ***
Aborted
    pplayer will play sound through the emu101k, but it seems like it's 44.1khz samples being played as though someone thought they were 48khz samples -- everything's very slightly slowed down, I think.

    How to fix the fake "glare" on qjackctl. Qjackctl has this really annoying fake glare on the fake LED display. To get rid of it, go into the source directory for qjackctl, there is an icons directory, and a file called "displaybg1.png" Bring that up in the gimp, and right click, select Layers->Colors->Brightness/Contrast < Turn the brightness all the way down, turn the contrast all the way up. This will turn it into a nice "glare"-free black rectangle. Save it and re-build qjackctl. Why somebody would want to emulate glare for an audio program is beyond me. It doesn't look "cool," it's just emulates something that's really annoying in real life. Edit: Much later, I find there's a checkbox that will turn this feature off, LOL. Why it's not off by default, I don't know.

    Worryingly, qjackctl/jack does not appear to see the RME Hammerfall. Amixer makes some mention of it.

    Jun 3, 2006 Went ahead and ordered two 50 foot ADAT lightpipe cables from audioMIDI.com. About a hundred bucks.

    Guess I need to get JACK and Ardour running, because I think Ardour is the only thing that understands how to really use a multi-channel sound card like the Hammerfall. Well, I think Audacity is OSS, using ALSA emulation, it might do one channel at a time... at best. Not looking forward to messing with downloading all that crap and getting it to work with a kernel in a smooth (non glitchy) way. Esp. since my current 2.6.16.11 kernel seems so crappy in this area.

    Jun 2, 2006 Went to Fry's a couple times, and stared at that stupid $149.00 "linspire" computer they have, wondering if I should get it for my TiVO project... They had lots of video capture cards, but none that I was sure would work with linux. Ultimately I decided to wait and think about it some more.

    Well, I found some 50ft ADAT lightpipe cables from Hosa. So that means building a TiVO isn't necessary, I think. Still might be a cool project if I can find the parts, and know they will work. Buying parts that turn out to work is not any fun though, and I really don't watch much TV, so it seems like maybe a stupid project... an mp3 jukebox on the other hand might be cool. A beater laptop with a big USB drive would probably suffice for that though.

    May 30, 2006 Rearranged my computer area to move my computer about 10 feet closer to my AW4416. I think it's still going to be pushing my luck, with the max length ADAT lightpipe cable being 10 meters. (AW is in another room.) Guy at guitar center told me I can make my own cables by getting the cable and connectors at Fry's. Maybe the RME and the Yammie are over-spec'ed (Yammie, I could see, they build good stuff) and so maybe it'll work with cables that are really long enough. I'm not sure 10m will reach, but if it does, it's going to be tight.

    Failing both of those, my plan is maybe this: Build a linux DVR system, headless (well, apart from the TV) but with network. Put the RME hammerfall into that machine, then access that machine over the network to copy the files to my "real" computer. Well, building a DVR would be an interesting project... except I don't even have cable, and don't watch much TV, so it would be kind of silly, really. Hope it doesn't come to that.

    May 29, 2006 I have about decided I'm going to get an RME Hammerfall DIGI9636/52 board and a MY8AT modules for my AW4416 so I can transfer 8 tracks back and forth at a time over ADAT lightpipe. It's just too much of a hassle burning CDs all the time.

    I think the max cable length for ADAT lightpipe is 10 meters, which isn't quite long enough, but I can shift some things around, I guess.

    Noticed with this 2.6.16.11 kernel, I cannot run Gneutronica and record with Audacity without glitches. I think the glitches are due to audacity's low tolerance for scheduling hiccups. A dual cpu system might fare better. Supposedly the RME board can go full bore with a shitload of tracks with minimal CPU utiliazton.

    It is not clear to me how you're supposed to monitor the RME, as it has only spdif and ADAT i/o. Digital monitors? Seems kind of nuts.

    Hmmm, my JVC stereo seems like it might have some digital inputs.

    Incredibly, I think my Motif has an optical and a digital out.

    May 27, 2006 Been thinking about new input methods for drum tracks... It'd be cool to take a microphone and just "sing" (human beatbox style) a drum track and have it produce MIDI...

    Well, searching the internet, there is some research in this area, it's not a new idea, but I see no free software to do it. Some pieces of the puzzle:

    I suspect it may be fairly easy to get something sort of half-ass working, being mostly a matter of figuring out details of how to use the various libraries and data formats. I suspect it will be very difficult to get something which works well.

    And, since this is the closest thing to ba blog I have, I'll put this here, seen on a discussion board:

    (Nelson voice): "Ha ha!"

    May 25Found a good site which may shed some light on how all the usb-midi stuff works: http://www.usb.org/developers/devclass_docs

    The PDF entitled "USB MIDI Devices 1.0" looks especially good. Lots of stuff that seems to correlate with things I saw in the usbmidi.c file in the linux kernel, talking about virtual cables, endpoints, how data is formatted for transmission over USB, etc. May very well be just what I need to crack this nut.

    May 24, about 1:30 am... I recorded this: Recyclotron, drums done with Gneutronica driving my Kurzweil (Motif would have been better, but it's in the wrong room.) Had some trouble with audacity skipping a lot with this 2.6.16.11 kernel. Also, it seems the EQ may have introduced some weird high frequency artifacts... but not really sure. Sound quality doesn't seem very good. I'll have to listen closely to see if the CDs I made with the AW4416 have the same problems.
    May 18, 2006 Some progress on the Akai linux driver front.... Here's the email I just sent to the alsa-user mailing list. 
    
Hi,

I have an Akai MPD16, it's a MIDI drum pad thingy.
Using the regular MIDI port works with linux just fine, but
I'd like to be able to use it using only USB, but it
seems not to be supported, so I thought I'd try to
add support myself.

I've had some success, despite not really knowing what I'm doing.
Not complete success, but close enough to complete
success that I'm very encouraged.

I added this into sound/usb/usbquirks.h:

/* Akai devices */
{
        USB_DEVICE_VENDOR_SPEC(0x09e8, 0x0062),
        .driver_info = (unsigned long) & (const struct snd_usb_audio_quirk) {
                .vendor_name = "AKAI Professional M.I. Corp.",
                .product_name = "AKAIpro MPD16 USB/MIDI PAD CONTROL UNIT",
                .ifnum = QUIRK_ANY_INTERFACE,
                .type = QUIRK_MIDI_RAW,
                .data = & (const struct snd_usb_midi_endpoint_info) {
                        .out_cables = 0x0001,
                        .in_cables  = 0x0001
                }
        }
},

I'm running a 2.6.16.11 kernel from kernel.org.

After rebuilding snd-usb-lib.ko, I can do this:

[root@zuul gneutronica]# aconnect -li
client 0: 'System' [type=kernel]
    0 'Timer           '
    1 'Announce        '
client 16: 'Audigy MPU-401 #2' [type=kernel]
    0 'Audigy MPU-401 (UART)'
   32 'Audigy MPU-401 #2'
client 20: 'MOTIF-R' [type=kernel]
    0 'MOTIF-R MIDI 1  '
client 24: 'AKAIpro MPD16 USB/MIDI PAD CONT' [type=kernel]
    0 'AKAIpro MPD16 USB/MIDI PAD CONT'
    1 'AKAIpro MPD16 USB/MIDI PAD CONT'

So it seems 2 interfaces show up on the Akai...?
The first one doesn't seem to do anything, that I can
tell.  The second one works, I can do this:

[root@zuul gneutronica]# aconnect -li
client 0: 'System' [type=kernel]
    0 'Timer           '
    1 'Announce        '
client 16: 'Audigy MPU-401 #2' [type=kernel]
    0 'Audigy MPU-401 (UART)'
   32 'Audigy MPU-401 #2'
client 20: 'MOTIF-R' [type=kernel]
    0 'MOTIF-R MIDI 1  '
client 24: 'AKAIpro MPD16 USB/MIDI PAD CONT' [type=kernel]
    0 'AKAIpro MPD16 USB/MIDI PAD CONT'
    1 'AKAIpro MPD16 USB/MIDI PAD CONT'
[root@zuul gneutronica]# aconnect 24:1 20:0

And then when I tap out things on the Akai, they
are played on my Yamaha Motif Rack.  Well, then it
sends something periodically (about 4 times per
second) something which makes a small quiet sound
on the Motif...  I know with the regular MIDI cable,
it will send a byte, 0xfe, about that often...
don't know what that is about.

However:

[root@zuul gneutronica]# ls -l /dev/snd/midi*
crw-------  1 scameron root  14, 18 May 18 19:32 /dev/snd/midi1
crw-------  1 scameron root  14, 34 May 18 19:32 /dev/snd/midi2
crw-------  1 scameron root 116,  8 May 18 13:36 /dev/snd/midiC0D0
crw-------  1 scameron root 116,  9 May 18 13:36 /dev/snd/midiC0D1
crw-------  1 scameron root 116, 10 May 18 18:59 /dev/snd/midiC0D2
crw-------  1 scameron root 116, 11 May 18 18:59 /dev/snd/midiC0D3
crw-------  1 scameron root 116, 40 May 18 19:32 /dev/snd/midiC1D0
crw-------  1 scameron root 116, 72 May 18 19:32 /dev/snd/midiC2D0


ot@zuul gneutronica]# 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,0  AKAIpro MPD16 USB/MIDI PAD CONT
hw:2,0,1  AKAIpro MPD16 USB/MIDI PAD CONT
[root@zuul gneutronica]#

/dev/snd/midiC0D* correspond, I guess to my audigy, hw:0
/dev/snd/midiC1D* is my motif, (I know, becasue I can send stuff and make sound)
so /dev/snd/midiC2D0 must be the akai, but I cannot get anything from it.

(When I use a midisport 2x2 and connect the akai through that, I
can read from the /dev/snd/midi and get data from the akai.)

So, any ideas about what I've done wrong?

It's so close to working...

Thanks,

-- steve
    May 17, 2006 Found on the Akai MPD16 FAQ that it can be powered by the USB cable, ven when using the MIDI cable for output... interesting. 
    Q. Does the MPD16 need an external power adaptor?
A. Not necessarily. The MPD16 can also be powered via its USB port, even when using the MIDI out.
However, if a USB host is not available, an optional MP9 AC adaptor should be used.
    I'm too lazy to try this out right now, but this seems maybe easier than using the wall wart for power. And it might let me develop a real USB/Midi driver for it easier, if I can compare what's coming in via the MIDI cable vs. what's coming in over USB at the same time... unless the presence of a MIDI cable reduces the USB cable to a power cable.
    May 16, 2006 Made a "record mode" for gneutronica which allows you to record using a MIDI input device, like my Akai MPD16. It works ok... except that getting a hit to record at the very beginning of the measure doesn't seem to work too well, and also, when looping a pattern, because of the slight delay when the schedule is recalculated at the beginning, there's a slight glitch in the timing which makes it a bit ugly. But, it basically works, apart from that.

    May want to mess around with it to get it to record multiple patterns, not sure. With the multi-pattern per measure arranger thing, it's not clear how recording several measures in a row would work... which pattern do the hits go into? Maybe the "first" one in the measure?

    Played around with Chuck, a weird on-the-fly audio programming language. Interesting. Not sure I have the patience to get anything really useful out of it, and the provided examples were a) better than I can imagine doing and b) not that musical sounding... kind of techno, but not really in a good way. Might have been the samples they picked, in that particular case. With patience, persistence, and brains, it could probably do some pretty cool stuff though.

    May 14, 2006 Continued working on gneutronica. Made French translations (via google, so they suck, but at least there's some sort of code to support different languages now.) Figured out how to change the background color of a drawing area (thanks to gnomedev.com). 
    
 GdkColor whitecolor;


  gdk_color_parse("white", &whitecolor);
  inst->canvas = gtk_drawing_area_new();
  gtk_widget_modify_bg(inst->canvas, GTK_STATE_NORMAL, &whitecolor);
    May 7, 2006 Made some progress getting Akai MPD16 to work with Gneutronica, now it reads input from the Akai, and routes this to the output MIDI device (e.g. yamaha motif). Now just have to make a "recording mode" let you tap in patterns.
    May 6, 2006 Finally got a power supply for the Akai MPD16 midi drum pad thingy. Hooked it up through the Midisport 2x2, and using aconnect, connected it to drive yy Motif-R, and also a softsynth. It works. Yay, I don't have to return it. Still wished it worked with USB alone though. Tried it with linux-2.6.16-11, which is spanking new, and it doesn't work with that, so, eh. Maybe if I get ambitious, I will try to debug the usb midi code and see if I can make it work... if it's something simple like the device just isn't recognized as "known, good", but the midi-over-usb protocol is already implemented. If it's proprietary midi-over-usb protocol which I have to reverse engineer and implement... well, that's probably too much for me to tackle.
    View older notes... 1