64bit FL Studio

[highkoo]

So I am guessing there are a lot of FL users out there who are for the first time thinking about 'the switch' over to 64bit, at least for our host.
And I realized, that I dont even know what the advantage there is...

So, two questions-
What does the host itself get out of running at 64bit, plugins aside?
And
Is running 32bit plugs in a 64bit host similarly as 'tricky' as regular bridging, or is is a little smoother in reverse?

Thanks!

[Hink]

the biggest thing is you can access more RAM I believe, I didn't upgrade samp to pro x (the first 64bit version) until I got a new machine that was 64 bit. As far as bridging, I haven't run into any issues at all with samp, not all my pluggins and vsti's are 64 bit but they all run fine for me...but that's samp

[highkoo]

Yeah its the extra ram I wonder about.
What does the host do with it?

It always 'feels' like its just plugins chugging ram, and plugins that need more, but if we look at just a host, what is it doing?

Like, Ive never hit pops/clicks and thought 'Oh, my host needs more ram!', but I dont really know whats going on in there I guess.

[Functional]

Yeah its the extra ram I wonder about.
What does the host do with it?

It always 'feels' like its just plugins chugging ram, and plugins that need more, but if we look at just a host, what is it doing?

Like, Ive never hit pops/clicks and thought 'Oh, my host needs more ram!', but I dont really know whats going on in there I guess.

In the case of FL-studio, I think it does actually nothing. I'm not 100% sure, but I believe that FL-studio actually opens up every plugin in it's own bridge, not just plugins that aren't in their native bit.

I could be wrong, but in that case, there's no real advantage from going to 64bit. FLstudio will never reach the memory limits of 32bit.

In case I am wrong:
FLstudio loads native plugins (64bit fl-studio loads natively 64bit plugins, 32bit loads 32bit) and it's matter of disadvantages vs advantages.

See, if you got a 64bit host and you need to open up 32bit plugins, well FLstudio does it for you through bridge. But if the plugin is native, in this case, 64bit, then FLstudio opens it internally. Then the plugin is attached to flstudio internal process. And this is where things get complicated (if FLstudio does this).

As Windows (and any other OS) is only able to handle processes with the power of 2 of your processors cores... Well, in case you got more than two cores in your processor, it means that for one process (to be specific, process like flstudio or games, not something like compressing predefined data) you only have the power of two of your cores. In case of 4-core processor, you're only able to use half of it's potential for one process like FL-studio.

So let's say you have LusH-101 by d16 group. Well, the thing eats CPU like a hog. So you decide "let's load this 64bit lush-101 to my 64bit fl-studio". Then you make a synth that uses a lot of the voices, the supersaw algorithm etc etc. You end up with a synth that eats 50% of the maximum processing power for FLstudio process. Now, let's say, you want to duplicate it and play them at the same time (yes, this makes no sense, but it's just a simplificated scenario). Well, you can't do that, because it will eat the rest of available processing power for FLstudio.exe

This is where the "bridge.exe" comes into play. Each bridge.exe actually means a VST that is loaded through a bridge and they all get dedicated processing. Thus, even if you have 6-cores, you're actually able to use all of their power, not just 33%. The exception obviously is if you have a lonely synth that eats more than 33% of the total power.


FLstudio has it's own bridge for sure. I'm not sure whenever 32bit flstudio opens up 32bit VST's through bridge or not, or 64bit opens 64bit vst's etc. If they do, then there's no point going from 32bit to 64bit. If they don't, then it's a matter of how many 32bit or 64bit plugins you have. And if you need to bridge them, you need to use something like jbridger, in case you don't want them to eat your Flstudio.exe processing power.

Hopefully this makes somewhat sense to you. I'm terrible at explaining things

[Functional]

Also, I forgot to mention. FLstudio bridge is not exactly loved by everyone. Even for me, it tended to crash often. This is why you might want to actually avoid using it and instead use jbridge.

