Norns on Raspberry Pi

simonvanderveldt · 2019-10-18T23:29:10.582Z

This is purely kernel/ALSA level, so I don’t expect any changes to the norns software stack to be at fault.

okyeron · 2019-10-18T23:32:27.110Z

simonvanderveldt:

This is purely kernel/ALSA level

I’m not so sure this is true (as this problem had not come up for me prior to this last release), but I am testing now to see if that’s the case

zebra · 2019-10-18T23:36:15.106Z

i just said i was shutting up, and i already said this, but an alternative test would be, yknow, not running matron (where the changes are) and just running jack/sc

okyeron · 2019-10-19T00:01:46.407Z

if I reboot, stop all norns services and just run jack, no problems.
/usr/bin/jackd -R -P 95 -d alsa -d hw:0 -r 48000 -n 3 -p 128 -S -s

But can’t test from a clean boot since the norns systemd stuff starts even if I disable them. What else do I need to change to keep these from starting at boot?

sudo systemctl disable norns-jack.service
sudo systemctl disable norns-crone.service
sudo systemctl disable norns-matron.service
sudo systemctl disable norns-maiden.service
sudo systemctl disable norns-sclang.service

zebra · 2019-10-19T00:11:59.473Z

sudo systemctl mask norns-matron ?

okyeron · 2019-10-19T01:19:24.144Z

OK - can confirm this is happening at the kernel/ALSA level. (I checked with a buster install without norns installed at all.)

Thank you for bearing with me while I tested this to confirm.

Fix

for (@buma)
(taken from here)

You can reorder the load order of audio devices in alsa-base.conf

sudo nano /etc/modprobe.d/alsa-base.conf

then add


# This sets the index value of the cards but doesn't reorder.
options snd_usb_audio index=-2
options snd_soc_rpi_proto index=0

# Does the reordering.
options snd slots=snd_soc_rpi_proto, snd_usb_audio

As for why these midi devices are showing up as snd_usb_audio devices? No idea yet.

Dogma · 2019-10-19T07:39:51.639Z

Is this the metric halo MIO? If so which one and are you using the 3d card?

TheTechnobear · 2019-10-19T07:49:49.480Z

okyeron:

But can’t test from a clean boot since the norns systemd stuff starts even if I disable them. What else do I need to change to keep these from starting at boot?

You don’t need to disable the individual services.
You should instead disable the target.
Eg

sudo systemctl disable norns.target

buma · 2019-10-19T09:58:39.736Z

Thank you all for your replies ! Really appreciated. The good news is that the issue seems to be fixed now (see below)

To clear up confusion about the Midi device, the Iconnectivity MIO is just a 30€ USB Midi to Din converter and doesn’t have any audio pass-thru feature unlike the IconnectMIDI2+ or 4+ made by the same manufacturer. It’s not a Metric Halo either, only a simple converter

These are the result of cat /proc/asound/modules in two different scenarios:

A . Norns booted without the MIO already connected and connected after
0 snd_soc_rpi_proto
1 snd_usb_audio

B. Norns booted with the MIO already connected. (causing the error)
0 snd_usb_audio
1 snd_soc_rpi_proto

simonvanderveldt:

What hardware are you running this on and which distro are you using? Did you change any system config for your primary soundcard (which one?) to work?

I’m running this on a RPI3B+, Raspbian Stretch and the soundcard is not an external USB card but a WM8731 like Fates. The onboard RPI soundcard is blacklisted. The system configuration and install process is almost identical as Fates. (It’s mostly the config and install process based on the work of @okyeron @TheTechnobear and others )

Yes, the MIO enumerates as a USB audio interface, therefore causing a problem with the main soundcard (not the onboard RPI audio but a WM8731 like Fates) It seems to be the case with other Midi devices as @okyeron mentioned. Yes, we share the same configuration.

Modifying alsa-base.conf as you’ve suggested above has fixed the issue, thanks a lot. I think I remember we used to do something similar from the very first « Norns on Raspi install instructions », then this step became optional. I’ll update the install scripts.

And today I will test the new multiport devices functionality with an IconnectMIDI2 this time, it’s great to have this feature !

Thanks again

simonvanderveldt · 2019-10-19T10:45:57.939Z

Thanks for the info and glad that it’s all working again

Could you maybe share the output from aplay -l with the MIO connected as well? (I’m aware you know what’s happening, I’d just like to have a complete datapoint).

buma · 2019-10-19T10:58:47.048Z

Yes, sure.

192.168.1.18 ~ $ aplay -l
**** List of PLAYBACK Hardware Devices ****
card 0: sndrpiproto [snd_rpi_proto], device 0: WM8731 HiFi wm8731-hifi-0 []
  Subdevices: 0/1
  Subdevice #0: subdevice #0

simonvanderveldt · 2019-10-19T11:05:24.634Z

That’s without the MIO connected I assume?

buma · 2019-10-19T11:21:08.649Z

No, that was with the MIO connected. I’ve just tested and the result is the same without MIO connected. Both following the fix in alsa-base.conf and the result is identical without the fix.
I can do more tests if it’s helpful, I’m available

buma · 2019-10-19T11:45:03.100Z

Oh, there’s one more thing I’d like to mention, it’s unrelated to the previous issue

If I make a typo in a script, for example writing screnn.move(20,30) instead of writing screen.move(20,30) this immediately breaks everything. I mean that it goes back to the main screen displaying the name of the script but the buttons and encoders become unresponsive.

Even if I fix the mistake and run the script again in Maiden, the only way of getting back to normal is to reboot the Raspberry Pi.

I’m often making a small typing mistake (or worse) when writing scripts in Maiden and this generally leads to an «attempt to index a nil value », but i think it used to go back to normal immediately after fixing the typo and without requiring a reboot.

I’m not sure yet but I think it happens only if the mistake is done within the redraw() function.

Has anybody noticed that too or does it happen only with my setup ?
If somebody wants to test on Fates maybe…

Here’s a very basic script containing a typo on line 24

-- scriptname: short script description
-- v1.0.0 @author
-- llllllll.co/t/22222



function init()
  -- initialization
  redraw()
end

function key(n,z)
  -- key actions: n = number, z = state
end

function enc(n,d)
  -- encoder actions: n = number, d = delta
end

function redraw()
  -- screen redraw
  screen.clear()
  screen.move(20,30)
  scree.text("hello")
  screen.update()
end

function cleanup()
  -- deinitialization
end

and this is the output of Matron

norns.script.load(“code/untitled.lua”)

script load: /home/we/dust/code/untitled.lua

cleanup

script clear

pset >> write: /home/we/dust/data/system.pset

script run

Engine.register_commands; count: 0

___ engine commands ___

___ polls ___

amp_in_l

amp_in_r
amp_out_l
amp_out_r
cpu_avg

cpu_peak

pitch_in_l

pitch_in_r

script init

lua:
/home/we/dust/code/untitled.lua:24: attempt to index a nil value (global ‘scree’)
stack traceback:
/home/we/dust/code/untitled.lua:24: in function ‘redraw’
/home/we/norns/lua/core/menu.lua:193: in field ‘set_mode’
/home/we/norns/lua/core/menu.lua:129: in field ‘init_done’
/home/we/norns/lua/core/engine.lua:90: in function </home/we/norns/lua/core/engine.lua:88>

okyeron · 2019-10-19T20:28:17.501Z

I can confirm that I get a “locked up” situation when I run that test script with the “scree” typo. (pi4 with most recent norns version from github pull today 10/20/2019)

But - if I fix the typo, then save/send the script again from maiden, it will clear and the buttons/encoders become functional again (but only if I hit button one first). At this point if I load the same or another script, that script name will show on the menu page, but the display will not update to that scripts display page.

Subsequent script loads give errors - like switching to Rebound I get lua: /home/we/norns/lua/lib/musicutil.lua:310: attempt to compare nil with number

SYSTEM>RESET gets things back to normal.

buma · 2019-10-19T20:36:05.122Z

okyeron:

But - if I fix the typo, then save/send the script again from maiden, it will clear and the buttons/encoders become functional again (but only if I hit button one first). At this point if I load the same or another script, that script name will show on the menu page, but the display will not update to that scripts display page.

Ah, thanks @okyeron for testing this
So, when this happens, hit button 1 then reset. Noted From now on I will be extremely careful when I write something in the redraw() function because it’s not very handy

ngwese · 2019-10-19T20:38:36.993Z

okyeron:

But - if I fix the typo, then save/send the script again from maiden, it will clear and the buttons/encoders become functional again (but only if I hit button one first). At this point if I load the same or another script, that script name will show on the menu page, but the display will not update to that scripts display page.

Subsequent script loads give errors - like switching to Rebound I get lua: /home/we/norns/lua/lib/musicutil.lua:310: attempt to compare nil with number

SYSTEM>RESET gets things back to normal.

A quicker way to get matron back to a clean state after saving the file would be to just run ;restart in the matron REPL within maiden.

The ;restart command is implemented such that even if matron is not functioning it will still be restarted.

buma · 2019-10-19T20:42:49.590Z

Ah yes, duly noted, easier indeed
Thanks

martindunne · 2019-10-22T11:54:15.844Z

still getting supercollider fail after fix?
i have a diy norns using fates disk image with audioinjector soundcard. if i just have my launchpad plugged in to rpi then no problems but when i have my usb to midi plugged in als this is when i get the error.

okyeron · 2019-10-22T14:42:42.530Z

When both devices are plugged in - reboot and post the output from cat /proc/asound/modules