FIXED:[2025.30280] Lasers flickery with helios, need large queue time to match 2023 performance

Bugs
1

I’ve been working with lasers in Touch for a few years now to great results. Upon booting up my project in the 2025 experimental build, I was pretty disappointed to see my patterns completely botched. Even after transitioning my laser and helios DAC chops to the new ones (laser and laser device), messing with settings, trying the new ID parameters and lascorner stuff, nothing seems to get patterns even close to looking like how they used to except changing the queue time from .1 to .5+. That doesn’t even help with some patterns though as some don’t seem to display at all.

I even made a new fresh project with just a simple circle with POPs and that will be super flickery and laggy unless the queue time is above 0.5.

I wish I could test this with other DACs, but I unfortunately only have access to two Helios (same thing on both of those).

Any ideas on such a drastic difference in these outcomes between these two versions? The 2023 build I had been using was 2023.12120.

For now, I can at least use my main project on 2025 with pops for visuals, then still run the 2023 build simultaneously with my laser stuff.

3

Hi @conradhellman.art, sorry this slipped through the cracks, we can look at it now. Do you have the original 2023 project file we could use to check behavior in 2023 and then load it into 2025 ourselves to compare? If you do not want to share it publicly you can email it to support.

4

Hello Ben!

All good on the delay - I know this is a pretty niche issue on an experimental build!

I’ve recorded a quick demo of the issue and you can watch it here: https://youtu.be/Kd8gZzG8jvw

You’ll see in the video it’s not a project specific issue, I can recreate it with just a few nodes in a fresh file. It definitely feels very specific to the Helios hardware. I have no doubt there are significant improvements from the rewrite on other DACs, or maybe even the laser type I have is part of the issue?

I’d be happy to reply with any other info I can gather for you. Not sure what that would be though.

The hardware is 2x Helios Laser DAC + Unity Raw 3 (The problem is identical on both pairs) plugged into a USB 3.2 port, though I don’t think they use any additional speed past 2.0 as I get the same results even sending it through a USB 2.0 speed Ethernet to USB converter.

5

It does seem to me like more of a problem with our Helios output rather than with the Laser CHOP itself.

On the Helios front, between the 2023.10000 and 2025.30000 series of builds we made a couple of changes:

  1. Updated our Helios SDK to the latest v11.0
  2. Changed Helios output to a full point structure which supports 16-bit color (increased from 8-bit in previous versions) and 4x 16-bit user fields

It seems like the larger point structure size might be causing issues. Does lowering the output rate on the Laser CHOP improve the issue?

6

I will test that as soon as I can this weekend! I can’t say I’ve messed with that one since I’ve always just kept it synced with the maximum of my lasers (30,000).

8

Was able to look into that suggestion today. See the video below for the results.

I did not notice any improvements with different output rates. Once you get really low it gets worse, of course. I did notice some interesting behavior with the queue time though (see second half of video). In 2023, I would notice a smooth decrease in artifacts/errors when I raise the queue time, but in this case there is the flickery effect until exactly .45 queue time. .44 queue time flickery, .45 queue time is perfect beam.

Maybe that gives some info onto what the issue might be? I can do some more testing - let me know what specifically you’d want to see!

9

Thanks for testing. I’ll try to reproduce the issue locally.

10

I tested and was able to reproduce. The problem is that older devices and firmware do not support the full/extended frames that we switched to in 2025.30000. I will fix it so that it falls back to the small frames (ie. with 8-bit color and no user channels) when the device does not support it.

11

Good to hear! For my own info - is that a problem with the Helios, period? And with this in mind what exactly would I be missing out on by continuing to use the Helios instead of a better DAC with these new improvements? Less precise color? Something with the corner point controls?

Thanks again for looking into this!

12

Extended frames are 16-bit color, so more precision and more total colors (281 trillion vs 16 million), basically. Additionally, extended frames support user fields which can expose custom functionality, or additional colors like yellow or cyan, depending on configuration.

For comparison: all EtherDream devices support 16-bit color so that is one difference between them.

13

Awesome, thank you so much!

14

The issue will be fixed in the next experimental we release: 2025.31328+. As mentioned earlier, devices that do not support full/extended frames will instead automatically fallback to use the older 8-bit frames (which also means no user channels). Thanks for the report.

2 Likes
15

Hello,

I have also been trying to get TouchDesigner → Helios ILDA → Unity RAW 1.7 working, and I’ve found that TouchDesigner crashes about 50% of the time when the Laser Device CHOP is turned off (full 2025.31760 version, as well as when testing in the non-commercial 2026 version).

The first thing to note is that everything works perfectly with my LaserWorld DS-1000RGB. It is completely stable.

After struggling with the Unity RAW 1.7, during which time I couldn’t get any laser output at all, I eventually followed a workaround described in a 2022 thread. This involved rolling back to the Helios DAC CHOP, activating the laser, quitting TouchDesigner, and then starting the latest version of TouchDesigner and using the Laser Device CHOP.

After doing this, I do get laser output, and with some adjustments to the Laser Device CHOP, I now have a stable image. (I can speculate that the Helios DAC CHOP activates something in the Unity RAW 1.7 that the Laser Device CHOP does not, but really have no idea!). However, it does now work for now, even after powering the laser off and on again.

But the TouchDesigner crashes are concerning. It happens even with the smallest test patch, but not systematically.

Any ideas?

If it’s of any help, below is the extract from the crash report.

Translated Report (Full Report Below)

Process: TouchDesigner [22653]
Path: /Applications/TouchDesigner-November2025.app/Contents/MacOS/TouchDesigner
Identifier: ca.derivative.TouchDesigner
Version: 2025.31760 (2025.31760)
Code Type: ARM-64 (Native)
Role: Foreground
Parent Process: launchd [1]
Coalition: ca.derivative.TouchDesigner [10542]
User ID: 501

