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

Кому интересна автоматизация тестирования, советую прочитать вот эту статью.
Tips and tricks for efficient GUI automation
Мне кажется, когда я читал у меня в голове всплывали картинки кода из Unicorn TAF

Туториал как сделать сайдчейн компрессию

Я купил Waldorf Pulse2, хороший моно синт(3 осцилятора, парфонический режим)
{:.clickableimg}
но никто не сказал, что хочется потом сразу синт, который будет делать то, чего твой не может.
Теперь хочется полифонический синт, короче =)
Хочу попробовать IDM и Dub Techno сделать, притом желательно что-то из роландовской палитры синтовой.

Но это не то, что я хотел сказать. Я пока смотрел на полифонические синты наткнулся снова на коммент по типу "обожаю этот синт, с его секвенсором сделал такое, чего бы не сделал сам в DAW". Мне кажется, это хорошая штука чтобы держать в голове когда создаешь свой музыкальный инструмент, виртуальный или физический.

Сейчас смотрим Дневники вампира. Я раньше не смотрел потому что был крутой и такое не смотрел(сейчас нет) и стало как-то особенно заметно, что современные сериалы смотреть не так интересно и есть теория. Сейчас сериалы выпускаются сезонами по 10 серий и динамика там на эти все 10 серий выглядит так: 1 эпизод интенсивно, 2-3 серия экспозиция и потом до конца сезона все идет к крещендо и клифхэнгеру.

И ты в целом уже запрограммирован ожидать такую динамику, в Дневниках мы на втором сезоне всего, но там в сезоне 22 серии и ощущение будто посмотрели уже 3, потому что на таких длинных сезонах привязки к этой современной прагматичной динамике нет и ты не знаешь когда ожидать какой-то поворот и они там случаются довольно часто.

Ну понятно, что это сейчас сделано чтобы у студий был короче фидбек луп с отзывами о сезоне и сериале в целом если он новый, но скучно быть зрителем.

Вот так, сейчас в общем-то неплохой сериал Разделение на середине второго сезона уже довольно ясно дает понять, что в конце сезона ясно не будет ничего, а клифхэнгер будет просто топливом для тиктока и от этих бурлений будет зависеть будет ли третий сезон.

Все усугубляется, если сезон в целом плохой, как второй у Укрытия, например, тогда получается уровень нетфликсовского хрючева.

Узнал что Emulator(один из первых сэмплеров "доступных", 8000$ в 1984) использовал для питч шифта смену частоты клока для DAC. Сейчас звучит дико, но вообще имеет смысл, потому что заставить чип делать буп-буп быстрее или медленее дешевле с точки зрения вычислений(1984 год же). Но это за собой влечет то, что у тебя несколько звуков разной высоты играть не могут если у тебя всего один DAC, а у него было 8 голосов полифонии, значит там было больше одного DAC, но я не смог нагуглить сколько именно.

Сделал булочки с кардамоном!
Все равно у Галимы пришлось спрашивать чо да как. Потому что это мои первые, кажется...
{:.clickableimg}

Сегодня снова подвигал пиксели в блоге(напозорился в CSS), а вчера посмотрел соника третьего, было очень плохо =)

Где-то в последних версиях JUCE(фреймворк для аудио девелопмента) добавили WebView. Теперь будет больше красивых VST плагинов - это фреймворк используют вообще все(примечание автора: художественное преувеличение).
Но старые интерфейсы в парадигме immediate ui мне нравятся больше своей отзывчивостью и что юай и логику можно на одном языке писать (в WebView тоже должно быть отзывчиво, там есть доступ к WebGL, но много людей его будут использовать?).

Так что будет проще продать очередной булщит биткрашер-флаттер-лофи плагин т.к. он не будет выглядеть как штука чтобы заказать товар со склада. И таких плагинов будет больше, но это в конце концов хорошо по теории двух тортиков.

Но даже и старые интерфейсы VST, в частности, иногда просто грузятся непростительно долго(Native Instruments(!), UAD, SoundToys, etc.), там что-то другое тормозит, не юай отрисовка.

Вот, собснно, сама теория

Саундклауд не дает загрузить трек, мильен ошибок в консоли. Поэтому он умирает, ю хед уан джоб.

Попросил Gemini сравнить две модели Raspberry PI в виде таблицы 🫠

Смотрел докуметалку про FSOL и там было про то, что у них есть ящик с DAT кассетами(помните такие?), которые им записывали друзья диджеи, там куча снипетов по 3-6 секунд с музыкальных альбомов, радио, тв. Это значит что они зачастую даже сами не знали что сэмплируют.
Ну, гении мыслят одинаково и у нас с другом тоже была-есть коллекция, но только на минидисках(помните такие?).
Это они сейчас.

