I’d be happy to pair with you (or anyone else) to help with the upgrade if we can make timezones etc. work. The upgrade of my 2020 shield went fine and I have some experience of norns and this kind of thing. Drop me a PM.
6 Likes
maybe stupid question and sorry if you said already:
are you using a 3A power supply with the pi4?
older pis use 2.5A supply. this might work with pi4 (tho it is !!not recommended!!) until you start pushing the system (e.g. with audio stack and all the peripherals)
[ed] ah right
yes i expect its exactly burst draw at boot. audio codec ends up misconfigured or something. restarting JACK won’t help b/c issue ids lower level. i’m just surprised the soundcard is seen by ALSA in that case, and we’re not seeing more complaints in dmesg, so it remains just a guess
Thanks buddy! Might just do that…
yes i am using the official supply with 3 amps
2 Likes
I’m still very new here, so please forgive me if this should go somewhere else. Is anyone else having trouble with the Boingg script on this new image? It was working ok for me on my previous hacked together setup with unofficial hardware. Now I’m using a true norns shield and this latest image. The graphics for Boingg show up on the screen and I can place a ball and watch it bounce. However, when the bounce occurs there is no sounds and the lines below #script init in the log pasted below show up in the REPL at the moment there should have been a note played. I noticed the engine is PolySub and saw there were changes in this image pertaining to that, but don’t know enough to make the necessary adjustments.
REPL output:
# script clear
pset >> write: /home/we/dust/data/cyrene/cyrene-01.pset
calling: passthrough post cleanup
# script load: /home/we/dust/code/boingg/boingg.lua
calling: passthrough
# script run
loading engine: PolySub
>> reading PMAP /home/we/dust/data/boingg/boingg.pmap
m.read: /home/we/dust/data/boingg/boingg.pmap not read.
lua: /home/we/norns/lua/core/clock.lua:59: bad argument #1 to 'resume' (thread expected)
stack traceback:
[C]: in function 'coroutine.resume'
/home/we/norns/lua/core/clock.lua:59: in function 'core/clock.resume'
lua: /home/we/norns/lua/core/clock.lua:59: bad argument #1 to 'resume' (thread expected)
stack traceback:
[C]: in function 'coroutine.resume'
/home/we/norns/lua/core/clock.lua:59: in function 'core/clock.resume'
lua: /home/we/norns/lua/core/paramset.lua:423: invalid paramset index: swing_amount
stack traceback:
[C]: in function 'error'
/home/we/norns/lua/core/paramset.lua:423: in function 'core/paramset.lookup_param'
/home/we/norns/lua/core/paramset.lua:327: in function 'core/paramset.get'
/home/we/dust/code/cyrene/lib/arcify.lua:122: in upvalue 'redraw_ring'
/home/we/dust/code/cyrene/lib/arcify.lua:146: in upvalue 'redraw_all'
/home/we/dust/code/cyrene/lib/arcify.lua:217: in field 'event'
/home/we/norns/lua/core/metro.lua:164: in function </home/we/norns/lua/core/metro.lua:160>
Engine.register_commands; count: 25
___ engine commands ___
ampAtk f
ampCurve f
ampDec f
ampRel f
ampSus f
cut f
cutAtk f
cutCurve f
cutDec f
cutEnvAmt f
cutRel f
cutSus f
detune f
fgain f
hzLag f
level f
noise f
shape f
solo if
start if
stop i
stopAll
sub f
timbre f
width f
___ 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/norns/lua/core/paramset.lua:423: invalid paramset index: output
stack traceback:
[C]: in function 'error'
/home/we/norns/lua/core/paramset.lua:423: in function 'core/paramset.lookup_param'
/home/we/norns/lua/core/paramset.lua:327: in function 'core/paramset.get'
/home/we/dust/code/boingg/boingg.lua:99: in upvalue 'update_cycle'
/home/we/dust/code/boingg/boingg.lua:120: in field 'event'
/home/we/norns/lua/core/metro.lua:164: in function </home/we/norns/lua/core/metro.lua:160>
1 Like
that is/was a bug with boingg, i just fixed it. update your boingg script and you should be gtg 
6 Likes
Wow thanks for the quick fix! Confirmed boingg is working as expected for me now.
4 Likes
So am I correct in saying that if I have a shield, I can ignore this vid until 3:40? It’s just the Etcher/sd card stuff, and no need to dismantle the shield and flick a switch?
@tehn I’m not concerned about losing anything. Just concerned about the actual process.
correct! just pull the card, do the etcher / imager process as outlined in that part of the video / docs, then you’re set to put the card back in shield, expand your file system (!!), and continue restoring your data by downloading fresh copies of the scripts you want and migrating your data and audio back in over wifi. the etcher flashing + validation process for a shield card should take around 10 minutes total.
1 Like
I didn’t see this answered elsewhere in the thread (my apologies if I missed it). To ensure we’re flashing the correct image on a Shield we’d use the date code on the top left corner?
For example mine says, 200323 and I’m using an R Pi 3, so I would flash rpi3-cs4270, correct?
Edit damn fat fingers 
Good catch, @Klinik
1 Like
Not CS4279 but 4270 !
2 Likes
Just installed the new image and the brand new shield received few days ago. (Raspberry 4 with the new codec)
All went smooth until expanding filesystem, which was OK to process. But after the reboot I got a “Supercollider failure”.
Turned off the machine and now it seems OK.
Don’t know exactly what happened
I flashed the image, and Awake is up and running . So far, so good.
Now my question is about bringing the data and audio folders back in. In my old data folder, there are sub folders for many of my scripts. If I copy those data folders to the new and improved dust folder, and then download fresh copies of the scripts through Maiden, will that save any time? Or, will downloading and installing the new scripts simply create new sub folders for those scripts?
Similarly, for example, I have audio folders for Arcologies and mx.samples, among others - the mx.samples folder is quite large. Am I better off copying the audio folders for these scripts into the new dust folder manually, or re-downloading the audio through the newly installed script? Does it matter?
Thanks in advance again for all your help!
glad you’re up and running!
your backed up data folder will contain:
-
system.state: the parameter settings for the system, eg. reverb, compressor, levels, your list of previously-connected MIDI devices -
system.favorites: the scripts you highlighted as favorites, which will show at the top of the script list with an asterisk (once they’re reinstalled) - subfolders for each script, which contain:
- a
.pmapfile: MIDI mappings which you created for that script -
.psetfiles: presets you saved for that script -
pset-last.txt: the last preset you had loaded for that script
- a
so, it’s more a matter of whether you want to start totally fresh with those scripts, or if you want to restore your previously-generated sessions / play. it’s true that when you run a newly-downloaded script for the first time, a data subfolder is created for it if one does not already exist – but if you want to restore your previous work with a script, you should restore the data subfolders from your backup. running the newly-downloaded script on your 220306 software will not overwrite the restored data subfolders – rather, it will respect their presence and integrate your restored PMAPs and PSETs into the newly downloaded copies of the scripts.
for audio, you can also just do a blanket restore. for example, if you restore your backed-up audio folder with all your mx.samples libraries, your newly-downloaded mx.samples will see these and surface them in the UI as selectable instruments.
hope this helps! please feel free to ping back with any further q’s / clarifications! 
5 Likes
So I’m running into this exact issue. Each time I try to Select Target the initializing device progress bar runs to completion, then starts over again and gets hung up around 20%.
I do have an older factory Norns and at this point have restarted my Mac (new M1 Mac Pro, os 12.2.1) 3 times, including once when it crashed and restarted itself. I’ve also tried 3 different USB dongles including an official Apple one, and 3 different USB cables. Any other ideas? Happy to go to email but thought others might run into this issue.
sorry to hear about the trouble, hope all’s well otherwise!
just to quickly verify, this is happening with both etcher and Imager?
2 Likes
Oh, I’ve only tried Etcher. Somehow missed the fact Imager could work with a Mac. I’ll try that next, thanks!
Edit: just tried Imager and I think am running into the same issue. Nothing shows up when I click Storage. Again tried different cables and restarting.
this is a weird one to advise, but could you try flipping disk/run switch rapidly a bunch? like, a dozen or so times? apologies for the brute force nature of the suggestion, but this has worked for a few folks. if this doesn’t get it going, let’s move over to help@monome.org
1 Like
I tried a couple bouts of flipping that switch around 20 times. I had a minor Mac OS upgrade I ran, restarted the laptop, tried different cables and dongles, but had the same issue. Thanks again for all the help today, I’ll email now.
EDIT: I brought my Norns to the office today to attempt the command line flash and update. I tried Etcher one last time with a usb cable connected to my apple display and it worked! For the record I tried 2x 3rd party adapters and an official Apple one at home with no luck.
1 Like