Parmaeters are not real, they can't hurt you

nih_plug_derive/src/params.rs

@@ -25,7 +25,7 @@ pub fn derive_params(input: TokenStream) -> TokenStream {
 
     // We only care about fields with `id`, `persist`, and `nested` attributes. For the `id` fields
     // we'll build a mapping function that creates a hashmap containing pointers to those
-    // parmaeters. For the `persist` function we'll create functions that serialize and deserialize
+    // parameters. For the `persist` function we'll create functions that serialize and deserialize
     // those fields individually (so they can be added and removed independently of eachother) using
     // JSON. The `nested` fields should also implement the `Params` trait and their fields will be
     // inherited and added to this field's lists.

nih_plug_iced/src/wrapper.rs

@@ -22,7 +22,7 @@ pub(crate) struct IcedEditorWrapperApplication<E: IcedEditor> {
     parameter_updates_receiver: Arc<channel::Receiver<crate::ParameterUpdate>>,
 }
 
-/// This wraps around `E::Message` to add a parmaeter update message which can be handled directly
+/// This wraps around `E::Message` to add a parameter update message which can be handled directly
 /// by this wrapper. That parameter update message simply forces a redraw of the GUI whenever there
 /// is a parameter update.
 pub enum Message<E: IcedEditor> {

nih_plug_vizia/src/widgets/generic_ui.rs

@@ -9,7 +9,7 @@ use super::{ParamSlider, ParamSliderExt, ParamSliderStyle};
 
 /// Shows a generic UI for a [`Params`] object. For additional flexibility you can either use the
 /// [`new()`][`Self::new()`] method to have the generic UI decide which widget to use for your
-/// parmaeters, or you can use the [`new_custom()`][`Self::new_custom()`] method to determine this
+/// parameters, or you can use the [`new_custom()`][`Self::new_custom()`] method to determine this
 /// yourself.
 pub struct GenericUi;
 

plugins/diopser/src/lib.rs

@@ -37,7 +37,7 @@ mod spectrum;
 /// How many all-pass filters we can have in series at most. The filter stages parameter determines
 /// how many filters are actually active.
 const MAX_NUM_FILTERS: usize = 512;
-/// The minimum step size for smoothing the filter parmaeters.
+/// The minimum step size for smoothing the filter parameters.
 const MIN_AUTOMATION_STEP_SIZE: u32 = 1;
 /// The maximum step size for smoothing the filter parameters. Updating these parameters can be
 /// expensive, so updating them in larger steps can be useful.

plugins/examples/gain/src/lib.rs

@@ -9,7 +9,7 @@ struct Gain {
 /// The [`Params`] derive macro gathers all of the information needed for the wrapepr to know about
 /// the plugin's parameters, persistent serializable fields, and nested parameter groups. You can
 /// aslo easily implement [`Params`] by hand if you want to, for instance, have multiple instances
-/// of a parmaeters struct for multiple identical oscillators/filters/envelopes.
+/// of a parameters struct for multiple identical oscillators/filters/envelopes.
 #[derive(Params)]
 struct GainParams {
     /// The parameter's ID is used to identify the parameter in the wrappred plugin API. As long as

plugins/examples/gain_gui_egui/src/lib.rs

@@ -99,7 +99,7 @@ impl Plugin for Gain {
                         "Also gain, but with a lame widget. Can't even render the value correctly!",
                     );
                     // This is a simple naieve version of a parameter slider that's not aware of how
-                    // the parmaeters work
+                    // the parameters work
                     ui.add(
                         egui::widgets::Slider::from_get_set(-30.0..=30.0, |new_value| {
                             match new_value {

src/param.rs

@@ -1,6 +1,6 @@
 //! NIH-plug can handle floating point, integer, boolean, and enum parameters. Parameters are
 //! managed by creating a struct deriving the [`Params`][internals::Params] trait containing fields
-//! for those parmaeter types, and then returning a reference to that object from your
+//! for those parameter types, and then returning a reference to that object from your
 //! [`Plugin::params()`][crate::prelude::Plugin::params()] method. See the `Params` trait for more
 //! information.
 

src/param/boolean.rs

@@ -6,7 +6,7 @@ use std::sync::Arc;
 use super::internals::ParamPtr;
 use super::{Param, ParamFlags};
 
-/// A simple boolean parmaeter.
+/// A simple boolean parameter.
 #[repr(C, align(4))]
 pub struct BoolParam {
     /// The field's current value. Should be initialized with the default value.
@@ -183,7 +183,7 @@ impl BoolParam {
     }
 
     /// Mark this parameter as a bypass parameter. Plugin hosts can integrate this parameter into
-    /// their UI. Only a single [`BoolParam`] can be a bypass parmaeter, and NIH-plug will add one
+    /// their UI. Only a single [`BoolParam`] can be a bypass parameter, and NIH-plug will add one
     /// if you don't create one yourself. You will need to implement this yourself if your plugin
     /// introduces latency.
     pub fn make_bypass(mut self) -> Self {

src/param/float.rs

@@ -38,7 +38,7 @@ pub struct FloatParam {
     /// called multiple times in rapid succession.
     ///
     /// To use this, you'll probably want to store an `Arc<Atomic*>` alongside the parmater in the
-    /// parmaeters struct, move a clone of that `Arc` into this closure, and then modify that.
+    /// parameters struct, move a clone of that `Arc` into this closure, and then modify that.
     ///
     /// TODO: We probably also want to pass the old value to this function.
     pub value_changed: Option<Arc<dyn Fn(f32) + Send + Sync>>,

src/param/integer.rs

@@ -38,7 +38,7 @@ pub struct IntParam {
     /// called multiple times in rapid succession.
     ///
     /// To use this, you'll probably want to store an `Arc<Atomic*>` alongside the parmater in the
-    /// parmaeters struct, move a clone of that `Arc` into this closure, and then modify that.
+    /// parameters struct, move a clone of that `Arc` into this closure, and then modify that.
     ///
     /// TODO: We probably also want to pass the old value to this function.
     pub value_changed: Option<Arc<dyn Fn(i32) + Send + Sync>>,

src/plugin.rs

@@ -12,7 +12,7 @@ use crate::param::internals::Params;
 /// Basic functionality that needs to be implemented by a plugin. The wrappers will use this to
 /// expose the plugin in a particular plugin format.
 ///
-/// The main thing you need to do is define a `[Params]` struct containing all of your parmaeters.
+/// The main thing you need to do is define a `[Params]` struct containing all of your parameters.
 /// See the trait's documentation for more information on how to do that, or check out the examples.
 ///
 /// This is super basic, and lots of things I didn't need or want to use yet haven't been

src/wrapper/clap/wrapper.rs

@@ -86,7 +86,7 @@ use crate::wrapper::state::{self, PluginState};
 use crate::wrapper::util::{hash_param_id, process_wrapper, strlcpy};
 
 /// How many output parameter changes we can store in our output parameter change queue. Storing
-/// more than this many parmaeters at a time will cause changes to get lost.
+/// more than this many parameters at a time will cause changes to get lost.
 const OUTPUT_EVENT_QUEUE_CAPACITY: usize = 2048;
 
 #[repr(C)]
@@ -208,7 +208,7 @@ pub struct Wrapper<P: ClapPlugin> {
     /// A queue of parameter changes and gestures that should be output in either the next process
     /// call or in the next parameter flush.
     ///
-    /// XXX: There's no guarentee that a single parmaeter doesn't occur twice in this queue, but
+    /// XXX: There's no guarentee that a single parameter doesn't occur twice in this queue, but
     ///      even if it does then that should still not be a problem because the host also reads it
     ///      in the same order, right?
     output_parameter_events: ArrayQueue<OutputParamEvent>,
@@ -260,7 +260,7 @@ pub enum ClapParamUpdate {
 pub enum OutputParamEvent {
     /// Begin an automation gesture. This must always be sent before sending [`SetValue`].
     BeginGesture { param_hash: u32 },
-    /// Change the value of a parmaeter using a plain CLAP value, aka the normalized value
+    /// Change the value of a parameter using a plain CLAP value, aka the normalized value
     /// multiplied by the number of steps.
     SetValue {
         /// The internal hash for the parameter.

src/wrapper/standalone/wrapper.rs

@@ -18,7 +18,7 @@ use crate::param::ParamFlags;
 use crate::plugin::{BufferConfig, BusConfig, Editor, ParentWindowHandle, Plugin, ProcessStatus};
 
 /// How many parameter changes we can store in our unprocessed parameter change queue. Storing more
-/// than this many parmaeters at a time will cause changes to get lost.
+/// than this many parameters at a time will cause changes to get lost.
 const EVENT_QUEUE_CAPACITY: usize = 2048;
 
 /// Configuration for a standalone plugin that would normally be provided by the DAW.

src/wrapper/state.rs

@@ -27,7 +27,7 @@ pub enum ParamValue {
 pub struct PluginState {
     /// The plugin's parameter values. These are stored unnormalized. This mean sthe old values will
     /// be recalled when when the parameter's range gets increased. Doing so may still mess with
-    /// parmaeter automation though, depending on how the host impelments that.
+    /// parameter automation though, depending on how the host impelments that.
     pub params: HashMap<String, ParamValue>,
     /// Arbitrary fields that should be persisted together with the plugin's parameters. Any field
     /// on the [`Params`][crate::param::internals::Params] struct that's annotated with `#[persist =
@@ -45,7 +45,7 @@ pub(crate) unsafe fn serialize_object(
     param_by_hash: &HashMap<u32, ParamPtr>,
     param_id_to_hash: &HashMap<String, u32>,
 ) -> PluginState {
-    // We'll serialize parmaeter values as a simple `string_param_id: display_value` map.
+    // We'll serialize parameter values as a simple `string_param_id: display_value` map.
     let params: HashMap<_, _> = param_id_to_hash
         .iter()
         .filter_map(|(param_id_str, hash)| {

src/wrapper/vst3/param_units.rs

@@ -1,7 +1,7 @@
 //! Parameter hierarchies in VST3 requires you to define units, which are linearly indexed logical
 //! units that have a name, a parent, and then a whole bunch of other data like note numbers and
 //! MIDI program state. We'll need to implement some of that to conver our list of slash-separated
-//! parmaeter group paths to units.
+//! parameter group paths to units.
 //!
 //! <https://steinbergmedia.github.io/vst3_doc/vstinterfaces/classSteinberg_1_1Vst_1_1IUnitInfo.html>
 

src/wrapper/vst3/wrapper.rs

@@ -923,7 +923,7 @@ impl<P: Vst3Plugin> IAudioProcessor for Wrapper<P> {
                                 normalized_value,
                             } => {
                                 // If this parameter change happens after the start of this block, then
-                                // we'll split the block here and handle this parmaeter change after
+                                // we'll split the block here and handle this parameter change after
                                 // we've processed this block
                                 if timing != block_start as u32 {
                                     event_start_idx = event_idx;