Mesmerization Sound Studio: Master Architecture and Product Specification

Full report

On this page

Executive synthesis and product doctrine

The Mesmerization Sound Studio should be built as one headless, deterministic generative-audio product core with two presentation shells:

1. a standalone /sound experience with no visualization or WebGL dependency; and
2. the Visualization Studio’s Advanced Sound Studio panel, which mounts the same controller, canonical state model, DSP policies, presets, scenes, score system, diagnostics, and UI components, adding only an optional Visual Sync adapter.

That architecture is strongly supported by the supplied UX, synthesis, synchronization, preset, modulation, workload, spatial, granular, and psychoacoustic research. The existing research consistently converges on a shared headless engine, reusable UI, explicit visitor-controlled transport, deterministic authored state, and a narrow optional bridge to visualization rather than a second audio implementation.

The Web Audio platform fits this model. Web Audio is itself graph-based, supports sample-accurate scheduling and parameter automation, exposes native oscillators, filters, delay, convolution, spatialization and custom AudioWorklet processing, and provides OfflineAudioContext for faster-than-real-time rendering. The API deliberately does not provide a stable graph-serialization/introspection model, which makes application-owned canonical project state essential rather than optional.

The central architectural decision

The canonical flow should be:

                       ┌─────────────────────┐
                       │   SoundProject      │
                       │ durable authored    │
                       │ state               │
                       └─────────┬───────────┘
                                 │
              ┌──────────────────┼──────────────────┐
              │                  │                  │
       AudioCharacter       SoundScene         AudioScore
              │                  │                  │
              └──────────────┬───┴──────────────────┘
                             │
                     SoundStudioController
                             │
                  ┌──────────┴──────────┐
                  │                     │
           ModulationMatrix       AudioPolicy
                  │                     │
                  └──────────┬──────────┘
                             │
                     CompiledAudioState
                             │
                    AudioEngine / Graph
                             │
       ┌─────────────────────┼─────────────────────┐
       │                     │                     │
 SourceFactory       Spatial/Temporal DSP    Feature extraction
       │                     │                     │
       └─────────────────────┴───────────┬─────────┘
                                         │
                                  master output
                                         │
                              visitor master volume
                                         │
                                persistent Stop gate
                                         │
                                     destination

The key principle is that live Web Audio state is a disposable projection of canonical authored state, never the source of truth. This follows directly from Web Audio's fire-and-forget scheduling and lack of serialization primitives.

Safety, intensity, and full-spectrum capability

The product should accept the user's stated product doctrine: comfort restrictions are optional; creative capability is not. But three concepts must be separated rigorously:

This distinction is crucial. The browser cannot know what acoustic sound-pressure level reaches a listener's ears because digital level is followed by operating-system volume, DAC gain, amplifiers and transducer sensitivity. NIOSH's hearing-exposure guidance is expressed in measured acoustic dBA—for example, its occupational recommended exposure limit is 85 dBA over eight hours with exposure duration halved for each additional 3 dB—and therefore cannot be inferred from a Web Audio sample value. The supplied browser-audio safety review reaches the same conclusion: dBFS is a digital quantity, not a guarantee of physical hearing safety.

Accordingly, the product should never call Expanded Range “safe” or “unsafe.” The copy should say approximately:

Expanded Range unlocks stronger bass, brighter spectra, higher resonance, deeper feedback, faster spatial motion, denser modulation and more extreme transformations. These settings can feel intense. Your device volume determines the physical listening level. Enter Expanded Range only when you deliberately want the broader range.

Enabling Expanded Range must not start playback, increase master volume, restore a previous running state, or move any parameter. It only widens what future user actions may select. That preserves both capability and visitor authority.

A true-peak/loudness meter is valuable diagnostic information. ITU-R BS.1770-5 is the current in-force ITU recommendation for program loudness and true-peak measurement. It should be offered as a meter and optional comfort tool, not represented as an SPL or medical-safety measurement.

Evidence synthesis

The research supports four evidence levels.

Very high-confidence platform facts. Web Audio provides graph-based synthesis, automation, spatialization, offline rendering and AudioWorklet custom processing; browser autoplay restrictions mean explicit user initiation is operationally robust; the API does not serialize its own graph.

High-confidence psychoacoustics. Perceived loudness depends strongly on frequency; ISO 226:2023 specifies normal equal-loudness contours for pure tones from 20 Hz through 12.5 kHz under defined listening conditions. This supports perceptual—not merely numerical—mapping of Weight, Brightness and low-frequency controls. The supplied bass and absorption studies correctly emphasize low-frequency sensitivity, masking, spectral balance and playback-system translation.

Useful creative evidence rather than universal laws. Moderate rhythmic complexity can be especially engaging: Witek et al. found an inverted-U relationship in which intermediate syncopation produced the highest pleasure and desire to move in their experiment. This justifies making rhythmic complexity a continuous scene dimension instead of equating “more complex” with “better.” The supplied rhythm research reaches the same product conclusion: alternate predictability and novelty rather than maximizing either.

Experimental claims should remain artistic options, not product promises. Binaural beats can be synthesized if desired, but claims that they reliably force a particular brain state are not justified: a 2023 systematic review found highly heterogeneous and inconsistent EEG entrainment results. Consequently Mesmerization should describe sounds in perceptual/artistic terms—immersive, pulsing, drifting, spatial, dense, calm, intense—not as guaranteed hypnosis, neurological entrainment or treatment. This is also the position of the supplied psychoacoustic synthesis.

Recommended product invariant: Mesmerization offers extraordinary auditory control; it never claims coercive or medically guaranteed effects.

Product requirements, information architecture, interaction design, accessibility, and mobile

The Studio should expose considerable depth without presenting every DSP variable at once. The supplied UX study's progressive-disclosure approach—Quick, Studio, Advanced and Diagnostics—is the right basis.

Information architecture

Both shells should render the same SoundStudioUI with context-sensitive additions.

Quick mode shows Transport, Discover and Character plus four or five scene-specific macros. Studio mode exposes Sources through Memory. Advanced mode adds the full Modulation Matrix, AudioScore editing, deterministic seed controls and engineering-grade parameter views. Diagnostics remains separate so ordinary use does not become visually noisy. This is an implementation refinement of the supplied UX architecture.

Transport semantics

Play and Stop are not project parameters.

Play means: “The visitor presently authorizes this page to produce sound.” It may initialize or resume an AudioContext, compile the current silent authored state, and then open the final output gate. Browser autoplay policy is another reason to tie this operation to a direct gesture, but the stronger Mesmerization rule is product-level: even if the browser would allow autoplay, Mesmerization does not autoplay.

Stop has stronger precedence than every other operation. It must:

desiredRunning = false          // synchronous authority latch
transportEpoch++                // invalidate pending Play/start work
stopGate = 0 at earliest audio time
cancel future source scheduling
stop/fade disposable voices as appropriate
optionally suspend context after graph becomes quiescent

The output gate must silence all returns and tails, including feedback and reverb. Stop is therefore downstream of the mix and effects graph.

The UI should distinguish:

• Stop: immediate audible cessation, no tails.
• Play: explicit start/resume.
• optional future Pause/Hold: preserve score position while silent.
• optional Panic need not be a separate concept if Stop already has the required hard authority.

Because already-buffered audio may exist between browser and hardware, a web application cannot promise literal zero physical latency. The implementation guarantee should instead be: Stop synchronously latches the stopped state and schedules the final gate to zero at the earliest available audio-render time; no stale asynchronous action is permitted to reopen it.

Public controls versus expert controls

The public control surface should manipulate semantic values in normalized domains, not raw unstable coefficients. That matches the uploaded modulation and morphing research, which advocates semantic mappings and canonical bounds rather than allowing UI components to manipulate implementation details directly.

For example:

Brightness 0…1
   ↓ AudioPolicy
oscillator spectral tilt
filter cutoff curve
upper-partial density
grain spectral weighting
reverb HF damping
sparkle probability

Expanded Range can widen those policy maps. It still does not expose invalid filter coefficients or memory addresses.

Accessibility specification

The target should be WCAG 2.2 AA, with the Studio designed from the start for keyboard and screen-reader operation. WCAG requires keyboard accessibility, and it specifically addresses audio control, dragging alternatives, control naming/state and minimum target sizing.

Every knob must have a semantic accessible value, direct keyboard editing and a non-drag alternative. The WAI-ARIA slider pattern defines Arrow keys for incremental changes and Home/End for boundaries. For complicated musical values, aria-valuetext should expose understandable strings such as “1/8 dotted,” “C2, 65.4 hertz,” or “Feedback 72 percent.”

The interaction contract should be:

No capability may exist only through rotary drag, XY drag or touch gesture. This is particularly important under WCAG 2.2's dragging requirement.

Meters should not produce continuous screen-reader announcements. Status announcements should be reserved for meaningful transitions such as “Sound stopped,” “Preset loaded silently,” “Quality reduced to Balanced,” or “Audio interrupted by the system.”

prefers-reduced-motion should also govern animated meters, rotating orbit illustrations and visualization-side feedback. It must not alter authored audio.

Mobile design

Mobile uses the same controller and state, not a simplified audio engine.

The recommended layout is a persistent two-row header:

[ Stop ] [ Play ]          [ Master volume ]
[ Scene ] [ Mutate ]       [ More… ]

Below it, one module is expanded at a time. Source strips become horizontal cards; the modulation matrix becomes a route list rather than a giant grid; AudioScore becomes a vertically scrollable cue sequence; diagnostics become a text-and-meter drawer.

Controls should be comfortably larger than WCAG's minimum target requirement, even though WCAG's normative minimum is less aggressive than a typical touch design target. Numeric entry must be available because precision dragging on a small touch display is poor.

The mobile implementation must also tolerate context interruption, background suspension and route changes without treating those events as permission to restart audio. A returning tab may restore authored UI state, but it may only emit sound if the visitor's current desiredRunning authority remains true and the browser allows the context to resume.

Canonical ownership, state model, and modular code architecture

The most important specification decision is who owns each kind of truth.

There should be four distinct state domains.

This separation is consistent with the uploaded preset research, which correctly excludes master volume, activation/consent and other operational state from generative preset mutation.

A canonical TypeScript contract should look approximately like this:

type SoundProject = {
  schemaVersion: number;
  projectId: string;
  metadata: ProjectMetadata;

  seed: Seed64;

  character: AudioCharacter;
  scene: SoundSceneInstance;

  sources: SourceConfiguration[];
  mixer: MixerState;
  rhythm: RhythmState;

  timbre: TimbreState;
  granular: GranularState;
  spatial: SpatialSoundState;
  temporal: TemporalAudioState;

  modulation: ModulationMatrixState;
  score: AudioScore;

  parameterLocks: ParameterLockState;

  // Artistic configuration only.
  // NEVER: running, masterVolume, consent, AudioContext state.
};

type VisitorAudioAuthority = {
  desiredRunning: boolean;       // always false on first page visit
  masterVolume: number;          // local visitor authority
  intensityProfile:
    | "standard"
    | "expanded";
  visualSyncEnabled: boolean;
  preferredQuality:
    | "auto"
    | "eco"
    | "balanced"
    | "high";
};

type AudioRuntimeState = {
  lifecycle:
    | "uninitialized"
    | "starting"
    | "running"
    | "stopping"
    | "stopped"
    | "interrupted"
    | "error";

  transportEpoch: number;
  projectRevision: number;
  graphRevision: number;
  effectiveQuality: QualityTier;
};

The corresponding ownership boundaries should be:

This is the cleanest synthesis of the requested ownership model and the supplied architectural studies.

State precedence

The exact precedence model should be explicit:

AUTHORED BASE
    ↓
scene expansion / AudioCharacter mappings
    ↓
AudioScore automation at time t
    ↓
ModulationMatrix dynamic offsets
    ↓
destination-specific AudioPolicy transfer functions
    ↓
quality-policy implementation choice
    ↓
live DSP graph
    ↓
optional comfort processing
    ↓
mandatory numerical-integrity sanitizer
    ↓
visitor master volume
    ↓
persistent Stop gate
    ↓
destination

Crucially:

AudioScore does not rewrite authored base values. It supplies time-indexed automation.

Modulation never overwrites a knob. The base parameter remains the user's authored value; disabling a route returns immediately to that base. The supplied modulation research calls this “Visitor Authority,” and it is the right semantic rule.

AudioWorkloadPolicy may change algorithms, never meaning. “Space 80%” should remain approximately the same perceived size if the governor changes from a twelve-line to an eight-line FDN.

Master volume applies after authored sound. No preset, score cue, mutation or import may modify it.

Stop applies last. Nothing upstream can circumvent it.

Preset, scene, score, project, and library semantics

These names should have non-overlapping meanings:

SoundPreset is a deterministic snapshot of a complete instantaneous sound configuration: Character, source topology/settings, mixer, rhythm configuration, timbre, granular, spatial, temporal, modulation and seed. It explicitly excludes running state, master volume, visitor consent and Visual Sync.

SoundScene is a reusable generative system: rules, permissible source families, macro mappings, parameter distributions, probability fields and default character. A scene can generate many presets.

AudioScore is the journey: sections, transitions, cues, parameter automation, preset/scene changes and morph instructions over time.

SoundProject contains the complete authored work: current sound, scene, score, custom presets/references and metadata.

Local Library contains durable projects, presets, scenes and optionally imported local audio assets.

This prevents the common failure mode where a “preset” ambiguously means patch, timeline, transport state and application state at once.

History and A/B

Undo/redo should operate on authored project commands only. A slider drag is coalesced into one history transaction. Play, Stop, browser interruptions, master volume, diagnostics and quality-governor changes never appear in history.

A/B slots hold immutable authored snapshots. Switching A/B while stopped is silent. While playing, compatible parameter states morph with destination-appropriate interpolation; topology changes crossfade between compiled graphs rather than trying to interpolate categorical structures.

Reusable single-flight operations

Every asynchronous browser operation should use a shared single-flight framework rather than ad hoc booleans:

interface SingleFlight {
  run<T>(
    key: string,
    policy: "join" | "newest-wins" | "preempt",
    task: (signal: AbortSignal, epoch: number) => Promise<T>
  ): Promise<T>;
}

Recommended semantics:

Every async continuation checks both its AbortSignal and relevant revision/epoch before committing. This is how a slow AudioContext.resume() or asset decode is prevented from resurrecting stale state after the user has pressed Stop.

DSP system, synthesis families, controls, modulation, presets, and sound scenes

Web Audio's native graph should be used where it is excellent; AudioWorklet should be used where custom stateful DSP or dense sample-level processing genuinely requires it. The platform already supplies highly optimized graph primitives, while AudioWorklet exists for custom synthesis and processing. A blanket “everything must be WASM immediately” rewrite would add migration risk without automatically improving sound. The supplied synthesis and granular studies correctly identify AudioWorklet/WASM as particularly valuable for dense granular processing and advanced custom kernels.

Recommended audio graph

Source Engine A ─┐
Source Engine B ─┼─► Source Strips ─► Mix Bus ─► Timbre Bus ──────────────┐
Source Engine C ─┘                                                        │
                                                                          │
                                  ┌► Temporal Send ─► Memory Return ───────┤
                                  │                                       │
Mix/Timbre ───────────────────────┼► Spatial Send ─► Space Return ────────┤
                                  │                                       │
                                  └► Special FX / Granular Return ─────────┤
                                                                          ▼
                                                                    Master Mix
                                                                          │
                                                               Optional Comfort DSP
                                                                          │
                                                               Integrity Sanitizer
                                                                          │
                                                               Visitor Master Gain
                                                                          │
                                                                    STOP GATE
                                                                          │
                                             ┌────────────────────────────┴───────┐
                                             ▼                                    ▼
                                        Destination                      AudioFeature tap

The Feature tap should default to the actually audible post-master/post-stop signal so visual intensity corresponds to what is reaching the browser output. A separate explicitly named semantic feature stream may carry beat phase, score progress, scene intensity or source events, but must never masquerade as measured audible energy.

Reusable source families

The architecture should not make “mode” equal to a giant conditional statement. Each source implements a common contract:

interface AudioSourceEngine {
  readonly family: SourceFamily;

  prepare(context: AudioBuildContext): Promise<void>;
  configure(state: CompiledSourceState): void;
  schedule(events: ReadonlyArray<AudioEvent>): void;
  connect(output: AudioNode): void;

  suspend(): void;
  dispose(): void;

  getDiagnostics(): SourceDiagnostics;
}

The initial portfolio should be:

The supplied synthesis research supports a hybrid rather than single-synthesis architecture because different families provide complementary temporal and spectral behavior. The granular research supports treating granulation as both a generator and an effect, implemented around one reusable kernel rather than duplicated systems.

Complete public control taxonomy

The following should become the stable public semantic API. Internals may change without breaking presets.

The full sonic parameter range should be sample-rate aware. High-frequency oscillators, filters and nonlinear processing must respect Nyquist and anti-aliasing requirements rather than presenting “full spectrum” as permission to generate mathematically invalid frequencies. The context sample rate sets the Nyquist boundary.

AudioCharacter

AudioCharacter should be semantic, normalized and engine-independent:

interface AudioCharacter {
  weight: number;       // low-frequency/body emphasis
  brightness: number;   // perceived spectral center
  harmonicity: number;  // harmonic ↔ inharmonic
  texture: number;      // smooth ↔ particulate/noisy
  density: number;      // sparse ↔ saturated
  transience: number;   // diffuse ↔ impulsive
  movement: number;     // static ↔ highly evolving
  air: number;          // upper spectral detail
}

Each source family implements its own mapping through AudioPolicy. A granular engine can translate texture into jitter and grain behavior while an additive engine translates it into partial irregularity. This preserves the same creative language across heterogeneous engines.

Bass and high-frequency design

Substantial bass capability belongs in Expanded Range, but bass design should rely on harmonics, phase discipline, controlled low-mid masking and device translation rather than simply adding enormous sub-band gain. The supplied bass study emphasizes the unequal perceptual sensitivity of low frequencies and the practical impossibility of expecting the same sub-bass reproduction from phones and subwoofers. ISO 226 likewise confirms that equal perceived loudness does not correspond to equal physical level across frequency.

Similarly, “Air” should preferentially add sparse, moving, low-level spectral detail rather than simply applying a huge high shelf. The supplied high-frequency study's strongest useful product insight is the preference for transient/sparse upper-band detail over persistent narrow resonances. Its more speculative physiological explanations should not be turned into product claims.

Rhythm engine

Pulse generation should combine deterministic clocked rhythm and free stochastic events:

master musical clock
 ├─ meter/subdivision
 ├─ Euclidean pulse generator
 ├─ probability mask
 ├─ swing/microtiming
 ├─ syncopation policy
 ├─ polymetric layer clocks
 └─ free Poisson/stochastic transient lane

The important creative control is a continuum between periodic anchor and uncertainty, not a binary “rhythm on/off.” The supplied rhythm study supports hierarchical macro/meso/micro timing and probabilistic deviation, while empirical groove research supports avoiding the assumption that maximal syncopation is inherently superior.

Spatial and infinite-depth behavior

SpatialSoundPolicy should begin with portable stereo semantics rather than requiring HRTF for every source.

A source's perceived depth should be synthesized from a coordinated mapping of:

distance
 → direct level
 → high-frequency attenuation
 → early-reflection timing
 → direct/reverberant ratio
 → width/decorrelation
 → optional micro-Doppler delay

Orbit should similarly combine position, width, microdelay, spectral changes and reverberant relationship. A naive left-right panner does not create convincing depth. The supplied spatial research supports coordinated temporal, spectral, direct/reverberant and decorrelation cues.

“Infinite depth” should therefore mean a perceptually cyclical receding architecture, not literally infinite distance. A source can gradually recede until it becomes mostly diffuse ambience, transform inside the memory network, and re-emerge as a new near-field object without an audible reset.

Temporal memory

The first production TemporalAudioPolicy should be simpler than the most ambitious research design:

stereo delay
→ damping filters
→ diffusion stages
→ stable feedback network
→ controlled nonlinear coloration

Later versions can graduate to modulated FDNs, granular feedback and freeze behavior. FDN mathematics provides a principled route to dense recursive ambience, while the supplied recursive-audio study explores unitary/unilossless network approaches and spectral transformation.

Memory = 100% must not simply map to an arbitrary scalar feedback coefficient of 1.0 in every topology. It should mean a policy-defined “near-freeze/freeze” mode whose internal algorithm is known to remain bounded.

