TiXL 布尔信号处理算子全解:CacheBoolean / DelayBoolean / DelayTriggerChange / KeepBoolean 的时序控制实战
音视频图形学桌面应用【免费下载链接】t3TiXL is an open source software to create realtime motion graphics.项目地址https://gitcode.com/GitHub_Trending/t3/t3点击查看免费下载导读在 TiXLt3实时动态图形系统中布尔Boolean信号是最常用的控制信号之一——无论是键盘/OSC 触发、节拍检测、还是 UI 交互最终都汇聚成一个个 true/false 脉冲。直接使用原始布尔信号常常会导致一帧内多次更新、状态闪烁、或难以实现按住一定时长才生效等交互需求。本文基于官方算子库文档 Lib.numbers.bool.process系统讲解其中 4 个布尔处理算子CacheBoolean缓存、DelayBoolean按帧延迟、DelayTriggerChange变化延迟 / MonoFlop、KeepBoolean状态保持并结合仓库源码Operators/Lib/Symbols/numbers/bool/process逐一剖析其底层实现原理、参数语义与典型应用场景。读完本文你将能够准确判断何时选用哪个算子并能在自己的实时作品中正确配置它们的参数。算子族概览四个布尔处理算子的定位根据官方文档 READMELib.numbers.bool.process命名空间下共注册了 4 个算子它们解决的是布尔信号的时序与状态管理这一组问题算子核心作用文档定位CacheBoolean阻止多次更新转发先前计算好的布尔值CacheBoolean.mdDelayBoolean将布尔值的变化按帧数延迟DelayBoolean.mdDelayTriggerChange将布尔标志的变化按时长延迟在 vvvv 中称为 MonoFlopDelayTriggerChange.mdKeepBoolean保持标志状态直到被重置KeepBoolean.md从源码结构看这 4 个算子都位于Operators/Lib/Symbols/numbers/bool/process/目录每个算子由三部分组成.csC# 实现、.t3算子定义与输入默认值和.t3ui编辑器中的 UI 布局。它们都继承自InstanceT泛型基类位于 Core/Operator/Instance.cs通过[Guid]特性注册唯一标识通过[Input]/[Output]特性声明插槽。文档末尾标注Auto-generated from the operator library说明该 README 由算子库自动生成四个子文档的描述文本实际来自每个算子编辑器中录入的说明——因此本文将以源码实现为准对文档描述进行深度展开。CacheBoolean阻止重复更新的布尔缓存文档定义Prevents multiple updates by forwarding a boolean value that was computed earlier.阻止多次更新转发先前计算好的布尔值。输入输出类别名称类型OutputResultSystem.Boolean源码剖析CacheBoolean.cs 的实现非常精简其核心逻辑在于Update方法中的分支判断if (!Value.HasInputConnections) { Result.Value Value.GetValue(context); return; } if (Value.TryGetFirstConnection(out var connection) connection is Slotbool boolValue) { Result.Value boolValue.Value; }从源码可以看出它的工作方式当输入Value没有连接任何上游节点时直接求值Value.GetValue(context)并输出当存在连接时则读取上游Slotbool节点已经计算好的值boolValue.Value而不再触发上游重新求值。这解释了文档中prevent multiple updates的准确含义在 TiXL 的惰性求值架构下一个输出槽被多个下游节点连接时可能被重复更新CacheBoolean作为中间节点缓存上游已经算出的布尔结果让下游消费者读取的是同一份稳定值从而避免一帧内同一信号被多次求值带来的抖动与开销。典型场景将一次计算结果分发给多个后续逻辑分支时用 CacheBoolean 保证所有分支拿到一致且只计算一次的布尔值。DelayBoolean按帧数延迟布尔信号文档定义原文档对该算子暂无文字描述No description yet但输入参数表给出了明确语义名称Relevancy Type描述TriggerBoolean Required布尔输入FrameCountInt32定义布尔变化被延迟多少帧输出名称类型DelayedTriggerSystem.Boolean源码剖析DelayBoolean.cs 使用一个Queuebool环形缓冲实现帧级延迟var frameCount FrameCount.GetValue(context).Clamp(0, 500); var current Trigger.GetValue(context); var result false; if (frameCount 0) { _queue.Clear(); result current; } else { while (_queue.Count frameCount) { result _queue.Dequeue(); } _queue.Enqueue(current); } DelayedTrigger.Value result;实现要点FrameCount 被Clamp(0, 500)限制取值被钳制在 0500 帧之间避免过大的延迟值造成队列无限增长。你可以用 MathUtils 确认这是Clamp的扩展实现。FrameCount 0 时直通清空队列并直接输出当前输入此时算子相当于纯透传。队列长度恒等于 FrameCount每帧先弹出最旧的元素作为输出再压入当前值实现了严格的 N 帧延迟。每帧只更新一次通过Math.Abs(context.LocalFxTime - _lastUpdateTime) 0.001f判断当前帧是否已更新过并记录_lastUpdateTime防止同一帧内重复处理。此外输出槽DelayedTrigger标记了DirtyFlagTrigger.Animated见 DirtyFlagTrigger.cs表示该输出随时间变化需要每帧重新求值——这与延迟逻辑每帧推进的语义一致。典型场景需要把信号精确延迟整数帧例如对齐节拍网格、实现连击判定窗口时使用。从默认配置DelayBoolean.t3可见FrameCount默认值为0即默认直通。DelayTriggerChangeMonoFlop 式布尔变化延迟这是四个算子中功能最丰富、文档描述最详细的一个也是官方文档强调的重点算子。文档定义Delays the change of a boolean flag. This can be useful for implementing interactions where a value needs to stay true for a minimum duration. In DelayTrue mode, it will immediately switch to true but delay switching back to false. Note: This is NOT a queue. Frequent changes of the incoming signal can lead to the delayed state filtering out changes within the delay duration. In vvvv, this op is called a MonoFlop. 延迟布尔标志的变化。这对实现值需要保持 true 至少一段最短时长的交互非常有用。在 DelayTrue 模式下它会立即切换为 true但延迟切换回 false。注意这不是队列。输入信号频繁变化可能导致延迟期间的变化被过滤掉。在 vvvv 中此算子被称为 MonoFlop。Also see DelayBoolean if you want to delay a signal.若想延迟一个信号另见 DelayBoolean。输入输出名称Relevancy Type描述TriggerBoolean Required—DelayDurationSingle—ModeInt32—TimeModeInt32—名称类型DelayedTriggerSystem.BooleanRemainingTimeSystem.Single源码剖析三种延迟模式DelayTriggerChange.cs 内部定义了核心枚举DelayModes这就是Mode输入的取值private enum DelayModes { DelayTrue, // 模式 0默认 DelayFalse, // 模式 1 DelayBoth, // 模式 2 }三种模式的延迟策略由Update方法中的 switch 分支决定switch (delayMode) { case DelayModes.DelayTrue: refTime _lastTrueTime; stateIfDelayed true; break; case DelayModes.DelayFalse: stateIfDelayed false; refTime _lastFalseTime; break; case DelayModes.DelayBoth: stateIfDelayed _stateBeforeChange; refTime _lastChangeTime; break; } var remainingTime refTime - currentTime delayDuration; var isDelayed remainingTime 0; RemainingTime.Value (float)remainingTime; DelayedTrigger.Value isDelayed ? stateIfDelayed : _triggered;DelayTrue默认枚举值 0以最近一次输入变为 true 的时刻_lastTrueTime为参考点。输入一旦变 true输出立即跟随为 true之后即使输入变回 false只要DelayDuration未走完输出仍保持 true。这正是文档所说的immediately switch to true but delay switching back to false用于保证 true 至少维持最短时长。DelayFalse对称地输出立即跟随 false但延迟切回 true以_lastFalseTime为参考。DelayBoth以最近一次状态变化时刻_lastChangeTime为参考在延迟期间保持变化前的旧状态_stateBeforeChange即上升沿与下降沿都延迟。isDelayed remainingTime 0的判定加上RemainingTime输出实时给出剩余延迟秒数可为负让下游可以驱动倒计时显示或进度动画。时间基准 TimeMode七种时间域TimeMode输入由内部枚举TimeModes映射默认值为6AppRunTime_InSecs见 DelayTriggerChange.t3 的DefaultValue: 6枚举值名称时间来源源码0LocalFxTime_InBarscontext.LocalFxTime本地 FX 时间以小节计1LocalFxTime_InSecscontext.Playback.SecondsFromBars(context.LocalFxTime)2LocalTime_InBarscontext.LocalTime3LocalTime_InSecscontext.Playback.SecondsFromBars(context.LocalTime)4PlayTime_InBarscontext.Playback.TimeInBars5PlayTime_InSecscontext.Playback.TimeInSecs6AppRunTime_InSecs默认Playback.RunTimeInSecs选择不同时间域会影响DelayDuration的计量单位与起点默认的AppRunTime_InSecs是自应用启动以来累计的秒数适合与具体秒数直接比较而_InBars系列则让延迟时长可以按音乐小节计算与 TiXL 的节拍同步体系参见 Core/Audio/Timing/BeatSynchronizer.cs结合可实现与 BPM 挂钩的延迟效果。与 DelayBoolean 的区别及文档中的两个重要警告计量单位不同DelayBoolean 按帧数延迟DelayTriggerChange 按**时长DelayDuration 秒**延迟。官方文档特别提示Also see DelayBoolean if you want to delay a signal——如果需要纯粹的、可预测的信号搬运延迟应选用按帧的 DelayBoolean。这不是队列NOT a queueDelayTriggerChange 不缓存历史信号序列。文档明确警告输入在延迟期间频繁翻转时延迟期间内的变化会被过滤掉——因为逻辑只记录最近一次 true / false / 变化时刻这几个时间点而不是把每次变化都排队。因此它适合最短保持时长类需求不适合精确复现一连串脉冲的时序。典型场景按键防抖、闪光灯最小显示时长、按钮按住高亮的最低时长、节拍同步的门限信号等交互逻辑。KeepBoolean保持标志状态直到重置文档定义Keeps the state of flag until it is reset.保持标志状态直到被重置。输入输出名称Relevancy Type描述ValueBoolean Relevant—FreezeBoolean Relevant—ModeInt32—名称类型ResultSystem.BooleanTimeSinceFreezeSystem.Single源码剖析冻结与两种更新模式KeepBoolean.cs 维护一个内部_frozenValue冻结值Mode枚举决定何时把Value的最新值写入冻结值private enum Modes { FreezeWhileTrue, // 模式 0默认 UpdateWhenSwitchingToTrue, // 模式 1 }更新逻辑节选var wasTriggered MathUtils.WasTriggered(freeze, ref _freeze); if (wasTriggered) { _freezeTime context.LocalTime; } if (mode Modes.FreezeWhileTrue) { if (!freeze) { _frozenValue newValue; // 未冻结时持续跟踪最新值 } } else { if (wasTriggered) { _frozenValue newValue; // 仅在 Freeze 上升沿捕获一次 } } Result.Value _frozenValue; TimeSinceFreeze.Value (float)(context.LocalTime - _freezeTime);FreezeWhileTrue默认模式 0当Freeze为 false 时Result跟随Value实时变化当Freeze变为 true冻结生效后Result锁定为冻结瞬间的值直到Freeze再次为 false 才解除锁定、重新跟随。UpdateWhenSwitchingToTrue模式 1在Freeze的上升沿由MathUtils.WasTriggered检测即 false→true 的那一帧捕获一次Value并写入冻结值之后即使Freeze保持 true也不再更新。即上升沿采样一次然后一直保持。TimeSinceFreeze输出自冻结时刻_freezeTime起经过的本地时间秒且该输出同样标注了DirtyFlagTrigger.Animated适合驱动与冻结时长相关的动画或超时判断。典型场景锁定某个按键在按下瞬间的开关状态、记录某个事件发生时的布尔现场、实现直到明确重置前一直保持的开关寄存器。四个算子的选型速查与实战建议结合官方文档与源码给出以下选型决策逻辑只是想缓存/分发一个已算好的布尔值避免重复更新→ 选CacheBoolean。它不引入任何延迟只做一次求值、多次复用。需要把布尔信号精确延迟整数帧如对齐帧网格、构建固定延迟线 → 选DelayBoolean用FrameCount0500 帧控制延迟量。需要最短保持时长语义true 至少维持 N 秒、防抖、MonoFlop → 选DelayTriggerChange用DelayDurationModeDelayTrue / DelayFalse / DelayBothTimeMode默认 AppRunTime_InSecs组合。牢记它不是队列不适合复现频繁变化的脉冲序列。需要把布尔状态冻结/保持直到解除→ 选KeepBoolean用Freeze与ModeFreezeWhileTrue / UpdateWhenSwitchingToTrue选择是持续锁定还是上升沿采样并可读取TimeSinceFreeze驱动超时动画。需要特别留意的是DelayBoolean 与 DelayTriggerChange 虽然都名为延迟但前者按帧、后者按时长且内部机制完全不同帧队列 vs 时间戳比较官方文档在 DelayTriggerChange 页中明确指引了二者边界实战中按延迟信号搬运与最短时长保持两类需求区分即可。小结Lib.numbers.bool.process是 TiXL 布尔信号时序处理的完整工具集CacheBoolean 负责求值收敛DelayBoolean 负责帧级搬运DelayTriggerChange 负责时长级保持MonoFlopKeepBoolean 负责状态冻结。本文以官方文档为骨架、以 Operators/Lib/Symbols/numbers/bool/process 下的 C# 源码与.t3默认配置为佐证还原了每个算子的内部状态机与参数语义。在搭建实时交互图形时把这四个算子放在手边即可高效处理绝大多数布尔时序问题。更多算子细节可回到官方算子库文档目录 .help/docs/operators 继续查阅。赞分享音视频图形学桌面应用【免费下载链接】t3TiXL is an open source software to create realtime motion graphics.项目地址https://gitcode.com/GitHub_Trending/t3/t3点击查看免费下载相关推荐TiXL 算子解析CacheBoolean —— 用「提前计算好的布尔值」阻止重复更新TiXL 算子解析CacheBoolean —— 用「提前计算好的布尔值」阻止重复更新 CacheBoolean 是 TiXL 实时运动图形库中一个看似不起眼音视频图形学桌面应用TiXL TriggerAnim 算子完全指南用布尔触发信号驱动实时交互动画TiXL TriggerAnim 算子完全指南用布尔触发信号驱动实时交互动画 TiXLt3是一套用于创作实时动态图形的开源软件而 TriggerAnim音视频图形学桌面应用Zeus未来展望路线图分析与社区贡献完整指南 Zeus未来展望路线图分析与社区贡献完整指南 Zeus作为一个革命性的Rails应用预加载工具已经在开发社区中赢得了广泛的赞誉。这个强大的工具能够在音视频图形学桌面应用创作声明:本文部分内容由AI辅助生成(AIGC),仅供参考

