A way to increase Cubase 32-bit memory allocation?

[JerGoertz]

I already have Cubase 8 (and thus all versions between 4 and 8 as well), but I love Cubase 4 and it's compatible with some of my older plugins which crash 8. I have also heard jBridge doesn't work with all plugins, plus I hate introducing additional layers which can cause processor overhead and instability. So I'm going to stick with 32 bits until dragged kicking and screaming to 64.

Anyhoo, it looks like setting the flag in Cubase 4 will either work or not, and I'll know pretty quick which is the case. If it crashes I might try it with Cubase 6 or 6.5. Was it Cubase 5 that had a bunch of processing overhead from Syncrosoft? 'Cause I want to avoid that one.

[Googly Smythe]

nm

[LawrenceF]

I doubt anyone would switch to a 32-bit DAW specifically for mixing if they're already using 64-bit DAW for whatever reason.

I do. I almost always mix in x86.

It takes all of 45 seconds to quit and launch x86 and use some of the audio plugs I like (some freeware actually, some just really old) that still aren't 64-bit, but frankly, more often than not production with virtual instruments that require lots of ram (and x64) and final mixing the audio stems of all that (which don't) aren't even in the same "sitting", or even the same day.

Granted, if my daw of choice had a native bit bridge (and it worked well) I might not bother doing that but it's not exactly time consuming.

I should clarify: With track freeze you can do that and still be able to go back and tweak instruments, change a piano sound later, whatever, without exceeding the x86 ram limit, if it ever comes up, and because all instruments are frozen, can add new instrument tracks if necessary if that comes up. I only default to launching x64 when I know I'll need to use a lot of ram, usually the initial VI production.

[ZapAxe]

I already have Cubase 8 (and thus all versions between 4 and 8 as well), but I love Cubase 4 and it's compatible with some of my older plugins which crash 8. I have also heard jBridge doesn't work with all plugins, plus I hate introducing additional layers which can cause processor overhead and instability. So I'm going to stick with 32 bits until dragged kicking and screaming to 64.

Anyhoo, it looks like setting the flag in Cubase 4 will either work or not, and I'll know pretty quick which is the case. If it crashes I might try it with Cubase 6 or 6.5. Was it Cubase 5 that had a bunch of processing overhead from Syncrosoft? 'Cause I want to avoid that one.

If you have Cubase 8, and other older versions, you may want to consider using Cubase's VST System Link between two computers/sound cards, with at least two of your Cubase versions. This way you could run Cubase 8 on a 64 bit DAW, and any of your old 32 bit VSTi's on your native 32 bit DAW. This is what I do myself, I use multiple PC's actually. I get the best of both 32 bit/64 bit native worlds, and nearly unlimited resources.

[swatwork]

I do. I almost always mix in x86...

An interesting approach. I would be concerned about mismatched plugins when the project was loaded in 32-bit and 64-bit versions of the DAW but I can see how track freeze could make it work. If you treat 'frozen' as the default state of each track and only unfreeze/freeze within each session you could avoid the 32-bit DAW complaining about loading 64-bit plugins and vice versa.

[Guenon]

If you've got a plugin installed in both 32 bit and 64 bit versions, there shouldn't be any errors thrown by the host or said plugins themselves. If everything works as intended, that is . They should be completely interchangeable, and usually are. I.e. you can open a new project in a 64 bit host, load different 64 bit plugins, then open the 32 bit version of the same host and it loads the project with 32 bit versions of those plugins automatically and completely interchangeably. The only caveat is the memory limit.

I've occasionally done the "open the late-stage project in 32-bit mode" thing, too. Especially for finalizing/mastering purposes, and when it's done in such a late stage, then it's not a risk of mismatching plugins at all -- as you operate on the rendered stereo mixdown anyway. I've done it a lot less lately, but on the other hand I see how the approach is still a very nice option to have. The Variety Of Sound bunch of plugins is one of those toolsets that is nice to keep around

[swatwork]

If you've got a plugin installed in both 32 bit and 64 bit versions, there shouldn't be any errors thrown by the host or said plugins themselves.

That's true but my understanding was the LawrenceF was mixing in 32-bit to make use of plugins that had no 64-bit equivalents; if all the plugins are duplicated between the 32- and 64-bit versions of a DAW I don't see any reason to switch between them, just pick one and work with that exclusively.

[Guenon]

That's true but my understanding was the LawrenceF was mixing in 32-bit to make use of plugins that had no 64-bit equivalents

Yes, of course . I was just saying that there's a general interchangeability between 64 bit and 32 bit plugins, in the case of plugins you have installed in both versions. So there is no need to keep absolutely everything frozen, for example, if you spin a project into the 32 bit version of the host and back. Just keep in mind the memory limit, and additionally render the tracks that don't have 64 bit plugin versions available, when/if loading the project back into the 64 bit host.

[swatwork]

Oh, I see what you mean now. Yes it would make more sense to just freeze the tracks where the plugins aren't duplicated, rather than everything. It still sounds like a lot of trouble to me though. I'm glad I took the time to weed out any 32-bit-only plugins from my setup so I don't need to worry about running this sort of hybrid approach; I can switch between an exclusively 32-bit or 64-bit setup as required

[LawrenceF]

I do. I almost always mix in x86...

An interesting approach. I would be concerned about mismatched plugins when the project was loaded in 32-bit and 64-bit versions of the DAW but I can see how track freeze could make it work. If you treat 'frozen' as the default state of each track and only unfreeze/freeze within each session you could avoid the 32-bit DAW complaining about loading 64-bit plugins and vice versa.

Yes. All my instruments are both x64 & x86 so there's never any conflict there with unfreezing a few of them in x86 to tweak, as long as you don't exceed the x86 ram limit while doing that.

I freeze regularly anyway by habit. If I load and play a piano track from a 2gb piano sample (Kontakt, whatever) and edit the midi and like it, I freeze it rather than leave it running. You can always change it later anyway if you change your mind. One handy thing, in the host I use, common edits done to frozen audio also happens in the midi so you can chop things up and still unfreeze and not change the sound.