Modulation architecture

The matrix should be reusable and destination-typed.

Sources: sine/triangle LFO, multi-stage envelope, random walk, smoothed random, sample-and-hold, coherent noise, step sequence, Euclidean trigger, rhythm phase, scene progress, score progress, envelope follower, selected spectral bands, and—only inside the Visualization shell—explicit visual sources.

Destinations: public semantic parameters first, expert DSP parameters second.

A route contract should be:

type ModRoute = {
  id: string;
  sourceId: ModSourceId;
  destinationId: ModDestinationId;

  amount: number;           // normalized signed depth
  polarity: "unipolar" | "bipolar";
  mode: "add" | "multiply" | "replace-offset";
  curve: TransferCurve;
  smoothingMs: number;
  evaluationRate: "control" | "audio";

  enabled: boolean;
};

The source dependency graph should be topologically sorted. Nested modulation is allowed. Unlike silently inserting feedback wherever a user creates a cycle, the production product should reject ordinary cycles and require an explicit advanced Delayed Feedback Route type whose delay semantics are visible. This is a deliberate refinement of the supplied modulation study, which explores automatic cycle-breaking with delays; explicitness is better for explainability, reproducibility and debugging.

Pitch and filter-frequency destinations should use perceptually appropriate nonlinear transfer functions; amplitude and probability routes need their own semantics. The modulation research correctly notes that generic linear mapping is inadequate across frequency, gain, delay and feedback parameters.

Preset and SoundScene taxonomy

Presets should be tagged independently along several axes rather than placed in one giant genre list:

Recommended flagship SoundScene families are Deep Drone, Tidal Atmosphere, Harmonic Orbit, Particle Field, Resonant Cavern, Pulse Loom, Granular Bloom, Infinite Memory, Metallic Constellation, and Quiet Void.

Randomization must operate through scene-aware probability distributions and correlation rules rather than uniformly randomizing raw DSP controls. Parameter locks remain immutable during mutation. The supplied preset research strongly supports deterministic seeds, constrained parameter distributions, semantic mutation and isolation of operational state from generative parameters.

Browser runtime, workload scaling, diagnostics, and optional Visual Sync

Web Audio lifecycle

Use one principal AudioContext per Sound Studio instance, with lifecycle owned exclusively by AudioEngine. Web Audio contexts represent system resources, while the project's authored state exists independently and can be prepared while sound is stopped.

The implementation must support this sequence:

page visit
  ↓
load authored project / preset / scene
  ↓
render fully interactive silent UI
  ↓
user presses Play
  ↓
single-flight backend initialization
  ↓
AudioContext resume/init
  ↓
build or update graph
  ↓
open final Stop gate

Importing a project follows the first half only. It does not call Play.

Render quantum assumptions

Do not write custom DSP with 128 hard-coded as the worklet callback length.

The currently published Web Audio 1.1 draft describes a default render quantum of 128 frames, while the September 2026 editor's draft is evolving render-size controls and variable supported quantum sizes. The editor's draft is explicitly work in progress.

Every AudioWorklet algorithm should therefore process:

const frames = outputs[0][0].length;

and use frames everywhere internally.

Native nodes, AudioWorklet, and WASM

Recommended implementation policy:

Native Web Audio for basic gain, simple filtering, mixing and other operations where browser implementations are already appropriate.

JavaScript AudioWorklet for moderately complex custom stateful processing and early prototypes.

WASM inside AudioWorklet for the high-density granular kernel, advanced FDN/feedback networks, anti-aliased nonlinear synthesis, spectral processing or other hot paths proven by profiling to justify it.

The supplied workload and granular research appropriately emphasizes preallocated worklet processing and avoiding rapid creation of hundreds of short-lived JS graph objects for grain clouds.

All real-time kernels should avoid allocations in their render loops, preallocate scratch buffers and use bounded voice pools.

Quality tiers

AudioWorkloadPolicy should expose four user concepts:

The same project semantics must survive every tier.

Example degradation table:

The supplied workload study is particularly strong on this point: degradation should preserve perceived semantic intent—size, movement, texture—not simply mute effects or shorten them.

Governor

Auto mode must not fingerprint the device or run hardware benchmarks. It should react only to conditions arising during the current audio session.

Inputs may include:

worklet queue/backpressure
local DSP deadline estimate
graph/source/grain counts
browser-reported context latency where useful
actual underrun statistics if available
recent context interruption/error

The September 2026 Web Audio editor's draft includes AudioContext.playbackStats, but because that document is explicitly an editor's draft, Mesmerization must feature-detect it rather than depend on it.

Likewise, avoid requesting "hardware" render sizing merely to probe a device. The current editor's draft itself notes a fingerprinting risk because hardware render quantum information can expose characteristics of the audio system.

A sensible governor policy is:

incident detected
   → immediately reduce one expensive dimension
   → crossfade algorithm implementation
   → hold tier for stability interval
   → downgrade again if incidents continue

long stable interval
   → consider one-tier upgrade
   → never oscillate tiers rapidly

The governor should degrade quickly and upgrade slowly.

Diagnostics

AudioDiagnostics is a local profiler, not telemetry.

Display:

