В WDL-OL есть обработка этих интерфейсов, но примитивнейшая. Берется последнее значение параметра и устанавливается для всех сэмплов. В обертке для AU практически то же самое.
Я не совсем понял о каком эффекте речь (возможно не внимательно читал), но без аддитивного синтеза мусор в спектре будет присутствовать вне зависимости от частоты. Вообще, даже сигнал с одной гармоникой покажет несколько гармоник после ДПФ. От этого никуда не деться. Пример из статьи стремиться быть похожим на результат аддитивного синтеза, но все же немного отличается, хотя можно этого и не услышать.
Решает DAW и обычно размер буфера находиться в настройках. Чтобы плагин был готов, на этапе конфигурации передается это значение. Кстати, оно не обязано быть постоянным. Главное, что не будет превышать значения переданного при конфигурации.
Фильтр тут в качестве примера. Тут может быть любой изменяемый параметр (ручка).
Начну тогда из далека. Аудиоплагин используется не сам по себе, а в какой-нибудь DAW, которая посылает ему различные комманды, аудио на вход и ожидает на выходе получить какой-то результат. Это может происходить в реальном времени, во время воспроизведения трэка или при финальном рендеринге трэка.
Допустим в трэке есть секция возрастания какого-то параметра (обычно это называется automation),
и при воспроизведении или рендеренге трэка DAW должна каким-то образом посылать это изменение в плагин.
В текущей реализации параметр изменяется между вызовами ProcessDoubleReplacing, а внутри ProcessDoubleReplacing он имеет одно и то же значение для всех сэмплов. В ProcessDoubleReplacing обрабатывается nFrames сэмплов за раз.
То есть вместо плавного возрастания получается лесенка, где длинна каждой ступени nFrames сэмплов.
Чем больше длинна ступеньки, тем больше высота этой ступеньки. При достаточно больших значениях nFrames, получается не плавное, а скачкообразное возрастание параметра.
Если параметр начинает возрастать где-то по середине буфера переданного в ProcessDoubleReplacing, то изменения начнутся лишь в начале следующего ProcessDoubleReplacing. А если параметр будет колебаться с периодом меньше, чем за nFrames сэмплов (например automation, записанный с помощью mod wheel), никакой модуляции мы не услышим.
В качестве другого примера можно выставить большой размер выходного буфера и покрутить ручки синта. Будет тот самый эффект.
Почему nFrames может иметь большое значение? Потому что чем больше nFrames, тем меньше тратиться процессорных тактов. И для рендеринга часто ставят значение побольше. Хотя и для воспроизведения может быть выставлено большое значение, если при малом значение слышны glitch'и.
Например, в VST начиная кажется с 3-ей версии добавили специальные комманды для sample accurate изменения параметров (IParameterChanges и IParamValueQueue).
Обрабатывать их это то еще веселье, но это обязательно для современного синта.
Существуют и другие проблемы, но эта самая очевидная.
Я смотрел следующую статью в оригинале, там речь о bandlimited осциляторах, что является полезным знанием, но приведенный осциллятор с большой натяжкой можно назвать bandlimited.
Ссылок дать не могу. В основном используются заранее сгенерированные таблицы одного периода волны, выборка из которых может быть или прямой, или интерполироваться. Чтобы избежать алиасинга, я использую N таблиц каждая последующая в 2 раза длиннее предыдущей, а таблица выбирается в зависимости от шага (pitch). Если у осциллятора постоянный шаг, то для большей точности можно использовать fixed point для фазы и шага.
Если в композиции есть плавно нарастающая или убывающая cutoff frequency, то без sample accurate param changes не обойтись, иначе при слишком большом размере выходного буффера будет скачкообразное изменение параметра, что недопустимо. Как-то так.
Как базис — неплохо, все рассказано и показано очень доступно, но за доступностью скрывается много проблем. Начиная с производительности (в основном осцилляторов) и заканчивая отсутствием возможности sample accurate изменения параметров (cutoff, res, etc). А это must have для современного синта.
Как уже писали выше, не ясно о каких дедлоках речь, если мутекс тут только один.
Даже если тут есть проблема и она решена, то все дедлоки в этом подходе не устранены. Коллбэк назначается одной нитью, а выполняется другой. Тут тоже возможны дедлоки на доступе к общим данным.
Подход, устраняющий все потенциальные дедлоки — использование «входящей» и «исходящей» очередей для воркера.
Когда говорят как глупо выглядят противники теорий относительности мне всегда вспоминается концепция всепроникающего эфира. Теория тоже была очень обнадеживающей, нашла множество подтвеждений, но в конце-концов была отвергнута.
Что Вы хотете мне показать? Я прекрасно знаю как это обойти. Но это сильно не нормальное поведение. Если для Вас нормальное — замечательно. У меня другое мнение.
Вы хотите доказать мне что это не грабли? Или Вы хотите оправдать perl? В чем посыл? Если для Вас это не грабли — замечательно. Мне писать об этом не нужно.
Человек специально написал однострочник на perl и сделал его коротким, чтобы другим людям было проще его запустить. Но за это был почти предан анафеме. Однако.
Противоестесвенные порядок есть не только в perl, занчит пора писать статью и про проф. деформацию и ruby программистов.
При чем здесь «не выпендриваться»? Объясните в какой из двух конструкций выше есть «выпендривание»? На всякий случай объясню, вторая из них с точки зрения perl имеет синтаксическую ошибку на всех версиях интерпретатора, которые сейчас под рукой.
Автор открыл для себя разницу между списком и массивом? Да, в скалярном контексте они ведут себя по разному. Для полноты картины можно добавить пример с возвращаемыми параметрами функции. Но это все азы. В perl'е есть более страшные грабли.
|4 — 9/2| = |5 — 9/2|
Соответственно из него уже не следует, что 4=5.
Начну тогда из далека. Аудиоплагин используется не сам по себе, а в какой-нибудь DAW, которая посылает ему различные комманды, аудио на вход и ожидает на выходе получить какой-то результат. Это может происходить в реальном времени, во время воспроизведения трэка или при финальном рендеринге трэка.
Допустим в трэке есть секция возрастания какого-то параметра (обычно это называется automation),
и при воспроизведении или рендеренге трэка DAW должна каким-то образом посылать это изменение в плагин.
В текущей реализации параметр изменяется между вызовами ProcessDoubleReplacing, а внутри ProcessDoubleReplacing он имеет одно и то же значение для всех сэмплов. В ProcessDoubleReplacing обрабатывается nFrames сэмплов за раз.
То есть вместо плавного возрастания получается лесенка, где длинна каждой ступени nFrames сэмплов.
Чем больше длинна ступеньки, тем больше высота этой ступеньки. При достаточно больших значениях nFrames, получается не плавное, а скачкообразное возрастание параметра.
Если параметр начинает возрастать где-то по середине буфера переданного в ProcessDoubleReplacing, то изменения начнутся лишь в начале следующего ProcessDoubleReplacing. А если параметр будет колебаться с периодом меньше, чем за nFrames сэмплов (например automation, записанный с помощью mod wheel), никакой модуляции мы не услышим.
В качестве другого примера можно выставить большой размер выходного буфера и покрутить ручки синта. Будет тот самый эффект.
Почему nFrames может иметь большое значение? Потому что чем больше nFrames, тем меньше тратиться процессорных тактов. И для рендеринга часто ставят значение побольше. Хотя и для воспроизведения может быть выставлено большое значение, если при малом значение слышны glitch'и.
Например, в VST начиная кажется с 3-ей версии добавили специальные комманды для sample accurate изменения параметров (IParameterChanges и IParamValueQueue).
Обрабатывать их это то еще веселье, но это обязательно для современного синта.
Существуют и другие проблемы, но эта самая очевидная.
Надеюсь понятно объяснил.
Ссылок дать не могу. В основном используются заранее сгенерированные таблицы одного периода волны, выборка из которых может быть или прямой, или интерполироваться. Чтобы избежать алиасинга, я использую N таблиц каждая последующая в 2 раза длиннее предыдущей, а таблица выбирается в зависимости от шага (pitch). Если у осциллятора постоянный шаг, то для большей точности можно использовать fixed point для фазы и шага.
Если в композиции есть плавно нарастающая или убывающая cutoff frequency, то без sample accurate param changes не обойтись, иначе при слишком большом размере выходного буффера будет скачкообразное изменение параметра, что недопустимо. Как-то так.
И да, спасибо за проделанную работу. :)
Даже если тут есть проблема и она решена, то все дедлоки в этом подходе не устранены. Коллбэк назначается одной нитью, а выполняется другой. Тут тоже возможны дедлоки на доступе к общим данным.
Подход, устраняющий все потенциальные дедлоки — использование «входящей» и «исходящей» очередей для воркера.
perl -e 'map { "-$_" => $_ } @ARGV'vs
perl -e 'map { "-".$_ => $_ } @ARGV'Противоестесвенные порядок есть не только в perl, занчит пора писать статью и про проф. деформацию и ruby программистов.
На всякий случай:
echo "$_" testperl -e 'map { $_ => 1 } @ARGV'vs
perl -e 'map { "$_" => 1 } @ARGV'