Change wording

This commit is contained in:
Robbert van der Helm
2022-10-02 23:47:07 +02:00
parent e8f8efd639
commit 3d832159b3
7 changed files with 9 additions and 9 deletions
+1 -1
View File
@@ -64,7 +64,7 @@ template <typename Thread>
class MutualRecursionHelper {
public:
/**
* Run `fn` from a new thread, while handling calls to `handle()` and
* Run `fn` from a new thread, during calls to `handle()` and
* `maybe_handle()` on this thread. See the docstring on
* `MutualRecursionHelper` for more information on this mechanism.
*
+1 -1
View File
@@ -110,7 +110,7 @@ class YaMessagePtr : public Steinberg::Vst::IMessage {
* Instead, we'll send a thin wrapper that only stores a name and a pointer to
* the actual object. This is needed in case the plugin tries to store the
* `IMessage` object, thinking it's backed by a smart pointer. This means that
* the message we pass while handling `IConnectionPoint::notify` should live as
* the message we pass during `IConnectionPoint::notify` should live as
* long as the original message object, thus we'll use a pointer to get back the
* original message object.
*
@@ -127,7 +127,7 @@ Steinberg::Vst::ProcessData& YaProcessData::reconstruct(
// The actual audio data is contained within a shared memory object, and the
// input and output pointers point to regions in that object. These pointers
// are calculated while handling `IAudioProcessor::setActive()`.
// are calculated during `IAudioProcessor::setActive()`.
// NOTE: The 32-bit and 64-bit audio pointers are a union, and since this is
// a raw memory buffer we can set either `channelBuffers32` or
// `channelBuffers64` to point at that buffer as long as we do the
+3 -3
View File
@@ -57,8 +57,8 @@ Vst2Bridge* current_bridge_instance = nullptr;
*
* NOTE: This is needed for Voxengo VST2 plugins in Renoise. When
* `effSetChunk()` is called from the GUI thread, Voxengo VST2 plugins
* will (wrongly) call `audioMasterUpdateDisplay()` while handling that
* call. Renoise then calls `effGetProgram()` while handling that which
* will (wrongly) call `audioMasterUpdateDisplay()` during that
* call. Renoise then calls `effGetProgram()` during that which
* shouldn't cause any issues, but the Voxengo plugins try to lock
* recursive mutexes on both functions so `effGetProgram()` _has_ to be
* called on the same thread that is currently calling
@@ -89,7 +89,7 @@ static const std::unordered_set<int> safe_mutually_recursive_requests{
* involve GUI operations.
*
* NOTE: `effMainsChanged` is the odd one here. EZdrummer interacts with the
* Win32 message loop while handling this function. If we don't execute
* Win32 message loop during this function. If we don't execute
* this from the main GUI thread, then EZdrummer won't produce any sound.
* NOTE: `effSetChunk` and `effGetChunk` should be callable from any thread, but
* Algonaut Atlas doesn't restore chunk data unless `effSetChunk` is run
+1 -1
View File
@@ -1826,7 +1826,7 @@ size_t Vst3Bridge::register_object_instance(
void Vst3Bridge::unregister_object_instance(size_t instance_id) {
// Tear the dedicated audio processing socket down again if we
// created one while handling `Vst3PluginProxy::Construct`
// created one during `Vst3PluginProxy::Construct`
if (const auto& [instance, _] = get_instance(instance_id);
instance.interfaces.audio_processor || instance.interfaces.component) {
sockets_.remove_audio_processor(instance_id);
+1 -1
View File
@@ -147,7 +147,7 @@ struct Vst3PluginInstance {
* If the host passes an `IPlugFrame` object during `IPlugView::setFrame()`,
* then we'll store a proxy object here and then pass it to
* `plug_view->setFrame()`. Will be initialized with a null pointer until
* used. When we destroy `plug_view` while handling
* used. When we destroy `plug_view` during
* `Vst3PlugViewProxy::Destruct`, we'll also destroy (our pointer of) this
* proxy object.
*/