norns: new image 220306

As this will be my first update, I would appreciate a quick confirmation:

  1. this means I cannot use the update process ON norns?
  2. But instead need to flash the SD card?
  3. After I copy the dust folder back to Norns, everything will be the same as before? Or is there a configuration step to take (e.g. Wifi, midi clock, devices)

yes, that is what it means. there is no update script this time, only a disk image

yes

in general, no, it will not be a total and exact restoration. more specifically:

  • WIFI configuration in particular will not survive. sorry!

  • the top level of ~/dust/data contains system-level configuration files that can be carried over:

    • editor.json
    • grid-settings.state
    • system.favorites
    • system.mods
    • system.state. (<-this one includes clock settings and device port assignments, etc)
  • in general, script-specific preset data under ~/dust/data/<script>/ should carry over, barring the case of breaking script updates.

  • many scripts will be fine to copy over. but these days, there are quite a few scripts that install their own dependency packages in the linux system when they are first run. (yuck!) so in general, i can only advise that scripts should be re-installed to a fresh ~/dust, then any favorite .pset or .pmap files you want to save for particular scripts can be copied over.

7 Likes

Thanks for the update. Just a little thing: there is a mismatch between file names of the disk image on github and in the docs, e.g. norns220306-shield-pi3-cs4270.tgz (github) vs. cs4720.tgz (docs).

oh! there shouldn’t be any specific .tgz-tagged references in the docs, just the callouts which encourage using the cs4720 cs4270 images for older shields and the cs4721 cs4271 (ah! typos discovered!) ones for newer (example), along with the pi3/pi4 consideration. since the norns220306 part of the filename will change with future updates, hardcoding it into the documentation leaves room for error. if you saw any .tgz references, implying an exact filename rather than this general guidance, please let us know where and we will correct it!

1 Like


Hi there, i put the Standard image on my SD card and get an error message on my Norns Shield (from sept 2021) - did i flash the SD card with the wrong image ?

yes — standard is for the machined aluminum version of norns.

no worries tho! for pre-2022 shields running on a pi3, choose the cs4270 file for pi3 (the top one) :slight_smile:

the docs linked on that download page does this a bit, but we can also post a lil matrix on that page which gives direct “if you have ___ and ___ use ___”, if that’d help?

table made!

hardware version software version to download
pre-211028 shield with raspberry pi 3 norns220306-shield-pi3-cs4270.tgz
211028 revision shield with raspberry pi 3 norns220306-shield-pi3-cs4271.tgz
pre-211028 shield with raspberry pi 4 norns220306-shield-pi4-cs4270.tgz
211028 revision shield with raspberry pi 4 norns220306-shield-pi4-cs4271.tgz
machined aluminum norns (aka ‘standard’ norns) norns220306-standard.tgz
4 Likes

Thanks Dan :slightly_smiling_face: Now i installed the right image. I flash the micro SD card with Etcher, and re-powers Norns Shield but keep getting the “Jack Fail” message.

Edit: apparently it helped to pull out all USB cables and try again. Now Norns boot how normal - but when i attach USB devices i get the “Jack Fail message”

Edit 2: did some more investigations. I am able to attach my Grid (Neo) and Nanokotrol2. But When i attach my UM-One interface, I get the “Jack Fail” message when sleep restarting.

Flashed the new image, everything working so far, but norns shield now takes a lot of time to boot up, anyone else having this same issue?

Jack Fail
I have the same “Jack Fail” issue when Korg nanoKONTROL 2 is plugged into USB at the start of Norns Shield (V210330). Other USB devices seem ok. Also the Korg works fine if I plug it in later. So far no other issues in my tests with different scripts, midi, recording etc.

File Names
The thing with the file names was badly described by me: it’s the numbers that are not the same in the docs and the file name on GitHub: 4720 vs. 4270. You can also see it in the screen shot above. Just a small thing really.

1 Like

lolol ah geez, thank you so much. dang, shouldn’t do support right after waking up :sweat_smile:
correcting now! corrected!

sorry to hear about the trouble – grabbing some gear to test out, hang tight!

Does this relate to shields only or should I do this for my factory Norns?

