The Handoff Solution: Building a Permanent Architectural Framework on TouchDesigner

Digital Ambiance has spent over a decade building permanent architectural lighting: installations that run continuously for years, operated day to day by facility teams who have never opened a node-based tool. Out of that work came Lightpath, a web-based platform that wraps TouchDesigner in everything a permanent install needs to be handed off, operated, scheduled, monitored, and evolved over its whole lifespan. We spoke with Lightpath team members Kyle Meredith and Javier Martinez about the handoff problem that started it, why TouchDesigner is the engine, and what it means to design for permanence at scale.

Derivative: Who is Digital Ambiance, and what is Lightpath?

Lightpath: Digital Ambiance is a design-build studio that transforms spaces into immersive experiences by blending architecture, technology, and storytelling. For over a decade we've designed, built, and operated large-scale permanent lighting environments for hospitality, entertainment, and cultural spaces across North America: casinos, hotel lobbies, cultural institutions, mixed-use developments.

Lightpath is the platform that came out of that work. It's a unified, web-based system for building and managing dynamic architectural lighting installations: content authoring, scheduling, fleet monitoring, alerts, device integrations, and role-based access, all on top of a TouchDesigner engine. It started as internal scaffolding we kept rebuilding on every install, and it has since become a fully-fledged platform. We've now spun it off into a separate company, Digital Ambiance Systems, with Lightpath as the flagship product. Check out the website to learn more.

Derivative: What problem does Lightpath solve? Where did it come from?

Lightpath: Lightpath was created to solve a few core problems that stacked up over years of permanent install work.

The first was duplication. To meet the unique needs of each project, we found ourselves building a separate patch and a separate set of solutions every time. We needed one underlying framework that dynamically loads .tox files and configuration files, a single platform to effectively manage all of our installations in one place.

The second was the handoff. You finish a network that's pixel-mapped and AV-integrated, and then you hand it to a facility team that has never opened TouchDesigner: the marketing director who wants to swap seasonal content, the floor manager who wants to recall a look from a touchscreen, the maintenance team that needs an alert when a fixture fails before a guest sees it. None of that exists by default, so on every install we ended up cobbling it together from separate platforms and tools. There's so much a permanent install needs beyond the TouchDesigner patch itself: scheduling, monitoring, content management, remote access, alerts. Lightpath exists to pull all of it into one place.

Derivative: Why did you build on TouchDesigner?

Lightpath: Flexibility is the key. Any geometry, any hardware, any sensor, any data source. We came to TouchDesigner because we needed complex 3D pixel mapping and interactivity, and most other tools are built for the stage or locked into specific restrictions. They’re just not as flexible. Everything we build is bespoke and permanent, so an engine that only handles standard fare was never going to work for us. 

TouchDesigner handles whatever we throw at it, and it's never gotten in our way.

It's also open in a way that lets us build a complete software platform on top of it instead of fighting a closed system. And the community is a huge part of it. TouchDesigner is the shared language of so many of the world's best creative developers, so building on it means anyone in that community can pick up Lightpath and work inside it.

Derivative: Which TouchDesigner features proved most valuable while building Lightpath — and what would make building platforms like this easier?

Lightpath:

• Python. The fact that the entire app is scriptable through Python is foundational for building a configurable application like this.

• Extensions. We use them heavily. They keep the code organized and let us encapsulate real logic in proper classes instead of scattered callbacks.

• WebSockets. All of the communications between the web app and TouchDesigner flow through the Socket IO DAT. We built an RPC layer that calls TouchDesigner Python functions directly from JavaScript (TypeScript), which is a big part of how the web app and TouchDesigner stay in sync.

• The plugin / .tox model. Self-contained, reusable building blocks let us easily change behavior for each project.

• Real-time content. TouchDesigner's unlimited real-time content engine makes it easy to build out generative content for any install. One of the most fun features of Lightpath is authoring new content directly from the browser with real-time pre-vis.

