Pull to refresh

Comments 17

Больше всего поражает ваша упорность в написании статей, за которые отдельное спасибо :)
Пожалуйста :) Правда, я их не пишу, а перевожу, от себя добавляю мало.
Пожалуйста, не переставайте! Не смотря на отсутствие активности в комментариях, статьи очень полезны и, уверен, множество благодарных читателей приходят с гугла :)
Осталось совсем немного до конца цикла :)
Да, я надеюсь, приходят. Несколько человек писали мне в соцсетях, что эти статьи им полезны. DSP, даже ограниченная обработкой звука, это очень объемная тема, в ней масса суперинтересных и непростых задач. Было бы здорово иметь даже небольшое сообщество для обсуждения. С другой стороны, конкуренция в этой области достаточно высока, и таких сообществ в интернете вообще не так много.
Отличный цикл статей, продолжайте дальше. Технические статьи всегда собирают довольно мало комментариев, но они оказываются в дальнейшем самыми полезными!
Как базис — неплохо, все рассказано и показано очень доступно, но за доступностью скрывается много проблем. Начиная с производительности (в основном осцилляторов) и заканчивая отсутствием возможности sample accurate изменения параметров (cutoff, res, etc). А это must have для современного синта.
Буду рад, если вы дадите ссылки на более производительные алгоритмы, я этим тоже озабочен. Следующий пост будет, к слову, об осцилляторах.

Что касается sample precision — тут с вами поспорю.
Да, есть направления, где это необходимо (что-нибудь типа работ Ryoji Ikeda или Alva Noto), но масса прекрасных вещей делается и без sample precision — NIN, GusGus, Moderat, Depeche Mode, Jon Hopkins и т.д.
В конце концов, теплый ламповый звук — это полная противоположность точности.
Пардон за нэймдроппинг :)
Я смотрел следующую статью в оригинале, там речь о bandlimited осциляторах, что является полезным знанием, но приведенный осциллятор с большой натяжкой можно назвать bandlimited.

Ссылок дать не могу. В основном используются заранее сгенерированные таблицы одного периода волны, выборка из которых может быть или прямой, или интерполироваться. Чтобы избежать алиасинга, я использую N таблиц каждая последующая в 2 раза длиннее предыдущей, а таблица выбирается в зависимости от шага (pitch). Если у осциллятора постоянный шаг, то для большей точности можно использовать fixed point для фазы и шага.

Если в композиции есть плавно нарастающая или убывающая cutoff frequency, то без sample accurate param changes не обойтись, иначе при слишком большом размере выходного буффера будет скачкообразное изменение параметра, что недопустимо. Как-то так.

И да, спасибо за проделанную работу. :)
Я, честно говоря, не совсем понял про фильтр. Опишите пожалуйста пример подробнее :)
Фильтр тут в качестве примера. Тут может быть любой изменяемый параметр (ручка).

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

Допустим в трэке есть секция возрастания какого-то параметра (обычно это называется automation),
и при воспроизведении или рендеренге трэка DAW должна каким-то образом посылать это изменение в плагин.

В текущей реализации параметр изменяется между вызовами ProcessDoubleReplacing, а внутри ProcessDoubleReplacing он имеет одно и то же значение для всех сэмплов. В ProcessDoubleReplacing обрабатывается nFrames сэмплов за раз.

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

Если параметр начинает возрастать где-то по середине буфера переданного в ProcessDoubleReplacing, то изменения начнутся лишь в начале следующего ProcessDoubleReplacing. А если параметр будет колебаться с периодом меньше, чем за nFrames сэмплов (например automation, записанный с помощью mod wheel), никакой модуляции мы не услышим.

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

Почему nFrames может иметь большое значение? Потому что чем больше nFrames, тем меньше тратиться процессорных тактов. И для рендеринга часто ставят значение побольше. Хотя и для воспроизведения может быть выставлено большое значение, если при малом значение слышны glitch'и.

Например, в VST начиная кажется с 3-ей версии добавили специальные комманды для sample accurate изменения параметров (IParameterChanges и IParamValueQueue).
Обрабатывать их это то еще веселье, но это обязательно для современного синта.

Существуют и другие проблемы, но эта самая очевидная.

Надеюсь понятно объяснил.
Объяснили здорово. И вернули меня к одному старому вопросу: кто решает, какой именно длины будет nFrames. Возможно, ответ скрыт где-то в комментах к коду, но я его пока не нашел.
Решает DAW и обычно размер буфера находиться в настройках. Чтобы плагин был готов, на этапе конфигурации передается это значение. Кстати, оно не обязано быть постоянным. Главное, что не будет превышать значения переданного при конфигурации.
Надо покопаться и проверить, но я предполагаю, что в WDL-OL должны быть способы менять IParameterChanges и IParamValueQueue.
В WDL-OL есть обработка этих интерфейсов, но примитивнейшая. Берется последнее значение параметра и устанавливается для всех сэмплов. В обертке для AU практически то же самое.
Получается, «лесенку» никак не обойти?
Стандартными средствами никак. Но всегда можно форкнуть WDL и переписать какую-либо часть. :)
Sign up to leave a comment.

Articles