Do you still use 32 bit plugins?

[ZeePok]

 

Yes, my laptop has only 4GB memory (which is enough for what I do anyway), so why bother to install only 64-bit software host/plugins then?

I always thought so too, but last week I learned this:

Windows 32 bit only supports up to 3GB of RAM per application, and that is only if a special bootup "switch" is enabled. If it's not, only 2GB per application are allowed. You can maximize use of your available memory with a 64 bit OS, even if you only have 4GB.

Surely is something to consider ...
 

[incubus]

No no, you MUST keep at 32 bit. DO NOT take advantage of even 6GB of ram, keep telling yourself "It's fine, no problem" .....

Honestly, I went through this 6 years ago, please stop. It's embarrassing !

[.jon]

No no, you MUST keep at 32 bit. DO NOT take advantage of even 6GB of ram, keep telling yourself "It's fine, no problem" .....

Honestly, I went through this 6 years ago, please stop. It's embarrassing !

Memory is irrelevant to most people. My biggest project to date with 37 tracks uses 372Mb. I've gotten up to 600Mb in some other projects, but nothing that would be anywhere near even that ancient 2Gb limit. I'm on W10 x64 with x64 host and plugins (still occasionally bridge a few x32 ones), but most of those 16Gb of memory lie unused in my audio work.

[xoxos]

most of those 16Gb of memory lie

so they have something in common with our many friends at kvr then

[SampleScience]

The 32 bit debate is certainly a topic that sparks conversation on KVR. A bit like the Timbre Wolf debate on Audiofanzine (in French) which has more than 600 comments.

[Kumi_27]

Yes. My 3 different DAWs all have native bridging so really I don't see any problem with using such plugins.

BTW I'm still using some 8 and 16 bit hardware and have several 32bit virtual machines with different old soft.
8 GB RAM allows to run 2-3 of them at the same time

[Cruba]

I really would like to use some epic 32bit freebies, but never found out which one is makin problems. No time to guess, I made this thread today, because I need some 32bit input:

Let's list together! Totally stable 32bit free vsts in Cubase 64bit (Cubase bridge only!)
viewtopic.php?f=1&t=471348

Maybe you wanna help to fill up the list.

For now I just could put my hands into fire for Synth1. It's totally stable in my Cubase 64 and for now the only one I could open over 10 instances without my pc freaking out or bein shakey.

[Guenon]

Memory is irrelevant to most people. My biggest project to date with 37 tracks uses 372Mb.

What did you use as reference for the size of most people's projects' RAM footprint? This is actually a serious question, not sarcasm. I've thought about this, and I honestly don't know where to look if wanting to get an actually realistic view on this. Where did you?

If there were polls on KVR, GearSlutz, VI-control and the most important music prod magazines (SOS, Future Music, Computer Music, etc...), all at once, along the lines of "how much RAM did your largest project to date use up?" ... I don't know what might come out of it.

What one can objectively say, however, is that mostly outboard recording and/or synth dsp based projects (with audio tracks streaming from HD for good measure, in either case) often fall into the category you describe. (How often?) Similarly, if there's need for sampled instruments, using Kontakt libraries or Spectrasonics stuff or dedicated multisampled drum products or, or... anything of that sort, the 32 bit memory restriction easily becomes something of a burden, or at the very least something else than "irrelevant" and a thing to keep an eye on. So if one decides to roll with that limitation, it's also a decision that rules out convenient experimenting in certain types of production. Which is, of course, what "most people" might do anyway - ruling out that sort of stuff from the get go, I mean. I don't know

[robotmonkey]

My main DAW is still 32bit solely for the sad reason that there's still some old but good plugins that I regularly use. Bridging tends to be unstable. Also FL Studio x64 is much buggier than the x32 version. My second DAW is 64bit though as it has less stuff installed.

Actually I'm going to try to make a switch to fully 64bit today. Maybe it's time to let go of those couple of old 32bit plugins.

[.jon]

So if one decides to roll with that limitation, it's also a decision that rules out convenient experimenting in certain types of production. Which is, of course, what "most people" might do anyway - ruling out that sort of stuff from the get go, I mean. I don't know

Nobody "conveniently experiments" with production using Kontakt libraries, using them is a decision you make before you invest thousands and thousands and thousands of euros into them. Of course these people already have a use case for them, and ensure their machine runs them properly.

You can experiment samples with way less memory than 2Gb, what do you think people did 15 years ago? Memory doesn't stop anyone from experimenting with certain types of production.

