Scope v5.1 x64 installed, but it always runs in x32 mode

[odlumb]

Sorry if this is a duplicate. I searched around a bit for a similar previous question and didn't find one, but it's difficult to believe this hasn't come up before.

Anyway, while developing a third party application, an exception was thrown that caused me to notice something I've never paid attention to previously - Scope v5.1 is running on my machine in 32 bit mode. How I missed this is a mystery, it's easy to see in Task Manager.

The question is why? The x64 version is installed, the machine is definitely 64 bit in all aspects (HW and SW). Almost everything that runs on this computer is running in x64, but for a few older programs I use occasionally. Somebody must have encountered this previously. Anyone?

[garyb]

it's working properly.

almost ALL audio apps are 32bit programs. the 64bit versions are 32bit apps that address the 64bit system. really, only Kontact is truly 64bit. it's just about the only app that will really use the extra ram available. you could just as well use 32bit windows and JBridge. with 32bit windows, your audio apps will be happier and JBridge will allow an app like Kontact to access additional ram(the same as 64bit windows). http://jstuff.wordpress.com/jbridge/ ....or just use 64bit windows and don't worry about it...

[dante]

Isn't Spewbase 7 x64 tru 64 bit ?

[garyb]

sure. does it matter?
it's not like they rewrite the nuts and bolts for 64bit operation. only the parts that interface with system resources need to be rewritten.

[dante]

sure. does it matter?

For Kontakt it does. But I figure CPU will run out before I fill ram.

[garyb]

i think you misunderstand.
the part of the program that interfaces with windows is 64bit in all the audio 64bit software. it's the rest of the program that's 32bit. that includes quite a few plugins. there is a bridge between the 32 and 64bit script, so as long as the host app is the 64bit version, there's no real harm done if the same 32bit script is used for both versions. the slight extra drain in resources from the bridge is made up by the faster 64bit architecture. all this means is that if you're using a 64bit os because you expect a performance gain, you're wasting your time.

as to whether you want to run 32 or 64bit os, that's a anyone's choice, but of course you want to use the version meant for the os you use. the 64bit version od Scope shows up in the task manager as a 32bit process and th op was concerned about that. the rest is immaterial.

by the way, you can use the same amount of ram in 32bit windows as 64bit windows for your Kontact samples if you run JBridge, afaik. http://jstuff.wordpress.com/jbridge/

[dante]

As long as Cubase x64 addresses full RAM its true 64 bit for my purposes - rather that than use a bridging mechanism.

[garyb]

Cubase IS a bridging mechanism. that's what i keep saying!

[dante]

Ok, assume clarity now on what you keep saying.

Would you also say that a jbridged system is as good or better (eg issue count wise) than everything just running native 64 bit (OS and apps - apps 'real' 64 bit or not) ? And would you also say that the benefits of extra RAM don't qualify as a performance improvement ?

[garyb]

yes, either you use Cubase's bridge for the program itself and for any 32bit apps, or Jbridge to allow Kontact to use the same amount of ram that it would in 64bit.

extra ram is the only advantage to 64bit for audio programs, but only Kontact is going to actually benefit.

for these reasons, i would run 32bit windows with JBridge, because your audio programs and plugins will have fewer compatibility issues.

of course, i haven't done extensive testing, so...a surface examination leads me to my conclusion...

[dante]

Fair enough. Worth noting that the jbridge works both ways though, so overcoming incompatibilities on both 32 and 64 bit app/os.

Found the following link, and even though its 4 years old from 2010 (eg Reason 7 64 bit not represented and no bridge for that), a good background.

http://www.soundonsound.com/sos/nov10/a ... 64-bit.htm

It does mention that setting up bridging can be a bit of work, since you may be using it selectively on some plugs and not others - maybe its got easier in 4 years though. Or, maybe its got easier to jbridge from 64 to 32 now rather than 32 to 64 as more plugins now run on 64.

good old SOS !

[garyb]

i'd say that article is probably out of date...

[dante]

Sure. But still seems to me that a users 64 vs 32 bit VST ratio could be a factor in whether its easier for them to do their bridging in a 32 bit environment rather than a 64 bit one.

The main way that article is out of date is most likely that theres more 64 bit vst's now.

[garyb]

no, NO ONE benefits with 64bit, EXCEPT for the extra ram for Kontact.
if you can bridge the one plugin that matters so that it can use the same amount of ram in 32bit as 64bit, then there really isn't a 64bit advantage.

for cad/cam, it's the opposite, likewise video, where the apps really are 64bit.

actually, it's not that serious of a controversy...

[SilverScoper]

no, NO ONE benefits with 64bit, EXCEPT for the extra ram for Kontact.

Better add Reason to that list. Look ma, no bridges !

Reason

Reason.jpg (78.82 KiB) Viewed 3733 times

[garyb]

and Reason...
sampler apps in general...