Norns on Raspberry Pi

norns

#301

for norns I used stretch without desktop (minimal?) ,

more generally ive used stretch desktop for other things, and never had any issues with networking.
sure some tools are not included in the default install, but that is very much the nature of linux (each distro includes different packages), but nothing vital was missing.

(so as a random guess, perhaps Pixel has introduced some issue, as ive never used pixel)


#302

Not sure if anyone is keeping bleeding edge with this, but I tried to update to the latest versions of Matron, Maiden and Crone last night and failed.

After pulling monome/dust, monome/norns and monome/maiden, running ./waf configure and ./waf, Matron broke on reboot and is temporarily resolved on running ./stop.sh and ./start.sh until the next restart.

This also seems to have affected my norns-init.service as a wifi script and potentially the cpu governor no longer process.

I can provide more information in a few hours if anyone else is interested.


#303
norns-matron.service output ● norns-matron.service Loaded: loaded (/etc/systemd/system/norns-matron.service; disabled; vendor preset: enabled) Active: failed (Result: signal) since Wed 2018-08-29 11:29:32 UTC; 21min ago Process: 409 ExecStart=/home/we/norns/build/ws-wrapper/ws-wrapper /home/we/norns/build/matron/matron ws://*:5555 (code=killed, signal=ABRT) Main PID: 409 (code=killed, signal=ABRT)

