thesis/thesis.tex: Elaborating on implemented features. Extending network enabled head tracking. Minor fix.

1 files changed, 51 insertions, 1 deletions

diff --git a/thesis/thesis.tex b/thesis/thesis.tex
index 0c7c47b..7d752c3 100644
--- a/thesis/thesis.tex
+++ b/thesis/thesis.tex
@@ -244,7 +244,7 @@ parskip=never]{paper}
     preferred, due to its ease of reproducability (the sources can be
     retrieved, modified and used, free of charge).\\
 
-    Spatial audio rendering software exists for different \glspl{OS}, in
+    Spatial audio rendering software exists for different \glspl{os}, in
     several stages of completeness and feature richness, while covered by free
     and non-free licenses. The following work will focus on free software, used
     in scientific research and artistic contexts. Several spatial audio
@@ -1808,6 +1808,47 @@ ssr-aap -N “server” -C “127.0.0.1:50002”
 
     \subsection{Implemented Features}
       \label{subsec:implemented_features}
+      The \gls{osc} interface described in~\ref{subsec:osc-interface} can be
+      seen as a full replacement (with one minor exception, detailed
+      in~\ref{subsubsec:scene_transfer}) for the \gls{ip} interface, already in
+      place. Its additional features are what set it trully apart though, when
+      not only regarding non-reliance on external software to enable \gls{osc}
+      capabilities.\\
+
+      The implementation follows the internal \gls{pubsub} interface, as
+      described in~\ref{subsec:publisher_subscriber_interface} and extends it,
+      where appropriate. Additionally an open client-server architecture has
+      been created, according to a message level system, further elaborated
+      upon in \gls{subsubsec:message_levels}. An attempt at giving extensive
+      examples on the various setup possibilities, that are now possible, is
+      made in \gls{subsubsec:setups}, some of which are still dependant on
+      various missing features (see~\ref{subsec:future_work}).\\
+      The \gls{osc} messaging system is adhering to the aforementioned
+      client-server architecture by distinguishing between client-only,
+      server-only and messages available to clients and servers alike
+      (see~\ref{subsubsec:message_interface}). Examples for different workflows
+      are given in~\ref{subsubsec:workflow_examples} to illustrate simple
+      use-cases.\\
+      This puts the \gls{osc} interface in the unique position of providing a
+      native messaging interface and a flexible architecture. It can be used
+      from single local instances up to large scale networked setups (with the
+      limitations discussed in~\ref{subsubsec:alien_loudspeaker}
+      and~\ref{subsubsec:assigning_in_and_outputs_on_the_fly}).\\
+      While with the \gls{ip} interface, multiple instances are only
+      controllable by using an \gls{osc} capable application or one, that is
+      able to send \gls{xml}-formatted strings over \gls{tcp}/\gls{ip}, the
+      \gls{osc} interface can deal with \textit{n} clients natively, while only
+      one instance has to be controlled using \gls{osc}. The behavior implies,
+      that setups are possible, in which a large collection of different types
+      of renderers can share the same scene, which is particularly useful for
+      e.g.\ auditioning different rendering algorithms over the same system, or
+      rather in the same room.\\
+      Message sending takes place over \gls{udp}, instead of \gls{tcp}, which
+      lowers the complexity of the network topology (\gls{udp} does not perform
+      handshakes for every packet sent, unlike \gls{tcp}) and thus the size of
+      each message sent.\\
+      The \gls{osc} interface therefore implements messaging using lower
+      bandwidth at a greater feature set.
 
     \subsection{Future Work}
       \label{subsec:future_work}
@@ -2161,6 +2202,15 @@ ssr-aap -N “server” -C “127.0.0.1:50002”
         that could prove to be cheaper, more reliable and flexible, than the
         compile-time opt-ins (i.e.\ VRPN, Polhemus Fastrak/ Patriot, InterSense
         InertiaCube3).\\
+        In the specific case of setting up a large array of independent
+        \gls{brs} or \gls{bs} renderers, connected to one server instance or
+        application, it might however be needed to extend the messaging system
+        to allow passing on of messages from one client to a server only to one
+        specific other client (a type of proxy messaging). This would ensure,
+        that every renderer can be supplied with a specific stream of \gls{osc}
+        messages from its assigned head tracker. Single (and local) renderers
+        can be started as a server instance and clients can be assigned to it
+        flexibly.
 
   \cleardoublepage
   \pagestyle{empty}