Re: vertical spacing of rests

2015-08-25 Thread Peter Selinger 
Phil Holmes wrote:
 
 - Original Message - 
 From: Michael Gerdau m...@qata.de
 To: lilypond-user@gnu.org
 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: m...@qata.de
  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

___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: vertical spacing of rests

2015-08-25 Thread Peter Selinger 
70147pers...@telia.com wrote:
 
 Hello,
 There might be another aspect of positioning (common) rests from 
 different voices. This is beside all the technical solutions presented 
 earlier in this thread. All these work more or less fine for half rests 
 as well as full rests. But when it comes to full rests, in almost every 
 note sheet I have come in contact with, it is printed hanging below 
 staff line number two, not zero, so the half rest and full rest reside 
 in the same white space.
 
 You can not have different definitions for these two rests, except for 
 individual rests (\once \override...). But if you need a full rest, at 
 least I prefer the multi measure rest (R1 instead of r1) as this is 
 automatically centred in the measure. This type of rest also has its own 
 definition of the vertical position. So the definition of centerRests 
 should be:
 
 centerRests = {
 \override Rest.staff-position = ##t
 \override MultiMeasureRest.staff-position = #2
 }
 
 Regarding the voice VoiceTwo, I use to convert the rests into spaces, 
 which is quite simple by means of the global replace function (ctrl+H) 
 in Frescobaldi and the regular expression (Regex) option. Replace //([ 
 ])r([^a-zA-Z]*) with \1s\2)// (remove the quotation marks, they are 
 here just for pointing out the text to insert). For non English works 
 the exclude text (a-zA-Z) might have to be expanded, not to affect 
 comments and similar texts.
 
 Kaj

Hi Kaj,

thanks for pointing this out. Ugh, what an ugly mess. In my opinion,
this is a bug in the font for the full measure rest glyph. The
reference point for that glyph should be so that the glyph is above,
not below, its reference point.

Currently, the behavior is completely inconsistent, as this example
shows:

%
\version 2.19.25


  \compressFullBarRests
  \new Staff {
^default
| r\longa | r\breve | r1 | r2 r4 r8 r8 | R1*4 | R1*2 | R1 |
  }
  \new Staff {
\override Rest.staff-position = #0
\override MultiMeasureRest.staff-position = #0
^staff-position = 0
| r\longa | r\breve | r1 | r2 r4 r8 r8 | R1*4 | R1*2 | R1 |
\revert Rest.staff-position
\revert MultiMeasureRest.staff-position
  }
  \new Staff {
\override Rest.Y-offset = #0
\override MultiMeasureRest.Y-offset = #0
^Y-offset = 0
| r\longa | r\breve | r1 | r2 r4 r8 r8 | R1*4 | R1*2 | R1 |
\revert Rest.Y-offset
\revert MultiMeasureRest.Y-offset
  }

%

All three staffs (see tests8.pdf) contain the same set of rests. 
The default positioning (top staff) is correct both for normal rests
and full-measure rests.

Setting staff-position = 0 (middle staff) works correctly for r1
rests, incorrectly for R1 rests, and correctly for all other rests
(including multi-measure).

Setting Y-offset = 0 (bottom staff) works incorrectly for r1 and
R1 rests, and correctly for all other rests (including multi-measure).

This is inconsistent in several ways, because

* if staff-position is used, whole rests of type r1 and R1 are
  treated differently from each other. Moreover, the R1 type rests
  are positioned incorrectly relative to all other rests.

* if Y-offset is used, both r1 and R1 rests are positioned
  incorrectly relative to all other rests.

* finally, the behavior of staff-position doesn't match that of
  Y-offset, in the case of r1 rests only.

I think the correct long-term solution is to redefine the reference
point of the whole rest glyph so that it is always positioned slightly
above the half-rest glyph. 

Meanwhile, one has to work around this. Here is another incremental
patch to the merge-rests code (from
http://www.mail-archive.com/lilypond-user%40gnu.org/msg69608.html, now
triply patched):

diff --git a/merge-rests.ily b/merge-rests.ily
index 688a37c..f4e3adb 100644
--- a/merge-rests.ily
+++ b/merge-rests.ily
@@ -21,10 +21,10 @@
 % merge a list of rests, by moving the first one to the specified
 % offset, and disabling all the other ones including any associated dots.
 #(define (merge-to-offset rests offset)
