Control EDC loudspeakers from your own software.

EDC loudspeakers are software-defined and network-controlled. This is where that control path is being opened to third parties: a documented protocol, an HTTP API described in OpenAPI, an OSC namespace for show control, SDKs, a device simulator so you can build without hardware, and modules for the tools integrators already use.

Read the draft protocol openapi.yaml llms.txt

What exists today

The hardware already has the capabilities.

RJ45 Ethernet monitoring and control on every cabinet
UDP network control with multicast support (Rapid app release notes)
Optional Dante or AES3 digital input; three inputs per cabinet
Per-transducer, thermal and amplifier fault reporting on the monitored version
Up to four beams per cabinet: aim ±60°, width 2°–120°, level, delay, source
Projects pushed from the Pro and Rapid apps on Push / Apply

Getting started (when the SDK ships)

docker run -p <PORT>:<PORT> ghcr.io/edc-acoustics/simulator --model SQ-90 --count 4
npm install @edc-acoustics/sdk
edc discover
edc preset recall sunday-service

Everything on these pages is a draft specification for review. Endpoint shapes, ports and names are proposals until EDC's engineers confirm the eight facts below. Nothing here should be coded against until it is marked available.

Documentation

Draft

Protocol reference (draft v0.1)

The network control protocol EDC loudspeakers already speak — documented for third parties. Transport, discovery, framing, commands, telemetry, errors and versioning.

Draft

REST & WebSocket API (OpenAPI 3.1 stub)

A proposed HTTP/JSON face for the loudspeakers, served by the cabinet or a small gateway, described in OpenAPI so an assistant can generate a client from it.

Draft

OSC address space (proposal)

The show-control face of EDC loudspeakers — an Open Sound Control namespace modelled on Meyer's and d&b's conventions so QLab, Companion and TouchDesigner users find it familiar.

Draft

AES70 / OCA mapping note

Where EDC sits against the open control standard consultants ask for — and the honest answer that OSC and REST are the developer-adoption path while AES70 is the specification-compliance path.

Draft

Dante & AES67 channel mapping

The single most common integration question, answered once — which models carry the Dante option, how its channels map to the three inputs, clocking, redundancy and AES67 mode.

Draft

SDKs — TypeScript and Python (proposal)

Open-source client libraries so a developer can discover, aim and monitor EDC loudspeakers from ten lines of code, with typed models generated from the OpenAPI file so docs and code cannot drift.

Draft

Device simulator (proposal)

A Docker image that emulates EDC loudspeakers — discovery, the control protocol, REST/WebSocket and OSC faces, telemetry with injectable faults and preset storage — so anyone can build and test without hardware.

Draft

Integrations — Companion, Node-RED, Q-SYS, Crestron, QLab, Home Assistant, MCP

The listings that put EDC in the tools integrators and agents already use. Each is a small open-source module built on the SDK.

Draft

Sample applications

Three small, runnable examples that tell the story — a lighting-and-sound cue-sync demo, a telemetry logger, and a worship scheduler — each with a transcribed video.

Draft

Changelog & versioning policy

Protocol, API and SDK changes with semantic versioning, and the deprecation promise integrators need before they build on EDC.

Draft

Developer kit & loan programme

A 30-day loan of an SC-30 or SL-30 for developers with a public repository plan, and a hosted simulator endpoint for everyone else.

Draft

Licence & trademark

The licence posture for the protocol specification and the code, the API stability promise, and how to refer to EDC compatibility — published before anyone is asked to build.

The plan, in order

Protocol reference v1 — document the existing UDP control, discovery and telemetry
Device simulator — Docker image so nobody needs hardware
SDKs — TypeScript and Python, MIT, on npm and PyPI
Bitfocus Companion module
OSC bridge and published address space
Q-SYS plug-in and Crestron module
REST + WebSocket API behind the published OpenAPI
MCP server for AI agents; Node-RED and Home Assistant
AES70/OCA mapping, then implementation

Eight facts that decide the shape of the API

Have a view on any of them, or want to build an integration? Contact EDC with what you plan to build.

Next step

Build the integration you need.

Tell us what you are building — a Companion module, a Q-SYS design, a show-control app, an agent — and what you need from the protocol to do it.

Talk to engineering → Draft protocol