summaryrefslogtreecommitdiffstats
path: root/thesis
diff options
context:
space:
mode:
Diffstat (limited to 'thesis')
-rw-r--r--thesis/thesis.tex116
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}