🔥Синтезатор, где звук добывают битьём виртуальных пружин Бывший ведущий инженер Google Эван Мезеске три года пилил Anukari, и в этом месяце программа вышла из беты в стабильную версию 1.0. Что она делает. Обычно компьютер получает звук либо по аккуратным формулам, либо проигрывая запись живого рояля. Anukari выбрасывает оба способа. Вместо них — пустая 3D-арена, куда вы затаскиваете грузики, пружины и якоря. Нажимаете клавишу — по конструкции бьёт виртуальная киянка. Грузы отскакивают, пружины растягиваются, энергия расходится по всей сцепке. А виртуальный микрофон внутри трёхмерного пространства снимает это движение и превращает кинетику в звук. Дальше начинается веселье. Можно сцепить сотни блоков, шаров и пружин в свисающую паутину, лупить по ней несколькими MIDI-киянками и параллельно модулировать всё это осцилляторами. Соедините хотя бы 20 грузов и постучите — конструкцию начнёт крутить и сталкивать саму с собой. На выходе металлические скрипы, кинетические дроны и щелчки, которые звучат живыми просто потому, что подчиняются законам движения, а не фиксированному скрипту. Работает и в обратную сторону: подайте реальный звук, например свой голос, — и программа переведёт его в кинетическую силу. Крикнете, и пружины физически затрясутся. Ставится и как отдельное приложение, и как плагин в GarageBand или Ableton Live: можно играть живьём или собрать трек и выгрузить обычным аудиофайлом. @droidergram

Разработчик Александр Романов выложил на GitHub открытый проект Cassette Simulation, который через FFmpeg имитирует звучание кассетных лент пяти производителей. Инструмент накладывает шум ленты, детонацию wow и flutter, режет полосу пропускания и крутит эквалайзер. Код опубликован под лицензией MIT, для запуска хватает bash и ffmpeg, собранного с libmp3lame. Профилей шесть, и каждый тянет цифровой звук к своим дефектам. Немецкая BASF LH Extra C90 добавляет умеренное шипение и лёгкий флаттер, Maxell UD C90 шипит меньше и берёт диапазон шире. Винтажные Sony CHF60 и CHF90 1978 года дают тёплую середину, а 90-минутная сильнее плывёт по скорости. Поздняя TDK D90 середины 90-х имитирует чистый звук с тонким аналоговым характером. На другом полюсе советская МК-60, которая заваливает трек сильным шумом, мощными wow и флаттером и агрессивно срезает частоты. FFmpeg, инструмент для честной цифровой обработки, здесь возвращает записи шипение, дрейф скорости и зарезанный верх.

Несуществующие агенты для аудио В последнее время много работаю с генерацией аудио. И удивляет, что в основном аудио пайплайны собираются в условном comfy – визуальном блочном редакторе. Удивляет потому что это как писать код пайплайном в n8n вместо клода Основная проблема тут – нет полноценного агентного цикла, где модель видит, а точнее слышит, результаты предыдущих действий и может сама выбирать что с этим делать делаше Но тут есть одна техническая сложность, которая многое объясняет: у моделей пока нет нативного восприятия аудио. Например, умение "видеть" картинки уже есть. Поэтому клод код может посмотреть скриншоты лендинга, который он сделал, увидеть косяки и поправить их. Картинки – в контексте той же модели, которая пишет код А с аудио так не работает – большинство моделей не умеют в нативный аудио input Вы скажете: так есть же gemini. Это да. Но: ни одна агентная обертка не поддерживает чтение аудио файлов чисто на уровне тулов. Агентный экзоскелет просто не может просунуть аудиофайл в API запрос к "мозгу". Да, можно подключить gemini по api к основному агенту и отправлять туда аудио с промптом мол "расскажи, чего не хватает" (кстати, китайская glm-5.2 все еще с картинками работает именно так). Но это все равно что глухой композитор, который зовет своего племянника послушать музыку и сказать, что он там слышит – работает, очевидно, плохо из-за эффекта глухого телефона Вот и получается, что сейчас просто нет привычного нам агентного решения (со скиллами, запуском терминальных комманд, форками сессий, субагентами и т.д.), которое может полноценно работать с аудио (= замыкая фидбэк луп) ——— UPD: Спустя два часа после написания текста выше: 1. Собран простенький самодельный агент вокруг gemini на 300 js строк, с агентным циклом, интерактивностью, fork/edit/resume и проверен подход 2. Это все перенесено в PI в виде экстеншна, который патчит тул чтения файлов (он там by design умеет и текст читать, и бинарные данные) Короче, теперь добавить своему агенту "уши" можно в 1-2 строки:

