Closed mhetrick closed 5 years ago
renamed issue. more generally, the problem is that handling an event in lua blocks the main event loop.
unfortunately, i don't see a trivial solution for this.
we can add a mechanism for lua to temporarily stop new events from being posted, but of course we will miss things.
we could investigate doing long blocking operations like usb sync in a coroutine.
other processes that block:
perhaps scripts/engines should just be shut down before any of these operations. this would require implementing engine.shutdown()
i don't think it's sufficient to stop scripts and engines. unhandled items in the main event queue need to be avoided entirely. (consider joystick, CC or midi clock input that can produce many events quickly / continuously.) i can make the necessary changes to events
and weaver
.
i meant running cleanup()
which should null out any callbacks to norns.none
this seems sufficient to have the event loop continue but do nothing? or are you suggesting we'd overflow the event queue?
are you suggesting we'd overflow the event queue?
Yes that's what I mean. It's not a huge or mysterious problem but it needs attention
likely solution: https://github.com/monome/norns/issues/779
I'm experiencing weird behavior when performing a USB sync with the "wormhole" script open. As soon as the sync completes, there is a massive explosion of sound, as though the engine is attempting to catch up with a large queue of Lua messages. This slows norns down to a crawl. I can still navigate to SLEEP, but it takes many button presses until the machine responds.