07-31-2020, 06:30 PM
(This post was last modified: 07-31-2020, 06:43 PM by JeffLearman.)
The term "64-bit plugin" can mean two different things.
When the VST interface was first defined by Steinberg:
* It was for the Intel/AMD 32-bit processor instruction set. (As in, x86 rather than x64).
* The data path (sample format) was 32-bit floating point numbers (IEEE single-precision floating point rather than double-precision, AKA "float" vs "double" in the C programming language.)
Since then, we have 64-bit processors, with new instructions and more registers, and they run a lot faster at the expense of using a bit more memory. The code has to be compiled that way. This is what I meant by "64-bit executable / instruction set". 64-bit plugins are not compatible with 32-bit hosts, and vice-versa, although some hosts are smart enough to automatically load a container to run the other type. For example, the Reaper DAW does this and you don't even notice it.
Since then, a new version of the VST standard has come out that supports a 64-bit data path and other enhancements. Hosts that support the new VSTs will also support old ones. I don't know whether new VSTs will work in old hosts; they might. This is what I meant by "64-bit data path". (Note: this is an oversimplification. There are two VST standards: VST2 and VST3. They're very different. VST3 requires 64-bit data path support. VST2 doesn't, but IIRC, somewhere between VST2 and VST2.4 it appeared as optional. It's possible to have compatibility issues between host and plugin regarding VST2 vs VST3. So, I'm just talking about supporting 64-bit data path.)
In any case, when we say "64-bit VST" there are really two completely different things we might mean. Most likely the OP was talking about the first: whether it uses the x86 instruction set or the x64 instruction set. The more I think about it, I guess my question was dumb because I doubt anyone cares about 64-bit data path, and VSTs that support 32-bit data path aren't disappearing. Sorry, please move on.
When the VST interface was first defined by Steinberg:
* It was for the Intel/AMD 32-bit processor instruction set. (As in, x86 rather than x64).
* The data path (sample format) was 32-bit floating point numbers (IEEE single-precision floating point rather than double-precision, AKA "float" vs "double" in the C programming language.)
Since then, we have 64-bit processors, with new instructions and more registers, and they run a lot faster at the expense of using a bit more memory. The code has to be compiled that way. This is what I meant by "64-bit executable / instruction set". 64-bit plugins are not compatible with 32-bit hosts, and vice-versa, although some hosts are smart enough to automatically load a container to run the other type. For example, the Reaper DAW does this and you don't even notice it.
Since then, a new version of the VST standard has come out that supports a 64-bit data path and other enhancements. Hosts that support the new VSTs will also support old ones. I don't know whether new VSTs will work in old hosts; they might. This is what I meant by "64-bit data path". (Note: this is an oversimplification. There are two VST standards: VST2 and VST3. They're very different. VST3 requires 64-bit data path support. VST2 doesn't, but IIRC, somewhere between VST2 and VST2.4 it appeared as optional. It's possible to have compatibility issues between host and plugin regarding VST2 vs VST3. So, I'm just talking about supporting 64-bit data path.)
In any case, when we say "64-bit VST" there are really two completely different things we might mean. Most likely the OP was talking about the first: whether it uses the x86 instruction set or the x64 instruction set. The more I think about it, I guess my question was dumb because I doubt anyone cares about 64-bit data path, and VSTs that support 32-bit data path aren't disappearing. Sorry, please move on.