Control

Content.

How does a computer tell a light, a speaker or a screen what to do, and how do we make three departments fire on one cue?

This is where the module pays off for lighting students specifically, and where audio and video students discover that show control is a shared discipline.

Learning outcomes#

By the end of this session a student can:

1. Distinguish state based from event based control and predict how each behaves when a packet is lost.
2. Describe DMX512 physically and electrically, and calculate its refresh rate limit.
3. Explain the relationship between DMX, Art-Net and sACN, and choose between them.
4. Calculate universe requirements for a pixel based lighting rig.
5. Choose appropriately between OSC, MIDI, MSC, serial and contact closure for a given trigger.
6. Explain what timecode is for and why a large show is built on it, and describe how LTC survives being recorded, played back at the wrong level and run backwards.
7. Explain what a dimmer curve does, why square law is the usual default, and where 8 bit dimming runs out.
8. Explain how an LED dims, and predict when a camera will see banding.
9. Read a fixture personality, calculate a patch, and identify an address overlap from its symptom.
10. Choose between HTP and LTP for a given channel, and say what each one costs.
11. Explain tracking against cue only, and predict where an edit will appear.
12. Build, measure and document a working cross department trigger chain.

Block plan#

If the class is split across two shorter meetings, split after Block C.

Block A: The anatomy of a control message#

Callback to Class 1#

Remember pulling the network cable in Class 1. The light held its last look, the audio stopped dead, the video froze. Today we explain why, and the explanation is the most important idea in this session.

State versus event#

Every control protocol is one of these two. Students who understand this distinction can predict the behaviour of a protocol they have never met.

This is why the light held and the video froze. DMX repeats itself into eternity, so the node had a value to keep outputting. The video was waiting for a "go to next" event that never came.

The design rule worth writing down:

Anything that must happen, exactly once, at exactly the right moment, is the fragile part of your system. Protect it.

Where were the fragile points in the venue you visited? Worth five minutes of argument.

The three parts of any control message#

Every protocol in this session, without exception, is a way of expressing these three things:

1. Address. Which thing? (A DMX channel, an OSC path, a MIDI channel and note.)
2. Value. What state, or what action? (A level, a colour, a cue number, a file name.)
3. Timing. When, and how fast? (Now, at this timecode, over 3 seconds.)

Introduce it here and then, as each protocol appears in Blocks B and C, ask the class to point at each of the three parts. By the fourth protocol they will be doing it unprompted, and they will be able to read a protocol they have never seen before. That transfer is the real objective.

Control versus media, restated with numbers#

From Class 1: control is tiny, media is enormous. One DMX universe is about 0.25 Mbit/s. One uncompressed HD video stream is 2,500 Mbit/s, so ten thousand times larger.

The practical consequence: control traffic almost never runs out of bandwidth. When lighting control fails on a network, the cause is almost always configuration (address, subnet, multicast, universe number), not capacity. Different fault families need different diagnostic habits. Audio and video failures are often capacity or clock. Lighting failures are almost always addressing.

Block B: The lighting family, on the wire and in the fixture#

DMX512, physically#

Introduced 1986, revised as DMX512-A. It is still the last hop to almost every fixture on earth, which for a technology this old is remarkable and worth a sentence about why: it is simple, cheap, and good enough.

• Electrically it is RS-485: a balanced, differential pair, which is why it survives long runs in an electrically noisy building.
• 250,000 bits per second.
• 512 slots per universe, each one byte, so 0 to 255.
• 5 pin XLR is the standard connector. 3 pin exists, is common, is not compliant, and mixing DMX and audio cable on 3 pin XLR causes exactly the confusion you would expect.
• Daisy chain only, never a star. No splitting a DMX line by putting a Y cable on it.
• Up to 32 devices per segment (32 unit loads on an RS-485 segment). Beyond that, a splitter or opto isolator, which starts a fresh segment.
• Terminate the last device, 120 ohms across the data pair. An unterminated line causes reflections, which cause flicker that comes and goes, which will cost a year one student an entire afternoon at least once in their life.

The refresh rate calculation#

Worth working through. It explains a lot of behaviour you will see.