Date/Time: 2026-02-06 10:12:21.5346 +0100
Launch Time: 2026-02-06 10:11:40.4192 +0100
Hardware Model: Mac14,5
OS Version: macOS 26.2 (25C56)
Release Type: User

Crash Reporter Key: 0DC73868-BD08-6044-0C9C-20B968D404E8
Incident Identifier: 8B66D253-7887-4BFB-83CE-811020AF1CA7

Sleep/Wake UUID: 8BA2C704-F452-408E-AEC1-00BD6CB45861

Time Awake Since Boot: 310000 seconds
Time Since Wake: 41330 seconds

System Integrity Protection: enabled

Triggered by Thread: 71

Exception Type: EXC_BAD_ACCESS (SIGSEGV)
Exception Subtype: KERN_INVALID_ADDRESS at 0x0000000000000028
Exception Codes: 0x0000000000000001, 0x0000000000000028

VM Region Info: 0x28 is not in any region. Bytes before following region: 4371873752
REGION TYPE START - END [ VSIZE] PRT/MAX SHRMOD REGION DETAIL
UNUSED SPACE AT START
—>
__TEXT 104958000-10495c000 [ 16K] r-x/r-x SM=COW /Applications/TouchDesigner-November2025.app/Co

Thread 71 Crashed:
0 libUT.dylib 0x10b01db84 0x10afbc000 + 400260
1 libUT.dylib 0x10b104da4 0x10afbc000 + 1346980
2 libUT.dylib 0x10b104d14 0x10afbc000 + 1346836
3 libsystem_pthread.dylib 0x194169c08 _pthread_start + 136
4 libsystem_pthread.dylib 0x194164ba8 thread_start + 8

Thread 71 crashed with ARM Thread State (64-bit):
x0: 0x0000000000000001 x1: 0x0000000000000060 x2: 0xfffff0007fc00000 x3: 0x0000000000000001
x4: 0x0000000b335350c0 x5: 0x00000000000000a0 x6: 0x000000000000003c x7: 0x0000000000000000
x8: 0x0000000000000000 x9: 0x000000007fbe76fb x10: 0x0000000000000000 x11: 0x0000000000000000
x12: 0x014c626280418904 x13: 0x014c5262004180a0 x14: 0x0000000000018800 x15: 0x000000000000004e
x16: 0x952d000b33535040 x17: 0x00000004c52620a0 x18: 0x0000000000000000 x19: 0x0000000af0291880
x20: 0x0000000b19d18000 x21: 0x0000000000003e80 x22: 0x000000003f28f5c3 x23: 0x0000000000000001
x24: 0x0000000000000000 x25: 0x0000000000000000 x26: 0x0000000000000000 x27: 0x0000000000000000
x28: 0x0000000000000000 fp: 0x00000001737caf70 lr: 0x000000010b01dcfc
sp: 0x00000001737caf20 pc: 0x000000010b01db84 cpsr: 0x60001000
far: 0x0000000000000000 esr: 0x56000080 (Syscall)

16

Thanks for the crash report. I believe I know what the problem is and I will implement a fix.

Regarding your connection issue:

What does the Laser Device CHOP’s Info CHOP channel supports_extended_frames report? When it’s failing to send, is the Helios device successfully scanned and actually in the drop-down Device menu of the Laser Device CHOP?

In your working case with the LaserWorld DS-1000RGB, are you also sending via Helios?

I’m not sure what the 2022 build triggered to get it to work because we aren’t setting anything on the device, only querying some device info and writing frames to it. But in that build Helios communication is done using 8-bit color frames, whereas in the newer builds it uses 16-bit color, with 8-bit color as a fallback if the device doesn’t support 16-bit, so perhaps it has something to do with that. The supports_extended_frames channel will report which one it’s doing.

17

Today I again needed to go through the procedure of first booting the 2022 version of TD and activating the laser with the old HeliosDac to get the laser light to work. Then opening new TD to be able to use the Laser Device CHOP.

I’m guessing that after my test from yesterday, even though I powered off and on again, maybe a capacitor or memory in the Unity laser preserved the info sent by the HeliosDac, which then discharged over night and causing the same symptoms today.

To answer your questions:

Laser Device CHOP’s Info CHOP says “0 supports_extended_frames”

When it’s failing to send, yes, the Helios device is successfully scanned and in the drop-down Device menu of the Laser Device CHOP. I can even hear the mirrors on the laser moving. On the rear of the laser there are RGB lights, which correctly illuminate to say what colour I’m sending out of the Laser Device CHOP, but the forth light (unlabelled) doesn’t illuminate. I guess that is the ‘laser active’ light. No info in the manual about that, but it lights up when the laser light is on.

With the LaserWorld DS-1000RGB I am also sending via Helios. Exactly the same setup. Works reliably first time with new TD / Laser Device CHOP.

Regarding the colours, then manual lists values 0-255, so 8-bit. So yes, maybe that’s the root of the problem.

Let me know if you need more diagnostics about the crashing.

Thanks.

19

After some debugging, I’ve implemented a fix that I believe addresses the communication issues with the Unity RAW 1.7 laser. However, I only have a LaserWorld DS-1000RGB, so I can’t reproduce and confirm that it is actually fixed. If you wish to test a build and verify on your end that it is indeed fixed then that would definitely be helpful. If you send me a direct message then I can provide you with a build.

21

Hi, Sorry for the late response (I didn’t see your reply). Yes please! Send me the fix and I’ll test.