LED Player

The name suggests something that plays media. It does not. LED Player is lighting control software, the kind used to drive stage fixtures and architectural installations, and it speaks the protocol that has run professional lighting for decades.

That protocol carries channel values down a cable to fixtures, each of which listens on the addresses it has been given. One channel might be brightness, the next red, the next the angle of a moving head. The software’s job is turning what you want the lights to do into those numbers, several hundred of them, updated continuously.

If you arrived here looking for control over the coloured lights inside a computer, that is an entirely different category and a tool that unifies lighting across desktop hardware is what you actually want.

Profiles and patching, which come first

Nothing works until LED Player knows what each fixture is. A profile describes that, mapping which channel does what for a particular model, so the interface can offer a colour picker rather than three numbered sliders.

LED Player ships with a large library of existing profiles covering thousands of fixtures, and includes an editor for creating, renaming, copying, importing, updating them when a fixture is missing or behaves differently from its documentation.

Patching is the step that connects profiles to reality. Each fixture is assigned its starting address, and the software addresses across many universes, each carrying its own set of channels. Graphical addressing makes that less painful than typing numbers, which is what the process used to involve.

The matrix editor and the effect generator

Where fixtures sit in a grid, which is how most installations are built, the LED Player matrix editor handles them collectively. You name the matrix, set its dimensions, and choose the order the addresses run in, because a strip wired from the right produces mirrored results otherwise.

The test playback in that editor is the feature that saves an afternoon. Running it lights fixtures in sequence so you can see whether the order you told the software matches the order somebody physically wired, and discovering a reversed row before programming a show rather than during it is worth the whole exercise.

Effects are generated rather than drawn. Colour effects across a group and pan and tilt movement patterns for moving fixtures come from a generator with parameters, which is how a rainbow chase across forty fixtures gets built without setting forty values by hand.

Scenes, steps, timeline

The structure underneath LED Player is simple once stated. A step records a fixed level for every channel, with a hold time and a fade time attached. A scene is a series of steps played consecutively, and a show is scenes arranged and triggered.

That model covers both a slow architectural fade and a fast chase, since the difference is only the timing values in the steps.

A graphic timeline shows the triggers laid out, which matters when a show has scenes firing at different times and you need to see the shape of it rather than reading a list. Scheduling extends that to dates, so a building can run one look on weekday evenings and another at the weekend without anybody touching it.

Real-time visualisation of the output means you can watch what is being sent while programming, and a companion viewer renders beams, gobos and prisms so a show can be built before the rig is hung.

Running a show with no computer attached

For stage work a computer running the show is normal, and LED Player supports that. For a building facade, a shop window or a restaurant, leaving a computer switched on permanently is not.

LED Player writes a show into the memory of a compatible control interface, which then plays it with nothing else attached. The scenes, the schedule and the triggers all live in the hardware, so the installation runs itself and the computer is only needed when the show changes.

That capability is what separates lighting control software aimed at installations from software aimed at live operation. It also ties you to interfaces that support it, which is the practical constraint to check before committing, since the writing depends on the hardware accepting it.

What it asks of you

LED Player offers live control while a show runs, through the mouse, the keyboard, incoming protocol data or a musical instrument controller, which covers an operator adjusting things during an event.

None of this is difficult once the concepts are familiar, and all of it is opaque until they are. Universes, channels, patching, fades and holds are the vocabulary of a field rather than of a program, and somebody arriving without them will find the interface logical and meaningless at the same time.

Conclusion

LED Player is a proper lighting control application wearing a misleading name. Profiles, patching, a matrix editor with a test that catches wiring mistakes, generated effects and a timeline cover what programming a show actually involves, and the stand-alone writing is what makes it suitable for installations rather than only for events.

Judge it on whether you know the field. Somebody comfortable with universes and channels will find it capable and quick to learn, and somebody who is not will find that the software assumes an education it does not provide. Confirm your control hardware supports writing a show to memory before planning an installation around that feature, because it is the one thing here that depends on equipment rather than software.