Each slot is sent as 11 bits (a start bit, 8 data bits, 2 stop bits). Plus a break and a mark before the first slot.

512 slots × 11 bits = 5,632 bits
5,632 bits ÷ 250,000 bits per second ≈ 22.5 ms
plus break and mark, so roughly 23 ms per full frame
1 ÷ 0.023 ≈ 44 frames per second maximum

So a full DMX universe updates about 44 times per second, at best. Consequences worth stating:

• That is the ceiling on how smooth a fast chase or a strobe effect can be.
• It is why very fast pixel effects need many universes, not a faster universe. The protocol has no faster gear.
• Some devices transmit fewer slots to go faster. This is legal and it is a real technique.

Dimming: what a level actually does#

A DMX value is a request. Between the number and the photons sits a curve, and the curve decides how the fade feels. This matters because your eye is not linear: its response to light is roughly a cube root, so a lamp emitting half its light looks about three quarters as bright.

Send that through a linear curve and the top half of the fader does almost nothing you can see, while everything happens in the bottom third. A slow fade to black sits still, then falls off a cliff. Send it through a square law curve, where output is the square of the fader, and the squaring almost exactly cancels the cube root in your eye. Fader position and apparent brightness now move together, which is why square law is the default on most consoles.

Then the resolution problem. An 8 bit dimmer has 256 levels. At the top of a fade one step is a fraction of a percent and invisible. At the bottom, one step is a large share of what is left, and the square law makes it worse by squaring an already small number. So a fade that is smooth for four seconds comes apart in the last half second, always in the same place.

16 bit dimming puts 256 intermediate levels between every one of those steps. That is the entire reason a fixture offers a fine channel, and the reason a designer asking for a five second fade to black on an 8 bit rig is going to be disappointed by something that is nobody's fault.

How an LED actually dims, and why the camera sees it#

An LED does not dim. A filament dims, because you can feed it less power and it glows less. An LED run at reduced current shifts colour, so instead it is switched fully on and fully off, very fast, and left on for a fraction of each cycle. That fraction is the level. This is PWM, pulse width modulation, and it is the same trick as everything else in this module: a smooth quantity turned into a rate.

Your eye averages it and sees a steady dimmer level. A camera shutter does not average, it samples, and if the exposure is short enough to catch only a few PWM cycles, each frame lands on a different amount of on time. With a rolling shutter, where each row of the sensor starts a fraction later than the one above, every row catches a different slice, and you get bands.

Nothing is broken when this happens. The fixture is doing exactly what it was told. The fix is one of three things: raise the PWM frequency in the fixture menu, slow the shutter, or use a fixture whose PWM rate is high enough that any realistic shutter averages hundreds of cycles. That last one is what "flicker free" on a spec sheet means, and it is worth checking against the actual camera at the actual shutter, because it will look fine on the monitor in the room and show up on the broadcast feed.

A fixture personality, and the footprint#

A fixture reads the slot at its address and a run of slots after it. How many, and what each one means, is the personality or mode, and it is decided by the fixture, not by the desk.

A modest moving head might use eight:

Two things follow, and both cause real faults.

Ranges inside a byte. Strobe, colour and gobo pack a whole behaviour into one value using bands. The same DMX value means different things on two fixtures, so the manual's channel chart is not optional reading.

16 bit, which is two bytes and an agreement#

Start with the thing that surprises people: there is no 16 bit DMX. The wire has carried single bytes, one after another, since 1986, and it still does. 16 bit is an agreement between the desk and the fixture that two particular slots are to be read as one number:

value = coarse × 256 + fine

Coarse is the top eight bits, fine is the bottom eight. So the fine byte is not a smaller version of the coarse byte, and this is the sentence to hold on to: fine is the gap that coarse leaves behind. Run fine from 0 to 255 and you travel from one coarse position exactly to the next, and no further. 256 coarse positions, each divided into 256, is 65,536.

Now the reason anyone bothers. A moving head with 540 degrees of pan, on 8 bit, has 255 steps across that sweep:

540° ÷ 256 coarse positions   = 2.11° per coarse step
at a 20 m throw               = 20 × 2.11 × π/180  ≈ 0.74 m of arc

Three quarters of a metre. On a snap that is invisible, because the beam was going somewhere anyway. On a fifteen second creep across a cyc it is a stutter, and it is the kind of fault a designer describes as "the movement looks cheap" without being able to say why. At 16 bit the same sum gives 540 ÷ 65,535 = 0.0082°, which at 20 m is under 3 mm. Tilt is the same argument with 270 degrees in the numerator.

Dimming is the same idea in a different department, and you have already met it: an 8 bit dimmer has 256 levels, and at the bottom of a fade one step is a large share of what is left, made worse by the square law squaring an already small number. That figure is in the dimming section above. The mechanism is identical; only the consequence differs.

What it costs. Every fine channel is a whole extra slot, on every fixture, forever. Pan, tilt and dimmer at 16 bit is three extra slots each fixture, and 512 does not get any bigger.

So the judgement is per parameter, not per fixture. Pan and tilt on a slow-moving rig, yes. The dimmer on anything that fades from black in front of an audience, yes. A gobo wheel, a colour wheel, a strobe: no, because they were never going to move smoothly and a fine channel there buys you nothing but a smaller universe.

And the fault it causes. Coarse and fine are read as a pair. Patch a fixture one slot out and the fixture reads coarse where fine should be, so the head jumps in huge arcs and jitters, which looks exactly like broken hardware. Before anyone opens a case: check the patch, check the mode, check that the fixture is in the 16 bit personality the desk thinks it is in. A fixture in an 8 bit mode being sent a 16 bit profile fails in the same way and for the same reason.

Going deeperColour, and why two fixtures at the same temperature do not match#

Class 2 established that three numbers make a colour, because your eye has three cone types. Here is what that leaves out, and it is the part that decides which fixture you specify.

Hitting a colour and rendering a colour are different problems. An object does not have three cone types: it reflects whatever wavelengths it happens to reflect. Point a three spike RGB source at a costume that only reflects between 610 and 660 nm, and if the red emitter peaks at 632 nm with nothing either side, there is very little there for it to reflect. Objects that line up with a spike come back over saturated; objects that sit in a gap come back muddy or the wrong hue. The meter still says you are on target.

That is what a CRI or TM-30 figure on a spec sheet is trying to describe, and it is what the extra emitters in a seven colour fixture are buying. It is also the honest answer to why one costs four times the other.

Then colour temperature, and the axis nobody prints on the fixture. Kelvin says where a white sits along one curve, the Planckian locus, running from warm tungsten through daylight to cold blue. It does not say how far off that curve you are sitting.

That second axis is green against magenta, sometimes labelled Duv, sometimes just a plus green control. Two fixtures can agree on 5,600 K and still not match, because one is sitting green of the curve. Correcting it with the Kelvin control makes it worse. It needs the green control, or a minus green gel.

White is not a colour. It is an agreement, and a white balance is where the agreement is set.

Patching arithmetic#

Patching is addition, and the mistake is always the same one.

next address  =  this address  +  this fixture's footprint

When two fixtures overlap, both read the same numbers and both obey them. The symptom is a light that half works: right colour, wrong movement, or a fixture that flickers whenever a completely different one moves. Nothing on the desk shows it, because as far as the desk is concerned the patch is fine.

The version that catches people out is subtler. The footprint comes from the fixture's mode, so someone changing a mode in a fixture menu changes the footprint without touching the patch, and a rig that was clean this morning has overlaps this afternoon. Leave gaps when you patch. They cost nothing and they save an hour.

RDM#

One paragraph. Remote Device Management adds a return path over the same cable, so a controller can discover fixtures, read and set their addresses, and read status like lamp hours and temperature. It is bidirectional DMX. It requires RDM capable splitters, which is why it often does not work in a venue that has RDM capable fixtures.

Block C: The lighting family, from the desk to the rig#

Going deeperEffects, which are not programmed one cue at a time#

A rig that appears to be doing something complicated is usually doing something very simple to every fixture at a different moment. An effect engine holds three numbers:

• a shape, a curve over one cycle: sine, ramp, step, triangle
• a rate, how many cycles per second
• a spread, how the offsets are distributed across the selected fixtures

