\subsection{The Virtual Soundstage}

The abstracted virtual space will be a two-dimensional space with orthogonal basis $(\hat{x},\hat{y})$. For ease of visualization, $\hat{x}$ will be considered as left-pointing, and $\hat{y}$ will be considered as pointing forward and bisecting the soundstage. Thus, the used virtual soundstage area will be the area within the range of positive $y$; the positive $x$ direction will be perceptual left, and the negative $x$ direction will be perceptual right.

\subsection{The Sound Source}

\subsubsection{The propagation of sound from real sound sources}

The first immediate barrier to modeling the propagation of sound from a sound source is the nature of any given sound source. Few acoustic resonators approach being perfect point sources with equal spherical radiation of sound across the entire audible frequency spectrum. It is, in theory, possible to model the emission of sound using frequency-dependent statistical directivity data derived from various instruments. This model could be applied to the algorithm if the facing of the sound source was known. However, chasing down this trail raises questions into the propagation of sound towards any given microphone, the effect of the physical characteristics of the sound stage, and the effect of height components in the positioning of the source and microphones.

Trying to account for all of these components would eventually necessitate venturing into the realm of physical modeling. While such an undertaking is a worthwhile avenue of research, it breaks this processor's goals of ease of use and intuition of abstraction, as well violating the goal of remaining computationally efficient enough to use as a general DAW plug-in.

A review of literature regarding stereophonic recording practice tends to focus on the directional characteristics of sound sources as considerations for the height of microphones in the array, with the aim of obtaining the desired blend of each source’s characteristic frequency components, as well as informing the optimal placement of spot/area microphones. The effect that a sound source's directivity can have on localization does not seem to be a remarkable characteristic of stereophonic recording arrays.

\subsubsection{The virtual sound source}

Based on the typical assumptions of stereophonic recording praxis, the virtual sound source can be considered as an ideal sound radiator which radiates sound equally towards every measured virtual point. The virtual sound source, $S$, has its location at $(r, \theta)$ and does not have any other properties -- it does not inherently apply any frequency/amplitude transfer function onto the pre-encoded signal.

The useable range of $\theta_S$, in keeping with the bounds of the defined virtual soundstage is $[0, \pi]$. The radial distance $r_S$ is an abstraction of a real distance in meters.

Since the virtual sound source only imparts positional data to the sound, the actual recorded sound to be encoded can also be represented by $S$; where $S$ is the recorded sound, which is emitted into the virtual space at point $(r, \theta)$\footnote{The choice of polar coordinates to represent the position of $S$ is semi-arbitrary, and does owe some part to the specifics of the implementation. An origin shift will be necessary during the processing which will require the translation of the polar coordinates into cartesian, however there will be a second translation back to polar coordinates again. In this sense, the source is always conceptually considered based on its angle and distance from some reference point. Thus, it seems natural to define $S$ in those terms.}

\subsection{Virtual Microphones}

The virtual stereophonic array can be represented as a set of virtual microphones, $M \: | \: M = \{m_1, ... m_n\}$. Each virtual microphone has its placement within the virtual space at coordinates $(x,y)$, and has orientation $\theta$, with polar directivity factor $p$.

The orientation, $\theta$ of the virtual microphone represents is direction of facing into the soundstage. Like $\theta_s$, the range of usable values is $[0, \pi]$ where a rotation of $0$ indicates a facing directly to the left, a facing of $\pi$ is directly to the right, and an orientation of $\frac{\pi}{2}$ points the virtual microphone directly forward -- parallel to the $y$-axis with a lateral offset of $x_m$.

The polar directivity value, $p$ is a real number in the range $[0,1]$ where $p=0$ yields a non-directional polar directivity pattern, and $p=1$ yields a bidirectional polar directivity pattern. The resulting polar attenuation pattern at angle of arrival (relative to the ``font'' of the virtual microphone) $\phi$ for any value of $p$ can be found as:

\begin{equation}\label{polarPatternPlot}
m(p,\phi) = (1-p) + p\cos(\phi)
\end{equation}

\subsubsection{Limitations in abstracting ideal microphones}

It should be noted that real microphones' polar patterns are frequency-dependent, with cardioid microphones ($0 < p < 1$) becoming increasingly less directional at lower frequencies. At higher frequencies, the physical body of the microphone and the diameter of the microphone diaphragm also begin to affect in the polar response. Additionally, cardioid microphones -- due to the physical mechanics of generating a cardioid polar pattern -- tend to exhibit a marked attenuation in their frequency response at lower frequencies.

Often, the specific color that a specific model of microphone imparts on the recorded sound is carefully chosen, with the choice of microphone being considered one of the major creative decisions in recording and the design of many microphones being intentional to support specific colorations and yield various creative options. It would be impractical to try and model the specific responses of common microphones used in main arrays, and the processing needed to apply the frequency-domain modeling would break the CPU-efficiency goal. Additionally, an attempt to reproduce the frequency-domain aspects of a stereophonic array would have the effect of distorting the (likely intentionally-chosen) frequency-domain aspects of the source recording.

Thus, using virtual microphones with ideal polar patterns is likely the optimal use-case for most users. This will be with the understanding that the virtual microphone array will impart localization cues that approach that of a real microphone array, but -- due to limitations in modeling real-world physics -- will not fully replicate the cues of a real-world microphone array. However, the processor will provide localization cues that are closer than level-difference-only panning methodologies.

There is one case that is worth considering. As previously noted, directional microphones tend to exhibit a marked attenuation at low-frequencies. There are some recording techniques that take advantage of this tendency, especially since the human prioritization of localization cues is frequency-dependent. It may be desirable to include some simple high-pass and low-pass filter options within the implementation to allow the user to emulate some of the key frequency-dependent behavior.

\subsection{The User Interface}

In the implementation of the processor, the relevant controls for defining the desired virtual objects and their parameters need to be exposed to the user. For the virtual sound source, this means exposing controls for $\theta_S$ and $r_S$. Then the number of virtual microphones in set $M$ needs to be defined, the relevant values for $p_m$, $(x_m,y_m)$, and $\theta_m$ need to be exposed.

\subsubsection{Orienting the user within the virtual space} The first concern is presenting the orientation of the virtual space to the user in a way allows them to be intuitively oriented within and able to intuitively understand the distances and placements of virtual objects with in. Thus, establishing an intuitive reference for the placement of the origin of the space is of primary importance.

Following the specific facings of the basis $(\hat{x},\hat{y})$, the most logical place to orient $O$ would be at the central point of the microphone array -- which is also what user will intuit as the "perceptual center". This also gives a consistent and predictable basis for user to take real-world measurements and translate them into the virtual abstraction used by the processor.

\subsubsection{Orienting the virtual sound source} The typical mixing engineer is likely to naturally think of angular rotation in terms of radians. Similarly, considering the amount of angular rotation from the $x$-axis is not reflective of the "front" oriented human experience. Thus, the user interface is better presented with $\theta_S$ translated as degrees of deflection from forward. Additionally, there is a bias (at least within Western culture) that a numerical increase in amount be translated as right-ward motion. Due to this, the number of degrees needs to decrease with counter-clockwise rotation.

Thus, if $\phi$ is the value, in degrees of deflection from forward, then:

\begin{equation}
\theta_S = (-\phi + 90) * \frac{\pi}{180} \; | \; \phi = [-90,90]
\end{equation}

Since $r$ is abstracted as meters, the user can specify the distance $r$ from point $O$ directly -- understanding it as the distance from the center of the real (or imagined) microphone array.

\subsubsection{Constructing the microphone array}

The set of microphones in the virtual array, $M$, is some number of virtual microphones. While it is possible to define an arbitrary number of virtual microphones each at any conceivable position within the virtual space and define the algorithm in a way to accommodate, usual stereophonic recording practice, again, gives some practical limits that can be used to refine and focus the amount of controls exposed to the user and enhance the quality of the user experience.

The fundamental praxis of stereophonic recording is based on the use of a microphone pair, that translate to the raw left and right audio channels. This microphone pair is laterally spaced at some distance, and has an angular splay of some angle. This primary pair can be designated the ``main' stereo pair, $m_\text{mains}$, that has the properties of its lateral distance, $d$, angular splay, $\phi$.

As discussed in the overview, it is also common to use a second pair of microphones in tandem to the first, that occupy a wider spacing. These additional microphones can be designated as the "flanks", $m_\text{flanks}$. The flank pair will have the same properties, $d$ and $\phi$, as the main pair.

Finally, there is a long tradition of using a center microphone, $m_\text{center}$. Typically, the center microphone does not rotate in the 2D plane; so, it will only have a distance, $d$. However, for a center microphone, the displacement is forward, rather than lateral; following this, any value for $d_\text{center}$ will be long the $y$ axis.

This gives a maximum size of $M$ of $n=5$, which is a manageable number. These are presented to the user as two pairs and the single center microphone. The preferred ordering of the microphones within $M$ will follow the order of expected frequency of use (mains, flanks, center), and the audio-industry preference for left-right ordering of channels:

\begin{equation}
M = \{m_\text{mL}, m_\text{mR}, m_\text{fL}, m_\text{fR}, m_\text{c}\}
\end{equation}

The two pairs and center microphone are each switchable, so that the user can freely enable/disable any combination of them. Each microphone group also has a control exposed that applies an amplitude scalar to the signal of that group, to allow for different proportions of that group's signal into the output\footnote{Ideally, the plug-in would be able to output the individual processing of each microphone; however the format of the competition that the plug-in was designed for limits the output channels to two.}. This scalar, $g$, has an adjustment range in decibels: $g = [-20,0]$.

\subsubsection{Identifying virtual microphone distance limits}

Identifying practical limits for the $d$ value for the two pairs will require a bit of arbitrary demarcation. The main pair must allow for a minimum of $d_\text{mains}=0$ to accommodate coincident microphone techniques. Likewise, for flexibility and simplicity there is little reason not to allow $d_\text{flanks} = 0$ (though it would an odd use-case for this value to be used). For the center microphone, while it is common in many cases for it to be displaced forward, there are also a number of cases that require it to remain in-line with adjacent pairs; so a minimum value of $d_\text{center} = 0$ is also necessary to accommodate all reasonable use-cases.

For maximal allowed values, and examination of the literature shows that main mic pairs usually occur in spaces smaller than 100cm, however triplets can employ rather wide distances, with ``typical'' Decca-tree configurations spanning 2m. The current implementation allows for a maximal span of 3m to accommodate some extra working room for three-microphone expanded configurations, additionally, due to the common use of $d < 1m$, the values for $d_\text{mains}$ are presented to the user in centimeters; this gives $0 \leq d_\text{mains} \leq 300$ as the total range for the mains' lateral distance.

After an informal poll and discussion with several sound recordists who specialize in acoustic ensemble recording, an upper limit of 10m was chosen for the flanking pair. This gives $0 \leq d_\text{flanks} \leq 10$ as the total range for the flanks' lateral distance, and this presented to the user in meters.

Finally, the maximum amount of forward displacement for the center microphone is was set to $d_\text{center} = 100$ in centimeters. Common uses of a forward-set center microphone are under this threshold, and the 100cm point allows for a round number as the limit and offers some extra distance as a buffer to catch reasonable outliers.

\subsubsection{Microphone UI parameter conversion to values for calculation}

A key aspect of many stereophonic recording arrays is bilateral symmetry. Hence the focus on pairs of microphones and defining them in terms of their mutual distance and angular splay. Because of this, it can be assumed that for any of the paired microphones:

\begin{equation}
d_{\vec{mO}} = \frac{d_m}{2}
\end{equation}

Since the standard abstracted unit of measure in the virtual space is a meter, the distances for the center microphone and the main pair will need to be converted from the centimeter presentation to the user. Since every microphone only moves along one axis, and does not cross the origin, its position along the other axis will remain fixed at $0$. For the pairs of microphones, the symmetry at the $y$-axis means that the left microphone of each pair will remain in the span $d_L \leq 0$ whereas the right microphone in each pair will be within the span $d_R \geq 0$.

Thus, for the pairs of microphones:

\begin{equation}
\begin{bmatrix} x_L \\ x_R \end{bmatrix} = C0.5 \begin{bmatrix} -d_m \\ +d_m \end{bmatrix}
\end{equation}

Where $C$ is the unit conversion constant: $C_\text{mains} = 0.01$ and $C_\text{flanks} = 1$.

The value of $d_c$ can be directly converted into meters, and used as the $y$-coordinate value for the center microphone:

