i would suggest monitoring the power draw in the menu (the mA number after pushing K2 at HOME), and consider externally powering the arc/grid combo if you continue to see trouble.
we are working on a non-hard-reset method for getting out of a lockup. if you can capture any maiden otuput when K2/K3 lock up it’d be very helpful. that is not something easy for us to reproduce.
ok will do - current working and home menu reads:
BAt 99
0ma
DISK 2094M
CPU 24%
63c
IP (address)
@tehn FYI I’ve experienced K2/3 lockup (complete system menu lockup actually) while doing dev work on midigrids with grid_test on fates build 191028. Did not report as I assume my script was behaving poorly and spamming midi events.
Is there and prioritisation on events? i.e. local hardware taking precedence over midi / grid events?
My supposition is usb brownout causing multiple mount/unmount events? or some other burst of events? Though, I suspect the linux usb subsystem prevents flapping?
Sorry if this is not helpful or relevant. I know this type of issue can be extremely hard to debug without reproducibility.
TL/DR: no.
in matron (the process running lua and thus implementing the UI) there is a main loop, which is the sole consumer of events. the lua VM is single-threaded and is serviced from the main loop. there is a single event queue, without prioritization.
MIDI, GPIO, metro and USB events are produced and added to the event queue from other threads or ISRs.
so yes, we are able to implement a soft-reset mechanism that runs entirely from ISRs, and will work even if the main loop is stalled from I/O or event queue flooding. there are many ways to stall the main loop, from scripting errors or edge-case bugs in the system lua stack, so, yes, i think a lower-level reset mechanism is a good idea. we have been discussing the best way to implement this feature without impacting any other functionality. it should be a small task once the decisions are made.
if anyone else would like to suggest (or better, implemement) technical improvements to the main event loop structure, i am all ears. there are small changes, like eliminating mallocs, that would be nice but have not been deemed critical because there is unlikely to be a measurable performance improvement from them.
and there are potential bigger changes we could consider, for example:
a watchdog thread that monitors the event queue and “does something” when the event queue “looks bad.” but defining those states and actions would need to be done very very carefully, and in general we are reluctant to implement heavy-handed solutions that require a lot of engineering, make a lot of assumptions and/or expose a lot of surfaces for new bugs (norns is a scripting platform after all, making it difficult to test every possible component interaction.)
separate event queues for different priorities. events originating from hardware service threads in the C layer could be given higher priority than events originating from metros (say) or other components that the scripting layer can control directly. i’m not sure i immediately see how this could help anything,
github is probably a better venue for exploring these questions further.
Booted norns this eve and encountered the same situation - brief flash of Arc LED’s then unresponsive nub/grid/arc
tried sleep and soft resets - nothing
booted with arc unplugged (on the arc end, not the norns end) and everything booted fine, then plugged the arc in, and everything worked.
Tried to replicate the boot error by sleep cycling and couldn’t do it. Nothing shown in maiden as the error always involves the wifi nub not responding.
@SPIKE the next time you encounter this you may want to try booting w/out the arc then plugging it in.
is that an older ARC?
you mentioned it has pushbutton encoders.
(or did i read that incorrectly)
both of my ARCs are from last year.
Bootup this morning and encountering the same issues. Grid works fine alone, arc plugin causes the same issues previously mentioned.
The only thing new I’ve found is the ohm rating when I try to plug the arc in moves between 0ma and -5ma.
When I try plugging the arc in it kicks the grid off, then the grid registers again in maiden, so I get
grid added: 1 monome 256 m0000550 m0000550
grid added: 2 monome 256 m0000550 m0000550
@SPIKE pushbutton arc 4
Going to try a reinstall today
Flashed the norns system
updated to latest OS
updated cheat codes
plugged in ARC - same issues
eidt: I was able to solve the lockup issue by removing the wifi nub before booting.
later on issue persisted wirthout wifi nub. At this point I feel I’ve tried every use combination. will update re powered hub tomorrow.
I strongly recommend you get a powered usb hub given the probability of a power issue
Quick question: Is it possible to use Norns with 3rd-party USB audio interfaces?
If yes:
Does the same apply to external MIDI interfaces?
USB audio - no and yes (or maybe). You can change system level audio source, but norns routing is still only stereo in/out.
Lotsa settings need changing. I did some experiments with this a long while back.
Midi - Yes? It’s midi. There’s 3-4 USB ports to connect to. What are you trying to accomplish?
everything in norns ecosystem is designed for stereo I/O. the norns hardware has stereo I/O with a headphone amp, and the shield is just a means to get the same functionality with lower cost.
presumably you have some specific creative application in mind for higher channel counts. just work on that application in a hardware-agnostic fashion - supercollider is a great environment for multichannel work. maybe a rasbpi will be able to handle it and maybe not.
if you think about it a little, i think you’ll quickly see how it would be basically impossible to make a platform like norns that seamlessly supports all possible applications of arbitrary I/O channel counts. more general environments like supercollider or csound already exist and are very mature.
the norns system is about having a predictable common environment for sharing. i guess i primarily see it, like all embodied designs, as a set of limitations. limitations are what allows us to actually do work instead of making tools forever.
closing this thread. please use the Questions category!
Totaly norns uneducated neewbie question bit overhelmed by it.
When you say 8x16, what would i loose using 8x8? And are there better suited apps for chopping up, playing and sequencing earthsea-alike live sample material for an 8x8? I love the square for musical stuff.
Exactly half of the grid UI 
i’m experiencing similar LOW BATT issue on factory norns as @SPIKE but with a twist
i just tested w/ opz and bleached:
seems quite odd, no?