Nothing moves. Twelve lamps fade at twelve different phases of the same curve, and your eye reads travel. Spread is the control that matters artistically, because it decides whether the rig reads as one gesture or as movement along a line, and the shape barely changes that.

Two practical consequences. An effect is state, not events, so it keeps running when the network stops, which is the Class 1 point about state protocols arriving in a useful place. And an effect running on top of a cue is a second source claiming the same channels, so everything in the next section applies to it.

When two sources want the same channel#

A show network usually has more than one thing capable of writing to a universe: the main console, a backup, a media server doing pixel mapping, a house desk somebody forgot about. When two of them claim the same slot, something has to decide, and there are only two rules.

HTP, highest takes precedence. The bigger number wins. Nobody can black out a channel somebody else is holding up, which is why this is the traditional rule for dimmers and why it is safe. The cost is that you cannot take a light out while another source is holding it, so a busking desk left at 30 percent puts a quiet floor under the whole show and every blackout has a glow in it.

LTP, latest takes precedence. Whoever moved last owns it. This is necessary for anything that is not a quantity: the highest of red and blue is not a colour, and the highest of two pan positions is not a position. So moving lights are LTP and dimmers are usually HTP, often inside the same desk. The cost is that a stray source can steal a channel and nothing in the numbers tells you which one did it.

On a network this stops being theoretical. Art-Net and sACN both allow several senders on one universe. sACN has a priority field, 0 to 200, so a backup console can sit on the same universe at lower priority and take over cleanly when the main one stops sending. Art-Net has no such field, which is why an Art-Net rig with two senders is decided by whichever packet arrived most recently, and why two people can each be certain the rig is theirs.

Cues, and the idea that confuses everybody once#

A cue is not a picture of the stage. It is a set of changes plus a set of times, and the times are the part people forget: a fade time, sometimes a separate one for up and down, a delay before it starts, and sometimes a follow that fires the next cue automatically.

The confusing part is what a cue stores.

Tracking. A cue only records the channels it changes. Anything it does not mention keeps doing whatever it was doing. Change a wash in cue 12 and the change runs forward through every later cue that never mentions that wash. This is the point rather than a fault: on a show with four hundred cues, you want to change the warm wash once.

Cue only. Every cue stores a complete state, so an edit stays exactly where you put it. Predictable, and much more work.

Almost every professional console is tracking, and almost every first year student is surprised once, in a technical rehearsal, when a note in cue 12 turns up in cue 40. Knowing the word tracking is what turns that from a mystery into a setting.

The related trap. "Blocking" a cue means deliberately recording a hard value into every channel so that nothing tracks through it, usually to protect an act break. A show with blocks everywhere has thrown away the reason to use tracking, and a show with none can have a note from act one reappear in act three.

Getting DMX onto the network#

The generation by generation version of what follows, with what each step gave up, is on How we got here.

DMX ran out of room. A modern rig needs dozens or hundreds of universes, and cannot have dozens of separate cable runs from the control position. So we put universes inside network packets.

Which to choose. If everything supports sACN, use sACN, because priority and defined merging matter as soon as two consoles exist (a main and a backup, which is every professional show). Use Art-Net when a device only speaks Art-Net, which is still often. Do not run both to the same node unless you have thought hard about it.

The 2.x.x.x trap deserves a full minute: an Art-Net node on 2.0.0.10/8 and a laptop on 192.168.1.5/24 share a cable and cannot talk. This is the number one reason a year one student declares a node "broken". Link back to Class 3, row 4 of the subnet table.

Universe maths for pixel work#

The calculation every lighting student needs and few are taught early enough.

One RGB pixel        = 3 DMX channels
One universe         = 512 channels
512 ÷ 3              = 170 RGB pixels per universe (with 2 channels spare)

An RGBW pixel        = 4 channels
512 ÷ 4              = 128 RGBW pixels per universe

Worked example, do it with the class:

An LED batten has 60 RGB pixels. You have 24 of them. 60 × 24 = 1,440 pixels. × 3 channels = 4,320 channels. 4,320 ÷ 512 = 8.4, so 9 universes, and that is before a single moving light.

Then the follow up question that lands the point: what is the data rate of 9 universes? About 2.25 Mbit/s. Trivial. The constraint on a pixel rig is never bandwidth, it is universe count, node port count and processing. Bandwidth is not the enemy here. Configuration is.

