VST Plugins - Revision history

Techbot at 10:42, 21 February 2022

2022-02-21T10:42:56Z

← Older revision		Revision as of 12:42, 21 February 2022
Line 1:		Line 1:
			[[Coding]]
	= Virtual Studio Technology =		= Virtual Studio Technology =
	(VST) is an audio plug-in software interface that integrates software synthesizers and effects units into digital audio workstations. VST and similar technologies use digital signal processing to simulate traditional recording studio hardware in software. Thousands of plugins exist, both commercial and freeware, and many audio applications support VST under license from its creator, Steinberg.		(VST) is an audio plug-in software interface that integrates software synthesizers and effects units into digital audio workstations. VST and similar technologies use digital signal processing to simulate traditional recording studio hardware in software. Thousands of plugins exist, both commercial and freeware, and many audio applications support VST under license from its creator, Steinberg.

Techbot: /* Download */

2022-02-21T10:41:06Z

Download

← Older revision		Revision as of 12:41, 21 February 2022
Line 11:		Line 11:


	= Download =		== Download ==
	https://www.steinberg.net/developers/		https://www.steinberg.net/developers/

Techbot: /* 2.5.5 Multi-Threaded Software */

2022-02-21T10:40:19Z

2.5.5 Multi-Threaded Software

← Older revision		Revision as of 12:40, 21 February 2022
Line 255:		Line 255:
	The API-specific chapters that follow will elaborate with the details as they relate to those plugin specifications. Before we move on, we need to discuss the labels in Figure 2.4 that involve the threads and safe copy mechanisms.		The API-specific chapters that follow will elaborate with the details as they relate to those plugin specifications. Before we move on, we need to discuss the labels in Figure 2.4 that involve the threads and safe copy mechanisms.

	== 2.5.5 Multi-Threaded Software ==		=== 2.5.5 Multi-Threaded Software ===
	If you’ve studied microprocessor design and programming, you’ve come across something called the instruction pointer (IP). At its lowest level, all software runs in a loop of three stages: fetch, decode, and execute. The program fetches an instruction from memory, decodes it, and then executes the instruction. The IP points to the current instruction that is being fetched. After the instruction executes—and assuming no branching occurred—the IP will be updated to point to the next instruction in the sequence and the three-step cycle repeats. Branching (if/then statements) will alter the IP to jump to a new location in code. Function calls do the same thing and alter the IP accordingly. We say that the IP “moves through instructions” in the program. There was a time when you could write a piece of		If you’ve studied microprocessor design and programming, you’ve come across something called the instruction pointer (IP). At its lowest level, all software runs in a loop of three stages: fetch, decode, and execute. The program fetches an instruction from memory, decodes it, and then executes the instruction. The IP points to the current instruction that is being fetched. After the instruction executes—and assuming no branching occurred—the IP will be updated to point to the next instruction in the sequence and the three-step cycle repeats. Branching (if/then statements) will alter the IP to jump to a new location in code. Function calls do the same thing and alter the IP accordingly. We say that the IP “moves through instructions” in the program. There was a time when you could write a piece of
	software with only one IP; most of us wrote our first “Hello World” program like that. An instruction pointer that is moving through a program from one instruction to the next is called a thread or a thread of execution.		software with only one IP; most of us wrote our first “Hello World” program like that. An instruction pointer that is moving through a program from one instruction to the next is called a thread or a thread of execution.

Techbot: /* 2.5.2 Parameter Smoothing */

2022-02-21T10:39:25Z

2.5.2 Parameter Smoothing

← Older revision		Revision as of 12:39, 21 February 2022
Line 232:		Line 232:
	variables separate involves parameter smoothing.		variables separate involves parameter smoothing.

	== 2.5.2 Parameter Smoothing ==		=== 2.5.2 Parameter Smoothing ===

	You can see in Figure 2.6a that the plugin parameters are transferred into the plugin only at the beginning of the buffer processing cycle. If the user makes drastic adjustments on the GUI control, then the parameter changes arriving at the plugin may be coarsely quantized, which can cause clicks		You can see in Figure 2.6a that the plugin parameters are transferred into the plugin only at the beginning of the buffer processing cycle. If the user makes drastic adjustments on the GUI control, then the parameter changes arriving at the plugin may be coarsely quantized, which can cause clicks

