Задача: Создать визуальную лабораторию временных сценариев VoiceSynthesizer

Подробный прогресс по визуальной лаборатории временных сценариев

Что уже реализовано

Создан отдельный новый экспериментальный синтезатор и визуальный редактор, намеренно не связанный с прежним VoiceSynthesizer и его накопившейся сложной DSP-моделью.

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

Текущая структура включает:

• многодорожечный редактор временных параметров;
• keyframe-точки на общей временной шкале;
• drag-and-drop по времени и по значению;
• Play / Pause / Stop;
• режим Loop;
• независимую общую длительность сценария;
• seek по timeline;
• отображение текущих значений параметров;
• типы переходов hold, linear, bezier, sine, burst, noise;
• отдельный новый аудиосинтез на Web Audio API;
• минимальную акустическую модель на базе sawtooth + noise + formant filters + gain.

В UI сейчас представлены основные экспериментальные дорожки:

• F0 / Pitch;
• Periodicity;
• Noise;
• Formant 1;
• Formant 2;
• Formant 3;
• Gain.

Интерфейс визуально получился удачным как лабораторный инструмент: временная ось читается, события видны, параметры можно быстро менять, а общая длительность не привязана к последней точке. Это позволяет строить длинные удерживаемые звуки и последовательности состояний.

Важное уточнение постановки

Новый редактор НЕ должен сейчас быть интерфейсом к старому DSP.

Он задуман как независимый чистый эксперимент:

простые источники + простые фильтры + временные траектории -> слышимый результат.

Основной исследовательский вопрос:

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

То есть текущая задача — не воспроизводимость старых VoiceScenario, а поиск самой минимальной работающей акустической модели.

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

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

Поэтому чистый стенд нужен как контролируемая среда, где каждый новый механизм добавляется осознанно и его эффект можно услышать отдельно.

Принцип дальнейшей работы:

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

Что показала первая практическая проверка

По словам разработавшего агента набор возможностей выглядит завершённым, но фактическая проверка результата показала, что отчёт был слишком оптимистичным.

На текущем этапе:

• большинство подготовленных звуков/пресетов практически не слышны или не дают ожидаемого результата;
• отчёт агента сам по себе нельзя считать доказательством работоспособности;
• из простых узнаваемых эффектов пока фактически слышен в основном шипящий звук, близкий к С;
• полноценные А, М, Р, Т и другие звуки ещё не получены вручную и не подтверждены слухом.

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

Текущая практическая ценность лаборатории

Практическая ценность редактора пока не доказана окончательно.

Сейчас проверяется более базовая вещь:

1. Есть ли слышимая причинная связь между конкретным параметром и результатом.
2. Можно ли двигая одну или несколько точек вручную получать предсказуемо меняющееся звучание.
3. Можно ли найти устойчивые акустические классы:
   • гласноподобный;
   • шумовой/фрикативный;
   • взрывной;
   • носовой;
   • периодический/дрожащий;
   • другие речеподобные классы.
4. Можно ли сохранить найденную конфигурацию как воспроизводимый рецепт.

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

Важный концептуальный вывод

Не нужно заранее строить сложную физиологическую модель речи.

Правильнее сначала искать минимальные акустические механизмы вручную.

Например:

• если Р невозможно получить без периодического модулятора, это станет экспериментальным основанием добавить такой механизм;
• если Т требует последовательности silence -> burst -> noise tail, это тоже должно вытекать из ручного эксперимента;
• если определённый тип гласного требует устойчивого F0 + F1/F2/F3, это должно быть найдено и подтверждено слухом.

То есть новые возможности добавляются не по предположению, а по наблюдаемому дефициту текущей модели.

Текущие ограничения и вопросы

1. Нужно проверить каждый существующий control отдельно и в минимальных комбинациях.
2. Нужно понять, какие из текущих transition types реально полезны, а какие пока декоративны.
3. burst, sine, повторяющиеся колебания и шумовые модуляции концептуально могут оказаться не просто интерполяциями, а отдельным классом временных модуляторов. Возможно, позже стоит разделить:
   • envelope / keyframes;
   • modulators поверх базовой траектории.
4. Нужно проверить, насколько корректно организованы физические диапазоны параметров и их нулевые состояния.
5. Нужно добавить удобное сохранение удачных звучаний и сценариев, когда появятся действительно интересные результаты.
6. Спектрограмма и другие способы анализа результата могут понадобиться позже, но сейчас приоритет — слуховой ручной поиск и причинная понятность интерфейса.

Критерий ближайшего успеха

Не «синтезатор уже умеет говорить» и не «пресеты совпадают с буквами».

Ближайший критерий успеха намного проще:

Пользователь может включить Loop, двигать keyframe-точку или параметр, слышать несколько вариантов подряд и устойчиво находить хотя бы некоторые узнаваемые речеподобные звучания, понимая, какое изменение к ним привело.

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

Краткий прогресс: текущую реализацию требуется переписать с нуля

Фактическая проверка показала, что текущий компонент нельзя считать пригодной основой для дальнейших экспериментов со звуком.

Основные проблемы:

• Аудиоархитектура принципиально не подходит для качественного синтеза. Параметры порциями обновляются через Web Audio nodes во время воспроизведения, тогда как для контролируемого экспериментального синтеза логичнее заранее вычислять PCM/массив sample-значений по всей временной логике и уже готовый буфер отдавать AudioContext на воспроизведение.
• Текущий DSP сам по себе устроен неудачно: sawtooth проходит через три последовательно включённых узких bandpass-formant фильтра, что почти уничтожает периодическую часть; шум при этом идёт отдельным прямым трактом.
• UI timeline и audio timeline фактически имеют разные часы. Loop, seek, pause/play и реальное аудиовремя не являются одной state machine.
• Управление звуком через requestAnimationFrame (~60 Hz) непригодно для коротких акустических событий, burst и быстрых переходов; дополнительное сглаживание ещё сильнее размывает события.
• Lifecycle аудиоисточников содержит race conditions и несогласованные состояния: повторный Play работает нестабильно, Stop способен приводить к неожиданному возобновлению звука, старые callbacks/source refs могут переживать смену состояния.
• В UI/UX слишком много независимых refs/states/hooks, отвечающих за части одного playback-состояния. Вместо этого нужен единый useReducer/finite state machine с явными состояниями stopped/playing/paused и детерминированными переходами.
• Отчёт о реализации оказался значительно оптимистичнее фактического поведения: интерфейс визуально выглядит как готовая лаборатория, но базовые пользовательские сценарии Play/Stop/Replay и сами звуковые результаты ненадёжны.

Вывод: точечное исправление текущей реализации нецелесообразно. Компонент нужно переписать с нуля, сохранив только общую идею визуальной лаборатории: timeline, дорожки параметров, keyframes, loop и ручной поиск звучаний. Новая версия должна строиться вокруг единой машины состояния и предварительного вычисления аудиобуфера из сценария.