Hmm. Would norns not take a straight line in from an OPZ? Would it expect my putting it through an audio interface or some other form of amplification?

Mix page has input at full volume. Shows very low levels of audio

Dunno. I use it a lot with line sources. No you shouldn’t need anything else

Be aware that levels meters show linear amplitude, which is really dumb and which will probably be fixed in next point release

is the OPZ’s output level all the way up?

Yeah, the levels are all the way up. I was wondering if there was something I was missing, cause I get good levels out of my sound interface (like porting ableton through the norns) but very low levels in general. It might just be a DAC issue, but I thought that maybe I might be missing something in the norns software

Okay, part of the issue was the PGA was at 50%. I have upped that and things are much better. Now my biggest issue is that when I attempt to save my alsamixer settings with this command:

sudo alsactl store

I get this returned

alsactl: get_control:256: Cannot read control ‘2,0,0,C Data Buffer,0’: Input/outp ut error

So, apparently with the audio injector, I would need to patch and recompile the kernel, which, let’s face it, I’m NOT doing. There are some oddities in my build, so I am going to just use this as a place holder until getting my hands on both a FATES board AND buying a Norns in the next couple of months. Until then, I guess my norns is a “work station” norns and I will just boost the PGA manually at each startup. Should’ve gone with a PiSound for this build.

:roll_eyes:

Not sure in which thread I should post about the « Supercollider fail » error I encountered after the system boots (it happens on a RPI install) but I think I’ve found the cause. I’m not sure if it’s linked to the latest update.

I tried to increase the timeout in hello.c , tried running sclang after the update, tried updating again.

  • The error disappears if I disconnect the Iconnectivity MIO that is connected to the RPI. If I connect it back and reboot, the error comes back again.

It’s not an audio interface, only a midi (usb to Din) interface but it seems to cause a timeout issue / conflict with Jack and causes this error.

@Nordseele we need to separate this whole debug process out into a RPi (and/or) fates thread, or a github issue on the fates linux installation.

basically we spent a ton of time fixing these sorts of problems over the last several years on the norns image and while i’m happy to help debug, i definitely want to have these issues properly placed on in the right context. it’d be good if the fates image could closely mirror the norns image so time won’t be spent revisiting old issues.

but! on our roadmap is making norns work with more hardware combinations— so it’d be good to have some data points as to what you’re experiencing, so i appreciate the report.

(i need to check if there’s a norns on pi thread to merge this conversation— are you using a fates or which screen interface?)

3 Likes

Thanks for your reply. Sure I understand it’s not possible to do case by case troubleshooting. I posted here because they’re indeed many threads and was not sure where I should post, sorry. No, I’m not using Fates but another Norns on Raspi setup (Norns on a RPi 3B+, NHD display, wm8731 audio) and both used to share the same install/kernel config but many things might have change since June :slight_smile: I never had any issue before the September update but now there’s this « supercollider fail » error. Well, I’d be happy to share further details in another thread about the setup and environment or to post an issue on GitHub if it’s more convenient.

@Nordseele yes please let’s move the discussion of your setup to “norns on raspi” thread or some such.

we are missing a lot of details, like what happens when you run sclang alone, if there’s output from the norns-jack service, &c

if the midi thing is causing jack to hang that might be out of scope for us to figure out or fix.

Yes, sure. I can provide all the details when someone moves the posts into the appropriate thread. I tried running sclang separately etc, I can share the results.

Here’s the output when I run sclang

Here’s the result of a ;restart.sh from Maiden

The setup: Norns installation 191016 on a Raspberry Pi 3B+

It used to work before the September update I think. The only thing I know/discovered is that if a MIO Midi interface (which is not an audio interface like an IconnectMidi2 or 4 and could be detected as an audio interface and cause an interference) is connected to the RPI when I start the device, it will (most of the time) end up with an error: Supercollider fail. That’s what I don’t understand :slight_smile: For some reason it prevents Jack from running correctly, it might be a timeout issue as mentioned in another thread, I tried to increase the timeout in hello.c up to 4000 and then recompiled Norns but that doesn’t solve the problem.

As soon as I disconnect the MIO and reboot the device, it starts without any problem.

Here’s the device https://github.com/nordseele/nordhat
And here are the install files https://github.com/nordseele/nordhat_install/tree/master/install/norns

They’re quite old (June) so many things might have change since then.