Да, они выпускались с 1992 по 2025.
Только у нас источником был исключительно винил. Я ничего чтобы это случилось не делал, я просто использовал, а друг все это записывал из собственной коллекции, огромное спасибо! Я до сих пор пользуюсь, у меня есть оцифровки.


Интересны они тем были, что это самый футуристично выглядящий носитель, но так же еще что это lossy аудио формат, там алгоритм компрессии основан на писхоакустике.

Я полез в вики(английскую) проверять факты и увидел, что они прекратили выпуск в 2013 году, но свежая новость есть за этот 2025 год вот. Возможно они выпускались только в Японии с 2013.

Несмотря на то, что минидиск это не лослесс я бы все равно выбрал библиотеку сэмплов на них, а не на DAT. Потому что когда делаешь музыку последнее что хочется это прослушивать DAT кассету подряд. Потому что на ней нельзя переключать треки целиком как на минидиске(ну и на обычных сиди).

Кстати, есть даже портативные плееры и рекордеры минидисков.

Наступило время когда меня начала бесить моя же клавиатура Vortex Race 3. Хочется чего-то без проводов и тише... и может что-то с меньшим ходом клавиш. Ей уже лет 5 как минимум, я даже с ней в офис ходил(простите).

Выключил снег в блоге. Нам сказали его не будет этой зимой(и сейчас нет).

Это я хотел посмотреть что там происходит в Slack Report Portal.
В прошлой жизни я кое-чего там спрашивал про миграцию на новые версии и теперь не могу прочитать свои же сообщения из лички.
Скоро так же в дискорде будет.

Посмотрел видео, и да, даже я уже почувствовал это, что чтобы собрать зависимости в кучу чтобы они собрались и слинковались слишком много путей и нужен огромный мозг чтобы это сделать. Какие-то умные пакадж манагеры есть, но это все еще зоопарк, после такого приятно возвращаться в C#.



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

Оказывается очень сложно писать текст чтобы можно было его потом читать нормально, и еще я постоянно все в скобки беру, нужно сюда допилить какие-то ссылки удобные, будет блог как Бесконечная шутка(ха-ха). Только в шутке там специально ссылки сделаны чтобы тебя задолбать за 900 страниц листать в конец книги.

Еще о автоматизации.
Я заметил, что существует такая лакуна в понимании тестового покрытия: юнит тесты считаются автоматизацией и фигурируют в этой пирамиде тестирования, но чаще всего являются ответственностью разработчиков.
{:.clickableimg}
Более того, часто юнит тесты живут с кодом приложения(ну это понятно), а код автоматизации лежит где-то в другом репозитории, так что он даже физически где-то в другом месте(это не плохо само по себе, просто пример). А в отчетах и метриках автофреймворка(у вас же они есть, да?) о юнит тестах и покрытии в общем-то ничего нет.

Оказывается в спанах в C# нужно еще разбираться и разбираться.
Мне в повседневной работе это вообще не нужно, но интересно как это работает.
Вообще, в оптимизации тестов по скорости выполнения(это одна часть моей работы) самые большие гейны в скорости прогона тестов приходят из параллелизации(тут ясно) и следования тестовой пирамиде.
Если вы оптимизируете тесты по скорости выполнения как-то иначе, то скорее всего это трата времени и смотрите вы не туда. Тут стоить заметить, я говорю о довольно больших фреймворках автоматизации с количеством тестов >100(но это цифра из головы, зависит от типа тестов) и это не о юнит тестах(с ними уже больше смысла биться за скорость выполнения).
А причин почему тестовая пирамида может быть сломана уйма, но вот одна. У вас есть множество автоматизированных тестовых сценариев, которые тестируют функциональность внахлест(происходит тестирование одной функциональности по нескольку раз), это очень частый случай, но предпосылки могут быть разными. Случиться это может, например, из-за непонимания домена или архитектуры приложения. Человек может не понимать, что проверяя функциональность(или часть системы) `А` он еще проверяет функциональность `Б`, которая может использоваться неявно или использоваться в каких-то эдж кейсах и тестировать явно ее не нужно, но на нее тоже написаны тесты. Или функциональности `А` сначала не было, а была только `Б` и тесты на неё. Или несколько команд использующих один фреймворк автоматизации, но работающих над разными частями системы могут создавать тесты для того, что возможно уже покрыто другой командой, и это уже проблема коммуникации и трейсабилити(блять, смотря какой фабрик, traceability, как это по-русски?), которая решается не оптимизациями в коде и может быть предотвращена сбором и оценкой соответствующих метрик.

Вообще тут очень много оговорок и нужно писать статью.

А про спаны интересно, да, я просто видео хотел запостить.

Visual Studio обновилась и теперь там показывается плашка если есть уязвимости в пакетах(транзитивные тоже), круто.
{:.clickableimg}