[gsharp-devel] Lyrics!

[Robert STRANDH]

Hello,

Christophe Rhodes writes:
 > 
 > Over the weekend (well, really an hour on Friday and an hour today) I
 > had a play with adding some kind of support for lyrics to gsharp.  You
 > can get some feel for my progress and wanderings by examining
 >   <http://www-jcsu.jesus.cam.ac.uk/~csr21/lyrics-1.png>
 >   <http://www-jcsu.jesus.cam.ac.uk/~csr21/lyrics-2.png>
 >   <http://www-jcsu.jesus.cam.ac.uk/~csr21/lyrics-3.png>
 >   <http://www-jcsu.jesus.cam.ac.uk/~csr21/lyrics-4.png>
 >   <http://www-jcsu.jesus.cam.ac.uk/~csr21/lyrics-5.png>

Nice progress. 

 > Lyric engraving has plenty of pitfalls that I haven't even begun to
 > address: as you can see, I'm not adjusting spacing requirements based
 > on the length of the lyric; 

I think this is a more general problem.  At the very least, a cluster
should have an indication as to how much it sticks out to the left and
to the right of its timeline.  The calculation of the width of a
measure must take these values into account.  This would solve the
problem of clusters with many alterations as well as the problem with
lyric spacing.  

 > I'm not getting hyphens and underscore
 > extenders at all right -- I'm not even placing the lyrics below the
 > staff!

Perhaps lyrics should have their own (invisible) staff, they way
percussion should have.  All lyrics could then go in one staff with
each line on a different "staff line". 

 > Also, from a representational point of view, I have currently got a
 > firm association between a cluster and a lyric.  This is non-optimal
 > for two reasons: one, music with a verse structure often has more than
 > one set of lyrics for the same notes; two, there is often a need for a
 > more horizontal notion of lyrics (as an example, consider the act of
 > deleting an element from the score: it is very unlikely that you also
 > want to delete its associated lyric).

Right.  I think lyrics should be placed in their own layer, probably
one layer for each set of lyrics.  Each "word" in the lyrics should
have values for "notehead" and "dots" so that its duration can be
calculated.  

One could even imagine that having the cursor in such a layer changes
some aspects of the keyboard mappings so that `c', `d', etc will
insert characters instead. 

There is also another (existing) general mechanism that will be useful
for lyrics, namely the possibility of having a horizontal offset of
an element compared to its timeline.  I currently use it to avoid that
crossing voices on the same staff overlap physically.  For lyrics, it
could be used to align whatever letter you want with the timeline. 

 > Nevertheless, I attach my current patch, basically because I'd welcome
 > comments as I don't really know what I'm doing.  One thing that has
 > become apparent is that my way of testing the horizontal extent of the
 > lyrics (the WITH-OUTPUT-TO-OUTPUT-RECORD/WITH-BOUNDING-RECTANGLE* in
 > drawing.lisp) is quite expensive -- it takes a significant time for
 > the screen to refresh after each keystroke in lyric mode.  Is there a
 > way of making this less expensive?

I will let Tim answer that question.  

Speaking of which: As an SBCL expert, perhaps you know more about how
to profile code than I do.  Refreshing a page of "rapsoden-sjunger"
takes around a second, which is a little too much.  I have tried
profiling pretty much everything in the gsharp packages and in the
McCLIM packages, without any conclusive results.  As a started, I
would like to know whether it is computing the score or drawing it
that takes time.  Do you have any ideas about how to do that? 

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