64 Bit Plugins Question

They are in no substantial way better FOR AUDIO. Any plug in that could benefit from 64bit audio path has been able to work at double precision for more than a decade internally without any compatibility with 32bit DAWs.

The need for 64bit audio plug ins is simple--coexisting inside the DAW with 64bit virtual instruments. Apple has pushed the fact by making LogicX 64bit with no capability to bridge back to 32bit plug ins.

To back up, if you're not a computer guy....it's about RAM access. 32bit cuts off at 4gb. 64bit, I don't know what the theoretical limit is--but it's a number not likely seen or used in my lifetime, being that bits are exponential...

I've always found it kind of humorous the amount of hate companies, who make audio plug ins, get for not "jumping right on that" 64bit bandwagon, because it's a ground up recode that is MEANINGLESS to their product's quality. It's a compatibility upgrade to the code--that requires substantial recoding. Not like a little GUI API tweak like some new large cat or number revision OS would need--but, a serious reworking of their code.

So, it's about V(irtual)I(nstrument)s. If BFD2 takes 1gb for a large kit....and VSL takes 4gb for strings...and Alicia's Keys takes 500mb for the piano...and....ok, I'm out really--but, you can see how it gets over the 4gb 32bit application limit quickly. Especially with the latest VIs that use 200% more RAM for 1% improvement in sound....people are building machines with 16 and 32gb, so they think they want to use it. I say think....because, I figure with a standard magnetic drive, it would take something like 20-30min to load a template of buffers that large. I've got VSL projects with my meager 8gb machine that take 5-6min to load a song. Which is why I'm glad I really only do string work for ME. That goes down substantially with SSDs, BUT...a lot of these "libraries" are huge. So, the actually pay as much for the storage for the library than you do for the library!

Picture a gant chart. One bubble? engineers who want CPU efficient good sounding DSP algorithms for audio production....and another bubble of people who want to arrange for drums, pianos, orchestras, horns, and whatever else all by themselves. Where that overlaps are the people who care about 64bit audio plug ins. NOW...you add to that every audio Logic user (if those exist) who also feels the need to stay current and move to a version that offers them nothing other than maybe the latest OS compatibility.

DAWs are mature. And so now they're aiming for another market.

I can explain the hate company's get for not jumping up to 64-bit.

I upgraded my DAW to 64 bit and now some of my plugins don't work anymore. Some - not even with JBridge

While popmann makes a good point about RAM access, that's not the whole story.

In a thread a while ago I explained why higher bit depth is important. Truncation.

Truncation: limiting the number of digits to the right of the decimal point by discarding the least significant ones.

In layman's terms it means fitting 12 inches of numbers into a space made for 6 inches by cutting off 6 inches. In other words, you lose precision and ultimately fidelity.  You might not hear it at first, but once you run your audio through a bunch of plugs and then through the DAW summing system, you'll start to hear it.

It's the same reason that people use to output their audio to analog summing mixers instead of using internal summing on DAWs. Once you have many tracks and many effects, each truncating the excessive strings created by the previous math functions, you start to diminish the fidelity of the audio making it through the system.

So 64 bit systems and 64 bit plug ins allow the math results to be longer without being cut apart and therefor keeping fidelity through the system.

On the other hand though, it's allowed a lot of plug-in designers to be more sloppy in their coding because they used to have to be more smart and efficient in their math to keep fidelity at lesser bit depths.

That's precisely (pun intended) what I mean.  It's not a drastic difference.  It just builds up over a bunch of plug, inserts, routing, summing, etc.  The more audio streams that need to neatly fit into a small space, the more that each one is cut down to make the bunch fit.  Most folks hear this exactly as you describe.  It's just a little more dull and muffled, like it's lost all the nuance.

That's probably the largest reason I went back to outboard gear and no longer use plugs when i don't have to.  i also don't use the faders in the DAW or do any routing that I don't have to do in the box.  I do it all on an analog mixer.

All good stuff. Great replies.

I like it because 64 is a larger number than 32. It is 32 better.

there is a fine line between clever and stupid..

I don't know about Cubase, but there isn't 't anything preventing macs from running 64 bits. With macs, it's always a setting somewhere. I find it's way easier to incorporate a drop by at the Apple store into a day's routine, than search around on the internet. I get an answer in 5 minutes or less.

Try the "help" tab up top, type in settings /. 64 bit. I'm not home, or I'd do it for you.

Just thought of something, how much RAM do you have? You won't get any improvement unless you're over 4mb

It is true, like popmann said,
64bit internal resolution was availabe in 32bit DAW already.
Anyway, applications (DAWs) and libraries (plugins) compiled for 64bit can use the native CPU data formats for 64bit in the instructions set of the machine language of the processor. This makes code considerably faster, if done right, resulting in less cpu load.
Nowadays, computing power gets cheaper and cheaper due to parallelization and there are new possibilities for highest quality native plugins. E.g. the Nebula engine that uses dynamic convolution based on volterra kernels. Using these very cpu-heavy plugins profits from 64bit acceleration which adds up with no. of instances. Quality of these kind of effects in emulating nonlinear analog behaviour is outstanding, btw., and gives a bunch of very interesting possibilities ("sampling" your analog real thing - not only EQs but also dynamics).

Also, 32bit applications running in a 64bit OS environment need an additional layer to run in the OS, which has to be implemented into the OS (same as for 32 bit plugins in a 64bit DAW/"bitbridge"). 32bit applications are already legacy and will not be supported forever, same as 32bit operating systems.
Tbis is very forseeable...just a matter of time.

Best regards,
Martin

UAD won't run in 64 bit yet will they?

But, to answer your question: (from their site)

UAD Powered Plug-Ins are 64-bit enabled for Mac and Windows since v6.4.

Thanks Ethan, but you can have your "no provable differences" , and I'll keep my $2,000 power cord. Believe me, if I switched it out, and someone can't hear an improvement, it's their hearing that needs testing !

I believe that in 64 bits a 16 mb buffer can be used and in 32, there's a 4mb limit, so that could make for a difference, and perhaps that's what I'm noticing..

I remember how often folks would argue with audiophiles that bits are bit, and denied there could possibly be a difference between two pieces, then jitter began to be taken much more seriously, and is now considered a bona fide factor in audio quality instead of being irrelevant. But things like being affected by jitter might not be measurable in a test environment, it might show up as a listener turning off their stereo sooner than they used to, and not even realizing it was the sound that was bugging them. 

So, sometimes things are subtle, I use my instinct and feelings, and they haven't steered me wrong yet. It would take a novel to tell the entire story, but I've embarrassed some world famous producers more than once by simply insisting they locate a problem I was noticing, and they weren't. So that began my habit of trusting my ears and what I feel, not wasting my time thinking about testing it. I have tracks to make, so I can't go quite as far down the audio science road as I might otherwise.

All the best, nice meeting you at AES :-)