Re: Controlling vertical spacing exactly - mini HOWTO

2007-01-30 Thread Trevor Bača

On 1/18/07, Graham Percival [EMAIL PROTECTED] wrote:

Trevor Bača wrote:
 The following might be of interest to folks using proportional
 notation. If there's any general interest (of if Graham wants it to be
 so) then I'll retype the following as an addition to 11.3.4
 Controlling spacing of individual systems.

Definitely.  I don't think you need to make many changes; I'd get rid of
the capital-letter sections at the end, though.  Or integrate that
material into the rest of stuff.

In the future, it's safest if you cc'd potential doc stuff to the -devel
list, since I don't read -user in any great detail these days.


Hi Graham  Max (and everyone),

I've been reading through chapter 11 on vertical spacing and getting
some vertical spacing examples ready for the manual.

And on reflection I think I've now figured out why it's been tricky
for me to get a good conceptual handle on vertical spacing. So I'd
like to bounce two ideas off of you guys and see if the way that I'm
thinking about the problem makes sense.

1. First, it seems that there are two *different* models for
controlling vertical spacing, which we might term permissive and
strict, respectively. The first model corresponds roughly to chapers
11.3.1 and 11.3.3, and concerns overrides to VerticalAxisGroup and
settings in the paper block like

 \override Staff.VerticalAxisGroup #'minimum-Y-extent = #'(-3 . 3)

 \paper {
between-system-space = 1.5\cm
between-system-padding = #1
ragged-bottom=##f
ragged-last-bottom=##f
 }

My analysis of this type of vertical spacing control is that what
we're really doing here is mostly setting *padding* in different
guises. We're not really saying this staff should be so far away from
this other staff; and then this system should be so far away from this
other system further down the page. Instead we're saying I want at
least this much padding between these staves or between these systems;
beyond those padding specifications, just let Lily figure out what to
do. So we might term this padding-based way of thinking about
vertical spacing something like permissive. And an interesting
characteristic of this way of tweaking vertical spacing is that -- I
think -- you can *not* cause staves or systems to *overlap*. And this
relates to the primary disadvantage of using VerticalAxisGroup
overrides (and paper and margin adjustments) to control vertical
spacing: it can sometimes seem frustratingly difficult to draw staves
or systems close enough together.[1]

[1] Feel free to contradict me here; Is it possible to cause staff- or
system-overlaps using the commands given in 11.1 and 11.3? And maybe I
was alone in my experience of feeling frustrated trying to game
VerticalAxisGroup to move staves closer together.

The second model for controlling vertical spacing centers around
NonMusicalPaperColumn line-break-system-details, is very lightly
touched on in 11.4, and concerns commands like:

\overrideProperty
#Score.NonMusicalPaperColumn
#'line-break-system-details
#'((alignment-offsets . (0 -5 -20)))

   \overrideProperty #Score.NonMusicalPaperColumn
   #'line-break-system-details #'((Y-offset . 20)
(alignment-offsets . (0 -15)))

 \overrideProperty
 #Score.NonMusicalPaperColumn
 #'line-break-system-details
 #'((fixed-alignment-extra-space . 15))

These overrides to line-break-system-details might be termed the
strict (or control freak) approach to vertical spacing (as opposed
to the traditional, more permissive approach) because what we're
doing with these settings is saying I want control here; start this
staff at exactly this vertical offset and then start this staff at
this vertical offset and finally put this staff at this vertical
offset; the vertical spacing that results is whatever results and I
don't even care if there are overlaps; just do what I say; oh and same
with the systems, too. If we want to be precise, we might even point
out that these overrides to line-break-system-details don't so much
control the spacing *between* staves and systems so much as the exact
vertical *positions at which* staves and systems begin on the page
(with the vertical spacing just a side-effect of these explicit
positioning commands).

The advantages and disadvantages to the line-break-system-details
approach to vertical spacing are pretty much what we would expect
versus the VerticalAxisGroup approach: line-break-system-details makes
it extremely easy to draw staves and system quite close to each other
but does indeed allow for staff or system overprinting.

So, to sum up this first point: it seems to me that there are two
different approaches to controlling vertical spacing: by
VerticalAxisGroup + paper settings or else by
line-break-system-details. These two methods aren't so much at odds
with each other as in a kind of cascade relationship: you can make
whatever VerticalAxisGroup + paper settings you want, but any
overrides to line-break-system-dettails will 

Re: Controlling vertical spacing exactly - mini HOWTO

2007-01-30 Thread Daniel Johnson
 Hi Graham  Max (and everyone),

 I've been reading through chapter 11 on vertical spacing and getting
 some vertical spacing examples ready for the manual.

 And on reflection I think I've now figured out why it's been tricky
 for me to get a good conceptual handle on vertical spacing. So I'd
 like to bounce two ideas off of you guys and see if the way that I'm
 thinking about the problem makes sense.

 1. First, it seems that there are two *different* models for
 controlling vertical spacing, which we might term permissive and
 strict, respectively. The first model corresponds roughly to chapers
 11.3.1 and 11.3.3, and concerns overrides to VerticalAxisGroup and
 settings in the paper block like

   \override Staff.VerticalAxisGroup #'minimum-Y-extent = #'(-3 . 3)

   \paper {
  between-system-space = 1.5\cm
  between-system-padding = #1
  ragged-bottom=##f
  ragged-last-bottom=##f
   }

snip

Hi Trevor,

There is a way I've found to make the VerticalAxisGroup stuff strict.  It
roughly involves the following:

\override Staff.VerticalAxisGroup #'minimum-Y-extent = ##f
\override Staff.VerticalAxisGroup #'Y-extent = #'(-3 . 3)

Sometime in the 2.7 dev cycle this started to cause misaligned beams, and
someone was kind enough to point me in the direction of a fix, which I've
incorporated into a Scheme function.  I don't know if this bug still
exists, but I've just gotten used to including this function whenever I
want to set absolute staff distances (for two-staff choral scores, for
example). I can verify that it works with the 2.10 series.

Usage:
\include set-y-extent.ly
\new Staff {
  \setYextent #'(-3 . 3)
  a' b' c'' d''
}

And the function itself:

