macOS Sonoma 14.7.5
In build 32460, the Laserdevice CHOP with Type set to EtherDream introduces a DC offset on the RGB output channels. This causes the laser to remain on during blanking segments where RGB values are zero, making blanking lines visible in the laser output. The issue can be compensated by adding a Pre-Add of -0.03 and Post-Add of -0.02 to all three RGB channels, but this was not necessary in previous builds. Note: it is unclear whether both Pre-Add and Post-Add are necessary, but something is shifting the RGB channel zero point in build 32460 that was not present before. It is also possible the offset is affecting the X and Y channels (channels 1 and 2) as well, however this is harder to notice visually in laser output.
Note: I may have the direction of the offset backwards — it is possible the RGB channels are being pushed into negative territory rather than positive, and my compensation values are correcting in the opposite direction. Either way something is shifting the RGB channel zero point in build 32460 that was not happening in previous builds.
This issue is visible in the following two videos: https://photos.app.goo.gl/PNbS1yYXzTJHzM7s7
The video quality is poor however you can clearly see the difference. One video shows the correct output — lots of tiny circles with clean blanking between them. The other video shows the buggy output — the same tiny circles but with red lines connecting all of them. Those red lines are blanking lines that should not be visible; they are being pushed into visible brightness range by the DC offset being applied to the RGB channels by the Laserdevice CHOP in build 32460.
The content being played back is analog wav laser show content — 5 channel wav files (channels: X, Y, R, G, B) generated with analog synthesizer hardware and software (VCV Rack), recorded as wav files, and played back through TouchDesigner’s Laserdevice CHOP into a laser projector via EtherDream. This same content plays back perfectly through an analog audio interface output path, confirming the content itself is correct and the issue is specific to TouchDesigner’s Laserdevice CHOP implementation in build 32460.
Tested and confirmed on builds 31760 and 32280 — both work perfectly with no offset needed. Build 32460 exhibits the issue consistently.
I am writing this report from home where I have an EtherDream with hwrev 10, swrev 2, protocol 0, maxrate 100000, connecting via USB ethernet adapter (Realtek RTL8153) at 10.1.1.22 port 7765. The multiple additional EtherDream units and lasers on which I reproduced this bug are not available to me at the moment and I cannot confirm the hardware versions for those units. I can confirm which Etherdream version the other units are when I’m back at the studio on Monday.
The same hardware and content works correctly when using Liberation software or an analog audio interface output path, isolating the issue to TouchDesigner’s Laserdevice CHOP implementation in build 32460.