Block D: The show control family#

OSC#

Open Sound Control. Despite the name, it is used far more for show control than for sound.

• Runs over UDP (usually) or TCP, on whatever port you configure.
• The message is a path plus arguments: `` /cue/12/start /eos/chan/5/level 75 /qlab/workspace/go ``
• Strength: human readable, flexible, carries real data types (numbers, text, floats), and almost every modern show product speaks it.
• Weakness, and it is a real one: there is no standard namespace. Every manufacturer invents its own paths. /cue/12/start on one product means nothing on another. You must read the manufacturer's OSC documentation every single time. The flexibility looks like a promise, and it is not one.
• It is event based. A lost OSC message is a cue that did not happen.

OSC in audio, specifically. Most current digital mixing desks accept OSC, and this is how a sound department automates itself without a show control system: a playback machine sends /ch/03/mix/on 1 before a cue and the channel is open before the actor speaks. Two patterns cover almost all of it:

The thing to check before promising it: whether the desk's OSC implementation is receive only, and whether it needs a specific port and a specific enable switch buried in a setup menu. Both are common, both are in the manual, and neither is discoverable by guessing.

MIDI, and MSC#

• MIDI is from 1983, musical instrument origin, still everywhere. Notes, control changes, program changes. Cheap, reliable, and universally supported.
• Using a MIDI note as a trigger is common, crude and works.
• MIDI Show Control (MSC) is a proper show control layer on top of MIDI: commands like GO, STOP, RESUME, addressed to a device type and a cue number. Designed for exactly our industry. It is old, limited and still in use because it is dependable.
• MTC (MIDI Time Code) carries timecode over MIDI. See below.

What you will actually do with MIDI. Three jobs, and they cover nearly everything:

Two practical points and then move on. MIDI over a DIN cable is a physical link between two boxes and has no addressing beyond its 16 channels; MIDI over USB is a connection to one computer and dies when that computer sleeps. And a control change carries 7 bits, so a fade driven by MIDI has 128 steps, which is the resolution argument from the lighting block arriving in a different department.

Going deeperTracking: telling the rig where somebody is#

A control message usually says do this. A tracking message says this is where the thing is now, sixty times a second, and lets every department decide what to do about it.

That difference matters more than it sounds. A follow spot operator is a person making an artistic decision continuously. A tracking system replaces the knowing where and leaves the deciding to each department: the light follows, the reverb follows, the projection maps onto a moving surface, the camera stays framed. One position stream, several answers.

PosiStageNet (PSN) is the open one, and the one to learn first.

That last row is the practical one. A receiver that reads only PSN_DATA gets a stream of numbers with no idea which tracker they belong to, so "the console sees positions but cannot tell which performer is which" is an INFO problem, not a DATA problem.

RTTrPM is BlackTrax's format, also published. It carries the same ideas plus individual point positions and zone information. Its famous trap is byte order: the header carries both a big endian and a little endian signature, so a parser that does not check which one it got decodes every position as noise.

FreeD is the camera one, from Vinten, carrying pan, tilt, roll, zoom and focus on UDP port 6000. It is what a camera tells a render engine so that virtual scenery moves correctly behind a real presenter.

What a year one student should take away. Tracking is the Four Flows argument again: this is media rate traffic wearing control clothing. Sixty updates a second per tracked object, times the number of objects, is real bandwidth with a hard deadline, and it degrades the way media degrades rather than the way cue triggers degrade. A dropped GO is a cue that did not happen. A dropped position is a light that lags behind a performer, which the audience reads as the light being wrong rather than the network being busy.

Ports, packet structures and the full gotcha list are in showstack, which is where these numbers came from.

Going deeperPJLink, and controlling a projector#

Projectors are the department that everyone forgets is on the network until somebody has to turn forty of them off.

PJLink is a manufacturer independent standard for basic projector control over IP, on TCP port 4352. It is deliberately small: power on and off, input select, mute, and a status query that reports lamp hours, errors and whether the thing is actually on.

%1POWR 1        turn on
%1POWR 0        turn off
%1INPT 31       select input
%1POWR ?        are you on?

