Задача: Исследовать временную причинность VoiceControlState → DSP → акустические признаки

Цель

Исследовать не мгновенное соответствие вида parameter[t] -> sample[t], а временную причинность в цепочке:

VoiceControlState(t) -> внутреннее DSP-состояние -> PCM -> акустические признаки на временном окне.

Нужно понять, какой управляющий параметр на что реально влияет, через какое время это влияние проявляется, как долго сохраняется и какие наблюдаемые признаки позволяют его восстановить.

Это необходимо для корректного обратного декодирования Sound -> VoiceScenario.

---

Контекст и проблема

Текущий VoiceScenario задаёт управляющие параметры, но выходной PCM формируется динамической системой с внутренним состоянием:

• voicePhase;
• resonator1.low, resonator1.band;
• resonator2.low, resonator2.band;
• resonator3.low, resonator3.band;
• состоянием PRNG;
• активными automation.

Поэтому даже постоянные управляющие параметры дают сложный, высокочастотный waveform.

Примеры:

• постоянный f0Hz не означает постоянный waveform — он задаёт скорость вращения voicePhase;
• постоянный noiseLevel управляет амплитудой случайного источника, который меняется каждый sample;
• постоянные resonance* управляют stateful-фильтрами, внутреннее состояние которых меняется каждый sample;
• наблюдаемые признаки (RMS, spectralFlatness, dominantFrequency и т.д.) зависят сразу от нескольких управляющих параметров и истории DSP.

Следовательно, прямые эвристики типа:

RMS -> sourceLevel

dominantFrequency -> f0Hz

не являются корректной моделью обратного преобразования.

---

Основная гипотеза

Для речи и данного синтезатора нужно анализировать не отдельный sample и не отдельный лог-фрейм, а временное окно.

Вместо:

parameter[t] -> sample[t]

исследовать:

parameter trajectory[t0:t1] -> audio response[t0:t1+Δ]

где Δ — возможный лаг реакции и/или время затухания внутреннего DSP-состояния.

Рабочие масштабы окон для проверки:

• 5 ms;
• 10 ms;
• 20 ms;
• 30 ms;
• 50 ms;
• при необходимости 100 ms.

Для каждого параметра нужно определить, на каком масштабе времени его влияние наблюдается наиболее устойчиво.

---

Что исследовать для каждого VoiceControlState-параметра

Минимально:

• sourceLevel
• periodicity
• noiseLevel
• f0Hz
• glottalOpenPhase
• glottalReturnPhase
• resonance1Freq
• resonance1Bandwidth
• resonance1Gain
• resonance2Freq
• resonance2Bandwidth
• resonance2Gain
• resonance3Freq
• resonance3Bandwidth
• resonance3Gain
• outputLevel

Для каждого параметра определить:

1. Чувствительность — насколько сильно его изменение влияет на PCM и признаки.
2. Лаг — через сколько времени после изменения control это влияние становится наблюдаемым.
3. Время затухания — сколько сохраняется эффект после изменения параметра.
4. Локальность — влияет ли параметр в основном на конкретный диапазон спектра/временную характеристику или глобально.
5. Однозначность — можно ли по наблюдаемому эффекту отличить изменение этого параметра от изменения другого.
6. Взаимодействия — какие пары параметров дают неаддитивный эффект.

---

Эксперимент 1: одиночный parameter sweep

Для каждого параметра:

1. Зафиксировать все остальные параметры в одном baseline-состоянии.
2. Изменять только исследуемый параметр по сетке значений.
3. Для каждого значения синтезировать одинаковый по длительности PCM.
4. Собирать одновременно:
   • полный VoiceControlState(t);
   • внутренний DSP trace;
   • PCM;
   • акустические признаки по окнам.
5. Сравнивать результат с baseline.

Пример для f0Hz:

• 80 Hz
• 100 Hz
• 120 Hz
• 150 Hz
• 180 Hz
• 220 Hz
• 300 Hz

Пример для resonance1Freq:

• фиксировать source и остальные резонаторы;
• двигать только resonance1Freq;
• смотреть, какой спектральный пик реально перемещается и как.

---

Эксперимент 2: ступенчатое изменение во времени

Проверить динамический отклик системы.

Пример:

t < 100 ms: resonance1Freq = 600

