It is an issue that this program exists. I would rather have it the other way. This could be an udev setup, an amendment of the systemd service norns-jack, part of the norns configuration in SYSTEM > DEVICES or something like that, rather than one of programs which I would rather be about making bleeps and bloops. This is a kind of a workaround, and should go away.

Better sound quality and lower CPU, according to website https://kokkinizita.linuxaudio.org/linuxaudio/zita-ajbridge-doc/

Look, science!!

a2j

alsa_in

A drop-in replacement, give it a shot.

https://jackaudio.org/api/group__PortFunctions.html#gaf2bd9f649c51dafdb382847f0c15963f

This makes the little utility a bit more complicated to use, well double as complicated, but this would help with #1 and be a bit more specific maybe. Output isn't working anyway at this point.

Will there be feedback if both are enabled? If yes, this is harmful to human bodies. If not, yeah for OP-Z sampling and re-sampling and other things.

Looks like the pen is left up at some point during the first run of the program. The redraw function clears it.

Matron mods are a new feature in beta, suggested to check out in lllllllines DM.

A hook based architecture, I imagine the hook enabling/disabling the #7, perhaps by activating/disactivating a udev rule.

If the OP-Z disconnects e.g. by removing cable or turning it off while this thing is enabled, the alsa_in process is left confused and start producing errors fast. This slows down norns, so this event needs to be recovered from. udev rules would make so much sense, rather than having a program like this in the first place.

The script blocks the main thread as the current status is periodically polled. This is not cool, and e.g. make navigating the main norns menus sluggish. Re-implement the poll as a separate thread.

RasPi ie. norns is multicore. Investigate would it be worth running alsa_in and alsa_out on a specific core if norns is not using them... which I presume it is but investigate.

From Oootini

FYI in this update, it seems the screen levels have been tweaked to be 0-15, to match grid messages i guess. Previously, screen.level(16) set max brightness on a pixel.

Not great. How to reference current directory in (norns) Lua?

There seems to be audio glitch artifacts when this thing is enabled. Someone please help get rid of them, I have not been able to find their cause and what to do with them. Maybe tune the alsa_in and alsa_out?

Or alternatively reconceptualize them as an opportunity rather than a problem, and as input into creative process. They sound good with reverb on them ♫.

https://soundcloud.com/user-976929187/norns-glitching-then-running-alsa_in-and-alsa_out

One idea would be to amend the norns systemd service norns-jackd which is defined in file /etc/systemd/system/norns-jack.service, and change it's -d hw:0 to -d hw:1for alsa.

A variation of the above idea would be to have a different, separate service which connects to -d hw:1 (or by name) to replaces the norns-jack service, perhaps called something like norns-jack-opz.service, and alternate between these two. systemctl --quiet is-enabled norns-jack etc. can be used to programmatically check if a service is currently running.

This would spare running separate processes which eat a lot of CPU. At the same time, this would disable the norns input and output.

It would (partially) make sense to do this at system level rather than a norns program. This would be done by adding udev rule in /etc/udev/rules.d plus writing a program which starts alsa_in and alsa_out when the OP-Z is plugged in and adds the jack routes, and tears this setup down when the OP-Z is disconnected from USB.