Не хватает полифонии в Кубе 6.5

[composerr]

Впервые с таким сталкиваюсь.

Проект в Кубе 6.5, не очень тяжёлый, с использованием библиотек в Контакте 5.1
Начинают пропадать голоса как будто не хватает полифонии (как в синтезаторах).
Може где чего щёлкнул не того?

Заранее спасибо за ответы.

 

[Vosk]

Начинают пропадать голоса как будто не хватает полифонии (как в синтезаторах)

ну в контакте и не хватает Поставь 256 на каждый патч, например.

 

[composerr]

Контакт под каждый патч свой, полифонии там с большим запасом (все партии, кроме ф-но и ударных - одноголосные).

Стоит добавить, что ещё пару дней назад в этом же проекте (да и в других) таких проблем не было. Мне кажется,это в Кубе что-то глобально включилось. Вот только не въеду что...

 

[Vosk]

засними датчики контакта в режиме плэй во время пропадания звуков. Например так:

вот этой утилитой например

 

[vip76]

Сталкиваюсь переодически с таким. Попробуй в свойствах загруженного инструмента увеличить кол-во голосов. Чревато, что будет конкретно загружать процессор. У меня на i7-3930 при алгоритме TIME MACHINE PRO - HQ Mode - Keep Formants начинаются затыки.

 

[composerr]

Щя заснять нечем, но вижу следующее:
На партии ф-но максимум 70 при выставленных 256.
Остальное - бас, ударные, валторны, струнные - от 1 до 6-7.
Тем более - контакт отдельно на каждый инструмент.

Опа!!!

Короче, какой-то бред... Пока писал и ковырялся - проблема пропала. Похоже, это была реакция на зашкал индикатора Disk.

 

[Rusik]

Сорри, немного оффтоп - а зачем на каждый инструмент отдельный контакт?

 

[vip76]

Сорри, немного оффтоп - а зачем на каждый инструмент отдельный контакт?

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

 

[composerr]

Так точно! Насколько я знаю, тесты показывают, что разница между 16 инструментов = 1 Контакт и 16 инструментов = 16 контактов по ресурсоёмкости не такая значительная как может показаться.

 

[Rusik]

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

имеется в виду Instrument Track? Ну это понятно, с одноканальным инструментом удобнее, но с многоканальным...

Насколько я знаю, тесты показывают, что разница между 16 инструментов = 1 Контакт и 16 инструментов = 16 контактов по ресурсоёмкости не такая значительная как может показаться.

Вот не проводил, конечно, никаких подобных тестов, знаю только, что каждая открытая единица VST - это сразу "отъедание" куска памяти. Вот сейчас провел эксперимент - Контакт, открытый через инструмент-трек - примерно 35-40 мБ памяти, а Контакт, открытый через F11 - около 50 мб. Это всё без загрузки библиотек - только сам VST. То есть, если открыть Контакт один раз - это 50 мб - плюс -Объем-всех-библ. А через Инструмент-трек по одному - Объем Всех библ ПЛЮС каждый раз по 35-40мБ ))

 

[vip76]

Контакт, открытый через инструмент-трек - примерно 35-40 мБ памяти

Имея оперативки 16GB \ 40MB = 410 Контаков. Думаю комфорт в работе важнее, чем экономия в 40 MB RAM, скорее процессор и хард диски не потянут такое кол-во, прежде чем удастся навтыкать столько Контактов =)
Если даже один инструмент весит под 10 гиг, то вопрос скорее нужно решать объемом оперативки, 40 мег тут не спасут =)

 

[Rusik]

Думаю комфорт в работе важнее, чем экономия в 40 MB RAM,

сорри, таки не понимаю пока, в чем комфорт? )

 

[vip76]

сорри, таки не понимаю пока, в чем комфорт? )

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

 

[composerr]

А о чём спор, собственно?
Например, мне удобнее делать через Instrumental track и кидать на контакт те эффекты, которые мне хочется, не заморачиваясь с маршрутизацией, миди-треками, выходами и т.д. (как при загрузке одного контакта через F11). Работал и так и сяк, пришёл к выводу, что так мне лично удобнее. И похоже, что загружая каждый раз контакт как новый плагин - он не ест каждый раз оперативку. Как и, к примеру, любую библиотеку можно один раз загрузить, а затем раздублировать на разные треки - от этого нового места в оперативке она не ест.
И ещё. Когда-то делал большой проект, который мой комп не тянул. Переделал "под F11", продолбался не один час, пока всё перенастроил - всё равно не потянул, ресурсы почти не освободились. Пришлось фризить.
С одним аранжировщиком сотрудничаю - так он переделывает мои проекты под F11 всё, ему так удобнее...
Дело вкуса.

 

[Rusik]

мне удобнее делать через Instrumental track и кидать на контакт те эффекты, которые мне хочется, не заморачиваясь с маршрутизацией, миди-треками, выходами и т.д. (как при загрузке одного контакта через F11). Работал и так и сяк, пришёл к выводу, что так мне лично удобнее.

Конечно, так удобнее - но если речь идет об одноканальных VST.

И похоже, что загружая каждый раз контакт как новый плагин - он не ест каждый раз оперативку.

Вот именно что ест (как и любой VST) - я это знал и раньше, но сейчас специально открыл в проекте (правда, 5-й Куб) несколько Контактов - каждый съедает по 40-50 мБ сразу после открытия ) Любой плагин при открытии ест оперативку, это давно известно )

Как и, к примеру, любую библиотеку можно один раз загрузить, а затем раздублировать на разные треки - от этого нового места в оперативке она не ест.

Это непонятно. Что значит - библиотеку? Библиотека - это не VST, её нельзя "раздублировать на разные треки" ) Или я чего-то не понимаю )

 

[composerr]

Да, вначале контакт берёт где-то метров 100, каждый следующий - где-то по 40.
Ну, это некритично при наличии 64 битной системы и достаточного количества оперативки.

 

[vip76]

так, короче вот вам наглядный пример =) дело привычки, оно конечно понятно, но я не успел привыкнуть к этому нагромаждению треков и уж лучше потрачу несколько сотен оперативки, чем ломать потом мозг =)))



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

 

[composerr]

А я раньше вот так вот нагромождал... Потом сам чёрт ногу сломит, чтобы воткнуть несчастный компрессор куда-то - надо было иногда перерыть весь проект

 

[ruslan.st]

Интересный вопрос. Попробовал сделать тест в Рипере. В одном проекте загрузил 5 инструментов в один Контакт и назначил выходы из него. В другом загрузил те же 5 инструментов в 5 Контактов по отдельным трекам.
В итоге в первом варианте памяти использовано 1509MB.
Во втором - 1638MB
Разница всего в ~130MB, т.е. каждый лишний Контакт дополнительно расходует около 26MB памяти.

 

[vip76]

Интересный вопрос. Каждый лишний Контакт дополнительно расходует около 26MB памяти.

По моему, вопрос о мультиканальности теряет свою актуальность. Исключение - специфичные задачи, где нужно отдельные нюансы одного интсрумента расскидать на разные миди дорожки.
И барабаны конечно требуют мультиканальности, но в идеале я бы хотел видеть инструмент, который поддерживает VST (AU) в своих встроенных инсертах, и тогда вообще про эти пережитки забыть можно =)

 

[Rusik]

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

в идеале я бы хотел видеть инструмент, который поддерживает VST (AU) в своих встроенных инсертах

я опять же, наверное, не понимаю чего-то ) Тот же Контакт позволяет раскидать все загруженные библы на 16 разных выходов микшера - на каждый из которых можно повесить отдельную обработку - или же в самом Контакте можно повесить на каждый канал\выход\библу встроенную обработку - или я не понимаю проблему? )

 

[vip76]

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

Вроде же все доводы обозначили и даже скриншот прилагается =)))
Может привести свои доводы "за"? Чтобы не абстрактный спор с одной стороны был =)))

 

[composerr]

Тот же Контакт позволяет раскидать все загруженные библы на 16 разных выходов микшера - на каждый из которых можно повесить отдельную обработку - или же в самом Контакте можно повесить на каждый канал\выход\библу встроенную обработку - или я не понимаю проблему? )

Ключевой момент в словах "Контакт позволяет раскидать все загруженные библы на 16 разных выходов микшера - на каждый из которых можно повесить отдельную обработку". В Контакте надо делать переадресацию и ковыряться в нём со всякими ауксами. С вариантом 1 инструмент - 1 контакт этот момент, забирающий время и дающий дополнительный геморрой автоматически отпадает. Плюс чисто наглядно - работаешь с меньшим количеством дорожек, всё на месте и на лету. А иначе - миди команды надо прописывать на миди треке, а обработку надо накручивать на другой дорожке, на выходе микшера. Ну, как-то так...

 

[vip76]

Все равно не понятно ))

А можно поинтересоваться какой DAW вы пользуетесь и какой версии?

 

[composerr]

А можно поинтересоваться какой DAW вы пользуетесь и какой версии?

Русик говорил вроде, что 5й куб.

 

[vip76]

Русик говорил вроде, что 5й куб.

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

 

[composerr]

Именно. В 5м кубе уже можно вставлять отдельный инструментальный трек, как и в 6 и в 7.

 

[vip76]

Именно. В 5м кубе уже можно вставлять отдельный инструментальный трек, как и в 6 и в 7.

Ну это в свою очередь может объяснить предпочтения, т.к. 5й народный куб 32 бита, то память соответственно максимум 2-3 Гб, вот тут и надо думать на чем экономить.

 

[RockMeister]

vip76, давно существует jBridge, который позволяет VSTi видеть всю память, которую видит ОС.

 

[vip76]

vip76, давно существует jBridge, который позволяет VSTi видеть всю память, которую видит ОС.

А то я не в курсе, есть у меня легально купленный jBridge, но во первых не всегда он корректно работает, давно не обновляется, во вторых это еще одна прокладка, вместо использования напрямую всех функций 64 битного DAW, лишний геморрой. Учитывая что это используют, как попытку способа решение проблем с народным софтом, то это не преимущество.