t >= 100 ms: resonance1Freq = 800

Анализировать окна:

• 60–80 ms
• 80–100 ms
• 100–120 ms
• 120–140 ms
• 140–160 ms
• 160–200 ms

Цель:

• определить момент начала наблюдаемого изменения;
• измерить лаг;
• понять форму переходного процесса;
• измерить время стабилизации.

Повторить для остальных параметров.

---

Эксперимент 3: импульсное/кратковременное возмущение

Для stateful-параметров особенно важно измерить память системы.

Схема:

baseline -> parameter + δ на короткий интервал -> baseline

Например:

• 100 ms baseline;
• 10–20 ms изменение;
• возврат к baseline;
• наблюдение ещё 100–200 ms.

Измерить:

• насколько быстро появляется эффект;
• сохраняется ли он после возврата параметра;
• сколько времени DSP возвращается к исходному состоянию.

Для резонаторов это должно показать реальную длительность памяти low/band состояний.

---

Эксперимент 4: пары параметров

После одиночных sweep проверить взаимодействия минимум для наиболее связанных пар:

• sourceLevel × outputLevel
• periodicity × noiseLevel
• f0Hz × glottalOpenPhase
• f0Hz × glottalReturnPhase
• resonanceFreq × resonanceGain
• resonanceFreq × resonanceBandwidth
• sourceLevel × resonanceGain

Цель — понять, можно ли считать эффекты параметров независимыми или их нужно восстанавливать совместно.

---

Какие данные логировать

Управляющий уровень

• все значения VoiceControlState(t);
• активные automation;
• момент каждой команды set / animate.

Внутренний DSP trace

Минимально:

• voicePhase;
• periodicSource;
• noiseSource;
• excitation;
• resonator1.low / resonator1.band;
• resonator2.low / resonator2.band;
• resonator3.low / resonator3.band;
• отдельный выход каждого резонатора до суммирования;
• value до clamp;
• value после clamp.

Акустические признаки по окнам

Минимально:

• RMS / energy;
• zero crossing rate;
• autocorrelation;
• pitch estimate;
• periodicity estimate;
• spectral centroid;
• spectral flatness;
• спектральные пики;
• энергия по диапазонам;
• формантоподобные пики / спектральная огибающая;
• при необходимости LPC.

Важно: dominantFrequency рассматривать только как один из спектральных признаков, а не как прямой f0Hz.

---

Временные окна и частота логирования

Нужно отдельно проверить влияние throttling.

Текущий лог может скрывать значимую временную структуру. Поэтому для исследования желательно иметь максимально частый внутренний trace, а затем уже программно агрегировать его в окна.

Рекомендуемый подход:

• DSP trace — максимально близко к sample-level либо с контролируемым decimation;
• акустические признаки — вычислять по окнам 5/10/20/30/50 ms;
• overlap окон: 50–75% для плавного временного анализа;
• не смешивать частоту сбора данных и размер аналитического окна.

---

Что должно получиться

Построить экспериментальную карту:

VoiceControl parameter -> observable consequences

Для каждого параметра зафиксировать:

• какие признаки реагируют;
• направление реакции;
• масштаб реакции;
• лаг;
• длительность памяти;
• зависимость от других параметров;
• насколько параметр восстанавливаем из аудио.

Желательно оформить это в таблицу вида:

Control	Наблюдаемые признаки	Лаг	Окно	Однозначность	Комментарий
f0Hz	autocorrelation peak, harmonic spacing	...	...	высокая/средняя/...	...
resonance1Freq	spectral envelope / peak shift	...	...	...	...
...	...	...	...	...	...

---

Критерий результата

После исследования должно стать понятно:

1. Какие параметры VoiceControlState можно восстанавливать непосредственно из аудио.
2. Какие можно восстанавливать только совместно с другими параметрами.
3. Какие параметры текущим набором признаков вообще не наблюдаются.
4. Какие дополнительные признаки нужно добавить в логгер.
5. Какой временной контекст нужен decoder'у для каждого класса параметров.
6. Можно ли строить decoder как аналитическое/эвристическое преобразование или нужен оптимизационный/обучаемый подход.

Главный результат — не просто новый decoder, а физически и экспериментально подтверждённая модель соответствия между управляющим пространством синтезатора и наблюдаемым звуком во времени.