Re: proportional notation screws up score

[Trevor Bača]

On 12/3/06, Orm Finnendahl <address@hidden> wrote:
> Hi,
>
> it seems proportional notation and the spacing is more broken than I
> ever expected. I'm extremely frustrated (especially after I put so
> much hope into lilypond) having spent 5 days to enter 12 lines
> of music and now having lost 4 hours of work trying to space 4 lines
> of music correctly (with the musicians waiting...).
>
> I urge the maintainers of the documentation to put a warning in big
> bold letters to the section of proportional notation (8.4.3) that
> users encountered severe bugs in the spacing algorithm or maybe
> skipping the section stating that lilypond is capable of proportional
> notation altogether.
>
> For anybody able to help I uploaded the score in question here:
>
> icem-www.folkwang-hochschule.de/~finnendahl/download/violine-test.tgz
>
> To generate the score, "gesamt.ly" has to be evaluated by lilypond. To
> see what is wrong, you can simply change the expression
> "#(ly:make-moment 8 99)" at the end of line 10 into #(ly:make-moment 8
> 100) and reevaluate. In my version (2.11.0-1) the first staff system
> stretches out all the way to the right paper edge while being far too
> short with the "99" setting. To get a feeling why this is so strange,
> compare the output of a 98 to the output of a 99). But you can also
> leave that line alone and change the next ly:make-moment into
> different values to observe completely unpredictable results (it would
> even be funny if I hadn't run into a severe time problem).
>
> I'm completely at loss here and will probably have to resort to
> non-proportional notation (which is less than suboptimal in the
> special case of that piece) or go back to handwriting (after throwing
> my computer out of the window).

Hi Orm,

Wow, after rendering the score I can totally see why you're so frustrated.

I use proportional notation in most of my scores and I have some best
practices. But I'm also afraid that we probably won't be able to get
your score exactly the way it should look with the current
implementation of the proportional notation package.

First the pointers:

1. I almost always turn on \override SpacingSpanner
#'strict-note-spacing = ##t together with propotional notation. This
causes nonrhythmic glyphs like accidentals and clefs to have no impact
on spacing whatsoever.

2. There is a bug with proportional not dealing with skips correctly.
Proportional notation handles notes and rests correctly. But
proportional notation freaks out with skips. I noticed this some time
ago but haven't really drawn any special attention to the bug because
a reasonable workaround is to use a transparent rest (or transparent
note) in place of a skip. But this is a problem and does need to be
fixed because using this workaround can (and does) lead to all sorts
of interpreter warnings about clashing note columns or unknown rest
direction. Here's a snippet and I'll crosspost the bug list; to see
what's going on, render the example and note that the spacing of all
three scores should be identical but that the 2nd score is not:

%%% BEGIN %%%

\version "2.11.0"

\new Score \with {
  propotionalNotationDuration = #(ly:make-moment 1 64)
} {
  \new Staff {
     c'4
     c'4 % proportional spacing ok here with notes -- OK
     c'4
     c'4
  }
}

\new Score \with {
  propotionalNotationDuration = #(ly:make-moment 1 64)
} {
  \new Staff {
     c'4
     s4  % proportional spacing freaks out here because of the skip -- BUG
     c'4
     c'4
  }
}

\new Score \with {
  propotionalNotationDuration = #(ly:make-moment 1 64)
} {
  \new Staff {
     c'4
     \once \override Rest #'transparent = ##t
     r4  % propotional spacing ok here with notes and rests -- WORKAROUND
     c'4
     c'4
  }
}

%%% END %%%

3. I saw the discussion on the list a couple of days ago about setting
proportionalNotationDuration in the middle of musical input and was
quite surprised to find out that this was possible. It obviously is
possible (as the violin score here shows) but I wonder if the behavior
is well-defined. I guess that's a question for Han-Wen, but it doesn't
surprise me that resetting proportionalNotationDuration in mid-input
can confuse the spacing algorithms. FWIW, I set
proportionalNotationDuration once in the header of the Score context
only. However, this set-only-once idea obviously won't work where
there are tempo changes. At a tempo change I would start a new spacing
section and then reset proportionaNotationDuration, thus minimizing
the number of different settings to proportionalNotationDuration.

4. I have no idea why this is, but "wider" values assigned to
proportionalNotationDuration seem to help achieve the look of true
proportional notation considerably. By "wider" I mean *shorter*
durations that thus result in spacing the music more widely. So:

 proportionalNotationDuration = #(ly:make-moment 1 64)

works a lot better than

 proportionalNotationDuration = #(ly:make-moment 1 8)

What seems to be the case is that there's some weirdness when rhythmic
elements in the score (like notes and rests and skips ... things that
carry a duration) have a smaller duration than the reference duration
that we pass into the proportionalNotationDuration assignment. This
doesn't mean that the proportional notation reference duration must be
smaller than the durations of *all* the rhythmic elements in the score
(which would be a pain), but just that -- as a heuristic -- in general
a smaller proportional notation reference duration seems to work
better. (I wish I could provide a real explanation here, but I can't
yet.)

* * *

Pointers aside, I'm not sure what to suggest you do here in the violin
piece. The score is so beautiful and idea of the parameter display on
literal graph paper is so clear, yet my instinct tells me that we
unfortunately probably can't get the music to line up exactly under
the current implementation of the proportional package.

With the musicians waiting, the best bet might be to strip out the
graph, render the score in lilypond as closely as possible knowing
that the spacing won't be exact, and then import the score into
Illustrator (or whatever drawing package you're using), and redraw the
parameter graph by hand to line up exactly with the imported score.
Which is a complete pain, of course.

* * *

All of this said, the current proportional package *does* bring a
tremendous amount of benefit. Following the pointers above you'll wind
up with score that does come extremely close to proportional layout,
that will space all tuplets (no matter how involved) correctly, and
that will even let you get away with putting nonrythmic elements (like
timesignatures) in the music and still produce excellent results. But
it doesn't surprise me that the current implementation can't space
exactly when put next to a piece of graph paper.

I know it won't help you at all right now since you've got the players
ready, but I'd very much be interested in sponsoring a second type of
proportional spacing that would *exactly* support the way your score
works. Maybe this could be "graph paper spacing" or something (which
we did discuss last year when scoping the current proportional
package). I can clearly see the value and I'd be interested in using
it in my own music eventually, too.

So if you have time after you finish the violin piece, perhaps we
could together contact Han-Wen and ask first for advice on what such
an enhancement might look like (like how would a "graph paper" spacing
package get turned on and off, and how could it be reset in mid-input
to accommodate tempo changes as occur here in the violin piece?) and
second on whether we could sponsor such work sometime in the 2.11
series of releases.

If you're interested, please let me know and I'll be happy to sponsor.

[One last thought: what's particularly frustrating in your case is
that I'm not certain that you might not be able to get exact spacing
even with the current implementation. If you follow the pointers
above, you *might* be able to get it to work out ... but I feel
irresponsible suggesting that you spend more time tweaking when the
players are ready :-( better to just sponsor an explicit package for
what you need after the current piece is done.]


--
Trevor Bača
address@hidden