npm install -g pi-agent

pi install git:github.com/toolittlecakes/pi-gemini-audio-read

(не забываем потом /login → google → api key и выбрать модель gemini-3.5-flash) Где нужно: генерация музыки, качественные аудио переводы, работа с voice cloning, монтаж аудио (и видео, если это подкаст) Ограничения: 20мб на файл – не добавлял загрузку файлов через file api. И нет видео инпута

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

Мускриптор: Audio To MIDI Kyutai(да, те самые, с реалтаймовым голосом) вместе с MireloAI выпустили MuScriptor - открытую модель, которая превращает готовую песню в набор отдельных MIDI-партий. Она умеет «услышать» барабаны, бас, клавиши, вокал и другие инструменты прямо из финального микса, Без Исходных Дорожек. Еще раз - в отдельные MIDI-дорожки для разных инструментов. Причем ей не нужны исходные мультитреки - она работает прямо с финальным сведенным миксом. Демо: https://muscriptor.kyutai.org/ Код: https://github.com/muscriptor/muscriptor Папира: https://arxiv.org/abs/2607.08168 А теперь представим: берем трек из Суны, разбиваем на МИДИ, суваем в Суну. Аранжировщики, чо. Для Гиков:

MuScriptor обучали в три этапа. Главная проблема музыкальной транскрипции в том, что почти не существует больших наборов данных, где готовая песня идеально размечена по нотам и инструментам. Поэтому сначала исследователи использовали около **1,45 млн MIDI-файлов**, в которых вся эта информация уже содержится. Из каждого MIDI во время обучения автоматически создавались десятки вариантов звучания: менялись инструменты, темп, тональность и громкость, после чего композиция **озвучивалась с помощью более 250 различных виртуальных наборов инструментов**. Благодаря этому одна и та же мелодия каждый раз звучала по-новому, а модель училась распознавать музыку в самых разных вариантах исполнения. Но синтетическая музыка слишком отличается от реальных записей. Поэтому второй этап — дообучение на **170 тысячах настоящих треков** (более 11 тысяч часов аудио). Перед этим MIDI автоматически синхронизировали с живым исполнением, чтобы ноты максимально точно совпадали с записью. В основе MuScriptor лежит Transformer, который получает спектрограмму аудио и генерирует последовательность MIDI-событий: определяет, какие ноты звучат, когда они начинаются и заканчиваются, а также каким инструментам принадлежат. Модель также может учитывать заранее известный список инструментов в композиции, что заметно снижает количество ошибок. Финальная настройка выполнялась с помощью **reinforcement learning** на 300 тщательно проверенных композициях. Вместо оценки отдельных нот модель училась максимизировать качество всей транскрипции целиком. Именно сочетание масштабного обучения на синтетической музыке, большого объема реальных записей и RL позволило MuScriptor добиться высокой точности на сложных коммерческих треках.

@cgevent

В большинстве своем при поиске latency метрик мы находим общую latency = написал текст/сказал текст и получил аудио обратно. Однако за этим стоит не только большая доля инженерии, но и модули модели. Метрики, которые мы здесь рассмотрим: • FTL - first packet latency • TPP - first packet decode • DEC - mean packet decode • FPL - first packet latency • RTFx - audio_duration / processing time - общий throughput пайплайна Чаще всего работаем с пайплайном: текст -> LM based TTS - - - > audio codebook tokens - - - -> Codebook based Vocoder FTL - это путь от текста к первому audio codebook token. Это может быть как и один токен, который генерит большая модель, так и sequence токенов, которые генерит какой-то depth transformer, а может быть вообще multi-token generation от главной модели. Так или иначе на выходе только дискретный токен / латентный вектор. На эту метрику влияют кроме всех прочих приколюх модели и параметры интеренса. Например, сколько буковок вообще нужно ждать, чтобы начать генерить. Или сколько буковок передавать как lookahead, чтобы аудиотокены получались лучше. TPP - это путь только вокодера. Получили аудио токены - получили первый audio patch. У этого пути может быть отдельный cuda stream. Здесь также главную роль играют "accumulation" параметры. Например, сколько токенов нужно подсобрать чтобы сделать один pass вокодера? —— Но также именно здесь есть важный дизайнхук, который всегда люди делают по-разному. Как декодировать последовательность, чтобы не было странных звуков между патчами😒 Многие это делают декодируя всю предыдущую последовательность. Кто-то собирает n прошлых секунд и отправляет именно их. Кто-то использует kv cache, что часто идентично. Каждый из них влияет на latency. Именно это design choices отражаются на DEC метрики, так как один пасс через vocoder может потом линейно вырости и будет казаться, что вокодер вместо 50ms почему-то стал тратить 200ms, а все потому что мы передали ему весь предыдущий контекст. —— Все метрики выше влияют на FPL, как раз то, что большинство юзеров называют latency. Или вот эта задержка между тем как вы что-то сказали и бот ответил вам в ответ (здесь мы считали только TTS часть). Большинство компаний стремятся к тому, чтобы это значение latency было меньшее 100ms 😌 В борьбе за этим что только можно и нельзя использовать. При этом важно и смотреть на общий RTF, так как многие (в том числе и я) могут занижать FPL с помощью более маленького контекста, lookeahead'a и тд, а потом уже кормить модель нормальным контекстом🙂. Ну и конечно мы оставляем за большими скобками хитрые вещи по типу filler words или заготовленные фразы, чтобы не казалось что модель долго думает.

А с каким latency говорите вы? Я иногда с 300ms, а иногда с -100ms (ну знаете когда собеседник уже слишком тянет и ты все уже понял)

Подборка инструментов для создания VST эффектов ChatDSP Плагин Ableton Live, превращает текстовые запросы в звуковые эффекты и инструменты. Работает через ИИ, создаёт до 48 настраиваемых параметров. Стоит $10, требует API-ключ для работы с ИИ Amorph Бесплатная штука для создания собственных плагинов через текстовые подсказки. Работает в популярных DAW как VST3 и AU. Можно делать инструменты, эффекты и MIDI-плагины. Сейчас в бете, но уже можно юзать Pluginmaker.ai Веб-сервис для создания плагинов прямо в браузере. Можно тестировать через MIDI и секвенсор, потом скачивать готовый плагин. Есть маркет для продажи своих творений. На бесплатном тарифе дадут потестить ваши плагины в браузере #vst #text2vst #ableton

В Google Pixel хотят запихнуть "ИИ-Шазам" для всего вокруг 9to5Google покопались в свежей версии Android System Intelligence для Pixel 10 и нашли там одну забавную штуку - фичу Audio Memory (кодовое имя "blueflax", это такой цветок). Суть такая. Телефон пассивно (но активно!) весь день слушает всё вокруг - музыку, разговоры, всё подряд - потом расшифровывает и делает заметки. По сути, это эволюция "Now Playing" - фирменной фичи Пикселя, которая распознаёт музон и выводит название на экране блокировки. Только теперь вместо трека будет "Вы обсудили с Васей правки к договору" или типа того. Про приватность: аудио на сервера Google не летит, всё обрабатывается на устройстве через Private Compute Core. Здесь мы опять упираемся в нюансик, что собеседник о данной фиче на вашем телефоне знать не будет, но эта общая проблема всех подобных ИИ-штук, так что ладно. Пиксель давно позиционируют себя как "самый умный Android", и их киллер-фичи - как раз такие бесшовные ИИ-примочки под капотом. Pixel Watch умеет мониторить здоровье, Pixel Camera делает неплохие "вычислительные фото", а сам Pixel теперь ещё и будут помнить всё, что вы слышали. Вторая память со строенным "мета-ассистентом", которую не надо специально запускать. Фичу пока ещё не анонсировали, только tech-журналисты строчки в коде нашли. Так что, до релиза может что-то поменяться. Но направление понятное: устройства будут соревноваться в бесшовности юзерской пользы и точечности сценариев. Сервисы, которые слушали все разговоры юзеров и раньше, но ничего не показывали на экране, такие: 🫢🫢🫢 Фичизм