[gsharp-devel] Gsharp progress report

[Robert Strandh]

Dear mailing-list member,

This is the first in what I hope to be a series of regular Gsharp
progress reports for people who do not follow the cvs mailing list
and who do not participate in the #lisp IRC channel.

Since it is hard to talk about `progess' in a first report like this,
let me instead give a brief list of what Gsharp can do, what it can
not yet do, and what things are, should, or ought to be worked on
first. 

What we have: 

  * The fundamental buffer data structure is not perfect yet, but it is
    getting there.  We don't have a formal buffer protocol yet, but
    such a protocol is getting possible as I learn what could be
    implemented efficiently.  

  * The line-breaking algorithm seems to work, and has been abstracted
    out into a library called Obseq.  Gsharp uses this library only in
    a trivial way right now for producing `roll of paper' output.  We
    would like to add various page-based output styles (fixed number
    of pages, number of pages modulo n = 0, last page filled or not,
    etc). 

  * The spacing algorithm is similar to that of the Lime score editor,
    and seems to work.  However currently only temporal spacing is
    implemented.  So called lyric spacing which is used in crowded 
    conditions, is not yet implemented, because the spacing algorithm
    does not know the physical width of clusters and lyrics elements. 

  * The beaming algorithm seems to be work. 

  * Functionality-wise, Gsharp can handle multiple staves, multiple
    voices (called layers), multi-staff note clusters, complex
    accidental placements, etc. 

What can not do yet:

  * Literally hundreds of little things that are necessary in any
    score editor, like staccato marks, fermata, etc.  It is my hope
    that advanced potential Gsharp users will eventually be able to
    add such functionality, so that I can concentrate my energy on
    fundamental algorithms and data structures.

  * Multiple beams.  The main difficulty is to get secondary and
    fractional beams to come out exactly parallel to the main beam.
    Doing this requires fiddling with regions for the output.

  * Triplets, etc.  The spacing algorithm needs to be improved to
    handle this.

  * Many minor things like creating a buffer when a non-existing file
    name is used for loading, doing the right thing when the user
    remove a staff, etc.

What is being worked on:

  * Changing key signatures and clefs at arbitrary places in the score
    (Christophe Rhodes is working on this). 

  * Personally, I am working on restructuring some computations such
    as stem direction and accidental placement, so that the result of
    these computations are known to the line-breaking algorithm.  This
    will enable that algorithm to take physical width into account,
    which is a prerequisite for lyrics spacing. 

  * In parallel with restructuring the code, I have added many
    comments to it, and tried to improve it so as to facilitate future
    modifications. 

Other things that are high priority but that nobody is working on yet
(as far as I know):

  * Multiple beams (see above)

  * Improving the appearance of stacks of notes by substituting
    special glyphs for such stacks. 

  * Adding a "mode line" giving the name of the file being edited, and
    more. 

  * Using presentation types for better user interaction

  * Introducing Flexichains for the buffer implementation

  * Improving the documentation and synchronizing it with the code. 

  * Probably dozens of things that I can't think of right now.

Lower-priority things that need to be done:

  [Too many to enumerate]

Finally, thanks to Robert J. Macomber for the patch that enables the
user to delete the current note from the current cluster. 

If you have any questions or remarks with respect to this report,
please do not hesitate to let us know by sending mail to the
gsharp-devel mailing list. 

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