thesis/thesis.tex: Fixing a lot of things from Henriks review. Glossary entries in captions still have to be fixed.

1 files changed, 170 insertions, 120 deletions

diff --git a/thesis/thesis.tex b/thesis/thesis.tex
index 6516265..d42095f 100644
--- a/thesis/thesis.tex
+++ b/thesis/thesis.tex
@@ -15,7 +15,7 @@ parskip=never]{paper}
 \definecolor{table-background-one}{RGB}{194,195,194}
 \definecolor{table-background-two}{RGB}{210,213,210}
 
-\usepackage[cache=false,newfloat=true]{minted}
+\usepackage[newfloat=true]{minted}
 \usepackage{mdframed}
 
 \usepackage{fancyhdr}
@@ -362,7 +362,7 @@ parskip=never]{paper}
     \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 MacOSX\@. Based on its underlying \gls{apf}
       \citep{MatthiasGeierTorbenHohn1890}, it is able to use \gls{bs},
       \gls{brs}, \gls{aap}, \gls{wfs}, \gls{hoa} and \gls{vbap}.\\
       It can be used with a \gls{qt4} based \gls{gui} or headless (without
@@ -431,10 +431,13 @@ parskip=never]{paper}
     \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 for extension, as it offers a wide set of
+    The application was chosen to be extended by a \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{MatthiasGeierTorbenHohn1890} and because it was still
-    actively maintained by its creators at the time of writing.\\
+    \gls{apf} \citep{MatthiasGeierTorbenHohn1890}, is used extensively in
+    scientific research, has the future possibility to run medium and large
+    scale \gls{wfs} setups and was still actively maintained by its creators at
+    the time of writing.\\
 
     \subsection{Outline}
       \label{subsec:outline}
@@ -448,7 +451,7 @@ parskip=never]{paper}
       with the help of only one of its engines proved to be linked to a
       massive, but avoidable overhead (see~\ref{subsubsec:preliminaries}).\\
       The \gls{ssr}, being a multi-purpose spatial audio renderer, can be used
-      in diverse setup scenarios (see~\ref{subsubsec:setups}), which is why not
+      in diverse setup scenarios (see~\ref{subsubsec:setups}). Therefore not
       only classic server-client relationships
       (see~\ref{subsubsec:remote_controlling_a_server}), but also client-only
       and local (see~\ref{subsubsec:remote_controlling_a_client}) setups had to
@@ -554,28 +557,35 @@ parskip=never]{paper}
         \label{fig:ssr-publisher-with-legacy-subscribers}
       \end{figure}
 
-      The abstract class Publisher defines the messages possible to send and
-      provides means to subscribe to them. The global Controller class is its
-      only implementation within the \gls{ssr}.\\
-      The abstract class Subscriber in turn defines the messages understood,
-      while its implementations in RenderSubscriber, Scene, OscSender and
-      NetworkSubscriber take care of how they are used.\\
+      The abstract class \mintinline{c++}{Publisher} defines the messages
+      possible to send and provides means to subscribe to them. The global
+      \mintinline{c++}{Controller} class is its only implementation within the
+      \gls{ssr}.\\
+      The abstract class \mintinline{c++}{Subscriber} in turn defines the
+      messages understood, while its implementations in
+      \mintinline{c++}{RenderSubscriber}, \mintinline{c++}{Scene},
+      \mintinline{c++}{OscSender} and \mintinline{c++}{NetworkSubscriber} take
+      care of how they are used.\\
       This system enables a versatile messaging layout, in which components can
-      call the publisher functionality in Controller, which in turn will send
-      out messages to all of its subscribers.\\
-      Depending on the design of an application, \gls{pubsub} is not necesarily
-      a one-way-road. As showin in
-      Figure~\ref{fig:ssr-publisher-with-legacy-subscribers}, subscribers can also
-      be able to call functions of the Publisher, if the implementation permits
-      it.\\
-      In the \gls{ssr} this is possible, because each Subscriber holds a
-      reference to the Controller instance and is therefore able to call its
+      call the \mintinline{c++}{Publisher} functionality in
+      \mintinline{c++}{Controller}, which in turn will send out messages to all
+      of its subscribers.\\
+      Depending on the design of an application, \gls{pubsub} is not
+      necessarily a one-way-road. As shown in
+      Figure~\ref{fig:ssr-publisher-with-legacy-subscribers}, subscribers can
+      also be able to call functions of the \mintinline{c++}{Publisher}, if the
+      implementation permits it.\\
+      In the \gls{ssr} this is possible, because each
+      \mintinline{c++}{Subscriber} holds a reference to the
+      \mintinline{c++}{Controller} instance and is therefore able to call its
       public functions.\\
       According to the principle of encapsulation in \gls{oop}, this type of
       functionality is handled by a separate class. In
-      Figure~\ref{fig:ssr-publisher-with-legacy-subscribers}, the OscHandler and
-      Server instances delegate calls to Controller functionality to their
-      utilities OscReceiver and CommandParser (respectively).
+      Figure~\ref{fig:ssr-publisher-with-all-subscribers}, the
+      \mintinline{c++}{OscHandler} and \mintinline{c++}{Server} instances
+      delegate calls to \mintinline{c++}{Controller} functionality to their
+      utilities \mintinline{c++}{OscReceiver} and
+      \mintinline{c++}{CommandParser} (respectively).
 
     \subsection{IP interface}
       \label{subsec:ip-interface}
@@ -590,7 +600,7 @@ parskip=never]{paper}
       to be linted (error checked) before sending and again parsed, 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}. It has however, no
+      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.
@@ -601,19 +611,25 @@ parskip=never]{paper}
         based \gls{pd} external. It uses two externals
         (\textit{IEMnet}\footnote{
             \href{https://puredata.info/downloads/iemnet}
-          {https://puredata.info/downloads/iemnet}} and pdlua)
-        alongside a Lua library for parsing and creating \gls{xml} (SLAXML).
+        {https://puredata.info/downloads/iemnet}} and
+        \textit{pdlua}\footnote{\href{https://puredata.info/downloads/pdlua}
+      {https://puredata.info/downloads/pdlua}}) alongside a Lua library for
+      parsing and creating \gls{xml}
+      (\textit{SLAXML}\footnote{\href{https://github.com/Phrogz/SLAXML}
+      {https://github.com/Phrogz/SLAXML}}).
 
       \subsubsection{Sending and receiving}
         \label{subsubsec:sending_and_receiving}
         As mentioned in
         section~\nameref{subsec:publisher_subscriber_interface}, the
-        NetworkSubscriber class (part of the \gls{ip} interface) implements the
-        subscriber interface. This means: The network interface subscribes to
-        the messages the publisher (the Controller instance) has to offer.
-        Every time a function of the \gls{ssr}'s Controller instance, that was
-        inherited from Publisher, is called, it will issue the call on all of
-        its subscribers, too.\\
+        \mintinline{c++}{NetworkSubscriber} class (part of the \gls{ip}
+        interface) implements the \mintinline{c++}{Subscriber} interface. This
+        means: The network interface subscribes to the messages the
+        \mintinline{c++}{Publisher} (the \mintinline{c++}{Controller} instance)
+        has to offer. Every time a function of the \gls{ssr}'s
+        \mintinline{c++}{Controller} instance, that was inherited from
+        \mintinline{c++}{Publisher}, is called, it will issue the call on all
+        of its subscribers, too.\\
 
   \cleardoublepage
     \subsection{Open Sound Control interface}
@@ -655,26 +671,30 @@ parskip=never]{paper}
         {ssr-publisher-with-all-subscribers.pdf}
         \caption{A diagram depicting a simplified version of the \gls{pubsub}
           used within the \gls{ssr}.\\
-          {\color{pubsub-in}\textbf{--}} Calls from Publisher to Subscriber
-          {\color{controller-in}\textbf{--}} Calls from Subscribers to
-          Controller (Publisher)
+          {\color{pubsub-in}\textbf{--}} Calls from \mintinline{c++}{Publisher}
+          to \mintinline{c++}{Subscriber} {\color{controller-in}\textbf{--}}
+          Calls from \mintinline{c++}{Subscribers} to
+          \mintinline{c++}{Controller} (\mintinline{c++}{Publisher})
         }
         \label{fig:ssr-publisher-with-all-subscribers}
       \end{figure}
 
       The main implementations of the interface, further described in the
-      following subsections, can be found in the classes OscHandler (handling
-      the \gls{osc} server), OscReceiver (handling incoming \gls{osc}
-      messages and acting upon them in the context of the \gls{ssr} instance)
-      and OscSender (responsible for reacting to calls from the
+      following subsections, can be found in the classes
+      \mintinline{c++}{OscHandler} (handling the \gls{osc} server),
+      \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).\\
       As shown in Figure~\ref{fig:ssr-publisher-with-all-subscribers}, the
-      OscSender is another implementation of the Subscriber interface. This
-      way, every call made through the Publisher (i.e.\ the Controller), will
-      be made on the corresponding function in OscSender as well.
-      With OscReceiver the \gls{osc} interface has direct access to the
-      Controller and can make calls to it, on receiving a message.
+      \mintinline{c++}{OscSender} is another implementation of the
+      \mintinline{c++}{Subscriber} interface. This way, every call made through
+      the \mintinline{c++}{Publisher} (i.e.\ the \mintinline{c++}{Controller}),
+      will be made on the corresponding function in \mintinline{c++}{OscSender}
+      as well. With \mintinline{c++}{OscReceiver} the \gls{osc} interface has
+      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 therefore follows
       that of the \textbf{\nameref{subsec:ip-interface}}, expanding however in
       creating a client-server architecture, controlled by
@@ -718,14 +738,15 @@ parskip=never]{paper}
         Applications can therefore be client and server at the same time.\\
 
         \begin{table}[!htb]
+          \renewcommand{\arraystretch}{1.2}
           \scriptsize
           \centering
           \rowcolors{2}{table-background-one}{table-background-two}
           \begin{tabular}{ p{2cm} | p{8cm} }
             \textbf{\gls{osc} type tag} & \textbf{Type} \\
             \hline
-            \texttt{i} & int32 \\
-            \texttt{f} & float32 \\
+            \texttt{i} & \mintinline{c++}{int32} \\
+            \texttt{f} & \mintinline{c++}{float32} \\
             \texttt{s} & \gls{osc}-string \\
             \texttt{b} & \gls{osc}-blob \\
             \hline
@@ -759,13 +780,14 @@ parskip=never]{paper}
           \label{tab:ssr-osc-data-type-acronyms}
         \end{table}
 
-        As shown in Table~\ref{tab:ssr-osc-data-type-acronyms}, only int32,
-        float32, \gls{osc}-string and \gls{osc}-blob are considered
-        standardized. Most of the remaining non-standard types are however
-        implemented and used by many different clients.
-        For implementing the \gls{ssr} \gls{osc} interface, described in the
-        following subsubsections, it was necessary to use the non-standard types
-        \textit{True} and \textit{False} alongside the standard-types.
+        As shown in Table~\ref{tab:ssr-osc-data-type-acronyms}, only
+        \mintinline{c++}{int32}, \mintinline{c++}{float32}, \gls{osc}-string
+        and \gls{osc}-blob are considered standardized. Most of the remaining
+        non-standard types are however implemented and used by many different
+        clients.  For implementing the \gls{ssr} \gls{osc} interface, described
+        in the following subsubsections, it was necessary to use the
+        non-standard types \textit{True} and \textit{False} alongside the
+        standard-types.
 
       \subsubsection{liblo}
         \label{subsubsec:liblo}
@@ -782,28 +804,29 @@ parskip=never]{paper}
         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
         to the codebase since then. One of them is the implementation of a
-        ServerThread for the C++ abstraction layer, which runs a Server instance
-        on a separate thread automatically.\\
+        \mintinline{c++}{ServerThread} for the C++ abstraction layer, which
+        runs a \mintinline{c++}{Server} instance on a separate thread
+        automatically.\\
         In programming, threads are a way to implement simultaneous and/ or
-        asynchroneous execution of code. The liblo Server class, at the core of
-        the C++ side of the library, is responsible for assigning a network
-        port to listen to for incoming messages, listening for messages,
-        executing code on their arrival (callback handling) and sending
-        messages to clients. As most applications, facilitating liblo, use
-        \gls{osc} only as a messaging system, it usually means, that the
-        application itself is not single-purpose and is busy computing
+        asynchroneous execution of code. The liblo \mintinline{c++}{Server}
+        class, at the core of the C++ side of the library, is responsible for
+        assigning a network port to listen to for incoming messages, listening
+        for messages, executing code on their arrival (i.e.\ callback handling)
+        and sending messages to clients. As most applications, facilitating
+        liblo, use \gls{osc} only as a messaging system, it usually means, that
+        the application itself is not single-purpose and is busy computing
         something else most of the time. Therefore it makes sense to run a
         Server instance on a separate background thread, to not interfere with
         the executional flow of the rest of the program.\\
-        The ServerThread class is able to free its ressources upon going ot of
-        scope, known as \gls{raii}. For this reason, the latest development
-        version, instead of the current stable version of liblo was chosen for
-        the implementation.
+        The \mintinline{c++}{ServerThread} class is able to free its ressources
+        upon going ot of scope, known as \gls{raii}. For this reason, the
+        latest development version, instead of the current stable version of
+        liblo was chosen for the implementation.
 
       \subsubsection{Starting the SSR}
         \label{subsubsec:starting-the-ssr}
         The \gls{ssr} can be started with a rendering engine preselected (an
-          executable postfixed by the supported rendering algorithm is provided
+        executable postfixed by the supported rendering algorithm is provided
         by the software - e.g. \textbf{ssr-wfs}), or by selecting one through
         the configuration file, when using the standard executable named
         \textbf{ssr}. This way \gls{aap}, \gls{bs}, \gls{brs}, generic,
@@ -1057,11 +1080,11 @@ ssr-aap -N “server” -C “127.0.0.1:50002”
         To be able to distinguish between types of
         clients and servers, several message levels were implemented for the
         \gls{osc} interface conceived in the course of this work.\\
-        The \textit{enumeration class} \textit{MessageLevel}
+        The \mintinline{c++}{enumeration class MessageLevel}
         \pdfcomment[color=red,icon=Note]{Don't allow static\_casts above
         MessageLevel::GUI\_SERVER} (see Listing~\ref{lst:ssr_global.h}) defines
-        the four types \textit{CLIENT},
-        \textit{GUI\_CLIENT}, \textit{SERVER}, \textit{GUI\_SERVER}, which are
+        the four types \mintinline{c++}{CLIENT}, \mintinline{c++}{GUI_CLIENT},
+        \mintinline{c++}{SERVER}, \mintinline{c++}{GUI_SERVER}, which are
         represented as non-negative integers (in ascending order), starting
         from 0.\\
 
@@ -1070,35 +1093,39 @@ ssr-aap -N “server” -C “127.0.0.1:50002”
             \inputminted[numbers=left, firstline=54, lastline=60,
               fontsize=\footnotesize]{c++}{../../ssr/src/ssr_global.h}
           \end{mdframed}
-          \caption{src/ssr\_global.h: enum class MessageLevel}
+          \caption{src/ssr\_global.h: \mintinline{c++}{enum class
+          MessageLevel}}
           \label{lst:ssr_global.h}
         \end{listing}\\
 
-        \gls{ssr} client instances subscribe to (\gls{ssr}) server instances
-        with the \textit{MessageLevel} \textit{CLIENT} by default. Server
-        instances get the \textit{MessageLevel} \textit{SERVER} assigned
-        to by each client on subscribing to it.\\
+        \noindent\gls{ssr} client instances subscribe to (\gls{ssr}) server instances
+        with the \mintinline{c++}{MessageLevel} \mintinline{c++}{CLIENT} by
+        default. Server instances get the \mintinline{c++}{MessageLevel}
+        \mintinline{c++}{SERVER} assigned to by each client on subscribing to
+        it.\\
         In the \gls{osc} interface it is implemented as follows: A (recycable
         and reconfigurable) list of clients is held by a server instance, which
-        enables for the \textit{MessageLevel} to change for each client. Every
-        client instance holds a (reconfigurable) server representation, that
-        enables for the \textit{MessageLevel} to change for each client towards
-        its server.\\
+        enables for the \mintinline{c++}{MessageLevel} to change for each
+        client. Every client instance holds a (reconfigurable) server
+        representation, that enables for the \mintinline{c++}{MessageLevel} to
+        change for each client towards its server.\\
         Several messages, such as information related to \gls{cpu} load or
         master signal level are not useful for a rendering client (additionally
         they are issued in very short intervals, which can lead to performance
         issues), which is why they are only sent to clients with a
-        \textit{MessageLevel} of \textit{GUI\_CLIENT} or servers with a
-        \textit{MessageLevel} of \textit{GUI\_SERVER}.\\
+        \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}
         server instance are clients to said server instance. An elevated
-        \textit{MessageLevel} of \textit{SERVER} (instead of \textit{CLIENT})
-        enables them to send messages to the server and have them evaluated.
-        Analogous to a server instance holding a \textit{MessageLevel} of
-        \textit{GUI\_SERVER} towards its clients, a client instance can hold
-        the same \textit{MessageLevel} towards a server instance to receive the
-        above mentioned performance heavy \gls{osc} messages.\\
-        How the setting up of message levels is achieved is further elaborated
+        \mintinline{c++}{MessageLevel} of \mintinline{c++}{SERVER} (instead of
+        \mintinline{c++}{CLIENT}) enables them to send messages to the server
+        and have them evaluated.\\
+        Analogous to a server instance holding a \mintinline{c++}{MessageLevel}
+        of \mintinline{c++}{GUI_SERVER} towards its clients, a client instance
+        can hold the same \mintinline{c++}{MessageLevel} towards a server
+        instance to receive the above mentioned performance heavy \gls{osc}
+        messages.
+        How the setting up of message levels is achieved, is further elaborated
         upon in the following section.
 
       \subsubsection{Message interface}
@@ -1111,8 +1138,8 @@ ssr-aap -N “server” -C “127.0.0.1:50002”
         related to server-client and client-only functionality were integrated
         as well.\\
         Generally it can be distinguished between \textit{direct} messages -
-        sent from a server (or an application mimicking one) to a client to
-        trigger processing (see
+        sent from a server (or an application mimicking one) to a client or a
+        server to trigger processing (see
         Table~\ref{tab:ssr-osc-processing-tracker-transport}), reference (see
         Table~\ref{tab:ssr-osc-reference}), scene (see
         Table~\ref{tab:ssr-osc-scene}), source (see
@@ -1123,27 +1150,9 @@ ssr-aap -N “server” -C “127.0.0.1:50002”
         Table~\ref{tab:ssr-osc-update}) - sent from a client to a server upon
         successful processing an operation related to a \textit{direct}
         message.\\
-        A special set of \textit{direct} message are the subscribe and message
-        level (see Table~\ref{tab:ssr-osc-subscribe}) and poll and message
-        level (see Table~\ref{tab:ssr-osc-client-poll-message-level}) messages.
-        The former - understood only by \gls{ssr} server instances - enable
-        clients to subscribe (with a certain message level) or subscribe other
-        clients (with a predefined message level) and set their own message
-        level or that of another client. The latter set - only understood by
-        clients - enables servers (or applications mimicking one) to poll yet
-        unsubscribed clients to have them subscribe and subscribed clients to
-        reply with an alive message. Similar to the message level message
-        understood by server instances, the one understood by clients sets the
-        message level (of the server representation in the client).\\
-
-        When starting a \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}
-        ,~\ref{tab:ssr-osc-processing-tracker-transport}
-        ,~\ref{tab:ssr-osc-reference} and~\ref{tab:ssr-osc-update}.
 
         \begin{table}[!htb]
+          \renewcommand{\arraystretch}{1.2}
           \scriptsize
           \centering
           \rowcolors{2}{table-background-one}{table-background-two}
@@ -1179,6 +1188,7 @@ ssr-aap -N “server” -C “127.0.0.1:50002”
         \end{table}
 
         \begin{table}[!htb]
+          \renewcommand{\arraystretch}{1.2}
           \scriptsize
           \centering
           \rowcolors{2}{table-background-one}{table-background-two}
@@ -1202,7 +1212,22 @@ ssr-aap -N “server” -C “127.0.0.1:50002”
           \label{tab:ssr-osc-client-poll-message-level}
         \end{table}
 
+        A special set of \textit{direct} message are the \textit{subscribe} and
+        \textit{message level} (see Table~\ref{tab:ssr-osc-subscribe}) and
+        \textit{poll} and \textit{message level} (see
+        Table~\ref{tab:ssr-osc-client-poll-message-level}) messages. The former
+        - understood only by \gls{ssr} server instances - enable clients to
+        subscribe (with a certain message level) or subscribe other clients
+        (with a predefined message level) and set their own message level or
+        that of another client. The latter set - only understood by clients -
+        enables servers (or applications mimicking one) to poll yet
+        unsubscribed clients to have them subscribe and subscribed clients to
+        reply with an alive message. Similar to the \textit{message level}
+        message understood by server instances, the one understood by clients
+        sets the message level (of the server representation in the client).\\
+
         \begin{table}[!htb]
+          \renewcommand{\arraystretch}{1.2}
           \scriptsize
           \centering
           \rowcolors{2}{table-background-one}{table-background-two}
@@ -1236,6 +1261,7 @@ ssr-aap -N “server” -C “127.0.0.1:50002”
         \end{table}
 
         \begin{table}[!htb]
+          \renewcommand{\arraystretch}{1.2}
           \scriptsize
           \centering
           \rowcolors{2}{table-background-one}{table-background-two}
@@ -1264,6 +1290,7 @@ ssr-aap -N “server” -C “127.0.0.1:50002”
         \end{table}
 
         \begin{table}[!htb]
+          \renewcommand{\arraystretch}{1.2}
           \scriptsize
           \centering
           \rowcolors{2}{table-background-one}{table-background-two}
@@ -1305,7 +1332,16 @@ ssr-aap -N “server” -C “127.0.0.1:50002”
           \label{tab:ssr-osc-scene}
         \end{table}
 
+        When starting a \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}
+        ,~\ref{tab:ssr-osc-source}
+        ,~\ref{tab:ssr-osc-processing-tracker-transport}
+        ,~\ref{tab:ssr-osc-reference} and~\ref{tab:ssr-osc-update}.
+
         \begin{table}[!htb]
+          \renewcommand{\arraystretch}{1.2}
           \scriptsize
           \centering
           \rowcolors{2}{table-background-one}{table-background-two}
@@ -1365,8 +1401,17 @@ ssr-aap -N “server” -C “127.0.0.1:50002”
           }
           \label{tab:ssr-osc-source}
         \end{table}
+        
+        \noindent A client instance (see~\ref{para:client-instance}) will only
+        respond to the \textit{direct} messages listed in
+        Table~\ref{tab:ssr-osc-client-poll-message-level}
+        ,~\ref{tab:ssr-osc-scene} ,~\ref{tab:ssr-osc-source}
+        ,~\ref{tab:ssr-osc-processing-tracker-transport}
+        and~\ref{tab:ssr-osc-reference}, but is able to send \textit{update}
+        messages.
 
         \begin{table}[!htb]
+          \renewcommand{\arraystretch}{1.2}
           \scriptsize
           \centering
           \rowcolors{2}{table-background-one}{table-background-two}
@@ -1472,9 +1517,9 @@ ssr-aap -N “server” -C “127.0.0.1:50002”
 
           As shown in Listing~\ref{lst:ssr-workflow-sclang-controls-server}, it
           is necessary to subscribe to the server instance with a
-          \textit{MessageLevel} of \textit{SERVER} or higher.\\
+          \mintinline{c++}{MessageLevel} of \mintinline{c++}{SERVER} or higher.\\
           After doing so, also all \textit{direct} \gls{osc} messages (i.e.
-            Table~\ref{tab:ssr-osc-source},~\ref{tab:ssr-osc-scene}
+          Table~\ref{tab:ssr-osc-source},~\ref{tab:ssr-osc-scene}
           ,~\ref{tab:ssr-osc-reference},~\ref{tab:ssr-osc-subscribe}) are
           evaluated when sent to the \gls{ssr}.\\
           The server instance will relay valid messages to all of its active
@@ -1503,9 +1548,10 @@ ssr-aap -N “server” -C “127.0.0.1:50002”
           are accepted by the client instance, when coming from the server
           address and port.\\
           An interesting concept here is to (temporarily) set a different
-          \textit{MessageLevel} for the application acting as a server (e.g.\
-          to \textit{GUI\_SERVER}), to receive \gls{gui} relevant messages, as
-          explained in \nameref{subsubsec:message_interface}.\\
+          \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}.\\
 
     \subsection{Automated tests}
       \label{subsec:automated_tests}
@@ -1530,10 +1576,11 @@ ssr-aap -N “server” -C “127.0.0.1:50002”
         and~\ref{lst:ssr-tests-sclang-subscribed-controls-server} describe
         server-side tests for robustness. While the first will not lead to any
         processed action by the server, the latter will. This is explained by
-        \gls{sclang} not being a subscribed client with a \textit{MessageLevel}
-        of \textit{SERVER} or higher in the first case. In the second test
-        however \gls{sclang} subscribes to the \gls{ssr} server instance, which
-        is why the \gls{osc} messages are evaluated in this case.\\
+        \gls{sclang} not being a subscribed client with a
+        \mintinline{c++}{MessageLevel} of \mintinline{c++}{SERVER} or higher in
+        the first case. In the second test however \gls{sclang} subscribes to
+        the \gls{ssr} server instance, which is why the \gls{osc} messages are
+        evaluated in this case.\\
 
         \begin{listing}[!htb]
           \begin{mdframed}
@@ -1641,7 +1688,7 @@ ssr-aap -N “server” -C “127.0.0.1:50002”
         estimated, when observing the \gls{ssr}'s workload towards the system,
         while using the long-running tests.\\
         It has to be mentioned, that a higher load can be observed, when using
-        higher levels of verbosity (especially above \textit{-vv}). This is
+        higher levels of verbosity (especially above \textbf{-vv}). This is
         explained by the fact, that the \gls{ssr} will print out every
         \gls{osc} message received and sent above the aforementioned verbosity
         level.
@@ -1688,6 +1735,9 @@ ssr-aap -N “server” -C “127.0.0.1:50002”
     \subsection{Implementing AlienLoudspeaker}
       \label{subsec:implementing_alienloudspeaker}
 
+    \subsection{Implementing automatic client discarding}
+      \label{subsec:implementing_automatic_client_discarding}
+
     \subsection{Status messages}
       \label{subsec:status_messages}