Doc/plans.tex

   1 \chapter{Plans for the future}
   2
   3 \section{Minor issues}
   4
   5 There are tons of minor issues to fix.  Here is a partial list.
   6
   7 \subsection{Notation issues}
   8
   9 \begin{itemize}
  10 \item Elements now have an additional property that lets the user
  11   position them horizontally with an offset relative to their normal
  12   aligned position, so that notes with an interval of a second form
  13   different layers do not overlap physically.  But we also have to
  14   introduce a set of primitives to alter this offset, and perhaps some
  15   visual indications that show the offset.  Perhaps we should show a
  16   thin yellow line where the alignment is whenever there is a nonzero
  17   offset.  I am suggesting yellow, because it would not destroy the
  18   overall visual impression of the score.
  19 \item The cursor is currently drawn by the drawing routine for the
  20   layer, but that routine is not supposed to know where the cursor
  21   is.  We need to separate out cursor drawing from layer drawing.
  22 \end{itemize}
  23
  24 \subsection{Implementation details}
  25
  26 \begin{itemize}
  27 \item Playing as MIDI should create a temporary file with a unique
  28   name in \texttt{/tmp} as opposed a file in the current directory
  29   with a name that can clash with others.
  30 \end{itemize}
  31
  32 \section{Major issues}
  33
  34 \subsection{Implementation details}
  35
  36 \begin{itemize}
  37 \item Different information might need to be attached conceptually to
  38   barlines, in particular: fermata, repeat bars, etc.  It would be
  39   natural to physically attach this information to the bar, indicating
  40   properties of the barline at the end of the bar, but there is a
  41   conceptual problem with this, since some of this information is not
  42   unique to the layer, but sometimes global to all layers that are
  43   traversed by the resulting barline and sometimes even (repeat bars?)
  44   to the entire score.  One could imagine a separate structure for the
  45   segment, indicating positions of repeat bars and such.  It would
  46   have the additional advantage that if a barline is deleted in a
  47   layer which has a repeat bar further on, the visual effect would be
  48   nicer.  Operating on this new structure should be possible from any
  49   layer.
  50 \item The fermata symbol is sometimes centered on a beam (tremolo).
  51   We currently have no way of attaching any information to a beam,
  52 \end{itemize}
  53
  54 \section{Minor projects}
  55
  56 \subsection{Default staff line for rests}
  57
  58 When using several voices (usually two) on one staff line, one would
  59 like for rests to be placed on (say) the upper staff line for the
  60 upper voice and (say) the lower staff line for the lower voice rather
  61 than, as now, having all rests inserted by default on the middle staff
  62 line.  It would be nice if a layer had a default staff line for rests
  63 so that changing the layer automatically changes the default staff
  64 line for rests.
  65
  66 \subsection{Default stem direction for a layer}
  67
  68 When using several voices on a staff line, one somtimes wants the
  69 stems of the upper voice to be up and the ones of the lower voice to
  70 be down.  It would be nice for a layer to have a default stem
  71 direction so that changing the voice would automatically change the
  72 stem direction.
  73
  74 Here is a possible specification of such a feature:
  75
  76 A new element is still created according to the stem direction of the
  77 input state without taking into account the stem direction of the
  78 layer.  When a layer is displayed, the following final stem direction
  79 is computed:
  80
  81 \begin{itemize}
  82 \item if the stem direction of the element is not \emph{auto} then
  83   that stem direction is used;
  84 \item if the stem direction of the element is \emph{auto}, but the
  85   default stem direction of the layer is not \emph{auto}, then the
  86   default stem direction of the layer is used;
  87 \item otherwise, the stem direction is computed from the position of
  88   the notes of the element.
  89 \end{itemize}
  90
  91 \subsection{Other minor projects}
  92
  93 \begin{itemize}
  94 \item multi-buffer, multi-frame
  95 \item display additional information around current element (beaming
  96   information, stem information (auto or not)), etc
  97 \end{itemize}
  98
  99 \section{Major projects}
 100
 101 \subsection{Improved spacing algorithm}
 102
 103 There are two aspects of the spacing algorithm:
 104
 105 \begin{enumerate}
 106 \item Determining how to divide a sequence of measures into pages and
 107   lines based on the amount of space each measure will require on a
 108   given line,
 109 \item Rendering the page(s) actually visible by the user at any given
 110   time.
 111 \end{enumerate}
 112
 113 We can spend relatively much time on rendering since it is supposedly
 114 only done for a small fraction of the entire score and relatively
 115 little time on dividing sequences of measures into pages and lines.
 116 Also, we can accept a rough estimate of the space that a measure needs
 117 for the purpose of dividing into pages and lines, whereas the
 118 rendering phase needs to be very precise so as to avoid overlapping
 119 characters.
 120
 121 For rendering, we can assume that we have a bunch of \emph{lines},
 122 each one being a \emph{sequence of measures}.  For this phase, one
 123 idea would be to compute an \emph{elasticity function} for each
 124 measure indicating how willing it is to stretch or compress given that
 125 a certain force is applied to it.  In fact it would indicate the width
 126 as a function of force applied.  Such a function would be piecewise
 127 linear with rational coordinates to avoid rounding errors.  The
 128 elasticity function of a line would be the sum of the elasticity
 129 functions of the measures of the line, again a piecewise linear
 130 function.  The combined function would then be solved for the line
 131 length which gives a force to be applied to each measure (elementary
 132 mechanics give that each measure in the sequence would have the same
 133 force applied to it).  To render each measure, that force would be
 134 applied to it.
 135
 136 The problem with dividing a sequence of measures into lines and pages
 137 is that the elasticity function depends on the context.  Specifically,
 138 the \emph{natural width} (the width that the measure would take when
 139 given a force of 0) depends on the smallest distance between two
 140 adjacent time lines \emph{of all of the time lines in all of the
 141 measures on a line}.  This gets messy, since currently, we depend on
 142 the cost function of a line to be combined in constant time, i.e., the
 143 cost function of a line with a new measure added to the beginning or
 144 to the end of it is possible to compute in constant time from the cost
 145 function of the existing line and that of the new measure.  Either I
 146 am being to conservative here, and we can afford to spend more time
 147 computing the cost function of a line, or else, we need to find an
 148 approximation of the elasticity function that will combine in constant
 149 time.  This is hard to know until we have tested {\gs} on large
 150 scores, and until we have implemented the page-breaking algorithm (as
 151 opposed to the line-breaking algorithm that we now have). An example
 152 of an approximation of the elasticity function would be to use the
 153 current estimate with an additional value called \emph{additional
 154 constant space}.  The cost combination function would add the constant
 155 spaces required by each measure as long as newly added measures have
 156 the same smallest time-line distance (min-dist).  As soon as a measure
 157 with smaller min-dist is added to the line, the additional constant
 158 space of the existing line is set to 0.  The assumption is that the
 159 existing line is going to have to expand as a result of the smaller
 160 min-dist which will eliminate the need for the additional constant
 161 space.  Adding a measure with a larger min-dist than that of the
 162 existing line would simply ignore the additional constant space of
 163 that measure.  Again, the assumption is that the new measure will have
 164 to expand so that the additional space will not be needed.
 165
 166 The additional constant spaced of a measure would be computed as if it
 167 would be inserted into a line having the same min-dist as the measure
 168 itself.  Such space would include space for lyrics, accidentals of
 169 complicated clusters, etc.
 170
 171 \subsection{Layout by page}
 172
 173 We need to have a more sophisticated layout algorithm that divides the
 174 score into pages rather than just lines.  One interesting idea seems
 175 to be to use the {\obseq} library in a nested kind of way, where an
 176 invocation of the cost combination method on the global level would
 177 provoke another call to the \texttt{solve} function on the page
 178 level.  This would be really cute, actually, and it would show the
 179 power of the approach of the {\obseq} library.
 180
 181 Here is how it would be done.  First it requires a minor modification
 182 to the {\obseq} library.  Instead of the elements \emph{inheriting}
 183 from \texttt{obseq-elem}, they need to be separate so that an element
 184 can be contained in more than one \texttt{obseq}.  This modification
 185 has some consequences: the operations to compute the next and previous
 186 element need to take an \texttt{obseq} argument to dispatch on.  The
 187 operations \texttt{last-undamaged-element} and
 188 \texttt{first-undamaged-element} must be modified and renamed to (say)
 189 \texttt{tail-valid-elements} and \texttt{head-valid-elements} and take
 190 a number instead of an element, since the \texttt{obseq} itself does
 191 not have a mapping from its internal elements to the client element.
 192 This requires the client to know how many elements there are, which is
 193 a minor inconvenience (but still an inconvenience). Then the seq-cost
 194 on the global level will be an obseq on the page level, and a call to
 195 combine a seq-cost and an element on the global level would trigger a
 196 call to solve on the page level.
 197
 198 We also need to have different cost combination strategies, for
 199 instance:
 200
 201 \begin{itemize}
 202 \item Paper roll with last line not right justified.  This involves
 203   assigning a low cost to the last line even when it has to be highly
 204   stretched in order to fill the line.
 205 \item Paper roll with last line right justified.  This is all we have
 206   right now.
 207 \item Pages with last page not filled and last line on last page not
 208   filled.
 209 \item Pages with last page filled normally.
 210 \item Pages with a fixed number of filled pages.
 211 \item Pages with an arbitrary number of pages, but the number must be
 212   of the form $n = ax + b$.
 213 \end{itemize}
 214
 215 \subsection{Other major projects}
 216
 217 \begin{itemize}
 218 \item presentations everywhere (noteheads, clusters, beam groups).
 219   Currently, McCLIM is a bit to slow for this.
 220 \item context menus on notes, etc
 221 \item allow mouse-based input of new notes by making staff steps
 222   around cursor into presentations.  Move pointer to horizontal
 223   location of cursor after interaction.
 224 \item allow mouse-based addition and deletion of notes in existing
 225   clusters by making staff steps around cluster into presentations
 226 \item make sure user can use either keyboard or mouse without changing
 227   too often
 228 \item add new views of score, especially to manipulate staves,
 229   brackets, braces, instruments, etc.
 230 \item perhaps hide interactor by default and use something like M-x to
 231   make it visible.
 232 \item use output recording (hierarchical records) to reorganize pixmaps
 233   and to substitute combined pixmaps.
 234 \end{itemize}
 235
 236 \section{McCLIM issues and projects}
 237
 238 \begin{itemize}
 239 \item add better system for Emacs-style commands and key
 240   bindings
 241 \item fix problem of input focus being retained (also a
 242   problem for Goatee)
 243 \item make sure gestures work as announced
 244 \item perhaps make it possible to use something like M-x to change
 245   input focus
 246 \item make setf of frame-layout work
 247 \item multiple top-level frames (as in Franz CLIM).
 248 \item remove compilation warnings in McCLIM
 249 \item remove dead code
 250 \item remove reasons for remarks such as XXX:, FIXME, etc, or at least
 251   put a name in their place
 252 \end{itemize}