Path A: K11-Centric -- K11 Does Everything Possible Locally

Path A: K11-Centric -- K11 Does Everything Possible Locally

Concept

K11 is the god-node. All sensor processing, visual rendering, audio analysis, motion feature extraction, and coordination happen on K11. Other machines are optional consumers or ML inference servers. K11 runs its own feature extractor for mocopi (replacing MotionMix's MocopiFeatureExtractor), its own motion-to-music parameter mapper (port of ParamMapper logic), and its own coordination layer. MotionMix becomes a camera-only node or is removed entirely.

Architecture

K11 (everything)
+----------------------------------------------------------+
| Femto Bolt -> pointcloud_pub.py -> LUMD -> Unity          |
| UMA-8     -> audio_pub.py      -> LUMF -> Unity          |
| mocopi BT -> Sony app -> :12351 -> mocopi_bridge.py       |
|              -> LUMM :9702 -> Unity LumeMocopiReceiver     |
|              -> LumeMotionFeatureExtractor (NEW, in Unity) |
|                                                            |
| Unity: all 10+ components + NEW motion-to-music mapper     |
|        + NEW coordination dispatcher                       |
|        + sends param packets to Mac5 Strudel via HTTP/UDP  |
|                                                            |
| Python: 3 publishers + NEW lume_coordinator.py             |
+----------------------------------------------------------+
        |
        | Tailscale UDP: motion params -> Mac5 Strudel :9600
        | Tailscale HTTP: ML inference -> cloud-vm / Mac5
        v
Mac5: Strudel.js (audio synthesis only)
cloud-vm: Diffusion inference API

Strengths

• Minimal network dependency. Sensor-to-visual path is entirely local. Zero Tailscale hops for the core loop.
• Single point of deployment. All code runs on one machine. One git clone, one set of services.
• Lowest latency for visuals. Sensor -> publisher -> Unity is loopback UDP, sub-2ms.
• Simplest failure mode. If K11 works, everything works. No distributed failure scenarios.

Weaknesses

• Duplicates MotionMix intelligence. ParamMapper, ChestFlexDetector, MocopiFeatureExtractor would need C# ports in Unity or Python equivalents. That's ~800 lines of logic that already works in Swift.
• No CUDA. ML inference still requires network hop. Can't run diffusion locally.
• Echelon not available. The 20-crate Rust engine (128D latent, SAN, lexicon) has never been compiled for Windows. Porting is weeks of work, not hours.
• Music synthesis gap. K11 has no audio synthesis engine. Strudel.js is on Mac5. Echelon's audio engine is iOS. Building a new audio engine on K11 is a massive undertaking.
• Single point of failure. If K11 crashes, everything dies. No redundancy.
• Loses MotionMix's camera intelligence. Vision body pose from iPhone, face analysis, AutoDirector scoring are iPhone-native capabilities. K11 can't run Vision framework.

Verdict

PARTIAL ADOPT. The sensor-to-visual path SHOULD be K11-local (it already is). But duplicating MotionMix's motion intelligence and Echelon's coordination is wrong. K11 should be sovereign for visual rendering and sensor ingestion, but should not try to replicate the iOS intelligence stack.