From strandh at labri.fr Mon Dec 5 07:28:32 2005 From: strandh at labri.fr (Robert Strandh) Date: Mon, 5 Dec 2005 08:28:32 +0100 Subject: [gsharp-devel] Gsharp progress report Message-ID: <17299.60448.56852.147064@serveur5.labri.fr> 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. ---------------------------------------------------------------------