Re: [Denemo-devel] Denemo's barlines

[Richard Shann]

Ok, this is in git.
The new default behavior is to issue warnings in the Console (ie
warnings from LilyPond) when bar check fails. (This used to be the
default at one time).
But with the Score->Typeset Barlines Literally
the barlines will be wysiwig.
I am not sure which beginners would find easiest.
A script to point out wrong bar lengths would be good in any case ...

Richard


On Wed, 2010-07-28 at 18:59 +0200, Nils Gey wrote:
> Then lets win!
> 
> On Wed, 28 Jul 2010 17:53:08 +0100
> Richard Shann <address@hidden> wrote:
> 
> > 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
> > > > > 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
> >