Techbot: /* 2.5.1 Plugin Variables and Plugin Parameters */

2022-02-21T10:38:42Z

2.5.1 Plugin Variables and Plugin Parameters

← Older revision		Revision as of 12:38, 21 February 2022
Line 195:		Line 195:
	output, this is where they would generate these MIDI messages as well.		output, this is where they would generate these MIDI messages as well.

	== 2.5.1 Plugin Variables and Plugin Parameters ==		=== 2.5.1 Plugin Variables and Plugin Parameters ===

	It is important to understand the difference between the plugin’s internal variables and the plugin parameters. Each plugin parameter holds a value that relates to its current state—that value may be originating with a user–GUI interaction or automation, or it may be an output value that represents		It is important to understand the difference between the plugin’s internal variables and the plugin parameters. Each plugin parameter holds a value that relates to its current state—that value may be originating with a user–GUI interaction or automation, or it may be an output value that represents

Techbot: /* 3.5.1 Thread-Safe Parameter Access */

2022-02-21T10:37:51Z

3.5.1 Thread-Safe Parameter Access

← Older revision		Revision as of 12:37, 21 February 2022
Line 627:		Line 627:
	parameters.addParameter(param);		parameters.addParameter(param);

	===3.5.1 Thread-Safe Parameter Access ===		=== 3.5.1 Thread-Safe Parameter Access ===
	The controller component is used for accessing the parameters as normalized values. The		The controller component is used for accessing the parameters as normalized values. The
	SingleComponentEffect object inherits the controller component, so your plugin object simply calls		SingleComponentEffect object inherits the controller component, so your plugin object simply calls
