John T

 What motivation could I possibly have to lie about it?

Here's the problem I have with it. You responded to a specific statement with a generic reply with no facts to back up your claim.


What sampler are you using? What actual sample? Is it available in a 32bit version? If so, then your x64 it argument is bunk and therefor I call BS.


If I'm wrong I have no issue with correction myself ... just show me fact please.

Hmm. I suspect from your tone that no answer is going to satisfy you, but here goes.

If you really want to know, on the project in front of me right now I've got two instances of BFD2, with around 3gb's worth of stuff in ram between them. I've also got an EWQL Symphonic Orchestra currently taking up about 1gb, and that's going to go up as I work into it. That's the bulk of it, but I also have five instances of dimension pro with bits of this and that going on. So that's about 4.5 gb of samples sat in ram. This would be pretty hairy in a 32 bit setup, lots of virtual memory paging and whatnot, so lots of risk of drop outs and stuff.

I've only got 6gb in my computer at the moment, so I'll probably need to start freezing stuff soon, but for now, it's holding up admirably well.

Both BFD and EWQL are the 32 bit versions, running under bit bridge. I'm not sure how this makes the argument bunk.

Having given you your answer, I'm still interested in an answer to my question. Why would you think I would lie about this? I mean, it's such a dry, mundane technical point.

So in other words, what you are saying is, you can't load everything because you won't use the 'freeze' feature to free up your memory. That's what it is there for ... to take the load off your CPU/RAM.

So in essence ... you have created your own problem and have not shown me a valid instance where you are not able to use 32 bit.

So I stand by my comment.

Yeah, I kind of thought you would, as I said.

The thing is, a frozen track is exactly that, frozen. If I want to edit it, I have to unfreeze it. Having it all running live is orders of magnitude easier to work with than unfreezing and refreezing for every adjustment.

Freezing is a good workaround for when you've run out of options, but it's nobody's preference.

I guess we've moved on from the "you're making this up" position. I wonder if we can make any further progress.

Well, all I know is that using large, ram hungry VSTs like Omnisphere, for instance, used to bring my 32 bit system to it's knees.  Now, with 64bit, and 12 gigs ram I can throw everything AND the kitchen sink into a project (multiple instances even) and the machine/Sonar doesn't even break a sweat.  It does matter if you use these types of instruments and effects.  Absolutely.

LIAR!

You can unfreeze a track to work on it so again I call BS.

" ... it's nobody's preference." - Again, BS.

You said, "I've got projects that I can't play in 32 bit because the sample sets I'm using are too large. But I can play them in 64 bit."


Until you prove to me you have a situation where your only option is to use 64 bit .... then I stand by what I said.


So far you given me excuses as to why you want to work in a 64 bit environment, but you haven't shown anything based in fact as to why you are forced to work in a 64 bit environment.


I still call bull***t.

All I'm saying gentlemen ... you have the option to freeze if you're CPU/RAM are being taxed to the point of you not being able to continue.

If you want to make a change, unfreeze.

You may not like it, but the option is there freeze and therefor you can still work in a 32bit environment. So far nobody has shown me a single example of absolutely not being able to work in a 32 bit environment.

Still calling BS here.