i am trying to better understand the demand for partial kits, particularly SMD-populated boards w/o the rest of the kit parts. please follow up if there are other factors.

  • cost: hard to afford a single unit
  • cost: desire for multiple units
  • already have other components
  • making a custom case, or don’t want to use the kit knobs and/or enclosure/etc
  • tried to hand-populate SMD and failed
  • enjoy building kits, but SMD is too hard
  • sourcing a PCB is too difficult

0 voters

and here’s just a general DIY poll

  • source everything DIY
  • SMD-populated PCB alone
  • kit with SMD-PCB and parts, no enclosure or mechanical
    • (existing shield kit) requires soldering
    • no soldering required

0 voters

2 Likes

IMO, the kit as listed is very economical. considering the ecosystem, it is one of, if not the most incredible value in synthesis right now.

6 Likes

Just my experience on this - I wouldn’t have built the Norns Shield had a kit not been available - I’d have found it too intimidating as I’ve done very little DIY. Having built one using the kit and having found it an overwhelmingly positive experience I’d perhaps have a crack at sourcing the individual components myself next time. But I’d have no idea where to start with sourcing the PCB via a group-buy etc. I bought an original Norns from y’all way back when but had to sell it during a rough spot.

1 Like

Ok so a shield kit arrived today :package:, now i need to put it together somehow (planning to find someone to pay for it, in Copenhagen). I have a couple of loose concepts for programs, but no idea about the sound side of things. I’m pretty excited actually.


I told you about this problem, how can i solve it?

i believe this script has a bug – it creates the same trouble on stock norns as well as shield (seems like it’s overloading the CPU). please let the script’s author know (and post that helpful video) on the script’s thread: Grd

other applications have this problem too

if they all sound like the artifact you posted, then those scripts are hitting the CPU in unexpected ways. for example, the Grd trouble was very easy to reproduce and verify that it was a scripting issue. if you can provide reproducible steps for other scripts, we can investigate to determine if it’s a script issue or a hardware issue – please either email help@monome.org or post to the script threads which are problematic.

unless this is happening with every script? so far you have mentioned Grd and Pools. happy to help test more :slight_smile:

@alley_cam Thanks so much for the help. I fixed my problem by reflowing the pi header.

Separate Q for you or anyone here: is the Sleep mode supposed to work in reverse? Or is it just a “gentler” way of turning off the unit. I ask because I can’t get it to “wake up”.

1 Like

No. Sleep Is actually “shut down” on shield. You need to power cycle to turn it back on again.

(“Sleep” may stay in the display because the OLED still has power from the pi, but the pi OS is shutdown after the green led stops blinking)

1 Like

It’s the ONLY way of turning off the unit, else risk data corruption

i’m planning an update which has more guidance and correct language for the shield re: sleep/shutdown

3 Likes

Thank you @Cementimental, @okyeron. I will be sure to use Sleep mode to shut down going forward.

One last Q: is the red light supposed to mean the unit is not getting sufficient power? Or is it supposed to toggle as it’s processing?

it is dependent on the capability of the machine. with smallest ‘delta’ and largest ‘duration’ one can spawn a few hundreds of overlapping sound, which is not a problem for example for RPi4.

This is done internally in SuperCollider with Synth.grain and self-free done action.

ah, gotcha – very helpful to know! Pi 4 is not officially supported for norns shield, unfortunately. hmm. this is a curious situation. i’m curious what we can do about scripts which push on the limits of the 3b+ – i’ve asked the core development team, though, and i’ll report what they say.

See here for a full guide to raspberry pi status lights; https://elinux.org/R-Pi_Troubleshooting#Normal_LED_status

1 Like

By getting the model of the underlying Raspberry Pi one could have different range of min/max param values accordingly. That could be a scripting guideline.

2 Likes

I will note it down in the original thread. Thanks !

That’d be useful esp. for engines that has no ‘voice’ structure (i.e. FreeSelfWhenDone or similar in SuperCollider). But how can Lua know on what it’s running?

Well, there might be a better way, but this should do:

function init()
  local raspi_model = util.os_capture('cat /proc/device-tree/model')
  print("raspi_model="..raspi_model)

-- [...]

@yota loving your work btw.

2 Likes