Работа с разными значениями латенси

Испанский ГалстоГ

▬▬▬▬▬▬▬▬
20 Янв 2006
2.871
911
113
44
г. Саратов
Нельзя сказать что проблема связана именно с Cubase/Nuendo, потому что другие программы-хосты ведут себя на моем сетапе так же.

Вопрос в следующем:


У меня не очень мощная машина (прескот 3Ггц) и я работаю в основном так: закончил партию - перегоняю ее в вавку или делаю freez. Посему до конечного миксдауна проекта у меня происходит множество операций миксдауна. Важным моментом является то, что при нарастании проекта размер задержки в настройках асио приходится все время увеличивать. Т.о. разные куски аранжировки оказались сбаусенны при разных значениях латенси. Впринципе логично бы на это и не обратщать внимания НО выявилось следующее на моей конфигурации:


допустим есть проект с темпом в 125-130. Вст инструмент играет четвертыми нотами аккорды. В инсерт вст инструмента ставлю фленджер из пакета waves, пресет slow rotation. Устанавливаю авто-тап (кнопка"А") и значение 2. При задержке в 2 мс - все нормально. при задержке 30-40 мс и более - играет неровно, тоже самое после фриза канала или после миксдауна. Причем если с вэйвовским флэнджером это слышно явно и четко (большая степень ошибки), то с другими вст - не так явно, либо вообще не слышно, либо этот эффект начинает проявлятся при экстремально больших значениях латенси (не используемых реально) . Еще очень хорошо этот эффект проявляется на трилоджи.


Таким образом выявилась проблема:

ПРИ БОЛЬШИХ ЗНАЧЕНИЯХ ЛАТЕНСИ СОБЫТИЯ, ПЕРИОД МЕЖДУ КОТОРЫМИ МЕНЬШЕ ЗНАЧЕНИЯ ЛАТЕНСИ ИГРАЮТ НЕРОВНО. Самое обидное что это и во фризе так и после миксдауна.

Посему моя работа с множествами промежуточных миксдаунов приводит к накоплению этой ошибки. Видимый выход из проблеиы - все время переключать латенси на минимальную и все просчеты производить в ней. Но запарило меня это открытие сильно.

Друзья, попробуйте прогнать такой тестик с waves фленджером на своей конфигурациии кто нибудь. А то грешу - что это проблема драйверов emu.
 
Тут проблема разработчиков плагов, не все корректно передают данные о своей внутренней латенси хосту, наглядный пример трилоджи, у него конкретный баг с таймингами при буфере больше 1024, так что или ищи плаги у которых этого бага нет, или уменьшай латенси при фризе, других вариантов что то не видно.

з.ы. по собственному наблюдению практически все плаги при буфере до 512 работают корректно, если выше - с некоторыми начинаются проблемы.
 
Vosk подозреваю что ты хочешь посоветовать. но не думаю что покупка лицензии 4-ки решит эту проблему ))

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

вот пример такой девиации:

http://www.sendspace.com/file/3o3uiw

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

я к тому, что в процессе работы микродевиации накапливаются и в динамичных танцевальных вещах может потерятся грув и т.д.
 
<div class='quotetop'>Цитата</div>
я к тому, что в процессе работы микродевиации накапливаются и в динамичных танцевальных вещах может потерятся грув и т.д.[/b]
ну тут как бы совет - работать с одной и тойже латенси,
 
Вот есть такое
View hidden content is available for registered users!
Он как раз предназначен для компенсации неверной задержки в плагах. В рипере и т3 правильно работает.

Сейчас не доступа к кубу . Если есть желание с ним можно провести такой тест.
В пустой проект импортируем любую вэвку.Дублируем трэк и меняем его фазу.При воспроизведении на мастере получаем 0.Терерь вставляем в первый трэк этот плаг и выставляем Sample и Report задержки
в 30 отсчетов и смотрим что получится на мастере.Дальше меняем размер ASIO буфера и опять слушаем.
 
Нет, я сначала с одной латенси арнаж делаю, это где есть необходимость рилтайм играть, а как только до фриза доходит, то увеличиваю и в ней уже дальше и работаю, к этому моменту как правило рилтайм партии уже писать не надо, а только редактирование и сведение остаётся.

з.ы. в особо тяжёлых случаях где надо инструменты типа LPC с амплитюбом юзать - просто делаю промежуточный микс, закидываю его в другой проект, и уже в другом проекте нужные партии прописываю, а аудио результат - обратно в оновной закидываю для микса.
 
ужаснах :blink: .

P00H а почему не сделают чтобы при миксдауне он ставил например 1024 задержку для всех и точка. там же реалтайм скорость не нужна - а в относительных единицах можно сколь угодно тяжелую для процессора задачу разложить на N количество времени и просчитать.
А в реальности миксдаун - это чисто тупо сохранение в файл того же самого потока что и реалтайм играет, просто звук отключается. Кстати у меня было ситуация в нуендо когда на очень емком проекте при латенси в 2 мс миксдаун не захотел делаться, написал типа ресурсов не хватает. пришлось до 20 увеличивать. вот такой вот замкнутый круг...


кстати в нуендо есть что-то такое - constant delay compinsation
 
<div class='quotetop'>Цитата</div>
P00H а почему не сделают чтобы при миксдауне он ставил например 1024 задержку для всех и точка. [/b]
а при офлайн миксдауне хост никакой латенси помоему и не использует кроме известного ему от инструмента значения для компенсации задержки, на сколько ресурсов проца хватает, он с той скоростью и миксит если галку fast поставить, другой вопрос что если ему инструмент это значение неправильно выдал - то и результат будет соответствующий.
<div class='quotetop'>Цитата</div>
при латенси в 2 мс миксдаун не захотел делаться, написал типа ресурсов не хватает. пришлось до 20[/b]
чёт у тебя какие то экстремальные значения, :blink:
 
как я понимаю, в реалтайме процесс происходит так:
миди команда дает инструкцию вст сгенерить какой либо звук. время генерации и возврата потока в хост и есть латенси. в реалтайме чтобы подогнать одновременно все к сетке нужно возвращать значение латенси, оно у всех инструментов разное и логично что общая задержка звука микса будет определятся самым тормозным плагином. По такой логике нужно было бы сделать огромню задержку чтобы любой плаг бы в нее вместился. Но чтобы иметь возможность играть более "легкими" плагинами с меньшей латенси эта система автокомпенсации и придумана. другого назначения ей я не вижу (ну еще железки есс-но подключать). Это офиительная задумка программистов и очень полезна для реалтайм игры, но к миксдауну какое отношение имеет не понимаю. - В оффлайне же ничто не мешает сначала получить нужные потоки, потом поставить их правильно по сетке!!! - но почему то этого не происходит, сделано же в программе это по видимому по другому (по пути легчайшего сопротивления) - миксдаун просто пишет звук в файл. И если что в реалтайме по какой либо причине заикнется-споткнется (по причине ли плага, или просто процессор не справится) - все в микс запишется.
 
<div class='quotetop'>Цитата</div>
а при офлайн миксдауне хост никакой латенси помоему и не использует [/b]

Нет, использует назначенный буфер. Чем больше значение буфера, тем быстрее считается миксдаун, например.
 
Еще замечал из этой оперы такую хрень:



В данном примере семпл закрытого хета следует за открытым и оба сэмпла в одной группе, т.е. закрытый хэт, закрывает висящую октрытую ноту. На слух эти дырки заметны.

Все настройки одинаковы, просто срендерено два раза с задержкой 10ms и 50ms.

Это драм машинка LM4-II. Такую же хрень замечал в Халионе и Батарее, под разными картами и даже в других хостах (Лоджик, Сонар). Такая же хрень случается с Трилоджи, если вклучить режим монофонии.
 
А я всегда с буфером в 512 работаю, видимо потому и не замечал ничего, или просто невнимательным был? Кстати не подскажете где хороший LM4 взять, а то инсталяцию потерял...?
 

Сейчас просматривают