Kroon Information Systems
Howto: Digitech GNX4 and Linux

Last updated 9 August 2023


The Digitech GNX4 pedal is a guitar effects processor, and happens to have a few other goodies included as well (such as a MIDI-capapble drum-kit, 8 track recorder, microphone input, 2 unbalanced outputs, 2 balanced outputs and headphone jacks). I got mine around March/April of 2006 and have been playing around with using it under Linux periodically. I've managed to get quite a few bits of functionality working and this page is where I share what works and what doesn't, and as far as possible, how to make things work.

Parts of this page act as a scratchpad for ideas on how to make other parts work, if you notice something I miss, then please drop me an email so that I can add those ideas here.


I've recently been contacted by Tomasz Mon who wrote a program called gdigi. It looks reasonably promising, and I suggest checking it out. Unfortunately at the moment my schedule is of such a nature that I don't have time to invest in this promising project.

Making the USB connection

Connecting the USB cable is easy. It was harder for me to figure out what modules needs to be loaded to 'manage' the device. At the time of writing the lsusb (usbutils) program doesn't know the Id used by Digitech for the GNX4 (I've submitted this and hopefully the Id will be added shortly). The output from lsusb looks something like this (showing only the nodes that carries relation to the GNX4):

Bus 001 Device 003: ID 1210:0004  
Bus 001 Device 002: ID 0451:2036 Texas Instruments, Inc. TUSB2036 Hub

As you can see the unit exposes a USB Hub and then behind that there is a supposedly unknown device. For me the Hub worked out of the box, it's a 2-port USB Hub. The reason is there is because when you press the Cf-Storage button there appears another device:

Bus 001 Device 006: ID 1210:0003

All in all this makes sense. The sad thing is that this is only USB-1.1 and things happen relatively "slowly". I guess it's fast enough for the amount of audio we are pushing through the device so it's fine.

The compact flash

I'll handle the compact flash first since that is by far the simplest of all the functionality on the device. Well, after a few very twisted turns and lots and lots of googling.

Essentially you just need to load the usb-storage module and then when you press the Cf-Storage button it should present you with an extra drive that contains a single partition and is formatted with vfat. This is all fair and well, but the compact flash still only manages about 70KiB/s and generates lots of errors in dmesg. This is due to a broken USB mass storage implementation from Digitech. Strange enough, when I confronted them about it they didn't actually respond other than their usual "We don't support Linux". I replied stating that I don't expect them to, I expect them to support the device, providing me with any technical details that I require in order to use the device. They never responded.

Bottom line is that fortunately there already exists a quirks mode for some devices in the kernel, so simply adding the GNX-4 USB-mass-storage identifier with the appropriate quirk makes the kernel work around the problem, the patch has been submitted and accepted for mainline and will hopefully be part of the mainline kernel as from 2.6.20 (but only time will tell):

--- linux-	2006-10-14 05:34:03.000000000 +0200
+++ linux-	2006-11-14 23:22:32.000000000 +0200
@@ -1271,6 +1271,16 @@
 		US_SC_DEVICE, US_PR_DEVICE, usb_stor_ucr61s2b_init,
 		0 ),
