Hi everyone,
There’s an issue when sending frames with lots of points to Helios DACs that can cause Liberation to crash. The next build will not have this issue but in the meantime watch out for complex clips, or setting the scanner speed very low when using Helios.
Thanks so much to @Lib.Lobberson for helping me get to the bottom of this.
The nerdy details for those of you that are into this kind of thing 
Most DACs require a constant stream of point data which determines the path and colour of the laser, and there are usually around 30,000 points per second to get high fidelity output.
Internally, Liberation has a “frame” system, where each frame of animation is calculated and sent into the point stream. If the frame is very simple, only requiring a few points, then Liberation will send it over and over again until a new frame is ready.
Helios is different from the other DACs because it has its own frame system, rather than just a stream of points. Originally when I implemented the Helios code I broke up the point stream into arbitrary Helios frames and bypassed the Helios frame system altogether.
However, it didn’t seem to like this, and I was noticing the occasional dropout between frames. I don’t think it had been tested by its developer with a continuous stream of points across frames.
So I instead made a special system where I actually join up Liberation frames and Helios frames. Here’s where the issue arose - Helios frames are limited to 4096 points, and I wasn’t correctly limiting this; Liberation could sometimes send a frame with more than that.
I’ve changed it now so that it clips the number of points at 4096 - this isn’t ideal as longer frames will be cut short, losing content. But for most normal use cases this should be absolutely fine. So if you’re using Helios, update to the new build when I post it.
cheers!
Seb