I’m not familiar with vports / device management etc. but could / should there be some kind of system level connected devices reset / redetect menu?

(Perhaps there is. Will look next time I boot Norns.)

FWIW I don’t have USB issues as far as I can tell, but I regularly get lock ups / no sound after the unit has been slept overnight. Will log anything useful if I can reproduce reliably.

update coming today which will have a more thorough reset system

3 Likes

Is there either a directory of scripts that function with a 64 grid or a way of tagging the library posts that specify which grids are supported?

I only have a 64 right now with a new Fates on the way and a quick way to find 64 friendly scripts would super helpful to a relatively new user.

1 Like

there is such a thing as too many tags, particularly for minority use cases. perhaps you’d like to start a new thread after compiling a list yourself, which could later be contributed to?

1 Like

Actually a community thread would be a good idea. Would it be better in the Monome section or the Library?

Awesome thank you
I’m sure you have more important stuff to be doing
But this little box you have created is incredible
And when it doesn’t run correctly I’m lost
I know it’s dumb …
But for me you replaced a huge amount of gear
And I am lost with out my norns
Again
Thank you
And my personal apologies for being a hinderence in any way

There is an edit of less concepts that I did, and also an edit of mlr that I’ve seen on the forum. Search and find it.

Edit: Less concepts

A lines tag or a thread to collect them would be nice for sure. I think most apps could be modified to at work with monobright 64, or some subset of functionality at least. I’d like to have a crack at modifying cheat codes at some point too.

fwiw - i think im having similar issues to @SPIKE

When I turn the norns on for a new session, usually the midi ports do not register, including the wifi nub. this is with the most recent update tehn just posted:

(most recent norns update - grid 256 and Arc 4 pushbutton)

wake up - nothing registers

reset - nothing

sleep - wifi registers but grid / arc do not

sleep again - nothing registers

reset w/ usbs out - nothing registers

hard reset - wifi registers / grid + arc do not

reset - usbs seem to register but K2 / k3 are unresponsive

hard reset - nothing

sleep w/ nothing plugged in - K2 / K 3 unresponsive

hard reset - looked in maiden and got

grid added:	1	monome 256 m0000550	m0000550

but nothing showed up when I added the arc, the K2/K3 went unresponsive again.

hard reset - arc tries to add but I get nothing in maiden and just flickery lights.

reset - grid works again but once the arc is in it all goes blank.

(this process is typical for be when starting a new session)

@tehn seems like the Arc is where to look

Open your browser and fill in the ip adress in the address bar.
Does this work?

woop, sorry @Gregory_Delabelle , i didn’t close the loop – this was resolved thru email to help@monome.org :revolving_hearts:

1 Like

does your arc work at all? can you try it with a computer to confirm?

is this with a norns? kit? fates?

as i said in the update, please STOP HARD RESETTNG. it fixes nothing, and probably breaks your file system. i would recommend you do a fresh install.

if your K2/K3 go unresponsive (which is incredibly bizarre), please have maiden open so we can understand what’s happening. you can reset using maiden by typing ;restart

Norns, not kit or fates. Arc works with computer.

Is there another option apart from hard reset if K2/3 are unresponsive and the wifi nub is not working? when the usb ports go out the wifi does as well.

you’re on the newest update?

i need some help understanding your bug report. please try to be as thorough as possible.

when you say “does not register” do you mean it doesn’t show up in SYSTEM > DEVICES?

if wifi and K2/K3 are not working, yes, it’s time to hard reset.

is there a script running when K2/K3 break?

by “go out” do you mean the USB was working, then suddenly it isn’t? if so, and the arc is the culprit, i might suggest using a powered USB hub, as there might be a power issue.

is the norns being powered during all of this, or are you running via battery? highly suggest powering from the power supply shipped with the norns. underpowering causes problems, and a heavy script (much CPU) paired with tons of USB devices can very likely overwhelm the system.

does not register / out = maiden does not register a connection, nothing shows up in the norns devices menu, wifi is unavailable and the light on the usb wifi nub is not lit.

Norns has been powered via power cable throughout.

No script running when this is going on. I’ve tried it while running cheat codes and without anything running.

it seems like plugging the ARC 4 Pushbutton is the thing that creates this bug. When I plug the arc in nothing registers in Maiden.

This has happened in the past and seems to resolve without an apparent reason.

I don’t have a powered usb hub so it’ll be a while until I can try that.

you’re on the newest version?

if the arc getting plugged in disconnects all the USB devices, that is certainly the problem.

have you tried different USB ports? different cables?

sorry, yes newest update. tried different cables and different ports on the norns. Also tried plugging the arc in first / second in order. as well as booting with nothing plugged in vs already plugged in.

Just tried it again and the arc successfully registered for no apparent reason. smh.

grid added:	3	monome 256 m0000550	m0000550
arc added:	4	monome arc 4 m0000632	m0000632

now its running cheat codes and everything is working fine

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.

3 Likes