[Debutante]

i havent been able to use a single 64 bit plugin in my 32bit fl. it simply has never worked for me. not even simple freebie dll's

[koolkeys]

Doesn't FL Studio load all it's audio files directly into RAM? I think I read that at one point, but it may have been another host.

Brent

[highkoo]

This is confusing shit now.

@Frantic, I get ya, and thats the stuff I wonder about.
Id like someone from IL to explain/confirm how its working.
If it is bridging everything thats x32 like you describe, Im not sure I want to deal with that just so the host gets more ram. I cant imagine thats an insignificant thing to do, considering 20+ dlls on a track.

Doesn't FL Studio load all it's audio files directly into RAM? I think I read that at one point, but it may have been another host.

Hey, theres one!
I think you are right. Its ram by default, with a switch to go from hdd.
So thats a solid gain for the host probably.
I should just take for granted that Im going to take the plunge on this and jump right to bitching about x64 plugs.

Adding to the confusion, since a few versions back, FL Studio comes with a "Extra Ram" version of the .exe that has been described as being able to 'access more ram'...
I believe that was created while there was no possibility of an x64 FL due to Delphi.
Nope, its for the 32bit 3GB switch...

[hibidy]

There is an x64 beta iirc.

[chokehold]

I don't understand why there's so much confusion about this whole 32/64 shebang.

A 32-bit host can't load 64-bit plugins - without using a BitBrige.
A 64-bit host can't load 32-bit plugins - without using a BitBridge.

What about BitBridges? They cause all sorts of trouble.

Point 1 - they're external processes (look into your task manager), sort of container-applications that run alongside your actual host. So audio has to be constantly sent back and fort between two applications, time-synced of course. That causes the first possibility for severe screwups, and not to mention the extra CPU hit for every instance of a non-native plugin you load into its own external container process.

Things like pressing the Space Bar for Play/Pause etc. won't work when you're fiddling with the knobs on the plugin's GUI because your keyboard commands go to the container process and are not sent on to the actual host.

If your host auto-closes your audio device when you switch to other applications so they can use it, you're basically screwed because you're constantly switching back and forth between sound and no sound.
Show the host interface - can't change settings on the plugin.
Show the plugin GUI - can't hear what it does because host mutes.

Then there's that thing where you theoretically can give some plugin windows the "stay on top" pin, most hosts have that. You know, float the plugin's GUI above all others and wherever you click, it won't be sent to the background and covered by others. Especially helpful when working with analyzers or readouts in general.
As a BitBridge is a separate program and not really a plugin inside the host you're using, you can click on the little "stay on top" pin icon 'til you're blue in the face - as soon as you click anything other than the plugin's GUI (like for example the host itself, so you can press play...) that plugin will just vanish into the dark nothingness behind what it was you clicked.

Because all the above aside, there's always the danger of instability or incompatibility, and maybe not all specific plugin features are supported.

As far as continuing to use dead plugins goes, BitBridges are of course a gift from heaven. But as far as desirability for serious fluent workflow goes - don't bother.

Then why 64-bit at all?

If you just throw a couple of samples together, maybe load a few synth patches, use a sidechain compressor and slam a limiter on the master ... then you'll likely never need 64-bits, because you'd only be using material that feeds off the CPU and memory (as in hard disk) performancs.

But if you work like me, with sometimes multiple Kontakt-instances containing 16 instruments between 30MB and 1.5GB each, maybe a Superior Drummer drumkit at 1.5GB along with it, and then some synths, samples and FX - you'll VERY soon reach the limit of 3 or 3.5 GB RAM which is the limit for 32-bit applications. Even if those samplers use Direct-From-Disk, because that still requires a partially RAM-preloaded amount of the samples to work fluently.

So if you're doing mainly "synth stuff" and maybe string together some sample loops, then you shouldn't have to worry about 64-bits. Just stay on 32-bit and be happy you can continue to use those laid-back 32-bit plugins.

