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.
