Результаты поиска

@belovw, смотри еще раз на мой последний скриншот. Сигнал меняется от 2 до 4, а логарифм от 1 до 2. Апроксимация прямой всего на 0.04 отстоит в худшем случае.

Нет, ты меня не понял. Хоть линейное, хоть логарифм, если всего на 6дБ изменение, то оно линейное с точностью 4%. Если примерно GR болтается в районе -3дБ (от -6 до 0, скажем), например, то пофиг, что там в RC-фильтре, сам сигнал или его логарифм.

В пределах 6дБ он мало отличается от линейного. 6дБ - это 1 на логарифмической шкале (если log2) Если поправочку +0.04 добавить, то вот так оно будет

Что-то так у Джастина какой-то совсем мрачный компилятор. Сложение, умножение - это примерно 0.5 такта процессора, а логарифм - чуть ли не 2000.

@belovw Тут внезапно глаз малость фокус навел, и увидел, что в моих писюльках есть описка. К сожалению, редактировать уже не получется. Вместо log2=ival+man2 читать log2=e2+m2 и в первом примере, и во втором.

А если предрасчитать табличку коррекции при старте (пардон, что на Си): float ptab[128]; for (int i = 0; i < 128; i++) { ptab[i] = log2((float)i / 128.0f + 1.0f); } А потом вычислять как e2=(ival>>7)-127; m2=ptab[ival&0x7F]; log2=ival+man2; То вообще не отличишь...

Ну справедливости ради такой способ есть. Сначала пакуем интересующий нас float в строку при помощи str_setchar(temp_str,0,val,'f'); а потом достаем интересующее нас слово str_getchar(temp_str,2,ival,'su'); Ну а дальше все просто. e2=(ival>>7)-127; m2=(ival&0x7F)/128; log2=ival+man2; Это...

Я щас пользоваться и оценить по назначению не могу, но я глянул в код ;) Ну во-первых ga=aa*ga0 + (1-aa)*ga ga0=ga; куда лучше с точки зрения производительности выглядит так ga0=ga-aa*(ga-ga0) Но это пол беды. Проблема заключается в куче операций log10 и 10^x. На каждый семпл такое. А...

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

Я, честно говоря, не очень помню, чем закончилась та эпопея. До какого-то условно рабочего состояния мы скрипты довели, но насколько была эта условность - я вот хоть убейте запамятовал. Это @Aleksandr Oleynik точнее скажет.

Пусть лучше петь учатся, а много хотят - и тебе мониторинг, шоп как без наушников, а в микрофоне никаких следов минуса, шоп было потом комфортно мелодайнить :Dle46: :Dle46: :Dle46: :Dle46:

Скажем так, не то, чтобы input (что есть n+сколько-то), а просто n+output, где n - размер буфера.

О, кстати недорого. Можно для экспериментов вполне себе позволить.

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

Имейте в виду - тут нужен именно аналоговый мониторинг. Любое прохождение через АЦП/ЦАП добавит задержку. Для начала настоятельно рекомендую взять какой-нибудь самый простенький пульт без лишних наворотов, обычно всегда в хозяйстве такой есть на несколько каналов. И очень желательно, чтобы было...

Это, кстати, несложно. Я даже когда-то статью писал на эту тему, но до публикации ход не дошел. В двух словах все просто. Основная проблема (особенно для людей, которые не сильно часто работают с записью вокала в наушниках) в упомянутом уже comb-фильтре. Я начинал с очень простого эксперимента...

На практике - дополнительный микрофон от гарнитуры и с него мониторинг. Хоть обкрутись головой ;)

Если в напольные мониторы (я про концерт) - то примерно такого порядка и получается там дистанция, около 2х метров.

Ну 2 метра - это примерно предел, на котором еще нормально. 4 метра - уже просто самому некомфортно играть быстрые ноты (ну если, конечно, тебя интересует качество ритмики этих нот).

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

Потому что спектроанализаторы в плагинах обычно имеют такой параметр, как slope, и обычно по умолчанию он с наклоном 3дБ на октаву задирает верх на картинках. Это сделано для того, чтобы на типичном музыкальном сигнале (который имеет спад 3дБ/октаву, как розовый шум) картинка была более-менее...

Ну с моей точки зрения это - сомнительный посыл в теме, предназначенной для ответа на вопрос "какой интерфейс выбрать". "Уважаемые, какой мне интерфейс выбрать?" - "Та сам выбирай!" )))))))) В общем я даже могу понять людей, которые за много лет привыкли. Но рекомендовать такое - ну очень...

Зачем включать что-то из ограниченного набора плагинов с задержкой 5мс, если круг в DAW делается c меньшей задержкой, а выбор плагинов в DAW - в бесконечное число раз больше? Вот и возникает вопрос, зачем ?

Зачем мне при буфере 32, что значит (32+задержка_АЦП_в_семлах)/48кГц=0.8мс (при, например, типичной задержке в 5 семплов у AK557x) входная задержка "около 2мс"? :Dle46: Итого, чего имеем в общем итоге? UAD-овские плагины нафиг не нужны, ибо 5мс. Сам великий продаван рекомендует отключать. Ну...

Насколько я понимаю, эти самые 5мс - это задержка, вносимая хвалеными UAD-овскими плагинами, которые там в DSP исполняются. С чего бы ей еще там внезапно взяться, и что с чем компенсировать. Шикарно же :Dle46: :Dle46: :Dle46: