[climacs-cvs] CVS update: papers/ilc2005/syntax/boardfig.eps papers/ilc2005/syntax/boardfig.pdf papers/ilc2005/syntax/climacssyntax.bib papers/ilc2005/syntax/climacssyntax.tex
Christophe Rhodes
crhodes at common-lisp.net
Mon May 23 11:34:59 UTC 2005
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}
}
@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 = {}
+}
+
+ at 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}
More information about the Climacs-cvs
mailing list