Я тут уже примерно месяц мучался с задачей, которая аналитическим способом позволяла бы определять полигоны, на которые падают прямые лучи от источника света, и игнорировать другие полигоны, если они спереди закрыты чем-то другим. Долго не мог найти решение, которое имеет конечную сходимость, но в итоге понял, что крутился вокруг некорректного решения. Так или иначе, задача была решена, на что есть небольшая видео-демонстрация: Как думаете, когда я закончу со всем матаном (и, разумеется, с конечной задачей), имеет смысл написать статью на эту тему?
Владимир(SadKo), а вы не планируете портировать свои VST-плагины на Windows? И следом бы статью на эту тему - было бы просто замечательно. Естественно, на тему создания, а не портирования . В сети по этой теме очень мало материала, да и с книжками негусто. У вас кстати нет литературы по этому вопросу?
Нет, литературы нету, увы. Портирование начал, даже завёл виртуалки с вендой, но эта задача меня полностью поглотила, поэтому пока отложил портирование на время.
SadKo, сложность алгоритма (от количества треугольников)? Сцена как-то прекалькулируется, или все в динамике (то есть можно ли двигать по-всякому принимающие треугольники)? Производительность?
Здесь обработка идёт в несколько проходов, для каждого своя сложность, и не факт, что каждую я правильно могу оценить. 1. Подготовка пространства. Сцена (с набором объектов и матриц трансформаций) превращается в единый меш треугольников. Проверка пересечения объекта и падающих лучей осуществляется при помощи bounding box-ов. Сложность линейная. 2. Решение конфликтов. Необходимо все пересекающиеся треугольники рассечь на непересекающиеся. Квадратичная сложность. 3. Отсечение области видимости треугольников. Пространство рассекается четырьмя плоскостями: тремя боковыми и плоскостью проекций. Каждая операция отсечения имеет линейную сложность. 4. BSP: пространство бьётся пополам плоскостью, проходящей через фокусную точку и точки очередного ребра треугольника. Сама операция рассечения треугольников плоскостью имеет линейную сложность. При хорошем выборе порядка рёбер получим сложность N*log(N), при плохом - N^2, как в быстрой сортировке. 5. Depth-тест: выбирается очередной треугольник, все, треугольники, находящиеся над плоскостью треугольника (считаем, что точка фокуса находится под плоскостью треугольника), отсекаются. В лучшем случае сложность будет квадратичная, в лучшем - N*log(N). Ну и всё это делается на стековой STATE-машине.
материалов более, чем хватает http://www.martin-finke.de/blog/articles/audio-plugins-001-introduction/, есть куча гитов, есть теория акустики, статистических фильтров.
UbIvItS, судя по вашим комментариям вы, конечно, далеко не новичек в программировании, реверсе и т.п. Но в данном случае с вашей стороны это прям какая-то провокация , на предмет "прощупать" меня и мои познания в этом вопросе, и сами вы очень далеки от этой темы . Материалов, конечно, хватает, но к большому сожалению, почти все они на уровне Hello, world! На гите, разумеется, кое-что есть, но как правило у этого "кое-что" код очень низкого качества, комментарии очень скудные и чаще всего проще написать что-либо свое с ноля, чем разбираться в таком коде. Теория акустики тут вообще дело десятое, если, конечно, ты не занимаешся физическим моделированием какого-нибудь акустического инструмента. Ну, правда, вот в "ревере" какие-то тонкости еще могут пригодиться и свертка еще каким-то боком к этому имеет отношение. Насчет статистических фильтров - вообще непонятно что вы под этим подразумеваете? В DSP, насколько мне известно, - нет такого термина. Может вы под этим термином имеете в виду вообще все фильтры вместе взятые . Ну, в общем, не хочу спорить. Думаю, что если я не прав, то Владимир(SadKo) нас рассудит .
https://github.com/audacity/audacity на хэлоу ворлд не похоже https://github.com/LMMS/lmms тоже не смахивает на хэлоу
sty, https://www.audiopluginsforfree.com/linux/vst-linux/ тута смотри, у части плугинов есть ссыли на гит.
Вот тут можете почитать описание моего плагин-фреймворка в комментариях: https://github.com/sadko4u/lsp-plugins/issues/3
Владимир, вы только не обижайтесь, а то подумаете, что я умничаю, но подобная информация как раз и подразумевалась, когда я писал про Hello, world. Основы архитектуры VST-плагинов я знаю и примеры из SDK тоже собирал и изучал в свое время. Мне было бы интересно почитать про то, как вы реализовали свертку и на ее базе импульсный ревербератор. На чем делали GUI (или будете делать для венды)? Я имею в виду, что кто-то делает на QT, а кто-то на Juce или GUI из SDK. Также интересно было бы узнать на чем вы строите математические модели, перед тем как запрограммировать это на C/C++? И еще очень интересует код на C/C++ интерполяции B-сплайнами, только желательно с учетом применения на WAV-файлах. А то я что-то находил в сети, но там все было расчитано на 3-хмерную графику, а ума адаптировать для WAV-файлов не хватило . Это, если что, для применения в семплере. Вдруг с ней звук будет более чище .
Ничего в этом обидного нет. Значит, я не совсем верно понял вопрос. Свёртка делается путём применения прямого и обратного преобразования Фурье к блокам сэмплов. Об этом хорошо написано вот здесь: http://www.dspguide.com/ch18/2.htm И вообще, книжка must have, если вы только начинаете осваивать DSP-алгоритмы, благо есть отличный перевод на русский. Чем больше размер блока, тем быстрее работает свёртка, но тем ниже точность из-за ошибок округления. Однако чем больше размер блока, тем больше latency. А хочется иметь ревербератор с нулевой задержкой. Поэтому мне пришлось совмещать алгоритм вычисления свёртки "в лоб" с FFT. Изначально GUI был на GTK2. Однако использование любого "крутого" тулкита рано или поздно аукнется. Поясняю. Есть Ardour, текущая версия которого написана на GTK2. И есть некоторый плагин, который написан на GTK3. Ardour пытается грузить UI для этого плагина и благополучно валится. Потому что приложения GTK2 и GTK3 несовместимы между собой. Juce популярен для разработки плагинов, но мне он совершенно не нравится. Поэтому начиная с версии 1.1.0 я полностью перешёл на собственноручно написанный тулкит. Мат. модели - обычно тот же C/C++. Коллега по цеху делает симуляции на Julia/Faust. Не совсем понимаю про интерполяцию B-сплайнами. Какую прикладную задачу хотите решить?
Я сначала принял ваш ответ за розыгрыш. Подумал, что ну как же так у человека набор эффектов, семплер и ему ни разу не понадобилась интерполяция. А как же тогда без этого работает хорус, фазер, фленжер, да и, собственно, семплер. Стал смотреть вашу документацию и сразу стало все ясно, что семплер - это драм-семплер. Соответственно, преобразование по высоте (Pitch Shifter) - отсутствует, и хоруса, фленжера и фазера - тоже нет. Тогда все встало на свои места и стало понятно. Ну и далее, собственно, о моей прикладной задаче. Везде где применяется FM-модуляция (хорус, фазер, фленжер) или просто сдвиг по высоте (семплер, Pitch Shifter) - везде применяется интерполяция (я пользуюсь линейной и кубической, в зависимости от задачи). Иначе на выходе будем иметь треск и искажения. Если коротко, то когда мы изменяем частоту семпла - мы сужаем или расширяем отсчеты (семплы) и соответственно получаются резкие перепады уровня (ступеньки), которые нужно сглаживать. Если хотите могу презентовать вам хорус, фазер, фленжер - у меня есть уже готовые решения, GUI только не успел прикрутить. Ну GUI для вас не проблема. И будет у вас почти (дисторшена и овердрайва только не хватает) джентельменский набор гитариста. Если заинтересуетесь, то в личку постучите.