Re: vertical spacing of rests

[Peter Selinger]

Phil Holmes wrote:
> 
> ----- Original Message ----- 
> From: "Michael Gerdau" <address@hidden>
> To: <address@hidden>
> Sent: Tuesday, August 25, 2015 3:27 PM
> Subject: Re: vertical spacing of rests
> 
> 
> >> >> \override Rest.voiced-position = 0
> >>
> >> Yes, first available in 2.19.15, courtesy of Keith O'Hara.
> >> Yet to be documented in the NR, I believe.
> >
> > I have used Peter's example code and tried various parameter to
> > voiced-position (see attached). It is my impression that the odd
> > parameters show an...odd (pun intended) behaviour:
> > - some odd parameter show additional horizontal lines
> > - the vertical spacing is not symmetric up/down for odd numbers
> >
> > W/o a documentation I can't judge whether that's intended, but it
> > is at least unexpected.
> >
> > Kind regards,
> > Michael
> > -- 
> > Michael Gerdau       email: address@hidden
> > GPG-keys available on request or at public keyserver
> 
> I would expect it.  If you look at the list of glyphs in the NR, you'll see 
> that the rests include the ledger line.

Did you see his output? What struck me as strange is not that the
rests were shifted in increments of half a staff line - that is to be
expected.

What is strange, however, is that for all rests longer than a quarter,
voiced-position = 3 has the same effect as voiced-position = 2 (i.e.,
they are *not* shifted the final odd step), and voiced-position = 5 has
the same effect as voiced-position = 4. Also, for multi-measure rests,
voiced-position > 2 seems to have no effect whatsoever; they don't go
any higher than voiced-position = 2. 

This behavior seems internally inconsistent. Even if we take for
granted that odd voiced-position shifts are probably not very common,
it is still concerning that there is one behavior for shifts <= 2, a
different behavior for shifts > 2, and finally that the behavior is
different for each kind of rest (<= quarter, >= half, and
multi-measure each behave differently, but only when voiced-position 
> 2).

Perhaps this is a bug in the voiced-position implementation?

-- Peter