## Goal

Create a new visual interface not for cosmetic editing of an existing `VoiceScenario`, but as an **experimental speech synthesis laboratory**.

The main objective of the interface is to allow manual exploration of:

- which synthesizer parameters;
- in what sequence;
- at what moments in time;
- with what values and laws of change

produce a particular audible result.

We do NOT assume in advance that we know the correct scenario for a specific sound. The interface is specifically designed for exploration: the user moves time points and parameters, listens to the result, and can then save the discovered interesting sounds and export them along with logs/scenarios for subsequent analysis.

---

## General Interface Model

The interface should be organized as a multitrack timeline, logically similar at the same time to:

- automation lanes in a DAW;
- a keyframe editor;
- a Gantt chart, but only in terms of a shared timeline and event synchronization.

This is NOT a classic Gantt chart nor a list of `set/animate` commands.

### Coordinates

For each track:

- horizontal axis = time;
- vertical axis = parameter value;
- a parameter is defined by a set of editable points `(time, value)`;
- a point can be dragged horizontally to change the moment of the event;
- a point can be dragged vertically to change the value;
- the transition law between points is defined.

The UI may normalize the vertical scale to `0..1`, but the physical parameter value must retain its own range and units (`Hz`, gain, etc.).

---

## Separate Overall Sound Duration

An independent **overall scenario duration** parameter is required.

This is crucial: control parameters can be set or changed only at the beginning, but the resulting state must continue to sound for a long time.

Examples of the semantic model:

- quickly set a state and hold a long `AAAAA`;
- early events form `MA`, and then the state holds `AAAAAAA` for a long time;
- after the last keyframe point, the value of each control continues to be held until the total duration of the scenario.

The duration should not be automatically truncated at the last control point.

---

## Cyclic Playback

A **"Loop"** toggle must be provided.

In loop mode:

- the scenario plays again immediately after finishing;
- the user does not need to press Play every time;
- parameter/point changes must take effect in the next playback cycle;
- the user can move a point or value and hear several variant results over several consecutive repetitions.

This is a key mode specifically for manual sound discovery.

---

## Parameter Tracks

At the first stage, the editor should work with all existing `VoiceControlState` parameters.

For each track, you need to see:

- control name;
- its physical value;
- normalized position on the vertical scale;
- keyframe points;
- value holding between events;
- transition shape between points.

The editor should show the actual temporal trajectory of the parameter, not just active `animate` segments.

---

## Types of Transitions and Modulators

The architecture should be designed from the start so that more than just a single `animate` type exists between points.

An extensible model of a **time interval converter/modulator** is needed.

At a minimum, provide the ability to have different types in the future:

- hold / constant value;
- linear transition;
- bezier transition;
- periodic modulator;
- sinusoidal modulation by formula;
- impulse / burst;
- repeating beat;
- noise or other stochastic modulation;
- other time functions.

That is, in the future, not only a keyframe should be placed on the timeline, but also a **converter** that forms a complex parameter trajectory over a given interval.

Example meaning: a parameter can have a stable base, but on top of it, periodic modulation works over a time interval.

---

## Connection to Speech Physiology

The editor architecture cannot be designed as if each control is completely physically independent.

A human has a single speech apparatus:

- one tongue;
- one lip configuration;
- one mouth/oral cavity;
- one vocal tract;
- one vocal cord and airflow system.

You cannot simultaneously set mutually exclusive articulatory states as if two independent languages or two independent mouth shapes exist.

While the current DSP operates in the acoustic space (`f0`, periodicity, noise, resonances, gains, etc.), the editor must be designed so that in the future it is possible to introduce **coupled physiological/articulatory converters** that control multiple DSP controls coherently.

Examples of semantic converters that may appear later:

- mouth opening/closing;
- change in tongue position;
- pressure accumulation and release;
- short plosive burst;
- steady airflow;
- articulator tremor/beat for `R`;
- transition between articulatory states.

Important: this is not a requirement to immediately implement a full physiological model. The requirement is **not to block such a possibility with the architecture**.

---

## Special Meaning of Temporal Structure

The editor must proceed from the premise that sound only makes sense in time.

For example, a plosive consonant is not a single parameter value, but a sequence of phases:

- preparation/closure;
- accumulation;
- release;
- burst;
- noise or vocal tail;
- transition to the next sound.

And a sustained sound can be the result of a stable state that is held for a long time after a short input transition.

Therefore, the user must see and edit the **composition of phases over time**, rather than just a list of numbers.

---

## What to Save

A discovered experiment must be reproducible.

You need to be able to save:

- total duration;
- all tracks and keyframes;
- transition/converter types;
- their parameters;
- the final `VoiceScenario` or compilable representation;
- experiment metadata if necessary.

The existing `VoiceScenario` can be used as a runtime/execution format, but the UI should not be limited by its current command-centric form. A separate experimental/keyframe format that compiles into a runtime representation is acceptable.

---

## Connection to Existing Runtime

The editor must use the same shared `VoiceScenario` runtime used by the synthesizer and visualizer, after appropriate refactoring.

You cannot have separate parameter execution semantics only inside the UI.

The actual sound and actually displayed trajectories must come from a single state machine.

---

## What is NOT the Goal of the First Stage

Currently, it is not required to:

- automatically guess the correct sound;
- automatically construct a phoneme;
- add new acoustic metrics just for visualization;
- immediately build a full physiological model of the speech apparatus;
- replace the decoder.

The primary applied goal is **to maximize the simplification of manual experimentation**:

1. quickly place time points;
2. change values;
3. hear the result in a loop;
4. understand the sequence of one's own actions;
5. save successful options;
6. export the found scenario and its logs for further analysis.

---

## Result Criterion

The user can open the laboratory, set the total duration, enable `Loop`, place and move keyframe points of several parameters along a shared timeline, and continuously hear how changes affect the sound.

The interface should help specifically in **searching for pre-unknown sounds**, rather than requiring prior understanding of what JSON needs to be written.

An interactive multitrack editor for manual experimentation with synthesizer parameters over time, cyclic listening, and discovering interesting sounds.

Create VoiceSynthesizer Temporal Scenario Visual Laboratory

![](</images/resized/middle/cmkppub1z0002mu0z427kxsay/1789428405800-Screenshot From 2026-09-15 02-21-05.png>)

Worklog for task "Create VoiceSynthesizer Temporal Scenario Visual Laboratory"

Task: Create VoiceSynthesizer Temporal Scenario Visual Laboratory