Connect-OPZ: using USB audio with norns

[xmacex]

My setup is the norns shield + OP-Z. It is a lovely combo. However, pushing audio from the headphone output of the latter to the input of the former gives a low signal even with OP-Z volume is turned all the way up, and so sound quality isn’t great. Sure my audio cable isn’t great either. But since I am connecting these two devices with USB anyway for MIDI, I wanted to pass audio too.

So I made a little norns program for it, called connect-opz. And while there are some issues, it works – the audio cable is gone.

Basically I open the program, enable OP-Z, and from then on OP-Z is the audio device for all other programs, without disabling norns’ own audio inputs and outputs.

This is a bit of a private project, but I want to shared it regardless. It is written for a specific device (OP-Z) and for a specific user (me), but the idea would generalize to standards compliant USB audio devices. Reimplementing this whole contraption as part of the norns configuration as udev rules etc would perhaps make more sense, or re-starting jack/alsa with the OP-Z as the audio device instead of, not together with the norns audio (-d hw:0 → -d hw:1). My desire is that this program goes away.

But this is it for now, and I also am looking for some excuses to write these norns programs and “staying within the (norns) product” rather than spend all my time doing basically GNU/Linux configuration – though I am convinced this would be better solved another way. Comments and ideas welcome.

Warning: please always disable OP-Z in the program before disconnecting it or turning it off. Not doing so results in loud noises which can harm your hearing, and also leave your norns in an unstable state until a restart.

Requirements

• norns
• teenage engineering OP-Z

Installation

Open Maiden REPL for Lua and run

;install https://github.com/xmacex/connect-opz

Troubleshooting

If you disconnected or turned off OP-Z without disabling it in the program first (please don’t do it), please restart norns to get rid of a faulty process running on norns.

xmacex/connect-opz

[MatthewAshmore]

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

[xmacex]

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.

[zebra]

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 norns.target, 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)

[xmacex]

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

[moogah]

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

[LLK]

@zebra

if there is widespread interest it is worth considering rolling audio device selection into an “official” configuration layer.

Just here to manifest my interest.

[andrew]

@zebra

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

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

[gimber]

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.

[scazan]

ooh this is great. thanks for doing this!

[xmacex]

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…

[moogah]

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/??

[xmacex]

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

[Unit]
After=sound.target

[Service]
Type=simple
User=we
Group=we
LimitRTPRIO=95
LimitMEMLOCK=infinity
ExecStart=/home/we/dust/code/xmacex/connect-opz/lib/connect-opz.sh
ExecStop=/home/we/dust/code/xmacex/connect-opz/lib/disconnect-opz.sh
RemainAfterExit=True

[Install]
WantedBy=norns.target

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 connect-opz.sh[32313]: err = -19

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

[xmacex]

@moogah

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/??

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.

[moogah]

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.

[moogah]

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.

[xmacex]

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.

[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.

[xmacex]

@xmacex

I should be making beeps, not configuration files…

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

[moogah]

… this gives me dangerous ideas.