Updated: 2007/07/27 – New section on LEDs. Update on mixxx SVN.
In case any of you who have read my review of the M-Audio Xponent are thinking of getting one and wondering “but will it work under Linux?”, the short answer is a resounding Yes!… except for the LEDs, so far. More on that later.
I use Debian unstable with a hand-rolled kernel. YMMV, of course, but the chances are that if you’re using any modern distro you’ll be fine. In fact you may not even have to manually insert the kernel modules if you have a working udev setup, you might just be able to plug’n’play.
Full details below the cut, as they say…
The ALSA driver (Audio and MIDI)
The Xponent is a class-compliant USB MIDI and Audio device. Both aspects are handled well by the ALSA snd_usb_audio module. If necessary, do modprobe snd_usb_audio, check dmesg, then try amidi -l and aplay -l to show the devices.
The Xponent presents two audio devices, representing the main output and the headphones output. On my system these are called Xponent Audio #1 and Xponent Audio respectively (note the order — you might have expected them to be the other way around).
You’ll also get two MIDI devices, which are either numbered 0 and 1, or 1 and 2, depending how you look at them. The lower of these handles the controls from the Xponent itself. My guess is that the second device forwards what has been received at the 5-pin MIDI IN socket, though I haven’t confirmed that yet.
When the Xponent’s MIDI button is illuminated, the trackpad functions as a regular MIDI controller, sending Note On/Off for touch/release (and the two buttons), and CCs for X and Y position. Switch the MIDI light off, and it’s a normal mouse trackpad.
I didn’t expect it to work in “mouse mode” under Linux for some reason… perhaps because the Xponent comes with “drivers” for OSX and Windows, which are clearly not required for the audio and MIDI support, so what else would they be for?) But as an experiment I did modprobe usbmouse… nothing… then tried modprobe usbhid and was somewhat startled to find that my X cursor was now controllable from the trackpad (as well as from my mouse)… without even having to touch xorg.conf. I dunno, maybe that doesn’t seem remarkable to you, but over my 13 years of Linux it’s been a pretty rare occurrence that a new piece of hardware has Just Worked without any special configuration or driver. God bless the fine folk who came up with USB class standards good enough for manufacturers to stick to them!
The trackpad is very sensitive to small movements, like even a slight roll of the finger. I think for it to be useable as a mouse cursor some configuration will be needed to reduce the influence of small movements on the cursor, and provide a configurable threshold for fast movements. I don’t anticipate working on this myself, though, as I don’t expect to use the trackpad in this way; for me it’s more useful as a MIDI x-y controller.
So, since I can’t use the supplied Torq software until I get a Macbook Pro, for now let’s get this working with mixxx, a fine piece of free open source DJ software which is under very active development and is, I think, approaching professional quality (though it isn’t quite there yet.) By the way it runs on Windows and OSX too, not just Linux.
The first thing to do was write a MIDI mapping file to map the Xponent’s controllers to mixxx’s controls. So I needed to know what MIDI messages were being sent by the controllers. I sat there with kmidimon open, trying each controller, making a note of what it sent. Only later did I discover that the CD-ROM has a PDF manual on it which contains this information already! (Alas it doesn’t contain what I now need to know… what messages to send to the Xponent to control the LEDs1…) But still, it was a useful exercise.
Having written the map, most of the controls worked straight off, but there was something amiss with the Pitch sliders, which (unlike, and superior to, most hardware controllers) send Pitch Bend instead of Controller messages. I fixed that initial problem quite quickly (it’s so nice to be able to do that yourself instead of being at the mercy of a software supplier).
Then there was the jogwheels. They work by sending repeated CCs with a value greater or less than 64 depending on the direction of travel, and with the distance from 64 representing the rotation speed (something the Xponent manual calls “Relative CC”, suggesting it’s not uncommon, but mixxx had no support for it). The value always returns to either 63 or 65 (not 64) so these have to be regarded as “stop” values. I added a new “option” to the available mapping options in mixxx called “Spread64” — as well as handling the stop values, this applies an acceleration to the values so that fast spins of the jogwheels cause fast tracking while small nudges cause only slight adjustments, which is what you need for beatmatching and cueing. I’ve also added a sensitivity setting so that there is some scope for adjusting the formula in the map file without hacking the code of mixxx itself. I’m no mathematician so it took me a while to come up with a formula I was happy with, but I think it’s about right now.
I’ve now been accepted into the fold of “official” mixxx developers, and I’m reworking the earlier changes I made in order to get the Xponent working quickly into something that will be consistent and compatible with other controllers. I hope to get that done and committed to the mixxx SVN trunk within the next few days: I’ll update here when it is. [Update 2007/07/27: It’s in SVN as of a couple of weeks ago. Currently the SVN head is rather flaky because it’s just been migrated to QT4 and there’s a lot of clearup to be done. Consequently you might want to use SVN r1318 for now, which also includes support for the Xponent’s transform buttons.]
The proof of the controller is in the mixing. I was somewhat delighted to find that, despite not having DJ’d to any degree for several years, once I got the jogwheel formula right, beatmatching and cueing on the Xponent and mixxx was a piece of cake — much, much easier than vinyl. mixxx’s “Pitch-Independent Time Stretch”, which alters the playback speed without changing the pitch, means it’s far less noticeable if you have to nudge a track back into line during the crossfade as I, a strict amateur, sometimes still have to do. It also feels easier to get the tracks in line to start with, although the lightness of the Xponent’s pitch fader is an issue with doing precise speed adjustment — of course you can use buttons to nudge the speed as well, but then your pitch fader is in “the wrong place”, so if you move it again (or it moves itself, which it might do from the lightest breeze), the speed will jump back to its old value. This needs resolving… I shall go shopping for felt washers tomorrow.
I’ve realised for a while that vinyl, despite enjoying something of a renaissance among the nu-skool breaks community, was probably finally going to die off among DJs in the very near future (which is annoying as I have a large collection to sell!). CDJs alone couldn’t do it, but as MIDI controllers like the Xponent continue to improve, with the greater creative possibilities offered by computer-based mixing, more and more vinyl DJs will be leaving their heavy boxes at home.
Currently in discussion with M-Audio UK Tech Support about how to obtain the necessary information to support the Xponent’s LEDs. It’s a bit of a usability drag for them not to reflect what’s going on in the software at present; particularly for important toggles like the touch-sensitivity switch, you really need to be able to see on the Xponent whether this is enabled or not (not least cos there isn’t an on-screen control for it, but even if there was, you’re not looking there, you’re looking at the jogwheel…) The guy’s just got back to me asking me to sign an NDA to get their SDK, which of course I can’t do since mixxx is open source so the information would, by definition, be disclosed. I’ve written back to explain the situation, we’ll see what transpires, and I’ll keep updating this page as new info arrives.