MotionMix Sphere Product Architecture - Current

MotionMix Sphere Product Architecture - Current

Generated: 2026-06-13 02:31 EDT

Core Product Shape

MotionMix should treat a session as a Sphere: a shared capture room where people, phones, cameras, audio sources, gestures, stage controls, and later editing assets belong to one temporary production space. The user should not have to think in terms of IP addresses, ports, device tokens, or a Rust multicam server. The user-facing act is simple: create a Sphere, invite a friend, scan a QR code or open a link, assign what that friend contributes, and start recording or directing.

This maps directly onto the infrastructure already built. The iPhone or iPad app is a node. The multicam server on port 9404 is the Sphere coordinator. Live Director is the production surface. K11 is the heavy local archive, command gate, and studio storage node. SAN and BodyTruth are analysis lanes. The future Studio tab is where the resulting rushes, body-motion evidence, cuts, and templates become reusable media.

The Friend Podcast Scenario

The clean consumer story is: you want to do a podcast with a friend, so you create a Sphere called something like "Saturday episode." Your friend downloads MotionMix, opens your invite link, and chooses a role. Their iPhone can become a guest camera, a guest mic, a room angle, a shared clap sync source, or just a contributor device for remote capture. The Sphere owns the relationship between all of these devices, not the individual app windows.

For a podcast, the host may have one main iPhone, one side iPhone, one iPad running Director, and one Mac or K11 storage node. A friend can add another iPhone camera from across the table or from another location if the network mode supports it. The result is not just a video call. It is a structured capture session with labeled sources, synchronized recordings, optional live switching, and post-session assets that can be cut later.

The same model works for dance, rehearsal, stage capture, interviews, DJ sets, choreography, fitness coaching, and community challenges. The common object is always the Sphere.

Current System Mapping

MotionMix iOS is the capture node. It already knows how to publish camera frames, pose/body data, recording results, device identity, and control responses. In the Sphere model, each app instance registers with a session identity, a role, a label, and a permissions envelope.

The 9404 multicam server becomes the local Sphere coordinator. It discovers devices, tracks freshness, routes preview streams, receives recording state, drives Record All, exposes Director state, and eventually should fan out video streams from one upstream per device instead of opening repeated per-viewer streams.

MotionMix Live Director is the control surface. It should not be thought of as a separate product from the web director. It is the native production console for a Sphere. It should support camera layout modes, source selection, record all, flip, zoom, source health, session naming, and later Studio handoff.

K11 is the pro local archive and command node. It should remain the only Rekordbox command gate. For production capture, K11 should also be the durable place where rushes land after a recording, because it has the storage runway Mac1 does not. Mac1 can coordinate and develop, but K11 should own the heavier saved media path.

SAN and BodyTruth are not "always true" just because they are live. They are evidence lanes. They show that capture is alive, but training admission requires performer presence, freshness, multi-camera agreement, and a real session window. When the performer is out of frame, the data is heartbeat/room state, not movement truth.

Studio is the missing product surface. It should become the library and editing engine for Spheres: all recordings, all source angles, all body/gesture sidecars, all cut decisions, all template packs, and all exports belong there.

Joining A Sphere

The join flow should be:

1. Host creates a Sphere.
2. Host shares a QR code, local link, invite code, or account invite.
3. Guest opens MotionMix and joins the Sphere.
4. App registers the device with source label, camera capabilities, mic availability, pose capability, storage availability, network path, and battery/thermal state.
5. Host sees the new node in Live Director and assigns a role.
6. Recording and control permissions are governed by the Sphere.

Roles should include host, co-host, camera source, audio source, guest source, director, stage viewer, archive node, and observer. A device can hold more than one role. For example, an iPhone can be both "left guest camera" and "guest mic," while an iPad can be "Director only" or "stage monitor."

Recording Model

The right recording model is local-first, synchronized, and source-aware. Each mobile device should record its own high-quality local file using AVFoundation. The live stream is only a preview/control stream. That means preview lag or lower preview quality should not define final video quality. After recording ends, each device reports file metadata, duration, orientation, resolution, timestamps, and health. The K11 archive path then fetches or receives the actual rushes.

The Sphere should also save sidecar data for each session: source labels, timebase data, rough sync markers, body pose samples, gesture events, director cuts, camera flips, zoom changes, thermal/battery health, and any manual tags. These sidecars are what make the future Studio useful.

For podcasts, the system needs a clean "Record All" proof: visible recording state per device, saved count, failed count, upload/fetch status, and final K11 archive path. The user should never have to wonder whether the red button did anything.

Data And Training Boundary

The app can capture operational state continuously, but training data must be admitted intentionally. There are three separate states:

Capture alive means frames, device heartbeats, pose messages, and server counters are moving.

Performer present means the intended human is actually in frame with enough coverage and freshness.

Training admissible means a real session is active, the performer is present, motion is above baseline, multiple views agree, and the saved data is tied to a session with useful labels or context.

This prevents empty-room, sleeping, stale, or out-of-frame data from polluting the movement model. It also turns community use into a privacy advantage: people can join and contribute cameras without automatically donating body data or video to training.

Community And Monetization

The monetizable object is not "a camera app." It is hosted Spheres plus the workflows around them.

Free should allow a user to join a Sphere, contribute one camera, do simple local recording, and participate in a friend session.

Creator Pro should unlock hosting Spheres, three or more cameras, Record All, high-quality local recording, K11/NAS/cloud archive targets, Studio editing, custom camera layouts, templates, and session libraries.

Studio or Team should unlock shared spaces, persistent crews, podcast rooms, dance crews, branded templates, role permissions, remote guests, centralized archives, multi-user editing, and batch export.

Marketplace/community should focus on things that are safe to share: camera formations, podcast layouts, gesture packs, AirDeck mappings, movement phrase templates, edit recipes, color looks, and session blueprints. Raw video and body data should remain private by default.

Technical Direction

The next technical shape should be a Sphere manifest. Every live session should have one object that records:

• sphere id
• host id
• session name
• joined devices
• source labels
• device roles
• network path
• recording capability
• current recording state
• pose/body data eligibility
• archive target
• Studio project id

The current 9404 server already has most of the pieces, but they are still expressed as device registry, director state, recording state, and ad hoc readiness artifacts. A Sphere manifest would unify them and make the same infrastructure usable for friends, guests, podcast sessions, choreography capture, and pro local production.

The immediate product priority is not public cloud first. The immediate priority is to make local Sphere hosting excellent: easy join, clear source labels, reliable record all, K11 archive, visible health, and Studio handoff. Once that works locally, cloud-hosted or remote Spheres become an extension, not a replacement.

Product Rule

MotionMix should sell coordination, not capture alone. Every phone can already record video. The value is that MotionMix lets people assemble a small production sphere in minutes, synchronize the devices, control the session, preserve the evidence, and turn the resulting multi-angle material into something usable.