OK, I received a new Pi today, plumbed it in and it all works again. Phew!
I may have fried the original Pi by sharing the mains power distribution with something noisy, although everything else seems to be unaffected
3 Likes
In good contrarian fashion, since I see questions/requests/hopes/desires that the norns shield would work with RaspberryPi 4 in addition to the 3 it is designed for, I have started to wonder if the norns shield would work with the older RaspberryPi 2 instead?
Speaking for myself, I see an lot of reasons to interested this. Has anyone tried it or are there reasons to think it wouldn’t work, or arguments to abandon thoughts in this direction?
The shield will work with a Pi 2 but…
I’ve got a shield on a Pi 3 and another one I put on a Pi 2 I had that was doing nothing. Everything seems to work fine on the Pi 2 but its worth noting that all of the scripts are written for the Pi 3 so you could have issues if they’re doing something strange or require the extra CPU.
If you already have a Pi 2, give it a go but if you’re buying then I’d recommend just getting a 3.
1 Like
Interesting, thank you @tomw. I don’t have an RasPi 2 (will try it out if I find one), but I think this is quite fascinating. I mean if people are excited about C-cassettes, 90s synths, and old banjos they found in the attic, why not RasPi 2s?
I have no idea know how much of the power of a RasPi 3 the norns programs use¹ either theoretically, or in how people actually use them. Will investigate… 
¹ I mean “power” computationally, not musically or creatively speaking
Hi all,
Correct parts, some soldering and resoldering, debugging and guess what - no more smoke 
Super happy 
Many thanks for your help and support!
Special thanks to @okyeron, you are awesome!
Shield + case (minor mod from @okyeron design) + dyi grid (@okyeron design)
https://www.instagram.com/p/CGxTkA0hYf1/?igshid=eq3f51fh3kpy
2 Likes
Alright, continuing from my previous post.
I guess that my norns is alright, it’s just I might have been testing with the wrong device.
This post by tehn states that an 3.2 Vpp / 4dBu sine wave applied to norns’ input corresponds to 90% of the VU meter. With a signal generator I was able to reproduce the same thing.
My issue was that I was testing with a microKorg which I only got to output ~700-800 mVpp when pressing its keys with its volume maxed out. It’s documentation (p67) states that it outputs max +0dBu (2 Vpp). I guess I would need more than 1 single sine voice to attain this max theoretical output.
microkorg max output.bmp (1.1 MB)
So this weak 800 mVpp (versus 3.2 Vpp to attain 90%) seems to explains why my input seemed so low.
The CS4270 audio codec documentation (p26) gives an example of an input circuit with a voltage divider composed of 2 x 2k ohm, attenuating by half the input voltage.
The norns shield schematic has similar input circuit but with 3.3k and 1.5k ohm. This gives a stronger attenuation, of ~1/3.
So I assume that the example circuit is for +0 dBu circuits while norns’ is for hotter +4dBu ones.
I guess it’s safe to use a line-level preamp to boost my microKorg signal going into the norns (I was afraid at first seeing forrest’s comment).
I also assume that a preamp is even more needed to connect consumer electronics to norns’ input (e.g. a phone stereo jack) and get a decent enough level.
Am I right?
3 Likes
Found first issues with my build.
- Occasional volume variations - using official RPi power supply, no devices connected. Level goes up for a moment, then back to normal. Rare.
- Low input level (same as @eigen?). Have to set input and monitoring level to max, but then I start hearing the buzz. Playing audio from Behringer UCA222 connected to Mac, also max playback level. What is you typical input / monitor level? Do you have to boost your source to avoid buzz?
i’d say yes and no. at this late stage in the CE loudness wars, consumer levels are all over the place. at times, i have measured these for work reasons in a pretty serious lab setup. one of the more extreme cases i measured was a 2012 macbook air that put out over 3vpp at max volume with a very low output impedance (<5ohms.)
you are right that norns inputs are designed to handle +4dbu without clipping.
but there is also digital gain available on the inputs. it’s a high quality codec capturing at 24b, so you will not lose significant resolution or SNR by applying +4db or +6db of gain post-capture.
if, on the other hand, the inputs clipped at 0dbu, then you would of course need hardware attenuation to cope with hotter signals. so… i know which compromise i prefer
i should also maybe note that the the VU meter follows IE-60268 spec for PPM scaling. so 90% corresponds to -4dbFS.
1 Like
Thanks for the elaborate answer.
I know that some apps (e.g. pedalboard) implement such a feature but it seems that you are referring to a global param?
If that’s the case, where can it be found ?
sorry, i guess i just meant that it is possible (and very easy) in the abstract to add digital gain at the system level.
i didn’t remember whether the system input level parameter went to 0db or higher. it does in fact max out at 0db. this can easily be modified by changing these lines, in ~/norns/lua/core/mix.lua:
the ADC and DAC levels presently use the same parameter scale. it might be a good idea overall to use a different scale for ADC level, allowing more gain by default.
if you want to try this out, replace those lines with something like this:
local cs_MAIN_LEVEL = cs.new(-math.huge,0,'db',0,0,"dB")
local cs_INPUT_LEVEL = cs.new(-math.huge,12,'db',0,0,"dB")
mix:add_control("output", "output", cs_MAIN_LEVEL)
mix:set_action("output",
function(x) audio.level_dac(util.dbamp(x)) end)
mix:add_control("input", "input", cs_INPUT_LEVEL)
mix:set_action("input",
function(x) audio.level_adc(util.dbamp(x)) end)
the “12” in the second line will give you +12db gain on the input.
if this seems like a good idea we can change it upstream. but i’d want opinions from @tehn and others.
4 Likes
while we’re at it there’s probably not a huge reason not to provide more output gain as well?
mostly the upper limits were convenient to prevent presumed clipping.
we’d still want clear graphic demarcation on the levels screen to show where unity gain lives
8 Likes
this would be v helpful especially for shield + headphones
2 Likes
are you talking about a situation where the maximum output level of the shield is not sufficiently loud in headphones? raising the limit of output level digitally will not help with that, it will just clip more.
(e.g., we already have compressor post-gain, which you can use as a final boost - up to +60db! you can even do this with no compression by minimizing ratio or maximizing threshold.)
i’d acquire or construct a little headphone preamp. i have a non-name rechargeable one that cost $25 and sounds pretty good. (i use it with norns shield.) i think it’s based on one of these cheap TI parts like TPA6138A2.
but no, i don’t think there’s a reason not to provide more output gain, as long as it’s easy to dial in 0db.
i wonder if it makes sense to apply higher dB limit to all mix paths to maintain consistency. on the other hand its kinda good to just be able to spin the encoder and know that it will end on a neutral setting.
also, just bear in mind that these limits only apply to the controls on the mix page. in the lua API, you can apply as much gain as you want (or apply negative gain to invert the signal.)
I’m occasionally loading quiet-ish samples and the script doesn’t always get me to unity gain w/ those - compressor post gain is a good tip though !
1 Like
how about an option to normalize when reading a file to a softcut buffer? (i mean… if you don’t want to just run sox on your samples…)
4 Likes
now THAT is a better idea
I’ll play with this value, thanks.
Yes, akin to what compact cameras display for optical VS digital zoom.
1 Like
as you mention, digital gain will not make headphones louder without clipping.
and normalizing tape files makes sense.
but i mentioned extra digital gain more just as general symmetry for gain flexibility within the chain. for example, i can imagine live-sampling some small loop into softcut, and then focusing in on some quiet tail of that recording, and then wanting to amp/emphasize this moment— yes, i could specifically go to softcut gain (which is also capped at 0db as it happens) but say this similar occurrence happened with a quiet moment in an engine— i’d separately need to reach for the engine gain. my suggestion was just that perhaps it’s interesting/enabling to just revisit the gain params everywhere and provide +12db capability and trust the the user knows what they’re doing.
1 Like
Maybe non-realtime ops for applying gain or normalizing a region are a good way to accomplish this goal in particular. You can get up to +6dB at a time using
softcut.buffer_copy_region_mono(1, 1, start, start, dur, 0, preserve) – copy the region onto itself with preserve determining how much of the original content is mixed in – and you can attenuate a region using the new preserve argument to buffer_clear_region_channel.
3 Likes
yeah i was actually thinking a separate operation for normalize / gain would be more flexible / clean.
There is only one NRT buffer work thread and an ordered queue for jobs. So it should work fine to request a read to region, and immediately follow with a request to gain / normalize same region.
So it’s sounding like adding, say, 12db to all paths would be good? Including monitor? Including softcut input? Output? Matrix?