Use websocket bridge for snapshot and pedalboard change events#141
Conversation
# Conflicts: # modalapi/mod.py
# Conflicts: # modalapi/websocket_bridge.py
At startup self.current can be None before the first pedalboard loads, causing a crash if the pedalboard monitor fires before initialization is complete.
# Conflicts: # modalapi/modhandler.py
Two pre-existing issues blocking test collection / making test runs hang on feat/websocket-sync: 1. modalapi/modhandler.py: 98701cd "Fix duplicate import" removed the second of two `from pistomp.handler import Handler` lines but ended up dropping both, leaving `class Modhandler(Handler)` referencing an undefined name. 2. tests/integration/conftest.py: Modhandler.__init__ spins up a real AsyncWebSocketBridge worker thread. Tests never call cleanup(), so the daemon threads accumulate across the suite and join() at interpreter shutdown deadlocks under Python 3.14 (PythonFinalization Error: cannot join thread at interpreter shutdown). Patch the bridge class in the fixture so no real thread is ever started. Co-Authored-By: Claude Opus 4.7 <[email protected]>
Py 3.14 raises PythonFinalizationError when Thread.join() runs after the interpreter starts finalizing. Modhandler.__del__ hit this whenever the handler was collected during shutdown. Move bridge teardown to cleanup() only, and guard stop() with sys.is_finalizing() for any other caller. Co-Authored-By: Claude Opus 4.7 <[email protected]>
rreichenbach
left a comment
There was a problem hiding this comment.
This is also very cool. So stoked to see the Snapshot change from MOD-UI sync with the LCD. It all seems to work, but I want to review the code better. If for no other reason to understand how to use it. I'm hoping this will eventually allow us to sync plugin bypass events too.
Ask and ye shall receive: sastraxi#25 I also added some more tests to this branch. |
# Conflicts: # modalapi/mod.py
rreichenbach
left a comment
There was a problem hiding this comment.
Looks good, and seems to work. I'm really excited to have this.
Rather than loading
last.jsonand detecting modification time changes, we can load the current pedalboard using the REST API on startup (mod-ui starts before pistomp) and then track pedalboard changes using websocket messages.We still use the polling loop for mod-ui changes, but instead of checking the file, we check for queued messages from mod-ui on the websocket since the last time we checked.
Bonus: we can actually read snapshot changes this way too, so this PR also adds that feature to sync the current snapshot if changed in MOD-UI.
Branch stack