It seems I had a request recently to improve my Roland TD-15 hack. And since I'm such a nice guy *cough* I figured I'll have a go at it... and behold the new version! It's pretty similar to the old one except that it now not only sends from the Roland to MIDI but also the other way around, i.e. it's "read / write".

Unfortunately the development didn't went as smooth as I hoped. Conceptually it was quite easy, just read from the MIDI device and pass that to USB via bulk data. The first annoying but was the fact that some programs send MIDI data in a somewhat shortened version which means you can't pass it directly but it needs some conversion. 

However that wasn't the bit I struggled with... reading from both MIDI and USB at the same time was. The first attempt was to fork the process and read USB in one process and MIDI in the other. While this worked in principle, it caused a weird issue, namely that the USB reading process would catch the result of the other process writing to the USB port. Which in turn locked up the device causing nothing to happen after that. What I don't get is that windows manages to send to the USB while listening to it uninterrupted. So probably the reading process is paused during the write... then again I haven't managed to convince LibUSB to do so...

Anyway as a result it's now a "polling" based driver which continuously checks the MIDI and the USB devices for new data and handles it accordingly. The obvious result is that it causes a somewhat heavy load and lags (a little)... then again I played around with Renoise and my TD-15 and I'm actually quite pleased with the results!

Enjoy, and keep the feedback coming!

I upgraded my box recently which came with a nice new Linux kernel. And after a reboot (prolly 2 weeks later) all of a sudden this line showed up in lsusb:

Is it really so? Does Linux recognize my TD-15? Yup... unfortunately that's pretty much it, i.e. it doesn't actually support it. Which is obviously quite a pain in the arse. However with my recent USB reverse engineering experience I figured I can crack this puppy as well! So I did.

Now before you all get too excited, for now I've only been able to get the MIDI part to work. Which is the easy part but I consider this a step in the right direction. As a matter of fact I'm planning to go all the way (i.e. sound in+out) with this so the TD-15 can actually be fully supported by ALSA. But I will probably need "some" help with that since I've got no experience with ALSA (i.e. feel free to leave some comments!). 

Like the previous exercise, I used a windows VM with the driver and wireshark to see what windows was doing to that poor USB port. As it turns out, not that much, the initiation is fairly simple and after that it's just receiving bulk data. There are 2 additional "interfaces" available which presumably are the sound in+out but, as stated, I haven't figured those out for now. 

Using the hack

Getting this puppy up and running is similar as with the Cyborg volume bar, download the source, run "make" in the "roland-td15" directory and run the roland-td15 binary that's produced  (yes, you need root).

When started without any arguments it will try to connect to the TD-15 and if successful it will spit out the raw MIDI values. You can start it a MIDI device name (e.g. hw:3,0) which will cause it to write the MIDI command directly to that device. There is also and optional 2nd argument "skipOffs" which skips the "off" MIDI commands. To start, simply run the following (don't forget to modify /etc/sudoers!):

So far I've had success with the ALSA Virtual Raw MIDI device:

If it doesn't show any Virtual device try loading the driver:

That's it for now, hopefully I got some more updates soon!

 

While playing with the Cyborg V.7 macro keys I though: how hard can it be to get the volume bar working on the keyboard as well? As it turns out, not too hard.

The big difference is that instead of reading what happens on USB, you'll actually need to write to USB to change the volume bar leds. So I started to play around with LibUSB, grabbed some scripts and monitored what windows did on my USB port when adjusting the volume bar via the "official" driver. 

The end result is a wee piece of C code that sends a signal to the relevant USB device (06a3:0728) and you're done. You can download the code here, untar it, go into the cyborg directory, run make and if all goes well you should have a binary called "cyborgLeds".

Just run this binary as root with a argument 0 to 20 and it'll change the volume bar on your keyboard: 

To run as root, add the following line to /etc/sudoers:

BTW, reverse engineering windows drivers actually became a lot easier with virtual machines. Get a windows VM up and running on a Linux box, attach the relevant USB device, start usbmon, use wireshark or just cat the usb device (cat /sys/kernel/debug/usb/usbmon/0u) to monitor what windows and the device are doing to each other.