Stage Precision vs TAIT LightStrike: choosing the translation layer
Two ways to sit between position sources and the rig. The choice is about scope, how much show logic you want in the layer, and who maintains it.
What you’re deciding
Neither of these senses anything. Both take position data that already exists and turn it into something the rest of the show can consume, which makes them easy to conflate and easy to mis-scope. The decision is not about capability lists. It is about how wide the chain is and how much of the show lives inside the layer. LightStrike has a clear centre of gravity: automation data becoming console-ready stage coordinates, with performer tracking able to join the same hub. Stage Precision is broader, with a low-code logic environment and reach into media servers and real-time engines. Choose wrong and you either buy scope you never use or you outgrow the layer during tech.
What each is built to do
LightStrike is purpose-built for the automation-to-lighting lane. It ingests encoder counts from automation platforms, applies coordinate transforms configured for the show, and hands the console clean stage coordinates over PSN, sACN or OSC. It can also take performer tracking alongside that, which makes it the hub where a show's position sources meet. Stage Precision starts from a wider premise: multi-source ingest, coordinate-space alignment between departments, and routing to consoles, media servers, DMX and ACN infrastructure, and engines like Unreal. If your chain runs automation in and lighting out, the narrower tool is the better-fitting one.
How much show logic lives in the layer
Every integration puts logic somewhere. On a LightStrike show much of it is the math: the formulas converting native track positions into stage coordinates, verified unit conversion, and live adjustment through tech. On a Stage Precision show the low-code environment invites more, because custom logic between source and consumer is what the platform is for. That is genuine power when the show needs conditional behaviour, blends between sources, or per-department transforms. It is also a liability if nobody scoped it, because logic accumulated during previews is logic nobody wrote down. Decide deliberately how much belongs in the layer versus the console.
Number of sources and number of consumers
Count both ends honestly. One source to one console rarely justifies a translation layer at all; direct integration is simpler and cheaper, and both platforms are the wrong answer to that question. Several position sources converging on lighting is the case LightStrike was built for. Several sources feeding several departments, where video and a real-time engine need the same number lighting is using, is where Stage Precision earns its scope, because the hard part stops being conversion and becomes making every department agree on where the stage is. The consumer list, not the source list, usually decides.
Who maintains it after opening
The layer outlives the people who built it. A run crew inherits a show file, and whether they can maintain it depends on how legible the logic is and how well it is documented, which is a deliverable rather than a courtesy. A narrower configuration with well-documented formulas is easier to hand over and easier to fault-find at half hour. A rich logic layer needs its behaviour written down in terms the crew uses, plus a clear account of what to check when a source drops. On a long run, maintainability may outweigh the feature comparison entirely.
List every position source and every consumer before you name a platform. If the list is one source and one console, use neither and integrate directly. If sources are mostly automation and the consumer is lighting, LightStrike fits the lane it was built for and the handover stays simple. If the consumer list runs past lighting into video or a real-time engine, and departments must share one coherent coordinate space, Stage Precision is doing work the narrower tool would strain against. Then apply the maintenance test: name the person who will maintain this at show forty, and pick the option you can document to that person.
Is a translation layer a tracking system?
No, and this is the most common misconception. Neither platform puts sensors on performers or cameras in the rig. They read position data that already exists, whether from an automation system or from tracking systems that do sense, and convert it into something the console or another consumer can use. If nothing in the show currently produces position data, a translation layer has nothing to translate.
We already run automation. Does that change the answer?
It changes what tracking costs. When scenery and flying run on an automation platform, every axis already knows its position, so the work is extraction, translation and console integration rather than new sensing infrastructure. That points toward the automation-to-lighting lane by default. It stops being the whole answer as soon as unautomated bodies in open space also need to be tracked, which needs a sensed source alongside it.
Can these platforms coexist on one show?
They can, though it is worth asking why before you build it. Two layers means two places for the show logic to live and two things to fault-find under pressure. It is defensible when departments have genuinely separate ownership and a clean boundary between them. It is not defensible as an accident of procurement. If you end up there, document which layer is authoritative for each source and each consumer.