denemo-devel
[Top][All Lists]
Advanced

[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 15:51:47 +0100

With code like this

(d-DirectivePut-score-prefix "DenemoBar" "\nDnmBar = \\bar \"|\"")


or this

(d-DirectivePut-score-prefix "DenemoBar" "\nDnmBar = | \n")

We can give the user control of the behavior at Denemo barlines by
making the LilyPond creation routine in Denemo output a \DnmBar at each
denemo bar.
By including the code given in the last email we can go further and
ensure that barnumbering and accidentals work as expected when forcing
barlines.

Richard


On Wed, 2010-07-28 at 09:00 +0100, Richard Shann wrote:
> 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
> 
> 
> _______________________________________________
> Denemo-devel mailing list
> address@hidden
> http://lists.gnu.org/mailman/listinfo/denemo-devel




reply via email to

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