note-spacing: stretch somewhat uniformly; issue 3304

1   note-spacing: let compressibility be uniform; issue 3304
    
    Comments implied that half the width of accidentals, etc., was added
    to the ideal spacing between notes, but in fact only compressibility
    was affected.  The non-uniform compressibility caused note-spacing
    to become non-uniform when the lines were compressed.  For example
    a sequence {\stemUp a a d a] would have the head of the D tuck under
    the preceding A.
    
    This commit keeps spacing uniform on compressed lines until objects
    come within padding of each other.

 input/regression/baerenreiter-sarabande.ly |    7 +++----
 input/regression/spanner-alignment.ly      |    2 +-
 lily/include/note-spacing.hh               |    2 +-
 lily/note-spacing.cc                       |   28 +++++++++-------------------


2   note-spacing: stretch somewhat uniformly
    
    Start with a basic spring based on the note duration, and apply optical
    corrections to that.  This results in more consistent springs thus more
    uniform stretching in polyphonic situations.
 input/regression/spacing-multi-tuplet.ly |   18 +++-----------
 lily/include/note-spacing.hh             |    2 +-
 lily/include/spacing-spanner.hh          |    2 +-
 lily/note-spacing.cc                     |   21 +++++++++--------
 lily/spacing-basic.cc                    |   36 +++++++++++++++++++----------
 lily/spacing-determine-loose-columns.cc  |    2 +-
 lily/spacing-loose-columns.cc            |   19 +++++----------
 lily/spacing-spanner.cc                  |   26 ++++++---------------


3   springs: comment and typo
 lily/spring.cc |   19 ++++++++++++++++++-

4   spacing-options: clarify documentation
 Documentation/notation/spacing.itely |    3 +--
 lily/spacing-options.cc              |   11 ++++-------
 scm/define-grob-properties.scm       |   13 ++++++-------

5   ledger-lines: horizontal space only when present
 lily/ledger-line-spanner.cc |    2 +-

[MikeSol, 2013-12-16 07:42:52]

https://codereview.appspot.com/36830045/diff/20001/lily/note-spacing.cc
File lily/note-spacing.cc (right):

https://codereview.appspot.com/36830045/diff/20001/lily/note-spacing.cc#newco...
lily/note-spacing.cc:117: ret.set_inverse_stretch_strength (base_space);
Looked at it, but I have no idea what any of this stuff means.
If you understand this stuff, could you put a comment in lily/include/spring.hh
as to what inverse_compress_strength and inverse_stretch_strength are?

[Keith, 2013-12-16 08:24:35]

On 2013/12/16 07:42:52, MikeSol wrote:

> If you understand this stuff, could you put a comment in
lily/include/spring.hh
> as to what inverse_compress_strength and inverse_stretch_strength are?

They are the stretchability and compressibility of the space.
Next time I have linux up I'll put a comment, or just change the names.

You should try the patch on your music.  You probably have a lot of staggered
timing in the style of 3-against-2 hemiola, which should be aligned more evenly
with the patch.

The greater compressibility between note-columns makes it easier for me to make
readable piano music with fewer page-turns, so I like it.  Before the patch,
there is extra stiffness between a note-column and a following column with
accidentals or other protrusions, and I wonder if this stiffness is needed for
readability.

[mike7, 2013-12-16 08:28:48]

On Dec 16, 2013, at 10:24 AM, k-ohara5a5a@oco.net wrote:

> Reviewers: MikeSol,
> 
> Message:
> On 2013/12/16 07:42:52, MikeSol wrote:
> 
>> If you understand this stuff, could you put a comment in
> lily/include/spring.hh
>> as to what inverse_compress_strength and inverse_stretch_strength are?
> 
> They are the stretchability and compressibility of the space.
> Next time I have linux up I'll put a comment, or just change the names.
> 

Ok - try to explain the relation between things (min distance, ideal distance,
and these two constants).

> You should try the patch on your music.  You probably have a lot of
> staggered timing in the style of 3-against-2 hemiola, which should be
> aligned more evenly with the patch.
> 

I’d say Trevor Bača is an even better candidate (cc’d to this e-mail) - he has π
on e hemiolas in his music.

Cheers,
MS

[trevorbaca_gmail.com, 2013-12-27 06:47:43]

On Mon, Dec 16, 2013 at 2:28 AM, Mike Solomon <mike@mikesolomon.org> wrote:

