thesis/thesis.tex: Adding changes by reviewer. Thanks Nanni.

1 files changed, 138 insertions, 138 deletions

diff --git a/thesis/thesis.tex b/thesis/thesis.tex
index ca1f6e9..f396bd4 100644
--- a/thesis/thesis.tex
+++ b/thesis/thesis.tex
@@ -48,7 +48,7 @@ parskip=never]{paper}
 \newacronym{adat}{ADAT}{Alesis Digital Audio Tape}
 \newacronym{alsa}{ALSA}{Advanced Linux Sound Architecture}
 \newacronym{apf}{APF}{Audio Processing Framework}
-\newacronym{api}{API}{Application programming interface}
+\newacronym{api}{API}{Application Programming Interface}
 \newacronym{asdf}{ASDF}{Audio Scene Description Format}
 \newacronym{bs}{BS}{Binaural Synthesis}
 \newacronym{brir}{BRIR}{Binaural Room Impulse Response}
@@ -59,7 +59,7 @@ parskip=never]{paper}
 \newacronym{cpu}{CPU}{Central Processing Unit}
 \newacronym{fdl}{FDL}{GNU Free Documentation License}
 \newacronym{gpl}{GPL}{GNU General Public License}
-\newacronym{gui}{GUI}{Graphical user interface}
+\newacronym{gui}{GUI}{Graphical User Interface}
 \newacronym{hrir}{HRIR}{Head Related Impulse Response}
 \newacronym{hrtf}{HRTF}{Head Related Transfer Function}
 \newacronym{iana}{IANA}{Internet Assigned Numbers Authority}
@@ -71,14 +71,14 @@ parskip=never]{paper}
 \newacronym{jack}{JACK}{JACK Audio Connection Kit}
 \newacronym{madi}{MADI}{Multichannel Audio Digital Interface}
 \newacronym{midi}{MIDI}{Musical Instrument Digital Interface}
-\newacronym{nfc-hoa}{NFC-HOA}{Near-field-compensated Higher Order Ambisonics}
-\newacronym{oop}{OOP}{Object-oriented Programming}
+\newacronym{nfc-hoa}{NFC-HOA}{Near-Field-Compensated Higher Order Ambisonics}
+\newacronym{oop}{OOP}{Object-Oriented Programming}
 \newacronym{os}{OS}{Operating System}
 \newacronym{osc}{OSC}{Open Sound Control}
 \newacronym{posix}{POSIX}{Portable Operating System Interface}
-\newacronym{pubsub}{PubSub}{Publish-subscribe message pattern}
+\newacronym{pubsub}{PubSub}{Publish-Subscribe message pattern}
 \newacronym{pd}{Pd}{PureData}
-\newacronym{raii}{RAII}{Ressource acquisition is initialization}
+\newacronym{raii}{RAII}{Ressource Acquisition Is Initialization}
 \newacronym{ssr}{SSR}{SoundScape Renderer}
 \newacronym{tcp}{TCP}{Transmission Control Protocol}
 \newacronym{tu-berlin}{TU Berlin}{Technische Universität Berlin}
@@ -125,17 +125,17 @@ parskip=never]{paper}
 }
 \newglossaryentry{python}{
   name={Python},
-  description={An multi-purpose, object-oriented programming language}
+  description={A multi-purpose, object-oriented programming language}
 }
 \newglossaryentry{qt4}{
   name={Qt4},
   description={Version 4 (legacy) of the cross-platform application framework
-  for creating desktop applications.}
+  for creating desktop applications}
 }
 \newglossaryentry{qt5}{
   name={Qt5},
   description={Version 5 of the cross-platform application framework for
-  creating desktop applications.}
+  creating desktop applications}
 }
 
 \graphicspath{{../images//}}
@@ -205,8 +205,8 @@ parskip=never]{paper}
     ones, found in scientific research, involving Dynamic Binaural Synthesis.
     All of them are in need of extensively supported and reliable software,
     that can even be used, once the operating system is changing. This can
-    happen, if the hardware has to be upgraded, due to old age, or if new
-    software is required, that can not be build on older operating systems.\\
+    happen, if the hardware has to be upgraded due to old age or if new
+    software is required, that can not be built on older operating systems.\\
     In the following work, a set of current free and open-source realtime
     spatial audio renderers, actively used in scientific and artistic contexts,
     is evaluated for usability, applicability and realtime context: sWONDER,
@@ -286,7 +286,8 @@ parskip=never]{paper}
   \\
   Thanks to Matthias Geier for being relentless and yet supportive.\\
   \\
-  Special thanks to my family for their loving support over all of this time.\\
+  Special thanks to my family for their loving support over all of this time
+  spent.\\
   Thank you Nanni, for taking my mind off.\\
   \\
   Thanks to Sabine and Peter for reading through all of this nonsense.\\
@@ -364,12 +365,12 @@ parskip=never]{paper}
     one was chosen for extension.\\
     Some spatial audio renderers are single-purpose applications, conceived for
     a specific (and often quite rare) loudspeaker setup, such as those used for
-    \gls{wfs} or \gls{hoa}. An examle of this is the large scale system at
+    \gls{wfs} or \gls{hoa}. An example of this is the large scale system at
     \gls{tu-berlin} \citep{website:tu-wfs} or HAW Hamburg.
 
     The \gls{ssr} is a multi-purpose spatial audio renderer, developed at the
     \gls{tu-berlin}. To improve its usability and networking capabilities, a
-    new networking extension was developed, facilitating a \gls{osc} based
+    new networking extension was developed, facilitating an \gls{osc} based
     messaging system, that incorporates features for distributed processing in
     massive multi-loudspeaker setups.\\
 
@@ -379,10 +380,10 @@ parskip=never]{paper}
     \gls{jack} \citep{website:jackaudio2016} is a low-latency audio server,
     that allows for software using its environment to connect their in- and
     outputs with any other application using it. It is licensed under the