The main feature that would make development easier is a text / file-based project format. Since .toe and .tox files are binary, version control and collaboration are challenging, and changes to expressions and node structure are totally opaque. We know a file-based format is in the works, and we're excited for it. In the meantime the community has bridged the gap for us — Embody by Dylan Roscover and TDN have both helped a lot — but first-class, human-readable versioning would be massive.

Derivative: How is a Lightpath install different from a conventional TouchDesigner install?

Lightpath: Most TD-powered installs involve a complicated patch unique to that installation and a bolted-on UI that is coded from scratch. Lightpath streamlines the process by providing a unified system. Every install runs from the same Lightpath application and TouchDesigner file, with dynamic configuration loading whatever a given install needs. The integrator builds only the parts unique to their install, patterns, outputs, sensor logic, and inherits everything else.

Instead of a bespoke one-off with a hand-built control panel, you get an install that inherits the entire operational layer out of the box.

Derivative: For a developer, what does building a Lightpath install actually look like inside TouchDesigner?

Lightpath: Lightpath is opinionated by design. Anyone who's inherited someone else's TouchDesigner project knows how messy .toe files can get. Different developers, different conventions, and the result can be hard to parse and hard to make portable. Lightpath provides a shared structure that contains the complexity and makes a permanent install maintainable years later, while preserving all of TouchDesigner's freedom inside your own components.

You author your install as a small set of .tox files that follow a simple contract, and Lightpath handles the rest, loading them, routing content through them, and exposing their parameters to the web UI.

There are two kinds of component:

• Outputs are the destinations. Each one takes the final composed texture and pushes it to a physical endpoint: a pixel-mapped LED sculpture, a projection surface, a video wall over NDI. You make one output per destination in the install.

• Plugins are everything that feeds those outputs. They come in three flavors:

  • Sources generate textures: patterns, media playback, audio-reactive or shader visuals.

  • Effects transform textures: blurs, color shifts, masks, distortions.

  • System plugins don't render anything at all, they pull in shared data or send control signals, like sensors, cameras, or external APIs.

The other half of the contract is parameters. Any custom parameter you drop on a page named Look, Config, or Status gets surfaced to Lightpath automatically: Look params are per-look, so operators tune them in the look editor; Config params are set once at the project level; and Status params are read-only values that stream back into Lightpath's Devices view and can trigger alerts.

Derivative: How do users create content in Lightpath?

Lightpath: The core unit of content is a look: a source, a palette, and an optional stack of effects. We ship a library of sources and effects to build from, and you can write your own custom sources and effects to extend it however you want.

You compose looks in a dedicated look editor in the web UI, with real-time pre-vis streaming straight from TouchDesigner, so you see exactly what the install will show as you tune it. It makes authoring content approachable for people who'll never open TouchDesigner.

Derivative: You describe Lightpath's use case as "permanence at scale." What does that mean, and what does it take to operate an install that way?

Lightpath: Permanence at scale is the quiet, parallel world of TouchDesigner: permanent, built-environment installations that run continuously for years, managed remotely by facility teams who may never have touched a node-based tool. Our installs come on in the morning, move through curated schedules all day, and get reprogrammed seasonally by marketing teams through a browser.

A permanent install has very different considerations than a temporary one or a live performance. A show runs for a night with an operator standing right there; ours run for years with nobody technical on site. That reframes everything around a few questions: how do you keep the processes running and the uptime rock-solid? How do you get real insight into the health and performance of all the hardware on site? And how do you make the installation usable by the on-site team? Lightpath wraps TouchDesigner with some core features to address these:

• A web UI reachable from anywhere — with a per-install URL, the whole install runs from a browser, on site or across the country.

• Cloud project management — sync across machines, versioning and reverting, multi-user collaboration, and a fleet view across every install.

• Scheduling and role-based access — schedule content by date, time, recurrence, and astronomical time (sunset/sunrise), and give every role from viewer to admin a surface built for its flow, down to a CEO who wants one button or a locked-down mobile screen for on-site staff.

