Skip to content

Roadmap

Pavel Litvinenko edited this page Aug 23, 2026 · 1 revision

Kithara Roadmap

This page describes the ordered strategic outcomes for Kithara. Detailed capabilities, their order within each work area, and evidence-backed status are maintained in Kithara Development.

Current Product Outcome: Mobile Mixing

Mobile is the first foundation because it is the more constrained integration environment: lifecycle, network variability, latency, resource budgets, thermal behavior, and packaging must all work through a narrow public surface. Once that base is accepted, larger desktop and other music applications can build on the same engine without redefining its contracts. A Spotify-style transition experience is the initial product reference.

Deliver an embeddable iOS and Android engine that mixes two streamed tracks through a canonical editable transition:

  • playback starts as soon as playable data is available;
  • musical analysis is supplied through one typed, revisioned contract;
  • the engine creates and validates an initial transition plan;
  • the host application can edit musical anchors, overlap, tempo, gain, EQ, and filters;
  • both tracks remain exactly aligned to the Session host grid throughout the overlap;
  • the transition executes deterministically through equivalent Swift and Kotlin APIs;
  • physical-device evidence covers supported media, tempo ranges, lifecycle events, network conditions, latency, and resource budgets.

A time-based crossfade without exact musical synchronization does not satisfy this outcome.

Ordered Strategic Outcomes

1. Exact Two-Track Mobile Mixing

Complete the first end-to-end path from streamed media and supplied analysis to an editable, persistent transition and beat-perfect execution on iOS and Android. This is the immediate integration and acceptance target.

2. Continuous Playlist Mixing

Extend the same transition model from one pair to a complete queue. Maintain a plan for every adjacent pair, rebuild only affected transitions when the queue changes, and support deliberate tempo pivots and harmonic preparation without moving recommendation policy into the engine.

3. Professional DJ Workflow Completeness

Complete the capability families expected from a professional DJ system: flexible routing, cues, beatjumps, loops, expressive transport, effects, scratching and DVS, stems, remix and sample sources, live input, external controllers and synchronization, recording, export, and broadcast.

4. Dynamic and Extensible Music Runtime

Support dynamic Session entities, complete the composable audio graph and open domain registry, and prove that non-DJ applications can reuse Core without parallel state or product-specific behavior.

5. Mature Cross-Platform SDK

Provide stable Rust, Swift, Kotlin, and browser contracts with reproducible packaging, typed errors, capability discovery, lifecycle parity, observability, documented resource profiles, and a versioned extension boundary.

Work Directions

Every direction contributes to the current product outcome. Links open the canonical Project views rather than duplicating task lists in the Wiki.

  1. Product — transition behavior, editing, playlist mixing, preparation, and professional DJ workflows.
  2. Core Engine — streaming, playback, musical time, synchronization, transition execution, DSP, routing, and dynamic entities.
  3. Kithara App & UI — reference editor, public deck workflow, shared UI and scene runtime, and full reference application.
  4. Engineering Infrastructure — mathematical audio oracles, deterministic runtime, real-time safety, stress evidence, CI, and performance measurement.
  5. Platforms, SDKs & Extensions — mobile embedding, lifecycle, packaging, public APIs, additional platforms, media services, and extension contracts.

Acceptance Principles

  • Musical correctness: rendered PCM proves beat, downbeat, and phase alignment without accumulated drift.
  • Streaming readiness: current playback and the next transition use bounded readiness windows rather than full downloads.
  • Determinism: the same versioned inputs and transition plan preserve their musical meaning across replay.
  • Atomic failure: invalid analysis, plans, or resource expansion are rejected without disturbing active playback.
  • Measured scale: correctness is unchanged across entity counts; performance guarantees are attached to explicit device and workload profiles.
  • Public-path proof: Kithara App and platform integrations use the same engine surface available to external consumers.

Feedback

Clone this wiki locally