-    \gls{gpl} and can be built for various \glspl{os} (e.g. Linux, Mac OSX,
+    \gls{gpl} and can be built for various \glspl{os} (e.g. Linux, macOS,
     Windows). As of today, a plethora of applications exist, that extend
     \gls{jack}'s functionality graphically, or make use of it musically and
-    productively. Due to a large set of audio drivers it can use (i.e.
+    productively. Due to the large set of audio drivers it can use (i.e.
     \gls{alsa}, coreaudio, freebob, oss sun and portaudio) and its general
     availability, the audio server has become the de-facto standard for free
     and open-source, production ready applications on all major \glspl{os}.\\
@@ -454,11 +455,11 @@ parskip=never]{paper}
         sound source.\\
         The relatively small listening area can be extended by using additional
         sets of loudspeakers, which in turn lead to more spatial aliasing.\\
-        Due to the perceptebility of localization cues, mentioned
+        Due to the perceptibility of localization cues, mentioned
         in~\ref{subsubsec:binaural}, it is required to apply spatial
         equalization for the rendered sources, to account for differences in
         low- and high-frequency localization capabilities of the human ear.\\
-        For ambisonics, plane-wave sources are assumed, which means, their
+        For ambisonics, plane-wave sources are assumed, which means their
         distance is infinite. Due to the proximity effect, this leads to a bass
         boost in the listening area. \gls{nfc-hoa} accounts for this by a set
         of driving functions, applying a per speaker near-field compensation.\\
@@ -483,11 +484,11 @@ parskip=never]{paper}
         synthesized by the superposition of elementary spherical waves.\\
         Setups mainly focus on horizontal, preferably spatially discrete,
         speaker arrays of rectangular or circular shape as the human hearing is
-        most capable to localize acoustic sources in this this plane.\\
+        most capable of localizing acoustic sources in this plane.\\
         According to \citet{inproceedings:wierstorfetal2012}, localization is
         accurately and evenly distributed in the listening area with
         loudspeaker spacings of up to 40cm.\\
-        Although \gls{wfs} does not suffer from a pronounced sweet spot and
+        Although \gls{wfs} does not suffer from a pronounced sweet spot, and
         spatial aliasing is distributed over a relatively large listening area,
         compared to e.g.\ \gls{nfc-hoa}, the spatial sampling artifacts may
         still be perceived as coloration of the sound field, which can be
@@ -512,8 +513,8 @@ parskip=never]{paper}
       It uses \gls{osc} for messaging between its components and for setting
       its controls. Additionally, it can be controlled through a \gls{gui},
       that was specifically designed for it.\\
-      Sound sources can be moved dynamically, or according to a \gls{xml} based
-      score.\\
+      Sound sources can be moved dynamically, or according to an \gls{xml}
+      based score.\\
       For example sWONDER has been in use for the medium and large scale
       \gls{wfs} systems in the Electronic Music Studio
       \citep{website:tu-electronic_studio} and lecture hall H0103
@@ -580,13 +581,13 @@ parskip=never]{paper}
       \citep[p. 22]{manual:wfscollider}. By nature WFSCollider is \gls{osc}
       capable and extendable by what \gls{sclang} has to offer. Its scores are
       saved as \gls{supercollider} code, as well.\\
-      It is currently only tested on MacOSX and is based upon a several year
+      It is currently only tested on macOS and is based upon a several year
       old version of \href{https://supercollider.github.io}{SuperCollider}.
 
     \subsection{SoundScape Renderer}
       \label{subsec:soundscaperenderer}
       The \gls{ssr}, written in C++, is a multi-purpose spatial audio renderer,
-      that runs on Linux and MacOSX\@. Based on its underlying \gls{apf}
+      that runs on Linux and macOS\@. Based on its underlying \gls{apf}
       \citep{inproceedings:geieretal2012}, it is able to use \gls{bs},
       \gls{brs}, \gls{aap}, \gls{wfs}, \gls{nfc-hoa} and \gls{vbap}. However,
       all rendering algorithms with potentially orthogonal sound fields, are
@@ -613,7 +614,7 @@ parskip=never]{paper}
       back). The \gls{asdf} however is not (yet) able to represent dynamic
       setups.\\
       The application can be controlled through a \gls{tcp}/\gls{ip} socket.
-      \gls{osc} functionality can only be achieved using the capapilities of
+      \gls{osc} functionality can only be achieved using the capabilities of
       other applications such as \gls{pd} \citep{website:puredata2016} in
       combination with it.\\
       Unlike \nameref{subsec:swonder} or \nameref{subsec:wfscollider}, the
@@ -636,9 +637,9 @@ parskip=never]{paper}
       free documentation license, such as the \gls{fdl}, allowing access to
       anyone, free of charge.\\
       The software used in scientific institutions is unfortunately rarely free
-      (e.g.\ word processing, statistics, mathmatical calculations, realtime
+      (e.g.\ word processing, statistics, mathematical calculations, realtime
       audio synthesis and audio production) and additionally mostly bound to
-      proprietary \glspl{os}, such as Microsoft Windows or Apple's Mac OSX,
+      proprietary \glspl{os}, such as Microsoft Windows or Apple's macOS,
       preventing interoperability, development and an open society.\\
       However, free software enables students and researchers to learn from the
       source code directly (if they can and want to), to modify (and improve)
@@ -651,10 +652,10 @@ parskip=never]{paper}
       scientific context it can happen, that software is conceived by an
       institution, put to use, but later lacks the developers to drive the
       project onwards (e.g. \nameref{subsec:swonder}).
-      Therefore, a high responsibility weighs on these institutions, as they
+      Therefore, a high responsibility lies with these institutions, as they
       need to ensure further development on systems, not easily accessible to
       the public, or not feasible for home use (e.g. \gls{wfs}). This situation
-      however also holds a great opportunity for coorporation.\\
+      however also holds a great opportunity for cooperation.\\
       As the development of free and open-source software is driven by its
       users and its contributors, its main goal should be to build a large and
       dedicated community at some point. Only this way new features can be
@@ -662,14 +663,14 @@ parskip=never]{paper}
       code.\\
       Extending a software's functionality and improving its usability, such as
       that of the \gls{ssr}, can therefore be seen as an important step towards
-      a more diverse user base and by that ensuring its further development.
+      a more diverse user base and in effect ensuring its further development.
 
   \cleardoublepage
   \section{Implementation}
     \label{sec:implementation}
     This section covers the implementation of a networking interface for the
     \gls{ssr} and the considerations leading to it.
-    The application was chosen to be extended by a \gls{osc} based networking
+    The application was chosen to be extended by an \gls{osc} based networking
     interface, because it runs on multiple \glspl{os}, offers a wide set of
     rendering algorithms (in various stages of completion) by using the
     \gls{apf} \citep{inproceedings:geieretal2012}, is used extensively in
@@ -681,13 +682,13 @@ parskip=never]{paper}
     (see~\ref{subsec:3dj_supercollider_quark}) were not considered, as they
     were too reliant on their environment (i.e.\ \gls{pd} or
     \gls{supercollider}) and only implemented a small set of spatial audio
-    renderers, while sWONDER was additionally long unmaintained
-    (see~\ref{subsec:swonder}) and WFSCollider bound to a non-free operating
-    system (see~\ref{subsec:wfscollider}).
+    renderers, while sWONDER was additionally unmaintained for a long period of
+    time (see~\ref{subsec:swonder}) and WFSCollider bound to a non-free
+    operating system (see~\ref{subsec:wfscollider}).
 
     \subsection{Outline}
       \label{subsec:outline}
-      Initially, it was aimed to extend the \gls{ssr}'s features in the scope
+      Initially, the aim was to extend the \gls{ssr}'s features in the scope
       of creating a replacement for the aging sWONDER software, enabling it to
       run networked instances to drive a medium or large scale \gls{wfs} setup.
       However, the approach appeared too narrow, as the application offers many
@@ -742,7 +743,7 @@ parskip=never]{paper}
 
       \subsubsection{Remote Controlling a Server}
         \label{subsubsec:remote_controlling_a_server}
-        A \gls{ssr} server instance in the notion of a medium to large scale
+        An \gls{ssr} server instance in the notion of a medium to large scale
         reproduction setup is supposed to have a set of \textit{n}
         (pre-)assigned clients. Generally, controlling it should be possible
         through either \gls{udp} or \gls{tcp}.
@@ -757,7 +758,7 @@ parskip=never]{paper}
 
       \subsubsection{Remote Controlling Clients}
         \label{subsubsec:remote_controlling_a_client}
-        A \gls{ssr} client can either be local (on the same machine) or
+        An \gls{ssr} client can either be local (on the same machine) or
         somewhere on the same network, as the server or application controlling
         it. It should not make a difference, if the client instance is
         controlled by a server instance or any other application, implementing
@@ -783,7 +784,7 @@ parskip=never]{paper}
       to implement control through and over several parts of its components.\\
       In \gls{oop}, \gls{pubsub} --- also called observer, listener messaging
       --- is usually comprised of a publisher class, handling the messages,
-      without explicitely implementing how they will be used and a subscriber
+      without explicitly implementing how they will be used and a subscriber
       class, that allows for its implementations to subscribe to the messages
       provided. Filtering takes place to enable subscribers to only receive a
       certain subset of the messages.\\
@@ -849,10 +850,10 @@ parskip=never]{paper}
       the message has to be linted (error checked) before sending and parsed
       again, after receiving an answer from the application.\\
       The \gls{ip} interface achieves to offer more or less direct access to
-      the \nameref{subsec:publisher_subscriber_interface}. However, it has no
-      notion of a networked setup and could therefore be described as a
-      two-directional message system between two destinations. With it, only
-      setups with up to \textit{n} clients are possible.
+      the \gls{pubsub} (see~\ref{subsec:publisher_subscriber_interface}).
+      However, it has no notion of a networked setup and could therefore be
+      described as a two-directional message system between two destinations.
+      With it, only setups with up to \textit{n} clients are possible.
 
       \subsubsection{OSC through PureData}
         \label{subsubsec:osc_through_puredata}
@@ -937,8 +938,8 @@ parskip=never]{paper}
       \mintinline{c++}{OscReceiver} (handling incoming \gls{osc} messages and
       acting upon them in the context of the \gls{ssr} instance) and
       \mintinline{c++}{OscSender} (responsible for reacting to calls from the
-      \textbf{\nameref{subsec:publisher_subscriber_interface}} and sending of
-      \gls{osc} messages to clients and server).\\
+      \gls{pubsub}, as defined in~\ref{subsec:publisher_subscriber_interface}
+      and sending of \gls{osc} messages to clients and server).\\
       The class \mintinline{c++}{OscClient} implements the representation of a
       client (or server) to the message interface. It holds information about
       the client's address and port, along with its
@@ -954,10 +955,11 @@ parskip=never]{paper}
       direct access to the \mintinline{c++}{Controller} and can make calls to
       it, on receiving a message.\\
       In its implementation approach the \gls{osc} interface follows that of
-      the \textbf{\nameref{subsec:ip-interface}}. However, it expands in
-      creating a client-server architecture, controlled by
-      \textbf{\nameref{subsubsec:message_levels}}, using a unified
-      \textbf{\nameref{subsubsec:message_interface}}.\\
+      the \gls{ip} interface (see~\ref{subsec:ip-interface}). However, it
+      expands in creating a client-server architecture, controlled by message
+      levels (further elaborated in~\ref{subsubsec:message_levels}), using a
+      unified message interface (explained
+      in~\ref{subsubsec:message_interface}).\\
       \gls{ssr} client instances only evaluate messages of server instances
       they are subscribed to. Server instances only evaluate messages of client
       instances, that are subscribed to them.
@@ -979,7 +981,7 @@ parskip=never]{paper}
         \begin{itemize}
           \item Atomic data types, which are also reflected in type tags (see
             Table~\ref{tab:ssr-osc-data-type-acronyms} for details)
-          \item Address patterns (a \gls{osc}-string starting with a “/”)
+          \item Address patterns (an \gls{osc}-string starting with a “/”)
           \item Type tag string (a string, beginning with a “,”, holding a set
             of type tags, describing a collection of atomic data types)
           \item Arguments, a set of binary representations of each argument