Line 635:		Line 635:
	ParamValue PLUGIN_API getParamNormalized(ParamID id);		ParamValue PLUGIN_API getParamNormalized(ParamID id);
	tresult PLUGIN_API setParamNormalized(ParamID id, ParamValue value);		tresult PLUGIN_API setParamNormalized(ParamID id, ParamValue value);
	3.5.2 Initialization: Defining Plugin Channel I/O Support
	As of this writing, VST3 has the broadest audio channel support of all of the APIs: it includes 33		=== 3.5.2 Initialization: Defining Plugin Channel I/O Support ===
	traditional formats (mono, stereo, 5.1, 7.1, etc.), three Ambisonics® formats, and a whopping 27
	different 3-D formats for a total of 63 supported channel I/O types. These input/output channel formats		As of this writing, VST3 has the broadest audio channel support of all of the APIs: it includes 33 traditional formats (mono, stereo, 5.1, 7.1, etc.), three Ambisonics® formats, and a whopping 27 different 3-D formats for a total of 63 supported channel I/O types. These input/output channel formats are named speaker arrangements and you can find their definitions in vstspeaker.h. When the user sets up a session track with a specific channel format and loads your plugin, the host will query it to find out if the format is supported. The system is quite robust and (as with the other APIs) it allows for
	are named speaker arrangements and you can find their definitions in vstspeaker.h. When the user sets		different input and output formats. There is some dependence on the host’s own capabilities as well, but the specification allows for maximum flexibility. For example, if the user loads a 5.1 audio file, the host will query you to see if your plugin supports 5.1. But what if you have some kind of specialized
	up a session track with a specific channel format and loads your plugin, the host will query it to find		plugin that operates on the left and right surround channels only? The host will query that as well: the speaker arrangement named kStereoSurround is a two-channel format just for this purpose.
	out if the format is supported. The system is quite robust and (as with the other APIs) it allows for
	different input and output formats. There is some dependence on the host’s own capabilities as well,		For most DAWs, the host will call the function setBusArrangements repeatedly to see if your plugin can handle the audio file format, or any of its sub-formats as discussed earlier. Your plugin must not only reply with a true/false answer, but also must set up the audio busses on the plugin component
	but the specification allows for maximum flexibility. For example, if the user loads a 5.1 audio file, the
	host will query you to see if your plugin supports 5.1. But what if you have some kind of specialized
	plugin that operates on the left and right surround channels only? The host will query that as well: the
	speaker arrangement named kStereoSurround is a two-channel format just for this purpose.
	For most DAWs, the host will call the function setBusArrangements repeatedly to see if your plugin
	can handle the audio file format, or any of its sub-formats as discussed earlier. Your plugin must not
	only reply with a true/false answer, but also must set up the audio busses on the plugin component
	in response. Two functions named addAudioInput and addAudioOutput are used for this purpose.		in response. Two functions named addAudioInput and addAudioOutput are used for this purpose.
	However, you need to clear out any previously declared busses to adapt to the new scheme. Some very		However, you need to clear out any previously declared busses to adapt to the new scheme. Some very limited or very specialized VST3 hosts may support only one audio channel I/O scheme, so you should actually set up your audio I/O twice: once in the initialize function, and then again in response to the
	limited or very specialized VST3 hosts may support only one audio channel I/O scheme, so you should		setBusArrangements queries. For example, suppose your plugin supports mono in/mono out and stereo in/stereo out operation, and your preferred default arrangement is stereo in/stereo out. First, you would set up the busses inside the initialize function:
	actually set up your audio I/O twice: once in the initialize function, and then again in response to the
	setBusArrangements queries. For example, suppose your plugin supports mono in/mono out and stereo
	in/stereo out operation, and your preferred default arrangement is stereo in/stereo out. First, you would
	set up the busses inside the initialize function:
	addAudioInput(STR16 ("Stereo In"), SpeakerArr::kStereo);		addAudioInput(STR16 ("Stereo In"), SpeakerArr::kStereo);
	addAudioOutput(STR16 ("Stereo Out"), SpeakerArr::kStereo);		addAudioOutput(STR16 ("Stereo Out"), SpeakerArr::kStereo);
	Next, you would override the setBusArrangements function to handle other combinations and
	schemes. The arguments for setBusArrangements will pass you an array of input and output speaker		Next, you would override the setBusArrangements function to handle other combinations and schemes. The arguments for setBusArrangements will pass you an array of input and output speaker arrangements and channel counts. The following snippet is based on the VST3 sample project AGainWithSideChain (you can find more variations in the numerous other sample projects, so definitely check out that code). If you are supporting many formats and sub-variants, this code can become tricky, as you might have a bunch of logic to sort through. There are a few things to observe here. Note how the audio busses are cleared out with removeAudioBusses: if you support a side chain input, you must re-create it any time you remove all busses. Here, the side chain is mono (some code has been removed for brevity):
	arrangements and channel counts. The following snippet is based on the VST3 sample project
	AGainWithSideChain (you can find more variations in the numerous other sample projects, so
	definitely check out that code). If you are supporting many formats and sub-variants, this code can
	become tricky, as you might have a bunch of logic to sort through. There are a few things to observe
	here. Note how the audio busses are cleared out with removeAudioBusses: if you support a side chain
	input, you must re-create it any time you remove all busses. Here, the side chain is mono (some code
	has been removed for brevity):
	tresult PLUGIN_API setBusArrangements(SpeakerArrangement* inputs,		tresult PLUGIN_API setBusArrangements(SpeakerArrangement* inputs,
	int32 numIns,		int32 numIns,
Line 690:		Line 672:
	etc...		etc...
	}		}

	=== 3.5.3 Initialization: Channel Counts and Sample Rate Information ===		=== 3.5.3 Initialization: Channel Counts and Sample Rate Information ===

Techbot: /* 2.4.1 Processing: Audio Signal Processing (DSP) */

2022-02-21T10:36:15Z

2.4.1 Processing: Audio Signal Processing (DSP)