\begin{equation}
x_c = 0.01d_m
\end{equation}

For the angular splay values of the microphone pairs a similar conversion can be used. Since the angular splay value is the angle between the microphones, the deflection from forward can be found by halving the angular splay. Since perceptual forward is at an angular rotation of $\frac{\pi}{2}$, the left and right microphones' rotation values can be found by adding or subtracting the deflection value (converted to radians) from $\frac{\pi}{2}$:

\begin{equation}
\begin{bmatrix} \theta_L \\ \theta_R \end{bmatrix} = \frac{\phi\pi}{360}J_{2,1} + \begin{bmatrix} +\frac{\pi}{2} \\ -\frac{\pi}{2} \end{bmatrix}
\end{equation}

Where $\phi$ is the angular splay value in degrees and $J$ is a matrix of ones.


\section{Solving quadratic polynomials}


\chapter{The Stability of the FLUTE Electron Gun and Proposed Solution}
This chapter deals with the electron gun of \gls{flute} and its power supply. Then, based on fundamental equations of electron gun's microwave cavity, the dependence of the electron energy from the \gls{rf} supply is derived, which motivates why the \gls{rf} supply should be stable. Finally, a solution to stabilize the \gls{rf} is proposed.

The electron gun is powered by a \SI{50}{\MW} klystron, a high-power vacuum tube \gls{rf} amplifier. The input signal for the klystron is a $\SI{2.99855}{\GHz}\approx\SI{3}{\GHz}$ harmonic oscillator pre-amplified to \SI{200}{\watt}. The supply input is generated by a pulse forming network and a transformer. The pulse forming network mainly consists of capacitors to store electrical energy and is charged with a constant current source. The connection of these devices is shown in \autoref{fig:fluteEgun-rfschematic}.

A \SI{5}{\hertz} master clock (``trigger'') is used to switch on the output of the pulse forming network to the klystron and the oscillator every \SI{0.2}{\second} for \SI{4.5}{\micro\second}. During this time, the laser could also be triggered causing a stimulated emission of an electron bunch from the cathode. But even without the laser being active, powering the electron gun with the klystron generates an electron beam through thermionic emission of electrons. This undesired effect is called \textit{dark current}.

The current source to charge the pulse forming network is powered by mains voltage. This makes it susceptible to noise on the mains and also causes slowly time varying drifts of the klystron power due the pulse forming network being triggered at different relations to the mains \SI{50}{\hertz}. This issue has been remedied in \cite{Nasse2019} by adding synchronization to the mains phase.

\begin{figure}[tbh]
	\centering
	\includegraphics[]{chap/StabilityOfTheElectronGun/img/fluteSchem.tikz}
	\caption[FLUTE RF schematic]{Schematic of the \gls{flute} \gls{rf} system}
	\label{fig:fluteEgun-rfschematic}
\end{figure}

\section{The Electron Gun}
The electron gun of \gls{flute} was originally designed and operated in CTF II at \gls{cern}. \cite{Schuh2014}
It is of the ``BNL type'' (see \cite{Batchelor1988}, based on the original design by \cite{fraser1987}) and was  developed at \gls{cern}. \cite{Bossart:288412}

The gun is made up of a 2.5 cell microwave cavity with a removable copper cathode embedded in the cone shaped back at the end of the half cell (see \autoref{fig:fluteEgun-gunDraw}). Cooling is achieved with a two-stage water cooling system: A temperature control unit uses a short water circuit to cool the gun while itself uses a heat exchanger to a bigger outside climate unit.

Applying \gls{rf} power to the cavity through the hole-coupled wave guide causes a standing wave inside the cavity. Because of the cavity's dimensions, only the fundamental mode $\text{TM}_{010}$ is excited, for which the relation between resonance frequency $f_{010}$ and radius $a$ of the cavity is given by
\begin{equation}
\frac{f_{010}}{2\pi}=\frac{2.405 \cdot c}{a}.
\end{equation}
For the $\text{TM}_{010}$ mode there is only an electrical field in the $z$ direction, i.e. along the beam axis. This $E_z(z)$ field is used to accelerate the electrons. For the \gls{flute} gun, $E_z(z)$ has been measured in \cite{Bossart:clic}, see \autoref{fig:fluteEgun-Ezplot}. These measurements are also verified in \cite{Schuh2014}.

To tune the resonance frequency $f_{010}$, which depends on the cavity's radius $a$, to the target design frequency of \SI{2.99855}{\GHz}, two methods are used. The cavity is equipped with piston tuners that allow changing the geometries of each cell slightly. Because of the expansion and contraction of the copper body due to temperature changes, the set-point of the water cooling system can also be changed to alter the cavity geometry.

\begin{figure}[tbh]
	\centering
	\includegraphics[width=\textwidth,height=0.7\textwidth]{chap/StabilityOfTheElectronGun/img/Ez.tikz}
	\caption[Plot of the electric field $E_z(z)$ in the electron gun]{Plot of the electrical field in $z$ direction over the length of the gun cavity (redrawn from \cite{Bossart:clic} using geometrical measurements from \cite{Hoeninger2014})}
	\label{fig:fluteEgun-Ezplot}
\end{figure}

\begin{figure}[tbh]
	\centering
	\includegraphics[]{chap/StabilityOfTheElectronGun/img/gun.tikz}
	\caption[Cross-section of the electron gun]{Cross section drawing of the electron gun together with the solenoid (which is used for focusing the electron beam) showing the photo-cathode (red) and the electron and laser beam trajectories
	\\(modified version from \cite{Bossart:clic} and \cite{Bossart:288412})}
	\label{fig:fluteEgun-gunDraw}
\end{figure}

\section{Relation between RF power and Electron Energy}
A standing wave inside a \gls{rf} cavity for a $TM_{010}$ mode can be written as
\begin{equation}
E_z(z,t) = E(z)\,\cos(\omega t + \phi).
\end{equation}
The time $t$ has to be expressed in terms of the electron velocity $v(z)$ as
\begin{equation}
t=t(z)=\int_{0}^{z} \frac{\d{z}}{v(z)},
\end{equation}
which is the arrival time of the electron at location $z$.

If moving through an accelerating gap of length $L$ inside a cavity, an electron with charge $q$ gains the energy
\begin{equation}
\Delta W = q \int_{-L/2}^{L/2} E(z)\,\cos(\omega t(z) + \phi) \d{z}
\end{equation}

This can be rewritten as
\begin{equation}\label{eq:W}
\Delta W = q V_0 T \cos(\phi)
\end{equation}
using the axial \gls{rf} voltage
\begin{equation}
V_o := \int_{-L/2}^{L/2} E(z) \d{z}
\end{equation}
and the travel time factor $T$. \cite[p.~32]{Wangler2008}

With the \textit{shunt impedance} $R_s$, the axial \gls{rf} voltage can be brought into relation with the \gls{rf} power which needs to be induced into the cavity to compensate losses in the non-perfect conducting walls and power lost to the electron beam. \cite{burtRF}

The shunt impedance is defined as
\begin{equation}\label{eq:rs}
R_s = \frac{V^2_0}{P_{\text{RF}}}
\end{equation}

\autoref{eq:W} and \autoref{eq:rs} show that the \gls{rf} supply has a great impact on the electron energy, so it needs to be stable.

Additionally, there is the so called \textit{R over Q}, defined as
\begin{equation}
\frac{R}{Q} = \frac{(V_0T)^2}{\omega U}\qquad \text{with: }R=R_s T^2\;\text{(effective shunt impedance)}
\end{equation}
using the total stored electromagnetic energy $U$ and the quality factor $Q=\nicefrac{\omega U}{P_{\text{RF}}}$.

This shows the gained energy also depends on the properties of the cavity.

\section{Current RF Stability and Proposed Solution}
To get an overview of the current stability of the cavity \gls{rf} power, the deviation of the cavity power process value (\gls{epics}\footnote{See \autoref{sec:inputs}} \gls{pv} name F:RF:LLRF:01:GunCav1:Power:Out Value $=:P_\text{cavity}$) from its mean is plotted over one hour, see \autoref{fig:fluteEgun-deviation}.

\begin{figure}[tb]
	\centering
	\includegraphics[width=\textwidth,height=0.5\textwidth]{chap/StabilityOfTheElectronGun/img/assesment.tikz}
	\caption{Deviation of the cavity \gls{rf} power over the course of one hour}
	\label{fig:fluteEgun-deviation}
\end{figure}

\begin{figure}[tb]
	\centering
	\includegraphics[width=\textwidth,height=0.5\textwidth]{chap/StabilityOfTheElectronGun/img/periodo.tikz}
	\caption{Periodogram of \autoref{fig:fluteEgun-deviation}; calculated using the Welch method}
	\label{fig:fluteEgun-periodo}
\end{figure}

With the metrics defined in \autoref{sec:metrics}, over a time interval of $T=\SI{5}{\hour}$, the metrics $\op{\%STD}_{P_\text{cavity}}=\SI{0.15}{\percent}$, $\op{MSE}_{P_\text{cavity}}=38.54$ and $\op{MPN}_{P_\text{cavity}}=0.01677$ are calculated.

By utilizing simulation data and approximate analytical calculations, it is known that for \gls{thz} generation using the chicane at the end of the compressor (see \autoref{sec:intro}) and to generate chirped \gls{thz} pulses for \gls{cstart}, a stability of $\op{\%STD}_{P_\text{cavity}}=\SI{0.10}{\percent}$ would suffice. For time resolved \gls{thz} experiments, a higher stability of $\op{\%STD}_{P_\text{cavity}}=\SI{0.01}{\percent}$ is necessary. \cite{Nigel2021}

As this is a very demanding task, the goal at the moment is
\begin{equation}\label{eq:goalstd}
\op{\%STD}_{P_\text{cavity}} \overset{!}{\in} [\SI{0.01}{\percent},\,\SI{0.10}{\percent}].
\end{equation}

From the time plot in \autoref{fig:fluteEgun-deviation} and the periodogram in \autoref{fig:fluteEgun-periodo} it becomes clear that there is random white noise, but also a periodic part and a slow drift in the signal. While it is not possible to counteract the random fluctuations by any means of the control system developed in this thesis, it is possible to compensate for the slower disturbances that have effects over several pulses.

To get more insight into these slowly changing disturbances, the time signals of several available sensors in \gls{epics} are compared to the cavity \gls{rf} power. This shows similar trends in both the cavity \gls{rf} power $P_\text{cavity}$ and the electron gun temperature $\vartheta_\text{gun}$. To analyze them in more detail, the signals are both normalized to zero mean and unity standard deviation as they have different units and would be otherwise difficult to compare (see \autoref{fig:fluteEgun-corrTime}).

\begin{figure}[tb]
	\centering
	\includegraphics[width=\textwidth,height=0.5\textwidth]{chap/StabilityOfTheElectronGun/img/corrTime.tikz}
	\caption[Normalized cavity power and gun temperature]{Cavity \gls{rf} power and electron gun temperature in a normalized plot}
	\label{fig:fluteEgun-corrTime}
\end{figure}

To quantify their relation, the normalized cross covariance is used. It is calculated by using \autoref{eq:crosscovariance} with the normalized cavity \gls{rf} power and the normalized electron gun temperature and the result is shown in \autoref{fig:fluteEgun-corrCorr}. This shows the two signals are anti-similar ($\rho=r_\text{norm}(0)=-0.7$) for zero lag, i.e. no shift in time. This suggests a strong relation between them.

\begin{figure}[tb]
	\centering
	\includegraphics[width=\textwidth,height=0.5\textwidth]{chap/StabilityOfTheElectronGun/img/corrCorr.tikz}
	\caption[Cross covariance analysis of cavity power and gun temperature]{Normalized cross covariance of the signals in \autoref{fig:fluteEgun-corrTime}}
	\label{fig:fluteEgun-corrCorr}
\end{figure}

Hence in the next chapters, the control system is developed to counteract these noise components, especially the changes in the electron gun temperature.

To be autonomous from existing components, the control system should be made up with a controllable \gls{rf} attenuator added to the existing \gls{rf} system. This way there is no modification to the proprietary \gls{llrf}\footnote{The \gls{llrf} is visualized as only the oscillator in \autoref{fig:fluteEgun-rfschematicControl} and \autoref{fig:fluteEgun-rfschematic} but contains also its own feedback system and a vector modulator} necessary. With the addition of the control unit (see \autoref{fig:fluteEgun-rfschematicControl}), which is designed in later chapters and contains the controller $G(s)$ and the filter $H(s)$, a closed-loop for feedback control is formed.

\begin{figure}[tb]
	\centering
	\includegraphics[]{chap/StabilityOfTheElectronGun/img/fluteSchemControlUnit.tikz}
	\caption[FLUTE RF schematic with control unit]{Schematic of the \gls{flute} \gls{rf} system with the proposed control unit and the controllable \gls{rf} attenuator added}
	\label{fig:fluteEgun-rfschematicControl}
\end{figure}


\documentclass{article}
\usepackage[francais]{babel}
\usepackage[utf8]{inputenc}
\usepackage[T1]{fontenc}
\usepackage{tipa}
\usepackage{amsmath, amssymb}
\usepackage{hyperref}

\setlength\parindent{0in}
\setlength\topmargin{-0.25in}
\setlength\headheight{0in}
\setlength\headsep{0in}
\setlength\topskip{0.5in}
\setlength\textheight{9.75in}
\setlength\textwidth{6.50in}
\setlength\oddsidemargin{0in}
\setlength\evensidemargin{0in}

\title{HARMOTRON}
\author{F}
\date{\today}

\begin{document}

\section{Concept}
The Harmotron is an idea for a dual control synthesizer. One of the controls
will be the pitch of the tone generator (a harmonic rich sound) while the other
will control the bandpass frequencies. This way, the user will be able play
on both the main note (background) and the isolated frequencies for harmonic
effect.

\subsection{todo}
\begin{description}
\item continue to test effect of a specific bandpass fc on static signals
\item find appropriate serie with shiftable parameter (like exponent exp<->log)
\item generate sines on user input (midi input???).
\item generate appropriate filter on user input.
\item implement adsr
\end{description}

\section{Source synthesis}
The source will be synthesized by adding sinusoids that are integer multiples of
the fundamental frequency (user input).

Each harmonic will have an amplitude equal to its term in a serie determined
by user input (harmonic, geometric, or something like that).

\subsection{Formulaes and results}
The following synthesis formulaes have been used and tested:
\begin{description}
\item 1)$synth(f, t) = \sum\limits_{n=1}^N a^n cos(2 \pi f t n /F_s)$
\item 2)$synth(f, t) = \sum\limits_{n=1}^N a^n cos(2 \pi f t n /F_s)
                     + \sum\limits_{n=1}^N a^n cos(2 \pi f t n /F_s * \frac{3}{2})
                     + \sum\limits_{n=1}^N a^n cos(2 \pi f t n /F_s * 3)$
\end{description}

It could be interesting to generate different type of spacing for the harmonics.
Different series of ratios of other enharmonic (or is it xenharmonic?) ideas.

\section{filtering}
The filter will be a bandpass (maybe morphing to a comb filter centered on $F_c$).
$F_c$ will be dynamically determined by user input.

\subsection{reflexions on filtering}
After a few initial tests, the concept works but needs refining. Some amplitudes
were too low, others were a bit dissonant. The present hypothesis is that the
filter frequency $F_c$ does not perfectly align with all harmonics, causing loss
of amplitude and dissonances from letting pass untargeted frequencies in a
greater ratio.

As it is, a single harmonic may be passed at a time. By using parrallel filters,
it would be possible to play simultaneous harmonics by computing them all and
controlling their amplitudes by user input (i.e. on/off from keyboard input).

\section{envelope}
\subsection{initial gain}
Since the signal is the result of coefficients of a geometric series multiplied
by the amplitude of the \texttt{cos} function, it can be multiplied by its
inverse to reduce peaking. The total sum of a geometric series is known to be
$\sum\limits_{n=1}^N a^n = \frac{1}{1 - a}$ if $\left|a\right| < 1$. It's
iverse is $1 - a$. We estimate the energy of the \texttt{cos} function by
taking $\int_{\frac{-\pi}{2}}^{\frac{\pi}{2}} \! cos(x)\, \mathrm{d}x = 2$ and
its inverse is of course $\frac{1}{2}$. Since int the case of the second
synthesis formula, the series is applied three times,it seems wise to divide
the gain by 3.

So the initial gain will be $\frac{1-a}{6}$

\end{document}


\section{Measuring pooling bias}
\label{sec:analysis}
%(1 pages)

% Primer
The example in \figureref{pooling} makes it apparent that pooling-based evaluation can introduce a systematic bias against unpooled systems.
However, it has been assumed that the bias is insignificant in practice given the large number of systems pooled in the TAC KBP evaluation.
We will now show that the assumption is not valid using data from the TAC KBP 2015 evaluation.\footnote{%
Our results are not qualitatively different on data from previous years of the shared task.}

% Data and methodology
\begin{figure}[t]
  \centering
  \begin{subfigure}{\columnwidth}
      \includegraphics[width=\columnwidth]{figures/pooling_bias/pooling_bias}
    \centering
    \small{\begin{tabular} {l r r r} \toprule
                    & \multicolumn{3}{c}{Median bias} \\
                    & Precision & Recall & Macro \fone{} \\ \midrule
   Official         & 17.93\% &  17.00\% & 15.51\% \\
   \anydoc{}        & 2.34\% &  1.93\% & 2.05\% \\ \bottomrule
   \end{tabular}}
  \end{subfigure}
  \caption{\label{fig:pooling-bias} Median pooling bias (difference between pooled and unpooled scores) on the top 40 systems of TAC KBP 2015 evaluation using the official and \anydoc{} scores.
  The bias is much smaller for the lenient \anydoc{} metric, but even so, it is larger than the largest difference between adjacent systems (1.5\% \fone{}) and typical system improvements (around 1\% \fone{}).
%  the assumption that pooling bias is insignificant is false.
  }
\end{figure}
\paragraph{Measuring bias.}
In total, there are 70 system submissions from 18 teams for 317 evaluation entities ($E$) and the evaluation set consists of 11,008 labeled relation instances.\footnote{%
  The evaluation set is actually constructed from compositional queries like, ``what does Carrie Fisher's parents do?'':
  these queries select relation instances that answer the question ``who are Carrie Fisher's parents?'', and then use those answers (e.g.\ ``Debbie Reynolds'') to select relation instances that answer ``what does Debbie Reynolds do?''.
  We only consider instances selected in the first part of this process.
}
The original evaluation dataset gives us a good measure of the true scores for the participating systems.
Similar to \citet{zobel1998reliable}, which studied pooling bias in information retrieval,
we simulate the condition of a team not being part of the pooling process by removing any predictions that are unique to its systems from the evaluation dataset.
The pooling bias is then the difference between the true and unpooled scores.

\paragraph{Results.}
\reffig{pooling-bias} shows the results of measuring pooling bias on the TAC KBP 2015 evaluation on the \fone{} metric using the official and \anydoc{} scores.\footnote{%
  We note that \anydoc{} scores are on average 0.88\%\fone{} larger than the official scores.
  }\footnote{
  The outlier at rank 36 corresponds to a University of Texas, Austin system that only filtered predictions from other systems and hence has no unique predictions itself.
  }
We observe that even with lenient \anydoc{} heuristic, the median bias (2.05\% \fone{}) is much larger than largest difference between adjacently ranked systems (1.5\% \fone{}).
This experiment shows that pooling evaluation is significantly and systematically biased against systems that make novel predictions!

%  We also considered an alternate scoring model where relation instances outside the evaluation set were of ignored instead of marked wrong and find that under this model \fone{} scores remain biased by 14.99\% and 0.73\% points on average, with and without the \anydoc{} heuristic respectively.
%% TODO:  \ap{elaborate methodology}
%While this scoring model is less biased than assuming unassessed relation instances to be wrong, combined with the discrepancy of the \anydoc{} score it remains too large a difference to be ignored.
%The analysis confirms the necessity of the \anydoc{} heuristic during development evaluations,
%  but at the same time, even with the heuristic, the bias is much larger than the typical system difference.
%Thus, we conclude that this evaluation is biased against improvements that lead to novel predictions!

% OLD as of 4/9/17
% % TODO: Need to state explicitly this is for entity scores.
%
% The closed-world assumption is well understood to provide pessimistic estimates of system performance \pl{based on what?}, but its bias has not been measured before.
% The prevailing intuition is that the evaluation set probably covers most of the correct relations because only instances pertaining to a very specific set of relations are evaluated.
% %In this section, we will describe what kinds of predictions are falsely marked negative by the closed world heuristic, how the resulting bias can be measured and finally present results regarding the bias in the context of TAC KBP.
% In this section, we will describe how the resulting bias can be measured and discuss results regarding the bias in the context of TAC KBP.\@
%
% %\paragraph{False negatives.}
% %% What are the different ways that systems predict new facts?
% %Let's assume that our evaluation set contains only the relation instance shown in \figureref{example}, which identifies Debbie Reynolds as a parent of Carrie Fisher.
% %There are few ways that the closed world assumption can falsely predict a relation instance to be wrong.
% %First, the instance may state known information but from a different place, e.g.\ from the sentence
% %  ``\textit{Carrie Frances Fisher} was born \ldots to actors and singers Eddie Fisher and \textit{Debbie Reynolds}.''
% %% TODO: "object string" is clunky.
% %Secondly, a relation instance may state known information but use a different string for the object, e.g.\ a system might use ``Mary Frances Reynolds'' instead of ``Debbie Reynolds'', which is a nickname.
% %Finally, a relation instance may express an entirely new relation, e.g.\ that ``Eddie Fisher'' is Carrie's father.
% %In all the above cases, the closed world assumption considers the instance to be wrong.
% %With the \anydoc{} heuristic, the first instance is correctly marked, but this heuristic also incorrectly marks the instance, ``Bright Lights: Starring Carrie Fisher and Debbie Reynolds'' as being true.
% %Consequently,
% %  while the closed world assumption is a strict underestimate of performance, the \anydoc{} heuristic is not guaranteed to be.
%
% % Remind closed world assumption.
% % How do we measure the effects of CWA on development?
% % Ideally, we would like to measure the performance of development runs and see ifthere are potentially useful contributoins that could have been used had it not been for the evaluation.
% % We can't do that, but we can compare how teams that participated in the evaluation might have fared had they not been part of the evaluation.
% % To do so, we use the SVT data...
% % For each submission, we compare its scores with the hypothetical scores of how the system would have done the team had not participated in the construction of the evaluation data.
% % describe results
% % describe consequences.
%
% \pl{think of a simple figure / example to show the bias;
% this is an important point and a simple concept;
% I bet that there's a figure that someone could look at for 5 seconds and understand
% }
%
% \paragraph{Measuring bias.}
% \begin{figure*}[t]
%   \begin{subfigure}{\columnwidth}
%   \includegraphics[width=\columnwidth]{figures/pooling_bias/pooling_bias_closed-world}
%   \caption{Pooling bias for macro \fone{} scores without the \anydoc{} heuristic.}
%   \end{subfigure}
%   \begin{subfigure}{\columnwidth}
%   \includegraphics[width=\columnwidth]{figures/pooling_bias/pooling_bias_anydoc}
%   \caption{Pooling bias for macro \fone{} scores with the \anydoc{} heuristic.}
%   \end{subfigure}
%   \caption{\label{fig:pooling-bias} Pooling bias measures how much a system's score is affected by not having its output as part of the pooled evaluation.
%   The median bias on the top 40 teams against an unpooled team is 15.51\% points for the standard macro \fone{} metric and 1.98\% when evaluating using the \anydoc{} heuristic.
%   Note that the median difference between the \anydoc{} scores and standard scores is 0.74\% points; this difference is caused because the \anydoc{} heuristic erroneously scores fills with incorrect judgements to be correct.}
% \end{figure*}
%
% Ideally, we would like to measure the difference between performance scores of development systems on the evaluation set and a hypothetical set that includes evaluations of all its relations.
% This difference is often called the ``pooling bias'' in information retrieval literature~\citep{}. % TODO: cite weber and many others.
% As a proxy to development systems, we will make use of system submissions to the TAC KBP 2015 competition, made available through the TAC KBP Slot Validation Tracks~\citep{}.
% There are 70 submissions from 18 teams for 317 queries and the evaluation set consists of 11,008 assessed relation instances.\footnote{%
%   The evaluation set is actually constructed from compositional queries like, ``what does Carrie Fisher's parents do?'':
%   these queries select relation instances that answer the question ``who are Carrie Fisher's parents?'', and then use those answers (e.g.\ ``Debbie Reynolds'') to select relation instances that answer ``what does Debbie Reynolds do?''.
%   We only consider instances selected in the first part of this process.
% }
% Adopting the methodology of \citet{weber2010measurement},
% we construct a hypothetical evaluation set for each submission to simulate what the evaluation set would look like if the corresponding team did not submit its results.
% This hypothetical evaluation set contains only those relations that were predicted by at least one other system or the human annotators.
% We then measure the difference between performance scores on the original evaluation set and on the hypothetical evaluation set with and without the \anydoc{} heuristic.
%
% \paragraph{Results.}
% \figureref{pooling-bias} summarizes our results on pooling bias for the macro \fone{} metric.
% The effect of bias is truncated on systems that performed very poorly.
% Consequently, we report median results on the top 40 systems (which corresponding to a sharp drop in performance).
% The outlier in the graph at rank 36 corresponds to a submission from University of Texas, Austin that only filtered outputs from other systems: this submission does not suffer any pooling bias because all of its outputs are included in the hypothetical evaluation set.
%
% Without the \anydoc{} heuristic, pooling bias is 15.51\% \fone{} points and with the heuristic it is 1.98\% \fone{} points.
% We note that the \anydoc{} heuristic overestimates scores by about 0.74\% \fone{} points.
% The bias affects precision and recall almost equally:
%   the median bias the without \anydoc{} heuristic being 17.93\% and 17.0\% respectively, and
%   the median bias the with \anydoc{} heuristic being 2.34\% and 1.93\% respectively.
% We also consider the alternate heuristic of ignoring relation instances outside the evaluation set and find that that biases \fone{} scores upwards by \fake{3\%}.
% At the same time, the median difference between two adjacent submissions is only 0.3\%\fone{} with largest difference being 1.5\% \fone{} (between the 26th and 27th ranked submissions).
% This analysis confirms the necessity of the \anydoc{} heuristic during development evaluations,
%   but at the same time, even with the heuristic, the bias is much larger than the typical system difference.
% Thus, we conclude that this evaluation is biased against novel system improvements!
%
% %  the median bias against an unpooled team is 13.55\% \fone{} points and for an unpooled system is 4.55\% \fone{} points,
% %  making it impossible to evaluate against this metric in development (also significantly biasing new entrants to the task).
% %The former is a proxy that measures how much bias development systems of teams that had participated in the KBP evaluation experience and the latter measures the bias development systems of new teams experience.
% %\figureref{pooling-bias} shows the pooling bias experienced by teams and systems in the 2015 evaluation;
% %  the median bias against an unpooled team is 13.55\% \fone{} points and for an unpooled system is 4.55\% \fone{} points,
% %  making it impossible to evaluate against this metric in development (also significantly biasing new entrants to the task).
% %
%
% % We will make use of system submissions released as part of the TAC KBP Slot Validation tracks in 2013, 2014 and 2015.
% % The 2015 dataset contains 70 submissions from 18 teams for 317 queries.
% % Considering only the submissions to the first hop of the two-hop \pl{to non-KBP person, don't know what this means} evaluation,
% % each submission contains on average about 35,951 predicted slotfills.
% % There are in total 201,332 relations that were predicted, of which only 11,008 of these slotfills have were evaluated.
%
% %  each submission predicts on average
% %We will make use of system submissions released as part of the TAC KBP Slot Validation tracks in 2013, 2014 and 2015.
% %The 2015 dataset contains 70 submissions from 18 teams for 317 queries.
% %Considering only the submissions to the first hop of the two-hop \pl{to non-KBP person, don't know what this means} evaluation,
% %each submission contains on average about 35,951 predicted slotfills.
% %There are in total 201,332 relations that were predicted, of which only 11,008 of these slotfills have were evaluated.
% %
% %The ``gold'' labels on relation contexts are collected by a combination of a time-bounded human search in the corpus and a human evaluation of pooled output from participating systems.
% %While the human search identifies a significant fraction of relations (\todo{80\%}),
% %  it does not sufficiently cover the variety of contexts that are submitted as justifications of the relation.
% %This has two implications on how a development system, \textit{D}, that did not participate in the original evaluation is scored.
% %Firstly, it is likely that contexts \pl{I thought the problem with bias was due to the set of relations $D$ returns, not contexts} the system \textit{D} submits has never been seen before and hence can not be evaluated.
% %Secondly, it is also likely that relations the system \textit{D} submits have never been seen before, particularly if \textit{D} incorporates a novel method of relation extraction, creating a perverse incentive to ensure that new extraction methods behave similarly to old extraction systems.
% %The magnitude of this effect, the pooling bias, is can be quantified by performing a ``leave-one-out'' (``leave-team-out'') experiment on previous years submissions, measuring the difference in metric scores when output unique to a single submission (team) is excluded from the gold data.
% %The former is a proxy that measures how much bias development systems of teams that had participated in the KBP evaluation experience and the latter measures the bias development systems of new teams experience.
% %\figureref{pooling-bias} shows the pooling bias experienced by teams and systems in the 2015 evaluation;
% %  the median bias against an unpooled team is 13.55\% \fone{} points and for an unpooled system is 4.55\% \fone{} points,
% %  making it impossible to evaluate against this metric in development (also significantly biasing new entrants to the task).
% %
% %To mitigate this unreasonable bias, teams typically adopt an `anydoc' heuristic during evaluation, which ignores the justification of a context while evaluating a relation.
% %\pl{hard for me to get intuition for implications of anydoc}
% %With this heuristic (\figureref{pooling-bias-anydoc}), the pooling bias decreases considerably, with
% %  the median bias against an unpooled team being 1.98\% \fone{} points and unpooled system is 0.0\% \fone{} points.
% %However, it should also be noted that scores under the `anydoc' heuristics are on average 0.74\% higher than the standard scores due to erroneously labeling entries to be correct.
% %This analysis confirms the necessity of the `anydoc' heuristic on the current evaluations, but regardless, the bias is large enough to wash out the effect of the typical improvement a development makes.
% % TAKEAWAY: new entrants are biased against!
%
% % In the latter sections of this paper, we eliminate the problem of pooling evaluation all together by proposing an online evaluation methodology where every new submission is considered and selectively evaluated to ensure statistical validity.
%
% % \paragraph{Evaluating performance across years.}
% % \fake{This analysis is incomplete, so omitting for your convenience!}
% % % NOTE: should we describe any more statistics?
% % \paragraph{How informative is \fone{} as a metric?}
% % \ac{Ignore for now!}
% % \begin{figure*}
% %   \begin{subfigure}{0.49\textwidth}
% %   \includegraphics[width=\columnwidth]{figures/experiment1}
% %   \caption{\label{fig:f1}}
% %   \end{subfigure}
% %   \begin{subfigure}{0.49\textwidth}
% %   \includegraphics[width=\columnwidth]{figures/experiment3}
% %   \caption{\label{fig:sf1}}
% %   \end{subfigure}
% %   \caption{}
% % \end{figure*}
% %
% % \begin{table*}
% %   \begin{tabular} {l r r r r r} \toprule
% %     Metric & \multicolumn{3}{c}{Normal} & \multicolumn{2}{c}{Standardized} \\
% %            & Average value & 95\% confidence interval & Mean difference between top 10 teams &  Average value & 95\% confidence interval  \\  \midrule
% % Micro $P^e$     & $30.91\%$ &  $16.77\%$ & 0.12\% &     &  \\
% % Micro $R^e$     & $30.45\%$ &  $ 6.41\%$ & 0.17\% &     &  \\
% % Micro $\fone^e$ & $38.62\%$ &  $ 6.79\%$ & 0.24\% &     &  \\
% % Macro $P^e$     & $24.98\%$ &  $ 6.93\%$ & 0.24\% &     &  \\
% % Macro $R^e$     & $03.56\%$ &  $ 6.87\%$ & 0.23\% &     &  \\
% % Macro $\fone^e$ & $22.72\%$ &  $ 6.19\%$ & 1.04\% &     &  \\ \bottomrule
% %   \end{tabular}
% %
% % \begin{tabular}{l r r r r r} \toprule
% %   Metric ($\sigma^2$) & System variance ($\sigma^2_{s}) $ & Query variance($\sigma_{e}$) & Residual ($\sigma_{s,e})$ \\ \midrule % & $\psi$  & $\rho$ \\
% %   \fone{} (0.102) & 11.75\% & 20.59\% & 66.66\% \\ \bottomrule % &     0.120 & 0.152
% % \end{tabular}
% %   \caption{\label{metric-variance}}
% % \end{table*}
% %
% % Most teams hill climb on a combination of micro and macro entity-level $\fone$ during development.
% % It is natural to ask how much of an improvement on the metric score is necessary to actually trust that system performance has improved.
% % We use a bootstrap sampling \pl{what exactly is being resampled?} method to estimate the variance of $\fone$ and other metrics over query sets \tableref{metric-variance} and measure the 95\% confidence intervals for system scores \figureref{f1}.
% % The median difference in metric scores between adjacent submissions in the top 10 scores (for that metric) is between 0.1--1\%,
% % while the confidence intervals are at least 6\%.
% % % TODO: we can use the differences between the submissions of the each team.
% % It is hard for the researcher to identify if any of the presumably distinct submissions hold any water of another. \pl{awkward}
% %
% % Next, we would like to ask what factors contribute to the large variance in the system metrics above.
% % One natural confounding variable is the substantial variability in the difficulty of query entities.
% % We can measure the effect of the query entity by analyzing the variation in topic-model scores.
% % Consider the linear model, \pl{$\mu$'s don't cancel out}
% % \begin{align*}
% %   X_{s,e} &= \mu
% %     + \underbrace{\mu_{s} - \mu}_{\nu_{s}}
% %     + \underbrace{\mu_{e} - \mu}_{\nu_{e}}
% %     + \underbrace{X_{s,e} - \nu_{s} - \nu_{e} - \mu}_{\nu_{s,e}},
% % \end{align*}
% % where $\nu_{s}$, $\nu_{e}$ and $\nu_{s,e}$ capture the effect of the system $s$ and query entity $e$, and the residual.
% % Variance can also be decomposed as,
% % \begin{align*}
% %   \sigma^2(X_{s,e}) &= \sigma^2(\nu_s) + \sigma^2(\nu_e) + \sigma^2(\nu_{s,e}).
% % \end{align*}
% %
% % \tableref{} shows the variance explained by different components for macro metrics. As we can see, almost twice as much of the variance is explained by the entity only as that of the system.
% % \pl{this is true of any task in general, right, not just KBP?  easy examples everyone gets,
% % hard examples, some people get?}
% % % Explain what the high q,e scores mean.
% % %Another consequence is in confidence intervals.
% % %Bad differentiation from pairwise scores.
% %
% % % TODO: replace with a GLMM
% %
% % \paragraph{Controlling for query variance.}
% % \ac{Ignore for now!}
% %
% % It's easy for us to control for query variance by standardizing our metric,
% % $$X'_{se} = \frac{X_{se} - \mu_e}{\sigma_e}$$.
% %
% % \figureref{sf1} plots the performance of systems under the standardized macro \fone metric.
% % % TODO: variance under standardized metric -- showing less contribution
% % % due to queries and an overall reduction in variance.
% % % NOTE: This is only useful when comparing systems, as one is wont to do during development.
% %
% % % TODO: I wish we could give scroes for this.
% % % \subsection{Are we improving over time?}
% %


    \filetitle{subsref}{Subscripted reference function for tseries objects}{tseries/subsref}

	\paragraph{Syntax returning numeric
array}\label{syntax-returning-numeric-array}

\begin{verbatim}
... = X(Dates)
... = X(Dates,...)
\end{verbatim}

\paragraph{Syntax returning tseries
object}\label{syntax-returning-tseries-object}

\begin{verbatim}
... = X{Dates}
... = X{Dates,...}
\end{verbatim}

\paragraph{Input arguments}\label{input-arguments}

\begin{itemize}
\item
  \texttt{X} {[} tseries {]} - Tseries object.
\item
  \texttt{Dates} {[} numeric {]} - Dates for which the time series
  observations will be returned, either as a numeric array or as another
  tseries object.
\end{itemize}

\paragraph{Description}\label{description}

\paragraph{Example}\label{example}


\chapter{The Fourier transform}


\section{Predicate  Parser}

\todo{predicate parsing stuff}
  \begin{bluetext}
    a : a x | b (x can be anything)
    =>
    a : b r
    r : x r | e
    -----------------------
    exp : exp op exp | prim
    =>
    exp : prim expR
    expR : op exp expR | e
  \end{bluetext}