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 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




reply via email to

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