[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Denemo-devel] Denemo's barlines
From: |
Richard Shann |
Subject: |
Re: [Denemo-devel] Denemo's barlines |
Date: |
Wed, 28 Jul 2010 09:00:53 +0100 |
Two further points:
* I wonder if this should be not a user pref but rather a property
of a score: even those using it may not want it all the time
* The LilyPond bar number and the persistence of accidentals needs
to respect the custom barlines. There is a snippet for this
already in the LSR. We can define \denemoBar to do this.
Snippet follows:
increaseBarNumber = \applyContext
#(lambda (x)
(let ((measurepos (ly:context-property x 'measurePosition)))
; Only increase bar number if not at start of measure.
; This way we ensure that you won't increase bar number twice
; if two parallel voices call increaseBarNumber simultanously:
(if (< 0 (ly:moment-main-numerator measurepos)) ; ugh. ignore grace part
(begin
(ly:context-set-property!
(ly:context-property-where-defined x 'internalBarNumber)
'internalBarNumber
(1+ (ly:context-property x 'internalBarNumber)))
(ly:context-set-property!
(ly:context-property-where-defined x 'currentBarNumber)
'currentBarNumber
(1+ (ly:context-property x 'currentBarNumber)))
; set main part of measurepos to zero, leave grace part as it is:
(ly:context-set-property!
(ly:context-property-where-defined x 'measurePosition)
'measurePosition
(ly:make-moment 0 1
(ly:moment-grace-numerator measurepos)
(ly:moment-grace-denominator measurepos)))))))
% Named Increasing BAR
nibar = #(define-music-function (parser location x) (string?)
#{
\bar $x
\increaseBarNumber
#})
% Increasing BAR
ibar = \nibar "|"
On Tue, 2010-07-27 at 17:03 +0100, Richard Shann wrote:
> Denemo's barlines have long been problematic. It used to be that Denemo
> issued a request to LilyPond to check that the barline position that
> Denemo had corresponded with what LilyPond calculated. I commented these
> out because the warnings were unhelpful in the case of upbeats etc,
> obscuring the real problems.
> It occurs to me that we could ask LilyPond to stop auto-placing barlines
> and issue the command to LilyPond to insert a barline wherever Denemo
> has one.
> There is a balance between creating readable LilyPond - the sort of
> LilyPond someone might type in - and making an easily controllable GUI.
> The case of repeat blocks is a good example of this: a LilyPond user
> will want to see \volta 2 { ... } \alternative {{...}{...}} for a
> repeat with first and second time bars, but from the perspective of the
> user who never looks at the LilyPond the \set Score.repeatCommands =
> #'((volta "1")) generated by the OpenFirstTimeBar command is simpler to
> manage.
> Likewise with this change - each bar will end with
>
> \bar "|"
>
> which is more verbose than the simple barline check | which a user would
> type.
>
> Furthermore I am not sure quite how this will work out for those doing
> more than trivial tasks. I'll implement it as an optional behavior and
> we can take it from there. When ON Denemo will no longer use light gray
> barlines, though it should perhaps continue to issue colored ones. In
> this connection it seems to me that the visual impact of
> incomplete/over-full measures has never been enough, considering the
> havoc it can give in the output. Any suggestions for improvements
> welcome.
>
> Richard
>
>
>
> _______________________________________________
> Denemo-devel mailing list
> address@hidden
> http://lists.gnu.org/mailman/listinfo/denemo-devel