Aug 29 11:29:32 norns systemd[1]: Started norns-matron.service.
Aug 29 11:29:32 norns ws-wrapper[409]: ws-wrapper: …/ws-wrapper/src/main.c:43: bind_sock: Assertion `( *eid = nn_bind(*sock, url) ) >= 0’ failed.
Aug 29 11:29:32 norns ws-wrapper[409]: attempting to bind socket at url /home/we/norns/build/matron/matron
Aug 29 11:29:32 norns systemd[1]: norns-matron.service: Main process exited, code=killed, status=6/ABRT
Aug 29 11:29:32 norns systemd[1]: norns-matron.service: Unit entered failed state.
Aug 29 11:29:32 norns systemd[1]: norns-matron.service: Failed with result ‘signal’.


#304

You probably need to update the systems units as well. They live in the norns-image repo


#305

yeah, I keep my rPI on the bleeding edge - though my fork probably needs a little tweak for the midi changes just merged in.

as @simonvanderveldt said, check the services - this issue is probably to do with the order of parameters changing for ws-wrapper.

if you are using master, you will also need to update your supercollider image, and install supernova.
as mentioned here:


#306

Has anyone developed an “update procedure” to use a full update like the one dropped today?

My first thought is to unpack the .tgz and make various changes to the sources, repack it and run the update.

Thoughts/Suggestions?


#307

have you tried running the update on the rpi? if you take a look at how it’s built you’ll see there isn’t anything exotic going on


#308

Not as yet - but I assume it’s going to overwrite my screen.c changes (using fb1) and encoder setup. Thought I’d checkin before I break anything.


#309

yeah, Id assume so too…

what I do is merge master into my fork, then just deal with any conflicts that occur.
(I know what Ive changed, so its easy enough to see what the resolution is when conflicts occur)

I also tend to track master (to some extent) during its development, which means that its a smaller set of changes each time, so easier to spot whats going on - this also means Im testing norns during its development, which gives it an ‘extra set of eyes’

(If I had to have a ‘live box’ ready to go, Id use 2 sdcards or 2 rPIs, then keep one for dev, one for ‘production’)

anyway, main changes I had to make (apart from tracking the screen api changes which are specific to my fork) were the ws-wrapper change, and the move to supernova.


#310

It looks like maiden got moved around in the new update.

There’s now a regular maiden directory with maiden.arm and a start.sh script (which is launched from norns-image/init-norns.sh

Thus for a new build it appears it’s no longer necessary to install maiden separately and change norns-maiden.service?


#311

i don’t believe maiden changed in 180828. that change would’ve happened in 180707.

the service files are in norns-image and did indeed change. did you check out the guts of the 180828.tgz?


#312

Yeah. I made a few minor changes to the 180828 guts based on my original install notes and ran update.sh manually. I ran into some errors with symlinks like this:

Processing triggers for man-db (2.7.6.1-2) ...
mkdir: cannot create directory ‘/root/.local/share/SuperCollider/Extensions/norns’: No such file or directory

Then I tried running the norns ./waf first and then running sclang before running the sc install script. (This was needed in @TheTechnobear’s original build notes, but I don’t remember why).

After this norns was OK, but maiden wasn’t loading - so I poked around and sorted it out. Perhaps I was still using the older version of maiden that I compiled rather than what was installed by 180707 (?).

Seems to be running OK now


#313

Running sclang during first install is just to create the user extension folder ( as the sc/installl script assumes it’s there) , however it’s good practice to do when upgrading to just check SC and crone are ‘happy’ :slight_smile:
(Easier than checking the service logs :))


#314

Progress report

I updated to the latest norns-image, norns, and dust. Everything seems to be going smoothly, however @tehn and @artfwo scripts are throwing errors

Flin Maiden Output

norns.script.load(“artfwo/flin.lua”)

script load

cleanup

script clear

SCRIPT ERROR: load fail

/home/we/dust/scripts/artfwo/flin.lua:12: attempt to call a nil value (field ‘connect’)

stack traceback:

/home/we/norns/lua/norns.lua:159: in field ‘connect’

/home/we/dust/scripts/artfwo/flin.lua:12: in main chunk

[C]: in function ‘dofile’

/home/we/norns/lua/script.lua:72: in function </home/we/norns/lua/script.lua:72>

[C]: in function ‘xpcall’

/home/we/norns/lua/norns.lua:160: in field ‘try’

/home/we/norns/lua/script.lua:72: in function ‘script.load’

(…tail calls…)

<ok>


Awake Maiden Output

norns.script.load(“tehn/awake.lua”)

script load

cleanup

script clear

SCRIPT ERROR: load fail

/home/we/dust/scripts/tehn/awake.lua:30: attempt to call a nil value (field ‘connect’)

stack traceback:

/home/we/norns/lua/norns.lua:159: in field ‘connect’

/home/we/dust/scripts/tehn/awake.lua:30: in main chunk

[C]: in function ‘dofile’

/home/we/norns/lua/script.lua:72: in function </home/we/norns/lua/script.lua:72>

[C]: in function ‘xpcall’

/home/we/norns/lua/norns.lua:160: in field ‘try’

/home/we/norns/lua/script.lua:72: in function ‘script.load’

(…tail calls…)

<ok

Any tips would be greatly appreciated


Norns: help
#315

Nevermind,

I pulled the latest norns and dust and the problem went away.

Thank you all


#316

I got an rpi + pisound + grid setup running tonight. I had very bad audio timing dropouts when I was powering everything with an LG phone charger that was rated at 5V 1.8 amps.

I solidered headers to the pisound and connected a digital adjustable power supply to the 5V input at 5.1V and everything seemed fine. It seemed weird that the power supply screen informed me that the peak current draw was 0.8 amps which the LG should handle based on the writing on the enclosure.

The kernel was reporting under voltage errors with the LG adapter. Then it stopped with the adjustable power. Does the Norns image use a custom compiled kernel? I have an RT kernel with limits configured for rt priority.

I attached a monitor to the HDMI port and the frame buffer displayed what I imagine is the output for the OLED. That seems cool.

Doing more experiments tomorrow.


#317

that’ll be fine…

I assume this is a rPI3?
if so 2.5A is recommended, and i had issues with under voltage previously when trying to use supplies less that 2A, once I replace that with a 2.5A all was fine.
of course , it all depends on what you have plugged into UBS, what mode the cpu is in etc,etc.

the RI FAQ on power is i think pretty good

(note: not sure what the power requirements are for pisound…
but with my 2.5A supply, Im fine with pisound, hdmi with a 7" waveshare touchscreen powered off it, and usb devices, some powered directly from the rPI)


#318

I spent some time today with my setup connected to an HP E3631A digital DC power supply. The voltage was stable at 5.075 when I set the output to 5.1 V. The current draw would spike to 0.8 amps sometimes.

It appears something is wrong with the software on the device. When I load the TestSine engine, everything is fine. When I load the Sines engine with the same script, supernova immediately consumes over 140% of a CPU core, crone starts reporting xruns and the sound is audibly losing samples.

I changed so many things in the last 24 hours. I’m running code from the master branch in git so I understand why it’s all broken.

Is there an official “release version” of all the four repos in the Norns products? I’d like to start from there.


#319

the current master for all repos is good for the release version. we’ll be careful in the future not to introduce breaking or desynchronized changes. moving to supernova was tricky.


#320

I’ve discovered that my understanding of the ext4 filesystem is incorrect. I thought the journaling feature would ensure no data is corrupted if a mounted ext4 filesystem suddenly loses power, in my case pulling the power plug out of a Raspberry Pi rather than performing a shut down procedure from the OS.

I now have an SD card that intermittently flips into read-only mode when I do heavy writes, for example, upgrading system packages or compiling the norns repo after an upgrade.

I plan on following this tutorial to put the SD card into read-only mode at boot and use a USB flash drive for patches and samples.

How does the hardware Norns mitigate filesystem corruption when the power is switched off?