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

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

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

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

sudo systemctl mask norns-matron ?

1 Like

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 (@Nordseele)
(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.

5 Likes

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

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

sudo systemctl disable norns.target
1 Like

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 :slight_smile:

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

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 :slight_smile: )

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 ! :wink:

Thanks again :wink:

1 Like

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

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

1 Like

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

That’s without the MIO connected I assume?

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 :slight_smile:

1 Like

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>

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.

1 Like

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

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.

2 Likes

Ah yes, duly noted, easier indeed :slight_smile:
Thanks

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. :confused:

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