32 и 64 бит сегодня (2015), о бриджах и пр.

  • Автор темы Автор темы Wham_48
  • Дата начала Дата начала

Wham_48

Sneiro Member
15 Дек 2006
8.278
5.851
113
46
Валдай-Минск
Добавлено - ссылка на основной топик по jbridge: http://rmmedia.ru/threads/53532

========================
Вот задумался таки о переходе на 64 бит. Просто как уже говорил, нравятся многие старые плаги, и всегда хотелось избежать разных доп.костылей типа дж-бриджей (и не часто использую контакт библы жирные), но всё ближе тот момент когда придётся это сделать, недавно вот вышел UVI Falcon например, и он только в 64бит (ага). Ещё тот же семпл танк третий, хотя не жалею о нём, но тенденция похоже уже вырисовывается.

Просто мне досих пор кажется что 64бит (как и вст3) всё ещё несколько сыроват )). Неудивительно, некоторые конторы относительно недавно обновились в него. Но в тоже время я допускаю что несколько выпал из жизни, т.е. прогресса.

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

И хочется услышать отзывы о работе JBridge на сегодня - как справляется со своими задачами, хорошо ли например синтедит-плаги бриджит, нет ли проблем с автоматизацией при этом, не повышает ли это жручесть, или ещё каких камней.
 
Последнее редактирование:
Уже года полтора ТОЛЬКО на 64Bit Reaper-е и плагинах.
32 Bit остался наверное один плагин - Freeverb и Blockfish.
Использую их через JBridge, хотя у Рипера есть и родной бридж. JBridge ни разу не подвёл, а с родным бриджем пару раз были проблемы.
У Freeverb в общем то есть 64Bit заменитель - Freeverb Too - Но он мне кажется несколько иным всё-же, не полный аналог.
Blockfish начал в проектах менять на Slate-овские компрессора.
На заре перехода сравнивал 32 и 64 Bit близнецов - не заметил НИ КАКОЙ РАЗНИЦЫ ни в чём!
 
Просто мне досих пор кажется что 64бит (как и вст3) всё ещё несколько сыроват
1. 64бит - это просто отодвинутая граница используемой памяти. И ничего более. в этом контексте.
2. VST3 - да и сам по себе VST - настолько замороченный SDK, тащащий из глубины веков тонну резиновых костылей. Но 3я версия позволяет делать кошерные вещи в плагах, касательно как удобства работы, так и скорости.
 
  • Like
Реакции: Oliver_Cray
Спасибо за ваши мнения, это важно. Про родные бриджи хостов (рипер, кубейс) тоже слышал, и да, что дж.бридж получше тоже.
Ок буду пробовать.
64бит - это просто отодвинутая граница используемой памяти. И ничего более. в этом контексте.
В плане работы алгоритма плагинов я тоже понимаю что разницы нет. Но вот как воспринимает работу любого не родного по битности процесса сама операционная система, тут чёрт его знает.
Может даже так получиться (а я пользуюсь 64бит WIN, а в ней 32бит daw) что даже наоборот - не хуже а лучше будет, ну мол - 32битный процесс может быть тоже както "бриджится" виртуально 64-битной системой, забирая пусть на мизер но доп.ресурсы. А может быть и нет ничего такого.
 
Про родные бриджи хостов (рипер, кубейс) тоже слышал, и да, что дж.бридж получше тоже.
У меня как раз с точностью до наоборот почему-то. С некоторыми плагами jBridge очень здорово глючил, при этом родной риперовский - ну просто песня, никаких проблем.
Правда, давно это было (в самом начале 4-го Рипера), как сейчас обстоят дела с jBridge не знаю. х86 плагинов практически нет в системе, а те немногие, что остались (5-6 штук емнип) бриджатся Рипером.
 
Правда, давно это было (в самом начале 4-го Рипера)
Да, и дж.бридж обновился какраз на днях. Но ок, учтёмс.
[DOUBLEPOST=1446570033,1446569867][/DOUBLEPOST]ГЗ
Мне на квр посоветовали ещё такой вариант - пробриджить Фалкон 64>32 ))) Незнал чесно говоря что дж.бридж так умеет. Но это так, как на крайний случай.
 
Win7x64 Pro, Cubase 7x64. jBridge v1.5. Поначалу пользовался встроенным в хост бриджем - периодические затыки, "всхлипы" и пр. заставляли нервничать. jBridge избавил от этой напасти напрочь. Просто кайф! Ни с одним из 32-битных плагов/синтюков нет проблем. jBridge намеренно не обновляю. А зачем, если и так все летает.)
 
В очередной раз убеждаюсь, насколько все в жизни индивидуально...

Начитавшись в свое время отзывов о прелести jbridge, при переходе на 64-битную систему забриджил им все 32-битное - и стал регулярно выхватывать таблички о том, что краш хоста произошел по вине jbridge.

Переставил плаги, оставил на милость штатного бриджа :) - все заработало как часы :)
Единственное исключение - штатный не справился с двумя старыми инструментами от U.S.B., которые неожиданно понадобились :)

После танцев с бубном вспомнил о джейбридже, который и решил проблему.
Возможно, jbridge в больших дозах :) плохо переносится - то ли хостом, то ли системой в целом.
 
Последнее редактирование:
  • Like
Реакции: AslashA и diggidon
В плане работы алгоритма плагинов я тоже понимаю что разницы нет. Но вот как воспринимает работу любого не родного по битности процесса сама операционная система, тут чёрт его знает.
все в кучу.
есть 64битный процессинг - это расчеты с 64 битной разрядностью (это как 16 и 24, только 64, бгг). То есть просто точнее цифры, используется процессором. можно сделать хоть 256 разрядов, вопрос насколько быстро будет считаться.
есть 64битная архитектура - это способность приложухи использовать больше 2 гигов оперативки.
Может даже так получиться (а я пользуюсь 64бит WIN, а в ней 32бит daw) что даже наоборот - не хуже а лучше будет, ну мол - 32битный процесс может быть тоже както "бриджится" виртуально 64-битной системой, забирая пусть на мизер но доп.ресурсы. А может быть и нет ничего такого.
ничего такого нет.
 
@Wham_48,
Очень долго сопротивлялся переходу на 64 бита и до последнего юзал 32-х битную хрюшу, но всё же не так давно, пару месяцев как, пересел.
...Ибо возможность юзать больше памяти взяла верх...
Собственно пока не пожалел..
 
32битный процесс может быть тоже както "бриджится" виртуально 64-битной системой
так и есть - 32-битный процесс эмулируется через 64-битную c:\WINDOWS\System32\wow64.dll в замкнутой виртуальной машине

есть 64битная архитектура - это способность приложухи использовать больше 2 гигов оперативки.
а еще это 16 регистров у процессора вместо прежних 8 - при правильной оптимизации машинного кода компилятором это дает некий прирост производительности
 
  • Like
Реакции: CakeWorker и bloodykot
После перехода на 64 бит отказался от всех 32-битных плагов. Не страдаю от этого.) Всегда можно найти замену. По крайней мере практически всему, что мне было нужно, нашёл. Чаще стал использовать плаги встроенные в рипер, в том числе JS.
 
Нужно учитывать то, что jbridge работает как отдельный процесс для каждого запущенного в его режиме плагина, поэтому если плагин завис - падает только этот плагин (процесс), остальное остаётся на месте, включая хост с открытым не спасённым проектом ).
Встроенный же в кубэйс бридж - если плагин падает (например виртуал гитарист), падает всё, включая кубэйс. Не знаю как работает бридж в рипере, но в кубе я включаю всё 32x битное строго через jbridge.(А вообще давно уже ничего не запускаю в кубе, работаю в вене :-))
 
  • Like
Реакции: Igor Leontyev
Не знаю как работает бридж в рипере,
все 32-битные плагины в одном отдельном процессе. Собственно как у всех - знаю только Pinnacle как-то умудрилась запускать 32-битные плагины прямо в 64-битном процессе через хитрые адаптеры. Беглого реверсинга не хватило, чтоб понять как им это удалось - надо будет глубже копнуть…
 
все 32-битные плагины в одном отдельном процессе.
Можно и каждый плаг в своём отдельном процессе, и х64 плаги точно так же...
Теоретически это может быть полезно, если какой-нибудь особо ценный плаг подглючивает - запускать его в отдельном процессе во избежание падения хоста или бриджа с другими плагами. Практически же у меня таких плагов нет.
 
если какой-нибудь особо ценный плаг подглючивает - запускать его в отдельном процессе во избежание падения хоста или бриджа с другими плагами.

Господи, ну естесвенно! Почему я сразу не додумался! У меня же проблема что все плаги от Изотоп (х64) открываются не за 1, а за 3 секунды. Пока дождешься... Через бридж нормальная 1 секунда.
А то я из-за этого держу все плаги дублями х86 и х64, и работаю в Рипере х86, пока проект не вырастет до 3 гб в оперативе, потом иду на х64. Иначе эти тормозные открывания интерфейсов заболтали уже).
Ну все. Теперь будет шастье)))) Вот уж глупости бывают, признаю.

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

Не будет шастье, короче. Один фиг в Рипере х86 все быстрее. Черт.
 
Последнее редактирование:
  • Like
Реакции: fruitcore
Да, я забыл упомянуть почему ещё осадок от 64 остался - Макс\Мсп (от cycling74 который) имеет давние ограничения в 64 битной версии (некоторые модули из набора нельзя использовать, связанные с джиттером, т.е. работой с видео, и с квиктаймом), почему - невкурсе, вероятно какаято сообенность портирования макс среды однажды с мак-а в вин.
Вот тут есть инфо : https://cycling74.com/support/faq_max7/#3
(а тут в самом низу список модулей неработающих в 64 http://cycling74.s3.amazonaws.com/support/version_6_1_0.html )
Но правда тут речь о 6-ой версии идёт, насчёт седьмой незнаю, но если не ошибаюсь там тоже самое.

ГЗ Замечал кстати что среди пользователей аблетон лайва довольно нередко попадаются юзеры 32бит версии, может какраз с этим чтото связанное, т.е. с работой m4l, чёртего знает.
[DOUBLEPOST=1446665493,1446664820][/DOUBLEPOST]
Такое только в х64 Рипере. Это пипец какой-то. Никто не может сказать, почему.
Интересно, надо будет потестить в студиоване\аблетоне. Какраз имею парочку Изотопов.
 
т.е. работой с видео, и с квиктаймом), почему - невкурсе
квиктайм умер 32-битным и тем, кому сильно нужно, приходится лепить к нему бриджи - а остальные забивают…
 
проблемы с изотопами в Рипере далеко не у всех. А скорее даже совсем не у всех
Ну да, хорошо если частный случай, но полезно собрать всю инфу в кучу о возможных проблемных местах, чтоб самому потестить.
У мня вон тоже например с Acon Digital Verberate цпу-аномалия какаято, судя по тому что никто больше на подобное не жаловался (кстати виндовс переустановил, максимально акуратно)) на чистой системе первое что для теста это верберейт поставил - тоже самое).

Недавно ещё был прикольный случай, с PSP Audioware плагином, взял по скидке Pianoverb2, помня насколько psp всегда легковесными были и неглючными, думаю пусть будет такой лайтовый ревер с фризом. Инсталил, открываю - лаги страшнейшие, всё повисает на секнд пять при попытке тронуть гуй плагина (хотел фриз - получил)))). Закрываешь окно - всё отлично. Мозг сломал вообще, инсталил по всякому и в обоих битностях, видео дрова переинсталивал, всё тоже самое. Стал смотреть что происходит через Process Monitor майкрософтовский - и оказалось при зависании есть обращение к цветовой схеме (ICC профилю или как там), а я там что-то накрутил до этого, монитор настраивал, ничего не поменялось и оставил как есть свои "настройки". Так вот погуглил\подкрутил, и вроде как в дефолтное положение вернул - и о чудо плагин отпустило! Вобщем из за такой вот фигни бывает. Хотя остальные плагины открывались при этом нормально.
 
Что вы вернули в дефолт конкретно?
Короче, сейчас уже точно не скажу последовательность действий (т.е. винду сейчас переставил и больше в цветовые профили не залажу), но находится это в: Разрешение экрана>Дополнительные параметры>Управление цветом>Управление цветом
И там в этих трёх закладках я чегото накрутил нетого. А потом поубирал лишнее, и чегото там поприменял чтоб было "по умолчанию" на первой закладке (после чего рассосалось).
[DOUBLEPOST=1447427384,1446731877][/DOUBLEPOST]Чиорт, знакомство с дж-бриджем прошло не очень удачно. После закрытия (т.е. выгрузки) бридженого плагина, секунд через пять стабильно вылазит сообщение о краше бриджа. Что впринципе не влияет на работу хоста, и вобщем не мешает непосредственно работе бридженого плагина, но как факт. Пробовал два разных плагина (синтедит), аналогичный краш после каждого удаления плагина с трека.

Софтину купил если что, версия последняя 1.74, ничего в настройках ни менял, следовал инструкции (всё запускается от админа само собой).
Что бы это могло быть ? Опций смотрю там много, пока никуда ни лезу.
 

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