Essentially, a VST Plug-in is a pure audio processing component, and not an audio application: It is a component that is utilized within a host application. This host application provides the audio streams that are processed by the plug-in's code.
Generally speaking, a VST plug-in it can take a stream of audio data, apply a process to the audio, and return the result to the host application. A VST Plug-In performs its process normally using the processor of the computer; It does not necessarily need dedicated digital signal processors. The audio stream is broken down into a series of blocks. The host supplies the blocks in sequence. The host and its current environment control the block-size. The VST Plug-In maintains the status of all its own parameters relating to the running process: The host does not maintain any information about what the plug-in did with the last block of data it processed.
From the host application’s point of view, a VST Plug-In is a black box with an arbitrary number of inputs, outputs (MIDI or Audio), and associated parameters. The host needs no implicit knowledge of the plug-in's process to be able to use it. The plug-in process can use whatever parameters it wishes, internally to the process, but depending on the capabilities of the host, it can allow the changes to user parameters to be automated by the host.
The source code of a VST Plug-In is platform independent, but the delivery system depends on the platform architecture:
- On the Windows platform, a VST Plug-In is a multi-threaded DLL (Dynamic Link Library). A standard (default) folder for the VST Plug-Ins is defined in the registry under "HKEY_LOCAL_MACHINE\SOFTWARE\VST\VSTPluginsPath".
- On Mac OS X, a VST Plug-In is a Bundle. You define the Plug-In's name in the plist.info file with the CFBundleName key.
- On BeOS and SGI (under MOTIF, UNIX), a VST Plug-In is a shared Library.
To learn more about VST you can subscribe to the VST Developer Mailing List - check the 3rd Party Developer Support section at www.steinberg.net.
Audio processing in the plug is accomplished by one of 3 methods, namely process (), processReplacing () and processDoubleReplacing (). While process () takes input data, applies its processing algorithm, and then adds the result to the output (accumulating), processReplacing () and processDoubleReplacing (), overwrite the output buffer.
- Note:
- The accumulating process mode is deprecated in VST 2.4. Please implement processReplacing (mandatory!) and processDoubleReplacing (optional).
Audio data processed by VST Plug-Ins is 32 bit (single precision) and optionally 64 bit (double precision) floating-point data. The default used range is from -1.0 to +1.0 inclusive [-1.0, +1.0] (where 1.0 corresponds to 0dB, 0.5 to -6dB and 0.0 to -oodB). Note that an effect could generate values above this range.
All parameters - the user parameters, acting directly or indirectly on that data, as automated by the host, are 32 bit floating-point data. They must always range from 0.0 to 1.0 inclusive [0.0, +1.0], regardless of their internal or external representation.
- See also:
- Threading issues
If you want to develop a VST Plug-In, you may prefer to go straight to the code examples now. These are very simple examples in which you will learn most of the important basic concepts just by reading a few lines of code. As a Plug-In developer you actually need to know very little about hosting a Plug-In. You should concentrate on the AudioEffect (VST 1.0) and AudioEffectX (VST 2.x extensions) base classes. - Note:
- Never edit any of the SDK source files. Never ever. The host application relies on them being used as they are provided. Anything can be added or changed by overriding in your private classes derived from AudioEffectX.
All user-interface issues are entirely separated from the audio processing issues. At its simplest there is an option where you can avoid providing a user interface at all. In this case the host requests character strings from the Plug-In representing each of the parameters. The host can use the separate ASCII strings for the value, the label, and the units of the parameters to construct its own user interface. This is how the simple code-examples, AGain & ADelay, work. This is also often a good way to develop a VST Plug-In, it offers a very short development cycle to start to test the algorithm. The proper interface can come later.
The next user interface level is provided when the Plug-In defines its own editor. This allows practically any user interface to be defined. A negative aspect is that then you can quickly land up in platform specifics when dealing with the nuts an bolts of the interface issues, even though the audio process, the concepts and methodology remain platform independent.
The final option is to use a portable framework for creating sophisticated user interfaces. This framework takes the form of the VSTGUI Library files that are available for almost all supported VST platforms. The VSTGUI Library classes and their usage is described in separate documentation.
- See also:
- VSTGUI on SourceForge
Empty