>
> On Dec 16, 2013, at 10:24 AM, k-ohara5a5a@oco.net wrote:
>
> Reviewers: MikeSol,
>
> Message:
> On 2013/12/16 07:42:52, MikeSol wrote:
>
> If you understand this stuff, could you put a comment in
>
> lily/include/spring.hh
>
> as to what inverse_compress_strength and inverse_stretch_strength are?
>
>
> They are the stretchability and compressibility of the space.
> Next time I have linux up I'll put a comment, or just change the names.
>
>
> Ok - try to explain the relation between things (min distance, ideal
> distance, and these two constants).
>
> You should try the patch on your music.  You probably have a lot of
> staggered timing in the style of 3-against-2 hemiola, which should be
> aligned more evenly with the patch.
>
>
> I’d say Trevor Bača is an even better candidate (cc’d to this e-mail) - he
> has π on *e* hemiolas in his music.
>


Hi all,

Just now read through this thread. (Thanks for point me to it, Mike!)

I haven't followed the details of this change. But it is true that I have a
large number of differently tupletted rhythms written against each other in
most of my scores (though, alas, no ratios in terms of transcendental
numbers ;) What I can say is that I've downloaded and run each of 2.17.95,
2.17.96 and 2.17.97 against all of my recent scores (and also against a
sizable battery of related regression tests) and the horizontal spacing has
been excellent in the output coming from all three release candidates.

I suppose it's important to note that all of my scores use proportional
notation everywhere. So I imagine that most of the horizontal spacing
improvements don't actually impact my scores. (The recent spacing changes
optimize Lily's *default* spacing, correct?) In fact I've been amazed at
how consistently correct horizontal spacing turns out from one version of
LilyPond to the next when proportional notation is turned on.

[As an aside (but hopefully a helpful one), proportional notation was one
of the first things that brought me to Lily years ago. Han-Wen and I built
the specification for proportional notation together and he did the
implementation (way back in 2005, IIRC). Since that time I've used
proportional notation in every score I've written. (And I've since seen a
number of other composers who favor more-or-less complicated rhythmic
divisions in their own music doing the same.) And I'd like to report
something quite wonderful: in *many* of the first rehearsals of
performances of my music that I've been to, it's been the case that one or
two of the musicians will take me aside during a break and say something
like "this regular spacing thing that you're doing here: it helped me
tremendously when I was trying to figure out how all these rhythms are
working; is there any chance you could convince other composers to do the
same thing." (!) So it was a (very gratifying) surprise to learn that
players have been as much of a fan of the feature over the years as I have.
And, actually, quite unexpected.]

So all of that is just to point out that I may very well not see the
results of recent spacing optimizations for reasons of proportional spacing.


Trevor.


-- 
Trevor Bača
trevorbaca@gmail.com

[trevorbaca_gmail.com, 2013-12-27 07:37:09]

On Fri, Dec 27, 2013 at 1:28 AM, Keith OHara <k-ohara5a5a@oco.net> wrote:

> On Thu, 26 Dec 2013 22:47:41 -0800, Trevor Bača <trevorbaca@gmail.com>
> wrote:
>
>  I suppose it's important to note that all of my scores use proportional
>> notation everywhere. So I imagine that most of the horizontal spacing
>> improvements don't actually impact my scores. (The recent spacing changes
>> optimize Lily's *default* spacing, correct?)
>>
>
> This patch does concern the default method of horizontal spacing.
>
> The bug that this is meant to fix (http://code.google.com/p/
> lilypond/issues/detail?id=3304) can be seen even with
> proportionalNotationDuration, if there are interleaved rhythms on a line
> that is stretched or compressed.  Probably, though, you also set
> 'uniform-stretching', which removes the problem.
>

Correct: I set uniform-stretching every time proportional notation is
turned on.



>
> This patch makes the default spacing case stretch/compress more like it
> does with uniform-stretching, while keeping the detailed spacing
> adjustments in response to things like neighboring stem directions that
> 'uniform-stretching' would normally skip.
>

Nice. I've always thought that sort of hybridization of classical spacing
and proportional spacing would eventually become a new norm.


-- 
Trevor Bača
trevorbaca@gmail.com

[janek, 2013-12-29 20:59:28]

https://codereview.appspot.com/36830045/diff/120001/lily/ledger-line-spanner.cc
File lily/ledger-line-spanner.cc (right):

https://codereview.appspot.com/36830045/diff/120001/lily/ledger-line-spanner....
lily/ledger-line-spanner.cc:103: if  (Staff_symbol::ledger_positions (staff,
pos).empty ())
Nice catch! Please add a regtest for this.  Since the regtest will concern a
very minute difference, i suggest to use staffsize ~50-80 to draw reviewer's
attention.

[Keith, 2013-12-29 21:50:46]

https://codereview.appspot.com/36830045/diff/120001/lily/ledger-line-spanner.cc
File lily/ledger-line-spanner.cc (right):

