Norns: help

norns

#734

yes, it works here.

cutoff parameter and associated action are added by these lines in init:

[edit] i’m able to reproduce that error by setting engine.cutoff = 200 (or some other value,) which is an easy mistake but which overwrites the .cutoff() method with a number and breaks it.

what’s odd is that after doing this, the error doesn’t go away, even after switching to a different engine and back. this seems to be a bug (i’d expect engine methods to be re-initialized.) will look into it.


#735

Yes, hermit_leaves.wav plays fine…


#736

Thanks for checking, @zebra! Yep, there was a stray engine.cutoff = 100 in one of my scripts.

In case anyone else runs into an issue like this:
restarting Norns via sleep/wake didn’t fix the issue, but ssh’ing in and restarting matron did. I assume a power-button restart would do the trick as well.


#737

hmm, strangely when I booted up Norns tonight, all the recorded tape files are playing back ok… I’ll report back if I can reproduce it!


#738

I’m struggling to get my head around using metro to put in a delay while drawing this pattern from study 2.
I’d like to draw the shape slowly say 0.25 sec before each screen.line()

– norns study 2
– study2h

function redraw()
screen.clear()
screen.level(math.random(15))
screen.line_width(0.5)
for upper = 0, 4 do
for lower = 0,4 do
screen.move(upper31, 0)
screen.line(lower
31, 60)
screen.stroke()
end
end
screen.update()
end


Approaching: norns
#739

you need to think about it slightly differently to do that.

What you have there is the state (upper and lower) changing in a loop. To add in a delay (lua does co-operative multi-tasking so you can’t just hog the CPU with a sleep command like you might in other languages) you are going to need to store the state and keep coming back. So something like (I’ve not run this so it will have errors in - ugh just spotted one. this seems overly complex now - hopefully someone will come past and point out that there is a simple way and I’m being an idiot)


local state = { dosomething=0; stage = 0; upper = 0; lower = 0 } 
local mymetro 

function redraw() 

if state.stage == 0 then 
    mymetro = metro.alloc( function()  state.dosomething = 1; redraw() end ) 
    state.stage = 1
    mymetro.start(0.25) 
end

-- do the rest of your screen setup stuff 
-- didnt bother typing it out 

if state.stage == 1 and state.dosomething == 1 then 
    screen.move(state.upper, 0)
    screen.line(state.lower, 60)
    state.lower = state.lower + 1
    if state.lower > 4 then
       state.lower = 0
       state.upper = state.upper + 1
       if state.upper > 4 then 
          -- you could set stage to 0 to restart the whole thing over 
          -- you should also stop the metro so it can be garbage collected 
          state.stage = 2 
       end 
   end
  state.dosomething = 0
end

end

( this is basically what co-routines do - but I figured it best to spell out the principle. You may find them a bit less verbose though)


#740

Just for reference in case I need to try it: how does one restart matron?


#741

on the face of it, that’s totally bizarre.

but it makes sense if you had engine.cutoff = in the last launched script. when you do sleep, norns remembers the last script you ran; on wake it looks this up and runs the script again, and in this case i’m guessing re-borks the engine method.

(again, its strange to me that you can’t un-bork it just by switching to a different engine and back; i really will look into this and maybe try to make engine methods un-settable with metatable hacks. but i am heavily occupied at the moment with other tasks.)

when you kill the matron process, or use the rude power button, the script isn’t saved; norns notices this on startup and doesn’t launch any script (the assumption being exactly that you are recovering from some pathological state brought about by the last script .)


#742
we@norns:~ $ cd norns
we@norns:~/norns $ ./stop.sh
we@norns:~/norns $ ./start.sh

#743

Yup, I know you have your hands full, I appreciate the help!
I’ll write up an issue on github, and I might take a first stab at a PR to fix.


#744

ok thanks I’ll check this out :cold_sweat:


#745

The reason I asked about the FH-2 though was that it can behave as a midi client as well as a host. This is one of the main differences between the FH-1 and FH-2. I may have to just get one to try it out. Theoretically it should work though.


#746

I’ve got an FH-2 coming in the mail this week - I should know by Thursday or Friday if it works or not. I share your understanding that the FH-2 in usb device/client mode should work, though. Fingers crossed!


#747

I can confirm: Norns sees the FH-2 as a device and sends MIDI over just fine, with a USB A to USB C cable. No special config required.

I should add that the FH-2 had some issues with the rest of my system. It was sending out messy gates, and double-triggering my Maths, as described here:
https://www.muffwiggler.com/forum/viewtopic.php?p=2909143#2909143
I’m not 100% happy with the suggested solution though, so be aware if you use a lot of Make Noise modules.


#748

Ah I wonder if it will be resolved in a future firmware update. I almost bought one today but might hold off for a bit as I don’t really want to deal with any workarounds. Glad to hear it hears Norns through the C port


#749

dumb non unix user question—are session uptimes logged anywhere? just discovered my grid going even though i haven’t had time to tough norns this week and i’m wondering if i left it on for 4 days or my cat is to blame.


#750

Hi. I think this is my first Norns: help post since I got my device. I’ve been playing as part of a trio. It’s me, a guitarist, and a vocalist, and I’m processing both their outputs with (1) Norns, (2) my Eurorack, and (3) an iPad. For the time being, I’m mostly using MLR with a 128 grid, and sometimes Cranes without any controller (though I’m looking to use something to tweak speed manually). At the most recent rehearsal (last week) and today at our first performance at an actual venue (a cafe), I found that after about an hour and a half, Norns became non-responsive. I’m only recording about four seconds or so of audio at any given time. Today I only used MLR, to see if there’s an issue with switching back and forth with Cranes (the issue of non-responsiveness after extended use persisted, so I guess it’s not about switching programs). Essentially what happens is that after about an hour and a half of constant Norns use, I can’t get out of the main menu, meaning I can’t put it to Sleep or change Parameters, or Select a different app(lication)/script/program. If you have thoughts about how to avoid that freeze, that’d be super. Thanks very much.


#751

I’ve only had this kind of freeze happen once.
I used MLR and Wurlitzer piano as my only instruments when I opened for Florist/@stripes last month and was a little worried it would happen then… but it was totally solid. :man_shrugging:t2:

Also, I highly recommend a usb midi knob/fader box to partner with Norns. It makes it much more playable in a live setting.


#752

so not really a solution to the problem, but perhaps a way to get running again without a hard restart…

If you are able to get the ipad and norns on the same wifi network (norns in hotspot mode I guess?) then you could connect via ssh (using Prompt or some other ssh app) and run ./stop.sh and ./start.sh (in the norns directory)

The problem sounds like one of the main norns processes has crashed or is stalled or something. Thus I think it would take a restart of the stop/start combo to get working again


#753

Thanks for that. Now I want to hear your Wurlitzer/Norns work. Is that online?

The MIDI device I’m using with my Norns (baby steps) is the Launch Control Mini.