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