In the widest possible sense a VST Plug-In is an audio process. A VST Plug-In is not an application. It needs a host application that handles the audio streams and makes use of the process the VST Plug-In supplies.
Generally speaking, it can take a stream of audio data, apply a process to the audio and send the result back 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 all parameters statuses that refer 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 knowledge of the Plug-In process to be able to use it.
The Plug-In process can use whatever parameters it wishes, internally to the process, but it can choose to allow the changes to user parameters to be automated by the host, if the host application wishes to do so.
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). On Mac OS X , a VST Plug-In is a Bundle. You define the plug's name in the plist.info file with the CFBundleName key. It is also possible to use the old Mac OS 9 format (see below) on OS X, but it is not recommended. On Mac OS 9 , it's a raw Code resource. Note that the plug's name as seen by the user is the resource name (not the file name). A folder labeled 'VstPlugIns' is searched for plugs, this should preferably be installed in the System Folder. Applications should additionally search the application folder. On BeOS, SGI (under MOTIF, UNIX), a VST Plug-In is a shared Library. |
Audio processing in the plug is accomplished by one of 2 methods, namely process (), and processReplacing (). The first one must be provided, while the second one is optional (but it is highly recommended to always implement both methods). While process () takes input data, applies its pocessing algorithm, and then adds the result to the output (accumulating), processReplacing () overwrites the output buffer. The host provides both input and output buffers for either process method.
The reasoning behind the accumulating version (process ()) is that it is much more efficient in the case where many processors operate on the same output (aux-send bus), while for simple chained connection schemes (inserts), the replacing method is more efficient.
All parameters - the user parameters, acting directly or indirectly on that data, as automated by the host, are 32 bit floating-point numbers. They must always range from 0.0 to 1.0 inclusive, regardless of their internal or external representation.
Audio data processed by VST Plug-Ins are 32 bit floating-point numbers. They must always range from -1.0 to +1.0 inclusive.
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 and AudioEffectX base classes.
AudioEffect is the base class, which represents VST 1.0 plugs-ins, and has its declarations in audioeffect.hpp, and the implementation in audioeffect.cpp. You will also need to be aware of the structure definitions in aeffect.h.
The files aeffectx.h (more structures), audioeffectx.h, and audioeffectx.cpp are similar to the ones above, and extend them to the version 2.3 specification.
The files relating to the 2.3 specification have their counterparts in the original 1.0 specification. The original files are expanded upon by versions representing the 2.3 specification. Basically the new classes files all have a 1.0 predecessor but the new ones have an X in the name.
aeffectx.h
includes aeffect.hpp
audioeffectx.h
includes audioeffect.hpp and
audioeffectx.cpp
extends the implementation in audioeffect.cpp
through the
AudioEffectX class, which inherits from AudioEffect and
thus is compatible to the 1.0 specs.
Never edit any of these 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 all supported VST platforms. Apart from converting a few pictures from one resource format to another, for which there are tools available, and setting up the initial project files, writing a VST 2.3 Plug-In can really be completely cross-platform (some given examples: ControlsGUI, ADelayEditGUI, SurroundDelay). VSTGUI Library files and their usage is completely described in the HMTL files that accompany this SDK. After reading about the underlying issues in this document and associated code examples, the VSTGUI comes very highly recommended.
The Steinberg VST Plug-In Software Development Kit can be used freely subject to certain licensing conditions by anyone interested in developing Plug-Ins, or to extend an application so that it’s capable of hosting VST Plug-Ins. When you chose to receive the VST Plug-In SDK you declared yourself to be in agreement with the Licensing conditions.
These notes don’t replace the licensing agreement in any way, but quickly explain what you can and cannot do with the Steinberg VST Plug-In Software Development Kit.
is not time limited.
is subject to the laws of the Federal Republic of Germany only.
its remaining conditions remain valid even if one of the conditions become invalid.
is created with the sole aim that you can create or host VST Plug-Ins.
is offered ‘AS IS’ and we make no claims about how suitable it is for your application.
still holds the copyright for VST Plug-In specification.
are not responsible for anything that happens because you chose to use the VST Plug-In Interface.
cannot be held liable if your use of the VST Plug-In Interfaces causes damage or loss to anyone.
may release improved versions of the Licensed Software Developer Kit
offer no commitment that updates will occur at anytime or for anybody.
are not aware of VST Plug-In technology infringing the intellectual copyright of anyone else,
cannot accept any responsibility for any claims made against you.
transfer your License to anyone
license the information contained in this SDK to anyone else.
sell the information contained in this SDK to anyone.
re-work or otherwise pass this technology off as your own.
give it away or in any other way distribute it, or cause it to be become distributed.
use the VST logo or other marks on promotional merchandise. So no VST t-shirts or baseball caps.
claim to be a partner of Steinberg or be acting on our behalf.
make any statements on Steinberg’s behalf.
bring the VST technology into disrepute, or damage its reputation in any way.
use VST technology in connection with products that are obscene, pornographic.
use VST technology in connection with products that are excessively violent, or in poor taste.
break the rules of the license, or we have the right terminate the License immediately.
include references to Steinberg’s copyrights and trademarks in a product that uses this SDK.
ensure “VST is a trademark of Steinberg Media Technologies GmbH” appears on any packaging
place the VST Logo on packages and promotional material. We provide the artwork.
add our copyright notice to your about box. “VST Plug-In Technology by Steinberg.”
agree that we hold your details on file for our internal purposes.
inform Steinberg immediately if any one makes a claim against you in regard to VST-Plug-Ins.
make sure the end-publisher of your work is also a VST license holder.
make vst Plug-Ins or vst-host applications and distribute them worldwide.
release products without having to pay to use the VST Plug-In Interface technology
use VST technology in demo-versions of your products.
The VSTGUI interfaces & Libraries were created by Wolfgang Kundrus and Yvan Grabit (additional developing Matthias Juwan, Arne Sheffler). The time they have invested has really made the huge inroads into cross-platform code compatibility.
Thanks too, to Philippe Goutier who provided the VST Offline Interface.
Not forgetting Dave Nicholson, Julien Junod, Pierre Jean Camillieri, Janne Roeper who did some additional typing.
There were many more people involved in the creation of this interface, not all of whom can be mentioned here. We extend our thanks not just to the Steinberg Staff and Associates that contributed but also to the many other developers from other parties have helped with their input - mainly all the nice people on the VST Plug-In DEVELOPER MAILING LIST
Thanks to all of you for having made this possible.
Charlie Steinberg 2003