• Process and uptime management — Lightpath supervises the TouchDesigner process itself, recovering it automatically after a crash or power blip, and distributes it across multiple render nodes when an install needs it.

• Live monitoring and alerts — status streams back from every output and device, so you see the health of the whole system at a glance, and alerts fire the moment something goes dark, by email or messaging app, before anyone on site notices.

• Device management — Lightpath is the hub for all the on-site gear, speaking OSC, HTTP, and the rest of the permanent-install world: Advatek, ISAAC, Pharos, Q-SYS, Lutron, Crestron, and more.

  

  

Derivative: Walk us through building and running a real Lightpath install.

Lightpath: Permanent installs have a long design cycle, and Lightpath is built to be part of it the whole way. Our recent flagship, the Lagunitas Experience in Northern California, is a good example: a permanent outdoor installation combining projection, architectural lighting, and 3D multi-channel sound, all real-time interactive through LiDAR and all running on Lightpath.

It starts with scoping. Lightpath is a bit of a buffet — you can use one feature, many, or all of them alongside the rest of your stack, so the first question is what role it plays. Does it render content, or just handle orchestration and UI for other engines? Is it the top-level system, or a subsystem of something like ISAAC? On Lagunitas we used Lightpath for pixel mapping, orchestration, and UI; Unreal for rendering; Modulo Pi for projection mapping; and Spatial for 3D audio.

Then comes the build: the hardware, the sensors, and how to read it all into TouchDesigner. You spin up a project and build your output components, iterating as you dial in the mapping, and when an install needs interactivity you add a system plugin for the sensor data plus custom sources and effects that turn it into generative content. At Lagunitas that meant custom C++ to bring in Ouster LiDAR data, a system plugin to feed it into Lightpath, and custom sources generating content from the live data in real time.

With that framework in place, you orchestrate everything on top: content and palettes, the schedule, devices, end-client interfaces, users and access, alerts and automations, then test and harden on site. That's what it takes to hand off a polished, permanent install, and from then on that same platform is what the on-site team uses to run it for years. Check out the full making of film to learn more about the Lagunitas Experience project.

Derivative: What have you learned building Lightpath that you'd pass on to others using TouchDesigner this way?

Lightpath: The biggest lesson was that designing for the non-technical end user from day one changes how you build everything. Once you accept that the person operating the install will never open TouchDesigner, you start making very different decisions about parameters, components, and how much you expose, and that discipline made us better builders on the engine side, too.

A few practical tips:

• Externalize as much as you can, extensions and DATs especially, and lean on configuration files to build a generalizable system. JSON is great for this.

• A good externalization management tool is essential. We recommend Embody by Dylan Roscover (the MCP is cool too), or Matthew Ragan's save-external helper for something more light-weight.

• Be as granular as you can with your .tox structure. The more granular and encapsulated your components, the easier it is to collaborate without merge conflicts.

• Building a web UI with a TouchDesigner backend is a really good way to go. Socket.IO makes a very solid communication layer, and you get the best of both worlds: a UI that's easy to iterate on and polish, backed by a powerful, flexible engine.

  

   

Derivative: What's next for Lightpath?

Lightpath: One feature we're especially excited about is AI Studio — an AI content engine we're building that makes it easy to generate dynamic content from prompts inside Lightpath, both in real time and as high-quality offline video. The idea is that whoever's running an install can create new looks on demand, without specialized tools or training.

But more than any single feature, we're excited to get Lightpath into the hands of more TouchDesigner developers. Until recently it has mostly been an internal tool, and it's been great to start collaborating with other design studios and see it used beyond our own installs. That's really what's next for us, getting it in front of more people building permanent installs.

If you've ever handed off a TouchDesigner network and found yourself rebuilding the same client UI, scheduling, and monitoring from scratch, that's exactly the problem we built Lightpath to solve. It's how we make permanent architectural installations last, and stay simple to operate, long after opening day. Come explore the platform at lightpath.online.
 

Learn More About Digital Ambiance + Lightpath Website | Lightpath | LinkedIn | Instagram