Computational Choreography: Deterministic Motion-to-Audio Synthesis via Geometric Anticipation Signals
Computational Choreography replaces direct sensor-axis-to-audio mappings with a deterministic geometric intermediary. The same motion window should produce the same anticipation packet and therefore the same downstream sound behavior.
Paper workspace
Live draft structure
Artifacts
Markdown paper source
Computational Choreography paper mapped from Comp-Core source.
source-only
Editable source
Paper source exists. Physical sensor-data evaluation remains the release gate.
Source anchors
Comp-Core/papers/computational-choreography/paper.md
computational-choreography/09-reference/external-research.md
Comp-Core motion/audio crates
Method tags
Ingest intersections
Status
Paper drafted with verified build artifacts; physical sensor-data evaluation still pending.
Key claims
01
Motion-to-audio systems need deterministic replay to become research instruments.
02
Anticipation packets decouple sensor hardware from musical control.
03
Physical sensor evaluation remains the release gate.
Public reading note
Public reader page safe; physical evaluation still pending.
Standard skeleton
What this paper must keep proving
problem
Ad hoc sensor-axis-to-audio mappings are fragile, non-deterministic, and hard to evaluate.
method
Insert a deterministic anticipation packet between sensor fusion and audio synthesis.
implementation
Rust motion/audio pipeline, fixed schema packets, Strudel bridge, genre kits, and replay checks.
data
Motion sensor streams and future physical evaluation captures; current paper includes build and cross-domain validation evidence.
evaluation
Determinism, latency, musical quality, and physical sensor-data performance.
references
NIME, TouchDesigner/Ableton motion systems, MediaPipe, Strudel/TidalCycles, anticipatory music systems.
openQuestions
Physical sensor-data evaluation must be completed before the strongest performance claims are public.
Checkpoints and references
Proof chain
Claim checkpoint
central-claim slot
Every central claim must point to a proof anchor or remain labeled as speculative.
Implementation checkpoint
implementation-map slot
Every method should identify the code path, harness, schema, or protocol that embodies it.
Evidence checkpoint
evidence-manifest slot
Every reported result should point to run IDs, packet IDs, data snapshots, commits, or review artifacts.
Reference checkpoint
references slot
Every external claim should resolve to a cited paper, benchmark, standard, or documented prior system.
Release checkpoint
release-gate slot
Every PDF needs a named condition before it can move from draft to citation-ready.