diff --git a/docs/architecture.md b/docs/architecture.md
index ab7cd787..cfcb2d04 100644
--- a/docs/architecture.md
+++ b/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
diff --git a/src/common/mutual-recursion.h b/src/common/mutual-recursion.h
index 14989a45..3ece5163 100644
--- a/src/common/mutual-recursion.h
+++ b/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.
      *
diff --git a/src/common/serialization/vst3/message.h b/src/common/serialization/vst3/message.h
index 7f416607..45096481 100644
--- a/src/common/serialization/vst3/message.h
+++ b/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.
  *
diff --git a/src/common/serialization/vst3/process-data.cpp b/src/common/serialization/vst3/process-data.cpp
index 653ad120..8d985e70 100644
--- a/src/common/serialization/vst3/process-data.cpp
+++ b/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
diff --git a/src/wine-host/bridges/vst2.cpp b/src/wine-host/bridges/vst2.cpp
index 6cf5f45e..2bf5b5f0 100644
--- a/src/wine-host/bridges/vst2.cpp
+++ b/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
- *       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
diff --git a/src/wine-host/bridges/vst3.cpp b/src/wine-host/bridges/vst3.cpp
index afa685a1..20a5e3cd 100644
--- a/src/wine-host/bridges/vst3.cpp
+++ b/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);
diff --git a/src/wine-host/bridges/vst3.h b/src/wine-host/bridges/vst3.h
index a0365f6e..f1b2b41f 100644
--- a/src/wine-host/bridges/vst3.h
+++ b/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.
      */