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()?
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 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:
