Fix spelling, grammar, and punctuation

README.rst

@@ -4,9 +4,9 @@ Open Neuro Interface
 
 This documentation's source template was taken from the `Spinal HDL <https://github.com/SpinalHDL/SpinalDoc-RTD>`_ project.
 
-The theme is based on the `PyData Sphinx Theme <https://pydata-sphinx-theme.readthedocs.io/en/latest/>`_
+The theme is based on the `PyData Sphinx Theme <https://pydata-sphinx-theme.readthedocs.io/en/latest/>`_.
 
-For more detailed usage instructions, see the `Open Ephys Doc Template <https://github.com/open-ephys/doc-template>`_
+For more detailed usage instructions, see the `Open Ephys Doc Template <https://github.com/open-ephys/doc-template>`_.
 
 How to build this documentation
 ===============================
@@ -18,26 +18,26 @@ Requirements (Python 3):
 
 * pipenv (will automatically download all the project requirements from pypi)
 
-Create a virtual environment with pipenv (will use the Pipfile for installing the necessary packages)
+Create a virtual environment with pipenv (will use the Pipfile for installing the necessary packages).
 
 .. code:: shell
 
    pipenv install
 
-then you can build the documentation
+Then you can build the documentation.
 
 .. code:: shell
 
    pipenv run make html
 
-if you want to run ``make`` multiple times, prepending ``pipenv run`` on each command can be annoying.
-You can spawn a subshell with
+If you want to run ``make`` multiple times, prepending ``pipenv run`` on each command can be annoying.
+You can spawn a subshell with:
 
 .. code:: shell
 
    pipenv shell
 
-and then you can use ``make`` the usual way
+and then you can use ``make`` the usual way.
 
 .. code:: shell
 
@@ -46,7 +46,7 @@ and then you can use ``make`` the usual way
    make latexpdf # for latex (will require latexpdf installed)
    make          # list all the available output format
 
-All the outputs will be in the docs folder (for html: docs/html)
+All the outputs will be in the docs folder (for html: docs/html).
 
 without pipenv/virtualenv
 -------------------------
@@ -59,7 +59,7 @@ Requirements (Python 3):
 * sphinx
 * pydata-sphinx-theme=="0.13.3"
 
-After installing the requirements you can run
+After installing the requirements you can run:
 
 .. code:: shell
 

source/_static/theme_overrides.css

@@ -81,7 +81,7 @@
 /* navigation bar: when page title is selected*/
 .navbar-nav > .active > .nav-link {
   background-color: #e6eddf !important; /* selected text background fill */
-  color: #2f401f !important; /* selected text colour*/
+  color: #2f401f !important; /* selected text color*/
   font-weight: normal !important;
   transition-duration: 0.4s; /* how quickly to change*/
 }

source/api/bindings/clroni/index.rst

@@ -24,7 +24,7 @@ Windows
 =======================================
 1. Open the :code:`clroni.sln` solution in Visual Studio 2019 or newer.
 2. "Running" the solution will compile the library and test program, and then
-   run the test program
+   run the test program.
 3. The Nuget package can be built by right clicking the clroni project and
    clicking "pack".
 
@@ -44,7 +44,7 @@ The :code:`clroni-repl` directory contains minimal working programs that use thi
 library
 
 1. :code:`clroni-repl.exe` : Basic data acquisition loop. Communicate with
-   emmulated (e.g. :ref:`test_driver`) or actual (e.g. :ref:`riffa`)
+   emulated (e.g., :ref:`test_driver`) or actual (e.g., :ref:`riffa`)
    hardware.
 
 This will be automatically built when the Visual Studio solution is built. It

source/api/bindings/cpponi/oni.rst

@@ -11,15 +11,15 @@ See https://semver.org/ for a complete explanation of these macro definitions.
 
 .. c:macro:: CPPONI_VERSION_MAJOR
 
-    MAJOR version for incompatible API changes
+    MAJOR version for incompatible API changes.
 
 .. c:macro:: CPPONI_VERSION_MINOR
 
-    MINOR version for added functionality that is backwards compatible
+    MINOR version for added functionality that is backwards compatible.
 
 .. c:macro:: CPPONI_VERSION_PATCH
 
-    PATCH version for backwards compatible bug fixes
+    PATCH version for backwards compatible bug fixes.
 
 .. c:macro:: CPPONI_MAKE_VERSION(major, minor, patch)
 
