Daniel sent us this one — he's asking about the tech stack behind theatrical lighting control. What actually lives inside that booth where the technical director sits, with all those sliders and panels for activating light sequences. What's the hardware, what's the software, and how does the whole thing actually talk to the lights themselves.
Oh, this is a fantastic question. I've been waiting for someone to ask this. And by the way — today's script is being generated by DeepSeek V four Pro.
Now back to the thing you've been waiting for.
So the first thing to understand is that what you see in that booth is just the tip of the iceberg. The lighting console — the thing with all the faders and buttons — that's the command center. But behind it is a whole stack of protocols, network infrastructure, and data distribution that most people never think about.
When I see a technical director slide a fader up and a light gets brighter, what's actually happening under the hood?
In a modern rig, that fader movement gets converted into a digital value between zero and two hundred fifty-five. That value gets packaged into a protocol called DMX512, which has been the backbone of lighting control since nineteen eighty-six. DMX stands for Digital Multiplex, and the five twelve refers to the number of channels you can send down a single cable — each channel is one byte of data.
Five hundred twelve channels per cable. So if you've got a big Broadway show with hundreds of lights, you're running multiple cables.
Multiple cables, or more commonly now, you're running DMX over Ethernet. That's where things get interesting. The modern standard is something called sACN — Streaming Architecture for Control Networks, though the acronym officially stands for Streaming ACN, where ACN is Advanced Control Network. It was developed and standardized as ANSI E one point three one.
The standards body being ESTA, the Entertainment Services and Technology Association.
Here's what makes sACN elegant — it takes those DMX universes, which is what we call each bundle of five hundred twelve channels, and wraps them in IP packets. So now you can send thousands of universes over standard network infrastructure. A single Cat6 cable can carry hundreds of universes simultaneously.
The physical layer went from dedicated DMX cable — which is basically five-pin XLR — to regular Ethernet cable.
Right, and that's a huge shift. But let me back up slightly, because the console itself is worth understanding first. The two dominant players in the high-end market are ETC with their Eos family, and MA Lighting with the grandMA3. These are the consoles you'll find on major Broadway productions, West End shows, and large-scale television.
They're not competing for the same use case, are they? My understanding is Eos dominates theater and grandMA dominates live events and television.
That's the general split. The Eos family — the Eos Ti, Eos Apex, Gio, Ion — these are purpose-built for theatrical cue-based programming. A theatrical lighting designer builds a cue stack, which is a sequential list of lighting states. Cue one might be a warm wash for an interior scene. Cue two fades to a cool moonlight look over four seconds. Cue three snaps to black in zero seconds. The console handles all the transitions — the crossfades, the timing, the split fades where different parameters move at different rates.
The faders I see on the console? Those aren't like an audio mixing board where each fader corresponds to one light.
Those faders are usually submasters. A submaster is a fader that you can assign to control a group of channels at a proportional level. So submaster one might be your front light wash, submaster two your overhead backlight. The operator can ride those faders during a show to adjust levels on the fly, but the core of the performance is running off that cue stack.
Hitting "go" advances to the next cue.
The big "go" button. It's almost comically prominent on Eos consoles — this large, backlit button that's designed to be impossible to miss. In a theatrical context, the board operator is essentially executing a pre-programmed sequence. The designer has spent weeks in tech rehearsals building every cue, setting every timing, and the operator's job during the show is to hit go at exactly the right moment.
Which sounds simple until you realize they might be executing hundreds of cues in a single performance, often timed to specific lines or stage movements, while also managing manual fades and handling any technical issues that arise.
The cue stack isn't just levels. A single cue on an Eos console can contain intensity data for every light, plus color mixing values if you're using LED fixtures, plus position data for moving lights, plus gobo selections, focus positions, zoom, and any number of other parameters. A complex cue on a Broadway show might be controlling thousands of individual parameters.
Let's talk about the moving lights piece, because that's where the data demands get serious. A conventional fixture — just a lamp in a housing — needs one DMX channel for intensity. How many channels does a modern moving head need?
A high-end moving head like a Martin MAC Ultra or a Robe Forte can easily consume thirty to sixty DMX channels. You've got pan and tilt — that's two channels for coarse and two for fine control, so four right there. Then color wheels, CMY color mixing, color temperature correction, gobo wheels, rotating gobos, prisms, frost filters, iris, zoom, focus, shutter, dimmer, and on and on. And each of those parameters needs at least one channel, often two for sixteen-bit resolution.
Sixteen-bit meaning two bytes per parameter, giving you sixty-five thousand five hundred thirty-six possible values instead of two hundred fifty-six.
Right, and that matters a lot for smooth movement. If you've only got two hundred fifty-six steps for pan across a forty-five degree range, you'll see the fixture stepping through positions. With sixteen-bit, the movement is essentially continuous — the human eye can't perceive the steps.
A rig with fifty moving heads might be consuming two thousand or more DMX channels. That's four full universes just for the movers.
And that's before you get into LED tape, pixel-mapped surfaces, media servers, and all the other elements of a modern production. A large-scale show might run forty or fifty universes. That's twenty thousand plus channels of control data, all updating at forty-four frames per second.
Which brings us back to the network layer. sACN is handling all of that over Ethernet. But what's actually receiving the data at the fixture end?
That's where nodes and gateways come in. Companies like ETC, Pathway Connectivity, and Luminex make DMX gateways — small boxes that sit on the network, receive sACN data, and output standard DMX over XLR to the fixtures. A typical gateway might have four or eight DMX outputs, each carrying one universe. You distribute these gateways around the venue — up in the catwalks, backstage, in the grid — close to where the fixtures actually are.
The signal path is: console generates the data, sends it over Ethernet via sACN, hits a network switch, goes out to distributed gateways, and those gateways convert back to DMX for the final few feet to the fixture.
That's the standard topology. And increasingly, fixtures are skipping the DMX conversion entirely. Many high-end moving lights now have Ethernet ports built in — they speak sACN or Art-Net directly. Art-Net, by the way, is an earlier protocol developed by Artistic Licence in the UK. It's still widely used, especially in live events and broadcast, though sACN is the ANSI standard and generally preferred for new installations.
What's the practical difference between sACN and Art-Net?
Art-Net was the pioneer — it came out in the late nineties and proved you could do DMX over IP. But it has some limitations. Art-Net uses a polling model where the console continuously sends data to specific nodes, and it has a maximum of thirty-two thousand seven hundred sixty-eight universes, which sounds like a lot but some productions are brushing up against that. sACN uses multicast — the console just broadcasts the data, and any device on the network that wants it can subscribe. It's more efficient at scale, and the universe limit is over sixty-three thousand.
Multicast means the network switch handles the distribution, only sending data to ports where a device has expressed interest.
IGMP snooping on the switch makes sure that a gateway only receives the universes it actually needs. If you've got forty universes flying around but gateway number seven only needs universes twelve through fifteen, the switch handles that filtering in hardware.
Let's shift to the console software itself. You mentioned Eos for theater. What's actually happening when a designer builds a cue?
The Eos software — and this is true of most modern lighting consoles — uses a tracking model. This is one of those concepts that separates theatrical consoles from live event consoles. In a tracking cue stack, if you set a channel to fifty percent in cue one and don't touch it in cue two, it stays at fifty percent through cue two. It "tracks" through until you give it a new instruction.
As opposed to a preset model where every cue stores the complete state of every channel.
Preset-based consoles — and this is more common in the live event world, like on grandMA — store absolute values for every parameter in every cue. That's useful for busking, which is the term for improvised lighting control during a concert, where you're jumping between different looks and need each one to be a complete snapshot.
That's the thing where the lighting operator is essentially performing the lights in real time, responding to the music.
Yes, and it's a completely different skillset from running a theatrical cue stack. A busking operator has a layout of faders and buttons, each assigned to different looks, chases, effects, and they're building the show on the fly. The grandMA platform is built around this workflow — lots of physical faders, executable buttons, and a powerful effects engine.
The grandMA3 is the current generation?
The grandMA3 was released in twenty nineteen, and it's now the standard for large-scale live events. The full-size grandMA3 has something like one hundred twenty physical playbacks, multiple touchscreens, and enough processing power to handle absurdly complex shows. But it had a rocky launch — the software wasn't fully featured at release, and a lot of designers stuck with grandMA2 for years. MA Lighting maintained grandMA2 software alongside grandMA3 through the transition.
That's a common story with professional tools. The old version is battle-tested and the new one isn't ready.
In live production, you can't afford a crash. If the lighting console goes down during a show, tens of thousands of people are sitting in the dark. Redundancy is a huge part of the tech stack that most people don't see. On a major production, you'll typically have a primary console and a backup console running in parallel, both receiving the same network data, both tracking the same cue stack. If the primary fails, the operator can switch to the backup in less than a second.
How does the backup stay in sync?
The consoles are networked together. On the Eos platform, this is called a multi-console system, and it uses a client-server architecture. The primary console is the server, and the backup is a client that mirrors everything. If the server goes down, the client promotes itself to server. The transition is fast enough that the audience might see a brief flicker, but the show continues.
There's usually a separate network for this sync traffic versus the lighting data?
Best practice is to have a dedicated sync network. You don't want cue sync data competing with forty universes of sACN traffic. On a properly designed show network, you'll have multiple VLANs — virtual LANs — separating management traffic, lighting data, and console sync.
This is starting to sound like IT infrastructure.
That's because it is. Modern lighting is an IT discipline. The days of running a single DMX cable from the console to a dimmer rack are long gone. A Broadway show's lighting network might have dozens of managed switches, hundreds of nodes, and miles of fiber optic cable. The network design is as important as the lighting design.
There's a whole other layer we haven't touched — the dimming and power distribution side.
So for conventional fixtures — tungsten lamps, basically — you need dimmers. The dimmer rack takes the DMX signal and regulates the AC power to the fixture. The industry standard for decades has been the ETC Sensor rack, which uses SCR dimming — silicon-controlled rectifiers — to chop the AC waveform and reduce the effective voltage to the lamp.
Chopping the waveform meaning you're turning the power on and off very rapidly to control brightness.
At one hundred twenty times per second. The dimmer switches on at a specific point in the AC sine wave — the later it switches on, the less power gets through, the dimmer the lamp. This is called forward-phase dimming, and it works beautifully with resistive loads like tungsten filaments.
It doesn't work with LEDs.
It absolutely does not. LEDs need constant current, not chopped AC. So the rise of LED fixtures has fundamentally changed the power distribution side. Instead of dimmer racks, you now have relay racks and constant-power distribution. The dimming happens inside the fixture itself, controlled via DMX.
Which means the "dimmer room" backstage is increasingly a server room.
The energy savings are enormous. A conventional Broadway rig might pull hundreds of kilowatts. An all-LED equivalent can do the same thing with a fraction of that. But it's also created new challenges — LED fixtures have cooling fans, which add noise, and their color rendering isn't always as good as tungsten, though it's gotten dramatically better.
Let's talk about color for a minute. With conventional fixtures, you had a limited palette — you put a gel in front of the light, and that was your color. With LEDs, you've got additive color mixing from red, green, blue, and often amber or white emitters.
Some fixtures add lime green emitters to fill in the spectrum. The challenge with RGB alone is that you get gaps in the spectrum — certain colors look washed out or unnatural, especially on skin tones. Adding amber and lime helps fill those gaps and gives you a much fuller, more natural color rendering.
This is all controlled through the console. The designer isn't thinking in terms of red at fifty percent, green at thirty percent — they're thinking in terms of a specific gel color or a specific color temperature.
Right, and this is where modern console software shines. On an Eos console, you can select a fixture and type in a gel number — like R eighty, which is primary blue — and the console knows the spectral characteristics of that gel and translates it to the appropriate LED mix. Or you can specify a color temperature in Kelvin, or an exact hue and saturation. The console handles the math.
Different LED fixtures from different manufacturers will render the same color slightly differently.
Which is why calibration is a whole sub-discipline. When you're hanging a show with fixtures from multiple manufacturers, you need to create calibration profiles so that "warm amber" looks the same on the Martin fixtures as it does on the ETC fixtures. This is usually done during focus and tech rehearsals, and it's painstaking work.
What about the visualizer side? I know designers often pre-program shows before they ever step into the theater.
That's become standard practice. Software like Capture, Vectorworks Vision, or LightConverse lets you build a 3D model of the set and the lighting rig, complete with accurate photometric data for every fixture. The designer can program cues in the visualizer, see exactly how the light will look, and then export that show file to the console. When they get into the theater, they load the file, and the core programming is already done.
The designer might spend weeks programming at home, then arrive at the theater and just need to adjust focus positions and tweak levels.
In practice, there's always more tweaking than anyone expects. Real-world physics doesn't perfectly match the visualizer — haze behaves differently, surfaces reflect differently, and the human eye perceives contrast differently than a computer screen. But it gets you eighty percent of the way there, which saves enormous amounts of expensive theater time.
What's the data format for exchanging show files between visualizers and consoles?
There's no universal standard, unfortunately. Each console platform has its own show file format. But there are interchange formats. The most widely used is probably the ASCII show file export from Eos — it's a text-based format that other software can parse. There's also GDTF, the General Device Type Format, which is an open standard for describing fixture characteristics. It was developed by MA Lighting and Robe and is now managed by ESTA. The idea is that a fixture manufacturer provides a GDTF file, and any console or visualizer can read it and know exactly what that fixture can do — the DMX channel map, the physical dimensions, the photometric data, the gobo images, the color mixing characteristics. It's a comprehensive digital twin of the fixture.
Let's circle back to the physical booth for a moment. Daniel mentioned seeing sliders and panels. Beyond the main console, what other control surfaces might live in that booth?
It depends on the production, but you'll often see a lighting network gateway or two, maybe a rack-mounted unit. There might be a remote video monitor showing the stage from the lighting perspective. You might see a dedicated followspot control system — some venues use remote-controlled followspots where the operator has a small control panel that feeds into the main lighting network.
The audio console is usually in the same booth or nearby?
In traditional theater architecture, the lighting booth is often at the back of the house, and the sound booth might be there too, or it might be in a separate location. The trend in newer venues is to combine them into a single control room. But from a technical standpoint, lighting and audio are completely separate systems. They don't share a network or a protocol layer. The only thing they share is timecode.
Timecode — that's how you synchronize lighting cues with music or video.
Linear timecode is an audio signal that carries a time reference — hours, minutes, seconds, frames. You can feed timecode into a lighting console, and it will auto-follow cues based on the timecode position. This is essential for musical theater, where certain lighting cues need to hit on specific beats, or for broadcast where lighting needs to be frame-accurate with video.
The timecode typically originates from the audio department or from a playback system?
Usually from a show control system or a playback rig. In a musical, the click track for the band often carries timecode. The conductor hears the click, the band plays to it, and the lighting console follows the timecode. It's a beautiful bit of integration when it works.
When it doesn't work, you've got lights going to black in the middle of a love song.
Which is why every professional show has a manual backup plan. The board operator can always take control and fire cues manually if timecode fails. You never rely entirely on automation.
Let's talk about the dimmer room — or the electrical room, whatever we're calling it now. What's actually in there in a modern venue?
If it's a venue built or renovated in the last decade, you're looking at a lot of circuit breaker panels and relay racks, not dimmer racks. Each lighting position — each electric, each boom, each catwalk position — has circuits that run back to the electrical room. Those circuits are connected to relays that can be switched on and off via the lighting network. The fixtures themselves are powered constantly when the relay is on, and they do their own dimming internally.
Those relays are controlled via DMX or sACN?
SACN typically, or they're on a separate control network. Companies like ETC make relay panels that speak sACN natively. The console or the architectural control system sends a command, and the relay switches. It's the same principle as the old dimmer racks, but instead of varying the voltage, you're just switching power on and off.
What about the architectural control side? The house lights, the work lights, the lobby lights — that's usually a separate system from the performance lighting.
You don't want the stage manager accidentally turning on the house lights during a performance because they bumped the wrong fader. Architectural systems — ETC's Paradigm is the dominant one in the US — handle all the non-performance lighting. They're programmed with preset scenes: "house open," "house at half," "house out," "work lights on," "cleaning lights." These are triggered from wall stations backstage or from a touchscreen at the stage manager's panel.
The architectural system is networked with the performance system?
They can be, but with strict priority rules. The performance console always has the ability to override the architectural system for show-related needs. But the architectural system has priority for life safety — if the fire alarm goes off, the architectural system brings up full house lights regardless of what the console is doing.
That's an important failsafe. What about the actual cabling infrastructure? You mentioned fiber. Is that common in theater installations?
Very common now. The backbone between the booth, the dimmer room, and the stage is often fiber optic, with Ethernet switches at each end. Fiber gives you huge bandwidth, electrical isolation — no ground loops — and it's immune to the electromagnetic interference you get from dimmer racks and high-power audio systems. For the final connection to fixtures, you're still usually running copper — either DMX cable or Ethernet, depending on the fixture.
Power and data are increasingly combined. I've seen fixtures that take Power over Ethernet.
PoE is huge for architectural fixtures and smaller LED units. A PoE port can deliver up to ninety watts with the latest standard, which is enough for a surprising number of fixtures. For larger theatrical fixtures, you're still running separate power and data — a moving head might draw a kilowatt or more, which is way beyond what PoE can handle.
The cable bundle going to a lighting position might include power cables, DMX, Ethernet, and maybe some analog control lines for older equipment.
The physical layer matters a lot. In a touring production, all of this has to be set up and struck in a matter of hours. Touring rigs use multi-cable — snakes that combine power and data in a single rugged cable — and everything is labeled and color-coded for speed. The touring world has its own set of standards and conventions.
Which brings us to the difference between installed theater systems and touring systems. The tech stack is the same at the protocol level, but the physical implementation is completely different.
An installed theater can have custom-built cable runs, permanently mounted fixtures, and a carefully tuned network. A touring show has to be modular, road-worthy, and fast to deploy. Touring consoles are often in flight cases with built-in UPS power backups. The network switches are ruggedized. Everything is redundant because you can't afford a failure in a strange city where you don't have spare parts.
The console itself might be the same model — an MA3 or an Eos Apex — but it's configured differently for touring.
A touring show file is built to be flexible. The designer might program the show in a rehearsal space, then adapt it to each venue on the tour. The cue timings stay the same, but focus positions get updated, color balances get tweaked for different throw distances, and the patch — which maps console channels to physical dimmers and fixtures — gets rebuilt for each venue's specific rig.
The patch is something we haven't really explained. When a designer says "channel one at full," that channel number is an abstraction.
It's a crucial abstraction. The console maintains a patch table that maps channel numbers — the designer's logical references — to DMX addresses, which are the physical addresses on the network. Channel one might control a front light that's plugged into DMX universe one, address one. Channel two might be a moving head that occupies addresses two through forty-eight on universe one, and also addresses one through ten on universe two for its additional parameters.
The designer thinks in channels — "I want my front warm wash up ten points" — and the console handles the translation to dozens of DMX addresses across multiple universes.
That patch can change from venue to venue without the designer having to reprogram anything. The show file stays the same. Only the patch changes.
That's elegant. What about the people who maintain all this? The technical director Daniel mentioned — what's their actual relationship to the tech stack?
The technical director is usually responsible for the overall production management — budgets, schedules, safety, crew. The lighting supervisor or master electrician handles the day-to-day implementation of the lighting system. On a Broadway show, the master electrician oversees the hang, the circuiting, the patching, and the maintenance. The board operator runs the console during performances. The designer is the artist who creates the look.
The designer might not know the first thing about sACN or multicast routing.
Some do, some don't. The best designers understand the technology well enough to know what's possible, but they don't need to be network engineers. That's what the production electrician and the lighting programmer are for. The programmer is the person who actually sits at the console during tech rehearsals and translates the designer's instructions into the console's language. "Give me more warmth on the downstage left special" becomes a series of keystrokes and fader moves.
That's a fascinating role — the programmer as translator between artistic intent and technical execution.
It's a highly skilled position. A good lighting programmer can work faster than the designer can talk, building cues and effects in real time while the designer is still describing what they want. They know the console inside and out — every shortcut, every macro, every trick. On a complex musical, the programmer might build thousands of cues over a multi-week tech process.
They're working on one of these consoles we've been discussing. What does the actual user interface look like?
On an Eos Apex, which is the current flagship, you've got a large multi-touch screen in the center, two smaller touchscreens on either side, and a row of motorized faders below. The faders can be configured as submasters, as cue list playbacks, or as individual channel controls. Above the screens, you've got a backlit keyboard with dedicated keys for common functions — go, stop, back, record, update, time, and so on.
Motorized faders meaning the faders physically move when you change pages or cues.
If you switch from page one to page two on the fader bank, the faders physically slide to their new positions. It's deeply satisfying to watch, and it's also functional — you can see at a glance where everything is set without looking at the screen.
The grandMA3 has a similar layout but with more faders and more of a live performance orientation.
The grandMA3 full-size is a beast. It has three banks of motorized faders, dozens of executor buttons, and a massive multi-touch screen area. The executors are the key to busking — each executor can be a single cue, a chase, an effect, or a complete cue list. An operator can build a busking layout with effects on faders, chases on buttons, and specials on flash keys, all arranged for quick access during a show.
Both platforms support remote control via tablets now.
That's been a game-changer for focus and programming. The designer or programmer can walk around the theater with an iPad, connected to the console over Wi-Fi, and adjust lights while standing on stage. ETC has their iRFR app, and MA has their remote app. The latency is low enough that you can do real-time adjustments.
What's the security model for that? You've got a lighting network that's controlling thousands of channels of show-critical data, and now you're connecting wireless devices to it.
This is an area where the industry has been a bit slow to adapt. Historically, lighting networks were isolated — no connection to the outside world, no wireless, just a closed Ethernet network. As remote access has become more common, the security model has had to evolve. Best practice now is to put the wireless access point on a separate VLAN with strict firewall rules, so the tablet can talk to the console but can't reach anything else on the network.
The console itself isn't exposed to the internet.
There's no reason for a lighting console to be on the internet during a show. The security risk is too high. Imagine someone taking control of the lighting during a live broadcast. It's a real concern, and the industry takes it seriously, even if the general public doesn't think about it.
We've covered a lot of ground. Let me try to summarize the tech stack from top to bottom, and you tell me if I've got it right.
Go for it.
At the top, you've got the lighting console — an Eos or a grandMA or similar — running specialized software that manages a cue stack or a busking layout. The console talks to the network using sACN or Art-Net, which packages DMX data into IP packets. That data travels over standard Ethernet infrastructure — switches, fiber, copper — to distributed gateways and nodes around the venue. Those nodes convert the network data back to DMX for fixtures that need it, or the fixtures receive sACN directly over Ethernet. The fixtures themselves — conventional, LED, moving heads — respond to the DMX data, adjusting intensity, color, position, and effects. Behind all of this is a patch table that maps logical channels to physical addresses, a sync network for redundancy, and often a timecode feed for synchronization with audio and video.
You've got it. The only thing I'd add is the architectural control layer — the house light system and the emergency overrides — which operates alongside the performance system but with its own priorities and its own control surfaces.
The whole thing is designed around one central principle: the show must go on. Redundancy at every level, manual overrides for every automated system, and a human operator who can take control when the technology fails.
That's the heart of it. All the protocols and consoles and networks are in service of a single goal — making sure that when the actor steps on stage and delivers their line, the light is exactly where it needs to be, exactly when it needs to be there. Everything else is just engineering.
That engineering is surprisingly deep. I think most people look at a lighting booth and see sliders and buttons, and they assume it's like a fancy dimmer switch. They don't see the IP networking, the multicast routing, the redundant sync systems, the timecode integration, the visualizer pre-programming, the calibration profiles.
That's what makes Daniel's question so good. The visible surface of the tech is maybe ten percent of what's actually happening. The rest is invisible infrastructure that's been evolving for decades.
It's still evolving. What's the next thing? Where is this going?
A few trends. One is the continued move toward fully network-native fixtures — no DMX conversion at all, just Ethernet straight to the fixture. Another is the integration of lighting with video and projection mapping, where the lighting console and the media server are sharing data and working from the same 3D model of the stage. We're also seeing more AI-assisted programming — consoles that can suggest looks or automatically adjust to changing conditions.
The physical console itself might eventually disappear, replaced by software running on generic hardware with specialized control surfaces.
That's already happening at the lower end. ETC's Nomad software runs on a laptop and gives you the full Eos experience with just a USB dongle for DMX output. But for high-end professional use, I think the dedicated console with physical controls is going to stick around for a long time. There's something about having a real go button under your finger when the moment counts.
Tactile feedback matters when you're executing a blackout on a musical beat with two thousand people watching.
Touchscreens are great for programming, but for performance, you want physical buttons and faders. Your muscle memory knows where everything is. You don't have to look.
I think we've done justice to Daniel's question. The tech stack is deeper than it looks from the booth.
And now I want to go program some cues.
And now: Hilbert's daily fun fact.
Hilbert: The Pompeii worm, which lives in hydrothermal vent ecosystems, holds the record for the most heat-tolerant complex organism on Earth — it survives temperatures up to one hundred seventy-six degrees Fahrenheit with its tail sitting in near-boiling water while its head rests in much cooler seawater, a thermal gradient of over one hundred degrees across just a few inches of its body. Scientists first started studying deep-sea hydrothermal vents in the eighteen eighties, though the vents themselves weren't discovered until the nineteen seventies, when researchers aboard the submersible Alvin found them off the Galapagos — but the Kamchatka Peninsula's Kuril-Kamchatka Trench has since yielded some of the deepest vent communities ever documented.
A worm with its own built-in temperature gradient.
One question to leave listeners with: if lighting control has evolved this far from simple dimmers to full IP networks, what other backstage technologies are due for a similar revolution? Sound has already gone digital. What about rigging, automation, pyrotechnics? There's a lot of stagecraft that's still running on analog systems and human muscle.
That's a whole other episode. Thanks to our producer Hilbert Flumingtop. This has been My Weird Prompts. Find us at myweirdprompts.
Catch you next time.
