Jbridge vst-адаптер

честно говоря не понимаю я , ребят ) желания себе огрести проблем с 64 битностью

почитав профильные форумы - я себе поставил 32 битный куб , под 64 винду семерку)
и пробриджил только экстремально жрущие семплеры..
благо у меня 16 гигов ....
скажете вот , есть ли реальный профит от перехода исключительно на 64 битный хост ?)

кроме гемора с вейвсами, и кучей других 32 битных плагов)
 
Последнее редактирование:
честно говоря не понимаю я , ребят ) желания себе огрести проблем с 64 битностью

почитав профильыне форумы - я себе поставил 32 битный куб , под 64 винду семерку)
и пробриджил только экстремально жрущие семплеры..
благо у меня 16 гигов ....
скажете вот , есть ри реальный профит от перехода исключительно на 64 битный хост ?)

кроме гемора с вейвсами, и кучей других 32 битных плагов)

Ну и я так же.
С самого начала причём:)
ИМХО- сейчас это лучший вариант.
 
+1
Но, если в 64-битном хосте реализован собственный бридж, и реализован нормально - то "пуркуа па"?
Иначе да, смысла париться и перелопачивать все бриджем - нет.

п.с.
Ну, например, попробовал x64 Reaper. Все работает нормально. С его бриджем.
 
Ой, только сейчас заметил, что тема в Кубейсовском разделе (нашёл её поиском).
У меня проблемы в Сонаре. В моём случае, плагины бриджатся в 32-х битной системе. С этой функцией я получил:
1. Большую стабильность - я бриджу глючные плагины, которые при вылетании не выбивают daw, а благополучно умирают отдельным процессом, и я продолжаю работать дальше.
2. Лучшее использование оперативной памяти - одним процессом Сонар занимает максимум 1.5 гига и начинает работать крайне нестабильно. С jbridge этого нет.
3. Несколько лучшее быстродействие Сонара (особенно на больших проектах). Точной причины не знаю, но могу предположить, что это из-за другой работы с оперативной памятью.

Чуть отвлёкся :) Вопрос по прежнему актуален:

Столкнулся с неприятной багой бридженого TheGlue (оба последних версий) - не копируются опции оверсемплинга другим инстанциям (Oversampling -> Copy To Others). Кто-нибудь сталкивался с подобным? Как решали? Или бридженые плагины по определению не могут общаться между собой?
 
Ну, например, попробовал x64 Reaper. Все работает нормально. С его бриджем.
+1
В последнее время всё поправили и теперь под бриджем не работает только то, что и без него не заводится xD
И с вейвсами проблем нет. Ни с айлочеными, ни с пиратскими.

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

Может просто Риперщики такие счастливцы
 
Ну не понимаю я таких разговоров.

И я.
Зачем мучаться? В чём вообще проблемы?
Работайте вы спокойно в 32 бита, и всё.
Пробриджить Контакт получается замечательно.
Если не нравится вин 7-64, есть 2003 сервер)))
 
Внезапно начались проблемы с Omnisphere. Первый запуск - все ОК. Второй (повторное обращение к GUI) - виснет примерно на 30 секунд, затем выдает ошибку опкода номер 14, после чего плагин работает некорректно (то ли не получает MIDI данные, то ли не выводит звуковой поток). Никогда такого не было. Пробовал переустанавливать плагин, удалял "бридженую" динамическую библиотеку, стирал записи из реестра в папке jbridge, которые связаны с Omni, снова "бриджил", не помогает. P.S. с прочими плагинами все ОК.
 
У меня было подобное с вэйвсами и рядом других плагов. На сайте джбриджа прочел, что можно включить separate gui или что-то в этом роде, вроде должно помочь.

---------- Добавлено в 10:06 ---------- Предыдущее сообщение было размещено в 10:04 ----------

Точнее, поставить галку Force Whole gui refresh и Pevent main host control...
 
Внезапно начались проблемы с Omnisphere. Первый запуск - все ОК. Второй (повторное обращение к GUI) - виснет примерно на 30 секунд, затем выдает ошибку опкода номер 14, после чего плагин работает некорректно (то ли не получает MIDI данные, то ли не выводит звуковой поток). Никогда такого не было. Пробовал переустанавливать плагин, удалял "бридженую" динамическую библиотеку, стирал записи из реестра в папке jbridge, которые связаны с Omni, снова "бриджил", не помогает. P.S. с прочими плагинами все ОК.
Была точно такая же проблема с омнисферой и jbridge 1.3
Обновился на jbridge 1.4 - там такой проблемы нет, омнисфера нормально работает с дефолтными настройками бриджа.
 
Точнее, поставить галку Force Whole gui refresh и Pevent main host control...
не помогает

Была точно такая же проблема с омнисферой и jbridge 1.3
Обновился на jbridge 1.4 - там такой проблемы нет, омнисфера нормально работает с дефолтными настройками бриджа.
У меня и так стоит версия 1.4

надо поставить эту галку и перезапустить плагин
Дядя Сережа, спасибо, теперь все работает! Странно, что раньше такого не было, может я ее случайно снял? Чудеса
 
Последнее редактирование:
Ага, чудеса прямо. Один советует - не помогает. Второй предлагает то же самое - и о чудо, помогло. :wacko2:
 
Обновился до 1.5

jBridge 1.5:

- fixed crash during startup in SAWStudio.
- fixed crash that could happen with Halion.
- Reduced memory usage ( Specially relevant if you're using a 32bit VST host )
- Unlimited number of inputs/outputs and all buffer sizes are now supported.
- Optimized resource usage.
- auxhosts should now quit after the main host on a forced shutdown ( thanks for the hint and the help, Jeremy! )
- added workaround for plugin scanning problem with Kore2.
- Other minor bugfixes.

jBridger 1.21:

- added option to reset origin and destination folders for bridging files.
In some situations, user was unable to access the desired folders, enabling this option on a new scan should clear the problem.
 
Еще одна приятная новость.. jBridge под макось уже делают. На сайте бета лежит уже)
 
у меня вот такой вопрос... система Win7 x64, хост куб 5 x32, запускаю забридженный контакт, загружаю в него три библиотеки алиша кейс... Диспетчер задас показывает загрузку памяти процессом 750Мб (хотя каждый инструмент 300Мб ест)... а вот когда запускаю три инсталляции контакта и в каждую загружаю по алише - каждый по 640Мб потребляет... это как? получается что у меня какое-то ограничение на один процесс?

и ещё вопрос: когда бриджу 64-битные плагины бриджер создаёт длл-ку с .32, так и должно быть? ведь если он делает из 64-битного плагина 32-битный получается что у него должно бть ограничение на количество потребяемой памяти? я может что-то не понимаю в принципе работы программы, но разве она не должна давать доступ плагину ко всей свободной памяти?

просвятите пожалуйста дурака!
 
у меня вот такой вопрос... система Win7 x64, хост куб 5 x32, запускаю забридженный контакт, загружаю в него три библиотеки алиша кейс... Диспетчер задас показывает загрузку памяти процессом 750Мб (хотя каждый инструмент 300Мб ест)... а вот когда запускаю три инсталляции контакта и в каждую загружаю по алише - каждый по 640Мб потребляет... это как?
Погоди, сейчас повторю твой эксперимент и гляну
хост Нуя4х32 но это неважно

---------- Добавлено в 17:18 ---------- Предыдущее сообщение было размещено в 17:10 ----------

хотя каждый инструмент 300Мб ест)... а вот когда запускаю три инсталляции контакта и в каждую загружаю по алише - каждый по 640Мб потребляет.
Ага, примерно так и есть)))
Точнее- 365 и 680
ну мне с 12 гб честно говоря это как-то до лампочки конечно...не стал бы обращать внимание даже.
 
  • Like
Реакции: kseile
Ага, примерно так и есть)))
Точнее- 365 и 680
ну мне с 12 гб честно говоря это как-то до лампочки конечно...не стал бы обращать внимание даже.
дык вопрос почему это происходит) значит есть смысл запускать каждый инструмент в отдельном контакте, раз у него какие-то ограничения на один процесс...
 
Vosk, :ireful2:
И по три компьютера всем покупать НЕМЕДЛЕННО с Виенной!:to_pick_ones_nose2:
 

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