changeset 47:69bd20e39aab

Work on plugins, future work etc

--- a/cannam.tex	Mon Sep 26 12:58:58 2011 +0100
+++ b/cannam.tex	Mon Sep 26 14:10:56 2011 +0100
@@ -103,7 +103,7 @@
 Magazine~\cite{vandewalle2009} and Computing in Science and
 Engineering [citation needed] on this subject both appeared in
 2009. The IEEE Signal Processing society now encourages Reproducible
-Research, allowing links from the online journal repository IEEEXplore
+Research, allowing links from the online journal repository IEEE Xplore
 to the code and data associated with a publication (TODO: check this).
 
 Actions such as these promote the idea that research results in signal
@@ -343,24 +343,26 @@
 \subsubsection{User interfaces for version control}
 \label{sec:easyhg}
 
-Attendees at the Autumn School also reported difficulty during the
+Attendees at our Autumn School also reported difficulty during the
 course in getting started with the complex user interfaces available
 for version control.  Nonetheless, version control was amongst the
-areas identified subsequently as most valuable, suggesting that lack
-of awareness may be the main barrier to uptake.
+areas identified subsequently as most valuable.
 
-Our attempt to address the difficulties faced in learning version
-control user interfaces is EasyMercurial,\footnote{\tt
-  http://easyhg.org} an application we developed based on existing
-work [citation needed] in order to provide a user interface that we
-could teach easily to researchers across multiple operating system
-platforms.
+To address some of the difficulties faced in learning version control
+we have developed EasyMercurial,\footnote{\tt http://easyhg.org} an
+application designed to be easy to teach to researchers across
+multiple operating system platforms.  This application uses a visual
+graph representation for change history, showing explicitly the flow
+of simultaneous changes by different users and of merge points.
+EasyMercurial behaves identically on each supported platform (Windows,
+OS/X and Linux) in order to simplify training for researchers with
+disparate platforms.
 
 \subsection{Barrier to reuse: Lack of incentive for publication}
 \label{sec:lackofincentives}
 
 In section \ref{sec:researchsoft} we noted that software and data are
-not typically recognised as assessable research outputs.  Software
+typically not recognised as assessable research outputs.  Software
 also lacks the publication convention for describing authorship
 hierarchy, making it unclear how an academic should be recognised for
 their contribution to a collaborative software work.
@@ -373,42 +375,41 @@
 publications, increasing the citation impact of the work.
 
 \subsection{Barrier to reuse: Platform incompatibilities}
-\label{sec:platforms}
+\label{sec:plugins}
 
-We observed in \ref{sec:researchsoft} that researchers in this field
-choose to use many platforms and programming languages to carry out
-their work.  Although the most common (MATLAB) is widely available in
+We observed in section \ref{sec:researchsoft} that researchers in this
+field choose to use many platforms and programming languages to carry
+out their work.  Although the most common (MATLAB) is used in many
 signal processing groups, it is a commercial platform that is not
 widely used in other fields related to audio and music such as
 computational musicology or music therapy.
 
-\subsubsection{Plugins}
-\label{sec:plugins}
-One method of giving code a better chance to survive may be to produce
-a ``plugin'' that can be used in applications that researchers in
-related fields might already be using.  This permits a working
-algorithm to be converted directly to a unit of code which can be used
-in real applications, without the need to develop a custom interface.
-A published interface supported by more than one host program ensures
-that the published code is not dependent on the continued distribution
-of a single application.  Code that uses the plugin format of a
-successful application is relatively likely to be understood by other
-developers.
+To promote software reuse outside of the immediate signal processing
+community, the C4DM has adopted a ``plugin'' approach.  Writing a
+plugin allows a working algorithm to be converted directly to a unit
+of code which can be used in real applications, without the need to
+develop a custom user interface.  Developing to a published
+specification supported by more than one host program increases the
+relevance of the code and therefore the likelihood of its being
+maintained.  Code that uses the plugin format of a successful
+application is relatively likely to be understood by other developers.
 
-At C4DM we have had some success with plugins in standard audio
-processing formats such as VST, as well as in writing externals for
-modular systems such as Max/MSP or SuperCollider.  For audio analysis
-methods, in 2006 we developed the Vamp plugin system \cite{vamp} and
-implemented it using \CC{} in our applications Sonic
-Visualiser~\cite{cannam2006} and the subsequent Sonic
-Annotator~\cite{cannam2010}.  This system has also been used by the
-Centre and others with some success for publishing working methods.
-In section~\ref{sec:casestudies} we discuss some examples.
+At C4DM we have had success with plugins in standard audio processing
+formats such as VST\footnote{\scriptsize\tt
+  http://en.wikipedia.org/wiki/Virtual\_Studio\_Technology} as well as
+in writing externals for modular systems such as Max/MSP or
+SuperCollider.  For audio analysis methods, in 2006 we developed the
+Vamp plugin system \cite{vamp} and implemented it using \CC{} in our
+visualisation software Sonic Visualiser~\cite{cannam2006}, a
+widely-used application that has seen over 200,000 downloads to date,
+and in the subsequent Sonic Annotator~\cite{cannam2010} batch feature
+extractor.  The Vamp system has subsequently been used by C4DM and
+others with some success for publishing working methods.
 
 \section{Case study}
 \label{sec:casestudy}
 
-\subsection{Chordino audio chord recogniser}
+\subsection{Chordino automatic chord transcription}
 \label{sec:chordino}
 
 Mauch describes in~\cite{mauch2010} a method for improving automatic
@@ -419,10 +420,10 @@
 through the submission of a MATLAB implementation of the method to the
 annual MIREX evaluation exchange~\cite{mirex}.
 
-Following this publication, the author worked with us to develop a C++
+Following this publication, the author worked with us to develop a \CC{}
 implementation of the method and turn it into a Vamp plugin for chord
 estimation, named Chordino.  This code and its revision history are
-available through our code site\footnote{\tt
+available through our code site\footnote{\scriptsize\tt
   http://code.soundsoftware.ac.uk/projects/nnls-chroma} and thereby
 linked with the associated publication.  Although the code has been
 updated since release, the plugin includes a mode in which it uses the
@@ -439,13 +440,13 @@
 straightforward to carry out.
 
 {\bf Tackle easy training targets.} In
-section~\ref{sec:lackofeducation} we observe that training considered
-very basic in the context of software engineering, such as an
-introduction to program structure across multiple source files and
-functions, may yield tangible rewards to researchers who are
-technically minded but lack software development experience.  To
-this end, we encourage researchers to make use of the video material
-from our Autumn School\footnote{\tt
+section~\ref{sec:lackofeducation} we observe that training which may
+be considered simplistic in the context of software engineering, such
+as an introduction to program structure across multiple source files
+and functions, may yield tangible rewards to researchers who are
+technically minded but lack software development experience and fear
+writing code.  We encourage researchers to make use of the video
+material from our Autumn School\footnote{\tt
   http://soundsoftware.ac.uk/autumnschool2010video} and the related
 Software Carpentry course material.\footnote{\tt
   http://software-carpentry.org/}
@@ -461,40 +462,43 @@
 application (section~\ref{sec:easyhg}) is designed to be an effective
 teaching tool in this respect.
 
-{\bf Produce plugins} and deliberately target end-user applications
+{\bf Turn code into plugins} and seek other ways in which your
+code can be used in conjunction with end-user applications that are
+already popular (section~\ref{sec:plugins}).
 
-[4. Don't feel bad]
+{\bf Encourage collaborative development.} Researchers are routinely
+encouraged to work together on conference papers, but collaborative
+software development appears to be the exception rather than the rule
+(section~\ref{sec:researchsoft}).  Working together increases the
+opportunities for learning and creates an environment of confidence
+about sharing and reusing code.
 
-[5. ???]
-
-\section{Future Work}
+\section{Conclusions and Future Work}
 \label{sec:future}
 
-[More study to find out how far these ``improvements'' actually help]
+We have identified some straightforward ways to make incremental
+improvements to software development practice for audio and music
+researchers, and described the developments we have made in support of
+them.
 
-[Visits to find code we can take under our wing]
+Further actions for the near future include providing more training
+material, particularly for EasyMercurial and our code site, and
+evaluating how researchers respond to training using these facilities.
 
-[Follow-up to Autumn School]
+We are also considering various options for following up the 2010
+Autumn School for researchers, perhaps with a more distributed model
+to take the school to a number of locations around the UK.
 
-[More training, videos, tutorials etc]
-
-[EasyHg evaluation]
-
-\subsubsection{Hands-on Help} % porting, etc
-
-Another approach to dealing with platform incompatibilities is to
-provide a service that can be used to respond to demand for research
-software and to maintain it accordingly.  That is, besides encouraging
-people to publish and if necessary maintain their own code, and
-teaching people how to update and fix the code they need to use, we
-can also locate code that researchers need and help them to obtain it
-in a working state.  Although the effort involved in updating old code
-is higher than that involved in improving it at the time it is
-written, this approach permits resources to be aimed directly at the
-code that current researchers actually want to use. We intend during
-late 2011 and early 2012 to visit a number of research groups,
-identify ``lost'' or troublesome code, and provide development
-expertise to make it available where possible. (TODO: move that last sentence to Future Work and refer to it here?)
+At the same time, we intend to begin another approach to dealing with
+platform incompatibilities, namely to provide a service that can be
+used to respond to demand for research software and to maintain it
+accordingly.  If we can locate code that researchers need, we may be
+able to help them to bring it to a working state.  Although updating
+old code takes effort, this approach should permit resources to be
+aimed directly at those methods that current researchers want to be
+able to use. We intend during the coming months to visit a number of
+research groups, identify ``lost'' or troublesome code, and provide
+development expertise to make it available again.
 
 %%\section{Appendix: SoundSoftware survey 2010}
 %%\label{sec:survey}