@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.
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.
Quick question: Is it possible to use Norns with 3rd-party USB audio interfaces?
is it possible to address more than a single pair of audio inputs and output?
if using just a single stereo pair of each, is it possible to set the interface without editing scripts (ie can the external interface be selected at a system level and all scripts with audio io will simply use the external interface instead of the builtin codec)?
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.
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.