lilypond-user
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: barNumberCheck with repeats


From: David Kastrup
Subject: Re: barNumberCheck with repeats
Date: Wed, 09 Nov 2016 10:05:14 +0100
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/25.1.50 (gnu/linux)

Robert Schmaus <address@hidden> writes:

> Dear Ponderers,
>
> I've got the following question about a problem involving bar number
> checks and repeats. When I'm engraving a bigger project, I find it
> useful to employ bar number checks. I also find it very useful to use
> the technique of having seperate layout and midi score blocks, the
> latter with \unfoldRepeats, as described here:
> http://lilypond.org/doc/v2.18/Documentation/notation/repeats-in-midi
>
> However, if there are "repeat volta" sections present in the score,
> all bar number checks seem to be off in the midi generation. Consider
> the following snippet:
>
> %%%%%%%%%%%%%%%%%%%
> \version "2.19.35"
>
> music = \relative c'' {
>
>   \barNumberCheck #1
>   c c c c
>
>   \barNumberCheck #2
>   \repeat volta 2 { d d d d }
>
>   \barNumberCheck #3
>   e e e e
> }
>
> \score {
>   \unfoldRepeats
>   \music
>   \layout{}
> }
> %%%%%%%%%%%%%%%%%%%
>
> If unfoldRepeat is used in the score block, the bar number check
> (sensibly) expects the last bar to be bar # 4, not 3.
>
> As workaround, I could leave out \unfoldRepeats while creating the
> score and just use it for the final engraving. But there might be some
> trick to have the bar number checks supressed in a score block - does
> anyone know?

Not much of a trick.

\set Score.ignoreBarChecks = ##t


Now I habitually look for such information in the code (which is sort of
the most direct to navigate for me).  Checking for the actual documented
availability of this property turns up

address@hidden:/usr/local/tmp/lilypond$ git grep ignoreBarChecks
Documentation/misc/ChangeLog-2.10:      ignoreBarChecks. Fixes: 
warn-partcombine-barcheck.ly
Documentation/misc/ChangeLog-2.10:      * lily/bar-check-iterator.cc (process): 
ignoreBarChecks property.
lily/bar-check-iterator.cc:      SCM check = tr->get_property 
("ignoreBarChecks");
ly/declarations-init.ly:    ignoreBarChecks = ##t
scm/define-context-properties.scm:     (ignoreBarChecks ,boolean? "Ignore bar 
checks.")

which means that it is completely undocumented apart from a mention in
the automatically generated Internals Reference.  The first line
suggests that this was just used as a hotfix for stopping \partcombine
from generating warnings, and indeed its only use is in the output
definition \partCombineListener .

Wait.  Bar number check, not bar check.  Uh, let me reconsider.  This is
not even a basic LilyPond music expression but open-coded in
ly/music-functions-init.ly :

barNumberCheck =
#(define-music-function (n) (integer?)
   (_i "Print a warning if the current bar number is not @var{n}.")
   (make-music 'ApplyContext
               'procedure
               (lambda (c)
                 (let ((cbn (ly:context-property c 'currentBarNumber)))
                   (if (and  (number? cbn) (not (= cbn n)))
                       (ly:input-warning (*location*)
                                         "Barcheck failed got ~a expect ~a"
                                         cbn n))))))

I think it would be reasonable to let this thing also heed
ignoreBarChecks ?  That would mean something like

barNumberCheck =
#(define-music-function (n) (integer?)
   (_i "Print a warning if the current bar number is not @var{n}.")
   (make-music 'ApplyContext
               'procedure
               (lambda (c)
                 (if (not (ly:context-property c 'ignoreBarChecks #f))
                   (let ((cbn (ly:context-property c 'currentBarNumber)))
                     (if (and  (number? cbn) (not (= cbn n)))
                         (ly:input-warning (*location*)
                                           "Barcheck failed got ~a expect ~a"
                                           cbn n)))))))

This should likely really be in LilyPond itself (and some documentation
would not be amiss for ignoreBarChecks) but while it isn't, you can
copy&paste.

-- 
David Kastrup



reply via email to

[Prev in Thread] Current Thread [Next in Thread]