That is roughly the whole vocabulary, and that is the point. It is supported across brands, so one control system can look after a mixed rig, and it is the reason a venue can shut down its projectors from one button rather than forty remote controls.

What it does not do. Anything creative. Lens control, geometry, blending and colour are all manufacturer specific, over the manufacturer's own protocol or a web interface. PJLink is housekeeping, and housekeeping is worth automating: a projector that reports its own lamp hours and its own error state is a projector that tells you it is dying before the show does.

Depth on any of these protocols belongs in the show networking and control elective. At year one the useful knowledge is which one to reach for, and what each one refuses to do.

Serial, RS-232 and RS-422#

Still everywhere in projectors, motorised screens, blinds, older video switchers and machine control.

• RS-232 is short run and point to point. RS-422 is balanced and goes further.
• Often carried over a network now, via a serial to Ethernet gateway.
• Why it survives: it is direct, deterministic and dumb. When it works, it always works.

Contact closure and GPIO#

The dumbest interface in the building, and the most reliable. Two wires. Touching them is a trigger.

Give it real respect out loud, because year one students assume newer is better. When the fire alarm has to stop the show, the interface is a contact closure, not an OSC message. Simplicity is a safety property.

TCP versus UDP#

The choice underneath everything above.

The genuinely counterintuitive part: for real time media, a retransmitted packet is worthless. By the time it arrives, its moment has passed. That is why almost all show media runs on UDP, the "unreliable" one. Reliability and timeliness are different goals, and we choose timeliness.

Timecode#

The spine of any large show.

• LTC (Linear Time Code) is an audio signal carrying the clock. You can hear it, it sounds like a fax machine, and it can travel down any audio path, which is exactly why it is used.
• MTC (MIDI Time Code) is the same idea over MIDI.
• Format: hours : minutes : seconds : frames.

What is actually in the sound. Each frame of LTC is 80 bits. Sixteen of them are the time itself, stored as BCD digits: four bits for frame units, two for frame tens, four for second units, and so on up to hours. Thirty two are user bits, free for a reel number or a date. The last sixteen are a sync word, 0011111111111101, identical in every frame ever recorded.

Three design decisions in that layout explain why LTC has outlived almost everything it was designed alongside:

• The bits are encoded biphase mark: a transition at every bit boundary, and one extra in the middle of the cell for a 1. The information lives in the transitions rather than in the level, so gain, polarity and a mediocre recording do not matter.
• 25 fps at 80 bits is 2,000 bits a second. That is audio, so any cable, recorder, desk channel or radio mic path that carries sound carries timecode.
• The sync word is asymmetric, so a reader can tell which way round it arrived. That is how a machine knows the source is running backwards, and it is why LTC works while a deck is shuttling.

• Frame rates: 24, 25, 29.97, 30. 29.97 drop frame exists because of a colour television compromise from 1953 and it still bites people. One sentence, do not go down the hole.
• The critical rule: everything on the show must agree on the frame rate. A machine at 25 fps following a source at 30 fps drifts, and drift is the failure mode that appears slowly, gets worse across the show, and looks like nothing is wrong at the top.

Why a big show is built on timecode. In cue based operation, an operator presses GO and everything after it is relative. In timecode operation, every department follows the same clock independently. Lighting, video, audio, automation and pyro each know what to do at 00:14:22:07, and none of them depend on the others. It is decentralised, repeatable and precise to a frame.

The trade off, and it is a real artistic one worth discussing with them for two minutes: timecode is precise and it does not listen. A cue based show breathes with the performance. A timecode show does not wait for the laugh. Which is correct depends entirely on the work, and that is an artistic decision made on technical grounds, which is the whole argument of this module in one example.

Block E: Lab, build a cross department trigger chain#

Assessed, 20 percent. The largest formative piece before the exam.

Teams of four, one from each specialism where the cohort allows. Each team builds a chain where one trigger fires all three departments.

The required chain#

   TRIGGER
      │
      ▼
   ┌──────────────────────┐
   │  Cue playback app    │  (QLab, Companion, or equivalent)
   └──┬────────┬────────┬─┘
      │        │        │
      ▼        ▼        ▼
   AUDIO   LIGHTING   VIDEO
   plays    changes    changes

