thesis/thesis.tex: Adding more acronyms. Adding special colors for diagrams. Adding first diagram in subssubsection Client-server setup. Adding some info on IP interface, Pd integration, OSC through Pd and sending and receiving information.

1 files changed, 84 insertions, 8 deletions

diff --git a/thesis/thesis.tex b/thesis/thesis.tex
index 2630191..8e7f0c1 100644
--- a/thesis/thesis.tex
+++ b/thesis/thesis.tex
@@ -20,7 +20,13 @@
 \usepackage{float}
 \floatstyle{boxed}
 \restylefloat{figure}
-\usepackage{color}
+\usepackage[usenames,dvipsnames,svgnames,table]{xcolor}
+\definecolor{osc-out}{RGB}{150,0,255}
+\definecolor{osc-in}{RGB}{0,0,255}
+\definecolor{audio-in}{RGB}{255,0,0}
+\definecolor{audio-out}{RGB}{0,206,0}
+
+%\usepackage{color}
 \usepackage{hyperref}
 \hypersetup{hidelinks, colorlinks = false}
 \usepackage[font=scriptsize]{caption}
@@ -30,15 +36,22 @@
 \usepackage[acronym,nonumberlist,toc]{glossaries}
 \newacronym{bs}{BS}{Binaural Synthesis}
 \newacronym{hoa}{HOA}{Higher Order Ambisonics}
+\newacronym{ip}{IP}{Internet Protocol}
 \newacronym{jack}{JACK}{JACK Audio Connection Kit}
+\newacronym{oop}{OOP}{Object-oriented Programming}
 \newacronym{osc}{OSC}{Open Sound Control}
 \newacronym{pubsub}{PubSub}{Publish-subscribe message pattern}
+\newacronym{pd}{Pd}{PureData}
 \newacronym{ssr}{SSR}{SoundScape Renderer}
+\newacronym{tcp}{TCP}{Transmission Control Protocol}
 \newacronym{vbap}{VBAP}{Vector Based Amplitude Panning}
 \newacronym{wfs}{WFS}{Wave Field Synthesis}
+\newacronym{xml}{XML}{Extensible Markup Language}
 \makeindex
 \makeglossaries
 
+
+
 \graphicspath{{../images//}}
 
 \begin{document}
@@ -193,8 +206,8 @@
       are currently used for rendering a selected source.
       \gls{ssr} uses TCP/IP sockets for communication and is therefore not directly
       \gls{osc} enabled. This functionality can be achieved using the capapilities of
-      other applications such as \href{http://puredata.info}{PureData}
-      \citep{website:puredata2016} in combination with it though.\\
+      other applications such as \gls{pd} \citep{website:puredata2016} in
+      combination with it though.\\
       Unlike the two renderers above, the \gls{ssr} is not able to run large-scale
       \gls{wfs} setups, as it lacks the features to communicate between instances of
       itself on several computers, while these instances serve a subset of the
@@ -244,7 +257,7 @@
     needed, be controlled via \gls{osc}.
     \subsection{Prelimenaries}
       \label{subsec:preliminaries}
-      In preparation to the exposé I tried to implement a side-by-side
+      In preparation to the work an implement a side-by-side
       installation, using Arch Linux on a medium scale setup, facilitating the
       \gls{wfs} system of the Electronic Studio at TU Berlin. Unfortunately the
       proprietary Dante driver, that is used in that system is very complex to be
@@ -263,7 +276,7 @@
       sought after \gls{ssr} features.
     \subsection{Outline}
       \label{subsec:outline}
-      Initially extending the \gls{ssr}'s features was aimed
+      Initially extending the \gls{ssr}'s features was aimed at 
       \subsubsection{Remote controlling a server}
         \label{subsubsec:remote_controlling_a_server}
       \subsubsection{Remote controlling clients}
@@ -272,10 +285,57 @@
         \label{subsubsec:rendering_on_dedicated_speakers}
     \subsection{Publisher/Subscriber interface}
       \label{subsec:publisher_subscriber_interface}
-    \subsection{IP interface}
+      The \gls{ssr} internally uses a \gls{pubsub}, which is a design pattern,
+      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 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.\\
+      The \gls{ssr} implements a content-based filtering system, in which each
+      subscriber evaluates the messages received and acts depending on its own
+      constraints to implement further actions upon it.\\
+      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.\\
+      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.
+
+    \subsection{\gls{ip} interface}
       \label{subsec:ip-interface}
-      \subsubsection{PureData integration}
-        \label{subsubsec:puredata_integration}
+      The \gls{ssr} from early on incorporated a network interface, that
+      accepts specially terminated \gls{xml}-formatted strings over a \gls{tcp}
+      port, called “\gls{ip} interface”. This has the benefit of reusing the
+      same \gls{xml} parser code in use for scene and reproduction
+      description.\\
+      A downside is however, that - from the perspective of other software - it
+      is complicated to use, as a conversion to \gls{xml} has to be attempted
+      before sending a message to the \gls{ssr}. Additionally the message has
+      to be linted (error checked) before sending and again parsed, after
+      receiving an answer from the application.\\
+
+      \paragraph{OSC through PureData}
+        \label{par:osc_through_puredata}
+        To allow \gls{osc} communication, the \gls{ssr} incorporates a Lua
+        based \gls{pd} external. It uses two externals (iemnet and pdlua)
+        alongside a Lua library for parsing and creating \gls{xml} (SLAXML).
+
+      \paragraph{Sending and receiving}
+        \label{par: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.\\
+
   \cleardoublepage
   \section{Results}
     \label{sec:results}
@@ -285,6 +345,22 @@
         \label{subsubsec:liblo}
       \subsubsection{Client-Server setup}
         \label{subsubsec:client_server_setup}
+        \begin{figure}[!htb]
+          \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
+            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.\\
+            {\color{osc-in}\textbf{--}} \gls{osc} input
+            {\color{osc-out}\textbf{--}} \gls{osc} output
+            {\color{audio-in}\textbf{--}} Audio input
+            {\color{audio-out}\textbf{--}} Audio output
+          }
+          \label{fig:ssr-client-server-shared-output}
+        \end{figure}
+
       \subsubsection{Layered clients}
         \label{subsubsec:layered_clients}
       \subsubsection{Message interface}