denemo-devel
[Top][All Lists]

## Re: [Denemo-devel] Denemo's barlines

 From: Nils Gey Subject: Re: [Denemo-devel] Denemo's barlines Date: Wed, 28 Jul 2010 18:59:18 +0200

Then lets win!

On Wed, 28 Jul 2010 17:53:08 +0100

> No - it is not for myself directly - indeed there is not much that I
> *really* need in Denemo for what I do with it.
> It *is* however something near trivial to do that I think will stop
> people getting stuck with LilyPond generating different output from
> Denemo's display. And if you adopt the proposed new default it becomes
> more wysiwig, which is not a bad thing.
>
> That was a good idea of yours to consider about possible impact on cut
> and paste etc. But apart from perfect backward compatibility (you just
> have to say that the denemo barline means nothing in LilyPond, rather
> than that it means | or \bar "|" or ...) I don't foresee any knock-on
> problems. I think it is win-win. Or even win-win-win:)
>
> Richard
>
> On Wed, 2010-07-28 at 17:47 +0200, Nils Gey wrote:
> > 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
> > > > http://lists.gnu.org/mailman/listinfo/denemo-devel
> > >
> > >
> > > _______________________________________________
> > > Denemo-devel mailing list