By: Tom Turkington, Vice President of Technology, Pliant Technologies
For decades, “where is your intercom system?” was a question you could answer by pointing. It was the rack. The frame. The chassis with the card slots and the fans, with cable running to every panel in the building. That box was the intercom. Everything else was attached to it. A frameless matrix IP intercom changes the answer to that question.
The matrix is no longer a box in a rack. The intelligence lives in the panels themselves, distributed across a standard IP network. That single architectural change reshapes what a system costs, how it’s deployed, how it scales, how it fails, and where it can reach.
First, a Quick Definition
A matrix is any-to-any routing.
Every user and every interface is an individually addressable endpoint. Any endpoint can connect to any other, or to any combination, and connections change instantly in software.
Talk and listen are independent. You can listen to a source without talking to it, talk to a destination without listening to it, or do both. That’s what makes private calls, overlapping groups, IFB, and per-user mix-minus possible. Matrix has been the professional standard in broadcast, stadiums, and command centers for decades.
Here’s the important part: matrix describes a behavior, not a box.
Traditional systems delivered that behavior with a specific piece of hardware, so the two ideas fused in the industry’s vocabulary. We started calling the frame “the matrix,” as though the routing lived in the sheet metal. Frameless matrix architecture separates them again.
How a Frame Matrix Works
A conventional matrix is built around a central chassis: a backplane, one or more control processors, power supplies, and slots for interface cards.
Every panel, every beltpack, every interface, every four-wire circuit, and every program feed terminates on a card in that frame. Physically, the system is a star. Every endpoint home-runs back to one central room. It works. Systems built this way have run world-class productions for decades. But the frame imposes costs that have nothing to do with capability.
What the Frame Actually Costs You
Capital cost is front-loaded and lumpy. You buy a chassis, control processors, interface cards, and power supplies before a single user can say a word. That first user is extraordinarily expensive. The hundredth is somewhat less so.
You size the system at purchase. Frames have finite slots and finite port counts. Buy too small and expansion becomes an expensive event, potentially a second frame plus trunking hardware. Buy too large and you paid for capacity you may never use.
Growth is stepwise, not smooth. Adding two users might only cost the panel hardware. Adding twenty might trigger a card or a frame purchase.
Infrastructure is heavy. Rack space, conditioned power, cooling, and a cable plant that home-runs from every panel location back to the frame room. In a retrofit, that cabling is frequently the largest line item in the entire project.
Geography is a hard constraint. Everything terminates in one room. Remote buildings, satellite control rooms, and off-site personnel require trunk links, gateway devices, or additional frames.
And the failure domain is concentrated. This is the technically significant one. If the frame’s control processor fails, or its power fails, every user loses communication at the same moment. Redundant processors, redundant supplies, and in critical installs a fully redundant second frame all help. Each one adds cost. None changes the fact that the system’s intelligence sits in one physical location.
The primary limitation of traditional matrix was never capability.
It was always the frame.
Frameless: The Endpoints Become the Matrix
A frameless matrix keeps everything the matrix control model does and removes the central chassis.
The routing intelligence moves into the endpoints. Every main panel, desktop panel, and expansion panel is its own intelligent matrix. Routing and mixing happen in the endpoints. Each one sources its audio to the network and receives the streams it needs. Devices share a synchronized view of the system. There is no central crosspoint switch in the audio path.
For anyone fluent in networking, the analogy is immediate. It’s the same transition networking itself made when it moved away from centralized chassis switching with everything home-run to a core, toward distributed designs on standard infrastructure.
The capability didn’t shrink. The dependency on one box did.
What Changes When the Frame Goes Away
The cost curve straightens. No chassis, no control processor, no cards, no central power supplies to buy before the first user exists. Four users cost roughly four users’ worth of money. A hundred users cost roughly a hundred users’ worth. Matrix intercom stops being a threshold purchase and becomes a per-seat purchase.
Scaling becomes incremental. No card capacity to run out of, no frame to outgrow, no forced re-architecture at an arbitrary port count. Adding a panel still means buying and installing a panel. What it no longer means is checking whether the frame has room for it.
The failure domain shrinks to the endpoint. One device fails, that device fails. Nothing else does.
Worth being precise: removing the frame doesn’t remove every shared dependency. It relocates the biggest one from a proprietary chassis to the IP network. That’s a favorable trade, and the reasons are worth a section of their own below.
Geography stops mattering. If an endpoint can reach the network, it’s part of the system. A control room across campus, a production office in another city, an engineer at a second facility.
Infrastructure becomes commodity. Standard managed switches, standard structured cabling, standard fiber, PoE. No frame to rack, no frame room to cool, and no home-run cable plant to pull.
Integration comes along for free. With AES67 and SMPTE ST 2110-30 as the transport, the intercom exchanges audio with consoles, routers, and transmission chains using the same mechanisms as everything else in the facility.
What Frameless Is Not
Frameless does not mean software-only.
This is the most common misreading, and it gets the architecture backwards. Frameless describes where the routing intelligence lives, not whether hardware exists. The core of the system is hardware: rack-mount key panels, desktop panels, wired beltpacks, and interfaces. Real keys, real displays, real headset connections, operated by people who need to feel a button during a show. What’s gone is the central chassis those devices used to depend on. Not the devices.
Virtual users, browser access, and cloud deployment are a real strength of the architecture, and they fold into the same ecosystem seamlessly. But they’re an option layered onto a hardware system, not the system itself. They join the system. They don’t define it.
Why Virtual Users Matter More Than They Used To
Saying virtual isn’t the core of the system is not the same as saying it’s a minor feature. For a great many productions, it’s the part of the architecture that changes what’s operationally possible.
Here’s why the frameless model makes it work so well.
In a frame system, a remote participant is an exception. Getting a producer at home or a commentator in another city onto the intercom means a gateway device, a dedicated circuit, or a codec pair, and that participant usually ends up with reduced capability compared to someone sitting at a panel in the building.
In a frameless system, a virtual user is just another endpoint.
Same matrix. Same addressing. Same independent talk and listen. Same access to party-lines, conferences, IFBs, and point-to-point calls. The difference is the device it runs on, not the capability it gets.
That distinction shows up in real workflows.
Crews change size constantly. A production that needs eight positions this week and forty next week can add virtual users for the difference without buying, shipping, or racking anything. Freelancers, guest contributors, temporary crew, and executives who need to listen in can be provisioned in minutes and removed just as fast.
People aren’t in the building anymore. Remote production is no longer a special project, and a virtual user in a distant control room, a home office, or a hotel is a first-class participant rather than a compromise.
Not everyone can install software. Browser-based access matters more than it sounds like it should. Temporary personnel, contractors, and anyone working on a device they don’t administer can open a browser, authenticate, and join the production without an install, a helpdesk ticket, or an IT exception.
Some positions can be virtualized entirely. A commentator working from another city can use a purpose-built virtual commentator position with separate on-air and intercom paths, program and IFB monitoring, and automatic on-air muting, instead of shipping a specialized hardware station across the country.
Tactile control is still available. Third-party control surface integration gives a virtual user physical buttons when speed and feel matter, which closes much of the gap between a software client and a dedicated panel.
The result is a system where the deployment model follows the production rather than constraining it. Some facilities will be almost entirely hardware, with a handful of virtual users for remote staff. Others will run primarily virtual with a few hardware positions where they matter most. Both are the same platform, the same matrix, and the same configuration environment.
That flexibility exists because of the architecture. Once routing intelligence is distributed and the transport is standards-based IP, adding a software endpoint is a natural extension of the design rather than a bolt-on.
The Honest Caveat
Frameless moves redundancy engineering effort from the frame to the network. For most facilities that’s a good trade, because the network is already there and already managed. But it isn’t free, and anyone promising “it just runs on your existing network” is setting up a hard day at commissioning.
A professional deployment needs real network discipline: managed switches with non-blocking capacity, QoS so time-sensitive audio and clock traffic is prioritized, properly configured PTP (IEEE 1588), IGMP snooping and querier, VLAN segmentation, and deliberate hardware redundancy where the show depends on it.
The meaningful difference is that network redundancy is a solved, standardized, comparatively inexpensive problem. Redundant paths, redundant switches, and SMPTE ST 2022-7 stream redundancy are ordinary practice, built with commodity equipment instead of a second proprietary frame.
You’re trading a proprietary single point of failure for a standards-based dependency you already know how to make redundant. The good news is that none of this is specialized intercom knowledge anymore. It’s the same skill set required for Dante and for ST 2110 audio and video.
Most facilities and integrators already have it.
CrewCom Flex in Practice
CrewCom Flex™ is Pliant’s frameless matrix IP intercom platform, and it’s built hardware-first.
The core is a family of AES67 endpoints, each functioning as its own intelligent matrix. Rack-mount main panels with sixteen talk/listen keys, TFT displays, professional headset support, redundant power, and redundant network connectivity. Expansion panels for positions that need a large number of destinations at once. Desktop panels with full master-panel capability and no rack space required. PoE-powered wired beltpacks with full-duplex access to party-lines, conferences, IFBs, and point-to-point calls.
That last one deserves emphasis. These are beltpacks with matrix capability.
A beltpack user isn’t restricted to a channel. They’re an addressable endpoint with private calls and IFB access. That’s a real departure from what “beltpack” has meant for fifty years. Existing CrewCom wireless systems integrate directly, so wireless users become part of the matrix without replacing the wireless investment. The whole environment is built and managed in CrewWare 2.0.
CrewCom Flex Virtual extends that same matrix to PCs, Macs, tablets, and phones, through an HTML5 browser or a native iOS and Android app. Virtual users are available in several key configurations, so a remote observer and a remote producer can each get an interface sized to the job.
Deployment follows the production. On-premises on a dedicated server, integrated with existing infrastructure over AES67 or SMPTE ST 2110-30, distributed across remote locations, or hosted entirely in the cloud. A facility can start with hardware and add virtual users as workflows change, or start virtual and add hardware where tactile operation matters.
It’s one platform, one configuration environment, and one user experience across all of it.
The Short Version
A frameless matrix IP intercom keeps everything that made matrix valuable and stops organizing the system around a central chassis.
Linear cost instead of stepped. A failure domain of one endpoint instead of the whole system. Commodity IP instead of a proprietary home-run cable plant. And no geographic ceiling.
Hardware where the work demands it. Virtual wherever the people happen to be.
The frame is gone. Nothing else is.
