//------------------------------------------------------------------------
@@ -208,7 +208,7 @@
//...
tresult PLUGIN_API getCompatibilityJSON (IBStream* stream) override
{
- /* write in the stream the JSON compatibility array
+ /* write the JSON compatibility array into the stream
[
{
"New": "BD58B550F9E5634E9D2EFF39EA0927B1",
diff --git a/pages/Technical+Documentation/Change+History/3.7.9/IComponentHandlerSystemTime.html b/pages/Technical+Documentation/Change+History/3.7.9/IComponentHandlerSystemTime.html
index 9fca4883..83d126fb 100644
--- a/pages/Technical+Documentation/Change+History/3.7.9/IComponentHandlerSystemTime.html
+++ b/pages/Technical+Documentation/Change+History/3.7.9/IComponentHandlerSystemTime.html
@@ -179,7 +179,7 @@
-
Extended plug-in interface IComponentHandler for an edit controller, IComponentHandlerSystemTime allows the plug-in to ask for the current systemTime (this should be the kind of time reference than the one used in ProcessContext::systemTime).
+Extended plug-in interface IComponentHandler for an edit controller, IComponentHandlerSystemTime allows the plug-in to ask for the current systemTime (this should be the same kind of time reference than the one used in ProcessContext::systemTime, this one is not compensated like the one of the ProcessContext).
- [host imp]
- [extends IComponentHandler]
diff --git a/pages/Technical+Documentation/Data+Exchange/Index.html b/pages/Technical+Documentation/Data+Exchange/Index.html
index 3fa161ef..cf5f2701 100644
--- a/pages/Technical+Documentation/Data+Exchange/Index.html
+++ b/pages/Technical+Documentation/Data+Exchange/Index.html
@@ -195,22 +195,22 @@
-In a modern plug-in the UI representation and the audio processing do not share any data directly.
-This eliminates undefined behaviour as they run in different threads and any directly shared data would
+
In a modern plug-in, the UI representation and the audio processing do not share any data directly.
+This eliminates undefined behavior, as they run in different threads and any directly shared data would
need to be protected by a mutex. But a mutex has no defined running time and may block the audio
-thread for too long creating an audible glitch which must be prevented.
+thread for too long, creating an audible glitch, which must be prevented.
The other issue with sharing data between the UI and the audio processing is that the audio is
-processed earlier than the time when the audio is streamed thru the monitor boxes or headphones.
-Without synchronization the visual representation will be shown earlier than the sound it represents.
+processed before the audio is streamed through the monitor boxes or headphones.
+Without synchronization, the visual representation is displayed earlier than the sound it represents.
To synchronize the visual representation and the processing of the audio signal, the UI has to queue
-the visual data until the time is reached the audio is heard.
-This problem is already solved for parameters which are automated by the host. The host delays
-sending the parameter change to the edit controller so that it is in sync with the heard audio.
+the visual data until the time is reached when the audio is heard.
+This problem has already been solved for parameters which are automated by the host. The host delays
+sending the parameter change to the edit controller so that it is in sync with the audible audio.
But parameters are limited in how much data they can transfer, this may be enough for a simple peak
-VU meter display, but presenting a FFT curve with it is a nightmare.
+VU meter display, but presenting an FFT curve with it is a nightmare.
Version 3.7.9 of the SDK contains the new Data Exchange API to send data from the realtime
processing function to the controller in a safe and efficient way.
-As this API needs support from the host and not all hosts will provide this API in the beginning
+
As this API needs support from the host and not all hosts provide this API right from the start,
the SDK contains a backwards compatibility layer that either uses the API directly, if available, or
an alternative method based on the IMessage API to emulate the API. See the
tutorial on how to use it.
@@ -221,39 +221,32 @@ queueOpened method when an exchange queue is opened by the processor. Later when the processor closes the queue, the host will call the queueClosed method.
+
While the queue is open, the host will call the onDataExchangeBlocksReceived method whenever the processor has sent data.
+The edit controller can decide in the call to queueOpened if the host should deliver the data on a background thread or on the UI thread.
diff --git a/pages/Technical+Documentation/Index.html b/pages/Technical+Documentation/Index.html
index 99dc6151..60776e84 100644
--- a/pages/Technical+Documentation/Index.html
+++ b/pages/Technical+Documentation/Index.html
@@ -267,9 +267,9 @@
A new way to control / modify / change a specific played note during playback.
-Allows information exchange between the plug-in and host about which key switches are currently used.
+Allows information exchange between the plug-in and the host about which key switches are currently used.
-How to better support remote (UI and hardware) for parameters.
+How to better support remote devices/controllers (UI and hardware) for parameters.
A plug-in can ask the host to create a context menu for a given exported parameter ID or a generic context menu.
@@ -305,7 +305,7 @@
This interface allows the host to get a parameter associated to a specific meaning (a functionName) for a given unit
-Allows the plug-in to request the host to create a progress for some specific tasks which take some time.
+Allows the plug-in to ask the host to create a progress for specific tasks which take some time.
To get accurate process context information (Vst::ProcessContext), it is now required to implement this interface.
@@ -313,7 +313,7 @@
Allows a plug-in to ask the host for the current system time.
-These interfaces allows to send data with a direct and thread-safe connection from the realtime audio context of the audio processor to the non-realtime audio context of the edit controller.
+These interfaces allow you to send data with a direct and thread-safe connection from the realtime audio context of the audio processor to the non-realtime audio context of the edit controller.
diff --git a/pages/Technical+Documentation/Locations+Format/Plugin+Locations.html b/pages/Technical+Documentation/Locations+Format/Plugin+Locations.html
index 02e9d2f2..31d2d96b 100644
--- a/pages/Technical+Documentation/Locations+Format/Plugin+Locations.html
+++ b/pages/Technical+Documentation/Locations+Format/Plugin+Locations.html
@@ -206,7 +206,7 @@
ⓘ Note
-The host should scan at first higher level of priority, first found plug-in (for a given Processor UID) has to be used.
+The host should scan, at first, higher level of priority. First found plug-in (for a given Processor UID) has to be used.
On the macOS platform, the host application expects VST 3 plug-ins to be located in:
diff --git a/pages/Technical+Documentation/Presets+Program+Lists/Index.html b/pages/Technical+Documentation/Presets+Program+Lists/Index.html
index 9ca77620..d79a9a7f 100644
--- a/pages/Technical+Documentation/Presets+Program+Lists/Index.html
+++ b/pages/Technical+Documentation/Presets+Program+Lists/Index.html
@@ -226,7 +226,7 @@
-
All programs are always transmitted as a flat list to the host. But the plug-in can assign a number of attributes to each program of the list. This enables the host to organize and filter them in a very flexible way. Attribute values are queried via Steinberg::Vst::IUnitInfo::getProgramInfo. The possible attribute identifiers are defined in namespace Steinberg::Vst::PresetAttributes. The attribute identifier specifying a program category, for example, is Steinberg::Vst::PresetAttributes::kInstrument. Although the name suggests that it should be used for instruments only, it can be used for any kind of audio plug-in. The value for an instrument category of a program is "Piano" for example. But it is possible to specify a subcategory like "Acoustic Piano" as well. In this case, the strings need to be chained like this:
+
All programs are always transmitted as a flat list to the host. But the plug-in can assign a number of attributes to each program of the list. This enables the host to organize and filter them in a very flexible way. Attribute values are queried via Steinberg::Vst::IUnitInfo::getProgramInfo. The possible attribute identifiers are defined in namespace Steinberg::Vst::PresetAttributes. The attribute identifier specifying a program category, for example, is Steinberg::Vst::PresetAttributes::kInstrument. Although the name suggests that it should be used for instruments only, it can be used for any kind of audio plug-in. The value for an instrument category of a program is "Piano" for example. But it is possible to specify a subcategory like "Acoustic Piano" as well. In this case, the strings need to be chained in the following way:
"Piano|Acoustic Piano". This allows the host to organize presets in a category tree view, for example.
Pitch names are intended to be used with drum kit programs where the different drum sounds are addressed by note pitches. In order to display the name of the drum instrument assigned to a pitch in a drum editor, for example, the host calls Steinberg::Vst::IUnitInfo::hasProgramPitchNames to determine if pitch names are supported and Steinberg::Vst::IUnitInfo::getProgramPitchName to query the pitch name of a single note.
diff --git a/pages/Technical+Documentation/Provide+A+Runloop+On+Linux/Index.html b/pages/Technical+Documentation/Provide+A+Runloop+On+Linux/Index.html
index 162e011f..2f0d8d67 100644
--- a/pages/Technical+Documentation/Provide+A+Runloop+On+Linux/Index.html
+++ b/pages/Technical+Documentation/Provide+A+Runloop+On+Linux/Index.html
@@ -178,7 +178,7 @@
-
On Linux there is no global event run loop like on Windows and macOS. For this reason the plug-in can query for an Linux::IRunLoop which must be provided by the host application in two different ways.
+On Linux, there is no global event run loop like on Windows and macOS. For this reason, the plug-in can query for an Linux::IRunLoop which must be provided by the host application in two different ways.
The host application must provide the Linux::IRunLoop via IPlugFrame (by calling IPlugView::setFrame).
// Plug-in implementation
diff --git a/pages/Technical+Documentation/VST+3+Units/Index.html b/pages/Technical+Documentation/VST+3+Units/Index.html
index c29eec64..4d9a58fb 100644
--- a/pages/Technical+Documentation/VST+3+Units/Index.html
+++ b/pages/Technical+Documentation/VST+3+Units/Index.html
@@ -189,10 +189,10 @@ For example, an EQ section can be a unit.
The purposes of units are:
-- Reveal the internal logical structure of the plug-in
-- Organize parameters by associating them with units
-- Support program lists
-- Support handling of Complex Plug-in Structures / Multi-timbral Instruments
+
- To reveal the internal logical structure of the plug-in
+- To organize parameters by associating them with units
+- To Support program lists
+- To support handling of Complex Plug-in Structures / Multi-timbral Instruments
- Multiple program lists (associated with a unit)
- Access to program list data
diff --git a/pages/Technical+Documentation/VST+Module+Architecture/Index.html b/pages/Technical+Documentation/VST+Module+Architecture/Index.html
index 0fa4b3d6..88b01f93 100644
--- a/pages/Technical+Documentation/VST+Module+Architecture/Index.html
+++ b/pages/Technical+Documentation/VST+Module+Architecture/Index.html
@@ -230,7 +230,7 @@
A component-ID or class-ID (CID) is used to identify a concrete implementation class and is usually passed to a class factory in order to create the corresponding component.
So a lot of different classes (with different class identifiers) can implement the same interfaces.
-An interface may have a direction, meaning that the interface is expected to be implemented either in the plug-in or in the host. The nature of an interface is documented like this:
+An interface may have a direction, meaning that the interface is expected to be implemented either in the plug-in or in the host. The nature of an interface is documented in the following way:
- [host imp]: the host implements the interface
- [plug imp]: the plug-in implements the interface
diff --git a/pages/Tutorials/Advanced+VST+3+techniques.html b/pages/Tutorials/Advanced+VST+3+techniques.html
index 726f796b..3e56d504 100644
--- a/pages/Tutorials/Advanced+VST+3+techniques.html
+++ b/pages/Tutorials/Advanced+VST+3+techniques.html
@@ -211,7 +211,7 @@
We have to change the handleParameterChanges function to:
@@ -308,7 +308,7 @@