meanderingjourney

As I've mentioned before, I recently came into posession of an Akai Electronic Wind Instrument, USB edition. To be of any use, this wonderful artifact must be connected to a computer running proper software. That on EWI's companion CD supports only MS Windows and Mac OS X so with my GNU/Linux notebook I was on my own.

I had obviously checked on-line for other people's experiences with the EWI and Linux before purchasing it but all I knew was that yes, it does work. I use a rolling-release Debian-based distro called aptosid (formerly known as sidux) which means I tend to be fairly up-to-date as far as the kernel and drivers are concerned. I wasn't expecting any major problems but I was ready for anything.

I started with the basics: I saved the listing of /dev and /dev/snd into a text file and plugged the EWI in. A bunch of messages in dmesg confirmed that the device was detected and recognized. Comparing the listing of /dev/snd with the previous version yielded /dev/snd/midiC1D0 as a new device and sudo cat /dev/snd/midiC1D0 produced a flurry of line noise as I tried playing the instrument. The low-level set-up, then, was exactly as it should be: pure plug-n'-play.

With my confidence boosted, I turned straight to QSynth which is a GUI front-end for fluidsynth, a powerful SoundFont-based command-line software synthesizer. QSynth has a nice setup dialog with separate tabs for the MIDI side (input) and the audio side (output). Unfortunately, the configuration options accurately reflect the mess that is Linux audio support, with four MIDI drivers and five audio drivers to choose from and fiddle with. To make a long story short, I failed to find a combination of settings that would work.

I needed clarity and precision, hence I turned to working with fluidsynth directly. After reading the manual, the alsa_raw driver looked like the most promising option for MIDI input as I had used ALSA to get a MIDI port on another computer going a few years ago. When I used alsa_raw without specifying a MIDI device path, however, fluidsynth would say "Error opening ALSA raw MIDI port". When I did specify /dev/snd/midiC1D0 as the MIDI device I got "Unknown RawMidi /dev/snd/midiC1D0". I somehow remembered that during my previous MIDI experiments the device was midiC0D0 rather than midiC1D0 so I tried ln -s /dev/snd/midiC1D0 /dev/snd/midiC0D0 and ran fluidsynth without giving it a device path. Bingo! I had sound!

There were two serious problems with this setup. First, the midiC0D0 symlink disappeared at every reboot, forcing me to re-create it over and over. More seriously, the audio lagged some 100 to 300 ms behind MIDI input, making the EWI so sluggish as to be unplayable. What was I to do? I will reveal the dramatic resolution of both issues in another post; stay tuned...

I use KDE 4. One of my workspaces is configured with a "dashboard" activity, displaying all the usual monitoring widgets (CPU, RAM, network, temperatures). When my notebook starts acting slow, I hop over to the dashboard to check out my CPU load. If it's high I whip out Konsole and launch htop to find the culprit. It has occurred to me that it would really be nice if I could see the CPU hog right away.

I realized there must be a process-monitor plasmoid out there but a Konsole widget seemed so much more flexible. Plasmacon seemed to fit the bill and I had it on the desktop in next to no time. It turned out, however, that it has no facility to launch a command at start-up. I figured it should be easy to extend the widget as it's written in Python. Checking the documentation for Konsole's KPart turned up two promising methods: sendInput() and startProgram(). Neither of them worked.

I inserted some trace code into Plasmacon's init method and it turned out that the object Plasmacon creates is just a plain KParts::ReadOnlyPart. Browsing PyKDE documentation brought the answer: PyKDE doesn't include a binding for kdebase-apps. The upshot is that you can create a Konsole::Part instance from Python but you can't access its full API.

Things didn't look so trivial anymore but I decided to have a go at creating the necessary bindings. PyKDE uses a generator called SIP (apt-get install python-sip in Debian) to create Python modules from C++ headers and deceptively simple spec files. I tried to write a SIP spec for Konsole starting from Konsole::Part's header file and various .sip files I dug up. I have to say SIP provides rather modest feedback. I ended up stuck with a terse "syntax error" message providing no detail at all.

I noticed a little comment in one of the .sip files, saying "Generated by twine". Googling for twine proved to be quite a challenge; this is really obscure code used primarily by PyKDE creators and few others. There is no website nor documentation. Another comment in a .sip file provided the decisive clue: a mention of "twine2". It brought me to http://gitorious.org/twine2 where the tool currently seems to live. And yes, it's a generator of input for a generator. Go figure...

Writing a twine2 script seemed quite daunting but I came up with an entirely different approach: what if I could talk to the Konsole via DBus? I quickly discovered qdbusviewer and clicked around to see what I could do. Unfortunately, while the org.kde.plasma-desktop service does expose a /Konsole object, it doesn't provide its Sessions. Some could be found under org.kde.konsole but they included strictly sessions in proper Konsole windows; the one in the Plasma widget didn't show up in the list. I had to go back to twine2.

Except I didn't. The ability to delve into the guts of open source software is one of its most useful aspects but there is a limit to how far down the rabbit hole one can reasonably afford to go. I've reached that limit and had to accept that, for the foreseeable future, I will simply not have a process monitor on my dashboard. Worse things have happened.