It’s not a big deal if I don’t solve this issue, I can still boot up Norns on RPI and then connect the MIO after but I’m sharing it for info :slight_smile:

If anyone has an idea of what I could check in order to solve this issue though, that’d be really cool

I’ve tried to keep the Fates image as close to norns as possible. Pretty much all my changes are just plumbing related (in norns-image rather than norns itself - I’m pulling/using the master norns repo).

More potentially obscure problems could stem from kernel differences?

Once the DIY shield linux build gets released or updated I will look into using it as my base for Fates (since the new build now includes my changes to the display driver).

This sounds related to the new MIDI changes in the new update perhaps?

2 Likes

thanks @Nordseele

key is in supercollider output: “jack server is not running or cannot be started”

it’s not just taking too long (so increasing the timeout won’t help) - jack isn’t starting at all. if this is just a basic weirdness between jack and the midi device, i dunno what we can do about it.

(does booting jack with the thing connected work in a stock rpi environment?)

i’m not in front of norns ATM and can’t remember if journalctl -u norns-jack will actually work to get any jack errors, but that’s what you want to do. will check later.

if the problem just started yesterday, i’d say it seems doubtful but worth checking. (like, our messing with snd_rawmidi_info_set_stream borks jack.)

but if the problem started in september, not possible.

anyways, if this is following my recommended troubleshooting steps above, and sclang borks before matron is run, then absolutely not possible.

1 Like

If I understood @Nordseele’s posts correctly this starting happening with the 191016 update. Perhaps he can clarify which update.

I will try to comb thru that midi update changes and see if anything jumps out at me, but it may be above my current knowledge level.

:shrug I dunno guys

Easy test to revert PR 886 and rebuild. Or like I said, first try sclang without matron

I have to sign off, will revisit this evening

Thanks for your replies @okyeron and @zebra.
I’m not sure when the problem started exactly, I didn’t use Norns this summer, I think I´ve updated it just before receiving Crow last week. I started writing a midi randomizer tool two days ago, that’s how/when I discovered the issue. I did the 191016 update today. Right after the update I thought the issue was gone but later I had to reboot the pi (after writing a typo in a script which happened to block the PI :flushed:) and the error was back until I disconnect the MIO.

I don’t know at the moment, I only have this Norns install on RPI, it’s a very simple device, never had any issue with it, it’s not even a multi port midi device as an Iconnectmidi4.

I could try to re-install the whole thing using the instructions we both used @okyeron but I’m not sure this will solve the problem. Did many things change in the install process since June ? Tomorrow morning I will try to connect an IconnectMidi2 instead of the MIO and see if the error shows up again :slight_smile:

Edit: and I’ll check journalctl too :wink:

if you think its related to the midi, id try unplugging all midi devices, and see if supercollider starts ok then

1 Like

Ah yes it does, like I said as soon as I disconnect the MIO device, it starts without any error, but if the MIO is connected when I start the device, most of the time it will fail to start and will display this error.
It might be related to this particular Midi device so I need to check and try using another one, maybe using an IconnectMidi2 or 4 will do the trick but as I was working with a Nord Drum, the MIO seemed to be the right/simplest tool for the job

I have an iConnectivity mio that I preemptively purchased months ago but haven’t used yet so you’ve got me concerned. I’ll test it out on the x86 SBC I’m prototyping with tonight.

1 Like

Check the logs for jack, which you should be able to do using journalctl -u norns-jack.

Alternatively kill/stop jack (systemctl stop norns-jack) and then manually start jack to see if it work.
This is the command we run https://github.com/monome/norns-image/blob/master/config/norns-jack.service#L11. I dont know if it’s different from the norns on RPi setup.

1 Like

ok, I can reproduce the error as well…

for me, it appears only when I have a couple of midi devices that have multi ports…
if I plug in a blokas midihub and the push 2 (or Virus TI) then I get the error.

also supercollider only fails, if the midi devices are assigned to virtual ports in norns.
i.e if they are not assigned, then there supercollider does not fail.
if I remove them , they norns starts to work again.


also there is another bug…
I, pretty sure the order of the devices listed in the midi setup , should stay as you set them up. (*)
but Im seeing that when I reboot, suddenly the midi devices are being listed in alphabetic order.
so they are moving around…

(*) this is so they retain the virtual address for lua scripts (no?)


sorry, have to dash off now… hope the above is useful…
at least its shows its not specific to the MIO

2 Likes