With VST SDK 2.4 you can compile native VST Plug-Ins for 64 Bit Platforms (e.g. Windows XP x64 Edition). The formerly used 'long' data type has been replaced by VstInt32 and VstIntPtr:
- VstInt32 is always 32 bits wide, regardless of the platform compiled for.
- VstIntPtr is a generic type, with the same size as a pointer (4 Bytes on a 32 bit OS, 8 Bytes on x64 Systems).
A new process function has been added to support 64 bit (double precision) floating-point audio samples. Please note that this function is optional, whereas the processReplacing function for 32 bit (single precision) floating-point samples is mandatory! - See also:
- AudioEffect::canDoubleReplacing
AudioEffect::processDoubleReplacing
AudioEffectX::setProcessPrecision
New enum VstMidiEventFlags for VstMidiEvent::flags with value kVstMidiEventIsRealtime which indicates that an event is played live, not from a sequencer track. This allows the Plug-In to handle these flagged events with higher priority, especially when the Plug-In has a high latency (AEffect::initialDelay).
Two new methods (getNumMidiInputChannels and getNumMidiOutputChannels) allow the Plug-In to inform the host how many MIDI channels are actually used for input and/or output. In this case the host doesnt need to display all 16 MIDI channels to the user, if the Plug-In uses less than 16. - See also:
- AudioEffectX::getNumMidiInputChannels
AudioEffectX::getNumMidiOutputChannels
The VST Parameters Structure XML definition provides an easy way to structure parameters of existing VST Plug-Ins hierarchically, without having to recompile the Plug-In binary. The VST SDK package contains a tool to test, extract and embed VSTXML resources.
- See also:
- VST Parameters Structure
All Plug-Ins built with this SDK must support composited windows on OSX.
- See also:
- Macintosh Editor as HIViewRef
The VST Protocol is a historically grown technology. In Version 2.4 the API has undergone a general cleanup. Some rarely (or not at all) used features and inconsistent or redundant parts of the protocol have been declared as deprecated. Deprecated opcodes and data structures are still available in the SDK headers, but their names are modified if the VST_FORCE_DEPRECATED compile switch is active (1 by default) - this might cause errors when compiling existing code.
What does it mean? Exisiting (already released) Hosts and Plug-Ins of course remain uninfluenced. If you create a new Plug with VST SDK 2.4 it should work in any existing host as well. However, there are some details that might cause compatibility problems:
- MIDI Input: New Plugs should implement AudioEffectX::canDo "receiveVstMidiEvent" to indicate the presence of a MIDI Input, instead of wantEvents. The base class method AudioEffectX::resume can be called for compatibility with old VST hosts (< 2.4).
- MIDI Output: implement AudioEffectX::canDo "sendVstMidiEvent".
- Idle Calls outside Editor: AudioEffectX::needIdle and AudioEffectX::fxIdle are not widely supported, thus Plugs can not rely on it. Please create your own timer/background thread if needed. On Windows SetTimer with a callback function could be used (look it up on MSDN), the MacOS X equivalent is InstallEventLoopTimer.
- No more accumulating process mode: New Plugs have to implement AudioEffect::processReplacing instead!
- The exported 'main' function (aka 'main_macho' on Mac or 'main_plugin') should be named 'VSTPluginMain' on all platforms! For downwards compatibility, you can export both.
To support VST Plug-Ins <= 2.4 in new Host Applications, you'll have to implement workarounds. In the long run, deprecated features shouldn't be used anymore. Future versions of VST SDK will not contain them at all.
- See also:
- Deprecated List
You might have already noticed some more minor changes in VST SDK 2.4:
- New SDK folder structure
- Some files have been renamed (e.g. AudioEffect.hpp -> audioeffect.h)
- MiniHost Example
- Updated documentation
- VSTGUI 3.0 included
Empty