@@ -37,7 +37,7 @@ See https://semver.org/ for a complete explanation of these macro definitions.
 
     .. code-block:: c
 
-        CPPONI_MAKE_VERSION(CPPONI_VERSION_MAJOR CPPONI_VERSION_MINOR, CPPONI_VERSION_PATCH).
+        CPPONI_MAKE_VERSION(CPPONI_VERSION_MAJOR CPPONI_VERSION_MINOR, CPPONI_VERSION_PATCH)
 
 .. function:: std::tuple<int, int, int> oni::version()
 
@@ -59,10 +59,10 @@ Errors
 
         Constructor. Not generally needed for cpponi use since
         :class:`oni::error_t` is constructed and thrown from within cpponi and
-        only need to be handled by the host application.
+        only needs to be handled by the host application.
 
         :param errnum: liboni error code integer, generally resulting from a non-zero
-            return value of an Underlying liboni function.
+            return value of an underlying liboni function.
 
     .. function:: const char *what() const noexcept override
 
@@ -94,15 +94,15 @@ Frames
     `RAII <https://en.cppreference.com/w/cpp/language/raii>`__-capable wrapper
     for :c:struct:`oni_frame_t`. User programs generally should not call the
     frame_t constructor directly but deal with frames created by a
-    :class:`oni::context_t`
+    :class:`oni::context_t`.
 
     .. function:: uint64_t time() const
 
-        :return: Underlying :c:struct:`oni_frame_t.time`
+        :return: Underlying :c:struct:`oni_frame_t.time`.
 
     .. function:: oni_dev_idx_t device_index() const
 
-        :return: Underlying :c:struct:`oni_frame_t.dev_idx`
+        :return: Underlying :c:struct:`oni_frame_t.dev_idx`.
 
     .. function:: template <typename raw_t>\
                   std::span<const raw_t> data() const   
@@ -115,7 +115,7 @@ Frames
             <https://en.cppreference.com/w/cpp/container/span>`__ Automatically
             made available when compiled with stdlib >= C++20. Otherwise, this
             function reverts to returning a `std::vector
-            <https://en.cppreference.com/w/cpp/container/vector>`__
+            <https://en.cppreference.com/w/cpp/container/vector>`__.
 
 Context
 --------------------------------------
@@ -140,7 +140,7 @@ Context
         :param host_idx: The index of the hardware we are going to
             manage using the initialized context and driver. A value of -1 will
             attempt to open the default host index and is useful if there is only a
-            single ONIX host managed by driver selected in :func:`oni_create_ctx`
+            single ONIX host managed by driver selected in :func:`oni_create_ctx`.
         :throws: `std::system_error
             <https://en.cppreference.com/w/cpp/error/system_error>`_ if underlying
             context cannot be allocated.
@@ -160,7 +160,7 @@ Context
 
     .. function:: context_t &operator=(context_t &&rhs) noexcept
 
-        Move assignment operator. 
+        Move assignment operator.
 
         :param rhs: Existing :class:`context_t` instance to move from. 
 
@@ -274,15 +274,15 @@ Context
         .. note:: ``data.size()`` must be
 
             #. An integer multiple of the selected ``dev_idx``'s write size as
-               indicated within the device table
+               indicated within the device table.
             #. Smaller than the internal write block memory size (see 
-               :c:macro:`ONI_OPT_BLOCKWRITESIZE` and :ref:`liboni_example_set_buffers`)
+               :c:macro:`ONI_OPT_BLOCKWRITESIZE` and :ref:`liboni_example_set_buffers`).
 
         .. note:: `std::span
             <https://en.cppreference.com/w/cpp/container/span>`__ is
             automatically made available when compiled with stdlib >= C++20.
             Otherwise, this function reverts to returning a `std::vector
-            <https://en.cppreference.com/w/cpp/container/vector>`__
+            <https://en.cppreference.com/w/cpp/container/vector>`__.
 
         .. seealso::
             :c:func:`oni_create_frame`

source/api/index.rst

@@ -31,5 +31,5 @@ Bindings
 :ref:`C++ Binding Reference <cpponi>`
     C++17 & C++20 bindings for :ref:`liboni`.
 
-:ref:`.NET Binding Refernece <clroni>`
+:ref:`.NET Binding Reference <clroni>`
     CLR/.NET bindings for :ref:`liboni`.

source/api/liboni/build.rst

@@ -103,7 +103,7 @@ full leak check on ``host``:
 
 Build in Windows
 ********************************************
