Re: [Denemo-devel] Denemo's barlines

[Nils Gey]

My WDR job is gone now, so I have (a lot) more time.

I see no problem in tweaking and enhancing barlines, but I fear (from a farer, 
broader, wider viewpoint) that this may introduce more problems (I can think of 
paste or rebar) or at least work. Is it really the time for such a heavy 
feature while there are other things to do?

I mean: Is this needed for music for you, Richard, or another user requested it 
seriously?
Not many people complain about barlines, some of them are just loud. I don't 
see a real problem right now. 

Nils


On Wed, 28 Jul 2010 15:51:47 +0100
Richard Shann <address@hidden> wrote:

> 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
> 
> 
> _______________________________________________
> Denemo-devel mailing list
> address@hidden
> http://lists.gnu.org/mailman/listinfo/denemo-devel
> 
W