Avalonia 舞蹈灯光控制台：时间轴与现场实时调控

舞蹈灯光控制系统用 Avalonia 做跨平台操控台：灯位编组、场景预设、节拍联动、现场一键切换。演出当晚操作员要在音乐间隙两秒内切场景，UI 再好看，拖影和误触都是事故。控制台负责「让人少犯错」，协议输出层负责「灯必须听指挥」，两者必须解耦。

为什么选 Avalonia

需要桌面级响应与 .NET 生态（串口、Art-Net、部分 DMX 网关 SDK）。Avalonia 让 UI 与输出层都留在 C# 技术栈，减少跨语言进程间通信。相比 WPF，跨 macOS / Windows 部署更统一，适合跟组走台。自定义控件（推杆、色盘、时间轴刻度）用 Skia 绘制，性能可控。

时间轴交互

编排本质是时间轴上的关键帧：某时刻某编组亮度、色温、效果模式。预览模式允许 scrub、跳转、反复试看；演出模式锁定时间轴编辑，只保留场景触发按钮与主控推杆，防止误拖关键帧。模式切换要有明显视觉区分（配色、水印），避免排练习惯带到 live。

场景库结构

场景按「节目 → 篇章 → cue」分层，每 cue 绑定输出快照。支持从当前 live 状态「抓取」为新 cue，减少从零调参时间。导入导出用 JSON 或专用包格式，演出前在离线机器预编，现场只加载包文件，不依赖编排时的网络环境。

现场可靠性

• 场景库本地加载，云同步仅用于排练期，演出机以本地文件为准
• 输出层与 UI 解耦：UI 帧率下降不阻塞 DMX 发送线程
• 一键黑场、应急场景按钮固定位置，任意界面层级下可达（全局快捷键 + 硬件 MIDI 映射）

与音频节拍

若做 BPM 联动，节拍检测或时间码输入独立线程处理，结果以事件写入调度器，不在 UI 线程做重计算。掉拍时允许手动 override，自动跟拍不能锁死操作员。时间码丢失时应有 fallback 策略（暂停跟拍或保持上一 tempo）。

典型坑

• 预览与演出共用同一输出通道：排练误开 live 会把信号送到现场控台
• 大 cue 切换时同步阻塞加载：应预加载下一 cue 资源，切换只做原子替换
• 多屏扩展把监控窗拖太远：主窗始终托管「当前 live 状态」摘要

排练与演出流程

排练期允许随意改 cue、试颜色；演出前做「冻结版本」标记，现场加载冻结包。变更需走解锁流程并留记录，避免演出中误改。操作员交接时，界面应一眼看到当前 cue 名、下一 cue 预告、输出是否在线。

硬件映射与备份控台

灯具地址、Universe 划分、网关 IP 属于现场配置，应与节目包分离存储，换场馆只换映射不改 cue。条件允许时准备备份控台，主台故障时可加载同一冻结包接管输出；切换过程要有 brief blackout 预案。

日志与事后复盘

演出期间记录 cue 切换时间、操作者、输出链路状态，不录每帧 DMX 值（体量过大）。复盘时能看到「第三幕切换延迟是否来自 UI 还是链路」，比口头回忆可靠。

UI 性能习惯

时间轴缩放、缩略图预览不要用同步解码大图阻塞 UI 线程。cue 列表虚拟化，数百个 cue 仍应流畅滚动。演出模式下禁用不必要的动画与模糊效果，把 CPU 预算留给输入响应与状态展示。

舞台软件的 KPI，是演出那晚别出事。花哨转场可以排练慢慢抠，可靠切换和应急路径必须先到位。

小结

演出控制台要把预览与演出模式严格分开，并保证应急黑场永远可达。UI 与协议输出解耦后，界面卡顿也不应阻断现场控灯。开演前检查清单（端口、场景库、备份控台）要写进交付，而不是靠个人经验。