The benefits are only spelled about above in “computer-nerd” jargon :nerd_face:

As a regular person, what’s my reason to update?

Thanks :pray:

3 Likes

I think the reason for updating a factory Norns is so that you can continue on with further later updates.

5 Likes

@alanza’s got it – there are also a few nice things in the 220306 update, like confirmation when deleting a PSET, more stable TAPE number auto-incrementing (so you don’t overwrite TAPEs with the same index), and a reversal of the param name collision errors which would cause init errors on scripts with overlapping params names (more background for the curious).

but yes, the most important bit to note is that after transferring the files you’d like to keep from norns to another computer, a disk wipe + fresh install with the new software is required for you to keep your norns up to date via the menu moving forward:

please let us know if you run into any other q’s!

9 Likes

Thank you @alanza and @dan_derks :pray:

1 Like

seems related?
[ screen is blank after boot with 2+ USB devices · Issue #1488 · monome/norns · GitHub ]
@ngwese those URB errors…

[ed] sorry to be brief, i should mention that i’ve personally had no issues using several simultaenous devices including UM-1 with factory norns/CM3 on this kernel.

I will not be able to investigate more deeply until later this evening but I just preformed the following test:

  • rpi3b-shield running the release image
  • small gauge usb cable and a usb hub for power, essentially a power source that is insufficient to meet peak power demands

I then booted the device multiples times:

  • nothing attached => okay
  • added Roland um-one mkII MIDI interface => okay
  • added iConnectivity mio1 => okay
  • added iConnectivity mio2 => jack fail (i.e three midi interfaces attached)

I would not be too surprised if the new kernel behaves differently from the previous kernel when the device is starved for power. Given that we are also using a different driver to configure the codec I could also imagine that in the presence of under voltage conditions the new driver might not enable the codec.

Long story short I suspect these failures may likely be power related.

UPDATE: I should also add that I’ve observed that the new kernel is more willing to pull the CPU out of performance mode (which we set by default) and force it into on demand mode which drops the CPU clock speed by 50%. Previously this resulted in under voltage warnings and starving USB bus. If the device starts feeling sluggish or boots slowly with lots of USB devices plugged in that could also be an indicator of insufficient power.

7 Likes

The instructions for flashing a shield mention to chose the correct version depending on the codec. How do I find out which one I have? Bought mine from a maker, closed encasing. Is there a menu that shows that?
Thanks!

1 Like

I’m not sure you can tell which codec you have from inside the software, but you can narrow it down a bit - is the charging port usb-c? That’s a pi 4. micro usb? That’s a pi 3b.

And when did you buy it? Unless it was very recently, you can narrow down the date, too :wink:

Anyway, you won’t hurt anything by trying to flash the wrong firmware, it just might not boot / give you JACK FAIL / etc

i’ve deprecated the we repository which had some outdated tests but also had some worthy engines. these engines (including PolySub and PolyPerc from awake ) now live in the core norns repository. there are a handful of scripts that use polysub.lua which is now located in the core. the fix: change include('we/lib/polysub.lua') to require('polysub') and all is well.

This includes KarplusRings, and now awake-rings doesn’t load, how it’s the new code supposed to be in this case: engine.name = 'KarplusRings' ??

You will need the cs4270 image - all the hardware that is in people’s hands today uses that codec. Only the 2022 rev shield boards use the cs4271.

There is no way to see which codec the device has from the menu but the codec is reported as part of the sound card description when by running the following in maiden’s repl: os.execute("aplay -l")

The output will look like this:

**** List of PLAYBACK Hardware Devices ****
card 0: sndrpimonome [snd-rpi-monome], device 0: bcm2835-i2s-cs4270-hifi cs4270-hifi-0 [bcm2835-i2s-cs4270-hifi cs4270-hifi-0]
  Subdevices: 0/1
  Subdevice #0: subdevice #0
true	exit	0

The charging port will help to identify the rpi3 vs rpi4 but that is completely independent of the which codec is on the shield. The most likely combinations as of now are rpi3+cs4270 and soon the 2022 rpi4+cs4271.

1 Like