setYextent = #(define-music-function (parser location yExtent)
 (pair?)
  (make-music
'SequentialMusic
'elements
(list (make-music
'ContextSpeccedMusic
'property-operations
'()
'context-type
'Staff
'element
(make-music
  'OverrideProperty
  'grob-property-path
  (list (quote minimum-Y-extent))
  'grob-value
  #f
  'symbol
  'VerticalAxisGroup
  'pop-first
  #t))
  (make-music
'ContextSpeccedMusic
'property-operations
'()
'context-type
'Staff
'element
(make-music
  'OverrideProperty
  'grob-property-path
  (list (quote Y-extent))
  'grob-value
  (lambda (g)
   (begin
 (ly:axis-group-interface::height g)
 yExtent))
  'symbol
  'VerticalAxisGroup
  'pop-first
  #t)



___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel


Re: Controlling vertical spacing exactly - mini HOWTO

2007-01-30 Thread Trevor Bača

On 1/30/07, Daniel Johnson [EMAIL PROTECTED] wrote:

 Hi Graham  Max (and everyone),

 I've been reading through chapter 11 on vertical spacing and getting
 some vertical spacing examples ready for the manual.

 And on reflection I think I've now figured out why it's been tricky
 for me to get a good conceptual handle on vertical spacing. So I'd
 like to bounce two ideas off of you guys and see if the way that I'm
 thinking about the problem makes sense.

 1. First, it seems that there are two *different* models for
 controlling vertical spacing, which we might term permissive and
 strict, respectively. The first model corresponds roughly to chapers
 11.3.1 and 11.3.3, and concerns overrides to VerticalAxisGroup and
 settings in the paper block like

   \override Staff.VerticalAxisGroup #'minimum-Y-extent = #'(-3 . 3)

   \paper {
  between-system-space = 1.5\cm
  between-system-padding = #1
  ragged-bottom=##f
  ragged-last-bottom=##f
   }

snip

Hi Trevor,

There is a way I've found to make the VerticalAxisGroup stuff strict.  It
roughly involves the following:

\override Staff.VerticalAxisGroup #'minimum-Y-extent = ##f
\override Staff.VerticalAxisGroup #'Y-extent = #'(-3 . 3)


Hi Daniel,

Interesting. Hmm ...

So can we use the minimum-Y-extent = ##f setting to cause actual
overprinting between adjacent staves? Here's an example going the
line-break-system-details route that's triggered by there being only
three units offset between the two staves:

%%% BEGIN OVERPRINT %%%

\version 2.11.14

\layout { indent = #0 }

\new Score \with {
  \override NonMusicalPaperColumn
  #'line-break-system-details = #'((alignment-offsets . (0 -3)))
} 
  \new Staff {
 \repeat unfold 18 { c'4 c'4 c'4 c'4 }
  }
  \new Staff {
 \repeat unfold 18 { d'4 d'4 d'4 d'4 }
  }




%%% END %%%

Can we reproduce this example with VerticalAxisGroup? I'm trying but
seem to be unable to get the settings right ...

I'm curious not because we'd ever want to see anything so ugly in
actual score but more to see if there's a difference in the amount of,
er, strictness between the minimum-Y-extent = ##f way and the
line-break-system-details way.


--
Trevor Bača
[EMAIL PROTECTED]
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel


Re: Controlling vertical spacing exactly - mini HOWTO

2007-01-30 Thread Trevor Bača

On 1/30/07, Trent Johnston [EMAIL PROTECTED] wrote:

Hi Trevor and all,

I've been watching your thread on controlling vertical space as I'm very
interested in this area.

Joe Neeman gave me the following advice early in January of putting the
strict control into the layout blook as follows:

\layout {
 \context { \Score \override NonMusicalPaperColumn
#'line-break-system-details = #'((alignment-offsets . (0 -15 -30 )))  }
}

he went on to say:

If you want to change it mid-piece, you can use \override instead of
\overrideProperty, but I think you have to do the \override one timestep
before you want it to take effect.


Hi Trent,

Ah, right. I'd forgotten that you can \override the
NonMusicalPaperColumn grob globally for an entire context (which is
why all the examples I'd put into the thread so far show the
NonMusicalPaperColumn grob being overriden with \overrideProperty in
the middle of note input).

(FWIW, I think the same breadcrumb appears in the
alignment-vertical-spacing.ly reg test comments, viz: For technical
reasons, overrideProperty has to be used for setting properties on
individual object. \override in a \context block may still be used for
global overrides.)

I'm sure you already know that context settings in the layout-block
are equivalent to context settings in the with-block. But here's an
example just in case:

%%% WITH-BLOCK BEGIN %%%

\version 2.11.14

\layout { indent = #0 }

\new Score \with {
  \override NonMusicalPaperColumn
  #'line-break-system-details = #'((alignment-offsets . (0 -15)))
} 
  \new Staff {
 \repeat unfold 18 { c'4 c'4 c'4 c'4 }
  }
  \new Staff {
 \repeat unfold 18 { d'4 d'4 d'4 d'4 }
  }




%%% END %%%

I'm a huge fan of with-blocks :-)





P.S. The one thing I can't figure out is what the numbers refer to. Are they
staff spaces as in what you would using in overriding minimum-Y-extent? I
seem to be using larger numbers than what I would use when setting
minimum-Y-extent.


In an earlier part of the thread Max wrote this:


Maybe it would also be a good idea to mention that the numbers are

interpreted as multiples of the distance between adjacent staff lines
and that positive numbers move the staves/lyrics up and negative values
move them down (better to read it in the docs than having to cook up an
example to find out by trial and error).

I haven't tested this myself, but it certainly sounds right.


--
Trevor Bača
[EMAIL PROTECTED]
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel