[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. 

I have worked on several different things since the last progress
report:

  * Key signatures are now Gsharp objects (as opposed to just
    vectors) with their own protocol.  I did not change the external
    format yet again, and instead made it possible for the current one
    to deal with either representation; 

  * Gsharp can now handle elements with zero duration.  That turned
    out to be a major reorganization of the code.  This functionality
    will be used for elements such as key signature changes and clef
    changes;

  * I changed the class hierarchy of elements according to a
    suggestion by Christophe Rhodes, so that there is now an
    additional class `rhythmic-element' that represents elements with
    non-zero duration; 

  * The external format for representing buffer objects has been
    modified, though Gsharp can still read the old format.  The new
    format is easier to extend with new types of objects.  Instead of
    using a dispatch macro character, there is now a single macro
    character `[', which is followed by a fully qualified symbol name
    that indicates the name of the class of the object;

  * I reorganized the command tables so that the one used by the
    command loop can be determined by the type of the current layer,
    and the type of the element preceding the cursor.  This makes it
    easier to use the same key strokes for different kinds of elements
    and different kinds of layers;

  * I started implementing ties.  The code for representing ties in
    the buffer seems to be working.  However, rendering ties is hard,
    and requires access to the book by Ted Ross, which I have now
    ordered so that I can finish this work.  Rendering ties turns out
    to be messy in other ways as well, since most rendering code at
    the moment works "vertically" by measures, whereas ties need to be
    processed "horizontally" by layers;

  * I introduced two new packages esa-buffer and esa-io (that I hope
    will become part of a separate ESA library one day) which contain
    code adapted from Climacs that manages buffer/file i/o in an
    application independent way.  I made Gsharp take advantage of
    these new packages to behave more like an editor application
    should, with named buffers and Emacs-style file i/o (C-x C-s, C-x
    C-w, etc);

  * Gsharp now has an `info pane' (what Emacs calls "mode line") that
    shows the name of the buffer, whether it needs saving, etc. 

Documentation changes:

  * I updated the documentation to reflect an old change from using a
    CLIM interactor pane to using an ESA minibuffer.  The
    documentation is still not fully up-to-date, nor is it complete,
    but it is better than it was. 

New score:

  * There is a new, partially-completed score in the Scores
    directory.  It is a tune used in a commercial on NZ TV.

Minor fixes:

  * Fixed a bug that made Gsharp crash for empty clusters.  These were
    used in one of the scores in the Scores directory, but I had not
    used that particular score to test Gsharp for a while.  Now, all
    the scores in the Scores directory should work;

  * Fixed a bug that ignored the explicit x-offset of elements.  This
    bug was introduced when the spacing algorithm was altered.  One of
    the scores in the Scores directory needs explicit x-offsets in
    order to avoid overlaps of elements in crossing voices;

  * The temporary midi file generated by the `play' commands is not
    put in /tmp.  It is still not uniquely named, nor is it cleaned
    up;

  * Fixed a bug that did not recognize modifications to lyrics
    elements so did not invalidate the corresponding element.  

Related fixes:

  * I modified the font viewer in the Fonts directory (another CLIM
    application) to play nicely with the others, and not destroy the
    port.  Now the viewer can be used from the CLIM Desktop.

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