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

1 Like
#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

1 Like
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)

1 Like
#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.

1 Like
#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?

#321

…built in battery :wink:

But in all seriousness hitting the reset button on the bottom of the device could in theory cause filesystem corruption. The norns device isn’t using an SD card - the cm3 module has a 4GB eMMC which has higher write throughput than an SD card and potentially different buffering characteristics as a result.

The fact that your SD card occasionally mounts read-only sound more like a system configuration thing. Forgive me for not knowing the specifics in the case of an rPI distro but most Linux/UNIX systems have the option of attempting to repair filesystem on boot if it wasn’t unmounted cleanly or to simply mount the filesystem read-only if it wasn’t cleanly unmounted. FWIW I suspect you might be running into the later situation - a system configured to be conservative and mount the fs read only.

#322

fsck ?

ive been meaning to checkout overlayfs as an option for readonly fs.
organelle, uses a simple approach of having rootfs readonly most of the time, but then making it writeable when doing things like installing. then using a ramfs (tmp) for transitory data.
then when I introduced patches on an sdcard (rather than usb which was the normal case) , I just added a second writeable partition

#323

The filesystem will flip into read-only mode during a system upgrade, no reboot required. This isn’t a configuration problem.

I’m familiar with fsck but I’d rather not have to do a file system check because I’d prefer if the filesystem not be corrupted. It sounds like the organelle design is closer to what I’m looking for.

#324

Does anyone know where to look for changing the GPIO pins to hook up encoders and buttons?

I’ve tried looking through norns/matron/src/hardware/gpio but nothing is standing out

#325

you have to change the norns-buttons-encoders-overlay.dts file

it can be found here:

and has to be converted into a .dtbo file by using

dtc -W no-unit_address_vs_reg -@ -I dts -O dtb -o norns-buttons-encoders.dtbo norns-buttons-encoders-overlay.dts

and place into /boot/overlays

so far as a starting point. :wink:

3 Likes
#326

Would it be a crazy idea to use a terminal emulator as the OLED screen? 128x64? No problem! That’s high resolution compared to an emulator a friend of mine put together while developing for a 35x45 pixel display made of milk crates and beer bottles called Flashen Taschen.

I haven’t read over the code but he made a 24bit color screen emulator that renders in a TTY. This is pretty important for development since there is literally only one of the 9 foot by 7 foot F~T screens :wink:

So…all the Cairo Linux framebuffer stuff in matron is coupled to a real display device. What if (pure imagination) there is some kind of /dev/fb => 8 bit ASCII utility?

In leiu of that. I’ll check out how hzeller did his version.

1 Like
#327

So I’m having quite a few issues getting encoders and buttons working with the norns stack (fried 2 rpis), so I was wondering, is there an easy way to replace the physical encoders with OSC controls?

I saw the latest study make extensive use of it, however I understand that the supercollider (crone?) level is separate from the hardware (matron?) level, so it’s probably not a quick solution at this point. Just thought I’d ask the question.

#328

What happened with the encoders you used that the whole board let out the magic smoke? Was it a short circuit? IIRC there are some Adafruit tutorials that describe how to wire a rotary encoder to an RPi.

Regarding OSC, I got TouchOSC working on a cheap Kindle Fire tablet. This is described in the 5th study.