相关新闻

BrewUI:让Homebrew包管理可视化,依赖清理更简单

BrewUI:让Homebrew包管理可视化,依赖清理更简单

/* MD / 富文本中的 .toc(含博客园搬家等嵌套结构);.toc-box 在侧栏,不受影响 */#content_views .toc,/* 编辑器常在目录前后插入空 p(:empty 仍占 20px),一并去掉避免顶空隙 */#content_views.markdown_views > p:empty:has(+ .toc),#content_views.markdown_views …

2026/11/4 3:27:46 阅读更多 →
colibri:用YAML优雅配置Karabiner,打造高效键盘映射

colibri:用YAML优雅配置Karabiner,打造高效键盘映射

1. 为什么键盘重度用户需要 colibri1.1 Karabiner 配置的真实痛点先聊个背景。macOS 上但凡想把键盘效率玩出花来,基本绕不开 Karabiner-Elements。这个工具本身确实强大,能把任意按键改造成任意功能,支持按住、双击、同时按下这些复杂手势&a…

2026/11/4 3:28:57 阅读更多 →
鱼骨栅结构:GaN HEMT功率器件版图设计的电流均匀性与热管理优化

鱼骨栅结构:GaN HEMT功率器件版图设计的电流均匀性与热管理优化

1. 从“平行”到“鱼骨”:为什么布局拓扑决定了HEMT的生死1.1 一个被低估的版图陷阱做AlGaN/GaN HEMT功率器件的人,几乎都经历过这样的场景:器件仿真结果漂亮得不行,转移特性曲线陡峭、跨导峰值高、击穿电压也够,可流片…