• The trigger is a GO button, a MIDI note, or timecode. Team's choice, and they must justify it.
• Lighting must change via sACN or Art-Net to a node or a visualiser.
• Video must change via OSC or MIDI to a second application or machine.
• Audio must play from the cue application.

Required deliverables#

1. It works. Demonstrated live to the lecturer. One trigger, three departments.
2. A signal flow diagram. Every box named, every line labelled with protocol and physical medium. Same standard as the the production visit sketch, done properly this time.
3. An IP schedule for everything on the network.
4. A measured latency. From trigger to each of the three outputs. Method is their choice (a phone camera at high frame rate pointed at the trigger and the output works, and is a genuinely used professional technique). State the method and the number.
5. A failure analysis. Name three things that would break this chain, and what you would do about each. At least one must be a network fault from Class 3.
6. One paragraph on protocol choice. Why OSC and not MIDI here, or the reverse. Trade offs named.

Deliberate difficulties to introduce, once they have it working#

Do not give these until the chain runs. Then walk round and do one to each team.

• Unplug the network mid cue, and explain what happened to each department, using the state versus event model from Block A. This is the Class 1 cold open, closed.
• Change one node's IP by one digit. Time how long they take to find it.
• Add a fourth department, and see whether your diagram made that easy or hard. This is criterion 3 of the rubric arriving in person.

Common misconceptions in this session#

Reading a wrong belief with its correction attached does very little. Spot the myth, on the Practice tab, puts each of these claims in front of you bare and asks you to commit before the correction appears.

• "DMX is old so it is bad." DMX is old because it is good enough and simple. Simplicity is a reliability property.
• "Art-Net and sACN are the same." Different transport, different addressing conventions, different priority behaviour. The distinction matters as soon as there are two consoles.
• "A universe is a cable." A universe is 512 channels of data. It might arrive over a network and never touch a DMX cable until the last hop.
• "More universes means more bandwidth is needed." Lighting control is tiny. The constraint is universe count and node ports, not bandwidth.
• "UDP is unreliable so it is worse." For real time media, a retransmitted packet is worthless. UDP is the correct choice, not a compromise.
• "OSC is a standard so devices will understand each other." OSC standardises the envelope, not the address. Read the manual.
• "Timecode is more professional than cue based operation." It is more precise and less responsive. Different tool, different work.

Sources and further study#

If this class interested you: the ESTA standards themselves are free to download, and ETC publish free console training. Both are on Where to go next.

The index this module checks itself against#

showstack, the open index of live entertainment technology. Protocols with their ports and multicast ranges, standards with their designations, hardware and software with what each one actually speaks, and bilingual EN / 繁中 vocabulary, with a citation on every fact and a free JSON API.

Three ways to use it in this module:

• Check a number before you repeat it. Every port and date in these notes was verified against it.
• The interop checker: pick two products, get the protocols they share and in which direction. That is the question this whole module is teaching you to ask.
• The field tools, 62 of them, for the calculations this module does not examine but the job needs: DIP switch addressing, bridle angle, voltage drop, noise dose, RF intermod, beam angle.

The two documents below are the actual standards behind almost everything in this class, they are free, and most working technicians have never opened either. Read the first ten pages of each.

Both come from the ESTA Technical Standards Program, where every published standard is free.

For OSC, there is no equivalent: the specification standardises the envelope, not the address. The only useful documentation is the manufacturer's own OSC reference for the specific product in front of you, and you will read a new one on every job. That is not a gap in your knowledge, it is the nature of the protocol, and knowing that saves you looking for a standard that does not exist.

For timecode, SMPTE ST 12 is the document, and it is paid. The practical knowledge you need is the frame rate list and the drop frame rule, both of which are in the reference card.

Homework before Class 5#

1. Finish and submit the trigger chain documentation pack.
2. Calculate the universe requirement for this rig: 36 LED battens of 40 RGBW pixels each, plus 18 moving heads at 32 channels each, plus 24 conventional dimmer channels. Show the working.
3. Learn the protocol block of the Numbers card. The DMX refresh calculation will be in the quiz.