Mercurial > hg > soundsoftware-icassp-2012
changeset 6:2d5128ba821e
Begin a bit of restructuring
author | Chris Cannam |
---|---|
date | Thu, 22 Sep 2011 09:47:41 +0100 |
parents | 36cdea858960 |
children | ba4e684e5a41 |
files | cannam.tex |
diffstat | 1 files changed, 49 insertions(+), 33 deletions(-) [+] |
line wrap: on
line diff
--- a/cannam.tex Wed Sep 21 17:39:35 2011 +0100 +++ b/cannam.tex Thu Sep 22 09:47:41 2011 +0100 @@ -46,50 +46,33 @@ \section{Introduction} \label{sec:intro} -\section{Background} -\label{sec:background} - -\subsection{Software in audio and music research} -\label{subsec:researchsoft} - It is widely understood in the audio and music research area that much research will involve both the development of new software, and evaluation of new methods against prior publications that also involved the use of software. -This presents two areas of difficulty. First, researchers in the UK -audio and music research community come from a wide range of +This presents two areas of difficulty. First, researchers in the +audio and music research community --- including within the group +represented by the present authors, the Centre for Digital Music at +Queen Mary University of London --- come from a wide range of backgrounds including signal processing, electronics, computer science, music, information sciences, dance and performance, and data -sonification. In many of the fields within this community, researchers -do not have the skills or desire to write their own code or to piece -together other code, but benefit greatly from ``out of the box'' -software. Even where they do write their own code, they work on -different platforms and use a wide variety of batch and real-time -environments. Our survey found MATLAB, C++, Max/MSP, OpenFrameworks, -Juce, HTK and MPTK, numerous MATLAB toolboxes, SuperCollider, Clojure -and R amongst environments and toolkits used \cite{ssamrsurvey}. +sonification. In many of these fields, researchers do not have the +skills or desire to become involved in traditional software +development practice or in publication of code. Second, there are many technical and logistical reasons why software developed during earlier research is no longer available for -evaluation and subsequent development. For example, in the well-known -subject of beat tracking, Scheirer et al \cite{scheirer} was developed -in C++ for a legacy platform and is now only available informally; -Goto et al \cite{goto} was written for a now-defunct parallel -architecture and never released; Hainsworth \cite{hainsworth} was -written in MATLAB with a non-portable DLL component and only runs on a -single platform; Klapuri et al \cite{klapuri} was written in MATLAB -with a platform-specific extension and is not widely distributed for -reasons of commercial confidentiality; and methods from Cemgil, -Laroche, Alonso, and Peeters have not been published as code. +evaluation and subsequent development even if it has been published, +including platform incompatibilities and obsolescence, or legal +limitations on distribution or reuse. -``A recent study found that the majority of scientists use desktop -computers most of the time for developing and using scientific -software. Further, they found that there was a great deal of variation -in the level of understanding of standard software engineering -concepts by scientists, and that for developing and using scientific -software, informal self-study or learning from peers was commonplace'' -\cite{gwilson2009} +In this paper we discuss some of these practical constraints on +application of reproducible research principles for software code, and +propose an incremental approach toward better practice. + +\section{Background} +\label{sec:background} \subsection{Reproducible Research} \label{subsec:rr} @@ -118,6 +101,39 @@ can also give comments about a publication and evaluate the reproducibility of the work. +\subsection{Real-world limitations on software practice} +\label{subsec:researchsoft} + + ``A recent study found that the majority of scientists use desktop + computers most of the time for developing and using scientific + software. Further, they found that there was a great deal of variation +@@ -90,6 +82,7 @@ + concepts by scientists, and that for developing and using scientific + software, informal self-study or learning from peers was commonplace'' + \cite{gwilson2009} + + +In many of the +fields within this community, researchers do not have the skills or +desire to write their own code or to piece together other code, but +benefit greatly from ``out of the box'' software. Even where they do +write their own code, they work on different platforms and use a wide +variety of batch and real-time environments. Our survey found MATLAB, +C++, Max/MSP, OpenFrameworks, Juce, HTK and MPTK, numerous MATLAB +toolboxes, SuperCollider, Clojure and R amongst environments and +toolkits used \cite{ssamrsurvey}. + + For example, in the well-known +subject of beat tracking, Scheirer et al \cite{scheirer} was developed +in C++ for a legacy platform and is now only available informally; +Goto et al \cite{goto} was written for a now-defunct parallel +architecture and never released; Hainsworth \cite{hainsworth} was +written in MATLAB with a non-portable DLL component and only runs on a +single platform; Klapuri et al \cite{klapuri} was written in MATLAB +with a platform-specific extension and is not widely distributed for +reasons of commercial confidentiality; and methods from Cemgil, +Laroche, Alonso, and Peeters have not been published as code. + \subsection{Current practice in the field} \label{subsec:current}