← Older revision		Revision as of 12:36, 21 February 2022
Line 160:		Line 160:
	audio streaming, and this is where you will perform these operations. In ASPiK, we call this the reset( )operation; if you used RackAFX v1 (RAFX1), the function was called prepareForPlay( )—a secret nod to the Korg 1212 I/O product that I designed, whose driver API used a function with the identical name. In each of the programming guide chapters, there is a section dedicated to this operation that explains the function name and how to initialize your algorithm. One thing to note: trying to use transport information from the host (i.e. information about the host’s transport state: playing, stopped, looping, etc.) is usually going to be problematic, unless the plugin specifically requires information about the process—for example, a pattern looping algorithm that needs to know how many bars are looping and what the current bar includes. In addition, some hosts are notoriously incorrect when they report their transport states (e.g. Apple Logic) so they may report that audio is streaming when it is not.		audio streaming, and this is where you will perform these operations. In ASPiK, we call this the reset( )operation; if you used RackAFX v1 (RAFX1), the function was called prepareForPlay( )—a secret nod to the Korg 1212 I/O product that I designed, whose driver API used a function with the identical name. In each of the programming guide chapters, there is a section dedicated to this operation that explains the function name and how to initialize your algorithm. One thing to note: trying to use transport information from the host (i.e. information about the host’s transport state: playing, stopped, looping, etc.) is usually going to be problematic, unless the plugin specifically requires information about the process—for example, a pattern looping algorithm that needs to know how many bars are looping and what the current bar includes. In addition, some hosts are notoriously incorrect when they report their transport states (e.g. Apple Logic) so they may report that audio is streaming when it is not.

	==2.4.1 Processing: Audio Signal Processing (DSP) ==		=== 2.4.1 Processing: Audio Signal Processing (DSP) ===

	Ultimately the effects plugin must process audio information, transforming it in some way. The audio data come either from audio files loaded into a session, or from real-time audio streaming into the audio adaptor. These days, and across all APIs, the audio input and output samples are formatted as floating point data on the range of [−1.0, +1.0] as described in Chapter 1. AU, AAX (native), and RAFX use float data types while VST3 allows either float or double data types, though these will likely change over time. In either case we will perform floating point math and we will encode all of our C++ objects to operate internally with double data types. In an interesting—but not unexpected—twist, all of the APIs send and receive multi-channel audio in the exact same manner. From the plugin’s point of view, it doesn’t matter whether the audio data comes from an audio file or from live input into hardware, or whether the final destination for the data is a file or audio hardware. In Figure 2.3 we’ll assume we have live audio streaming into the DAW.		Ultimately the effects plugin must process audio information, transforming it in some way. The audio data come either from audio files loaded into a session, or from real-time audio streaming into the audio adaptor. These days, and across all APIs, the audio input and output samples are formatted as floating point data on the range of [−1.0, +1.0] as described in Chapter 1. AU, AAX (native), and RAFX use float data types while VST3 allows either float or double data types, though these will likely change over time. In either case we will perform floating point math and we will encode all of our C++ objects to operate internally with double data types. In an interesting—but not unexpected—twist, all of the APIs send and receive multi-channel audio in the exact same manner. From the plugin’s point of view, it doesn’t matter whether the audio data comes from an audio file or from live input into hardware, or whether the final destination for the data is a file or audio hardware. In Figure 2.3 we’ll assume we have live audio streaming into the DAW.
Line 185:		Line 185:
	But many algorithms require that all of the information to each channel is known at the time when each channel is processed. Examples would include a stereo-to-mono fold-down plugin, a ping-pong delay, many reverb algorithms, and a stereo-linked dynamics processor. Since frame processing is a subset of buffer processing and is the most generic, we will be doing all of the book processing in frames.		But many algorithms require that all of the information to each channel is known at the time when each channel is processed. Examples would include a stereo-to-mono fold-down plugin, a ping-pong delay, many reverb algorithms, and a stereo-linked dynamics processor. Since frame processing is a subset of buffer processing and is the most generic, we will be doing all of the book processing in frames.

	2.5 Mixing Parameter Changes With Audio ~~ProcessingOur~~ plugin needs to deal with the parameter changes that occur in parallel with the audio processing and this is where things become tricky. The incoming parameter changes may originate with the user’s GUI interaction, or they may occur as a result of automation. Either way we have an interesting issue to deal with: there are two distinct activities happening during our plugin operation. In one case, the DAW is sending audio data to the plugin for processing, and in the other the user is interacting with the GUI—or running automation, or doing both—and this requires the plugin to periodically re-configure its internal operation and algorithm parameters. The user does not really experience the plugin as two activities: they simply listen to the audio and adjust the GUI as needed. For the user, this is all one unified operation. We may also have output parameters to send back to the GUI; this usually takes the		== 2.5 Mixing Parameter Changes With Audio Processing ==
			Our plugin needs to deal with the parameter changes that occur in parallel with the audio processing and this is where things become tricky. The incoming parameter changes may originate with the user’s GUI interaction, or they may occur as a result of automation. Either way we have an interesting issue to deal with: there are two distinct activities happening during our plugin operation. In one case, the DAW is sending audio data to the plugin for processing, and in the other the user is interacting with the GUI—or running automation, or doing both—and this requires the plugin to periodically re-configure its internal operation and algorithm parameters. The user does not really experience the plugin as two activities: they simply listen to the audio and adjust the GUI as needed. For the user, this is all one unified operation. We may also have output parameters to send back to the GUI; this usually takes the
	form of volume unit (VU) metering. We might also have a custom graph view that requires us to send it information. All of these things come together during the buffer processing cycle. We’ve already established that in all APIs the audio is processed in buffers, and the mechanism is a function call into your plugin. For AU and VST the function call has a predefined name, and in AAX you can name the function as you wish. So in all cases, the entire buffer processing cycle happens within a single function call. We can break the buffer processing cycle into three phases of operation.		form of volume unit (VU) metering. We might also have a custom graph view that requires us to send it information. All of these things come together during the buffer processing cycle. We’ve already established that in all APIs the audio is processed in buffers, and the mechanism is a function call into your plugin. For AU and VST the function call has a predefined name, and in AAX you can name the function as you wish. So in all cases, the entire buffer processing cycle happens within a single function call. We can break the buffer processing cycle into three phases of operation.

