wintaper


it does work in Cubase, which supports the latest version of the VST standard. 

 
VST is not a "standard". It's a proprietary API that happens to be used by just about everybody, which makes it a "de facto standard". VST3 is not used by everybody (i.e., host support required by a majority of plugin vendors), so it's not even a de facto standard at this point.
 
Waves coming out with a sidechain implementation that only works in VST3 hosts is absurd. Even if a majority of hosts have "plans to support VST3 in the 'near future'", how long is that going to take, realistically? 12, 18, 24 months to get all the implementations sussed? In fact, I don't believe they would be so short-sighted. There must be a VST2 version that works during this transition period. If not... baaaahaaaahahahaha!
 
 

Slow down horsy..... Wohhhhhh......

Some shared information pertaining to VST3 and 64 bit from another forum....

Most of the VST2 plugins already work at double precision. (64bit) Any critical process is always done in double precision. That goes for native plugins and Third Party plugins.

What happens is: the plugin receives a 32 bit signal from the host, the plugin upsamples to 64bit, does the process and then brings down the numbers to 32 bit and dumps the registers back into the host's summing engine. (which is 32 bit float)

The VST2 protocol is fixed to 32-bit in/32 bit out. Regardless of what the plugin does internally.

VST3 allows to accept and to dump the 64bit results into a 64bit mixing engine. 64bit in/64 bit out.

This means, used in a host that is double precision, the numbers don't have to be brought back to 32 bit before the registers are dumped into the host's summing engine.

That introduces small errors which end up in the LSB. These errors are of the same "magnitude" as the errors that a 64 bit engine produces.

While a Floating point CPU can hold up to 80bit (and more) registers, SSE registers are limited to (2x) 64 bit.
So, once you begin adding (big) numbers you will encounter the same errors in a 64bit engine as in a 32 bit engine.

In other words, *the way the Nuendo engine is build (holding the registers as long as possibly can before dumping the results to 32 bit)* for simple summing, 64 bit is less precise than 32 bit. (although the 64 bit errors are smaller than the 32bit errors - still both can be neglected.)

There are some advantages to a full 64bit engine, and there are disadvantages. But you should be able to get the exact same results. Unless you are doing some "exotic" things which would never occur in "normal" mixing conditions. (-50 dB/+50 dB)

So, in answer to your question. Most of the good plugins out there already use double precision for their processes. VST3 or VST2 won't make them sound better or worse.
No difference.


I agree with most of what is said... some is just computer science and some is opinion... I would have to do thorough testing to hear differences.

Have fun

"Cakewalk's VST plugins pass 64 bit data in and out."

I believe the idea is that it can't using VST1 or 2..... as it doesn't allow 64 bit data streaming to the host processor.... Using Cakewalk plug-ins is beside the point.. as you don't need a VST3 platform to run them... however a Waves plug-in that uses VST3 won't work on the 64 bit engine Sonar has and that's the problem.

Cakewalks plug-ins also kinda blow

Lol....  Also is that not limited to your OS running 64 bit and your system (Like hardware components/processors/busses) allowing 64 bit processing? Runnig windows at 32 bit floating point is not processing at 64 bit even if Sonar steps it up in it's own platform.

"The VST2 protocol is fixed to 32-bit in/32 bit out. Regardless of what the plugin does internally.
This illustrates the danger in blindly pasting "information" gleaned from unreliable sources."

Hence why I stated this was from a forum and I agree with most of what is said in it.... some people....

There is an agreed opcode within VST2.4 that says "this plugin can handle 64 bit in and out"

Does that mean it uses 64 bit though? I thought it just allows the plug-in to process at 64 bit but then down converts to 32....

jasonthurley


There is an agreed opcode within VST2.4 that says "this plugin can handle 64 bit in and out"

Does that mean it uses 64 bit though? I thought it just allows the plug-in to process at 64 bit but then down converts to 32....

It means it accepts 64 bit floating point going in and coming out.  It can (must, I guess) also support 32 in/out. Internally, it can of course do whatever it likes...

I have asked this question before with no real answer. How do we know that a native 64 bit plugin is processing at 64 bits? Now this adds the notion that even if it is is it keeping it fully 64 bits?

I would like to know just what the heck is going on.

This is an online forum.... get it or get out

Bit and Brun are two of the very best forum members. They have a enviable track record that you have yet to establish. It would be wise to listen to them and not try to insult them.

"Bit and Brun are two of the very best forum members. They have a enviable track record that you have yet to establish. It would be wise to listen to them and not try to insult them."

I offered free advice and someone who doesn't know what they are saying decided to correct information that is scince not opinion

If they are so highly respected.. then why not truly do your own research before correcting something you obviously don't know much about? My family has managed IBM from the original computers taking up rooms to currently teaching super computing in the leading colleges og\f the US... so regardless of the respect they might have if you don't know what your talking about then don't bother... that's all Im saying

jasonthurleyThis is an online forum.... get it or get out

You really need to start finishing some sentences, lest they be misinterpreted.


I'll take this to mean: "You encounter all kinds of people on online forums, including self-aggrandizing blowhards* who know just enough to be dangerous. It's pointless to try to get them to acknowledge their errors, even in the face of irrefutable evidence, so you might as well not try."


I'm in complete agreement with you there.




* "My family has managed IBM from the original computers taking up rooms to currently teaching super computing in the leading colleges og\f the US..."

To follow up on my previous post:

 
jasonthurley

The VST2 protocol is fixed to 32-bit in/32 bit out. Regardless of what the plugin does internally.
 

True up until VST2.4, which supports double precision in and out (as well as x64, I believe).

VST3 allows to accept and to dump the 64bit results into a 64bit mixing engine. 64bit in/64 bit out.

Also the case for VST 2.4.

I have asked this question before with no real answer. How do we know that a native 64 bit plugin is processing at 64 bits? Now this adds the notion that even if it is is it keeping it fully 64 bits?

Feed it a signal that 32 floating point bits is insufficient to represent and thus would require 64 floating point bits of resolution to represent. See what comes out the other end. That signal would have to have a magnitude that is very very small or very very large. Watch out for software techniques that try to avoid P4 denormals like Sonar's ZeroFillMethod= parameter, which might screw up the level of your very very small signal.

32 floating point bits can represent very small or very large, but 64 bits, being double precision, can represent very very small or very very large.

Both MSW and LSW are doubled.

Indeed! thank you for correcting my inexcusable error.