-Open the included `Visual Studio Coummunity
+Open the included `Visual Studio Community
 <https://visualstudio.microsoft.com/vs/community/>`_ solution and press play.
 For whatever reason, it seems that the selected startup project is not
 consistently saved with the solution. So make sure that it is set to

source/api/liboni/driver-translators/index.rst

@@ -5,15 +5,15 @@ Driver Translators
 
 :Code: https://github.com/open-ephys/liboni/tree/main/api/liboni/drivers
 
-There are a many existing `device drivers
+There are many existing `device drivers
 <https://en.wikipedia.org/wiki/Device_driver>`_ that support hardware for data
 acquisition. Some of these drivers can be used as a backend for ONI-compliant
 APIs if they provide some means to support the required ONI communication
 channels. Have a look at the :ref:`ONI controller spec <controller>`
 for specifications of these channels.
 
-An ONI hardware driver translator implements :ref:`onidriver.h` to convert,
-potentially proprietary, device drivers (and corresponding hardware) into a
+An ONI hardware driver translator implements :ref:`onidriver.h` to convert
+potentially proprietary device drivers (and corresponding hardware) into a
 user space library that can be consumed by ONI-compliant APIs. These are loaded
 by the API at runtime and therefore are separate from the API both in terms of
 development and licensing requirements.

source/api/liboni/index.rst

@@ -25,8 +25,8 @@ liboni
 implements the :ref:`oni-hw`. It is written in C to facilitate cross platform
 and cross-language use. It is composed of the following files:
 
-#. :ref:`onidefs.h`: common definitions
-#. :ref:`oni.h`: core API
+#. :ref:`onidefs.h`: common definitions.
+#. :ref:`oni.h`: core API.
 #. :ref:`onidriver.h`: device driver translation layer that must be
    implemented for a particular host hardware connection and
    firmware.

source/api/liboni/liboni-example.rst

@@ -42,11 +42,11 @@ manage the hardware at the specified host index using the specified driver.
 
 .. note:: Specifying a host index of -1 will open the default slot and is
     useful in cases where there is only one piece of acquisition hardware in the
-    host computer (e.g. a single PCIe card).
+    host computer (e.g., a single PCIe card).
 
-When multiple pieces of host hardware exist on a single host (e.g. multiple
+When multiple pieces of host hardware exist on a single host (e.g., multiple
 PCIe cards), a new context must be created and initialized to manage each
-one. In some cases (e.g. multiple PCIe cards in a single computer), these
+one. In some cases (e.g., multiple PCIe cards in a single computer), these
 contexts can be synchronized so that each host receiver board shares a common
 hardware clock and acquisition trigger (see :ref:`sync_ctx` for an example).
 This is not always possible. For instance, multiple USB hosts cannot be
@@ -55,7 +55,7 @@ synchronized.
 .. attention:: :func:`oni_init_ctx` cannot be called on a previously
     initialized context.  Doing so will return an error.
 
-If the device configuration is changed following context initialization (e.g. a
+If the device configuration is changed following context initialization (e.g., a
 headstage is plugged in or turned on), a context reset must be issued to
 instruct the initialized context to re-evaluate its device table. This can be
 done via
@@ -114,7 +114,7 @@ defined as:
 .. attention:: ``device_t.idx`` is the fully qualified address (hub.index) of a
     device within the acquisition hierarchy. Do not expect these values to increase
     linearly with the position in array returned when querying the device table as
-    some bit ranges are used to specifiy the hub address.
+    some bit ranges are used to specify the hub address.
 
 .. _liboni_example_read_write_reg:
 
@@ -124,9 +124,9 @@ It is often necessary to inspect and configure devices prior to or during
 acquisition. As described in the ONI specification, a device is a leaf element
 in the device table with *at least* the following properties:
 
-#. Its own register address space
-#. Register access through a standardized register programming interface
-#. A datasheet that describes access to these registers
+#. Its own register address space.
+#. Register access through a standardized register programming interface.
+#. A datasheet that describes access to these registers.
 
 Device registers can be read as follows:
 
@@ -139,7 +139,7 @@ Here, ``dev_idx`` is the fully specified device table index (hub.index) found
 in the device table, ``addr`` is the register address as specified within the
 ONI device datasheet. Because this is a register read, ``val`` is just a
 pointer to a register to be filled during the read. This function will return
-an error if the context is in an inappropriate state (e.g. not initialized),
+an error if the context is in an inappropriate state (e.g., not initialized),
 the specified device is not in the device table, or the register is write-only.
 Registers can be written as follows:
 
@@ -223,7 +223,7 @@ context option:
     reg = 1;
     oni_set_opt(ctx, ONI_OPT_RUNNING, &reg, sizeof(oni_size_t));
 
-.. attention:: Following the start of data acqusition, hardware memory
+.. attention:: Following the start of data acquisition, hardware memory
     resources are used to queue incoming device data. To prevent buffer overflows,
     the user must issue calls to ``oni_read_frame`` fast enough to keep up with
     data production.
@@ -287,7 +287,7 @@ calls to ``oni_read_frame`` as follows:
 In the preceding example, ``frame`` is initialized to ``NULL`` because a call
 to ``oni_read_frame`` will assign its contents to an existing, pre-allocated
 memory block (see :ref:`liboni_example_set_buffers`). ``oni_read_frame`` will
-return an error if the acquisition context is in an inappropriate state (e.g.
+return an error if the acquisition context is in an inappropriate state (e.g.,
 not started). If the hardware is not producing frames, it will wait
 indefinitely.
 
@@ -339,13 +339,13 @@ size, then ``oni_create_frame`` will return an error.
 .. warning:: Attempting to write multi-packet frames that are larger than
     :macro:`ONI_OPT_BLOCKWRITESIZE` will result in a error.
 
-After a frame has been created, it can then be written to to hardware using
+After a frame has been created, it can then be written to hardware using
 ``oni_write_frame``. Just like frames produced by ``oni_read_frame``, frames
 generated by ``oni_create_frame`` must be disposed of using
 ``oni_destroy_frame`` when the are no longer needed.
 
 .. tip:: Frames created using ``oni_create_frame`` can be reused by re-writing
-    their data field following a frame write
+    their data field following a frame write.
 
 The following example shows a single frame being used for two writes with a
 change in the data field in between writes:

source/api/liboni/making-drivers.rst

@@ -33,7 +33,7 @@ opaque pointer of type :c:type:`oni_driver_ctx` and stored in a field of
     in :c:func:`oni_driver_create_ctx` and accessed through the :c:type:`oni_driver_ctx`
     parameter present in most function calls. No static variables can be used to
     keep any state information. This is necessary for multiple instances of the driver
-    to exist simultaneously, acessing different devices of the same type.
+    to exist simultaneously, accessing different devices of the same type.
 
 An example of such a context for a simple, file-descriptor accessed device,
 could be
@@ -106,7 +106,7 @@ operation.
 all allocated resources.
 
 .. code-block:: c
-    :caption: Context managment examples
+    :caption: Context management examples.
 
     oni_driver_ctx oni_driver_create_ctx()
     {
@@ -164,7 +164,7 @@ interface used.
         else return ONI_EPATHINVALID;
     }
 
-.. note:: Read operations must return the same number of bytes as requested, or it will be treated as an error
+.. note:: Read operations must return the same number of bytes as requested, or it will be treated as an error.
 
 .. _making_drivers_functions_register:
 
@@ -180,7 +180,7 @@ Again, the specifics on how to access such registers are dependent on the hardwa
     trigger, when performing a reset or starting/stopping acquisition.
 
 .. code-block:: c
-    :caption: Examples of register access
+    :caption: Examples of register access.
 
     int oni_driver_read_config(oni_driver_ctx driver_ctx, oni_config_t config, oni_reg_val_t *value)
     {
@@ -232,7 +232,7 @@ function can simply return :c:macro:`ONI_ESUCCESS`.
     would act before, during low-level register access.
 
 .. code-block:: c
-    :caption: Example post-option callback
+    :caption: Example post-option callback.
 
     int oni_driver_set_opt_callback(oni_driver_ctx driver_ctx, int oni_option, const void *value, size_t option_len)
     {
@@ -267,10 +267,10 @@ A driver translator must be able to report its name and version information.
 This is done using the :ref:`oni_driver_info_t` structure, which contains
 information following the `Semantic Versioning <https://semver.org/>`_
 specification. This structure should be a constant, and a pointer to it should
-be returned by :c:func:`oni_get_driver_info`
+be returned by :c:func:`oni_get_driver_info`.
 
 .. code-block:: c
-    :caption: Example implemention
+    :caption: Example implementation
 
     const oni_driver_info_t oni_driver_info = {
         .name = "simple",