+/* Reported by Jaco Kroon <>
+ * The usb-storage module found on the Digitech GNX4 (and supposedly other
+ * devices) misbehaves and causes a bunch of invalid I/O errors.
+ */
+UNUSUAL_DEV(  0x1210, 0x0003, 0x0100, 0x0100,
+		"Digitech HMG",
+		"DigiTech Mass Storage",
 /* Reported by Vilius Bilinkevicius <vilisas AT xxx DOT lt) */
 UNUSUAL_DEV(  0x132b, 0x000b, 0x0001, 0x0001,

Note that the patch contains tab characters and you should rather download it from here. The patch was created against linux- but should also apply cleanly to older (and newer) kernels. If it doesn't I reckon the format should be obvious enough to manually make the required change.

After recompiling your kernel and rebooting (or re-loading the usb-storage module) everything should be working a lot better.

Audio Devices

Whilst the usb-storage device only becomes available once you hit the Cf-Storage button, there are still the usb-audio device that hangs around whenever the device is plugged in. If you look in /proc/asound (assuming ALSA) you should see a number of card? directories, with symlinks to them. Look for the GNX4 symlink. In my case it points to card2:

lrwxrwxrwx 1 root root 5 Jan  9 14:00 GNX4 -> card2

Performing ls -l GNX4/ provides us with some additional information:

/proc/asound $ ls -l GNX4/
total 0
-r--r--r-- 1 root root 0 Jan  9 14:02 id
-r--r--r-- 1 root root 0 Jan  9 14:02 midi0
-r--r--r-- 1 root root 0 Jan  9 14:02 midi1
-rw-r--r-- 1 root root 0 Jan  9 14:02 oss_mixer
-r--r--r-- 1 root root 0 Jan  9 14:02 usbbus
-r--r--r-- 1 root root 0 Jan  9 14:02 usbid

That simply states that we are presented with two MIDI capable devices, and gives some information with regards to how the device is connected. Taking a peek in /dev/snd reveales that there are also two DSP devices. That makes sense since they clain 4 channels in total, so each DSP device would carry two channels. So in theory we should be able to use hw:2.0.0 and hw:2.1.0 for playback purposes from the computer where both these devices will then get mixed together before being output in stereo to the various stereo outputs.

I haven't played a lot with the various DSP devices yet, but I know ALSA can handle audio devices with more than four channels, and it also happens to be possible to merge two two-channel devices into a 4-channel device, so you're welcome to go that route. I've seen examples of how to do this on the web (just google) but have no interrest in this at the moment. There are at least two programs you can use for recording, namely audacity and ardour. Audacity is probably the simpler one to use, but ardour (without having used it extensively, merely fired it up) looks way more professional, and it's device management upon startup is already rather intimidating. It has a nice look & feel about it. Audacity on the other hand looks like a toy, I've used it a couple of times, it's simple to use, but severely lacking in stability and features.


For those who haven't played with MIDI yet: It's pretty impressive. There are really funky things you can do. The GNX4 has a drum-kit that is MIDI compliant. The drumkit, as per convention, is on channel 10 (There are 15 individual MIDI channels, with channel 16 - or 0 - being a broadcast channel). The GNX4 generates MIDI events whenever it plays a MIDI drumkit loop, but you can also send these same MIDI events to the pedal from a MIDI synthesizer (Yes, the GNX4 has a MIDI input as well as OUT/THRU connectors). Alternatively you can do what I do (for now): Use the USB interface to send it the MIDI codes.

At the moment I'm using rosegarden to program the drumkit, but hydrogen looks like a better choice in the long run. Rosegarden is an awesome piece of software, but it was designed as a general MIDI tool, so it doesn't give you a drum feel, it gives you a 5-bar music stafe and you are required to program from there. This really does not make sense from a drumming point of view in my opinion, but would be great for composing a piece of music that gets played back to you via alternative MIDI devices (keyboards anybody?). I haven't yet used hydrogen though and only just realised that it actually supports MIDI. It may well be possible to record it's samples into wav files and actually be able to write a piece of MIDI music for the drumkit without having it connected. All things failing it seems hydrogen has a library, which might then be possible to use to read a hydrogen file and produce the appropriate MIDI events using that.

Manipulating the samples

I haven't yet managed much here. Via the Cf-Storage this seems _almost_ viable:

jkroon@chimera /mnt/usb/gnx4/presets $ file presets.tbl 
presets.tbl: DBase 3 data file (1094932303 records)
jkroon@chimera /mnt/usb/gnx4/presets $ 

So apparantly the presents is stored in a known file format, but since there is only really 80 effects on the CF this number of records seems a bit out-of-whack. Also take into consideration that ls reports that the file is about 215KB big. That means that there should be just over 5000 records per byte of data (not taking file-format overhead into consideration). So I'm guessing the fact that file reports it as DBase 3 is a bit wrong, but if anybody knows how to manipulate DBase 3 files in linux, give me a should and I'll investigate some more.

Gaining access to the patches via MIDI has so far also proved futile. I can get the pedal to dump all the patches using the buttons on the pedal itself (Utility -> BulkDump) and can capture the MIDI stream generated by this nothing I've done so far has managed to actually update any patches. Simply playing back a patch to the device does not work. I've managed to locate the SDISC SysEx MIDI documentation from Digitech's site (And according to one of the support people the stuff should be the same) but this does not help either. I'll get back on this one day when I've had some more time to play again. If anybody wants the docs, let me know and I'll see if I can locate it again.

Granted, I've just been fooling around with the Linux USB audio (ALSA) API. None of the CC codes I'm sending is working, and doing a general read on the input channel doesn't seem to be delivering anything. Basically I can get the name of the device at this point in time:

jkroon@pug ~/projects/gnx4 $ make && bin/gnx4c 
g++ -W -Wall -Iinclude -O0 -DDEBUG -g -ggdb -O0 -o obj/gnx4c.o -c src/gnx4c.C
g++ -rdynamic -Llib -g -ggdb -Wl,-rpath,/home/jkroon/projects/gnx4/lib -o bin/gnx4c -lasound -lsigsegv -lkroon obj/gnx4c.o
Everything has been brought up to date
snd_rawmidi_info_get_id(midi_info) = USB MIDI
snd_rawmidi_info_get_name(midi_info) = GNX4
snd_rawmidi_info_get_subdevice_name(midi_info) = GNX4 MIDI 1
jkroon@pug ~/projects/gnx4 $

There is one exception to the above. In some cases following the SDISC docs does get me feedback when I add extra bytes at semi-random places.

Well, that is what I've got so far. Hope it's useful, and if you've got anything to add, please drop me a mail!