Techbot: /* 2.3.2 Initialization: Sample Rate Dependency */

2022-02-21T10:35:37Z

2.3.2 Initialization: Sample Rate Dependency

← Older revision		Revision as of 12:35, 21 February 2022
Line 150:		Line 150:
	surround to stereo fold-down). Each API has a different way of specifying channel I/O support; it may be implemented as part of the plugin description, or the initialization, or a combination of both. You can find the exact mechanisms for each API in the plugin programming guide chapters that follow.		surround to stereo fold-down). Each API has a different way of specifying channel I/O support; it may be implemented as part of the plugin description, or the initialization, or a combination of both. You can find the exact mechanisms for each API in the plugin programming guide chapters that follow.

	== 2.3.2 Initialization: Sample Rate Dependency ==		=== 2.3.2 Initialization: Sample Rate Dependency ===

	Almost all of the plugin algorithms we study are sensitive to the current DAW sample rate, and its value is usually part of a set of equations we use to process the audio signal. Many plugins will support just about any sample rate, and its value is treated similarly to plugin parameters—it is just another		Almost all of the plugin algorithms we study are sensitive to the current DAW sample rate, and its value is usually part of a set of equations we use to process the audio signal. Many plugins will support just about any sample rate, and its value is treated similarly to plugin parameters—it is just another

Techbot: /* 2.3.1 Initialization: Defining Channel I/O Support */

2022-02-21T10:35:17Z

2.3.1 Initialization: Defining Channel I/O Support

← Older revision		Revision as of 12:35, 21 February 2022
Line 144:		Line 144:


	== 2.3.1 Initialization: Defining Channel I/O Support ==		=== 2.3.1 Initialization: Defining Channel I/O Support ===

	An audio plugin is designed to work with some combination of input and output channels. The most basic channel support is for three common setups: mono in/mono out, mono in/stereo out, and stereo in/stereo out. However, some plugins are designed for very specific channel processing (e.g. 7.1 DTS® vs.		An audio plugin is designed to work with some combination of input and output channels. The most basic channel support is for three common setups: mono in/mono out, mono in/stereo out, and stereo in/stereo out. However, some plugins are designed for very specific channel processing (e.g. 7.1 DTS® vs.

Techbot: /* 2.2.1 The Plugin Description: Features and Options */

2022-02-21T10:34:54Z

2.2.1 The Plugin Description: Features and Options

← Older revision		Revision as of 12:34, 21 February 2022
Line 88:		Line 88:
	value is generated for you when you create the project.		value is generated for you when you create the project.

	== 2.2.1 The Plugin Description: Features and Options ==		=== 2.2.1 The Plugin Description: Features and Options ===

	In addition to these simple strings and flags, there are some more complicated things that the plugin needs to define for the host at load-time. These are listed here and described in the chapters ahead.		In addition to these simple strings and flags, there are some more complicated things that the plugin needs to define for the host at load-time. These are listed here and described in the chapters ahead.