• AudioContext state and sample rate;
• base/output latency when exposed;
• engine/backend build;
• active source, voice and grain counts;
• graph revision/project revision;
• effective quality tier and reason;
• modulation route counts by rate;
• output sample peak, estimated true peak and loudness;
• DC estimate and phase/correlation metrics where appropriate;
• memory/feedback network state;
• underruns where a trustworthy API exists;
• latest error/interruption receipt.

Do not call an inferred number “CPU %” unless it truly represents CPU utilization. “DSP deadline utilization estimate” is more honest when derived from processing timing.

Nothing is transmitted.

AudioFeatureBus and Visual Sync

The standalone product must import zero WebGL/WebGPU code. That should be enforced at package boundaries and bundle tests, not merely by convention.

The shared audio core exports:

interface AudioFeatureFrame {
  audioTime: number;

  rms: number;
  peak: number;

  low: number;
  lowMid: number;
  mid: number;
  highMid: number;
  high: number;

  spectralCentroid: number;
  onset: number;

  pulsePhase?: number;
  scoreProgress?: number;
}

The Visualization Studio may subscribe only when Visual Sync is enabled. The supplied synchronization research correctly proposes a unidirectional feature bus that prevents the renderer from inspecting audio nodes directly.

For ordinary operation:

Audio DSP ──► AudioFeatureBus ──► VisualSyncAdapter ──► visual renderer

There is no reverse dependency.

If visual-to-audio modulation is offered, it should be architecturally separate:

visual renderer
    ↓ explicit opt-in mapping
ExternalVisualModulationAdapter
    ↓ normalized named sources
ModulationMatrix

No mapping exists merely because the panel is embedded. A project that depends on visual.particleVelocity should retain that route as dormant when opened in standalone Sound Studio and clearly report “External visual source unavailable.”

For high-frequency feature exchange, SharedArrayBuffer can be an optimization under appropriate cross-origin isolation; it must not be required for basic studio operation. A lower-rate MessagePort fallback is sufficient for UI meters and most visual sync. This is more deployable than making cross-origin isolation a mandatory prerequisite for sound. The supplied synchronization study's lock-free bus model is appropriate as an optimization.

Persistence, sharing, deterministic rendering, testing, privacy, and security

Storage model

Use IndexedDB for durable local Studio content:

projects
presets
scenes
assets
assetMetadata
schemaMigrations

Use small browser preference storage only for visitor-local preferences such as preferred quality, most recent UI mode and—in accordance with product policy—whether Expanded Range acknowledgement should be remembered.

Do not store desiredRunning=true as a state that causes future playback.

After every page construction:

desiredRunning = false
stopGate = 0

This is true even if the previous session ended while playing.

Import and export contract

The canonical package should be versioned:

{
  "format": "mesmerization.sound-project",
  "schemaVersion": 1,
  "engineCompatibility": {
    "minimum": "26.0"
  },
  "project": {},
  "assetManifest": []
}

Imports are untrusted data. Validation occurs before project commitment:

parse
→ top-level format check
→ schema version/migration
→ structural validation
→ parameter/domain validation
→ route-count/array-size bounds
→ asset type/size validation
→ seed normalization
→ dangling reference validation
→ create new authored candidate
→ commit as one undoable transaction

Critically:

imported.running = ignored;
imported.masterVolume = ignored;
imported.visualSyncConsent = ignored;
imported.intensityConsent = ignored;

Even if malicious data contains such keys, they do nothing.

Sharing

A shareable project contains authored sound state only. Visitor authority is stripped at serialization time rather than merely ignored at deserialization time.

For large user-imported samples, exports can package content-addressed assets in a future .mesmer-sound archive. Share URLs should remain configuration-oriented rather than embedding megabytes of PCM.

No microphone permission is necessary. User-provided sample files, if supported, are explicit local file imports, not live capture.

Deterministic randomization

All generative randomness must derive from a stable integer PRNG with independently derived streams:

project seed
 ├─ scene stream
 ├─ rhythm stream
 ├─ source A stream
 ├─ source B stream
 ├─ grain stream
 ├─ spatial stream
 └─ mutation stream

Adding a granular emitter later must not unexpectedly advance the rhythm random stream. Stream derivation from named domain IDs prevents that class of determinism bug. The supplied synthesis and preset studies both emphasize seeded, independent deterministic generation rather than Math.random()-style ambient state.

Mutation must also record its resulting seed/revision, so Undo restores both parameter state and future random sequence.

Determinism levels

“Deterministic” should be specified precisely:

That last distinction matters. OfflineAudioContext can render a graph faster than real time, but browser-native DSP implementation details are not a cross-browser bit-exact interchange format. The specification even leaves some interpolation behavior to the user agent.

AudioReferenceRenderer

The reference renderer should therefore invoke the same deterministic custom DSP kernels used by the production worklets, outside the live AudioContext, with fixed parameters:

sample rate: 48,000 Hz
channels: stereo
reference block size: fixed
seed: explicit
floating-point behavior: defined
engine version: explicit
assets: hash-addressed

Native Web Audio offline rendering remains useful for browser integration tests, but golden sample hashes should come from the controlled reference engine.

Reference fixtures should test:

