Wednesday, January 20, 2021

NUX MG-300 Guitar Processor under Linux and Android


I picked up a NUX MG-300 guitar effects unit with high hopes that it would work under Linux, since it is supposed to be a class-compliant USB audio device.

Unfortunately, it did not work out of the box. After some back and forth with the maintainer of the Linux kernel sound subsystem, we managed to get audio capture working, but never managed to get playback working. Everything seems to be operating correctly, but the device produces no audio output over USB.

I have admitted defeat and will be returning the device.

The discussion on the alsa-devel mailing list can be found here:

It at least resulted in a kernel patch to enable audio capture.

I also had no success getting it to work with Android - even with some of the apps that have their own custom USB audio implementation.

If anyone has more luck with this interface down the road, please let me know.

Update: As a last ditch effort, I gave the interface a try with the aforementioned kernel patch on my Raspberry Pi 4, which was running about a year old kernel version. And it worked. Sort of. It initially worked perfectly, but I found after more testing that it is sporadic. Sometimes it worked fine, sometimes only playback worked, and sometimes only capture worked. Not sure what needs to be done to get the interface working reliably.

Tuesday, November 3, 2020

Guitar amplifier and pedal simulation

I've been spending a lot of time lately playing guitar, and working on my own software for simulating guitar amplifiers and pedals. It is coming along nicely, and I have most of the important stuff covered.

I run it as a VST under Windows, but I also have a Linux version that I run on a Raspberry Pi 4. Coupled with a USB audio interface, a PA speaker, and a remote control app on my phone, it makes for a nice little portable rig.

Here is a little video of it in action (running as a VST in Reaper):

Saturday, August 22, 2020

Starting JACK automatically when a USB audio device is connected

I have a Raspberry Pi that I'm using headless for audio, and I wanted to automatically start jackd when I connected my USB audio device.

There are a lot of ways to try to do this - after a few false starts, I ended up with this method. It took me long enough to sort out the details that I figured I'd write up a little how-to.

This solution is composed of two parts: 1) set up jackd as a systemd service, and 2) use a udev rule to start the service when the sound card is connected.

First the service. Create a file called '/etc/systemd/system/jackd.service' with the following:

Description=JACK audio

ExecStart=/usr/bin/jackd <your jack commandline arguments here>


