Change wording

docs/architecture.md

@@ -278,7 +278,7 @@ buffers in a big block of shared memory and use the sockets for all other data
 that gets sent along with the actual audio buffers. This also means that the
 sockets act as a form of synchronisation, so we do not need any additional
 inter-process locking. These shared memory audio buffers are defined as part of
-`AudioShmBuffer`, and they are configured while handling `effMainsChanged` for
+`AudioShmBuffer`, and they are configured during `effMainsChanged` for
 VST2 plugins and during `IAudioProcessor::setActive()` for VST3 plugins.
 For VST2 plugins this does mean that we will need to keep track of the maximum
 block size and the sample size reported by the host, since this information is

src/common/mutual-recursion.h

@@ -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.
      *

src/common/serialization/vst3/message.h

@@ -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.
  *

src/common/serialization/vst3/process-data.cpp

@@ -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

src/wine-host/bridges/vst2.cpp

@@ -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
+ *       will (wrongly) call `audioMasterUpdateDisplay()` during that
- *       call. Renoise then calls `effGetProgram()` while handling that which
+ *       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

src/wine-host/bridges/vst3.cpp

@@ -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);

src/wine-host/bridges/vst3.h

@@ -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.
      */