-
Notifications
You must be signed in to change notification settings - Fork 3
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Reimplement as a systemd service #7
Comments
A problem is that this is outside of the norns product, and is messing with the operating system. A dangerous idea. |
Or another variation, the middle ground actually, to run the |
Made an udev rule with |
Ok works with this udev-rule in
and the following user service in
Now, how to package this for benefit and enjoyment of norns users, since these are both changes outside of |
Questions:
In testing today I've got my M8 tracker working and now also a Zoom H1 Recorder. I'm curious to see if this approach could be adapted to allow for a more generic set of scripts without having to have different scripts/rules for every possible device. |
Yes that's right. This is sketchy! A more generic rule would definitely respond to all PCM devices. That is possible by listening to kernel events. There is some inference then to be made for |
The udev rule takes glob patterns, e.g. Maybe one could generate service descriptions on the fly? ;) |
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:1
for 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 likenorns-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 startsalsa_in
andalsa_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.The text was updated successfully, but these errors were encountered: