Update of /project/climacs/cvsroot/papers/ilc2005/syntax In directory common-lisp.net:/tmp/cvs-serv6888
Modified Files: climacssyntax.bib climacssyntax.tex Added Files: boardfig.eps boardfig.pdf Log Message: Initial stab at describing interesting bits of the tabeditor
Date: Mon May 23 13:34:58 2005 Author: crhodes
Index: papers/ilc2005/syntax/climacssyntax.bib diff -u papers/ilc2005/syntax/climacssyntax.bib:1.7 papers/ilc2005/syntax/climacssyntax.bib:1.8 --- papers/ilc2005/syntax/climacssyntax.bib:1.7 Mon May 23 12:21:41 2005 +++ papers/ilc2005/syntax/climacssyntax.bib Mon May 23 13:34:58 2005 @@ -149,14 +149,14 @@
@book{FinsethCraft, author = {Craig A. Finseth}, - title = {The Craft of Text Editing}, + title = "{The Craft of Text Editing}", publisher = {Springer-Verlag}, year = {1991, 1999--}, note = {http://www.finseth.com/craft%7D }
@Manual{ISOProlog, - title = "{Information technology -- Programming languages -- Prolog -- Part 1: General core}", + title = "{Prolog -- Part 1: General core}", key = {ISO/IEC 13211-1:1995}, OPTauthor = {}, organization = {ISO}, @@ -165,6 +165,16 @@ OPTmonth = {}, year = {1995}, OPTnote = {}, + OPTannote = {} +} + +@Unpublished{tabxml, + author = {Frans Wiering and Tim Crawford and David Lewis}, + title = "{Creating an XML vocabulary for encoding lute music}", + note = {In preparation}, + OPTkey = {}, + OPTmonth = {}, + OPTyear = {}, OPTannote = {} }
Index: papers/ilc2005/syntax/climacssyntax.tex diff -u papers/ilc2005/syntax/climacssyntax.tex:1.16 papers/ilc2005/syntax/climacssyntax.tex:1.17 --- papers/ilc2005/syntax/climacssyntax.tex:1.16 Mon May 23 12:21:41 2005 +++ papers/ilc2005/syntax/climacssyntax.tex Mon May 23 13:34:58 2005 @@ -432,36 +432,72 @@ computer-based musicological studies (as in \cite{ecolm-graz} for example).
-\TabCode\ has a rather ad-hoc cobbled together grammar. Tokenising is -easy; determining which elements of the notation are best captured is -not so easy. Chords, obviously; beams, comments... Should we try to -capture a BNF or something? I suppose it depends how we're doing for -space. - -Ornaments are simple to model, as they are merely modifiers to note -objects; higher-level grouping things (beams, connecting lines) have -their own semi-independent identity, despite not being notated as such -in the textual \TabCode. Beams and connecting lines can overlap -(thinking linearly, not on the manuscript!) in non-trivial ways: - -\begin{verbatim} - [ beamed section ] - word word word word word - ^____ line ____^ -\end{verbatim} - -Need whole-buffer function to present an alternative whole-system view -on the data. - -Editor is in use for cataloguing European lute music, and supports -research into more advanced notations (for e.g. editorial comment, or -manuscript markup) - -Efficiency concerns assuaged by typical locality of edit, CLIM -incremental redisplay on the tablature buffer. - -MIDI feedback. At present, based on Apple's extremely badly -documented CoreMIDI framework; a port to alsalib is on the cards. +The \TabCode\ language itself has developed to provide a terse and +intuitive encoding of tablature, rather than a well-formed grammar for +parsing. Simple \TabCode, as in figure \ref{fig:besfantlach}, +presents no problems: each chord is an optional rhythm sign (a capital +letter), followed by zero or more notes as fret--string pairs +(letter--number combinations). Adding ornaments and fingering marks +to this structure is simple, as they are merely optional modifiers to +each note, and can be parsed as such. + +\begin{figure} + \begin{center} + \includegraphics{boardfig} + \caption{Extract from 'An Almand by mr Jo Dowland Bacheler of + musique', \textit{The Board Lute Book} (GB:Lam MS 603), f.13. + Note in particular the connecting lines in this bar, joining + chords within beams to an unbeamed chord.} + \label{fig:board} + \end{center} +\end{figure} + +More complex to model are beams and connecting lines, which have their +own semi-independent identity, despite being encoded in \TabCode\ as +modifiers to individual tokens. In particular, the existence of beams +and connecting lines means that we cannot parse a buffer into a +sequence of tabwords and thence into hypothetical higher-level +structures such as \texttt{beamed-group} and \texttt{connected-pair}, +because these higher-level structures can overlap in non-trivial ways, +as in figure \ref{fig:board}. Instead, we deal with these modifiers by +invoking a parser on the sequence of parsed buffer elements to +generate parallel sequences of beams, connecting lines and other such +tablature elements. + +The tablature editor that has been developed in parallel with Climacs +is in use for a project to catalogue European lute music, and +additionally supports research \cite{tabxml} into more advanced +notations and extensions of \TabCode\ (to provide a means to encode +editorial comments or alterations, or markup of distinguishing +features of a specific source ma-nu-script). + +When the tablature editor is in use, the user has in addition to the +usual editor window a scrollable graphical display of the tablature +encoded within the buffer. Individual tablature elements are +presented to this CLIM pane, allowing the graphical display to provide +mouse-activated commands, such as one which moves the buffer cursor to +the beginning of the tabword encoding a particular element. + +Since we are presenting an alternative view of the whole buffer's +contents, we analyse the entire buffer's contents on every edit, +rather than bounding our analysis by the extent of the visible textual +area. To mitigate the efficiency concerns that this might suggest, it +should first be noted that the typical length of a \TabCode\ file is +of the order of 200--300 words, which requires only little time to +parse on modern hardware. However, such a parsing scheme would stress +the display engine if a complete redraw were forced on every edit, so +we have implemented the obvious optimizations: the extent of the edit, +along with its typical locality of effect, are used to limit the +damaged region as before, so preserving the identity of unaffected +tabwords; this identity can then be used in a cache informing CLIM's +incremental redisplay mechanism. + +To assist the editorial process, we have also implemented MIDI audio +feedback: in addition to a command to render the entire tablature, we +provide several gestures to play individual chords: one intended for +use during the initial entry of the encoding, to act as a rapid +error-detection aid, and a motion command and mouse gesture to assist +revision and navigation.
\section{Future Work and Conclusions} \label{sec:conclusions}