Connect-OPZ: using USB audio with norns

This is wonderful! This is crazy timing. I put my OP-Z in a desk drawer today. Was tired of dealing with the usb noise. Fantastic


Cool, I hope it works for you or encourages you in some other way!

This two-device combo plus internet with smartphone is my setup, and I am pretty excited about it. But I really enjoy a proper techno sound, and sculpting in the low end of the frequency spectrum, so I really was a bit troubled by the noise and would rather not get a mixer. This seems to help, partially.

Another thing is to turn off OP-Z charging it’s battery when the USB is connected. Press the Screen [] and the right-most piano key, the green LEDs will turn yellow. See OP-Z manual 1.2 pro-tip

pro-tip: usb charging can be disabled by holding screen and pressing e2 (the right- most piano key). this can sometimes cancel noise related to usb.

when holding screen in this mode the track led lights are yellow.


cool. it seems like a pretty lightweight solution. (7 lines of bash, basically.)

my suggestion to make this happen at system level, rather than triggered from norns interpreter, would be to add another separate service that depends on, or something like that. (instead of actually changing the norns services which are liable to be blasted by updates.)

if there is widespread interest it is worth considering rolling audio device selection into an “official” configuration layer. this is already in the works because there is interest in several areas of custom hardware support that we would like to not have to test directly upstream, and also don’t want to force everything to be a hard fork of the whole norns stack.

alsa_in seems fine. i have not found any usable documentation regarding the “adapters” available for alsa devices in jack2.

(PS: get a mixer! life is better with mixers)


This is in close alignment with my thoughts and the movements of my soul. Except that remark about the mixer :level_slider::level_slider::level_slider::level_slider: :wink:


Nice work! This is relevant to my interests, and I’m hoping to have a chunk of time this holiday season to get back to working on a stable plug-and-play ES-8 implementation, so I’ll be watching here with interest :slight_smile:


Just here to manifest my interest.


I’ve dreamed of a shield hardware fork with an input pre-amp :person_in_lotus_position: maybe someday. always a tiny yamaha mixer up front in the meantime


Also very excited about this. I’ve been using a model:cycles with my norns quite a bit, and having both audio and midi over usb would be really nice.


ooh this is great. thanks for doing this!

Meanwhile I now have a systemd service, and an udev rule to start and stop it on connect and disconnect. It is however broken and doesn’t tear down gracefully. The thing is that starting and stopping the service works fine, but on hardware disconnect something is left in a chaotic state but I cannot find logs what.

I should be making beeps, not configuration files…

If you post the code as you work I may be able to help. I expect some additional work to be needed on shutdown… but to be honest I also don’t know if we’ll run into issues with the C level norns code not responding nicely to having it’s hardware switched live.

All of this can be solved, it’s just a matter of discovering what the blast radius really is.

Edit: because I forgot earlier, has anyone tried to have the norns send it’s output over USB into a computer/ipad? It only recently occurred to me that this might be possible, and it could have some strong utility if it just works. I’m at a loss to begin googling the solution though, presumably there is some protocol that needs support/configuration in jack/alsa/??

1 Like

This is sketchy, but the service in /etc/systemd/system/norns-opz-audio.service is




the udev rule in /etc/udev/rules.d/99-opz.rules

ACTION=="add", SUBSYSTEM=="usb", ATTRS{idVendor}=="2367", ATTRS{idProduct}=="000c", RUN=="/usr/bin/sudo systemctl start norns-opz-audio"
ACTION=="remove", SUBSYSTEM=="usb", ATTRS{idVendor}=="2367", ATTRS{idProduct}=="000c", RUN+="/usr/bin/sudo systemctl stop norns-opz-audio"

Works fine with sudo systemctl start norns-opz-audio and sudo systemctl stop norns-opz-audio, and also comes up when physically connected for the first time, but when the cable is pulled or OP-Z turned off, journalctl -xef starts getting dozens of

Nov 01 05:21:38 norns[32313]: err = -19

per second and I haven’t found a cause or a cure for now.

1 Like

Yeap it works, using the same idea as here, ie running alsa_out, then making a connections in Jack. Or I think it did… (didn’t take notes as it’s not my primary goal right now). Another way to get USB audio out of a norns is the -d hw:0-d hw:1 idea, ie. replace the norns hardware with another device. I tested this earlier, and it works but the way I set it up requires changing a configuration file and rebooting… so all of this is me exploring other opportunities right now.

well f*&$ that’s exciting.

RE: the errors you’re getting. This doesn’t look totally unfamiliar to me after working on hot-plugging the ES-8, but they are very likely from a different software domain. Doing some searching now, have a quarter-baked troubleshooting method in my head, but also don’t have my norns with me today.


The first thing I’d try, just to get a better picture of what’s going on, is to also restart some of the norns services (you can see them in /etc/systemd/system … or similar, again I don’t have access to a linux machine at the moment).

It’s odd that the errors are attributed to connect script… actually, that may indicate that the udev rules have gone haywire and are trying to spam a reconnect for a device that isn’t present.

Yeah I tried restarting all the norns services. Which didn’t help, and also the errors start flooding in even without any udev rules in place if the OP-Z is lost without shutting down the service nicely. Only thing I’ve found to help is a reboot (meh).

PS thanks for thinking aloud @moogah.

ok, this does seem familiar with the failure modes I was seeing when pulling the plug on the es-8.

Raw and naked assumption: the nature of an audio device engages some low level stuff in the OS that needs more than the ordinary udev rule configs to properly disengage. Not sure where to start next… but linux audio forums are where I started digging around.

1 Like

Or turning configuration files into beeps. Hmm an SuperCollider SynthDef idea right there…, or what would ORCΛ say about them…

The service

The udev rule


… this gives me dangerous ideas. :joy:

I saw some nice numbers running up and down in the lower left corner, so just patched a bit of transfer for bangs from the top-left and connected to my OP-Z, running whatever sounds I had from earlier jams.

This systemd service for OP-Z audio turned out pretty sweet wouldn’t you agree?