But if you're doing things like ethnic or orchestral stuff with EastWest, Kontakt, HALion, etc. then you should at least consider 64-bit because it MAY (!) make your life a lot easier. Or at least raise the limit of samples you can use.

[highkoo]

I don't understand why there's so much confusion about this whole 32/64 shebang.

I think most people get the general concept of 'access to more ram'.

The confusion for me starts at-
What does a 64bit host running 32bit plugins have over a 32bit host running 32bit plugins?
What kind of benefit would any kind of user see there?
i.e. What boost does the host itself get out of having more ram?
i.e. Why bother running an x64 host and bridging if you use x32 plugins?

Seems like koolkeys has a point with FL being able to load samples in ram.
So, if someone is using FL like Kontakt, bonus.
But, what a 32bit Kontakt would get out of a x64FL, I dunno.

Oh yeah-
"FL (extended memory).exe" I mention above is just for the 3GB switch on 32bit Win, so unrelated here, as far as I can tell by the FL manual.

[tony tony chopper]

If you ever went out of RAM in a project (generally because of massive audio files or non-streaming soundbanks), you indeed want 64bit.

If you don't, the only question is, do you have more 64bit-only plugins in your collection than 32bit-only? If yes, you want 64bit. If not, you want 32bit. To avoid bridging, because bridging will always be less efficient (& also generally troubles).

& it's not gonna be faster nor more precise (technically less precise in fact).


Note that there are plugins that eat massive amounts of memory for bad reasons: they load multiple giant animated knob strips, and don't share graphics between instances. Even in 64bit when you have a lot of RAM, it's still a waste of loading time.

[highkoo]

do you have more 64bit-only plugins in your collection than 32bit-only? If yes, you want 64bit. If not, you want 32bit.

Like a fookin laser.
Thankyou Sir!

Best case scenario for this thread was you confirming that so succinctly.

Can you confirm the theory above about the samples in FL?
Will FL x64 be able to handle more samples in ram?

[ferez21]

If you ever went out of RAM in a project (generally because of massive audio files or non-streaming soundbanks), you indeed want 64bit.

If you don't, the only question is, do you have more 64bit-only plugins in your collection than 32bit-only? If yes, you want 64bit. If not, you want 32bit. To avoid bridging, because bridging will always be less efficient (& also generally troubles).

& it's not gonna be faster nor more precise (technically less precise in fact).


Note that there are plugins that eat massive amounts of memory for bad reasons: they load multiple giant animated knob strips, and don't share graphics between instances. Even in 64bit when you have a lot of RAM, it's still a waste of loading time.

If i have all my plugins in both 32 and 64 bit, will i gain something from using the 64 version of FL (RAM advantages aside)?
For me, even a decrease of 1% in CPU usage will be a good ebough reason to switch to 64bit.

[chokehold]

The confusion for me starts at-
What does a 64bit host running 32bit plugins have over a 32bit host running 32bit plugins?
What kind of benefit would any kind of user see there?
i.e. What boost does the host itself get out of having more ram?
i.e. Why bother running an x64 host and bridging if you use x32 plugins?

Did you really read my entire post?
I answered those questions.
Answered as in pointing out the disadvantages of bridging and that you do not need to have an x64 host if you use x86 plugins.

The host itself gets absolutely no boost from being x64. But the host is not the "final stop", it's merely a relay station that distributes samples and plugins and instruments across the available system resources. And if that relay station can only access the limited x86 amount of resources anyway - why bother with x64 plugins?

If YOU as the user need to access resources beyond the point of the x86 spectrum, maybe because you use Gigabyte-heavy sample libraries like me, then you'll need a x64 host. Not because the host would profit from it, there's no gain in stability or speed or sound quality, but just because being x64 enables the host to access more than the limited x86 amount of system resources - as in "more RAM" and "larger single files" etc. and distribute more samples and stuff.