@@ -1032,9 +1034,8 @@ parskip=never]{paper}
           \gls{osc} messages and bundles \citep{website:oscv1.0}.}\\
           The first four types define the standard \gls{osc} type tags, which
           should be understood by all implementations. The remaining are
-          non-standard types, that are implemented by most (e.g.
-          \nameref{subsubsec:liblo} implements all but array and RGBA color
-          type).
+          non-standard types, that are implemented by most (e.g.\ liblo
+          implements all but array and RGBA color type).
           \label{tab:ssr-osc-data-type-acronyms}
         \end{table}
 
@@ -1058,7 +1059,7 @@ parskip=never]{paper}
         wrappers for the Perl and \gls{python} programming languages.\\
         Due to its long standing availability and usage in many small and
         large-scale software projects, alongside its fairly straight forward
-        implementability, it was chosen as the candidate for establishing a
+        implementability, it was chosen as the candidate for establishing an
         \gls{osc} interface for the \gls{ssr}.\\
         At the time of writing liblo's lastet stable release (0.28) was issued
         on 27th January 2014. Many changes and improvements have been applied
@@ -1078,7 +1079,7 @@ parskip=never]{paper}
         Server instance on a separate background thread, to not interfere with
         the executional flow of the rest of the program.\\
         The \mintinline{c++}{ServerThread} class is able to free its ressources
-        upon going ot of scope (i.e.\ their ressources are not used by any
+        upon going out of scope (i.e.\ their ressources are not used by any
         object or function anymore), known as \gls{raii}. For this reason, the
         latest development version, instead of the current stable version of
         liblo, was chosen for the implementation.
@@ -1096,8 +1097,8 @@ parskip=never]{paper}
         the executables. The customized ones, belonging to the \gls{osc}
         interface will be discussed in the following subsections. More
         information on the interplay between \gls{osc} messaging and the
-        \nameref{subsec:publisher_subscriber_interface} can be found in
-        \textbf{\nameref{subsubsec:message_interface}}.
+        \gls{pubsub} (see~\ref{subsec:publisher_subscriber_interface}) can be
+        found in~\ref{subsubsec:message_interface}.
 
         \paragraph{Client Instance}
           \label{para:client-instance}
@@ -1122,7 +1123,7 @@ ssr-binaural -p “50002”
 
           Once started, the client instance waits to receive a poll message
           from a server instance (or an application, mimicking one), upon which
-          it will subscribe to it. Only then it is possible for the server
+          it will subscribe to it. Only then is it possible for the server
           application to control the client instance to the full extent via
           \gls{osc}.
 
@@ -1131,11 +1132,10 @@ ssr-binaural -p “50002”
           With the help of the \textbf{-N} flag, it is possible to start the
           \gls{ssr} as an \gls{osc} server. Additionally, the flag can be used
           in a future extension of the networking interface
-          (see~\ref{subsubsec:non-renderer}). In
-          Listing~\ref{lst:ssr-binaural-server-start} additionally, flag
-          \textbf{-C} is used to specify an initial client \gls{ip} and its
-          port (the flag actually accepts a comma-separated list of
-          \gls{ip}-port pairs).\\
+          (see~\ref{subsubsec:non-renderer}). Additionally, in
+          Listing~\ref{lst:ssr-binaural-server-start} flag \textbf{-C} is used
+          to specify an initial client \gls{ip} and its port (the flag actually
+            accepts a comma-separated list of \gls{ip}-port pairs).\\
           The \textbf{-p} flag, for setting a specific port is also available,
           when starting a server instance.
 
@@ -1151,7 +1151,7 @@ ssr-aap -N “server” -C “127.0.0.1:50002”
             \label{lst:ssr-binaural-server-start}
           \end{listing}
 
-          When the server instance starts, it instantly starts sending out poll
+          When the server instance starts, it instantly sends out periodic poll
           messages to all of its active clients. Clients provided by the
           \textbf{-C} flag are considered instantly active.\\
           Additionally, it is possible for clients (\gls{ssr} client instances,
@@ -1190,10 +1190,9 @@ ssr-aap -N “server” -C “127.0.0.1:50002”
         \gls{adat} or \gls{madi}). However, this is not mandatory, as the
         \gls{ssr} is capable of playing back audio files directly.\\
         The differences between server and client messaging is further
-        elaborated in \textbf{\nameref{subsubsec:message_interface}}.\\
+        elaborated in~\ref{subsubsec:message_interface}.\\
         A special networked setup, in which the server instance is not
-        rendering any audio, is discussed in
-        \textbf{\nameref{subsubsec:non-renderer}}.
+        rendering any audio, is discussed in~\ref{subsubsec:non-renderer}.
 
         \paragraph{Client-Server, Shared Rendering}
           \label{para:client_server_shared_rendering}
@@ -1211,10 +1210,10 @@ ssr-aap -N “server” -C “127.0.0.1:50002”
             \centering
             \includegraphics[scale=1.0, trim = 20mm 204mm 10mm 10mm, clip]
             {ssr-client-server-shared-output.pdf}
-            \caption[A diagram displaying a \gls{ssr} client/server setup, in
+            \caption[A diagram displaying an \gls{ssr} client/server setup, in
               which the server and the clients render audio collectively (e.g.
               \gls{wfs}). The server instance is not controlled via \gls{osc},
-              but controls its clients through it.]{A diagram displaying a
+              but controls its clients through it.]{A diagram displaying an
               \gls{ssr} client/server setup, in which the server and the
               clients render audio collectively (e.g.  \gls{wfs}). The server
               instance is not controlled via \gls{osc}, but controls its
@@ -1231,11 +1230,11 @@ ssr-aap -N “server” -C “127.0.0.1:50002”
             \centering
             \includegraphics[scale=1.0, trim = 20mm 204mm 10mm 10mm, clip]
             {ssr-external-client-server-shared-output.pdf}
-            \caption[A diagram displaying a \gls{ssr} client/server setup, in
+            \caption[A diagram displaying an \gls{ssr} client/server setup, in
               which the server and the clients render audio collectively (e.g.
               \gls{wfs}). The server instance is controlled by an \gls{osc}
               capable application (acting as another client) and controls its
-              clients through \gls{osc} as well.]{A diagram displaying a
+              clients through \gls{osc} as well.]{A diagram displaying an
               \gls{ssr} client/server setup, in which the server and the
               clients render audio collectively (e.g.  \gls{wfs}). The server
               instance is controlled by an \gls{osc} capable application
@@ -1273,11 +1272,11 @@ ssr-aap -N “server” -C “127.0.0.1:50002”
             \centering
             \includegraphics[scale=1.0, trim = 20mm 204mm 10mm 10mm, clip]
             {ssr-client-server-separate-output.pdf}
-            \caption[A diagram displaying a \gls{ssr} client/server setup, in
+            \caption[A diagram displaying an \gls{ssr} client/server setup, in
               which the server and the clients render audio to separate outputs
               (e.g.\ multiple \gls{bs} renderers). The server instance is not
               controlled via \gls{osc}, but controls its clients through it.]{A
-              diagram displaying a \gls{ssr} client/server setup, in which
+              diagram displaying an \gls{ssr} client/server setup, in which
               the server and the clients render audio to separate outputs
               (e.g.\ multiple \gls{bs} renderers). The server instance is not
               controlled via \gls{osc}, but controls its clients through it.\\
@@ -1297,12 +1296,12 @@ ssr-aap -N “server” -C “127.0.0.1:50002”
             \centering
             \includegraphics[scale=1.0, trim = 20mm 204mm 10mm 10mm, clip]
             {ssr-external-client-server-separate-output.pdf}
-            \caption[A diagram displaying a \gls{ssr} client/server setup, in
+            \caption[A diagram displaying an \gls{ssr} client/server setup, in
               which the server and the clients render audio separately (e.g.\
               multiple \gls{bs} renderers). The server instance is controlled
               by an \gls{osc} capable application (acting as another client)
               and controls its clients through \gls{osc} as well.]{A diagram
-              displaying a \gls{ssr} client/server setup, in which the server
+              displaying an \gls{ssr} client/server setup, in which the server
               and the clients render audio separately (e.g.\ multiple \gls{bs}
               renderers). The server instance is controlled by an \gls{osc}
               capable application (acting as another client) and controls its
@@ -1320,12 +1319,12 @@ ssr-aap -N “server” -C “127.0.0.1:50002”
           \label{para:clients_only}
           Using the new \gls{osc} interface, it is also possible to have
           client-only setups, in which an \gls{osc} capable application mimics
-          a \gls{ssr} server. This way a set of \textit{n} clients can
+          an \gls{ssr} server. This way a set of \textit{n} clients can
           collectively (see
           Figure~\ref{fig:ssr-external-clients-only-shared-output}) or
           separately (see
           Figure~\ref{fig:ssr-external-clients-only-separate-output}) render
-          audio, without the specific need of a \gls{ssr} server instance
+          audio, without the specific need of an \gls{ssr} server instance
           controlling them. The clients send their update information back to
           the controlling application.\\
           Much of the functionality implemented in the server-side of the
@@ -1336,14 +1335,14 @@ ssr-aap -N “server” -C “127.0.0.1:50002”
             \centering
             \includegraphics[scale=1.0, trim = 20mm 204mm 10mm 10mm, clip]
             {ssr-external-clients-only-shared-output.pdf}
-            \caption[A diagram displaying a \gls{ssr} client cluster setup, in
+            \caption[A diagram displaying an \gls{ssr} client cluster setup, in
               which a set of clients render audio collectively (e.g.\ medium or
               large-scale \gls{wfs} setup). An \gls{osc} capable application
-              acts as a \gls{ssr} server instance and controls the clients.]{A
-              diagram displaying a \gls{ssr} client cluster setup, in which a
+              acts as an \gls{ssr} server instance and controls the clients.]{A
+              diagram displaying an \gls{ssr} client cluster setup, in which a
               set of clients render audio collectively (e.g.\ medium or
               large-scale \gls{wfs} setup). An \gls{osc} capable application
-              acts as a \gls{ssr} server instance and controls the clients.\\
+              acts as an \gls{ssr} server instance and controls the clients.\\
               {\color{osc-in}\textbf{--}} \gls{osc} input
               {\color{osc-out}\textbf{--}} \gls{osc} output
               {\color{audio-in}\textbf{--}} Audio input
@@ -1356,13 +1355,13 @@ ssr-aap -N “server” -C “127.0.0.1:50002”
             \centering
             \includegraphics[scale=1.0, trim = 20mm 204mm 10mm 10mm, clip]
             {ssr-external-clients-only-separate-output.pdf}
-            \caption[A diagram displaying a \gls{ssr} client cluster setup, in
+            \caption[A diagram displaying an \gls{ssr} client cluster setup, in
               which a set of clients render audio separately (e.g.\ multiple
               \gls{bs} renderers). An \gls{osc} capable application acts as a
               \gls{ssr} server instance and controls the clients.]{A diagram
-              displaying a \gls{ssr} client cluster setup, in which a set of
+              displaying an \gls{ssr} client cluster setup, in which a set of
               clients render audio separately (e.g.\ multiple \gls{bs}
-              renderers). An \gls{osc} capable application acts as a \gls{ssr}
+              renderers). An \gls{osc} capable application acts as an \gls{ssr}
               server instance and controls the clients.\\
               {\color{osc-in}\textbf{--}} \gls{osc} input
               {\color{osc-out}\textbf{--}} \gls{osc} output
@@ -1412,7 +1411,7 @@ ssr-aap -N “server” -C “127.0.0.1:50002”
         issues), which is why they are only sent to clients with a
         \mintinline{c++}{MessageLevel} \mintinline{c++}{GUI_CLIENT} or servers
         with a \mintinline{c++}{MessageLevel} \mintinline{c++}{GUI_SERVER}.\\
-        Lightweight \gls{osc} capable applications used to control a \gls{ssr}
+        Lightweight \gls{osc} capable applications used to control an \gls{ssr}
         server instance are clients to said server instance. An elevated
         \mintinline{c++}{MessageLevel} of \mintinline{c++}{SERVER} (instead of
         \mintinline{c++}{CLIENT}) enables them to send messages to the server
@@ -1430,8 +1429,8 @@ ssr-aap -N “server” -C “127.0.0.1:50002”
         \gls{osc} offers the possibility of a hierarchical path tree that can
         be used to group messages by type (i.e.\ context). In conjunction with
         messages only understood by client or server (or a context dependant
-        meaning), most of the messages understood by the
-        \nameref{subsec:ip-interface} are implemented. Additional features,
+        meaning), most of the messages understood by the \gls{ip} interface
+        (see~\ref{subsec:ip-interface}) are implemented. Additional features,
         related to server-client and client-only functionality, were integrated
         as well.\\
         In general, it can be distinguished between \textit{direct} messages
@@ -1631,7 +1630,7 @@ ssr-aap -N “server” -C “127.0.0.1:50002”
           \label{tab:ssr-osc-scene}
         \end{table}
 
-        When starting a \gls{ssr} server instance
+        When starting an \gls{ssr} server instance
         (see~\ref{para:server-instance}), it responds to the messages shown in
         Table~\ref{tab:ssr-osc-subscribe}
         ,~\ref{tab:ssr-osc-scene}
@@ -1825,7 +1824,7 @@ ssr-aap -N “server” -C “127.0.0.1:50002”
               {../../ssr/supercollider/workflows.scd}
             \end{mdframed}
             \caption{supercollider/workflows.scd: \gls{sclang} as client
-            controlling a \gls{ssr} server instance}
+            controlling an \gls{ssr} server instance}
             \label{lst:ssr-workflow-sclang-controls-server}
           \end{listing}\\
 
@@ -1849,31 +1848,31 @@ ssr-aap -N “server” -C “127.0.0.1:50002”
               {../../ssr/supercollider/workflows.scd}
             \end{mdframed}
             \caption{supercollider/workflows.scd: \gls{sclang} mimics server,
-            controlling a \gls{ssr} client instance}
+            controlling an \gls{ssr} client instance}
             \label{lst:ssr-workflow-sclang-is-server-controls-client}
           \end{listing}\\
 
-          When mimicking a \gls{ssr} server instance in a client-only setup
+          When mimicking an \gls{ssr} server instance in a client-only setup
           (e.g.\ Figure~\ref{fig:ssr-external-clients-only-shared-output} or
           Figure~\ref{fig:ssr-external-clients-only-separate-output}), it is
           necessary to send a poll message to the client instance to make it
           subscribe (which sets the server's address and port up internally).\\
-          Afterwards --- similar to the example in the subsection
-          \nameref{para:clients_only} --- all \textit{direct} \gls{osc}
+          Afterwards --- similar to the example in the
+          subsection~\ref{para:clients_only} --- all \textit{direct} \gls{osc}
           messages are accepted by the client instance, when coming from the
           server address and port.\\
           An interesting concept here is to (temporarily) set a different
           \mintinline{c++}{MessageLevel} for the application acting as a server
           (e.g.\ to \mintinline{c++}{GUI_SERVER}), to receive \gls{gui}
-          relevant messages, as explained in
-          \nameref{subsubsec:message_interface}.\\
+          relevant messages, as explained
+          in~\ref{subsubsec:message_interface}.\\
 
   \cleardoublepage
   \section{Discussion}
     \label{sec:discussion}
     The \gls{osc} based networking extension created for the \gls{ssr} can be
-    considered as a valuable usability improvement. Its implemented features
-    are further discussed in the following section, followed by an outlook on
+    considered a valuable usability improvement. Its implemented features are
+    further discussed in the following section, followed by an outlook on
     related future work. The extension is additionally extensively documented
     in the source code, to ensure the ease of further development.\\
     Due to the versatility of how the \gls{ssr} can be used in a networking
@@ -1924,13 +1923,13 @@ ssr-aap -N “server” -C “127.0.0.1:50002”
       The \gls{osc} interface therefore implements messaging, while using lower
       bandwidth and offering a greater feature set.
       In~\ref{subsec:automated_tests} a test environment is introduced, that
-      further elaborates on the overall functionality and feasibility of the
+      further elaborates the overall functionality and feasibility of the
       message interface.
 
     \subsection{Automated Tests}
       \label{subsec:automated_tests}
       The \gls{ssr} was developed without the help of a test framework, which
-      is responsible to test its components, after they have been changed.
+      is responsible for testing its components, after they have been changed.
       This means, that internal (e.g.\ the \gls{pubsub} interface) or external
       (e.g.\ the \gls{ip} or \gls{osc} interface) functionality might or might
       not work as expected. To test the \gls{osc} interface's logical coherency
@@ -1963,7 +1962,7 @@ ssr-aap -N “server” -C “127.0.0.1:50002”
             {../../ssr/supercollider/tests.scd}
           \end{mdframed}
           \caption{supercollider/tests.scd: \gls{sclang} (unsubscribed) tries
-          to control a \gls{ssr} server}
+          to control an \gls{ssr} server}
           \label{lst:ssr-tests-sclang-unsubscribed-controls-server}
         \end{listing}\\
 
@@ -1974,7 +1973,7 @@ ssr-aap -N “server” -C “127.0.0.1:50002”
             {../../ssr/supercollider/tests.scd}
           \end{mdframed}
           \caption{supercollider/tests.scd: \gls{sclang} (subscribed) tries to
-          control a \gls{ssr} server}
+          control an \gls{ssr} server}
           \label{lst:ssr-tests-sclang-subscribed-controls-server}
         \end{listing}\\
 
@@ -1994,7 +1993,7 @@ ssr-aap -N “server” -C “127.0.0.1:50002”
             fontsize=\footnotesize]{supercollider}
             {../../ssr/supercollider/tests.scd}
           \end{mdframed}
-          \caption{supercollider/tests.scd: \gls{sclang} tries to control a
+          \caption{supercollider/tests.scd: \gls{sclang} tries to control an
           \gls{ssr} client (without polling it)}
           \label{lst:ssr-tests-sclang-controls-client-unpolled}
         \end{listing}\\
@@ -2005,22 +2004,22 @@ ssr-aap -N “server” -C “127.0.0.1:50002”
             fontsize=\footnotesize]{supercollider}
             {../../ssr/supercollider/tests.scd}
           \end{mdframed}
-          \caption{supercollider/tests.scd: \gls{sclang} tries to control a
+          \caption{supercollider/tests.scd: \gls{sclang} tries to control an
           \gls{ssr} client (with previously polling it)}
           \label{lst:ssr-tests-sclang-controls-client-polled}
         \end{listing}\\
 
         In all tests for robustness the attempt is made to force errors in the
-        implementation of the \nameref{subsubsec:message_interface}. This is
-        achieved by purposely using ranges of data types for messages, that are
-        not allowed or not defined in the \gls{ssr}'s internal
-        implementation.\\
+        implementation of the message interface (as defined
+        in~\ref{subsubsec:message_interface}). This is achieved by purposely
+        using ranges of data types for messages, that are not allowed or not
+        defined in the \gls{ssr}'s internal implementation.\\
         Two examples for weak spot exploitations were the use of negative
         integers for \glspl{id} in source related messages (only non-zero,
         non-negative \glspl{id} are allowed internally) or supplying an empty
         string as hostname or port number for subscription messages.\\
         The first example will lead to undefined behavior, if the range is not
-        checked in the implementation, as a \textit{static\_cast} is used
+        checked in the implementation, because a \textit{static\_cast} is used
         internally to cast the value of the message data type (\textit{unsigned
         int}) to the one expected by the \gls{ssr}'s Controller implementation
         (\textit{signed int}) and the outcome of said operation is
@@ -2044,7 +2043,7 @@ ssr-aap -N “server” -C “127.0.0.1:50002”
             fontsize=\footnotesize]{supercollider}
             {../../ssr/supercollider/tests.scd}
           \end{mdframed}
-          \caption{supercollider/tests.scd: \gls{sclang} controls a \gls{ssr}
+          \caption{supercollider/tests.scd: \gls{sclang} controls an \gls{ssr}
           client (with previously polling it), creating several sources and
           moving them}
           \label{lst:ssr-tests-sclang-sources}
@@ -2087,12 +2086,12 @@ ssr-aap -N “server” -C “127.0.0.1:50002”
       maintainer\footnote{\href{https://sourceforge.net/p/liblo/bugs/42/}
       {https://sourceforge.net/p/liblo/bugs/42/}}.
 
-      \subsubsection{Non-renderer}
+      \subsubsection{Non-Renderer}
         \label{subsubsec:non-renderer}
         The \gls{ssr} features a \gls{gui}, that was in the process of being
         upgraded for \gls{qt5} at the time of writing. Future versions of the
-        software could be used to also display setups of networking
-        instances, instead of only displaying the locally running.\\
+        software could be used to also display setups of networking instances,
+        instead of only displaying the ones, that are locally running.\\
         The implementation could be desirable for massive multi-channel setups
         and simply switching between several (local or network-attached)
         \gls{ssr} instances alike. An additional identifier for the \textbf{-N}
@@ -2103,11 +2102,11 @@ ssr-aap -N “server” -C “127.0.0.1:50002”
           \centering
           \includegraphics[scale=1.0, trim = 20mm 204mm 10mm 10mm, clip]
           {ssr-client-server-clients-only-shared-output.pdf}
-          \caption[A diagram displaying a \gls{ssr} client/server setup, in which
+          \caption[A diagram displaying an \gls{ssr} client/server setup, in which
             only the clients render audio collectively (e.g.\ medium or
             large-scale \gls{wfs}). The server instance is not controlled via
             \gls{osc}, but controls its clients through it. Additionally, its
-            rendering engine does not have any outputs.]{A diagram displaying a
+            rendering engine does not have any outputs.]{A diagram displaying an
             \gls{ssr} client/server setup, in which only the clients render
             audio collectively (e.g.\ medium or large-scale \gls{wfs}). The
             server instance is not controlled via \gls{osc}, but controls its
@@ -2144,11 +2143,11 @@ ssr-aap -N “server” -C “127.0.0.1:50002”
           \centering
           \includegraphics[scale=1.0, trim = 20mm 204mm 10mm 10mm, clip]
           {ssr-client-server-clients-only-separate-output.pdf}
-          \caption[A diagram displaying a \gls{ssr} client/server setup, in
+          \caption[A diagram displaying an \gls{ssr} client/server setup, in
             which only the clients render audio to separate outputs (e.g.\
             multiple \glspl{bs} renderers). The server instance is not controlled
             via \gls{osc}, but controls its clients through it. Additionally, its
-            rendering engine does not have any outputs.]{A diagram displaying a
+            rendering engine does not have any outputs.]{A diagram displaying an
             \gls{ssr} client/server setup, in which only the clients render
             audio to separate outputs (e.g.\ multiple \glspl{bs} renderers).
             The server instance is not controlled via \gls{osc}, but controls
@@ -2254,7 +2253,7 @@ ssr-aap -N “server” -C “127.0.0.1:50002”
         usage). Both examples should allow a \gls{gui} (or any other
         monitoring) process to be subscribed, after the active \gls{ssr}
         instances started rendering.\\
-        To be able to retrieve information from a \gls{ssr} instance, its
+        To be able to retrieve information from an \gls{ssr} instance, its
         \gls{pubsub} interface has to be extended and \mintinline{c++}{get}
         functions implemented --- where applicable --- to return the desired
         information. A special case of this feature is described
@@ -2263,18 +2262,18 @@ ssr-aap -N “server” -C “127.0.0.1:50002”
       \subsubsection{Scene Transfer}
         \label{subsubsec:scene_transfer}
         The \gls{ip} interface of the \gls{ssr} implements a functionality to
-        transfer all information related to a scene as a \gls{xml} formatted
+        transfer all information related to a scene as an \gls{xml} formatted
         string. This is useful, if the scene information should be stored on
         the machine requesting the information, instead of on the rendering
         machine.\\
         Due to shortage of time to implement it and the original functionality
         heavily relying on the \gls{xml} associated code, the \gls{osc}
-        interface still lacks this feature, which in its context could
-        additionally also be used to transfer all scene information to another
-        client, subscribed to a server.\\
-        It could be particularly useful, if clients could for example request
-        the scene currently held be their server instance, in the case where
-        they are started after the server has been started, but its scene
+        interface still lacks this feature, which in its context could also be
+        used to transfer all scene information to another client, subscribed to
+        a server.\\
+        It would prove particularly useful, if clients could for example
+        request the scene currently held by their server instance, in the case
+        where they are started after the server has been started, but its scene
         already being setup. The server would then send a set of instructions
         as \gls{osc} messages, needed for setting up the scene in question.\\
         For this feature to work reliably, some edge cases have to be
@@ -2287,7 +2286,7 @@ ssr-aap -N “server” -C “127.0.0.1:50002”
         the \gls{osc} messages have to be designed in such a way, that they can
         account for them, as every source message (apart from
         \textit{/source/new}) requires a valid source \gls{id} and subsequent
-        calls to the server would otherwise trigger uncorrectly mapped
+        calls to the server would otherwise trigger incorrectly mapped
         operations on its clients sources.\\
         Additionally, it would be useful to be able to transfer a scene to
         another client, by request, if the caller's
@@ -2319,7 +2318,7 @@ ssr-aap -N “server” -C “127.0.0.1:50002”
         The approach however is somewhat static, as it only allows setting up
         one predefined client during startup. This can be the system's hardware
         in- and outputs or other \gls{jack} clients. The selected input name is
-        added to the prefix to connect a \gls{ssr} source to a \gls{jack}
+        added to the prefix to connect an \gls{ssr} source to a \gls{jack}
         client output with that name. Following the configuration file example,
         given a source input name of \mintinline{yaml}{1}, the \gls{ssr} would
         connect to the \gls{jack} client port named
@@ -2373,13 +2372,14 @@ ssr-aap -N “server” -C “127.0.0.1:50002”
       \subsubsection{Dynamic Scene}
         \label{subsubsec:dynamic_scene}
         When using the \gls{ssr} in a more artistic context, such as musical
-        scores, or in experiment environments dealing with moving sources, this
-        requires a dynamic scene.\ sWONDER (see~\ref{subsec:swonder}) has a
-        scoreplayer application, that can be synced with \gls{midi}, which is
-        used to record and play back scores (i.e.\ recorded source properties)
-        from unvalidated \gls{xml} files.  WFSCollider has a fully integrated
-        timeline, that can be used to place multiple (even concurrent) events,
-        save and play them \citep[p. 10]{manual:wfscollider}.\\
+        scores, or in scientific experimental environments dealing with moving
+        sources, this requires a dynamic scene.\ sWONDER
+        (see~\ref{subsec:swonder}) has a scoreplayer application, that can be
+        synced with \gls{midi}, which is used to record and play back scores
+        (i.e.\ recorded source properties) from unvalidated \gls{xml} files.
+        WFSCollider has a fully integrated timeline, that can be used to place
+        multiple (even concurrent) events, save and play them \citep[p.
+        10]{manual:wfscollider}.\\
 
         \begin{listing}[!htb]
           \begin{mdframed}
@@ -2407,7 +2407,7 @@ ssr-aap -N “server” -C “127.0.0.1:50002”
         in~\ref{subsubsec:interpolation_of_moving_sources} and thus enable the
         \gls{ssr} to deal with dynamic scenes efficiently.\\
         Additionally, the \gls{gui} efforts made for WFSCollider could be
-        combined with a \gls{ssr} backend, as it lacks a tool for creation and
+        combined with an \gls{ssr} backend, as it lacks a tool for creation and
         controlling of dynamic content.
 
       \subsubsection{Network Enabled Head Tracking}
@@ -2418,7 +2418,7 @@ ssr-aap -N “server” -C “127.0.0.1:50002”
         the conceived devices, such as the \gls{gpl} licensed \textit{Hedrot}
         \citep{website:hedrot}, allow for \gls{osc} communication.\\
         Using the \gls{osc} interface, such a head tracker can be added as a
-        client to a \gls{ssr} instance. This would probably require
+        client to an \gls{ssr} instance. This will probably require
         rate-limiting the sensor output, but would enable a networked setup,
         that could prove to be cheaper, more reliable and flexible, than the
         compile-time opt-ins (i.e.\ VRPN, Polhemus Fastrak/ Patriot, InterSense
@@ -2434,7 +2434,7 @@ ssr-aap -N “server” -C “127.0.0.1:50002”
         can be assigned to them flexibly.
 
   \cleardoublepage
-  \bibliographystyle{plainnat}
+  \bibliographystyle{../help/FG_AK_English_AuthorYear.bst}
   \bibliography{../bib/ssr-networking}
   \cleardoublepage
   \newpage
@@ -2497,10 +2497,10 @@ git log
         \item sclang-workflows\footnote{\href{https://github.com/SoundScapeRenderer/ssr/compare/master...dvzrv:sclang-workflows}{https://github.com/SoundScapeRenderer/ssr/compare/master...dvzrv:sclang-workflows}}
         \item alien-loudspeaker\footnote{\href{https://github.com/SoundScapeRenderer/ssr/compare/master...dvzrv:alien-loudspeaker}{https://github.com/SoundScapeRenderer/ssr/compare/master...dvzrv:alien-loudspeaker}}
       \end{itemize}\\
-      The source code developed in the branches mentioned above is merged into
+      The source code developed in the aforementioned branches was merged into
       a new, local branch called \textit{testing} for the
-      \nameref{digital_ressource}. All of them are available in this local
-      source repository.\\
+      \nameref{digital_ressource}. However, all of them are available
+      separately in this local source code repository.\\
       Therefore, git can also be used locally to checkout a specific branch of
       the source code, as shown in Listing~\ref{lst:git-branch-checkout}.\\
       \begin{listing}[!htb]