Now (or at least after you reboot, or do 'sudo systemctl daemon-reload', you can start and stop jackd with 'sudo systemctl start jackd.service' and 'sudo systemctl stop jackd.service'. I'm running the service as root - if you want to use a different user, change the "User=" line.

We want this to happen automatically, though, so it is time to use udev - the system for managing Linux device events.

First, you need to know some information about your USB audio device. Plug it in, and run 'lsusb'. You should see something like this:

Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 001 Device 003: ID 0582:01d6 Roland Corp.
Bus 001 Device 002: ID 2109:3431 VIA Labs, Inc. Hub
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub

Look for your sound card device in the list (mine is showing as "Roland Corp."), and note the two hex numbers after ID. They are the USB Vender and Product IDs for your device.

Create a file called something like '/etc/udev/rules.d/80-local.rules' with the following in it:

ACTION=="add", ATTR{idVendor}=="0582", ATTR{idProduct}=="01d6", TAG+="systemd", ENV{SYSTEMD_WANTS}="jackd.service"

Where the values for 'ATTR{idVendor}' and 'ATTR{idProduct}' are the Vendor and Product IDs you got from lsusb.

After your next reboot, or after running 'sudo udevadm control --reload', you new rule should be ready. When you plug in your sound card, the udev rule will fire and request your service, which will then start jackd.

Thursday, January 30, 2020

Using the Mod Devices guitar effects interface on Raspberry Pi 4

My last post was about getting my Boss GT-1 guitar effects floorboard to work in Linux. The reason I wanted to do this was to couple it with a Raspberry Pi to create a more configurable effect chain using LV2 plugins.

Once I had audio working, I installed Guitarix, an open-source guitar effects stack for Linux, and I was quickly off to the races. Guitarix works really well, but the interface is designed for desktop use - not ideal for my needs.

I had been aware of Mod Devices for a while, with their Mod Duo multi-effects hardware pedals built on top of Linux. They have added a slick, web-based pedalboard interface running on top of LV2 plugins. It is primarily designed for their hardware devices, but the project is open source.

The folks over at have a project called MODEP, which provides a custom Raspberry Pi image for running the Mod Devices interface. Unfortunately, it currently does not work on Raspberry Pi 4, which is what I have.

So, I went straight to the Mod Devices GitHub and built it myself. It turned out to be pretty straightforward, and I was up and running after about a half an hour of tinkering. I'm going to try to outline what I did here in case anyone else wants to give it a try:

Get Jack running with audio capture and playback - there is plenty of information out there on this

Get the Mod software from GitHub:
  git clone --depth 1
  git clone --depth 1
Install the tools you need to build the mod software. You'll need at least:
sudo apt-get install virtualenv python3-pip python3-dev git build-essential libasound2-dev libjack-jackd2-dev liblilv-dev libjpeg-dev zlib1g-dev
Build mod-host from the mod-host directory:
sudo make install
cd mod-ui
sudo make install
Make sure Jack is running, and start mod-host:
mod-host -n -p 5555 -f 5556
In another shell, build mod-ui from the mod-ui directory:
virtualenv modui-env
source modui-env/bin/activate
pip3 install -r requirements.txt
make -C utils
Run mod-ui from the mod-ui directory (you will also need to do "source modui-env/bin/activate" first if you did not just do it in the above build step):
export MOD_DEV_HOST=0
export MOD_APP=1
export MOD_LIVE_ISO=1
python3 ./
The mod-ui web server should now be running on port 8888. To access it, find out the IP address of your Raspberry Pi, and go to:
You should see the Mod pedalboard interface. It should load whatever LV2 plugins you have in /usr/lib/lv2 with a generic look. In my case, I had Guitarix installed and all of its plugins were there and ready to be used.

The Mod folks have custom UI overlays for most popular plugins. You can grab them here:
git clone --depth 1
Look in the "plugins" and "plugins-fixed" sub-folders for your plugins. If you copy a plugin folder over your existing plugin in /usr/lib/lv2, you will install the custom UI for the plugin.

My Pi 4 has no trouble at all running a decently complex guitar effect stack, complete with multiple pedals and pre-amp and cabinet simulation, all at very low latency.

Saturday, January 25, 2020

Getting the Boss GT-1 effects processor to work in Linux

** NOTE: I had though that this was fixed in the latest Linux kernel, but it doesn't seem to be. See notes at the bottom of this post.

I recently picked up a Boss GT-1 guitar digital effects floorboard to use directly, and also to play with connecting it up to the Raspberry Pi.

A month later, I have everything working well. As is often the case with niche gear and Linux, though, it was a bumpy road to get there. I'm going to document the process here, in case it is helpful for anyone with a similar issue.

I booted up my Pi, connected the GT-1 via USB, ran lsusb to list the available USB devices, and there it was. Great - that was easy!

Next, I tried playing a .wav file with aplay. No go. No audio at all. Not so great.

Time to start scouring the internet. After a while, I came across this thread on

It had a fix for another Boss device. It also turned out to work for Boss Katana Amplifiers, which have a software setup that is very similar to my GT-1 device.

I grabbed the kernel source code, applied the fix (with a tweak for my device), and soon I had working audio! Well, kind of working. I was getting pops and crackles every second or so - enough to make things unusable.

To understand this fix, and why it wasn't quite working requires a bit of explanation on how USB audio works. There are a number of methods that devices use to synchronize audio timing. The one used by the Boss GT-1 (and many similar devices) is called "implicit feedback". In simple terms, what this does is, on devices that have both a capture and playback that are controlled by the same clock, the capture source is used to determine the output data rate. Essentially, the host is in a USB feedback loop - outputting the same number of samples it receives - generally after doing some processing.

The fix that got my interface working basically disables the implicit feedback mechanism. This got audio moving through the system, but because there was no timing feedback it was slightly off - resulting in the pops and crackles I was experiencing.

A while later, I came across this post in the Line 6 forums about getting the Helix (another guitar processing device) working in Linux:

The additional fix here was to hack the sample rate slightly to try to match the real timing of the device. I gave it a try, and it turned out that if I nudged the sample rate to 44105 (instead of 44100), my pops and crackles mostly went away - happening every few minutes instead of constantly.

This fix was obviously a hack, and not perfect, but it at least made my interface usable. The core problem still existed - the device should be operating using implicit feedback, but when this was enabled it didn't work at all.

I had posted about these issues on the alsa-devel mailing list, and a while later I got a helpful email suggesting that some Roland devices waited to send capture data until they had received some playback data. The kernel implicit feedback code, on the other hand, was waiting for some capture data before it send any playback data. The result was a standoff - with nothing getting sent either way.

Simply disabling the code that caused playback to wait on capture resulted in working audio with implicit feedback enabled, and a perfectly solid audio stream with no pops or crackles!

I outlined this fix on the alsa-devel mailing list here:

I hope to get a patch for this into the kernel eventually - right now I am doing some poking around to see if I can find out what other similar devices this fix might work for.

** UPDATE **

A series of patches to implicit feedback handling made it into the kernel (5.11) a while back. I had thought that these changes were fully working on the BOSS GT-1, but it turns out that I just hadn't tested well enough.

Audio playback and capture works, but with periodic dropouts. I get the exact same behavior as I did with the quirk to completely disable implicit feedback.

Changing the GT-1 playback feedback handling from IMPLICIT_FB_SKIP_DEV(0x0582, 0x01d6)  to IMPLICIT_FB_GENERIC_DEV(0x0582, 0x01d6) and applying the endpoint.c patch outlined earlier in this post results in perfect playback and capture for me.

Here is my post on the alsa-devel mailing list about this:

** UPDATE 4/14/2021 **

A version of the above fix has now been submitted as a patch and should eventually get into the mainline kernel. The fix is also being applied to other BOSS devices, such as the rest of the GT family, and the BOSS Katana. Here is the patch:

Monday, September 12, 2016

Coming soon to Nintendo 3DS

We've been hard at work this year to bring support for our games and applications to the Nintendo 3DS. The recent support of the 3DS platform by the Unity engine (which we use for targeting most of our other platforms) made this possible.

PixelMaker will be our first release on Nintendo 3DS. It works great on the 3DS handset - using the bottom screen to draw, while having an overview of the entire scene on the upper screen. We even leveraged our drawing layer feature to provide support for the stereoscopic 3D display. The effect is really quite fun, and we are looking forward to see how people use it.

Even though Unity is primarily targeted at the New Nintendo 3DS, we worked hard to make PixelMaker run on the original 3DS as well. This wasn't easy, given the memory and CPU limitations of the original device, but we are very happy with the result we were able to achieve. I believe we will be the first Unity 3DS release to run on the original 3DS.

We plan to bring our voxel editor VoxelMaker, as well as at least some of our games, to the 3DS soon.

Tuesday, March 29, 2016

PixelMaker - a pixel art and sprite drawing program

I've been thinking about making a sprite editor for a while now. Drawing sprites is a big part of what we do when making our games. We have been using GIMP as our primary drawing tool, and while it works pretty well, it doesn't mesh perfectly with our workflow.

So, a few months ago I finally pulled the trigger and started working on PixelMaker. In order to justify making a polished program (instead of a rough-and-ready developer tool), we plan to release it on various platforms - initially on Wii U (the GamePad and stylus are great for drawing) and then later on mobile/PC.

I'm pretty happy with how it is turning out. It loads instantly, unlike programs like Gimp and Photoshop, and is fast and lean - with the features you need for drawing pixel-y stuff, uncluttered by features you don't need (at least *we* think so - we'll see once we have more customers...)

Our initial feature set for release targets drawing individual pixel art pieces, but future planning includes frame-based animation.

On a more dev-centric note, I recently bolted on a project structure interface for us to manage the art assets for a game - designed to integrate with the custom sprite scaling/shadowing/sheet-packing pipeline we currently use:

We plan to get back to working on our already-well-in-progress next game soon, now switching over to using PixelMaker as our core art creation and management tool.

What next game is that? Well, stay tuned for more on that soon!