https://codereview.appspot.com/36830045/diff/120001/lily/ledger-line-spanner....
lily/ledger-line-spanner.cc:103: if  (Staff_symbol::ledger_positions (staff,
pos).empty ())
On 2013/12/29 20:59:28, janek wrote:
> Please add a regtest for this.  Since the regtest will concern a
> very minute difference, i suggest to use staffsize ~50-80 to draw reviewer's
> attention.

I will certainly not.

[janek, 2013-12-29 22:58:32]

On 2013/12/29 21:50:46, Keith wrote:
>
https://codereview.appspot.com/36830045/diff/120001/lily/ledger-line-spanner.cc
> File lily/ledger-line-spanner.cc (right):
> 
>
https://codereview.appspot.com/36830045/diff/120001/lily/ledger-line-spanner....
> lily/ledger-line-spanner.cc:103: if  (Staff_symbol::ledger_positions (staff,
> pos).empty ())
> On 2013/12/29 20:59:28, janek wrote:
> > Please add a regtest for this.  Since the regtest will concern a
> > very minute difference, i suggest to use staffsize ~50-80 to draw reviewer's
> > attention.
> 
> I will certainly not.

Do you mean that you won't add a regtest or won't use big staffsize?
Of course, feel free to use whatever staffsize you see appropriate.

thanks,
Janek

[Keith, 2013-12-30 00:05:07]

On 2013/12/29 22:58:32, janek wrote:

> Do you mean that you won't add a regtest or won't use big staffsize?

I won't add a regression test.  Several tests already change in response to this
change in code.

Some thoughts on the space around the \mark are below:

https://codereview.appspot.com/36830045/diff/120001/lily/note-spacing.cc
File lily/note-spacing.cc (right):

https://codereview.appspot.com/36830045/diff/120001/lily/note-spacing.cc#newc...
lily/note-spacing.cc:95: {
Here is where I kept the extra space for a 'non-musical' column such as that
holding a \mark, for a naturally-spaced line.

https://codereview.appspot.com/36830045/diff/120001/lily/spacing-spanner.cc
File lily/spacing-spanner.cc (right):

https://codereview.appspot.com/36830045/diff/120001/lily/spacing-spanner.cc#n...
lily/spacing-spanner.cc:370: if (Paper_column::is_musical (right_col))
Probably here is where the old code was making the extra space around a
'non-musical' column be extra-compressible, though I'm not sure.

[Keith, 2014-02-17 17:54:41]

Forgot to move one magic number in the reorganization.

The behavior of the line-breaker is strange in the presence of zero-stretchable
lines; maybe the enforcement of minimum stretchability should go there instead.

https://codereview.appspot.com/36830045/diff/120001/lily/note-spacing.cc
File lily/note-spacing.cc (left):

https://codereview.appspot.com/36830045/diff/120001/lily/note-spacing.cc#oldc...
lily/note-spacing.cc:114: ret.set_inverse_stretch_strength (max (0.1, base_space
- increment));
Line-spacing depended on non-zero stretchability, so either line-spacing needs
an update, or this 0.1 needs to be preserved.

https://codereview.appspot.com/36830045/diff/120001/lily/spacing-basic.cc
File lily/spacing-basic.cc (right):

https://codereview.appspot.com/36830045/diff/120001/lily/spacing-basic.cc#new...
lily/spacing-basic.cc:160: ret.set_inverse_stretch_strength (fraction * max
(0.0, (len - min)));
A global minimum stretchability would go here.

[janek, 2014-02-22 14:43:17]

2014-02-17 18:54 GMT+01:00  <k-ohara5a5a@oco.net>:
> Forgot to move one magic number in the reorganization.
>
> The behavior of the line-breaker is strange in the presence of
> zero-stretchable lines; maybe the enforcement of minimum stretchability
> should go there instead.
>
>
> https://codereview.appspot.com/36830045/diff/120001/lily/note-spacing.cc
> File lily/note-spacing.cc (left):
>
>
https://codereview.appspot.com/36830045/diff/120001/lily/note-spacing.cc#oldc...
> lily/note-spacing.cc:114: ret.set_inverse_stretch_strength (max (0.1,
> base_space - increment));
> Line-spacing depended on non-zero stretchability, so either line-spacing
> needs an update, or this 0.1 needs to be preserved.
>
> https://codereview.appspot.com/36830045/diff/120001/lily/spacing-basic.cc
> File lily/spacing-basic.cc (right):
>
>
https://codereview.appspot.com/36830045/diff/120001/lily/spacing-basic.cc#new...
> lily/spacing-basic.cc:160: ret.set_inverse_stretch_strength (fraction *
> max (0.0, (len - min)));
> A global minimum stretchability would go here.


From what i see the patch for issue 3868 does exactly this, so i think
this can be considered done.

thanks!
Janek