thesis/thesis.tex: Updating publisher/subscriber interface figures. Adding information for osc-interface. Removing section Results. Adding glossary entry for sclang.

1 files changed, 98 insertions, 18 deletions

diff --git a/thesis/thesis.tex b/thesis/thesis.tex
index b2adedd..cd02e1f 100644
--- a/thesis/thesis.tex
+++ b/thesis/thesis.tex
@@ -39,7 +39,7 @@ parskip=never]{paper}
 \usepackage[authoryear]{natbib}
 
 % glossary
-\usepackage[acronym,nonumberlist,toc]{glossaries}
+\usepackage[acronym,nonumberlist,toc,xindy]{glossaries}
 \newacronym{aap}{AAP}{Ambisonics Amplitude Panning}
 \newacronym{adat}{ADAT}{Alesis Digital Audio Tape}
 \newacronym{alsa}{ALSA}{Advanced Linux Sound Architecture}
@@ -74,7 +74,12 @@ parskip=never]{paper}
 \newacronym{vbap}{VBAP}{Vector Based Amplitude Panning}
 \newacronym{wfs}{WFS}{Wave Field Synthesis}
 \newacronym{xml}{XML}{Extensible Markup Language}
-\makeindex
+\newglossaryentry{sclang}{
+  name={sclang},
+  description={Name of the SuperCollider programming language and the
+  interpreter executable of the SuperCollider programming language}
+}
+
 \makeglossaries
 
 \graphicspath{{../images//}}
@@ -176,6 +181,7 @@ parskip=never]{paper}
 
   \pagestyle{empty}
   {
+    \setcounter{tocdepth}{4}
     \renewcommand{\thispagestyle}[1]{}
     \tableofcontents
     \newpage
@@ -268,8 +274,8 @@ parskip=never]{paper}
       to each node, WFSCollider usually uses the audio files to be played on
       all machines simultaneously and synchronizes between them.\\
       It has a feature-rich \gls{gui} in the \textit{many window} style, making available
-      time lines and movement of sources through facilitating what the sclang
-      (SuperCollider programming language) has to offer.\\
+      time lines and movement of sources through facilitating what the
+      \gls{sclang} has to offer.\\
       As WFSCollider basically is SuperCollider plus extra features, it is also
       an \gls{osc} enabled application and can thus also be used for mere
       multi-channel playback of audio.\\
@@ -373,6 +379,7 @@ parskip=never]{paper}
     renderers, will not be problematic, as master and nodes can communicate
     through their builtin TCP/IP sockets directly and the master can, if
     needed, be controlled via \gls{osc}.
+
     \subsection{Prelimenaries}
       \label{subsec:preliminaries}
       In preparation to this work, an implemention of a side-by-side
@@ -405,6 +412,7 @@ parskip=never]{paper}
       described in \nameref{sec:implementation}, as they can be tested using
       two machines running Linux, \gls{jack} and a development version of
       the \gls{ssr}.\\
+
     \subsection{Outline}
       \label{subsec:outline}
       As described in \nameref{sec:implementation}, initially extending the
@@ -414,10 +422,13 @@ parskip=never]{paper}
 
       \subsubsection{Remote controlling a server}
         \label{subsubsec:remote_controlling_a_server}
+
       \subsubsection{Remote controlling clients}
         \label{subsubsec:remote_controlling_a_client}
+
       \subsubsection{Rendering on dedicated speakers}
         \label{subsubsec:rendering_on_dedicated_speakers}
+
     \subsection{Publisher/Subscriber interface}
       \label{subsec:publisher_subscriber_interface}
       The \gls{ssr} internally uses a \gls{pubsub}, which is a design pattern,
@@ -431,18 +442,20 @@ parskip=never]{paper}
       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.\\
+
       \begin{figure}[!htb]
         \centering
-        \includegraphics[scale=0.6, trim = 6mm 91mm 12mm 10mm, clip]
-        {ssr-publisher-with-all-subscribers.pdf}
+        \includegraphics[scale=0.6, trim = 6mm 130mm 12mm 4mm, clip]
+        {ssr-publisher-with-legacy-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)
         }
-        \label{fig:ssr-publisher-with-all-subscribers}
+        \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}.\\
@@ -454,7 +467,7 @@ parskip=never]{paper}
       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-all-subscribers}, subscribers can also
+      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
@@ -462,7 +475,7 @@ parskip=never]{paper}
       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-all-subscribers}, the OscHandler and
+      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).
 
@@ -497,10 +510,68 @@ parskip=never]{paper}
         its subscribers, too.\\
 
   \cleardoublepage
-  \section{Results}
-    \label{sec:results}
+
     \subsection{Open Sound Control interface}
       \label{subsec:osc-interface}
+      The networking interface conceived in the course of this work was
+      developed in several branches, using the git version control system
+      (written by Linus Torvalds, now maintained by Junio
+      Hamano\footnote{\href{https://git-scm.com}{https://git-scm.com}}),
+      publicly on Github\footnote{\href{https://github.com/dvzrv/ssr}
+      {https://github.com/dvzrv/ssr}}. Internally the liblo library (further
+      explained in~\ref{subsubsec:liblo}) was harnessed to implement \gls{osc}
+      functionality (see~\ref{subsubsec:open-sound-control}) for the
+      \gls{ssr}.\\
+      After initial conversations with the current maintainer Matthias Geier
+      through the project's Github issue
+      tracker\footnote{ \href{https://github.com/soundscaperenderer/ssr}
+      {https://github.com/soundscaperenderer/ssr}}, different ideas were worked
+      out to achieve a broad solution to the server-client and client-only
+      setups and get a better understanding of the underlying design. Initial
+      attempts, such as the mapping of a networking setup in the scene
+      description\footnote{
+      \href{https://github.com/dvzrv/ssr/tree/distributed\_reproduction}
+      {https://github.com/dvzrv/ssr/tree/distributed\_reproduction}}
+      proved too restrictive though, as it would allow the networking
+      functionality only to renderers, that use loudspeakers and mix scene
+      description with networking description.\\
+      A nearly configuration-less approach, based on subscribing clients on
+      sending poll messages to them proved more open (in the sense that it can
+      be interfaced with by any \gls{osc}-capable application or programming
+      language) and have less configuration overhead.\\
+
+      \begin{figure}[!htb]
+        \centering
+        \includegraphics[scale=0.6, trim = 6mm 91mm 12mm 10mm, clip]
+        {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)
+        }
+        \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
+      \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.
+      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
+      \textbf{\nameref{subsubsec:message_levels}}, using a unified
+      \textbf{\nameref{subsubsec:message_interface}}.
+
       \subsubsection{Open Sound Control}
         \label{subsubsec:open-sound-control}
         \gls{osc} is an “open, transport-independent, message-based protocol
@@ -515,6 +586,7 @@ parskip=never]{paper}
         SuperCollider \citep{website:supercollider}) since then.\\
         \gls{osc}'s syntax is defined by several parts, which are discussed
         briefly in this section.\\
+
         \begin{itemize}
           \item Atomic data types, which are also reflected in type tags (see
             Table~\ref{tab:ssr-osc-data-type-acronyms} for details)
@@ -528,6 +600,7 @@ parskip=never]{paper}
           \item Packets, the unit of transmission (sent over \gls{udp} or
             \gls{tcp}), consisting of a message or a bundle.
         \end{itemize}
+
         According to the specification, applications sending \gls{osc} packets
         are considered a client and the ones receiving packets a server.
         Applications can therefore be client and server at the same time.\\
@@ -1251,8 +1324,8 @@ ssr-aap -N “server” -C “127.0.0.1:50002”
         \label{subsubsec:workflow_examples}
         Using any \gls{osc} capable programming language or application enables
         for communication with the \gls{ssr}. The following examples illustrate
-        simple workflows using sclang (the SuperCollider programming language)
-        and should therefore be \gls{os} agnostic.\\
+        simple workflows using \gls{sclang} and should therefore be \gls{os}
+        agnostic.\\
 
         \paragraph{Controlling a server}
           \label{para:controlling_a_server}
@@ -1262,7 +1335,7 @@ ssr-aap -N “server” -C “127.0.0.1:50002”
               \inputminted[numbers=left, firstline=3, lastline=29,
               fontsize=\footnotesize]{supercollider}{../../ssr/supercollider/workflows.scd}
             \end{mdframed}
-            \caption{supercollider/workflows.scd: sclang as client
+            \caption{supercollider/workflows.scd: \gls{sclang} as client
             controlling a \gls{ssr} server instance}
             \label{lst:ssr-workflow-sclang-controls-server}
           \end{listing}\\
@@ -1285,7 +1358,7 @@ ssr-aap -N “server” -C “127.0.0.1:50002”
               \inputminted[numbers=left, firstline=31, lastline=61,
               fontsize=\footnotesize]{supercollider}{../../ssr/supercollider/workflows.scd}
             \end{mdframed}
-            \caption{supercollider/workflows.scd: sclang mimics server,
+            \caption{supercollider/workflows.scd: \gls{sclang} mimics server,
             controlling a \gls{ssr} client instance}
             \label{lst:ssr-workflow-sclang-is-server-controls-client}
           \end{listing}\\
@@ -1304,11 +1377,18 @@ ssr-aap -N “server” -C “127.0.0.1:50002”
           to \textit{GUI\_SERVER}), to receive \gls{gui} relevant messages, as
           explained in \nameref{subsubsec:message_interface}.\\
 
-    \cleardoublepage
+    \subsection{Automated tests}
+      \label{subsec:automated_tests}
+      To probe the \gls{osc} interface's robustness automatically, a set of
+      tests were written (as there exists no test framework for the \gls{ssr}
+      itself) in \gls{sclang}, to use all of the available messages (especially when
+      they should not be allowed - in the case of not being a subscribed client
+      or a setup server).
+
+
+  \cleardoublepage
   \section{Discussion}
     \label{sec:discussion}
-    \subsection{Stress testing the \gls{osc} interface}
-      \label{subsec:stress_testing_the_osc_interface}
   \cleardoublepage
     \subsection{Implementing a NullRenderer}
       \label{subsec:implementing_a_nullrenderer}