I just bought a ether dream and am using the discount code to try liberation for a month.
Unfortunately I am not able to get any output from liberation.
I already tried MadMapper and LaserShowGen and those work flawlessly.
I looked into Wireshark with the ether dream dissector and noticed that as soon as I output anything from liberation, the light_engine_flags go to status 3 which means Emergency stop occurred due to overtemperature condition.
After that I have to repower the DAC in order to get it to work again.
This does not happen when using any other software mentioned above.
Welcome! Great to hear you’ve already been experimenting with Liberation and sorry you’re having some difficulties.
First off, I can assure you that the Ether Dream implementation in Liberation is solid. It’s actually my preferred controller, and I’ve run many large shows using it - including setups with around 50 Ether Dreams running from a single laptop - so it’s definitely something specific to your setup rather than a general issue.
Liberation uses its own custom Ether Dream driver that I wrote from scratch, with several extra checks compared to MadMapper or LaserShowGen. One of those checks is a custom routine to detect whether an Ether Dream is already in use before trying to connect. This is really important because if more than one app connects to the same Ether Dream, it will crash (from v3 firmware onwards). Earlier versions would just dangerously mix the signals!
A few things to check:
Make absolutely sure that none of those other apps (MadMapper, LaserShowGen, etc.) are still running in the background, as they can block the UDP port Liberation uses for Ether Dream discovery.
Disable Wi-Fi while testing, and make sure your wired Ethernet adapter is the highest-priority network interface. Some apps handle this differently and may “find” the Ether Dream more reliably depending on priority order.
Check that no firewall or antivirus software is interfering. Liberation uses UDP for discovery and TCP for streaming - both must be allowed. If you’re on Windows, add Liberation as an exception in Windows Defender Firewall.
If you’re still seeing no output, it would help to narrow down exactly what’s happening.
In the Controller Assignment panel, do you see your Ether Dream appear on the network?
When you allocate it to a laser, does it connect successfully (green square “light” next to it)?
If yes, has your computer been authorised correctly and are the lasers armed?
At this point, sniffing packets probably won’t tell us much - it’s likely something higher-level. I’ve honestly never seen that light engine flags at 3 before, and as far as I know, the over-temperature system isn’t implemented in the Ether Dream firmware! It should normally just report 0. Some parts of the protocol are a bit inconsistently implemented, so I wouldn’t worry too much about that message until we’ve ruled out the more common network-related causes above.
Let’s get a bit more detail on what you’re seeing in the Controller Assignment panel and we can take it from there.
For those following along, after a bit of research, it turns out my theory was correct!
As well as the R, G and B lines, the ILDA connector also has a separate intensity line - I think this was used historically for analogue blanking before lasers had individual colour modulation. These days it’s never implemented, and lasers just ignore it completely. At least, that’s what I thought!
When Christoph told me his laser was a Sollinger, it made me wonder if perhaps this legendary manufacturer was still wiring up the intensity input in the old-school (and technically correct) way. I double-checked my Ether Dream driver code and realised I was just setting the intensity value to zero. Once I changed it to the maximum value and built a new test version, his laser immediately came to life!
Future releases of Liberation will include this fix, so anyone with a similar laser will be good to go. Thanks again to Christoph for helping uncover another obscure edge case!
