Re: barNumberCheck with repeats

[David Kastrup]

Robert Schmaus <address@hidden> writes:

>>
>> Not much of a trick.
>>
>> \set Score.ignoreBarChecks = ##t
>
> Ah, great - thanks David!
>
>
>
>> 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 will certainly work for my (probably comparatively simple) scores
> - 
> I'll use that.
>
> But in general, shouldn't bar checks still be valid even if the bar
> number count isn't necessarily?

Would there be any version in a file where bar checks and bar number
checks are never right at the same time?

I think most people can live with errors getting pointed out only once
to them.

While I admit that one may inadvertantly mess up the scope of a \repeat
such that it causes subsequent bar checks to fail when expanded, it's
probably tolerable to overlook one kind of warning when enabling the
checks and being only interested in the other.

Putting this into perspective, we currently have no reasonably
documented way of disabling either.

So I lean towards just introducing (or rather documenting) one obscure
option rather than two.

-- 
David Kastrup