I wanted to live code in C++. Not a DSL that compiles to C++. Not a scripting language with bindings. Not a state machine that responds to string commands. Actual C++, where if the compiler can compile it, I can eval it at runtime, line by line, scope by scope.
[The Live coding section in the video starts at 16:40, for some reason timestamp url is not working]
This is the story of how I got there, every wrong turn included.
The constraint
The live coding world has settled into a few comfortable patterns. You write a DSL (Tidal, Sonic Pi, Extempore). You embed a scripting language and write a million wrapper bindings. You build a state machine that maps string commands to a fixed set of functions. Or you ship a separate binary that exposes a handful of entry points and call it a day.
All of these work. None of them were what I wanted.
I'm building MayaFlux, a C++20/23 multimedia framework where audio, visual, and any other data stream flow through the same transformation primitives. It's built on Vulkan 1.3, uses coroutines for temporal coordination, and treats domain (audio rate, frame rate, compute rate) as a scheduling annotation rather than an architectural boundary. The whole point is that there are no artificial separations: a node that processes a float sample operates identically to one processing a pixel or a compute result. The only difference is when it runs.
Live coding in this context means writing actual framework code at runtime. Declaring nodes, wiring graphs, scheduling coroutines, defining processing functions. If I drop into a restricted subset or a string-command interface, the entire premise collapses. The performance IS the architecture demo.
So the constraint was: real C++, the full language, evaluated incrementally in a running process. With latency low enough to perform with.
Attempt 1: Hijacking a debugger
The first idea was inspired and slightly unhinged: debuggers already do this. LLDB can evaluate arbitrary expressions in a running process. It can call functions, inspect state, modify variables. If I could repurpose that machinery, maybe I wouldn't have to build anything from scratch.
I started by forking/exec-ing LLDB as a child process and piping code to it. After spending quite a bit of time learning the LLDB API (which is not exactly bedtime reading), I got something working. I could evaluate single lines, call functions, evaluate blocks. It worked in the sense that "it produced correct results."
The latency made it basically unusable for performance. Hundreds of milliseconds per eval. Not "perceptible delay" territory, more like "I could make coffee between pressing enter and hearing the result."
Next attempt: link the LLDB libraries directly to avoid the process boundary overhead. Painstaking API work. The documentation is sparse, the examples sparser. I tried to find existing projects that embed LLDB's evaluation machinery to learn from their approach. Results: almost nothing. I tried the various AI tools to help navigate the obscure parts of the API. That went about as expected: confident generalizations, bad causal reasoning ("this project uses a debugger" confused with "this project integrates a stepping mechanism"), hallucinated function signatures.
After significant effort I got something limping along. Then the realization hit: templates. The debugger evaluation path can only call template instantiations that already exist in the binary. You can't instantiate new templates at eval time. For a framework built on templates (like any modern C++ codebase), this is a dealbreaker. You'd have to pre-instantiate every possible template combination, which is insane for a live coding context where the whole point is that you don't know what you'll need ahead of time.
Dead end.
Attempt 2: Cling
Cling is CERN's interactive C++ interpreter, built on top of Clang/LLVM. It's the technology behind ROOT's C++ REPL. It already does incremental C++ compilation. This seemed like the right layer to build on.
I built an integration layer: send eval strings to Cling, make library attachment wrappers so that shared objects (.so files) could be bound without manual dlopen/dlsym ceremony.
Problems appeared quickly:
C++20 coroutines were not supported. For a framework where coroutines are the primary temporal coordination mechanism, this was severe.
Templates worked to some extent, better than the debugger path, but with limitations.
Latency was still through the roof for performance use. Not as bad as the debugger path, but not in the "play a note and hear it this buffer cycle" territory I needed.
And the worst issue: memory. At some point during a session, previously declared variables and functions in the open scope would just vanish. I still haven't figured out exactly what triggers it. The interpreter's internal state management does something that causes symbols to become unreachable. For a live coding session where you're building up state over the course of a performance, losing your accumulated declarations is catastrophic.
Dead end.
Attempt 3: JIT compiler + AST parser (the rabbit hole)
At this point I started looking at lower-level approaches. LLVM's JIT infrastructure (ORC JIT) can compile and execute IR at runtime. Clang can parse C++ into an AST. Maybe I could wire them together myself.
Weeks of research. Calling functions from JIT-compiled code: works. Declaring variables: works. But function definitions and class definitions require deep AST manipulation. Unless I wanted to spend the next twenty years understanding Clang's AST parser internals and building a custom incremental compilation pipeline on top of it, this was not viable.
The AST parser is an extraordinary piece of engineering, but it is not designed to be a user-facing tool for incremental code ingestion. It is designed to parse complete translation units. Bending it to accept "here's one more function definition, add it to the existing state" is fighting the architecture at every step.
The breakthrough: Clang's own incremental interpreter
Somewhere in the middle of attempt 3, I changed approach.
Up to that point, I was still thinking in terms of using various stages of compiler infrastructure. At some point it clicked that the compiler itself is just a binary built out of these same libraries. LLVM exists to build compilers. So instead of trying to stitch together a JIT and an AST parser from the outside, I started trying to build a minimal compiler interface of my own by linking against the relevant Clang and LLVM components.
The idea was straightforward in principle: take control of the compilation pipeline directly. Parse, lower, JIT, execute. If incremental compilation wasn’t exposed cleanly, I would assemble the pieces that make it possible.
That path led straight into the internals I had not acknowledged, considering my focus on infrastructure that enables those internals. And in the process of wiring those pieces together, I ran into something I hadn’t properly considered before: Clang already ships an incremental compilation layer.
clang::Interpreter, built with IncrementalCompilerBuilder. This is the machinery behind clang-repl. It sits on top of ORC JIT, manages incremental state, handles symbol resolution across eval boundaries, and crucially, supports the full C++ language.
At that point the direction became obvious. Instead of trying to recreate a compiler pipeline, I could inherit from the same infrastructure Clang uses itself. Load ORC JIT through Clang’s incremental builder, and let it manage the compilation lifecycle.
And it works. Real C++. Full language support. Templates, lambdas, classes, coroutines, the lot.
There is one caveat on Linux with LLVM versions before 21: unnamed lambdas with captures cause infinite recursion during symbol resolution. The workaround is to declare lambdas as named std::function variables before passing them. This is a small price to pay for a full C++ JIT REPL.
// This crashes on LLVM < 21 (Linux):
schedule_metro(0.5, [](){ /* ... */ }, "tick");
// This works everywhere:
std::function<void()> tick_fn = [](){ /* ... */ };
schedule_metro(0.5, std::move(tick_fn), "tick");
The result is Lila, MayaFlux's live coding engine. It wraps clang::Interpreter with a TCP server for networked eval (so an editor can send code blocks to a running MayaFlux instance), event hooks for eval success/error feedback, symbol introspection, and automatic PCH loading so the full MayaFlux API is available immediately on interpreter startup.
What Lila actually gives you at runtime
This is the part that matters most. Lila is not a toy REPL that can add two numbers. When the interpreter initializes, it does real work to make the JIT context behave like a normal compiled C++ environment:
It resolves the system include paths, the Clang resource directory, dependency headers (Eigen, GLM, Vulkan, etc.), and the entire MayaFlux header tree at startup. On Linux it queries llvm-config and the platform's system include layout. On macOS it finds the SDK via xcrun and sets -isysroot so the JIT can see Foundation, pthread, the lot. On Windows it loads the MSVC runtime DLLs (msvcp140.dll, vcruntime140.dll, ucrtbase.dll) and the MayaFlux shared library into the JIT's symbol space explicitly, because Windows symbol resolution won't find them otherwise.
The PCH (precompiled header) that the compiled binary uses is the same PCH the JIT loads. When the interpreter starts, it runs #include "pch.h" and #include "Lila/LiveAid.hpp" through ParseAndExecute. After that, every #include you'd write in normal MayaFlux code just works. You write #include "MayaFlux/MayaFlux.hpp" in a JIT eval block and it resolves exactly as it would in a compiled translation unit, because the paths are the same paths and the flags are the same flags (-std=c++23, -DMAYASIMPLE, platform-specific PIC/PIE flags).
On Linux specifically, MayaFlux is linked with -Wl,--no-as-needed against the JIT library, which forces all symbols from the framework's shared library to remain visible to the ORC JIT symbol resolver. Without that linker flag, the dynamic linker strips "unused" symbols and the JIT can't find framework functions at runtime. This is the kind of thing that takes a full day to debug and one line to fix.
The practical result: in a JIT eval block you can #include any header the compiled project can, call any function, instantiate any template, use any type. It is the same C++. Not a subset.
The architecture
Lila runs in three modes: Direct (eval calls in-process), Server (TCP listener that accepts code strings from a connected editor), or Both.
In server mode, a Neovim plugin sends selected code blocks over TCP to the running MayaFlux process. The server receives the string, strips framing, passes it to clang::Interpreter::ParseAndExecute, and returns a JSON response with success/error status.
The Listener
The TCP framing went through its own journey.
The first version didn’t use ASIO at all. I built a minimal server/listener from scratch. It worked, but it immediately ran into an annoying question: how often do you poll? Too fast and you waste cycles. Too slow and you introduce latency that is perceptible in a performance context. There isn’t a satisfying answer when you’re manually managing that loop.
On top of that, platform inconsistencies made things worse. Apple’s partial C++20 support meant I ended up maintaining two versions of the same codepath: one using std::jthread and one without. It worked, but it felt fragile and unnecessarily complex for what should be a solved problem.
That’s when I moved to ASIO and let the async model handle the scheduling properly.
The framing itself still needed iteration. The initial implementation used asio::async_read_until with a newline delimiter. This works for single-line input, but breaks down for multi-line code blocks, which is most real usage. The current implementation uses async_read_some, accumulating into a buffer and dispatching only when a trailing newline is detected, which more closely matches the raw socket behavior I needed.
The latency story: with coroutines managing the async I/O, the TCP round trip (editor to server, eval, response back) is consistently under one audio buffer cycle at 128 samples / 48kHz. That is about 2.67ms. For practical purposes, code evaluation is instantaneous relative to any perceptible musical or visual event.
What live coding actually looks like
Live coding in this context is a cue-sheet model. Something is already running: the MayaFlux engine, with audio output, a Vulkan window, active node graphs, scheduled coroutines. The performance instrument is the choice of which code block to eval and when.
You might have a file open with twenty code blocks. One defines an additive synthesis voice. Another wires it to a particle system. Another schedules a temporal pattern. The performance is selecting, modifying, and evaluating these blocks in response to what you hear and see.
This is distinct from the dominant live coding aesthetic where a rhythmic grid drives everything. There's no global clock ticking eighth notes. Timing emerges from coroutine scheduling, from logic node events, from the data itself. Audio and visual coupling comes from shared source data, not from a sync mechanism bolted on after the fact.
Here's what a simple physical modeling voice looks like, evaluated live:
auto net = vega.WaveguideNetwork(4, 48000);
net->set_delay(0, 0.004);
net->set_delay(1, 0.0057);
net->set_delay(2, 0.0031);
net->set_delay(3, 0.0043);
net->excite(0, 0.8);
route_node(net) | Audio;
And here's live-coded visuals reacting to it:
auto particles = vega.PointCollectionNode(2000);
particles->set_growth_rate(0.02);
route_node(particles) | Graphics;
net->on_change_to(true, [&](auto& ctx) {
particles->burst(200, ctx.value);
});
Each of these blocks is evaluated independently during a performance. The order, timing, and modifications are the composition.
The full pipeline: file to GPU to screen, all live
Here is where it gets interesting. Because Lila gives you the full framework at JIT time, and because MayaFlux treats audio and visual as the same kind of data, you can build an entire multimedia pipeline from nothing during a performance.
Load an audio file from disk using FFmpeg (any format: wav, flac, mp3, ogg, whatever FFmpeg can decode). MayaFlux's vega.read_audio() handles format detection, decoding, resampling to your project sample rate, and deinterleaving into a SoundFileContainer with a processor already attached:
auto source = vega.read_audio("res/audio/field_recording.wav");
Run granular synthesis on it. The granular pipeline segments the container into grains, attributes them (by spectral centroid, RMS, zero-crossing rate, or a custom lambda), sorts them, and reconstructs. The attribution step can run on GPU via compute shader when the grain count crosses a threshold:
auto granular = Kinesis::Granular::process_to_container(
source,
Kinesis::Granular::AnalysisType::SPECTRAL_CENTROID,
{ .grain_size = 2048, .hop_size = 512 }
);
Hook the container to the audio buffer system through IOManager, which creates per-channel SoundContainerBuffers and wires the processor that feeds data each cycle:
auto io = MayaFlux::get_io_manager();
auto audio_buffers = io->hook_audio_container_to_buffers(granular);
// That's it. Per-channel buffers are created, processors attached,
// auto-advance enabled. Audio flows next cycle.
Now take that same granular data and pass it to the GPU. Create a texture buffer, attach a TextureWriteProcessor that handles the CPU-to-GPU memory upload as a descriptor binding, write a fragment shader that reads from it. MayaFlux uses Vulkan 1.3 dynamic rendering, so there are no render pass objects to manage. You set up a ShaderConfig with your bindings, point a RenderProcessor at your fragment shader and target window, and the processing chain handles the command buffer recording, descriptor set updates, and frame synchronization:
auto tex = vega.TextureBuffer(1920, 1080);
auto writer = std::make_shared<Buffers::TextureWriteProcessor>();
writer->set_data(granular->get_region_data(Region::all()));
tex->setup_rendering({
.fragment_shader = "granular_vis.frag.spv",
.default_texture_binding = "grainData"
});
The fragment shader receives the grain amplitudes, spectral data, whatever you bound, as storage buffer data at the binding points you declared. It runs every frame. The audio runs every buffer cycle. They're driven by the same source data. The visual is not a visualization of the audio; it's a parallel transformation of the same numerical stream.
All of this is evaluated live. Each code block above is a separate eval sent from the editor during performance. You can change the grain size, swap the analysis type, rewrite the fragment shader path, rebind different data, all while the engine is running. Frame-accurate timing on the visual side, sample-accurate on the audio side. The scheduler ensures that node graph mutations land on the next tick boundary, not mid-buffer.
This is not a visualizer bolted onto a synth. This is one data pipeline with two output domains.
What's ahead
On the engine side, Lila's eval context has access to the full MayaFlux API, which means live coded blocks can do anything the compiled binary can do: create and wire audio graphs, dispatch Vulkan compute shaders, schedule coroutines, manipulate 3D mesh networks, read camera input, stream video. The performance space is the same as the development space.
A Steam Deck. Four cores, handheld hardware, running in desktop mode. A particle system with 10,000 particles driven by push constants updated from a network of hundreds of sound-producing nodes generating an async drone. Two external monitors. Vulkan dynamic rendering, real-time audio, live JIT eval from a Neovim instance over TCP. The whole thing is faster and more responsive than IPython is at importing NumPy on my 7950X3D desktop. That is not hyperbole. The JIT eval round-trip on the Deck completes before IPython finishes resolving import numpy. C++ compiled to native code through LLVM's ORC JIT, running on bare metal, will do that.
The first TOPLAP performance set is done: four pieces covering additive synthesis with particle visuals, waveguide physical modeling, granular reconstruction from a 2017 violin/analog rack composition, and a fully live-coded piece built from nothing during performance. Fifteen minutes. It works on a Steam Deck in desktop mode with a 14-inch touchscreen and an HDMI projector.
I’m linking the live coding segment here. This part of the set was not intended as a finished artistic piece, but as a demonstration of the system in use. In the video, I start from a fresh instance and incrementally evaluate code blocks to build the result in real time. The focus is on exposing the process rather than presenting a composed work.
If you want to live code in C++, it is difficult. You will waste time on debugger APIs. You will fight Cling's memory management. You will stare at Clang AST internals until your eyes blur. But clang::Interpreter with IncrementalCompilerBuilder and ORC JIT is the path. It works. It's fast enough. And it's real C++, not a subset, not a DSL, not a string-command dispatch table. If the compiler can compile it, you can eval it live.
Or, use Lila! If it cant already handle what you need, I will do my best to support the craziest of your ideas.
MayaFlux is open source: github.com/MayaFlux/MayaFlux
