[gsharp-devel] Gsharp progress report

[Robert Strandh]

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 the previous progress report, I have been working on multiple
beams.  The tricky part is to get secondary beams exactly parallel to
the primary beam.  Simply rounding the end points to integer
coordinates does not work.  Instead, one has to draw the secondary
beams as if they were the primary beam offset by a certain y position,
and with a clip mask that will show the secondary beam only when
appropriate.  This method mostly works, except that McCLIM seems to
ignore the clip mask when output records are repainted.  Thus, when a
Gsharp score is exposed after having been invisible, secondary beams
are displayed where there should not be any.  At the moment, I have
not attempted to find exactly where the problem is. 

I have also been working on preparing Gsharp for handling multiple
buffers and multiple windows.  For this, I am using a recent idea that
I discussed with Dave Murray, namely to use a pane -> view -> buffer
hierarchy.  Essentially, a pane displays a view and a view contains a
buffer and some other information that is specific to the view, such
as the cursor.  This model will allow us to have different kinds of
views, such as orchestra views and parts views. 

A bug report from Christophe Rhodes indicating that horizontal beams
had the wrong y position made me add some information relative to
beams in the SDL package.  In particular, the font object now knows
the upper and lower edges of a beam relative to the reference point,
as well as how much a beam should be moved vertically in order for it
to sit on or hang from a staff line. 

There have also been some minor improvements since the last progress
report: 

  * The calculation of the physical width of clusters with suspended
    notes has been improved;

  * The position of accidentals when a C clef was used was wrong and
    has been fixed (thanks to Christophe Rhodes);

  * The octave of the C clef was wrong.  This has been fixed (thanks
    to Christophe Rhodes);

  * When a clef was modified, the clusters did not get recomputed.
    This problem has now been fixed (thanks to Christophe Rhodes for
    reporting this problem).

That's all for this time.  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.
---------------------------------------------------------------------