Ability to load 32bits VST/i in 64 bits bidule

Post your feature requests/wishlist here

Moderators: davidv, seb@plogue

jobol
Posts: 1
Joined: Sat Apr 05, 2008 1:20 am

Ability to load 32bits VST/i in 64 bits bidule

Postby jobol » Thu Sep 28, 2017 6:26 pm

Hi,

Please consider adding the ability to load 32 bits VST/i in 64 bits Bidule without using Jbridge or any of the other bridging software.

I think there is a big gap in the market and that alone would be a reason for me to purchase Bidule.

Merci.

blackcom
Posts: 7
Joined: Tue Mar 11, 2014 2:35 pm

Re: Ability to load 32bits VST/i in 64 bits bidule

Postby blackcom » Thu Oct 05, 2017 8:07 pm

Slightly OT but DDMF Metaplugin3 just got this feature.

davidv
Site Admin
Posts: 1567
Joined: Tue Mar 02, 2004 7:23 pm
Contact:

Re: Ability to load 32bits VST/i in 64 bits bidule

Postby davidv » Thu Oct 12, 2017 9:39 am

Hello

There will never be bit bridging in Bidule sorry.
We are quite against the idea.
Its incredibly cpu inefficient and dangerous to real time performance/stability.
David Viens,
Plogue Art et Technologie Inc. Montreal.
http://www.plogue.com

ZergFood
Posts: 111
Joined: Fri Aug 21, 2009 3:39 pm

Postby ZergFood » Tue Oct 17, 2017 6:04 am

You can have it use asynchronous processing and delay by one buffer when bridging (jBridge has an option for this called "Performance Mode") which will make the CPU hit from bridging totally negligible (which is mostly in the inter-process signalling/waiting) and in some cases even offer superior performance (utilizes multi-cores better), but it does increase latency by one buffer though...

Stability is a weird one. Bitwig, for example, "firewalls" (i.e. bridges, no matter the mode) all plugins by default and does so for stability. Since each plugin gets its own separate address space/process, stability is actually much improved especially for more buggy plugins, even those not thread-safe. In fact, even if the plugin crashes, Bitwig still works perfectly fine and only that plugin crashes, and you can save the project (layout in Bidule) or restore only that one plugin. Bidule, on the other hand, is less stable in this respect (like any host that doesn't firewall/bridge) and you lose everything. I'm not sure where the stability myth comes from, probably from Steinberg since they're incapable of making a proper bridge and of course it's less stable with a crappy bridge like theirs (used to be).

Anyway, it is totally understandable if you aren't up to do it since I suppose it can be pretty time-consuming to make properly (and we have jBridge anyway), but I just wanted to clear out misconceptions.

davidv
Site Admin
Posts: 1567
Joined: Tue Mar 02, 2004 7:23 pm
Contact:

Re:

Postby davidv » Tue Oct 17, 2017 10:16 am

Stability comes from the way certain kernel drivers/RT APIs are implemented and specifically how well they tolerate blocking and yielding in the no-latency approach. (Pro tools drivers were particularly prone to BSODs when we started doing our bridge). (Note I don't believe anything that adds latency is worth talking about)

Yes we made (and still support) an IPC bridge from 2004 which is used when you load Bidule as a ReWire device, we know how hard it is to do well, and its not something we want to revisit when clearly everyone should be moving on to x64 only.

Also multiple address spaces is stupid. Many samplers like ARIA and Kontakt actually benefit from a shared address space for resource management. Since I work on both sides of the fence I had to explain the situation to many clients since bridges started appearing all over the place.

That said I do agree that there are some merits (on a user standpoint) to bridging no matter what.
But we are purists that believe in other devs to make crash free plugins. Before you say "there are no bug-free plugins", I can surely say there is no 100% transparent IPC synchronisation method, they all come at a cost which accumulates when scaling to many plugins.

We do not feel trying to test/scale our current IPC methods for multiple master/slaves at once is sound ROI at this point.
David Viens,

Plogue Art et Technologie Inc. Montreal.

http://www.plogue.com


Return to “Bidule Feature Requests”

Who is online

Users browsing this forum: No registered users and 1 guest