# Electra One Mk2 v4.1.4 — freeze during repeated dynamic Lua page/control updates **URL:** \ **Category:** Developers\ **Created:** [September 18, 2026, 7:15am UTC](https://forum.electra.one/t/electra-one-mk2-v4-1-4-freeze-during-repeated-dynamic-lua-page-control-updates/4611 "2026-09-18T07:15:10Z")\ **Posts on this page:** 4\ **Page:** 1
**Author:** ![fragletrollet](https://dub1.discourse-cdn.com/flex017/user_avatar/forum.electra.one/fragletrollet/32/4943_2.png) [@fragletrollet](https://forum.electra.one/u/fragletrollet)\ **Post date:** [September 18, 2026, 7:15am UTC](https://forum.electra.one/t/electra-one-mk2-v4-1-4-freeze-during-repeated-dynamic-lua-page-control-updates/4611/1 "2026-09-18T07:15:10Z")
Hi, I’m developing a fairly dynamic FL Studio DAW control surface for Electra One Mk2. Hardware: - Electra One Mk2 - hardware revision 3.0 - firmware 4.1.4 The preset uses pre allocated controls only. Lua changes properties such as control names, colors, visibility and displayed values at runtime. Application data arrives as private SysEx on normal MIDI Port 1 and is handled in `midi.onSysex()`. Electra management SysEx is kept separate on the CTRL port. The controller is otherwise working well: bidirectional mixer control, Channel Rack, plugin parameter control, FX and transport are functional. The remaining problem is a repeatable full-controller freeze during repeated switching between a Channel page and a dynamically populated Plugin page. Current observations: - A lightweight plugin such as Fruity Balance can survive roughly 10–20 repeated Channels ↔ Plugin transitions. - A heavier synth like Harmless can freeze the controller on approximately the second/third/fourth return to the Plugin page. - Reducing redundant `setName()`, `setColor()`, `setVisible()` and displayed-value updates with caching made the lightweight case substantially more reliable, but did not eliminate the Harmless failure. - Incoming runtime frames immediately before the failure are syntactically valid; no malformed-frame finding so far. - The touchscreen and normal runtime interaction stop together. - In the frozen state, a bounded read-only query on CTRL has also sometimes failed to return before the host MIDI backend timed out. - A power cycle restores normal operation. I found the earlier “Page Switch Problem” thread and the discussions about excessive repainting, so I’m now considering batching each completed page update inside a single `window.stop()` / `window.resume()` section. Before implementing that, could you clarify a few details about the runtime? **1. Are Lua callbacks serialized?** Can `midi.onSysex()`, page-change callbacks, pot/touch callbacks or other Lua callbacks interleave/re-enter while another callback is still executing, or is Lua execution strictly serialized? **2. Is this an intended safe use of `window.stop()` / `window.resume()`?** ```auto ``` ```auto window.stop() local ok, err = pcall(function() -- setName / setColor / setVisible / overrideValue -- possibly one pages.display() end) window.resume() ``` entirely within a single `midi.onSysex()` callback? Are `stop()` / `resume()` nestable, and what happens if Lua errors while repaint is stopped? **3. Do updates to controls on inactive pages still cause layout/repaint work?** For example, do calls such as: - `control:setName()` - `control:setColor()` - `control:setVisible()` - `value:overrideValue()` cause rendering/layout work even when that page is not currently displayed? **4. Is there a recommended batching limit?** Is there any practical recommended maximum number of control-property changes per callback or per time interval? A full page in my preset can contain 36 dynamically populated plugin controls, so a context change can potentially update many names/colors/visibility/value strings. **5. Are there Lua heap/GC considerations for frequently replacing strings?** Is there a documented or practical Lua heap limit, or anything to be aware of with repeatedly changing control names and override strings? **6. Are there any known v4.1.4 issues in this area?** In particular, could this be related to the earlier page-switch freezes, the repaint issues discussed during v4 development, or the VCV Rack freeze fixed in 4.1.3? **7. Could a UI/render/Lua lockup also prevent CTRL-port queries from being serviced?** I’m trying to determine whether loss of CTRL response during the freeze points to a broader firmware task lockup, or whether that would normally be a separate subsystem. I can provide a reduced preset/Lua reproducer, raw MIDI traces and exact before-freeze workload counters if that would help. I found a [thread](https://forum.electra.one/t/page-switch-problem/3938?utm_source=chatgpt.com)with quite similar problem, in my case I now have one page ACTION per operator intent, but the freeze remains. Some other, possibly related threads: ---
**Author:** ![martin](https://dub1.discourse-cdn.com/flex017/user_avatar/forum.electra.one/martin/32/145_2.png) [@martin](https://forum.electra.one/u/martin)\ **Post date:** [September 18, 2026, 2:41pm UTC](https://forum.electra.one/t/electra-one-mk2-v4-1-4-freeze-during-repeated-dynamic-lua-page-control-updates/4611/2 "2026-09-18T14:41:55Z")
> [@fragletrollet](#): > > Can `midi.onSysex()`, page-change callbacks, pot/touch callbacks or other Lua callbacks interleave/re-enter while another callback is still executing, or is Lua execution strictly serialized? yes, lua is serialized and executed in one thread. > [@fragletrollet](#): > > 2. Is this an intended safe use of `window.stop()` / `window.resume()`? Yes, that should be fine. Actually, on the mk2, `window.stop()` and `window.start()` don’t do much anymore, they merely stop the and resume the repaint process. Note that in 5.0.0, these are superseded by a transaction function that groups nested calls into a single consistent repaint. > [@fragletrollet](#): > > Are `stop()` / `resume()` nestable, and what happens if Lua errors while repaint is stopped? If not resumed, no repaints will take place, even the system ones. It may look wedged, but the system should respond on MIDI etc normally. Not optimal, hence the new transaction function. > [@fragletrollet](#): > > 3. Do updates to controls on inactive pages still cause layout/repaint work? when not on the screen, only model update takes place. no rendering. > [@fragletrollet](#): > > 4. Is there a recommended batching limit? on the mk2 the limit should be around that number, ie. one standard page. > [@fragletrollet](#): > > 5. Are there Lua heap/GC considerations for frequently replacing strings? heap can go as high as the system memory permits. when exhausted, errors will be reported. The GC, depending on where the strings are allocated. very frequent allocations/destroys will cause GC spikes that can affect the overall performance, short stalls. > [@fragletrollet](#): > > 6. Are there any known v4.1.4 issues in this area? 4.1.4 has an issue with handing certain situations when it internally calls panic/longjmp. That crashes the controller as it will mess the internal threads. the upcoming 5.0.0 resolves that. > [@fragletrollet](#): > > 7. Could a UI/render/Lua lockup also prevent CTRL-port queries from being serviced? yes, the Ui, Lua, CTRL api are serviced by the application thread, if anything in it stalls, the whole thread stalls. 5.0.0 resolves that. I am now preparing another update of 5.0.0 beta. it might be worth to test it with the 5.0.0, beta can also report system status: ![image](https://europe1.discourse-cdn.com/flex017/uploads/electraone/original/2X/7/717e4f0c5585c6a240836b31e224f48a1039ae85.png) and complete trace on breakpoint: ![image](https://europe1.discourse-cdn.com/flex017/uploads/electraone/original/2X/a/a2f4159236f6e23bd34f990174444db19f896a84.png) I am testing and working towards making it ready for a public release. Any additional testing will help… ---
**Author:** ![fragletrollet](https://dub1.discourse-cdn.com/flex017/user_avatar/forum.electra.one/fragletrollet/32/4943_2.png) [@fragletrollet](https://forum.electra.one/u/fragletrollet)\ **Post date:** [September 18, 2026, 3:17pm UTC](https://forum.electra.one/t/electra-one-mk2-v4-1-4-freeze-during-repeated-dynamic-lua-page-control-updates/4611/3 "2026-09-18T15:17:49Z")
Thanks — vibecobing at school, so pardon my AI-lingo. This is all a tad over my coding chops, so I can mostly just forward its remarks, hope thats not too tacky. …this was very helpful, especially the details about serialized Lua execution and the shared application thread. Since my original post I have made substantial progress, so I wanted to give you a concise update. I changed the controller protocol so a dynamic page is no longer applied incrementally. FL now sends a complete generation: `BEGIN → CONTEXT / SLOT / TEXT → COMMIT` Electra stages the data first, then applies the complete page inside one: `window.stop() → changed setters → optional pages.display() → window.resume()` A fully populated 36-parameter plugin page still performs about the same amount of actual UI work as before — roughly 147 setters. The important change is that they are now grouped into one consistent commit rather than being applied as individual metadata frames arrive. We also added transaction validation and ACK/NACK recovery. During testing we reproduced a case where one required `CONTEXT` frame was absent. The Electra side detected the incomplete generation, performed **zero UI setters** , kept the previous valid page, returned a NACK, and the host resent a complete fresh generation which then ACKed successfully. Most importantly, I have now tested the current version with **real FL Studio and real Harmless** , which was the plugin that previously froze the controller after only a few Channels↔Plugin transitions. Current result on Mk2 / firmware 4.1.4: - 12/12 Channels ↔ Harmless cycles completed - 24/24 page transactions ACKed - 0 NACK/retries during that real-plugin run - 0 malformed runtime frames - 1,695 transaction frames observed - CTRL remained responsive throughout - worst measured CTRL query latency was about 12 ms I have not yet physically inspected the controller after this latest automated run, so I am deliberately **not** claiming full success yet — I still need to confirm that the display contents are correct, the touchscreen remains responsive, and physical encoder control behaves normally. Your explanation of the v4.1.4 `panic/longjmp` issue is particularly interesting in hindsight. The old failure mode was exactly the case where UI, Lua/runtime and CTRL appeared to disappear together, whereas the newer missing-frame failure left Lua and CTRL completely alive. That now looks like two distinct failure classes. Two follow-up questions, if you have time: 1. Do you know what kinds of conditions normally lead into the problematic v4.1.4 `panic/longjmp` path? Could a valid but heavy Lua/UI workload trigger it indirectly, or would you normally expect an explicit Lua/API error first? 2. Once your next 5.0.0 beta is available, would it be useful to you if I run the same bounded Harmless page-switch test against it? I can keep the workload and captures essentially identical for a controlled 4.1.4 vs 5.0 comparison. If useful, I can also provide the small reproducible workload, runtime captures and transaction logs. - The preset is really coming together, the automatic mapping of external plugins is working wonderfully, I cant believe the days of mapping are over. Tested with Omnisphere 3, the amount of parameters available at my fingertips is amazing. Also tested most of Plugin Alliance plugins and most native FL stuff. - - Dynamic track, channel, plugin and parameter names - Banked control of the FL Mixer and Channel Rack - Mixer volume, pan, mute, solo, select and record-arm - Automatic control of the focused generator or effect - 36 plugin parameters per bank with formatted values - FX-slot browsing, wet/mix control and plugin opening - Play, stop, record, metronome, Song/Pattern, loop and tempo controls - FL track colors and selection feedback - Fast, smooth bidirectional control without feedback loops - Automatic synchronization after project, page or plugin changes - Transactional communication with error detection and recovery - Generic support for previously unseen plugins—no manual mappings required - Extensible plugin-profile system for future curated layouts ---
**Author:** ![HelenMarsh](https://avatars.discourse-cdn.com/v4/letter/h/a183cd/32.png) [@HelenMarsh](https://forum.electra.one/u/HelenMarsh)\ **Post date:** [September 21, 2026, 9:29am UTC](https://forum.electra.one/t/electra-one-mk2-v4-1-4-freeze-during-repeated-dynamic-lua-page-control-updates/4611/4 "2026-09-21T09:29:24Z")
For repeated dynamic updates, I would first coalesce writes per control and add a short debounce so a page refresh cannot outrun the device acknowledgement. A bounded update queue with a visible sequence number also makes it easier to tell a transport stall from a Lua-side loop. For checking a stable test signal while reproducing it, this [frequency reference](https://kyma369.com/frequencies) is useful.