Firebird in 64bit hosts

[bM3w]

Any ETA for Firebird 64bit?

Thanks  

[GeorgeZ]

I have no idea, but thought I'd just mention, for synthesis there is no advantage in going 64bit (as it only adds access to ram above 4gb, which is pointless for synths of course, but good if you're using samplers and massive sample libs). On the other hand, if your host is 64bit, and you're having problems with it's 32bit bridging wrapper, sure, 64bit could possibly solve that.

Any particular reason for wanting F+ as x64? Just curious 

[Markus Krause]

We have tried to build a 64 bit version, but unfortunately we had to notice that FireBird can't be compiled to 64 bit. The libraries from Steinberg's VST SDK v2.3 and the VSTGUI 2.x are 32bit only. Porting FireBird to 64 bit would mean a complete redesign of the synthesizer. Currenly we got no plans for a FireBird2 (which would be also 64 bit & Mac) in the near future.

[GeorgeZ]

Hmmm, think my PC love just went up by a tiny bit 

[bM3w]

We have tried to build a 64 bit version, but unfortunately we had to notice that FireBird can't be compiled to 64 bit. The libraries from Steinberg's VST SDK v2.3 and the VSTGUI 2.x are 32bit only. Porting FireBird to 64 bit would mean a complete redesign of the synthesizer. Currenly we got no plans for a FireBird2 (which would be also 64 bit & Mac) in the near future.

Too bad 

@GeorgeZ: I don't like to bridge/wrap plugins as it only adds instability to the system. Not on every single plugin, but the combined usage of more than one wrapped plugin.

[GeorgeZ]

Ye, I figured that might have been the case, aw well...

[MorpherX]

We have tried to build a 64 bit version, but unfortunately we had to notice that FireBird can't be compiled to 64 bit. The libraries from Steinberg's VST SDK v2.3 and the VSTGUI 2.x are 32bit only. Porting FireBird to 64 bit would mean a complete redesign of the synthesizer. Currenly we got no plans for a FireBird2 (which would be also 64 bit & Mac) in the near future.

Too bad 

@GeorgeZ: I don't like to bridge/wrap plugins as it only adds instability to the system. Not on every single plugin, but the combined usage of more than one wrapped plugin.

This is complete wrong !!!!!!!!!!!!

I have bridged over 40 plugins and within these are also 8 Firebird and it runs rock-stable in Cubase 4/5, Orion 8.5 and Sonar X1d 32bit in a Win7 64bit OS.
Don't tell here nonsense if you have no proof for what you are talking about.

[Markus Krause]

Our experience with wrappers was that they work quite well, but some of them still suffer from bugs. A wrapper does also come with a slightly more CPU since the audio data has to be moved between processes. There is indeed the risk of additional compatibility problems, since a wrapper acts as an additional host like a middleware.

We experienced some minor problems with the Logic 32 bit wrapper.

[LeVzi]

For the PC guys, check out jbridge, I use it on a lot of plugs, and the dev is really helpful if a problem does arise, and the CPU burn isn't too bad tbh Well in acceptable levels

[MorpherX]

Our experience with wrappers was that they work quite well, but some of them still suffer from bugs. A wrapper does also come with a slightly more CPU since the audio data has to be moved between processes. There is indeed the risk of additional compatibility problems, since a wrapper acts as an additional host like a middleware.

We experienced some minor problems with the Logic 32 bit wrapper.

Hi Markus,

I am using jBridge v1.5 with Cubase 4/5, Orion 8.5, Project5, Cantabile 2 and Sonar X1d (all 32bit versions on Win7 64bit)
Cantabile and Sonar have embeded support for jBridge.
jBridge offers many options and adjustments for "problem-plugins". If you found the correct adjustments for all the pluguns you are using with jBridge, the host and jBridge-services running really rock stable.
I am working every day with 20-46 bridged plugins in one of the above hosts.
For other hosts I can't give any proof if they work there without compatibility-issues.
I have an AMD 6 core processor at3.7 Ghz and it uses 5% less power if performance-mode is enabled to 40 bridged plugins.(assyncron processing for plugins when they don't send MIDI-out) compared to no bridged use.
If performance-mode is disabled to all bridged plugins the processor uses 5% more power. (seen in the Task-Manager). If you don't need MIDI out from plugins you can even save 5% processor power also when using 40 bridged plugins !!!

Also ElectraX, FireBird and AkustiX works jbridged without problems with the above hosts. Only FireBird needs some special adjustments in the jBridge-options (slow GUI-problem and dispatcher opcode 19 (slow response or possible crash)).

 

[LeVzi]

Do you run firebird as separate GUI or integrated ? I've found recently that running my bridged plugs in integrated GUI actually is stopping any errors and reducing overhead demand. I still use the slow GUI, stop host taking control and timehack options.

[Markus Krause]

Thank you for the detailed info. This can be really valuable for other users.

[MorpherX]

Do you run firebird as separate GUI or integrated ? I've found recently that running my bridged plugs in integrated GUI actually is stopping any errors and reducing overhead demand. I still use the slow GUI, stop host taking control and timehack options.

Hi LeVzi,

when using FireBird with jBridge I have the integrated GUI-Mode with the two options activated mentioned above.
A very good solution for bridging "problem-synths" is to use Wusik VM with VST-SDK 2.4 and bridge this little VSTi-Holder. Then load in the bridged Wusik VM your desired "problem-synth". This often helps a lot. But rethink that Wusik-VM has only stereo output.
You could also make the same prozedur with Chainer from Xlutop. Just bridge it and load the desired synths. Chainer has also only stereo output but much more intern routing capabilities.
In very heavy cases of a "problem synth" load Wusik VM within a bridged Chainer and then load within Wusik VM  the synth. With this method you can load every synth bridged within a 32bit or 64bit host.
If nothing helps you still have the option of mailing to the developer Joe from jBridge. He is very friendly and will try to help you in stone-hard cases.