I have to do a hard reset at least once per session. I’m not a sys admin, therefore I poke it in the eye when it won’t behave. Can someone provide some details for serial login and Linux shutdown commands? Or point me to it? Appreciated!

1 Like

Oh no! Called out be the ZEEB. :scream:
Luckily I don’t need to hard reset much anymore.

if you ssh into the Norns from a terminal on your computer

$ ssh we@[device IP] 

with the default password “sleep”

you should be able to shut it down with

$ sudo shutdown now
1 Like

in the context of this discussion, networking might not be functional, ssh isn’t an option; use the serial port:

(from the docs)

Without WIFI, you can connect to norns via USB-UART by connecting the power cable to your computer. On Mac/linux do:

screen /dev/tty.usb(tab) 115200

where (tab) means: use the shell’s autocompletion to give you the right device path to norns; it will be the only one starting with /dev/tty.usb (or maybe /dev/ttyUSB) unless you have other usb-serial things attached.

on windows, use PuTty and a COM port; same baud setting

that’s definitely not good and indicates some root issue that should be addressed instead of subjecting the flash storage to constant abuse.

2 Likes

ah this is good to know!

posting this here as well as the meadowphysics thread incase people here know of a solution. Meadowphysics used to run fine, but now I get the following error:

pset >> read: /home/we/dust/data/meadowphysics/mp_midi/mp_midi.pset

### SCRIPT ERROR: init

/home/we/dust/code/meadowphysics/mp_midi.lua:52: bad argument #1 to 'pairs' (table expected, got nil)

stack traceback:

/home/we/norns/lua/core/norns.lua:185: in function </home/we/norns/lua/core/norns.lua:185>

[C]: in function 'pairs'

/home/we/dust/code/meadowphysics/mp_midi.lua:52: in field 'action'

/home/we/norns/lua/core/params/option.lua:48: in function 'core/params/option.bang'

/home/we/norns/lua/core/params/option.lua:35: in function 'core/params/option.set'

/home/we/norns/lua/core/paramset.lua:246: in function 'core/paramset.read'

/home/we/norns/lua/core/paramset.lua:264: in function 'core/paramset.default'

/home/we/dust/code/meadowphysics/mp_midi.lua:211: in global 'init'

/home/we/norns/lua/core/script.lua:71: in function 'core/script.init'

[C]: in function 'xpcall'

/home/we/norns/lua/core/norns.lua:186: in field 'try'

/home/we/norns/lua/core/engine.lua:83: in function </home/we/norns/lua/core/engine.lua:82>

>> reading PMAP /home/we/dust/data/meadowphysics/mp_midi/mp_midi.pmap

This is weird error because I can clearly see that table defined in the script, and it would be broken for everybody if it wasn’t… I would just try removing and re-adding meadowphyics if you haven’t already.

Interested to hear how others have been getting on with the compressor, I was playing with it today but not really getting expected results.
Specifically, I couldn’t hear any change when attack is adjusted, am I missing something?
Also curious as to why there are both pre-gain and threshold params?

1 Like

Tried that already unfortunately…also removed any of the new scripts I installed since it stopped working…I have ZERO programming skills/knowledge, so I am at the mercy of all you savvy people on the forum :grimacing:

Do you host the image? Is it not on GitHub?

I’m happy to stick it on a seedbox and let people use a torrent to get at it if that helps?

I have also been curious about ppl using it. I haven’t found a case where I preferred it on. I also wish for clarity on some of the controls in the audio menu. If there is a reason it makes sense to have both of the controls you’re asking about, for example, I’d like to hear about the intended use cases :slight_smile:

What would you like to know more vs what’s already in the docs at the moment?

hey, there’s a bug! lua/crone time units don’t agree. fortunately a trivial fix. seems to work for me.
[ https://github.com/monome/norns/pull/837 ]

Also curious as to why there are both pre-gain and threshold params?

just different options / workflows. for example, set threshold / ratio / postgain to produce the desired nominal output level / amount of compression given 0dbFS input. then, adjust pregain to make it work for the actual material present. there’s no other control that changes the level of the insert fx bus before compression is applied.

i think the comp sounds pretty dang good on drums. it’s a simple approximation of an optical gain curve, (knee smoothing is implemented by an additional lowpass step after gain, in log domain, with smoothing time tied to attack time; poor man’s 1176 but sounds decent to me. thanks, faust stdlib.)

i would have expected more controversy over putting comp after reverb :slight_smile:

3 Likes

Cool thanks for the quick fix and tips, going to spend some more time playing with it tomorrow! :smiley:

Hello!
I’m thinking about putting Norns in the effects loop of my guitar amp and running MLR. Does this sound sane? Anyone have any advice about something like this?

4 Likes

i do this! no advice but ill say it works great!

1 Like

Hi,

I’ve only just started Norns development and I have a question which might have been answered by I could not find the answer to.

If I ssh into the norns, install git and start versioning my projects in /code/, will that break anything?

Thanks a lot!

1 Like

That is what I currently do with every project in my /code folder. :slight_smile: makes updating much easier

edit: I’m pretty sure that git is already installed.

1 Like

Thanks a lot @Justmat I wasn’t sure if this was standard practice.

1 Like

i’m trying to sync my op-1 tape to norns and have run into some weird drift on the op-1 tape itself (see video)

norns is running loom, which is using the beatclock library to send clock info to the op-1. the op-1 is accurately receiving the tempo (as you can hear with the metronome), but the tape loop region is getting confused by something.

other info:
-i can get the same issue with awake, but it’s much more intermittent (can’t reliably reproduce). so maybe a cpu issue?
-i can’t replicate the issue sending clock out from ableton to the op-1 at all. so i don’t think it can just be written off as op-1’s poor midi fluency.

not sure if this is a norns issue, a beatclock issue, or a midi issue. if anyone has any thoughts… :pray: