MCCF: Showtime! From Experimental Platform to Narrative Composition — and Beyond X3D
Watch the MCCF demo
A short video of the Multi-Channel Coherence Field working in an X3D scene. Watch it on YouTube.
A pleasant surprise, and an important milestone On November 9, 2026, I received an unexpected and particularly welcome report from Paul Garrett Hugel, who had independently downloaded and investigated the Multi-Channel Coherence Field (MCCF) repository. Paul's work is important for several reasons. He did not simply review the documentation or run a prepared demonstration. He established an independent development environment, used a different LLM provider, connected multiple MCCF interfaces, created a narrative scene, and exercised the existing relational couplers.
Someone else ran it. What an independent test found, and where V6 goes.
Over the weekend Paul Garrett Hugel posted a report to the Web3D AI list about an independent exploration of MCCF. I did not know it was coming. It is the first time someone outside the project has taken the repository, built their own environment and worked with it, and I want to answer it properly.
What Paul did
He ran MCCF locally on a Mac mini M4, with Jan.ai as the model provider, a llama.cpp server and Gemma 4 E4B (IQ4_XS), not a cloud API. He pinned a repository revision, kept the original untouched and worked in a separate copy. OpenAI Codex assisted with repository inspection, the Jan integration, scene creation, testing and documenting the findings. Paul directed and approved the work, and he said so plainly.
- Four LLM paths. Chat, scene dialogue, zone commands and the Greek Chorus each returned generated text from the local model. Gemma was slow on some scene prompts, and small output budgets sometimes produced no answer text.
- The Crossing. A scene he made: two robots approach a boundary, exchange four lines written by Gemma, and cross together. Movement, cameras, timing and captions were authored. The dialogue was generated once, saved and replayed. He verified movement, captions, chapter jumps and pause/resume.
- The couplers. With a small comparison interface that called the existing runtime unchanged, he ran six ticks. Resonance moved a synthetic target E from 0.200 to 0.786. Inversion asked for negative drift, but the runtime clipped it at the lower bound and the target stayed at 0.200. From identical warmed-up states of 0.500, Damping took the target to 0.218 and Integration to 0.586.
- Two defects. A viewer diagnostic assumed an avatar named Avatar_Cindy, and port 5000 clashed with Apple AirPlay.
He closed with a recommendation: live, unscripted dialogue between characters under controlled coupler conditions, with logs that keep model output, state updates and authored staging separate.
What I take from it
The numbers are what they claim to be. They show implemented behavior. Paul says so himself: not measured emotions, not validated alignment, not psychological effects. I agree, and that has been this project's position from the start.
Requested versus applied is a real finding. The runtime clamps its state values to fixed ranges, so a coupler can ask for a change the state cannot take. That is the model working as designed, but the author never sees it, because only the applied result is reported. Paul found by experiment what the interface should have told him. In V6 a coupler tick should report the requested change, the applied change and the bound that stopped it. I have not yet reproduced his figures. They are plausible given the clamps, and I will run them as a regression test once I have his setup.
His two defects are ours. The Loader's SAI test button falls back to the name Avatar_Cindy when a scene registers no avatar. That is harmless in our scenes and wrong in anyone else's. And the Loader and several other pages hard-code localhost:5000. Recent macOS keeps port 5000 for AirPlay Receiver, so every Mac user will hit what Paul hit.
Empty answers. Our token budgets are small on purpose: 60 for zone commands and 80 for the Chorus by default. They were tuned on a model that talks too much. This week Llama would not stop. A model that spends tokens on hidden reasoning can use up the whole budget before it writes a word, and MCCF then says nothing and does not tell you why. A silent failure is a bug.
These go first on the fix list, ahead of new features. Making an outside tester's life easier is how MCCF becomes something people can rely on.
- Replace the Avatar_Cindy fallback with the registered avatar, or a clear message that the scene has none.
- Make the port configurable: derive the address from the page, add a server port setting, and document the AirPlay conflict.
- Detect an empty reply, retry once with a larger budget, and report it on screen and in the log. Make budgets and timeouts configurable per provider.
- Report requested change, applied change and the stopping bound from the coupler tick.
The Crossing, and some questions
I want to see The Crossing. The test of an instrument is what someone else finds they can play with it, and Paul made something with MCCF that I did not make. Paul, a few questions:
- Which repository revision did you pin? A commit hash would let me tell you which of these problems are already fixed.
- Did you build the scene with the Scene Composer and mccf.xsd, or write the X3D directly? Either answer helps. If the Composer and the Guide were enough without me in the room, that is the best evidence I could ask for. If not, it shows me where the authoring tools fell short.
- What did you change to connect Jan?
- May I see the scene, your modifications, the test evidence and the checkpoints? They could become a reproducible test case.
- May I quote your numbers and link your report?
Two jobs, one architecture
MCCF as a laboratory. An environment for investigating how dialogue, character state, relationships, events and presentation affect one another, under controlled conditions. It is judged by reproducibility, observability and whether it explains anything.
MCCF as a composition instrument. An authoring environment for characters, relationships, dialogue, sound, timing and spatial staging, rendered in 3D. It is judged by expressive range, authorial control and the quality of what people make with it.
They share one semantic architecture, and neither needs the other to be useful. Paul's work touched both: the couplers are the laboratory, The Crossing is the instrument.
Beyond X3D
X3D is the stage, not the narrative. mccf.xsd carries narrative semantics: characters, relationships, events, dialogue and state. Its spatial parts (waypoints, zones, lights) are shaped around X3D, so another medium would need an adapter. I am not claiming those adapters exist. There is one small piece of evidence: this weekend a zone in a scene's XML began steering the scale of a generative music engine. It is the same scene description driving a second medium.
Possible adapters, none built: audio drama and interactive radio, branching web stories, interactive text and teaching exercises, and cue sheets for physical theatre. The cost argument is simple. Reuse the semantics and write a thin presentation layer, rather than a new narrative engine for every medium.
Directions for V6
These are proposals, not a claim that any of it is done.
- Semantic foundation. Keep developing mccf.xsd and its vocabularies, and keep the principle of least commitment: unknown stays unknown.
- Event identity and provenance. Record an event once, attach its manifestations, and record the resulting state transitions with provenance.
- Observable experiments. Log model, prompt, response, latency and errors; requested and applied transitions; and authored staging, as three separate records.
- Three kinds of test. Component tests, integration tests, and complete narrative-use tests, kept apart. Until now our testing has been mostly the first. Paul's work is a start on the third.
- Authoring for non-programmers. The mixing-board idea stays: shape a narrative through understandable controls, not runtime code.
- Presentation independence. Keep the narrative model separate from X3D details, and define what an adapter needs.
- Outside contributions. Reproducible experiments, pinned revisions and documented configurations, so others can repeat what we claim.
Paul's recommendation suggests the first full integration test. Hold the model, prompts and staging constant, vary only the coupler, and compare the state trajectories and the dialogue. One variable at a time, with the three logs kept separate. That asks whether relational topology changes the dialogue or only sits beside it.
Thanks
Thank you, Paul, for the care in this: the pinned revision, the preserved original, the plain statement of what the numbers do and do not show. Thanks also to Codex, credited as Paul credited it. MCCF is at https://github.com/artistinprocess/mccf.
We have tested the pieces. Now someone outside the project has played the whole instrument, and I am eager to hear the rest.
May fortune favor the foolish.
Len Bullard

Comments
Post a Comment