A research and artistic software system for audience-participatory performance: audience inputs are aggregated through weighted consensus while performers retain explicit override authority.
Repository status: active proof-of-concept with recovered native core-engine verification. The integration line has produced strict compiler/test logs and a preserved benchmark artifact. Exact-head monorepo validation and accepted-main closeout are tracked in issue #82. Current deployment, rehearsal, and live-performance validation remain separate, unestablished gates.
Evidence status · Core engine · Examples · Documentation · Contributing
At the source level, the repository contains inspectable implementations or scaffolding for:
absolute, blend, and lock;Those facts are implementation facts. They do not, by themselves, prove that the complete system builds, deploys, scales, delivers messages reliably, meets a latency target, works for performers or audiences, or has operated in rehearsal or live performance.
| Question | Current answer |
|---|---|
| Is there inspectable source for weighted consensus and performer override? | Yes. |
| Are deterministic functional tests and a benchmark entrypoint defined? | Yes. |
| Has the strict core workflow produced complete compiler/test logs for the integration line? | Yes: native run 36084110788, candidate 9c7ac7042d762a72b2bec440e50cd8585edf8782. Later-head acceptance is recorded separately in #82. |
| Is there preserved benchmark JSON evidence for the integration line? | Yes: artifact 10843446354, recording executed merge SHA b3843de97e6a97a8f8bf749010db3a4955d02658. Candidate and executed-merge trees both equal 5d0f67b6aba3ea330a0cf447cafe28ccf691db35. |
| Is any latency, throughput, delivery, error-rate, or connection-capacity result currently admissible? | No. Earlier numerical claims are being removed or reduced to explicit targets/history. |
| Is there current deployment evidence? | Not established. Infrastructure files are not deployment evidence. |
| Is there rehearsal or live-performance evidence? | Not established in the current evidence lane. |
| Is the system production ready? | Not established. |
The canonical claim register is docs/reproducibility/core-engine-evidence-status.md.
The project asks how an audience can shape a performance without collapsing the performer into a servant of a vote.
The proposed authority model is neither unilateral authorship nor simple majority rule:
This is a design proposition implemented in code. Whether the proposition produces usable, legible, or artistically valuable interaction remains an empirical and practice-research question.
Audience and performer clients
|
Socket.IO
|
Parameter bus
|
Consensus aggregation
- spatial component
- temporal component
- agreement component
- filtering and smoothing
|
Performer override
|
Browser, dashboard, OSC,
audio, or other outputs
Primary locations:
packages/
core-engine/ consensus, bus, server, OSC, types
performance-sdk/ performer and audience UI components
client-sdk/ lighter client integration
audio-synthesis-bridge/ audio and OSC paths
orchestrate/ separate Python orchestration package
examples/
generative-music/
generative-visual/
choreographic-interface/
theatre-dialogue/
infra/ deployment scaffolding
docs/ design, research, operations, and archive
The directory tree describes repository organization, not a claim that every package or example currently passes its build or integration tests.
For an input value x_i, the current core implementation computes:
These components are combined and clamped to a positive scalar weight. A weighted mean is then computed over the retained cohort, or a median/cluster mode is selected. Optional smoothing incorporates a prior value. Performer override is applied separately.
The current pairwise agreement calculation compares every input with the cohort. Therefore the dominant time complexity of one consensus call is Theta(n^2) for n inputs; auxiliary space is O(n). No capacity claim follows from the presence of the implementation.
A formal, assessment-ready analysis of the bounds, determinism conditions, complexity, counterexamples, and code correspondence is maintained in the doctoral dossier repository and references the exact repair head.
From the repository root, with the locked workspace dependencies available:
pnpm install --frozen-lockfile
pnpm --filter @omni-dromenon/core-engine typecheck
pnpm --filter @omni-dromenon/core-engine test
pnpm --filter @omni-dromenon/core-engine test:bench -- \
--output benchmark-results/consensus-baseline.json
The strict workflow is .github/workflows/core-engine-evidence.yml.
The seeded benchmark evaluates only in-process calls to computeConsensus over deterministic cohorts of:
For each cohort it declares the seed, fixed evaluation clock, warm-up count, measured-call count, timer, runtime, source revision, and summary statistics. It also requires identical consensus output across repeated calls in one process.
It excludes:
The benchmark deliberately asserts no threshold. Any future number must be described as in-process consensus compute time in the recorded environment unless a separate end-to-end protocol supports a broader statement.
packages/core-engine/ contains the principal evidence lane.
Important files:
| Object | Path |
|---|---|
| Weighted consensus | packages/core-engine/src/consensus/weighted-voting.ts |
| Parameter aggregation | packages/core-engine/src/consensus/parameter-aggregation.ts |
| Bus | packages/core-engine/src/bus/ |
| Server | packages/core-engine/src/server.ts |
| OSC path | packages/core-engine/src/osc/ |
| Shared types | packages/core-engine/src/types/ |
| Deterministic and functional tests | packages/core-engine/tests/ |
| Seeded benchmark | packages/core-engine/src/benchmarks/consensus-bench.ts |
| Package evidence statement | packages/core-engine/README.md |
The current repair injects one evaluation clock through temporal weighting and result timestamps, removes randomized unit-test timing thresholds, adds deterministic invariants, and moves performance measurement into an artifact-producing benchmark lane.
The examples are genre-oriented exploratory implementations, not equivalent to verified deployments.
| Example | Intended exploration | Current claim boundary |
|---|---|---|
generative-music |
audience control of musical parameters and browser/audio paths | inspectable proof-of-concept source; no preserved 2 ms, delivery, error-rate, participant, rehearsal, or performance result |
generative-visual |
consensus values mapped into visual parameters | implementation and build status require exact-head audit |
choreographic-interface |
movement and audience-input relationships | implementation, camera assumptions, rights, and evaluation require audit |
theatre-dialogue |
branch selection and performer authority | implementation and study status require audit |
Successful startup of an example would establish only that it starts in the named environment. It would not establish production readiness or artistic outcome.
The source defines three performer override modes:
absolute: replace the computed value;blend: combine performer and audience values under a declared factor;lock: hold a performer-selected value.This makes performer authority explicit in the interface. It does not prove that the authority model is understandable, fair, usable, or artistically successful. Those questions require participant-facing studies or documented practice research.
The outlier-removal and agreement-weighting mechanisms also carry governance consequences: a mathematically valid filter can suppress a minority signal. The implementation must therefore be evaluated not only for numerical correctness, but for how its rules distribute voice and intervention.
Historical documentation names targets such as low latency, high connection capacity, bounded memory, and fixed broadcast cadence. Until measured artifacts exist, these remain unvalidated engineering targets.
A target may stay in active documentation only when it is clearly labeled as a target and not presented as achieved. Reinstating a numerical result requires:
The repository contains documents created at different times and maturity levels.
docs/reference/omnidramanon-cold-storage/ preserves earlier records and claims; it must not be used silently as current evidence.The presence of a document, diagram, deployment file, screenshot, or portfolio page is not proof of runtime behavior.
The core evidence lane remains incomplete until:
Contributions should state which evidence class they affect:
Do not describe code as deployed because it builds, or a benchmark as audience latency because it times one function.
General contribution guidance is in .github/CONTRIBUTING.md.
MIT License. See LICENSE.
Primary author and repository steward: Anthony Padavano (@4444J99).
This repository is part of the broader ORGANVM corpus. That institutional relationship does not alter the evidence boundary of this individual project.
Case Study · Portfolio · System Directory · ORGAN II · Poiesis · Part of the ORGANVM system