[Guenon]

Memory doesn't stop anyone from experimenting with certain types of production.

Of course it does , and people obviously "conveniently experiment" with such production without investing thousands upon thousands on sample libraries. Things aren't that black and white, it's not like you're either someone with absolutely humongous libraries and massive investments made into them, or someone who only uses stuff that fits into 2-3 gigabytes (and on the other hand, a small memory footprint doesn't rule out massive investments into one's tools, either). Again, I'm interested in where you got the "most people" data. Hatustako vedit?

[stardustmedia]

In new sessions = NO
Rarely when I open old sessions = YES

Hardly no 32bit plugin left on my drive. In very rare occasions I still gotta use some of the old 32bit plugins, for instance opening an old session. But I do NOT use them anymore in new sessions.

I don't see a reason to use them in new sessions, since they're all covered by 64bit plugins by now. In some case, for instance Vanguard, there is no exact 64bit version, but there are other very good "trancey" 64bit synths. So I don't bother not using Vanguard.

I believe there is actually no 32bit plugin that cannot be replaced. At least I don't have any 32bit plugin features that I miss in 64bit plugins.

If you think you cannot live with a 32bit plugin, it's yourself hindering you. I'd suggest to overhink your workflow then, because sooner or later you'll be forced to. This situation will probably come unplanned and will put you in a bad situation. So rather now swapping all to 64bit, slowly and controlled.

[Guenon]

Memory is irrelevant to most people. My biggest project to date with 37 tracks uses 372Mb. I've gotten up to 600Mb in some other projects, but nothing that would be anywhere near even that ancient 2Gb limit.

As an additional comment to this, I just checked how much RAM my recent One Synth Challenge projects occupy. For example, the "Basement Bootleg Connection" that was quite well received with its emulated lo-fi bootleg recording sound, containing nothing else than synth instances, of course, and decidedly sparse effects processing (minimalistic host effects use only) -- the Ableton Live 8 process running the project in its final state takes up 1.7 gigabytes. The current OSC I'm experimenting with and hopefully finishing takes up 1.2 gigabytes already. So, such numbers strictly without any sample use whatsoever.

If these were "actual" productions, their structure would be completely different, most probably utilizing some sampled components as well.

Just an isolated example, that. Nothing more, but a single illustration of how projects can rake up RAM in other circumstances than huge $$$ pro soundtrack Zimmer magic sample library use, too, heh.

[.jon]

Memory doesn't stop anyone from experimenting with certain types of production.

Of course it does , and people obviously "conveniently experiment" with such production without investing thousands upon thousands on sample libraries. Things aren't that black and white, it's not like you're either someone with absolutely humongous libraries and massive investments made into them, or someone who only uses stuff that fits into 2-3 gigabytes (and on the other hand, a small memory footprint doesn't rule out massive investments into one's tools, either). Again, I'm interested in where you got the "most people" data. Hatustako vedit?

No, it doesn't. I can load 80 tracks with multisampled acoustic instruments before hitting 2Gb limit. What you don't get is that people have "conveniently experimented" with such production way before x64 memory space even existed.

Where did you get the data that most people use massive sample libraries?

[.jon]

Memory is irrelevant to most people. My biggest project to date with 37 tracks uses 372Mb. I've gotten up to 600Mb in some other projects, but nothing that would be anywhere near even that ancient 2Gb limit.

As an additional comment to this, I just checked how much RAM my recent One Synth Challenge projects occupy. For example, the "Basement Bootleg Connection" that was quite well received with its emulated lo-fi bootleg recording sound, containing nothing else than synth instances, of course, and decidedly sparse effects processing (minimalistic host effects use only) -- the Ableton Live 8 process running the project in its final state takes up 1.7 gigabytes. The current OSC I'm experimenting with and hopefully finishing takes up 1.2 gigabytes already. So, such numbers strictly without any sample use whatsoever.

If these were "actual" productions, their structure would be completely different, most probably utilizing some sampled components as well.

Just an isolated example, that. Nothing more, but a single illustration of how projects can rake up RAM in other circumstances than huge $$$ pro soundtrack Zimmer magic sample library use, too, heh.

Must be just inefficient RAM management then. I checked my Tyrell OSC project and it used 137Mb, so I duplicated the tracks until I reached 254 instances of Tyrell plus FX and ran out of CPU, RAM was at 520Mb.