• exact PRNG/event sequence;
• oscillator phase continuity;
• deterministic envelope timing;
• no NaN/Infinity;
• DC behavior;
• feedback decay/freeze invariants;
• known filter impulse responses;
• limiter/integrity behavior;
• mono sum behavior;
• Stop output;
• scene mutation;
• grain scheduling;
• preset round trips;
• score timing.

Browser test matrix

The acceptance suite should cover capability families rather than hard-code current browser version assumptions:

The Web Audio Working Group maintains a Web Platform Tests implementation suite, reinforcing the need to test behavior across engines rather than assuming one browser's implementation defines the platform.

Critical automated browser cases include:

visit → silence
import → silence
load preset → silence
undo import → silence
Play → audible
Stop during pending Play → remains silent
Stop during project import → remains silent
two rapid presets → newest wins
rapid Play/Stop/Play → final visitor intent wins
tab background/restore → no unauthorized restart
Visual Sync off → no visual subscription
standalone bundle → no WebGL/WebGPU imports

Physical listening tests

Automated metrics cannot substitute for reproduction testing. ISO 226's equal-loudness work itself is defined in physical SPL under controlled acoustic conditions, and NIOSH exposure recommendations are likewise based on measured acoustic level rather than digital full scale.

Every flagship scene and quality tier should therefore be auditioned on:

For calibrated exposure studies, use an actual acoustic measurement chain rather than trying to infer SPL from Web Audio values.

Testers should score perceived brightness, bass dominance, harshness, density, depth, motion comfort, repetitiveness and musical coherence at multiple externally controlled listening levels. The objective is not to remove intense sounds; it is to understand them.

Security and privacy

The Sound Studio requires:

• no microphone permission;
• no camera;
• no geolocation;
• no device enumeration;
• no audio-hardware fingerprint;
• no hardware benchmarking for tier selection;
• no project/audio telemetry;
• no hidden analytics containing preset, score or parameter content;
• strict imported-data validation;
• bounded decode/file sizes;
• no remote execution or executable project extensions.

The current Web Audio editor's draft explicitly discusses fingerprinting risks from latency and hardware render quantum information, strengthening the case for not using those values as a fingerprint or persistent identifier.

Diagnostics remain on-device and disappear when the session ends unless the visitor explicitly exports a diagnostic receipt.

Migration strategy, delivery roadmap, and release acceptance

Because the repository itself was not supplied, this migration plan is intentionally contract-level rather than file-by-file. It should be implemented as a strangler migration: establish the canonical interfaces around the current audio implementation, then replace internals without forcing a simultaneous rewrite of Visualization Studio.

Migration sequence

The first change should not alter the audible result at all.

Foundation migration. Introduce SoundStudioController, AudioEngine, AudioGraph and the three-state separation—authored, visitor authority, runtime—around the existing sound implementation. All visualization code that currently talks directly to audio nodes should be routed through a temporary compatibility adapter. This is the highest-value architectural change because subsequent DSP replacement can occur behind a stable API. The supplied UI and audiovisual-decoupling research both support this boundary-first migration.

Transport migration. Install final master gain and Stop gate, single-flight lifecycle, transport epochs and “import never plays” invariants before adding new synthesis.

Canonical controls. Define normalized semantic schemas and AudioPolicy. Map the current visual/audio public controls into those schemas without changing their visible behavior.

Graph modernization. Introduce reusable mix buses, source strips, temporal send/return, spatial send/return and diagnostic taps.

Source extraction. Move each existing synthesis path behind AudioSourceFactory one family at a time. Nothing outside the factory is allowed to instantiate source-specific nodes once migration is complete.

DSP upgrades. Improve oscillators, noise, filtering, gain staging, delay, reverb and spatial processing first; add granular/worklet-heavy features after the base graph is stable.

State tools. Add deterministic presets, seed, parameter locks, history, A/B and library.

Second shell. Mount exactly the same SoundStudioUI and controller beneath /sound. A build-time dependency test should fail if standalone imports visualization packages.

Visualization adapter. Finally replace the temporary visualization coupling with AudioFeatureBus and explicit visual modulation adapters.

Architectural acceptance gates

A release cannot be considered migrated until all of these are true:

Release implementation plan

The greatest risk would be trying to ship granular synthesis, advanced FDN feedback, AudioScore, a giant modulation matrix, new spatial DSP, visualization synchronization and a new standalone interface simultaneously. The highest-return sequence is instead architecture first, signal quality second, breadth third.

V26: shared core and major sound-quality leap

V26 should be the unification and fidelity release.

Its overriding objective is to establish the permanent ownership model while substantially improving the sound using technologies that do not require destabilizing the visualization renderer.

First milestone — transport and canonical core. Implement:

SoundProject schema
VisitorAudioAuthority
SoundStudioController
AudioEngine
AudioGraph
AudioPolicy
single-flight operation framework
persistent Stop gate
master visitor gain
graph/runtime diagnostics

Do this before a single ambitious new effect. The success criterion is that existing Visualization Studio sound can be routed through the new core with virtually no intended audible change.

Second milestone — graph and gain staging. Establish proper source strips and dry/temporal/spatial buses. Centralized gain architecture is foundational because every later engine—granular, recursive memory, resonator, FM—depends on predictable headroom. The bass and digital-safety studies both emphasize that uncontrolled generative summation is a fundamental problem.

Third milestone — source-quality foundation. Ship the first reusable synthesis portfolio:

• harmonic/drone;
• noise/atmosphere;
• FM/PM/ring;
• modal/resonator;
• procedural pulse/percussion.

These provide a far larger sonic vocabulary without yet introducing the most expensive workloads. The synthesis research supports these families as complementary foundations for long-form evolution.

Fourth milestone — semantic sound shaping. Implement AudioCharacter, filter/timbre policy and deterministic slow modulation. This is likely to produce a greater perceived improvement than exposing dozens of raw knobs because it makes every source capable of coherent long-form evolution. The supplied timbral-morphing study specifically supports slow spectral movement and engine-independent perceptual dimensions.

Fifth milestone — production Space and Memory. Ship a strong stereo spatial layer, multi-stage delay/diffusion and an efficient initial FDN-based ambience. Keep the first recursion implementation deliberately contained; advanced granular feedback and near-lossless freeze can follow later.

Sixth milestone — deterministic creative workflow. Ship:

SoundPreset
seed
Randomize
Slight Variation
Deep Variation
parameter locks
A/B
undo/redo
local preset library

This converts the engine from a sound demo into an instrument.

Seventh milestone — standalone shell. Launch /sound as the canonical public route, optionally redirecting /sound-studio to it. The same SoundStudioUI should continue to appear inside Visualization Studio.

V26 should deliberately not make visual behavior dependent on new sound features. Visualization Studio sees the new system through a compatibility boundary, which dramatically reduces regression risk.

The recommended V26 priority order is therefore:

shared lifecycle/state
      ↓
gain staging and graph
      ↓
source fidelity
      ↓
AudioCharacter / timbral movement
      ↓
Space + Memory
      ↓
presets/mutation/history
      ↓
standalone shell

That sequence delivers the largest improvement in both sound quality and studio usefulness for the lowest risk to existing visualization.

V27: deep generative studio

V27 should build the advanced instrument on the now-stable foundation.

Its centerpiece should be the granular worklet engine, serving both source and effect roles through one reusable kernel. The supplied granular research makes a strong engineering case for a pooled AudioWorklet implementation for dense grain clouds rather than spawning browser nodes for every grain.

Next should come the complete ModulationMatrix: coherent noise, random walks, MSEGs, step modulators, Euclidean triggers, score progress, audio followers, nested acyclic routes and explicit delayed recursive modulation.

Then add AudioScore as a first-class journey system rather than a conventional DAW timeline: sections, long-duration macro arcs, scene changes, cue-based preset transitions, automation and deterministic probabilistic events.

V27 should then expand the spatial and temporal systems into the genuinely distinctive Mesmerization capability:

perceptual infinite-depth cycles
multi-layer orbit
advanced FDN diffusion
frequency-selective memory
near-freeze
granular feedback
pitch-transforming echoes
scene-scale morphs

These capabilities should remain semantically governed by SpatialSoundPolicy and TemporalAudioPolicy, not appear as one-off preset hacks.

The AudioWorkloadPolicy governor should arrive once these expensive engines exist in production. Auto mode then has meaningful dimensions to trade—grain population, FDN complexity, oversampling, analyzer resolution and modulation rate—rather than attempting to optimize prematurely.

V27 is also the appropriate release for the permanent AudioFeatureBus and optional Visual Sync integration. By waiting until the shared audio engine has already shipped independently, the synchronization bridge remains demonstrably optional instead of becoming hidden architectural coupling.

Finally V27 should complete project portability with full project library, versioned import/export, asset packaging and reference-render CI.

The target end-state is therefore:

                    MESMERIZATION SOUND CORE
                              │
        ┌─────────────────────┴─────────────────────┐
        │                                           │
   /sound shell                          Visualization Studio shell
        │                                           │
        │                                optional VisualSyncAdapter
        │                                           │
        └─────────────────────┬─────────────────────┘
                              │
                     SoundStudioController
                              │
              canonical authored SoundProject
                              │
      ┌──────────────┬────────┼──────────┬──────────────┐
      │              │        │          │              │
 AudioCharacter   Scene    Score    Preset/History   Library
      │              │        │          │              │
      └──────────────┴────────┴──────────┴──────────────┘
                              │
                         AudioPolicy
                              │
                       ModulationMatrix
                              │
                         AudioEngine
                              │
                          AudioGraph
                              │
         ┌────────────┬───────┼───────┬─────────────┐
         │            │       │       │             │
      Sources       Pulse   Timbre  Granular   Space/Memory
         └────────────┴───────┴───────┴─────────────┘
                              │
                   optional Comfort Profile
                              │
                     DSP Integrity Layer
                              │
                    Visitor Master Volume
                              │
                     Persistent Stop Gate
                              │
                         audio output
                              │
                 optional downstream features
                              │
                       AudioFeatureBus

That structure resolves the most important product tensions at once: maximum creative range without conflating creativity with numerical instability; explicit opt-in without crippling the advanced instrument; authored sound that can exist silently; one audio implementation across both products; deterministic portable projects without importing operational authority; optional audiovisual synchronization without WebGL dependency; and a migration path that improves the audio substantially before it asks the existing visualization experience to change.