[gsharp-devel] Gsharp progress report

Robert Strandh strandh at labri.fr
Mon Dec 5 07:28:32 UTC 2005


Dear mailing list member,

As promised, here is another Gsharp progress report, again mainly for
those who follow neither the CVS mailing list nor the #lisp IRC
channel. 

Since last progress report, I have been working on restructuring the
division of labor between three different parts of Gsharp, namely the
line-breaking algorithm, the spacing algorithm, and the code for
drawing the various music elements.  Determining stem direction was a
prerequisite for knowing the placement of accidentals, and knowing
where accidentals are located was a prerequisite for knowing how much
space must precede an cluster.  For that reason, this computation has
been moved, and not takes place before line breaking.  The
line-breaking algorithm does not yet take advantage of this fact
though, and remains the same as before. 

The best news, however, is that the restructuring cited above made it
possible to implement a new spacing algorithm, which became
operational today.  The new algorithm models a system as a sequence of
physical springs that can stretch according to a force that is applied
to them.  This model, together with some non-linearities introduced by
smallest allowed distances between certain elements, is a reasonable
approximation of how the spaces of a system must adapt to the line
width at our disposal.  For those who remember the overlaps created by
certain accidentals in the file rapsoden-sjunger.gsh, I advice you to
check again with the new algorithm.  In addition to avoiding overlaps
in the case of many accidentals, the new algorithm also gradually
applies what is known as "lyrics spacing" when conditions become too
crowded to use normal temporal spacing rules.  Such conditions are
usually the result of wide lyrics compared to the overall compactness
of the spacing style, but similar conditions can be due to complicated
clusters with many accidentals. 

The code that models a system of springs has been abstracted out to a
separate library, so as to facilitate test and maintenance, and in
case someone needs it for a different application.  

Gsharp now uses the Flexichain library for the first time.  For the
new spacing algorithm, we use explicitly represented timelines, which
group together simultaneous elements.  The sequence of timelines
within a measure is represented as a Flexichain.  However, we also had
to extend the Flexichain library a bit, because we needed for an
element to know its position in the sequence.  This new functionality
is implemented in a different file `flexirank.lisp' which provides two
mixin classes, one to use with a flexichain, and one for the elements
of a flexichain.  The latter contains the position of the element in
the chain, but the physical rather than the logical position, so as to
avoid having to update the positions for each insertion or deletion.
Now, positions only have to be updated when the gap moves, or when the
Flexichain is resized.  This new feature of Flexichains will come in
handy in other parts of Gsharp as well, since we would want parts of
the score to be displayed using presentation types.  Selecting a music
element to be deleted (say), makes it necessary to obtain the position
of an element from the element itself. 

With respect to future work, the new spacing algorithm should make it
easier to have zero-duration elements (such as key signatures, clefs,
etc) in a layer.  Each can have its own elasticity function to
properly model the amount of space that should follow.  

That's all for this time.  I am taking a week off starting at the end
of this week, so it is unclear how much work will be done in the next
two weeks.  I'll be back with another progress report when there is
something worth reporting. 

-- 
Robert Strandh

---------------------------------------------------------------------
Greenspun's Tenth Rule of Programming: any sufficiently complicated C
or Fortran program contains an ad hoc informally-specified bug-ridden
slow implementation of half of Common Lisp.
---------------------------------------------------------------------



More information about the gsharp-devel mailing list