-   (ly:grob-set-property! (car rests) 'Y-offset offset)
+   (ly:grob-set-property! (car rests) 'staff-position offset)
(for-each
 (lambda (rest)
-  (ly:grob-set-property! rest 'Y-offset offset)
+  (ly:grob-set-property! rest 'staff-position offset)
   (if (not (null? (ly:grob-object rest 'dot)))
  (ly:grob-set-property! (ly:grob-object rest 'dot) 'stencil #f)))
 (cdr rests)))
@@ -58,7 +58,7 @@
  (lambda (rests)
(if (all-equal rests mmrest-same-length)
(let ((offset (if (eq? (ly:grob-property (car rests)
-'measure-count) 1) 1 0)))
+'measure-count) 1) 2 0)))
  (merge-to-offset rests offset)
 (curr-rests '())
 (rests '()))

It turns out the code was already compensating

Re: vertical spacing of rests

2015-08-25 Thread Peter Selinger 
Trevor Daniels wrote:
 
 selin...@mathstat.dal.ca (Peter Selinger) writes:
 
  this is a true newbie question. I am trying to engrave two polyphonic
  voices on a single staff. Since the two voices have all their rests in
  common, I only want to typeset each rest once, so I use spacer rests
  in the second voice. Still the vertical spacing is such that all the
  rests are put near the top of the staff. I would like them to appear
  in their normal positions.
 
  From the manual, I know two ways to do this. Solution 1 is to enclose
  each rest between \oneVoice and \voiceOne, forcing standard vertical
  spacing:
 
  Solution 2 is to specify an explicit vertical position for each rest.
 
  Neither solution is particularly elegant, as they both require every
  rest to be marked up individually. Is there a global way to turn off
  vertical spacing for rests in a context, i.e., some command whose
  effect would be to make notes behave as with \voiceOne and rests
  behave as with \oneVoice?
 
 I think using
 
 \override Rest.voiced-position = 0
 
 in the voice in which you have rests might do the trick for you.
 
 Trevor

This shows that I should read my emails in the correct order. Thanks
for the tip about voiced-position. This seems to be a new feature in
2.19? 

Unlike staff-position, voiced-position does the right thing for all
rests, including r1 and R1. 

Adding that to my previous example:

%
\version 2.19.25


  \compressFullBarRests
  \new Staff {
\oneVoice
^default for oneVoice
| r\longa | r\breve | r1 | r2 r4 r8 r8 | R1*4 | R1*2 | R1 |
  }
  \new Staff {
\voiceOne
^default for voiceOne
| r\longa | r\breve | r1 | r2 r4 r8 r8 | R1*4 | R1*2 | R1 |
  }
  \new Staff {
\voiceOne   
\override Rest.staff-position = #0
\override MultiMeasureRest.staff-position = #0
^voiceOne with staff-position = 0
| r\longa | r\breve | r1 | r2 r4 r8 r8 | R1*4 | R1*2 | R1 |
\revert Rest.staff-position
\revert MultiMeasureRest.staff-position
  }
  \new Staff {
\voiceOne   
\override Rest.Y-offset = #0
\override MultiMeasureRest.Y-offset = #0
^voiceOne with Y-offset = 0
| r\longa | r\breve | r1 | r2 r4 r8 r8 | R1*4 | R1*2 | R1 |
\revert Rest.Y-offset
\revert MultiMeasureRest.Y-offset
  }
  \new Staff {
\voiceOne   
\override Rest.voiced-position = #0
\override MultiMeasureRest.voiced-position = #0
^voiceOne with voiced-position = 0
| r\longa | r\breve | r1 | r2 r4 r8 r8 | R1*4 | R1*2 | R1 |
\revert Rest.voiced-position
\revert MultiMeasureRest.voiced-position
  }

%

(see attached rests8b.pdf for the output). The fact that
voiced-position works correctly and staff-position doesn't seems to
further underscore the problem with (and possible bug in)
MultiMeasureRest.staff-position.

-- Peter

___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: vertical spacing of rests

2015-08-23 Thread Peter Selinger 
Klaus Blum wrote:
 
 A quick and dirty approach would be to remove the Rest_engraver from the
 second voice:

Yes, this works. 

 If you look for an automatic solution that detects if both voices have the
 same rests, go for the merge-rests-engraver already mentioned by Harm. 
 AFAIK the most recent version is here:
 https://github.com/openlilylib/openlilylib/tree/master/editorial-tools/merge-rests-engraver

The merge-rests-engraver solutions (written by Jay Anderson,
apparently) would clearly be the best solution to the problem, as it
solves the general case (i.e., when some rests are in common and some
are not). I hope that this will become a part of the standard library
in the future. It might even make sense to turn it on by default.

However, a significant problem with Jay's code is that it too doesn't
work correctly with dotted rests.

% 
\version 2.19.25

\include definition.ily

\layout {
  \context { \Staff \consists #merge-rests-engraver }
  \context { \Staff \consists #merge-mmrests-engraver }
}

\new Staff 
  \new Voice {
\relative c'' {
  \voiceOne
  r  c  r  d | r2. e4
  d2. e4
}
  }
  \new Voice {
\relative c'' {
  \voiceTwo
  r4 a8 a8 r4 b8 b8 | r2. c4
  c2. a4
}
  }

%

Here, the definition.ily that I have included is the latest version
from the above github link.  The output (see rests4.pdf) still shows
two dots for each of the merged dotted rests.

So it's the same problem in disguise. It seems that Jay's code, rather
than turning the redundant rests into spacers, prints them all on top
of each other, resulting in the multiple dots since the
Dot_column_engraver doesn't understand that the rests have been
merged.

My guess is that the part of the code that says

  (for-each
   (lambda (rest)
 (ly:grob-set-property! rest 'Y-offset 0))
   rests

should be changed: rather than just setting all the Y-offsets to 0,
all rests except the first one in the list should be disabled
completely, and preferably turned into spacers so that there will be
no dots associated with them.

But I don't know enough about internals to know how to do that.

-- Peter


rests4.pdf
Description: PDF document, version 1.4
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: vertical spacing of rests

2015-08-23 Thread Peter Selinger 
Thomas Morley wrote:
 
 Anyway, if you want to have the dots for rests affected as well, you
 need to adress them through the Rest:
 
 \version 2.19.25
 
 omit-rest-and-dots =
 \override Rest.after-line-breaking =
   #(lambda (grob)
 (ly:grob-set-property! grob 'stencil #f)
 (if (not (null? (ly:grob-object grob 'dot)))
 (ly:grob-set-property! (ly:grob-object grob 'dot) 'stencil #f)))
 
 centerRests = {
   \override Rest.staff-position = #0
 }
 
 \new Staff 
   \new Voice
   \relative c'' {
 \voiceOne
 \omit-rest-and-dots
 r4  c  r  d | r2. e4
 d2. e4
   }
   \new Voice
   \relative c'' {
 \voiceTwo
 \centerRests
 r4 a8 a8 r4 b8 b8 | r2. c4
 c2. a4
   }


Great, that is just the information I was missing in order to fix
Jay's Scheme code. Attached is an updated version of

https://github.com/openlilylib/openlilylib/blob/master/editorial-tools/merge-rests-engraver/definition.ily

that now works correctly for dotted rests (as well as double-dotted
rests, full-measure rests, and so on). I am attaching the full file,
as well as a patch.

I factored the actual rest-merging code into a separate Scheme
function that is shared by both merge-rests-engraver and
merge-mmrests-engraver -- this is probably technically unnecessary
because multi-measure rests are not usually dotted. Still I think it
is better to engrave just one glyph for the merged rests, rather than
a bunch of identical glyphs at the same coordinate. Also, having it as
a separate function is easier to comprehend than deeply-nested Scheme.

Here's an example showing it all in action:

%
\version 2.19.25

\include definition.ily

\layout {
  \context { \Staff \consists #merge-rests-engraver }
  \context { \Staff \consists #merge-mmrests-engraver }
}

\new Staff 
  \new Voice {
\relative c'' {
  \voiceOne
  | r  c  r  d
  | r2. r4
  | r2.. e8
  | r2... e16
  | d2. e4
  | R1
  | c4 c c c
  | R1
}
  }
  \new Voice {
\relative c'' {
  \voiceTwo
  | r4 a8 a8 r4 b8 b8
  | r2. c4
  | r2.. c8
  | r2... c16
  | c2. a4
  | R1*3
}
  }

%

See rests5.pdf for the output.

If you all agree that this patch works correctly, hopefully someone
with commit privileges can merge it into git?

Thanks, -- Peter
--- definition.ily-orig 2015-08-23 16:16:13.428995010 -0300
+++ definition.ily  2015-08-23 16:13:43.995254184 -0300
@@ -18,6 +18,17 @@
(or (has-one-or-less lst)
(and (pred (car lst) (cadr lst)) (all-equal (cdr lst) pred
 
+% merge a list of rests, by moving the first one to the specified
+% offset, and disabling all the other ones including any associated dots.
+#(define (merge-to-offset rests offset)
+   (ly:grob-set-property! (car rests) 'Y-offset offset)
+   (for-each
+(lambda (rest)
+  (ly:grob-set-property! rest 'stencil #f)
+  (if (not (null? (ly:grob-object rest 'dot)))
+ (ly:grob-set-property! (ly:grob-object rest 'dot) 'stencil #f)))
+(cdr rests)))
+
 #(define merge-rests-engraver
(lambda (context)
  (let ((rest-same-length
@@ -30,10 +41,7 @@
  (stop-translation-timestep . ,(lambda (trans)
  (if (and (has-at-least-two
rests) (all-equal rests 
rest-same-length))
- (for-each
-  (lambda (rest)
-(ly:grob-set-property! rest 
'Y-offset 0))
-  rests
+ (merge-to-offset rests 0
  (acknowledgers
   (rest-interface . ,(lambda (engraver grob source-engraver)
(if (eq? 'Rest (assoc-ref
@@ -51,10 +59,7 @@
(if (all-equal rests mmrest-same-length)
(let ((offset (if (eq? (ly:grob-property (car rests)
 'measure-count) 1) 1 0)))
- (for-each
-  (lambda (rest) (ly:grob-set-property! rest
-   'Y-offset offset))
-  rests)
+ (merge-to-offset rests offset)
 (curr-rests '())
 (rests '()))
`((start-translation-timestep . ,(lambda (trans)


rests5.pdf
Description: PDF document, version 1.4
\version 2.18.0

\header {
  snippet-title = merge-rests-engraver
  snippet-author = Jay Anderson
  snippet-source =
http://www.mail-archive.com/lilypond-user%40gnu.org/msg69608.html;
  snippet-description = \markup {
Merge rests of equal duration in different voice
  }
  tags = merge, rest, rests, voice, voices
  status = ready
}

#(define has-one-or-less (lambda (lst) (or (null? lst) (null? (cdr lst)
#(define has-at-least-two

Re: vertical spacing of rests

2015-08-23 Thread Peter Selinger 
I tried this on the two test cases, and there seems to be no
difference between the behavior of empty-stencil and #f (i.e., it
doesn't work). 

-- Peter

Paul Morris wrote:
 
  On Aug 23, 2015, at 4:29 PM, Peter Selinger selin...@mathstat.dal.ca wr=
 ote:
 =20
  -  (ly:grob-set-property! rest 'stencil #f)
  +  (ly:grob-set-property! rest 'Y-offset offset)
 
 I wonder if this might work instead:
 
   (ly:grob-set-property! rest 'stencil empty-stencil)
 
 Just an untested idea=E2=80=A6
 
 -Paul=
 


___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: vertical spacing of rests

2015-08-23 Thread Peter Selinger 
Point taken. So I was wrong: it's not possible to remove the stencils
for redundant rests, or else fermatas in that voice don't have
anything to attach to. So the behavior of Jay's original code was the
better one, i.e., to force all the redundant rests to the same
coordinates, but to retain their glyphs. In addition, dots should be
removed from all but one of them.

Another bug was also present in my previous example (rests5.pdf from
my last email): the two quarter rests in the first measure weren't
vertically centered. I am not entirely sure why this happens, and why
it only affects quarter rests, but the following patch-to-my-patch
happens to fix both problems at the same time.

--- /tmp/definition.ily 2015-08-23 17:15:54.591816683 -0300
+++ definition.ily  2015-08-23 17:15:29.044253078 -0300
@@ -24,7 +24,7 @@
(ly:grob-set-property! (car rests) 'Y-offset offset)
(for-each
 (lambda (rest)
-  (ly:grob-set-property! rest 'stencil #f)
+  (ly:grob-set-property! rest 'Y-offset offset)
   (if (not (null? (ly:grob-object rest 'dot)))
  (ly:grob-set-property! (ly:grob-object rest 'dot) 'stencil #f)))
 (cdr rests)))

This seems to work fine with your example as well as mine. Of course
further testing may be needed to ensure that it works in all other
cases. Apart from an equivalent refactoring of the Scheme code, the
only two lines that now differ from Jay's version are the two lines
(if (not (null? ... #f)).

I'm also attaching the patched file definition.ly as a whole, for ease
of reference.

-- Peter

Thomas Morley wrote:
 
 2015-08-23 21:21 GMT+02:00 Peter Selinger selin...@mathstat.dal.ca:
  Thomas Morley wrote:
 
  Anyway, if you want to have the dots for rests affected as well, you
  need to adress them through the Rest:
 
  \version 2.19.25
 
  omit-rest-and-dots =
  \override Rest.after-line-breaking =
#(lambda (grob)
  (ly:grob-set-property! grob 'stencil #f)
  (if (not (null? (ly:grob-object grob 'dot)))
  (ly:grob-set-property! (ly:grob-object grob 'dot) 'stencil #f)))
 
  centerRests = {
\override Rest.staff-position = #0
  }
 
  \new Staff 
\new Voice
\relative c'' {
  \voiceOne
  \omit-rest-and-dots
  r4  c  r  d | r2. e4
  d2. e4
}
\new Voice
\relative c'' {
  \voiceTwo
  \centerRests
  r4 a8 a8 r4 b8 b8 | r2. c4
  c2. a4
}
 
 
  Great, that is just the information I was missing in order to fix
  Jay's Scheme code. Attached is an updated version of
 
  https://github.com/openlilylib/openlilylib/blob/master/editorial-tools/merge-rests-engraver/definition.ily
 
  that now works correctly for dotted rests (as well as double-dotted
  rests, full-measure rests, and so on). I am attaching the full file,
  as well as a patch.
 
  I factored the actual rest-merging code into a separate Scheme
  function that is shared by both merge-rests-engraver and
  merge-mmrests-engraver -- this is probably technically unnecessary
  because multi-measure rests are not usually dotted. Still I think it
  is better to engrave just one glyph for the merged rests, rather than
  a bunch of identical glyphs at the same coordinate. Also, having it as
  a separate function is easier to comprehend than deeply-nested Scheme.
 
 
 Hi Peter,
 
 glad I could help.
 Though, reading up the whole thread I got some concerns and did some
 further testing.
 
 Try with your updated engravers:
 
 \layout {
   \context { \Staff \consists #merge-rests-engraver }
   \context { \Staff \consists #merge-mmrests-engraver }
   \compressFullBarRests
 }
 
 \new Staff 
   \new Voice {
   \voiceOne
   R1*3^\fermataMarkup
   }
   \new Voice {
   \voiceTwo
   R1*3_\fermataMarkup
   }
 
 
 Looks some more work has to be done ...
 
 png attached
 
 
  If you all agree that this patch works correctly, hopefully someone
  with commit privileges can merge it into git?
 
 Afaik, there are still some problems with scheme-engravers in the source-code.
 But I may be wrong here.
 
 
 Cheers,
   Harm
\version 2.18.0

\header {
  snippet-title = merge-rests-engraver
  snippet-author = Jay Anderson
  snippet-source =
http://www.mail-archive.com/lilypond-user%40gnu.org/msg69608.html;
  snippet-description = \markup {
Merge rests of equal duration in different voice
  }
  tags = merge, rest, rests, voice, voices
  status = ready
}

#(define has-one-or-less (lambda (lst) (or (null? lst) (null? (cdr lst)
#(define has-at-least-two (lambda (lst) (not (has-one-or-less lst
#(define (all-equal lst pred)
   (or (has-one-or-less lst)
   (and (pred (car lst) (cadr lst)) (all-equal (cdr lst) pred

% merge a list of rests, by moving the first one to the specified
% offset, and disabling all the other ones including any associated dots.
#(define (merge-to-offset rests offset)
   (ly:grob-set-property! (car rests) 'Y-offset offset)
   (for-each
(lambda (rest)
  (ly:grob-set-property! rest 'Y-offset offset

question about putting music expressions in sequence

2015-08-22 Thread Peter Selinger 
Hello,

I have a question about using lyrics with automatic syllable
durations, when putting music expressions in sequence.

The Learning Manual states: Putting a group of music expressions
(e.g. notes) in braces means that they are in sequence (i.e. each one
follows the previous one). The result is another music expression.

I have a piece consistsing of several verses that must be engraved
individually (each verse has a different melody and accompaniment).
I'd like to arrange the input file so that the data is grouped by
verse (rather than by voice). I was able to make this work using
sequencing like this (see test1.pdf):

  \version 2.18.2
  
  {
% First verse   

  \new Voice = up \relative c' { e f g a }
  \new Lyrics = lyrics \lyricmode { Words to first verse }
  \new Voice = down \relative c' { c d e f }

% Seconds verse 

  \context Voice = up \relative c' { f g a b }
  \context Lyrics = lyrics \lyricmode { Words to next verse }
  \context Voice = down \relative c' { d e f g }

  }

However, this only works as long as I enter manual syllable
durations. If I try to use automatic syllable durations, everything
breaks (see test2.pdf):

  \version 2.18.2
  
  {
% First verse 

  \new Voice = up \relative c' { e f g a }
  \new Lyrics = lyrics \lyricsto up { Words to first verse }
  \new Voice = down \relative c' { c d e f }

% Seconds verse   

  \context Voice = up \relative c' { f g a b }
  \context Lyrics = lyrics \lyricsto up { Words to next verse }
  \context Voice = down \relative c' { d e f g }

  }

Not only does the second set of lyrics generate an error message, but
also the notes to the second verse are not typeset at all, and an
extra (empty) pair of staves is generated.

Is there a way to make this work? (I realize that I could put all the
information into variables, and rearrange the expression to be grouped
by voice rather than verse. However, I am looking for a way to make
the above grouping work).

Thanks, -- Peter


test2.pdf
Description: PDF document, version 1.4


test1.pdf
Description: PDF document, version 1.4
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: vertical spacing of rests

2015-08-22 Thread Peter Selinger 
Wait, this didn't quite work:

hideRests = {
  \override Rest.transparent = ##t
}

It almost produces the correct output, but it generates a million
warnings (one for each rest) about a rest collision that could not
be resolved. I guess a transparent rest is not the same as a spacer
rest - even though it is invisible, it can still collide. 

Also, strangely, the dots on the dotted rests are still visible, even
when the rests themselves are transparent.

Is there a property similar to Rest.transparent that will remove the
rest (effectively turning it into a spacer rest), rather than just
making it invisible?

-- Peter

Peter Selinger wrote:
 
 Thanks for your replies. That's awesome. I think I will also define a
 command \hideRests, so that I don't have to manually convert all the
 rests to spacer rests - this might be handy if I later decide to use
 one staff per voice.
 
 centerRests = {
   \override Rest.staff-position = #0
 }
 
 hideRests = {
   \override Rest.transparent = ##t
 }
 
 \new Staff 
   \new Voice \relative c'' {
 \voiceOne 
 \centerRests
 r4 c r d
   }
   \new Voice \relative c'' {
 \voiceTwo 
 \hideRests
 r4 a8 a8 r4 b8 b8
   }
 
 
 By the way, properties such as staff-position are not included in the
 index of the Notation Manual (though they do appear in the index of
 the Learning Manual). I had to search the whole document to find these
 properties in Appendix A.17. Would it make sense to include them in
 the index?
 
 -- Peter
 
 Klaus Blum wrote:
  
  Peter Selinger wrote
   Is there a global way to turn off
   vertical spacing for rests in a context, i.e., some command whose
   effect would be to make notes behave as with \voiceOne and rests
   behave as with \oneVoice?
  
  Hi Peter, 
  
  yes, there is:
   \override Rest.staff-position = #0
  but you have to apply it once for every voice.
  
  Cheers, 
  Klaus
  
  
  %-
  \version 2.19.25
  
  centerRests = {
\override Rest.staff-position = #0
  }
  
  \new Staff 
\new Voice
\relative c'' {
  \voiceOne  % you don't need a pair of braces here
  \centerRests
  r  c  r  d
}
\new Voice
\relative c'' {
  \voiceTwo
  \centerRests
  r4 a8 a8 r4 b8 b8
}
  
  %-
  
  
  
  
  --
  View this message in context: 
  http://lilypond.1069038.n5.nabble.com/vertical-spacing-of-rests-tp179947p179950.html
  Sent from the User mailing list archive at Nabble.com.
  
  ___
  lilypond-user mailing list
  lilypond-user@gnu.org
  https://lists.gnu.org/mailman/listinfo/lilypond-user
  
 
 
 ___
 lilypond-user mailing list
 lilypond-user@gnu.org
 https://lists.gnu.org/mailman/listinfo/lilypond-user
 


___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: vertical spacing of rests

2015-08-22 Thread Peter Selinger 
Klaus,

your code snippet does not work correctly if some of the rests are
dotted (see attached for the output). It's a bit of a mystery to me
why this happens. 

-- Peter

%
\version 2.19.25

centerRests = {
  \override Rest.staff-position = #0
}

\new Staff 
  \new Voice
  \relative c'' {
\voiceOne
\centerRests
r  c  r  d | r2. e4
  }
  \new Voice
  \relative c'' {
\voiceTwo
\centerRests
r4 a8 a8 r4 b8 b8 | r2. c4
  }

%



Klaus Blum wrote:
 
 Peter Selinger wrote
  Is there a global way to turn off
  vertical spacing for rests in a context, i.e., some command whose
  effect would be to make notes behave as with \voiceOne and rests
  behave as with \oneVoice?
 
 Hi Peter, 
 
 yes, there is:
  \override Rest.staff-position = #0
 but you have to apply it once for every voice.
 
 Cheers, 
 Klaus
 
 
 %-
 \version 2.19.25
 
 centerRests = {
   \override Rest.staff-position = #0
 }
 
 \new Staff 
   \new Voice
   \relative c'' {
 \voiceOne  % you don't need a pair of braces here
 \centerRests
 r  c  r  d
   }
   \new Voice
   \relative c'' {
 \voiceTwo
 \centerRests
 r4 a8 a8 r4 b8 b8
   }
 
 %-
 
 
 
 
 --
 View this message in context: 
 http://lilypond.1069038.n5.nabble.com/vertical-spacing-of-rests-tp179947p179950.html
 Sent from the User mailing list archive at Nabble.com.
 
 ___
 lilypond-user mailing list
 lilypond-user@gnu.org
 https://lists.gnu.org/mailman/listinfo/lilypond-user
 



rests1.pdf
Description: PDF document, version 1.4
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: vertical spacing of rests

2015-08-22 Thread Peter Selinger 
Thanks for your replies. That's awesome. I think I will also define a
command \hideRests, so that I don't have to manually convert all the
rests to spacer rests - this might be handy if I later decide to use
one staff per voice.

centerRests = {
  \override Rest.staff-position = #0
}

hideRests = {
  \override Rest.transparent = ##t
}

\new Staff 
  \new Voice \relative c'' {
\voiceOne 
\centerRests
r4 c r d
  }
  \new Voice \relative c'' {
\voiceTwo 
\hideRests
r4 a8 a8 r4 b8 b8
  }


By the way, properties such as staff-position are not included in the
index of the Notation Manual (though they do appear in the index of
the Learning Manual). I had to search the whole document to find these
properties in Appendix A.17. Would it make sense to include them in
the index?

-- Peter

Klaus Blum wrote:
 
 Peter Selinger wrote
  Is there a global way to turn off
  vertical spacing for rests in a context, i.e., some command whose
  effect would be to make notes behave as with \voiceOne and rests
  behave as with \oneVoice?
 
 Hi Peter, 
 
 yes, there is:
  \override Rest.staff-position = #0
 but you have to apply it once for every voice.
 
 Cheers, 
 Klaus
 
 
 %-
 \version 2.19.25
 
 centerRests = {
   \override Rest.staff-position = #0
 }
 
 \new Staff 
   \new Voice
   \relative c'' {
 \voiceOne  % you don't need a pair of braces here
 \centerRests
 r  c  r  d
   }
   \new Voice
   \relative c'' {
 \voiceTwo
 \centerRests
 r4 a8 a8 r4 b8 b8
   }
 
 %-
 
 
 
 
 --
 View this message in context: 
 http://lilypond.1069038.n5.nabble.com/vertical-spacing-of-rests-tp179947p179950.html
 Sent from the User mailing list archive at Nabble.com.
 
 ___
 lilypond-user mailing list
 lilypond-user@gnu.org
 https://lists.gnu.org/mailman/listinfo/lilypond-user
 


___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

vertical spacing of rests

2015-08-22 Thread Peter Selinger 
Hello again,

this is a true newbie question. I am trying to engrave two polyphonic
voices on a single staff. Since the two voices have all their rests in
common, I only want to typeset each rest once, so I use spacer rests
in the second voice. Still the vertical spacing is such that all the
rests are put near the top of the staff. I would like them to appear
in their normal positions.

From the manual, I know two ways to do this. Solution 1 is to enclose
each rest between \oneVoice and \voiceOne, forcing standard vertical
spacing:

  \version 2.19.25
  
  \new Staff 
\new Voice \relative c'' {
  \voiceOne {
\oneVoice r \voiceOne c \oneVoice r \voiceOne d
%%%
  }
}
\new Voice \relative c'' {
  \voiceTwo {
s4 a8 a8 s4 b8 b8
  }
}
  

Solution 2 is to specify an explicit vertical position for each rest.

  \version 2.19.25
  
  \new Staff 
\new Voice \relative c'' {
  \voiceOne {
b4\rest c b\rest \voiceOne d

  }
}
\new Voice \relative c'' {
  \voiceTwo {
s4 a8 a8 s4 b8 b8
  }
}
  

Neither solution is particularly elegant, as they both require every
rest to be marked up individually. Is there a global way to turn off
vertical spacing for rests in a context, i.e., some command whose
effect would be to make notes behave as with \voiceOne and rests
behave as with \oneVoice?

Thanks, -- Peter


___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: question about putting music expressions in sequence

2015-08-22 Thread Peter Selinger 
Dear David, Phil, and Thomas,

thanks for your quick replies! I'm surprised that as a newbie, I was
able to find a bug in less than 24 hours of using Lilypond. But it's
fortunate that it has already been fixed!

I had double-checked that 2.18.2 is the most current version by
checking that it is the version described in the documentation:
http://www.lilypond.org/website/manuals.html

But I had forgotten that there is also an unstable release. 

Great, thanks again for your help! I'll report back in case I run into
any more problems. -- Peter

David Kastrup wrote:
 
 Phil Holmes m...@philholmes.net writes:
 
  It looks to me that you have posted the same example twice, both of
  which work as planned, and neither of which provides the output you've
  attached. Please check.
 
 Well, let's see:
 
 First version:
 
   \new Lyrics = lyrics \lyricmode { Words to first verse }
 [...]
   \context Lyrics = lyrics \lyricmode { Words to next verse }
 
 Second version:
 
   \new Lyrics = lyrics \lyricsto up { Words to first verse }
 [...]
   \context Lyrics = lyrics \lyricsto up { Words to next verse }
 
 Looks different to me.  Also, either version:
 
  \version 2.18.2
 
 And indeed, version 2.18.2 falls flat rather uglily on the second
 version while current LilyPond versions have no problem with it.
 
 This is issue 2010
 URL:https://code.google.com/p/lilypond/issues/detail?id=2010, fixed in
 version 2.19.16 but likely not in a manner where this example would
 work.  I suspect this example would require the fix from issue 4419
 URL:https://code.google.com/p/lilypond/issues/detail?id=4419 in order
 not to be stopped short, meaning a version of LilyPond of 2.19.23 or
 later.
 
  Is there a way to make this work? (I realize that I could put all the
  information into variables, and rearrange the expression to be
  grouped by voice rather than verse. However, I am looking for a way
  to make the above grouping work).
 
 Upgrade.  The respective fixes are in C++ code so there is no way you
 can just patch up some parts of LilyPond.
 
 -- 
 David Kastrup
 


___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: question about putting music expressions in sequence

2015-08-22 Thread Peter Selinger 
Hi Phil,

I just double-checked: 

* my two posted code snippets are not the same (the first uses
  \lyricmode and the second uses \lyricsto, as I had mentioned in the
  accompanying text).

* the two posted code snippets produce exactly the respective output I
  attached.

I'm using GNU LilyPond 2.18.2, as included in the current Ubuntu
distribution.

Could you double-check that you really can't reproduce the output? 

Thanks, -- Peter


Phil Holmes wrote:
 
 - Original Message - 
 From: Peter Selinger selin...@mathstat.dal.ca
 To: lilypond-user@gnu.org
 Sent: Saturday, August 22, 2015 3:32 PM
 Subject: question about putting music expressions in sequence
 
 
  Hello,
 
  I have a question about using lyrics with automatic syllable
  durations, when putting music expressions in sequence.
 
  The Learning Manual states: Putting a group of music expressions
  (e.g. notes) in braces means that they are in sequence (i.e. each one
  follows the previous one). The result is another music expression.
 
  I have a piece consistsing of several verses that must be engraved
  individually (each verse has a different melody and accompaniment).
  I'd like to arrange the input file so that the data is grouped by
  verse (rather than by voice). I was able to make this work using
  sequencing like this (see test1.pdf):
 
   \version 2.18.2
 
   {
 % First verse
 
   \new Voice = up \relative c' { e f g a }
   \new Lyrics = lyrics \lyricmode { Words to first verse }
   \new Voice = down \relative c' { c d e f }
 
 % Seconds verse
 
   \context Voice = up \relative c' { f g a b }
   \context Lyrics = lyrics \lyricmode { Words to next verse }
   \context Voice = down \relative c' { d e f g }
 
   }
 
  However, this only works as long as I enter manual syllable
  durations. If I try to use automatic syllable durations, everything
  breaks (see test2.pdf):
 
   \version 2.18.2
 
   {
 % First verse
 
   \new Voice = up \relative c' { e f g a }
   \new Lyrics = lyrics \lyricsto up { Words to first verse }
   \new Voice = down \relative c' { c d e f }
 
 % Seconds verse
 
   \context Voice = up \relative c' { f g a b }
   \context Lyrics = lyrics \lyricsto up { Words to next verse }
   \context Voice = down \relative c' { d e f g }
 
   }
 
  Not only does the second set of lyrics generate an error message, but
  also the notes to the second verse are not typeset at all, and an
  extra (empty) pair of staves is generated.
 
  Is there a way to make this work? (I realize that I could put all the
  information into variables, and rearrange the expression to be grouped
  by voice rather than verse. However, I am looking for a way to make
  the above grouping work).
 
 It looks to me that you have posted the same example twice, both of which 
 work as planned, and neither of which provides the output you've attached. 
 Please check.
 
 --
 Phil Holmes 
 


___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user