2026/11/2 13:08:30 阅读更多 →

最新新闻

Electron桌面应用开发实战:从环境搭建到打包发布全流程

Electron桌面应用开发实战:从环境搭建到打包发布全流程

做前端这些年,我大部分时间都在跟浏览器标签页打交道,直到第一次把桌面应用跑起来,才发现原来自己一直被限制在地址栏和刷新按钮围起来的框框里。Electron这个词,最开始是在某段时间频繁出现在同事的讨论里,一个用HTML…

2026/11/4 1:35:24 阅读更多 →
滑盖智能锁T109深度解析:结构原理、安装调试与故障排查

滑盖智能锁T109深度解析:结构原理、安装调试与故障排查

简介:亚太天能T109滑盖智能锁产品说明书是一份PDF格式的官方技术文档,主要面向智能锁安装人员、终端用户及售后维护者,帮助快速掌握产品安装、配置与常见故障处理。全包仅1个PDF文件,大小4.37MB,内容结构清晰&#xff…

2026/11/3 10:57:27 阅读更多 →
PMSM弱磁控制原理与Simulink建模:高速AGV驱动系统设计指南

PMSM弱磁控制原理与Simulink建模:高速AGV驱动系统设计指南

上个月我在调试一台高速AGV的驱动系统,整车要求空载跑到8m/s,电机转速已经拉到额定点,驱动器的输出电压也顶到了母线电压极限附近。再往上踩速度指令,转速纹丝不动,三相电流反而开始震荡。那会儿我的第一反应就是&…

2026/11/3 11:35:49 阅读更多 →
C++核心知识点:从内存管理到STL的实战指南

C++核心知识点:从内存管理到STL的实战指南

C 这门语言我前前后后折腾了十几年,用它写过嵌入式驱动、做过游戏服务端,也搭过基础组件库。每次看到新人一头扎进"C 核心知识点"这个搜索词,我其实挺感慨的——这门语言的难点从来不是语法多,而是知识点之间的耦合太深…

2026/11/3 2:27:21 阅读更多 →
T109滑盖智能锁怎么装?安装调试与故障排查全攻略

T109滑盖智能锁怎么装?安装调试与故障排查全攻略

简介:亚太天能T109滑盖智能锁产品说明书以PDF格式发布,适合智能锁用户、安装人员与售后维修人员阅读。内容围绕T109系列指纹密码刷卡锁展开,先介绍前面板、后面板、锁体、机械钥匙、电池盒盖等部件名称与功能,再给出完整安装步骤&…

2026/11/3 10:47:27 阅读更多 →
LLM知识降熵:从信息垄断到理解权下放

LLM知识降熵:从信息垄断到理解权下放

你有没有过这种经历:翻开源码注释、论文摘要或者一份专业报告,每个字都认识,连在一起却像天书。想找人聊聊,身边要么没人懂,要么懂的懒得跟你解释。后来我试着把同一段内容丢给一个大语言模型,几秒钟之后&a…

2026/11/3 10:57:33 阅读更多 →

日新闻

周新闻

月新闻