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

Не совсем так. Это HC(T)-серия, токи КЗ по выходу миллиампер 40. При 8мА у него всего милливольт на 300 просаживается уровень лог.1, а для нижнего плеча ситуация еще лучше. Зачем? Он копеечный и широко распространен.

Вообще эти Атмелы по очень толстым технологиям сделаны и трудноубиваемые. Но "и на старуху бывает проруха", потому просто поставьте после этих 200 ом на землю супрессор P6KE6.8A (анодом в землю, катодом - к линии MIDI OUT). Можно и просто стабилитрон типа bzx84c5v6, он, конечно, менее крепкий...

Хотя, похоже лучше делать sin(x)/x-интерполяцию. Фарроу недостаточно прямоуголен по АЧХ, нужен запас сверху по частоте дискретизации. Но да, sin(x)/x чуть более требователен по ресурсам. Но, опять же, несмертельно.

Нет, какие там разы, Фарроу - вполне простой. Десяток умножений и сложений. Ну так это ж не мне надо, это люди просят ;)

Нужен дилей с задержкой, некратной семплу. Для этого нужна интерполяция между семплами. Можно sin(x)/x сделать, а можно - интерполятор Фарроу. Например, можно начать читать отсюда - https://ru.dsplib.org/content/resampling_lagrange/resampling_lagrange.html

Что-то я уже сам запутался. Я попозже отпишу, занят щас.

Это Xrms и Threshold в каких единицах?

Все точно так же, воспользоваться тем, что логарифм мало отличается от самого числа при малых изменениях. Т.е. просто выкинув логарифмы ;)

Да я ж в общем это "свое" приводил как пример, как информацию к размышлению ;)

Не знаю, но не думаю, что оно вообще представляет интерес.

Не совсем так. В Макоси можно поставить приоритет потоку выше всех (в том числе, и выше потоков ядра), а в Линухе - нельзя. Я про юзерсспейс, если что. И выше 99 бывают. Но только в ядре. И совсем по другому там вытеснение начинает работать (оно продолжает работать, потому что между потоками...

Там довольно много накладных расходов с той точки зрения, что надо подклеить снизу и сверху к кривой нужные прямые, а кроме того, рассчитать параметр t. Банальный smin, который я приводил выше, куда проще.

Это, блин, что-то там немыслимое у Джастина накручено. Может дело не в таблице, а в медленном выполнении str_getchar/str_setchar?

Так, теперь про вычисление произвольной степени: Напомню, что a^b=exp(ln(a)*b); Для наших целей проще использовать log2, это будет a^b=2^(log2(a)*b); Как сделать быстрый log2 мы уже обсуждали выше: str_setchar(temp_str,0,a,'f'); str_getchar(temp_str,2,ival,'su')...

Почему бы не начать с какой-нибудь простенькой реализации smooth min, например, с такой: // polynomial smooth min 2 (k=0.1) float smin( float a, float b, float k ) { float h = max( k-abs(a-b), 0.0 )/k; return min( a, b ) - h*h*k*(1.0/4.0); } Эта функция возвращает минимум из значений...

Да мне как бы все равно, лишь бы на здоровье ;)

Так то, что там в секции @slider - это можно все оставлять, оно не влияет на производительность, ручки же в отдельном низкоприоритетном потоке крутятсся.

99 - это не самый максимально возможный приоритет, если что. Если Вы поищете BASEPRI_RTQUEUES вот в этом файле - https://fergofrog.com/code/cbowser/xnu/osfmk/kern/sched_prim.c.html (более удобный просмотрщик, чем в гитхабе ;) ), то увидите большую кучу всяких изменений поведения при установке...

Я имею в виду просто поведение пикового детектора, когда у него на входе сигнал ниже запомненного, а не компрессора с пиковым детектором, если что.

По макос - запросто, https://developer.apple.com/library/archive/documentation/Darwin/Conceptual/KernelProgramming/scheduler/scheduler.html А по линухам трудно дать ссылку на то, чего нет в природе ))))

А что тут можно подробнее? В macos есть способ (штатный) дать потоку приоритет выше всех. В том числе выше системных. Там прямо специальный костыль (штатный) поверх типичного юниксового шедуллера прибит в ядре для этого. В линухах такой возможности нет.

Не могла она такое давать. Потому что там обычный RC-фильтр. Линейно в дБ происходит падение, если бы мы измеряли уровень сигнала пиковым детектором. Т.е. запомнили в фильтре какой-то пик, а потом он бы падал до 0. Вот от этого пика до 0 изменение в дБ было бы действительно линейным. Потому...

Поведение еще можно приблизить друг к другу путем небольшой коррекции постоянной времени в моем варианте https://www.desmos.com/calculator/cwa3jam5bf Коэффициент коррекции подозрительно похож на sqrt(e)/2, но я не готов щас математически доказать минимум ошибки именно с таким коэффициентом...

Вы путаете графики функций на огромных диапазонах значений с реальными диапазонами, которые у Вас в работе происходят. Более того, Вы в RC-фильтре имеете, скажем, значения, от -6 до 0 (это в дБ), а если бы работали с непорседственным представлением сигнала, то управление бы было наоборот, от...

@belovw, все, я сдаюсь, делайте что хотите :Dle46: :Dle46: :Dle46: :Dle46: