Re: Barline scaling issues

[Vaughan McAlley]

On Fri, 12 Jul 2024 at 06:11, Tom Brennan  wrote:

> Hi all
>
> When using `\magnifyStaff #2/3`, I'm seeing weird transitions between the
> staves of a `StaffGroup`. For example,
>
> ```
> \version "2.24.3"
>
> music = \relative c'' {
> \repeat unfold 10 { c4 d e f } \bar "||" c d e f \bar "|."
> }
>
> % Weird transition between I and II -- I "wins"
> \bookpart {
> \new StaffGroup {
> <<
> \tag #'a-normal {
> \new Staff \with {
> instrumentName = "Inst I"
> shortInstrumentName = "I"
> \RemoveEmptyStaves
> } { \music }
> }
> \tag #'b-small {
> \new Staff \with {
> instrumentName = "Inst II"
> shortInstrumentName = "II"
> \magnifyStaff #2/3
> \RemoveEmptyStaves
> } { \music }
> }
> >>
> }
> }
> ```
>
> which produces this:
>
> [image: image.png]
>
> You can see the staff size transition -- the top one "wins" in the sense
> that its larger barlines are longer. If you flip the magnification from the
> bottom to the top, then the smaller lines "win" and they are longer
> instead, meaning that the staff on top seems to always be the one chosen to
> dictate the barline vertical span.
>
> It looks like you can get the barlines to be consistent by using the
> following workaround in a staff `\with` block:
>
> ```
> fontSize = #-3
> \override StaffSymbol.staff-space = #(magstep -3)
> ```
>
> But I figure this (basically a constant cue staff) probably isn't a great
> use for a StaffGroup, though. If you look at this Mozart example
> <https://www.youtube.com/watch?v=Gzemq3bpz54> the StaffGroup is grouping
> two staves of the same size, whereas in this Ravel example
> <https://youtu.be/-z_Ee3E3C0Q?si=042_d_n0FW41vLTU>, where it looks like a
> cello part of a duo/duet because the violin is smaller, the staves aren't
> grouped. I think the Ravel example is probably what I'm looking for, but
> when you do this kind of thing, where there are exactly the same number of
> bars in each staff, the final barline incorrectly leaves room at the end of
> the staff:
>
> ```
> \version "2.24.3"
>
> music = \relative c'' {
> \repeat unfold 10 { c4 d e f } \bar "||" c d e f \bar "|."
> }
>
> % No `StaffGroup` -- right padding/margin on small staff should not be
> there
> \bookpart {
> <<
> {
> \new Staff \with {
> instrumentName = "Inst I"
> shortInstrumentName = "I"
> \magnifyStaff #2/3
>     \RemoveEmptyStaves
> } { \music }
> }
> {
> \new Staff \with {
> instrumentName = "Inst II"
> shortInstrumentName = "II"
> \RemoveEmptyStaves
> } { \music }
> }
> >>
> }
> ```
>
> which gives you this:
>
> [image: image.png]
>
> As you can see, there's a little bit of margin/padding on the right of the
> final barline of the small staff. It could be fixed by using the
> `StaffSymbol.staff-space` and `fontsize` workaround, but I think it
> probably looks better to have these scaled-down barlines. The only issue is
> that I think this last one needs to be positioned at the end of the staff,
> small or not, like it is in the Ravel example above.
>
> The question is, is this a bug or expected behavior? Is there a workaround
> to get that barline to snap to the end?
>
> Thanks
> Tom
>

The second issue is fixed in 2.25:

http://lilypond.org/doc/v2.25/Documentation/changes/rhythm-improvements

Cheers,
Vaughan

Re: Barline scaling issues

[Mats Bengtsson]

  
  
This is a well-known problem and you can find several alternative
  work-arounds in the manual, see
https://lilypond.org/doc/v2.24/Documentation/notation/setting-the-staff-size
   /Mats

On 2024-07-11 22:09, Tom Brennan wrote:


  
  Hi all


When using `\magnifyStaff #2/3`, I'm seeing weird
  transitions between the staves of a `StaffGroup`. For
  example, 


```
\version "2.24.3"
  
  music = \relative c'' {
      \repeat unfold 10 { c4 d e f } \bar "||" c d e f \bar "|."
  
  }
  
  % Weird transition between I and II -- I "wins"
  \bookpart {
      \new StaffGroup {
          <<
              \tag #'a-normal {
                  \new Staff \with {
                      instrumentName = "Inst I"
                      shortInstrumentName = "I"
                      \RemoveEmptyStaves
                  } { \music }
              }
              \tag #'b-small {
                  \new Staff \with {
                      instrumentName = "Inst II"
                      shortInstrumentName = "II"
                      \magnifyStaff #2/3
                      \RemoveEmptyStaves
                  } { \music }
              }
          >>
      }
  }

```


which produces this:






You can see the staff size transition -- the top one "wins"
  in the sense that its larger barlines are longer. If you flip
  the magnification from the bottom to the top, then the smaller
  lines "win" and they are longer instead, meaning that the
  staff on top seems to always be the one chosen to dictate the
  barline vertical span.


It looks like you can get the barlines to be consistent by
  using the following workaround in a staff `\with` block:


```
fontSize = #-3
  \override StaffSymbol.staff-space = #(magstep -3)

```


But I figure this (basically a constant cue staff) probably
  isn't a great use for a StaffGroup, though. If you look at this Mozart example the
  StaffGroup is grouping two staves of the same size, whereas in
  this Ravel example, where it
  looks like a cello part of a duo/duet because the violin is
  smaller, the staves aren't grouped. I think the Ravel example
  is probably what I'm looking for, but when you do this kind of
  thing, where there are exactly the same number of bars in each
  staff, the final barline incorrectly leaves room at the end of
  the staff:



```
\version "2.24.3"
  
  music = \relative c'' {
      \repeat unfold 10 { c4 d e f } \bar "||" c d e f \bar "|."
  
  }



% No `StaffGroup` -- right padding/margin on small staff
  should not be there
  \bookpart {
      <<
          {
              \new Staff \with {
                  instrumentName = "Inst I"
                  shortInstrumentName = "I"
                  \magnifyStaff #2/3
                  \RemoveEmptyStaves
              } { \music }
          }
          {
              \new Staff \with {
                  instrumentName = "Inst II"
                  shortInstrumentName = "II"
                  \RemoveEmptyStaves
              } { \music }
          }
      >>
  }

```
    
    
which gives you this:






As you can see, there's a little bit of margin/padding on
  the right of the final barline of the small staff. It could be
  fixed by using the `StaffSymbol.staff-space` and `fontsize`
  workaround, but I think it probably looks better to have these
  scaled-down barlines. The only issue is that I think this last
  one needs to be positioned at the end of the staff, small or
  not, like it is in the Ravel example above.


The question is, is this a bug or expected behavior? Is
  there a workaround to get that barline to snap to the end?


Thanks
Tom


  

  

Re: Barline scaling issues

[Xavier Scheuer]

On Thu, 11 Jul 2024 at 22:10, Tom Brennan  wrote:
>
> Hi all
>
> When using `\magnifyStaff #2/3`, I'm seeing weird transitions between the
staves of a `StaffGroup`. For example,
>
> (snip)
>
> The question is, is this a bug or expected behavior? Is there a
workaround to get that barline to snap to the end?

Hello,

All this is documented in NR 4.2.2 Setting the staff size (see Known issues
and warnings).
https://lilypond.org/doc/v2.25/Documentation/notation/setting-the-staff-size

3 proposed outputs are given with their code.

Kind regards,
Xavier

Barline scaling issues

[Tom Brennan]

Hi all

When using `\magnifyStaff #2/3`, I'm seeing weird transitions between the
staves of a `StaffGroup`. For example,

```
\version "2.24.3"

music = \relative c'' {
\repeat unfold 10 { c4 d e f } \bar "||" c d e f \bar "|."
}

% Weird transition between I and II -- I "wins"
\bookpart {
\new StaffGroup {
<<
\tag #'a-normal {
\new Staff \with {
instrumentName = "Inst I"
shortInstrumentName = "I"
\RemoveEmptyStaves
} { \music }
}
\tag #'b-small {
\new Staff \with {
instrumentName = "Inst II"
shortInstrumentName = "II"
\magnifyStaff #2/3
\RemoveEmptyStaves
} { \music }
}
>>
}
}
```

which produces this:

[image: image.png]

You can see the staff size transition -- the top one "wins" in the sense
that its larger barlines are longer. If you flip the magnification from the
bottom to the top, then the smaller lines "win" and they are longer
instead, meaning that the staff on top seems to always be the one chosen to
dictate the barline vertical span.

It looks like you can get the barlines to be consistent by using the
following workaround in a staff `\with` block:

```
fontSize = #-3
\override StaffSymbol.staff-space = #(magstep -3)
```

But I figure this (basically a constant cue staff) probably isn't a great
use for a StaffGroup, though. If you look at this Mozart example
<https://www.youtube.com/watch?v=Gzemq3bpz54> the StaffGroup is grouping
two staves of the same size, whereas in this Ravel example
<https://youtu.be/-z_Ee3E3C0Q?si=042_d_n0FW41vLTU>, where it looks like a
cello part of a duo/duet because the violin is smaller, the staves aren't
grouped. I think the Ravel example is probably what I'm looking for, but
when you do this kind of thing, where there are exactly the same number of
bars in each staff, the final barline incorrectly leaves room at the end of
the staff:

```
\version "2.24.3"

music = \relative c'' {
\repeat unfold 10 { c4 d e f } \bar "||" c d e f \bar "|."
}

% No `StaffGroup` -- right padding/margin on small staff should not be there
\bookpart {
<<
{
\new Staff \with {
instrumentName = "Inst I"
shortInstrumentName = "I"
\magnifyStaff #2/3
\RemoveEmptyStaves
} { \music }
}
{
\new Staff \with {
instrumentName = "Inst II"
shortInstrumentName = "II"
    \RemoveEmptyStaves
} { \music }
}
>>
}
```

which gives you this:

[image: image.png]

As you can see, there's a little bit of margin/padding on the right of the
final barline of the small staff. It could be fixed by using the
`StaffSymbol.staff-space` and `fontsize` workaround, but I think it
probably looks better to have these scaled-down barlines. The only issue is
that I think this last one needs to be positioned at the end of the staff,
small or not, like it is in the Ravel example above.

The question is, is this a bug or expected behavior? Is there a workaround
to get that barline to snap to the end?

Thanks
Tom

Re: PianoPedalBracket.to-barline doesn't always work as expected

[Kieren MacMillan]

Hi Werner,

>> Might I suggest that “to-barline” is potentially
>> misleading/confusing…?
> I suggest you file an issue.

https://gitlab.com/lilypond/lilypond/-/issues/6709

Cheers,
Kieren.
__

My work day may look different than your work day. Please do not feel obligated 
to read or respond to this email outside of your normal working hours.

Re: PianoPedalBracket.to-barline doesn't always work as expected

[Kieren MacMillan]

Hi Mats,

> Exactly the same feature might also be useful for hairpins and other spanner 
> types

Indeed!
I’ll be sure to make the issue I submit a general spanner issue…

Best,
Kieren.
__

My work day may look different than your work day. Please do not feel obligated 
to read or respond to this email outside of your normal working hours.

Re: PianoPedalBracket.to-barline doesn't always work as expected

[Mats Bengtsson]

On 2024-04-12 12:05, Werner LEMBERG wrote:

Might I suggest that “to-barline” is potentially
misleading/confusing…?

On the other hand:

 end-at-barline, for a pedal coded for release on a note **just
 after** a barline, might be more clearly descriptive of the
 current behaviour; and

 extend-to-barline, for a pedal coded for release on a note
 **just before** a barline, might be more suggestive of the
 behaviour Maurits was expecting.

Is there any technical reason both of these different-but-related
properties can’t/shouldn’t be made available?

I suggest you file an issue.


Exactly the same feature might also be useful for hairpins and other 
spanner types, for example when you want to typeset a diminuendo on the 
last note of a piece, where the diminuendo ends at the final bar line. 
Admittedly, the same result can be obtained by attaching the \! to an 
empty chord after the final bar line, but it's still a bit weird syntax:


\version "2.24.3"

\fixed c' {
  long piece, ending with
c1 \> | <> \!
\fine
}

Of course, in this specific example, I guess that the following is the 
cleanest solution:


\fixed c' {
  long piece, ending with
\endSpanners c1 \> |
\fine
}

The same idea of attaching something to an empty chord just after the 
bar line is also applicable for the pedal bracket scenario discussed 
earlier in this thread:


\score {
   \new Staff {
 \clef bass
 \time 6/8
 \relative c' {
   c8 b a g e c |
   \set Staff.pedalSustainStyle = #'mixed
   \override Staff.PianoPedalBracket.to-barline = ##t
   \repeat tremolo 12 { b,32\sustainOn b' } |
   \repeat tremolo 12 { b,32 b' } | <>\sustainOff
   c8 e f g a
 }
   }
}

However, I couldn't find a way to extend the use of \endSpanner to 
provide the equivalent result. I would have expected to the following to 
work, but it doesn't:


\score {
   \new Staff {
 \clef bass
 \time 6/8
 \relative c' {
   c8 b a g e c |
   \set Staff.pedalSustainStyle = #'mixed
   \override Staff.PianoPedalBracket.to-barline = ##t
    \endSpanners{
          \repeat tremolo 12 { b,32\sustainOn b' } |
  \repeat tremolo 12 { b,32  b' } } |
   c8 d e f g a
 }
   }
}

    /Mats

Re: PianoPedalBracket.to-barline doesn't always work as expected

[Werner LEMBERG]

> Might I suggest that “to-barline” is potentially
> misleading/confusing…?
> 
> On the other hand:
>
> end-at-barline, for a pedal coded for release on a note **just
> after** a barline, might be more clearly descriptive of the
> current behaviour; and
>
> extend-to-barline, for a pedal coded for release on a note
> **just before** a barline, might be more suggestive of the
> behaviour Maurits was expecting.
> 
> Is there any technical reason both of these different-but-related
> properties can’t/shouldn’t be made available?

I suggest you file an issue.


Werner

Re: PianoPedalBracket.to-barline doesn't always work as expected

[Kieren MacMillan]

Hi all,

Might I suggest that “to-barline” is potentially misleading/confusing…?

On the other hand:
end-at-barline, for a pedal coded for release on a note **just after** a 
barline, might be more clearly descriptive of the current behaviour; and
extend-to-barline, for a pedal coded for release on a note **just before** 
a barline, might be more suggestive of the behaviour Maurits was expecting.

Is there any technical reason both of these different-but-related properties 
can’t/shouldn’t be made available?

Cheers,
Kieren.
__

My work day may look different than your work day. Please do not feel obligated 
to read or respond to this email outside of your normal working hours.

Re: PianoPedalBracket.to-barline doesn't always work as expected

[Maurits Lamers via LilyPond user discussion]

Hi Jean,

Of course you are right. Let me explain how I got to this to explain my 
confusion.


My first attempt was to add it to the next note without using \override 
Staff.PianoPedalBracket.to-barline = ##t (as I wasn't aware of it 
existence at that point). What I discovered however is that when the 
tremolo is the last bar of that system, the bracket is continued on the 
next system. Example:


%%%

\score {
  \new Staff {
    \clef bass
    \time 6/8
    \relative c' {
  c8 b a g e c |
  \set Staff.pedalSustainStyle = #'mixed
  \repeat tremolo 12 { b,32\sustainOn b' } |
  \repeat tremolo 12 { b,32 b'  } | \break
  c8\sustainOff e f g a
    }
  }
}

%%

That is confusing because it means for the player that it is not 
immediately obvious where to lift the sustain pedal. This lead to me 
moving the \sustainOff back to the last note of the tremolo, and trying 
to extend it to the end of the barline.


It is indeed the case that if you set it to the next note (the c8 in the 
example) AND set \override Staff.PianoPedalBracket.to-barline = ##t, it 
works as expected. To me it was not immediately obvious that this is the 
correct solution. When trying to find a solution, I was surprised to 
only find a reference to this type of solution on the mailing list in a 
post of 2015, and it didn't feature the end of system situation. I 
expected that this kind of issue would have come up more frequently. 
Perhaps this solution might deserve a mention in the Pedal department of 
the Lilypond documentation. Happy to contribute that mention.


cheers

Maurits

Op 10-04-2024 om 12:01 schreef Jean Abou Samra:

Le mardi 09 avril 2024 à 23:55 +0200, Maurits Lamers via LilyPond user 
discussion a écrit :

Hey all,

I encountered a situation where the PianoPedalBracket setting to-barline
doesn't always do what you'd expect. Given the following code, the pedal
bracket is not extended to the end of the bar:

%%%

\version "2.24.0"
\score {
    \new Staff {
  \clef bass
  \time 6/8
  \relative c' {
    c8 b a g e c |
    \set Staff.pedalSustainStyle = #'mixed
    \override Staff.PianoPedalBracket.to-barline = ##t
    \repeat tremolo 12 { b,32\sustainOn b' } |
    \repeat tremolo 12 { b,32 b'\sustainOff  } |
    c8 e f g a
  }
    }
}


Correct syntax is

\version "2.24.0"
\score {
\new Staff {
  \clef bass
  \time 6/8
  \relative c' {
c8 b a g e c |
\set Staff.pedalSustainStyle = #'mixed
\override Staff.PianoPedalBracket.to-barline = ##t
\repeat tremolo 12 { b,32\sustainOn b' } |
\repeat tremolo 12 { b,32 b' } |
c8\sustainOff e f g a
  }
}
}


The \sustainOff command is placed on the note where you *release*
the pedal. And because LilyPond uses post-fix syntax, it comes just
*after* that note.

Best,
Jean

Re: PianoPedalBracket.to-barline doesn't always work as expected

[Jean Abou Samra]

Le mardi 09 avril 2024 à 23:55 +0200, Maurits Lamers via LilyPond user 
discussion a écrit :
> Hey all,
> 
> I encountered a situation where the PianoPedalBracket setting to-barline 
> doesn't always do what you'd expect. Given the following code, the pedal 
> bracket is not extended to the end of the bar:
> 
> %%%
> 
> \version "2.24.0"
> \score {
>    \new Staff {
>  \clef bass
>  \time 6/8
>  \relative c' {
>    c8 b a g e c |
>    \set Staff.pedalSustainStyle = #'mixed
>    \override Staff.PianoPedalBracket.to-barline = ##t
>    \repeat tremolo 12 { b,32\sustainOn b' } |
>    \repeat tremolo 12 { b,32 b'\sustainOff  } |
>    c8 e f g a
>  }
>    }
> }


Correct syntax is

\version "2.24.0"
\score {
   \new Staff {
 \clef bass
 \time 6/8
 \relative c' {
   c8 b a g e c |
   \set Staff.pedalSustainStyle = #'mixed
   \override Staff.PianoPedalBracket.to-barline = ##t
   \repeat tremolo 12 { b,32\sustainOn b' } |
   \repeat tremolo 12 { b,32 b' } |
   c8\sustainOff e f g a
 }
   }
}


The \sustainOff command is placed on the note where you *release*
the pedal. And because LilyPond uses post-fix syntax, it comes just
*after* that note.

Best,
Jean



signature.asc
Description: This is a digitally signed message part

Re: PianoPedalBracket.to-barline doesn't always work as expected

[Maurits Lamers via LilyPond user discussion]

Hi Aaron,

Yes it does. It is just unexpected that this would be necessary.

cheers

Maurits

Op 10-04-2024 om 00:12 schreef Aaron Hill:

Does the empty chord construct help?

  <>\sustainOff

(I'm away from my normal environment, so I cannot test this locally to 
confirm.)



-- Aaron Hill

Re: PianoPedalBracket.to-barline doesn't always work as expected

[Aaron Hill]

On 2024-04-09 2:55 pm, Maurits Lamers via LilyPond user discussion 
wrote:
Only when the \sustainOff is placed outside of the tremolo, the bracket 
extends to the barline:


%%%

\version "2.24.0"
\score {
  \new Staff {
    \clef bass
    \time 6/8
    \relative c' {
  c8 b a g e c |
  \set Staff.pedalSustainStyle = #'mixed
  \override Staff.PianoPedalBracket.to-barline = ##t
  \repeat tremolo 12 { b,32\sustainOn b' } |
  \repeat tremolo 12 { b,32 b' }  \sustainOff |
  c8 e f g a
    }
  }
}

%%%

However, this leads to Lilypond complaining about an unattached 
SustainEvent. Is this a bug?



Does the empty chord construct help?

  <>\sustainOff

(I'm away from my normal environment, so I cannot test this locally to 
confirm.)



-- Aaron Hill

PianoPedalBracket.to-barline doesn't always work as expected

[Maurits Lamers via LilyPond user discussion]

Hey all,

I encountered a situation where the PianoPedalBracket setting to-barline 
doesn't always do what you'd expect. Given the following code, the pedal 
bracket is not extended to the end of the bar:


%%%

\version "2.24.0"
\score {
  \new Staff {
    \clef bass
    \time 6/8
    \relative c' {
  c8 b a g e c |
  \set Staff.pedalSustainStyle = #'mixed
  \override Staff.PianoPedalBracket.to-barline = ##t
  \repeat tremolo 12 { b,32\sustainOn b' } |
  \repeat tremolo 12 { b,32 b'\sustainOff  } |
  c8 e f g a
    }
  }
}

%%%

Only when the \sustainOff is placed outside of the tremolo, the bracket 
extends to the barline:


%%%

\version "2.24.0"
\score {
  \new Staff {
    \clef bass
    \time 6/8
    \relative c' {
  c8 b a g e c |
  \set Staff.pedalSustainStyle = #'mixed
  \override Staff.PianoPedalBracket.to-barline = ##t
  \repeat tremolo 12 { b,32\sustainOn b' } |
  \repeat tremolo 12 { b,32 b' }  \sustainOff |
  c8 e f g a
    }
  }
}

%%%

However, this leads to Lilypond complaining about an unattached 
SustainEvent. Is this a bug?


cheers

Maurits

Re: "\override BarLine" for a PianoStaff

[Ivan Kuznetsov]

Yes it does!  Thank you.

On Fri, Jan 26, 2024 at 11:23 PM Vaughan McAlley 
wrote:

>
> Hi Ivan,
>
> \new PianoStaff \with {  \remove "Span_bar_engraver" }
>
> should work!
>
>

Re: "\override BarLine" for a PianoStaff

[Vaughan McAlley]

On Sat, 27 Jan 2024 at 11:08, Ivan Kuznetsov 
wrote:

> "\override BarLine" for a PianoStaff
>
> I frequently use lilypond for short theory
> examples for teaching, and for such examples
> I often use the code:
>
>\override BarLine.transparent = ##t
>
> to make bar lines disappear.  This has always worked
> for me for a single staff, but when I just tried
> to do this with a grand staff in the excerpt
> below, the bar lines only disappeared "on the staves"
> but still appeared "between the staves".
> Running the excerpt below will illustrate this.
>
> How do I make the entire bar lines transparent
> for a grand staff?
>
> Thank you for your help.
>
>
> \version "2.24.1"
> \language "english"
>
> \paper{ indent = 0\cm }
>
> \score {
>
>   \new PianoStaff
>   <<
>   \new Staff \with { \remove "Time_signature_engraver" }
>   {
> \time 4/4
> \clef "treble"
> s1   s1 s1   s1   e'1b'1   fs''   cs'''   gs'''
>   }
>
>   \new Staff \with { \remove "Time_signature_engraver" }
>   {
> \time 4/4
> \clef "bass"
> c,1   g,1   d1   a1e'1   s1s1s1  s1
>   }
>   >>
>
>   \layout {
>
> \context {
>\Score
>\override BarLine.transparent = ##t
> }
>   }
>
> } % score
>
>
Hi Ivan,

\new PianoStaff \with {  \remove "Span_bar_engraver" }

should work!

Cheers,
Vaughan

"\override BarLine" for a PianoStaff

[Ivan Kuznetsov]

"\override BarLine" for a PianoStaff

I frequently use lilypond for short theory
examples for teaching, and for such examples
I often use the code:

   \override BarLine.transparent = ##t

to make bar lines disappear.  This has always worked
for me for a single staff, but when I just tried
to do this with a grand staff in the excerpt
below, the bar lines only disappeared "on the staves"
but still appeared "between the staves".
Running the excerpt below will illustrate this.

How do I make the entire bar lines transparent
for a grand staff?

Thank you for your help.


\version "2.24.1"
\language "english"

\paper{ indent = 0\cm }

\score {

  \new PianoStaff
  <<
  \new Staff \with { \remove "Time_signature_engraver" }
  {
\time 4/4
\clef "treble"
s1   s1 s1   s1   e'1b'1   fs''   cs'''   gs'''
  }

  \new Staff \with { \remove "Time_signature_engraver" }
  {
\time 4/4
\clef "bass"
c,1   g,1   d1   a1e'1   s1s1s1  s1
  }
  >>

  \layout {

\context {
   \Score
   \override BarLine.transparent = ##t
}
  }

} % score

Re: Anything similar to to-barline for extender lines of cresc/dim?

[Mats Bengtsson]

  
  
On 2023-10-11 17:17, Knute Snortum
  wrote:


  
  
On Wed, Oct 11, 2023 at 5:40 AM Mats Bengtsson
  <matsboxergr...@gmail.com>
  wrote:


  
Follow-up question; wouldn't it be good to have this setting
as the 
default?
  
  
  
  You can, in a way, set it as the default by using an
override instead of a tweak:
  ...
  

  

Certainly! You can even do the setting for all scores of the
  current file by adding
\layout{
    \context{
      \Score
      \override DynamicTextSpanner.to-barline = ##t
    }
  }

(or even putting these lines in an include file together with all
  other favorite settings of yours). 

My question was on the default behavior in LilyPond, where
      to-barline is true by default for hairpins but not for the
  extender lines of textual dynamics. I have just ordered a copy of
  E. Gould's "Behind bars" (which now is available in paperback at a
  much lower price than the earlier bound version), but before it
  arrives I don't know if she has anything authoritative to say
  about best typesetting practice in this situation. 

   /Mats



  

Re: Anything similar to to-barline for extender lines of cresc/dim?

[Knute Snortum]

On Wed, Oct 11, 2023 at 5:40 AM Mats Bengtsson 
wrote:

> Follow-up question; wouldn't it be good to have this setting as the
> default?
>

You can, in a way, set it as the default by using an override instead of a
tweak:

\version "2.24.2"

theNotes = { c'1\cresc 1 1 1\f 1 1\cresc 1 1 1\f 1 1\cresc 1 1 1\f }

{
  \theNotes
  \break
  \override DynamicTextSpanner.to-barline = ##t
  \theNotes
}


--
Knute Snortum

Re: Anything similar to to-barline for extender lines of cresc/dim?

[Mats Bengtsson]

On 2023-10-10 23:01, Mats Bengtsson wrote:

On 2023-10-10 18:07, David Kastrup wrote:

Have you tried not "anything like to-barline" but rather _exactly_
to-barline ?

Like

c -\tweak to-barline ##t \cresc

and its ilk?



Silly me! Too obvious to try. Well, in fact I was looking around in 
the internals manual, but didn't spot that to-barline was listed in 
the spanner-interface.


   /Mats

Follow-up question; wouldn't it be good to have this setting as the 
default?


   /Mats

Re: Anything similar to to-barline for extender lines of cresc/dim?

[Mats Bengtsson]

  
  
On 2023-10-10 18:07, David Kastrup wrote:

  Mats Bengtsson  writes:


  
Hi,

Is there anything analogous to Hairpin.to-barline = #t that applies to
the extender line of textual dynamics like \cresc or \dim?

Unfortunately, I don't have a copy of Gould, but to me all the options
I tried below look worse than having an extender line that ends
exactly below the bar line.

\version "2.25.9"

\fixed c' {
<>^"Extending into next bar"
c4 \cresc d e f |
g \f f g a |
g4 \dim f e d |
c \mf  d c b, |
<>^"Especially ugly at line breaks"
c4 \cresc d e f |
g \f f g a |
g4 \dim f e d | \break
c1 \mf |
<>^"Ended (too early) before the bar"
c4 \cresc d e f \! |
g \f f g a |
g4 \dim f e d \! |
c \mf d c b, |
<>^\markup\column{"Still too early" "adjusting bound-details" }
\override DynamicTextSpanner.bound-details.right.attach-dir = #RIGHT
c4 \cresc d e f \! |
g \f f g a |
g4 \dim f e d \! | \break
c1 \mf |

}

Any ideas, or should I file it as a feature request?

  
  
Have you tried not "anything like to-barline" but rather _exactly_
to-barline ?

Like

c -\tweak to-barline ##t \cresc

and its ilk?




Silly me! Too obvious to try. Well, in fact I was looking around
  in the internals manual, but didn't spot that to-barline was
  listed in the spanner-interface.
   /Mats



  

Re: Anything similar to to-barline for extender lines of cresc/dim?

[David Kastrup]

Mats Bengtsson  writes:

> Hi,
>
> Is there anything analogous to Hairpin.to-barline = #t that applies to
> the extender line of textual dynamics like \cresc or \dim?
>
> Unfortunately, I don't have a copy of Gould, but to me all the options
> I tried below look worse than having an extender line that ends
> exactly below the bar line.
>
> \version "2.25.9"
>
> \fixed c' {
> <>^"Extending into next bar"
> c4 \cresc d e f |
> g \f f g a |
> g4 \dim f e d |
> c \mf  d c b, |
> <>^"Especially ugly at line breaks"
> c4 \cresc d e f |
> g \f f g a |
> g4 \dim f e d | \break
> c1 \mf |
> <>^"Ended (too early) before the bar"
> c4 \cresc d e f \! |
> g \f f g a |
> g4 \dim f e d \! |
> c \mf d c b, |
> <>^\markup\column{"Still too early" "adjusting bound-details" }
> \override DynamicTextSpanner.bound-details.right.attach-dir = #RIGHT
> c4 \cresc d e f \! |
> g \f f g a |
> g4 \dim f e d \! | \break
> c1 \mf |
>
> }
>
> Any ideas, or should I file it as a feature request?

Have you tried not "anything like to-barline" but rather _exactly_
to-barline ?

Like

c -\tweak to-barline ##t \cresc

and its ilk?

-- 
David Kastrup

Anything similar to to-barline for extender lines of cresc/dim?

[Mats Bengtsson]

Hi,

Is there anything analogous to Hairpin.to-barline = #t that applies to 
the extender line of textual dynamics like \cresc or \dim?


Unfortunately, I don't have a copy of Gould, but to me all the options I 
tried below look worse than having an extender line that ends exactly 
below the bar line.


\version "2.25.9"

\fixed c' {
<>^"Extending into next bar"
c4 \cresc d e f |
g \f f g a |
g4 \dim f e d |
c \mf  d c b, |
<>^"Especially ugly at line breaks"
c4 \cresc d e f |
g \f f g a |
g4 \dim f e d | \break
c1 \mf |
<>^"Ended (too early) before the bar"
c4 \cresc d e f \! |
g \f f g a |
g4 \dim f e d \! |
c \mf d c b, |
<>^\markup\column{"Still too early" "adjusting bound-details" }
\override DynamicTextSpanner.bound-details.right.attach-dir = #RIGHT c4 
\cresc d e f \! |

g \f f g a |
g4 \dim f e d \! | \break
c1 \mf |

}

Any ideas, or should I file it as a feature request?

   /Mats

Re: barline in proportional notation disappear

[Valentin Petzel]

> Thank you sooo much for your answer!
> That’s amazing, it’s really clear and I’ll take a deep look at it! 
> What is MusicSE? I cannot find anything on google. Can u point me out 
to the > reference u said? 
> Cheers!

As Jean said it is the music stackexchange thing. You’ve accidently replied 
to the wrong thread, so I’ll take it back here.

Cheers,
Valentin


signature.asc
Description: This is a digitally signed message part.

Re: barline in proportional notation disappear

[Valentin Petzel]

Hello,

this was also posted on MusicSE, for reference here my reply:

You are not getting some barlines as

s1^"text" \bar "!"

will insert the bar line after the skip, which is in your case in a random 
position later. Rather do

\bar "!" s1^"text"

to have the bar line at the exact position you specify. Alternatively you may 
do

<>^"text" \bar "!"

or

\bar "!" <>^"text"

Some more details:

\new Staff \new Staff ...

creates contexts within contexts. I’d rather do

\new Staff $(empty-music)

instead to create an empty context.

Also `\after x m1 m2` is equivalent to `<< m2 sx m1>>`. So instead of

\after 4*##e0.333 { f,, 4*##e1.324 _"+1.96¢" } <>

you can directly do

s4*##e0.333 f,, 4*##e1.324 _"+1.96¢"

etc.

So this could look like this:

\version "2.24.0"

\paper {
  #(set-paper-size "a4landscape")
  print-page-number = ##t
  system-separator-markup = \slashSeparator
}

\layout {
  \context {
\Score
proportionalNotationDuration = #(ly:make-moment 1/48)
\override SpacingSpanner.uniform-stretching = ##t
\override TimeSignature.stencil = ##f
\override TextScript.font-size = #-9
  }
  \context {
\Voice
\remove Stem_engraver
\remove Dots_engraver
\override NoteHead.duration-log = 2
  }
}

<<
  %===
  \new RhythmicStaff = "timeline" $(empty-music)
  \new Staff = "org" $(empty-music)
  \new Staff = "senot" $(empty-music)
  \cadenzaOn
  %===
  \context Staff = "org" \new Voice { s4*##e0.333 f,, 4*##e1.324 _"+1.96¢" 
}
  \context Staff = "org" \new Voice { s4*##e0.333 \clef "bass_8" }
  \context Staff = "org" \new Voice { s4*##e0.663  cis,, 4*##e1.318 
_"-11.73¢" }
  \context Staff = "org" \new Voice { s4*##e13.655  bes,, 4*##e1.112 
_"+3.91¢" }
  \context Staff = "org" \new Voice { s4*##e13.655  \clef "bass_8" }
  \context Staff = "org" \new Voice { s4*##e13.933  cis,, 4*##e1.108 
_"-11.73¢" }
  \context Staff = "org" \new Voice { s4*##e13.933  \clef "bass_8" }
  \context Staff = "org" \new Voice { s4*##e14.21  f,, 4*##e1.105 _"+1.96¢" 
}
  \context Staff = "org" \new Voice { s4*##e14.21  \clef "bass_8" }
  \context Staff = "org" \new Voice { s4*##e14.487  c, 4*##e1.101 _"0.0¢" }
  \context Staff = "org" \new Voice { s4*##e14.487  \clef "bass_8" }
  \context Staff = "org" \new Voice { s4*##e14.762  fis,, 4*##e1.097 
_"-9.78¢" }
  \context Staff = "org" \new Voice { s4*##e14.762  \clef "bass_8" }
  \context Staff = "org" \new Voice { s4*##e15.036  f,, 4*##e1.094 
_"+1.96¢" }
  \context Staff = "org" \new Voice { s4*##e15.036  \clef "bass_8" }
  \context Staff = "senot" \new Voice { s4*##e14.486  bes, 4*##e1.101 
_"+3.91¢" }
  \context Staff = "senot" \new Voice { s4*##e14.486  \clef "bass_8" }
  \context Staff = "senot" \new Voice { s4*##e14.762  f,, 4*##e1.097 
_"+1.96¢" }
  \context Staff = "senot" \new Voice { s4*##e14.762  \clef "bass_8" }
  \context Staff = "senot" \new Voice { s4*##e15.036  cis,, 4*##e1.094 
_"-11.73¢" }
  \context Staff = "senot" \new Voice { s4*##e15.036  \clef "bass_8" }
  \context Staff = "timeline" \new Voice { s4*##e1  <> ^\markup"1" \bar "!" 
 
}
  \context Staff = "timeline" \new Voice { s4*##e2  <> ^\markup"2" \bar "!" 
 
}
  \context Staff = "timeline" \new Voice { s4*##e3  <> ^\markup"3" \bar "!" 
 
}
  \context Staff = "timeline" \new Voice { s4*##e4  <> ^\markup"4" \bar "!" 
 
}
  \context Staff = "timeline" \new Voice { s4*##e5  \break }
  \context Staff = "timeline" \new Voice { s4*##e6  <> ^\markup"6" \bar "!" 
 
}
  \context Staff = "timeline" \new Voice { s4*##e7  <> ^\markup"7" \bar "!" 
 
}
  \context Staff = "timeline" \new Voice { s4*##e8  <> ^\markup"8" \bar "!" 
 
}
  \context Staff = "timeline" \new Voice { s4*##e9  <> ^\markup"9" \bar "!" 
 
}
  \context Staff = "timeline" \new Voice { s4*##e10  \break }
  \context Staff = "timeline" \new Voice { s4*##e11  <> ^\markup"11" \bar 
"!"  }
  \context Staff = "timeline" \new Voice { s4*##e12  <> ^\markup"12" \bar 
"!"  }
  \context Staff = "timeline" \new Voice { s4*##e13  <> ^\markup"13" \bar 
"!"  }
  \context Staff = "timeline" \new Voice { s4*##e14  <> ^\markup"14" \bar 
"!"  }
  \context Staff = "timeline" \new Voice { s4*##e15  \break }
  \context Staff = "timeline" \new Voice { s4*##e16  <> ^\markup"16" \bar 
"!"  }
>>

But I wouldn’t really do the counters as separate markups in the first place, 
but add them to the bar line stencil, e.g. do something like

\new RhythmicStaff = "timeline" \with {
  \override BarLine.stencil =
  #(grob-transformer
'stencil
(lambda (grob orig)
  (let ((text (ly:text-interface::print grob)))
(ly:stencil-add
 orig
   

barline in proportional notation disappear

[Cordelia]

Hello,

A while back, I reached out to this mailing list seeking assistance in building 
a Csound to LilyPond converter. What I had in mind was a tool to enhance the 
readability and presentation of Csound scores using LilyPond.

For context, the Csound score format I'm working with is relatively 
straightforward and consists of the following fields:   
   (at least).

With your help, we managed to devise a solution that looks something like this:

\context Staff = "org" \new Voice \after 4*##e0.333 { f,, 4*##e1.324 \- 
_"+1.96¢" } <>

It works well, but now when I’m building something more complex I have some 
incoherencies.

Why the first system do not show bar lines marking the seconds in this code?
Also they do not appear in the last measure of the system..
Is this a good approach to make the result?
thank u !


\version "2.24.0"

\paper {
#(set-paper-size "a4landscape")
print-page-number = ##t
system-separator-markup = \slashSeparator
}

\layout {
\context {
\Score
proportionalNotationDuration = #(ly:make-moment 1/48)
\override SpacingSpanner.uniform-stretching = ##t
\override TimeSignature.stencil = ##f
\override TextScript.font-size = #-9
}
\context {
\Voice
\remove Stem_engraver
\remove Dots_engraver
\override NoteHead.duration-log = 2
}
}

<<
%===
\new RhythmicStaff = timeline
\new Staff = "org"
\new Staff = "senot"
\cadenzaOn
%===
\context Staff = "org" \new Voice \after 4*##e0.333 { f,, 4*##e1.324 _"+1.96¢" 
} <>
\context Staff = "org" \new Voice \after 4*##e0.333 { \clef "bass_8" } <>
\context Staff = "org" \new Voice \after 4*##e0.663 { cis,, 4*##e1.318 
_"-11.73¢" } <>
\context Staff = "org" \new Voice \after 4*##e13.655 { bes,, 4*##e1.112 
_"+3.91¢" } <>
\context Staff = "org" \new Voice \after 4*##e13.655 { \clef "bass_8" } <>
\context Staff = "org" \new Voice \after 4*##e13.933 { cis,, 4*##e1.108 
_"-11.73¢" } <>
\context Staff = "org" \new Voice \after 4*##e13.933 { \clef "bass_8" } <>
\context Staff = "org" \new Voice \after 4*##e14.21 { f,, 4*##e1.105 _"+1.96¢" 
} <>
\context Staff = "org" \new Voice \after 4*##e14.21 { \clef "bass_8" } <>
\context Staff = "org" \new Voice \after 4*##e14.487 { c, 4*##e1.101 _"0.0¢" } 
<>
\context Staff = "org" \new Voice \after 4*##e14.487 { \clef "bass_8" } <>
\context Staff = "org" \new Voice \after 4*##e14.762 { fis,, 4*##e1.097 
_"-9.78¢" } <>
\context Staff = "org" \new Voice \after 4*##e14.762 { \clef "bass_8" } <>
\context Staff = "org" \new Voice \after 4*##e15.036 { f,, 4*##e1.094 _"+1.96¢" 
} <>
\context Staff = "org" \new Voice \after 4*##e15.036 { \clef "bass_8" } <>
\context Staff = "senot" \new Voice \after 4*##e14.486 { bes, 4*##e1.101 
_"+3.91¢" } <>
\context Staff = "senot" \new Voice \after 4*##e14.486 { \clef "bass_8" } <>
\context Staff = "senot" \new Voice \after 4*##e14.762 { f,, 4*##e1.097 
_"+1.96¢" } <>
\context Staff = "senot" \new Voice \after 4*##e14.762 { \clef "bass_8" } <>
\context Staff = "senot" \new Voice \after 4*##e15.036 { cis,, 4*##e1.094 
_"-11.73¢" } <>
\context Staff = "senot" \new Voice \after 4*##e15.036 { \clef "bass_8" } <>
\context Staff = timeline \new Voice \after 4*##e1 { s1 ^\markup"1" \bar "!"  } 
<>
\context Staff = timeline \new Voice \after 4*##e2 { s1 ^\markup"2" \bar "!"  } 
<>
\context Staff = timeline \new Voice \after 4*##e3 { s1 ^\markup"3" \bar "!"  } 
<>
\context Staff = timeline \new Voice \after 4*##e4 { s1 ^\markup"4" \bar "!"  } 
<>
\context Staff = timeline \new Voice \after 4*##e5 { \break } <>
\context Staff = timeline \new Voice \after 4*##e6 { s1 ^\markup"6" \bar "!"  } 
<>
\context Staff = timeline \new Voice \after 4*##e7 { s1 ^\markup"7" \bar "!"  } 
<>
\context Staff = timeline \new Voice \after 4*##e8 { s1 ^\markup"8" \bar "!"  } 
<>
\context Staff = timeline \new Voice \after 4*##e9 { s1 ^\markup"9" \bar "!"  } 
<>
\context Staff = timeline \new Voice \after 4*##e10 { \break } <>
\context Staff = timeline \new Voice \after 4*##e11 { s1 ^\markup"11" \bar "!"  
} <>
\context Staff = timeline \new Voice \after 4*##e12 { s1 ^\markup"12" \bar "!"  
} <>
\context Staff = timeline \new Voice \after 4*##e13 { s1 ^\markup"13" \bar "!"  
} <>
\context Staff = timeline \new Voice \after 4*##e14 { s1 ^\markup"14" \bar "!"  
} <>
\context Staff = timeline \new Voice \after 4*##e15 { \break } <>
\context Staff = timeline \new Voice \after 4*##e16 { s1 ^\markup"16" \bar "!"  
} <>
>>

Re: Distance from barline to first note of bar

[Kieren MacMillan]

Hi Jean,

>> I know  
>> describes the different spacing-style options, but can you comment on 
>> why/whether one would/should set both this spacing-style *and* another 
>> (e.g., minimum-space)?
> I don't understand the question. How could you set several spacing styles at 
> once?

Well, with other spacing parameters, we can and do, e.g.

score-system-spacing =
#'((basic-distance . 12)
   (minimum-distance . 6)
   (padding . 1)
   (stretchability . 12))

Why not

\override BarLine.space-alist.next-note = #'((semi-fixed-space . 10) 
(minimum-space . 4))

or similar?

Thanks,
Kieren.
__

My work day may look different than your work day. Please do not feel obligated 
to read or respond to this email outside of your normal working hours.

Re: Distance from barline to first note of bar

[Jean Abou Samra]

Le dimanche 16 juillet 2023 à 08:51 -0400, Kieren MacMillan a écrit :
> I know 
> describes the different spacing-style options, but can you comment on
> why/whether one would/should set both this spacing-style *and* another (e.g.,
> minimum-space)?


I don't understand the question. How could you set several spacing styles at
once?

Thanks,
Jean





signature.asc
Description: This is a digitally signed message part

Re: Distance from barline to first note of bar

[Kieren MacMillan]

Hi all,

> I won't comment on the default value

I‘ve always found it too small…

>   \layout {
> \context {
>   \Score
>   \override BarLine.space-alist.next-note = #'(semi-fixed-space . 10)
> }
>   }

I know  
describes the different spacing-style options, but can you comment on 
why/whether one would/should set both this spacing-style *and* another (e.g., 
minimum-space)?

Thanks,
Kieren.

__

My work day may look different than your work day. Please do not feel obligated 
to read or respond to this email outside of your normal working hours.

Re: Distance from barline to first note of bar

[Jean Abou Samra]

I won't comment on the default value, but:

> Can the gap be extended by some ratio of global staff size? (I'm assuming a 
> fixed increase would make problems with scores with a larger basic staff 
> size, like my own.)



Sure:

```
  \layout {
\context {
  \Score
  \override BarLine.space-alist.next-note = #'(semi-fixed-space . 10)
}
  }
```

(it will automatically scale with the global staff size).


signature.asc
Description: This is a digitally signed message part

Distance from barline to first note of bar

[Jakob Pedersen via LilyPond user discussion]

Dear everybody,

So I've been wondering about the distance between the barline and the 
first note of a measure.


I'm not an expert typesetter by any means, but it does seem to me that 
the gap is narrower in lilypond scores than in examples by Gould, for 
instance. I've come up with this comparison:




The example on the left is from a chorale I've made (attached.) The 
Gould example is from page 468 of the 2011 edition.


The ratios of staff height to gap is 3.648 in lilypond, but 2.518 in 
Gould. That means the lilypond gap is ~0,69% of the Gould gap, close to ⅔.


That's quite the difference.

Have I done something that diminishes the gap? (see attached chorale.ly)
Is the smaller gap by design? And if so, would it preferable to have it 
bigger by default?
Can the gap be extended by some ratio of global staff size? (I'm 
assuming a fixed increase would make problems with scores with a larger 
basic staff size, like my own.)


I would appreciate any insight on the matter, both with regards to 
desirable typesetting, my attached example, and how lilypond deals with 
this. (I have yet to figure out how to read the detailed documentations 
of engravers etc.)



Best wishes,

Jakob
Aarhus, Denmark\version "2.25.6"
\language "deutsch"

\header {
  title = "10. Alle mine kilder skal være hos dig"
  composer = \markup { \vspace #1.5 \small { Thomas Laub 1922 } }
  poet = \markup { \italic \small { Uregelmæssig tekst } }
} 

\paper {
  #(set-paper-size "a4landscape")
  markup-system-spacing.basic-distance = #20
}

#(set-global-staff-size 24)

global = {
  \key c \major
  \time 4/2
}

alleminelinjeet = \lyricmode { \override LyricText.font-size = #-2
Al -- le mi -- ne kil -- der skal væ -- re hos "dig! /"
}

alleminerightOne = \relative c' {
  \global
c4 c g' g a2 c4 c | h2 g4 g e1 |
}

alleminerightTwo = \relative c' {
  \global
g4 g d' d c2 e4 e | e2 e4 d c1 |
}

allemineleftOne = \relative c {
  \global
e4 e d d e2 a4 a | g a h h c1 |
}

allemineleftTwo = \relative c {
  \global \voiceTwo
c4 c h h a2 a4 a | e'2 e4 g a1 |
}

\score {
  \new PianoStaff <<
\new Lyrics = "alleminemelodi" \with {
  \override VerticalAxisGroup.staff-affinity = #DOWN
}
\new Staff = "højre" <<
  \new Voice = "sopran" {
\voiceOne
<< \alleminerightOne >>
  }
  \new Voice = "alt" {
\voiceTwo
<< \alleminerightTwo >>
  }
>>
\new Staff = "venstre" <<
  \clef bass
  \new Voice = "tenor" {
\voiceOne
<< \allemineleftOne >>
  }
  \new Voice = "basses" { 
\voiceTwo << \allemineleftTwo >>
  }
>>
\context Lyrics = "alleminemelodi" \lyricsto "sopran" \alleminelinjeet
  >>

  \layout {
indent = 0.0
\context {
  \Score \remove "Bar_number_engraver"
}
  }

}

\markup { \vspace #1 \fill-line { \column { \line {} }
  \right-column { \line { \abs-fontsize #12 {
  \bold v6 \italic { Alle mine kilder skal være hos dig! }
  } } \line { \abs-fontsize #12 {
  \italic { Af dig genfødes skal jord og himmel } } } } }
}

Re: Missing barline

[Pierre Perol-Schneider]

Hi Rip_Mus,
Try:

\relative c' {
  c1 \bar ".|:-|" \break
  c1
}

Cheers,
Pierre

Le dim. 14 mai 2023 à 11:17, Rip _Mus  a
écrit :

> Hello,
> in the following minimal example, at the end of the first line, the
> barline is missing:
>
> ```
> \version "2.24.0"
> \relative c' {
>   c1 \bar ".|:" \break
>   c1
> }
> ```
>
> Is it possible to find a simple solution to implement?
>
> Thank you!
>
> Rip_mus
>

Missing barline

[Rip _Mus]

Hello,
in the following minimal example, at the end of the first line, the barline
is missing:

```
\version "2.24.0"
\relative c' {
  c1 \bar ".|:" \break
  c1
}
```

Is it possible to find a simple solution to implement?

Thank you!

Rip_mus

Re: Note head on barline

[Valentin Petzel]

Hello Immanuel,

The problem here is that the Dots are not placed in the NoteColumn, but in a 
DotsColumn,
so they are not affected by changing the parent of the NoteColumn.

This should solve this (by taking affected Dots and placing them into a new 
DotsColumn:

#(define (Heads_on_bar_lines_engraver context)
   (let ((busy #f))
 (make-engraver
  ((process-music engraver)
   (let ((current (ly:context-current-moment context)))
 (set! busy (filter-map
 (match-lambda
  ((end . grob)
   (and (not (equal? end current))
grob)))
 (ly:context-property context 'busyGrobs '())
  ((stop-translation-timestep engraver)
   (let ((bar (ly:context-property context 'currentBarLine #f)))
 (when (and bar (pair? busy))
   (let* ((col (ly:grob-parent (car busy) X))
  (dots (map (lambda (grob) (ly:grob-object grob 'dot)) busy))
  (dots (filter ly:grob? dots))
  (group (ly:grob-parent bar X)))
 (if (not (null? dots))
 (let ((dcol (ly:engraver-make-grob engraver 'DotColumn '(
   (ly:grob-set-object! dcol 'dots (ly:grob-list->grob-array 
dots))
   (for-each (lambda (dot) (ly:grob-set-parent! dot X dcol)) 
dots)
   (ly:grob-set-parent! dcol X group)))
 (ly:grob-set-parent! col X group)
 (ly:grob-translate-axis! col -0.6 X

Note that DotColumns are supposed to be created on Staff level, so in case
you have multiple Voices this engraver should sit at the staff level (this 
should
cause any problems, as Jean’s code does not really make use of any context
specific stuff).

Cheers,
Valentin

Am Mittwoch, 22. Februar 2023, 17:06:50 CET schrieb Immanuel Asmus:
> Thank you, this works like a charm, even with tuplets, multiple voices
> or staves (as far as I tested).
> There is one case that doesn’t work as expected, but I do not (yet) need
> it: Namely, when the note on the barline is dotted, the dot will not be
> moved. Try, e.g.,
> 
> \fixed c' { \time 3/4 d4 g2. fis8 g a4 }
> 
> instead of the original melody, and you see what I mean.
> 
> Regards,
> Immanuel
> 
> Am 22.02.2023 um 15:49 schrieb Jean Abou Samra:
> > Le mercredi 22 février 2023 à 15:05 +0100, Immanuel Asmus a écrit :
> >> |Dear all, I want to typeset the sincopa as it was customary between
> >> 
> >> 1500 and 1700 AD: A note whose duration would exceed the bar should
> >> be placed directly on the barline. (Attached is a scan from a 1739
> >> edition of one of Geminiani’s sonatas.) Some years ago, I found a
> >> snippet that dealt exactly with this problem and used some excessive
> >> scheme coding, so I know it must be possible. However, I’m unable to
> >> relocate this snippet. Any help would be appreciated. |
> > 
> > For me, this works:
> > |\version "2.25.3" #(define (Heads_on_bar_lines_engraver context) (let
> > 
> > ((busy #f)) (make-engraver ((process-music engraver) (let ((current
> > (ly:context-current-moment context))) (set! busy (filter-map
> > (match-lambda ((end . grob) (and (not (equal? end current)) grob)))
> > (ly:context-property context 'busyGrobs '())
> > ((stop-translation-timestep engraver) (let ((bar (ly:context-property
> > context 'currentBarLine #f))) (when (and bar (pair? busy)) (let ((col
> > (ly:grob-parent (car busy) X)) (group (ly:grob-parent bar X)))
> > (ly:grob-set-parent! col X group) (ly:grob-translate-axis! col -0.6
> > X \layout { \context { \Voice \consists
> > #Heads_on_bar_lines_engraver } } \fixed c' { \time 3/4 r4 d g2 fis8(
> > g) a4 r g b2 a8( b) c'4 r b d' g c'( ees') } |
> > 
> > I am actually pretty surprised that it works, because I would have
> > expected turning note columns into non-musical grobs to wreck all
> > assumptions of the layout engine, but, well, at least on this example,
> > it works. I would not count on it to be super reliable, though.
> > 
> > Best,
> > 
> > Jean



signature.asc
Description: This is a digitally signed message part.

Re: Note head on barline

[Immanuel Asmus]

Thank you, this works like a charm, even with tuplets, multiple voices 
or staves (as far as I tested).
There is one case that doesn’t work as expected, but I do not (yet) need 
it: Namely, when the note on the barline is dotted, the dot will not be 
moved. Try, e.g.,


\fixed c' { \time 3/4 d4 g2. fis8 g a4 }

instead of the original melody, and you see what I mean.

Regards,
Immanuel

Am 22.02.2023 um 15:49 schrieb Jean Abou Samra:


Le mercredi 22 février 2023 à 15:05 +0100, Immanuel Asmus a écrit :

|Dear all, I want to typeset the sincopa as it was customary between 
1500 and 1700 AD: A note whose duration would exceed the bar should 
be placed directly on the barline. (Attached is a scan from a 1739 
edition of one of Geminiani’s sonatas.) Some years ago, I found a 
snippet that dealt exactly with this problem and used some excessive 
scheme coding, so I know it must be possible. However, I’m unable to 
relocate this snippet. Any help would be appreciated. |


For me, this works:

|\version "2.25.3" #(define (Heads_on_bar_lines_engraver context) (let 
((busy #f)) (make-engraver ((process-music engraver) (let ((current 
(ly:context-current-moment context))) (set! busy (filter-map 
(match-lambda ((end . grob) (and (not (equal? end current)) grob))) 
(ly:context-property context 'busyGrobs '()) 
((stop-translation-timestep engraver) (let ((bar (ly:context-property 
context 'currentBarLine #f))) (when (and bar (pair? busy)) (let ((col 
(ly:grob-parent (car busy) X)) (group (ly:grob-parent bar X))) 
(ly:grob-set-parent! col X group) (ly:grob-translate-axis! col -0.6 
X \layout { \context { \Voice \consists 
#Heads_on_bar_lines_engraver } } \fixed c' { \time 3/4 r4 d g2 fis8( 
g) a4 r g b2 a8( b) c'4 r b d' g c'( ees') } |


I am actually pretty surprised that it works, because I would have 
expected turning note columns into non-musical grobs to wreck all 
assumptions of the layout engine, but, well, at least on this example, 
it works. I would not count on it to be super reliable, though.


Best,

Jean

Re: Fwd: Note head on barline

[Jean Abou Samra]

Le mercredi 22 février 2023 à 15:05 +0100, Immanuel Asmus a écrit :
>  Dear all,I want to typeset the sincopa as it was customary 
> between 1500 and 1700 AD: A note whose duration would exceed the bar 
> should be placed directly on the barline. (Attached is a scan from a  
>1739 edition of one of Geminiani’s sonatas.)  
> Some years ago, I found a snippet that dealt exactly with this
>  problem and used some excessive scheme coding, so I know it must be 
> possible. However, I’m unable to relocate this snippet.  
>   Any help would be appreciated.  


For me, this works:

```
\version "2.25.3"

#(define (Heads_on_bar_lines_engraver context)
   (let ((busy #f))
 (make-engraver
  ((process-music engraver)
   (let ((current (ly:context-current-moment context)))
 (set! busy (filter-map
 (match-lambda
  ((end . grob)
   (and (not (equal? end current))
grob)))
 (ly:context-property context 'busyGrobs '())
  ((stop-translation-timestep engraver)
   (let ((bar (ly:context-property context 'currentBarLine #f)))
 (when (and bar (pair? busy))
   (let ((col (ly:grob-parent (car busy) X))
 (group (ly:grob-parent bar X)))
 (ly:grob-set-parent! col X group)
 (ly:grob-translate-axis! col -0.6 X

\layout {
  \context {
\Voice
\consists #Heads_on_bar_lines_engraver
  }
}

\fixed c' {
  \time 3/4
  r4 d g2 fis8( g) a4 r g b2 a8( b) c'4
  r b d' g c'( ees')
}
```

I am actually pretty surprised that it works, because I would have expected 
turning note columns into non-musical grobs to wreck all assumptions of the 
layout engine, but, well, at least on this example, it works. I would not count 
on it to be super reliable, though.

Best,

Jean


signature.asc
Description: This is a digitally signed message part

Re: Visible Barline in ChoirStaff

[David Kastrup]

Leo Correia de Verdier  writes:

> Your example doesn’t work because the bars between the staves are in fact not 
> BarLine grobs, but SpanBar grobs, and they would live in the ChoirStaff 
> context.
> The difference between a ChoirStaff and a StaffGroup is that the Choirstaff 
> doesn’t contain the Span_Bar_Engraver, that creates them. You would need to 
> include the engraver in the ChoirStaff (essentially making it a StaffGroup), 
> \omit the SpanBars you don’t need (all the others) and make just the one you 
> need visible, like:
>
>
> \new ChoirStaff \with { 
>   \consists Span_bar_engraver
>   \omit SpanBar } 
> <<
>   \new Staff { 
> c''1 b' 
> \once \revert ChoirStaff.SpanBar.stencil

Probably nicer written as

  \once \undo \omit ChoirStaff.SpanBar

because that does not require you to know what grob property is affected
by \omit .

> a' }
>   \new Staff { 
> \clef bass
> a1 g f }
>>>
>
>
>> 8 feb. 2023 kl. 16:12 skrev Johannes Roeßler :
>> 
>> Hi Group,
>> 
>> how can I add a visible (in the sense of connecting all staffs)
>> barline in a choirstaff?
>> 
>> I tried  \once \override Staff.BarLine.transparent = ##f \bar "|"
>> 
>> but o course it doesn't work, for its just in a staff...
>> 
>> Best regards
>> Johannes
>> 
>> 
>
>
>

-- 
David Kastrup

Re: Visible Barline in ChoirStaff

[Johannes Roeßler]

excellent! Worked perfect.

Your example doesn’t work because the bars between the staves are in fact not 
BarLine grobs, but SpanBar grobs, and they would live in the ChoirStaff context.
The difference between a ChoirStaff and a StaffGroup is that the Choirstaff 
doesn’t contain the Span_Bar_Engraver, that creates them. You would need to 
include the engraver in the ChoirStaff (essentially making it a StaffGroup), 
\omit the SpanBars you don’t need (all the others) and make just the one you 
need visible, like:


\new ChoirStaff \with {
   \consists Span_bar_engraver
   \omit SpanBar }
<<
   \new Staff {
 c''1 b'
 \once \revert ChoirStaff.SpanBar.stencil
 a' }
   \new Staff {
 \clef bass
 a1 g f }


8 feb. 2023 kl. 16:12 skrev Johannes Roeßler:

Hi Group,

how can I add a visible (in the sense of connecting all staffs) barline in a 
choirstaff?

I tried  \once \override Staff.BarLine.transparent = ##f \bar "|"

but o course it doesn't work, for its just in a staff...

Best regards
Johannes

Re: Visible Barline in ChoirStaff

[Leo Correia de Verdier]

Your example doesn’t work because the bars between the staves are in fact not 
BarLine grobs, but SpanBar grobs, and they would live in the ChoirStaff context.
The difference between a ChoirStaff and a StaffGroup is that the Choirstaff 
doesn’t contain the Span_Bar_Engraver, that creates them. You would need to 
include the engraver in the ChoirStaff (essentially making it a StaffGroup), 
\omit the SpanBars you don’t need (all the others) and make just the one you 
need visible, like:


\new ChoirStaff \with { 
  \consists Span_bar_engraver
  \omit SpanBar } 
<<
  \new Staff { 
c''1 b' 
\once \revert ChoirStaff.SpanBar.stencil 
a' }
  \new Staff { 
\clef bass
a1 g f }
>>


> 8 feb. 2023 kl. 16:12 skrev Johannes Roeßler :
> 
> Hi Group,
> 
> how can I add a visible (in the sense of connecting all staffs) barline in a 
> choirstaff?
> 
> I tried  \once \override Staff.BarLine.transparent = ##f \bar "|"
> 
> but o course it doesn't work, for its just in a staff...
> 
> Best regards
> Johannes
> 
> 

Re: Visible Barline in ChoirStaff

[Johannes Roeßler]

thx Jean, yes I want a ChoirStaff - but only at a specific bar one line 
through ALL voices..




Le 8 févr. 2023 à 16:13, Johannes Roeßler  a écrit :



Hi Group,

how can I add a visible (in the sense of connecting all staffs) 
barline in a choirstaff?


I tried  \once \override Staff.BarLine.transparent = ##f \bar "|"

but o course it doesn't work, for its just in a staff…




Is it really a ChoirStaff that you want? Consider using a StaffGroup 
instead. 
https://lilypond.org/doc/v2.24/Documentation/notation/displaying-staves#grouping-staves

Re: Visible Barline in ChoirStaff

[Jean Abou Samra]

> Le 8 févr. 2023 à 16:13, Johannes Roeßler  a écrit :
> 
> 
> Hi Group,
> 
> how can I add a visible (in the sense of connecting all staffs) barline in a 
> choirstaff?
> 
> I tried  \once \override Staff.BarLine.transparent = ##f \bar "|"
> 
> but o course it doesn't work, for its just in a staff…
> 


Is it really a ChoirStaff that you want? Consider using a StaffGroup instead. 
https://lilypond.org/doc/v2.24/Documentation/notation/displaying-staves#grouping-staves

Visible Barline in ChoirStaff

[Johannes Roeßler]

Hi Group,

how can I add a visible (in the sense of connecting all staffs) barline 
in a choirstaff?


I tried  \once \override Staff.BarLine.transparent = ##f \bar "|"

but o course it doesn't work, for its just in a staff...

Best regards
Johannes

Re: Barline glyph in markup

[Rip _Mus]

Hi,
thank you for the suggestions!
Attached the piece of notation that I would like to engraver, in a piece
for piano solo.
I was thinking about using two Staff contexts and a Dynamics context
between the staves to put those repeat barline, better if vertically
centered.
Any other suggestions?

Rip_mus

Il ven 3 feb 2023, 15:51 Jean Abou Samra  ha scritto:

> On 03/02/2023 10:50, Rip _Mus wrote:
> > Hi,
> > is it possible to use a repeat barline glyph(opened or closed) in a
> markup? I'm trying to print it centered between two staves within a
> Dynamics context.
> > Thank you in advance!
>
>
> The two other answers work, but I wonder if this might be an XY question.
> Are you looking for something like this?
>
>
> https://lilypond.org/doc/v2.24/Documentation/notation/working-with-ancient-music-_002d-scenarios-and-solutions#mensurstriche-layout
>
> Best,
> Jean
>
>
>

Re: Barline glyph in markup

[Jean Abou Samra]

On 03/02/2023 10:50, Rip _Mus wrote:
> Hi,
> is it possible to use a repeat barline glyph(opened or closed) in a markup? 
> I'm trying to print it centered between two staves within a Dynamics context.
> Thank you in advance!


The two other answers work, but I wonder if this might be an XY question.
Are you looking for something like this?

https://lilypond.org/doc/v2.24/Documentation/notation/working-with-ancient-music-_002d-scenarios-and-solutions#mensurstriche-layout

Best,
Jean




OpenPGP_signature
Description: OpenPGP digital signature

Re: Barline glyph in markup

[Xavier Scheuer]

On Fri, 3 Feb 2023 at 15:03, Valentin Petzel  wrote:
>
> Hi Rip_mus,
>
> Bar Lines are not in fact glyphs, but drawn directly. We could recreate a
> drawing procedure for markups, but the easiest thing to do would probably
be
> to use the \score markup command for this as seen in the appended file.

Hello,

Or we could add the "Bar_engraver" to the Dynamics context, with some
tweaks as the following example shows.

\score {
  <<
\new Staff {
  \new Voice = "melody" {
\relative {
  a'4 a a a
  a a a a
  \repeat volta 2 { b4 b b b }
}
  }
}
\new Dynamics \with {
  \consists "Bar_engraver"
  \override BarLine.bar-extent = #'(-2 . 2)
  \override BarLine.stencil =
  #(lambda (grob)
(if (string=? (ly:grob-property grob 'glyph-name) "|")
(set! (ly:grob-property grob 'glyph-name) ""))
(ly:bar-line::print grob))
} {
  s1\mf
  s1
  \repeat volta 2 { s1\p }
}
  >>
}

Cheers,
Xavier

-- 
Xavier Scheuer 

Re: Barline glyph in markup

[Valentin Petzel]

Hi Rip_mus,

Bar Lines are not in fact glyphs, but drawn directly. We could recreate a 
drawing procedure for markups, but the easiest thing to do would probably be 
to use the \score markup command for this as seen in the appended file.

Cheers,
Valentin

Am Freitag, 3. Februar 2023, 10:50:30 CET schrieb Rip _Mus:
> Hi,
> is it possible to use a repeat barline glyph(opened or closed) in a markup?
> I'm trying to print it centered between two staves within a Dynamics
> context.
> Thank you in advance!
> 
> Rip_mus

#(define-markup-command (bar layout props type) (string?)
   #:properties ((font-size 0))
   (let* ((ref-fs (ly:output-def-lookup layout 'text-font-size 11))
  (unit (* 5 (/ ref-fs 11)))
  (tfs (* (magstep font-size) ref-fs))
  (fs (* tfs 0.722030560219551))
  (mu #{
 \markup\score {
   \layout {
 #(layout-set-staff-size (* 1.15 fs))
   }
   \new Staff \with {
 \remove Clef_engraver
 \remove Time_signature_engraver
 \remove Default_bar_line_engraver
 \omit StaffSymbol
   } { s \bar #type s }
 }
  #})
  (stc (interpret-markup layout props mu))
  (stc (ly:stencil-aligned-to stc X LEFT))
  (stc-height (interval-length (ly:stencil-extent stc Y)))
  (stc (ly:stencil-aligned-to stc Y CENTER))
  (stc (ly:stencil-translate-axis stc (/ fs unit 2)  Y)))
 stc))

\markup \column { \line { This is a BarLine: \bar "|" }
      \line { This is section BarLine: \bar "||" }
      \line { This is an end BarLine: \bar "|." }
  \line { This is a repeat BarLine: \bar ":|." }
  \line { This is a start repeat BarLine: \bar ".|:" }
  \line { This is a double repeat BarLine: \bar ":|.|:" }
  \line { This is a winged repeat BarLine: \bar ":|]" }
  \line { This is a segno BarLine: \bar "S" } }

signature.asc
Description: This is a digitally signed message part.

Barline glyph in markup

[Rip _Mus]

Hi,
is it possible to use a repeat barline glyph(opened or closed) in a markup?
I'm trying to print it centered between two staves within a Dynamics
context.
Thank you in advance!

Rip_mus

Re: sustain to-barline? LP 2.24.0

[Kenneth Wolcott]

Hi Martin;

  I really did not think that I could have another Dynamics Context;
wonderful idea.

Thanks,
Ken

On Thu, Jan 12, 2023 at 12:10 AM Martín Rincón Botero
 wrote:
>
> Hi Kenneth,
>
> you can add another Dynamics context below the lower staff and use it only 
> for pedalling.
>
> Martín.
>
> www.martinrinconbotero.com
>
>
> On Jan 12, 2023 at 7:07 AM,  wrote:
>
> Hi;
>
>   However, placing the sustain pedal actions in the Dynamic Context
> means that the pedal actions show up below the treble clef rather than
> below the bass clef.  This, of course, interferes with hairpins and
> dynamics.  I'd like an RFE to have a sustainContext that pairs with
> the lower staff :-)
>
> Thanks,
> Ken
>
> On Wed, Jan 11, 2023 at 9:32 PM Kenneth Wolcott
>  wrote:
> >
> > Hi;
> >
> >   Now that's weird :-)
> >
> >   Now the sustain pedal bracket style is working as desired.
> >
> > Thanks,
> > Ken
> >
> > On Wed, Jan 11, 2023 at 9:04 PM Kenneth Wolcott
> >  wrote:
> > >
> > > Hi;
> > >
> > >   Placing the sustain pedal actions in the Dynamics Context results in
> > > the sustain pedal bracket style being ignored, reverting to the
> > > default style.
> > >
> > > Thanks,
> > > Ken
> > >
> > > On Wed, Jan 11, 2023 at 8:50 PM Kenneth Wolcott
> > >  wrote:
> > > >
> > > > Hi;
> > > >
> > > >   I decided to place my sustain pedal commands in the Dynamics
> > > > Context; I hope that solves the problem.
> > > >
> > > > Thanks,
> > > > Ken
> > > >
> > > > On Wed, Jan 11, 2023 at 7:29 PM Kenneth Wolcott
> > > >  wrote:
> > > > >
> > > > > Hi;
> > > > >
> > > > > sustain to-barline? LP 2.24.0
> > > > >
> > > > >   I'd like to have the sustain pedal terminate at the bar line, not at
> > > > > the last note in the staff.
> > > > >
> > > > >   Is there a "to-barline" setting for the sustain pedal?  I searched
> > > > > for "to-barline" and found nothing regarding the sustain pedal.
> > > > >
> > > > >   I looked at the mailing list archive and found something in 2015 
> > > > > mentioning:
> > > > >
> > > > > \override Staff.PianoPedalBracket.to-barline = ##t
> > > > >
> > > > >   I tried this but it seems to be ignored.
> > > > >
> > > > > Thanks,
> > > > > Ken Wolcott
>

Re: sustain to-barline? LP 2.24.0

[Martín Rincón Botero]

  
  

 Hi Kenneth,
  

  
you can add another Dynamics context below the lower staff and use it only for 
pedalling.
  

  
Martín.
  
  
  
 www.martinrinconbotero.com
  
  
  

  
  
>   
> On Jan 12, 2023 at 7:07 AM,   (mailto:kennethwolc...@gmail.com)>  wrote:
>   
>   
>   
>  Hi; However, placing the sustain pedal actions in the Dynamic Context means 
> that the pedal actions show up below the treble clef rather than below the 
> bass clef. This, of course, interferes with hairpins and dynamics. I'd like 
> an RFE to have a sustainContext that pairs with the lower staff :-) Thanks, 
> Ken On Wed, Jan 11, 2023 at 9:32 PM Kenneth Wolcott  
>   wrote:  >   >  Hi;  >   >  Now that's weird :-)  
> >   >  Now the sustain pedal bracket style is working as desired.  >   >  
> Thanks,  >  Ken  >   >  On Wed, Jan 11, 2023 at 9:04 PM Kenneth Wolcott  >   
>   wrote:  >   >   >   >  Hi;  >   >   >   >  
> Placing the sustain pedal actions in the Dynamics Context results in  >   >  
> the sustain pedal bracket style being ignored, reverting to the  >   >  
> default style.  >   >   >   >  Thanks,  >   >  Ken  >   >   >   >  On Wed, 
> Jan 11, 2023 at 8:50 PM Kenneth Wolcott  >   > 
> wrote:  >   >   >   >   >   >  Hi;  >   >   >   >   >   >  I decided to place 
> my sustain pedal commands in the Dynamics  >   >   >  Context; I hope that 
> solves the problem.  >   >   >   >   >   >  Thanks,  >   >   >  Ken  >   >   
> >   >   >   >  On Wed, Jan 11, 2023 at 7:29 PM Kenneth Wolcott  >   >   >   
>   wrote:  >   >   >   >   >   >   >   >  Hi;  >   > 
>   >   >   >   >   >   >  sustain to-barline? LP 2.24.0  >   >   >   >   >   > 
>   >   >  I'd like to have the sustain pedal terminate at the bar line, not at 
>  >   >   >   >  the last note in the staff.  >   >   >   >   >   >   >   >  
> Is there a "to-barline" setting for the sustain pedal? I searched  >   >   >  
>  >  for "to-barline" and found nothing regarding the sustain pedal.  >   >   
> >   >   >   >   >   >  I looked at the mailing list archive and found 
> something in 2015 mentioning:  >   >   >   >   >   >   >   >  \override 
> Staff.PianoPedalBracket.to-barline = ##t  >   >   >   >   >   >   >   >  I 
> tried this but it seems to be ignored.  >   >   >   >   >   >   >   >  
> Thanks,  >   >   >   >  Ken Wolcott  
>
>   
  
  
 

Re: sustain to-barline? LP 2.24.0

[Kenneth Wolcott]

Hi;

  However, placing the sustain pedal actions in the Dynamic Context
means that the pedal actions show up below the treble clef rather than
below the bass clef.  This, of course, interferes with hairpins and
dynamics.  I'd like an RFE to have a sustainContext that pairs with
the lower staff :-)

Thanks,
Ken

On Wed, Jan 11, 2023 at 9:32 PM Kenneth Wolcott
 wrote:
>
> Hi;
>
>   Now that's weird :-)
>
>   Now the sustain pedal bracket style is working as desired.
>
> Thanks,
> Ken
>
> On Wed, Jan 11, 2023 at 9:04 PM Kenneth Wolcott
>  wrote:
> >
> > Hi;
> >
> >   Placing the sustain pedal actions in the Dynamics Context results in
> > the sustain pedal bracket style being ignored, reverting to the
> > default style.
> >
> > Thanks,
> > Ken
> >
> > On Wed, Jan 11, 2023 at 8:50 PM Kenneth Wolcott
> >  wrote:
> > >
> > > Hi;
> > >
> > >   I decided to place my sustain pedal commands in the Dynamics
> > > Context; I hope that solves the problem.
> > >
> > > Thanks,
> > > Ken
> > >
> > > On Wed, Jan 11, 2023 at 7:29 PM Kenneth Wolcott
> > >  wrote:
> > > >
> > > > Hi;
> > > >
> > > > sustain to-barline? LP 2.24.0
> > > >
> > > >   I'd like to have the sustain pedal terminate at the bar line, not at
> > > > the last note in the staff.
> > > >
> > > >   Is there a "to-barline" setting for the sustain pedal?  I searched
> > > > for "to-barline" and found nothing regarding the sustain pedal.
> > > >
> > > >   I looked at the mailing list archive and found something in 2015 
> > > > mentioning:
> > > >
> > > > \override Staff.PianoPedalBracket.to-barline = ##t
> > > >
> > > >   I tried this but it seems to be ignored.
> > > >
> > > > Thanks,
> > > > Ken Wolcott

Re: sustain to-barline? LP 2.24.0

[Kenneth Wolcott]

Hi;

  Now that's weird :-)

  Now the sustain pedal bracket style is working as desired.

Thanks,
Ken

On Wed, Jan 11, 2023 at 9:04 PM Kenneth Wolcott
 wrote:
>
> Hi;
>
>   Placing the sustain pedal actions in the Dynamics Context results in
> the sustain pedal bracket style being ignored, reverting to the
> default style.
>
> Thanks,
> Ken
>
> On Wed, Jan 11, 2023 at 8:50 PM Kenneth Wolcott
>  wrote:
> >
> > Hi;
> >
> >   I decided to place my sustain pedal commands in the Dynamics
> > Context; I hope that solves the problem.
> >
> > Thanks,
> > Ken
> >
> > On Wed, Jan 11, 2023 at 7:29 PM Kenneth Wolcott
> >  wrote:
> > >
> > > Hi;
> > >
> > > sustain to-barline? LP 2.24.0
> > >
> > >   I'd like to have the sustain pedal terminate at the bar line, not at
> > > the last note in the staff.
> > >
> > >   Is there a "to-barline" setting for the sustain pedal?  I searched
> > > for "to-barline" and found nothing regarding the sustain pedal.
> > >
> > >   I looked at the mailing list archive and found something in 2015 
> > > mentioning:
> > >
> > > \override Staff.PianoPedalBracket.to-barline = ##t
> > >
> > >   I tried this but it seems to be ignored.
> > >
> > > Thanks,
> > > Ken Wolcott

Re: sustain to-barline? LP 2.24.0

[Kenneth Wolcott]

Hi;

  Placing the sustain pedal actions in the Dynamics Context results in
the sustain pedal bracket style being ignored, reverting to the
default style.

Thanks,
Ken

On Wed, Jan 11, 2023 at 8:50 PM Kenneth Wolcott
 wrote:
>
> Hi;
>
>   I decided to place my sustain pedal commands in the Dynamics
> Context; I hope that solves the problem.
>
> Thanks,
> Ken
>
> On Wed, Jan 11, 2023 at 7:29 PM Kenneth Wolcott
>  wrote:
> >
> > Hi;
> >
> > sustain to-barline? LP 2.24.0
> >
> >   I'd like to have the sustain pedal terminate at the bar line, not at
> > the last note in the staff.
> >
> >   Is there a "to-barline" setting for the sustain pedal?  I searched
> > for "to-barline" and found nothing regarding the sustain pedal.
> >
> >   I looked at the mailing list archive and found something in 2015 
> > mentioning:
> >
> > \override Staff.PianoPedalBracket.to-barline = ##t
> >
> >   I tried this but it seems to be ignored.
> >
> > Thanks,
> > Ken Wolcott

Re: sustain to-barline? LP 2.24.0

[Kenneth Wolcott]

Hi;

  I decided to place my sustain pedal commands in the Dynamics
Context; I hope that solves the problem.

Thanks,
Ken

On Wed, Jan 11, 2023 at 7:29 PM Kenneth Wolcott
 wrote:
>
> Hi;
>
> sustain to-barline? LP 2.24.0
>
>   I'd like to have the sustain pedal terminate at the bar line, not at
> the last note in the staff.
>
>   Is there a "to-barline" setting for the sustain pedal?  I searched
> for "to-barline" and found nothing regarding the sustain pedal.
>
>   I looked at the mailing list archive and found something in 2015 mentioning:
>
> \override Staff.PianoPedalBracket.to-barline = ##t
>
>   I tried this but it seems to be ignored.
>
> Thanks,
> Ken Wolcott

sustain to-barline? LP 2.24.0

[Kenneth Wolcott]

Hi;

sustain to-barline? LP 2.24.0

  I'd like to have the sustain pedal terminate at the bar line, not at
the last note in the staff.

  Is there a "to-barline" setting for the sustain pedal?  I searched
for "to-barline" and found nothing regarding the sustain pedal.

  I looked at the mailing list archive and found something in 2015 mentioning:

\override Staff.PianoPedalBracket.to-barline = ##t

  I tried this but it seems to be ignored.

Thanks,
Ken Wolcott

Re: Missing end-of-stave barline?

[Mark Probert]

Many thanks, Valentin! I find, as a casual user of LP, I get in a “working
rut,” using what works without fulling understanding then consequences.
This explanation is very helpful to me and I’m heading back to rework my
music.

-mark.


On 9 Jan 2023 at 23:57:12, Valentin Petzel  wrote:

> Hello Mark,
>
> somewhat OT, but you should let \repeat volta handle the setting of bar
> lines. If you want winged repeats set
>
> \set Staff.startRepeatBarType = #"[|:"
>
> \set Staff.endRepeatBarType = #":|]"
>
> or even for all Staves
>
> \set Score.startRepeatBarType = #"[|:"
>
> \set Score.endRepeatBarType = #":|]"
>
> Now to your actual problem: As Jean already said with a recent version of
> Lilypond you should let most of the Bars be handled by Lilypond itself:
>
> Use \repeat volta for repeats and \repeat segno for jumps, and use
> \section instead of "||" and \fine instead of "|." and set the
> corresponding context properties as described in this part of the
> documentation:
>
>
> https://lilypond.org/doc/v2.24/Documentation/notation/bars#automatic-bar-lines
>
> This way of doing things allows us to tell Lilypond what we want instead
> of manually specifying what we want things to look like.
>
> But if you want to do things manually you need to keep in mind that at one
> time we can only have one bar line, so \bar "||" \bar "[|:" will only keep
> \bar "[|:". Instead of this you want to use a bar that is "[|:" in staff
> and after line breaks and "||" and the end of line. This can be done using
>
> \bar "[|:-||"
>
> In fact \bar "[|:" will not print anything at the end of a bar, so you
> should usually default to \bar "[|:-|" (single Bar line at end of line).
> (The same holds true for ".|:" by the way!).
>
> Using \repeat, \section, \fine and such will automatically take care of
> constellations such as barline-repeat or double repeats.
>
> Cheers,
>
> Valentin
>
> Am Montag, 9. Jänner 2023, 12:07:07 CET schrieb Mark Probert:
>
> >  Thanks!
>
> >
>
> > -mark.
>
> >
>
> > On 9 Jan 2023 at 17:58:10, Jean Abou Samra  wrote:
>
> > > Le 9 janv. 2023 à 07:56, Mark Probert  a écrit :
>
> > >
>
> > > Hi.
>
> > >
>
> > > When I run this snippet the barline at the end of first stave, which
>
> > > I think should be a “||”, goes “missing” (there is no barline at all).
>
> > >
>
> > > Is there a correct way of setting the end of stave barline in this
> kind of
>
> > > situation?
>
> > >
>
> > >
>
> > >
>
> > >
>
> > > Look up \section in the manual. It is designed for exactly this.
>
> > >
>
> > > Best,
>
> > > Jean
>
>
>

Re: Missing end-of-stave barline?

[Valentin Petzel]

Hello Mark,

somewhat OT, but you should let \repeat volta handle the setting of bar lines. 
If you want 
winged repeats set

\set Staff.startRepeatBarType = #"[|:"
\set Staff.endRepeatBarType = #":|]"

or even for all Staves

\set Score.startRepeatBarType = #"[|:"
\set Score.endRepeatBarType = #":|]"

Now to your actual problem: As Jean already said with a recent version of 
Lilypond you 
should let most of the Bars be handled by Lilypond itself:

Use \repeat volta for repeats and \repeat segno for jumps, and use \section 
instead of "||" 
and \fine instead of "|." and set the corresponding context properties as 
described in this 
part of the documentation:

https://lilypond.org/doc/v2.24/Documentation/notation/bars#automatic-bar-lines[1]

This way of doing things allows us to tell Lilypond what we want instead of 
manually 
specifying what we want things to look like.

But if you want to do things manually you need to keep in mind that at one time 
we can 
only have one bar line, so \bar "||" \bar "[|:" will only keep \bar "[|:". 
Instead of this you 
want to use a bar that is "[|:" in staff and after line breaks and "||" and the 
end of line. 
This can be done using

\bar "[|:-||"

In fact \bar "[|:" will not print anything at the end of a bar, so you should 
usually default 
to \bar "[|:-|" (single Bar line at end of line). (The same holds true for 
".|:" by the way!).

Using \repeat, \section, \fine and such will automatically take care of 
constellations such 
as barline-repeat or double repeats.

Cheers,
Valentin

Am Montag, 9. Jänner 2023, 12:07:07 CET schrieb Mark Probert:
>  Thanks!
> 
> -mark.
> 
> On 9 Jan 2023 at 17:58:10, Jean Abou Samra  wrote:
> > Le 9 janv. 2023 à 07:56, Mark Probert  a écrit :
> > 
> > Hi.
> > 
> > When I run this snippet the barline at the end of first stave, which
> > I think should be a “||”, goes “missing” (there is no barline at all).
> > 
> > Is there a correct way of setting the end of stave barline in this kind of
> > situation?
> > 
> > 
> > 
> > 
> > Look up \section in the manual. It is designed for exactly this.
> > 
> > Best,
> > Jean




[1] 
https://lilypond.org/doc/v2.24/Documentation/notation/bars#automatic-bar-lines


signature.asc
Description: This is a digitally signed message part.

Re: Missing end-of-stave barline?

[Mark Probert]

 Thanks!

-mark.


On 9 Jan 2023 at 17:58:10, Jean Abou Samra  wrote:

>
>
> Le 9 janv. 2023 à 07:56, Mark Probert  a écrit :
>
> Hi.
>
> When I run this snippet the barline at the end of first stave, which
> I think should be a “||”, goes “missing” (there is no barline at all).
>
> Is there a correct way of setting the end of stave barline in this kind of
> situation?
>
>
>
>
> Look up \section in the manual. It is designed for exactly this.
>
> Best,
> Jean
>
>

Re: Missing end-of-stave barline?

[Jean Abou Samra]

> Le 9 janv. 2023 à 07:56, Mark Probert  a écrit :
> 
> Hi.
> 
> When I run this snippet the barline at the end of first stave, which I think 
> should be a “||”, goes “missing” (there is no barline at all). 
> 
> Is there a correct way of setting the end of stave barline in this kind of 
> situation?



Look up \section in the manual. It is designed for exactly this.

Best,
Jean

Missing end-of-stave barline?

[Mark Probert]

Hi.

When I run this snippet the barline at the end of first stave, which
I think should be a “||”, goes “missing” (there is no barline at all).

Is there a correct way of setting the end of stave barline in this kind of
situation?

%% ——
\version "2.24"

parta = {
  aes4 bes c d | d4 ees f g |
}

partb = {
  aes,2 c2 | ees1 |
}

tune = \relative c'' {
  \clef treble
  \key c \minor
  \time 4/4

  \parta \bar "||" \break
  \repeat volta 2 {
 \bar "[|:" \partb \bar ":|]"
   }
}

\score {
  \new Staff  \tune
}
%%—

TIA,
  -mark.

Re: Align markdown to barline?

[Kenneth Flak]

Great, thanks! I'm using 2.22.2, so I suppose \mark is my new friend

Kenneth

--
Roosna & Flak - Contemporary Dance & Music
Web: roosnaflak.com
Code: {github,gitlab}.com/kflak
Mastodon: @k...@sonomu.club
On 20 Nov 2022  00:24, Paul Scott wrote:
>On 11/19/22 11:34 PM, Kenneth Flak wrote:
>> Hi list,
>>
>> Is there a way to (easily) attach a text to a barline? Currently I am doing 
>> this kind of a stunt in order to line it up correctly:
>>
>>
>> left = {
>> \relative c {
>>   \clef bass
>>   c1_"C" d_"P" f_"  C" e_"  C"
>>   f_" P" g_"P" a_"  C" g_"  S"
>>   e_" C" d_"C" c
>> }
>> }
>>
>> ... which obviously is not very sustainable.
>>
>You don't say what version you are using.  \mark for 2.22.2 or \textMark
>for 2.23.81 should be what you want.
>
>NR 1.8.1 for 2.22.2 or 2.23.81 (Notation Reference}
>
>HTH
>
>Paul
>
>

Re: Align markdown to barline?

[Paul Scott]

On 11/19/22 11:34 PM, Kenneth Flak wrote:

Hi list,

Is there a way to (easily) attach a text to a barline? Currently I am doing 
this kind of a stunt in order to line it up correctly:


left = {
\relative c {
  \clef bass
  c1_"C" d_"P" f_"  C" e_"  C"
  f_" P" g_"P" a_"  C" g_"  S"
  e_" C" d_"C" c
}
}

... which obviously is not very sustainable.

You don't say what version you are using.  \mark for 2.22.2 or \textMark 
for 2.23.81 should be what you want.


NR 1.8.1 for 2.22.2 or 2.23.81 (Notation Reference}

HTH

Paul

Align markdown to barline?

[Kenneth Flak]

Hi list,

Is there a way to (easily) attach a text to a barline? Currently I am doing 
this kind of a stunt in order to line it up correctly:


left = {
   \relative c {
 \clef bass
 c1_"C" d_"P" f_"  C" e_"  C"
 f_" P" g_"P" a_"  C" g_"  S"
 e_" C" d_"C" c
   }
}

... which obviously is not very sustainable.

Best,
Kenneth

--
Roosna & Flak - Contemporary Dance & Music
Web: roosnaflak.com
Code: {github,gitlab}.com/kflak
Mastodon: @k...@sonomu.club

Re: Custom scheme engraver (Barline) problem

[Kyle Baldwin]

Jean -

Merci! This is exactly what I needed.

-kwb
On Jul 24, 2022, 11:50 PM -0700, Jean Abou Samra , wrote:
>
>
> > Le 25 juil. 2022 à 08:23, Kyle Baldwin  a écrit :
> >
> > I'm trying to create a custom bar number engraver that will respond to 
> > couple of different events, but wanted to initially try and clone the Bar 
> > number engraver in c to scheme. Everything seems to work the way I want it 
> > to, except for the positioning seems to be wrong. The numbers appear in 
> > line with the top staff as opposed to above the top staff.
> >
> > If someone can help me get these numbers into the "correct" place, it would 
> > be greatly appreciated. I think that it may have something to do with the 
> > side-support not working correctly, but not sure why.
> >
> > Thanks
> >
> > %
> > #(define (Bar_number_ten_engraver context)
> >   ; main let
> >   (let*
> >     ; main let defs
> >     (
> >       ; we need two variables to hold information about current bar number 
> > grobs.
> >       ; The bar-text is for regular bar numbers and the bar-span is for 
> > spanning
> >       ; bar number - i.e., "centered" bar numbers. Default values we can 
> > just
> >       ; mark as empty lists to make error checking easier. (with null?)
> >       (bar-text '())
> >       (bar-span '())
> >       ; The next set of variables are just used for internal state.
> >       (considered-numbering #f) ; flag to mark if we have already processed 
> > this barline
> >       (saw-bar-line #t)         ; flag to set when we see a barline. This 
> > makes it
> >                                 ; so the same barline isn't processed 
> > multiple times.
> >                                 ; although the first barline will never 
> > have a number,
> >                                 ; this should run the check to get things 
> > started
> >       (break-allowed-now #f)    ; store the value read in process-music. 
> > This is
> >                                 ; explained in the default bar number 
> > engraved to
> >                                 ; to avoid engraver order dependance.
> >       ; there are the "class" helper functions
> >       ; this will get the alternate bar number to send to the bar number 
> > formatter
> >       (get-alt-number (lambda (ctx)
> >         (let
> >           (
> >             (alt-number (ly:context-property ctx 'alternativeNumber 0))
> >             (numbering-style (ly:context-property ctx 
> > 'alternativeNumberingStyle)))
> >           ; if alt-number > 0 and numbering-style != 'numbers-with-letters
> >           (if
> >             (and
> >               (> alt-number 0)
> >               (not (eqv? numbering-style 'numbers-with-letters)))
> >             0
> >             alt-number
> >       ; this function either creates the actual bar number if a simple grob 
> > (smob)
> >       ; or starts the spanner if using centered bar numbers.
> >       (create-bar-number (lambda (engr ctx txt)
> >         (let
> >           (
> >             (are-centered-bars (ly:context-property ctx 'centerBarNumbers 
> > #f)))
> >           (if (eqv? are-centered-bars #t)
> >             ; if we're using centered bar numbers
> >             (begin
> >                 (set! bar-span (ly:engraver-make-grob engr 
> > 'CenteredBarNumber '()))
> >                 (ly:spanner-set-bound! bar-span LEFT (ly:context-property 
> > ctx 'currentCommandColumn))
> >                 (ly:grob-set-property! bar-span 'text txt)
> >             )
> >             ; regular bar numbers
> >             (begin
> >                 (set! bar-text (ly:engraver-make-grob engr 'BarNumber '()))
> >                 (ly:grob-set-property! bar-text 'text txt)
> >             )
> >       (consider-creating-bar-number (lambda (engr ctx)
> >         (format #t "Considering creating bar number...~%")
> >         ; note that we considered a bar number here
> >         (set! considered-numbering #t)
> >
> >         ; if there is a center bar number pending, close it out now as we 
> > are now
> >         ; at the next bar line
> >         (when (ly:grob? bar-span) (
> >             ; set right (end) column
> >             (ly:spanner-set-bound! bar-span RIGHT (ly:context-property ctx 
> > 'currentCommandColumn))
> >             ; announce
> >             (ly:engraver-announ

Re: Custom scheme engraver (Barline) problem

[Jean Abou Samra]

> Le 25 juil. 2022 à 08:23, Kyle Baldwin  a écrit :
> 
> 
> I'm trying to create a custom bar number engraver that will respond to couple 
> of different events, but wanted to initially try and clone the Bar number 
> engraver in c to scheme. Everything seems to work the way I want it to, 
> except for the positioning seems to be wrong. The numbers appear in line with 
> the top staff as opposed to above the top staff. 
> 
> If someone can help me get these numbers into the "correct" place, it would 
> be greatly appreciated. I think that it may have something to do with the 
> side-support not working correctly, but not sure why. 
> 
> Thanks 
> 
> %
> #(define (Bar_number_ten_engraver context)
>   ; main let 
>   (let*
> ; main let defs  
> (
>   ; we need two variables to hold information about current bar number 
> grobs.  
>   ; The bar-text is for regular bar numbers and the bar-span is for 
> spanning 
>   ; bar number - i.e., "centered" bar numbers. Default values we can just 
>   ; mark as empty lists to make error checking easier. (with null?)
>   (bar-text '())
>   (bar-span '())
>   ; The next set of variables are just used for internal state. 
>   (considered-numbering #f) ; flag to mark if we have already processed 
> this barline 
>   (saw-bar-line #t) ; flag to set when we see a barline. This 
> makes it 
>     ; so the same barline isn't processed 
> multiple times. 
> ; although the first barline will never have 
> a number, 
> ; this should run the check to get things 
> started 
>   (break-allowed-now #f); store the value read in process-music. This 
> is 
> ; explained in the default bar number 
> engraved to 
> ; to avoid engraver order dependance. 
>   ; there are the "class" helper functions
>   ; this will get the alternate bar number to send to the bar number 
> formatter 
>   (get-alt-number (lambda (ctx) 
> (let 
>   (
> (alt-number (ly:context-property ctx 'alternativeNumber 0))
> (numbering-style (ly:context-property ctx 
> 'alternativeNumberingStyle)))
>   ; if alt-number > 0 and numbering-style != 'numbers-with-letters
>   (if 
> (and 
>   (> alt-number 0) 
>   (not (eqv? numbering-style 'numbers-with-letters)))
> 0
> alt-number
>   ; this function either creates the actual bar number if a simple grob 
> (smob)
>   ; or starts the spanner if using centered bar numbers. 
>   (create-bar-number (lambda (engr ctx txt)
> (let
>   (
> (are-centered-bars (ly:context-property ctx 'centerBarNumbers 
> #f)))
>   (if (eqv? are-centered-bars #t)
> ; if we're using centered bar numbers 
> (begin  
> (set! bar-span (ly:engraver-make-grob engr 'CenteredBarNumber 
> '()))
> (ly:spanner-set-bound! bar-span LEFT (ly:context-property ctx 
> 'currentCommandColumn))
> (ly:grob-set-property! bar-span 'text txt)
> )
> ; regular bar numbers 
> (begin 
> (set! bar-text (ly:engraver-make-grob engr 'BarNumber '()))
> (ly:grob-set-property! bar-text 'text txt)
> )
>   (consider-creating-bar-number (lambda (engr ctx) 
> (format #t "Considering creating bar number...~%") 
> ; note that we considered a bar number here 
> (set! considered-numbering #t)
> 
> ; if there is a center bar number pending, close it out now as we are 
> now 
> ; at the next bar line
> (when (ly:grob? bar-span) ( 
> ; set right (end) column 
> (ly:spanner-set-bound! bar-span RIGHT (ly:context-property ctx 
> 'currentCommandColumn))
> ; announce 
> (ly:engraver-announce-end-grob engr bar-span '())
> ; reset bar-span 
> (set! bar-span '())) 
> ) ; end close bar span block 
> 
> ; actual bar number consider logic 
> (let (
>   (cur-bar (ly:context-property ctx 'currentBarNumber))
>   (measure-pos (ly:context-property ctx 'measurePosition 
> (ly:make-moment 0)))
>   ; bar number formatter 
>   (formatter (ly:context-property ctx 'barNumberFormatter))
> )
>   ; if bar num mod 10 = 0, th

Custom scheme engraver (Barline) problem

[Kyle Baldwin]

I'm trying to create a custom bar number engraver that will respond to couple 
of different events, but wanted to initially try and clone the Bar number 
engraver in c to scheme. Everything seems to work the way I want it to, except 
for the positioning seems to be wrong. The numbers appear in line with the top 
staff as opposed to above the top staff.

If someone can help me get these numbers into the "correct" place, it would be 
greatly appreciated. I think that it may have something to do with the 
side-support not working correctly, but not sure why.

Thanks

%
#(define (Bar_number_ten_engraver context)
  ; main let
  (let*
    ; main let defs
    (
      ; we need two variables to hold information about current bar number 
grobs.
      ; The bar-text is for regular bar numbers and the bar-span is for spanning
      ; bar number - i.e., "centered" bar numbers. Default values we can just
      ; mark as empty lists to make error checking easier. (with null?)
      (bar-text '())
      (bar-span '())
      ; The next set of variables are just used for internal state.
      (considered-numbering #f) ; flag to mark if we have already processed 
this barline
      (saw-bar-line #t)         ; flag to set when we see a barline. This makes 
it
                                ; so the same barline isn't processed multiple 
times.
                                ; although the first barline will never have a 
number,
                                ; this should run the check to get things 
started
      (break-allowed-now #f)    ; store the value read in process-music. This is
                                ; explained in the default bar number engraved 
to
                                ; to avoid engraver order dependance.
      ; there are the "class" helper functions
      ; this will get the alternate bar number to send to the bar number 
formatter
      (get-alt-number (lambda (ctx)
        (let
          (
            (alt-number (ly:context-property ctx 'alternativeNumber 0))
            (numbering-style (ly:context-property ctx 
'alternativeNumberingStyle)))
          ; if alt-number > 0 and numbering-style != 'numbers-with-letters
          (if
            (and
              (> alt-number 0)
              (not (eqv? numbering-style 'numbers-with-letters)))
            0
            alt-number
      ; this function either creates the actual bar number if a simple grob 
(smob)
      ; or starts the spanner if using centered bar numbers.
      (create-bar-number (lambda (engr ctx txt)
        (let
          (
            (are-centered-bars (ly:context-property ctx 'centerBarNumbers #f)))
          (if (eqv? are-centered-bars #t)
            ; if we're using centered bar numbers
            (begin
                (set! bar-span (ly:engraver-make-grob engr 'CenteredBarNumber 
'()))
                (ly:spanner-set-bound! bar-span LEFT (ly:context-property ctx 
'currentCommandColumn))
                (ly:grob-set-property! bar-span 'text txt)
            )
            ; regular bar numbers
            (begin
                (set! bar-text (ly:engraver-make-grob engr 'BarNumber '()))
                (ly:grob-set-property! bar-text 'text txt)
            )
      (consider-creating-bar-number (lambda (engr ctx)
        (format #t "Considering creating bar number...~%")
        ; note that we considered a bar number here
        (set! considered-numbering #t)

        ; if there is a center bar number pending, close it out now as we are 
now
        ; at the next bar line
        (when (ly:grob? bar-span) (
            ; set right (end) column
            (ly:spanner-set-bound! bar-span RIGHT (ly:context-property ctx 
'currentCommandColumn))
            ; announce
            (ly:engraver-announce-end-grob engr bar-span '())
            ; reset bar-span
            (set! bar-span '()))
        ) ; end close bar span block

        ; actual bar number consider logic
        (let (
          (cur-bar (ly:context-property ctx 'currentBarNumber))
          (measure-pos (ly:context-property ctx 'measurePosition 
(ly:make-moment 0)))
          ; bar number formatter
          (formatter (ly:context-property ctx 'barNumberFormatter))
        )
          ; if bar num mod 10 = 0, then we can put a bar number here
          (when
            (eqv? (modulo cur-bar 10) 0)
            (create-bar-number
              engr
              ctx
              (formatter
                cur-bar
                measure-pos
                (- (get-alt-number ctx) 1)
                ctx)))
    ; main let body
    (make-engraver
      (acknowledgers
        (
          (bar-line-interface engraver grob source-engraver)
          (begin
            (format #t "Acknowledged barline.~%")
            (set! saw-bar-line #t)
          )
        )
      )
      ((process-acknowledged engraver)
        (begin
          ; if we sa

Re: Code pointer from end-BarLine to previous NoteHead.?

[Jean Abou Samra]

Le 19/07/2022 à 15:00, David Kastrup a écrit :

Jean Abou Samra  writes:


Meanwhile, like Lukas, I have been unashamedly switching
back to 2.22 when I wished a better diagnostic. This is
what we advise most users to use, so I'm not bothered.
The issue is marked as a regression, so it will have to
be fixed before we release the next stable version anyway.

What was the news regarding this issue on the current stable
(!#$#%!$%$#%!$) 3.0 release of Guile?  What were the roadblockers there?
Anybody who has had enough involvement here to give a quick refresher?



Guile 3.0 still gives poor diagnostics (without error locations)
on evaluated code. Its latest release also gives poor diagnostics
(with ) while byte-compiling, but this is not
problematic for the issue at hand. When I last looked, it
seemed that we'd have to use different APIs in Guile 2 and Guile 3
to get better diagnostics, but it's been a while, I don't recall
the details right now, and for personal reasons I am likely to
be less active for a while.

Re: Code pointer from end-BarLine to previous NoteHead.?

[David Kastrup]

Jean Abou Samra  writes:

> Meanwhile, like Lukas, I have been unashamedly switching
> back to 2.22 when I wished a better diagnostic. This is
> what we advise most users to use, so I'm not bothered.
> The issue is marked as a regression, so it will have to
> be fixed before we release the next stable version anyway.

What was the news regarding this issue on the current stable
(!#$#%!$%$#%!$) 3.0 release of Guile?  What were the roadblockers there?
Anybody who has had enough involvement here to give a quick refresher?

-- 
David Kastrup

Re: Code pointer from end-BarLine to previous NoteHead.?

[Jean Abou Samra]

Le 18/07/2022 à 19:28, Thomas Morley a écrit :

Am Mo., 18. Juli 2022 um 18:43 Uhr schrieb Lukas-Fabian Moser :


I regularly switch back to old Guile v1.8 LilyPond versions (that's very
easy in Frescobaldi) if my Scheme code gets to complicated for me - this
happens quite often :-) - and I want to have meaningful debug messages.
Maybe that's a compromise one has to make for the time being.



That said, ...
It shouldn't be that hard to code with guilev2 in LilyPond.



I think it is worth remembering that the four participants
in this thread are contributors and would likely prefer not
to go back to the stable (“outdated”) version, but after all,
this is what has quality guarantees, unlike the development
version. Yes, there are generally high quality expectations in
this project, meaning that unstable versions are _usually_ very
stable and usable, but quirks are unavoidable, and it simply
takes time and energy to iron them out.

Meanwhile, like Lukas, I have been unashamedly switching
back to 2.22 when I wished a better diagnostic. This is
what we advise most users to use, so I'm not bothered.
The issue is marked as a regression, so it will have to
be fixed before we release the next stable version anyway.

Re: Code pointer from end-BarLine to previous NoteHead.?

[Jean Abou Samra]

Le 18/07/2022 à 18:43, Lukas-Fabian Moser a écrit :

Forgive me for piping up:

I'm not able to say what happened, I'm not able to debug because of
that unhelpful (oh, I'm very polite this evening) guile messages, see
the other thread.

I'm overtired like hell, close to trashing the whole project, and
close to advertising everyone to not use LilyPond for huge custom
codings.


That would be a pity, seeing as you're one of the most virtuoso 
suppliers of non-trivial LilyPond scheme extensions.


I regularly switch back to old Guile v1.8 LilyPond versions (that's 
very easy in Frescobaldi) if my Scheme code gets to complicated for me 
- this happens quite often :-) - and I want to have meaningful debug 
messages. Maybe that's a compromise one has to make for the time being.


In any case, please don't let yourself get frustrated: Remember how 
lots of people were very grateful for your experiences and insights 
regarding extending LilyPond you could share in Salzburg two years 
ago; they are even more important since you declare yourself to be 
"not a programmer", if I recall correctly, and hence probably closer 
to the LilyPond users without a computer science/maths/... background 
than most people on this list (and certainly on -devel) are. This 
project needs you. :-)


Hang on in there!


+1. Thanks for saying this.

Re: Code pointer from end-BarLine to previous NoteHead.?

[David Kastrup]

Thomas Morley  writes:

> I will not vanish from the list/project in the foreseeable future,
> unless hit by bus...
>
> Though in my humble opinion meaningful error messages are the most
> pressing issue and I don't see I could do anything to improve the
> situation.
> That is frustrating, furthermore I was stuck in a huge coding I could
> not debug, because of those not-messages.
> (I'll insert some german words now, not knowing them in english).
> Every time I get such a not-message it feels like "Verarschung".

"getting bullshitted", more or less.  With a similar departure from
polite discourse due to the raised emotions.

> At the end of a day I feel not frustrated but realy pissed.
>
> Sometimes writing about that is a possbility come down a bit, even at
> the risk someone gives me a "Kopfnuss". ;)

rap/whack on the head.

> Nevertheless, did you read
> https://lists.gnu.org/archive/html/lilypond-user/2022-07/msg00234.html
> ?
> Thanks Jean, I found a possibility to workaround.
>
> That said, ...
> It shouldn't be that hard to code with guilev2 in LilyPond.

Well, we start mostly with reaping the drawbacks because the benefits
require more rewriting of LilyPond.

Yes, getting the debugging into saner shape would appear important.

-- 
David Kastrup

Re: Code pointer from end-BarLine to previous NoteHead.?

[Thomas Morley]

Am Mo., 18. Juli 2022 um 18:43 Uhr schrieb Lukas-Fabian Moser :
>
> Forgive me for piping up:
> > I'm not able to say what happened, I'm not able to debug because of
> > that unhelpful (oh, I'm very polite this evening) guile messages, see
> > the other thread.
> >
> > I'm overtired like hell, close to trashing the whole project, and
> > close to advertising everyone to not use LilyPond for huge custom
> > codings.
>
> That would be a pity, seeing as you're one of the most virtuoso
> suppliers of non-trivial LilyPond scheme extensions.
>
> I regularly switch back to old Guile v1.8 LilyPond versions (that's very
> easy in Frescobaldi) if my Scheme code gets to complicated for me - this
> happens quite often :-) - and I want to have meaningful debug messages.
> Maybe that's a compromise one has to make for the time being.
>
> In any case, please don't let yourself get frustrated: Remember how lots
> of people were very grateful for your experiences and insights regarding
> extending LilyPond you could share in Salzburg two years ago; they are
> even more important since you declare yourself to be "not a programmer",
> if I recall correctly, and hence probably closer to the LilyPond users
> without a computer science/maths/... background than most people on this
> list (and certainly on -devel) are. This project needs you. :-)
>
> Hang on in there!
>
> Lukas
>

Hi Lukas,

I will not vanish from the list/project in the foreseeable future,
unless hit by bus...

Though in my humble opinion meaningful error messages are the most
pressing issue and I don't see I could do anything to improve the
situation.
That is frustrating, furthermore I was stuck in a huge coding I could
not debug, because of those not-messages.
(I'll insert some german words now, not knowing them in english).
Every time I get such a not-message it feels like "Verarschung". At
the end of a day I feel not frustrated but realy pissed.

Sometimes writing about that is a possbility come down a bit, even at
the risk someone gives me a "Kopfnuss". ;)

Nevertheless, did you read
https://lists.gnu.org/archive/html/lilypond-user/2022-07/msg00234.html
?
Thanks Jean, I found a possibility to workaround.

That said, ...
It shouldn't be that hard to code with guilev2 in LilyPond.

Cheers,
  Harm

Re: Code pointer from end-BarLine to previous NoteHead.?

[Lukas-Fabian Moser]

Forgive me for piping up:

I'm not able to say what happened, I'm not able to debug because of
that unhelpful (oh, I'm very polite this evening) guile messages, see
the other thread.

I'm overtired like hell, close to trashing the whole project, and
close to advertising everyone to not use LilyPond for huge custom
codings.


That would be a pity, seeing as you're one of the most virtuoso 
suppliers of non-trivial LilyPond scheme extensions.


I regularly switch back to old Guile v1.8 LilyPond versions (that's very 
easy in Frescobaldi) if my Scheme code gets to complicated for me - this 
happens quite often :-) - and I want to have meaningful debug messages. 
Maybe that's a compromise one has to make for the time being.


In any case, please don't let yourself get frustrated: Remember how lots 
of people were very grateful for your experiences and insights regarding 
extending LilyPond you could share in Salzburg two years ago; they are 
even more important since you declare yourself to be "not a programmer", 
if I recall correctly, and hence probably closer to the LilyPond users 
without a computer science/maths/... background than most people on this 
list (and certainly on -devel) are. This project needs you. :-)


Hang on in there!

Lukas

Re: Code pointer from end-BarLine to previous NoteHead.?

[David Kastrup]

Jean Abou Samra  writes:

> Le 18/07/2022 à 00:59, David Kastrup a écrit :
>> Harm is not a C programmer either.  Scheme is his only language and he
>> learnt it because of LilyPond.  So he has no exposure to the low-level
>> nature of C++, nor to the basics of imperative programming languages
>> that are sort of a required firm footing before you dive into the
>> syntactic shitshow that C++ is.
>>
>> I certainly hope that he isn't as miffed at your dismissive attitude as
>> I am since he is one of the most important contributors coming from the
>> user side of LilyPond.
>
>
> I propose that we continue this part of the discussion
> off-list (but it may take me some time to reply).

My whole point was to stop it, not continue it.

-- 
David Kastrup

Re: Code pointer from end-BarLine to previous NoteHead.?

[Jean Abou Samra]

Le 18/07/2022 à 00:59, David Kastrup a écrit :

Harm is not a C programmer either.  Scheme is his only language and he
learnt it because of LilyPond.  So he has no exposure to the low-level
nature of C++, nor to the basics of imperative programming languages
that are sort of a required firm footing before you dive into the
syntactic shitshow that C++ is.

I certainly hope that he isn't as miffed at your dismissive attitude as
I am since he is one of the most important contributors coming from the
user side of LilyPond.



I propose that we continue this part of the discussion
off-list (but it may take me some time to reply).

Re: Code pointer from end-BarLine to previous NoteHead.?

[David Kastrup]

Jean Abou Samra  writes:

> Le 18/07/2022 à 00:44, David Kastrup a écrit :
>> Jean Abou Samra  writes:
>>
>> [Harm:]
>>
>> You are aware that you are not talking to a C++ programmer?  Not exactly
>> a motivating message under the circumstances...
>
>
>
> I learnt C++ (like many things) by pretending I was a
> C++ programmer while I wasn't, and trying to get along.

Harm is not a C programmer either.  Scheme is his only language and he
learnt it because of LilyPond.  So he has no exposure to the low-level
nature of C++, nor to the basics of imperative programming languages
that are sort of a required firm footing before you dive into the
syntactic shitshow that C++ is.

I certainly hope that he isn't as miffed at your dismissive attitude as
I am since he is one of the most important contributors coming from the
user side of LilyPond.

>> Would something like this be a reasonable patch?
>
>
> Yes, in my opinion. I actually tried to display
> the original name some time ago
> 
> but abandoned it (one of my projects for this summer
> is to introduce "grob definitions" akin to context
> definitions, which would make this possible and simple).

Ok, I'll try that.

-- 
David Kastrup

Re: Code pointer from end-BarLine to previous NoteHead.?

[Jean Abou Samra]

Le 18/07/2022 à 00:44, David Kastrup a écrit :

Jean Abou Samra  writes:

[Harm:]

You are aware that you are not talking to a C++ programmer?  Not exactly
a motivating message under the circumstances...




I learnt C++ (like many things) by pretending I was a
C++ programmer while I wasn't, and trying to get along.




Would something like this be a reasonable patch?



Yes, in my opinion. I actually tried to display
the original name some time ago

but abandoned it (one of my projects for this summer
is to introduce "grob definitions" akin to context
definitions, which would make this possible and simple).

Jean

Re: Code pointer from end-BarLine to previous NoteHead.?

[David Kastrup]

Jean Abou Samra  writes:

[Harm:]

>> After some further hours of work, following a different idea, it now
>> displays # (as it should).
>>
>> I'm not able to say what happened, I'm not able to debug because of
>> that unhelpful (oh, I'm very polite this evening) guile messages, see
>> the other thread.
>>
>> I'm overtired like hell, close to trashing the whole project, and
>> close to advertising everyone to not use LilyPond for huge custom
>> codings.
>
>
> Well, how about rolling up your sleeves and working
> on that issue with unhelpful messages? See also my recent
> message to lilypond-devel about the need for help to
> fix regressions.

You are aware that you are not talking to a C++ programmer?  Not exactly
a motivating message under the circumstances...

Would something like this be a reasonable patch?

>From 7e4ff15a40158db8fc065623fbb0f0549ba75f0c Mon Sep 17 00:00:00 2001
From: David Kastrup 
Date: Mon, 18 Jul 2022 00:38:54 +0200
Subject: [PATCH] Include "dead" in name of grobs without reflection

Nothing to do with (undead) vampires: reflection means containing a
type description, and `ly:grob-suicide!` removes that.
---
 lily/grob.cc | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/lily/grob.cc b/lily/grob.cc
index 009c4de206..e014e0dc84 100644
--- a/lily/grob.cc
+++ b/lily/grob.cc
@@ -788,7 +788,9 @@ Grob::name () const
   SCM meta = get_property (this, "meta");
   SCM nm = scm_assq (ly_symbol2scm ("name"), meta);
   nm = (scm_is_pair (nm)) ? scm_cdr (nm) : SCM_EOL;
-  return scm_is_symbol (nm) ? ly_symbol2string (nm) : class_name ();
+  return scm_is_symbol (nm)
+? ly_symbol2string (nm)
+: string ("dead ").append (class_name ());
 }
 
 ADD_INTERFACE (Grob,
-- 
2.34.1




-- 
David Kastrup

Re: Code pointer from end-BarLine to previous NoteHead.?

[Jean Abou Samra]

I tried to use ly.grob-original, though, in the real code it first
returned #.




Namely a dead grob, on which ly:grob-suicide! was called,
and on which grob::is-live? will return #f.

That's the sort of thing that can happen if your callback
gets called after line breaking, at a point where the original
has been killed due to break-visibility. Observe:

\version "2.23.10"

#(define (debug grob)
   (ly:message "~s ~s"
   (ly:item-break-dir grob)
   (ly:grob-original grob)))

{
  \override Staff.BarLine.before-line-breaking = #debug
  \override Staff.BarLine.after-line-breaking = #debug
  c'1
}




After some further hours of work, following a different idea, it now
displays # (as it should).

I'm not able to say what happened, I'm not able to debug because of
that unhelpful (oh, I'm very polite this evening) guile messages, see
the other thread.

I'm overtired like hell, close to trashing the whole project, and
close to advertising everyone to not use LilyPond for huge custom
codings.



Well, how about rolling up your sleeves and working
on that issue with unhelpful messages? See also my recent
message to lilypond-devel about the need for help to
fix regressions.

Best,
Jean

Re: Code pointer from end-BarLine to previous NoteHead.?

[Thomas Morley]

Am So., 17. Juli 2022 um 09:26 Uhr schrieb Jean Abou Samra :
>
>
>
> Le 17/07/2022 à 01:25, Thomas Morley a écrit :
> > Thanks for your explanations, right now I had only a quick glance over
> > them.
> > I'll hopefully have some time soon to dive into it...
> > Nevertheless, before I posted the problem I searched for an
> > 'original'-BarLine-grob, as we have for broken spanners.
> > For (maybe broken) spanners I sometimes switch to that
> > 'original'-grob, would it improve the situation if we had some
> > 'original' for items as well?
>
>
>
> D'oh, why didn't think about that? It does solve the problem too
> (and more elegantly):
>
>
> \version "2.23.11"
>
> tst =
> #(lambda (ctx)
>(let ((nhd #f)
>  (previous-nhd #f)
>  (bar #f))
>(make-engraver
>  (acknowledgers
>((bar-line-interface engraver grob source-engraver)
>  (set! bar grob))
>((note-head-interface engraver grob source-engraver)
>  (set! nhd grob)))
>  ((stop-translation-timestep engraver)
>   (when (and bar previous-nhd)
> ;; for debugging
> (ly:grob-set-property! previous-nhd 'color red)
> (ly:grob-set-object! bar 'element previous-nhd)
> (set! (ly:grob-property bar 'details)
>   (acons 'previous-note-head
>  previous-nhd
>  (ly:grob-property bar 'details
> (when nhd
> ;; Move the next line out of (when ...) if you only want the
> ;; note head from the time step right before, and not the last
> ;; note head seen before the bar line.
> (set! previous-nhd nhd)
> (set! nhd #f))
>   (set! bar #f)
>
> moveBarLineToPrevHead = {
>\override Staff.BarLine.Y-offset =
>  #(lambda (grob)
>(let* ((prev-head (ly:grob-object (ly:grob-original grob)
>  'element
>  #f))
>   (staff-pos (and prev-head (ly:grob-property prev-head
> 'staff-position
> (/ (or staff-pos 0) 2)))
> }
>
> \layout {
>\context {
>\Staff
>\consists \tst
>\moveBarLineToPrevHead
>}
> }
>
> \new Staff { s4 s \bar "." b s c' d' e' f' g' a' b' c'' \bar "|." }
>
>
>
> Not sure why it didn't work when you tried?
>
>
>
> Jean

I tried to use ly.grob-original, though, in the real code it first
returned #.
After some further hours of work, following a different idea, it now
displays # (as it should).

I'm not able to say what happened, I'm not able to debug because of
that unhelpful (oh, I'm very polite this evening) guile messages, see
the other thread.

I'm overtired like hell, close to trashing the whole project, and
close to advertising everyone to not use LilyPond for huge custom
codings.

Re: Code pointer from end-BarLine to previous NoteHead.?

[Thomas Morley]

Am So., 17. Juli 2022 um 09:26 Uhr schrieb Jean Abou Samra :
>
>
>
> Le 17/07/2022 à 01:25, Thomas Morley a écrit :
> > Thanks for your explanations, right now I had only a quick glance over
> > them.
> > I'll hopefully have some time soon to dive into it...
> > Nevertheless, before I posted the problem I searched for an
> > 'original'-BarLine-grob, as we have for broken spanners.
> > For (maybe broken) spanners I sometimes switch to that
> > 'original'-grob, would it improve the situation if we had some
> > 'original' for items as well?
>
>
>
> D'oh, why didn't think about that? It does solve the problem too
> (and more elegantly):

[...]

> Not sure why it didn't work when you tried?

Well, actually I searched for a _function_ returning the unbroken
_item_, because I was under the impression ly:grob-original was fpr
spanners only.
Thus I didn't try it out, my bad.

After a night full sleep, I reseached ly:grob-original in our code base.

I found only one instance where ly:grob-original is used for grobs
which may not be spanners: `offsetter' in music-functions.scm.
Though IR says:
Function: ly:grob-original grob
  Return the unbroken original grob of grob.
Coming from
Return the unbroken original grob of @var{grob}.
in grob-scheme.cc

I think it would be more clear to do
Return the unbroken original grob of @var{grob}, @var{grob} may be an
item or spanner.

If you agree I'd put up a patch.


Cheers,
  Harm

Re: Code pointer from end-BarLine to previous NoteHead.?

[Jean Abou Samra]

Le 17/07/2022 à 01:25, Thomas Morley a écrit :
Thanks for your explanations, right now I had only a quick glance over 
them.

I'll hopefully have some time soon to dive into it...
Nevertheless, before I posted the problem I searched for an
'original'-BarLine-grob, as we have for broken spanners.
For (maybe broken) spanners I sometimes switch to that
'original'-grob, would it improve the situation if we had some
'original' for items as well?




D'oh, why didn't think about that? It does solve the problem too
(and more elegantly):


\version "2.23.11"

tst =
#(lambda (ctx)
  (let ((nhd #f)
    (previous-nhd #f)
    (bar #f))
  (make-engraver
    (acknowledgers
  ((bar-line-interface engraver grob source-engraver)
    (set! bar grob))
  ((note-head-interface engraver grob source-engraver)
    (set! nhd grob)))
    ((stop-translation-timestep engraver)
 (when (and bar previous-nhd)
   ;; for debugging
   (ly:grob-set-property! previous-nhd 'color red)
   (ly:grob-set-object! bar 'element previous-nhd)
   (set! (ly:grob-property bar 'details)
 (acons 'previous-note-head
    previous-nhd
    (ly:grob-property bar 'details
   (when nhd
   ;; Move the next line out of (when ...) if you only want the
   ;; note head from the time step right before, and not the last
   ;; note head seen before the bar line.
   (set! previous-nhd nhd)
   (set! nhd #f))
 (set! bar #f)

moveBarLineToPrevHead = {
  \override Staff.BarLine.Y-offset =
    #(lambda (grob)
  (let* ((prev-head (ly:grob-object (ly:grob-original grob)
    'element
    #f))
 (staff-pos (and prev-head (ly:grob-property prev-head 
'staff-position

   (/ (or staff-pos 0) 2)))
}

\layout {
  \context {
  \Staff
  \consists \tst
  \moveBarLineToPrevHead
  }
}

\new Staff { s4 s \bar "." b s c' d' e' f' g' a' b' c'' \bar "|." }



Not sure why it didn't work when you tried?



Jean

Re: Code pointer from end-BarLine to previous NoteHead.?

[Thomas Morley]

Am Sa., 16. Juli 2022 um 23:12 Uhr schrieb Jean Abou Samra :
>
> Le 16/07/2022 à 20:47, Thomas Morley a écrit :
> > Hi Jean,
> > thanks for the hint.
> > Alas, the code below _ensures_ the NoteHead _before_ the BarLine is
> > taken (if I'm wrong here, I am completely lost), and again the
> > override for BarLine.Y-offset fails.
>
>
> Ah, yes, sigh. This is caused by prebreak substitution.
> You likely know about break substitution, and even if you
> didn't know that term, you definitely know about the concept.
>
> <https://extending-lilypond.readthedocs.io/en/latest/backend.html#grob-pointers>
>
> (What I call) "prebreak substitution" is exactly the same,
> but happening right after translation, _before_ line breaking.
> It's done one items only, and uses break directions as the
> criterion for replacing grobs instead of systems. Concretely,
> the grob pointers in each item are scanned for other items;
> let's assume a pointer to J is found in I. Then J is replaced
> by its broken piece having the same break direction of I.
> If it doesn't exist, the value is removed if it's in a grob
> array, or otherwise replaced with *unspecified*.
>
> I've never been a fan of this, TBH. For example, it doesn't
> play so well with the actual break substitution. If item I
> with break direction LEFT refers to J which is on the non-musical
> column at a line break, then prebreak substitution will replace
> J with its LEFT broken piece, but if I ends up on the system
> just after the line break where J is located, then break
> substitution will again replace that pointer, this time with
> the RIGHT broken piece.
>
> End of line
>
> ||  <- NonMusicalPaperColumn
> ||
> J   <- Item J, LEFT version
>
> -- line break
>
> Beginning of line  End of line
> || ||
> || ||
> J, RIGHT version   Item I, LEFT break dir, with
> pointer to J
> => with prebreak substitution,
> pointer replaced
>with LEFT J above (same break
> dir)
> => with break substitution,
> replaced with
>RIGHT J (same system)
>

Thanks for your explanations, right now I had only a quick glance over them.
I'll hopefully have some time soon to dive into it...

Nevertheless, before I posted the problem I searched for an
'original'-BarLine-grob, as we have for broken spanners.
For (maybe broken) spanners I sometimes switch to that
'original'-grob, would it improve the situation if we had some
'original' for items as well?


>
>
> Maybe this is something to raise on the bug tracker.
> Meanwhile, you can work around it by using a regular
> property (ly:grob-property etc) instead of a pointer
> (ly:grob-object etc).
>
>
> Some code comments:

Thanks for them!
Though, the posted engraver was heavily simplied, I didn't care about
foreseeable bugs or efficiency, it should demonstrate the probelm
nothing else :)
>
> > tst =
> > #(lambda (ctx)
> >(let ((nhds '())
> >  (bar #f))
> >(make-engraver
> >  (acknowledgers
> >((bar-line-interface engraver grob source-engraver)
> >  (set! bar grob))
> >((note-head-interface engraver grob source-engraver)
> >  (set! nhds (cons (cons (ly:context-current-moment ctx) grob) 
> > nhds
> >  ((stop-translation-timestep engraver)
> >(let* ((curr (ly:context-current-moment ctx))
> >   (nhds-to-consider
> > (remove
> >   (lambda (x)
> > (equal? (car x) curr))
> >   nhds))
> >   (sorted-nhds
> > (reverse
> >   (sort
> > nhds-to-consider
> > (lambda (x y)
> >   (ly:moment >  (if (and (ly:grob? bar) (pair? nhds))
>
>
> (pair? sorted-nhds) rather. Otherwise, you have a bug where
> you take the car of the empty list if nhds only contains note
> heads from the current moment.
>
>
> >  (begin
> >(ly:grob-set-property! (cdr (car sorted-nhds)) 'color red)
> >(ly:grob-set-object! bar 'element (car sorted-nhds))
> >(set! bar #f
>
>
>
> The last line has a bug, the (set! ...) shou

Re: Code pointer from end-BarLine to previous NoteHead.?

[Jean Abou Samra]

Le 16/07/2022 à 20:47, Thomas Morley a écrit :

Hi Jean,
thanks for the hint.
Alas, the code below _ensures_ the NoteHead _before_ the BarLine is
taken (if I'm wrong here, I am completely lost), and again the
override for BarLine.Y-offset fails.



Ah, yes, sigh. This is caused by prebreak substitution.
You likely know about break substitution, and even if you
didn't know that term, you definitely know about the concept.

<https://extending-lilypond.readthedocs.io/en/latest/backend.html#grob-pointers>

(What I call) "prebreak substitution" is exactly the same,
but happening right after translation, _before_ line breaking.
It's done one items only, and uses break directions as the
criterion for replacing grobs instead of systems. Concretely,
the grob pointers in each item are scanned for other items;
let's assume a pointer to J is found in I. Then J is replaced
by its broken piece having the same break direction of I.
If it doesn't exist, the value is removed if it's in a grob
array, or otherwise replaced with *unspecified*.

I've never been a fan of this, TBH. For example, it doesn't
play so well with the actual break substitution. If item I
with break direction LEFT refers to J which is on the non-musical
column at a line break, then prebreak substitution will replace
J with its LEFT broken piece, but if I ends up on the system
just after the line break where J is located, then break
substitution will again replace that pointer, this time with
the RIGHT broken piece.

   End of line

   ||  <- NonMusicalPaperColumn
   ||
   J   <- Item J, LEFT version

-- line break

Beginning of line  End of line
|| ||
|| ||
J, RIGHT version   Item I, LEFT break dir, with 
pointer to J
   => with prebreak substitution, 
pointer replaced
  with LEFT J above (same break 
dir)
   => with break substitution, 
replaced with

  RIGHT J (same system)




Maybe this is something to raise on the bug tracker.
Meanwhile, you can work around it by using a regular
property (ly:grob-property etc) instead of a pointer
(ly:grob-object etc).


Some code comments:


tst =
#(lambda (ctx)
   (let ((nhds '())
 (bar #f))
   (make-engraver
 (acknowledgers
   ((bar-line-interface engraver grob source-engraver)
 (set! bar grob))
   ((note-head-interface engraver grob source-engraver)
 (set! nhds (cons (cons (ly:context-current-moment ctx) grob) nhds
 ((stop-translation-timestep engraver)
   (let* ((curr (ly:context-current-moment ctx))
  (nhds-to-consider
(remove
  (lambda (x)
(equal? (car x) curr))
  nhds))
  (sorted-nhds
(reverse
  (sort
nhds-to-consider
(lambda (x y)
  (ly:moment


(pair? sorted-nhds) rather. Otherwise, you have a bug where
you take the car of the empty list if nhds only contains note
heads from the current moment.



 (begin
   (ly:grob-set-property! (cdr (car sorted-nhds)) 'color red)
   (ly:grob-set-object! bar 'element (car sorted-nhds))
   (set! bar #f




The last line has a bug, the (set! ...) should be outside
the (if ...), or the bar line will take note heads after it
if there are only skips before it.

Furthermore, you have quadratic behavior because you sort the
whole list of note heads at every timestep. Overall, I'd write
this engraver more simply -- and efficiently -- as this:

\version "2.23.11"

tst =
#(lambda (ctx)
  (let ((nhd #f)
    (previous-nhd #f)
    (bar #f))
  (make-engraver
    (acknowledgers
  ((bar-line-interface engraver grob source-engraver)
    (set! bar grob))
  ((note-head-interface engraver grob source-engraver)
    (set! nhd grob)))
    ((stop-translation-timestep engraver)
 (when (and bar previous-nhd)
   ;; for debugging
   (ly:grob-set-property! previous-nhd 'color red)
   (set! (ly:grob-property bar 'details)
 (acons 'previous-note-head
    previous-nhd
    (ly:grob-property bar 'details
   (when nhd
   ;; Move the next line out of (when ...) if you only want the
   ;; note head from the time step right before, and not the last
   ;; note head seen before the bar line.
   (set! previous-nhd nhd)
   (set! nhd #f))
 (set! bar #f)

moveBarLineToPrevHead = {
  \override Staff.BarLine.Y-offset =
    #(lambda (grob)
  (let* ((prev-head (as

Re: Code pointer from end-BarLine to previous NoteHead.?

[Thomas Morley]

Am Sa., 16. Juli 2022 um 14:05 Uhr schrieb Jean Abou Samra :
>
>
>
> > Le 16 juil. 2022 à 13:01, Thomas Morley  a écrit :
> >
> > Hi,
> >
> > I'm trying to code an engraver setting a pointer from BarLine to
> > previous NoteHead and an override for BarLine.Y-offset acting upon
> > that pointer.
> > It does not work, if the BarLine is at end.
> >
> > Here a stripped down example (every security is removed and all is
> > heavily simplified):
> >
> > 
> >
> > \version "2.23.9"
> >
> > tst =
> > #(lambda (ctx)
> >  (let ((nc #f)
> >(bar #f))
> >  (make-engraver
> >(acknowledgers
> >  ((bar-line-interface engraver grob source-engraver)
> >(set! bar grob))
> >  ((note-head-interface engraver grob source-engraver)
> >(set! nc grob)))
> >((stop-translation-timestep engraver)
> >  (if (and nc bar)
> >  (ly:grob-set-object! bar 'element nc))
> >
> > moveBarLineToPrevHead =
> >  \override Staff.BarLine.Y-offset =
> >#(lambda (grob)
> >  (let* ((prev-head (ly:grob-object grob 'element))
> > (staff-pos
> >   (if (ly:grob? prev-head)
> >   (ly:grob-property prev-head 'staff-position #f)
> >   #f)))
> >   (pretty-print
> > (list
> >   (cons 'prev-head prev-head)
> >   (cons 'staff-pos staff-pos)))
> >   (/ (or staff-pos 10) 2)))
> >
> > \layout {
> >  \context {
> >  \Staff
> >  \consists \tst
> >  \moveBarLineToPrevHead
> >  }
> > }
> >
> > \new Staff { b4 \bar "." b }
> > \new Staff { b4 \bar "." }
> >
> > 
> >
> > I'm aware the (main) difference between the two staves is the
> > break-direction of the BarLine.
> >
> > Though, how to catch it ?
> > Or how to do it different?
> >
> > Thanks,
> >  Harm
>
>
> In a given timestep, the currentCommandColumn is at the _left_ of the 
> currentMusicalColumn. You’re storing a pointer to the next note head, not the 
> previous.
>
> Jean
>
>

Hi Jean,

thanks for the hint.
Alas, the code below _ensures_ the NoteHead _before_ the BarLine is
taken (if I'm wrong here, I am completely lost), and again the
override for BarLine.Y-offset fails.

tst =
#(lambda (ctx)
  (let ((nhds '())
(bar #f))
  (make-engraver
(acknowledgers
  ((bar-line-interface engraver grob source-engraver)
(set! bar grob))
  ((note-head-interface engraver grob source-engraver)
(set! nhds (cons (cons (ly:context-current-moment ctx) grob) nhds
((stop-translation-timestep engraver)
  (let* ((curr (ly:context-current-moment ctx))
 (nhds-to-consider
   (remove
 (lambda (x)
   (equal? (car x) curr))
 nhds))
 (sorted-nhds
   (reverse
 (sort
   nhds-to-consider
   (lambda (x y)
 (ly:moment

Re: Code pointer from end-BarLine to previous NoteHead.?

[Jean Abou Samra]

> Le 16 juil. 2022 à 13:01, Thomas Morley  a écrit :
> 
> Hi,
> 
> I'm trying to code an engraver setting a pointer from BarLine to
> previous NoteHead and an override for BarLine.Y-offset acting upon
> that pointer.
> It does not work, if the BarLine is at end.
> 
> Here a stripped down example (every security is removed and all is
> heavily simplified):
> 
> 
> 
> \version "2.23.9"
> 
> tst =
> #(lambda (ctx)
>  (let ((nc #f)
>(bar #f))
>  (make-engraver
>(acknowledgers
>  ((bar-line-interface engraver grob source-engraver)
>(set! bar grob))
>  ((note-head-interface engraver grob source-engraver)
>(set! nc grob)))
>((stop-translation-timestep engraver)
>  (if (and nc bar)
>  (ly:grob-set-object! bar 'element nc))
> 
> moveBarLineToPrevHead =
>  \override Staff.BarLine.Y-offset =
>#(lambda (grob)
>  (let* ((prev-head (ly:grob-object grob 'element))
> (staff-pos
>   (if (ly:grob? prev-head)
>   (ly:grob-property prev-head 'staff-position #f)
>   #f)))
>   (pretty-print
> (list
>   (cons 'prev-head prev-head)
>   (cons 'staff-pos staff-pos)))
>   (/ (or staff-pos 10) 2)))
> 
> \layout {
>  \context {
>  \Staff
>  \consists \tst
>  \moveBarLineToPrevHead
>  }
> }
> 
> \new Staff { b4 \bar "." b }
> \new Staff { b4 \bar "." }
> 
> 
> 
> I'm aware the (main) difference between the two staves is the
> break-direction of the BarLine.
> 
> Though, how to catch it ?
> Or how to do it different?
> 
> Thanks,
>  Harm


In a given timestep, the currentCommandColumn is at the _left_ of the 
currentMusicalColumn. You’re storing a pointer to the next note head, not the 
previous.

Jean

Code pointer from end-BarLine to previous NoteHead.?

[Thomas Morley]

Hi,

I'm trying to code an engraver setting a pointer from BarLine to
previous NoteHead and an override for BarLine.Y-offset acting upon
that pointer.
It does not work, if the BarLine is at end.

Here a stripped down example (every security is removed and all is
heavily simplified):



\version "2.23.9"

tst =
#(lambda (ctx)
  (let ((nc #f)
(bar #f))
  (make-engraver
(acknowledgers
  ((bar-line-interface engraver grob source-engraver)
(set! bar grob))
  ((note-head-interface engraver grob source-engraver)
(set! nc grob)))
((stop-translation-timestep engraver)
  (if (and nc bar)
  (ly:grob-set-object! bar 'element nc))

moveBarLineToPrevHead =
  \override Staff.BarLine.Y-offset =
#(lambda (grob)
  (let* ((prev-head (ly:grob-object grob 'element))
 (staff-pos
   (if (ly:grob? prev-head)
   (ly:grob-property prev-head 'staff-position #f)
   #f)))
   (pretty-print
 (list
   (cons 'prev-head prev-head)
   (cons 'staff-pos staff-pos)))
   (/ (or staff-pos 10) 2)))

\layout {
  \context {
  \Staff
  \consists \tst
  \moveBarLineToPrevHead
  }
}

\new Staff { b4 \bar "." b }
\new Staff { b4 \bar "." }



I'm aware the (main) difference between the two staves is the
break-direction of the BarLine.

Though, how to catch it ?
Or how to do it different?

Thanks,
  Harm

Re: Volta barline precedence

[Xavier Scheuer]

On Tue, 21 Sept 2021 at 20:28, Ignacio Lois  wrote:
>
> Hello! I'm working on a score with its set of parts and I've been having
some barline trouble.
>
> I have a \global variable where I define key, time sig, rehearsal marks
and barlines. Along with each rehearsal mark I add a double barline. Now
the problem is, some of the instruments have volta repeats at the beginning
of a section. The score unfolds the repeat and it looks correct, but the
parts end up having a double bar instead of a repeat bar.
>
> This small example illustrates the problem:
http://www.lilybin.com/7yielg/1
>
> Am I missing a setting or is this a bug? In which case, is there a
workaround?

Hello,

It is uncommon that some instruments have a volta repeat whereas others (or
the score/conductor) have them unfolded. They do have different bar numbers
then?!?
See for example if you add \override Score.BarNumber.break-visibility =
##(#t #t #t) to your parts and score.
In your case I would use different \global variables for volta/unfolded.
Now you are basically telling LilyPond to use a double barline instead of
the one from the volta repeat.

Cheers,
Xavier

-- 
Xavier Scheuer 

Volta barline precedence

[Ignacio Lois]

Hello! I'm working on a score with its set of parts and I've been having
some barline trouble.

I have a \global variable where I define key, time sig, rehearsal marks and
barlines. Along with each rehearsal mark I add a double barline. Now the
problem is, some of the instruments have volta repeats at the beginning of
a section. The score unfolds the repeat and it looks correct, but the parts
end up having a double bar instead of a repeat bar.

This small example illustrates the problem: http://www.lilybin.com/7yielg/1

Am I missing a setting or is this a bug? In which case, is there a
workaround?

Thanks in advance

Re: Custom Barline

[Paul Hodges]

All you're missing is the closing angle brackets ">>", which maybe your 
mail program saw as quote marks.

Paul

On 22/08/2021 22:34:47, "ole"  wrote:

>>  \new StaffGroup
>>   <<
>> \new Staff { b1 \mark \default \bar "p|" b \break \bar "p|" b }
>> \new Staff { b1 b b }

>>
>>
>>
>>  HTH,
>>   Harm
>>
>
>
>Unfortunatly your example is not complete here, can you please send it again, 
>thanks!

Re: Custom Barline

[ole]

> Am 22.08.2021 um 18:16 schrieb Thomas Morley :
> 
> Am So., 22. Aug. 2021 um 13:42 Uhr schrieb Paul Hodges :
>> 
>> Encouraged by the fantastic responses to my first problem, I now offer my 
>> other issue.
>> 
>> The composer uses a special barline to mark the phrase pattern of a piece.  
>> The form of this barline is like this:
>> (MS) https://cassland.org/images/PhraseBarMS.jpg
>> (Printed elsewhere) https://cassland.org/images/PhraseBarSet.jpg
>> 
>> In this case I can't even think where to start...
>> 
>> Thanks,
>> Paul
> 
> How about:
> 
> %% Define a new bar-line drawing-procedure
> #(define (make-thick-phrase-bar-line grob extent)
>  "Draw a smaller thick bar line."
>  (let* ((line-thickness (layout-line-thickness grob))
> (thick-thickness (* (ly:grob-property grob 'thick-thickness 1)
>   line-thickness))
> (inner-extent
>   (interval-widen extent (- (ly:staff-symbol-staff-space grob
> (final-extent-thick
>   (bar-line::widen-bar-extent-on-span grob inner-extent)))
> 
>(bar-line::draw-filled-box
>  (cons 0 thick-thickness)
>  final-extent-thick
>  thick-thickness
>  final-extent-thick
>  grob)))
> 
> %% Assign "p" to the new bar-line drawing-procedure
> #(add-bar-glyph-print-procedure "p" make-thick-phrase-bar-line)
> 
> %% Define a ready to use new BarLine
> #(define-bar-line "p|" "p|" #f " |")
> 
> \layout {
>  \context {
>  \Score
>  %% Actually not really needed:
>  \override BarNumber.break-visibility = ##(#t #t #t)
>  \override BarNumber.self-alignment-X = 0
>  }
>  \context {
>  \Staff
>  %% Needed:
>  %% If "p|"-BarLine is used, set 'kern to zero.
>  \override BarLine.before-line-breaking =
>#(lambda (grob)
>  (if (equal? (ly:grob-property grob 'glyph) "p|")
>  (ly:grob-set-property! grob 'kern 0)))
>  }
> }
> 
> \new StaffGroup
>  <<
>\new Staff { b1 \mark \default \bar "p|" b \break \bar "p|" b }
>\new Staff { b1 b b }
>>> 
> 
> 
> 
> HTH,
>  Harm
> 


Unfortunatly your example is not complete here, can you please send it again, 
thanks!

Re: Custom Barline

[Paul Hodges]

Once again - spot on!

I will try to learn from such examples so that I don't need to leech 
like this in the future...

Thanks,
Paul

On 22/08/2021 17:16:48, "Thomas Morley"  
wrote:

>Am So., 22. Aug. 2021 um 13:42 Uhr schrieb Paul Hodges :
>>
>>  Encouraged by the fantastic responses to my first problem, I now offer my 
>> other issue.
>>
>>  The composer uses a special barline to mark the phrase pattern of a piece.  
>> The form of this barline is like this:
>>  (MS) https://cassland.org/images/PhraseBarMS.jpg
>>  (Printed elsewhere) https://cassland.org/images/PhraseBarSet.jpg
>>
>>  In this case I can't even think where to start...
>>
>>  Thanks,
>>  Paul
>
>How about:
>
>%% Define a new bar-line drawing-procedure
>#(define (make-thick-phrase-bar-line grob extent)
>   "Draw a smaller thick bar line."
>   (let* ((line-thickness (layout-line-thickness grob))
>  (thick-thickness (* (ly:grob-property grob 'thick-thickness 1)
>line-thickness))
>  (inner-extent
>(interval-widen extent (- (ly:staff-symbol-staff-space grob
>  (final-extent-thick
>(bar-line::widen-bar-extent-on-span grob inner-extent)))
>
> (bar-line::draw-filled-box
>   (cons 0 thick-thickness)
>   final-extent-thick
>   thick-thickness
>   final-extent-thick
>   grob)))
>
>%% Assign "p" to the new bar-line drawing-procedure
>#(add-bar-glyph-print-procedure "p" make-thick-phrase-bar-line)
>
>%% Define a ready to use new BarLine
>#(define-bar-line "p|" "p|" #f " |")
>
>\layout {
>   \context {
>   \Score
>   %% Actually not really needed:
>   \override BarNumber.break-visibility = ##(#t #t #t)
>   \override BarNumber.self-alignment-X = 0
>   }
>   \context {
>   \Staff
>   %% Needed:
>   %% If "p|"-BarLine is used, set 'kern to zero.
>   \override BarLine.before-line-breaking =
> #(lambda (grob)
>   (if (equal? (ly:grob-property grob 'glyph) "p|")
>   (ly:grob-set-property! grob 'kern 0)))
>   }
>}
>
>\new StaffGroup
>   <<
> \new Staff { b1 \mark \default \bar "p|" b \break \bar "p|" b }
> \new Staff { b1 b b }
>   >>
>
>
>
>HTH,
>   Harm

Re: Custom Barline

[Thomas Morley]

Am So., 22. Aug. 2021 um 13:42 Uhr schrieb Paul Hodges :
>
> Encouraged by the fantastic responses to my first problem, I now offer my 
> other issue.
>
> The composer uses a special barline to mark the phrase pattern of a piece.  
> The form of this barline is like this:
> (MS) https://cassland.org/images/PhraseBarMS.jpg
> (Printed elsewhere) https://cassland.org/images/PhraseBarSet.jpg
>
> In this case I can't even think where to start...
>
> Thanks,
> Paul

How about:

%% Define a new bar-line drawing-procedure
#(define (make-thick-phrase-bar-line grob extent)
  "Draw a smaller thick bar line."
  (let* ((line-thickness (layout-line-thickness grob))
 (thick-thickness (* (ly:grob-property grob 'thick-thickness 1)
   line-thickness))
 (inner-extent
   (interval-widen extent (- (ly:staff-symbol-staff-space grob
 (final-extent-thick
   (bar-line::widen-bar-extent-on-span grob inner-extent)))

(bar-line::draw-filled-box
  (cons 0 thick-thickness)
  final-extent-thick
  thick-thickness
  final-extent-thick
  grob)))

%% Assign "p" to the new bar-line drawing-procedure
#(add-bar-glyph-print-procedure "p" make-thick-phrase-bar-line)

%% Define a ready to use new BarLine
#(define-bar-line "p|" "p|" #f " |")

\layout {
  \context {
  \Score
  %% Actually not really needed:
  \override BarNumber.break-visibility = ##(#t #t #t)
  \override BarNumber.self-alignment-X = 0
  }
  \context {
  \Staff
  %% Needed:
  %% If "p|"-BarLine is used, set 'kern to zero.
  \override BarLine.before-line-breaking =
#(lambda (grob)
  (if (equal? (ly:grob-property grob 'glyph) "p|")
  (ly:grob-set-property! grob 'kern 0)))
  }
}

\new StaffGroup
  <<
\new Staff { b1 \mark \default \bar "p|" b \break \bar "p|" b }
\new Staff { b1 b b }
  >>



HTH,
  Harm

Re: Custom Barline

[Valentin Petzel]

Hello Paul,
I can't give you a working example becauae I am not at home, but you might 
simply override BarLine.stencil. Override it with a function that uses 
ly:stencil-combine-at-edges to tie a suitable stencil to (ly:barline::print 
grob). You might need to mess a bit with the dimensions of that stencil and the 
padding for the barline.

Cheers,
Valentin

22.08.2021 13:42:25 Paul Hodges :

> Encouraged by the fantastic responses to my first problem, I now offer my 
> other issue.
> 
> The composer uses a special barline to mark the phrase pattern of a piece.  
> The form of this barline is like this:
> (MS) https://cassland.org/images/PhraseBarMS.jpg
> (Printed elsewhere) https://cassland.org/images/PhraseBarSet.jpg
> 
> In this case I can't even think where to start...
> 
> Thanks,
> Paul

Re: Custom Barline

[ole]

It looks to me very close to a repetition sign, is there a Postscript 
definition somewhere (which can be tweaked by someone having more knowledge 
than me:-))?



> Am 22.08.2021 um 13:41 schrieb Paul Hodges :
> 
> Encouraged by the fantastic responses to my first problem, I now offer my 
> other issue.
> 
> The composer uses a special barline to mark the phrase pattern of a piece.  
> The form of this barline is like this:
> (MS) https://cassland.org/images/PhraseBarMS.jpg
> (Printed elsewhere) https://cassland.org/images/PhraseBarSet.jpg
> 
> In this case I can't even think where to start...
> 
> Thanks,
> Paul

Custom Barline

[Paul Hodges]

Encouraged by the fantastic responses to my first problem, I now offer 
my other issue.

The composer uses a special barline to mark the phrase pattern of a 
piece.  The form of this barline is like this:
(MS) https://cassland.org/images/PhraseBarMS.jpg
(Printed elsewhere) https://cassland.org/images/PhraseBarSet.jpg

In this case I can't even think where to start...

Thanks,
Paul

Re: barline

[Kees van den Doel]

Thanks!

On Sat, Aug 7, 2021 at 1:53 AM Lukas-Fabian Moser  wrote:

> Hi Kees,
>
> Am 07.08.21 um 08:12 schrieb Kees van den Doel:
> > How can I get all barlines to look like ticks?   As in \bar "'".
> > I got from manual
> >
> > \set Staff.whichBar = "'"
> >
> > but that puts a bar between every note.
> >
> > \override BarLine.glyph = #"'"
>
> That's the final information in
> https://lilypond.org/doc/v2.22/Documentation/notation/bars.html#bar-lines
> :
>
> \version "2.22.0"
>
> \layout {
>\set Timing.defaultBarType = "'"
> }
>
> {
>\repeat unfold 100 c'4
> }
>
> Lukas
>
>

Re: barline

[Lukas-Fabian Moser]

Hi Kees,

Am 07.08.21 um 08:12 schrieb Kees van den Doel:

How can I get all barlines to look like ticks?   As in \bar "'".
I got from manual

\set Staff.whichBar = "'"

but that puts a bar between every note.

\override BarLine.glyph = #"'"


That's the final information in 
https://lilypond.org/doc/v2.22/Documentation/notation/bars.html#bar-lines :


\version "2.22.0"

\layout {
  \set Timing.defaultBarType = "'"
}

{
  \repeat unfold 100 c'4
}

Lukas

barline

[Kees van den Doel]

How can I get all barlines to look like ticks?   As in \bar "'".
I got from manual

\set Staff.whichBar = "'"

but that puts a bar between every note.

\override BarLine.glyph = #"'"

does nothing.

Thanks,
Kees

Re: repeat barline after fine double-barline

[Ahanu Banerjee]

Good points, Aaron, thank you.

-Ahanu

On Sat, May 1, 2021, 22:35 Aaron Hill  wrote:

> On 2021-05-01 5:56 pm, Ahanu Banerjee wrote:
> > Here you go:
> >
> > \version "2.20.0"
> > { \defineBarLine "xyz" #'("|." ".|:" "")
> >   \repeat unfold 7 c'
> >   c'-\tweak X-offset #5 _\markup \bold \italic "Fine"
> >   \bar "xyz" \break
> >   \repeat unfold 7 c' c'_\markup \bold \italic "D.C. al Fine"
> >   \bar ":|." }
>
> To follow convention, you could name the custom bar ".|:-|.".
>
> Also, you probably want to specify the spanning type as well:
>
> 
> \defineBarLine ".|:-|." #'("|." ".|:" ".|")
> 
>
> That makes it more closely match the existing ".|:-||" as defined in
> bar-line.scm:
>
> 
> (define-bar-line ".|:-||" "||" ".|:" ".|")
> 
>
>
> -- Aaron Hill
>

Re: repeat barline after fine double-barline

[Aaron Hill]

On 2021-05-01 5:56 pm, Ahanu Banerjee wrote:

Here you go:

\version "2.20.0"
{ \defineBarLine "xyz" #'("|." ".|:" "")
  \repeat unfold 7 c'
  c'-\tweak X-offset #5 _\markup \bold \italic "Fine"
  \bar "xyz" \break
  \repeat unfold 7 c' c'_\markup \bold \italic "D.C. al Fine"
  \bar ":|." }


To follow convention, you could name the custom bar ".|:-|.".

Also, you probably want to specify the spanning type as well:


\defineBarLine ".|:-|." #'("|." ".|:" ".|")


That makes it more closely match the existing ".|:-||" as defined in 
bar-line.scm:



(define-bar-line ".|:-||" "||" ".|:" ".|")



-- Aaron Hill